From Niklas.Edmundsson@hpc2n.umu.se Tue Jul 1 00:37:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jul 2003 00:37:51 -0700 (PDT) Received: from tekla.ing.umu.se (root@tekla.ing.umu.se [130.239.117.80]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h617bS2x004363 for ; Tue, 1 Jul 2003 00:37:30 -0700 Received: from tekla.ing.umu.se (nikke@tekla.ing.umu.se [130.239.117.80]) by tekla.ing.umu.se (8.12.3/8.12.3/Debian-6.4) with ESMTP id h617bQ0j006731 for ; Tue, 1 Jul 2003 09:37:27 +0200 Date: Tue, 1 Jul 2003 09:37:26 +0200 (CEST) From: Niklas Edmundsson X-X-Sender: nikke@tekla.ing.umu.se To: netdev@oss.sgi.com Subject: martian packet checks breaks multi-homing Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3703 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Niklas.Edmundsson@hpc2n.umu.se Precedence: bulk X-list: netdev Hi! We are setting up a multi homed server (currently running Linux 2.4.18) connected to several physical networks (due to the fact that the server is a dhcp server too). All clients talks to the main interface on the machine, routing is done by the network equipment. The problem is that when a client tries to talk to the main interface of the server (not on the same network), the server tags the packets as martian source and discards them! It's a perfectly valid packet since the client is not even aware of the servers extra interface on the network at this point and thus talks to the main interface via the default gateway and the normal routing on the campus network. This feature is desirable if you are doing some sort of routing or firewalling when there are no reason to talk to the other interface, but when doing multi-homing it's not what you want if you have an environment where clients talks to a main interface of a machine to establish communication (due to higher bandwidth or other reasons). I haven't even been able to find a way to disable or circumvent the check other than edit the source (fib_validate_source() is rather hard to read by the way). It would be nice if there existed a runtime way to disable it. I have done this setup a number of times using Solaris and AIX boxes, and it's a simple thing that really ought to work... If things are unclear or I have forgotten/missed something just tell me so and I'll try to clarify. /Nikke -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Niklas Edmundsson, Admin @ {acc,hpc2n,ing}.umu.se | nikke@hpc2n.umu.se --------------------------------------------------------------------------- Egotist: Thinks he's in the groove when he's in a rut =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From nikke@ing.umu.se Tue Jul 1 02:22:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jul 2003 02:23:02 -0700 (PDT) Received: from tekla.ing.umu.se (root@tekla.ing.umu.se [130.239.117.80]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h619Mp2x014958 for ; Tue, 1 Jul 2003 02:22:52 -0700 Received: from tekla.ing.umu.se (nikke@tekla.ing.umu.se [130.239.117.80]) by tekla.ing.umu.se (8.12.3/8.12.3/Debian-6.4) with ESMTP id h619Mo0j009659 for ; Tue, 1 Jul 2003 11:22:50 +0200 Date: Tue, 1 Jul 2003 11:22:50 +0200 (CEST) From: Niklas Edmundsson To: netdev@oss.sgi.com Subject: Re: martian packet checks breaks multi-homing In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3704 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nikke@ing.umu.se Precedence: bulk X-list: netdev On Tue, 1 Jul 2003, Niklas Edmundsson wrote: > > Hi! > > We are setting up a multi homed server (currently running Linux > 2.4.18) connected to several physical networks (due to the fact that > the server is a dhcp server too). > I haven't even been able to find a way to disable or circumvent the > check other than edit the source (fib_validate_source() is rather hard > to read by the way). It would be nice if there existed a runtime way > to disable it. Ignore me. Just after I sent this mail I found /proc/sys/net/ipv4/conf/*/rp_filter which solves all my problems. Sorry for the inconvenience. /Nikke - spanks the paranoid debian startup scripts a bit. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Niklas Edmundsson, Admin @ {acc,hpc2n,ing}.umu.se | nikke@ing.umu.se --------------------------------------------------------------------------- There once was a man from Nantucket.You've been talking to Garibaldi! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From srompf@barkeeper.isg.de Tue Jul 1 02:51:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jul 2003 02:51:51 -0700 (PDT) Received: from mail.isg.de (rzfoobar.is-asp.com [217.11.194.155]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h619pU2x016820 for ; Tue, 1 Jul 2003 02:51:31 -0700 Received: from barkeeper.isg.de (barkeeper.frankfurter-softwarefabrik.de [192.168.6.182]) by mail.isg.de (Postfix) with ESMTP id 6D1C51312C1E; Tue, 1 Jul 2003 11:11:27 +0200 (CEST) Received: from localhost (localhost [[UNIX: localhost]]) by barkeeper.isg.de (8.9.3/8.9.3) id LAA00936; Tue, 1 Jul 2003 11:11:26 +0200 From: Stefan Rompf To: Niklas Edmundsson , netdev@oss.sgi.com Subject: Re: martian packet checks breaks multi-homing Date: Tue, 1 Jul 2003 11:11:05 +0200 User-Agent: KMail/1.5.9.1i References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200307011111.26762.srompf@isg.de> X-archive-position: 3705 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: srompf@isg.de Precedence: bulk X-list: netdev Am Dienstag, 1. Juli 2003 09:37 schrieb Niklas Edmundsson: > The problem is that when a client tries to talk to the main interface > of the server (not on the same network), the server tags the packets > as martian source and discards them! It's a perfectly valid packet > If things are unclear or I have forgotten/missed something just tell > me so and I'll try to clarify. Have a look at linux/Documentation/networking/ip-sysctl.txt, rp_filter Stefan -- "doesn't work" is not a magic word to explain everything. From mtk-lists@gmx.net Tue Jul 1 04:23:57 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jul 2003 04:24:04 -0700 (PDT) Received: from mx0.gmx.net (mx0.gmx.net [213.165.64.100]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61BNt2x020920 for ; Tue, 1 Jul 2003 04:23:56 -0700 Received: (qmail 7717 invoked by uid 0); 1 Jul 2003 11:23:49 -0000 Date: Tue, 1 Jul 2003 13:23:49 +0200 (MEST) From: mtk-lists@gmx.net To: netdev@oss.sgi.com MIME-Version: 1.0 Subject: shutdown() and SHUT_RD on TCP sockets - broken? X-Priority: 3 (Normal) X-Authenticated-Sender: #0018454895@gmx.net X-Authenticated-IP: [212.18.21.202] Message-ID: <14321.1057058629@www1.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-archive-position: 3706 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mtk-lists@gmx.net Precedence: bulk X-list: netdev Hello, I've done quite some searching, but have so far not found an answer to the question of why does the behaviour described below occur on Linux... According to SUSv3, if we perform a shutdown(fd, SHUT_RD) on a socket, then further reads on that socket should be disabled. In the AF_UNIX domain, all is fine -- things operate as I expect. However, for TCP sockets, things are different (tested on 2.2.14, and 2.4.20): 1. If we perform a read() on the socket and there is no data, then 0 (EOF) is (immediately) returned. (This is what I expected.) 2. However, the peer can still write() to the socket, and afterwards we can read() that data from the socket, even though the reading half of the socket should be shut down. Instead of this behaviour, I expected the read() to continue to return 0 as in point 1. This is what we see for example in FreeBSD 4.8, Tru64 5.1B, and HP/UX 11. I thought that most implementations (other than Linux) did things this way, but I've just now gone and tested things on Solaris 8, and it seems to behave in the same way as Linux. I've read the relevant source code to confirm the anomalous behaviour described here. But, why do things happen in this way on Linux? 3. (A side point.) Looking at Stevens UNPv1, p161, there is a statement that after a SHUT_RD, "any data for a TCP socket is acknowledged and then silently discarded". This implies to me that the sender could keep on writing to the socket and never block. However, on Linux, if the peer keeps sending to a socket, then eventually (the channel is filled and) it blocks. I see that this also occurs on FreeBSD 4.8, Tru64 5.1B, HP/UX 11 and Solaris 8. Have I misunderstood Stevens, or has something changed since the implementation he described (or was his statement wrong)? (In the AF_UNIX domain on Linux, the peer gets SIGPIPE/EPIPE if it keeps writing after a local SHUT_RD.) Thanks Michael -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage! From ahu@outpost.ds9a.nl Tue Jul 1 06:27:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jul 2003 06:27:45 -0700 (PDT) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61DRF2x031102 for ; Tue, 1 Jul 2003 06:27:15 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id D904440F5; Tue, 1 Jul 2003 14:58:08 +0200 (CEST) Date: Tue, 1 Jul 2003 14:58:08 +0200 From: bert hubert To: Andreas Jellinghaus Cc: "netdev@oss.sgi.com" Subject: Re: ipsec without interface Message-ID: <20030701125808.GA19408@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Andreas Jellinghaus , "netdev@oss.sgi.com" References: <1054235787.605.21.camel@simulacron> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1054235787.605.21.camel@simulacron> User-Agent: Mutt/1.3.28i X-archive-position: 3707 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev On Thu, May 29, 2003 at 09:16:27PM +0200, Andreas Jellinghaus wrote: > sure, the simple configurations work fine with kernel 2.5.* ipsec. > But I miss the interface and things I did with it. How are these > setups supposed to work without an interface? > > a) in iptables allow everything coming from ipsec0, > allow only ssh and ipsec on eth0. iptables can filter on ESP/AH presence. > b) source address selection. put the default route on ipsec0, Do you need a separate source address? -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From aj@dungeon.inka.de Tue Jul 1 06:31:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jul 2003 06:31:49 -0700 (PDT) Received: from mail.inka.de (mail@quechua.inka.de [193.197.184.2]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61DVW2x031439 for ; Tue, 1 Jul 2003 06:31:33 -0700 Received: from dungeon.inka.de (uucp@[127.0.0.1]) by mail.inka.de with uucp (rmailwrap 0.5) id 19XLEI-0005f6-00; Tue, 01 Jul 2003 15:31:30 +0200 Received: from [192.168.3.1] (unknown [192.168.3.1]) by dungeon.inka.de (Postfix) with ESMTP id F11C421210; Tue, 1 Jul 2003 15:31:24 +0200 (CEST) Subject: Re: ipsec without interface From: Andreas Jellinghaus To: bert hubert Cc: "netdev@oss.sgi.com" In-Reply-To: <20030701125808.GA19408@outpost.ds9a.nl> References: <1054235787.605.21.camel@simulacron> <20030701125808.GA19408@outpost.ds9a.nl> Content-Type: text/plain Message-Id: <1057066404.4054.9.camel@simulacron> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 01 Jul 2003 15:33:24 +0200 Content-Transfer-Encoding: 7bit X-archive-position: 3708 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: aj@dungeon.inka.de Precedence: bulk X-list: netdev On Tue, 2003-07-01 at 14:58, bert hubert wrote: > On Thu, May 29, 2003 at 09:16:27PM +0200, Andreas Jellinghaus wrote: > > sure, the simple configurations work fine with kernel 2.5.* ipsec. > > But I miss the interface and things I did with it. How are these > > setups supposed to work without an interface? > > > > a) in iptables allow everything coming from ipsec0, > > allow only ssh and ipsec on eth0. > > iptables can filter on ESP/AH presence. the packet is seen once as ESP/AH and once as normal (e.g. TCP) packet. where is the connection? how can you see that a packet came in first as ESP/AH packet and was then decrypted, and did not came in without ipsec? with freeswan that was easy: drop everything, unless it is from interface ipsec0. And you always new, packets from ipsec0 came in with valid ipsec encryption, that was easy to make sure. and now? use fwmark? even if that works, its not as easy. > > > b) source address selection. put the default route on ipsec0, > > Do you need a separate source address? I'm a "road warrior", so the local wireless lan gives me a 192.168.* address. For my ipsec tunnel to $company gateway I need get an official address assigned, so I can use that to access the company network, or even the internet (if I don't trust the local network, and don't want unencrypted connections to the internet). I think such a setup will be quite common. local lan some nat company gateway 192.168.0.* <-> 192.168.0.1 <-> 1.2.3.4 ipsec tunnel 1.2.3.5 <-> 1.2.3.4 connetion will use 1.2.3.5 <-> 1.2.3.80 (e.g. company file server, allowing access from 1.2.3.*). ip route del default ip route add default gw 192.168.0.1 src 1.2.3.5 yes, that works. but it's not nice. also company getway needs a ip route add 1.2.3.5 dev eth0/1/2/whatever even though no packet to "1.2.3.5" will ever be on any wire - the packet will be alway encrypted and have a final ip address somewhere in the internet or wireless network. hmm. I haven't tried to use an explicit ipip tunnel. did anyone use ESP in transport mode to encrypt packets of an IPIP tunnel? that might help me. Regards, Andreas From shmulik.hen@intel.com Tue Jul 1 06:44:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jul 2003 06:44:39 -0700 (PDT) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61DiH2x031807 for ; Tue, 1 Jul 2003 06:44:18 -0700 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h61DdQM00581 for ; Tue, 1 Jul 2003 13:39:26 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h61DbKa02239 for ; Tue, 1 Jul 2003 13:37:20 GMT Received: from jrslxjul1.npdj.intel.com ([10.12.254.186]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003070106403620572 ; Tue, 01 Jul 2003 06:40:38 -0700 Date: Tue, 1 Jul 2003 16:44:11 +0300 (IDT) From: Shmulik Hen X-X-Sender: Reply-To: Shmulik Hen To: bond-devel , "Chad N. Tindel" , Jay Vosburgh , Jeff Garzik , linux-netdev cc: Amir Noam , Noam Marom , Shmulik Hen , Tsippy Mendelson Subject: [patch][bonding] Fix change active for ALB/TLB Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3709 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Hi, The following patch fixes bonding's change active interface operation for ALB/TLB modes. It used to incorrectly set the old active interface's state to BACKUP (which is required only for active-backup mode) and would cause that slave not to take part in load sharing. It should be applied on latest net-drivers-2.4 BK tree. -- | Shmulik Hen | | Israel Design Center (Jerusalem) | | LAN Access Division | | Intel Communications Group, Intel corp. | diff -Nuarp linux-2.4.22-pre1-netdrvr1/drivers/net/bonding/bond_main.c linux-2.4.22-pre1-netdrvr1-devel/drivers/net/bonding/bond_main.c --- linux-2.4.22-pre1-netdrvr1/drivers/net/bonding/bond_main.c Mon Jun 30 15:29:56 2003 +++ linux-2.4.22-pre1-netdrvr1-devel/drivers/net/bonding/bond_main.c Mon Jun 30 15:29:57 2003 @@ -385,6 +385,9 @@ * - In conjunction with fix for ifenslave -c, in * bond_change_active(), changing to the already active slave * is no longer an error (it successfully does nothing). + * + * 2003/06/30 - Amir Noam + * - Fixed bond_change_active() for ALB/TLB modes. */ #include @@ -429,8 +432,8 @@ #include "bond_3ad.h" #include "bond_alb.h" -#define DRV_VERSION "2.2.13" -#define DRV_RELDATE "June 25, 2003" +#define DRV_VERSION "2.2.14" +#define DRV_RELDATE "June 30, 2003" #define DRV_NAME "bonding" #define DRV_DESCRIPTION "Ethernet Channel Bonding Driver" @@ -1761,8 +1764,11 @@ static int bond_change_active(struct net (oldactive != NULL)&& (newactive->link == BOND_LINK_UP)&& IS_UP(newactive->dev)) { - bond_set_slave_inactive_flags(oldactive); - bond_set_slave_active_flags(newactive); + if (bond_mode == BOND_MODE_ACTIVEBACKUP) { + bond_set_slave_inactive_flags(oldactive); + bond_set_slave_active_flags(newactive); + } + bond_mc_update(bond, newactive, oldactive); bond_assign_current_slave(bond, newactive); printk("%s : activate %s(old : %s)\n", From jmorris@intercode.com.au Tue Jul 1 07:00:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jul 2003 07:00:43 -0700 (PDT) Received: from blackbird.intercode.com.au (IDENT:vrOxXT2uj4iTAwgLdo5TiySDE/u7yS28@blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61E0S2x003973 for ; Tue, 1 Jul 2003 07:00:30 -0700 Received: from excalibur.intercode.com.au (excalibur.intercode.com.au [203.32.101.12]) by blackbird.intercode.com.au (8.11.6p2/8.9.3) with ESMTP id h61E0Er07026; Wed, 2 Jul 2003 00:00:14 +1000 Date: Wed, 2 Jul 2003 00:00:13 +1000 (EST) From: James Morris To: Andreas Jellinghaus cc: bert hubert , "netdev@oss.sgi.com" Subject: Re: ipsec without interface In-Reply-To: <1057066404.4054.9.camel@simulacron> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3710 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@intercode.com.au Precedence: bulk X-list: netdev On 1 Jul 2003, Andreas Jellinghaus wrote: > hmm. I haven't tried to use an explicit ipip tunnel. > did anyone use ESP in transport mode to encrypt packets > of an IPIP tunnel? that might help me. It's known to work on a gre tunnel (if you manually adjust the mtu), so ipip probably works. - James -- James Morris From ja@ssi.bg Tue Jul 1 14:53:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jul 2003 14:53:51 -0700 (PDT) Received: from u.domain.uli (ja.mac.ssi.bg [217.79.71.194]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61LrZ2x015425 for ; Tue, 1 Jul 2003 14:53:40 -0700 Received: from localhost (IDENT:ja@localhost [127.0.0.1]) by u.domain.uli (8.11.6/8.11.6) with ESMTP id h61LvLG02312; Wed, 2 Jul 2003 00:57:21 +0300 Date: Wed, 2 Jul 2003 00:57:21 +0300 (EEST) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: Ben Greear cc: netdev@oss.sgi.com Subject: Re: send-to-self (was Re: routing bug report for 2.4) In-Reply-To: <3EFFEDD7.5020205@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3711 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ja@ssi.bg Precedence: bulk X-list: netdev Hello, On Mon, 30 Jun 2003, Ben Greear wrote: > You should be able to easily test most of the changes your code > if you have a machine with two ethernet interfaces and a loopback > cable... ok, tested the 2.5 version, the patch files are updated: http://www.ssi.bg/~ja/#loop - added missing dev_put on ENETDOWN - removed the checks that ignore oif for local routes as Alexey suggests I have tried simple tests: ICMP, telnet. What I see is that the 2.5 rt_set_nexthop() does not set sysctl_ip_default_ttl if res->fi is NULL and that causes the icmp echo packets to use ttl=0. May be there are still some noisy places like arp_set_predefined, it will need further investigation. I'm stopping here, for now. > My requirements are: > > 1) Both ethernet ports communicate over the exernal link, UDP & IP traffic. Done > Third-party programs if possible, thus I set the flag on the interface in > my patch, not on an individual socket, though I do have to BINDTODEVICE and > policy-base base route to get things working right... Now you have 2 options: - bind to src IP: the app needs to be aware for that - ip route replace local IP2 dev DEV2 ... src IP1 table local: the app does not need to be aware to use this feature Now using BINDTODEVICE can cause problems with this feature, because we do not ignore oif for local destinations, you risk to miss the local route and arp_filter to break the things or worse (not tested) > 1b) Allow both same-subnet comm (eth1 & eth2 are on same subnet), and also > routed traffic (eth1 & eth2 have their own default router, similar to the > previously discussed routing setup) all other routes remain unchanged, I hope > 2) Allow normal non-looped communication on the ports, including policy-based routing > based on source addr. hm, you better know what you mean. As expected, this feature has its drawbacks. The safe way is to teach some apps to bind to IP1 and the apps that are unaware for these loops to use the prefsrc and thus to use lo. There is no much space for improvement here but I'm open for suggestions. > Thanks, > Ben Regards -- Julian Anastasov From greearb@candelatech.com Tue Jul 1 15:07:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jul 2003 15:07:23 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-074.evrtwa1.dsl-verizon.net [4.33.45.74]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61M7I2x015866 for ; Tue, 1 Jul 2003 15:07:18 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h61M7CKk018766; Tue, 1 Jul 2003 15:07:12 -0700 Message-ID: <3F020610.2080109@candelatech.com> Date: Tue, 01 Jul 2003 15:07:12 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Anastasov CC: netdev@oss.sgi.com Subject: Re: send-to-self (was Re: routing bug report for 2.4) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3712 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Julian Anastasov wrote: > Hello, > > On Mon, 30 Jun 2003, Ben Greear wrote: > > >>You should be able to easily test most of the changes your code >>if you have a machine with two ethernet interfaces and a loopback >>cable... > > > ok, tested the 2.5 version, the patch files are updated: > > http://www.ssi.bg/~ja/#loop > > - added missing dev_put on ENETDOWN > - removed the checks that ignore oif for local routes as Alexey suggests > > I have tried simple tests: ICMP, telnet. What I see > is that the 2.5 rt_set_nexthop() does not set sysctl_ip_default_ttl if > res->fi is NULL and that causes the icmp echo packets to use > ttl=0. May be there are still some noisy places like arp_set_predefined, > it will need further investigation. I'm stopping here, for now. How did you get telnet to bind to a particular local interface? Also, what ping syntax did you use? Did you have to modify either of these applications to get them to work? I looked at the patch...but don't have a good enough grasp of the routing code to provide a useful critique. I believe my patch _is_ smaller though ;) Thanks, Ben > > >>My requirements are: >> >>1) Both ethernet ports communicate over the exernal link, UDP & IP traffic. > > > Done > > >> Third-party programs if possible, thus I set the flag on the interface in >> my patch, not on an individual socket, though I do have to BINDTODEVICE and >> policy-base base route to get things working right... > > > Now you have 2 options: > > - bind to src IP: the app needs to be aware for that > > - ip route replace local IP2 dev DEV2 ... src IP1 table local: the app > does not need to be aware to use this feature > > Now using BINDTODEVICE can cause problems with this feature, > because we do not ignore oif for local destinations, you risk to > miss the local route and arp_filter to break the things or worse (not > tested) > > >>1b) Allow both same-subnet comm (eth1 & eth2 are on same subnet), and also >> routed traffic (eth1 & eth2 have their own default router, similar to the >> previously discussed routing setup) > > > all other routes remain unchanged, I hope > > >>2) Allow normal non-looped communication on the ports, including policy-based routing >> based on source addr. > > > hm, you better know what you mean. As expected, this feature > has its drawbacks. The safe way is to teach some apps to bind to > IP1 and the apps that are unaware for these loops to use the prefsrc > and thus to use lo. There is no much space for improvement here but > I'm open for suggestions. > > >>Thanks, >>Ben > > > Regards > > -- > Julian Anastasov > -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From linux-netdev@gmane.org Tue Jul 1 15:17:19 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jul 2003 15:17:26 -0700 (PDT) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61MHH2x016286 for ; Tue, 1 Jul 2003 15:17:18 -0700 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19XT27-0006BX-00 for ; Tue, 01 Jul 2003 23:51:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: netdev@oss.sgi.com Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19XT24-0006B5-00 for ; Tue, 01 Jul 2003 23:51:24 +0200 From: Jason Lunz Subject: [PATCH 2.4.22-bk] dev->promiscuity refcounting broken in af_packet.c Date: Tue, 1 Jul 2003 21:51:23 +0000 (UTC) Organization: PBR Streetgang Lines: 99 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@main.gmane.org User-Agent: slrn/0.9.7.4 (Linux) X-archive-position: 3713 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lunz@falooley.org Precedence: bulk X-list: netdev niz@vencraft.com said: > A number of people have mentioned that they get a weird situation > where when they *start* a program that does promiscuous network reads > (with, say, ‘tcpdump –i eth0’). They then get a kernel message > “left promiscuous mode” when the program starts and the message > “entered promiscuous mode” when it exits – the exact opposite of > what should happen. Thanks for finding this! This has been happening to me for over a year, but always so rarely that I never bothered to really track it down. Your patch isn't really correct, though. Aside from the whitespace damage, it doesn't really address the problem. Clamping the refcount at zero only stops the bleeding. The problem is that packet sockets are calling dev_set_promiscuity too many times. For example, if I take an unconfigured interface and do: halfoat:~ # ip link show eth1 9: eth1: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:30:48:41:62:12 brd ff:ff:ff:ff:ff:ff halfoat:~ # ip link set up eth1 halfoat:~ # tcpdump -i eth1 & [1] 457 tcpdump: WARNING: eth1: no IPv4 address assigned tcpdump: listening on eth1 halfoat:~ # ip link set down eth1 tcpdump: pcap_loop: recvfrom: Network is down [1]+ Exit 1 tcpdump -i eth1 halfoat:~ # ip link show eth1 9: eth1: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:30:48:41:62:12 brd ff:ff:ff:ff:ff:ff eth1 is now in promiscuous mode because dev->promiscuity is -1 (!= 0). When the interface goes down, dev_change_flags calls dev_close, which sends NETDEV_DOWN down the netdev notifier chain. Because tcpdump has a packet socket open, packet_notifier calls packet_dev_mclist -> packet_dev_mc -> dev_set_promiscuity. When tcpdump gets ENETDOWN, it aborts, closing the packet socket. af_packet.c's proto_ops->release cleanup method is packet_release. On close(), packet_release calls packet_flush_mclist, which again decrements dev->promiscuity, so when tcpdump exits, dev promiscuity is left at -1. I can't see any reason to be mucking about with the device promiscuity on NETDEV_DOWN and NETDEV_UP events in the first place. The attached patch seems to fix all the cases I can think of. It works properly in both of the above cases, and has also been verified to do the right thing with NETDEV_UNREGISTER events. Jason Index: linux-2.4/net/packet/af_packet.c =================================================================== RCS file: /home/cvs/linux-2.4/net/packet/af_packet.c,v retrieving revision 1.11 diff -u -p -r1.11 af_packet.c --- linux-2.4/net/packet/af_packet.c 12 Jun 2002 23:10:34 -0000 1.11 +++ linux-2.4/net/packet/af_packet.c 1 Jul 2003 20:17:51 -0000 @@ -1378,8 +1378,13 @@ static int packet_notifier(struct notifi po = sk->protinfo.af_packet; switch (msg) { - case NETDEV_DOWN: case NETDEV_UNREGISTER: +#ifdef CONFIG_PACKET_MULTICAST + if (po->mclist) + packet_dev_mclist(dev, po->mclist, -1); + // fallthrough +#endif + case NETDEV_DOWN: if (dev->ifindex == po->ifindex) { spin_lock(&po->bind_lock); if (po->running) { @@ -1396,10 +1401,6 @@ static int packet_notifier(struct notifi } spin_unlock(&po->bind_lock); } -#ifdef CONFIG_PACKET_MULTICAST - if (po->mclist) - packet_dev_mclist(dev, po->mclist, -1); -#endif break; case NETDEV_UP: spin_lock(&po->bind_lock); @@ -1409,10 +1410,6 @@ static int packet_notifier(struct notifi po->running = 1; } spin_unlock(&po->bind_lock); -#ifdef CONFIG_PACKET_MULTICAST - if (po->mclist) - packet_dev_mclist(dev, po->mclist, +1); -#endif break; } } From ja@ssi.bg Tue Jul 1 15:19:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jul 2003 15:19:43 -0700 (PDT) Received: from u.domain.uli (ja.mac.ssi.bg [217.79.71.194]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61MJa2x016593 for ; Tue, 1 Jul 2003 15:19:38 -0700 Received: from localhost (IDENT:ja@localhost [127.0.0.1]) by u.domain.uli (8.11.6/8.11.6) with ESMTP id h61MNQG02379; Wed, 2 Jul 2003 01:23:26 +0300 Date: Wed, 2 Jul 2003 01:23:25 +0300 (EEST) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: Ben Greear cc: netdev@oss.sgi.com Subject: Re: send-to-self (was Re: routing bug report for 2.4) In-Reply-To: <3F020610.2080109@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3714 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ja@ssi.bg Precedence: bulk X-list: netdev Hello, On Tue, 1 Jul 2003, Ben Greear wrote: > How did you get telnet to bind to a particular local interface? Also, what I tested telnet with replacing the prefsrc, as result, 'ip route get telnet_server_ip_on_eth1' returns local_ip_from_eth0 as src. telnetd listens as usually to 0.0.0.0, incoming connection comes (IP1->IP2), so the server always gets two different IPs... > ping syntax did you use? Did you have to modify either of these applications > to get them to work? Nooo :) 'ping -I IP1 IP2' or if you set IP2's prefsrc to IP1 then even 'ping IP2' works > I looked at the patch...but don't have a good enough grasp of the routing > code to provide a useful critique. I believe my patch _is_ smaller though ;) At least, we have two alternatives :) I'm still not sure whether the "loop" feature will need some tuning in other netsource places. > Thanks, > Ben Regards -- Julian Anastasov From yoshfuji@linux-ipv6.org Tue Jul 1 17:17:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jul 2003 17:17:47 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h620HK2x019307 for ; Tue, 1 Jul 2003 17:17:34 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h620IRBo030900; Wed, 2 Jul 2003 09:18:27 +0900 Date: Wed, 02 Jul 2003 09:18:25 +0900 (JST) Message-Id: <20030702.091825.72842784.yoshfuji@linux-ipv6.org> To: krkumar@us.ibm.com Cc: davem@redhat.com, netdev@oss.sgi.com, linux-net@vger.kernel.org, yoshfuji@linux-ipv6.org, kuznet@ms2.inr.ac.ru Subject: Re: [PATCH] Prefix List against 2.5.70 (re-done) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <3F008771.5030206@us.ibm.com> References: <20030627.144752.78715628.davem@redhat.com> <20030628.130602.63704890.yoshfuji@linux-ipv6.org> <3F008771.5030206@us.ibm.com> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3715 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <3F008771.5030206@us.ibm.com> (at Mon, 30 Jun 2003 11:54:41 -0700), Krishna Kumar says: > Well, there are two reason that I can see to not do so (ADDRCONF flag is already > fixed in earlier patch) : : You do not explain why we (or kernel) NEED(s) this. It is not so important how SMALL it is though it may cause problems how LARGE it is. > About your point about the managed flag, I think it is a per interface flag > that gets returned when a request for getting flags on that interface is made. > That's why I have made it per interface as part of a GETLNKFLAGS operation. > I don't understand why you think it is NEWLINK thing (not sure what you mean by > that), since it is a flag information on your existing device that a RA is > advertising. I want to get this information not on receipt of an RA, but when > a request is made. This is design issue; how we should provide L3 per-interface information to userspace; eg. in_device and/or inet6_dev things including per-interface statistics. Since I think it is not appropriate to provide per-interface statistics via RTM_xxxROUTE, so I don't agree to provide the RA infomation (i.e. Manage/Otherconf Flags) via RTM_xxxROUTE. Options: - use RTM_xxxLINK for L3 operation - introduce RTM_xxxIFACE for L3 per-interface operations I really want to hear from other maintainers here... David? Alexey? Well, on moving forward; you can split your patch up to 3 things: 1. fix routing flags 2. provide Managed/Otherconf flags API (3. provide the prefix list API (if it IS required)) I'm not against the first item. We need to discuss on the design related to the 2nd item. I don't think that we really need 3rd item. Thank you. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From kuznet@ms2.inr.ac.ru Tue Jul 1 22:17:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jul 2003 22:17:45 -0700 (PDT) Received: from dub.inr.ac.ru (dub.inr.ac.ru [193.233.7.105]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h625HX2x023753 for ; Tue, 1 Jul 2003 22:17:34 -0700 Received: (from kuznet@localhost) by dub.inr.ac.ru (8.6.13/ANK) id JAA05258; Wed, 2 Jul 2003 09:17:22 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200307020517.JAA05258@dub.inr.ac.ru> Subject: Re: Fw: [PATCH 2.4.22-bk] dev->promiscuity refcounting broken in To: davem@redhat.com (David S. Miller) Date: Wed, 2 Jul 2003 09:17:22 +0400 (MSD) Cc: jmorris@redhat.com, netdev@oss.sgi.com, lunz@falooley.org In-Reply-To: <20030701.155051.104064679.davem@redhat.com> from "David S. Miller" at Jul 01, 2003 03:50:51 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3716 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Hello! > I can't see any reason to be mucking about with the device promiscuity > on NETDEV_DOWN and NETDEV_UP events in the first place. I do not remember why protocols (i.e. IP) withdraw multicast lists on device down too. :-) > The attached > patch seems to fix all the cases I can think of. I think it is right. Actually, if to follow the tradition, we could do the same thing as IP does (remembering that mc record is not loaded), but it looks really useless. Dave, the patch looks OK. Alexey PS. Wow! X-MIME-Autoconverted: from 8bit to quoted-printable by oss.sgi.com id h61MHp2x016322 X-MIME-Autoconverted: from quoted-printable to 8bit by devserv.devel.redhat.com id h61MI0K27113 Mime-Version: 1.0 (modified by Mew) Content-Transfer-Encoding: quoted-printable (modified by Mew) All three agents (oss, redhat and your mailer) are damn smart. Rare mail will pass through this uncorrupted, I guess. :-) From pekkas@netcore.fi Tue Jul 1 22:30:19 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jul 2003 22:30:56 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h625UH2x024116 for ; Tue, 1 Jul 2003 22:30:18 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h625U7X23499; Wed, 2 Jul 2003 08:30:07 +0300 Date: Wed, 2 Jul 2003 08:30:07 +0300 (EEST) From: Pekka Savola To: Michael Bellion and Thomas Heinz cc: linux-kernel@vger.kernel.org, Subject: Re: [ANNOUNCE] nf-hipac v0.8 released In-Reply-To: <3EFF1349.6020802@hipac.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3717 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev Hi, Thanks for your clarification. We've also conducted some tests with bridging firewall functionality, and we're very pleased with nf-hipac's performance! Results below. In the measurements, tests were run through a bridging Linux firewall, with a netperf UDP stream of 1450 byte packets (launched from a different computer connected with gigabit ethernet), with a varying amount of filtering rules checks for each packet. I don't have the specs of the Linux PC hardware handy, but I recall they're *very* highend dual-P4's, like 2.4Ghz, very fast PCI bus, etc. Shouldn't be a factor here. 1. Filtering based on source address only, for example: $fwcmd -A $MAIN -p udp -s 10.0.0.1 -j DROP ... $fwcmd -A $MAIN -p udp -s 10.0.3.255 -j DROP $fwcmd -A $MAIN -p udp -j ACCEPT Results: rules | plain NF | NF-HIPAC | sent | got thru | sent | got thru | (n.o) | (Mbit/s) | (Mbit/s) | (Mbit/s) | (Mbit/s) | ------------------------------------------------------------- 0 | 956,00 | 953,24 | 956,00 | 953,24 | 512 | 956,00 | 800,68 | 956,46 | 952,81 | 1024 | 956,00 | 472,78 | 956,46 | 952,81 | 2048 | 955,99 | 170,52 | 956,46 | 952,86 | 3072 | 956,00 | 51,97 | 956,46 | 952,85 | 2. Filtering based on UDP protocol's source port, for example: $fwcmd -A $MAIN -p udp --source-port 1 -j DROP ... $fwcmd -A $MAIN -p udp --source-port 1024 -j DROP $fwcmd -A $MAIN -p udp -j ACCEPT Results: rules | plain NF | NF-HIPAC | sent | got thru | sent | got thru | (n.o) | (Mbit/s) | (Mbit/s) | (Mbit/s) | (Mbit/s) | ------------------------------------------------------------- 0 | 955,37 | 954,33 | 956,46 | 952,85 | 512 | 980,68 | 261,41 | 956,46 | 951,92 | 1024 | N/A | N/A | 956,47 | 952,86 | 2048 | N/A | N/A | 956,46 | 952,85 | 3072 | N/A | N/A | 956,46 | 952,85 | N/A = Netfilter bridging can't handle this at all, no traffic can pass the bridge. So, plain Netfilter can tolerate about a couple of hundred rules checking for addresses and/or ports on a gigabit line. With HIPAC Netfilter, packet loss is very low, less than 0.5%, even with the maximum number (of tested) rules, the same amount as without filtering at all. On Sun, 29 Jun 2003, Michael Bellion and Thomas Heinz wrote: > You wrote: > >>We are going to test the stuff tomorrow on an i386 and tell you > >>the results afterwards. > > Well, nf-hipac works fine together with the ebtables patch for 2.4.21 > on an i386 machine. We expect it to work with other patches too. > > >>In principle, nf-hipac should work properly whith the bridge patch. > >>We expect it to work just like iptables apart from the fact that > >>you cannot match on bridge ports. > > Well, this statement holds for the native nf-hipac in/out interface > match but of course you can match on bridge ports with nf-hipac > using the iptables physdev match. So everything should be fine :) > > > One obvious thing that's missing in your performance and Roberto's figures > > is what *exactly* are the non-matching rules. Ie. do they only match IP > > address, a TCP port, or what? (TCP port matching is about a degree of > > complexity more expensive with iptables, I recall.) > > [answered in private e-mail] > > > Regards, > > +-----------------------+----------------------+ > | Michael Bellion | Thomas Heinz | > | | | > +-----------------------+----------------------+ > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From nf@hipac.org Wed Jul 2 05:27:13 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 05:27:19 -0700 (PDT) Received: from indyio.rz.uni-saarland.de (indyio.rz.uni-saarland.de [134.96.7.3]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h62CRB2x032309 for ; Wed, 2 Jul 2003 05:27:13 -0700 Received: from mars.rz.uni-saarland.de (mars.rz.uni-saarland.de [134.96.7.4]) by indyio.rz.uni-saarland.de (8.12.9/8.12.5) with ESMTP id h62CQwfZ012757; Wed, 2 Jul 2003 14:26:59 +0200 (CEST) Received: from e002.stw.stud.uni-saarland.de (e002.stw.stud.uni-saarland.de [134.96.65.17]) by mars.rz.uni-saarland.de (8.9.3p2/8.8.4/8.8.2) with ESMTP id OAA27042; Wed, 2 Jul 2003 14:26:57 +0200 (CEST) Received: from e002.stw.stud.uni-saarland.de ([134.96.65.138] helo=e123.stw.stud.uni-saarland.de) by e002.stw.stud.uni-saarland.de with esmtp (Exim 3.35 #1 (Debian)) id 19XghM-0007HJ-00; Wed, 02 Jul 2003 14:26:56 +0200 From: Michael Bellion and Thomas Heinz Reply-To: nf@hipac.org To: Pekka Savola Subject: Re: [ANNOUNCE] nf-hipac v0.8 released Date: Wed, 2 Jul 2003 14:26:56 +0200 User-Agent: KMail/1.5.2 References: In-Reply-To: Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200307021426.56138.nf@hipac.org> X-archive-position: 3718 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nf@hipac.org Precedence: bulk X-list: netdev Hi Pekka > Thanks for your clarification. We've also conducted some tests with > bridging firewall functionality, and we're very pleased with nf-hipac's > performance! Results below. Great, thanks a lot. Your tests are very interesting for us as we haven't done any gigabit or SMP tests yet. > In the measurements, tests were run through a bridging Linux firewall, > with a netperf UDP stream of 1450 byte packets (launched from a different > computer connected with gigabit ethernet), with a varying amount of > filtering rules checks for each packet. > I don't have the specs of the Linux PC hardware handy, but I recall > they're *very* highend dual-P4's, like 2.4Ghz, very fast PCI bus, etc. Since real world network traffic always consists of a lot of different sized packets taking maximum sized packets is very euphemistic. 1450 byte packets at 950 Mbit/s correspond to approx. 80,000 packets/sec. We are really interested in how our algorithm performs at higher packet rates. Our performance tests are based on 100 Mbit hardware so we coudn't test with more than approx. 80,000 packets/sec even with minimum sized packets. At this packet rate we were hardly able to drive the algorithm to its limit, even with more than 25000 rules involved (and our test system was 1.3 GHz uniprocessor). We'd appreciate it very much if you could run additional tests with smaller packet sizes (including minimum packet size). This way we can get an idea of whether our SMP optimizations work and whether our algorithm in general would benefit from further fine tuning. Regards +-----------------------+----------------------+ | Michael Bellion | Thomas Heinz | | | | +-----------------------+----------------------+ From P@draigBrady.com Wed Jul 2 06:14:48 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 06:14:59 -0700 (PDT) Received: from corvil.com (gate.corvil.net [213.94.219.177]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h62DEj2x000525 for ; Wed, 2 Jul 2003 06:14:47 -0700 Received: from draigBrady.com (pixelbeat.local.corvil.com [172.18.1.170]) by corvil.com (8.12.9/8.12.5) with ESMTP id h62DEWlT084256; Wed, 2 Jul 2003 14:14:33 +0100 (IST) (envelope-from P@draigBrady.com) Message-ID: <3F02D964.7050301@draigBrady.com> Date: Wed, 02 Jul 2003 14:08:52 +0100 From: P@draigBrady.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030617 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nf@hipac.org CC: Pekka Savola , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [ANNOUNCE] nf-hipac v0.8 released References: <200307021426.56138.nf@hipac.org> In-Reply-To: <200307021426.56138.nf@hipac.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by corvil.com id h62DEWlT084256 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h62DEj2x000525 X-archive-position: 3719 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: P@draigBrady.com Precedence: bulk X-list: netdev Michael Bellion and Thomas Heinz wrote: > Hi Pekka > > >>Thanks for your clarification. We've also conducted some tests with >>bridging firewall functionality, and we're very pleased with nf-hipac's >>performance! Results below. > > > Great, thanks a lot. Your tests are very interesting for us as we haven't done > any gigabit or SMP tests yet. > >>In the measurements, tests were run through a bridging Linux firewall, >>with a netperf UDP stream of 1450 byte packets (launched from a different >>computer connected with gigabit ethernet), with a varying amount of >>filtering rules checks for each packet. >>I don't have the specs of the Linux PC hardware handy, but I recall >>they're *very* highend dual-P4's, like 2.4Ghz, very fast PCI bus, etc. > > Since real world network traffic always consists of a lot of different sized > packets taking maximum sized packets is very euphemistic. 1450 byte packets > at 950 Mbit/s correspond to approx. 80,000 packets/sec. > We are really interested in how our algorithm performs at higher packet rates. > Our performance tests are based on 100 Mbit hardware so we coudn't test with > more than approx. 80,000 packets/sec even with minimum sized packets. Interrupt latency is the problem here. You'll require napi et. al to get over this hump. > At this > packet rate we were hardly able to drive the algorithm to its limit, even > with more than 25000 rules involved (and our test system was 1.3 GHz > uniprocessor). Cool. The same sort of test with ordinary netfilter that I did showed it could only handle around 125 rules at this packet rate on a 1.4GHz PIII, e1000 @ 100Mb/s. # ./readprofile -m /boot/System.map | sort -nr | head -30 6779 total 0.0047 4441 default_idle 69.3906 787 handle_IRQ_event 7.0268 589 ip_packet_match 1.6733 433 ipt_do_table 0.6294 106 eth_type_trans 0.5521 56 kfree 0.8750 46 skb_release_data 0.3194 37 add_timer_randomness 0.1542 35 alloc_skb 0.0781 30 __kmem_cache_alloc 0.1172 27 kmalloc 0.3375 23 ip_rcv 0.0342 22 do_gettimeofday 0.1964 20 netif_rx 0.0521 19 __kfree_skb 0.0540 18 add_entropy_words 0.1023 15 __constant_c_and_count_memset 0.0938 13 batch_entropy_store 0.0813 12 kfree_skbmem 0.1071 11 netif_receive_skb 0.0208 7 nf_iterate 0.0437 7 nf_hook_slow 0.0175 6 process_backlog 0.0221 5 batch_entropy_process 0.0223 5 add_interrupt_randomness 0.0781 3 kmem_cache_free 0.0625 2 ipt_hook 0.0312 1 write_profile 0.0156 1 ip_promisc_rcv_finish 0.0208 Pádraig. From nf@hipac.org Wed Jul 2 06:48:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 06:48:39 -0700 (PDT) Received: from indyio.rz.uni-saarland.de (indyio.rz.uni-saarland.de [134.96.7.3]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h62DmT2x001337 for ; Wed, 2 Jul 2003 06:48:30 -0700 Received: from mars.rz.uni-saarland.de (mars.rz.uni-saarland.de [134.96.7.4]) by indyio.rz.uni-saarland.de (8.12.9/8.12.5) with ESMTP id h62DmLfZ032855; Wed, 2 Jul 2003 15:48:21 +0200 (CEST) Received: from e002.stw.stud.uni-saarland.de (e002.stw.stud.uni-saarland.de [134.96.65.17]) by mars.rz.uni-saarland.de (8.9.3p2/8.8.4/8.8.2) with ESMTP id PAA113215; Wed, 2 Jul 2003 15:48:20 +0200 (CEST) Received: from e002.stw.stud.uni-saarland.de ([134.96.65.138] helo=e123.stw.stud.uni-saarland.de) by e002.stw.stud.uni-saarland.de with esmtp (Exim 3.35 #1 (Debian)) id 19Xhy8-0007Pk-00; Wed, 02 Jul 2003 15:48:20 +0200 From: Michael Bellion and Thomas Heinz Reply-To: nf@hipac.org To: P@draigbrady.com Subject: Re: [ANNOUNCE] nf-hipac v0.8 released Date: Wed, 2 Jul 2003 15:48:19 +0200 User-Agent: KMail/1.5.2 References: <200307021426.56138.nf@hipac.org> <3F02D964.7050301@draigBrady.com> In-Reply-To: <3F02D964.7050301@draigBrady.com> Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200307021548.19989.nf@hipac.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h62DmT2x001337 X-archive-position: 3720 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nf@hipac.org Precedence: bulk X-list: netdev Hi Pádraig > > Since real world network traffic always consists of a lot of different > > sized packets taking maximum sized packets is very euphemistic. 1450 byte > > packets at 950 Mbit/s correspond to approx. 80,000 packets/sec. > > We are really interested in how our algorithm performs at higher packet > > rates. Our performance tests are based on 100 Mbit hardware so we coudn't > > test with more than approx. 80,000 packets/sec even with minimum sized > > packets. > > Interrupt latency is the problem here. You'll require napi et. al > to get over this hump. Yes we know, but with 128 byte frame size you can archieve a packet rate of at most 97,656 packets/sec (in theory) on 100 Mbit hardware. We don't think this few more packets would have changed the results fundamentally, so it's probably not worth it on 100 Mbit. Certainly you are right, that napi is required on gigabit to saturate the link with small sized packets. > Cool. The same sort of test with ordinary netfilter that > I did showed it could only handle around 125 rules at this > packet rate on a 1.4GHz PIII, e1000 @ 100Mb/s. > > # ./readprofile -m /boot/System.map | sort -nr | head -30 > 6779 total 0.0047 > 4441 default_idle 69.3906 > 787 handle_IRQ_event 7.0268 > 589 ip_packet_match 1.6733 > 433 ipt_do_table 0.6294 > 106 eth_type_trans 0.5521 > [...] What do you want to show with this profile? Most of the time is spend in the idle loop and in icq handling and only a few percentage in ip_packet_match and ipt_do_table, so we don't quite get how this matches your statement above. Could you explain this in a few words? Regards, +-----------------------+----------------------+ | Michael Bellion | Thomas Heinz | | | | +-----------------------+----------------------+ From or@logreport.org Wed Jul 2 07:00:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 07:00:28 -0700 (PDT) Received: from hibou.logreport.org (postfix@logreport.IAE.nl [212.61.24.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h62E0N2x001805 for ; Wed, 2 Jul 2003 07:00:24 -0700 Received: by hibou.logreport.org (Postfix, from userid 1005) id CBEC3C052; Wed, 2 Jul 2003 16:00:21 +0200 (CEST) Content-Type: text/plain; name="lr_log2mail.common.lr_tag-20030702160003-4776.4NuBoD.errors" Content-Disposition: inline; filename="lr_log2mail.common.lr_tag-20030702160003-4776.4NuBoD.errors" MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) To: netdev@oss.sgi.com From: log@logreport.org Subject: [LogReport] Error in common report (was: [LogReport] common report (was: Re: Movie)) Reply-To: support@logreport.org Message-Id: <20030702140021.CBEC3C052@hibou.logreport.org> Date: Wed, 2 Jul 2003 16:00:21 +0200 (CEST) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h62E0N2x001805 X-archive-position: 3721 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: log@logreport.org Precedence: bulk X-list: netdev WARNING: Logfile may be bogus. There were 319 errors on the 319 lines in the log. This may be because you sent a log file that doesn't strictly contain common logs. This is probable if you sent a syslog log file without filtering it to keep only the logs relevant to the common service. It could also be because you sent a log file in the wrong format or a file that isn't a common log file. A report was generated for the 0 records that could be extracted from your log file. From P@draigBrady.com Wed Jul 2 07:29:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 07:29:28 -0700 (PDT) Received: from corvil.com (gate.corvil.net [213.94.219.177]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h62ETG2x002532 for ; Wed, 2 Jul 2003 07:29:18 -0700 Received: from draigBrady.com (pixelbeat.local.corvil.com [172.18.1.170]) by corvil.com (8.12.9/8.12.5) with ESMTP id h62ETAlT092982; Wed, 2 Jul 2003 15:29:14 +0100 (IST) (envelope-from P@draigBrady.com) Message-ID: <3F02EAE2.8050609@draigBrady.com> Date: Wed, 02 Jul 2003 15:23:30 +0100 From: P@draigBrady.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030617 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nf@hipac.org CC: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [ANNOUNCE] nf-hipac v0.8 released References: <200307021426.56138.nf@hipac.org> <3F02D964.7050301@draigBrady.com> <200307021548.19989.nf@hipac.org> In-Reply-To: <200307021548.19989.nf@hipac.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by corvil.com id h62ETAlT092982 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h62ETG2x002532 X-archive-position: 3722 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: P@draigBrady.com Precedence: bulk X-list: netdev Michael Bellion and Thomas Heinz wrote: > Hi Pádraig > > >>>Since real world network traffic always consists of a lot of different >>>sized packets taking maximum sized packets is very euphemistic. 1450 byte >>>packets at 950 Mbit/s correspond to approx. 80,000 packets/sec. >>>We are really interested in how our algorithm performs at higher packet >>>rates. Our performance tests are based on 100 Mbit hardware so we coudn't >>>test with more than approx. 80,000 packets/sec even with minimum sized >>>packets. >> >>Interrupt latency is the problem here. You'll require napi et. al >>to get over this hump. > > Yes we know, but with 128 byte frame size you can archieve a packet rate of at > most 97,656 packets/sec (in theory) on 100 Mbit hardware. We don't think this > few more packets would have changed the results fundamentally, so it's > probably not worth it on 100 Mbit. I was testing with 64 byte packets (so around 190Kpps). e100 cards at least have a handy mode for continually sending a packet as fast as possible. Also you can use more than one interface. So 100Mb is very useful for testing. For the test below I was using a rate of around 85Kpps. > Certainly you are right, that napi is required on gigabit to saturate the link > with small sized packets. > >>Cool. The same sort of test with ordinary netfilter that >>I did showed it could only handle around 125 rules at this >>packet rate on a 1.4GHz PIII, e1000 @ 100Mb/s. >> >># ./readprofile -m /boot/System.map | sort -nr | head -30 >> 6779 total 0.0047 >> 4441 default_idle 69.3906 >> 787 handle_IRQ_event 7.0268 >> 589 ip_packet_match 1.6733 >> 433 ipt_do_table 0.6294 >> 106 eth_type_trans 0.5521 >> [...] > > What do you want to show with this profile? Most of the time is spend in the > idle loop and in irq handling and only a few percentage in ip_packet_match > and ipt_do_table, so we don't quite get how this matches your statement > above. Could you explain this in a few words? Confused me too. The system would lock up and start dropping packets after 125 rules. I.E. it would linearly degrade as more rules were added. I'm guessing there is a fixed interrupt overhead that is accounted for by default_idle? Note the e1000 drivers were left in the default config so there could definitely be some tuning done here. Note I changed netfilter slightly to accept promiscuous traffic which is done in ip_rcv() and then the packets are just dropped after the (match any in the test case) rules are traversed. Pádraig. From or@logreport.org Wed Jul 2 07:33:23 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 07:33:30 -0700 (PDT) Received: from hibou.logreport.org (postfix@logreport.IAE.nl [212.61.24.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h62EXB2x002870 for ; Wed, 2 Jul 2003 07:33:12 -0700 Received: by hibou.logreport.org (Postfix, from userid 1005) id 106D5C039; Wed, 2 Jul 2003 16:00:21 +0200 (CEST) Content-Type: text/plain; name="report.txt" Content-Disposition: inline; filename="report.txt" MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) To: netdev@oss.sgi.com From: log@logreport.org Subject: [LogReport] common report (was: Re: Movie) Reply-To: support@logreport.org Message-Id: <20030702140021.106D5C039@hibou.logreport.org> Date: Wed, 2 Jul 2003 16:00:21 +0200 (CEST) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h62EXB2x002870 X-archive-position: 3723 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: log@logreport.org Precedence: bulk X-list: netdev Report generated: 2003-07-02 16:00:16 CEST Reporting on period: Unknown Period Activity Reports ---------------- Number of Requests Served by 1d Period No content in report. Total Size of Requests Served By 1d Period No content in report. User Sessions By 1d Period No content in report. Number of Requests Served by 1h Timeslot Timeslot Requests % Total ------------------------------------------------------- -------- ------- 00:00 0 NaN 01:00 0 NaN 02:00 0 NaN 03:00 0 NaN 04:00 0 NaN 05:00 0 NaN 06:00 0 NaN 07:00 0 NaN 08:00 0 NaN 09:00 0 NaN 10:00 0 NaN 11:00 0 NaN 12:00 0 NaN 13:00 0 NaN 14:00 0 NaN 15:00 0 NaN 16:00 0 NaN 17:00 0 NaN 18:00 0 NaN 19:00 0 NaN 20:00 0 NaN 21:00 0 NaN 22:00 0 NaN 23:00 0 NaN Number of Requests by Request's Size No content in report. Total size of requests served by directory, Top 10 No content in report. Visitors Reports ---------------- Number of Requests by Client Hosts, Top 10 No content in report. Total size of requests by Client Hosts, Top 10 No content in report. Requests By Top Level Domain The "top level domain" is determined from the hostname of the client. There is no real correlation to where the user is geographically located. For example, a client connecting from the hostname ppp10.nl-div.globalcorp.co.uk will get listed as a United Kindom top level domain, even when that user is connecting from a division in The Netherlands. No content in report. Accessed Pages Reports ---------------------- Applied filter in this section: excluded requests matching "\.(png|gif|jpg|jpeg|css)$" Number of Requests Served by 1d Period No content in report. Most Requested Pages, Top 10 No content in report. Most Requested URLs, Top 10, Top 5 URLs No content in report. Session Reports --------------- First Page In User Session, Top 10 - means that only images were requested. No content in report. Last Page In User Session, Top 10 - means that only images were requested. No content in report. User Sessions by Their Recurrence No content in report. Visit Duration Duration is given in seconds. No content in report. Number of Pages per Visit No content in report. Top Traversals, Top 10 Start Page, Top 5 2nd Pages, Top 5 3rd Page No content in report. Download Reports ---------------- Applied filter in this section: selected requests matching \.(gz|tgz|zip|exe|pdf|doc)$ Number of Requests Served by 1d Period No content in report. Most Requested Pages, Top 10 No content in report. Most Requested URLs, Top 10, Top 5 URLs No content in report. Browsers and Platforms Reports ------------------------------ Top 10 Requests By Browser The "browser" is determined from the User-Agent header. It is possible for a user to change that string. This means that the value Internet Explorer could be sent by a user running a customized version of Mozilla. No content in report. Top 10 Requests By Operating System The "operating system" is determined from the User-Agent header. It is possible for a user to change that string. This means that the value Mac PowerPC could be attributed to a user who is really running a customized version of Mozilla under GNU/Linux. No content in report. Top 10 Requests By Browser Language The "language" is determined from the User-Agent header. Users can set this variable to indicate their preferred language. No content in report. Top 10 Requests By Robot No content in report. Search Engines and "Referers" ----------------------------- Applied filter in this section: excluded requests with a referer matching "^-$" Top 10 Referring Sites No content in report. Top 10 Referring Pages No content in report. Top Referring Pages By Requested Page, Top 5 Referrers, Top 10 Pages No content in report. Most Travelled Referer -> Pages Connection, Top 10 No content in report. Requests By Search Engine No content in report. Requests By Keywords, Top 10 No content in report. Requests by Search Engine with Keywords, Top 10 Search Engines, Top 5 Keywords No content in report. Abuse Reports ------------- Requests By Attack No content in report. Compression Reports ------------------- Requests By Gzip Result No content in report. Most Average Compressed Requested URL, Top 10 Compression is in percent. No content in report. File Types With Highest Average Compression Level, Top 10 Compression is in percent. No content in report. Technical Reports ----------------- Requests By HTTP Method No content in report. Requests By HTTP Protocol Version No content in report. Requests By HTTP Result The most common HTTP status codes are given below: 200 OK (The request has succeeded.) 201 Created (The request has been fulfilled and resulted in a new resource being created.) 206 Partial Content (The server has fulfilled the partial GET request for the resource.) 301 Moved Permanently (The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs.) 302 Found (The requested resource resides temporarily under a different URI.) 304 Not Modified (The client has performed a conditional GET request and access is allowed, but the document has not been modified.) 403 Forbidden (The server understood the request, but is refusing to fulfill it.) 404 Not Found (The server has not found anything matching the Request-URI.) No content in report. Requests by Client Hosts By HTTP Result, Top 5 Clients No content in report. Requests by URL By HTTP Result, Top 5 URLs No content in report. -- LogReport sent to you by http://www.LogReport.org/ or@hibou.logreport.org mailto:logreport@logreport.org running lire-1.3.tar.gz The Online Report Responder Service is free of charge. We do not accept any liability however incurred in respect of a failure to perform as is imputable to the same for any loss direct or indirect. If you use the responder on a regular basis, please subscribe to our announcement mailing list (http://logreport.org/contact/lists/) to keep informed on updates and modification to the service. To support the online responder, make a donation to the LogReport Foundation (http://logreport.org/about/donate.php). From Larry.Sendlosky@storigen.com Wed Jul 2 07:59:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 07:59:49 -0700 (PDT) Received: from xchangeserver2.storigen.com ([65.193.106.66]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h62Exi2x003368 for ; Wed, 2 Jul 2003 07:59:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: e1000 in 2.4.21 and carrier errors Date: Wed, 2 Jul 2003 10:59:31 -0400 Message-ID: <7BFCE5F1EF28D64198522688F5449D5A01FF2AF7@xchangeserver2.storigen.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: e1000 in 2.4.21 and carrier errors Thread-Index: AcNAqop9ROmFxCNxTqOmxIx5r8BIYg== From: "Larry Sendlosky" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h62Exi2x003368 X-archive-position: 3724 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Larry.Sendlosky@storigen.com Precedence: bulk X-list: netdev We started running 2.4.21 and use the e1000 driver in the kernel. Our NICs are PRO-1000 82543GC based copper. Using the new driver we see constant increase in carrier errors. Loading the Intel e1000 v3.6.8.1 driver we have no carrier errors. This happens on all our systems with the PR0-1000 card using 2.4.21 and RH9. Switches are a mixture of Dell, Asante, Cisco, and Extreme. Any ideas? thanks larry From jmorris@intercode.com.au Wed Jul 2 09:01:11 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 09:01:15 -0700 (PDT) Received: from blackbird.intercode.com.au (IDENT:FHRUnQvXcBJGTwFDC/PQq8eV2MOvvdEj@blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h62G172x004202 for ; Wed, 2 Jul 2003 09:01:09 -0700 Received: from excalibur.intercode.com.au (excalibur.intercode.com.au [203.32.101.12]) by blackbird.intercode.com.au (8.11.6p2/8.9.3) with ESMTP id h62G09r13320; Thu, 3 Jul 2003 02:00:10 +1000 Date: Thu, 3 Jul 2003 02:00:09 +1000 (EST) From: James Morris To: kuznet@ms2.inr.ac.ru cc: "David S. Miller" , , , Subject: Re: Fw: [PATCH 2.4.22-bk] dev->promiscuity refcounting broken in In-Reply-To: <200307020517.JAA05258@dub.inr.ac.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3725 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@intercode.com.au Precedence: bulk X-list: netdev On Wed, 2 Jul 2003 kuznet@ms2.inr.ac.ru wrote: > Dave, the patch looks OK. Applied to bk://kernel.bkbits.net/jmorris/net-2.5 and bk://kernel.bkbits.net/jmorris/net-2.4 - James -- James Morris From nf@hipac.org Wed Jul 2 09:58:11 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 09:58:22 -0700 (PDT) Received: from indyio.rz.uni-saarland.de (indyio.rz.uni-saarland.de [134.96.7.3]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h62Gw92x005473 for ; Wed, 2 Jul 2003 09:58:10 -0700 Received: from mars.rz.uni-saarland.de (mars.rz.uni-saarland.de [134.96.7.4]) by indyio.rz.uni-saarland.de (8.12.9/8.12.5) with ESMTP id h62Gw3fZ067817; Wed, 2 Jul 2003 18:58:03 +0200 (CEST) Received: from e002.stw.stud.uni-saarland.de (e002.stw.stud.uni-saarland.de [134.96.65.17]) by mars.rz.uni-saarland.de (8.9.3p2/8.8.4/8.8.2) with ESMTP id SAA279378; Wed, 2 Jul 2003 18:58:02 +0200 (CEST) Received: from e226.stw.stud.uni-saarland.de ([134.96.65.241] helo=hipac.org) by e002.stw.stud.uni-saarland.de with esmtp (Exim 3.35 #1 (Debian)) id 19Xkvi-0007iJ-00; Wed, 02 Jul 2003 18:58:02 +0200 Message-ID: <3F030EFC.7090809@hipac.org> Date: Wed, 02 Jul 2003 18:57:32 +0200 From: Michael Bellion and Thomas Heinz User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 X-Accept-Language: de, en MIME-Version: 1.0 To: P@draigbrady.com CC: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [ANNOUNCE] nf-hipac v0.8 released References: <200307021426.56138.nf@hipac.org> <3F02D964.7050301@draigBrady.com> <200307021548.19989.nf@hipac.org> <3F02EAE2.8050609@draigBrady.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by indyio.rz.uni-saarland.de id h62Gw3fZ067817 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h62Gw92x005473 X-archive-position: 3726 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nf@hipac.org Precedence: bulk X-list: netdev Hi Pádraig You wrote: > I was testing with 64 byte packets (so around 190Kpps). e100 cards at > least have a handy mode for continually sending a packet as fast as > possible. Also you can use more than one interface. Yes, that's true. When we did the performance tests we had in mind to compare the worst case behaviour of nf-hipac and iptables. Therefore we designed a ruleset which models the worst case for both iptables and nf-hipac. Of course, the test environment could have been tuned a lot more, e.g. udp instead of tcp, FORWARD chain instead of INPUT, tuned network parameters, more interfaces etc. Anyway, we prefer independent, more sophisticated performance tests. >>> # ./readprofile -m /boot/System.map | sort -nr | head -30 >>> 6779 total 0.0047 >>> 4441 default_idle 69.3906 >>> 787 handle_IRQ_event 7.0268 >>> 589 ip_packet_match 1.6733 >>> 433 ipt_do_table 0.6294 >>> 106 eth_type_trans 0.5521 >>> [...] > > Confused me too. The system would lock up and start dropping > packets after 125 rules. I.E. it would linearly degrade > as more rules were added. I'm guessing there is a fixed > interrupt overhead that is accounted for > by default_idle? Hm, but once the system starts to drop packets ip_packet_match and ipt_do_table start to dominate the profile, don't they? Regards, +-----------------------+----------------------+ | Michael Bellion | Thomas Heinz | | | | +-----------------------+----------------------+ From yoshfuji@linux-ipv6.org Wed Jul 2 10:54:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 10:54:22 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h62HsD2x006724 for ; Wed, 2 Jul 2003 10:54:15 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h62HtTBo003477; Thu, 3 Jul 2003 02:55:30 +0900 Date: Thu, 03 Jul 2003 02:55:29 +0900 (JST) Message-Id: <20030703.025529.100658086.yoshfuji@linux-ipv6.org> To: davem@redhat.com, jmorris@intercode.com.au CC: netdev@oss.sgi.com Subject: [PATCH] IPV6: fix a mistake in ipv6_advmss() conversion From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3727 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Hello. Sorry, I introduced a bug in ipv6_advmss() while converting advmss calculation to inline function. This patch fixes the bug. Index: linux-2.5/net/ipv6/route.c =================================================================== RCS file: /home/cvs/linux-2.5/net/ipv6/route.c,v retrieving revision 1.43 diff -u -r1.43 route.c --- linux-2.5/net/ipv6/route.c 28 Jun 2003 03:58:20 -0000 1.43 +++ linux-2.5/net/ipv6/route.c 2 Jul 2003 16:25:04 -0000 @@ -602,6 +602,8 @@ static inline unsigned int ipv6_advmss(unsigned int mtu) { + mtu -= sizeof(struct ipv6hdr) + sizeof(struct tcphdr); + if (mtu < ip6_rt_min_advmss) mtu = ip6_rt_min_advmss; -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From scott.feldman@intel.com Wed Jul 2 13:53:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 13:53:22 -0700 (PDT) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h62KrF2x008796 for ; Wed, 2 Jul 2003 13:53:15 -0700 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h62KmMB03526 for ; Wed, 2 Jul 2003 20:48:22 GMT Received: from fmsmsxv040-1.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108]) by petasus.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h62KkGZ09881 for ; Wed, 2 Jul 2003 20:46:16 GMT Received: from [134.134.179.196] ([134.134.179.196]) by fmsmsxv040-1.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003070213524023002 ; Wed, 02 Jul 2003 13:52:40 -0700 Date: Wed, 2 Jul 2003 14:09:09 -0700 (PDT) From: "Feldman, Scott" X-X-Sender: scott.feldman@localhost.localdomain Reply-To: "Feldman, Scott" To: Larry Sendlosky cc: netdev@oss.sgi.com Subject: Re: e1000 in 2.4.21 and carrier errors In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3728 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev On Wed, 2 Jul 2003, Larry Sendlosky wrote: > We started running 2.4.21 and use the e1000 driver in the kernel. Our > NICs are PRO-1000 82543GC based copper. Using the new driver we see > constant increase in carrier errors. Loading the Intel e1000 v3.6.8.1 > driver we have no carrier errors. This happens on all our systems with > the PR0-1000 card using 2.4.21 and RH9. Switches are a mixture of Dell, > Asante, Cisco, and Extreme. > > Any ideas? Hi Larry, apply this patch to 3.6.8.1 and see if you get carrier errors. Looks to me like a bug that was fixed in later drivers. Doesn't explain why we're getting carrier errors, but this will let us moved forward to 2.4.21. What are you testing with? Do you have any newer adapters (82544/5/6) you could try in the same setup? -scott diff -Naurp e1000-3.6.8.1/src/e1000_main.c e1000-3.6.8.1-mod/src/e1000_main.c --- e1000-3.6.8.1/src/e1000_main.c 2001-12-28 15:06:18.000000000 -0800 +++ e1000-3.6.8.1-mod/src/e1000_main.c 2003-07-02 14:03:02.000000000 -0700 @@ -2928,6 +2928,7 @@ UpdateStatsCounters(struct adapter * Ada Adapter->net_stats.tx_aborted_errors = Adapter->Ecol; Adapter->net_stats.tx_fifo_errors = Adapter->Tuc; Adapter->net_stats.tx_window_errors = Adapter->Latecol; + Adapter->net_stats.tx_carrier_errors = Adapter->Tncrs; /* Tx Dropped needs to be maintained elsewhere */ From latten@austin.ibm.com Wed Jul 2 16:50:05 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 16:50:11 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h62No42x012030 for ; Wed, 2 Jul 2003 16:50:05 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h62NnJxe106086; Wed, 2 Jul 2003 19:49:19 -0400 Received: from austin.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h62NnGsH202560; Wed, 2 Jul 2003 17:49:17 -0600 Received: from faith.austin.ibm.com (faith.austin.ibm.com [9.41.94.16]) by austin.ibm.com (8.12.9/8.12.9) with ESMTP id h62NnGTi030114; Wed, 2 Jul 2003 18:49:16 -0500 Received: from faith.austin.ibm.com (localhost.localdomain [127.0.0.1]) by faith.austin.ibm.com (8.12.5/8.12.8) with ESMTP id h62NsOIY002989; Wed, 2 Jul 2003 18:54:24 -0500 Received: (from jml@localhost) by faith.austin.ibm.com (8.12.5/8.12.5/Submit) id h62NsMYP002987; Wed, 2 Jul 2003 18:54:23 -0500 Date: Wed, 2 Jul 2003 18:54:23 -0500 From: latten@austin.ibm.com Message-Id: <200307022354.h62NsMYP002987@faith.austin.ibm.com> To: netdev@oss.sgi.com Subject: IPSecv6 AH doesn't work with Fragmenting Cc: davem@redhat.com, kuznet@ms2.inr.ac.ru X-archive-position: 3729 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: latten@austin.ibm.com Precedence: bulk X-list: netdev I am using netperf to stress IPSecv6 with AH protocol. Netperf sent a stream of TCP packets to the receiver. I examined the log on my receiver and saw many "IPSec ah authentication error" messages. I then sniffed my incoming packets and saw that they had been fragmented and each fragment was reported as being malformed. Source Destination Protocol Info 1 fec0:0:0:105::56 fec0:0:0:105::55 TCP 32780 > 32772 [ACK]... 2 fec0:0:0:105::56 fec0:0:0:105::55 AH AH (SPI=0x00000000)[Malformed Packet] 3 fec0:0:0:105::55 fec0:0:0:105::56 TCP 32772 > 32780 [ACK]... 4 fec0:0:0:105::56 fec0:0:0:105::55 TCP 32780 > 32772 [ACK]... 5 fec0:0:0:105::56 fec0:0:0:105::55 AH AH (SPI=0x00000000)[ Malformed Packet] Just for the heck of it, I did a "ping6 -s 1800" and sniffed the wire and although the ping/ICMPv6 works fine in that I get a reply and no authentication failures are logged, my packets are reported as being malformed. It seems AH with fragmenting is not working properly and perhaps that is the cause of all the AH authentication errors I see in my log. Unfortunately I could not cut and paste my ethereal output but if anyone is interested I could send it. It is also easy to reproduce. Just configure AHv6 manually between two machines and run netperf or ping6 -s or anything that would result in fragmentation. Joy From zwane@arm.linux.org.uk Wed Jul 2 17:16:19 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 17:16:32 -0700 (PDT) Received: from hemi.commfireservices.com ([66.212.224.118]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h630GF2x012524 for ; Wed, 2 Jul 2003 17:16:18 -0700 Received: from montezuma.mastecende.com (cuda.commfireservices.com [24.203.207.204]) by hemi.commfireservices.com (Postfix) with ESMTP id 59C34BC51; Wed, 2 Jul 2003 20:06:02 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by montezuma.mastecende.com (8.12.8/8.12.8) with ESMTP id h63053vo011678; Wed, 2 Jul 2003 20:05:03 -0400 Date: Wed, 2 Jul 2003 20:05:03 -0400 (EDT) From: Zwane Mwaikambo X-X-Sender: zwane@montezuma.mastecende.com To: "Feldman, Scott" Cc: netdev@oss.sgi.com Subject: RE: e1000 lockup with port io type reset In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3730 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zwane@arm.linux.org.uk Precedence: bulk X-list: netdev On Sat, 28 Jun 2003, Zwane Mwaikambo wrote: > Thanks, i just have to wait on the dmi decode. I'll have it to you ASAP. Here we go; # dmidecode 2.1 SMBIOS 2.3 present. 46 structures occupying 1342 bytes. Table at 0x000F2970. Handle 0x0000 DMI type 0, 20 bytes. BIOS Information Vendor: Award Software, Inc. Version: ASUS CUV4X-E ACPI BIOS Revision 1004 Release Date: 07/25/2001 Address: 0xF0000 Runtime Size: 64 kB ROM Size: 256 kB Characteristics: PCI is supported PNP is supported APM is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported Selectable boot is supported BIOS ROM is socketed EDD is supported 5.25"/360 KB floppy services are supported (int 13h) 5.25"/1.2 MB floppy services are supported (int 13h) 3.5"/720 KB floppy services are supported (int 13h) 3.5"/2.88 MB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) CGA/mono video services are supported (int 10h) ACPI is supported AGP is supported Handle 0x0001 DMI type 1, 25 bytes. System Information Manufacturer: System Manufacturer Product Name: System Name Version: System Version Serial Number: SYS-1234567890 UUID: Not Settable Wake-up Type: Power Switch Handle 0x0002 DMI type 2, 8 bytes. Base Board Information Manufacturer: ASUSTeK Computer INC. Product Name: CUV4X-E Version: REV 1.xx Serial Number: xxxxxxxxxxx Handle 0x0003 DMI type 3, 17 bytes. Chassis Information Manufacturer: Chassis Manufacture Type: Tower Lock: Not Present Version: Chassis Version Serial Number: Chassis Serial Number Asset Tag: Asset-1234567890 Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: Unknown OEM Information: 0x00000000 Handle 0x0004 DMI type 4, 32 bytes. Processor Information Socket Designation: PGA 370 Type: Central Processor Family: Celeron Manufacturer: GenuineIntel ID: 8A 06 00 00 FF F9 83 03 Signature: Type 0, Family 6, Model 8, Stepping 10 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) PAE (Physical address extension) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture) CMOV (Conditional move instruction supported) PAT (Page attribute table) PSE-36 (36-bit page size extension) MMX (MMX technology supported) FXSR (Fast floating-point save and restore) SSE (Streaming SIMD extensions) Version: Intel Celeron(TM) Processor Voltage: 1.7 V External Clock: 100 MHz Max Speed: 1200 MHz Current Speed: 1100 MHz Status: Populated, Enabled Upgrade: LIF Socket L1 Cache Handle: 0x000A L2 Cache Handle: 0x000B L3 Cache Handle: Not Provided Handle 0x0005 DMI type 5, 24 bytes. Memory Controller Information Error Detecting Method: None Error Correcting Capabilities: Other Supported Interleave: Unknown Current Interleave: Unknown Maximum Memory Module Size: 1024 MB Maximum Total Memory Size: 4096 MB Supported Speeds: 70 ns 60 ns 50 ns Supported Memory Types: DIMM SDRAM Memory Module Voltage: 3.3 V Associated Memory Slots: 4 0x0006 0x0007 0x0008 0x0009 Enabled Error Correcting Capabilities: Unknown Handle 0x0006 DMI type 6, 12 bytes. Memory Module Information Socket Designation: DIMM 1 Bank Connections: 0 1 Current Speed: Unknown Type: DIMM SDRAM Installed Size: 128 MB (Single-bank Connection) Enabled Size: 128 MB (Single-bank Connection) Error Status: OK Handle 0x0007 DMI type 6, 12 bytes. Memory Module Information Socket Designation: DIMM 2 Bank Connections: 2 3 Current Speed: Unknown Type: DIMM SDRAM Installed Size: 128 MB (Double-bank Connection) Enabled Size: 128 MB (Double-bank Connection) Error Status: OK Handle 0x0008 DMI type 6, 12 bytes. Memory Module Information Socket Designation: DIMM 3 Bank Connections: 4 5 Current Speed: Unknown Type: DIMM SDRAM Installed Size: Not Installed (Single-bank Connection) Enabled Size: Not Installed (Single-bank Connection) Error Status: OK Handle 0x0009 DMI type 6, 12 bytes. Memory Module Information Socket Designation: DIMM 4 Bank Connections: 6 7 Current Speed: Unknown Type: DIMM SDRAM Installed Size: Not Installed (Single-bank Connection) Enabled Size: Not Installed (Single-bank Connection) Error Status: OK Handle 0x000A DMI type 7, 19 bytes. Cache Information Socket Designation: L1 Cache Configuration: Enabled, Not Socketed, Level 1 Operational Mode: Write Back Location: Internal Installed Size: 32 KB Maximum Size: 32 KB Supported SRAM Types: Pipeline Burst Synchronous Installed SRAM Type: Pipeline Burst Synchronous Speed: Unknown Error Correction Type: Unknown System Type: Data Associativity: 4-way Set-associative Handle 0x000B DMI type 7, 19 bytes. Cache Information Socket Designation: L2 Cache Configuration: Enabled, Not Socketed, Level 2 Operational Mode: Write Back Location: Internal Installed Size: 128 KB Maximum Size: 256 KB Supported SRAM Types: Pipeline Burst Synchronous Installed SRAM Type: Pipeline Burst Synchronous Speed: Unknown Error Correction Type: Unknown System Type: Data Associativity: 4-way Set-associative Handle 0x000C DMI type 8, 9 bytes. Port Connector Information Internal Reference Designator: PRIMARY IDE/HDD Internal Connector Type: On Board IDE External Reference Designator: Not Specified External Connector Type: None Port Type: None Handle 0x000D DMI type 8, 9 bytes. Port Connector Information Internal Reference Designator: SECONDARY IDE/HDD Internal Connector Type: On Board IDE External Reference Designator: Not Specified External Connector Type: None Port Type: None Handle 0x000E DMI type 8, 9 bytes. Port Connector Information Internal Reference Designator: FLOPPY Internal Connector Type: On Board Floppy External Reference Designator: Not Specified External Connector Type: None Port Type: None Handle 0x000F DMI type 8, 9 bytes. Port Connector Information Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: USB1 External Connector Type: Access Bus (USB) Port Type: USB Handle 0x0010 DMI type 8, 9 bytes. Port Connector Information Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: USB2 External Connector Type: Access Bus (USB) Port Type: USB Handle 0x0011 DMI type 8, 9 bytes. Port Connector Information Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: PS/2 Keybaord External Connector Type: PS/2 Port Type: Keyboard Port Handle 0x0012 DMI type 8, 9 bytes. Port Connector Information Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: PS/2 Mouse External Connector Type: PS/2 Port Type: Mouse Port Handle 0x0013 DMI type 8, 9 bytes. Port Connector Information Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: Parallel Port External Connector Type: DB-25 female Port Type: Parallel Port ECP/EPP Handle 0x0014 DMI type 8, 9 bytes. Port Connector Information Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: Serial Port External Connector Type: DB-9 male Port Type: Serial Port 16550 Compatible Handle 0x0015 DMI type 8, 9 bytes. Port Connector Information Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: Serial Port 2 External Connector Type: DB-9 male Port Type: Serial Port 16550 Compatible Handle 0x0016 DMI type 8, 9 bytes. Port Connector Information Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: Video Port External Connector Type: Mini Jack (headphones) Port Type: Video Port Handle 0x0017 DMI type 9, 13 bytes. System Slot Information Designation: PCI 1 Type: 32-bit PCI Current Usage: Available Length: Short ID: 1 Characteristics: 5.0 V is provided 3.3 V is provided PME signal is supported Handle 0x0018 DMI type 9, 13 bytes. System Slot Information Designation: PCI 2 Type: 32-bit PCI Current Usage: In Use Length: Short ID: 2 Characteristics: 5.0 V is provided 3.3 V is provided PME signal is supported Handle 0x0019 DMI type 9, 13 bytes. System Slot Information Designation: PCI 3 Type: 32-bit PCI Current Usage: In Use Length: Short ID: 3 Characteristics: 5.0 V is provided 3.3 V is provided PME signal is supported Handle 0x001A DMI type 9, 13 bytes. System Slot Information Designation: PCI 4 Type: 32-bit PCI Current Usage: In Use Length: Short ID: 4 Characteristics: 5.0 V is provided 3.3 V is provided PME signal is supported Handle 0x001B DMI type 9, 13 bytes. System Slot Information Designation: PCI 5 Type: 32-bit PCI Current Usage: Available Length: Short ID: 5 Characteristics: 5.0 V is provided 3.3 V is provided PME signal is supported Handle 0x001C DMI type 9, 13 bytes. System Slot Information Designation: PCI 6 Type: 32-bit PCI Current Usage: Available Length: Short ID: 6 Characteristics: 5.0 V is provided 3.3 V is provided PME signal is supported Handle 0x001D DMI type 9, 13 bytes. System Slot Information Designation: AGP Type: 32-bit PCI Current Usage: In Use Length: Short ID: 7 Characteristics: 3.3 V is provided PME signal is supported Handle 0x001E DMI type 11, 5 bytes. OEM Strings String 1: 0 String 2: 0 Handle 0x001F DMI type 13, 22 bytes. BIOS Language Information Installable Languages: 1 en|US|iso8859-1 Currently Installed Language: en|US|iso8859-1 Handle 0x0020 DMI type 14, 14 bytes. Group Associations Name: Cpu Module Items: 3 0x0004 (Processor) 0x000A (Cache) 0x000B (Cache) Handle 0x0021 DMI type 14, 35 bytes. Group Associations Name: Memory Module Set Items: 10 0x0022 (Physical Memory Array) 0x0023 (Memory Device) 0x0028 (Memory Device Mapped Address) 0x0024 (Memory Device) 0x0029 (Memory Device Mapped Address) 0x0025 (Memory Device) 0x002A (Memory Device Mapped Address) 0x0026 (Memory Device) 0x002B (Memory Device Mapped Address) 0x0027 (Memory Array Mapped Address) Handle 0x0022 DMI type 16, 15 bytes. Physical Memory Array Location: System Board Or Motherboard Use: System Memory Error Correction Type: None Maximum Capacity: 1 GB Error Information Handle: Not Provided Number Of Devices: 4 Handle 0x0023 DMI type 17, 23 bytes. Memory Device Array Handle: 0x0022 Error Information Handle: No Error Total Width: 72 bits Data Width: 64 bits Size: 128 MB Form Factor: DIMM Set: 1 Locator: DIMM 1 Bank Locator: Not Specified Type: DRAM Type Detail: Synchronous Speed: Unknown Handle 0x0024 DMI type 17, 23 bytes. Memory Device Array Handle: 0x0022 Error Information Handle: No Error Total Width: 72 bits Data Width: 64 bits Size: 128 MB Form Factor: DIMM Set: 2 Locator: DIMM 2 Bank Locator: Not Specified Type: DRAM Type Detail: Synchronous Speed: Unknown Handle 0x0025 DMI type 17, 23 bytes. Memory Device Array Handle: 0x0022 Error Information Handle: No Error Total Width: Unknown Data Width: Unknown Size: No Module Installed Form Factor: DIMM Set: 2 Locator: DIMM 3 Bank Locator: Not Specified Type: DRAM Type Detail: Synchronous Speed: Unknown Handle 0x0026 DMI type 17, 23 bytes. Memory Device Array Handle: 0x0022 Error Information Handle: No Error Total Width: Unknown Data Width: Unknown Size: No Module Installed Form Factor: DIMM Set: 2 Locator: DIMM 4 Bank Locator: Not Specified Type: DRAM Type Detail: Synchronous Speed: Unknown Handle 0x0027 DMI type 19, 15 bytes. Memory Array Mapped Address Starting Address: 0x00000000000 Ending Address: 0x040000003FF Range Size: 268435457 kB Physical Array Handle: 0x0022 Partition Width: 0 Handle 0x0028 DMI type 20, 19 bytes. Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x00007FFFFFF Range Size: 128 MB Physical Device Handle: 0x0023 Memory Array Mapped Address Handle: 0x0027 Partition Row Position: 1 Handle 0x0029 DMI type 20, 19 bytes. Memory Device Mapped Address Starting Address: 0x00008000000 Ending Address: 0x0000FFFFFFF Range Size: 128 MB Physical Device Handle: 0x0024 Memory Array Mapped Address Handle: 0x0027 Partition Row Position: 2 Handle 0x002A DMI type 126, 19 bytes. Inactive Handle 0x002B DMI type 126, 19 bytes. Inactive Handle 0x002C DMI type 32, 11 bytes. System Boot Information Status: No errors detected Handle 0x002D DMI type 127, 4 bytes. End Of Table 00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4) Subsystem: Asustek Computer, Inc.: Unknown device 80e7 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: 06 11 91 06 06 00 10 22 c4 00 00 06 00 00 00 00 10: 08 00 00 fc 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 43 10 e7 80 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: fd d8 c8 f6 04 00 10 10 88 00 08 08 0c 10 10 10 60: 0f 2a 00 a0 e6 e6 95 95 41 7c 86 2f 08 6f 00 33 70: c0 88 cc 0c 0e a1 d2 00 01 b4 01 02 00 00 00 02 80: 0f 41 00 00 e0 00 00 00 03 80 f1 0f cc 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 02 c0 20 00 03 02 00 1f 00 00 00 00 6b 02 00 00 b0: 7f 63 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 01 00 00 00 00 00 00 0e 00 00 00 00 00 00 00 00 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- FastB2B- Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: 06 11 98 85 07 00 30 22 00 00 04 06 00 00 01 00 10: 00 00 00 00 00 00 00 00 00 01 01 00 d0 d0 00 00 20: 00 fa d0 fa f0 fa f0 fb 00 00 00 00 00 00 00 00 30: 00 00 00 00 80 00 00 00 00 00 00 00 00 00 08 00 40: c8 cd 00 44 04 72 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 01 00 02 02 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40) Subsystem: Asustek Computer, Inc.: Unknown device 80e7 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- [disabled] [size=128K] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable+ DSel=0 DScale=1 PME- Capabilities: [e4] PCI-X non-bridge device. Command: DPERE- ERO+ RBC=0 OST=0 Status: Bus=0 Dev=0 Func=0 64bit- 133MHz- SCD- USC-, DC=simple, DMMRBC=2, DMOST=0, DMCRS=0, RSCEM- Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 00: 86 80 0c 10 17 00 30 02 02 00 00 02 08 20 00 00 10: 00 00 80 f9 00 00 00 f9 01 a8 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 12 11 30: 00 00 00 00 dc 00 00 00 00 00 00 00 0a 01 ff 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 01 e4 22 c8 e0: 00 21 00 37 07 f0 02 00 00 00 40 00 00 00 00 00 f0: 05 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00:09.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 30) Subsystem: 3Com Corporation 3C905B Fast Etherlink XL 10/100 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- [disabled] [size=128K] Capabilities: [dc] Power Management version 1 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: b7 10 55 90 17 00 10 02 30 00 00 02 08 20 00 00 10: 01 a4 00 00 00 00 80 f8 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 b7 10 55 90 30: 00 00 00 00 dc 00 00 00 00 00 00 00 07 01 0a 0a 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 01 00 01 f6 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:0a.0 FireWire (IEEE 1394): Texas Instruments TSB12LV23 IEEE-1394 Controller (prog-if 10 [OHCI]) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- 00: 02 10 42 47 87 00 90 02 5c 00 00 03 08 40 00 00 10: 08 00 00 fb 01 d8 00 00 00 00 00 fa 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 02 10 80 00 30: 00 00 fe fa 50 00 00 00 00 00 00 00 ff 00 08 00 40: 0c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 02 00 10 00 03 02 00 ff 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 From haveblue@us.ibm.com Wed Jul 2 17:56:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 17:56:45 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h630uR2x013011 for ; Wed, 2 Jul 2003 17:56:34 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h630uKXq147674; Wed, 2 Jul 2003 20:56:20 -0400 Received: from DYN318089.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h630uIqO253254; Wed, 2 Jul 2003 20:56:18 -0400 Subject: impressive throughput on 2.5.73 From: Dave Hansen To: netdev@oss.sgi.com Cc: Scott Feldman , Nivedita Singhvi Content-Type: text/plain Organization: Message-Id: <1057193766.31286.843.camel@nighthawk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 02 Jul 2003 17:56:07 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 3731 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: haveblue@us.ibm.com Precedence: bulk X-list: netdev I run a little script to load up a gigabit ethernet link between two of my machines: an 8-way PIII web server, and a 4-way PIII client. Both client and server have e1000s. The script fetches a bunch of fairly big files via http from the server, using apache. I'm impressed that it can fill just about the entire gigabit pipe, while using less than 1 of the server's CPUs. 176 requests/sec - 110.0 MB/second - 0.6 MB/request Server CPU breakdown. 2% system 7% user 91% idle I'm not using any interrupt mitigation, so I'm still at ~9k interrupts/sec. I'll try NAPI next. server profile: 197212 total 0.1159 175783 poll_idle 2441.4306 1474 alloc_skb 6.8241 1281 skb_release_data 8.6554 1202 skb_clone 3.7563 1038 do_tcp_sendpages 0.3655 998 e1000_clean_tx_irq 2.1886 974 e1000_xmit_frame 0.5148 841 tcp_transmit_skb 0.5729 827 Letext 2.0675 791 __kmalloc 6.3790 739 ip_queue_xmit 0.6415 629 ip_finish_output 1.4976 583 tcp_write_xmit 0.7836 571 tcp_v4_rcv 0.2896 422 schedule 0.2733 417 e1000_intr 3.7232 403 tcp_clean_rtx_queue 0.5140 399 __kfree_skb 2.1685 353 kfree 3.6771 337 kmem_cache_free 4.4342 309 e1000_clean_rx_irq 0.3053 291 find_get_page 6.0625 284 do_softirq 1.4200 246 eth_type_trans 1.4643 233 dev_queue_xmit 0.4380 226 __wake_up 5.1364 216 ip_rcv 0.2093 202 sock_wfree 3.3667 202 memcpy 5.0500 client profile: 33363 total 0.0196 9575 poll_idle 132.9861 5099 __copy_user_intel 32.6859 3307 schedule 2.1418 1753 __wake_up 39.8409 667 tcp_v4_rcv 0.3382 577 pipe_write 0.7970 510 __down_wq 1.7708 488 alloc_skb 2.2593 476 tcp_recvmsg 0.2216 457 tcp_rcv_established 0.2746 457 __kfree_skb 2.4837 405 dnotify_parent 4.5000 382 pipe_read 0.7290 368 system_call 8.3636 350 kill_fasync 7.0000 341 current_kernel_time 5.0147 299 __kmalloc 2.4113 280 ip_rcv 0.2713 252 eth_type_trans 1.5000 245 skb_release_data 1.6554 233 ip_queue_xmit 0.2023 232 kfree 2.4167 228 e1000_clean_rx_irq 0.2253 210 pipe_wait 1.3816 205 e1000_clean_tx_irq 0.4496 200 tcp_transmit_skb 0.1362 199 e1000_xmit_frame 0.1052 -- Dave Hansen haveblue@us.ibm.com From niv@us.ibm.com Wed Jul 2 20:01:43 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 20:01:46 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6331a2x014325 for ; Wed, 2 Jul 2003 20:01:42 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h6331R8w246212; Wed, 2 Jul 2003 23:01:28 -0400 Received: from us.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6331QsH179690; Wed, 2 Jul 2003 21:01:27 -0600 Message-ID: <3F039BE1.2080008@us.ibm.com> Date: Wed, 02 Jul 2003 19:58:41 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Hansen CC: netdev@oss.sgi.com, Scott Feldman Subject: Re: impressive throughput on 2.5.73 References: <1057193766.31286.843.camel@nighthawk> In-Reply-To: <1057193766.31286.843.camel@nighthawk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3733 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Dave Hansen wrote: > 176 requests/sec - 110.0 MB/second - 0.6 MB/request > > Server CPU breakdown. > 2% system > 7% user > 91% idle > > client profile: > 33363 total 0.0196 > 9575 poll_idle 132.9861 > 5099 __copy_user_intel 32.6859 > 3307 schedule 2.1418 > 1753 __wake_up 39.8409 > 667 tcp_v4_rcv 0.3382 Nice numbers :). In addition to NAPI, would be nice to stick in more adapters. Any idea why __wake_up should be so expensive on the client side? thanks, Nivedita From haveblue@us.ibm.com Wed Jul 2 20:21:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 20:21:22 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h633LB2x016492 for ; Wed, 2 Jul 2003 20:21:18 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h633L4Xq143078; Wed, 2 Jul 2003 23:21:04 -0400 Received: from nighthawk.sr71.net (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h633L241074244; Wed, 2 Jul 2003 23:21:03 -0400 Subject: Re: impressive throughput on 2.5.73 From: Dave Hansen To: Nivedita Singhvi Cc: netdev@oss.sgi.com, Scott Feldman In-Reply-To: <3F039BE1.2080008@us.ibm.com> References: <1057193766.31286.843.camel@nighthawk> <3F039BE1.2080008@us.ibm.com> Content-Type: text/plain Organization: Message-Id: <1057202451.2916.36.camel@nighthawk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 02 Jul 2003 20:20:52 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 3734 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: haveblue@us.ibm.com Precedence: bulk X-list: netdev On Wed, 2003-07-02 at 19:58, Nivedita Singhvi wrote: > Nice numbers :). In addition to NAPI, would be nice to > stick in more adapters. Any idea why __wake_up should be > so expensive on the client side? NAPI seems to degrade throughput down to ~80MB/sec, but the interrupt rate doesn't change. I'm going to put some debugging in and makes sure that it's kicking in properly. -- Dave Hansen haveblue@us.ibm.com From shibu_lkml@yahoo.com Wed Jul 2 20:16:11 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 20:27:14 -0700 (PDT) Received: from web20704.mail.yahoo.com (web20704.mail.yahoo.com [216.136.226.177]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h633GA2x016453 for ; Wed, 2 Jul 2003 20:16:11 -0700 Message-ID: <20030703031610.79050.qmail@web20704.mail.yahoo.com> Received: from [202.54.26.201] by web20704.mail.yahoo.com via HTTP; Wed, 02 Jul 2003 20:16:10 PDT Date: Wed, 2 Jul 2003 20:16:10 -0700 (PDT) From: Shibu LKML Subject: Disconnecting a connected UDP socket To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-572335396-1057202170=:79043" X-archive-position: 3735 X-Approved-By: ralf@linux-mips.org X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shibu_lkml@yahoo.com Precedence: bulk X-list: netdev --0-572335396-1057202170=:79043 Content-Type: text/plain; charset=us-ascii Hi, I am wondering if Linux supports disconnecting a connected UDP socket. The manpage for connect lists it in the BUGS section. It says disconnect is still not supported. I was wondering if it involves more than adding the following lines to udp_connect in udp.c if (usin->sin_family == AF_UNSPEC) return udp_disconnect(sk, 0); (just above sk_dst_reset(sk)) Will this fix the problem for IPV4 stuff? Regards Shibu --------------------------------- Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! --0-572335396-1057202170=:79043 Content-Type: text/html; charset=us-ascii
Hi,
 
I am wondering if Linux supports disconnecting a connected UDP socket. The manpage for connect lists it in the BUGS section. It says disconnect is still not supported. I was wondering if it involves more than adding the following lines to udp_connect in udp.c
 
if (usin->sin_family == AF_UNSPEC)
  return udp_disconnect(sk, 0);
(just  above sk_dst_reset(sk))
 
Will this fix the problem for IPV4 stuff?
 
 
Regards
Shibu
 

Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month! --0-572335396-1057202170=:79043-- From haveblue@us.ibm.com Wed Jul 2 21:50:42 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 21:50:50 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h634of2x017532 for ; Wed, 2 Jul 2003 21:50:41 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h634oYDG174726; Thu, 3 Jul 2003 00:50:34 -0400 Received: from nighthawk.sr71.net (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h634oYl4116652; Wed, 2 Jul 2003 22:50:34 -0600 Subject: RE: impressive throughput on 2.5.73 From: Dave Hansen To: Scott Feldman Cc: netdev@oss.sgi.com, Nivedita Singhvi In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1057207823.2916.87.camel@nighthawk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 02 Jul 2003 21:50:23 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 3737 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: haveblue@us.ibm.com Precedence: bulk X-list: netdev On Wed, 2003-07-02 at 21:41, Feldman, Scott wrote: > How many TSO per/second are you doing? > > # watch "ethtool -S ethX | grep tx_tcp_seg" Hmmm. My ethtool doesn't have a "-S", only "-s". Is is too ancient? -- Dave Hansen haveblue@us.ibm.com From haveblue@us.ibm.com Wed Jul 2 21:59:09 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 21:59:13 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h634x82x017763 for ; Wed, 2 Jul 2003 21:59:09 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h634x2Ys225030; Thu, 3 Jul 2003 00:59:02 -0400 Received: from nighthawk.sr71.net (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h634wxqO257098; Thu, 3 Jul 2003 00:59:00 -0400 Subject: RE: impressive throughput on 2.5.73 From: Dave Hansen To: Scott Feldman Cc: netdev@oss.sgi.com, Nivedita Singhvi In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1057208329.2957.96.camel@nighthawk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 02 Jul 2003 21:58:49 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 3738 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: haveblue@us.ibm.com Precedence: bulk X-list: netdev On Wed, 2003-07-02 at 21:41, Feldman, Scott wrote: > > server, using apache. I'm impressed that it can fill just > > about the entire gigabit pipe, while using less than 1 of the > > server's CPUs. > > 1 PIII CPU per 1GbE interface is a good rule of thumb. A 10GbE > interface would consume your 8-way, right? Sounds right :) > How many TSO per/second are you doing? > > # watch "ethtool -S ethX | grep tx_tcp_seg" ethtool 1.6 fixed my -S problem ~3500, apparently tx_tcp_seg_good: 401212 tx_tcp_seg_failed: 0 -- Dave Hansen haveblue@us.ibm.com From zwane@arm.linux.org.uk Wed Jul 2 22:51:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 22:51:46 -0700 (PDT) Received: from hemi.commfireservices.com ([66.212.224.118]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h635pZ2x019268 for ; Wed, 2 Jul 2003 22:51:37 -0700 Received: from montezuma.mastecende.com (cuda.commfireservices.com [24.203.207.204]) by hemi.commfireservices.com (Postfix) with ESMTP id 68AADBC51; Thu, 3 Jul 2003 01:41:20 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by montezuma.mastecende.com (8.12.8/8.12.8) with ESMTP id h635eLvo007264; Thu, 3 Jul 2003 01:40:21 -0400 Date: Thu, 3 Jul 2003 01:40:21 -0400 (EDT) From: Zwane Mwaikambo X-X-Sender: zwane@montezuma.mastecende.com To: "Feldman, Scott" Cc: Dave Hansen , netdev@oss.sgi.com, Nivedita Singhvi Subject: RE: impressive throughput on 2.5.73 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3740 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zwane@arm.linux.org.uk Precedence: bulk X-list: netdev On Wed, 2 Jul 2003, Feldman, Scott wrote: > Interrupt mitigation must be on if you're only getting 9K intr/sec. If > you where getting one interrupt per packet, you'd see an order of > magnitude higher intr/sec rate. What about the e1000 hw interrupt mitigation, isn't the interrupt throttle on by default? Zwane -- function.linuxpower.ca From yoshfuji@linux-ipv6.org Thu Jul 3 02:38:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Jul 2003 02:38:51 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h639ch2x024187 for ; Thu, 3 Jul 2003 02:38:44 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h639cpBo009420; Thu, 3 Jul 2003 18:38:52 +0900 Date: Thu, 03 Jul 2003 18:38:50 +0900 (JST) Message-Id: <20030703.183850.78164037.yoshfuji@linux-ipv6.org> To: davem@redhat.com, jmorris@intercode.com.au, chas@cmf.nrl.navy.mil CC: netdev@oss.sgi.com, linux-atm-general@lists.sourceforge.net, yoshfuji@linux-ipv6.org Subject: [PATCH] ATM: CLIP: C99 initializers From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3743 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Hello. This converts nlip_tbl to C99 initializers. (and fixes wrong value for proxy_len and locktime.) Thanks. Index: linux-2.5/net/atm/clip.c =================================================================== RCS file: /home/cvs/linux-2.5/net/atm/clip.c,v retrieving revision 1.17 diff -u -r1.17 clip.c --- linux-2.5/net/atm/clip.c 23 Jun 2003 22:08:56 -0000 1.17 +++ linux-2.5/net/atm/clip.c 3 Jul 2003 08:17:44 -0000 @@ -327,40 +327,34 @@ return hash_val; } - static struct neigh_table clip_tbl = { - NULL, /* next */ - AF_INET, /* family */ - sizeof(struct neighbour)+sizeof(struct atmarp_entry), /* entry_size */ - 4, /* key_len */ - clip_hash, - clip_constructor, /* constructor */ - NULL, /* pconstructor */ - NULL, /* pdestructor */ - NULL, /* proxy_redo */ - "clip_arp_cache", - { /* neigh_parms */ - NULL, /* next */ - NULL, /* neigh_setup */ - &clip_tbl, /* tbl */ - 0, /* entries */ - NULL, /* priv */ - NULL, /* sysctl_table */ - 30*HZ, /* base_reachable_time */ - 1*HZ, /* retrans_time */ - 60*HZ, /* gc_staletime */ - 30*HZ, /* reachable_time */ - 5*HZ, /* delay_probe_time */ - 3, /* queue_len */ - 3, /* ucast_probes */ - 0, /* app_probes */ - 3, /* mcast_probes */ - 1*HZ, /* anycast_delay */ - (8*HZ)/10, /* proxy_delay */ - 1*HZ, /* proxy_qlen */ - 64 /* locktime */ + .family = AF_INET, + .entry_size = sizeof(struct neighbour)+sizeof(struct atmarp_entry), + .key_len = 4, + .hash = clip_hash, + .constructor = clip_constructor, + .id = "clip_arp_cache", + + /* parameters are copied from ARP ... */ + .parms = { + .tbl = &clip_tbl, + .base_reachable_time = 30 * HZ, + .retrans_time = 1 * HZ, + .gc_staletime = 60 * HZ, + .reachable_time = 30 * HZ, + .delay_probe_time = 5 * HZ, + .queue_len = 3, + .ucast_probes = 3, + .mcast_probes = 3, + .anycast_delay = 1 * HZ, + .proxy_delay = (8 * HZ) / 10, + .proxy_qlen = 64, + .locktime = 1 * HZ, }, - 30*HZ,128,512,1024 /* copied from ARP ... */ + .gc_interval = 30 * HZ, + .gc_thresh1 = 128, + .gc_thresh2 = 512, + .gc_thresh3 = 1024, }; -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From jmorris@intercode.com.au Thu Jul 3 04:14:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Jul 2003 04:14:17 -0700 (PDT) Received: from blackbird.intercode.com.au (IDENT:Zdb8oZtOJR7QKm2UDpQnqzfsE8lpvVJb@blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h63BDs2x026968 for ; Thu, 3 Jul 2003 04:13:56 -0700 Received: from excalibur.intercode.com.au (excalibur.intercode.com.au [203.32.101.12]) by blackbird.intercode.com.au (8.11.6p2/8.9.3) with ESMTP id h63ADpr18579; Thu, 3 Jul 2003 20:13:51 +1000 Date: Thu, 3 Jul 2003 20:13:51 +1000 (EST) From: James Morris To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: davem@redhat.com, , , , Subject: Re: [PATCH] NET: fix SEGV/OOPS with /proc/net/{raw,igmp,...} (is Re: [Bug 863] New: cat /proc/buddyinfo + netstat -a kills machine) In-Reply-To: <20030703.154429.06241047.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 3744 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@intercode.com.au Precedence: bulk X-list: netdev On Thu, 3 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote: > I'm not so sure if this is ralated to BUG#863, but anyway; > > Following patch fixes segv/oops with /proc/net/{raw,igmp,mfilter, > raw6,igmp6,mfilter6,anycast,ip6_flowlabel}. Applied to bk://kernel.bkbits.net/jmorris/net-2.5 - James -- James Morris From mcr@sandelman.ottawa.on.ca Thu Jul 3 09:35:04 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Jul 2003 09:35:15 -0700 (PDT) Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h63GYs2x006599 for ; Thu, 3 Jul 2003 09:35:04 -0700 Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h63GYcw18729 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Thu, 3 Jul 2003 12:34:40 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h63Ga5Y03011 for ; Thu, 3 Jul 2003 12:36:05 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h63GYIHc012786 for ; Thu, 3 Jul 2003 12:34:21 -0400 To: netdev Subject: rfc-editor@rfc-editor.org: RFC 3549 on Linux Netlink as an IP Services Protocol Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 03 Jul 2003 12:34:18 -0400 Message-ID: <12785.1057250058@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-archive-position: 3745 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcr@sandelman.ottawa.on.ca Precedence: bulk X-list: netdev From owner-ietf-announce@ietf.org Wed Jul 2 21:00:43 2003 Return-Path: Message-Id: <200307022318.h62NI9L04528@gamma.isi.edu> To: IETF-Announce: ; Subject: RFC 3549 on Linux Netlink as an IP Services Protocol Cc: rfc-editor@rfc-editor.org, forces@peach.ease.lsoft.com From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 02 Jul 2003 16:18:09 -0700 Sender: owner-ietf-announce@ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3549 Title: Linux Netlink as an IP Services Protocol Author(s): J. Salim, H. Khosravi, A. Kleen, A. Kuznetsov Status: Informational Date: July 2003 Mailbox: hadi@znyx.com, hormuzd.m.khosravi@intel.com, ak@suse.de, kuznet@ms2.inr.ac.ru Pages: 33 Characters: 72161 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-forces-netlink-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3549.txt This document describes Linux Netlink, which is used in Linux both as an intra-kernel messaging system as well as between kernel and user space. The focus of this document is to describe Netlink's functionality as a protocol between a Forwarding Engine Component (FEC) and a Control Plane Component (CPC), the two components that define an IP service. As a result of this focus, this document ignores other uses of Netlink, including its use as a intra-kernel messaging system, as an inter-process communication scheme (IPC), or as a configuration tool for other non-networking or non-IP network services (such as decnet, etc.). This document is intended as informational in the context of prior art for the ForCES IETF working group. This document is a product of the Forwarding and Control Element Separation Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030702161638.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3549 --OtherAccess Content-Type: Message/External-body; name="rfc3549.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030702161638.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From yoshfuji@linux-ipv6.org Thu Jul 3 10:27:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Jul 2003 10:27:57 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h63HRh2x007697 for ; Thu, 3 Jul 2003 10:27:45 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h63HSxBo012759; Fri, 4 Jul 2003 02:28:59 +0900 Date: Fri, 04 Jul 2003 02:28:57 +0900 (JST) Message-Id: <20030704.022857.07343571.yoshfuji@linux-ipv6.org> To: shibu_lkml@yahoo.com, davem@redhat.com, jmorris@intercode.com.au Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: [PATCH] NET: disconnect support by null address (is Re: Disconnecting a connected UDP socket) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20030703031610.79050.qmail@web20704.mail.yahoo.com> References: <20030703031610.79050.qmail@web20704.mail.yahoo.com> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3746 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Hello. In article <20030703031610.79050.qmail@web20704.mail.yahoo.com> (at Wed, 2 Jul 2003 20:16:10 -0700 (PDT)), Shibu LKML says: > I am wondering if Linux supports disconnecting a connected UDP socket. The manpage for connect lists it in the BUGS section. It says disconnect is still not supported. I was wondering if it involves more than adding the following lines to udp_connect in udp.c > > if (usin->sin_family == AF_UNSPEC) > return udp_disconnect(sk, 0); > > (just above sk_dst_reset(sk)) > > Will this fix the problem for IPV4 stuff? It seems. Please apply this. Index: linux-2.5/net/ipv4/udp.c =================================================================== RCS file: /home/cvs/linux-2.5/net/ipv4/udp.c,v retrieving revision 1.36 diff -u -r1.36 udp.c --- linux-2.5/net/ipv4/udp.c 21 Jun 2003 16:20:28 -0000 1.36 +++ linux-2.5/net/ipv4/udp.c 3 Jul 2003 16:01:29 -0000 @@ -868,6 +868,9 @@ if (addr_len < sizeof(*usin)) return -EINVAL; + if (usin->sin_family == AF_UNSPEC) + return udp_disconnect(sk, 0); + if (usin->sin_family != AF_INET) return -EAFNOSUPPORT; Index: linux-2.5/net/ipv6/udp.c =================================================================== RCS file: /home/cvs/linux-2.5/net/ipv6/udp.c,v retrieving revision 1.39 diff -u -r1.39 udp.c --- linux-2.5/net/ipv6/udp.c 1 Jul 2003 16:42:06 -0000 1.39 +++ linux-2.5/net/ipv6/udp.c 3 Jul 2003 16:01:29 -0000 @@ -213,6 +213,9 @@ int addr_type; int err; + if (usin->sin6_family == AF_UNSPEC) + return udp_disconnect(sk, 0); + if (usin->sin6_family == AF_INET) { if (__ipv6_only_sock(sk)) return -EAFNOSUPPORT; -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From yoshfuji@linux-ipv6.org Thu Jul 3 10:47:32 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Jul 2003 10:47:38 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h63HlV2x009392 for ; Thu, 3 Jul 2003 10:47:32 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h63HmoBo012935; Fri, 4 Jul 2003 02:48:50 +0900 Date: Fri, 04 Jul 2003 02:48:50 +0900 (JST) Message-Id: <20030704.024850.88858438.yoshfuji@linux-ipv6.org> To: shibu_lkml@yahoo.com, davem@redhat.com, jmorris@intercode.com.au Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] NET: disconnect support by null address (is Re: Disconnecting a connected UDP socket) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20030704.022857.07343571.yoshfuji@linux-ipv6.org> References: <20030703031610.79050.qmail@web20704.mail.yahoo.com> <20030704.022857.07343571.yoshfuji@linux-ipv6.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-archive-position: 3747 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <20030704.022857.07343571.yoshfuji@linux-ipv6.org> (at Fri, 04 Jul 2003 02:28:57 +0900 (JST)), YOSHIFUJI Hideaki / $B5HF#1QL@(B says: > It seems. Please apply this. Sorry, I was too hurry. net/ipv4/af_inet.c:inet_dgram_connect() cares this case. Please forget the patch... -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From greearb@candelatech.com Thu Jul 3 11:01:12 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Jul 2003 11:01:21 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-074.evrtwa1.dsl-verizon.net [4.33.45.74]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h63I1B2x009802 for ; Thu, 3 Jul 2003 11:01:12 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h63I0sKk024810; Thu, 3 Jul 2003 11:00:55 -0700 Message-ID: <3F046F56.1080808@candelatech.com> Date: Thu, 03 Jul 2003 11:00:54 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Richardson , hadi@znyx.com, hormuzd.m.khosravi@intel.com, ak@suse.de, kuznet@ms2.inr.ac.ru, "'netdev@oss.sgi.com'" Subject: Re: rfc-editor@rfc-editor.org: RFC 3549 on Linux Netlink as an IP Services Protocol References: <12785.1057250058@marajade.sandelman.ottawa.on.ca> In-Reply-To: <12785.1057250058@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3748 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Please make the 'table-id' field to be at least 16 bits. Now that we have VLANs and other types of virtual interfaces, it would be nice to be able to have a routing table for each interface, for example. 640k was not enough for everyone, and ~250 routing tables isn't either :) From section 3.1.1: Table ID: 8 bits Table identifier. Up to 255 route tables are supported. RT_TABLE_UNSPEC An unspecified routing table. RT_TABLE_DEFAULT The default table. RT_TABLE_MAIN The main table. RT_TABLE_LOCAL The local table. The user may assign arbitrary values between RT_TABLE_UNSPEC(0) and RT_TABLE_DEFAULT(253). Thanks, Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From jgarzik@pobox.com Thu Jul 3 19:47:11 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Jul 2003 19:47:17 -0700 (PDT) Received: from www.linux.org.uk (parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h642lA2x018741 for ; Thu, 3 Jul 2003 19:47:11 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19YGbL-0006Gs-Lu; Fri, 04 Jul 2003 03:47:07 +0100 Message-ID: <3F04EAA0.2050102@pobox.com> Date: Thu, 03 Jul 2003 22:46:56 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: Jeff Sipek CC: Kernel Mailing List , Andrew Morton , Dave Jones , Linus Torvalds , netdev@oss.sgi.com Subject: Re: [PATCH - RFC] [1/5] 64-bit network statistics - generic net References: <200307032231.39842.jeffpc@optonline.net> In-Reply-To: <200307032231.39842.jeffpc@optonline.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3749 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 Jeff Sipek wrote: > + spinlock_t rx_packets; > + spinlock_t tx_packets; > + spinlock_t rx_bytes; > + spinlock_t tx_bytes; > + spinlock_t rx_errors; > + spinlock_t tx_errors; > + spinlock_t rx_dropped; > + spinlock_t tx_dropped; > + spinlock_t multicast; > + spinlock_t collisions; > + spinlock_t rx_length_errors; > + spinlock_t rx_over_errors; > + spinlock_t rx_crc_errors; > + spinlock_t rx_frame_errors; > + spinlock_t rx_fifo_errors; > + spinlock_t rx_missed_errors; > + spinlock_t tx_aborted_errors; > + spinlock_t tx_carrier_errors; > + spinlock_t tx_fifo_errors; > + spinlock_t tx_heartbeat_errors; > + spinlock_t tx_window_errors; > + spinlock_t rx_compressed; > + spinlock_t tx_compressed; That's a fat daddy list of locks you got there. > + NETSTAT_TYPE _rx_packets; /* total packets received */ > + NETSTAT_TYPE _tx_packets; /* total packets transmitted */ > + NETSTAT_TYPE _rx_bytes; /* total bytes received */ > + NETSTAT_TYPE _tx_bytes; /* total bytes transmitted */ > + NETSTAT_TYPE _rx_errors; /* bad packets received */ > + NETSTAT_TYPE _tx_errors; /* packet transmit problems */ > + NETSTAT_TYPE _rx_dropped; /* no space in linux buffers */ > + NETSTAT_TYPE _tx_dropped; /* no space available in linux */ > + NETSTAT_TYPE _multicast; /* multicast packets received */ > + NETSTAT_TYPE _collisions; Increasing user-visible sizes arbitrarily breaks stuff. Having config-dependent types like this increases complexity. Short term, just sample the stats more rapidly. Long term, I suppose with 10GbE we should start thinking about this. Personally, I would prefer to make the standard net device stats available in the format already exported by ETHTOOL_GSTATS -- which I note uses u64's for its counters, and it's easily extensible. I received a request for this just today, even. Jeff P.S. Please cc netdev@oss.sgi.com for networking discussions. From vnuorval@tcs.hut.fi Fri Jul 4 17:16:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Jul 2003 17:16:40 -0700 (PDT) Received: from mail.tcs.hut.fi (mail.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h650GO2x014726 for ; Fri, 4 Jul 2003 17:16:25 -0700 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by mail.tcs.hut.fi (Postfix) with ESMTP id 52C8C800217; Fri, 4 Jul 2003 16:00:31 +0300 (EEST) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-5) with ESMTP id h64D0V5L015331; Fri, 4 Jul 2003 16:00:31 +0300 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-5) with ESMTP id h64D0T4J015327; Fri, 4 Jul 2003 16:00:30 +0300 Date: Fri, 4 Jul 2003 16:00:29 +0300 (EEST) From: Ville Nuorvala To: yoshfuji@linux-ipv6.org, , Cc: netdev@oss.sgi.com Subject: [PATCH] Tunnel device init patch Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3758 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Hello, I noticed a couple of bugs(?) in sit.c, ip_gre.c and ipip.c introduced in the alloc_netdev patches (csets 1.305.3.9, 1.305.3.10 and 1.1305.3.11). This patch made against cset 1.384 fixes the following issues: - tunnel dev pointer also set for fallback tunnels - dev name copied back to tunnel parameters so names autogenerated by kernel get correctly reported to userspace Thanks, Ville diff -Nur linux-2.5.OLD/net/ipv4/ip_gre.c linux-2.5/net/ipv4/ip_gre.c --- linux-2.5.OLD/net/ipv4/ip_gre.c Fri Jul 4 15:01:54 2003 +++ linux-2.5/net/ipv4/ip_gre.c Fri Jul 4 14:59:27 2003 @@ -1153,7 +1153,9 @@ tunnel = (struct ip_tunnel*)dev->priv; iph = &tunnel->parms.iph; - tunnel->dev = dev; + tunnel->dev = dev; + strcpy(tunnel->parms.name, dev->name); + memcpy(dev->dev_addr, &tunnel->parms.iph.saddr, 4); memcpy(dev->broadcast, &tunnel->parms.iph.daddr, 4); @@ -1214,6 +1216,9 @@ { struct ip_tunnel *tunnel = (struct ip_tunnel*)dev->priv; struct iphdr *iph = &tunnel->parms.iph; + + tunnel->dev = dev; + strcpy(tunnel->parms.name, dev->name); iph->version = 4; iph->protocol = IPPROTO_GRE; diff -Nur linux-2.5.OLD/net/ipv4/ipip.c linux-2.5/net/ipv4/ipip.c --- linux-2.5.OLD/net/ipv4/ipip.c Fri Jul 4 15:01:54 2003 +++ linux-2.5/net/ipv4/ipip.c Fri Jul 4 14:59:27 2003 @@ -805,7 +805,10 @@ tunnel = (struct ip_tunnel*)dev->priv; iph = &tunnel->parms.iph; + tunnel->dev = dev; + strcpy(tunnel->parms.name, dev->name); + memcpy(dev->dev_addr, &tunnel->parms.iph.saddr, 4); memcpy(dev->broadcast, &tunnel->parms.iph.daddr, 4); @@ -840,6 +843,9 @@ { struct ip_tunnel *tunnel = dev->priv; struct iphdr *iph = &tunnel->parms.iph; + + tunnel->dev = dev; + strcpy(tunnel->parms.name, dev->name); iph->version = 4; iph->protocol = IPPROTO_IPIP; diff -Nur linux-2.5.OLD/net/ipv6/sit.c linux-2.5/net/ipv6/sit.c --- linux-2.5.OLD/net/ipv6/sit.c Fri Jul 4 15:01:55 2003 +++ linux-2.5/net/ipv6/sit.c Fri Jul 4 14:59:27 2003 @@ -743,7 +743,10 @@ tunnel = (struct ip_tunnel*)dev->priv; iph = &tunnel->parms.iph; + tunnel->dev = dev; + strcpy(tunnel->parms.name, dev->name); + memcpy(dev->dev_addr, &tunnel->parms.iph.saddr, 4); memcpy(dev->broadcast, &tunnel->parms.iph.daddr, 4); @@ -779,6 +782,9 @@ { struct ip_tunnel *tunnel = dev->priv; struct iphdr *iph = &tunnel->parms.iph; + + tunnel->dev = dev; + strcpy(tunnel->parms.name, dev->name); iph->version = 4; iph->protocol = IPPROTO_IPV6; -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From vnuorval@tcs.hut.fi Fri Jul 4 17:16:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Jul 2003 17:16:43 -0700 (PDT) Received: from mail.tcs.hut.fi (mail.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h650GM2x014724 for ; Fri, 4 Jul 2003 17:16:23 -0700 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by mail.tcs.hut.fi (Postfix) with ESMTP id 00867800225; Sat, 5 Jul 2003 01:11:24 +0300 (EEST) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-5) with ESMTP id h64MBN5L017133; Sat, 5 Jul 2003 01:11:23 +0300 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-5) with ESMTP id h64MBN2L017129; Sat, 5 Jul 2003 01:11:23 +0300 Date: Sat, 5 Jul 2003 01:11:23 +0300 (EEST) From: Ville Nuorvala To: yoshfuji@linux-ipv6.org, Cc: netdev@oss.sgi.com, , , , Subject: [PATCH][1/3] IPV6: split CONFIG_IPV6_SUBTREES fix In-Reply-To: <20030531.000319.114704530.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-377318441-274968981-1057356683=:17083" X-archive-position: 3759 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---377318441-274968981-1057356683=:17083 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, now I've split and cleaned up the CONFIG_IPV6_SUBTREES patch I submitted earlier. The functionality should be equivalent with the previous version, but I'll still do some more bug tests on the code when I get back from my vacation on Monday :) The patches are done agains cset 1.1384 and are incremental. The first patch doesn't actually fix any bugs in the IPv6 code, but tweaks tcp_v6_connect() a bit and makes the actual subtrees fix for TCP a bit cleaner. Regards, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 ---377318441-274968981-1057356683=:17083 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="subtrees-1.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="subtrees-1.patch" ZGlmZiAtTnVyIC0tZXhjbHVkZT1SQ1MgLS1leGNsdWRlPUNWUyAtLWV4Y2x1 ZGU9U0NDUyAtLWV4Y2x1ZGU9Qml0S2VlcGVyIC0tZXhjbHVkZT1DaGFuZ2VT ZXQgbGludXgtMi41Lk9MRC9uZXQvaXB2Ni90Y3BfaXB2Ni5jIGxpbnV4LTIu NS9uZXQvaXB2Ni90Y3BfaXB2Ni5jDQotLS0gbGludXgtMi41Lk9MRC9uZXQv aXB2Ni90Y3BfaXB2Ni5jCVdlZCBKdWwgIDIgMTU6NDI6MDMgMjAwMw0KKysr IGxpbnV4LTIuNS9uZXQvaXB2Ni90Y3BfaXB2Ni5jCUZyaSBKdWwgIDQgMjM6 Mjg6MzIgMjAwMw0KQEAgLTU0NCw3ICs1NDQsNiBAQA0KIAlzdHJ1Y3QgaXB2 Nl9waW5mbyAqbnAgPSBpbmV0Nl9zayhzayk7DQogCXN0cnVjdCB0Y3Bfb3B0 ICp0cCA9IHRjcF9zayhzayk7DQogCXN0cnVjdCBpbjZfYWRkciAqc2FkZHIg PSBOVUxMOw0KLQlzdHJ1Y3QgaW42X2FkZHIgc2FkZHJfYnVmOw0KIAlzdHJ1 Y3QgZmxvd2kgZmw7DQogCXN0cnVjdCBkc3RfZW50cnkgKmRzdDsNCiAJaW50 IGFkZHJfdHlwZTsNCkBAIC02NzEsMjMgKzY3MCwyNCBAQA0KIAkJZ290byBm YWlsdXJlOw0KIAl9DQogDQotCWlwNl9kc3Rfc3RvcmUoc2ssIGRzdCwgTlVM TCk7DQotCXNrLT5za19yb3V0ZV9jYXBzID0gZHN0LT5kZXYtPmZlYXR1cmVz ICYNCi0JCQkgICAgfihORVRJRl9GX0lQX0NTVU0gfCBORVRJRl9GX1RTTyk7 DQotDQogCWlmIChzYWRkciA9PSBOVUxMKSB7DQotCQllcnIgPSBpcHY2X2dl dF9zYWRkcihkc3QsICZucC0+ZGFkZHIsICZzYWRkcl9idWYpOw0KLQkJaWYg KGVycikNCisJCWVyciA9IGlwdjZfZ2V0X3NhZGRyKGRzdCwgJm5wLT5kYWRk ciwgJmZsLmZsNl9zcmMpOw0KKwkJaWYgKGVycikgew0KKwkJCWRzdF9yZWxl YXNlKGRzdCk7DQogCQkJZ290byBmYWlsdXJlOw0KLQ0KLQkJc2FkZHIgPSAm c2FkZHJfYnVmOw0KKwkJfQ0KKwkJc2FkZHIgPSAmZmwuZmw2X3NyYzsNCisJ CWlwdjZfYWRkcl9jb3B5KCZucC0+cmN2X3NhZGRyLCBzYWRkcik7DQogCX0N CiANCiAJLyogc2V0IHRoZSBzb3VyY2UgYWRkcmVzcyAqLw0KLQlpcHY2X2Fk ZHJfY29weSgmbnAtPnJjdl9zYWRkciwgc2FkZHIpOw0KIAlpcHY2X2FkZHJf Y29weSgmbnAtPnNhZGRyLCBzYWRkcik7DQogCWluZXQtPnJjdl9zYWRkciA9 IExPT1BCQUNLNF9JUFY2Ow0KIA0KKwlpcDZfZHN0X3N0b3JlKHNrLCBkc3Qs IE5VTEwpOw0KKwlzay0+c2tfcm91dGVfY2FwcyA9IGRzdC0+ZGV2LT5mZWF0 dXJlcyAmDQorCQkJICAgIH4oTkVUSUZfRl9JUF9DU1VNIHwgTkVUSUZfRl9U U08pOw0KKw0KIAl0cC0+ZXh0X2hlYWRlcl9sZW4gPSAwOw0KIAlpZiAobnAt Pm9wdCkNCiAJCXRwLT5leHRfaGVhZGVyX2xlbiA9IG5wLT5vcHQtPm9wdF9m bGVuICsgbnAtPm9wdC0+b3B0X25mbGVuOw0KQEAgLTcxNCw4ICs3MTQsOCBA QA0KIA0KIGxhdGVfZmFpbHVyZToNCiAJdGNwX3NldF9zdGF0ZShzaywgVENQ X0NMT1NFKTsNCi1mYWlsdXJlOg0KIAlfX3NrX2RzdF9yZXNldChzayk7DQor ZmFpbHVyZToNCiAJaW5ldC0+ZHBvcnQgPSAwOw0KIAlzay0+c2tfcm91dGVf Y2FwcyA9IDA7DQogCXJldHVybiBlcnI7DQo= ---377318441-274968981-1057356683=:17083-- From vnuorval@tcs.hut.fi Fri Jul 4 17:33:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Jul 2003 17:33:24 -0700 (PDT) Received: from mail.tcs.hut.fi (mail.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h650X32x015088 for ; Fri, 4 Jul 2003 17:33:03 -0700 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by mail.tcs.hut.fi (Postfix) with ESMTP id CC7E1800226; Sat, 5 Jul 2003 01:25:20 +0300 (EEST) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-5) with ESMTP id h64MPK5L017160; Sat, 5 Jul 2003 01:25:20 +0300 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-5) with ESMTP id h64MPHnw017156; Sat, 5 Jul 2003 01:25:17 +0300 Date: Sat, 5 Jul 2003 01:25:17 +0300 (EEST) From: Ville Nuorvala To: yoshfuji@linux-ipv6.org, Cc: netdev@oss.sgi.com, , , , Subject: [PATCH][2/3] IPV6: split CONFIG_IPV6_SUBTREES fix In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-377318441-1491903089-1057357517=:17083" X-archive-position: 3761 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---377318441-1491903089-1057357517=:17083 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, the second patch fixes the bugs with CONFIG_IPV6_SUBTREES so it doesn't crash the kernel anymore. The route lookups in the IPv6 code have also been changed to better take the source address into account. Regards, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 ---377318441-1491903089-1057357517=:17083 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="subtrees-2.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="subtrees-2.patch" ZGlmZiAtTnVyIC0tZXhjbHVkZT1SQ1MgLS1leGNsdWRlPUNWUyAtLWV4Y2x1 ZGU9U0NDUyAtLWV4Y2x1ZGU9Qml0S2VlcGVyIC0tZXhjbHVkZT1DaGFuZ2VT ZXQgbGludXgtMi41Lk9MRC9pbmNsdWRlL2xpbnV4L2lwdjYuaCBsaW51eC0y LjUvaW5jbHVkZS9saW51eC9pcHY2LmgNCi0tLSBsaW51eC0yLjUuT0xEL2lu Y2x1ZGUvbGludXgvaXB2Ni5oCU1vbiBKdW4gMzAgMjA6MzY6MDAgMjAwMw0K KysrIGxpbnV4LTIuNS9pbmNsdWRlL2xpbnV4L2lwdjYuaAlGcmkgSnVsICA0 IDIzOjMyOjE0IDIwMDMNCkBAIC0xNTAsNyArMTUwLDkgQEANCiAJc3RydWN0 IGluNl9hZGRyIAlyY3Zfc2FkZHI7DQogCXN0cnVjdCBpbjZfYWRkcgkJZGFk ZHI7DQogCXN0cnVjdCBpbjZfYWRkcgkJKmRhZGRyX2NhY2hlOw0KLQ0KKyNp ZmRlZiBDT05GSUdfSVBWNl9TVUJUUkVFUw0KKwlzdHJ1Y3QgaW42X2FkZHIJ CSpzYWRkcl9jYWNoZTsNCisjZW5kaWYNCiAJX191MzIJCQlmbG93X2xhYmVs Ow0KIAlfX3UzMgkJCWZyYWdfc2l6ZTsNCiAJaW50CQkJaG9wX2xpbWl0Ow0K ZGlmZiAtTnVyIC0tZXhjbHVkZT1SQ1MgLS1leGNsdWRlPUNWUyAtLWV4Y2x1 ZGU9U0NDUyAtLWV4Y2x1ZGU9Qml0S2VlcGVyIC0tZXhjbHVkZT1DaGFuZ2VT ZXQgbGludXgtMi41Lk9MRC9pbmNsdWRlL25ldC9pcDZfcm91dGUuaCBsaW51 eC0yLjUvaW5jbHVkZS9uZXQvaXA2X3JvdXRlLmgNCi0tLSBsaW51eC0yLjUu T0xEL2luY2x1ZGUvbmV0L2lwNl9yb3V0ZS5oCU1vbiBKdW4gMzAgMjA6MzY6 MDAgMjAwMw0KKysrIGxpbnV4LTIuNS9pbmNsdWRlL25ldC9pcDZfcm91dGUu aAlGcmkgSnVsICA0IDIzOjMyOjE0IDIwMDMNCkBAIC0xMDIsNyArMTAyLDgg QEANCiAgKi8NCiANCiBzdGF0aWMgaW5saW5lIHZvaWQgaXA2X2RzdF9zdG9y ZShzdHJ1Y3Qgc29jayAqc2ssIHN0cnVjdCBkc3RfZW50cnkgKmRzdCwNCi0J CQkJICAgICBzdHJ1Y3QgaW42X2FkZHIgKmRhZGRyKQ0KKwkJCQkgc3RydWN0 IGluNl9hZGRyICpkYWRkciwNCisJCQkJIHN0cnVjdCBpbjZfYWRkciAqc2Fk ZHIpDQogew0KIAlzdHJ1Y3QgaXB2Nl9waW5mbyAqbnAgPSBpbmV0Nl9zayhz ayk7DQogCXN0cnVjdCBydDZfaW5mbyAqcnQgPSAoc3RydWN0IHJ0Nl9pbmZv ICopIGRzdDsNCkBAIC0xMTAsNiArMTExLDkgQEANCiAJd3JpdGVfbG9jaygm c2stPnNrX2RzdF9sb2NrKTsNCiAJX19za19kc3Rfc2V0KHNrLCBkc3QpOw0K IAlucC0+ZGFkZHJfY2FjaGUgPSBkYWRkcjsNCisjaWZkZWYgQ09ORklHX0lQ VjZfU1VCVFJFRVMNCisJbnAtPnNhZGRyX2NhY2hlID0gc2FkZHI7DQorI2Vu ZGlmDQogCW5wLT5kc3RfY29va2llID0gcnQtPnJ0Nmlfbm9kZSA/IHJ0LT5y dDZpX25vZGUtPmZuX3Nlcm51bSA6IDA7DQogCXdyaXRlX3VubG9jaygmc2st PnNrX2RzdF9sb2NrKTsNCiB9DQpkaWZmIC1OdXIgLS1leGNsdWRlPVJDUyAt LWV4Y2x1ZGU9Q1ZTIC0tZXhjbHVkZT1TQ0NTIC0tZXhjbHVkZT1CaXRLZWVw ZXIgLS1leGNsdWRlPUNoYW5nZVNldCBsaW51eC0yLjUuT0xEL25ldC9pcHY2 L0tjb25maWcgbGludXgtMi41L25ldC9pcHY2L0tjb25maWcNCi0tLSBsaW51 eC0yLjUuT0xEL25ldC9pcHY2L0tjb25maWcJTW9uIEp1biAzMCAyMDozNjow MyAyMDAzDQorKysgbGludXgtMi41L25ldC9pcHY2L0tjb25maWcJRnJpIEp1 bCAgNCAyMzozMjoxNCAyMDAzDQpAQCAtNjMsNCArNjMsMTIgQEANCiANCiAJ ICBJZiB1bnN1cmUsIHNheSBOLg0KIA0KK2NvbmZpZyBJUFY2X1NVQlRSRUVT DQorCWJvb2wgIklQdjY6IFNvdXJjZSBhZGRyZXNzIHJvdXRpbmciDQorCWRl cGVuZHMgb24gSVBWNg0KKwktLS1oZWxwLS0tDQorCSAgU3VwcG9ydCBmb3Ig YWR2YW5jZWQgcm91dGluZyBieSBib3RoIHNvdXJjZSBhbmQgZGVzdGluYXRp b24gYWRkcmVzcy4NCisNCisJICBJZiB1bnN1cmUsIHNheSBOLg0KKw0KIHNv dXJjZSAibmV0L2lwdjYvbmV0ZmlsdGVyL0tjb25maWciDQpkaWZmIC1OdXIg LS1leGNsdWRlPVJDUyAtLWV4Y2x1ZGU9Q1ZTIC0tZXhjbHVkZT1TQ0NTIC0t ZXhjbHVkZT1CaXRLZWVwZXIgLS1leGNsdWRlPUNoYW5nZVNldCBsaW51eC0y LjUuT0xEL25ldC9pcHY2L2lwNl9maWIuYyBsaW51eC0yLjUvbmV0L2lwdjYv aXA2X2ZpYi5jDQotLS0gbGludXgtMi41Lk9MRC9uZXQvaXB2Ni9pcDZfZmli LmMJTW9uIEp1biAzMCAyMDozNjowMyAyMDAzDQorKysgbGludXgtMi41L25l dC9pcHY2L2lwNl9maWIuYwlGcmkgSnVsICA0IDIzOjMyOjE0IDIwMDMNCkBA IC0xOCw2ICsxOCw3IEBADQogICogCVl1amkgU0VLSVlBIEBVU0FHSToJU3Vw cG9ydCBkZWZhdWx0IHJvdXRlIG9uIHJvdXRlciBub2RlOw0KICAqIAkJCQly ZW1vdmUgaXA2X251bGxfZW50cnkgZnJvbSB0aGUgdG9wIG9mDQogICogCQkJ CXJvdXRpbmcgdGFibGUuDQorICogCVZpbGxlIE51b3J2YWxhOgkJRml4ZWQg cm91dGluZyBzdWJ0cmVlcy4NCiAgKi8NCiAjaW5jbHVkZSA8bGludXgvY29u ZmlnLmg+DQogI2luY2x1ZGUgPGxpbnV4L2Vycm5vLmg+DQpAQCAtNDk2LDYg KzQ5Nyw4IEBADQogCQltb2RfdGltZXIoJmlwNl9maWJfdGltZXIsIGppZmZp ZXMgKyBpcDZfcnRfZ2NfaW50ZXJ2YWwpOw0KIH0NCiANCitzdGF0aWMgc3Ry dWN0IHJ0Nl9pbmZvICogZmliNl9maW5kX3ByZWZpeChzdHJ1Y3QgZmliNl9u b2RlICpmbik7DQorDQogLyoNCiAgKglBZGQgcm91dGluZyBpbmZvcm1hdGlv biB0byB0aGUgcm91dGluZyB0cmVlLg0KICAqCTxkZXN0aW5hdGlvbiBhZGRy Pi88c291cmNlIGFkZHI+DQpAQCAtNTA2LDYgKzUwOSw5IEBADQogew0KIAlz dHJ1Y3QgZmliNl9ub2RlICpmbjsNCiAJaW50IGVyciA9IC1FTk9NRU07DQor I2lmZGVmIENPTkZJR19JUFY2X1NVQlRSRUVTDQorCXN0cnVjdCBmaWI2X25v ZGUgKnBuID0gTlVMTDsNCisjZW5kaWYNCiANCiAJZm4gPSBmaWI2X2FkZF8x KHJvb3QsICZydC0+cnQ2aV9kc3QuYWRkciwgc2l6ZW9mKHN0cnVjdCBpbjZf YWRkciksDQogCQkJcnQtPnJ0NmlfZHN0LnBsZW4sICh1OCopICZydC0+cnQ2 aV9kc3QgLSAodTgqKSBydCk7DQpAQCAtNTU4LDEwICs1NjQsNiBAQA0KIAkJ CS8qIE5vdyBsaW5rIG5ldyBzdWJ0cmVlIHRvIG1haW4gdHJlZSAqLw0KIAkJ CXNmbi0+cGFyZW50ID0gZm47DQogCQkJZm4tPnN1YnRyZWUgPSBzZm47DQot CQkJaWYgKGZuLT5sZWFmID09IE5VTEwpIHsNCi0JCQkJZm4tPmxlYWYgPSBy dDsNCi0JCQkJYXRvbWljX2luYygmcnQtPnJ0NmlfcmVmKTsNCi0JCQl9DQog CQl9IGVsc2Ugew0KIAkJCXNuID0gZmliNl9hZGRfMShmbi0+c3VidHJlZSwg JnJ0LT5ydDZpX3NyYy5hZGRyLA0KIAkJCQkJc2l6ZW9mKHN0cnVjdCBpbjZf YWRkciksIHJ0LT5ydDZpX3NyYy5wbGVuLA0KQEAgLTU3MSw2ICs1NzMsMTMg QEANCiAJCQkJZ290byBzdF9mYWlsdXJlOw0KIAkJfQ0KIA0KKwkJLyogZmli Nl9hZGRfMSBtaWdodCBoYXZlIGNsZWFyZWQgdGhlIG9sZCBsZWFmIHBvaW50 ZXIgKi8NCisJCWlmIChmbi0+bGVhZiA9PSBOVUxMKSB7DQorCQkJZm4tPmxl YWYgPSBydDsNCisJCSAgYXRvbWljX2luYygmcnQtPnJ0NmlfcmVmKTsNCisJ CX0NCisNCisJCXBuID0gZm47DQogCQlmbiA9IHNuOw0KIAl9DQogI2VuZGlm DQpAQCAtNTg0LDggKzU5MywyNCBAQA0KIAl9DQogDQogb3V0Og0KLQlpZiAo ZXJyKQ0KKwlpZiAoZXJyKSB7DQorI2lmZGVmIENPTkZJR19JUFY2X1NVQlRS RUVTDQorCQkvKiBJZiBmaWI2X2FkZF8xIGhhcyBjbGVhcmVkIHRoZSBvbGQg bGVhZiBwb2ludGVyIGluIHRoZSANCisJCSAgIHN1cGVyLXRyZWUgbGVhZiBu b2RlIHdlIGhhdmUgdG8gZmluZCBhIG5ldyBvbmUgZm9yIGl0LiAqLw0KKwkJ DQorCQlpZiAocG4gJiYgIShwbi0+Zm5fZmxhZ3MgJiBSVE5fUlRJTkZPKSkg ew0KKwkJCXBuLT5sZWFmID0gZmliNl9maW5kX3ByZWZpeChwbik7DQorI2lm IFJUNl9ERUJVRyA+PSAyDQorCQkJaWYgKCFwbi0+bGVhZikgew0KKwkJCQlC VUdfVFJBUChwbi0+bGVhZik7DQorCQkJCXBuLT5sZWFmID0gJmlwNl9udWxs X2VudHJ5Ow0KKwkJCX0NCisjZW5kaWYNCisJCQlhdG9taWNfaW5jKCZwbi0+ bGVhZi0+cnQ2aV9yZWYpOw0KKwkJfQ0KKyNlbmRpZg0KIAkJZHN0X2ZyZWUo JnJ0LT51LmRzdCk7DQorCX0NCiAJcmV0dXJuIGVycjsNCiANCiAjaWZkZWYg Q09ORklHX0lQVjZfU1VCVFJFRVMNCkBAIC02MzcsMzIgKzY2MiwzMSBAQA0K IAkJYnJlYWs7DQogCX0NCiANCi0Jd2hpbGUgKChmbi0+Zm5fZmxhZ3MgJiBS VE5fUk9PVCkgPT0gMCkgew0KKwlmb3IgKDs7KSB7DQorCQlpZiAoU1VCVFJF RShmbikgfHwgZm4tPmZuX2ZsYWdzICYgUlROX1JUSU5GTykgew0KKwkJCXN0 cnVjdCBydDZrZXkgKmtleTsNCisJCQlrZXkgPSAoc3RydWN0IHJ0NmtleSAq KSAoKHU4ICopIGZuLT5sZWFmICsgYXJncy0+b2Zmc2V0KTsNCisJCQkNCisJ CQlpZiAoYWRkcl9tYXRjaCgma2V5LT5hZGRyLCBhcmdzLT5hZGRyLCBrZXkt PnBsZW4pKSB7DQogI2lmZGVmIENPTkZJR19JUFY2X1NVQlRSRUVTDQotCQlp ZiAoZm4tPnN1YnRyZWUpIHsNCi0JCQlzdHJ1Y3QgZmliNl9ub2RlICpzdDsN Ci0JCQlzdHJ1Y3QgbG9va3VwX2FyZ3MgKm5hcmc7DQotDQotCQkJbmFyZyA9 IGFyZ3MgKyAxOw0KLQ0KLQkJCWlmIChuYXJnLT5hZGRyKSB7DQotCQkJCXN0 ID0gZmliNl9sb29rdXBfMShmbi0+c3VidHJlZSwgbmFyZyk7DQotDQotCQkJ CWlmIChzdCAmJiAhKHN0LT5mbl9mbGFncyAmIFJUTl9ST09UKSkNCi0JCQkJ CXJldHVybiBzdDsNCi0JCQl9DQotCQl9DQorCQkJCWlmIChmbi0+c3VidHJl ZSkgew0KKwkJCQkJc3RydWN0IGxvb2t1cF9hcmdzICpuYXJnID0gYXJncyAr IDE7DQorCQkJCQkNCisJCQkJCWlmIChuYXJnLT5hZGRyKSB7DQorCQkJCQkJ c3RydWN0IGZpYjZfbm9kZSAqc3Q7DQorCQkJCQkJc3QgPSBmaWI2X2xvb2t1 cF8xKGZuLT5zdWJ0cmVlLCBuYXJnKTsNCisJCQkJCQkNCisJCQkJCQlpZiAo c3QpDQorCQkJCQkJCXJldHVybiBzdDsNCisJCQkJCX0NCisJCQkJfQ0KICNl bmRpZg0KLQ0KLQkJaWYgKGZuLT5mbl9mbGFncyAmIFJUTl9SVElORk8pIHsN Ci0JCQlzdHJ1Y3QgcnQ2a2V5ICprZXk7DQotDQotCQkJa2V5ID0gKHN0cnVj dCBydDZrZXkgKikgKCh1OCAqKSBmbi0+bGVhZiArDQotCQkJCQkJIGFyZ3Mt Pm9mZnNldCk7DQotDQotCQkJaWYgKGFkZHJfbWF0Y2goJmtleS0+YWRkciwg YXJncy0+YWRkciwga2V5LT5wbGVuKSkNCi0JCQkJcmV0dXJuIGZuOw0KKwkJ CQlpZiAoZm4tPmZuX2ZsYWdzICYgUlROX1JUSU5GTykNCisJCQkJCXJldHVy biBmbjsNCisJCQl9DQogCQl9DQorCQlpZiAoZm4tPmZuX2ZsYWdzICYgUlRO X1JPT1QpDQorCQkJYnJlYWs7DQogDQogCQlmbiA9IGZuLT5wYXJlbnQ7DQog CX0NCkBAIC03NDEsMTIgKzc2NSwxMiBAQA0KIA0KICNpZmRlZiBDT05GSUdf SVBWNl9TVUJUUkVFUw0KIAlpZiAoc3JjX2xlbikgew0KLQkJQlVHX1RSQVAo c2FkZHIhPU5VTEwpOw0KLQkJaWYgKGZuID09IE5VTEwpDQotCQkJZm4gPSBm bi0+c3VidHJlZTsNCi0JCWlmIChmbikNCi0JCQlmbiA9IGZpYjZfbG9jYXRl XzEoZm4sIHNhZGRyLCBzcmNfbGVuLA0KKwkJQlVHX1RSQVAoc2FkZHIgIT0g TlVMTCk7DQorCQlpZiAoZm4gJiYgZm4tPnN1YnRyZWUpDQorCQkJZm4gPSBm aWI2X2xvY2F0ZV8xKGZuLT5zdWJ0cmVlLCBzYWRkciwgc3JjX2xlbiwNCiAJ CQkJCSAgICh1OCopICZydC0+cnQ2aV9zcmMgLSAodTgqKSBydCk7DQorCQll bHNlDQorCQkJcmV0dXJuIE5VTEw7DQogCX0NCiAjZW5kaWYNCiANCmRpZmYg LU51ciAtLWV4Y2x1ZGU9UkNTIC0tZXhjbHVkZT1DVlMgLS1leGNsdWRlPVND Q1MgLS1leGNsdWRlPUJpdEtlZXBlciAtLWV4Y2x1ZGU9Q2hhbmdlU2V0IGxp bnV4LTIuNS5PTEQvbmV0L2lwdjYvaXA2X291dHB1dC5jIGxpbnV4LTIuNS9u ZXQvaXB2Ni9pcDZfb3V0cHV0LmMNCi0tLSBsaW51eC0yLjUuT0xEL25ldC9p cHY2L2lwNl9vdXRwdXQuYwlXZWQgSnVsICAyIDE1OjQyOjAzIDIwMDMNCisr KyBsaW51eC0yLjUvbmV0L2lwdjYvaXA2X291dHB1dC5jCUZyaSBKdWwgIDQg MjM6MzI6MTQgMjAwMw0KQEAgLTUzMSw2ICs1MzEsNyBAQA0KIAlzdHJ1Y3Qg aXB2Nl9waW5mbyAqbnAgPSBpbmV0Nl9zayhzayk7DQogCXN0cnVjdCBpbjZf YWRkciBmaW5hbF9kc3RfYnVmLCAqZmluYWxfZHN0ID0gTlVMTDsNCiAJc3Ry dWN0IGRzdF9lbnRyeSAqZHN0Ow0KKwlzdHJ1Y3QgcnQ2X2luZm8gKnJ0Ow0K IAlpbnQgZXJyID0gMDsNCiAJdW5zaWduZWQgaW50IHBrdGxlbmd0aCwganVt Ym9sZW4sIG10dTsNCiANCkBAIC01NDYsMTEgKzU0NywxMSBAQA0KIA0KIAlk c3QgPSBfX3NrX2RzdF9jaGVjayhzaywgbnAtPmRzdF9jb29raWUpOw0KIAlp ZiAoZHN0KSB7DQotCQlzdHJ1Y3QgcnQ2X2luZm8gKnJ0ID0gKHN0cnVjdCBy dDZfaW5mbyopZHN0Ow0KKwkJcnQgPSAoc3RydWN0IHJ0Nl9pbmZvKilkc3Q7 DQogDQogCQkJLyogWWVzLCBjaGVja2luZyByb3V0ZSB2YWxpZGl0eSBpbiBu b3QgY29ubmVjdGVkDQogCQkJICAgY2FzZSBpcyBub3QgdmVyeSBzaW1wbGUu IFRha2UgaW50byBhY2NvdW50LA0KLQkJCSAgIHRoYXQgd2UgZG8gbm90IHN1 cHBvcnQgcm91dGluZyBieSBzb3VyY2UsIFRPUywNCisJCQkgICB0aGF0IHdl IGRvIG5vdCBzdXBwb3J0IHJvdXRpbmcgYnkgVE9TLA0KIAkJCSAgIGFuZCBN U0dfRE9OVFJPVVRFIAkJLS1BTksgKDk4MDcyNikNCiANCiAJCQkgICAxLiBJ ZiByb3V0ZSB3YXMgaG9zdCByb3V0ZSwgY2hlY2sgdGhhdA0KQEAgLTU3MCw2 ICs1NzEsMTMgQEANCiAJCSAgICAgIGlwdjZfYWRkcl9jbXAoJmZsLT5mbDZf ZHN0LCAmcnQtPnJ0NmlfZHN0LmFkZHIpKQ0KIAkJICAgICAmJiAobnAtPmRh ZGRyX2NhY2hlID09IE5VTEwgfHwNCiAJCQkgaXB2Nl9hZGRyX2NtcCgmZmwt PmZsNl9kc3QsIG5wLT5kYWRkcl9jYWNoZSkpKQ0KKyNpZmRlZiBDT05GSUdf SVBWNl9TVUJUUkVFUw0KKwkJICAgIHx8ICghaXB2Nl9hZGRyX2FueSgmZmwt PmZsNl9zcmMpDQorCQkJJiYgKHJ0LT5ydDZpX3NyYy5wbGVuICE9IDEyOCB8 fA0KKwkJCSAgICBpcHY2X2FkZHJfY21wKCZmbC0+Zmw2X3NyYywgJnJ0LT5y dDZpX3NyYy5hZGRyKSkNCisJCQkmJiAobnAtPnNhZGRyX2NhY2hlID09IE5V TEwgfHwNCisJCQkgICAgaXB2Nl9hZGRyX2NtcCgmZmwtPmZsNl9zcmMsIG5w LT5zYWRkcl9jYWNoZSkpKQ0KKyNlbmRpZg0KIAkJICAgIHx8IChmbC0+b2lm ICYmIGZsLT5vaWYgIT0gZHN0LT5kZXYtPmlmaW5kZXgpKSB7DQogCQkJZHN0 ID0gTlVMTDsNCiAJCX0gZWxzZQ0KQEAgLTU5Niw2ICs2MDQsMjAgQEANCiAJ CQlnb3RvIG91dDsNCiAJCX0NCiAJfQ0KKyNpZmRlZiBDT05GSUdfSVBWNl9T VUJUUkVFUw0KKwlydCA9IChzdHJ1Y3QgcnQ2X2luZm8qKWRzdDsNCisJaWYg KGlwdjZfYWRkcl9jbXAoJmZsLT5mbDZfc3JjLCAmbnAtPnNhZGRyKSAmJiAN CisJICAgIChydC0+cnQ2aV9zcmMucGxlbiAhPSAxMjggfHwgDQorCSAgICAg aXB2Nl9hZGRyX2NtcCgmZmwtPmZsNl9zcmMsICZydC0+cnQ2aV9zcmMuYWRk cikpKSB7DQorCQlkc3RfcmVsZWFzZShkc3QpOw0KKwkJZHN0ID0gaXA2X3Jv dXRlX291dHB1dChzaywgZmwpOw0KKwkJaWYgKGRzdC0+ZXJyb3IpIHsNCisJ CQlJUDZfSU5DX1NUQVRTKElwNk91dE5vUm91dGVzKTsNCisJCQlkc3RfcmVs ZWFzZShkc3QpOw0KKwkJCXJldHVybiAtRU5FVFVOUkVBQ0g7DQorCQl9DQor CX0NCisjZW5kaWYNCiAJcGt0bGVuZ3RoID0gbGVuZ3RoOw0KIA0KICAgICAg ICAgaWYgKGRzdCkgew0KQEAgLTcxOSw3ICs3NDEsOSBAQA0KIG91dDoNCiAJ aXA2X2RzdF9zdG9yZShzaywgZHN0LA0KIAkJICAgICAgIWlwdjZfYWRkcl9j bXAoJmZsLT5mbDZfZHN0LCAmbnAtPmRhZGRyKSA/DQotCQkgICAgICAmbnAt PmRhZGRyIDogTlVMTCk7DQorCQkgICAgICAmbnAtPmRhZGRyIDogTlVMTCwN CisJCSAgICAgICFpcHY2X2FkZHJfY21wKCZmbC0+Zmw2X3NyYywgJm5wLT5z YWRkcikgPw0KKwkJICAgICAgJm5wLT5zYWRkciA6IE5VTEwpOw0KIAlpZiAo ZXJyID4gMCkNCiAJCWVyciA9IG5wLT5yZWN2ZXJyID8gbmV0X3htaXRfZXJy bm8oZXJyKSA6IDA7DQogCXJldHVybiBlcnI7DQpAQCAtMTE0NCwxNSArMTE2 OCwxNiBAQA0KIGludCBpcDZfZHN0X2xvb2t1cChzdHJ1Y3Qgc29jayAqc2ss IHN0cnVjdCBkc3RfZW50cnkgKipkc3QsIHN0cnVjdCBmbG93aSAqZmwpDQog ew0KIAlzdHJ1Y3QgaXB2Nl9waW5mbyAqbnAgPSBpbmV0Nl9zayhzayk7DQor CXN0cnVjdCBydDZfaW5mbyAqcnQ7DQogCWludCBlcnIgPSAwOw0KIA0KIAkq ZHN0ID0gX19za19kc3RfY2hlY2soc2ssIG5wLT5kc3RfY29va2llKTsNCiAJ aWYgKCpkc3QpIHsNCi0JCXN0cnVjdCBydDZfaW5mbyAqcnQgPSAoc3RydWN0 IHJ0Nl9pbmZvKikqZHN0Ow0KKwkJcnQgPSAoc3RydWN0IHJ0Nl9pbmZvKikq ZHN0Ow0KIA0KIAkJCS8qIFllcywgY2hlY2tpbmcgcm91dGUgdmFsaWRpdHkg aW4gbm90IGNvbm5lY3RlZA0KIAkJCSAgIGNhc2UgaXMgbm90IHZlcnkgc2lt cGxlLiBUYWtlIGludG8gYWNjb3VudCwNCi0JCQkgICB0aGF0IHdlIGRvIG5v dCBzdXBwb3J0IHJvdXRpbmcgYnkgc291cmNlLCBUT1MsDQorCQkJICAgdGhh dCB3ZSBkbyBub3Qgc3VwcG9ydCByb3V0aW5nIGJ5IFRPUywNCiAJCQkgICBh bmQgTVNHX0RPTlRST1VURSAJCS0tQU5LICg5ODA3MjYpDQogDQogCQkJICAg MS4gSWYgcm91dGUgd2FzIGhvc3Qgcm91dGUsIGNoZWNrIHRoYXQNCkBAIC0x MTcyLDYgKzExOTcsMTMgQEANCiAJCSAgICAgIGlwdjZfYWRkcl9jbXAoJmZs LT5mbDZfZHN0LCAmcnQtPnJ0NmlfZHN0LmFkZHIpKQ0KIAkJICAgICAmJiAo bnAtPmRhZGRyX2NhY2hlID09IE5VTEwgfHwNCiAJCQkgaXB2Nl9hZGRyX2Nt cCgmZmwtPmZsNl9kc3QsIG5wLT5kYWRkcl9jYWNoZSkpKQ0KKyNpZmRlZiBD T05GSUdfSVBWNl9TVUJUUkVFUw0KKwkJICAgIHx8ICghaXB2Nl9hZGRyX2Fu eSgmZmwtPmZsNl9zcmMpDQorCQkJJiYgKHJ0LT5ydDZpX3NyYy5wbGVuICE9 IDEyOCB8fA0KKwkJCSAgICBpcHY2X2FkZHJfY21wKCZmbC0+Zmw2X3NyYywg JnJ0LT5ydDZpX3NyYy5hZGRyKSkNCisJCQkmJiAobnAtPnNhZGRyX2NhY2hl ID09IE5VTEwgfHwNCisJCQkgICAgaXB2Nl9hZGRyX2NtcCgmZmwtPmZsNl9z cmMsIG5wLT5zYWRkcl9jYWNoZSkpKQ0KKyNlbmRpZg0KIAkJICAgIHx8IChm bC0+b2lmICYmIGZsLT5vaWYgIT0gKCpkc3QpLT5kZXYtPmlmaW5kZXgpKSB7 DQogCQkJKmRzdCA9IE5VTEw7DQogCQl9IGVsc2UNCkBAIC0xMTk4LDcgKzEy MzAsMjAgQEANCiAJCQlyZXR1cm4gZXJyOw0KIAkJfQ0KIAl9DQotDQorI2lm ZGVmIENPTkZJR19JUFY2X1NVQlRSRUVTDQorCXJ0ID0gKHN0cnVjdCBydDZf aW5mbyopKmRzdDsNCisJaWYgKGlwdjZfYWRkcl9jbXAoJmZsLT5mbDZfc3Jj LCAmbnAtPnNhZGRyKSAmJiANCisJICAgIChydC0+cnQ2aV9zcmMucGxlbiAh PSAxMjggfHwgDQorCSAgICAgaXB2Nl9hZGRyX2NtcCgmZmwtPmZsNl9zcmMs ICZydC0+cnQ2aV9zcmMuYWRkcikpKSB7DQorCQlkc3RfcmVsZWFzZSgqZHN0 KTsNCisJCSpkc3QgPSBpcDZfcm91dGVfb3V0cHV0KHNrLCBmbCk7DQorCQlp ZiAoKCpkc3QpLT5lcnJvcikgew0KKwkJCUlQNl9JTkNfU1RBVFMoSXA2T3V0 Tm9Sb3V0ZXMpOw0KKwkJCWRzdF9yZWxlYXNlKCpkc3QpOw0KKwkJCXJldHVy biAtRU5FVFVOUkVBQ0g7DQorCQl9DQorCX0NCisjZW5kaWYNCiAgICAgICAg IGlmICgqZHN0KSB7DQogCQlpZiAoKGVyciA9IHhmcm1fbG9va3VwKGRzdCwg ZmwsIHNrLCAwKSkgPCAwKSB7DQogCQkJZHN0X3JlbGVhc2UoKmRzdCk7CQ0K ZGlmZiAtTnVyIC0tZXhjbHVkZT1SQ1MgLS1leGNsdWRlPUNWUyAtLWV4Y2x1 ZGU9U0NDUyAtLWV4Y2x1ZGU9Qml0S2VlcGVyIC0tZXhjbHVkZT1DaGFuZ2VT ZXQgbGludXgtMi41Lk9MRC9uZXQvaXB2Ni9pcDZfdHVubmVsLmMgbGludXgt Mi41L25ldC9pcHY2L2lwNl90dW5uZWwuYw0KLS0tIGxpbnV4LTIuNS5PTEQv bmV0L2lwdjYvaXA2X3R1bm5lbC5jCUZyaSBKdWwgIDQgMTQ6NDg6MjEgMjAw Mw0KKysrIGxpbnV4LTIuNS9uZXQvaXB2Ni9pcDZfdHVubmVsLmMJRnJpIEp1 bCAgNCAyMzozMjozNCAyMDAzDQpAQCAtNzU3LDYgKzc1NywxMCBAQA0KIAlp ZiAoZHN0KSB7DQogCQlpZiAobnAtPmRhZGRyX2NhY2hlID09IE5VTEwgfHwN CiAJCSAgICBpcHY2X2FkZHJfY21wKCZmbC5mbDZfZHN0LCBucC0+ZGFkZHJf Y2FjaGUpIHx8DQorI2lmZGVmIENPTkZJR19JUFY2X1NVQlRSRUVTDQorCQkg ICAgbnAtPnNhZGRyX2NhY2hlID09IE5VTEwgfHwNCisJCSAgICBpcHY2X2Fk ZHJfY21wKCZmbC5mbDZfc3JjLCBucC0+c2FkZHJfY2FjaGUpIHx8DQorI2Vu ZGlmDQogCQkgICAgKGZsLm9pZiAmJiBmbC5vaWYgIT0gZHN0LT5kZXYtPmlm aW5kZXgpKSB7DQogCQkJZHN0ID0gTlVMTDsNCiAJCX0NCkBAIC04MTYsNyAr ODIwLDcgQEANCiAJCXNvY2tfa2ZyZWVfcyhzaywgb3B0LCBvcHQtPnRvdF9s ZW4pOw0KIA0KIAlmbDZfc29ja19yZWxlYXNlKGZsX2xibCk7DQotCWlwNl9k c3Rfc3RvcmUoc2ssIGRzdCwgJm5wLT5kYWRkcik7DQorCWlwNl9kc3Rfc3Rv cmUoc2ssIGRzdCwgJm5wLT5kYWRkciwgJm5wLT5zYWRkcik7DQogCWlwNl94 bWl0X3VubG9jaygpOw0KIAlrZnJlZV9za2Ioc2tiKTsNCiAJdC0+cmVjdXJz aW9uLS07DQpkaWZmIC1OdXIgLS1leGNsdWRlPVJDUyAtLWV4Y2x1ZGU9Q1ZT IC0tZXhjbHVkZT1TQ0NTIC0tZXhjbHVkZT1CaXRLZWVwZXIgLS1leGNsdWRl PUNoYW5nZVNldCBsaW51eC0yLjUuT0xEL25ldC9pcHY2L3Jhdy5jIGxpbnV4 LTIuNS9uZXQvaXB2Ni9yYXcuYw0KLS0tIGxpbnV4LTIuNS5PTEQvbmV0L2lw djYvcmF3LmMJV2VkIEp1bCAgMiAxNTo0MjowMyAyMDAzDQorKysgbGludXgt Mi41L25ldC9pcHY2L3Jhdy5jCUZyaSBKdWwgIDQgMjM6MzI6MzQgMjAwMw0K QEAgLTY5NCw3ICs2OTQsOSBAQA0KIGRvbmU6DQogCWlwNl9kc3Rfc3RvcmUo c2ssIGRzdCwNCiAJCSAgICAgICFpcHY2X2FkZHJfY21wKCZmbC5mbDZfZHN0 LCAmbnAtPmRhZGRyKSA/DQotCQkgICAgICAmbnAtPmRhZGRyIDogTlVMTCk7 DQorCQkgICAgICAmbnAtPmRhZGRyIDogTlVMTCwNCisJCSAgICAgICFpcHY2 X2FkZHJfY21wKCZmbC5mbDZfc3JjLCAmbnAtPnNhZGRyKSA/DQorCQkgICAg ICAmbnAtPnNhZGRyIDogTlVMTCk7DQogCWlmIChlcnIgPiAwKQ0KIAkJZXJy ID0gbnAtPnJlY3ZlcnIgPyBuZXRfeG1pdF9lcnJubyhlcnIpIDogMDsNCiAN CmRpZmYgLU51ciAtLWV4Y2x1ZGU9UkNTIC0tZXhjbHVkZT1DVlMgLS1leGNs dWRlPVNDQ1MgLS1leGNsdWRlPUJpdEtlZXBlciAtLWV4Y2x1ZGU9Q2hhbmdl U2V0IGxpbnV4LTIuNS5PTEQvbmV0L2lwdjYvcm91dGUuYyBsaW51eC0yLjUv bmV0L2lwdjYvcm91dGUuYw0KLS0tIGxpbnV4LTIuNS5PTEQvbmV0L2lwdjYv cm91dGUuYwlNb24gSnVuIDMwIDIwOjM2OjAzIDIwMDMNCisrKyBsaW51eC0y LjUvbmV0L2lwdjYvcm91dGUuYwlTYXQgSnVsICA1IDAwOjIzOjQ0IDIwMDMN CkBAIC0zNjMsMTIgKzM2Myw4IEBADQogCQlydC0+dS5kc3QuZmxhZ3MgfD0g RFNUX0hPU1Q7DQogDQogI2lmZGVmIENPTkZJR19JUFY2X1NVQlRSRUVTDQot CQlpZiAocnQtPnJ0Nmlfc3JjLnBsZW4gJiYgc2FkZHIpIHsNCi0JCQlpcHY2 X2FkZHJfY29weSgmcnQtPnJ0Nmlfc3JjLmFkZHIsIHNhZGRyKTsNCi0JCQly dC0+cnQ2aV9zcmMucGxlbiA9IDEyODsNCi0JCX0NCisJCXJ0LT5ydDZpX3Ny Yy5wbGVuID0gb3J0LT5ydDZpX3NyYy5wbGVuOw0KICNlbmRpZg0KLQ0KIAkJ cnQtPnJ0NmlfbmV4dGhvcCA9IG5kaXNjX2dldF9uZWlnaChydC0+cnQ2aV9k ZXYsICZydC0+cnQ2aV9nYXRld2F5KTsNCiANCiAJCWRzdF9ob2xkKCZydC0+ dS5kc3QpOw0KQEAgLTczNCw3ICs3MzAsNyBAQA0KIAkJCWlmICghKGd3YV90 eXBlJklQVjZfQUREUl9VTklDQVNUKSkNCiAJCQkJZ290byBvdXQ7DQogDQot CQkJZ3J0ID0gcnQ2X2xvb2t1cChnd19hZGRyLCBOVUxMLCBydG1zZy0+cnRt c2dfaWZpbmRleCwgMSk7DQorCQkJZ3J0ID0gcnQ2X2xvb2t1cChnd19hZGRy LCAmcnRtc2ctPnJ0bXNnX3NyYywgcnRtc2ctPnJ0bXNnX2lmaW5kZXgsIDEp Ow0KIA0KIAkJCWVyciA9IC1FSE9TVFVOUkVBQ0g7DQogCQkJaWYgKGdydCA9 PSBOVUxMKQ0KQEAgLTg3OSw3ICs4NzUsNyBAQA0KIAlzdHJ1Y3QgcnQ2X2lu Zm8gKnJ0LCAqbnJ0Ow0KIA0KIAkvKiBMb2NhdGUgb2xkIHJvdXRlIHRvIHRo aXMgZGVzdGluYXRpb24uICovDQotCXJ0ID0gcnQ2X2xvb2t1cChkZXN0LCBO VUxMLCBuZWlnaC0+ZGV2LT5pZmluZGV4LCAxKTsNCisJcnQgPSBydDZfbG9v a3VwKGRlc3QsIHNhZGRyLCBuZWlnaC0+ZGV2LT5pZmluZGV4LCAxKTsNCiAN CiAJaWYgKHJ0ID09IE5VTEwpDQogCQlyZXR1cm47DQpAQCAtMTA0NCw2ICsx MDQwLDkgQEANCiAJCW5ydCA9IGlwNl9ydF9jb3B5KHJ0KTsNCiAJCWlmIChu cnQgPT0gTlVMTCkNCiAJCQlnb3RvIG91dDsNCisjaWZkZWYgQ09ORklHX0lQ VjZfU1VCVFJFRVMNCisJCW5ydC0+cnQ2aV9zcmMucGxlbiA9IHJ0LT5ydDZp X3NyYy5wbGVuOw0KKyNlbmRpZg0KIAkJaXB2Nl9hZGRyX2NvcHkoJm5ydC0+ cnQ2aV9kc3QuYWRkciwgZGFkZHIpOw0KIAkJbnJ0LT5ydDZpX2RzdC5wbGVu ID0gMTI4Ow0KIAkJbnJ0LT51LmRzdC5mbGFncyB8PSBEU1RfSE9TVDsNCmRp ZmYgLU51ciAtLWV4Y2x1ZGU9UkNTIC0tZXhjbHVkZT1DVlMgLS1leGNsdWRl PVNDQ1MgLS1leGNsdWRlPUJpdEtlZXBlciAtLWV4Y2x1ZGU9Q2hhbmdlU2V0 IGxpbnV4LTIuNS5PTEQvbmV0L2lwdjYvdGNwX2lwdjYuYyBsaW51eC0yLjUv bmV0L2lwdjYvdGNwX2lwdjYuYw0KLS0tIGxpbnV4LTIuNS5PTEQvbmV0L2lw djYvdGNwX2lwdjYuYwlGcmkgSnVsICA0IDIzOjMxOjEzIDIwMDMNCisrKyBs aW51eC0yLjUvbmV0L2lwdjYvdGNwX2lwdjYuYwlGcmkgSnVsICA0IDIzOjMy OjM0IDIwMDMNCkBAIC02NzYsNiArNjc2LDE2IEBADQogCQkJZHN0X3JlbGVh c2UoZHN0KTsNCiAJCQlnb3RvIGZhaWx1cmU7DQogCQl9DQorI2lmZGVmIENP TkZJR19JUFY2X1NVQlRSRUVTDQorCQlkc3RfcmVsZWFzZShkc3QpOw0KKw0K KwkJZHN0ID0gaXA2X3JvdXRlX291dHB1dChzaywgJmZsKTsNCisNCisJCWlm ICgoZXJyID0gZHN0LT5lcnJvcikgIT0gMCkgew0KKwkJCWRzdF9yZWxlYXNl KGRzdCk7DQorCQkJZ290byBmYWlsdXJlOw0KKwkJfQ0KKyNlbmRpZg0KIAkJ c2FkZHIgPSAmZmwuZmw2X3NyYzsNCiAJCWlwdjZfYWRkcl9jb3B5KCZucC0+ cmN2X3NhZGRyLCBzYWRkcik7DQogCX0NCkBAIC02ODQsNyArNjk0LDcgQEAN CiAJaXB2Nl9hZGRyX2NvcHkoJm5wLT5zYWRkciwgc2FkZHIpOw0KIAlpbmV0 LT5yY3Zfc2FkZHIgPSBMT09QQkFDSzRfSVBWNjsNCiANCi0JaXA2X2RzdF9z dG9yZShzaywgZHN0LCBOVUxMKTsNCisJaXA2X2RzdF9zdG9yZShzaywgZHN0 LCBOVUxMLCBOVUxMKTsNCiAJc2stPnNrX3JvdXRlX2NhcHMgPSBkc3QtPmRl di0+ZmVhdHVyZXMgJg0KIAkJCSAgICB+KE5FVElGX0ZfSVBfQ1NVTSB8IE5F VElGX0ZfVFNPKTsNCiANCkBAIC0xMzQ1LDcgKzEzNTUsNyBAQA0KIAlhdG9t aWNfaW5jKCZpbmV0Nl9zb2NrX25yKTsNCiAjZW5kaWYNCiANCi0JaXA2X2Rz dF9zdG9yZShuZXdzaywgZHN0LCBOVUxMKTsNCisJaXA2X2RzdF9zdG9yZShu ZXdzaywgZHN0LCBOVUxMLCBOVUxMKTsNCiAJc2stPnNrX3JvdXRlX2NhcHMg PSBkc3QtPmRldi0+ZmVhdHVyZXMgJg0KIAkJCSAgICB+KE5FVElGX0ZfSVBf Q1NVTSB8IE5FVElGX0ZfVFNPKTsNCiANCkBAIC0xNzM3LDcgKzE3NDcsNyBA QA0KIAkJCXJldHVybiBlcnI7DQogCQl9DQogDQotCQlpcDZfZHN0X3N0b3Jl KHNrLCBkc3QsIE5VTEwpOw0KKwkJaXA2X2RzdF9zdG9yZShzaywgZHN0LCBO VUxMLCBOVUxMKTsNCiAJCXNrLT5za19yb3V0ZV9jYXBzID0gZHN0LT5kZXYt PmZlYXR1cmVzICYNCiAJCQkJICAgIH4oTkVUSUZfRl9JUF9DU1VNIHwgTkVU SUZfRl9UU08pOw0KIAl9DQpAQCAtMTc3OSw3ICsxNzg5LDcgQEANCiAJCQly ZXR1cm4gLXNrLT5za19lcnJfc29mdDsNCiAJCX0NCiANCi0JCWlwNl9kc3Rf c3RvcmUoc2ssIGRzdCwgTlVMTCk7DQorCQlpcDZfZHN0X3N0b3JlKHNrLCBk c3QsIE5VTEwsIE5VTEwpOw0KIAl9DQogDQogCXNrYi0+ZHN0ID0gZHN0X2Ns b25lKGRzdCk7DQpkaWZmIC1OdXIgLS1leGNsdWRlPVJDUyAtLWV4Y2x1ZGU9 Q1ZTIC0tZXhjbHVkZT1TQ0NTIC0tZXhjbHVkZT1CaXRLZWVwZXIgLS1leGNs dWRlPUNoYW5nZVNldCBsaW51eC0yLjUuT0xEL25ldC9pcHY2L3VkcC5jIGxp bnV4LTIuNS9uZXQvaXB2Ni91ZHAuYw0KLS0tIGxpbnV4LTIuNS5PTEQvbmV0 L2lwdjYvdWRwLmMJV2VkIEp1bCAgMiAxNTo0MjowMyAyMDAzDQorKysgbGlu dXgtMi41L25ldC9pcHY2L3VkcC5jCUZyaSBKdWwgIDQgMjM6MzI6MzQgMjAw Mw0KQEAgLTM0NSw3ICszNDUsMTYgQEANCiAJCWRzdF9yZWxlYXNlKGRzdCk7 DQogCQlnb3RvIG91dDsNCiAJfQ0KKyNpZmRlZiBDT05GSUdfSVBWNl9TVUJU UkVFUw0KKwlkc3RfcmVsZWFzZShkc3QpOw0KIA0KKwlkc3QgPSBpcDZfcm91 dGVfb3V0cHV0KHNrLCAmZmwpOw0KKw0KKwlpZiAoKGVyciA9IGRzdC0+ZXJy b3IpICE9IDApIHsNCisJCWRzdF9yZWxlYXNlKGRzdCk7DQorCQlnb3RvIG91 dDsNCisJfQ0KKyNlbmRpZg0KIAlpZiAoaXB2Nl9hZGRyX2FueSgmbnAtPnNh ZGRyKSkNCiAJCWlwdjZfYWRkcl9jb3B5KCZucC0+c2FkZHIsICZmbC5mbDZf c3JjKTsNCiANCkBAIC0zNTYsNyArMzY1LDkgQEANCiANCiAJaXA2X2RzdF9z dG9yZShzaywgZHN0LA0KIAkJICAgICAgIWlwdjZfYWRkcl9jbXAoJmZsLmZs Nl9kc3QsICZucC0+ZGFkZHIpID8NCi0JCSAgICAgICZucC0+ZGFkZHIgOiBO VUxMKTsNCisJCSAgICAgICZucC0+ZGFkZHIgOiBOVUxMLA0KKwkJICAgICAg IWlwdjZfYWRkcl9jbXAoJmZsLmZsNl9zcmMsICZucC0+c2FkZHIpID8NCisJ CSAgICAgICZucC0+c2FkZHIgOiBOVUxMKTsNCiANCiAJc2stPnNrX3N0YXRl ID0gVENQX0VTVEFCTElTSEVEOw0KIG91dDoNCkBAIC05NzAsNyArOTgxLDkg QEANCiANCiAJaXA2X2RzdF9zdG9yZShzaywgZHN0LA0KIAkJICAgICAgIWlw djZfYWRkcl9jbXAoJmZsLmZsNl9kc3QsICZucC0+ZGFkZHIpID8NCi0JCSAg ICAgICZucC0+ZGFkZHIgOiBOVUxMKTsNCisJCSAgICAgICZucC0+ZGFkZHIg OiBOVUxMLA0KKwkJICAgICAgIWlwdjZfYWRkcl9jbXAoJmZsLmZsNl9zcmMs ICZucC0+c2FkZHIpID8NCisJCSAgICAgICZucC0+c2FkZHIgOiBOVUxMKTsN CiAJaWYgKGVyciA+IDApDQogCQllcnIgPSBucC0+cmVjdmVyciA/IG5ldF94 bWl0X2Vycm5vKGVycikgOiAwOw0KIAlyZWxlYXNlX3NvY2soc2spOw0K ---377318441-1491903089-1057357517=:17083-- From vnuorval@tcs.hut.fi Fri Jul 4 17:33:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Jul 2003 17:33:17 -0700 (PDT) Received: from mail.tcs.hut.fi (mail.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h650X32x015087 for ; Fri, 4 Jul 2003 17:33:03 -0700 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by mail.tcs.hut.fi (Postfix) with ESMTP id 2223B8000A3; Fri, 4 Jul 2003 16:14:19 +0300 (EEST) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-5) with ESMTP id h64DEI5L015363; Fri, 4 Jul 2003 16:14:18 +0300 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-5) with ESMTP id h64DEInZ015359; Fri, 4 Jul 2003 16:14:18 +0300 Date: Fri, 4 Jul 2003 16:14:18 +0300 (EEST) From: Ville Nuorvala To: yoshfuji@linux-ipv6.org, Cc: netdev@oss.sgi.com Subject: [PATCH] IPV6: Fix incorrect dst_entry handling in ip6_tunnel.c Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3760 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Hi, I noticed a bug in ip6ip6_err(), please apply this patch! Thanks, Ville diff -Nur linux-2.5.OLD/net/ipv6/ip6_tunnel.c linux-2.5/net/ipv6/ip6_tunnel.c --- linux-2.5.OLD/net/ipv6/ip6_tunnel.c Fri Jul 4 14:48:21 2003 +++ linux-2.5/net/ipv6/ip6_tunnel.c Fri Jul 4 14:54:53 2003 @@ -506,7 +506,7 @@ icmpv6_send(skb2, rel_type, rel_code, rel_info, skb2->dev); if (rt) - dst_free(&rt->u.dst); + dst_release(&rt->u.dst); kfree_skb(skb2); } -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From vnuorval@tcs.hut.fi Fri Jul 4 18:23:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Jul 2003 18:23:22 -0700 (PDT) Received: from mail.tcs.hut.fi (mail.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h651N22x015996 for ; Fri, 4 Jul 2003 18:23:03 -0700 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by mail.tcs.hut.fi (Postfix) with ESMTP id 900BF800221; Fri, 4 Jul 2003 23:23:45 +0300 (EEST) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-5) with ESMTP id h64KNj5L016899; Fri, 4 Jul 2003 23:23:45 +0300 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-5) with ESMTP id h64KNipn016895; Fri, 4 Jul 2003 23:23:45 +0300 Date: Fri, 4 Jul 2003 23:23:44 +0300 (EEST) From: Ville Nuorvala To: yoshfuji@linux-ipv6.org, Cc: netdev@oss.sgi.com Subject: [PATCH] IPV6: ipv6-in-ipv6 tunnel using alloc_netdev Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-377318441-1068751107-1057349978=:16323" Content-ID: X-archive-position: 3762 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---377318441-1068751107-1057349978=:16323 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Hi, I finally had the time to fix ip6_tunnel.c so it also uses alloc_netdev() for creating new tunnel devices. Tested by adding and deleting tunnel device. Patch as attachment... Thanks, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 ---377318441-1068751107-1057349978=:16323 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="ip6_tnl_dyn_alloc.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="ip6_tnl_dyn_alloc.patch" ZGlmZiAtTnVyIGxpbnV4LTIuNS5PTEQvbmV0L2lwdjYvaXA2X3R1bm5lbC5j IGxpbnV4LTIuNS9uZXQvaXB2Ni9pcDZfdHVubmVsLmMNCi0tLSBsaW51eC0y LjUuT0xEL25ldC9pcHY2L2lwNl90dW5uZWwuYwlGcmkgSnVsICA0IDE0OjQ4 OjIxIDIwMDMNCisrKyBsaW51eC0yLjUvbmV0L2lwdjYvaXA2X3R1bm5lbC5j CUZyaSBKdWwgIDQgMTQ6Mzc6MjQgMjAwMw0KQEAgLTg3LDE4ICs4NywxMSBA QA0KIA0KIHN0YXRpYyBpbnQgaXA2aXA2X2ZiX3RubF9kZXZfaW5pdChzdHJ1 Y3QgbmV0X2RldmljZSAqZGV2KTsNCiBzdGF0aWMgaW50IGlwNmlwNl90bmxf ZGV2X2luaXQoc3RydWN0IG5ldF9kZXZpY2UgKmRldik7DQorc3RhdGljIHZv aWQgaXA2aXA2X3RubF9kZXZfc2V0dXAoc3RydWN0IG5ldF9kZXZpY2UgKmRl dik7DQogDQogLyogdGhlIElQdjYgdHVubmVsIGZhbGxiYWNrIGRldmljZSAq Lw0KLXN0YXRpYyBzdHJ1Y3QgbmV0X2RldmljZSBpcDZpcDZfZmJfdG5sX2Rl diA9IHsNCi0JLm5hbWUgPSAiaXA2dG5sMCIsDQotCS5pbml0ID0gaXA2aXA2 X2ZiX3RubF9kZXZfaW5pdA0KLX07DQorc3RhdGljIHN0cnVjdCBuZXRfZGV2 aWNlICppcDZpcDZfZmJfdG5sX2RldjsNCiANCi0vKiB0aGUgSVB2NiBmYWxs YmFjayB0dW5uZWwgKi8NCi1zdGF0aWMgc3RydWN0IGlwNl90bmwgaXA2aXA2 X2ZiX3RubCA9IHsNCi0JLmRldiA9ICZpcDZpcDZfZmJfdG5sX2RldiwNCi0J LnBhcm1zID17Lm5hbWUgPSAiaXA2dG5sMCIsIC5wcm90byA9IElQUFJPVE9f SVBWNn0NCi19Ow0KIA0KIC8qIGxpc3RzIGZvciBzdG9yaW5nIHR1bm5lbHMg aW4gdXNlICovDQogc3RhdGljIHN0cnVjdCBpcDZfdG5sICp0bmxzX3JfbFtI QVNIX1NJWkVdOw0KQEAgLTIxNiw1OSArMjA5LDM5IEBADQogaXA2X3RubF9j cmVhdGUoc3RydWN0IGlwNl90bmxfcGFybSAqcCwgc3RydWN0IGlwNl90bmwg KipwdCkNCiB7DQogCXN0cnVjdCBuZXRfZGV2aWNlICpkZXY7DQotCWludCBl cnIgPSAtRU5PQlVGUzsNCiAJc3RydWN0IGlwNl90bmwgKnQ7DQorCWNoYXIg bmFtZVtJRk5BTVNJWl07DQorCWludCBlcnI7DQogDQotCWRldiA9IGttYWxs b2Moc2l6ZW9mICgqZGV2KSArIHNpemVvZiAoKnQpLCBHRlBfS0VSTkVMKTsN Ci0JaWYgKCFkZXYpDQotCQlyZXR1cm4gZXJyOw0KKwlpZiAocC0+bmFtZVsw XSkgew0KKwkJc3RybGNweShuYW1lLCBwLT5uYW1lLCBJRk5BTVNJWik7DQor CX0gZWxzZSB7DQorCQlpbnQgaTsNCisJCWZvciAoaSA9IDE7IGkgPCBJUDZf VE5MX01BWDsgaSsrKSB7DQorCQkJc3ByaW50ZihuYW1lLCAiaXA2dG5sJWQi LCBpKTsNCisJCQlpZiAoX19kZXZfZ2V0X2J5X25hbWUobmFtZSkgPT0gTlVM TCkNCisJCQkJYnJlYWs7DQorCQl9DQorCQlpZiAoaSA9PSBJUDZfVE5MX01B WCkgDQorCQkJcmV0dXJuIC1FTk9CVUZTOw0KKwl9DQorCWRldiA9IGFsbG9j X25ldGRldihzaXplb2YgKCp0KSwgbmFtZSwgaXA2aXA2X3RubF9kZXZfc2V0 dXApOw0KKwlpZiAoZGV2ID09IE5VTEwpDQorCQlyZXR1cm4gLUVOT01FTTsN CiANCi0JbWVtc2V0KGRldiwgMCwgc2l6ZW9mICgqZGV2KSArIHNpemVvZiAo KnQpKTsNCi0JZGV2LT5wcml2ID0gKHZvaWQgKikgKGRldiArIDEpOw0KLQl0 ID0gKHN0cnVjdCBpcDZfdG5sICopIGRldi0+cHJpdjsNCi0JdC0+ZGV2ID0g ZGV2Ow0KKwl0ID0gZGV2LT5wcml2Ow0KIAlkZXYtPmluaXQgPSBpcDZpcDZf dG5sX2Rldl9pbml0Ow0KLQltZW1jcHkoJnQtPnBhcm1zLCBwLCBzaXplb2Yg KCpwKSk7DQotCXQtPnBhcm1zLm5hbWVbSUZOQU1TSVogLSAxXSA9ICdcMCc7 DQotCXN0cmNweShkZXYtPm5hbWUsIHQtPnBhcm1zLm5hbWUpOw0KLQlpZiAo IWRldi0+bmFtZVswXSkgew0KLQkJaW50IGkgPSAwOw0KLQkJaW50IGV4aXN0 cyA9IDA7DQotDQotCQlkbyB7DQotCQkJc3ByaW50ZihkZXYtPm5hbWUsICJp cDZ0bmwlZCIsICsraSk7DQotCQkJZXhpc3RzID0gKF9fZGV2X2dldF9ieV9u YW1lKGRldi0+bmFtZSkgIT0gTlVMTCk7DQotCQl9IHdoaWxlIChpIDwgSVA2 X1ROTF9NQVggJiYgZXhpc3RzKTsNCisJdC0+cGFybXMgPSAqcDsNCiANCi0J CWlmIChpID09IElQNl9UTkxfTUFYKSB7DQotCQkJZ290byBmYWlsZWQ7DQot CQl9DQotCQltZW1jcHkodC0+cGFybXMubmFtZSwgZGV2LT5uYW1lLCBJRk5B TVNJWik7DQotCX0NCi0JU0VUX01PRFVMRV9PV05FUihkZXYpOw0KIAlpZiAo KGVyciA9IHJlZ2lzdGVyX25ldGRldmljZShkZXYpKSA8IDApIHsNCi0JCWdv dG8gZmFpbGVkOw0KKwkJa2ZyZWUoZGV2KTsNCisJCXJldHVybiBlcnI7DQog CX0NCisJZGV2X2hvbGQoZGV2KTsNCisNCiAJaXA2aXA2X3RubF9saW5rKHQp Ow0KIAkqcHQgPSB0Ow0KIAlyZXR1cm4gMDsNCi1mYWlsZWQ6DQotCWtmcmVl KGRldik7DQotCXJldHVybiBlcnI7DQotfQ0KLQ0KLS8qKg0KLSAqIGlwNl90 bmxfZGVzdHJveSgpIC0gZGVzdHJveSBvbGQgdHVubmVsDQotICogICBAdDog dHVubmVsIHRvIGJlIGRlc3Ryb3llZA0KLSAqDQotICogUmV0dXJuOg0KLSAq ICAgd2hhdGV2ZXIgdW5yZWdpc3Rlcl9uZXRkZXZpY2UoKSByZXR1cm5zDQot ICoqLw0KLQ0KLXN0YXRpYyBpbmxpbmUgaW50DQotaXA2X3RubF9kZXN0cm95 KHN0cnVjdCBpcDZfdG5sICp0KQ0KLXsNCi0JcmV0dXJuIHVucmVnaXN0ZXJf bmV0ZGV2aWNlKHQtPmRldik7DQogfQ0KIA0KIC8qKg0KQEAgLTMwNCwyNCAr Mjc3LDEzIEBADQogCQkJcmV0dXJuIChjcmVhdGUgPyAtRUVYSVNUIDogMCk7 DQogCQl9DQogCX0NCi0JaWYgKCFjcmVhdGUpIHsNCisJaWYgKCFjcmVhdGUp DQogCQlyZXR1cm4gLUVOT0RFVjsNCi0JfQ0KKwkNCiAJcmV0dXJuIGlwNl90 bmxfY3JlYXRlKHAsIHB0KTsNCiB9DQogDQogLyoqDQotICogaXA2aXA2X3Ru bF9kZXZfZGVzdHJ1Y3RvciAtIHR1bm5lbCBkZXZpY2UgZGVzdHJ1Y3Rvcg0K LSAqICAgQGRldjogdGhlIGRldmljZSB0byBiZSBkZXN0cm95ZWQNCi0gKiov DQotDQotc3RhdGljIHZvaWQNCi1pcDZpcDZfdG5sX2Rldl9kZXN0cnVjdG9y KHN0cnVjdCBuZXRfZGV2aWNlICpkZXYpDQotew0KLQlrZnJlZShkZXYpOw0K LX0NCi0NCi0vKioNCiAgKiBpcDZpcDZfdG5sX2Rldl91bmluaXQgLSB0dW5u ZWwgZGV2aWNlIHVuaW5pdGlhbGl6ZXINCiAgKiAgIEBkZXY6IHRoZSBkZXZp Y2UgdG8gYmUgZGVzdHJveWVkDQogICogICANCkBAIC0zMzIsMTQgKzI5NCwx NCBAQA0KIHN0YXRpYyB2b2lkDQogaXA2aXA2X3RubF9kZXZfdW5pbml0KHN0 cnVjdCBuZXRfZGV2aWNlICpkZXYpDQogew0KLQlpZiAoZGV2ID09ICZpcDZp cDZfZmJfdG5sX2Rldikgew0KKwlpZiAoZGV2ID09IGlwNmlwNl9mYl90bmxf ZGV2KSB7DQogCQl3cml0ZV9sb2NrX2JoKCZpcDZpcDZfbG9jayk7DQogCQl0 bmxzX3djWzBdID0gTlVMTDsNCiAJCXdyaXRlX3VubG9ja19iaCgmaXA2aXA2 X2xvY2spOw0KIAl9IGVsc2Ugew0KLQkJc3RydWN0IGlwNl90bmwgKnQgPSAo c3RydWN0IGlwNl90bmwgKikgZGV2LT5wcml2Ow0KLQkJaXA2aXA2X3RubF91 bmxpbmsodCk7DQorCQlpcDZpcDZfdG5sX3VubGluaygoc3RydWN0IGlwNl90 bmwgKikgZGV2LT5wcml2KTsNCiAJfQ0KKwlkZXZfcHV0KGRldik7DQogfQ0K IA0KIC8qKg0KQEAgLTg3OCw3ICs4NDAsNiBAQA0KIAl9DQogfQ0KIA0KLQ0K IHN0YXRpYyB2b2lkIGlwNmlwNl90bmxfbGlua19jb25maWcoc3RydWN0IGlw Nl90bmwgKnQpDQogew0KIAlzdHJ1Y3QgbmV0X2RldmljZSAqZGV2ID0gdC0+ ZGV2Ow0KQEAgLTkwNiwzMSArODY3LDI1IEBADQogCWlmIChwLT5mbGFncyAm IElQNl9UTkxfRl9DQVBfWE1JVCkgew0KIAkJc3RydWN0IHJ0Nl9pbmZvICpy dCA9IHJ0Nl9sb29rdXAoJnAtPnJhZGRyLCAmcC0+bGFkZHIsDQogCQkJCQkJ IHAtPmxpbmssIDApOw0KLQkJaWYgKHJ0KSB7DQotCQkJc3RydWN0IG5ldF9k ZXZpY2UgKnJ0ZGV2Ow0KLQkJCWlmICghKHJ0ZGV2ID0gcnQtPnJ0NmlfZGV2 KSB8fA0KLQkJCSAgICBydGRldi0+dHlwZSA9PSBBUlBIUkRfVFVOTkVMNikg ew0KLQkJCQkvKiBhcyBsb25nIGFzIHR1bm5lbHMgdXNlIHRoZSBzYW1lIHNv Y2tldCANCi0JCQkJICAgZm9yIHRyYW5zbWlzc2lvbiwgbG9jYWxseSBuZXN0 ZWQgdHVubmVscyANCi0JCQkJICAgd29uJ3Qgd29yayAqLw0KLQkJCQlkc3Rf cmVsZWFzZSgmcnQtPnUuZHN0KTsNCi0JCQkJZ290byBub19saW5rOw0KLQkJ CX0gZWxzZSB7DQotCQkJCWRldi0+aWZsaW5rID0gcnRkZXYtPmlmaW5kZXg7 DQotCQkJCWRldi0+aGFyZF9oZWFkZXJfbGVuID0gcnRkZXYtPmhhcmRfaGVh ZGVyX2xlbiArDQotCQkJCQlzaXplb2YgKHN0cnVjdCBpcHY2aGRyKTsNCi0J CQkJZGV2LT5tdHUgPSBydGRldi0+bXR1IC0gc2l6ZW9mIChzdHJ1Y3QgaXB2 Nmhkcik7DQotCQkJCWlmIChkZXYtPm10dSA8IElQVjZfTUlOX01UVSkNCi0J CQkJCWRldi0+bXR1ID0gSVBWNl9NSU5fTVRVOw0KLQkJCQkNCi0JCQkJZHN0 X3JlbGVhc2UoJnJ0LT51LmRzdCk7DQotCQkJfQ0KKw0KKwkJaWYgKHJ0ID09 IE5VTEwpDQorCQkJcmV0dXJuOw0KKw0KKwkJLyogYXMgbG9uZyBhcyB0dW5u ZWxzIHVzZSB0aGUgc2FtZSBzb2NrZXQgZm9yIHRyYW5zbWlzc2lvbiwNCisJ CSAgIGxvY2FsbHkgbmVzdGVkIHR1bm5lbHMgd29uJ3Qgd29yayAqLw0KKwkJ DQorCQlpZiAocnQtPnJ0NmlfZGV2ICYmIHJ0LT5ydDZpX2Rldi0+dHlwZSAh PSBBUlBIUkRfVFVOTkVMNikgew0KKwkJCWRldi0+aWZsaW5rID0gcnQtPnJ0 NmlfZGV2LT5pZmluZGV4Ow0KKw0KKwkJCWRldi0+aGFyZF9oZWFkZXJfbGVu ID0gcnQtPnJ0NmlfZGV2LT5oYXJkX2hlYWRlcl9sZW4gKw0KKwkJCQlzaXpl b2YgKHN0cnVjdCBpcHY2aGRyKTsNCisNCisJCQlkZXYtPm10dSA9IHJ0LT5y dDZpX2Rldi0+bXR1IC0gc2l6ZW9mIChzdHJ1Y3QgaXB2Nmhkcik7DQorDQor CQkJaWYgKGRldi0+bXR1IDwgSVBWNl9NSU5fTVRVKQ0KKwkJCQlkZXYtPm10 dSA9IElQVjZfTUlOX01UVTsNCiAJCX0NCi0JfSBlbHNlIHsNCi0Jbm9fbGlu azoNCi0JCWRldi0+aWZsaW5rID0gMDsNCi0JCWRldi0+aGFyZF9oZWFkZXJf bGVuID0gTExfTUFYX0hFQURFUiArIHNpemVvZiAoc3RydWN0IGlwdjZoZHIp Ow0KLQkJZGV2LT5tdHUgPSBFVEhfREFUQV9MRU4gLSBzaXplb2YgKHN0cnVj dCBpcHY2aGRyKTsNCisJCWRzdF9yZWxlYXNlKCZydC0+dS5kc3QpOw0KIAl9 DQogfQ0KIA0KQEAgLTk5NSw3ICs5NTAsNyBAQA0KIA0KIAlzd2l0Y2ggKGNt ZCkgew0KIAljYXNlIFNJT0NHRVRUVU5ORUw6DQotCQlpZiAoZGV2ID09ICZp cDZpcDZfZmJfdG5sX2Rldikgew0KKwkJaWYgKGRldiA9PSBpcDZpcDZfZmJf dG5sX2Rldikgew0KIAkJCWlmIChjb3B5X2Zyb21fdXNlcigmcCwNCiAJCQkJ CSAgIGlmci0+aWZyX2lmcnUuaWZydV9kYXRhLA0KIAkJCQkJICAgc2l6ZW9m IChwKSkpIHsNCkBAIC0xMDI0LDcgKzk3OSw3IEBADQogCQkJZXJyID0gLUVG QVVMVDsNCiAJCQlicmVhazsNCiAJCX0NCi0JCWlmICghY3JlYXRlICYmIGRl diAhPSAmaXA2aXA2X2ZiX3RubF9kZXYpIHsNCisJCWlmICghY3JlYXRlICYm IGRldiAhPSBpcDZpcDZfZmJfdG5sX2Rldikgew0KIAkJCXQgPSAoc3RydWN0 IGlwNl90bmwgKikgZGV2LT5wcml2Ow0KIAkJfQ0KIAkJaWYgKCF0ICYmIChl cnIgPSBpcDZpcDZfdG5sX2xvY2F0ZSgmcCwgJnQsIGNyZWF0ZSkpKSB7DQpA QCAtMTA1Miw3ICsxMDA3LDcgQEANCiAJCWlmICghY2FwYWJsZShDQVBfTkVU X0FETUlOKSkNCiAJCQlicmVhazsNCiANCi0JCWlmIChkZXYgPT0gJmlwNmlw Nl9mYl90bmxfZGV2KSB7DQorCQlpZiAoZGV2ID09IGlwNmlwNl9mYl90bmxf ZGV2KSB7DQogCQkJaWYgKGNvcHlfZnJvbV91c2VyKCZwLCBpZnItPmlmcl9p ZnJ1LmlmcnVfZGF0YSwNCiAJCQkJCSAgIHNpemVvZiAocCkpKSB7DQogCQkJ CWVyciA9IC1FRkFVTFQ7DQpAQCAtMTA2MSwxNCArMTAxNiwxNCBAQA0KIAkJ CWVyciA9IGlwNmlwNl90bmxfbG9jYXRlKCZwLCAmdCwgMCk7DQogCQkJaWYg KGVycikNCiAJCQkJYnJlYWs7DQotCQkJaWYgKHQgPT0gJmlwNmlwNl9mYl90 bmwpIHsNCisJCQlpZiAodCA9PSBpcDZpcDZfZmJfdG5sX2Rldi0+cHJpdikg ew0KIAkJCQllcnIgPSAtRVBFUk07DQogCQkJCWJyZWFrOw0KIAkJCX0NCiAJ CX0gZWxzZSB7DQogCQkJdCA9IChzdHJ1Y3QgaXA2X3RubCAqKSBkZXYtPnBy aXY7DQogCQl9DQotCQllcnIgPSBpcDZfdG5sX2Rlc3Ryb3kodCk7DQorCQll cnIgPSB1bnJlZ2lzdGVyX25ldGRldmljZSh0LT5kZXYpOw0KIAkJYnJlYWs7 DQogCWRlZmF1bHQ6DQogCQllcnIgPSAtRUlOVkFMOw0KQEAgLTExMTAsNDAg KzEwNjUsNDkgQEANCiB9DQogDQogLyoqDQotICogaXA2aXA2X3RubF9kZXZf aW5pdF9nZW4gLSBnZW5lcmFsIGluaXRpYWxpemVyIGZvciBhbGwgdHVubmVs IGRldmljZXMNCisgKiBpcDZpcDZfdG5sX2Rldl9zZXR1cCAtIHNldHVwIHZp cnR1YWwgdHVubmVsIGRldmljZQ0KICAqICAgQGRldjogdmlydHVhbCBkZXZp Y2UgYXNzb2NpYXRlZCB3aXRoIHR1bm5lbA0KICAqDQogICogRGVzY3JpcHRp b246DQotICogICBTZXQgZnVuY3Rpb24gcG9pbnRlcnMgYW5kIGluaXRpYWxp emUgdGhlICZzdHJ1Y3QgZmxvd2kgdGVtcGxhdGUgdXNlZA0KLSAqICAgYnkg dGhlIHR1bm5lbC4NCisgKiAgIEluaXRpYWxpemUgZnVuY3Rpb24gcG9pbnRl cnMgYW5kIGRldmljZSBwYXJhbWV0ZXJzDQogICoqLw0KIA0KLXN0YXRpYyB2 b2lkDQotaXA2aXA2X3RubF9kZXZfaW5pdF9nZW4oc3RydWN0IG5ldF9kZXZp Y2UgKmRldikNCitzdGF0aWMgdm9pZCBpcDZpcDZfdG5sX2Rldl9zZXR1cChz dHJ1Y3QgbmV0X2RldmljZSAqZGV2KQ0KIHsNCi0Jc3RydWN0IGlwNl90bmwg KnQgPSAoc3RydWN0IGlwNl90bmwgKikgZGV2LT5wcml2Ow0KLQlzdHJ1Y3Qg Zmxvd2kgKmZsID0gJnQtPmZsOw0KLQ0KLQltZW1zZXQoZmwsIDAsIHNpemVv ZiAoKmZsKSk7DQotCWZsLT5wcm90byA9IElQUFJPVE9fSVBWNjsNCi0NCi0J ZGV2LT5kZXN0cnVjdG9yID0gaXA2aXA2X3RubF9kZXZfZGVzdHJ1Y3RvcjsN CisJU0VUX01PRFVMRV9PV05FUihkZXYpOw0KIAlkZXYtPnVuaW5pdCA9IGlw NmlwNl90bmxfZGV2X3VuaW5pdDsNCisJZGV2LT5kZXN0cnVjdG9yID0gKHZv aWQgKCopKHN0cnVjdCBuZXRfZGV2aWNlICopKWtmcmVlOw0KIAlkZXYtPmhh cmRfc3RhcnRfeG1pdCA9IGlwNmlwNl90bmxfeG1pdDsNCiAJZGV2LT5nZXRf c3RhdHMgPSBpcDZpcDZfdG5sX2dldF9zdGF0czsNCiAJZGV2LT5kb19pb2N0 bCA9IGlwNmlwNl90bmxfaW9jdGw7DQogCWRldi0+Y2hhbmdlX210dSA9IGlw NmlwNl90bmxfY2hhbmdlX210dTsNCisNCiAJZGV2LT50eXBlID0gQVJQSFJE X1RVTk5FTDY7DQorCWRldi0+aGFyZF9oZWFkZXJfbGVuID0gTExfTUFYX0hF QURFUiArIHNpemVvZiAoc3RydWN0IGlwdjZoZHIpOw0KKwlkZXYtPm10dSA9 IEVUSF9EQVRBX0xFTiAtIHNpemVvZiAoc3RydWN0IGlwdjZoZHIpOw0KIAlk ZXYtPmZsYWdzIHw9IElGRl9OT0FSUDsNCi0JaWYgKGlwdjZfYWRkcl90eXBl KCZ0LT5wYXJtcy5yYWRkcikgJiBJUFY2X0FERFJfVU5JQ0FTVCAmJg0KLQkg ICAgaXB2Nl9hZGRyX3R5cGUoJnQtPnBhcm1zLmxhZGRyKSAmIElQVjZfQURE Ul9VTklDQVNUKQ0KLQkJZGV2LT5mbGFncyB8PSBJRkZfUE9JTlRPUE9JTlQ7 DQotCS8qIEhtbS4uLiBNQVhfQUREUl9MRU4gaXMgOCwgc28gdGhlIGlwdjYg YWRkcmVzc2VzIGNhbid0IGJlIA0KKwlkZXYtPmlmbGluayA9IDA7DQorCS8q IEhtbS4uLiBNQVhfQUREUl9MRU4gaXMgOCwgc28gdGhlIGlwdjYgYWRkcmVz c2VzIGNhbid0IGJlDQogCSAgIGNvcGllZCB0byBkZXYtPmRldl9hZGRyIGFu ZCBkZXYtPmJyb2FkY2FzdCwgbGlrZSB0aGUgaXB2NA0KIAkgICBhZGRyZXNz ZXMgd2VyZSBpbiBpcGlwLmMsIGlwX2dyZS5jIGFuZCBzaXQuYy4gKi8NCiAJ ZGV2LT5hZGRyX2xlbiA9IDA7DQogfQ0KIA0KKw0KKy8qKg0KKyAqIGlwNmlw Nl90bmxfZGV2X2luaXRfZ2VuIC0gZ2VuZXJhbCBpbml0aWFsaXplciBmb3Ig YWxsIHR1bm5lbCBkZXZpY2VzDQorICogICBAZGV2OiB2aXJ0dWFsIGRldmlj ZSBhc3NvY2lhdGVkIHdpdGggdHVubmVsDQorICoqLw0KKw0KK3N0YXRpYyBp bmxpbmUgdm9pZA0KK2lwNmlwNl90bmxfZGV2X2luaXRfZ2VuKHN0cnVjdCBu ZXRfZGV2aWNlICpkZXYpDQorew0KKwlzdHJ1Y3QgaXA2X3RubCAqdCA9IChz dHJ1Y3QgaXA2X3RubCAqKSBkZXYtPnByaXY7DQorCXQtPmZsLnByb3RvID0g SVBQUk9UT19JUFY2Ow0KKwl0LT5kZXYgPSBkZXY7DQorCXN0cmNweSh0LT5w YXJtcy5uYW1lLCBkZXYtPm5hbWUpOw0KK30NCisNCiAvKioNCiAgKiBpcDZp cDZfdG5sX2Rldl9pbml0IC0gaW5pdGlhbGl6ZXIgZm9yIGFsbCBub24gZmFs bGJhY2sgdHVubmVsIGRldmljZXMNCiAgKiAgIEBkZXY6IHZpcnR1YWwgZGV2 aWNlIGFzc29jaWF0ZWQgd2l0aCB0dW5uZWwNCkBAIC0xMTY3LDggKzExMzEs MTAgQEANCiANCiBpbnQgaXA2aXA2X2ZiX3RubF9kZXZfaW5pdChzdHJ1Y3Qg bmV0X2RldmljZSAqZGV2KQ0KIHsNCi0JaXA2aXA2X3RubF9kZXZfaW5pdF9n ZW4oZGV2KTsNCi0JdG5sc193Y1swXSA9ICZpcDZpcDZfZmJfdG5sOw0KKwlz dHJ1Y3QgaXA2X3RubCAqdCA9IGRldi0+cHJpdjsNCisJaXA2aXA2X3RubF9k ZXZfaW5pdF9nZW4oZGV2KTsgDQorCWRldl9ob2xkKGRldik7DQorCXRubHNf d2NbMF0gPSB0Ow0KIAlyZXR1cm4gMDsNCiB9DQogDQpAQCAtMTE5MCw4ICsx MTU2LDYgQEANCiAJc3RydWN0IHNvY2sgKnNrOw0KIAlzdHJ1Y3QgaXB2Nl9w aW5mbyAqbnA7DQogDQotCWlwNmlwNl9mYl90bmxfZGV2LnByaXYgPSAodm9p ZCAqKSAmaXA2aXA2X2ZiX3RubDsNCi0NCiAJZm9yIChpID0gMDsgaSA8IE5S X0NQVVM7IGkrKykgew0KIAkJaWYgKCFjcHVfcG9zc2libGUoaSkpDQogCQkJ Y29udGludWU7DQpAQCAtMTIxOSwxMCArMTE4MywyMyBAQA0KIAkJZ290byBm YWlsOw0KIAl9DQogDQotCVNFVF9NT0RVTEVfT1dORVIoJmlwNmlwNl9mYl90 bmxfZGV2KTsNCi0JcmVnaXN0ZXJfbmV0ZGV2KCZpcDZpcDZfZmJfdG5sX2Rl dik7DQotDQorCQ0KKwlpcDZpcDZfZmJfdG5sX2RldiA9IGFsbG9jX25ldGRl dihzaXplb2Yoc3RydWN0IGlwNl90bmwpLCAiaXA2dG5sMCIsDQorCQkJCQkg aXA2aXA2X3RubF9kZXZfc2V0dXApOw0KKw0KKwlpZiAoIWlwNmlwNl9mYl90 bmxfZGV2KSB7DQorCQllcnIgPSAtRU5PTUVNOw0KKwkJZ290byB0bmxfZmFp bDsNCisJfQ0KKwlpcDZpcDZfZmJfdG5sX2Rldi0+aW5pdCA9IGlwNmlwNl9m Yl90bmxfZGV2X2luaXQ7DQorDQorCWlmICgoZXJyID0gcmVnaXN0ZXJfbmV0 ZGV2KGlwNmlwNl9mYl90bmxfZGV2KSkpIHsNCisJCWtmcmVlKGlwNmlwNl9m Yl90bmxfZGV2KTsNCisJCWdvdG8gdG5sX2ZhaWw7DQorCX0NCiAJcmV0dXJu IDA7DQordG5sX2ZhaWw6DQorCWluZXQ2X2RlbF9wcm90b2NvbCgmaXA2aXA2 X3Byb3RvY29sLCBJUFBST1RPX0lQVjYpOw0KIGZhaWw6DQogCWZvciAoaiA9 IDA7IGogPCBpOyBqKyspIHsNCiAJCWlmICghY3B1X3Bvc3NpYmxlKGopKQ0K QEAgLTEyNDEsNyArMTIxOCw3IEBADQogew0KIAlpbnQgaTsNCiANCi0JdW5y ZWdpc3Rlcl9uZXRkZXYoJmlwNmlwNl9mYl90bmxfZGV2KTsNCisJdW5yZWdp c3Rlcl9uZXRkZXYoaXA2aXA2X2ZiX3RubF9kZXYpOw0KIA0KIAlpbmV0Nl9k ZWxfcHJvdG9jb2woJmlwNmlwNl9wcm90b2NvbCwgSVBQUk9UT19JUFY2KTsN CiANCg== ---377318441-1068751107-1057349978=:16323-- From jeffpc@optonline.net Fri Jul 4 18:48:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Jul 2003 18:48:32 -0700 (PDT) Received: from mta10.srv.hcvlny.cv.net (mta10.srv.hcvlny.cv.net [167.206.5.45]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h651mP2x016260 for ; Fri, 4 Jul 2003 18:48:26 -0700 Received: from asv13.srv.hcvlny.cv.net (asv13.srv.hcvlny.cv.net [167.206.5.147]) by mta10.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HHI00FWKHW7LK@mta10.srv.hcvlny.cv.net> for netdev@oss.sgi.com; Fri, 04 Jul 2003 13:57:44 -0400 (EDT) Received: from jeff.home (ool-44c2049f.dyn.optonline.net [68.194.4.159]) by asv13.srv.hcvlny.cv.net (8.12.9/8.12.9) with ESMTP id h64HuatX016667; Fri, 04 Jul 2003 13:56:39 -0400 (EDT) Date: Fri, 04 Jul 2003 13:57:19 -0400 From: Jeff Sipek Subject: Re: [PATCH - RFC] [1/5] 64-bit network statistics - generic net In-reply-to: <20030704094745.GG29233@lug-owl.de> To: Jan-Benedict Glaw , Kernel Mailing List Cc: Andrew Morton , Dave Jones , Jeff Garzik , netdev@oss.sgi.com, Linus Torvalds Message-id: <200307041357.32871.jeffpc@optonline.net> MIME-version: 1.0 Content-type: Text/Plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline Content-description: clearsigned data User-Agent: KMail/1.5.2 References: <200307032231.39842.jeffpc@optonline.net> <20030704094745.GG29233@lug-owl.de> X-archive-position: 3763 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeffpc@optonline.net Precedence: bulk X-list: netdev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 04 July 2003 05:47, Jan-Benedict Glaw wrote: > Well... I don't really like to break userspace, but why don't we simply > make packet/traffic counters long long / u_int64_t? This way, we'd > simply keep almost all drivers untouched and only need to fiddle with > some sprints()/printk() statements? I'm no hardware expert, however, that approach contains potential race condition - not a system critical one, but something we should be concerned about. If one cpu tries to read a u_int64_t variable while another tries to update it, the worst case scenario is that the reader will get the high 32-bits before the write, and low 32-bit after the write, now if the counter overflow, the number would be off by 4GB! (This only applies to 32-bit architectures.) True, there are cache coherency algorithms, etc... > Really, how many programs use the current statistics? I'd prefer to > modify them over adding strange patches like this one to the kernel... I believe that on any kind of router some at some point in time would like to know the data transfered. Jeff. - -- Keyboard not found! Press F1 to enter Setup -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/BcADwFP0+seVj/4RAq2TAKDS0oAnj0/PrCuPoxdQF0euBiy6LACeMHqk gWJhwub4y0VtQmC/hcevJB4= =RCSe -----END PGP SIGNATURE----- From chas@locutus.cmf.nrl.navy.mil Fri Jul 4 19:19:13 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Jul 2003 19:19:18 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h652JB2x016567 for ; Fri, 4 Jul 2003 19:19:12 -0700 Received: from locutus.cmf.nrl.navy.mil (locutus.cmf.nrl.navy.mil [134.207.10.66]) by ginger.cmf.nrl.navy.mil (8.12.7/8.12.7) with ESMTP id h652J7sG025618 for ; Fri, 4 Jul 2003 22:19:07 -0400 (EDT) Message-Id: <200307050219.h652J7sG025618@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Subject: igmp3 and igmp_group_dropped() trouble? Reply-To: chas3@users.sourceforge.net Date: Fri, 04 Jul 2003 22:16:50 -0400 From: chas williams X-Spam-Score: (**) hits=2.5 X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 3764 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 recently i noticed a little problem with my lane interfaces not being unregistered completely when i rmmod'ed the module -- it would stick with a single outstanding reference to the network device. also, if i kept ifup'ing/ifdown'ing, eventually i would get an oops in kernel/timer.c:377. i have tracked this down to a problem with igmp_group_dropped() and the newish (to me anyway) igmp3 support. during ip_mc_down(), seems like its trying to stop all the timers and drop any refs that a timer might have to the inet device: in_dev->mr_ifc_count = 0; if (del_timer(&in_dev->mr_ifc_timer)) __in_dev_put(in_dev); then it goes on to delete the multicast groups: for (i=in_dev->mc_list; i; i=i->next) igmp_group_dropped(i); unfortunately igmp_group_dropped() seems to schedule the mr_ifc_timer (via igmp_ifc_event) in an effort to inform the network its no longer a member of the group (or so i think). this isnt a particular problem, except that the timers use __in_dev_put(), so if the timer is the last guy to dec the refcnt on inet device, the inet destroy function is never called and inet never drops its last reference to to the network interface. i am guessing that ip_mc_down() is supposed to get the igmp stack to drop all references to the inet device. some possible solutions (assuming the above is correct): in igmp_group_dropped() dont bother trying to send drop messages if !IFF_UP. in ip_mc_down(), delete the mr_ifc_timer AFTER dropping the group membership. i guess i would learn toward this one. however, you might also need delete the timer again in ip_mc_destroy_dev() since it also calls igmp_group_dropped() after its too late to send anything to the network. From jmorris@intercode.com.au Sat Jul 5 10:58:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jul 2003 10:58:34 -0700 (PDT) Received: from blackbird.intercode.com.au (IDENT:zklLyXdkVtQeqBRWV7vlAaoO+PS3w/oO@blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h65HwS2x029318 for ; Sat, 5 Jul 2003 10:58:30 -0700 Received: from excalibur.intercode.com.au (excalibur.intercode.com.au [203.32.101.12]) by blackbird.intercode.com.au (8.11.6p2/8.9.3) with ESMTP id h65Hvur30414; Sun, 6 Jul 2003 03:57:57 +1000 Date: Sun, 6 Jul 2003 03:57:55 +1000 (EST) From: James Morris To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: davem@redhat.com, , , Subject: Re: [PATCH] ATM: CLIP: C99 initializers In-Reply-To: <20030703.183850.78164037.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 3770 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@intercode.com.au Precedence: bulk X-list: netdev On Thu, 3 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote: > This converts nlip_tbl to C99 initializers. > (and fixes wrong value for proxy_len and locktime.) Heh, nice catch. Applied to bk://kernel.bkbits.net/jmorris/net-2.5 - James -- James Morris From jmorris@intercode.com.au Sat Jul 5 11:11:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jul 2003 11:11:36 -0700 (PDT) Received: from blackbird.intercode.com.au (IDENT:qbv7G6atDeF37mJ5F/sn6KcyBRyLcryE@blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h65IBO2x029729 for ; Sat, 5 Jul 2003 11:11:26 -0700 Received: from excalibur.intercode.com.au (excalibur.intercode.com.au [203.32.101.12]) by blackbird.intercode.com.au (8.11.6p2/8.9.3) with ESMTP id h65IBLr30679; Sun, 6 Jul 2003 04:11:21 +1000 Date: Sun, 6 Jul 2003 04:11:20 +1000 (EST) From: James Morris To: netdev@oss.sgi.com cc: lode leroy Subject: [PATCH] 2.5.70 - display bootserver in /proc/net/pnp (net/ipv4/ipconfig.c) (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3771 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@intercode.com.au Precedence: bulk X-list: netdev Forwarded to netdev for comment. ---------- Forwarded message ---------- Date: Fri, 04 Jul 2003 11:43:38 +0200 From: lode leroy To: linux-kernel@vger.kernel.org Cc: mj@atrey.karlin.mff.cuni.cz Subject: [PATCH] 2.5.70 - display bootserver in /proc/net/pnp (net/ipv4/ipconfig.c) Hello, I would like to submit a trivial enhancement to display the ip address of the bootserver in /proc/net/pnp This aids me in developing a diskless linux root image to know where it comes from... please kindly apply this to the current linux 2.7.x tree -- lode # diff -u net/ipv4/ipconfig.{orig,c} --- net/ipv4/ipconfig.orig 2003-05-27 03:00:21.000000000 +0200 +++ net/ipv4/ipconfig.c 2003-07-04 11:17:30.000000000 +0200 @@ -1115,6 +1115,9 @@ "nameserver %u.%u.%u.%u\n", NIPQUAD(ic_nameservers[i])); } + len += sprintf(buffer + len, + "bootserver %u.%u.%u.%u\n", + NIPQUAD(ic_servaddr)); if (offset > len) offset = len; _________________________________________________________________ Receive your Hotmail & Messenger messages on your mobile phone with MSN Mobile http://www.msn.be/gsm/smsservices - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From jgarzik@pobox.com Sat Jul 5 13:41:04 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jul 2003 13:41:11 -0700 (PDT) Received: from www.linux.org.uk (parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h65Kf32x031253 for ; Sat, 5 Jul 2003 13:41:04 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19Ytq8-0002Ji-GT; Sat, 05 Jul 2003 21:41:00 +0100 Message-ID: <3F0737D1.5090109@pobox.com> Date: Sat, 05 Jul 2003 16:40:49 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: Jeff Sipek CC: Bernd Eckenfels , linux-kernel@vger.kernel.org, Andrew Morton , Dave Jones , Linus Torvalds , netdev@oss.sgi.com Subject: Re: [PATCH - RFC] [1/5] 64-bit network statistics - generic net References: <200307051637.52252.jeffpc@optonline.net> In-Reply-To: <200307051637.52252.jeffpc@optonline.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3775 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 The net stats are already unsigned long internally. 64-bit case is handled quite nicely today, thanks :) I'm such a 64-bit bigot that "buy a 64-bit computer" is a solution I commonly suggest, and it seems to fit well here, too. Jeff, wondering if Intel will bother to compete w/ Athlon64 From jeffpc@optonline.net Sat Jul 5 13:53:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jul 2003 13:53:19 -0700 (PDT) Received: from mta2.srv.hcvlny.cv.net (mta2.srv.hcvlny.cv.net [167.206.5.5]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h65KrE2x031532 for ; Sat, 5 Jul 2003 13:53:15 -0700 Received: from asv19.srv.hcvlny.cv.net (asv19.srv.hcvlny.cv.net [167.206.5.173]) by mta2.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HHK00K63JZ9MF@mta2.srv.hcvlny.cv.net> for netdev@oss.sgi.com; Sat, 05 Jul 2003 16:37:57 -0400 (EDT) Received: from jeff.home (ool-44c2049f.dyn.optonline.net [68.194.4.159]) by asv19.srv.hcvlny.cv.net (8.12.9/8.12.9) with ESMTP id h65KaujJ009847; Sat, 05 Jul 2003 16:36:57 -0400 (EDT) Date: Sat, 05 Jul 2003 16:37:43 -0400 From: Jeff Sipek Subject: Re: [PATCH - RFC] [1/5] 64-bit network statistics - generic net In-reply-to: To: Bernd Eckenfels , linux-kernel@vger.kernel.org Cc: Andrew Morton , Dave Jones , Linus Torvalds , netdev@oss.sgi.com, Jeff Garzik Message-id: <200307051637.52252.jeffpc@optonline.net> MIME-version: 1.0 Content-type: Text/Plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline Content-description: clearsigned data User-Agent: KMail/1.5.2 References: X-archive-position: 3776 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeffpc@optonline.net Precedence: bulk X-list: netdev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 05 July 2003 15:58, Bernd Eckenfels wrote: > a reader like ifconfig can easyly work around this with multiple tries, but > incremeting those variables wont work that easy, and therefore needs a > lock, which will be a major pita. > > 64bit counters should be a result of lockless per-cpu network counters > (32bit) with some kind of async merging. This is going to make the structure huge - not only you have the 32-bit variables for every CPU, but you have one global set of 64-bit variables (possibly you will need a lock for the 64-bit vars.) Also another thing to consider is portability across architectures - we don't need all this code on 64-bit arches. On the other hand, per-cpu stats may possibly make up for the extra code - no cache bouncing, etc. > Or we wait till 64bit hardware is more common :) Hehe, the thing is, that when 64bits beecome more common you will have this huge number of unused x86 computers that people will: - - throw out - - donate - - convert to all sorts of "embedded" systems which need stable OS (read: Linux) (these include routers) So, x86 is here to stay for some time. Jeff. - -- The Moon is Waxing Crescent (36% of Full) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/BzcbwFP0+seVj/4RAuMHAJ9sN0E4OgsPeM09D6hbgM3boECLDwCbBDTP 6u8SSobW0+Y0oWq3H4koHd0= =Z89A -----END PGP SIGNATURE----- From greearb@candelatech.com Sat Jul 5 14:46:52 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jul 2003 14:46:57 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-074.evrtwa1.dsl-verizon.net [4.33.45.74]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h65Lkn2x032090 for ; Sat, 5 Jul 2003 14:46:52 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h65LkXKk002853; Sat, 5 Jul 2003 14:46:33 -0700 Message-ID: <3F074739.9090006@candelatech.com> Date: Sat, 05 Jul 2003 14:46:33 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Sipek CC: Linus Torvalds , Kernel Mailing List , Andrew Morton , Dave Jones , Jeff Garzik , netdev@oss.sgi.com Subject: Re: [PATCH - RFC] [1/5] 64-bit network statistics - generic net References: <200307051449.32934.jeffpc@optonline.net> In-Reply-To: <200307051449.32934.jeffpc@optonline.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3779 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Jeff Sipek wrote: > Using KB would give us additional 10 bits (making the overflow at 4 TB.) I > don't really like the idea of using MB, but the underlying idea is the same - > 20 more bits, making the limit 4 PB. > > What is the consensus on this way of solving the problem? I guess it could be useful for something like ifconfig, but serious applications will need more precision and should deal with wraps anyway (even on 64-bits, in my opinion..why have to fix bugs in 10 years because we were too lazy to take the 10 minutes to make it right now). Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From creatix@hipac.org Sat Jul 5 15:29:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jul 2003 15:29:09 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [62.67.200.157]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h65MT02x032496 for ; Sat, 5 Jul 2003 15:29:01 -0700 Received: (qmail 11005 invoked from network); 5 Jul 2003 22:22:19 -0000 Received: from unknown (HELO portal.lan) (134300@[80.138.229.66]) (envelope-sender ) by smtprelay02.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 5 Jul 2003 22:22:19 -0000 Received: from hipac.org (tmobile.lan [192.168.0.6]) by portal.lan (Postfix) with ESMTP id 16A084B07E; Sat, 5 Jul 2003 22:54:42 +0200 (CEST) Message-ID: <3F074F74.2090308@hipac.org> Date: Sun, 06 Jul 2003 00:21:40 +0200 From: Thomas Heinz Reply-To: Thomas Heinz User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 X-Accept-Language: de, en MIME-Version: 1.0 To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: tc stack overflow Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3780 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: creatix@hipac.org Precedence: bulk X-list: netdev Hi Have you already crashed your kernel today? No? Well, try this one: # tc qdisc add dev eth0 root handle 1: prio \ for i in `seq 500` ; do tc qdisc add dev eth0 \ parent $i:1 handle `expr $i + 1`: prio ; done ; \ ping 1.2.3.4 [replace eth0 by a device of your choice] I think some of you are aware of the problem but strangely I didn't find any mention on linux-kernel or linux-netdev or lartc. The problem is that the depth of the classification tree is not limited in any way and since for every qdisc the corresponding enqueue function is called we have a stack overflow here. IMO the problem could be fixed by adding a depth parameter to the enqueue function. This way the function can decide whether it is save to go deeper down the tree (maybe subject to a global policy). So, what do you think about the issue? Do you care? Regards, Thomas From romieu@fr.zoreil.com Sat Jul 5 15:55:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jul 2003 15:55:33 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h65MtQ2x000342 for ; Sat, 5 Jul 2003 15:55:27 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id h65LpWfI010947; Sat, 5 Jul 2003 23:51:32 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id h65LpVDx010946; Sat, 5 Jul 2003 23:51:31 +0200 Date: Sat, 5 Jul 2003 23:51:31 +0200 From: Francois Romieu To: Jeff Sipek Cc: Jeff Garzik , Bernd Eckenfels , linux-kernel@vger.kernel.org, Andrew Morton , Dave Jones , Linus Torvalds , netdev@oss.sgi.com Subject: Re: [PATCH - RFC] [1/5] 64-bit network statistics - generic net Message-ID: <20030705235131.A10511@electric-eye.fr.zoreil.com> References: <200307051637.52252.jeffpc@optonline.net> <3F0737D1.5090109@pobox.com> <200307051700.32533.jeffpc@optonline.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200307051700.32533.jeffpc@optonline.net>; from jeffpc@optonline.net on Sat, Jul 05, 2003 at 04:59:05PM -0400 X-archive-position: 3782 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 Jeff Sipek : [network counter overflow on 32 bits systems] > The thing is that x86 is here to stay for quite some time. Even if 64-bit > processors take over the market, you will have so many "old" computers that > can: > > - - be thrown out > - - donated to some institution > - - converted to routers, and other "embedded" systems > > Plus, they will be dirt cheap. - the PCI bus don't/won't/can't handle multiple 10 Gb/s adapters; - nobody sane would recycle x86 systems as core routers after having bought a few Gb/s link. -- Ueimor From greearb@candelatech.com Sat Jul 5 16:36:21 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jul 2003 16:36:28 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-074.evrtwa1.dsl-verizon.net [4.33.45.74]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h65NaK2x001026 for ; Sat, 5 Jul 2003 16:36:20 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h65Lf0Kk002164; Sat, 5 Jul 2003 14:41:03 -0700 Message-ID: <3F0745EC.1060204@candelatech.com> Date: Sat, 05 Jul 2003 14:41:00 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: Jeff Sipek , Bernd Eckenfels , linux-kernel@vger.kernel.org, Andrew Morton , Dave Jones , Linus Torvalds , netdev@oss.sgi.com Subject: Re: [PATCH - RFC] [1/5] 64-bit network statistics - generic net References: <200307051637.52252.jeffpc@optonline.net> <3F0737D1.5090109@pobox.com> In-Reply-To: <3F0737D1.5090109@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3783 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Jeff Garzik wrote: > The net stats are already unsigned long internally. > > 64-bit case is handled quite nicely today, thanks :) > > I'm such a 64-bit bigot that "buy a 64-bit computer" is a solution I > commonly suggest, and it seems to fit well here, too. > > Jeff, wondering if Intel will bother to compete w/ Athlon64 Untill the net-stats are 64-bit on 32-bit systems, we will need some way to know if they have wrapped or not when reading from nettool and getting 64-bit numbers. I guess what I really mean to say is that, if nettool is returning 64-bit values, we need to know which ones are obtained from 32-bit counters. 32 -> 64 bit mapping will require wrap handling on low 32-bits, but 64 -> 64 bit mapping will require wrapping about 4-billion times less often :) Perhaps a precision field is also needed for backwards/forwards compatability, and perhaps a nettool version field as well to also help with backwards/forwards compat. Ben > > > -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From romieu@fr.zoreil.com Sat Jul 5 16:45:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jul 2003 16:45:45 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h65Njd2x001206 for ; Sat, 5 Jul 2003 16:45:40 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id h65NiPfI011755; Sun, 6 Jul 2003 01:44:25 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id h65NiOmB011754; Sun, 6 Jul 2003 01:44:24 +0200 Date: Sun, 6 Jul 2003 01:44:23 +0200 From: Francois Romieu To: Jeff Sipek Cc: Jeff Garzik , Bernd Eckenfels , linux-kernel@vger.kernel.org, Andrew Morton , Dave Jones , Linus Torvalds , netdev@oss.sgi.com Subject: Re: [PATCH - RFC] [1/5] 64-bit network statistics - generic net Message-ID: <20030706014423.A11165@electric-eye.fr.zoreil.com> References: <200307051700.32533.jeffpc@optonline.net> <20030705235131.A10511@electric-eye.fr.zoreil.com> <200307051839.50327.jeffpc@optonline.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200307051839.50327.jeffpc@optonline.net>; from jeffpc@optonline.net on Sat, Jul 05, 2003 at 06:39:41PM -0400 X-archive-position: 3784 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 Jeff Sipek : [...] > P.S. I just looked up the cheapest gigabit copper I could find in 10 seconds, > and I found: D-Link DGE-500T for $36.27 this is just 4 times the price of the > cheapest fast ethernet I found on the same site (cdw.com - they are not the > cheapest, but I like them) Please google around on the topic "nanog/gigabit/routing/linux" and read netdev archive again. It isn't _that_ simple. -- Ueimor From alan@lxorguk.ukuu.org.uk Sun Jul 6 00:30:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Jul 2003 00:31:05 -0700 (PDT) Received: from lxorguk.ukuu.org.uk (pc2-cwma1-4-cust86.swan.cable.ntl.com [213.105.254.86]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h667UV2x004845 for ; Sun, 6 Jul 2003 00:30:34 -0700 Received: from dhcp22.swansea.linux.org.uk (dhcp22.swansea.linux.org.uk [127.0.0.1]) by lxorguk.ukuu.org.uk (8.12.8/8.12.5) with ESMTP id h667RIKd000765; Sun, 6 Jul 2003 08:27:18 +0100 Received: (from alan@localhost) by dhcp22.swansea.linux.org.uk (8.12.8/8.12.8/Submit) id h667REEW000763; Sun, 6 Jul 2003 08:27:14 +0100 X-Authentication-Warning: dhcp22.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: [PATCH - RFC] [1/5] 64-bit network statistics - generic net From: Alan Cox To: Ben Greear Cc: Jeff Garzik , Jeff Sipek , Bernd Eckenfels , Linux Kernel Mailing List , Andrew Morton , Dave Jones , Linus Torvalds , netdev@oss.sgi.com In-Reply-To: <3F0745EC.1060204@candelatech.com> References: <200307051637.52252.jeffpc@optonline.net> <3F0737D1.5090109@pobox.com> <3F0745EC.1060204@candelatech.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1057476433.700.2.camel@dhcp22.swansea.linux.org.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 06 Jul 2003 08:27:14 +0100 X-archive-position: 3786 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: netdev On Sad, 2003-07-05 at 22:41, Ben Greear wrote: > Untill the net-stats are 64-bit on 32-bit systems, we will need some > way to know if they have wrapped or not when reading from nettool > and getting 64-bit numbers. iptables Collecting the data on a need to know basis 8) From rol@as2917.net Sun Jul 6 02:43:42 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Jul 2003 02:43:46 -0700 (PDT) Received: from tag.witbe.net (IDENT:root@tag.witbe.net [81.88.96.48]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h669he2x009514 for ; Sun, 6 Jul 2003 02:43:41 -0700 Received: from fifi (APuteaux-102-1-1-241.w193-251.abo.wanadoo.fr [193.251.27.241]) by tag.witbe.net (8.11.0/8.11.0) with ESMTP id h669hVp08325; Sun, 6 Jul 2003 09:43:31 GMT From: "Paul Rolland" To: "'Chris Friesen'" , Cc: , , , Subject: Re: [BUG]: problem when shutting down ppp connection since 2.5.70 Date: Sun, 6 Jul 2003 11:43:30 +0200 Message-ID: <008201c343a3$0f9f8a70$2101a8c0@witbe> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <3F03BC55.6050506@nortelnetworks.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-archive-position: 3787 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rol@as2917.net Precedence: bulk X-list: netdev Hello, > Well, I've upgraded to the latest 2.5.74 kernel and pppd > version 2.4.2b3 > (still using the rp-pppoe userspace software though). > > Per Stephen's suggestion I also tried removing the ip address and > bringing down the ppp link before shuttind down the adsl connection. > > Makes no difference. > To complete on this topic : I've got the problem since 2.5.70, when netdev_wait_allrefs has been introduced in net/core/dev.c I have the same behavior using vtund, configured to create a tap0 interface. At shutdown time, the interface refuses to get freed and I'm stuck. Having vtund started at boot time (within the /etc/rc.d/... stuff) or later doesn't make any difference. Shutting down the interface before stopping the application or halting the machine doesn't make any difference either. The other problem is that the current implementation of netdev_wait_allrefs makes that if you kill an application that is using a device not correctly counted, you lock the console you are working on. e.g., killing vtund will create a printk(... unregister_netdevice...), and the console cannot be used anymore as long as the counter hasn't reached 0 and the device is freed... Paul From jmorris@intercode.com.au Sun Jul 6 05:43:30 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Jul 2003 05:43:36 -0700 (PDT) Received: from blackbird.intercode.com.au (IDENT:Y6eLAoDcGUlJvIAdPB8S+8iU7wcEA3WC@blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h66ChQ2x016252 for ; Sun, 6 Jul 2003 05:43:28 -0700 Received: from excalibur.intercode.com.au (excalibur.intercode.com.au [203.32.101.12]) by blackbird.intercode.com.au (8.11.6p2/8.9.3) with ESMTP id h66Cger08253; Sun, 6 Jul 2003 22:42:41 +1000 Date: Sun, 6 Jul 2003 22:42:40 +1000 (EST) From: James Morris To: "David S. Miller" cc: kuznet@ms2.inr.ac.ru, Subject: [PATCH] Don't call request_module() under spinlock in xfrm_get_type() Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3788 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@intercode.com.au Precedence: bulk X-list: netdev This patch fixes a problem where request_module() was being called under the lock taken in xfrm_policy_get_afinfo(). An alternative fix would be to refcount xfrm_policy_afinfo structs, either explicitly or via a module owner field, although it seems like overkill in this case. - James -- James Morris diff -urN -X dontdiff bk.orig/net/xfrm/xfrm_policy.c bk.w1/net/xfrm/xfrm_policy.c --- bk.orig/net/xfrm/xfrm_policy.c 2003-07-06 02:59:18.000000000 +1000 +++ bk.w1/net/xfrm/xfrm_policy.c 2003-07-06 22:32:47.230524746 +1000 @@ -80,22 +80,24 @@ struct xfrm_type *xfrm_get_type(u8 proto, unsigned short family) { - struct xfrm_policy_afinfo *afinfo = xfrm_policy_get_afinfo(family); + struct xfrm_policy_afinfo *afinfo; struct xfrm_type_map *typemap; struct xfrm_type *type; int modload_attempted = 0; +retry: + afinfo = xfrm_policy_get_afinfo(family); if (unlikely(afinfo == NULL)) return NULL; typemap = afinfo->type_map; -retry: read_lock(&typemap->lock); type = typemap->map[proto]; if (unlikely(type && !try_module_get(type->owner))) type = NULL; read_unlock(&typemap->lock); if (!type && !modload_attempted) { + xfrm_policy_put_afinfo(afinfo); request_module("xfrm-type-%d-%d", (int) family, (int) proto); modload_attempted = 1; From niv@us.ibm.com Sun Jul 6 13:27:47 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Jul 2003 13:27:54 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h66KRd2x020879 for ; Sun, 6 Jul 2003 13:27:46 -0700 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h66KRW8w286636; Sun, 6 Jul 2003 16:27:32 -0400 Received: from us.ibm.com (d03av03.boulder.ibm.com [9.17.193.83]) by westrelay03.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h66KRVcW131778; Sun, 6 Jul 2003 14:27:32 -0600 Message-ID: <3F08858E.8000907@us.ibm.com> Date: Sun, 06 Jul 2003 13:24:46 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: palbrecht@qwest.net CC: linux-kernel@vger.kernel.org, netdev Subject: Re: question about linux tcp request queue handling Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3789 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev > Linux (2.4.18) places incoming connection requests into the syn_recd state > when the server's backlog queue is full. I thought they were supposed to be > discarded if the server's backlog is full, forcing the client to > subsequently retransmit the request after it times out. Why does linux put > the server side into the syn_recd state when its backlog is full? Do you have tcp_syncookies on? And are you exceeding the len as configured by tcp_max_syn_backlog? thanks, Nivedita [Please cc or post to netdev, like most networking folk, dont subscribe to lkml] From palbrecht@qwest.net Sun Jul 6 15:15:38 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Jul 2003 15:15:53 -0700 (PDT) Received: from mpls-qmqp-02.inet.qwest.net (mpls-qmqp-02.inet.qwest.net [63.231.195.113]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h66MFb2x022394 for ; Sun, 6 Jul 2003 15:15:38 -0700 Received: (qmail 14687 invoked by uid 0); 6 Jul 2003 21:43:05 -0000 Received: from mpls-pop-14.inet.qwest.net (63.231.195.14) by mpls-qmqp-02.inet.qwest.net with QMQP; 6 Jul 2003 21:43:05 -0000 Received: from 0-1pool148-107.nas7.minneapolis1.mn.us.da.qwest.net (HELO oemcomputer) (67.4.148.107) by mpls-pop-14.inet.qwest.net with SMTP; 6 Jul 2003 22:15:36 -0000 Date: Sun, 6 Jul 2003 17:12:19 -0700 Message-ID: <001a01c3441c$6fe111a0$6801a8c0@oemcomputer> From: "Paul Albrecht" To: "Nivedita Singhvi" Cc: linux-kernel@vger.kernel.org, "netdev" References: <3F08858E.8000907@us.ibm.com> Subject: Re: question about linux tcp request queue handling MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-archive-position: 3790 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: palbrecht@qwest.net Precedence: bulk X-list: netdev Nivedita writes: > > Do you have tcp_syncookies on? > syncookies = 0. > >And are you exceeding the len as configured by tcp_max_syn_backlog? > max_syn_backlog = 256. My server program sets its backlog to one and pauses ninety seconds before accepting connections. Within that ninety second interval, I start three client programs that do an active open to my server. I expect one of connections to get discarded when the server's connection backlog limit is exceeded. From niv@us.ibm.com Sun Jul 6 17:03:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Jul 2003 17:03:40 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6702L2x023217 for ; Sun, 6 Jul 2003 17:03:02 -0700 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h6702Gxe248456; Sun, 6 Jul 2003 20:02:16 -0400 Received: from us.ibm.com (d03av03.boulder.ibm.com [9.17.193.83]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6702Ecu144700; Sun, 6 Jul 2003 18:02:15 -0600 Message-ID: <3F08B7E2.7040208@us.ibm.com> Date: Sun, 06 Jul 2003 16:59:30 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Albrecht CC: linux-kernel@vger.kernel.org, netdev Subject: Re: question about linux tcp request queue handling References: <3F08858E.8000907@us.ibm.com> <001a01c3441c$6fe111a0$6801a8c0@oemcomputer> In-Reply-To: <001a01c3441c$6fe111a0$6801a8c0@oemcomputer> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3791 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Paul Albrecht wrote: > My server program sets its backlog to one and pauses ninety seconds before > accepting connections. Within that ninety second interval, I start three > client programs that do an active open to my server. I expect one of > connections to get discarded when the server's connection backlog limit is > exceeded. We actually have two queues - the syn queue and the socket acccept queue. We move the connection request from the syn queue to the accept queue of the socket once the 3 way handshake is complete - i.e. once the state is ESTABLISHED. If the syn queue is full, requests will get dropped and the socket will not change state. When you set a the backlog to 1 in the listen call, what is being capped is the accept queue. So I would expect your server to allow only one of those requests in the accept queue, and the kernel will drop the other two requests. Actually, details, but we also apply some other conditions before we actually drop the connection request - we try not to be so harsh if the syn queue is still fairly empty.. Think thats so, at any rate :). Nivedita From palbrecht@qwest.net Sun Jul 6 21:24:01 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Jul 2003 21:24:13 -0700 (PDT) Received: from mpls-qmqp-03.inet.qwest.net (mpls-qmqp-03.inet.qwest.net [63.231.195.114]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h674O02x031556 for ; Sun, 6 Jul 2003 21:24:00 -0700 Received: (qmail 25532 invoked by uid 0); 7 Jul 2003 04:16:44 -0000 Received: from mpls-pop-11.inet.qwest.net (63.231.195.11) by mpls-qmqp-03.inet.qwest.net with QMQP; 7 Jul 2003 04:16:44 -0000 Received: from 0-1pool150-126.nas8.minneapolis1.mn.us.da.qwest.net (HELO oemcomputer) (67.4.150.126) by mpls-pop-11.inet.qwest.net with SMTP; 7 Jul 2003 04:23:59 -0000 Date: Sun, 6 Jul 2003 23:20:42 -0700 Message-ID: <000d01c3444f$e6439600$6801a8c0@oemcomputer> From: "Paul Albrecht" To: "Nivedita Singhvi" Cc: linux-kernel@vger.kernel.org, "netdev" References: <3F08858E.8000907@us.ibm.com> <001a01c3441c$6fe111a0$6801a8c0@oemcomputer> <3F08B7E2.7040208@us.ibm.com> Subject: Re: question about linux tcp request queue handling MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-archive-position: 3792 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: palbrecht@qwest.net Precedence: bulk X-list: netdev Nivedita Singhvi writes: > > When you set a the backlog to 1 in the listen call, what is > being capped is the accept queue. So I would expect your > server to allow only one of those requests in the accept > queue, and the kernel will drop the other two requests. > What you get when you set backlog to one is operating system dependent. Tracing the flows with tcpdump, I get two clean handshakes so presumeably, for linux, one means two. The third connection request *isn't* dropped; according to netstat, it's placed in the syn_recd state. I thought berkeley-derived implementations followed the rule that if there is no room on the backlog queue for the new connection, tcp ignored the the received syn. > > Actually, details, but we also apply some other conditions > before we actually drop the connection request - we try not to be > so harsh if the syn queue is still fairly empty.. > Irrespective of whatever conditions linux applies, how can the connection enter the syn_recd state if the backlog limit would be exceeded? What's the client supposed to do with the syn/ack from the server? What's the server supposed to do with the ack it get's back from the client? From niv@us.ibm.com Sun Jul 6 22:54:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Jul 2003 22:55:25 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h675s22x002118 for ; Sun, 6 Jul 2003 22:54:49 -0700 Received: from westrelay05.boulder.ibm.com (westrelay05.boulder.ibm.com [9.17.193.33]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h675rv8w189942; Mon, 7 Jul 2003 01:53:57 -0400 Received: from us.ibm.com (d03av03.boulder.ibm.com [9.17.193.83]) by westrelay05.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h675rtTl079362; Sun, 6 Jul 2003 23:53:56 -0600 Message-ID: <3F090A4F.10004@us.ibm.com> Date: Sun, 06 Jul 2003 22:51:11 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Albrecht CC: linux-kernel@vger.kernel.org, netdev Subject: Re: question about linux tcp request queue handling References: <3F08858E.8000907@us.ibm.com> <001a01c3441c$6fe111a0$6801a8c0@oemcomputer> <3F08B7E2.7040208@us.ibm.com> <000d01c3444f$e6439600$6801a8c0@oemcomputer> In-Reply-To: <000d01c3444f$e6439600$6801a8c0@oemcomputer> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3793 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Paul Albrecht wrote: >>When you set a the backlog to 1 in the listen call, what is >>being capped is the accept queue. So I would expect your >>server to allow only one of those requests in the accept >>queue, and the kernel will drop the other two requests. > What you get when you set backlog to one is operating system dependent. You asked about Linux 2.4.18, and I was speaking strictly for it. This is after all linux-netdev :). > Tracing the flows with tcpdump, I get two clean handshakes so presumeably, > for linux, one means two. The third connection request *isn't* dropped; Again, youre limiting the number of connnection requests that are allowed to wait in the *accept* queue, where we move to once we're ESTABLISHED. You arent limiting a request sitting in the SYN queue. > according to netstat, it's placed in the syn_recd state. I thought > berkeley-derived implementations followed the rule that if there is no room > on the backlog queue for the new connection, tcp ignored the the received > syn. >>Actually, details, but we also apply some other conditions >>before we actually drop the connection request - we try not to be >>so harsh if the syn queue is still fairly empty.. >> > > > Irrespective of whatever conditions linux applies, how can the connection > enter the syn_recd state if the backlog limit would be exceeded? What's the > client supposed to do with the syn/ack from the server? What's the server > supposed to do with the ack it get's back from the client? Er, complete the 3 way handshake? If the client gets the syn/ack, it should send a SYN in response, and move to ESTABLISHED state. If the server gets an ack back from the client, we process the ack. Our processing involves moving the request from the syn queue to the accept queue. Should the accept queue be full (which could occur anytime - eg it could have occurred *after* the server recvd this SYN) we would drop the request. Should the client then send data, it would get a RST, letting it know our side (srvr) has had to throw the connection away. Its quite possible that the accept queue clears and a request can be moved from the SYN queue to the accept queue in the interval of the handshake being completed (?) If we get a SYN, it doesn't seem unreasonable that we enter SYN_RCVD state :). thanks, Nivedita From niv@us.ibm.com Sun Jul 6 23:02:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Jul 2003 23:02:25 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6761w2x002503 for ; Sun, 6 Jul 2003 23:02:21 -0700 Received: from westrelay05.boulder.ibm.com (westrelay05.boulder.ibm.com [9.17.193.33]) by e34.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h6761pDG208178; Mon, 7 Jul 2003 02:01:51 -0400 Received: from us.ibm.com (d03av03.boulder.ibm.com [9.17.193.83]) by westrelay05.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6761nTl054060; Mon, 7 Jul 2003 00:01:49 -0600 Message-ID: <3F090C28.4080405@us.ibm.com> Date: Sun, 06 Jul 2003 22:59:04 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nivedita Singhvi CC: Paul Albrecht , linux-kernel@vger.kernel.org, netdev Subject: Re: question about linux tcp request queue handling References: <3F08858E.8000907@us.ibm.com> <001a01c3441c$6fe111a0$6801a8c0@oemcomputer> <3F08B7E2.7040208@us.ibm.com> <000d01c3444f$e6439600$6801a8c0@oemcomputer> <3F090A4F.10004@us.ibm.com> In-Reply-To: <3F090A4F.10004@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3794 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Nivedita Singhvi wrote: > Er, complete the 3 way handshake? If the client gets the syn/ack, it > should send a SYN in response, and move to ESTABLISHED state. If the ~~~ my bad, sorry, that should be ACK, of course... thanks, Nivedita From MAILER-DAEMON@oss.sgi.com Mon Jul 7 01:08:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jul 2003 01:08:25 -0700 (PDT) Received: from ns1.ryston.cz (ns1.ryston.cz [62.77.73.11]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6788F2x013419 for ; Mon, 7 Jul 2003 01:08:17 -0700 Received: (qmail 10210 invoked by uid 504); 7 Jul 2003 08:08:09 -0000 Date: 7 Jul 2003 08:08:09 -0000 From: "System Anti-Virus Administrator" To: netdev@oss.sgi.com Subject: virus found in sent message "Re: Movie" Message-ID: X-Tnz-Problem-Type: 40 MIME-Version: 1.0 Content-type: text/plain X-archive-position: 3795 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: postmaster@ryston.cz Precedence: bulk X-list: netdev Attention: netdev@oss.sgi.com A virus was found in an Email message you sent. This Email scanner intercepted it and stopped the entire message reaching its destination. The virus was reported to be: I-Worm.Sobig.e Please update your virus scanner or contact your IT support personnel as soon as possible as you have a virus on your system. Your message was sent with the following envelope: MAIL FROM: netdev@oss.sgi.com RCPT TO: petr@ryston.cz ... and with the following headers: --- MAILFROM: netdev@oss.sgi.com Received: from unknown (HELO ROCKYLU) (61.144.149.99) by ns1.ryston.cz with SMTP; 7 Jul 2003 08:07:47 -0000 From: To: Subject: Re: Movie Date: Mon, 7 Jul 2003 16:06:59 +0800 Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="CSmtpMsgPart123X456_000_0191A495" --- From kohei@cysols.com Mon Jul 7 04:37:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jul 2003 04:37:28 -0700 (PDT) Received: from geto.cysol.co.jp (geto.cysol.co.jp [210.233.3.227]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h67BbN2x024433 for ; Mon, 7 Jul 2003 04:37:24 -0700 Received: from cysols.com (agari2.priv.cysol.co.jp [192.168.0.249]) by geto.cysol.co.jp (8.12.9/3.7W) with ESMTP id h67BbKwQ007480 for ; Mon, 7 Jul 2003 20:37:21 +0900 (JST) Message-ID: <3F095B7B.5090203@cysols.com> Date: Mon, 07 Jul 2003 20:37:31 +0900 From: Kohei OHTA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: IP-ID field of ICMP echo request X-Enigmail-Version: 0.76.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3796 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kohei@cysols.com Precedence: bulk X-list: netdev Hi folks, I found a strange packet, which is generated by ping of Linux. It is observed ID field of IP header in ping packet (Echo request) is always 0. I confirmed this on kernel 2.4.18 and 2.4.21. My colleague also confirmed this is fixed in kernel 2.5.74. I hope this is fixed in next next 2.4.x release. I am sorry if this had been fixed already. #I am not member of this ML. #If you need any further information, please CC me. Regards, Kohei. From solt@dns.toxicfilms.tv Mon Jul 7 05:29:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jul 2003 05:29:46 -0700 (PDT) Received: from dns.toxicfilms.tv (postfix@dns.toxicfilms.tv [150.254.37.24]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h67CTW2x026104 for ; Mon, 7 Jul 2003 05:29:35 -0700 Received: by dns.toxicfilms.tv (Postfix, from userid 1000) id 60602309B3F; Mon, 7 Jul 2003 14:29:28 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by dns.toxicfilms.tv (Postfix) with ESMTP id 5F9A2187055E; Mon, 7 Jul 2003 14:29:28 +0200 (CEST) Date: Mon, 7 Jul 2003 14:29:28 +0200 (CEST) From: Maciej Soltysiak To: Kohei OHTA Cc: netdev@oss.sgi.com Subject: Re: IP-ID field of ICMP echo request In-Reply-To: <3F095B7B.5090203@cysols.com> Message-ID: References: <3F095B7B.5090203@cysols.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3797 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: solt@dns.toxicfilms.tv Precedence: bulk X-list: netdev > I found a strange packet, which is generated by ping of Linux. > It is observed ID field of IP header in ping packet (Echo request) is always 0. > > I confirmed this on kernel 2.4.18 and 2.4.21. > My colleague also confirmed this is fixed in kernel 2.5.74. > > I hope this is fixed in next next 2.4.x release. RFC 792 says: ... Identifier If code = 0, an identifier to aid in matching echos and replies, may be zero. ... I guess it is okay to have 0 as IPID. Regards, Maciej From yoshfuji@linux-ipv6.org Mon Jul 7 05:38:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jul 2003 05:38:40 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h67CcR2x026542 for ; Mon, 7 Jul 2003 05:38:29 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h67CdVBo006132; Mon, 7 Jul 2003 21:39:31 +0900 Date: Mon, 07 Jul 2003 21:39:30 +0900 (JST) Message-Id: <20030707.213930.07095787.yoshfuji@linux-ipv6.org> To: solt@dns.toxicfilms.tv Cc: kohei@cysols.com, netdev@oss.sgi.com Subject: Re: IP-ID field of ICMP echo request From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <3F095B7B.5090203@cysols.com> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3798 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article (at Mon, 7 Jul 2003 14:29:28 +0200 (CEST)), Maciej Soltysiak says: > > I found a strange packet, which is generated by ping of Linux. > > It is observed ID field of IP header in ping packet (Echo request) is always 0. > > > > I confirmed this on kernel 2.4.18 and 2.4.21. > > My colleague also confirmed this is fixed in kernel 2.5.74. > > > > I hope this is fixed in next next 2.4.x release. > RFC 792 says: > ... > Identifier > > If code = 0, an identifier to aid in matching echos and replies, > may be zero. > ... > > I guess it is okay to have 0 as IPID. No, he is not talking about ICMP Identifier (RFC792 Page 14), but IP Identification (RFC791 Page 29). --yoshfuji From solt@dns.toxicfilms.tv Mon Jul 7 05:48:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jul 2003 05:48:55 -0700 (PDT) Received: from dns.toxicfilms.tv (postfix@dns.toxicfilms.tv [150.254.37.24]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h67Cmh2x026907 for ; Mon, 7 Jul 2003 05:48:44 -0700 Received: by dns.toxicfilms.tv (Postfix, from userid 1000) id DB64A309B3F; Mon, 7 Jul 2003 14:48:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by dns.toxicfilms.tv (Postfix) with ESMTP id DAA0A187055E; Mon, 7 Jul 2003 14:48:41 +0200 (CEST) Date: Mon, 7 Jul 2003 14:48:41 +0200 (CEST) From: Maciej Soltysiak To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Cc: kohei@cysols.com, netdev@oss.sgi.com Subject: Re: IP-ID field of ICMP echo request In-Reply-To: <20030707.213930.07095787.yoshfuji@linux-ipv6.org> Message-ID: References: <3F095B7B.5090203@cysols.com> <20030707.213930.07095787.yoshfuji@linux-ipv6.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3799 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: solt@dns.toxicfilms.tv Precedence: bulk X-list: netdev > No, he is not talking about ICMP Identifier (RFC792 Page 14), > but IP Identification (RFC791 Page 29). Aah, yes, I misread. Sorry. Anyway I tested it on 2.4.2 and 2.4.18, 2.5.74 and 2.4.21, they set IP ID to 0. At first I thought it was that issue with early 2.4, but it seems it has been there for a while. > --yoshfuji Maciej From yoshfuji@linux-ipv6.org Mon Jul 7 06:10:04 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jul 2003 06:10:12 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h67DA32x027424 for ; Mon, 7 Jul 2003 06:10:04 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h67DBJBo006382; Mon, 7 Jul 2003 22:11:19 +0900 Date: Mon, 07 Jul 2003 22:11:19 +0900 (JST) Message-Id: <20030707.221119.105548240.yoshfuji@linux-ipv6.org> To: kohei@cysols.com CC: netdev@oss.sgi.com, solt@dns.toxicfilms.tv Subject: Re: IP-ID field of ICMP echo request From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20030707.213930.07095787.yoshfuji@linux-ipv6.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3800 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article (at Mon, 7 Jul 2003 14:48:41 +0200 (CEST)), Maciej Soltysiak says: > > No, he is not talking about ICMP Identifier (RFC792 Page 14), > > but IP Identification (RFC791 Page 29). > Aah, yes, I misread. Sorry. > > Anyway I tested it on 2.4.2 and 2.4.18, 2.5.74 and 2.4.21, they set IP ID > to 0. At first I thought it was that issue with early 2.4, but it seems it > has been there for a while. It seems linux-2.2.22 behaves similarly. Well..., I remember the DF bit. Kohei, add "-M dont" option (do not set DF flag) and we can see non-zero IPID, can't we? -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From linux_4ever@yahoo.com Mon Jul 7 07:03:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jul 2003 07:03:47 -0700 (PDT) Received: from web9602.mail.yahoo.com (web9602.mail.yahoo.com [216.136.129.181]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h67E3h2x028642 for ; Mon, 7 Jul 2003 07:03:44 -0700 Message-ID: <20030707140343.14852.qmail@web9602.mail.yahoo.com> Received: from [207.69.99.207] by web9602.mail.yahoo.com via HTTP; Mon, 07 Jul 2003 07:03:43 PDT Date: Mon, 7 Jul 2003 07:03:43 -0700 (PDT) From: Steve G Subject: Unaccepted Connections To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 3801 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linux_4ever@yahoo.com Precedence: bulk X-list: netdev Hello, I have a user space programming question and need some ideas from networking gurus. I am working on a well known inet daemon that listens for tcp connections and passes the descriptor returned by listen() to a child program to handle in the tcp/wait mode. It turns out that many child programs error during their startup and exit without accepting the connection (linuxconf is one of them). The daemon that listens sees the descriptor as readable and starts a new child...which dies. This can loop forever. The questions are: 1) How can a parent process reliably determine that its child has indeed accepted the connection? (ptrace is not a good solution.) 2) Is it possible to tell anything about a connection that has returned from listen but not yet accepted? For instance the source IP address? Or checksum? Can recvfrom PEEK into the packet? Thanks, Steve Grubb __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From kaber@trash.net Mon Jul 7 07:05:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jul 2003 07:06:02 -0700 (PDT) Received: from gw.localnet (port-212-202-52-167.reverse.qsc.de [212.202.52.167]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h67E5q2x029014 for ; Mon, 7 Jul 2003 07:05:53 -0700 Received: from ws.localnet ([192.168.0.23] helo=trash.net) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 19ZWbe-0002RM-00; Mon, 07 Jul 2003 16:04:38 +0200 Message-ID: <3F097E4D.1080707@trash.net> Date: Mon, 07 Jul 2003 16:06:05 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030618 Debian/1.3.1-3 X-Accept-Language: en MIME-Version: 1.0 To: Linux Kernel Mailing List CC: netdev@oss.sgi.com Subject: RFC: another approach for 64-bit network stats Content-Type: multipart/mixed; boundary="------------050706090100050808080106" X-archive-position: 3802 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. --------------050706090100050808080106 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This patch implements a lockless aproach for 64-bit netstatistics with only a very rare racecondition. On 64 bit system, nothing is changed. On 32 bit system the (32bit) counter is checked periodically for overflows. The overflows are saved in counter_high. To detect overflows, we need to save the counter value when last checked (counter_last), so there is a 4byte overhead per 64bit counter. The 32-bit values can be accessed as before through stats->counter, the 64bit values are accessed through a macro NETSTAT64(stats, counter). Accessing the 64bit values contains the before mentioned race-condition, when the counters are synced while they are read and an overflow occured the value could be of 4gb. However the next read will return the correct value and with gigabit speed we only need to sync every ~30s, so thats much better than racing on every counter update (using 64bit counters directly) and potentially damaging the counter permanently. The race could be avoided by locking syncs and reads (not normal counter updates). The patch only breaks binary interfaces, all in-kernel users can continue to use the 32bit values until they have been changed, userspace software just needs recompilation, device drivers don't need any changes at all. Comments ? Bye, Patrick --------------050706090100050808080106 Content-Type: text/plain; name="netstats64.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netstats64.diff" ===== include/linux/netdevice.h 1.45 vs edited ===== --- 1.45/include/linux/netdevice.h Wed Jul 2 09:20:08 2003 +++ edited/include/linux/netdevice.h Mon Jul 7 15:09:05 2003 @@ -91,41 +91,83 @@ #endif /* + * Macros for lockless 64 bit netdevice statistics. On 32-bit arches + * the counter is checked periodically for overflows. The overflows + * are carried in name_high. The updates are not atomic, there is a + * race between updating and reading the counters, however this is a + * very rare condition. + */ + +#if (BITS_PER_LONG == 64) + +#define DECLARE_NETSTAT64(name) \ + unsigned long name +#define NETSTAT64(stats, name) \ + ((unsigned long long)(stats)->name) + +#else + +#define DECLARE_NETSTAT64(name) \ + unsigned long name; \ + unsigned long name##_high; \ + unsigned long name##_last + +#define NETSTAT64(stats, name) \ +({ \ + unsigned long cnt = (stats)->name; \ + int carry = (stats)->name##_last > cnt; \ + ((unsigned long long)((stats)->name##_high + carry) << 32 | cnt); \ +}) + +#define NETSTAT64_SYNC(stats, name) \ +do { \ + unsigned long cnt = (stats)->name; \ + if ((stats)->name##_last > cnt) \ + (stats)->name##_high++; \ + (stats)->name##_last = cnt; \ +} while(0) + +/* 32bit overflow about every 34s at full gigabit speed */ +#define NETSTATS64_SYNC_INTERVAL 30 + +#endif + +/* * Network device statistics. Akin to the 2.0 ether stats but * with byte counters. */ struct net_device_stats { - unsigned long rx_packets; /* total packets received */ - unsigned long tx_packets; /* total packets transmitted */ - unsigned long rx_bytes; /* total bytes received */ - unsigned long tx_bytes; /* total bytes transmitted */ - unsigned long rx_errors; /* bad packets received */ - unsigned long tx_errors; /* packet transmit problems */ - unsigned long rx_dropped; /* no space in linux buffers */ - unsigned long tx_dropped; /* no space available in linux */ - unsigned long multicast; /* multicast packets received */ - unsigned long collisions; + DECLARE_NETSTAT64(rx_packets); /* total packets received */ + DECLARE_NETSTAT64(tx_packets); /* total packets transmitted */ + DECLARE_NETSTAT64(rx_bytes); /* total bytes received */ + DECLARE_NETSTAT64(tx_bytes); /* total bytes transmitted */ + DECLARE_NETSTAT64(rx_errors); /* bad packets received */ + DECLARE_NETSTAT64(tx_errors); /* packet transmit problems */ + DECLARE_NETSTAT64(rx_dropped); /* no space in linux buffers */ + DECLARE_NETSTAT64(tx_dropped); /* no space available in linux */ + DECLARE_NETSTAT64(multicast); /* multicast packets received */ + DECLARE_NETSTAT64(collisions); /* detailed rx_errors: */ - unsigned long rx_length_errors; - unsigned long rx_over_errors; /* receiver ring buff overflow */ - unsigned long rx_crc_errors; /* recved pkt with crc error */ - unsigned long rx_frame_errors; /* recv'd frame alignment error */ - unsigned long rx_fifo_errors; /* recv'r fifo overrun */ - unsigned long rx_missed_errors; /* receiver missed packet */ + DECLARE_NETSTAT64(rx_length_errors); + DECLARE_NETSTAT64(rx_over_errors); /* receiver ring buff overflow */ + DECLARE_NETSTAT64(rx_crc_errors); /* recved pkt with crc error */ + DECLARE_NETSTAT64(rx_frame_errors); /* recv'd frame alignment error */ + DECLARE_NETSTAT64(rx_fifo_errors); /* recv'r fifo overrun */ + DECLARE_NETSTAT64(rx_missed_errors); /* receiver missed packet */ /* detailed tx_errors */ - unsigned long tx_aborted_errors; - unsigned long tx_carrier_errors; - unsigned long tx_fifo_errors; - unsigned long tx_heartbeat_errors; - unsigned long tx_window_errors; + DECLARE_NETSTAT64(tx_aborted_errors); + DECLARE_NETSTAT64(tx_carrier_errors); + DECLARE_NETSTAT64(tx_fifo_errors); + DECLARE_NETSTAT64(tx_heartbeat_errors); + DECLARE_NETSTAT64(tx_window_errors); /* for cslip etc */ - unsigned long rx_compressed; - unsigned long tx_compressed; + DECLARE_NETSTAT64(rx_compressed); + DECLARE_NETSTAT64(tx_compressed); }; ===== net/core/dev.c 1.89 vs edited ===== --- 1.89/net/core/dev.c Thu Jul 3 09:32:44 2003 +++ edited/net/core/dev.c Mon Jul 7 13:53:38 2003 @@ -1869,23 +1870,33 @@ struct net_device_stats *stats = dev->get_stats ? dev->get_stats(dev) : NULL; if (stats) - seq_printf(seq, "%6s:%8lu %7lu %4lu %4lu %4lu %5lu %10lu %9lu " - "%8lu %7lu %4lu %4lu %4lu %5lu %7lu %10lu\n", - dev->name, stats->rx_bytes, stats->rx_packets, - stats->rx_errors, - stats->rx_dropped + stats->rx_missed_errors, - stats->rx_fifo_errors, - stats->rx_length_errors + stats->rx_over_errors + - stats->rx_crc_errors + stats->rx_frame_errors, - stats->rx_compressed, stats->multicast, - stats->tx_bytes, stats->tx_packets, - stats->tx_errors, stats->tx_dropped, - stats->tx_fifo_errors, stats->collisions, - stats->tx_carrier_errors + - stats->tx_aborted_errors + - stats->tx_window_errors + - stats->tx_heartbeat_errors, - stats->tx_compressed); + seq_printf(seq, "%6s:%8llu %7llu %4llu %4llu %4llu %5llu " + "%10llu %9llu %8llu %7llu %4llu %4llu %4llu " + "%5llu %7llu %10llu\n", + dev->name, + NETSTAT64(stats, rx_bytes), + NETSTAT64(stats, rx_packets), + NETSTAT64(stats, rx_errors), + NETSTAT64(stats, rx_dropped) + + NETSTAT64(stats, rx_missed_errors), + NETSTAT64(stats, rx_fifo_errors), + NETSTAT64(stats, rx_length_errors) + + NETSTAT64(stats, rx_over_errors) + + NETSTAT64(stats, rx_crc_errors) + + NETSTAT64(stats, rx_frame_errors), + NETSTAT64(stats, rx_compressed), + NETSTAT64(stats, multicast), + NETSTAT64(stats, tx_bytes), + NETSTAT64(stats, tx_packets), + NETSTAT64(stats, tx_errors), + NETSTAT64(stats, tx_dropped), + NETSTAT64(stats, tx_fifo_errors), + NETSTAT64(stats, collisions), + NETSTAT64(stats, tx_carrier_errors) + + NETSTAT64(stats, tx_aborted_errors) + + NETSTAT64(stats, tx_window_errors) + + NETSTAT64(stats, tx_heartbeat_errors), + NETSTAT64(stats, tx_compressed)); else seq_printf(seq, "%6s: No statistics available.\n", dev->name); } @@ -2943,6 +2954,56 @@ return 0; } +#if (BITS_PER_LONG != 64) +static void netstats64_sync_work(void *); +static DECLARE_WORK(netstats64_work, netstats64_sync_work, NULL); + +static inline void netstats64_schedule_work(void) +{ + schedule_delayed_work(&netstats64_work, NETSTATS64_SYNC_INTERVAL * HZ); +} + +static void netstats64_sync_work(void *data) +{ + struct net_device *dev; + struct net_device_stats *stats; + + read_lock_bh(&dev_base_lock); + for (dev = dev_base; dev; dev = dev->next) { + stats = dev->get_stats ? dev->get_stats(dev) : NULL; + if (!stats) + continue; + NETSTAT64_SYNC(stats, rx_packets); + NETSTAT64_SYNC(stats, tx_packets); + NETSTAT64_SYNC(stats, rx_bytes); + NETSTAT64_SYNC(stats, tx_bytes); + NETSTAT64_SYNC(stats, rx_errors); + NETSTAT64_SYNC(stats, tx_errors); + NETSTAT64_SYNC(stats, rx_dropped); + NETSTAT64_SYNC(stats, tx_dropped); + NETSTAT64_SYNC(stats, multicast); + NETSTAT64_SYNC(stats, collisions); + + NETSTAT64_SYNC(stats, rx_length_errors); + NETSTAT64_SYNC(stats, rx_over_errors); + NETSTAT64_SYNC(stats, rx_crc_errors); + NETSTAT64_SYNC(stats, rx_frame_errors); + NETSTAT64_SYNC(stats, rx_fifo_errors); + NETSTAT64_SYNC(stats, rx_missed_errors); + + NETSTAT64_SYNC(stats, tx_aborted_errors); + NETSTAT64_SYNC(stats, tx_carrier_errors); + NETSTAT64_SYNC(stats, tx_fifo_errors); + NETSTAT64_SYNC(stats, tx_heartbeat_errors); + NETSTAT64_SYNC(stats, tx_window_errors); + + NETSTAT64_SYNC(stats, rx_compressed); + NETSTAT64_SYNC(stats, tx_compressed); + } + read_unlock_bh(&dev_base_lock); + netstats64_schedule_work(); +} +#endif /* * Initialize the DEV module. At boot time this walks the device list and @@ -3082,6 +3143,9 @@ #ifdef CONFIG_NET_SCHED pktsched_init(); +#endif +#if (BITS_PER_LONG != 64) + netstats64_schedule_work(); #endif rc = 0; out: ===== net/core/net-sysfs.c 1.7 vs edited ===== --- 1.7/net/core/net-sysfs.c Sun Jun 15 10:21:46 2003 +++ edited/net/core/net-sysfs.c Mon Jul 7 13:57:11 2003 @@ -184,9 +184,9 @@ ssize_t (*store)(struct net_device_stats *, const char *, size_t); }; -static ssize_t net_device_stat_show(unsigned long var, char *buf) +static ssize_t net_device_stat_show(unsigned long long var, char *buf) { - return sprintf(buf, "%ld\n", var); + return sprintf(buf, "%lld\n", var); } /* generate a read-only statistics attribute */ @@ -194,7 +194,7 @@ static ssize_t show_stat_##_NAME(const struct net_device_stats *stats, \ char *buf) \ { \ - return net_device_stat_show(stats->_NAME, buf); \ + return net_device_stat_show(NETSTAT64(stats, _NAME), buf); \ } \ static struct netstat_fs_entry net_stat_##_NAME = { \ .attr = {.name = __stringify(_NAME), .mode = S_IRUGO }, \ --------------050706090100050808080106-- From garzik@gtf.org Mon Jul 7 07:30:19 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jul 2003 07:30:58 -0700 (PDT) Received: from havoc.gtf.org (host-64-213-145-173.atlantasolutions.com [64.213.145.173] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h67EUH2x029935 for ; Mon, 7 Jul 2003 07:30:18 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id C9605664E; Mon, 7 Jul 2003 10:30:11 -0400 (EDT) Date: Mon, 7 Jul 2003 10:30:11 -0400 From: Jeff Garzik To: Patrick McHardy Cc: Linux Kernel Mailing List , netdev@oss.sgi.com Subject: Re: RFC: another approach for 64-bit network stats Message-ID: <20030707143011.GA14787@gtf.org> References: <3F097E4D.1080707@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F097E4D.1080707@trash.net> User-Agent: Mutt/1.3.28i X-archive-position: 3803 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 If you don't want to poll periodically for network stats, as has been repeatedly suggested, you can always poll periodically for the 64-bit NIC-specific stats that most gige adapters provide these days, using ethtool. NIC-specific stats also tend to provide more fine granularity than the current net_device_stats members. Jeff From greearb@candelatech.com Mon Jul 7 09:53:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jul 2003 09:53:33 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-074.evrtwa1.dsl-verizon.net [4.33.45.74]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h67GrN2x032570 for ; Mon, 7 Jul 2003 09:53:24 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h67GrIKk021734; Mon, 7 Jul 2003 09:53:18 -0700 Message-ID: <3F09A57D.8030003@candelatech.com> Date: Mon, 07 Jul 2003 09:53:17 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Patrick McHardy CC: Linux Kernel Mailing List , netdev@oss.sgi.com Subject: Re: RFC: another approach for 64-bit network stats References: <3F097E4D.1080707@trash.net> In-Reply-To: <3F097E4D.1080707@trash.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3804 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Patrick McHardy wrote: > This patch implements a lockless aproach for 64-bit netstatistics with > only a very rare > racecondition. On 64 bit system, nothing is changed. On 32 bit system I think that you should consider providing a new API as opposed to breaking existing APIs. And, perhaps this new API could deal with the very rare race to make it never happen? No matter how rare it is, you still have to write code to work around it if it exists..might as well do it once in the kernel instead of making each user of the interface deal with it. Personally, I'd like to see the net-device stats (64-bit or otherwise) available through the ethtool interface in a well defined binary package (perhaps a struct net_device_stats, or similar.) Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From jeffpc@optonline.net Mon Jul 7 10:34:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jul 2003 10:34:12 -0700 (PDT) Received: from mta9.srv.hcvlny.cv.net (mta9.srv.hcvlny.cv.net [167.206.5.42]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h67HY12x000816 for ; Mon, 7 Jul 2003 10:34:02 -0700 Received: from asv7.srv.hcvlny.cv.net (asv7.srv.hcvlny.cv.net [167.206.5.43]) by mta9.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HHO00I0V0RZAL@mta9.srv.hcvlny.cv.net> for netdev@oss.sgi.com; Mon, 07 Jul 2003 13:33:36 -0400 (EDT) Received: from jeff.home (ool-44c2049f.dyn.optonline.net [68.194.4.159]) by asv7.srv.hcvlny.cv.net (8.12.9/8.12.9) with ESMTP id h67HXjMP010298; Mon, 07 Jul 2003 13:33:48 -0400 (EDT) Date: Mon, 07 Jul 2003 13:33:43 -0400 From: Jeff Sipek Subject: Re: RFC: another approach for 64-bit network stats In-reply-to: <3F09A57D.8030003@candelatech.com> To: Ben Greear , Patrick McHardy Cc: Linux Kernel Mailing List , netdev@oss.sgi.com Message-id: <200307071333.48179.jeffpc@optonline.net> MIME-version: 1.0 Content-type: Text/Plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline Content-description: clearsigned data User-Agent: KMail/1.5.2 References: <3F097E4D.1080707@trash.net> <3F09A57D.8030003@candelatech.com> X-archive-position: 3805 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeffpc@optonline.net Precedence: bulk X-list: netdev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 07 July 2003 12:53, Ben Greear wrote: > I think that you should consider providing a new API as opposed to > breaking existing APIs. Do you mean reworking the network statistics side of networking? Jeff. - -- Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Ca77wFP0+seVj/4RArtOAJwNVhV9PNgyli/d93n4ocCaRZzxmACeMdr8 9W0vfMOt76DNXq2t4Phoye0= =8LGV -----END PGP SIGNATURE----- From alex@pilosoft.com Mon Jul 7 11:07:32 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jul 2003 11:07:38 -0700 (PDT) Received: from paix.pilosoft.com ([216.66.12.246]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h67I7V2x001519 for ; Mon, 7 Jul 2003 11:07:31 -0700 Received: from localhost (alex@localhost) by paix.pilosoft.com (8.11.6/8.11.6) with ESMTP id h67H3Se05912 for ; Mon, 7 Jul 2003 13:03:28 -0400 Date: Mon, 7 Jul 2003 13:03:27 -0400 (EDT) From: alex@pilosoft.com To: netdev@oss.sgi.com Subject: route-cache status? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3806 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alex@pilosoft.com Precedence: bulk X-list: netdev Hello, i've been following discussions a few weeks ago regarding developments of route cache, and am trying to develop conclusion of the current best code base. From list, it seems that 2.4.20 is still better than 2.5.70+davem patches or 2.4.21. Am I correct? Are there any newer patches available? -alex From ra993482@ic.unicamp.br Mon Jul 7 12:07:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jul 2003 12:07:19 -0700 (PDT) Received: from itaqui.terra.com.br (itaqui.terra.com.br [200.176.3.19]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h67J732x002225 for ; Mon, 7 Jul 2003 12:07:03 -0700 Received: from tucuriba.terra.com.br (tucuriba.terra.com.br [200.176.3.53]) by itaqui.terra.com.br (Postfix) with ESMTP id 576D6810505; Mon, 7 Jul 2003 15:39:12 -0300 (BRT) Received: from ryback.home.net (unknown [200.232.206.224]) (authenticated user macwad) by tucuriba.terra.com.br (Postfix) with ESMTP id CB06D2641EC; Mon, 7 Jul 2003 15:39:10 -0300 (BRT) Subject: Re: IP-ID field of ICMP echo request From: Ulisses To: Kohei OHTA Cc: netdev@oss.sgi.com In-Reply-To: <3F095B7B.5090203@cysols.com> References: <3F095B7B.5090203@cysols.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-9.7x.1) Date: 07 Jul 2003 15:40:36 -0300 Message-Id: <1057603237.1001.18.camel@ryback> Mime-Version: 1.0 X-archive-position: 3807 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ra993482@ic.unicamp.br Precedence: bulk X-list: netdev On Mon, 2003-07-07 at 08:37, Kohei OHTA wrote: > I found a strange packet, which is generated by ping of Linux. > It is observed ID field of IP header in ping packet (Echo request) is always 0. > > I confirmed this on kernel 2.4.18 and 2.4.21. > My colleague also confirmed this is fixed in kernel 2.5.74. > > I hope this is fixed in next next 2.4.x release. Hi, Kohei, I guess this behaviour is to prevent Idle scanning, that is based on predictable IPID numbers [1]. Therefore, the Linux TCP/IP stack uses 0 as IPID when the DF (Don't Fragment) bit is set. I'm not sure, but I think that Linux also uses peer-specific IPID numbers to make the prediction harder. -- Ulisses [1] http://www.insecure.org/nmap/idlescan.html From pekkas@netcore.fi Mon Jul 7 12:40:11 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jul 2003 12:40:16 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h67Je92x006123 for ; Mon, 7 Jul 2003 12:40:11 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h67Je3716261 for ; Mon, 7 Jul 2003 22:40:03 +0300 Date: Mon, 7 Jul 2003 22:40:02 +0300 (EEST) From: Pekka Savola To: netdev@oss.sgi.com Subject: disablenetwork() syscall? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3808 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev Hi, In a bugtraq thread, DJ Bernstein brought up an idea which I'm not sure has been brought up in the past. I'm not sure whether it's feasible or not, but at least it (and other methods to limit the functions of a user-level code) might bear consideration. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ---------- Forwarded message ---------- Date: 4 Jul 2003 23:17:20 -0000 From: D. J. Bernstein To: bugtraq@securityfocus.com Subject: Re: Email marketing company gives out questionable security advice [...] P.S. It's hard for a portable chroot tool to cut off a program's network access. Kernel designers should provide a disablenetwork() syscall, with the disabling inherited by children. Other kernel changes would be nice, but disablenetwork() is the only critical change. From garzik@gtf.org Mon Jul 7 12:47:05 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jul 2003 12:47:09 -0700 (PDT) Received: from havoc.gtf.org (host-64-213-145-173.atlantasolutions.com [64.213.145.173] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h67Jl32x006478 for ; Mon, 7 Jul 2003 12:47:05 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id EE0936652; Mon, 7 Jul 2003 15:46:57 -0400 (EDT) Date: Mon, 7 Jul 2003 15:46:57 -0400 From: Jeff Garzik To: Pekka Savola Cc: netdev@oss.sgi.com Subject: Re: disablenetwork() syscall? Message-ID: <20030707194657.GA11328@gtf.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-archive-position: 3809 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev On Mon, Jul 07, 2003 at 10:40:02PM +0300, Pekka Savola wrote: > In a bugtraq thread, DJ Bernstein brought up an idea which I'm not sure > has been brought up in the past. I'm not sure whether it's feasible or > not, but at least it (and other methods to limit the functions of a > user-level code) might bear consideration. What about some URLs to what you are describing? The most information you provided was in $subject, whose content makes me a bit leery... Jeff From pekkas@netcore.fi Mon Jul 7 12:52:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jul 2003 12:52:32 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h67JqP2x006946 for ; Mon, 7 Jul 2003 12:52:26 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h67JqFR16467; Mon, 7 Jul 2003 22:52:15 +0300 Date: Mon, 7 Jul 2003 22:52:15 +0300 (EEST) From: Pekka Savola To: Jeff Garzik cc: netdev@oss.sgi.com Subject: Re: disablenetwork() syscall? In-Reply-To: <20030707194657.GA11328@gtf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3810 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev On Mon, 7 Jul 2003, Jeff Garzik wrote: > On Mon, Jul 07, 2003 at 10:40:02PM +0300, Pekka Savola wrote: > > In a bugtraq thread, DJ Bernstein brought up an idea which I'm not sure > > has been brought up in the past. I'm not sure whether it's feasible or > > not, but at least it (and other methods to limit the functions of a > > user-level code) might bear consideration. > > What about some URLs to what you are describing? > > The most information you provided was in $subject, whose content > makes me a bit leery... Well, apart from the post scriptum, there was very little content about the feature/idea :-), and the details would seem to be up for everyone's imagination. FWIW, the body of the message is below: ===== Richard M. Smith writes: [ mail readers disabling inline images ] > It will be interesting to see how email marketing companies and > spammers adapt to these technical changes in HTML email. ASCII porn, perhaps? Especially if the sender can control the color, and size, of text. I suppose those will be the next casualties in the war on spam. It's quite depressing that this is what people think of as ``security'': patch maniacally; install a scanner that checks for yesterday's attacks; don't view the pictures, don't drink the water, don't breathe the air. I've been playing with a radically different system design (I'm thinking of calling it ``UNIX'') where conceptually separate tasks are split into separate processes. If you want to gunzip a stream of data, for example, you run a gunzip program in its own chroot jail, under its own uid, with no way to read any interesting data except through a predefined IPC hook (I'm thinking of calling that a ``pipe'' on ``standard input'') and with no way to touch anything except through another predefined IPC hook. The only thing that an attacker can do by taking over this gunzip program is generate arbitrary output data, which he could have done anyway. Typical picture-generating programs can be isolated in the same way. ==== -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From mitch@sfgoth.com Mon Jul 7 13:57:56 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jul 2003 13:58:03 -0700 (PDT) Received: from gaz.sfgoth.com ([63.205.85.133]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h67Kvt2x007783 for ; Mon, 7 Jul 2003 13:57:56 -0700 Received: from gaz.sfgoth.com (localhost.sfgoth.com [127.0.0.1]) by gaz.sfgoth.com (8.12.6p2/8.12.6) with ESMTP id h67L3Alx022365; Mon, 7 Jul 2003 14:03:10 -0700 (PDT) (envelope-from mitch@gaz.sfgoth.com) Received: (from mitch@localhost) by gaz.sfgoth.com (8.12.6p2/8.12.6/Submit) id h67L3Amn022364; Mon, 7 Jul 2003 14:03:10 -0700 (PDT) (envelope-from mitch) Date: Mon, 7 Jul 2003 14:03:10 -0700 From: Mitchell Blank Jr To: Pekka Savola Cc: netdev@oss.sgi.com Subject: Re: disablenetwork() syscall? Message-ID: <20030707210310.GA21759@gaz.sfgoth.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-archive-position: 3811 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mitch@sfgoth.com Precedence: bulk X-list: netdev Pekka Savola wrote: > In a bugtraq thread, DJ Bernstein brought up an idea which I'm not sure > has been brought up in the past. I'm not sure whether it's feasible or > not, but at least it (and other methods to limit the functions of a > user-level code) might bear consideration. It sounds like something that could be a implemented as a capability (CAP_NET_ACCESS or such) -Mitch From palbrecht@qwest.net Mon Jul 7 14:34:07 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jul 2003 14:34:19 -0700 (PDT) Received: from mpls-qmqp-03.inet.qwest.net (mpls-qmqp-03.inet.qwest.net [63.231.195.114]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h67LY62x008454 for ; Mon, 7 Jul 2003 14:34:07 -0700 Received: (qmail 21795 invoked by uid 0); 7 Jul 2003 21:26:47 -0000 Received: from mpls-pop-07.inet.qwest.net (63.231.195.7) by mpls-qmqp-03.inet.qwest.net with QMQP; 7 Jul 2003 21:26:47 -0000 Received: from 0-1pool152-236.nas9.minneapolis1.mn.us.da.qwest.net (HELO oemcomputer) (67.4.152.236) by mpls-pop-07.inet.qwest.net with SMTP; 7 Jul 2003 21:34:05 -0000 Date: Mon, 7 Jul 2003 16:30:47 -0700 Message-ID: <001401c344df$ccbc63c0$6801a8c0@oemcomputer> From: "Paul Albrecht" To: "Nivedita Singhvi" Cc: linux-kernel@vger.kernel.org, "netdev" References: <3F08858E.8000907@us.ibm.com> <001a01c3441c$6fe111a0$6801a8c0@oemcomputer> <3F08B7E2.7040208@us.ibm.com> <000d01c3444f$e6439600$6801a8c0@oemcomputer> <3F090A4F.10004@us.ibm.com> Subject: Re: question about linux tcp request queue handling MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-archive-position: 3812 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: palbrecht@qwest.net Precedence: bulk X-list: netdev Nivedita Singhvi writes: > > Again, youre limiting the number of connnection requests > that are allowed to wait in the *accept* queue, where > we move to once we're ESTABLISHED. You arent limiting > a request sitting in the SYN queue. > This statement is inconsistent with the description of this scenario in Steven's TCP/IP Illustrated. Specifically, continuing the handshake in the TCP layer, i.e., sending a syn/ack and moving to the syn_recd state, is incorrect if the limit of the server's socket backlog would be exceeded. How do you account for this discrepancy between linux and other berkeley-derived implementations? From ak@suse.de Mon Jul 7 14:48:21 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jul 2003 14:48:25 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h67LmH2x008869 for ; Mon, 7 Jul 2003 14:48:20 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id E33DF15089; Mon, 7 Jul 2003 23:48:11 +0200 (MEST) X-Authentication-Warning: oldwotan.suse.de: ak set sender to ak@suse.de using -f To: "Paul Albrecht" Cc: niv@us.ibm.com, linux-kernel@vger.kernel.org, "netdev" Subject: Re: question about linux tcp request queue handling References: <3F08858E.8000907@us.ibm.com.suse.lists.linux.kernel> <001a01c3441c$6fe111a0$6801a8c0@oemcomputer.suse.lists.linux.kernel> <3F08B7E2.7040208@us.ibm.com.suse.lists.linux.kernel> <000d01c3444f$e6439600$6801a8c0@oemcomputer.suse.lists.linux.kernel> <3F090A4F.10004@us.ibm.com.suse.lists.linux.kernel> <001401c344df$ccbc63c0$6801a8c0@oemcomputer.suse.lists.linux.kernel> From: Andi Kleen Date: 07 Jul 2003 23:48:10 +0200 In-Reply-To: <001401c344df$ccbc63c0$6801a8c0@oemcomputer.suse.lists.linux.kernel> Message-ID: Lines: 14 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 3813 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 "Paul Albrecht" writes: > This statement is inconsistent with the description of this scenario in > Steven's TCP/IP Illustrated. Specifically, continuing the handshake in the > TCP layer, i.e., sending a syn/ack and moving to the syn_recd state, is > incorrect if the limit of the server's socket backlog would be exceeded. > How do you account for this discrepancy between linux and other > berkeley-derived implementations? The 4.4BSD-Lite code described in Stevens is long outdated. All modern BSDs (and probably most other Unixes too) do it in a similar way to what Nivedita described. The keywords are "syn flood attack" and "DoS". -Andi From doug@wireboard.com Mon Jul 7 15:25:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jul 2003 15:25:38 -0700 (PDT) Received: from varsoon.wireboard.com (www.wireboard.com [216.151.155.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h67MPQ2x009417 for ; Mon, 7 Jul 2003 15:25:27 -0700 Received: from doug by varsoon.wireboard.com with local (Exim 3.35 #1) id 19ZeQ9-0002nB-00; Mon, 07 Jul 2003 18:25:17 -0400 To: Andi Kleen Cc: "Paul Albrecht" , niv@us.ibm.com, linux-kernel@vger.kernel.org, "netdev" Subject: Re: question about linux tcp request queue handling References: <3F08858E.8000907@us.ibm.com.suse.lists.linux.kernel> <001a01c3441c$6fe111a0$6801a8c0@oemcomputer.suse.lists.linux.kernel> <3F08B7E2.7040208@us.ibm.com.suse.lists.linux.kernel> <000d01c3444f$e6439600$6801a8c0@oemcomputer.suse.lists.linux.kernel> <3F090A4F.10004@us.ibm.com.suse.lists.linux.kernel> <001401c344df$ccbc63c0$6801a8c0@oemcomputer.suse.lists.linux.kernel> From: Doug McNaught Date: 07 Jul 2003 18:25:17 -0400 In-Reply-To: Andi Kleen's message of "07 Jul 2003 23:48:10 +0200" Message-ID: Lines: 19 User-Agent: Gnus/5.0806 (Gnus v5.8.6) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 3814 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: doug@mcnaught.org Precedence: bulk X-list: netdev Andi Kleen writes: > "Paul Albrecht" writes: > > > This statement is inconsistent with the description of this scenario in > > Steven's TCP/IP Illustrated. Specifically, continuing the handshake in the > > TCP layer, i.e., sending a syn/ack and moving to the syn_recd state, is > > incorrect if the limit of the server's socket backlog would be exceeded. > > How do you account for this discrepancy between linux and other > > berkeley-derived implementations? > > The 4.4BSD-Lite code described in Stevens is long outdated. All modern > BSDs (and probably most other Unixes too) do it in a similar way to what > Nivedita described. The keywords are "syn flood attack" and "DoS". And furthermore, IIRC, the current Linux networking code is not Berkeley-derived, though an earlier version was. -Doug From acme@conectiva.com.br Mon Jul 7 16:01:07 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jul 2003 16:01:11 -0700 (PDT) Received: from orion.netbank.com.br (orion.netbank.com.br [200.203.199.90]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h67N152x009965 for ; Mon, 7 Jul 2003 16:01:06 -0700 Received: from [200.181.170.115] (helo=brinquendo.conectiva.com.br) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 19Zf1Z-00012Q-00; Mon, 07 Jul 2003 20:03:57 -0300 Received: by brinquendo.conectiva.com.br (Postfix, from userid 500) id 36CBC1966C; Mon, 7 Jul 2003 22:33:35 +0000 (UTC) Date: Mon, 7 Jul 2003 19:33:35 -0300 From: Arnaldo Carvalho de Melo To: Pekka Savola Cc: Jeff Garzik , netdev@oss.sgi.com Subject: Re: disablenetwork() syscall? Message-ID: <20030707223334.GG5292@conectiva.com.br> References: <20030707194657.GA11328@gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Url: http://advogato.org/person/acme Organization: Conectiva S.A. User-Agent: Mutt/1.5.4i X-archive-position: 3815 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Em Mon, Jul 07, 2003 at 10:52:15PM +0300, Pekka Savola escreveu: > On Mon, 7 Jul 2003, Jeff Garzik wrote: > > On Mon, Jul 07, 2003 at 10:40:02PM +0300, Pekka Savola wrote: > > > In a bugtraq thread, DJ Bernstein brought up an idea which I'm not sure > > > has been brought up in the past. I'm not sure whether it's feasible or > > > not, but at least it (and other methods to limit the functions of a > > > user-level code) might bear consideration. > > > > What about some URLs to what you are describing? > > > > The most information you provided was in $subject, whose content > > makes me a bit leery... > > Well, apart from the post scriptum, there was very little content about > the feature/idea :-), and the details would seem to be up for everyone's > imagination. > > FWIW, the body of the message is below: Incomplete, here is the part that he mention the disablenetwork syscall: ------------------------------------- 8< ------------------------------ P.S. It's hard for a portable chroot tool to cut off a program's network access. Kernel designers should provide a disablenetwork() syscall, with the disabling inherited by children. Other kernel changes would be nice, but disablenetwork() is the only critical change. ------------------------------------- 8< ------------------------------ From ak@suse.de Mon Jul 7 16:52:10 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jul 2003 16:52:19 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h67Nq82x010571 for ; Mon, 7 Jul 2003 16:52:09 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 80B8A144E5; Tue, 8 Jul 2003 01:52:03 +0200 (MEST) Date: Tue, 8 Jul 2003 01:52:01 +0200 From: Andi Kleen To: Doug McNaught Cc: palbrecht@qwest.net, niv@us.ibm.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: question about linux tcp request queue handling Message-Id: <20030708015201.4a5ad7e6.ak@suse.de> In-Reply-To: References: <3F08858E.8000907@us.ibm.com.suse.lists.linux.kernel> <001a01c3441c$6fe111a0$6801a8c0@oemcomputer.suse.lists.linux.kernel> <3F08B7E2.7040208@us.ibm.com.suse.lists.linux.kernel> <000d01c3444f$e6439600$6801a8c0@oemcomputer.suse.lists.linux.kernel> <3F090A4F.10004@us.ibm.com.suse.lists.linux.kernel> <001401c344df$ccbc63c0$6801a8c0@oemcomputer.suse.lists.linux.kernel> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 3816 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev On 07 Jul 2003 18:25:17 -0400 Doug McNaught wrote: > And furthermore, IIRC, the current Linux networking code is not > Berkeley-derived, though an earlier version was. The linux network stack was never BSD derived in any way. [there are two header files that came from net2, but they do not contain any code] -Andi From jmorris@intercode.com.au Mon Jul 7 16:59:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jul 2003 16:59:50 -0700 (PDT) Received: from blackbird.intercode.com.au (IDENT:0SE68HI0BZK1XMeIREV1bZehjFUCwaYg@blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h67Nxh2x010902 for ; Mon, 7 Jul 2003 16:59:44 -0700 Received: from excalibur.intercode.com.au (excalibur.intercode.com.au [203.32.101.12]) by blackbird.intercode.com.au (8.11.6p2/8.9.3) with ESMTP id h67NxWr15959; Tue, 8 Jul 2003 09:59:33 +1000 Date: Tue, 8 Jul 2003 09:59:32 +1000 (EST) From: James Morris To: Pekka Savola cc: netdev@oss.sgi.com Subject: Re: disablenetwork() syscall? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3817 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@intercode.com.au Precedence: bulk X-list: netdev On Mon, 7 Jul 2003, Pekka Savola wrote: > Hi, > > In a bugtraq thread, DJ Bernstein brought up an idea which I'm not sure > has been brought up in the past. Such a feature already exists in SELinux. > I'm not sure whether it's feasible or > not, but at least it (and other methods to limit the functions of a > user-level code) might bear consideration. This is precisely what LSM is for, so new security models can be implemented without any direct effect on the core kernel. - James -- James Morris From doug@wireboard.com Mon Jul 7 17:18:04 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jul 2003 17:18:14 -0700 (PDT) Received: from varsoon.wireboard.com (www.wireboard.com [216.151.155.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h680I32x011336 for ; Mon, 7 Jul 2003 17:18:04 -0700 Received: from doug by varsoon.wireboard.com with local (Exim 3.35 #1) id 19ZgBB-00031R-00; Mon, 07 Jul 2003 20:17:57 -0400 To: Andi Kleen Cc: palbrecht@qwest.net, niv@us.ibm.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: question about linux tcp request queue handling References: <3F08858E.8000907@us.ibm.com.suse.lists.linux.kernel> <001a01c3441c$6fe111a0$6801a8c0@oemcomputer.suse.lists.linux.kernel> <3F08B7E2.7040208@us.ibm.com.suse.lists.linux.kernel> <000d01c3444f$e6439600$6801a8c0@oemcomputer.suse.lists.linux.kernel> <3F090A4F.10004@us.ibm.com.suse.lists.linux.kernel> <001401c344df$ccbc63c0$6801a8c0@oemcomputer.suse.lists.linux.kernel> <20030708015201.4a5ad7e6.ak@suse.de> From: Doug McNaught Date: 07 Jul 2003 20:17:57 -0400 In-Reply-To: Andi Kleen's message of "Tue, 8 Jul 2003 01:52:01 +0200" Message-ID: Lines: 20 User-Agent: Gnus/5.0806 (Gnus v5.8.6) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 3818 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: doug@mcnaught.org Precedence: bulk X-list: netdev Andi Kleen writes: > On 07 Jul 2003 18:25:17 -0400 > Doug McNaught wrote: > > > And furthermore, IIRC, the current Linux networking code is not > > Berkeley-derived, though an earlier version was. > > The linux network stack was never BSD derived in any way. > > [there are two header files that came from net2, but they do not > contain any code] OIDNRC, thanks for the correction. :) Although, I distinctly remember seeing "Net-2" in one of the boot mesages in an early kernel (pre 1.0); was that just the header files' doing? -Doug From ak@suse.de Mon Jul 7 17:25:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jul 2003 17:25:19 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h680PE2x011664 for ; Mon, 7 Jul 2003 17:25:14 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id B289E14E0A; Tue, 8 Jul 2003 02:25:08 +0200 (MEST) Date: Tue, 8 Jul 2003 02:25:07 +0200 From: Andi Kleen To: Doug McNaught Cc: palbrecht@qwest.net, niv@us.ibm.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: question about linux tcp request queue handling Message-Id: <20030708022507.0c9f439b.ak@suse.de> In-Reply-To: References: <3F08858E.8000907@us.ibm.com.suse.lists.linux.kernel> <001a01c3441c$6fe111a0$6801a8c0@oemcomputer.suse.lists.linux.kernel> <3F08B7E2.7040208@us.ibm.com.suse.lists.linux.kernel> <000d01c3444f$e6439600$6801a8c0@oemcomputer.suse.lists.linux.kernel> <3F090A4F.10004@us.ibm.com.suse.lists.linux.kernel> <001401c344df$ccbc63c0$6801a8c0@oemcomputer.suse.lists.linux.kernel> <20030708015201.4a5ad7e6.ak@suse.de> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 3819 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev On 07 Jul 2003 20:17:57 -0400 Doug McNaught wrote: > Although, I distinctly remember seeing "Net-2" in one of the boot > mesages in an early kernel (pre 1.0); was that just the header files' > doing? Net-2 was the name for a linux network code release too. The current code is net4 (actually more net5). But it has nothing to do with the similarly named BSD release. -Andi From kohei@cysols.com Mon Jul 7 18:58:57 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jul 2003 18:59:06 -0700 (PDT) Received: from geto.cysol.co.jp (geto.cysol.co.jp [210.233.3.227]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h681wu2x013338 for ; Mon, 7 Jul 2003 18:58:57 -0700 Received: from cysols.com (agari2.priv.cysol.co.jp [192.168.0.249]) by geto.cysol.co.jp (8.12.9/3.7W) with ESMTP id h681wlwQ011322; Tue, 8 Jul 2003 10:58:48 +0900 (JST) Message-ID: <3F0A2564.6030003@cysols.com> Date: Tue, 08 Jul 2003 10:59:00 +0900 From: Kohei OHTA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: Ulisses CC: netdev@oss.sgi.com Subject: Re: IP-ID field of ICMP echo request References: <3F095B7B.5090203@cysols.com> <1057603237.1001.18.camel@ryback> In-Reply-To: <1057603237.1001.18.camel@ryback> X-Enigmail-Version: 0.76.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3820 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kohei@cysols.com Precedence: bulk X-list: netdev Ulisses, Thanks for your helpful information. I understood the reason. The article pointed by you says "Linux 2.4 also uses peer-specific IPID values (see net/ipv4/inetpeer.c)." That is great. Kohei. >>I found a strange packet, which is generated by ping of Linux. >>It is observed ID field of IP header in ping packet (Echo request) is always 0. >> >>I confirmed this on kernel 2.4.18 and 2.4.21. >>My colleague also confirmed this is fixed in kernel 2.5.74. >> >>I hope this is fixed in next next 2.4.x release. > > Hi, Kohei, > > I guess this behaviour is to prevent Idle scanning, that is based on > predictable IPID numbers [1]. Therefore, the Linux TCP/IP stack uses 0 > as IPID when the DF (Don't Fragment) bit is set. I'm not sure, but I > think that Linux also uses peer-specific IPID numbers to make the > prediction harder. > > -- Ulisses > > [1] http://www.insecure.org/nmap/idlescan.html > > > From palbrecht@qwest.net Mon Jul 7 19:18:09 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Jul 2003 19:18:24 -0700 (PDT) Received: from mpls-qmqp-02.inet.qwest.net (mpls-qmqp-02.inet.qwest.net [63.231.195.113]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h682I82x013852 for ; Mon, 7 Jul 2003 19:18:09 -0700 Received: (qmail 75219 invoked by uid 0); 8 Jul 2003 01:45:28 -0000 Received: from mpls-pop-14.inet.qwest.net (63.231.195.14) by mpls-qmqp-02.inet.qwest.net with QMQP; 8 Jul 2003 01:45:28 -0000 Received: from 0-2pool145-162.nas8.minneapolis1.mn.us.da.qwest.net (HELO oemcomputer) (67.4.145.162) by mpls-pop-14.inet.qwest.net with SMTP; 8 Jul 2003 02:18:06 -0000 Date: Mon, 7 Jul 2003 21:14:48 -0700 Message-ID: <001501c34507$7a19baa0$6801a8c0@oemcomputer> From: "Paul Albrecht" To: "Andi Kleen" Cc: niv@us.ibm.com, linux-kernel@vger.kernel.org, "netdev" References: <3F08858E.8000907@us.ibm.com.suse.lists.linux.kernel><001a01c3441c$6fe111a0$6801a8c0@oemcomputer.suse.lists.linux.kernel><3F08B7E2.7040208@us.ibm.com.suse.lists.linux.kernel><000d01c3444f$e6439600$6801a8c0@oemcomputer.suse.lists.linux.kernel><3F090A4F.10004@us.ibm.com.suse.lists.linux.kernel><001401c344df$ccbc63c0$6801a8c0@oemcomputer.suse.lists.linux.kernel> Subject: Re: question about linux tcp request queue handling MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-archive-position: 3821 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: palbrecht@qwest.net Precedence: bulk X-list: netdev Andi Kleen writes: > > The 4.4BSD-Lite code described in Stevens is long outdated. > I was referring to volume one subtitled: "The Protocols." It doesn't describe implementation and the examples are not limited to bsd-lite. > >All modern BSDs (and probably most other Unixes too) do it in a similar way to what > Nivedita described. > Linux doesn't operate in the manner Nivedita describes ... the tcp layer on the server side moves to the syn_recd state, but doesn't accept the ack back from client. Instead it times out and sends its syn/ack back to the client and again ignores the client's ack, ... Eventually, either there's room on backlog queue and the server side moves to the established state or the server side stops resending the its syn/ack. This doesn't seem to make much sense. If the tcp layer can send the syn/ack it seems like it should probably respond to the client's ack. > >The keywords are "syn flood attack" and "DoS". > I'd be interested in a more specific reference detailing the changes required to the listen syscall as a consequence of the changes required for avoidance of syn flood attacks. Thanks. From yoshfuji@linux-ipv6.org Tue Jul 8 06:17:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jul 2003 06:17:25 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h68DHD2x027872 for ; Tue, 8 Jul 2003 06:17:15 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h68DIYBo016349; Tue, 8 Jul 2003 22:18:35 +0900 Date: Tue, 08 Jul 2003 22:18:34 +0900 (JST) Message-Id: <20030708.221834.127574909.yoshfuji@linux-ipv6.org> To: davem@redhat.com, jmorris@intercode.com.au CC: netdev@oss.sgi.com, Thomas Graf , yoshfuji@linux-ipv6.org Subject: [PATCH] IPV6: Fix BUG when appending destination options headers From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3822 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Hello. This patch fixes BUG when pushing IPv6 destination options over an IPv6 raw socket. Patch is based on one from Thomas Graf . Index: linux-2.5/net/ipv6/ip6_output.c =================================================================== RCS file: /home/cvs/linux-2.5/net/ipv6/ip6_output.c,v retrieving revision 1.32 diff -u -r1.32 ip6_output.c --- linux-2.5/net/ipv6/ip6_output.c 1 Jul 2003 00:57:19 -0000 1.32 +++ linux-2.5/net/ipv6/ip6_output.c 8 Jul 2003 11:55:33 -0000 @@ -1239,7 +1239,6 @@ memcpy(np->cork.opt, opt, opt->tot_len); inet->cork.flags |= IPCORK_OPT; /* need source address above miyazawa*/ - exthdrlen += opt->opt_flen ? opt->opt_flen : 0; } dst_hold(&rt->u.dst); np->cork.rt = rt; @@ -1252,6 +1251,7 @@ length += exthdrlen; transhdrlen += exthdrlen; } + exthdrlen += opt ? opt->opt_flen : 0; } else { rt = np->cork.rt; if (inet->cork.flags & IPCORK_OPT) Index: linux-2.5/net/ipv6/raw.c =================================================================== RCS file: /home/cvs/linux-2.5/net/ipv6/raw.c,v retrieving revision 1.32 diff -u -r1.32 raw.c --- linux-2.5/net/ipv6/raw.c 7 Jul 2003 02:28:36 -0000 1.32 +++ linux-2.5/net/ipv6/raw.c 8 Jul 2003 11:55:33 -0000 @@ -624,6 +624,7 @@ if (msg->msg_controllen) { opt = &opt_space; memset(opt, 0, sizeof(struct ipv6_txoptions)); + opt->tot_len = sizeof(struct ipv6_txoptions); err = datagram_send_ctl(msg, &fl, opt, &hlimit); if (err < 0) { -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From shmulik.hen@intel.com Tue Jul 8 06:40:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jul 2003 06:40:57 -0700 (PDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h68Dej2x028784 for ; Tue, 8 Jul 2003 06:40:46 -0700 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h68DZ0609629 for ; Tue, 8 Jul 2003 13:35:00 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h68D6WR26138 for ; Tue, 8 Jul 2003 13:06:32 GMT Received: from jrslxjul1.npdj.intel.com ([10.12.254.186]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003070806515419980 ; Tue, 08 Jul 2003 06:51:57 -0700 Date: Tue, 8 Jul 2003 16:40:33 +0300 (IDT) From: Shmulik Hen X-X-Sender: Reply-To: Shmulik Hen To: Jeff Garzik cc: linux-netdev , Amir Noam , bond-devel , Jay Vosburgh , Noam Marom , Shmulik Hen , "Chad N. Tindel" , Tsippy Mendelson Subject: [patch][bonding] fix arp targets' addresses initialization In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="202029822-1412134829-1057671633=:8183" X-archive-position: 3823 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev 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. --202029822-1412134829-1057671633=:8183 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, The recent patch to bonding that made it use the standard in_aton() function introduced a bug. The converted IP addresses are saved in the wrong array, thus no ARPs are sent at all to any of the addresses specified. Attached patches are against latest net-drivers 2.4 and 2.5 trees. -- | Shmulik Hen | | Israel Design Center (Jerusalem) | | LAN Access Division | | Intel Communications Group, Intel corp. | --202029822-1412134829-1057671633=:8183 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="patch-2.4.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: patch-2.4.diff Content-Disposition: attachment; filename="patch-2.4.diff" ZGlmZiAtTnVhcnAgbmV0LWRyaXZlcnMtMi40L2RyaXZlcnMvbmV0L2JvbmRp bmcvYm9uZF9tYWluLmMgbmV0LWRyaXZlcnMtMi40LWRldmVsL2RyaXZlcnMv bmV0L2JvbmRpbmcvYm9uZF9tYWluLmMNCi0tLSBuZXQtZHJpdmVycy0yLjQv ZHJpdmVycy9uZXQvYm9uZGluZy9ib25kX21haW4uYwlUdWUgSnVsICA4IDE2 OjI1OjM2IDIwMDMNCisrKyBuZXQtZHJpdmVycy0yLjQtZGV2ZWwvZHJpdmVy cy9uZXQvYm9uZGluZy9ib25kX21haW4uYwlUdWUgSnVsICA4IDE2OjI1OjM3 IDIwMDMNCkBAIC00NjAsNyArNDYwLDcgQEAgc3RydWN0IGJvbmRfcGFybV90 Ymwgew0KIA0KIHN0YXRpYyBpbnQgYXJwX2ludGVydmFsID0gQk9ORF9MSU5L X0FSUF9JTlRFUlY7DQogc3RhdGljIGNoYXIgKmFycF9pcF90YXJnZXRbTUFY X0FSUF9JUF9UQVJHRVRTXSA9IHsgTlVMTCwgfTsNCi1zdGF0aWMgdW5zaWdu ZWQgbG9uZyBhcnBfdGFyZ2V0W01BWF9BUlBfSVBfVEFSR0VUU10gPSB7IDAs IH0gOw0KK3N0YXRpYyB1MzIgYXJwX3RhcmdldFtNQVhfQVJQX0lQX1RBUkdF VFNdID0geyAwLCB9IDsNCiBzdGF0aWMgaW50IGFycF9pcF9jb3VudCA9IDA7 DQogc3RhdGljIHUzMiBteV9pcCA9IDA7DQogY2hhciAqYXJwX3RhcmdldF9o d19hZGRyID0gTlVMTDsNCkBAIC0zOTMwLDcgKzM5MzAsNyBAQCBzdGF0aWMg aW50IF9faW5pdCBib25kaW5nX2luaXQodm9pZCkNCiAgICAgICAgICAgICAg ICAgICAgICAgICBhcnBfaW50ZXJ2YWwgPSAwOw0KIAkJfSBlbHNlIHsgDQog CQkJdTMyIGlwID0gaW5fYXRvbihhcnBfaXBfdGFyZ2V0W2FycF9pcF9jb3Vu dF0pOyANCi0JCQkqKHUzMiAqKShhcnBfaXBfdGFyZ2V0W2FycF9pcF9jb3Vu dF0pID0gaXA7DQorCQkJYXJwX3RhcmdldFthcnBfaXBfY291bnRdID0gaXA7 DQogCQl9DQogICAgICAgICB9DQogDQo= --202029822-1412134829-1057671633=:8183 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="patch-2.5.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: patch-2.5.diff Content-Disposition: attachment; filename="patch-2.5.diff" ZGlmZiAtTnVhcnAgbmV0LWRyaXZlcnMtMi41L2RyaXZlcnMvbmV0L2JvbmRp bmcvYm9uZF9tYWluLmMgbmV0LWRyaXZlcnMtMi41LWRldmVsL2RyaXZlcnMv bmV0L2JvbmRpbmcvYm9uZF9tYWluLmMNCi0tLSBuZXQtZHJpdmVycy0yLjUv ZHJpdmVycy9uZXQvYm9uZGluZy9ib25kX21haW4uYwlUdWUgSnVsICA4IDE2 OjI1OjUwIDIwMDMNCisrKyBuZXQtZHJpdmVycy0yLjUtZGV2ZWwvZHJpdmVy cy9uZXQvYm9uZGluZy9ib25kX21haW4uYwlUdWUgSnVsICA4IDE2OjI1OjUw IDIwMDMNCkBAIC00NDMsNyArNDQzLDcgQEAgc3RydWN0IGJvbmRfcGFybV90 Ymwgew0KIA0KIHN0YXRpYyBpbnQgYXJwX2ludGVydmFsID0gQk9ORF9MSU5L X0FSUF9JTlRFUlY7DQogc3RhdGljIGNoYXIgKmFycF9pcF90YXJnZXRbTUFY X0FSUF9JUF9UQVJHRVRTXSA9IHsgTlVMTCwgfTsNCi1zdGF0aWMgdW5zaWdu ZWQgbG9uZyBhcnBfdGFyZ2V0W01BWF9BUlBfSVBfVEFSR0VUU10gPSB7IDAs IH0gOw0KK3N0YXRpYyB1MzIgYXJwX3RhcmdldFtNQVhfQVJQX0lQX1RBUkdF VFNdID0geyAwLCB9IDsNCiBzdGF0aWMgaW50IGFycF9pcF9jb3VudCA9IDA7 DQogc3RhdGljIHUzMiBteV9pcCA9IDA7DQogY2hhciAqYXJwX3RhcmdldF9o d19hZGRyID0gTlVMTDsNCkBAIC0zODExLDcgKzM4MTEsNyBAQCBzdGF0aWMg aW50IF9faW5pdCBib25kaW5nX2luaXQodm9pZCkNCiAgICAgICAgICAgICAg ICAgICAgICAgICBhcnBfaW50ZXJ2YWwgPSAwOw0KIAkJfSBlbHNlIHsgDQog CQkJdTMyIGlwID0gaW5fYXRvbihhcnBfaXBfdGFyZ2V0W2FycF9pcF9jb3Vu dF0pOyANCi0JCQkqKHUzMiAqKShhcnBfaXBfdGFyZ2V0W2FycF9pcF9jb3Vu dF0pID0gaXA7DQorCQkJYXJwX3RhcmdldFthcnBfaXBfY291bnRdID0gaXA7 DQogCQl9DQogICAgICAgICB9DQogDQo= --202029822-1412134829-1057671633=:8183-- From jmorris@intercode.com.au Tue Jul 8 08:28:21 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jul 2003 08:28:27 -0700 (PDT) Received: from blackbird.intercode.com.au (IDENT:XBuZTrx4BLhOZb5Dd0N7WYhyTpLPTPpp@blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h68FSH2x005274 for ; Tue, 8 Jul 2003 08:28:19 -0700 Received: from excalibur.intercode.com.au (excalibur.intercode.com.au [203.32.101.12]) by blackbird.intercode.com.au (8.11.6p2/8.9.3) with ESMTP id h68FRxr19399; Wed, 9 Jul 2003 01:28:00 +1000 Date: Wed, 9 Jul 2003 01:27:59 +1000 (EST) From: James Morris To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: davem@redhat.com, , Thomas Graf Subject: Re: [PATCH] IPV6: Fix BUG when appending destination options headers In-Reply-To: <20030708.221834.127574909.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 3824 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@intercode.com.au Precedence: bulk X-list: netdev On Tue, 8 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote: > This patch fixes BUG when pushing IPv6 destination options over an > IPv6 raw socket. Patch is based on one from Thomas Graf . Applied to bk://kernel.bkbits.net/jmorris/ipv6-2.5 - James -- James Morris From mtk-lists@gmx.net Tue Jul 8 09:09:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jul 2003 09:09:30 -0700 (PDT) Received: from mx0.gmx.net (mx0.gmx.net [213.165.64.100]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h68G9L2x006797 for ; Tue, 8 Jul 2003 09:09:22 -0700 Received: (qmail 8673 invoked by uid 0); 8 Jul 2003 16:09:15 -0000 Date: Tue, 8 Jul 2003 18:09:14 +0200 (MEST) From: mtk-lists@gmx.net To: netdev@oss.sgi.com MIME-Version: 1.0 Subject: Re: shutdown() and SHUT_RD on TCP sockets - broken? X-Priority: 3 (Normal) X-Authenticated-Sender: #0018454895@gmx.net X-Authenticated-IP: [212.18.21.202] Message-ID: <27084.1057680554@www6.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-archive-position: 3825 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mtk-lists@gmx.net Precedence: bulk X-list: netdev Hello, There was no response to the note below. Is netdev the right place to raise this subject? Cheers Michael ------- Forwarded message follows ------- Date sent: Tue, 1 Jul 2003 13:23:49 +0200 (MEST) From: mtk-lists@gmx.net To: netdev@oss.sgi.com BCC to: michael.kerrisk@gmx.net Subject: shutdown() and SHUT_RD on TCP sockets - broken? Hello, I've done quite some searching, but have so far not found an answer to the question of why does the behaviour described below occur on Linux... According to SUSv3, if we perform a shutdown(fd, SHUT_RD) on a socket, then further reads on that socket should be disabled. In the AF_UNIX domain, all is fine -- things operate as I expect. However, for TCP sockets, things are different (tested on 2.2.14, and 2.4.20): 1. If we perform a read() on the socket and there is no data, then 0 (EOF) is (immediately) returned. (This is what I expected.) 2. However, the peer can still write() to the socket, and afterwards we can read() that data from the socket, even though the reading half of the socket should be shut down. Instead of this behaviour, I expected the read() to continue to return 0 as in point 1. This is what we see for example in FreeBSD 4.8, Tru64 5.1B, and HP/UX 11. I thought that most implementations (other than Linux) did things this way, but I've just now gone and tested things on Solaris 8, and it seems to behave in the same way as Linux. I've read the relevant source code to confirm the anomalous behaviour described here. But, why do things happen in this way on Linux? 3. (A side point.) Looking at Stevens UNPv1, p161, there is a statement that after a SHUT_RD, "any data for a TCP socket is acknowledged and then silently discarded". This implies to me that the sender could keep on writing to the socket and never block. However, on Linux, if the peer keeps sending to a socket, then eventually (the channel is filled and) it blocks. I see that this also occurs on FreeBSD 4.8, Tru64 5.1B, HP/UX 11 and Solaris 8. Have I misunderstood Stevens, or has something changed since the implementation he described (or was his statement wrong)? (In the AF_UNIX domain on Linux, the peer gets SIGPIPE/EPIPE if it keeps writing after a local SHUT_RD.) Thanks Michael -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Jetzt ein- oder umsteigen und USB-Speicheruhr als Prämie sichern! From jmorris@intercode.com.au Tue Jul 8 09:28:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jul 2003 09:28:28 -0700 (PDT) Received: from blackbird.intercode.com.au (IDENT:qSgcuNLQOEudkYz67FgECyo3FYdtmZfn@blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h68GSM2x007642 for ; Tue, 8 Jul 2003 09:28:23 -0700 Received: from excalibur.intercode.com.au (excalibur.intercode.com.au [203.32.101.12]) by blackbird.intercode.com.au (8.11.6p2/8.9.3) with ESMTP id h68GSDr19679; Wed, 9 Jul 2003 02:28:13 +1000 Date: Wed, 9 Jul 2003 02:28:12 +1000 (EST) From: James Morris To: mtk-lists@gmx.net cc: netdev@oss.sgi.com, Subject: Re: shutdown() and SHUT_RD on TCP sockets - broken? In-Reply-To: <27084.1057680554@www6.gmx.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3826 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@intercode.com.au Precedence: bulk X-list: netdev On Tue, 8 Jul 2003 mtk-lists@gmx.net wrote: > Hello, > > There was no response to the note below. Is netdev the right place to > raise this subject? Yes. I believe Alexey has some reservations about the specified behavior. - James -- James Morris From ak@suse.de Tue Jul 8 09:55:12 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jul 2003 09:55:21 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h68GtB2x008305 for ; Tue, 8 Jul 2003 09:55:12 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id F19B9142AB; Tue, 8 Jul 2003 18:55:05 +0200 (MEST) Date: Tue, 8 Jul 2003 18:55:04 +0200 From: Andi Kleen To: mtk-lists@gmx.net Cc: netdev@oss.sgi.com Subject: Re: shutdown() and SHUT_RD on TCP sockets - broken? Message-Id: <20030708185504.385c0d55.ak@suse.de> In-Reply-To: <27084.1057680554@www6.gmx.net> References: <27084.1057680554@www6.gmx.net> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 3827 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev On Tue, 8 Jul 2003 18:09:14 +0200 (MEST) mtk-lists@gmx.net wrote: > 1. If we perform a read() on the socket and there is no data, then 0 > (EOF) is (immediately) returned. (This is what I expected.) > > 2. However, the peer can still write() to the socket, and afterwards > we can read() that data from the socket, even though the reading half > of the socket should be shut down. Instead of this behaviour, I > expected the read() to continue to return 0 as in point 1. This is what we > see for example in FreeBSD 4.8, Tru64 5.1B, and HP/UX 11. The problem is that it adds a new check to the input path. It's not clear how the check can be done outside the fast path (one way would be to shrink the window forcedly and drop the receiver into slow path, but that would be a severe protocol violation if the shrunk window leaks out with some ACK). I don't think it's a good idea to add a check for such an obscure situation to the fast path. > > 3. (A side point.) Looking at Stevens UNPv1, p161, there is a statement > that after a SHUT_RD, "any data for a TCP socket is acknowledged and then > silently discarded". This implies to me that the sender could keep on > writing to the socket and never block. However, on Linux, if the peer > keeps sending to a socket, then eventually (the channel is filled and) it > blocks. I see that this also occurs on FreeBSD 4.8, Tru64 5.1B, HP/UX 11 That's because the data is not discarded so the window fills. > and Solaris 8. Have I misunderstood Stevens, or has something changed > since the implementation he described (or was his statement wrong)? (In Probably Stevens was confused. -Andi From kuznet@ms2.inr.ac.ru Tue Jul 8 10:03:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jul 2003 10:03:37 -0700 (PDT) Received: from dub.inr.ac.ru (dub.inr.ac.ru [193.233.7.105]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h68H3R2x008828 for ; Tue, 8 Jul 2003 10:03:28 -0700 Received: (from kuznet@localhost) by dub.inr.ac.ru (8.6.13/ANK) id VAA13437; Tue, 8 Jul 2003 21:03:07 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200307081703.VAA13437@dub.inr.ac.ru> Subject: Re: shutdown() and SHUT_RD on TCP sockets - broken? To: jmorris@intercode.com.au (James Morris) Date: Tue, 8 Jul 2003 21:03:07 +0400 (MSD) Cc: mtk-lists@gmx.net, netdev@oss.sgi.com In-Reply-To: from "James Morris" at éÀÌ 09, 2003 02:28:12 X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3828 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Hello! > blocks. I see that this also occurs on FreeBSD 4.8, Tru64 5.1B, > HP/UX 11 and Solaris 8. Have I misunderstood Stevens, Most likely, it is that rare case when Stevens forgot to check the statement. From viewpoint of TCP the behaviour described in Stevens' book is highly unnatural. SHUT_RD on TCP does not make any sense. > described here. But, why do things happen in this way on Linux? Actually, you could check one more thing. What does happen after freebsd 4.8 returns 0 on read()? Does it open window eventually? As you checked, all the stacks ignore SHUT_RD, when receiving data and queue it anyway. And when read()ing Linux and, apparently Solaris, prefer to return this data. Alexey From palbrecht@qwest.net Tue Jul 8 10:26:57 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jul 2003 10:27:14 -0700 (PDT) Received: from mpls-qmqp-01.inet.qwest.net (mpls-qmqp-01.inet.qwest.net [63.231.195.112]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h68HQu2x010024 for ; Tue, 8 Jul 2003 10:26:56 -0700 Received: (qmail 28098 invoked by uid 0); 8 Jul 2003 17:26:55 -0000 Received: from unknown (63.231.195.5) by mpls-qmqp-01.inet.qwest.net with QMQP; 8 Jul 2003 17:26:55 -0000 Received: from 0-1pool151-16.nas8.minneapolis1.mn.us.da.qwest.net (HELO oemcomputer) (67.4.151.16) by mpls-pop-05.inet.qwest.net with SMTP; 8 Jul 2003 17:26:54 -0000 Date: Tue, 8 Jul 2003 12:23:37 -0700 Message-ID: <001401c34586$6f955e20$6801a8c0@oemcomputer> From: "Paul Albrecht" To: "Andi Kleen" Cc: niv@us.ibm.com, linux-kernel@vger.kernel.org, "netdev" References: <3F08858E.8000907@us.ibm.com.suse.lists.linux.kernel><001a01c3441c$6fe111a0$6801a8c0@oemcomputer.suse.lists.linux.kernel><3F08B7E2.7040208@us.ibm.com.suse.lists.linux.kernel><000d01c3444f$e6439600$6801a8c0@oemcomputer.suse.lists.linux.kernel><3F090A4F.10004@us.ibm.com.suse.lists.linux.kernel><001401c344df$ccbc63c0$6801a8c0@oemcomputer.suse.lists.linux.kernel> Subject: Re: question about linux tcp request queue handling MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0011_01C3454B.C1D79260" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-archive-position: 3829 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: palbrecht@qwest.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C3454B.C1D79260 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Andi Kleen writes: > > The 4.4BSD-Lite code described in Stevens is long outdated. All modern > BSDs (and probably most other Unixes too) do it in a similar way to what > Nivedita described. The keywords are "syn flood attack" and "DoS". > I have attached a copy of tcpdump output for two linux systems connected over ether replaying the scenario for incoming request queue handling given in Stevens's TCP/IP Illustrated Volume 1: The Protocols. What I don't understand about the third handshake is if the server is going to send the syn/ack in response the client's initial syn then why does server repeatly ignore the subsequent ack from the client? ------=_NextPart_000_0011_01C3454B.C1D79260 Content-Type: text/plain; name="trace.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="trace.txt" 01:12:09.622208 client.acme.net.1024 > server.acme.net.7777: S = 2730884988:2730884988(0) win 5840 (DF) 01:12:09.623457 server.acme.net.7777 > client.acme.net.1024: S = 1682786145:1682786145(0) ack 2730884989 win 5792 (DF) 01:12:09.623963 client.acme.net.1024 > server.acme.net.7777: . ack = 1682786146 win 5840 (DF) 01:12:11.858191 client.acme.net.1025 > server.acme.net.7777: S = 2743503110:2743503110(0) win 5840 (DF) 01:12:11.858991 server.acme.net.7777 > client.acme.net.1025: S = 1690738882:1690738882(0) ack 2743503111 win 5792 (DF) 01:12:11.859535 client.acme.net.1025 > server.acme.net.7777: . ack = 1690738883 win 5840 (DF) 01:12:13.909895 client.acme.net.1026 > server.acme.net.7777: S = 2736891141:2736891141(0) win 5840 (DF) 01:12:13.910636 server.acme.net.7777 > client.acme.net.1026: S = 1692403887:1692403887(0) ack 2736891142 win 5792 (DF) 01:12:13.911144 client.acme.net.1026 > server.acme.net.7777: . ack = 1692403888 win 5840 (DF) 01:12:17.502319 server.acme.net.7777 > client.acme.net.1026: S = 1692403887:1692403887(0) ack 2736891142 win 5792 (DF) 01:12:17.502909 client.acme.net.1026 > server.acme.net.7777: . ack = 1692403888 win 5840 (DF) 01:12:23.502350 server.acme.net.7777 > client.acme.net.1026: S = 1692403887:1692403887(0) ack 2736891142 win 5792 (DF) 01:12:23.502969 client.acme.net.1026 > server.acme.net.7777: . ack = 1692403888 win 5840 (DF) 01:12:35.702302 server.acme.net.7777 > client.acme.net.1026: S = 1692403887:1692403887(0) ack 2736891142 win 5792 (DF) 01:12:35.702840 client.acme.net.1026 > server.acme.net.7777: . ack = 1692403888 win 5840 (DF) 01:12:59.702343 server.acme.net.7777 > client.acme.net.1026: S = 1692403887:1692403887(0) ack 2736891142 win 5792 (DF) 01:12:59.702994 client.acme.net.1026 > server.acme.net.7777: . ack = 1692403888 win 5840 (DF) ------=_NextPart_000_0011_01C3454B.C1D79260-- From willy@www.linux.org.uk Tue Jul 8 10:52:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jul 2003 10:52:56 -0700 (PDT) Received: from www.linux.org.uk (IDENT:4vBE4wuPSC5KCPsn6hIdI7xNi7UYOIOv@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h68Hqg2x010515 for ; Tue, 8 Jul 2003 10:52:43 -0700 Received: from willy by www.linux.org.uk with local (Exim 4.14) id 19ZvMY-0007KY-SR; Tue, 08 Jul 2003 17:30:42 +0100 Date: Tue, 8 Jul 2003 17:30:42 +0100 From: Matthew Wilcox To: Jeff Garzik , Arnaldo Carvalho de Melo Cc: netdev@oss.sgi.com Subject: [PATCH] netdev_ops Message-ID: <20030708163042.GL23597@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-archive-position: 3830 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@debian.org Precedence: bulk X-list: netdev After a conversation with acme, I realised that ethtool_ops is far too narrow scope. What we need are netdev_ops. This patch renames the ethtool_ops to netdev_ops and fixes some other minor flaws: - add _len() ops for operations which previously had to kmalloc their own memory. - move the netdev_ops from ethtool.h to netdevice.h - makes some ops generic as requested by Jeff Garzik. I think netdev_ops is still a little too ethtool-specific; something I'd like to do is convert the parameters to be a little less ethtool-related. For example, instead of ->get_drvinfo, I'd like to see ethtool_get_drvinfo() call several methods and fill in all the data that way. But let's see what everyone thinks of this patch first ... Index: include/linux/ethtool.h =================================================================== RCS file: /var/cvs/linux-2.5/include/linux/ethtool.h,v retrieving revision 1.5 diff -u -p -r1.5 ethtool.h --- include/linux/ethtool.h 14 Jun 2003 22:16:01 -0000 1.5 +++ include/linux/ethtool.h 8 Jul 2003 15:25:49 -0000 @@ -12,6 +12,7 @@ #ifndef _LINUX_ETHTOOL_H #define _LINUX_ETHTOOL_H +#include /* This should work for both 32 and 64 bit userland. */ struct ethtool_cmd { @@ -97,7 +98,7 @@ struct ethtool_coalesce { u32 rx_max_coalesced_frames; /* Same as above two parameters, except that these values - * apply while an IRQ is being services by the host. Not + * apply while an IRQ is being serviced by the host. Not * all cards support this feature and the values are ignored * in that case. */ @@ -119,7 +120,7 @@ struct ethtool_coalesce { u32 tx_max_coalesced_frames; /* Same as above two parameters, except that these values - * apply while an IRQ is being services by the host. Not + * apply while an IRQ is being serviced by the host. Not * all cards support this feature and the values are ignored * in that case. */ Index: include/linux/netdevice.h =================================================================== RCS file: /var/cvs/linux-2.5/include/linux/netdevice.h,v retrieving revision 1.14 diff -u -p -r1.14 netdevice.h --- include/linux/netdevice.h 2 Jul 2003 22:08:52 -0000 1.14 +++ include/linux/netdevice.h 8 Jul 2003 15:14:38 -0000 @@ -42,6 +42,7 @@ struct divert_blk; struct vlan_group; +struct netdev_ops; #define HAVE_ALLOC_NETDEV /* feature macro: alloc_xxxdev functions are available. */ @@ -299,6 +300,8 @@ struct net_device * See for details. Jean II */ struct iw_handler_def * wireless_handlers; + struct netdev_ops *netdev_ops; + /* * This marks the end of the "visible" part of the structure. All * fields hereafter are internal to the system, and may change at @@ -484,6 +487,102 @@ struct packet_type struct list_head list; }; +/* Some generic methods drivers may use in their netops */ +u32 netdev_op_get_link(struct net_device *dev); +u32 netdev_op_get_tx_csum(struct net_device *dev); +u32 netdev_op_get_sg(struct net_device *dev); +int netdev_op_set_sg(struct net_device *dev, u32 data); + +struct ethtool_cmd; +struct ethtool_drvinfo; +struct ethtool_regs; +struct ethtool_wolinfo; +struct ethtool_eeprom; +struct ethtool_coalesce; +struct ethtool_ringparam; +struct ethtool_pauseparam; +struct ethtool_test; +struct ethtool_gstrings; +struct ethtool_stats; + +/** + * &netdev_ops - Alter and report network device settings + * get_settings: Get device-specific settings + * set_settings: Set device-specific settings + * get_drvinfo: Report driver information + * get_regs: Get device registers + * get_wol: Report whether Wake-on-Lan is enabled + * set_wol: Turn Wake-on-Lan on or off + * get_msglevel: Report driver message level + * set_msglevel: Set driver message level + * nway_reset: Restart autonegotiation + * get_link: Get link status + * get_eeprom: Read data from the device EEPROM + * set_eeprom: Writedata to the device EEPROM + * get_coalesce: Get interrupt coalescing parameters + * set_coalesce: Set interrupt coalescing parameters + * get_ringparam: Report ring sizes + * set_ringparam: Set ring sizes + * get_pauseparam: Report pause parameters + * set_pauseparam: Set pause paramters + * get_rx_csum: Report whether receive checksums are turned on or off + * set_rx_csum: Turn receive checksum on or off + * get_tx_csum: Report whether transmit checksums are turned on or off + * set_tx_csum: Turn transmit checksums on or off + * get_sg: Report whether scatter-gather is enabled + * set_sg: Turn scatter-gather on or off + * self_test: Run specified self-tests + * get_strings: Return a set of strings that describe the requested objects + * phys_id: Identify the device + * get_stats: Return statistics about the device + * + * Description: + * + * Each operation is passed a &struct net_device as its first parameter. + * + * get_settings: + * @get_settings is passed an ðtool_cmd to fill in. It returns + * an negative errno or zero. + * + * set_settings: + * @set_settings is passed an ðtool_cmd and should attempt to set + * all the settings this device supports. It may return an error value + * if something goes wrong (otherwise 0). + */ +struct netdev_ops { + int (*get_settings)(struct net_device *, struct ethtool_cmd *); + int (*set_settings)(struct net_device *, struct ethtool_cmd *); + void (*get_drvinfo)(struct net_device *, struct ethtool_drvinfo *); + int (*get_regs_len)(struct ethtool_regs *); + void (*get_regs)(struct net_device *, struct ethtool_regs *, void *); + void (*get_wol)(struct net_device *, struct ethtool_wolinfo *); + int (*set_wol)(struct net_device *, struct ethtool_wolinfo *); + u32 (*get_msglevel)(struct net_device *); + void (*set_msglevel)(struct net_device *, u32); + int (*nway_reset)(struct net_device *); + u32 (*get_link)(struct net_device *); + int (*get_eeprom)(struct net_device *, struct ethtool_eeprom *); + int (*set_eeprom)(struct net_device *, struct ethtool_eeprom *); + int (*get_coalesce)(struct net_device *, struct ethtool_coalesce *); + int (*set_coalesce)(struct net_device *, struct ethtool_coalesce *); + void (*get_ringparam)(struct net_device *, struct ethtool_ringparam *); + int (*set_ringparam)(struct net_device *, struct ethtool_ringparam *); + void (*get_pauseparam)(struct net_device *, struct ethtool_pauseparam*); + int (*set_pauseparam)(struct net_device *, struct ethtool_pauseparam*); + u32 (*get_rx_csum)(struct net_device *); + int (*set_rx_csum)(struct net_device *, u32); + u32 (*get_tx_csum)(struct net_device *); + int (*set_tx_csum)(struct net_device *, u32); + u32 (*get_sg)(struct net_device *); + int (*set_sg)(struct net_device *, u32); + int (*self_test_len)(struct ethtool_test *); + void (*self_test)(struct net_device *, struct ethtool_test *, u64 *); + int (*get_strings_len)(struct ethtool_gstrings *); + void (*get_strings)(struct net_device *, struct ethtool_gstrings *, u8 *); + void (*phys_id)(struct net_device *, u32); + int (*get_stats_len)(struct ethtool_stats *); + void (*get_stats)(struct net_device *, struct ethtool_stats *, u64 *); +}; #include #include @@ -633,6 +732,7 @@ extern int netif_rx(struct sk_buff *skb #define HAVE_NETIF_RECEIVE_SKB 1 extern int netif_receive_skb(struct sk_buff *skb); extern int dev_ioctl(unsigned int cmd, void *); +extern int dev_ethtool(struct ifreq *); extern unsigned dev_get_flags(const struct net_device *); extern int dev_change_flags(struct net_device *, unsigned); extern int dev_set_mtu(struct net_device *, int); Index: net/socket.c =================================================================== RCS file: /var/cvs/linux-2.5/net/socket.c,v retrieving revision 1.21 diff -u -p -r1.21 socket.c --- net/socket.c 17 Jun 2003 11:54:29 -0000 1.21 +++ net/socket.c 17 Jun 2003 11:57:20 -0000 @@ -74,7 +74,6 @@ #include #include #include -#include #include #include #include @@ -1916,10 +1915,7 @@ int sock_unregister(int family) extern void sk_init(void); - -#ifdef CONFIG_WAN_ROUTER extern void wanrouter_init(void); -#endif void __init sock_init(void) { Index: net/core/Makefile =================================================================== RCS file: /var/cvs/linux-2.5/net/core/Makefile,v retrieving revision 1.9 diff -u -p -r1.9 Makefile --- net/core/Makefile 27 May 2003 17:29:33 -0000 1.9 +++ net/core/Makefile 4 Jun 2003 18:39:01 -0000 @@ -10,8 +10,8 @@ obj-y += sysctl_net_core.o endif endif -obj-$(CONFIG_NET) += flow.o dev.o net-sysfs.o dev_mcast.o dst.o neighbour.o \ - rtnetlink.o utils.o link_watch.o filter.o +obj-$(CONFIG_NET) += flow.o dev.o ethtool.o net-sysfs.o dev_mcast.o dst.o \ + neighbour.o rtnetlink.o utils.o link_watch.o filter.o obj-$(CONFIG_NETFILTER) += netfilter.o obj-$(CONFIG_NET_DIVERT) += dv.o Index: net/core/dev.c =================================================================== RCS file: /var/cvs/linux-2.5/net/core/dev.c,v retrieving revision 1.22 diff -u -p -r1.22 dev.c --- net/core/dev.c 2 Jul 2003 22:08:58 -0000 1.22 +++ net/core/dev.c 8 Jul 2003 15:36:35 -0000 @@ -2224,6 +2224,36 @@ int dev_set_mtu(struct net_device *dev, return err; } +/* These are all netdev_op methods in case a driver needs to do something + * different. If we find that all drivers want to do the same thing here, + * we can turn them into dev_() function calls. + */ + +u32 netdev_op_get_link(struct net_device *dev) +{ + return netif_carrier_ok(dev) ? 1 : 0; +} + +u32 netdev_op_get_tx_csum(struct net_device *dev) +{ + return (dev->features & NETIF_F_IP_CSUM) != 0; +} + +u32 netdev_op_get_sg(struct net_device *dev) +{ + return (dev->features & NETIF_F_SG) != 0; +} + +int netdev_op_set_sg(struct net_device *dev, u32 data) +{ + if (data) + dev->features |= NETIF_F_SG; + else + dev->features &= ~NETIF_F_SG; + + return 0; +} + /* * Perform the SIOCxIFxxx calls. @@ -2364,7 +2394,6 @@ static int dev_ifsioc(struct ifreq *ifr, cmd == SIOCBONDSLAVEINFOQUERY || cmd == SIOCBONDINFOQUERY || cmd == SIOCBONDCHANGEACTIVE || - cmd == SIOCETHTOOL || cmd == SIOCGMIIPHY || cmd == SIOCGMIIREG || cmd == SIOCSMIIREG || @@ -2461,13 +2490,26 @@ int dev_ioctl(unsigned int cmd, void *ar } return ret; + case SIOCETHTOOL: + dev_load(ifr.ifr_name); + rtnl_lock(); + ret = dev_ethtool(&ifr); + rtnl_unlock(); + if (!ret) { + if (colon) + *colon = ':'; + if (copy_to_user(arg, &ifr, + sizeof(struct ifreq))) + ret = -EFAULT; + } + return ret; + /* * These ioctl calls: * - require superuser power. * - require strict serialization. * - return a value */ - case SIOCETHTOOL: case SIOCGMIIPHY: case SIOCGMIIREG: if (!capable(CAP_NET_ADMIN)) Index: net/core/ethtool.c =================================================================== RCS file: net/core/ethtool.c diff -N net/core/ethtool.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ net/core/ethtool.c 8 Jul 2003 15:29:25 -0000 @@ -0,0 +1,546 @@ +/* + * net/core/ethtool.c - Ethtool ioctl handler + * Split from net/core/dev.c by Matthew Wilcox + * The only entry point in this file is dev_ethtool() and its only caller + * is from net/core/dev.c + * + * It's GPL, stupid. + */ + +#include +#include +#include + +static int ethtool_get_settings(struct net_device *dev, void *useraddr) +{ + struct ethtool_cmd cmd = { ETHTOOL_GSET }; + int err; + + if (!dev->netdev_ops->get_settings) + return -EOPNOTSUPP; + + err = dev->netdev_ops->get_settings(dev, &cmd); + if (err < 0) + return err; + + if (copy_to_user(useraddr, &cmd, sizeof(cmd))) + return -EFAULT; + return 0; +} + +static int ethtool_set_settings(struct net_device *dev, void *useraddr) +{ + struct ethtool_cmd cmd; + + if (!dev->netdev_ops->set_settings) + return -EOPNOTSUPP; + + if (copy_from_user(&cmd, useraddr, sizeof(cmd))) + return -EFAULT; + + return dev->netdev_ops->set_settings(dev, &cmd); +} + +static int ethtool_get_drvinfo(struct net_device *dev, void *useraddr) +{ + struct ethtool_drvinfo info = { ETHTOOL_GDRVINFO }; + + if (!dev->netdev_ops->get_drvinfo) + return -EOPNOTSUPP; + + dev->netdev_ops->get_drvinfo(dev, &info); + + if (copy_to_user(useraddr, &info, sizeof(info))) + return -EFAULT; + return 0; +} + +static int ethtool_get_regs(struct net_device *dev, char *useraddr) +{ + struct ethtool_regs regs; + struct netdev_ops *ops = dev->netdev_ops; + void *regbuf; + int ret; + + if (!ops->get_regs || !ops->get_regs_len) + return -EOPNOTSUPP; + + if (copy_from_user(®s, useraddr, sizeof(regs))) + return -EFAULT; + + regbuf = kmalloc(ops->get_regs_len(®s), GFP_KERNEL); + if (!regbuf) + return -ENOMEM; + + ops->get_regs(dev, ®s, regbuf); + + ret = 0; + if (copy_to_user(useraddr, ®s, sizeof(regs))) + ret = -EFAULT; + useraddr += offsetof(struct ethtool_regs, data); + if (copy_to_user(useraddr, regbuf, regs.len)) + ret = -EFAULT; + + kfree(regbuf); + return ret; +} + +static int ethtool_get_wol(struct net_device *dev, char *useraddr) +{ + struct ethtool_wolinfo wol = { ETHTOOL_GWOL }; + + if (!dev->netdev_ops->get_wol) + return -EOPNOTSUPP; + + dev->netdev_ops->get_wol(dev, &wol); + + if (copy_to_user(useraddr, &wol, sizeof(wol))) + return -EFAULT; + return 0; +} + +static int ethtool_set_wol(struct net_device *dev, char *useraddr) +{ + struct ethtool_wolinfo wol; + + if (!dev->netdev_ops->set_wol) + return -EOPNOTSUPP; + + if (copy_from_user(&wol, useraddr, sizeof(wol))) + return -EFAULT; + + return dev->netdev_ops->set_wol(dev, &wol); +} + +static int ethtool_get_msglevel(struct net_device *dev, char *useraddr) +{ + struct ethtool_value edata = { ETHTOOL_GMSGLVL }; + + if (!dev->netdev_ops->get_msglevel) + return -EOPNOTSUPP; + + edata.data = dev->netdev_ops->get_msglevel(dev); + + if (copy_to_user(useraddr, &edata, sizeof(edata))) + return -EFAULT; + return 0; +} + +static int ethtool_set_msglevel(struct net_device *dev, char *useraddr) +{ + struct ethtool_value edata; + + if (!dev->netdev_ops->set_msglevel) + return -EOPNOTSUPP; + + if (copy_from_user(&edata, useraddr, sizeof(edata))) + return -EFAULT; + + dev->netdev_ops->set_msglevel(dev, edata.data); + return 0; +} + +static int ethtool_nway_reset(struct net_device *dev) +{ + if (!dev->netdev_ops->nway_reset) + return -EOPNOTSUPP; + + return dev->netdev_ops->nway_reset(dev); +} + +static int ethtool_get_link(struct net_device *dev, void *useraddr) +{ + struct ethtool_value edata = { ETHTOOL_GLINK }; + + if (!dev->netdev_ops->get_link) + return -EOPNOTSUPP; + + edata.data = dev->netdev_ops->get_link(dev); + + if (copy_to_user(useraddr, &edata, sizeof(edata))) + return -EFAULT; + return 0; +} + +static int ethtool_get_eeprom(struct net_device *dev, void *useraddr) +{ + struct ethtool_eeprom eeprom = { ETHTOOL_GEEPROM }; + + if (!dev->netdev_ops->get_eeprom) + return -EOPNOTSUPP; + + dev->netdev_ops->get_eeprom(dev, &eeprom); + + if (copy_to_user(useraddr, &eeprom, sizeof(eeprom))) + return -EFAULT; + return 0; +} + +static int ethtool_set_eeprom(struct net_device *dev, void *useraddr) +{ + struct ethtool_eeprom eeprom; + + if (!dev->netdev_ops->get_eeprom) + return -EOPNOTSUPP; + + if (copy_from_user(useraddr, &eeprom, sizeof(eeprom))) + return -EFAULT; + + return dev->netdev_ops->set_eeprom(dev, &eeprom); +} + +static int ethtool_get_coalesce(struct net_device *dev, void *useraddr) +{ + struct ethtool_coalesce coalesce = { ETHTOOL_GCOALESCE }; + + if (!dev->netdev_ops->get_coalesce) + return -EOPNOTSUPP; + + dev->netdev_ops->get_coalesce(dev, &coalesce); + + if (copy_to_user(useraddr, &coalesce, sizeof(coalesce))) + return -EFAULT; + return 0; +} + +static int ethtool_set_coalesce(struct net_device *dev, void *useraddr) +{ + struct ethtool_coalesce coalesce; + + if (!dev->netdev_ops->get_coalesce) + return -EOPNOTSUPP; + + if (copy_from_user(useraddr, &coalesce, sizeof(coalesce))) + return -EFAULT; + + return dev->netdev_ops->set_coalesce(dev, &coalesce); +} + +static int ethtool_get_ringparam(struct net_device *dev, void *useraddr) +{ + struct ethtool_ringparam ringparam = { ETHTOOL_GRINGPARAM }; + + if (!dev->netdev_ops->get_ringparam) + return -EOPNOTSUPP; + + dev->netdev_ops->get_ringparam(dev, &ringparam); + + if (copy_to_user(useraddr, &ringparam, sizeof(ringparam))) + return -EFAULT; + return 0; +} + +static int ethtool_set_ringparam(struct net_device *dev, void *useraddr) +{ + struct ethtool_ringparam ringparam; + + if (!dev->netdev_ops->get_ringparam) + return -EOPNOTSUPP; + + if (copy_from_user(useraddr, &ringparam, sizeof(ringparam))) + return -EFAULT; + + return dev->netdev_ops->set_ringparam(dev, &ringparam); +} + +static int ethtool_get_pauseparam(struct net_device *dev, void *useraddr) +{ + struct ethtool_pauseparam pauseparam = { ETHTOOL_GPAUSEPARAM }; + + if (!dev->netdev_ops->get_pauseparam) + return -EOPNOTSUPP; + + dev->netdev_ops->get_pauseparam(dev, &pauseparam); + + if (copy_to_user(useraddr, &pauseparam, sizeof(pauseparam))) + return -EFAULT; + return 0; +} + +static int ethtool_set_pauseparam(struct net_device *dev, void *useraddr) +{ + struct ethtool_pauseparam pauseparam; + + if (!dev->netdev_ops->get_pauseparam) + return -EOPNOTSUPP; + + if (copy_from_user(useraddr, &pauseparam, sizeof(pauseparam))) + return -EFAULT; + + return dev->netdev_ops->set_pauseparam(dev, &pauseparam); +} + +static int ethtool_get_rx_csum(struct net_device *dev, char *useraddr) +{ + struct ethtool_value edata = { ETHTOOL_GRXCSUM }; + + if (!dev->netdev_ops->get_rx_csum) + return -EOPNOTSUPP; + + edata.data = dev->netdev_ops->get_rx_csum(dev); + + if (copy_to_user(useraddr, &edata, sizeof(edata))) + return -EFAULT; + return 0; +} + +static int ethtool_set_rx_csum(struct net_device *dev, char *useraddr) +{ + struct ethtool_value edata; + + if (!dev->netdev_ops->set_rx_csum) + return -EOPNOTSUPP; + + if (copy_from_user(&edata, useraddr, sizeof(edata))) + return -EFAULT; + + dev->netdev_ops->set_rx_csum(dev, edata.data); + return 0; +} + +static int ethtool_get_tx_csum(struct net_device *dev, char *useraddr) +{ + struct ethtool_value edata = { ETHTOOL_GTXCSUM }; + + if (!dev->netdev_ops->get_tx_csum) + return -EOPNOTSUPP; + + edata.data = dev->netdev_ops->get_tx_csum(dev); + + if (copy_to_user(useraddr, &edata, sizeof(edata))) + return -EFAULT; + return 0; +} + +static int ethtool_set_tx_csum(struct net_device *dev, char *useraddr) +{ + struct ethtool_value edata; + + if (!dev->netdev_ops->set_tx_csum) + return -EOPNOTSUPP; + + if (copy_from_user(&edata, useraddr, sizeof(edata))) + return -EFAULT; + + return dev->netdev_ops->set_tx_csum(dev, edata.data); +} + +static int ethtool_get_sg(struct net_device *dev, char *useraddr) +{ + struct ethtool_value edata = { ETHTOOL_GSG }; + + if (!dev->netdev_ops->get_sg) + return -EOPNOTSUPP; + + edata.data = dev->netdev_ops->get_sg(dev); + + if (copy_to_user(useraddr, &edata, sizeof(edata))) + return -EFAULT; + return 0; +} + +static int ethtool_set_sg(struct net_device *dev, char *useraddr) +{ + struct ethtool_value edata; + + if (!dev->netdev_ops->set_sg) + return -EOPNOTSUPP; + + if (copy_from_user(&edata, useraddr, sizeof(edata))) + return -EFAULT; + + return dev->netdev_ops->set_sg(dev, edata.data); +} + +static int ethtool_self_test(struct net_device *dev, char *useraddr) +{ + struct ethtool_test test; + struct netdev_ops *ops = dev->netdev_ops; + u64 *data; + int ret; + + if (!ops->self_test || !ops->self_test_len) + return -EOPNOTSUPP; + + if (copy_from_user(&test, useraddr, sizeof(test))) + return -EFAULT; + + data = kmalloc(ops->self_test_len(&test), GFP_KERNEL); + if (!data) + return -ENOMEM; + + ops->self_test(dev, &test, data); + + ret = 0; + if (copy_to_user(useraddr, &test, sizeof(test))) + ret = -EFAULT; + useraddr += sizeof(test); + if (copy_to_user(useraddr, data, sizeof(u64) * test.len)) + ret = -EFAULT; + + kfree(data); + return ret; +} + +static int ethtool_get_strings(struct net_device *dev, void *useraddr) +{ + struct ethtool_gstrings gstrings; + struct netdev_ops *ops = dev->netdev_ops; + u8 *data; + int ret; + + if (!ops->get_strings || !ops->get_strings_len) + return -EOPNOTSUPP; + + if (copy_from_user(&gstrings, useraddr, sizeof(gstrings))) + return -EFAULT; + + data = kmalloc(ops->get_strings_len(&gstrings), GFP_KERNEL); + if (!data) + return -ENOMEM; + + ops->get_strings(dev, &gstrings, data); + + ret= 0; + if (copy_to_user(useraddr, &gstrings, sizeof(gstrings))) + ret = -EFAULT; + useraddr += sizeof(gstrings); + if (copy_to_user(useraddr, data, gstrings.len * ETH_GSTRING_LEN)) + ret = -EFAULT; + + kfree(data); + return ret; +} + +static int ethtool_phys_id(struct net_device *dev, void *useraddr) +{ + struct ethtool_value id; + + if (!dev->netdev_ops->phys_id) + return -EOPNOTSUPP; + + if (copy_from_user(&id, useraddr, sizeof(id))) + return -EFAULT; + + dev->netdev_ops->phys_id(dev, id.data); + return 0; +} + +static int ethtool_get_stats(struct net_device *dev, void *useraddr) +{ + struct ethtool_stats stats; + struct netdev_ops *ops = dev->netdev_ops; + u64 *data; + int ret; + + if (!ops->get_stats || !ops->get_stats_len) + return -EOPNOTSUPP; + + if (copy_from_user(&stats, useraddr, sizeof(stats))) + return -EFAULT; + + data = kmalloc(ops->get_stats_len(&stats), GFP_KERNEL); + if (!data) + return -ENOMEM; + + ops->get_stats(dev, &stats, data); + + ret= 0; + if (copy_to_user(useraddr, &stats, sizeof(stats))) + ret = -EFAULT; + useraddr += sizeof(stats); + if (copy_to_user(useraddr, data, stats.n_stats * sizeof(u64))) + ret = -EFAULT; + + kfree(data); + return ret; +} + +int dev_ethtool(struct ifreq *ifr) +{ + struct net_device *dev = __dev_get_by_name(ifr->ifr_name); + void *useraddr = (void *) ifr->ifr_data; + u32 ethcmd; + + /* XXX: We can make this more finegrained now. Keep existing + * behaviour for the moment. + */ + if (!capable(CAP_NET_ADMIN)) + return -EPERM; + + if (!dev || !netif_device_present(dev)) + return -ENODEV; + + if (!dev->netdev_ops) + goto ioctl; + + if (copy_from_user (ðcmd, useraddr, sizeof (ethcmd))) + return -EFAULT; + + switch (ethcmd) { + case ETHTOOL_GSET: + return ethtool_get_settings(dev, useraddr); + case ETHTOOL_SSET: + return ethtool_set_settings(dev, useraddr); + case ETHTOOL_GDRVINFO: + return ethtool_get_drvinfo(dev, useraddr); + case ETHTOOL_GREGS: + return ethtool_get_regs(dev, useraddr); + case ETHTOOL_GWOL: + return ethtool_get_wol(dev, useraddr); + case ETHTOOL_SWOL: + return ethtool_set_wol(dev, useraddr); + case ETHTOOL_GMSGLVL: + return ethtool_get_msglevel(dev, useraddr); + case ETHTOOL_SMSGLVL: + return ethtool_set_msglevel(dev, useraddr); + case ETHTOOL_NWAY_RST: + return ethtool_nway_reset(dev); + case ETHTOOL_GLINK: + return ethtool_get_link(dev, useraddr); + case ETHTOOL_GEEPROM: + return ethtool_get_eeprom(dev, useraddr); + case ETHTOOL_SEEPROM: + return ethtool_set_eeprom(dev, useraddr); + case ETHTOOL_GCOALESCE: + return ethtool_get_coalesce(dev, useraddr); + case ETHTOOL_SCOALESCE: + return ethtool_set_coalesce(dev, useraddr); + case ETHTOOL_GRINGPARAM: + return ethtool_get_ringparam(dev, useraddr); + case ETHTOOL_SRINGPARAM: + return ethtool_set_ringparam(dev, useraddr); + case ETHTOOL_GPAUSEPARAM: + return ethtool_get_pauseparam(dev, useraddr); + case ETHTOOL_SPAUSEPARAM: + return ethtool_set_pauseparam(dev, useraddr); + case ETHTOOL_GRXCSUM: + return ethtool_get_rx_csum(dev, useraddr); + case ETHTOOL_SRXCSUM: + return ethtool_set_rx_csum(dev, useraddr); + case ETHTOOL_GTXCSUM: + return ethtool_get_tx_csum(dev, useraddr); + case ETHTOOL_STXCSUM: + return ethtool_set_tx_csum(dev, useraddr); + case ETHTOOL_GSG: + return ethtool_get_sg(dev, useraddr); + case ETHTOOL_SSG: + return ethtool_set_sg(dev, useraddr); + case ETHTOOL_TEST: + return ethtool_self_test(dev, useraddr); + case ETHTOOL_GSTRINGS: + return ethtool_get_strings(dev, useraddr); + case ETHTOOL_PHYS_ID: + return ethtool_phys_id(dev, useraddr); + case ETHTOOL_GSTATS: + return ethtool_get_stats(dev, useraddr); + default: + return -EOPNOTSUPP; + } + + ioctl: + if (dev->do_ioctl) + return dev->do_ioctl(dev, ifr, SIOCETHTOOL); + return -EOPNOTSUPP; +} + Index: drivers/net/tg3.c =================================================================== RCS file: /var/cvs/linux-2.5/drivers/net/tg3.c,v retrieving revision 1.16 diff -u -p -r1.16 tg3.c --- drivers/net/tg3.c 14 Jun 2003 22:15:21 -0000 1.16 +++ drivers/net/tg3.c 8 Jul 2003 14:03:04 -0000 @@ -5036,16 +5036,24 @@ static void tg3_set_rx_mode(struct net_d #define TG3_REGDUMP_LEN (32 * 1024) -static u8 *tg3_get_regs(struct tg3 *tp) +static int tg3_get_regs_len(struct ethtool_regs *regs) { - u8 *orig_p = kmalloc(TG3_REGDUMP_LEN, GFP_KERNEL); - u8 *p; + if (regs->len > TG3_REGDUMP_LEN) + regs->len = TG3_REGDUMP_LEN; + return regs->len; +} + +static void tg3_get_regs(struct net_device *dev, struct ethtool_regs *regs, void *p) +{ + struct tg3 *tp = dev->priv; + u8 *orig_p = p; int i; - if (orig_p == NULL) - return NULL; + if (regs->len > TG3_REGDUMP_LEN) + regs->len = TG3_REGDUMP_LEN; + regs->version = 0; - memset(orig_p, 0, TG3_REGDUMP_LEN); + memset(p, 0, TG3_REGDUMP_LEN); spin_lock_irq(&tp->lock); spin_lock(&tp->tx_lock); @@ -5099,390 +5107,291 @@ do { p = orig_p + (reg); \ spin_unlock(&tp->tx_lock); spin_unlock_irq(&tp->lock); - - return orig_p; } -static int tg3_ethtool_ioctl (struct net_device *dev, void *useraddr) +static int tg3_get_settings(struct net_device *dev, struct ethtool_cmd *cmd) { struct tg3 *tp = dev->priv; - struct pci_dev *pci_dev = tp->pdev; - u32 ethcmd; - - if (copy_from_user (ðcmd, useraddr, sizeof (ethcmd))) - return -EFAULT; - switch (ethcmd) { - case ETHTOOL_GDRVINFO:{ - struct ethtool_drvinfo info = { ETHTOOL_GDRVINFO }; - strcpy (info.driver, DRV_MODULE_NAME); - strcpy (info.version, DRV_MODULE_VERSION); - memset(&info.fw_version, 0, sizeof(info.fw_version)); - strcpy (info.bus_info, pci_dev->slot_name); - info.eedump_len = 0; - info.regdump_len = TG3_REGDUMP_LEN; - if (copy_to_user (useraddr, &info, sizeof (info))) - return -EFAULT; - return 0; - } + if (!(tp->tg3_flags & TG3_FLAG_INIT_COMPLETE) || + tp->link_config.phy_is_low_power) + return -EAGAIN; + + cmd->supported = (SUPPORTED_Autoneg); + + if (!(tp->tg3_flags & TG3_FLAG_10_100_ONLY)) + cmd->supported |= (SUPPORTED_1000baseT_Half | + SUPPORTED_1000baseT_Full); + + if (tp->phy_id != PHY_ID_SERDES) + cmd->supported |= (SUPPORTED_100baseT_Half | + SUPPORTED_100baseT_Full | + SUPPORTED_10baseT_Half | + SUPPORTED_10baseT_Full | + SUPPORTED_MII); + else + cmd->supported |= SUPPORTED_FIBRE; - case ETHTOOL_GSET: { - struct ethtool_cmd cmd = { ETHTOOL_GSET }; + cmd->advertising = tp->link_config.advertising; + cmd->speed = tp->link_config.active_speed; + cmd->duplex = tp->link_config.active_duplex; + cmd->port = 0; + cmd->phy_address = PHY_ADDR; + cmd->transceiver = 0; + cmd->autoneg = tp->link_config.autoneg; + cmd->maxtxpkt = 0; + cmd->maxrxpkt = 0; + return 0; +} - if (!(tp->tg3_flags & TG3_FLAG_INIT_COMPLETE) || - tp->link_config.phy_is_low_power) - return -EAGAIN; - cmd.supported = (SUPPORTED_Autoneg); - - if (!(tp->tg3_flags & TG3_FLAG_10_100_ONLY)) - cmd.supported |= (SUPPORTED_1000baseT_Half | - SUPPORTED_1000baseT_Full); - - if (tp->phy_id != PHY_ID_SERDES) - cmd.supported |= (SUPPORTED_100baseT_Half | - SUPPORTED_100baseT_Full | - SUPPORTED_10baseT_Half | - SUPPORTED_10baseT_Full | - SUPPORTED_MII); - else - cmd.supported |= SUPPORTED_FIBRE; +static int tg3_set_settings(struct net_device *dev, struct ethtool_cmd *cmd) +{ + struct tg3 *tp = dev->priv; - cmd.advertising = tp->link_config.advertising; - cmd.speed = tp->link_config.active_speed; - cmd.duplex = tp->link_config.active_duplex; - cmd.port = 0; - cmd.phy_address = PHY_ADDR; - cmd.transceiver = 0; - cmd.autoneg = tp->link_config.autoneg; - cmd.maxtxpkt = 0; - cmd.maxrxpkt = 0; - if (copy_to_user(useraddr, &cmd, sizeof(cmd))) - return -EFAULT; - return 0; + if (!(tp->tg3_flags & TG3_FLAG_INIT_COMPLETE) || + tp->link_config.phy_is_low_power) + return -EAGAIN; + + if (cmd->autoneg == AUTONEG_ENABLE) { + tp->link_config.advertising = cmd->advertising; + tp->link_config.speed = SPEED_INVALID; + tp->link_config.duplex = DUPLEX_INVALID; + } else { + tp->link_config.speed = cmd->speed; + tp->link_config.duplex = cmd->duplex; } - case ETHTOOL_SSET: { - struct ethtool_cmd cmd; - - if (!(tp->tg3_flags & TG3_FLAG_INIT_COMPLETE) || - tp->link_config.phy_is_low_power) - return -EAGAIN; - - if (copy_from_user(&cmd, useraddr, sizeof(cmd))) - return -EFAULT; - - /* Fiber PHY only supports 1000 full/half */ - if (cmd.autoneg == AUTONEG_ENABLE) { - if (tp->phy_id == PHY_ID_SERDES && - (cmd.advertising & - (ADVERTISED_10baseT_Half | - ADVERTISED_10baseT_Full | - ADVERTISED_100baseT_Half | - ADVERTISED_100baseT_Full))) - return -EINVAL; - if ((tp->tg3_flags & TG3_FLAG_10_100_ONLY) && - (cmd.advertising & - (ADVERTISED_1000baseT_Half | - ADVERTISED_1000baseT_Full))) - return -EINVAL; - } else { - if (tp->phy_id == PHY_ID_SERDES && - (cmd.speed == SPEED_10 || - cmd.speed == SPEED_100)) - return -EINVAL; - if ((tp->tg3_flags & TG3_FLAG_10_100_ONLY) && - (cmd.speed == SPEED_10 || - cmd.speed == SPEED_100)) - return -EINVAL; - } - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); - - tp->link_config.autoneg = cmd.autoneg; - if (cmd.autoneg == AUTONEG_ENABLE) { - tp->link_config.advertising = cmd.advertising; - tp->link_config.speed = SPEED_INVALID; - tp->link_config.duplex = DUPLEX_INVALID; - } else { - tp->link_config.speed = cmd.speed; - tp->link_config.duplex = cmd.duplex; - } + tg3_setup_phy(tp); + spin_unlock(&tp->tx_lock); + spin_unlock_irq(&tp->lock); - tg3_setup_phy(tp); - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + return 0; +} - return 0; - } +static void tg3_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info) +{ + struct tg3 *tp = dev->priv; + struct pci_dev *pci_dev = tp->pdev; - case ETHTOOL_GREGS: { - struct ethtool_regs regs; - u8 *regbuf; - int ret; - - if (copy_from_user(®s, useraddr, sizeof(regs))) - return -EFAULT; - if (regs.len > TG3_REGDUMP_LEN) - regs.len = TG3_REGDUMP_LEN; - regs.version = 0; - if (copy_to_user(useraddr, ®s, sizeof(regs))) - return -EFAULT; - - regbuf = tg3_get_regs(tp); - if (!regbuf) - return -ENOMEM; - - useraddr += offsetof(struct ethtool_regs, data); - ret = 0; - if (copy_to_user(useraddr, regbuf, regs.len)) - ret = -EFAULT; - kfree(regbuf); - return ret; - } - case ETHTOOL_GWOL: { - struct ethtool_wolinfo wol = { ETHTOOL_GWOL }; - - wol.supported = WAKE_MAGIC; - wol.wolopts = 0; - if (tp->tg3_flags & TG3_FLAG_WOL_ENABLE) - wol.wolopts = WAKE_MAGIC; - memset(&wol.sopass, 0, sizeof(wol.sopass)); - if (copy_to_user(useraddr, &wol, sizeof(wol))) - return -EFAULT; - return 0; - } - case ETHTOOL_SWOL: { - struct ethtool_wolinfo wol; + strcpy(info->driver, DRV_MODULE_NAME); + strcpy(info->version, DRV_MODULE_VERSION); + memset(&info->fw_version, 0, sizeof(info->fw_version)); + strcpy(info->bus_info, pci_dev->slot_name); + info->eedump_len = 0; + info->regdump_len = TG3_REGDUMP_LEN; +} - if (copy_from_user(&wol, useraddr, sizeof(wol))) - return -EFAULT; - if (wol.wolopts & ~WAKE_MAGIC) - return -EINVAL; - if ((wol.wolopts & WAKE_MAGIC) && - tp->phy_id == PHY_ID_SERDES && - !(tp->tg3_flags & TG3_FLAG_SERDES_WOL_CAP)) - return -EINVAL; +static void tg3_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol) +{ + struct tg3 *tp = dev->priv; - spin_lock_irq(&tp->lock); - if (wol.wolopts & WAKE_MAGIC) - tp->tg3_flags |= TG3_FLAG_WOL_ENABLE; - else - tp->tg3_flags &= ~TG3_FLAG_WOL_ENABLE; - spin_unlock_irq(&tp->lock); + wol->supported = WAKE_MAGIC; + wol->wolopts = 0; + if (tp->tg3_flags & TG3_FLAG_WOL_ENABLE) + wol->wolopts = WAKE_MAGIC; + memset(&wol->sopass, 0, sizeof(wol->sopass)); +} - return 0; - } - case ETHTOOL_GMSGLVL: { - struct ethtool_value edata = { ETHTOOL_GMSGLVL }; - edata.data = tp->msg_enable; - if (copy_to_user(useraddr, &edata, sizeof(edata))) - return -EFAULT; - return 0; - } - case ETHTOOL_SMSGLVL: { - struct ethtool_value edata; - if (copy_from_user(&edata, useraddr, sizeof(edata))) - return -EFAULT; - tp->msg_enable = edata.data; - return 0; - } - case ETHTOOL_NWAY_RST: { - u32 bmcr; - int r; +static int tg3_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol) +{ + struct tg3 *tp = dev->priv; - spin_lock_irq(&tp->lock); - tg3_readphy(tp, MII_BMCR, &bmcr); - tg3_readphy(tp, MII_BMCR, &bmcr); - r = -EINVAL; - if (bmcr & BMCR_ANENABLE) { - tg3_writephy(tp, MII_BMCR, - bmcr | BMCR_ANRESTART); - r = 0; - } - spin_unlock_irq(&tp->lock); + if (wol->wolopts & ~WAKE_MAGIC) + return -EINVAL; + if ((wol->wolopts & WAKE_MAGIC) && + tp->phy_id == PHY_ID_SERDES && + !(tp->tg3_flags & TG3_FLAG_SERDES_WOL_CAP)) + return -EINVAL; - return r; - } - case ETHTOOL_GLINK: { - struct ethtool_value edata = { ETHTOOL_GLINK }; - edata.data = netif_carrier_ok(tp->dev) ? 1 : 0; - if (copy_to_user(useraddr, &edata, sizeof(edata))) - return -EFAULT; - return 0; - } - case ETHTOOL_GRINGPARAM: { - struct ethtool_ringparam ering = { ETHTOOL_GRINGPARAM }; + spin_lock_irq(&tp->lock); + if (wol->wolopts & WAKE_MAGIC) + tp->tg3_flags |= TG3_FLAG_WOL_ENABLE; + else + tp->tg3_flags &= ~TG3_FLAG_WOL_ENABLE; + spin_unlock_irq(&tp->lock); - ering.rx_max_pending = TG3_RX_RING_SIZE - 1; - ering.rx_mini_max_pending = 0; - ering.rx_jumbo_max_pending = TG3_RX_JUMBO_RING_SIZE - 1; - - ering.rx_pending = tp->rx_pending; - ering.rx_mini_pending = 0; - ering.rx_jumbo_pending = tp->rx_jumbo_pending; - ering.tx_pending = tp->tx_pending; + return 0; +} - if (copy_to_user(useraddr, &ering, sizeof(ering))) - return -EFAULT; - return 0; - } - case ETHTOOL_SRINGPARAM: { - struct ethtool_ringparam ering; +static u32 tg3_get_msglevel(struct net_device *dev) +{ + struct tg3 *tp = dev->priv; + return tp->msg_enable; +} - if (copy_from_user(&ering, useraddr, sizeof(ering))) - return -EFAULT; +static void tg3_set_msglevel(struct net_device *dev, u32 value) +{ + struct tg3 *tp = dev->priv; + tp->msg_enable = value; +} - if ((ering.rx_pending > TG3_RX_RING_SIZE - 1) || - (ering.rx_jumbo_pending > TG3_RX_JUMBO_RING_SIZE - 1) || - (ering.tx_pending > TG3_TX_RING_SIZE - 1)) - return -EINVAL; +static int tg3_nway_reset(struct net_device *dev) +{ + struct tg3 *tp = dev->priv; + u32 bmcr; + int r; - tg3_netif_stop(tp); - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + spin_lock_irq(&tp->lock); + tg3_readphy(tp, MII_BMCR, &bmcr); + tg3_readphy(tp, MII_BMCR, &bmcr); + r = -EINVAL; + if (bmcr & BMCR_ANENABLE) { + tg3_writephy(tp, MII_BMCR, bmcr | BMCR_ANRESTART); + r = 0; + } + spin_unlock_irq(&tp->lock); - tp->rx_pending = ering.rx_pending; - tp->rx_jumbo_pending = ering.rx_jumbo_pending; - tp->tx_pending = ering.tx_pending; - - tg3_halt(tp); - tg3_init_rings(tp); - tg3_init_hw(tp); - netif_wake_queue(tp->dev); - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); - tg3_netif_start(tp); + return r; +} - return 0; - } - case ETHTOOL_GPAUSEPARAM: { - struct ethtool_pauseparam epause = { ETHTOOL_GPAUSEPARAM }; +static void tg3_get_ringparam(struct net_device *dev, struct ethtool_ringparam *ering) +{ + struct tg3 *tp = dev->priv; - epause.autoneg = - (tp->tg3_flags & TG3_FLAG_PAUSE_AUTONEG) != 0; - epause.rx_pause = - (tp->tg3_flags & TG3_FLAG_PAUSE_RX) != 0; - epause.tx_pause = - (tp->tg3_flags & TG3_FLAG_PAUSE_TX) != 0; - if (copy_to_user(useraddr, &epause, sizeof(epause))) - return -EFAULT; - return 0; - } - case ETHTOOL_SPAUSEPARAM: { - struct ethtool_pauseparam epause; + ering->rx_max_pending = TG3_RX_RING_SIZE - 1; + ering->rx_mini_max_pending = 0; + ering->rx_jumbo_max_pending = TG3_RX_JUMBO_RING_SIZE - 1; + + ering->rx_pending = tp->rx_pending; + ering->rx_mini_pending = 0; + ering->rx_jumbo_pending = tp->rx_jumbo_pending; + ering->tx_pending = tp->tx_pending; +} - if (copy_from_user(&epause, useraddr, sizeof(epause))) - return -EFAULT; +static int tg3_set_ringparam(struct net_device *dev, struct ethtool_ringparam *ering) +{ + struct tg3 *tp = dev->priv; - tg3_netif_stop(tp); - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); - if (epause.autoneg) - tp->tg3_flags |= TG3_FLAG_PAUSE_AUTONEG; - else - tp->tg3_flags &= ~TG3_FLAG_PAUSE_AUTONEG; - if (epause.rx_pause) - tp->tg3_flags |= TG3_FLAG_PAUSE_RX; - else - tp->tg3_flags &= ~TG3_FLAG_PAUSE_RX; - if (epause.tx_pause) - tp->tg3_flags |= TG3_FLAG_PAUSE_TX; - else - tp->tg3_flags &= ~TG3_FLAG_PAUSE_TX; - tg3_halt(tp); - tg3_init_rings(tp); - tg3_init_hw(tp); - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); - tg3_netif_start(tp); + if ((ering->rx_pending > TG3_RX_RING_SIZE - 1) || + (ering->rx_jumbo_pending > TG3_RX_JUMBO_RING_SIZE - 1) || + (ering->tx_pending > TG3_TX_RING_SIZE - 1)) + return -EINVAL; - return 0; - } - case ETHTOOL_GRXCSUM: { - struct ethtool_value edata = { ETHTOOL_GRXCSUM }; + tg3_netif_stop(tp); + spin_lock_irq(&tp->lock); + spin_lock(&tp->tx_lock); - edata.data = - (tp->tg3_flags & TG3_FLAG_RX_CHECKSUMS) != 0; - if (copy_to_user(useraddr, &edata, sizeof(edata))) - return -EFAULT; - return 0; - } - case ETHTOOL_SRXCSUM: { - struct ethtool_value edata; + tp->rx_pending = ering->rx_pending; + tp->rx_jumbo_pending = ering->rx_jumbo_pending; + tp->tx_pending = ering->tx_pending; + + tg3_halt(tp); + tg3_init_rings(tp); + tg3_init_hw(tp); + netif_wake_queue(tp->dev); + spin_unlock(&tp->tx_lock); + spin_unlock_irq(&tp->lock); + tg3_netif_start(tp); - if (copy_from_user(&edata, useraddr, sizeof(edata))) - return -EFAULT; + return 0; +} - if (tp->tg3_flags & TG3_FLAG_BROKEN_CHECKSUMS) { - if (edata.data != 0) - return -EINVAL; - return 0; - } +static void tg3_get_pauseparam(struct net_device *dev, struct ethtool_pauseparam *epause) +{ + struct tg3 *tp = dev->priv; - spin_lock_irq(&tp->lock); - if (edata.data) - tp->tg3_flags |= TG3_FLAG_RX_CHECKSUMS; - else - tp->tg3_flags &= ~TG3_FLAG_RX_CHECKSUMS; - spin_unlock_irq(&tp->lock); + epause->autoneg = (tp->tg3_flags & TG3_FLAG_PAUSE_AUTONEG) != 0; + epause->rx_pause = (tp->tg3_flags & TG3_FLAG_PAUSE_RX) != 0; + epause->tx_pause = (tp->tg3_flags & TG3_FLAG_PAUSE_TX) != 0; +} - return 0; - } - case ETHTOOL_GTXCSUM: { - struct ethtool_value edata = { ETHTOOL_GTXCSUM }; +static int tg3_set_pauseparam(struct net_device *dev, struct ethtool_pauseparam *epause) +{ + struct tg3 *tp = dev->priv; - edata.data = - (tp->dev->features & NETIF_F_IP_CSUM) != 0; - if (copy_to_user(useraddr, &edata, sizeof(edata))) - return -EFAULT; - return 0; - } - case ETHTOOL_STXCSUM: { - struct ethtool_value edata; + tg3_netif_stop(tp); + spin_lock_irq(&tp->lock); + spin_lock(&tp->tx_lock); + if (epause->autoneg) + tp->tg3_flags |= TG3_FLAG_PAUSE_AUTONEG; + else + tp->tg3_flags &= ~TG3_FLAG_PAUSE_AUTONEG; + if (epause->rx_pause) + tp->tg3_flags |= TG3_FLAG_PAUSE_RX; + else + tp->tg3_flags &= ~TG3_FLAG_PAUSE_RX; + if (epause->tx_pause) + tp->tg3_flags |= TG3_FLAG_PAUSE_TX; + else + tp->tg3_flags &= ~TG3_FLAG_PAUSE_TX; + tg3_halt(tp); + tg3_init_rings(tp); + tg3_init_hw(tp); + spin_unlock(&tp->tx_lock); + spin_unlock_irq(&tp->lock); + tg3_netif_start(tp); - if (copy_from_user(&edata, useraddr, sizeof(edata))) - return -EFAULT; + return 0; +} - if (tp->tg3_flags & TG3_FLAG_BROKEN_CHECKSUMS) { - if (edata.data != 0) - return -EINVAL; - return 0; - } +static u32 tg3_get_rx_csum(struct net_device *dev) +{ + struct tg3 *tp = dev->priv; + return (tp->tg3_flags & TG3_FLAG_RX_CHECKSUMS) != 0; +} - if (edata.data) - tp->dev->features |= NETIF_F_IP_CSUM; - else - tp->dev->features &= ~NETIF_F_IP_CSUM; +static int tg3_set_rx_csum(struct net_device *dev, u32 data) +{ + struct tg3 *tp = dev->priv; + if (tp->tg3_flags & TG3_FLAG_BROKEN_CHECKSUMS) { + if (data != 0) + return -EINVAL; return 0; } - case ETHTOOL_GSG: { - struct ethtool_value edata = { ETHTOOL_GSG }; - edata.data = - (tp->dev->features & NETIF_F_SG) != 0; - if (copy_to_user(useraddr, &edata, sizeof(edata))) - return -EFAULT; - return 0; - } - case ETHTOOL_SSG: { - struct ethtool_value edata; + spin_lock_irq(&tp->lock); + if (data) + tp->tg3_flags |= TG3_FLAG_RX_CHECKSUMS; + else + tp->tg3_flags &= ~TG3_FLAG_RX_CHECKSUMS; + spin_unlock_irq(&tp->lock); - if (copy_from_user(&edata, useraddr, sizeof(edata))) - return -EFAULT; + return 0; +} - if (edata.data) - tp->dev->features |= NETIF_F_SG; - else - tp->dev->features &= ~NETIF_F_SG; +static int tg3_set_tx_csum(struct net_device *dev, u32 data) +{ + struct tg3 *tp = dev->priv; + if (tp->tg3_flags & TG3_FLAG_BROKEN_CHECKSUMS) { + if (data != 0) + return -EINVAL; return 0; } - }; - return -EOPNOTSUPP; + if (data) + dev->features |= NETIF_F_IP_CSUM; + else + dev->features &= ~NETIF_F_IP_CSUM; + + return 0; } +static struct netdev_ops tg3_netdev_ops = { + .get_settings = tg3_get_settings, + .set_settings = tg3_set_settings, + .get_drvinfo = tg3_get_drvinfo, + .get_regs_len = tg3_get_regs_len, + .get_regs = tg3_get_regs, + .get_wol = tg3_get_wol, + .set_wol = tg3_set_wol, + .get_msglevel = tg3_get_msglevel, + .set_msglevel = tg3_set_msglevel, + .nway_reset = tg3_nway_reset, + .get_link = netdev_op_get_link, + .get_ringparam = tg3_get_ringparam, + .set_ringparam = tg3_set_ringparam, + .get_pauseparam = tg3_get_pauseparam, + .set_pauseparam = tg3_set_pauseparam, + .get_rx_csum = tg3_get_rx_csum, + .set_rx_csum = tg3_set_rx_csum, + .get_tx_csum = netdev_op_get_tx_csum, + .set_tx_csum = tg3_set_tx_csum, + .get_sg = netdev_op_get_sg, + .set_sg = netdev_op_set_sg, +}; + static int tg3_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) { struct mii_ioctl_data *data = (struct mii_ioctl_data *)&ifr->ifr_data; @@ -5490,8 +5399,6 @@ static int tg3_ioctl(struct net_device * int err; switch(cmd) { - case SIOCETHTOOL: - return tg3_ethtool_ioctl(dev, (void *) ifr->ifr_data); case SIOCGMIIPHY: data->phy_id = PHY_ADDR; @@ -6773,6 +6680,7 @@ static int __devinit tg3_init_one(struct tp->rx_jumbo_pending = TG3_DEF_RX_JUMBO_RING_PENDING; tp->tx_pending = TG3_DEF_TX_RING_PENDING; + dev->netdev_ops = &tg3_netdev_ops; dev->open = tg3_open; dev->stop = tg3_close; dev->get_stats = tg3_get_stats; -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From krkumar@us.ibm.com Tue Jul 8 11:44:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jul 2003 11:44:51 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h68Iic2x011292 for ; Tue, 8 Jul 2003 11:44:45 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h68Ihtxe237736; Tue, 8 Jul 2003 14:43:55 -0400 Received: from us.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h68IhrPw198614; Tue, 8 Jul 2003 12:43:54 -0600 Message-ID: <3F0B10E3.9050700@us.ibm.com> Date: Tue, 08 Jul 2003 11:43:47 -0700 From: Krishna Kumar Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" , kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Question about netlink Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3831 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: krkumar@us.ibm.com Precedence: bulk X-list: netdev Hi, Some of the netlink routines (eg rtnetlink_dump_ifinfo or inet6_dump_ifaddr) seem to get user arguments from cb->args['n']. However I was not able to figure out where the arguments are being set, can anyone help ? netlink_dump_start() is where the cb gets allocated (initialized to 0), and that calls netlink_dump(), which calls the assigned routine. I couldn't find where the args gets initialized to user provided values. Any pointer to what to look for is very much appreciated. Thanks, - KK From yoshfuji@linux-ipv6.org Tue Jul 8 12:03:20 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jul 2003 12:03:24 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h68J3I2x011727 for ; Tue, 8 Jul 2003 12:03:19 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h68J4YBo018135; Wed, 9 Jul 2003 04:04:34 +0900 Date: Wed, 09 Jul 2003 04:04:33 +0900 (JST) Message-Id: <20030709.040433.89038276.yoshfuji@linux-ipv6.org> To: krkumar@us.ibm.com Cc: davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: Question about netlink From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <3F0B10E3.9050700@us.ibm.com> References: <3F0B10E3.9050700@us.ibm.com> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3832 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <3F0B10E3.9050700@us.ibm.com> (at Tue, 08 Jul 2003 11:43:47 -0700), Krishna Kumar says: > Some of the netlink routines (eg rtnetlink_dump_ifinfo or inet6_dump_ifaddr) seem to get > user arguments from cb->args['n']. However I was not able to figure out where the > arguments are being set, can anyone help ? Take a look at net/core/rtnelink.c:rtnetlink_dump_ifinfo() net/core/neighbour.c:neigh_dump_{info,table}() and seek the truth. :-) --yoshfuji From jkenisto@us.ibm.com Tue Jul 8 12:47:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jul 2003 12:47:38 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h68JlJ2x012263 for ; Tue, 8 Jul 2003 12:47:26 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h68Jl5td166330; Tue, 8 Jul 2003 15:47:05 -0400 Received: from us.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h68Jl3nn037252; Tue, 8 Jul 2003 15:47:04 -0400 Message-ID: <3F0B1F56.D863F212@us.ibm.com> Date: Tue, 08 Jul 2003 12:45:26 -0700 From: Jim Keniston X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Morton CC: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, davem@redhat.com, jgarzik@pobox.com, alan@lxorguk.ukuu.org.uk, rddunlap@osdl.org Subject: Re: [PATCH - RFC] [1/2] 2.6 must-fix list - kernel error reporting References: <3F0AFFE6.E85FF283@us.ibm.com> <20030708105912.57015026.akpm@osdl.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3833 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkenisto@us.ibm.com Precedence: bulk X-list: netdev If you're going to reply to this, please change "netdev@oss.sgi.net" to "netdev@oss.sgi.com" in your cc list. My apologies for the error. Jim From jkenisto@us.ibm.com Tue Jul 8 13:01:32 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jul 2003 13:01:38 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h68K1O2x013039 for ; Tue, 8 Jul 2003 13:01:32 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h68K1Ixr171370 for ; Tue, 8 Jul 2003 16:01:19 -0400 Received: from us.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h68K1Ho1066990 for ; Tue, 8 Jul 2003 16:01:18 -0400 Message-ID: <3F0B22AC.1D600F98@us.ibm.com> Date: Tue, 08 Jul 2003 12:59:40 -0700 From: Jim Keniston X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: netdev Subject: [PATCH - RFC] 2.6 must-fix list - kernel error reporting Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3834 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkenisto@us.ibm.com Precedence: bulk X-list: netdev I posted this today on LKML. I intended to post to netdev as well, but botched the address. For the actual patches, see the LKML thread, or the indicated links. *Sigh.* Jim Keniston IBM Linux Technology Center ----- Andrew Morton's 2.6 must-fix list includes the following item: > o We need a kernel side API for reporting error events to userspace (could > be async to 2.6 itself) > > (Prototype core based on netlink exists) The enclosed patches provide a mechanism for reporting error events to user-mode applications via netlink. This mechanism supplements the text-oriented printk mechanism, providing a way to log binary data or a mixture of text+binary. Patch #1, closely based on a prototype by Dave Miller, implements the NETLINK_KERROR protocol for AF_NETLINK sockets. It provides two functions for broadcasting data packets to user-mode applications: in one, the caller provides a single data buffer, and in the other, the caller provides an iovec[]. Patch #2 (see accompanying post) provides an API built on patch #1's infrastructure. Patch #2's functions capture context about the error (e.g., driver/module, severity level, in interrupt or not, pid/uid/gid, CPU ID), pack this information into a header, add the error-specific data, and send the resulting packet via netlink. The two principal functions are: - evl_write(), which accepts an arbitrarily defined buffer of error-specific data; and - evl_printf(), which accepts a format string plus args, printk-style. Rather than combining the format and args, evl_printf() keeps them separate, as various developers have suggested. Thus the receiving application can easily determine both the type of error (as indicated by the raw format string) and the args' values, without parsing the message string. Applications that respond to kernel errors can establish AF_NETLINK/NETLINK_KERROR sockets and receive the error packets directly; or they can register with an event subsystem (e.g., see evlog.sourceforge.net), which will deliver events that match specific criteria. These patches are posted on evlog.sourceforge.net. (Click on "Latest Release"; then scroll down to "evlog-2.5_kernel/evlog + netlink". Or just follow the links posted below.) Also posted there is a tar file, kerrord.tar.gz, which contains: - a sample module that logs errors using evl_write() and evl_printf(); and - a sample daemon that reads such errors from netlink and logs them. Jim Keniston IBM Linux Technology Center http://prdownloads.sourceforge.net/evlog/kerror-2.5.74.patch?download http://prdownloads.sourceforge.net/evlog/evlog-2.5.74.patch?download http://prdownloads.sourceforge.net/evlog/kerrord.tar.gz?download From bob.olszewski@cmstk.com Tue Jul 8 13:05:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jul 2003 13:05:39 -0700 (PDT) Received: from corp148mr2.mcgraw-hill.com (corp148mr2.mcgraw-hill.com [198.45.18.163]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h68K5U2x013399 for ; Tue, 8 Jul 2003 13:05:35 -0700 Received: by corp148mr2.mcgraw-hill.com (Switch-3.0.4/Switch-3.0.0) with SMTP id h68K43ee023114 for ; Tue, 8 Jul 2003 16:04:04 -0400 (EDT) X-Lotus-FromDomain: SPC From: bob.olszewski@cmstk.com To: netdev@oss.sgi.com Message-ID: <85256D5D.006E5858.00@spchar2.spcomstock.com> Date: Tue, 8 Jul 2003 16:05:17 -0400 Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=AsfbwQBSZ3ABPOlMYzrAmVy5BJLvMN0BWIEaZcE1AN429kY1IRvNzRqx" Content-Disposition: inline X-archive-position: 3835 Subject: (no subject) X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bob.olszewski@cmstk.com Precedence: bulk X-list: netdev --0__=AsfbwQBSZ3ABPOlMYzrAmVy5BJLvMN0BWIEaZcE1AN429kY1IRvNzRqx Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I caught your name on a site and was wondering if you had any advise on this scenario. I'm running HA on multi-networked server, one interface (eth1) --0__=AsfbwQBSZ3ABPOlMYzrAmVy5BJLvMN0BWIEaZcE1AN429kY1IRvNzRqx Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable =A0is a member of the HA group that customers connect to, the other (eth0) is where it ge= ts its feed from ( not running HA). =A0Problem I have, is if the feed source i= nterface (eth0) goes down the server can not deliver data. I can not run eth0 in HA, our app. on the feed source side allows only = one connection. Is there any way to config heartbeat to recognize that if a non-HA'd in= terface goes down to make the interface that "is" in an HA group fail over ? = --0__=AsfbwQBSZ3ABPOlMYzrAmVy5BJLvMN0BWIEaZcE1AN429kY1IRvNzRqx-- From krkumar@us.ibm.com Tue Jul 8 13:29:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jul 2003 13:29:09 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h68KSq2x027846 for ; Tue, 8 Jul 2003 13:29:01 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h68KS1DG285948; Tue, 8 Jul 2003 16:28:01 -0400 Received: from us.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h68KRxPw018890; Tue, 8 Jul 2003 14:28:00 -0600 Message-ID: <3F0B294A.9060302@us.ibm.com> Date: Tue, 08 Jul 2003 13:27:54 -0700 From: Krishna Kumar Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: yoshfuji@linux-ipv6.org CC: davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: Question about netlink References: <3F0B10E3.9050700@us.ibm.com> <20030709.040433.89038276.yoshfuji@linux-ipv6.org> In-Reply-To: <20030709.040433.89038276.yoshfuji@linux-ipv6.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3836 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: krkumar@us.ibm.com Precedence: bulk X-list: netdev I am still not convinced how it works, though I have been trying to seek the truth for some time now :-). These routines 'get' the value of args[0] and then 'set' it to the resultant value. How is this value set in the first place to the user provided value ? It seems to be initialized to ZERO in netlink_dump_start(). The only way it seems to use the value is if it gets called twice from netlink_dump(), the first time cb->args will be set to zero's while the second time it will have the values set by the first invocation to the same routine. Am I missing something or is 'args' not intended for user specified arguments ? If so, how should we access the arguments passed by the user ? Thanks, - KK YOSHIFUJI Hideaki wrote: > In article <3F0B10E3.9050700@us.ibm.com> (at Tue, 08 Jul 2003 11:43:47 -0700), Krishna Kumar says: > > >>Some of the netlink routines (eg rtnetlink_dump_ifinfo or inet6_dump_ifaddr) seem to get >>user arguments from cb->args['n']. However I was not able to figure out where the >>arguments are being set, can anyone help ? > > > Take a look at net/core/rtnelink.c:rtnetlink_dump_ifinfo() > net/core/neighbour.c:neigh_dump_{info,table}() > and seek the truth. :-) > > --yoshfuji > From greearb@candelatech.com Tue Jul 8 13:44:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jul 2003 13:44:51 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-074.evrtwa1.dsl-verizon.net [4.33.45.74]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h68Kij2x028272 for ; Tue, 8 Jul 2003 13:44:46 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h68KiWKk015548; Tue, 8 Jul 2003 13:44:35 -0700 Message-ID: <3F0B2D30.4020102@candelatech.com> Date: Tue, 08 Jul 2003 13:44:32 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Wilcox CC: netdev@oss.sgi.com Subject: Re: [PATCH] netdev_ops References: <20030708163042.GL23597@parcelfarce.linux.theplanet.co.uk> In-Reply-To: <20030708163042.GL23597@parcelfarce.linux.theplanet.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3837 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Matthew Wilcox wrote: > After a conversation with acme, I realised that ethtool_ops is far too > narrow scope. What we need are netdev_ops. This patch renames the > ethtool_ops to netdev_ops and fixes some other minor flaws: > > - add _len() ops for operations which previously had to kmalloc their > own memory. > - move the netdev_ops from ethtool.h to netdevice.h > - makes some ops generic as requested by Jeff Garzik. > > I think netdev_ops is still a little too ethtool-specific; something > I'd like to do is convert the parameters to be a little less > ethtool-related. For example, instead of ->get_drvinfo, I'd like to > see ethtool_get_drvinfo() call several methods and fill in all the data > that way. > > But let's see what everyone thinks of this patch first ... > > + * Each operation is passed a &struct net_device as its first parameter. Some of these are missing their netdevice arg? > + int (*get_regs_len)(struct ethtool_regs *); > + int (*self_test_len)(struct ethtool_test *); > + int (*get_strings_len)(struct ethtool_gstrings *); > + int (*get_stats_len)(struct ethtool_stats *); -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From willy@www.linux.org.uk Tue Jul 8 14:25:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jul 2003 14:25:59 -0700 (PDT) Received: from www.linux.org.uk (IDENT:ZMJsD5p6cj1AQQe+eOWA9Gi94DMngJxa@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h68LPq2x002552 for ; Tue, 8 Jul 2003 14:25:53 -0700 Received: from willy by www.linux.org.uk with local (Exim 4.14) id 19ZzyB-0006GR-Cf; Tue, 08 Jul 2003 22:25:51 +0100 Date: Tue, 8 Jul 2003 22:25:51 +0100 From: Matthew Wilcox To: Ben Greear Cc: Matthew Wilcox , netdev@oss.sgi.com Subject: Re: [PATCH] netdev_ops Message-ID: <20030708212551.GL1939@parcelfarce.linux.theplanet.co.uk> References: <20030708163042.GL23597@parcelfarce.linux.theplanet.co.uk> <3F0B2D30.4020102@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F0B2D30.4020102@candelatech.com> User-Agent: Mutt/1.4.1i X-archive-position: 3838 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@debian.org Precedence: bulk X-list: netdev On Tue, Jul 08, 2003 at 01:44:32PM -0700, Ben Greear wrote: > Some of these are missing their netdevice arg? > >+ int (*get_regs_len)(struct ethtool_regs *); > >+ int (*self_test_len)(struct ethtool_test *); > >+ int (*get_strings_len)(struct ethtool_gstrings *); > >+ int (*get_stats_len)(struct ethtool_stats *); Well, they don't actually need it -- these are more attributes of the underlying driver than they are of any individual network device. I suspect at least one of them isn't needed, and I'm sure the e1000 guys are about to tell me which one ;-) -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From lunz@falooley.org Tue Jul 8 15:12:57 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jul 2003 15:13:04 -0700 (PDT) Received: from orr (mail@dsl027-161-081.atl1.dsl.speakeasy.net [216.27.161.81]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h68MCt2x003280 for ; Tue, 8 Jul 2003 15:12:56 -0700 Received: from lunz by orr with local (Exim 3.36 #1 (Debian)) id 19a0hT-0005NC-00; Tue, 08 Jul 2003 18:12:39 -0400 Date: Tue, 8 Jul 2003 18:12:39 -0400 To: netdev@oss.sgi.com Cc: jmorris@intercode.com.au, davem@redhat.com Subject: [PATCH RESEND 2.4, 2.5] dev->promiscuity refcounting broken in af_packet.c Message-ID: <20030708221239.GA20633@orr.falooley.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i From: Jason Lunz X-archive-position: 3840 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lunz@falooley.org Precedence: bulk X-list: netdev According to today's bkcvs, the below patch still hasn't been applied to 2.4 or 2.5 despite a -pre release or two, Alexey reviewed it and recommended for inclusion. James, I know you applied it to your bk tree. Will that be enough to get it into 2.4 and 2.5, or should I submit it elsewhere? Jason lunz@falooley.org said: > The problem is that packet sockets are calling dev_set_promiscuity too > many times. For example, if I take an unconfigured interface and do: > > halfoat:~ # ip link show eth1 > 9: eth1: mtu 1500 qdisc pfifo_fast qlen 100 > link/ether 00:30:48:41:62:12 brd ff:ff:ff:ff:ff:ff > halfoat:~ # ip link set up eth1 > halfoat:~ # tcpdump -i eth1 & > [1] 457 > tcpdump: WARNING: eth1: no IPv4 address assigned > tcpdump: listening on eth1 > halfoat:~ # ip link set down eth1 > tcpdump: pcap_loop: recvfrom: Network is down > [1]+ Exit 1 tcpdump -i eth1 > halfoat:~ # ip link show eth1 > 9: eth1: mtu 1500 qdisc pfifo_fast qlen 100 > link/ether 00:30:48:41:62:12 brd ff:ff:ff:ff:ff:ff > > eth1 is now in promiscuous mode because dev->promiscuity is -1 (!= 0). > > When the interface goes down, dev_change_flags calls dev_close, which > sends NETDEV_DOWN down the netdev notifier chain. Because tcpdump has a > packet socket open, packet_notifier calls packet_dev_mclist -> > packet_dev_mc -> dev_set_promiscuity. > > When tcpdump gets ENETDOWN, it aborts, closing the packet socket. > af_packet.c's proto_ops->release cleanup method is packet_release. On > close(), packet_release calls packet_flush_mclist, which again > decrements dev->promiscuity, so when tcpdump exits, dev promiscuity is > left at -1. > > I can't see any reason to be mucking about with the device promiscuity > on NETDEV_DOWN and NETDEV_UP events in the first place. The attached > patch seems to fix all the cases I can think of. It works properly in > both of the above cases, and has also been verified to do the right > thing with NETDEV_UNREGISTER events. > > Jason > Index: linux-2.4/net/packet/af_packet.c =================================================================== RCS file: /home/cvs/linux-2.4/net/packet/af_packet.c,v retrieving revision 1.11 diff -u -p -r1.11 af_packet.c --- linux-2.4/net/packet/af_packet.c 12 Jun 2002 23:10:34 -0000 1.11 +++ linux-2.4/net/packet/af_packet.c 1 Jul 2003 20:17:51 -0000 @@ -1378,8 +1378,13 @@ static int packet_notifier(struct notifi po = sk->protinfo.af_packet; switch (msg) { - case NETDEV_DOWN: case NETDEV_UNREGISTER: +#ifdef CONFIG_PACKET_MULTICAST + if (po->mclist) + packet_dev_mclist(dev, po->mclist, -1); + // fallthrough +#endif + case NETDEV_DOWN: if (dev->ifindex == po->ifindex) { spin_lock(&po->bind_lock); if (po->running) { @@ -1396,10 +1401,6 @@ static int packet_notifier(struct notifi } spin_unlock(&po->bind_lock); } -#ifdef CONFIG_PACKET_MULTICAST - if (po->mclist) - packet_dev_mclist(dev, po->mclist, -1); -#endif break; case NETDEV_UP: spin_lock(&po->bind_lock); @@ -1409,10 +1410,6 @@ static int packet_notifier(struct notifi po->running = 1; } spin_unlock(&po->bind_lock); -#ifdef CONFIG_PACKET_MULTICAST - if (po->mclist) - packet_dev_mclist(dev, po->mclist, +1); -#endif break; } } From shemminger@osdl.org Tue Jul 8 15:12:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jul 2003 15:13:01 -0700 (PDT) Received: from mail.osdl.org (air-2.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h68MCr2x003279 for ; Tue, 8 Jul 2003 15:12:54 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h68MCjI08162; Tue, 8 Jul 2003 15:12:46 -0700 Date: Tue, 8 Jul 2003 15:12:45 -0700 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH 2.5.74] convert apne to dynamic allocation Message-Id: <20030708151245.179cac2b.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 3839 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Convert apne driver away from static net_device structure. Builds, but not tested with real hardware. diff -Nru a/drivers/net/apne.c b/drivers/net/apne.c --- a/drivers/net/apne.c Mon Jul 7 14:46:31 2003 +++ b/drivers/net/apne.c Mon Jul 7 14:46:31 2003 @@ -534,16 +534,21 @@ } #ifdef MODULE -static struct net_device apne_dev; +static struct net_device *apne_dev; int init_module(void) { int err; + apne_dev = kmalloc(sizeof(*apne_dev)); + if (!apne_dev) + return -ENOMEM; + apne_dev.init = apne_probe; if ((err = register_netdev(&apne_dev))) { if (err == -EIO) printk("No PCMCIA NEx000 ethernet card found.\n"); + kfree(apne_dev); return (err); } return (0); @@ -551,11 +556,13 @@ void cleanup_module(void) { - unregister_netdev(&apne_dev); + unregister_netdev(apne_dev); pcmcia_disable_irq(); - free_irq(IRQ_AMIGA_PORTS, &apne_dev); + free_irq(IRQ_AMIGA_PORTS, apne_dev); + + kfree(apne_dev); pcmcia_reset(); From shemminger@osdl.org Tue Jul 8 15:14:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jul 2003 15:14:39 -0700 (PDT) Received: from mail.osdl.org (air-2.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h68MEY2x003871 for ; Tue, 8 Jul 2003 15:14:34 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h68MESI08466; Tue, 8 Jul 2003 15:14:28 -0700 Date: Tue, 8 Jul 2003 15:14:27 -0700 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] Convert hp100 to useing alloc_etherdev Message-Id: <20030708151427.328aae38.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 3841 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Change hp100 driver to using alloc_etherdev instead of separate allocation of dev->priv. Builds, but not tested since do not have hardware. diff -Nru a/drivers/net/hp100.c b/drivers/net/hp100.c --- a/drivers/net/hp100.c Mon Jul 7 14:49:18 2003 +++ b/drivers/net/hp100.c Mon Jul 7 14:49:18 2003 @@ -713,11 +713,8 @@ } /* Initialise the "private" data structure for this card. */ - if ((dev->priv = kmalloc(sizeof(struct hp100_private), GFP_KERNEL)) == NULL) - return -ENOMEM; - lp = (struct hp100_private *) dev->priv; - memset(lp, 0, sizeof(struct hp100_private)); + spin_lock_init(&lp->lock); lp->id = eid; lp->chip = chip; @@ -777,7 +774,6 @@ SET_MODULE_OWNER(dev); SET_NETDEV_DEV(dev, &pci_dev->dev); - ether_setup(dev); /* If busmaster mode is wanted, a dma-capable memory area is needed for * the rx and tx PDLs @@ -2963,8 +2959,6 @@ pci_free_consistent(p->pci_dev, MAX_RINGSIZE + 0x0f, p->page_vaddr_algn, virt_to_whatever(d, p->page_vaddr_algn)); if (p->mem_ptr_virt) iounmap(p->mem_ptr_virt); - kfree(d->priv); - d->priv = NULL; kfree(d); hp100_devlist[i] = NULL; } @@ -2983,9 +2977,10 @@ cards = 0; while ((hp100_port[++i] != -1) && (i < HP100_DEVICES)) { /* Create device and set basics args */ - hp100_devlist[i] = kmalloc(sizeof(struct net_device), GFP_KERNEL); + hp100_devlist[i] = alloc_etherdev(sizeof(struct hp100_private)); if (!hp100_devlist[i]) goto fail; + memset(hp100_devlist[i], 0x00, sizeof(struct net_device)); #if LINUX_VERSION_CODE >= 0x020362 /* 2.3.99-pre7 */ memcpy(hp100_devlist[i]->name, hp100_name[i], IFNAMSIZ); /* Copy name */ @@ -2998,7 +2993,6 @@ /* Try to create the device */ if (register_netdev(hp100_devlist[i]) != 0) { /* DeAllocate everything */ - /* Note: if dev->priv is mallocated, there is no way to fail */ kfree(hp100_devlist[i]); hp100_devlist[i] = (struct net_device *) NULL; } else From shemminger@osdl.org Tue Jul 8 15:16:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jul 2003 15:16:22 -0700 (PDT) Received: from mail.osdl.org (air-2.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h68MGI2x004229 for ; Tue, 8 Jul 2003 15:16:18 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h68MG6I08876; Tue, 8 Jul 2003 15:16:06 -0700 Date: Tue, 8 Jul 2003 15:16:06 -0700 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] Message-Id: <20030708151606.483604ad.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 3842 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Convert Digi RigtSwitch to use alloc_etherdev. Builds (on 2.5.74) but once again, do not have real hardware to test. diff -Nru a/drivers/net/dgrs.c b/drivers/net/dgrs.c --- a/drivers/net/dgrs.c Mon Jul 7 14:50:36 2003 +++ b/drivers/net/dgrs.c Mon Jul 7 14:50:36 2003 @@ -1252,18 +1252,12 @@ { DGRS_PRIV *priv; struct net_device *dev, *aux; - - /* Allocate and fill new device structure. */ - int dev_size = sizeof(struct net_device) + sizeof(DGRS_PRIV); int i, ret; - dev = (struct net_device *) kmalloc(dev_size, GFP_KERNEL); - + dev = alloc_etherdev(sizeof(DGRS_PRIV)); if (!dev) return -ENOMEM; - memset(dev, 0, dev_size); - dev->priv = ((void *)dev) + sizeof(struct net_device); priv = (DGRS_PRIV *)dev->priv; dev->base_addr = io; @@ -1279,7 +1273,7 @@ dev->init = dgrs_probe1; SET_MODULE_OWNER(dev); - ether_setup(dev); + if (register_netdev(dev) != 0) { kfree(dev); return -EIO; @@ -1302,15 +1296,18 @@ struct net_device *devN; DGRS_PRIV *privN; /* Allocate new dev and priv structures */ - devN = (struct net_device *) kmalloc(dev_size, GFP_KERNEL); - /* Make it an exact copy of dev[0]... */ + devN = alloc_etherdev(sizeof(DGRS_PRIV)); ret = -ENOMEM; if (!devN) goto fail; - memcpy(devN, dev, dev_size); - memset(devN->name, 0, sizeof(devN->name)); - devN->priv = ((void *)devN) + sizeof(struct net_device); + + /* Make it an exact copy of dev[0]... */ + *devN = *dev; + + /* copy the priv structure of dev[0] */ privN = (DGRS_PRIV *)devN->priv; + *privN = *priv; + /* ... and zero out VM areas */ privN->vmem = 0; privN->vplxdma = 0; @@ -1318,9 +1315,11 @@ devN->irq = 0; /* ... and base MAC address off address of 1st port */ devN->dev_addr[5] += i; + /* ... choose a new name */ + strncpy(devN->name, "eth%d", IFNAMSIZ); devN->init = dgrs_initclone; SET_MODULE_OWNER(devN); - ether_setup(devN); + ret = -EIO; if (register_netdev(devN)) { kfree(devN); From davem@redhat.com Tue Jul 8 15:16:47 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jul 2003 15:16:51 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h68MGk2x004440 for ; Tue, 8 Jul 2003 15:16:47 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id PAA21157; Tue, 8 Jul 2003 15:08:36 -0700 Date: Tue, 08 Jul 2003 15:08:35 -0700 (PDT) Message-Id: <20030708.150835.78728697.davem@redhat.com> To: willy@debian.org Cc: greearb@candelatech.com, netdev@oss.sgi.com Subject: Re: [PATCH] netdev_ops From: "David S. Miller" In-Reply-To: <20030708212551.GL1939@parcelfarce.linux.theplanet.co.uk> References: <20030708163042.GL23597@parcelfarce.linux.theplanet.co.uk> <3F0B2D30.4020102@candelatech.com> <20030708212551.GL1939@parcelfarce.linux.theplanet.co.uk> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3843 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: Matthew Wilcox Date: Tue, 8 Jul 2003 22:25:51 +0100 On Tue, Jul 08, 2003 at 01:44:32PM -0700, Ben Greear wrote: > Some of these are missing their netdevice arg? > >+ int (*get_regs_len)(struct ethtool_regs *); > >+ int (*self_test_len)(struct ethtool_test *); > >+ int (*get_strings_len)(struct ethtool_gstrings *); > >+ int (*get_stats_len)(struct ethtool_stats *); Well, they don't actually need it -- these are more attributes of the underlying driver than they are of any individual network device. Not true, at least for the regs len different variants of the same chip can have a different sized register set. From shemminger@osdl.org Tue Jul 8 15:17:51 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jul 2003 15:17:55 -0700 (PDT) Received: from mail.osdl.org (air-2.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h68MHo2x004870 for ; Tue, 8 Jul 2003 15:17:51 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h68MHgI10146; Tue, 8 Jul 2003 15:17:42 -0700 Date: Tue, 8 Jul 2003 15:17:42 -0700 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] convert plip to alloc_netdev Message-Id: <20030708151742.715ca49c.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 3844 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev This converts the parallel network driver to use alloc_netdev instead of doing it's own allocation. Tested (load/unload) on 2.5.74 diff -Nru a/drivers/net/plip.c b/drivers/net/plip.c --- a/drivers/net/plip.c Tue Jul 8 15:07:44 2003 +++ b/drivers/net/plip.c Tue Jul 8 15:07:44 2003 @@ -277,27 +277,10 @@ then calls us here. */ -int __init -plip_init_dev(struct net_device *dev, struct parport *pb) +static int +plip_init_netdev(struct net_device *dev) { - struct net_local *nl; - struct pardevice *pardev; - - SET_MODULE_OWNER(dev); - dev->irq = pb->irq; - dev->base_addr = pb->base; - - if (pb->irq == -1) { - printk(KERN_INFO "plip: %s has no IRQ. Using IRQ-less mode," - "which is fairly inefficient!\n", pb->name); - } - - pardev = parport_register_device(pb, dev->name, plip_preempt, - plip_wakeup, plip_interrupt, - 0, dev); - - if (!pardev) - return -ENODEV; + struct net_local *nl = dev->priv; printk(KERN_INFO "%s", version); if (dev->irq != -1) @@ -307,9 +290,6 @@ printk(KERN_INFO "%s: Parallel port at %#3lx, not using IRQ.\n", dev->name, dev->base_addr); - /* Fill in the generic fields of the device structure. */ - ether_setup(dev); - /* Then, override parts of it */ dev->hard_start_xmit = plip_tx_packet; dev->open = plip_open; @@ -322,22 +302,12 @@ memset(dev->dev_addr, 0xfc, ETH_ALEN); /* Set the private structure */ - dev->priv = kmalloc(sizeof (struct net_local), GFP_KERNEL); - if (dev->priv == NULL) { - printk(KERN_ERR "%s: out of memory\n", dev->name); - parport_unregister_device(pardev); - return -ENOMEM; - } - memset(dev->priv, 0, sizeof(struct net_local)); - nl = (struct net_local *) dev->priv; - nl->orig_hard_header = dev->hard_header; dev->hard_header = plip_hard_header; nl->orig_hard_header_cache = dev->hard_header_cache; dev->hard_header_cache = plip_hard_header_cache; - nl->pardev = pardev; nl->port_owner = 0; @@ -1299,29 +1269,52 @@ * available to use. */ static void plip_attach (struct parport *port) { - static int i; + static int unit; + struct net_device *dev; + struct net_local *nl; + char name[IFNAMSIZ]; if ((parport[0] == -1 && (!timid || !port->devices)) || plip_searchfor(parport, port->number)) { - if (i == PLIP_MAX) { + if (unit == PLIP_MAX) { printk(KERN_ERR "plip: too many devices\n"); return; } - dev_plip[i] = kmalloc(sizeof(struct net_device), - GFP_KERNEL); - if (!dev_plip[i]) { + + sprintf(name, "plip%d", unit); + dev = alloc_netdev(sizeof(struct net_local), name, + ether_setup); + if (!dev) { printk(KERN_ERR "plip: memory squeeze\n"); return; } - memset(dev_plip[i], 0, sizeof(struct net_device)); - sprintf(dev_plip[i]->name, "plip%d", i); - dev_plip[i]->priv = port; - if (plip_init_dev(dev_plip[i],port) || - register_netdev(dev_plip[i])) { - kfree(dev_plip[i]); - dev_plip[i] = NULL; + + dev->init = plip_init_netdev; + + SET_MODULE_OWNER(dev); + dev->irq = port->irq; + dev->base_addr = port->base; + if (port->irq == -1) { + printk(KERN_INFO "plip: %s has no IRQ. Using IRQ-less mode," + "which is fairly inefficient!\n", port->name); + } + + nl = dev->priv; + nl->pardev = parport_register_device(port, name, plip_preempt, + plip_wakeup, plip_interrupt, + 0, dev); + + if (!nl->pardev) { + printk(KERN_ERR "%s: parport_register failed\n", name); + kfree(dev); + return; + } + + if (register_netdev(dev)) { + printk(KERN_ERR "%s: network register failed\n", name); + kfree(dev); } else { - i++; + dev_plip[unit++] = dev; } } } @@ -1341,20 +1334,19 @@ static void __exit plip_cleanup_module (void) { + struct net_device *dev; int i; parport_unregister_driver (&plip_driver); for (i=0; i < PLIP_MAX; i++) { - if (dev_plip[i]) { - struct net_local *nl = - (struct net_local *)dev_plip[i]->priv; - unregister_netdev(dev_plip[i]); + if ((dev = dev_plip[i])) { + struct net_local *nl = dev->priv; + unregister_netdev(dev); if (nl->port_owner) parport_release(nl->pardev); parport_unregister_device(nl->pardev); - kfree(dev_plip[i]->priv); - kfree(dev_plip[i]); + kfree(dev); dev_plip[i] = NULL; } } From garzik@gtf.org Tue Jul 8 16:26:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jul 2003 16:26:55 -0700 (PDT) Received: from havoc.gtf.org (host-64-213-145-173.atlantasolutions.com [64.213.145.173] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h68NQe2x005707 for ; Tue, 8 Jul 2003 16:26:40 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id B2A996655; Tue, 8 Jul 2003 19:26:34 -0400 (EDT) Date: Tue, 8 Jul 2003 19:26:34 -0400 From: Jeff Garzik To: torvalds@osdl.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [BK PATCHES] net driver merges Message-ID: <20030708232634.GA29175@gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-archive-position: 3846 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 (note to others -- more coming, the queue isn't empty yet) Linus, please do a bk pull bk://kernel.bkbits.net/jgarzik/net-drivers-2.5 Others may download ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.5/2.5.74-bk5-netdrvr1.patch.bz2 This will update the following files: drivers/net/8139too.c | 2 drivers/net/e1000/e1000.h | 1 drivers/net/e1000/e1000_ethtool.c | 5 - drivers/net/e1000/e1000_hw.c | 59 ++++++++++-- drivers/net/e1000/e1000_hw.h | 18 +++ drivers/net/e1000/e1000_main.c | 186 ++++++++++++++++++++------------------ drivers/net/via-rhine.c | 36 +++++-- 7 files changed, 198 insertions(+), 109 deletions(-) through these ChangeSets: (03/07/08 1.1431) [e1000] misc cleanup * whitespace cleanup * removal of unused members of netdev priv struct * extendable arrangement of h/w reset logic (03/07/08 1.1430) [e1000] s/int/unsigned int/ for descriptor ring indexes * Perf cleanup: s/int/unsigned int/ for descriptor ring indexes [suggestion by Jeff Garzik]. * Perf cleanup: cache references to ring elements using local pointer (03/07/08 1.1429) [e1000] h/w workaround for mis-fused parts * h/w workaround: several 10's of thousands of 82547 controllers where mis-fused during manufacturing, resulting in PHY Tx amplitude to be too high and out of spec. This workaround detects those parts, and compensates the Tx amplitude by subtracting ~80mV. (03/07/08 1.1428) [e1000] ethtool diag cleanup * Cleanup: ethtool diags: only reset if not if_running. (03/07/08 1.1427) [e1000] alloc_etherdev failure didn't cleanup regions * Bug fix: alloc_etherdev failure didn't cleanup regions in probe. (03/07/08 1.1426) [e1000] missing Tx cleanup opportunities during intr handling * Bug fix: missing Tx cleanup opportunities during interrupt handling. (03/07/08 1.1425) [e1000] fix VLAN support on PPC64 * Bug fix: fix VLAN support on PPC64 [Mark Rakes (mrakes@vivato.net)] (03/07/08 1.1424) [e1000] request_irq() failure resulted in freeing twice * Bug fix: request_irq() failure resulted in freeing resources twice! [Don Fry (brazilnut@us.ibm.com)] (03/07/08 1.1423) [PATCH] via-rhine 1.18-2.5: Fix Rhine-I regression This patch addresses a minor regression reported by Rhine-I users (leading to occasional Tx timeouts). I also merged some cosmetic changes. (03/07/05 1.1422) [netdrvr 8139too] fix debug printk printk args had been accidentally reversed From davem@redhat.com Tue Jul 8 16:26:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jul 2003 16:26:53 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h68NQa2x005708 for ; Tue, 8 Jul 2003 16:26:36 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id QAA21406; Tue, 8 Jul 2003 16:18:18 -0700 Date: Tue, 08 Jul 2003 16:18:18 -0700 (PDT) Message-Id: <20030708.161818.28806942.davem@redhat.com> To: lunz@falooley.org Cc: netdev@oss.sgi.com, jmorris@intercode.com.au Subject: Re: [PATCH RESEND 2.4, 2.5] dev->promiscuity refcounting broken in af_packet.c From: "David S. Miller" In-Reply-To: <20030708221239.GA20633@orr.falooley.org> References: <20030708221239.GA20633@orr.falooley.org> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3845 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: Jason Lunz Date: Tue, 8 Jul 2003 18:12:39 -0400 James, I know you applied it to your bk tree. Will that be enough to get it into 2.4 and 2.5, or should I submit it elsewhere? We're just waiting for me to catchup to my backlog from my vacation and push James's tree(s) to Marcelo and Linus. Please be patient! :-) From kuznet@ms2.inr.ac.ru Tue Jul 8 16:52:05 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jul 2003 16:52:16 -0700 (PDT) Received: from dub.inr.ac.ru (dub.inr.ac.ru [193.233.7.105]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h68Nq32x006471 for ; Tue, 8 Jul 2003 16:52:04 -0700 Received: (from kuznet@localhost) by dub.inr.ac.ru (8.6.13/ANK) id DAA13835; Wed, 9 Jul 2003 03:50:59 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200307082350.DAA13835@dub.inr.ac.ru> Subject: Re: Question about netlink To: krkumar@us.ibm.com (Krishna Kumar) Date: Wed, 9 Jul 2003 03:50:54 +0400 (MSD) Cc: yoshfuji@linux-ipv6.org, davem@redhat.com, netdev@oss.sgi.com In-Reply-To: <3F0B294A.9060302@us.ibm.com> from "Krishna Kumar" at Jul 08, 2003 01:27:54 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3847 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Hello! > These routines 'get' the value of args[0] and then 'set' it to the resultant value. How is > this value set in the first place to the user provided value ? It is not. Zero values means that dump starts from the very beginning. It is supposed to be done at the first entry to the ->dump(), but selective dumps are not implemented in the most of ->dump() methods. > missing something or is 'args' not intended for user specified arguments ? If so, how > should we access the arguments passed by the user ? The pointer to nlmsg header is kept in cb->nlh. So, you can refer to it to get user supplied values of selector to rewind the dump to required point at the first entry or to select some specific entries while scanning a table. F.e. look into sch_api.c:tc_dump_tclass(), it scopes dump to a netdevice (tcp_ifindex), and filters answers to a specific qdisc (tcp_parent). It is also partial. More finegrain selection is not required, but desired, feel free to implement. F.e. implementation of "ip route ls root 3ffe::/24", which translates to selection of a root node for fib6_walk() to a more specific place and filtering out some nodes while walking, would be cool. Alexey From davem@redhat.com Tue Jul 8 19:38:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Jul 2003 19:39:02 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h692cr2x008445 for ; Tue, 8 Jul 2003 19:38:54 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id TAA21827; Tue, 8 Jul 2003 19:30:08 -0700 Date: Tue, 08 Jul 2003 19:30:07 -0700 (PDT) Message-Id: <20030708.193007.26293028.davem@redhat.com> To: jmorris@intercode.com.au Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: [PATCH] Don't call request_module() under spinlock in xfrm_get_type() From: "David S. Miller" In-Reply-To: References: X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3848 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: James Morris Date: Sun, 6 Jul 2003 22:42:40 +1000 (EST) This patch fixes a problem where request_module() was being called under the lock taken in xfrm_policy_get_afinfo(). Looks good, applied. From mtk-lists@gmx.net Wed Jul 9 03:12:06 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 03:12:43 -0700 (PDT) Received: from mx0.gmx.net (mx0.gmx.de [213.165.64.100]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h69ABP2x016225 for ; Wed, 9 Jul 2003 03:12:06 -0700 Received: (qmail 14055 invoked by uid 0); 9 Jul 2003 10:11:19 -0000 Date: Wed, 9 Jul 2003 12:11:19 +0200 (MEST) From: mtk-lists@gmx.net To: kuznet@ms2.inr.ac.ru, Andi Kleen Cc: netdev@oss.sgi.com MIME-Version: 1.0 Subject: Re: shutdown() and SHUT_RD on TCP sockets - broken? X-Priority: 3 (Normal) X-Authenticated-Sender: #0018454895@gmx.net X-Authenticated-IP: [212.18.21.202] Message-ID: <27451.1057745479@www2.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-archive-position: 3849 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mtk-lists@gmx.net Precedence: bulk X-list: netdev Hello Alexey and Andi, [Alexey] > > blocks. I see that this also occurs on FreeBSD 4.8, Tru64 5.1B, > > HP/UX 11 and Solaris 8. Have I misunderstood Stevens, > > Most likely, it is that rare case when Stevens forgot to check the > statement. yes, it cerainly doesn't correspond to any current implementation that I could find anyway. I should of course have added that (as you are probably well aware) SUSv3 is vague but does say: SHUT_RD Disables further receive operations. which suggest that we shouldn't be able to read any more. It seems to me that the only ways of satisfying that requirement are to either discard data (a la Stevens) or send an RST to the writing peer (more on that in a moment) so that it stops sending. > From viewpoint of TCP the behaviour described in Stevens' book > is highly unnatural. SHUT_RD on TCP does not make any sense. A while back I had some communication with Andi Kleen on this point, and he suggested that the TCP could send an RST in this case, much as occurs if the reader close()s the socket. Is this not a starter? (Maybe not, for the reasons Andi outlined in his mail to this list -- quoted below.) > > described here. But, why do things happen in this way on Linux? > > Actually, you could check one more thing. What does happen after freebsd > 4.8 returns 0 on read()? Does it open window eventually? I'm not quite sure what you mean here. Can you elaborate on the what type of experiment I should perform and what you expect I might see? [Andi] > > 1. If we perform a read() on the socket and there is no data, then 0 > > (EOF) is (immediately) returned. (This is what I expected.) > > > > 2. However, the peer can still write() to the socket, and afterwards we > > can read() that data from the socket, even though the reading half of the > > socket should be shut down. Instead of this behaviour, I expected the > > read() to continue to return 0 as in point 1. This is what we see for > > example in FreeBSD 4.8, Tru64 5.1B, and HP/UX 11. > > The problem is that it adds a new check to the input path. It's not clear > how the check can be done outside the fast path (one way would be to shrink > the window forcedly and drop the receiver into slow path, but that would be > a severe protocol violation if the shrunk window leaks out with some ACK). > I don't think it's a good idea to add a check for such an obscure situation > to the fast path. Andi, I noted already your idea about delivering a RST in this case. I assume the above is the practical reason that makes implementing this difficult? > > 3. (A side point.) Looking at Stevens UNPv1, p161, there is a statement > > that after a SHUT_RD, "any data for a TCP socket is acknowledged and then > > silently discarded". This implies to me that the sender could keep on > > writing to the socket and never block. However, on Linux, if the peer > > keeps sending to a socket, then eventually (the channel is filled and) it > > blocks. I see that this also occurs on FreeBSD 4.8, Tru64 5.1B, HP/UX 11 > > That's because the data is not discarded so the window fills. Yes, I should perhaps have added that in the circumstances, blocking at this point is not surprising (to me). > > and Solaris 8. Have I misunderstood Stevens, or has something changed > > since the implementation he described (or was his statement wrong)? (In > > Probably Stevens was confused. There seems to be a consensus emerging ;-). Cheers, Michael -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Jetzt ein- oder umsteigen und USB-Speicheruhr als Prämie sichern! From ak@suse.de Wed Jul 9 03:38:58 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 03:39:35 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h69AcH2x016756 for ; Wed, 9 Jul 2003 03:38:58 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 782E814496; Wed, 9 Jul 2003 12:38:11 +0200 (MEST) Date: Wed, 9 Jul 2003 12:38:10 +0200 From: Andi Kleen To: mtk-lists@gmx.net Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: shutdown() and SHUT_RD on TCP sockets - broken? Message-Id: <20030709123810.2b94d753.ak@suse.de> In-Reply-To: <27451.1057745479@www2.gmx.net> References: <27451.1057745479@www2.gmx.net> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 3850 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev On Wed, 9 Jul 2003 12:11:19 +0200 (MEST) mtk-lists@gmx.net wrote: . > > > From viewpoint of TCP the behaviour described in Stevens' book > > is highly unnatural. SHUT_RD on TCP does not make any sense. > > A while back I had some communication with Andi Kleen on this point, > and he suggested that the TCP could send an RST in this case, much Linux sends an RST when data arrives that the user cannot read anymore because the receiving socket is already closed. It would make sense to extend this behaviour to SHUT_RD. But there is no natural place to implement it outside the fast path, and it's so obscure that it is not worth slowing common cases down. -Andi From julia_ward@mail.typemail.com Wed Jul 9 04:55:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 04:56:22 -0700 (PDT) Received: from mail.typemail.com ([66.70.38.160]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h69Bsa2x018498 for ; Wed, 9 Jul 2003 04:55:34 -0700 Date: Wed, 9 Jul 2003 04:35:00 -0700 Message-Id: <200307090435.AA30605550@mail.typemail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: "JULIANA HOWARD" Reply-To: To: Subject: hello my dear friend X-Mailer: X-archive-position: 3851 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: julia_ward@mail.typemail.com Precedence: bulk X-list: netdev Dear Friend, This contact has become imperative based on the recent tribulation in Zimbabwe which has led to my present predicament. I am therefore using this medium to appeal to your good conscience to come to my rescue and the rescue of my family. I am Mrs. Julia Howard a widow to a white commercial farmer from Zimbabwe and I got your contact from one of our business directories. I was born and bred in Zimbabwe to the best of my knowledge,my parents and grandparents lived all their lives in Zimbabwe africa.I have also lived all my life in Zimbabwe and so has all members of my family,therefore it is right to call me a Zimbabwean though white,I am by law a Zimbabwean.I have little or no knowledge of my roots save for the fact that my forefathers as I was told,hailed from Australia,which I have never visited all my life.It is pertinent that I tell you all this so that you can come to a full comprehension of the ill treatment that we have received from the Zimbabwean government of late. The government of Robert Mugabe,president of Zimbabwe,in the year 2000 promulgated an abbysmal land law,the fast tract land resettlement program,aimed at taking land from the rich white commercial farmers in Zimbabwe and given it to the so called poor natural inhabitants of Zimbabwe,the black Zimbabweans,who as the president claimed are the rightful owners of these land.To this effects,our lands,including the lands where our personal houses where built on have been taking from us,rendering us homeless.In pursuance to this law,the so called natural inhabitants,the black Zimbabweans,have committed serious human rights violations in the process of forcefully taking our ands from us.Many of our white brothers were maimed, killed and rendered homeless.Those of us that are alive now live in fear. As the victim of this inhuman treatment,I have been rendered homeless,that I now live in a village in the far north of Manica land,Zimbabwe,where I have to travel 100 kilometers to send this mail to you.We were hoping that the international community will come to our rescue,but this hope has been dashed since all we hear is that the international community is still appealing to the Zimbabwean government to reconsider the law,which clearly has fallen on deaf ears,since most of us have been relegated to abject poverty and homelessness while living in fear.All our properties have been confiscated including our bank accounts which have been frozen.The rest of us who managed to flee Zimbabwe at the inception of this law are now the lucky ones. My dear friend,I have lost all I worked for all my life.As a tobacco farmer I have lost both my farm land and all my financial resources in Zimbabwe.I only have one hope left,which is to leave Zimbabwe alive. I am using this medium to appeal to you to come to my rescue and that of my family by helping us get out of Zimbabwe to a safe abode,where we can start life afresh again.We have some money deposited with a courier firm in Amsterdam from an affiliate office in south africa enable us float an export and import company to facilitate the transportation of my farm produce which was costing us alot.I cannot reach the money because of my present isolation,moreover I do not have a bank account anymore in Zimbabwe to facilitate bank to bank transfer.I need your help to withdraw this money as all the documents neccessary for this withdrawal is still in my possession so that I can leave Zimbabwe as soon as possible and settle down with my family in your country.Please endeavour to try and help me as you will be greatly rewarded for your effort. I thank you for your anticipated cooperation as I await your response to this mail. Regards, Julia Howard From andrius@andrius.org Wed Jul 9 08:20:01 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 08:20:09 -0700 (PDT) Received: from hl.kalnieciai.lt (postfix@hl.kauneta.net [212.47.103.4]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h69FJw2x024539 for ; Wed, 9 Jul 2003 08:20:00 -0700 Received: by hl.kalnieciai.lt (Postfix, from userid 1430) id DC98E4F1BA; Wed, 9 Jul 2003 18:19:51 +0300 (GMT-3) Received: from localhost (localhost [127.0.0.1]) by hl.kalnieciai.lt (Postfix) with ESMTP id D7D684F156 for ; Wed, 9 Jul 2003 18:19:51 +0300 (GMT-3) Date: Wed, 9 Jul 2003 18:19:51 +0300 (GMT-3) From: Andrius Kasparavicius X-X-Sender: andrius@hl.kauneta.net To: netdev@oss.sgi.com Subject: network interface cards native vlans support in linux kernel? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3852 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andrius@andrius.org Precedence: bulk X-list: netdev hello, as far as i know, currently there is no native vlan support in network device drivers. I mean, always need patching MTU.. add 4 bytes.. :-( is there any problems to include full vlans support? Andrius From garzik@gtf.org Wed Jul 9 08:25:59 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 08:26:03 -0700 (PDT) Received: from havoc.gtf.org (host-64-213-145-173.atlantasolutions.com [64.213.145.173] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h69FPx2x024877 for ; Wed, 9 Jul 2003 08:25:59 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id 98AF6663B; Wed, 9 Jul 2003 11:25:53 -0400 (EDT) Date: Wed, 9 Jul 2003 11:25:53 -0400 From: Jeff Garzik To: netdev@oss.sgi.com Subject: reasons for dev_alloc_skb +16? Message-ID: <20030709152553.GB15293@gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-archive-position: 3853 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 I knew this at one time, but have forgotten it :) What is the reason for adding 16 to the dev_alloc_skb length? (and skb_reserve of the same length) Jeff From garzik@gtf.org Wed Jul 9 08:28:20 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 08:28:24 -0700 (PDT) Received: from havoc.gtf.org (host-64-213-145-173.atlantasolutions.com [64.213.145.173] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h69FSK2x025199 for ; Wed, 9 Jul 2003 08:28:20 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id 0DBC6663B; Wed, 9 Jul 2003 11:28:15 -0400 (EDT) Date: Wed, 9 Jul 2003 11:28:15 -0400 From: Jeff Garzik To: Andrius Kasparavicius Cc: netdev@oss.sgi.com Subject: Re: network interface cards native vlans support in linux kernel? Message-ID: <20030709152814.GC15293@gtf.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-archive-position: 3854 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev On Wed, Jul 09, 2003 at 06:19:51PM +0300, Andrius Kasparavicius wrote: > hello, as far as i know, currently there is no native vlan support in > network device drivers. I mean, always need patching MTU.. add 4 bytes.. > :-( > > is there any problems to include full vlans support? Native VLAN support has been in the kernel for a while. A few drivers still need patching, and unfortunately the VLAN driver patches floating around all need cleaning up. Jeff From shmulik.hen@intel.com Wed Jul 9 08:34:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 08:34:06 -0700 (PDT) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h69FY02x025568 for ; Wed, 9 Jul 2003 08:34:01 -0700 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h69FSw316301 for ; Wed, 9 Jul 2003 15:28:58 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h69Fart23592 for ; Wed, 9 Jul 2003 15:36:53 GMT Received: from hasmsx331.ger.corp.intel.com ([143.185.63.144]) by hasmsxvs01.iil.intel.com (NAVGW 2.5.2.11) with SMTP id M2003070918402809783 ; Wed, 09 Jul 2003 18:40:28 +0300 Received: from hasmsx403.ger.corp.intel.com ([143.185.63.109]) by hasmsx331.ger.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 9 Jul 2003 18:33:46 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: network interface cards native vlans support in linux kernel? Date: Wed, 9 Jul 2003 18:33:46 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: network interface cards native vlans support in linux kernel? Thread-Index: AcNGLcwOizzRTsJXROSm7ZB2OZS1HwAAPh0Q From: "Hen, Shmulik" To: "Andrius Kasparavicius" , X-OriginalArrivalTime: 09 Jul 2003 15:33:46.0590 (UTC) FILETIME=[7CB12FE0:01C3462F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h69FY02x025568 X-archive-position: 3855 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Do you mean "native" as in hardware acceleration offloading? If that's the case than the 8021q vlan module handshakes with the device driver to check for support and that's it. No need to do any settings on the device. In case there is no offloading support, the vlan module will take care of all stripping/inserting of the vlan tag into place. On the other hand, if the device cannot handle 1504 byte packets, it defines itself as "vlan challenged" and you can't use vlan on it at all. -- | Shmulik Hen | | Israel Design Center (Jerusalem) | | LAN Access Division | | Intel Communications Group, Intel corp. | > -----Original Message----- > From: Andrius Kasparavicius [mailto:andrius@andrius.org] > Sent: Wednesday, July 09, 2003 6:20 PM > To: netdev@oss.sgi.com > Subject: network interface cards native vlans support in linux kernel? > > > > hello, as far as i know, currently there is no native vlan support in > network device drivers. I mean, always need patching MTU.. > add 4 bytes.. > :-( > > is there any problems to include full vlans support? > > > Andrius > > From shmulik.hen@intel.com Wed Jul 9 08:36:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 08:36:54 -0700 (PDT) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h69FZe2x025888 for ; Wed, 9 Jul 2003 08:36:21 -0700 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h69FUd316759 for ; Wed, 9 Jul 2003 15:30:39 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h69FcYt23966 for ; Wed, 9 Jul 2003 15:38:34 GMT Received: from hasmsx331.ger.corp.intel.com ([143.185.63.144]) by hasmsxvs01.iil.intel.com (NAVGW 2.5.2.11) with SMTP id M2003070918421625837 ; Wed, 09 Jul 2003 18:42:16 +0300 Received: from hasmsx403.ger.corp.intel.com ([143.185.63.109]) by hasmsx331.ger.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 9 Jul 2003 18:35:33 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: reasons for dev_alloc_skb +16? Date: Wed, 9 Jul 2003 18:35:33 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: reasons for dev_alloc_skb +16? Thread-Index: AcNGLm+Wg3SZN7pXSiWwFG8PyzBrSwAASVPg From: "Hen, Shmulik" To: "Jeff Garzik" , X-OriginalArrivalTime: 09 Jul 2003 15:35:33.0996 (UTC) FILETIME=[BCB60AC0:01C3462F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h69FZe2x025888 X-archive-position: 3856 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Could be for alignment issues. Or preparation for things like 8021q tagging. Shmulik. > -----Original Message----- > From: Jeff Garzik [mailto:jgarzik@pobox.com] > Sent: Wednesday, July 09, 2003 6:26 PM > To: netdev@oss.sgi.com > Subject: reasons for dev_alloc_skb +16? > > > I knew this at one time, but have forgotten it :) > > What is the reason for adding 16 to the dev_alloc_skb length? > (and skb_reserve of the same length) > > Jeff > > > From ak@suse.de Wed Jul 9 08:54:43 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 08:55:17 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h69Fs22x026297 for ; Wed, 9 Jul 2003 08:54:43 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 2487414AA1; Wed, 9 Jul 2003 17:53:57 +0200 (MEST) Date: Wed, 9 Jul 2003 17:53:55 +0200 From: Andi Kleen To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: Re: reasons for dev_alloc_skb +16? Message-Id: <20030709175355.422545b5.ak@suse.de> In-Reply-To: <20030709152553.GB15293@gtf.org> References: <20030709152553.GB15293@gtf.org> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 3857 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev On Wed, 9 Jul 2003 11:25:53 -0400 Jeff Garzik wrote: > I knew this at one time, but have forgotten it :) > > What is the reason for adding 16 to the dev_alloc_skb length? > (and skb_reserve of the same length) For the skb_reserve alignment to align the IP header. But it's not clear it is still a good idea because it leads to cache line misalignment of the beginning of the packet, forcing the card to do a costly Read-Modify-Write cycle. -Andi From garzik@gtf.org Wed Jul 9 09:07:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 09:07:12 -0700 (PDT) Received: from havoc.gtf.org (host-64-213-145-173.atlantasolutions.com [64.213.145.173] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h69G732x026756 for ; Wed, 9 Jul 2003 09:07:03 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id A98536641; Wed, 9 Jul 2003 12:06:57 -0400 (EDT) Date: Wed, 9 Jul 2003 12:06:57 -0400 From: Jeff Garzik To: Andi Kleen Cc: netdev@oss.sgi.com Subject: Re: reasons for dev_alloc_skb +16? Message-ID: <20030709160657.GD15293@gtf.org> References: <20030709152553.GB15293@gtf.org> <20030709175355.422545b5.ak@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030709175355.422545b5.ak@suse.de> User-Agent: Mutt/1.3.28i X-archive-position: 3858 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev On Wed, Jul 09, 2003 at 05:53:55PM +0200, Andi Kleen wrote: > On Wed, 9 Jul 2003 11:25:53 -0400 > Jeff Garzik wrote: > > > I knew this at one time, but have forgotten it :) > > > > What is the reason for adding 16 to the dev_alloc_skb length? > > (and skb_reserve of the same length) > > For the skb_reserve alignment to align the IP header. > > But it's not clear it is still a good idea because it leads to cache line > misalignment of the beginning of the packet, forcing the card to do a > costly Read-Modify-Write cycle. Exactly. Ben H is running into this, and pondering direct use of alloc_skb for precisely this reason. Jeff From ak@suse.de Wed Jul 9 09:13:52 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 09:13:56 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h69GDV2x027138 for ; Wed, 9 Jul 2003 09:13:52 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 120D214738; Wed, 9 Jul 2003 18:13:26 +0200 (MEST) Date: Wed, 9 Jul 2003 18:13:24 +0200 From: Andi Kleen To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: Re: reasons for dev_alloc_skb +16? Message-Id: <20030709181324.16ed0c1d.ak@suse.de> In-Reply-To: <20030709160657.GD15293@gtf.org> References: <20030709152553.GB15293@gtf.org> <20030709175355.422545b5.ak@suse.de> <20030709160657.GD15293@gtf.org> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 3859 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev On Wed, 9 Jul 2003 12:06:57 -0400 Jeff Garzik wrote: > On Wed, Jul 09, 2003 at 05:53:55PM +0200, Andi Kleen wrote: > > On Wed, 9 Jul 2003 11:25:53 -0400 > > Jeff Garzik wrote: > > > > > I knew this at one time, but have forgotten it :) > > > > > > What is the reason for adding 16 to the dev_alloc_skb length? > > > (and skb_reserve of the same length) > > > > For the skb_reserve alignment to align the IP header. > > > > But it's not clear it is still a good idea because it leads to cache line > > misalignment of the beginning of the packet, forcing the card to do a > > costly Read-Modify-Write cycle. > > Exactly. Ben H is running into this, and pondering direct use of > alloc_skb for precisely this reason. Problem with changing it is that the payload ends up misaligned. And user space usually aligns the buffer passed to recvmsg. This means csum_copy_to_user has to csum-copy unaligned->aligned, which will be likely very slow. Related problem is that the TCP/IP headers are unaligned, but if your CPU has fast enough misalignment handling it shouldn't be too bad. -Andi From willy@www.linux.org.uk Wed Jul 9 09:15:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 09:15:36 -0700 (PDT) Received: from www.linux.org.uk (IDENT:7WD5g43L7JdHdPGfGnDhECHEiHPsevTw@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h69GFM2x027458 for ; Wed, 9 Jul 2003 09:15:23 -0700 Received: from willy by www.linux.org.uk with local (Exim 4.14) id 19aHbE-0005FB-6S; Wed, 09 Jul 2003 17:15:20 +0100 Date: Wed, 9 Jul 2003 17:15:20 +0100 From: Matthew Wilcox To: netdev@oss.sgi.com Cc: willy@debian.org, greearb@candelatech.com, "David S. Miller" , Arnaldo Carvalho de Melo , Jeff Garzik Subject: Re: [PATCH] netdev_ops Message-ID: <20030709161520.GW1939@parcelfarce.linux.theplanet.co.uk> References: <20030708163042.GL23597@parcelfarce.linux.theplanet.co.uk> <3F0B2D30.4020102@candelatech.com> <20030708212551.GL1939@parcelfarce.linux.theplanet.co.uk> <20030708.150835.78728697.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030708.150835.78728697.davem@redhat.com> User-Agent: Mutt/1.4.1i X-archive-position: 3860 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@debian.org Precedence: bulk X-list: netdev Changes since yesterday's patch: - Make all methods take the struct net_device as suggested by Ben Greear. - Rename self_test_len() and get_stats_len() to *_count() to reflect that they return a count of elements, not a byte length. - Related bugfixes. - Remove the get_strings_len() method; we now infer the length from either self_test_count() or get_stats_count(). - memset() the drvinfo struct so it doesn't leak information from the kernel stack (existing bug in tg3). - Clamp regs.len in ethtool.c rather than in the driver. - Pass the stringset value to get_strings() rather than a pointer to the whole ethtool_gstrings struct. I have a question about the error return values in ethtool_get_strings(). Are -EOPNOTSUPP and -EINVAL the right ones to use in the case statement? Or should I perhaps be using -ENOSYS instead of EINVAL? I've noticed drepper tends to prefer this for unimplemented subops. Since this is an ioctl(), perhaps I should be using -ENOTTY instead ;-) Anyway, further comments welcomed. Index: include/linux/ethtool.h =================================================================== RCS file: /var/cvs/linux-2.5/include/linux/ethtool.h,v retrieving revision 1.5 diff -u -p -r1.5 ethtool.h --- include/linux/ethtool.h 14 Jun 2003 22:16:01 -0000 1.5 +++ include/linux/ethtool.h 8 Jul 2003 15:25:49 -0000 @@ -12,6 +12,7 @@ #ifndef _LINUX_ETHTOOL_H #define _LINUX_ETHTOOL_H +#include /* This should work for both 32 and 64 bit userland. */ struct ethtool_cmd { @@ -97,7 +98,7 @@ struct ethtool_coalesce { u32 rx_max_coalesced_frames; /* Same as above two parameters, except that these values - * apply while an IRQ is being services by the host. Not + * apply while an IRQ is being serviced by the host. Not * all cards support this feature and the values are ignored * in that case. */ @@ -119,7 +120,7 @@ struct ethtool_coalesce { u32 tx_max_coalesced_frames; /* Same as above two parameters, except that these values - * apply while an IRQ is being services by the host. Not + * apply while an IRQ is being serviced by the host. Not * all cards support this feature and the values are ignored * in that case. */ Index: include/linux/netdevice.h =================================================================== RCS file: /var/cvs/linux-2.5/include/linux/netdevice.h,v retrieving revision 1.14 diff -u -p -r1.14 netdevice.h --- include/linux/netdevice.h 2 Jul 2003 22:08:52 -0000 1.14 +++ include/linux/netdevice.h 9 Jul 2003 15:24:33 -0000 @@ -42,6 +42,7 @@ struct divert_blk; struct vlan_group; +struct netdev_ops; #define HAVE_ALLOC_NETDEV /* feature macro: alloc_xxxdev functions are available. */ @@ -299,6 +300,8 @@ struct net_device * See for details. Jean II */ struct iw_handler_def * wireless_handlers; + struct netdev_ops *netdev_ops; + /* * This marks the end of the "visible" part of the structure. All * fields hereafter are internal to the system, and may change at @@ -484,6 +487,100 @@ struct packet_type struct list_head list; }; +/* Some generic methods drivers may use in their netops */ +u32 netdev_op_get_link(struct net_device *dev); +u32 netdev_op_get_tx_csum(struct net_device *dev); +u32 netdev_op_get_sg(struct net_device *dev); +int netdev_op_set_sg(struct net_device *dev, u32 data); + +struct ethtool_cmd; +struct ethtool_drvinfo; +struct ethtool_regs; +struct ethtool_wolinfo; +struct ethtool_eeprom; +struct ethtool_coalesce; +struct ethtool_ringparam; +struct ethtool_pauseparam; +struct ethtool_test; +struct ethtool_stats; + +/** + * &netdev_ops - Alter and report network device settings + * get_settings: Get device-specific settings + * set_settings: Set device-specific settings + * get_drvinfo: Report driver information + * get_regs: Get device registers + * get_wol: Report whether Wake-on-Lan is enabled + * set_wol: Turn Wake-on-Lan on or off + * get_msglevel: Report driver message level + * set_msglevel: Set driver message level + * nway_reset: Restart autonegotiation + * get_link: Get link status + * get_eeprom: Read data from the device EEPROM + * set_eeprom: Writedata to the device EEPROM + * get_coalesce: Get interrupt coalescing parameters + * set_coalesce: Set interrupt coalescing parameters + * get_ringparam: Report ring sizes + * set_ringparam: Set ring sizes + * get_pauseparam: Report pause parameters + * set_pauseparam: Set pause paramters + * get_rx_csum: Report whether receive checksums are turned on or off + * set_rx_csum: Turn receive checksum on or off + * get_tx_csum: Report whether transmit checksums are turned on or off + * set_tx_csum: Turn transmit checksums on or off + * get_sg: Report whether scatter-gather is enabled + * set_sg: Turn scatter-gather on or off + * self_test: Run specified self-tests + * get_strings: Return a set of strings that describe the requested objects + * phys_id: Identify the device + * get_stats: Return statistics about the device + * + * Description: + * + * Each operation is passed a &struct net_device as its first parameter. + * + * get_settings: + * @get_settings is passed an ðtool_cmd to fill in. It returns + * an negative errno or zero. + * + * set_settings: + * @set_settings is passed an ðtool_cmd and should attempt to set + * all the settings this device supports. It may return an error value + * if something goes wrong (otherwise 0). + */ +struct netdev_ops { + int (*get_settings)(struct net_device *, struct ethtool_cmd *); + int (*set_settings)(struct net_device *, struct ethtool_cmd *); + void (*get_drvinfo)(struct net_device *, struct ethtool_drvinfo *); + int (*get_regs_len)(struct net_device *); + void (*get_regs)(struct net_device *, struct ethtool_regs *, void *); + void (*get_wol)(struct net_device *, struct ethtool_wolinfo *); + int (*set_wol)(struct net_device *, struct ethtool_wolinfo *); + u32 (*get_msglevel)(struct net_device *); + void (*set_msglevel)(struct net_device *, u32); + int (*nway_reset)(struct net_device *); + u32 (*get_link)(struct net_device *); + int (*get_eeprom)(struct net_device *, struct ethtool_eeprom *); + int (*set_eeprom)(struct net_device *, struct ethtool_eeprom *); + int (*get_coalesce)(struct net_device *, struct ethtool_coalesce *); + int (*set_coalesce)(struct net_device *, struct ethtool_coalesce *); + void (*get_ringparam)(struct net_device *, struct ethtool_ringparam *); + int (*set_ringparam)(struct net_device *, struct ethtool_ringparam *); + void (*get_pauseparam)(struct net_device *, struct ethtool_pauseparam*); + int (*set_pauseparam)(struct net_device *, struct ethtool_pauseparam*); + u32 (*get_rx_csum)(struct net_device *); + int (*set_rx_csum)(struct net_device *, u32); + u32 (*get_tx_csum)(struct net_device *); + int (*set_tx_csum)(struct net_device *, u32); + u32 (*get_sg)(struct net_device *); + int (*set_sg)(struct net_device *, u32); + int (*self_test_count)(struct net_device *); + void (*self_test)(struct net_device *, struct ethtool_test *, u64 *); + void (*get_strings)(struct net_device *, u32 stringset, u8 *); + void (*phys_id)(struct net_device *, u32); + int (*get_stats_count)(struct net_device *); + void (*get_stats)(struct net_device *, struct ethtool_stats *, u64 *); +}; #include #include @@ -633,6 +730,7 @@ extern int netif_rx(struct sk_buff *skb #define HAVE_NETIF_RECEIVE_SKB 1 extern int netif_receive_skb(struct sk_buff *skb); extern int dev_ioctl(unsigned int cmd, void *); +extern int dev_ethtool(struct ifreq *); extern unsigned dev_get_flags(const struct net_device *); extern int dev_change_flags(struct net_device *, unsigned); extern int dev_set_mtu(struct net_device *, int); Index: net/socket.c =================================================================== RCS file: /var/cvs/linux-2.5/net/socket.c,v retrieving revision 1.21 diff -u -p -r1.21 socket.c --- net/socket.c 17 Jun 2003 11:54:29 -0000 1.21 +++ net/socket.c 17 Jun 2003 11:57:20 -0000 @@ -74,7 +74,6 @@ #include #include #include -#include #include #include #include @@ -1916,10 +1915,7 @@ int sock_unregister(int family) extern void sk_init(void); - -#ifdef CONFIG_WAN_ROUTER extern void wanrouter_init(void); -#endif void __init sock_init(void) { Index: net/core/Makefile =================================================================== RCS file: /var/cvs/linux-2.5/net/core/Makefile,v retrieving revision 1.9 diff -u -p -r1.9 Makefile --- net/core/Makefile 27 May 2003 17:29:33 -0000 1.9 +++ net/core/Makefile 4 Jun 2003 18:39:01 -0000 @@ -10,8 +10,8 @@ obj-y += sysctl_net_core.o endif endif -obj-$(CONFIG_NET) += flow.o dev.o net-sysfs.o dev_mcast.o dst.o neighbour.o \ - rtnetlink.o utils.o link_watch.o filter.o +obj-$(CONFIG_NET) += flow.o dev.o ethtool.o net-sysfs.o dev_mcast.o dst.o \ + neighbour.o rtnetlink.o utils.o link_watch.o filter.o obj-$(CONFIG_NETFILTER) += netfilter.o obj-$(CONFIG_NET_DIVERT) += dv.o Index: net/core/dev.c =================================================================== RCS file: /var/cvs/linux-2.5/net/core/dev.c,v retrieving revision 1.22 diff -u -p -r1.22 dev.c --- net/core/dev.c 2 Jul 2003 22:08:58 -0000 1.22 +++ net/core/dev.c 8 Jul 2003 15:36:35 -0000 @@ -2224,6 +2224,36 @@ int dev_set_mtu(struct net_device *dev, return err; } +/* These are all netdev_op methods in case a driver needs to do something + * different. If we find that all drivers want to do the same thing here, + * we can turn them into dev_() function calls. + */ + +u32 netdev_op_get_link(struct net_device *dev) +{ + return netif_carrier_ok(dev) ? 1 : 0; +} + +u32 netdev_op_get_tx_csum(struct net_device *dev) +{ + return (dev->features & NETIF_F_IP_CSUM) != 0; +} + +u32 netdev_op_get_sg(struct net_device *dev) +{ + return (dev->features & NETIF_F_SG) != 0; +} + +int netdev_op_set_sg(struct net_device *dev, u32 data) +{ + if (data) + dev->features |= NETIF_F_SG; + else + dev->features &= ~NETIF_F_SG; + + return 0; +} + /* * Perform the SIOCxIFxxx calls. @@ -2364,7 +2394,6 @@ static int dev_ifsioc(struct ifreq *ifr, cmd == SIOCBONDSLAVEINFOQUERY || cmd == SIOCBONDINFOQUERY || cmd == SIOCBONDCHANGEACTIVE || - cmd == SIOCETHTOOL || cmd == SIOCGMIIPHY || cmd == SIOCGMIIREG || cmd == SIOCSMIIREG || @@ -2461,13 +2490,26 @@ int dev_ioctl(unsigned int cmd, void *ar } return ret; + case SIOCETHTOOL: + dev_load(ifr.ifr_name); + rtnl_lock(); + ret = dev_ethtool(&ifr); + rtnl_unlock(); + if (!ret) { + if (colon) + *colon = ':'; + if (copy_to_user(arg, &ifr, + sizeof(struct ifreq))) + ret = -EFAULT; + } + return ret; + /* * These ioctl calls: * - require superuser power. * - require strict serialization. * - return a value */ - case SIOCETHTOOL: case SIOCGMIIPHY: case SIOCGMIIREG: if (!capable(CAP_NET_ADMIN)) Index: net/core/ethtool.c =================================================================== RCS file: net/core/ethtool.c diff -N net/core/ethtool.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ net/core/ethtool.c 9 Jul 2003 16:04:26 -0000 @@ -0,0 +1,585 @@ +/* + * net/core/ethtool.c - Ethtool ioctl handler + * Split from net/core/dev.c by Matthew Wilcox + * The only entry point in this file is dev_ethtool() and its only caller + * is from net/core/dev.c + * + * It's GPL, stupid. + */ + +#include +#include +#include + +static int ethtool_get_settings(struct net_device *dev, void *useraddr) +{ + struct ethtool_cmd cmd = { ETHTOOL_GSET }; + int err; + + if (!dev->netdev_ops->get_settings) + return -EOPNOTSUPP; + + err = dev->netdev_ops->get_settings(dev, &cmd); + if (err < 0) + return err; + + if (copy_to_user(useraddr, &cmd, sizeof(cmd))) + return -EFAULT; + return 0; +} + +static int ethtool_set_settings(struct net_device *dev, void *useraddr) +{ + struct ethtool_cmd cmd; + + if (!dev->netdev_ops->set_settings) + return -EOPNOTSUPP; + + if (copy_from_user(&cmd, useraddr, sizeof(cmd))) + return -EFAULT; + + return dev->netdev_ops->set_settings(dev, &cmd); +} + +static int ethtool_get_drvinfo(struct net_device *dev, void *useraddr) +{ + struct ethtool_drvinfo info; + struct netdev_ops *ops = dev->netdev_ops; + + if (!ops->get_drvinfo) + return -EOPNOTSUPP; + + memset(&info, 0, sizeof(info)); + info.cmd = ETHTOOL_GDRVINFO; + ops->get_drvinfo(dev, &info); + + if (ops->self_test_count) + info.testinfo_len = ops->self_test_count(dev); + if (ops->get_stats_count) + info.n_stats = ops->get_stats_count(dev); + if (ops->get_regs_len) + info.regdump_len = ops->get_regs_len(dev); + + if (copy_to_user(useraddr, &info, sizeof(info))) + return -EFAULT; + return 0; +} + +static int ethtool_get_regs(struct net_device *dev, char *useraddr) +{ + struct ethtool_regs regs; + struct netdev_ops *ops = dev->netdev_ops; + void *regbuf; + int reglen, ret; + + if (!ops->get_regs || !ops->get_regs_len) + return -EOPNOTSUPP; + + if (copy_from_user(®s, useraddr, sizeof(regs))) + return -EFAULT; + + reglen = ops->get_regs_len(dev); + if (regs.len > reglen) + regs.len = reglen; + + regbuf = kmalloc(reglen, GFP_KERNEL); + if (!regbuf) + return -ENOMEM; + + ops->get_regs(dev, ®s, regbuf); + + ret = -EFAULT; + if (copy_to_user(useraddr, ®s, sizeof(regs))) + goto out; + useraddr += offsetof(struct ethtool_regs, data); + if (copy_to_user(useraddr, regbuf, reglen)) + goto out; + ret = 0; + + out: + kfree(regbuf); + return ret; +} + +static int ethtool_get_wol(struct net_device *dev, char *useraddr) +{ + struct ethtool_wolinfo wol = { ETHTOOL_GWOL }; + + if (!dev->netdev_ops->get_wol) + return -EOPNOTSUPP; + + dev->netdev_ops->get_wol(dev, &wol); + + if (copy_to_user(useraddr, &wol, sizeof(wol))) + return -EFAULT; + return 0; +} + +static int ethtool_set_wol(struct net_device *dev, char *useraddr) +{ + struct ethtool_wolinfo wol; + + if (!dev->netdev_ops->set_wol) + return -EOPNOTSUPP; + + if (copy_from_user(&wol, useraddr, sizeof(wol))) + return -EFAULT; + + return dev->netdev_ops->set_wol(dev, &wol); +} + +static int ethtool_get_msglevel(struct net_device *dev, char *useraddr) +{ + struct ethtool_value edata = { ETHTOOL_GMSGLVL }; + + if (!dev->netdev_ops->get_msglevel) + return -EOPNOTSUPP; + + edata.data = dev->netdev_ops->get_msglevel(dev); + + if (copy_to_user(useraddr, &edata, sizeof(edata))) + return -EFAULT; + return 0; +} + +static int ethtool_set_msglevel(struct net_device *dev, char *useraddr) +{ + struct ethtool_value edata; + + if (!dev->netdev_ops->set_msglevel) + return -EOPNOTSUPP; + + if (copy_from_user(&edata, useraddr, sizeof(edata))) + return -EFAULT; + + dev->netdev_ops->set_msglevel(dev, edata.data); + return 0; +} + +static int ethtool_nway_reset(struct net_device *dev) +{ + if (!dev->netdev_ops->nway_reset) + return -EOPNOTSUPP; + + return dev->netdev_ops->nway_reset(dev); +} + +static int ethtool_get_link(struct net_device *dev, void *useraddr) +{ + struct ethtool_value edata = { ETHTOOL_GLINK }; + + if (!dev->netdev_ops->get_link) + return -EOPNOTSUPP; + + edata.data = dev->netdev_ops->get_link(dev); + + if (copy_to_user(useraddr, &edata, sizeof(edata))) + return -EFAULT; + return 0; +} + +static int ethtool_get_eeprom(struct net_device *dev, void *useraddr) +{ + struct ethtool_eeprom eeprom = { ETHTOOL_GEEPROM }; + + if (!dev->netdev_ops->get_eeprom) + return -EOPNOTSUPP; + + dev->netdev_ops->get_eeprom(dev, &eeprom); + + if (copy_to_user(useraddr, &eeprom, sizeof(eeprom))) + return -EFAULT; + return 0; +} + +static int ethtool_set_eeprom(struct net_device *dev, void *useraddr) +{ + struct ethtool_eeprom eeprom; + + if (!dev->netdev_ops->get_eeprom) + return -EOPNOTSUPP; + + if (copy_from_user(useraddr, &eeprom, sizeof(eeprom))) + return -EFAULT; + + return dev->netdev_ops->set_eeprom(dev, &eeprom); +} + +static int ethtool_get_coalesce(struct net_device *dev, void *useraddr) +{ + struct ethtool_coalesce coalesce = { ETHTOOL_GCOALESCE }; + + if (!dev->netdev_ops->get_coalesce) + return -EOPNOTSUPP; + + dev->netdev_ops->get_coalesce(dev, &coalesce); + + if (copy_to_user(useraddr, &coalesce, sizeof(coalesce))) + return -EFAULT; + return 0; +} + +static int ethtool_set_coalesce(struct net_device *dev, void *useraddr) +{ + struct ethtool_coalesce coalesce; + + if (!dev->netdev_ops->get_coalesce) + return -EOPNOTSUPP; + + if (copy_from_user(useraddr, &coalesce, sizeof(coalesce))) + return -EFAULT; + + return dev->netdev_ops->set_coalesce(dev, &coalesce); +} + +static int ethtool_get_ringparam(struct net_device *dev, void *useraddr) +{ + struct ethtool_ringparam ringparam = { ETHTOOL_GRINGPARAM }; + + if (!dev->netdev_ops->get_ringparam) + return -EOPNOTSUPP; + + dev->netdev_ops->get_ringparam(dev, &ringparam); + + if (copy_to_user(useraddr, &ringparam, sizeof(ringparam))) + return -EFAULT; + return 0; +} + +static int ethtool_set_ringparam(struct net_device *dev, void *useraddr) +{ + struct ethtool_ringparam ringparam; + + if (!dev->netdev_ops->get_ringparam) + return -EOPNOTSUPP; + + if (copy_from_user(useraddr, &ringparam, sizeof(ringparam))) + return -EFAULT; + + return dev->netdev_ops->set_ringparam(dev, &ringparam); +} + +static int ethtool_get_pauseparam(struct net_device *dev, void *useraddr) +{ + struct ethtool_pauseparam pauseparam = { ETHTOOL_GPAUSEPARAM }; + + if (!dev->netdev_ops->get_pauseparam) + return -EOPNOTSUPP; + + dev->netdev_ops->get_pauseparam(dev, &pauseparam); + + if (copy_to_user(useraddr, &pauseparam, sizeof(pauseparam))) + return -EFAULT; + return 0; +} + +static int ethtool_set_pauseparam(struct net_device *dev, void *useraddr) +{ + struct ethtool_pauseparam pauseparam; + + if (!dev->netdev_ops->get_pauseparam) + return -EOPNOTSUPP; + + if (copy_from_user(useraddr, &pauseparam, sizeof(pauseparam))) + return -EFAULT; + + return dev->netdev_ops->set_pauseparam(dev, &pauseparam); +} + +static int ethtool_get_rx_csum(struct net_device *dev, char *useraddr) +{ + struct ethtool_value edata = { ETHTOOL_GRXCSUM }; + + if (!dev->netdev_ops->get_rx_csum) + return -EOPNOTSUPP; + + edata.data = dev->netdev_ops->get_rx_csum(dev); + + if (copy_to_user(useraddr, &edata, sizeof(edata))) + return -EFAULT; + return 0; +} + +static int ethtool_set_rx_csum(struct net_device *dev, char *useraddr) +{ + struct ethtool_value edata; + + if (!dev->netdev_ops->set_rx_csum) + return -EOPNOTSUPP; + + if (copy_from_user(&edata, useraddr, sizeof(edata))) + return -EFAULT; + + dev->netdev_ops->set_rx_csum(dev, edata.data); + return 0; +} + +static int ethtool_get_tx_csum(struct net_device *dev, char *useraddr) +{ + struct ethtool_value edata = { ETHTOOL_GTXCSUM }; + + if (!dev->netdev_ops->get_tx_csum) + return -EOPNOTSUPP; + + edata.data = dev->netdev_ops->get_tx_csum(dev); + + if (copy_to_user(useraddr, &edata, sizeof(edata))) + return -EFAULT; + return 0; +} + +static int ethtool_set_tx_csum(struct net_device *dev, char *useraddr) +{ + struct ethtool_value edata; + + if (!dev->netdev_ops->set_tx_csum) + return -EOPNOTSUPP; + + if (copy_from_user(&edata, useraddr, sizeof(edata))) + return -EFAULT; + + return dev->netdev_ops->set_tx_csum(dev, edata.data); +} + +static int ethtool_get_sg(struct net_device *dev, char *useraddr) +{ + struct ethtool_value edata = { ETHTOOL_GSG }; + + if (!dev->netdev_ops->get_sg) + return -EOPNOTSUPP; + + edata.data = dev->netdev_ops->get_sg(dev); + + if (copy_to_user(useraddr, &edata, sizeof(edata))) + return -EFAULT; + return 0; +} + +static int ethtool_set_sg(struct net_device *dev, char *useraddr) +{ + struct ethtool_value edata; + + if (!dev->netdev_ops->set_sg) + return -EOPNOTSUPP; + + if (copy_from_user(&edata, useraddr, sizeof(edata))) + return -EFAULT; + + return dev->netdev_ops->set_sg(dev, edata.data); +} + +static int ethtool_self_test(struct net_device *dev, char *useraddr) +{ + struct ethtool_test test; + struct netdev_ops *ops = dev->netdev_ops; + u64 *data; + int ret; + + if (!ops->self_test || !ops->self_test_count) + return -EOPNOTSUPP; + + if (copy_from_user(&test, useraddr, sizeof(test))) + return -EFAULT; + + test.len = ops->self_test_count(dev); + data = kmalloc(test.len * sizeof(u64), GFP_KERNEL); + if (!data) + return -ENOMEM; + + ops->self_test(dev, &test, data); + + ret = -EFAULT; + if (copy_to_user(useraddr, &test, sizeof(test))) + goto out; + useraddr += sizeof(test); + if (copy_to_user(useraddr, data, test.len * sizeof(u64))) + goto out; + ret = 0; + + out: + kfree(data); + return ret; +} + +static int ethtool_get_strings(struct net_device *dev, void *useraddr) +{ + struct ethtool_gstrings gstrings; + struct netdev_ops *ops = dev->netdev_ops; + u8 *data; + int ret; + + if (!ops->get_strings) + return -EOPNOTSUPP; + + if (copy_from_user(&gstrings, useraddr, sizeof(gstrings))) + return -EFAULT; + + switch (gstrings.string_set) { + case ETH_SS_TEST: + if (ops->self_test_count) + gstrings.len = ops->self_test_count(dev); + else + return -EOPNOTSUPP; + case ETH_SS_STATS: + if (ops->get_stats_count) + gstrings.len = ops->get_stats_count(dev); + else + return -EOPNOTSUPP; + default: + return -EINVAL; + } + + data = kmalloc(gstrings.len * ETH_GSTRING_LEN, GFP_KERNEL); + if (!data) + return -ENOMEM; + + ops->get_strings(dev, gstrings.string_set, data); + + ret = -EFAULT; + if (copy_to_user(useraddr, &gstrings, sizeof(gstrings))) + goto out; + useraddr += sizeof(gstrings); + if (copy_to_user(useraddr, data, gstrings.len * ETH_GSTRING_LEN)) + goto out; + ret = 0; + + out: + kfree(data); + return ret; +} + +static int ethtool_phys_id(struct net_device *dev, void *useraddr) +{ + struct ethtool_value id; + + if (!dev->netdev_ops->phys_id) + return -EOPNOTSUPP; + + if (copy_from_user(&id, useraddr, sizeof(id))) + return -EFAULT; + + dev->netdev_ops->phys_id(dev, id.data); + return 0; +} + +static int ethtool_get_stats(struct net_device *dev, void *useraddr) +{ + struct ethtool_stats stats; + struct netdev_ops *ops = dev->netdev_ops; + u64 *data; + int ret; + + if (!ops->get_stats || !ops->get_stats_count) + return -EOPNOTSUPP; + + if (copy_from_user(&stats, useraddr, sizeof(stats))) + return -EFAULT; + + stats.n_stats = ops->get_stats_count(dev); + data = kmalloc(stats.n_stats * sizeof(u64), GFP_KERNEL); + if (!data) + return -ENOMEM; + + ops->get_stats(dev, &stats, data); + + ret = -EFAULT; + if (copy_to_user(useraddr, &stats, sizeof(stats))) + goto out; + useraddr += sizeof(stats); + if (copy_to_user(useraddr, data, stats.n_stats * sizeof(u64))) + goto out; + ret = 0; + + out: + kfree(data); + return ret; +} + +int dev_ethtool(struct ifreq *ifr) +{ + struct net_device *dev = __dev_get_by_name(ifr->ifr_name); + void *useraddr = (void *) ifr->ifr_data; + u32 ethcmd; + + /* XXX: We can make this more finegrained now. Keep existing + * behaviour for the moment. + */ + if (!capable(CAP_NET_ADMIN)) + return -EPERM; + + if (!dev || !netif_device_present(dev)) + return -ENODEV; + + if (!dev->netdev_ops) + goto ioctl; + + if (copy_from_user (ðcmd, useraddr, sizeof (ethcmd))) + return -EFAULT; + + switch (ethcmd) { + case ETHTOOL_GSET: + return ethtool_get_settings(dev, useraddr); + case ETHTOOL_SSET: + return ethtool_set_settings(dev, useraddr); + case ETHTOOL_GDRVINFO: + return ethtool_get_drvinfo(dev, useraddr); + case ETHTOOL_GREGS: + return ethtool_get_regs(dev, useraddr); + case ETHTOOL_GWOL: + return ethtool_get_wol(dev, useraddr); + case ETHTOOL_SWOL: + return ethtool_set_wol(dev, useraddr); + case ETHTOOL_GMSGLVL: + return ethtool_get_msglevel(dev, useraddr); + case ETHTOOL_SMSGLVL: + return ethtool_set_msglevel(dev, useraddr); + case ETHTOOL_NWAY_RST: + return ethtool_nway_reset(dev); + case ETHTOOL_GLINK: + return ethtool_get_link(dev, useraddr); + case ETHTOOL_GEEPROM: + return ethtool_get_eeprom(dev, useraddr); + case ETHTOOL_SEEPROM: + return ethtool_set_eeprom(dev, useraddr); + case ETHTOOL_GCOALESCE: + return ethtool_get_coalesce(dev, useraddr); + case ETHTOOL_SCOALESCE: + return ethtool_set_coalesce(dev, useraddr); + case ETHTOOL_GRINGPARAM: + return ethtool_get_ringparam(dev, useraddr); + case ETHTOOL_SRINGPARAM: + return ethtool_set_ringparam(dev, useraddr); + case ETHTOOL_GPAUSEPARAM: + return ethtool_get_pauseparam(dev, useraddr); + case ETHTOOL_SPAUSEPARAM: + return ethtool_set_pauseparam(dev, useraddr); + case ETHTOOL_GRXCSUM: + return ethtool_get_rx_csum(dev, useraddr); + case ETHTOOL_SRXCSUM: + return ethtool_set_rx_csum(dev, useraddr); + case ETHTOOL_GTXCSUM: + return ethtool_get_tx_csum(dev, useraddr); + case ETHTOOL_STXCSUM: + return ethtool_set_tx_csum(dev, useraddr); + case ETHTOOL_GSG: + return ethtool_get_sg(dev, useraddr); + case ETHTOOL_SSG: + return ethtool_set_sg(dev, useraddr); + case ETHTOOL_TEST: + return ethtool_self_test(dev, useraddr); + case ETHTOOL_GSTRINGS: + return ethtool_get_strings(dev, useraddr); + case ETHTOOL_PHYS_ID: + return ethtool_phys_id(dev, useraddr); + case ETHTOOL_GSTATS: + return ethtool_get_stats(dev, useraddr); + default: + return -EOPNOTSUPP; + } + + ioctl: + if (dev->do_ioctl) + return dev->do_ioctl(dev, ifr, SIOCETHTOOL); + return -EOPNOTSUPP; +} + Index: drivers/net/tg3.c =================================================================== RCS file: /var/cvs/linux-2.5/drivers/net/tg3.c,v retrieving revision 1.16 diff -u -p -r1.16 tg3.c --- drivers/net/tg3.c 14 Jun 2003 22:15:21 -0000 1.16 +++ drivers/net/tg3.c 9 Jul 2003 14:33:19 -0000 @@ -5036,16 +5036,20 @@ static void tg3_set_rx_mode(struct net_d #define TG3_REGDUMP_LEN (32 * 1024) -static u8 *tg3_get_regs(struct tg3 *tp) +static int tg3_get_regs_len(struct net_device *dev) { - u8 *orig_p = kmalloc(TG3_REGDUMP_LEN, GFP_KERNEL); - u8 *p; + return TG3_REGDUMP_LEN; +} + +static void tg3_get_regs(struct net_device *dev, struct ethtool_regs *regs, void *p) +{ + struct tg3 *tp = dev->priv; + u8 *orig_p = p; int i; - if (orig_p == NULL) - return NULL; + regs->version = 0; - memset(orig_p, 0, TG3_REGDUMP_LEN); + memset(p, 0, TG3_REGDUMP_LEN); spin_lock_irq(&tp->lock); spin_lock(&tp->tx_lock); @@ -5099,390 +5103,287 @@ do { p = orig_p + (reg); \ spin_unlock(&tp->tx_lock); spin_unlock_irq(&tp->lock); - - return orig_p; } -static int tg3_ethtool_ioctl (struct net_device *dev, void *useraddr) +static int tg3_get_settings(struct net_device *dev, struct ethtool_cmd *cmd) { struct tg3 *tp = dev->priv; - struct pci_dev *pci_dev = tp->pdev; - u32 ethcmd; - if (copy_from_user (ðcmd, useraddr, sizeof (ethcmd))) - return -EFAULT; - - switch (ethcmd) { - case ETHTOOL_GDRVINFO:{ - struct ethtool_drvinfo info = { ETHTOOL_GDRVINFO }; - strcpy (info.driver, DRV_MODULE_NAME); - strcpy (info.version, DRV_MODULE_VERSION); - memset(&info.fw_version, 0, sizeof(info.fw_version)); - strcpy (info.bus_info, pci_dev->slot_name); - info.eedump_len = 0; - info.regdump_len = TG3_REGDUMP_LEN; - if (copy_to_user (useraddr, &info, sizeof (info))) - return -EFAULT; - return 0; - } + if (!(tp->tg3_flags & TG3_FLAG_INIT_COMPLETE) || + tp->link_config.phy_is_low_power) + return -EAGAIN; + + cmd->supported = (SUPPORTED_Autoneg); + + if (!(tp->tg3_flags & TG3_FLAG_10_100_ONLY)) + cmd->supported |= (SUPPORTED_1000baseT_Half | + SUPPORTED_1000baseT_Full); + + if (tp->phy_id != PHY_ID_SERDES) + cmd->supported |= (SUPPORTED_100baseT_Half | + SUPPORTED_100baseT_Full | + SUPPORTED_10baseT_Half | + SUPPORTED_10baseT_Full | + SUPPORTED_MII); + else + cmd->supported |= SUPPORTED_FIBRE; - case ETHTOOL_GSET: { - struct ethtool_cmd cmd = { ETHTOOL_GSET }; + cmd->advertising = tp->link_config.advertising; + cmd->speed = tp->link_config.active_speed; + cmd->duplex = tp->link_config.active_duplex; + cmd->port = 0; + cmd->phy_address = PHY_ADDR; + cmd->transceiver = 0; + cmd->autoneg = tp->link_config.autoneg; + cmd->maxtxpkt = 0; + cmd->maxrxpkt = 0; + return 0; +} - if (!(tp->tg3_flags & TG3_FLAG_INIT_COMPLETE) || - tp->link_config.phy_is_low_power) - return -EAGAIN; - cmd.supported = (SUPPORTED_Autoneg); - - if (!(tp->tg3_flags & TG3_FLAG_10_100_ONLY)) - cmd.supported |= (SUPPORTED_1000baseT_Half | - SUPPORTED_1000baseT_Full); - - if (tp->phy_id != PHY_ID_SERDES) - cmd.supported |= (SUPPORTED_100baseT_Half | - SUPPORTED_100baseT_Full | - SUPPORTED_10baseT_Half | - SUPPORTED_10baseT_Full | - SUPPORTED_MII); - else - cmd.supported |= SUPPORTED_FIBRE; +static int tg3_set_settings(struct net_device *dev, struct ethtool_cmd *cmd) +{ + struct tg3 *tp = dev->priv; - cmd.advertising = tp->link_config.advertising; - cmd.speed = tp->link_config.active_speed; - cmd.duplex = tp->link_config.active_duplex; - cmd.port = 0; - cmd.phy_address = PHY_ADDR; - cmd.transceiver = 0; - cmd.autoneg = tp->link_config.autoneg; - cmd.maxtxpkt = 0; - cmd.maxrxpkt = 0; - if (copy_to_user(useraddr, &cmd, sizeof(cmd))) - return -EFAULT; - return 0; + if (!(tp->tg3_flags & TG3_FLAG_INIT_COMPLETE) || + tp->link_config.phy_is_low_power) + return -EAGAIN; + + if (cmd->autoneg == AUTONEG_ENABLE) { + tp->link_config.advertising = cmd->advertising; + tp->link_config.speed = SPEED_INVALID; + tp->link_config.duplex = DUPLEX_INVALID; + } else { + tp->link_config.speed = cmd->speed; + tp->link_config.duplex = cmd->duplex; } - case ETHTOOL_SSET: { - struct ethtool_cmd cmd; - if (!(tp->tg3_flags & TG3_FLAG_INIT_COMPLETE) || - tp->link_config.phy_is_low_power) - return -EAGAIN; - - if (copy_from_user(&cmd, useraddr, sizeof(cmd))) - return -EFAULT; - - /* Fiber PHY only supports 1000 full/half */ - if (cmd.autoneg == AUTONEG_ENABLE) { - if (tp->phy_id == PHY_ID_SERDES && - (cmd.advertising & - (ADVERTISED_10baseT_Half | - ADVERTISED_10baseT_Full | - ADVERTISED_100baseT_Half | - ADVERTISED_100baseT_Full))) - return -EINVAL; - if ((tp->tg3_flags & TG3_FLAG_10_100_ONLY) && - (cmd.advertising & - (ADVERTISED_1000baseT_Half | - ADVERTISED_1000baseT_Full))) - return -EINVAL; - } else { - if (tp->phy_id == PHY_ID_SERDES && - (cmd.speed == SPEED_10 || - cmd.speed == SPEED_100)) - return -EINVAL; - if ((tp->tg3_flags & TG3_FLAG_10_100_ONLY) && - (cmd.speed == SPEED_10 || - cmd.speed == SPEED_100)) - return -EINVAL; - } - - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); - - tp->link_config.autoneg = cmd.autoneg; - if (cmd.autoneg == AUTONEG_ENABLE) { - tp->link_config.advertising = cmd.advertising; - tp->link_config.speed = SPEED_INVALID; - tp->link_config.duplex = DUPLEX_INVALID; - } else { - tp->link_config.speed = cmd.speed; - tp->link_config.duplex = cmd.duplex; - } + tg3_setup_phy(tp); + spin_unlock(&tp->tx_lock); + spin_unlock_irq(&tp->lock); - tg3_setup_phy(tp); - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); + return 0; +} - return 0; - } +static void tg3_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info) +{ + struct tg3 *tp = dev->priv; - case ETHTOOL_GREGS: { - struct ethtool_regs regs; - u8 *regbuf; - int ret; - - if (copy_from_user(®s, useraddr, sizeof(regs))) - return -EFAULT; - if (regs.len > TG3_REGDUMP_LEN) - regs.len = TG3_REGDUMP_LEN; - regs.version = 0; - if (copy_to_user(useraddr, ®s, sizeof(regs))) - return -EFAULT; - - regbuf = tg3_get_regs(tp); - if (!regbuf) - return -ENOMEM; - - useraddr += offsetof(struct ethtool_regs, data); - ret = 0; - if (copy_to_user(useraddr, regbuf, regs.len)) - ret = -EFAULT; - kfree(regbuf); - return ret; - } - case ETHTOOL_GWOL: { - struct ethtool_wolinfo wol = { ETHTOOL_GWOL }; - - wol.supported = WAKE_MAGIC; - wol.wolopts = 0; - if (tp->tg3_flags & TG3_FLAG_WOL_ENABLE) - wol.wolopts = WAKE_MAGIC; - memset(&wol.sopass, 0, sizeof(wol.sopass)); - if (copy_to_user(useraddr, &wol, sizeof(wol))) - return -EFAULT; - return 0; - } - case ETHTOOL_SWOL: { - struct ethtool_wolinfo wol; + strcpy(info->driver, DRV_MODULE_NAME); + strcpy(info->version, DRV_MODULE_VERSION); + strcpy(info->bus_info, pci_name(tp->pdev)); +} - if (copy_from_user(&wol, useraddr, sizeof(wol))) - return -EFAULT; - if (wol.wolopts & ~WAKE_MAGIC) - return -EINVAL; - if ((wol.wolopts & WAKE_MAGIC) && - tp->phy_id == PHY_ID_SERDES && - !(tp->tg3_flags & TG3_FLAG_SERDES_WOL_CAP)) - return -EINVAL; +static void tg3_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol) +{ + struct tg3 *tp = dev->priv; - spin_lock_irq(&tp->lock); - if (wol.wolopts & WAKE_MAGIC) - tp->tg3_flags |= TG3_FLAG_WOL_ENABLE; - else - tp->tg3_flags &= ~TG3_FLAG_WOL_ENABLE; - spin_unlock_irq(&tp->lock); + wol->supported = WAKE_MAGIC; + wol->wolopts = 0; + if (tp->tg3_flags & TG3_FLAG_WOL_ENABLE) + wol->wolopts = WAKE_MAGIC; + memset(&wol->sopass, 0, sizeof(wol->sopass)); +} - return 0; - } - case ETHTOOL_GMSGLVL: { - struct ethtool_value edata = { ETHTOOL_GMSGLVL }; - edata.data = tp->msg_enable; - if (copy_to_user(useraddr, &edata, sizeof(edata))) - return -EFAULT; - return 0; - } - case ETHTOOL_SMSGLVL: { - struct ethtool_value edata; - if (copy_from_user(&edata, useraddr, sizeof(edata))) - return -EFAULT; - tp->msg_enable = edata.data; - return 0; - } - case ETHTOOL_NWAY_RST: { - u32 bmcr; - int r; +static int tg3_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol) +{ + struct tg3 *tp = dev->priv; - spin_lock_irq(&tp->lock); - tg3_readphy(tp, MII_BMCR, &bmcr); - tg3_readphy(tp, MII_BMCR, &bmcr); - r = -EINVAL; - if (bmcr & BMCR_ANENABLE) { - tg3_writephy(tp, MII_BMCR, - bmcr | BMCR_ANRESTART); - r = 0; - } - spin_unlock_irq(&tp->lock); + if (wol->wolopts & ~WAKE_MAGIC) + return -EINVAL; + if ((wol->wolopts & WAKE_MAGIC) && + tp->phy_id == PHY_ID_SERDES && + !(tp->tg3_flags & TG3_FLAG_SERDES_WOL_CAP)) + return -EINVAL; - return r; - } - case ETHTOOL_GLINK: { - struct ethtool_value edata = { ETHTOOL_GLINK }; - edata.data = netif_carrier_ok(tp->dev) ? 1 : 0; - if (copy_to_user(useraddr, &edata, sizeof(edata))) - return -EFAULT; - return 0; - } - case ETHTOOL_GRINGPARAM: { - struct ethtool_ringparam ering = { ETHTOOL_GRINGPARAM }; + spin_lock_irq(&tp->lock); + if (wol->wolopts & WAKE_MAGIC) + tp->tg3_flags |= TG3_FLAG_WOL_ENABLE; + else + tp->tg3_flags &= ~TG3_FLAG_WOL_ENABLE; + spin_unlock_irq(&tp->lock); - ering.rx_max_pending = TG3_RX_RING_SIZE - 1; - ering.rx_mini_max_pending = 0; - ering.rx_jumbo_max_pending = TG3_RX_JUMBO_RING_SIZE - 1; - - ering.rx_pending = tp->rx_pending; - ering.rx_mini_pending = 0; - ering.rx_jumbo_pending = tp->rx_jumbo_pending; - ering.tx_pending = tp->tx_pending; + return 0; +} - if (copy_to_user(useraddr, &ering, sizeof(ering))) - return -EFAULT; - return 0; - } - case ETHTOOL_SRINGPARAM: { - struct ethtool_ringparam ering; +static u32 tg3_get_msglevel(struct net_device *dev) +{ + struct tg3 *tp = dev->priv; + return tp->msg_enable; +} - if (copy_from_user(&ering, useraddr, sizeof(ering))) - return -EFAULT; +static void tg3_set_msglevel(struct net_device *dev, u32 value) +{ + struct tg3 *tp = dev->priv; + tp->msg_enable = value; +} - if ((ering.rx_pending > TG3_RX_RING_SIZE - 1) || - (ering.rx_jumbo_pending > TG3_RX_JUMBO_RING_SIZE - 1) || - (ering.tx_pending > TG3_TX_RING_SIZE - 1)) - return -EINVAL; +static int tg3_nway_reset(struct net_device *dev) +{ + struct tg3 *tp = dev->priv; + u32 bmcr; + int r; - tg3_netif_stop(tp); - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); + spin_lock_irq(&tp->lock); + tg3_readphy(tp, MII_BMCR, &bmcr); + tg3_readphy(tp, MII_BMCR, &bmcr); + r = -EINVAL; + if (bmcr & BMCR_ANENABLE) { + tg3_writephy(tp, MII_BMCR, bmcr | BMCR_ANRESTART); + r = 0; + } + spin_unlock_irq(&tp->lock); - tp->rx_pending = ering.rx_pending; - tp->rx_jumbo_pending = ering.rx_jumbo_pending; - tp->tx_pending = ering.tx_pending; - - tg3_halt(tp); - tg3_init_rings(tp); - tg3_init_hw(tp); - netif_wake_queue(tp->dev); - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); - tg3_netif_start(tp); + return r; +} - return 0; - } - case ETHTOOL_GPAUSEPARAM: { - struct ethtool_pauseparam epause = { ETHTOOL_GPAUSEPARAM }; +static void tg3_get_ringparam(struct net_device *dev, struct ethtool_ringparam *ering) +{ + struct tg3 *tp = dev->priv; - epause.autoneg = - (tp->tg3_flags & TG3_FLAG_PAUSE_AUTONEG) != 0; - epause.rx_pause = - (tp->tg3_flags & TG3_FLAG_PAUSE_RX) != 0; - epause.tx_pause = - (tp->tg3_flags & TG3_FLAG_PAUSE_TX) != 0; - if (copy_to_user(useraddr, &epause, sizeof(epause))) - return -EFAULT; - return 0; - } - case ETHTOOL_SPAUSEPARAM: { - struct ethtool_pauseparam epause; + ering->rx_max_pending = TG3_RX_RING_SIZE - 1; + ering->rx_mini_max_pending = 0; + ering->rx_jumbo_max_pending = TG3_RX_JUMBO_RING_SIZE - 1; + + ering->rx_pending = tp->rx_pending; + ering->rx_mini_pending = 0; + ering->rx_jumbo_pending = tp->rx_jumbo_pending; + ering->tx_pending = tp->tx_pending; +} - if (copy_from_user(&epause, useraddr, sizeof(epause))) - return -EFAULT; +static int tg3_set_ringparam(struct net_device *dev, struct ethtool_ringparam *ering) +{ + struct tg3 *tp = dev->priv; - tg3_netif_stop(tp); - spin_lock_irq(&tp->lock); - spin_lock(&tp->tx_lock); - if (epause.autoneg) - tp->tg3_flags |= TG3_FLAG_PAUSE_AUTONEG; - else - tp->tg3_flags &= ~TG3_FLAG_PAUSE_AUTONEG; - if (epause.rx_pause) - tp->tg3_flags |= TG3_FLAG_PAUSE_RX; - else - tp->tg3_flags &= ~TG3_FLAG_PAUSE_RX; - if (epause.tx_pause) - tp->tg3_flags |= TG3_FLAG_PAUSE_TX; - else - tp->tg3_flags &= ~TG3_FLAG_PAUSE_TX; - tg3_halt(tp); - tg3_init_rings(tp); - tg3_init_hw(tp); - spin_unlock(&tp->tx_lock); - spin_unlock_irq(&tp->lock); - tg3_netif_start(tp); + if ((ering->rx_pending > TG3_RX_RING_SIZE - 1) || + (ering->rx_jumbo_pending > TG3_RX_JUMBO_RING_SIZE - 1) || + (ering->tx_pending > TG3_TX_RING_SIZE - 1)) + return -EINVAL; - return 0; - } - case ETHTOOL_GRXCSUM: { - struct ethtool_value edata = { ETHTOOL_GRXCSUM }; + tg3_netif_stop(tp); + spin_lock_irq(&tp->lock); + spin_lock(&tp->tx_lock); - edata.data = - (tp->tg3_flags & TG3_FLAG_RX_CHECKSUMS) != 0; - if (copy_to_user(useraddr, &edata, sizeof(edata))) - return -EFAULT; - return 0; - } - case ETHTOOL_SRXCSUM: { - struct ethtool_value edata; + tp->rx_pending = ering->rx_pending; + tp->rx_jumbo_pending = ering->rx_jumbo_pending; + tp->tx_pending = ering->tx_pending; + + tg3_halt(tp); + tg3_init_rings(tp); + tg3_init_hw(tp); + netif_wake_queue(tp->dev); + spin_unlock(&tp->tx_lock); + spin_unlock_irq(&tp->lock); + tg3_netif_start(tp); - if (copy_from_user(&edata, useraddr, sizeof(edata))) - return -EFAULT; + return 0; +} - if (tp->tg3_flags & TG3_FLAG_BROKEN_CHECKSUMS) { - if (edata.data != 0) - return -EINVAL; - return 0; - } +static void tg3_get_pauseparam(struct net_device *dev, struct ethtool_pauseparam *epause) +{ + struct tg3 *tp = dev->priv; - spin_lock_irq(&tp->lock); - if (edata.data) - tp->tg3_flags |= TG3_FLAG_RX_CHECKSUMS; - else - tp->tg3_flags &= ~TG3_FLAG_RX_CHECKSUMS; - spin_unlock_irq(&tp->lock); + epause->autoneg = (tp->tg3_flags & TG3_FLAG_PAUSE_AUTONEG) != 0; + epause->rx_pause = (tp->tg3_flags & TG3_FLAG_PAUSE_RX) != 0; + epause->tx_pause = (tp->tg3_flags & TG3_FLAG_PAUSE_TX) != 0; +} - return 0; - } - case ETHTOOL_GTXCSUM: { - struct ethtool_value edata = { ETHTOOL_GTXCSUM }; +static int tg3_set_pauseparam(struct net_device *dev, struct ethtool_pauseparam *epause) +{ + struct tg3 *tp = dev->priv; - edata.data = - (tp->dev->features & NETIF_F_IP_CSUM) != 0; - if (copy_to_user(useraddr, &edata, sizeof(edata))) - return -EFAULT; - return 0; - } - case ETHTOOL_STXCSUM: { - struct ethtool_value edata; + tg3_netif_stop(tp); + spin_lock_irq(&tp->lock); + spin_lock(&tp->tx_lock); + if (epause->autoneg) + tp->tg3_flags |= TG3_FLAG_PAUSE_AUTONEG; + else + tp->tg3_flags &= ~TG3_FLAG_PAUSE_AUTONEG; + if (epause->rx_pause) + tp->tg3_flags |= TG3_FLAG_PAUSE_RX; + else + tp->tg3_flags &= ~TG3_FLAG_PAUSE_RX; + if (epause->tx_pause) + tp->tg3_flags |= TG3_FLAG_PAUSE_TX; + else + tp->tg3_flags &= ~TG3_FLAG_PAUSE_TX; + tg3_halt(tp); + tg3_init_rings(tp); + tg3_init_hw(tp); + spin_unlock(&tp->tx_lock); + spin_unlock_irq(&tp->lock); + tg3_netif_start(tp); - if (copy_from_user(&edata, useraddr, sizeof(edata))) - return -EFAULT; + return 0; +} - if (tp->tg3_flags & TG3_FLAG_BROKEN_CHECKSUMS) { - if (edata.data != 0) - return -EINVAL; - return 0; - } +static u32 tg3_get_rx_csum(struct net_device *dev) +{ + struct tg3 *tp = dev->priv; + return (tp->tg3_flags & TG3_FLAG_RX_CHECKSUMS) != 0; +} - if (edata.data) - tp->dev->features |= NETIF_F_IP_CSUM; - else - tp->dev->features &= ~NETIF_F_IP_CSUM; +static int tg3_set_rx_csum(struct net_device *dev, u32 data) +{ + struct tg3 *tp = dev->priv; + if (tp->tg3_flags & TG3_FLAG_BROKEN_CHECKSUMS) { + if (data != 0) + return -EINVAL; return 0; } - case ETHTOOL_GSG: { - struct ethtool_value edata = { ETHTOOL_GSG }; - edata.data = - (tp->dev->features & NETIF_F_SG) != 0; - if (copy_to_user(useraddr, &edata, sizeof(edata))) - return -EFAULT; - return 0; - } - case ETHTOOL_SSG: { - struct ethtool_value edata; + spin_lock_irq(&tp->lock); + if (data) + tp->tg3_flags |= TG3_FLAG_RX_CHECKSUMS; + else + tp->tg3_flags &= ~TG3_FLAG_RX_CHECKSUMS; + spin_unlock_irq(&tp->lock); - if (copy_from_user(&edata, useraddr, sizeof(edata))) - return -EFAULT; + return 0; +} - if (edata.data) - tp->dev->features |= NETIF_F_SG; - else - tp->dev->features &= ~NETIF_F_SG; +static int tg3_set_tx_csum(struct net_device *dev, u32 data) +{ + struct tg3 *tp = dev->priv; + if (tp->tg3_flags & TG3_FLAG_BROKEN_CHECKSUMS) { + if (data != 0) + return -EINVAL; return 0; } - }; - return -EOPNOTSUPP; + if (data) + dev->features |= NETIF_F_IP_CSUM; + else + dev->features &= ~NETIF_F_IP_CSUM; + + return 0; } +static struct netdev_ops tg3_netdev_ops = { + .get_settings = tg3_get_settings, + .set_settings = tg3_set_settings, + .get_drvinfo = tg3_get_drvinfo, + .get_regs_len = tg3_get_regs_len, + .get_regs = tg3_get_regs, + .get_wol = tg3_get_wol, + .set_wol = tg3_set_wol, + .get_msglevel = tg3_get_msglevel, + .set_msglevel = tg3_set_msglevel, + .nway_reset = tg3_nway_reset, + .get_link = netdev_op_get_link, + .get_ringparam = tg3_get_ringparam, + .set_ringparam = tg3_set_ringparam, + .get_pauseparam = tg3_get_pauseparam, + .set_pauseparam = tg3_set_pauseparam, + .get_rx_csum = tg3_get_rx_csum, + .set_rx_csum = tg3_set_rx_csum, + .get_tx_csum = netdev_op_get_tx_csum, + .set_tx_csum = tg3_set_tx_csum, + .get_sg = netdev_op_get_sg, + .set_sg = netdev_op_set_sg, +}; + static int tg3_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) { struct mii_ioctl_data *data = (struct mii_ioctl_data *)&ifr->ifr_data; @@ -5490,8 +5391,6 @@ static int tg3_ioctl(struct net_device * int err; switch(cmd) { - case SIOCETHTOOL: - return tg3_ethtool_ioctl(dev, (void *) ifr->ifr_data); case SIOCGMIIPHY: data->phy_id = PHY_ADDR; @@ -6773,6 +6672,7 @@ static int __devinit tg3_init_one(struct tp->rx_jumbo_pending = TG3_DEF_RX_JUMBO_RING_PENDING; tp->tx_pending = TG3_DEF_TX_RING_PENDING; + dev->netdev_ops = &tg3_netdev_ops; dev->open = tg3_open; dev->stop = tg3_close; dev->get_stats = tg3_get_stats; -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From greearb@candelatech.com Wed Jul 9 10:11:43 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 10:11:49 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-074.evrtwa1.dsl-verizon.net [4.33.45.74]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h69HBM2x028953 for ; Wed, 9 Jul 2003 10:11:43 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h69HB5Kk007597; Wed, 9 Jul 2003 10:11:05 -0700 Message-ID: <3F0C4CA8.7090502@candelatech.com> Date: Wed, 09 Jul 2003 10:11:04 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Wilcox CC: netdev@oss.sgi.com, "David S. Miller" , Arnaldo Carvalho de Melo , Jeff Garzik Subject: Re: [PATCH] netdev_ops References: <20030708163042.GL23597@parcelfarce.linux.theplanet.co.uk> <3F0B2D30.4020102@candelatech.com> <20030708212551.GL1939@parcelfarce.linux.theplanet.co.uk> <20030708.150835.78728697.davem@redhat.com> <20030709161520.GW1939@parcelfarce.linux.theplanet.co.uk> In-Reply-To: <20030709161520.GW1939@parcelfarce.linux.theplanet.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3861 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Matthew Wilcox wrote: > Changes since yesterday's patch: > > - Make all methods take the struct net_device as suggested by Ben Greear. > - Rename self_test_len() and get_stats_len() to *_count() to reflect > that they return a count of elements, not a byte length. > - Related bugfixes. > - Remove the get_strings_len() method; we now infer the length from > either self_test_count() or get_stats_count(). > - memset() the drvinfo struct so it doesn't leak information from the > kernel stack (existing bug in tg3). > - Clamp regs.len in ethtool.c rather than in the driver. > - Pass the stringset value to get_strings() rather than a pointer to > the whole ethtool_gstrings struct. > > I have a question about the error return values in ethtool_get_strings(). > Are -EOPNOTSUPP and -EINVAL the right ones to use in the case statement? > Or should I perhaps be using -ENOSYS instead of EINVAL? I've noticed > drepper tends to prefer this for unimplemented subops. Since this is > an ioctl(), perhaps I should be using -ENOTTY instead ;-) Considering any number of things may change in the future, what do you think of adding a global 'nettool-version' method. That could allow user-space code to take appropriate action if something ever changes in a non-compatible way.... Also, for the strings (labels) passed back to user space, is there any documentation for suggested values for these strings? Even though we can't be completely type-safe, if there were suggested values in a comment in the code, it could help a great deal for any code trying to parse them for multiple different drivers/nics. Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From greearb@candelatech.com Wed Jul 9 10:13:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 10:13:36 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-074.evrtwa1.dsl-verizon.net [4.33.45.74]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h69HDU2x029220 for ; Wed, 9 Jul 2003 10:13:31 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h69HDBKk007852; Wed, 9 Jul 2003 10:13:11 -0700 Message-ID: <3F0C4D27.20907@candelatech.com> Date: Wed, 09 Jul 2003 10:13:11 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hen, Shmulik" CC: Andrius Kasparavicius , netdev@oss.sgi.com Subject: Re: network interface cards native vlans support in linux kernel? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3862 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Hen, Shmulik wrote: > Do you mean "native" as in hardware acceleration offloading? > If that's the case than the 8021q vlan module handshakes with the device driver to check for support and that's it. No need to do any settings on the device. In case there is no offloading support, the vlan module will take care of all stripping/inserting of the vlan tag into place. > On the other hand, if the device cannot handle 1504 byte packets, it defines itself as "vlan challenged" and you can't use vlan on it at all. Even challenged ones can work if you set your MTU (and all peer MTUs) to 4 less than normal, ie 1496. Ben > > -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From greearb@candelatech.com Wed Jul 9 10:15:50 2003 Received: with ECARTIS (v1.0.0