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; list netdev); Wed, 09 Jul 2003 10:15:53 -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 h69HFn2x029606 for ; Wed, 9 Jul 2003 10:15:50 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h69HFfKk008170; Wed, 9 Jul 2003 10:15:41 -0700 Message-ID: <3F0C4DBD.8020007@candelatech.com> Date: Wed, 09 Jul 2003 10:15:41 -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: Andrius Kasparavicius CC: 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: 3863 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 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? Intel's e100 driver (and all NICs supported by it) support vlans fine, as do most of the GigE NICs. Tulip does not, last I hear, though a work-around patch has been around forever. Realtek worked at one time, not sure about now though... Ben > > > Andrius > -- 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 Wed Jul 9 10:25:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 10:25:38 -0700 (PDT) Received: from www.linux.org.uk (IDENT:IGTH7NcxQdNtrnY8ih8VlTNxdqHouBop@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h69HPT2x001623 for ; Wed, 9 Jul 2003 10:25:30 -0700 Received: from willy by www.linux.org.uk with local (Exim 4.14) id 19aIh3-0006Yh-J5; Wed, 09 Jul 2003 18:25:25 +0100 Date: Wed, 9 Jul 2003 18:25:25 +0100 From: Matthew Wilcox To: Ben Greear Cc: Matthew Wilcox , netdev@oss.sgi.com, "David S. Miller" , Arnaldo Carvalho de Melo , Jeff Garzik Subject: Re: [PATCH] netdev_ops Message-ID: <20030709172525.GZ1939@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> <20030709161520.GW1939@parcelfarce.linux.theplanet.co.uk> <3F0C4CA8.7090502@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F0C4CA8.7090502@candelatech.com> User-Agent: Mutt/1.4.1i X-archive-position: 3864 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 Wed, Jul 09, 2003 at 10:11:04AM -0700, Ben Greear wrote: > 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.... This patch makes only user-invisible changes. I'm trying to establish a base for further cleanups (eg, acme wants to look at unifying the wireless ops and the existing net_device function pointers into netdev_ops). I don't really have a position on adding a nettool-version ioctl or whatever, but I'm not sure it would make sense to have that as a netdev method. > 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. I didn't see any documentation; I just read the code. The only drivers I noticed supporting the GSTRINGS subcommand are 8139cp, 8139too, e100 and e1000. -- "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 kpfleming@cox.net Wed Jul 9 10:34:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 10:34:37 -0700 (PDT) Received: from fed1mtao07.cox.net (fed1mtao07.cox.net [68.6.19.124]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h69HY92x002025 for ; Wed, 9 Jul 2003 10:34:29 -0700 Received: from jeeves.kpf.internal ([24.56.60.83]) by fed1mtao07.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20030709173402.IZZS29962.fed1mtao07.cox.net@jeeves.kpf.internal>; Wed, 9 Jul 2003 13:34:02 -0400 Received: from [192.168.172.107] (helo=cox.net) by jeeves.kpf.internal with esmtp (Exim 4.05) id 19aIpP-0001UK-00; Wed, 09 Jul 2003 10:34:03 -0700 Message-ID: <3F0C520E.2080809@cox.net> Date: Wed, 09 Jul 2003 10:34:06 -0700 From: "Kevin P. Fleming" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: acpi-support@lists.sourceforge.net, netdev@oss.sgi.com Subject: How to begin debugging ACPI/network driver interrupt problem? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3865 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kpfleming@cox.net Precedence: bulk X-list: netdev I've got a system here using an MSI KT266-based motherboard that's been running 2.5.X successfully for months now. However, 2.5.73/74 have introduced a problem that (so far) I have only been able to cure by either not compiling in ACPI or using acpi=off on the kernel command line. The system three NICs: eth0 is a National Semiconductor DP83815 eth1 is a National Semiconductor DP83820 eth2 is a Lite-On 82C168 All three NICs work fine. However, on the newer kernels, with ACPI compiled in, during initialization of eth0 the kernel generates "IRQ 17 and nobody cared!" messages and disables IRQ 17, which causes eth0 to be useless :-) With older kernels, or ACPI not turned on, eth0 still gets assigned IRQ 17, and works just fine. IRQ 17 is not shared with any other devices. I don't think I can handle the additional message traffic of these two mailing lists, so I haven't subscribed... If anyone can suggest a course of action for how to debug this problem, please cc me on any responses. From greearb@candelatech.com Wed Jul 9 11:30:39 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 11:31:05 -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 h69ITr2x003913 for ; Wed, 9 Jul 2003 11:30:38 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h69IOZKk016833; Wed, 9 Jul 2003 11:24:35 -0700 Message-ID: <3F0C5DE3.7000506@candelatech.com> Date: Wed, 09 Jul 2003 11:24:35 -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: Matthew Wilcox , netdev@oss.sgi.com, "David S. Miller" , Arnaldo Carvalho de Melo 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> <3F0C4CA8.7090502@candelatech.com> <20030709181459.GE15293@gtf.org> In-Reply-To: <20030709181459.GE15293@gtf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3866 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: > On Wed, Jul 09, 2003 at 10:11:04AM -0700, Ben Greear wrote: > >>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. > > > The strings represent NIC-specific attributes. Yes, but surely there is some comonality? I'm not asking for something set in stone, but just some general guidelines. However, I don't feel too strongly about this, so if it is not worth the time/effort, then I'll still be happy :) Ben > > Jeff > > -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From yoshfuji@linux-ipv6.org Wed Jul 9 11:30:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 11:31:07 -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 h69IU12x003915 for ; Wed, 9 Jul 2003 11:30:39 -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 h69IVHBo025676; Thu, 10 Jul 2003 03:31:17 +0900 Date: Thu, 10 Jul 2003 03:31:17 +0900 (JST) Message-Id: <20030710.033117.93244305.yoshfuji@linux-ipv6.org> To: Jean-Luc.Richier@imag.fr Cc: pekkas@netcore.fi, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: Bug in Linux 2.5.74 IPv6 routing From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20030709195237.A8550@horus.imag.fr> References: <20030709195237.A8550@horus.imag.fr> 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: 3867 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 CC: netdev In article <20030709195237.A8550@horus.imag.fr> (at Wed, 9 Jul 2003 19:52:37 +0200), Jean-Luc Richier says: > There is a bug in IPv6 route calculation since kernel 2.5.71. It affects > all routes with prefix length != 0 (mod 8) > The bug is as follows: > do: ip -6 route add 2000::/3 via 2001:688:121:10::1 > ip -6 route > It shows a route for ::/3, not for 2000::/3 good catch. > PATCH 2: avoid overwriting the set value > --- linux-2.5.74/include/net/ipv6.h.DIST 2003-07-02 22:53:44.000000000 +0200 > +++ linux-2.5.74/include/net/ipv6.h 2003-07-09 18:51:25.000000000 +0200 > @@ -276,8 +276,10 @@ > b = plen & 0x7; > > memcpy(pfx->s6_addr, addr, o); > - if (b != 0) > + if (b != 0) { > pfx->s6_addr[o] = addr->s6_addr[o] & (0xff00 >> b); > + o++; > + } > if (o < 16) > memset(pfx->s6_addr + o, 0, 16 - o); > } > Ok, let's use this one. --yoshfuji From yoshfuji@linux-ipv6.org Wed Jul 9 11:43:11 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 11:43:15 -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 h69Ih92x004614 for ; Wed, 9 Jul 2003 11:43:10 -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 h69IiQBo025781; Thu, 10 Jul 2003 03:44:26 +0900 Date: Thu, 10 Jul 2003 03:44:25 +0900 (JST) Message-Id: <20030710.034425.55677522.yoshfuji@linux-ipv6.org> To: davem@redhat.com, jmorris@intercode.com.au CC: Jean-Luc.Richier@imag.fr, pekkas@netcore.fi, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: Bug in Linux 2.5.74 IPv6 routing From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20030710.033117.93244305.yoshfuji@linux-ipv6.org> References: <20030709195237.A8550@horus.imag.fr> <20030710.033117.93244305.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: 3868 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 <20030710.033117.93244305.yoshfuji@linux-ipv6.org> (at Thu, 10 Jul 2003 03:31:17 +0900 (JST)), YOSHIFUJI Hideaki / $B5HF#1QL@(B says: > Ok, let's use this one. Please apply this patch. D: Fix ipv6_addr_prefix() for prefixlen != 0 (mod 8). D: Patch from Jean-Luc RICHIER . --- linux-2.5.74/include/net/ipv6.h.DIST 2003-07-02 22:53:44.000000000 +0200 +++ linux-2.5.74/include/net/ipv6.h 2003-07-09 18:51:25.000000000 +0200 @@ -276,8 +276,10 @@ b = plen & 0x7; memcpy(pfx->s6_addr, addr, o); - if (b != 0) + if (b != 0) { pfx->s6_addr[o] = addr->s6_addr[o] & (0xff00 >> b); + o++; + } if (o < 16) memset(pfx->s6_addr + o, 0, 16 - o); } -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From garzik@gtf.org Wed Jul 9 11:44:07 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 11:44:10 -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 h69Ihu2x004834 for ; Wed, 9 Jul 2003 11:43:57 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id E83A46643; Wed, 9 Jul 2003 14:14:59 -0400 (EDT) Date: Wed, 9 Jul 2003 14:14:59 -0400 From: Jeff Garzik To: Ben Greear Cc: Matthew Wilcox , netdev@oss.sgi.com, "David S. Miller" , Arnaldo Carvalho de Melo Subject: Re: [PATCH] netdev_ops Message-ID: <20030709181459.GE15293@gtf.org> 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> <3F0C4CA8.7090502@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F0C4CA8.7090502@candelatech.com> User-Agent: Mutt/1.3.28i X-archive-position: 3869 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 10:11:04AM -0700, Ben Greear wrote: > 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. The strings represent NIC-specific attributes. Jeff From shemminger@osdl.org Wed Jul 9 11:45:06 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 11:45:10 -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 h69Ij52x005283 for ; Wed, 9 Jul 2003 11:45:06 -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 h69IhYI03705; Wed, 9 Jul 2003 11:43:35 -0700 Date: Wed, 9 Jul 2003 11:43:34 -0700 From: Stephen Hemminger To: "Paul Rolland" , cfriesen@nortelnetworks.com, paulus@samba.org Cc: linux-ppp@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [BUG]: problem when shutting down ppp connection since 2.5.70 Message-Id: <20030709114334.5b8cf7c6.shemminger@osdl.org> In-Reply-To: <008201c343a3$0f9f8a70$2101a8c0@witbe> References: <3F03BC55.6050506@nortelnetworks.com> <008201c343a3$0f9f8a70$2101a8c0@witbe> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.3 (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: 3870 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 The problem is that some protocol is still holding a reference to the device. This is a bug in the protocol, and needs to be fixed (ie not a ppp bug). Try building a kernel with only IPv4, eliminate all others then add back until you find the culprit. The following patch may help also. diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c Wed Jul 9 11:40:56 2003 +++ b/net/core/dev.c Wed Jul 9 11:40:56 2003 @@ -72,6 +72,8 @@ * - netif_rx() feedback */ +#define DEBUG 1 + #include #include #include @@ -2704,6 +2706,8 @@ goto out; } +extern void dst_dumpref(const struct net_device *dev); + static void netdev_wait_allrefs(struct net_device *dev) { unsigned long rebroadcast_time, warning_time; @@ -2740,6 +2744,30 @@ current->state = TASK_RUNNING; if (time_after(jiffies, warning_time + 10 * HZ)) { +#ifdef DEBUG + dst_dumpref(dev); + + if (dev->atalk_ptr) + printk(KERN_INFO "unregister_netdevice: " + " %s: probably in use as AppleTalk device\n", dev->name); + if (dev->ip_ptr) + printk(KERN_INFO "unregister_netdevice: " + " %s: probably in use as IPv4 device\n", dev->name); + + if (dev->atalk_ptr) + printk(KERN_INFO "unregister_netdevice: " + " %s: probably in use as DECnet device\n", dev->name); + if (dev->ip6_ptr) + printk(KERN_INFO "unregister_netdevice: " + " %s: probably in use as IPv6 device\n", dev->name); + + if (dev->ec_ptr) + printk(KERN_INFO "unregister_netdevice: " + " %s: probably in use as Econet device\n", dev->name); + if (dev->ax25_ptr) + printk(KERN_INFO "unregister_netdevice: " + " %s: probably in use as AX.25 device\n", dev->name); +#endif printk(KERN_EMERG "unregister_netdevice: " "waiting for %s to become free. Usage " "count = %d\n", diff -Nru a/net/core/dst.c b/net/core/dst.c --- a/net/core/dst.c Wed Jul 9 11:40:56 2003 +++ b/net/core/dst.c Wed Jul 9 11:40:56 2003 @@ -41,6 +41,21 @@ static struct timer_list dst_gc_timer = TIMER_INITIALIZER(dst_run_gc, 0, DST_GC_MIN); + +void dst_dumpref(const struct net_device *dev) +{ + struct dst_entry *dst; + int count = 0; + + spin_lock_bh(&dst_lock); + for (dst = dst_garbage_list; dst; dst = dst->next) { + if (dst->dev == dev) ++count; + } + spin_unlock_bh(&dst_lock); + + printk(KERN_INFO "dst route cache has %d references\n", count); +} + static void dst_run_gc(unsigned long dummy) { int delayed = 0; From andrius@andrius.org Wed Jul 9 12:12:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 12:12:36 -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 h69JCP2x006932 for ; Wed, 9 Jul 2003 12:12:28 -0700 Received: by hl.kalnieciai.lt (Postfix, from userid 1430) id 29CD94F228; Wed, 9 Jul 2003 22:12:23 +0300 (GMT-3) Received: from localhost (localhost [127.0.0.1]) by hl.kalnieciai.lt (Postfix) with ESMTP id 252354F226; Wed, 9 Jul 2003 22:12:23 +0300 (GMT-3) Date: Wed, 9 Jul 2003 22:12:23 +0300 (GMT-3) From: Andrius Kasparavicius X-X-Sender: andrius@hl.kauneta.net To: Ben Greear Cc: netdev@oss.sgi.com Subject: Re: network interface cards native vlans support in linux kernel? In-Reply-To: <3F0C4DBD.8020007@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3871 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 is there a clear list of which cards "works without patch", which "need patches/mtu changes" and which "never seen working"? Andrius On Wed, 9 Jul 2003, Ben Greear wrote: > 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? > > Intel's e100 driver (and all NICs supported by it) support vlans > fine, as do most of the GigE NICs. Tulip does not, last I hear, though > a work-around patch has been around forever. Realtek worked at one time, > not sure about now though... From tgr@reeler.org Wed Jul 9 12:36:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 12:36:50 -0700 (PDT) Received: from rei.rakuen (dclient217-162-65-211.hispeed.ch [217.162.65.211]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h69Jag2x000331 for ; Wed, 9 Jul 2003 12:36:45 -0700 Received: by reeler.org id 19aKjs-0003SC-00 ; Wed, 09 Jul 2003 21:36:28 +0200 Date: Wed, 9 Jul 2003 21:36:28 +0200 From: Thomas Graf To: davem@redhat.com Cc: netdev@oss.sgi.com, tgraf@suug.ch Subject: [PATCH] make {send|recv}msg return code 1003.1 compatible Message-ID: <20030709193628.GR2702@rei.rakuen> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Encryption: "Encrypted with ROT13 using key 42" X-archive-position: 3872 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Hello 1003.1 says: [EMSGSIZE] The msg_iovlen member of the msghdr structure pointed to by message is less than or equal to 0, or is greater than {IOV_MAX}. The patch changes the return code of {send|recv}msg from EINVAL to EMSGSIZE. -- thomas Index: net/socket.c =================================================================== RCS file: /cvs/tgr/linux-25/net/socket.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 socket.c --- net/socket.c 9 Jul 2003 18:42:29 -0000 1.1.1.1 +++ net/socket.c 9 Jul 2003 19:17:29 -0000 @@ -1614,7 +1614,7 @@ goto out; /* do not move before msg_sys is valid */ - err = -EINVAL; + err = -EMSGSIZE; if (msg_sys.msg_iovlen > UIO_MAXIOV) goto out_put; @@ -1713,7 +1713,7 @@ if (!sock) goto out; - err = -EINVAL; + err = -EMSGSIZE; if (msg_sys.msg_iovlen > UIO_MAXIOV) goto out_put; From shemminger@osdl.org Wed Jul 9 13:13:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 13:13:30 -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 h69KDH2x001106 for ; Wed, 9 Jul 2003 13:13: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 h69KD0I25600; Wed, 9 Jul 2003 13:13:00 -0700 Date: Wed, 9 Jul 2003 13:13:00 -0700 From: Stephen Hemminger To: "David S. Miller" , Jay Schulist Cc: netdev@oss.sgi.com, linux-atalk@lists.netspace.org Subject: [[RFT] convert appletalk over to new protocol Message-Id: <20030709131300.660c052f.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.3 (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: 3873 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 fixes appletalk ddp protocol to address a couple of issues: - routing code was holding a reference to device without doing ref counting. - packet interface was old style - add shared buffer checks - add pullup's where needed - change checksum to handle fragmented sk_buff's - clean up comments to match above changes. I don't have real appletalk test infrastructure, and given the checksum change it should be tested against real Apple hardware. It does build, and loads/unloads fine. I can bring up the netatalk stuff without problem but have nothing to talk to it. diff -Nru a/net/appletalk/ddp.c b/net/appletalk/ddp.c --- a/net/appletalk/ddp.c Wed Jul 9 12:55:00 2003 +++ b/net/appletalk/ddp.c Wed Jul 9 12:55:00 2003 @@ -239,6 +239,7 @@ while ((tmp = *iface) != NULL) { if (tmp->dev == dev) { *iface = tmp->next; + dev_put(dev); kfree(tmp); dev->atalk_ptr = NULL; } else @@ -256,6 +257,7 @@ goto out; iface->dev = dev; + dev_hold(dev); dev->atalk_ptr = iface; iface->address = *sa; iface->status = 0; @@ -665,9 +667,13 @@ static int ddp_device_event(struct notifier_block *this, unsigned long event, void *ptr) { - if (event == NETDEV_DOWN) + switch (event) { + case NETDEV_DOWN: + case NETDEV_UNREGISTER: /* Discard any use of this */ atalk_dev_down(ptr); + break; + } return NOTIFY_DONE; } @@ -935,13 +941,10 @@ * Checksum: This is 'optional'. It's quite likely also a good * candidate for assembler hackery 8) */ -unsigned short atalk_checksum(struct ddpehdr *ddp, int len) -{ - unsigned long sum = 0; /* Assume unsigned long is >16 bits */ - unsigned char *data = (unsigned char *)ddp; - len -= 4; /* skip header 4 bytes */ - data += 4; +static unsigned long atalk_sum_partial(const unsigned char *data, + int len, unsigned long sum) +{ /* This ought to be unwrapped neatly. I'll trust gcc for now */ while (len--) { @@ -953,10 +956,94 @@ } data++; } + return sum; +} + +/* Checksum skb data -- similar to skb_checksum */ +static unsigned long atalk_sum_skb(const struct sk_buff *skb, int offset, + int len, unsigned long sum) +{ + int start = skb_headlen(skb); + int i, copy; + int pos = 0; + + /* checksum stuff in header space */ + if ( (copy = start - offset) > 0) { + if (copy > len) + copy = len; + sum = atalk_sum_partial(skb->data + offset, copy, sum); + if ( (len -= copy) == 0) + return sum; + offset += copy; + pos = copy; + } + + /* checksum stuff in frags */ + for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) { + int end; + + BUG_TRAP(start <= offset + len); + + end = start + skb_shinfo(skb)->frags[i].size; + if ((copy = end - offset) > 0) { + u8 *vaddr; + skb_frag_t *frag = &skb_shinfo(skb)->frags[i]; + + if (copy > len) + copy = len; + vaddr = kmap_skb_frag(frag); + sum = atalk_sum_partial(vaddr + frag->page_offset + + offset - start, copy, sum); + kunmap_skb_frag(vaddr); + + if (!(len -= copy)) + return sum; + offset += copy; + pos += copy; + } + start = end; + } + + if (skb_shinfo(skb)->frag_list) { + struct sk_buff *list = skb_shinfo(skb)->frag_list; + + for (; list; list = list->next) { + int end; + + BUG_TRAP(start <= offset + len); + + end = start + list->len; + if ((copy = end - offset) > 0) { + if (copy > len) + copy = len; + sum = atalk_sum_skb(list, offset - start, + copy, sum); + if ((len -= copy) == 0) + return sum; + offset += copy; + pos += copy; + } + start = end; + } + } + + BUG_ON(len > 0); + + return sum; +} + +static unsigned short atalk_checksum(const struct sk_buff *skb, int len) +{ + unsigned long sum; + + /* skip header 4 bytes */ + sum = atalk_sum_skb(skb, 4, len-4, 0); + /* Use 0xFFFF for 0. 0 itself means none */ return sum ? htons((unsigned short)sum) : 0xFFFF; } + /* * Create a socket. Initialise the socket, blank the addresses * set the state. @@ -1335,25 +1422,26 @@ static int atalk_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt) { - struct ddpehdr *ddp = ddp_hdr(skb); + struct ddpehdr *ddp; struct sock *sock; struct atalk_iface *atif; struct sockaddr_at tosat; int origlen; struct ddpebits ddphv; - /* Size check */ - if (skb->len < sizeof(*ddp)) + /* Don't mangle buffer if shared */ + if (!(skb = skb_share_check(skb, GFP_ATOMIC))) + goto out; + + /* Size check and make sure header is contiguous */ + if (!pskb_may_pull(skb, sizeof(*ddp))) goto freeit; + ddp = ddp_hdr(skb); /* * Fix up the length field [Ok this is horrible but otherwise * I end up with unions of bit fields and messy bit field order * compiler/endian dependencies..] - * - * FIXME: This is a write to a shared object. Granted it - * happens to be safe BUT.. (Its safe as user space will not - * run until we put it back) */ *((__u16 *)&ddphv) = ntohs(*((__u16 *)ddp)); @@ -1374,7 +1462,7 @@ * valid for net byte orders all over the networking code... */ if (ddp->deh_sum && - atalk_checksum(ddp, ddphv.deh_len) != ddp->deh_sum) + atalk_checksum(skb, ddphv.deh_len) != ddp->deh_sum) /* Not a valid AppleTalk frame - dustbin time */ goto freeit; @@ -1433,14 +1521,16 @@ if (!ap || skb->len < sizeof(struct ddpshdr)) goto freeit; + + /* Don't mangle buffer if shared */ + if (!(skb = skb_share_check(skb, GFP_ATOMIC))) + return 0; + /* * The push leaves us with a ddephdr not an shdr, and * handily the port bytes in the right place preset. */ - - skb_push(skb, sizeof(*ddp) - 4); - /* FIXME: use skb->cb to be able to use shared skbs */ - ddp = (struct ddpehdr *)skb->data; + ddp = (struct ddpehdr *) skb_push(skb, sizeof(*ddp) - 4); /* Now fill in the long header */ @@ -1583,6 +1673,7 @@ SOCK_DEBUG(sk, "SK %p: Copy user data (%d bytes).\n", sk, len); + /* TODO: copy and checksum in one pass */ err = memcpy_fromiovec(skb_put(skb, len), msg->msg_iov, len); if (err) { kfree_skb(skb); @@ -1592,7 +1683,7 @@ if (sk->sk_no_check == 1) ddp->deh_sum = 0; else - ddp->deh_sum = atalk_checksum(ddp, len + sizeof(*ddp)); + ddp->deh_sum = atalk_checksum(skb, len + sizeof(*ddp)); /* * Loopback broadcast packets to non gateway targets (ie routes @@ -1801,11 +1892,13 @@ struct packet_type ltalk_packet_type = { .type = __constant_htons(ETH_P_LOCALTALK), .func = ltalk_rcv, + .data = (void *) 1, }; struct packet_type ppptalk_packet_type = { .type = __constant_htons(ETH_P_PPPTALK), .func = atalk_rcv, + .data = (void *) 1, }; static unsigned char ddp_snap_id[] = { 0x08, 0x00, 0x07, 0x80, 0x9B }; From shemminger@osdl.org Wed Jul 9 13:13:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 13:13:49 -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 h69KDh2x001125 for ; Wed, 9 Jul 2003 13:13:44 -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 h69KDYI25700; Wed, 9 Jul 2003 13:13:34 -0700 Date: Wed, 9 Jul 2003 13:13:34 -0700 From: Stephen Hemminger To: Jeff Garzik , Jay Schulist Cc: netdev@oss.sgi.com, linux-atalk@lists.netspace.org Subject: [PATCH 2.5.74] convert appletalk/ipddp to dynamic allocation Message-Id: <20030709131334.79df4dca.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.3 (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: 3874 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 Part of the continuing campaign to fix all network devices to allocate dynamically. Built, loaded/unloaded and configured but don't have real test environment to communicate with other hosts. diff -Nru a/drivers/net/appletalk/ipddp.c b/drivers/net/appletalk/ipddp.c --- a/drivers/net/appletalk/ipddp.c Wed Jul 9 12:55:44 2003 +++ b/drivers/net/appletalk/ipddp.c Wed Jul 9 12:55:44 2003 @@ -72,17 +72,8 @@ printk("%s: Appletalk-IP Decap. mode by Jay Schulist \n", dev->name); - /* Fill in the device structure with ethernet-generic values. */ - ether_setup(dev); - /* Initalize the device structure. */ dev->hard_start_xmit = ipddp_xmit; - - dev->priv = kmalloc(sizeof(struct net_device_stats), GFP_KERNEL); - if(!dev->priv) - return -ENOMEM; - memset(dev->priv,0,sizeof(struct net_device_stats)); - dev->get_stats = ipddp_get_stats; dev->do_ioctl = ipddp_ioctl; @@ -281,7 +272,7 @@ } } -static struct net_device dev_ipddp; +static struct net_device *dev_ipddp; MODULE_LICENSE("GPL"); MODULE_PARM(ipddp_mode, "i"); @@ -290,29 +281,33 @@ { int err; - dev_ipddp.init = ipddp_init; - err=dev_alloc_name(&dev_ipddp, "ipddp%d"); - if(err < 0) - return err; + dev_ipddp = alloc_netdev(sizeof(struct net_device_stats), + "ipddp%d", ether_setup); - if(register_netdev(&dev_ipddp) != 0) - return -EIO; + if (!dev_ipddp) + return -ENOMEM; - return 0; + dev_ipddp->init = ipddp_init; + + if((err = register_netdev(dev_ipddp))) + kfree(dev_ipddp); + + return err; } static void __exit ipddp_cleanup_module(void) { struct ipddp_route *p; - unregister_netdev(&dev_ipddp); - kfree(dev_ipddp.priv); + unregister_netdev(dev_ipddp); while (ipddp_route_list) { p = ipddp_route_list->next; kfree(ipddp_route_list); ipddp_route_list = p; } + + kfree(dev_ipddp); } module_init(ipddp_init_module); From shemminger@osdl.org Wed Jul 9 13:24:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 13:24:54 -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 h69KOj2x001792 for ; Wed, 9 Jul 2003 13:24:46 -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 h69KOcI28241; Wed, 9 Jul 2003 13:24:38 -0700 Date: Wed, 9 Jul 2003 13:24:38 -0700 From: Stephen Hemminger To: Jeff Garzik , Jay Schulist Cc: netdev@oss.sgi.com Subject: [PATCH 2.5.74] convert appletalk/ltpc over to dynamic allocation Message-Id: <20030709132438.432fcd2b.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.3 (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: 3875 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 Part of the continuing campaign to fix all network devices to allocate dynamically. Built, loaded/unloaded and configured but don't have real hardware. --- linux-2.5.74/drivers/net/appletalk/ltpc.c 2003-07-09 13:19:55.000000000 -0700 +++ linux-2.5-sysfs/drivers/net/appletalk/ltpc.c 2003-07-09 13:22:14.000000000 -0700 @@ -884,18 +884,8 @@ /* Initialize the device structure. */ /* Fill in the fields of the device structure with ethernet-generic values. */ - ltalk_setup(dev); dev->hard_start_xmit = ltpc_xmit; dev->hard_header = ltpc_hard_header; - - dev->priv = kmalloc(sizeof(struct ltpc_private), GFP_KERNEL); - if(!dev->priv) - { - printk(KERN_INFO "%s: could not allocate statistics buffer\n", dev->name); - return -ENOMEM; - } - - memset(dev->priv, 0, sizeof(struct ltpc_private)); dev->get_stats = ltpc_get_stats; /* add the ltpc-specific things */ @@ -1169,6 +1159,7 @@ printk(KERN_INFO "Apple/Farallon LocalTalk-PC card at %03x, DMA%d. Using polled mode.\n",io,dma); /* seems more logical to do this *after* probing the card... */ + ltalk_setup(dev); err = ltpc_init(dev); if (err) return err; @@ -1256,11 +1247,10 @@ } __setup("ltpc=", ltpc_setup); -#endif /* MODULE */ -static struct net_device dev_ltpc; +#else /* MODULE */ -#ifdef MODULE +static struct net_device *dev_ltpc; MODULE_LICENSE("GPL"); MODULE_PARM(debug, "i"); @@ -1268,23 +1258,22 @@ MODULE_PARM(irq, "i"); MODULE_PARM(dma, "i"); - -int __init init_module(void) +static int __init ltpc_init_module(void) { - int err, result; + int result; if(io == 0) printk(KERN_NOTICE "ltpc: Autoprobing is not recommended for modules\n"); - /* Find a name for this unit */ - dev_ltpc.init = ltpc_probe; - err=dev_alloc_name(&dev_ltpc,"lt%d"); - - if(err<0) - return err; + dev_ltpc = alloc_netdev(sizeof(struct ltpc_private), "lt%d", + ltalk_setup); + - if ((result = register_netdev(&dev_ltpc)) != 0) { + dev_ltpc->init = ltpc_probe; + + if ((result = register_netdev(dev_ltpc)) != 0) { + kfree(dev_ltpc); printk(KERN_DEBUG "could not register Localtalk-PC device\n"); return result; } else { @@ -1292,7 +1281,6 @@ return 0; } } -#endif static void __exit ltpc_cleanup(void) { @@ -1302,9 +1290,9 @@ if(debug & DEBUG_VERBOSE) printk("freeing irq\n"); - if(dev_ltpc.irq) { - free_irq(dev_ltpc.irq,&dev_ltpc); - dev_ltpc.irq = 0; + if(dev_ltpc->irq) { + free_irq(dev_ltpc->irq,dev_ltpc); + dev_ltpc->irq = 0; } if(del_timer(<pc_timer)) @@ -1323,16 +1311,16 @@ if(debug & DEBUG_VERBOSE) printk("freeing dma\n"); - if(dev_ltpc.dma) { - free_dma(dev_ltpc.dma); - dev_ltpc.dma = 0; + if(dev_ltpc->dma) { + free_dma(dev_ltpc->dma); + dev_ltpc->dma = 0; } if(debug & DEBUG_VERBOSE) printk("freeing ioaddr\n"); - if(dev_ltpc.base_addr) { - release_region(dev_ltpc.base_addr,8); - dev_ltpc.base_addr = 0; + if(dev_ltpc->base_addr) { + release_region(dev_ltpc->base_addr,8); + dev_ltpc->base_addr = 0; } if(debug & DEBUG_VERBOSE) printk("free_pages\n"); @@ -1343,9 +1331,14 @@ if(debug & DEBUG_VERBOSE) printk("unregister_netdev\n"); - unregister_netdev(&dev_ltpc); + unregister_netdev(dev_ltpc); if(debug & DEBUG_VERBOSE) printk("returning from cleanup_module\n"); + + kfree(dev_ltpc); } +module_init(ltpc_init_module); module_exit(ltpc_cleanup); + +#endif From shemminger@osdl.org Wed Jul 9 13:29:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 13:29:23 -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 h69KTH2x002112 for ; Wed, 9 Jul 2003 13:29: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 h69KTAI29092; Wed, 9 Jul 2003 13:29:10 -0700 Date: Wed, 9 Jul 2003 13:29:10 -0700 From: Stephen Hemminger To: Jeff Garzik , Jay Schulist Cc: netdev@oss.sgi.com Subject: [PATCH 2.5.74] Change appletalk/cops to dynamic allocation of net_device Message-Id: <20030709132910.589cf65d.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.3 (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: 3876 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 Part of the continuing campaign to fix all network devices to allocate dynamically. Built and loaded/unloaded, but do not have the hardware. Surprisingly probe suceeds even without hardware. diff -Nru a/drivers/net/appletalk/cops.c b/drivers/net/appletalk/cops.c --- a/drivers/net/appletalk/cops.c Wed Jul 9 12:55:30 2003 +++ b/drivers/net/appletalk/cops.c Wed Jul 9 12:55:30 2003 @@ -235,9 +235,11 @@ * Dayna cards don't autoprobe well at all, but if your card is * at IRQ 5 & IO 0x240 we find it every time. ;) JS */ - for(i=0; cops_portlist[i]; i++) + for(i=0; cops_portlist[i]; i++) { + ltalk_setup(dev); if(cops_probe1(dev, cops_portlist[i]) == 0) return 0; + } return -ENODEV; } @@ -311,24 +313,12 @@ dev->base_addr = ioaddr; /* Initialize the private device structure. */ - dev->priv = kmalloc(sizeof(struct cops_local), GFP_KERNEL); - if(dev->priv == NULL) { - if (dev->irq) - free_irq(dev->irq, dev); - retval = -ENOMEM; - goto err_out; - } - lp = (struct cops_local *)dev->priv; - memset(lp, 0, sizeof(struct cops_local)); spin_lock_init(&lp->lock); /* Copy local board variable to lp struct. */ lp->board = board; - /* Fill in the fields of the device structure with LocalTalk values. */ - ltalk_setup(dev); - dev->hard_start_xmit = cops_send_packet; dev->tx_timeout = cops_timeout; dev->watchdog_timeo = HZ * 2; @@ -1012,44 +1002,50 @@ } #ifdef MODULE -static struct net_device cops0_dev = { .init = cops_probe }; +static struct net_device *cops0_dev; MODULE_LICENSE("GPL"); MODULE_PARM(io, "i"); MODULE_PARM(irq, "i"); MODULE_PARM(board_type, "i"); -int init_module(void) +static int __init cops_init_module(void) { - int result, err; + int err; if(io == 0) printk(KERN_WARNING "%s: You shouldn't autoprobe with insmod\n", cardname); - /* Copy the parameters from insmod into the device structure. */ - cops0_dev.base_addr = io; - cops0_dev.irq = irq; + cops0_dev = alloc_netdev(sizeof(struct cops_local), "lt%d", + ltalk_setup); + + cops0_dev->init = cops_probe; - err=dev_alloc_name(&cops0_dev, "lt%d"); - if(err < 0) - return err; + /* Copy the parameters from insmod into the device structure. */ + cops0_dev->base_addr = io; + cops0_dev->irq = irq; - if((result = register_netdev(&cops0_dev)) != 0) - return result; + if ((err = register_netdev(cops0_dev))) + kfree(cops0_dev); - return 0; + return err; } -void cleanup_module(void) +static void __exit cops_cleanup_module(void) { - unregister_netdev(&cops0_dev); - kfree(cops0_dev.priv); - if(cops0_dev.irq) - free_irq(cops0_dev.irq, &cops0_dev); - release_region(cops0_dev.base_addr, COPS_IO_EXTENT); + unregister_netdev(cops0_dev); + + if(cops0_dev->irq) + free_irq(cops0_dev->irq, &cops0_dev); + release_region(cops0_dev->base_addr, COPS_IO_EXTENT); + kfree(cops0_dev); } -#endif /* MODULE */ + +module_init(cops_init_module); +module_exit(cops_cleanup_module); + +#endif /* * Local variables: From shemminger@osdl.org Wed Jul 9 14:45:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 14:45:40 -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 h69Lja2x003448 for ; Wed, 9 Jul 2003 14:45:36 -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 h69LjTI12035; Wed, 9 Jul 2003 14:45:29 -0700 Date: Wed, 9 Jul 2003 14:45:29 -0700 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Convert hp100 to useing alloc_etherdev Message-Id: <20030709144529.5c14d995.shemminger@osdl.org> In-Reply-To: <20030708151427.328aae38.shemminger@osdl.org> References: <20030708151427.328aae38.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.3 (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: 3877 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev This patch won't work for the non-module probe case, will resubmit a better one. From shemminger@osdl.org Wed Jul 9 14:46:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 14:46: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 h69LkE2x003531 for ; Wed, 9 Jul 2003 14:46:14 -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 h69Lk5I12225; Wed, 9 Jul 2003 14:46:05 -0700 Date: Wed, 9 Jul 2003 14:46:05 -0700 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.5.74] convert apne to dynamic allocation Message-Id: <20030709144605.48f3d4dc.shemminger@osdl.org> In-Reply-To: <20030708151245.179cac2b.shemminger@osdl.org> References: <20030708151245.179cac2b.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.3 (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: 3878 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev This patch won't work for the non-module case (and it has a typo). From davem@redhat.com Wed Jul 9 17:28:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 17:28:42 -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 h6A0SY2x007907 for ; Wed, 9 Jul 2003 17:28:35 -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 RAA24726; Wed, 9 Jul 2003 17:20:13 -0700 Date: Wed, 09 Jul 2003 17:20:12 -0700 (PDT) Message-Id: <20030709.172012.41656849.davem@redhat.com> To: ak@suse.de Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: reasons for dev_alloc_skb +16? From: "David S. Miller" In-Reply-To: <20030709175355.422545b5.ak@suse.de> References: <20030709152553.GB15293@gtf.org> <20030709175355.422545b5.ak@suse.de> 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: 3879 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: Andi Kleen Date: Wed, 9 Jul 2003 17:53:55 +0200 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. Only "dumb cards" do that, smart ones rewind to the beginning of the current cache line and ask for the whole thing instead of pieces. The +16 is actually needed to align the first hunk of the outgoing packet so we can do a 16-byte aligned memcpy of the hard-header cache as we build the packet. Jeff, look at LL_RESERVED_SPACE() and the comment above it in include/linux/netdevice.h From jmorris@intercode.com.au Wed Jul 9 18:31:30 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 18:31:37 -0700 (PDT) Received: from blackbird.intercode.com.au (IDENT:+8CNk7KKoaKvqKiG9qA1ggxYqyLR+QVh@blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6A1VR2x010044 for ; Wed, 9 Jul 2003 18:31: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 h6A1Utr28674; Thu, 10 Jul 2003 11:30:56 +1000 Date: Thu, 10 Jul 2003 11:30:55 +1000 (EST) From: James Morris To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: davem@redhat.com, , , Subject: Re: Bug in Linux 2.5.74 IPv6 routing In-Reply-To: <20030710.034425.55677522.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 3880 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, 10 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote: > Please apply this patch. > > D: Fix ipv6_addr_prefix() for prefixlen != 0 (mod 8). > D: Patch from Jean-Luc RICHIER . Applied to bk://kernel.bkbits.net/jmorris/net-2.5 -- James Morris From davem@redhat.com Wed Jul 9 19:17:09 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 19:17:15 -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 h6A2H92x010807 for ; Wed, 9 Jul 2003 19:17:09 -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 TAA25043; Wed, 9 Jul 2003 19:08:39 -0700 Date: Wed, 09 Jul 2003 19:08:38 -0700 (PDT) Message-Id: <20030709.190838.70200577.davem@redhat.com> To: shemminger@osdl.org Cc: netdev@oss.sgi.com Subject: Re: [PATCH] PPP handling fragmented skbuff's From: "David S. Miller" In-Reply-To: <20030627163524.347b2c8e.shemminger@osdl.org> References: <20030627163524.347b2c8e.shemminger@osdl.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: 3881 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: Stephen Hemminger Date: Fri, 27 Jun 2003 16:35:24 -0700 Don't think this ever happens today, but if PPP ever gets a fragmented a skbuff and decides to copy it then bad things will happen. The following replaces the places that memcpy() with skb_copy_bits(). Applied, thanks Stephen. From davem@redhat.com Wed Jul 9 20:49:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 20:49:20 -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 h6A3nD2x011952 for ; Wed, 9 Jul 2003 20:49:14 -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 UAA25268; Wed, 9 Jul 2003 20:39:48 -0700 Date: Wed, 09 Jul 2003 20:39:47 -0700 (PDT) Message-Id: <20030709.203947.116374520.davem@redhat.com> To: vnuorval@tcs.hut.fi Cc: yoshfuji@linux-ipv6.org, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] Tunnel device init patch 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: 3882 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: Ville Nuorvala Date: Fri, 4 Jul 2003 16:00:29 +0300 (EEST) 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: Surely you mean changeset "1.1384" and also changesets "1.1305.3.9, 1.1305..." etc. above too :-) - 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 Applied, thank you. From davem@redhat.com Wed Jul 9 20:52:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 20:52:48 -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 h6A3qg2x012277 for ; Wed, 9 Jul 2003 20:52:43 -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 UAA25287; Wed, 9 Jul 2003 20:43:12 -0700 Date: Wed, 09 Jul 2003 20:43:12 -0700 (PDT) Message-Id: <20030709.204312.68059397.davem@redhat.com> To: vnuorval@tcs.hut.fi Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [PATCH] IPV6: Fix incorrect dst_entry handling in ip6_tunnel.c 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: 3883 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: Ville Nuorvala Date: Fri, 4 Jul 2003 16:14:18 +0300 (EEST) I noticed a bug in ip6ip6_err(), please apply this patch! Applied, thank you. From jmorris@intercode.com.au Wed Jul 9 21:43:04 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 21:43:15 -0700 (PDT) Received: from blackbird.intercode.com.au (IDENT:8qQPMDpdNe7/V2wjfjX63I7fub7VUE57@blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6A4h12x012989 for ; Wed, 9 Jul 2003 21:43:03 -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 h6A4gjr29383; Thu, 10 Jul 2003 14:42:48 +1000 Date: Thu, 10 Jul 2003 14:42:44 +1000 (EST) From: James Morris To: Jim Keniston cc: LKML , , Andrew Morton , "David S. Miller" , Jeff Garzik , Alan Cox , Randy Dunlap Subject: Re: [PATCH - RFC] [1/2] 2.6 must-fix list - kernel error reporting In-Reply-To: <3F0AFFE6.E85FF283@us.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3884 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, Jim Keniston wrote: + kerror_nl = netlink_kernel_create(NETLINK_KERROR, kerror_netlink_rcv); + if (kerror_nl == NULL) + panic("kerror_init: cannot initialize kerror_nl\n"); You can simply use NULL instead of passing the dummy kerror_netlink_rcv function. +struct kern_log_entry { + __u16 log_kmagic; /* always LOGREC_KMAGIC */ + __u16 log_kversion; /* which version of this struct? */ + char log_facility[FACILITY_MAXLEN]; /* e.g., driver name */ These fields should generally be specified in ascending order to help with alignment. It may also be worth looking at how the ULOG code batches messages to improve peformance. - James -- James Morris From davem@redhat.com Wed Jul 9 22:56:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 22:56:33 -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 h6A5uP2x013654 for ; Wed, 9 Jul 2003 22:56:26 -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 WAA25513; Wed, 9 Jul 2003 22:47:00 -0700 Date: Wed, 09 Jul 2003 22:47:00 -0700 (PDT) Message-Id: <20030709.224700.27801124.davem@redhat.com> To: vnuorval@tcs.hut.fi Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [PATCH] IPV6: ipv6-in-ipv6 tunnel using alloc_netdev 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: 3885 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: Ville Nuorvala Date: Fri, 4 Jul 2003 23:23:44 +0300 (EEST) 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... Applied, thanks. From davem@redhat.com Wed Jul 9 23:01:05 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Jul 2003 23:01:09 -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 h6A6142x014023 for ; Wed, 9 Jul 2003 23:01:05 -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 WAA25551; Wed, 9 Jul 2003 22:52:41 -0700 Date: Wed, 09 Jul 2003 22:52:41 -0700 (PDT) Message-Id: <20030709.225241.98880784.davem@redhat.com> To: tgraf@suug.ch Cc: netdev@oss.sgi.com Subject: Re: [PATCH] make {send|recv}msg return code 1003.1 compatible From: "David S. Miller" In-Reply-To: <20030709193628.GR2702@rei.rakuen> References: <20030709193628.GR2702@rei.rakuen> 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: 3886 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: Thomas Graf Date: Wed, 9 Jul 2003 21:36:28 +0200 1003.1 says: [EMSGSIZE] The msg_iovlen member of the msghdr structure pointed to by message is less than or equal to 0, or is greater than {IOV_MAX}. The patch changes the return code of {send|recv}msg from EINVAL to EMSGSIZE. Patch applied, thanks. From scott.feldman@intel.com Thu Jul 10 00:47:21 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 00:47:29 -0700 (PDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6A7lK2x015324 for ; Thu, 10 Jul 2003 00:47:21 -0700 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.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 h6A7jAp10742 for ; Thu, 10 Jul 2003 07:45:10 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.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 h6A7gTS03362 for ; Thu, 10 Jul 2003 07:42:29 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003071000583616414 ; Thu, 10 Jul 2003 00:58:36 -0700 Received: from orsmsx402.amr.corp.intel.com ([192.168.65.208]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 10 Jul 2003 00:47:14 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [PATCH] netdev_ops Date: Thu, 10 Jul 2003 00:47:13 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] netdev_ops Thread-Index: AcNGNWOcsUvuyZ5UQHGlJaWR4BWYQwAgbxyg From: "Feldman, Scott" To: "Matthew Wilcox" Cc: X-OriginalArrivalTime: 10 Jul 2003 07:47:14.0449 (UTC) FILETIME=[7A7D3010:01C346B7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h6A7lK2x015324 X-archive-position: 3887 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 Can we get a HAVE_NETDEV_OPS? From davem@redhat.com Thu Jul 10 00:50:32 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 00:50:38 -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 h6A7oV2x015601 for ; Thu, 10 Jul 2003 00:50:32 -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 AAA25812; Thu, 10 Jul 2003 00:42:08 -0700 Date: Thu, 10 Jul 2003 00:42:07 -0700 (PDT) Message-Id: <20030710.004207.35528695.davem@redhat.com> To: scott.feldman@intel.com Cc: willy@debian.org, netdev@oss.sgi.com Subject: Re: [PATCH] netdev_ops 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: 3888 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: "Feldman, Scott" Date: Thu, 10 Jul 2003 00:47:13 -0700 Can we get a HAVE_NETDEV_OPS? Don't tell me you're seriously considering having _TWO_ copies of all this code sitting around? At that point backwards compat becomes absolutely rediculious. If it's important to you, just stick to the current scheme. You gain nothing by maintaining two copies of the same code. From scott.feldman@intel.com Thu Jul 10 01:18:58 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 01:19:06 -0700 (PDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6A8Iw2x016629 for ; Thu, 10 Jul 2003 01:18:58 -0700 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.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 h6A8Gmp26269 for ; Thu, 10 Jul 2003 08:16:48 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.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 h6A8E7m22456 for ; Thu, 10 Jul 2003 08:14:07 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003071001301421284 ; Thu, 10 Jul 2003 01:30:14 -0700 Received: from orsmsx402.amr.corp.intel.com ([192.168.65.208]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 10 Jul 2003 01:18:51 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [PATCH] netdev_ops Date: Thu, 10 Jul 2003 01:18:50 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] netdev_ops Thread-Index: AcNGt+/LXquM9ebEQEO0AjBtV3zQ1gAAU8Vg From: "Feldman, Scott" To: "David S. Miller" Cc: , X-OriginalArrivalTime: 10 Jul 2003 08:18:51.0133 (UTC) FILETIME=[E50032D0:01C346BB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h6A8Iw2x016629 X-archive-position: 3889 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 > Don't tell me you're seriously considering having _TWO_ > copies of all this code sitting around? > > At that point backwards compat becomes absolutely > rediculious. If it's important to you, just stick to the > current scheme. You gain nothing by maintaining two copies > of the same code. Either way we end up with duplicated code. If I stick with the current scheme (no netdev_ops), I duplicate in the driver all of the wrapper code that Matt has pulled into netdev_ops. Each driver that sticks to the current scheme duplicates Matt's code. With HAVE_NETDEV_OPS, you're right, we're maintaining the wrapper code outside the kernel. But, it does leave the possibility of having a shared backwards compatibility code for multiple (all?) drivers for those stuck with supporting kernels without netdev_ops. From rusty@samba.org Thu Jul 10 01:48:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 01:48:29 -0700 (PDT) Received: from lists.samba.org (dp.samba.org [66.70.73.150]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6A8mL2x017236 for ; Thu, 10 Jul 2003 01:48:21 -0700 Received: by lists.samba.org (Postfix, from userid 590) id 909D12C0DA; Thu, 10 Jul 2003 08:48:20 +0000 (GMT) From: Rusty Russell To: netdev@oss.sgi.com Cc: netfilter-devel@lists.netfilter.org, anton@samba.org Subject: [PATCH] Netfilter crossover module. Date: Thu, 10 Jul 2003 18:47:05 +1000 Message-Id: <20030710084820.909D12C0DA@lists.samba.org> X-archive-position: 3890 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rusty@rustcorp.com.au Precedence: bulk X-list: netdev Lots of people keep asking to be able to plug a crossover cables between to NICs in a machine, and use it for testing. This is a simple module which does this, by creating phantom machine(s) on each network with IP address 1 greater than the interface. Testers welcome. Ignore the backwards compat crap, it'll be out of the final version. Example usage: # Bring interfaces up ifconfig eth0 192.168.1.1 ifconfig eth1 192.168.2.1 # Add module which creates "phantom" machines 192.168.1.2, and 192.168.2.2. modprobe ip_crossover dev1=eth0 dev2=eth1 # Tell kernel that 192.168.1.2 packets go to eth1, and .2.1 to eth0. arp -s 192.168.1.2 arp -s 192.168.2.2 It'd be nice to have the module hardwire the arps itself, but this was quickest. Patch welcome. Rusty. Name: Hardware Loopback Module Author: Rusty Russell Status: Tested on 2.5.74-bk5 D: For testing it is often nice to connect two NICs with a crossover D: cable and have the machine route packets between them. D: D: Since Linux steadfastly regards IP addresses as properties of the D: box, not the individual NICs, this requires some trickery. A simple D: netfilter module makes this possible, by producing "phantom" boxes. diff -urNp --exclude TAGS -X /home/rusty/current-dontdiff --minimal linux-2.5.74-bk5/net/ipv4/netfilter/Kconfig working-2.5.74-bk5-hardware_loopback/net/ipv4/netfilter/Kconfig --- linux-2.5.74-bk5/net/ipv4/netfilter/Kconfig 2003-07-03 09:44:02.000000000 +1000 +++ working-2.5.74-bk5-hardware_loopback/net/ipv4/netfilter/Kconfig 2003-07-08 18:03:29.000000000 +1000 @@ -587,5 +587,18 @@ config IP_NF_COMPAT_IPFWADM If you want to compile it as a module, say M here and read . If unsure, say `N'. +config IP_NF_CROSSOVER + tristate "IP forced crossover support (EXPERIMENTAL)" + depends on EXPERIMENTAL + help + This option allows you to connect two local network cards + with a crossover cable, and then force packets to pass over + that cable (Linux will normally short-circuit such packets). + + If you want to compile it as a module, say M here and read + : the module will be called + ip_crossover. + + Say `N'. endmenu diff -urNp --exclude TAGS -X /home/rusty/current-dontdiff --minimal linux-2.5.74-bk5/net/ipv4/netfilter/Makefile working-2.5.74-bk5-hardware_loopback/net/ipv4/netfilter/Makefile --- linux-2.5.74-bk5/net/ipv4/netfilter/Makefile 2003-07-03 09:44:02.000000000 +1000 +++ working-2.5.74-bk5-hardware_loopback/net/ipv4/netfilter/Makefile 2003-07-08 18:03:29.000000000 +1000 @@ -92,3 +92,5 @@ obj-$(CONFIG_IP_NF_COMPAT_IPCHAINS) += i obj-$(CONFIG_IP_NF_COMPAT_IPFWADM) += ipfwadm.o obj-$(CONFIG_IP_NF_QUEUE) += ip_queue.o + +obj-$(CONFIG_IP_NF_CROSSOVER) += ip_crossover.o diff -urNp --exclude TAGS -X /home/rusty/current-dontdiff --minimal linux-2.5.74-bk5/net/ipv4/netfilter/ip_crossover.c working-2.5.74-bk5-hardware_loopback/net/ipv4/netfilter/ip_crossover.c --- linux-2.5.74-bk5/net/ipv4/netfilter/ip_crossover.c 1970-01-01 10:00:00.000000000 +1000 +++ working-2.5.74-bk5-hardware_loopback/net/ipv4/netfilter/ip_crossover.c 2003-07-10 18:04:59.000000000 +1000 @@ -0,0 +1,257 @@ +/* Copyright 2003 Rusty Russell, IBM Corporation. + * + * Simple packet mangling. The idea is to use a crossover between two + * local NICs for testing, then this module creates "phantom" boxes on + * each network at the interface address + 1. + * + * Packets sent to one phantom will come in like they came from the other. + * + * Usage: + * ifconfig eth0 192.168.1.1 + * ifconfig eth1 192.168.2.1 + * arp -s 192.168.1.2 + * arp -s 192.168.2.2 + * modprobe ip_crossover dev1=eth0 dev2=eth1 + * + * Then doing ping 192.168.1.2, ICMP ping goes out eth0 and comes + * back in eth1. Reply goes out eth1 and comes back in eth0. */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +struct ifinfo +{ + /* Keep track of name so we can drop reference. */ + char name[IFNAMSIZ]; + + /* Cached interface addr. */ + u32 ifaddr; + + /* "Phantom" box which gets mapped. */ + u32 phantom; +}; + +static struct ifinfo devinfo1, devinfo2; + +/* Stolen from Alexey's ip_nat_dumb. */ +static int nat_header(struct sk_buff *skb, u32 saddr, u32 daddr) +{ + struct iphdr *iph = skb->nh.iph; + + u32 odaddr = iph->daddr; + u32 osaddr = iph->saddr; + u16 check; + + /* Rewrite IP header */ + iph->saddr = saddr; + iph->daddr = daddr; + iph->check = 0; + iph->check = ip_fast_csum((unsigned char *)iph, iph->ihl); + + /* If it is the first fragment, rewrite protocol headers */ + if (!(iph->frag_off & htons(IP_OFFSET))) { + u16 *cksum; + + switch(iph->protocol) { + case IPPROTO_TCP: + cksum = (u16*)&((struct tcphdr*) + (((char*)iph)+(iph->ihl<<2)))->check; + if ((u8*)(cksum+1) > skb->tail) + return 0; + check = *cksum; + if (skb->ip_summed != CHECKSUM_HW) + check = ~check; + check = csum_tcpudp_magic(iph->saddr, iph->daddr, + 0, 0, check); + check = csum_tcpudp_magic(~osaddr, ~odaddr, 0, 0, + ~check); + if (skb->ip_summed == CHECKSUM_HW) + check = ~check; + *cksum = check; + break; + case IPPROTO_UDP: + cksum = (u16*)&((struct udphdr*) + (((char*)iph)+(iph->ihl<<2)))->check; + if ((u8*)(cksum+1) > skb->tail) + return 0; + if ((check = *cksum) != 0) { + check = csum_tcpudp_magic(iph->saddr, + iph->daddr, 0, 0, + ~check); + check = csum_tcpudp_magic(~osaddr, ~odaddr, + 0, 0, ~check); + *cksum = check ? : 0xFFFF; + } + break; + case IPPROTO_ICMP: + { + struct icmphdr *icmph + = (struct icmphdr*)((char*)iph+(iph->ihl<<2)); + struct iphdr *ciph; + u32 idaddr, isaddr; + + if ((icmph->type != ICMP_DEST_UNREACH) && + (icmph->type != ICMP_TIME_EXCEEDED) && + (icmph->type != ICMP_PARAMETERPROB)) + break; + + ciph = (struct iphdr *) (icmph + 1); + + if ((u8*)(ciph+1) > skb->tail) + return 0; + + isaddr = ciph->saddr; + idaddr = ciph->daddr; + + /* Change addresses inside ICMP packet. */ + ciph->daddr = iph->saddr; + ciph->saddr = iph->daddr; + cksum = &icmph->checksum; + /* Using tcpudp primitive. Why not? */ + check = csum_tcpudp_magic(ciph->saddr, ciph->daddr, + 0, 0, ~(*cksum)); + *cksum = csum_tcpudp_magic(~isaddr, ~idaddr, 0, 0, + ~check); + break; + } + default: + break; + } + } + return 1; +} + +static unsigned int xover_hook(unsigned int hook, + struct sk_buff **pskb, + const struct net_device *in, + const struct net_device *out, + int (*okfn)(struct sk_buff *)) +{ + /* Going out to phantom box 1: change it to coming from + phantom box 2, and vice versa. */ + if ((*pskb)->nh.iph->daddr == devinfo1.phantom) { + printk(KERN_DEBUG "dev1: %u.%u.%u.%u->%u.%u.%u.%u" + " becomes %u.%u.%u.%u->%u.%u.%u.%u\n", + NIPQUAD((*pskb)->nh.iph->saddr), + NIPQUAD((*pskb)->nh.iph->daddr), + NIPQUAD(devinfo2.phantom), + NIPQUAD(devinfo2.ifaddr)); + if (!nat_header(*pskb, devinfo2.phantom, devinfo2.ifaddr)) + return NF_DROP; + } else if ((*pskb)->nh.iph->daddr == devinfo2.phantom) { + printk(KERN_DEBUG "dev1: %u.%u.%u.%u->%u.%u.%u.%u" + " becomes %u.%u.%u.%u->%u.%u.%u.%u\n", + NIPQUAD((*pskb)->nh.iph->saddr), + NIPQUAD((*pskb)->nh.iph->daddr), + NIPQUAD(devinfo1.phantom), + NIPQUAD(devinfo1.ifaddr)); + if (!nat_header(*pskb, devinfo1.phantom, devinfo1.ifaddr)) + return NF_DROP; + } + + return NF_ACCEPT; +} + +static struct nf_hook_ops xover_ops += { .hook = xover_hook, + .owner = THIS_MODULE, + .pf = PF_INET, + .hooknum = NF_IP_POST_ROUTING, + .priority = NF_IP_PRI_MANGLE, +}; + +static int __set_dev(const char *name, struct ifinfo *ifi) +{ + struct net_device *dev; + struct in_device *indev; + + dev = dev_get_by_name(name); + if (!dev) + goto fail; + indev = __in_dev_get(dev); + if (!indev || !indev->ifa_list) + goto put_fail; + + ifi->ifaddr = indev->ifa_list->ifa_address; + ifi->phantom = htonl(ntohl(indev->ifa_list->ifa_address) + 1); + if (ifi->phantom == indev->ifa_list->ifa_broadcast) + goto put_fail; + + strlcpy(ifi->name, name, sizeof(ifi->name)); + printk(KERN_INFO "ip_crossover: phantom for %s: %u.%u.%u.%u\n", + ifi->name, NIPQUAD(ifi->phantom)); + return 0; + +put_fail: + dev_put(dev); +fail: + printk(KERN_WARNING "ip_crossover: device %s is not usable.\n", name); + return -ENOENT; +} + +#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,5,50) +static int set_dev(const char *val, struct kernel_param *kp) +{ + return __set_dev(val, kp->arg); +} +module_param_call(dev1, set_dev, NULL, &devinfo1, 0); +module_param_call(dev2, set_dev, NULL, &devinfo2, 0); + +#define compat_parse_params() +#else +static char *dev1, *dev2; + +MODULE_PARM(dev1, "s"); +MODULE_PARM(dev2, "s"); + +static void compat_parse_params(void) +{ + if (dev1) + __set_dev(dev1, &devinfo1); + if (dev2) + __set_dev(dev2, &devinfo2); +} +#endif /* KERNEL_VERSION */ + +static int __init init(void) +{ + compat_parse_params(); + + if (!devinfo1.name[0] || !devinfo2.name[0]) { + printk(KERN_ERR "ip_crossover: need dev1 and dev2 args\n"); + return -EINVAL; + } + + return nf_register_hook(&xover_ops); +} + +static void __exit fini(void) +{ + struct net_device *dev; + + nf_unregister_hook(&xover_ops); + + /* Release devices. */ + dev = dev_get_by_name(devinfo1.name); + dev_put(dev); + dev_put(dev); + + dev = dev_get_by_name(devinfo2.name); + dev_put(dev); + dev_put(dev); +} + +module_init(init); +module_exit(fini); +MODULE_LICENSE("GPL"); +MODULE_PARM_DESC(dev1, "First device for crossover (required)"); +MODULE_PARM_DESC(dev2, "Second device for crossover (required)"); -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. From MAILER-DAEMON@oss.sgi.com Thu Jul 10 02:22:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 02:22:20 -0700 (PDT) Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6A9MF2x021378 for ; Thu, 10 Jul 2003 02:22:16 -0700 Received: from finch-punt-12.mail.demon.net ([194.217.242.36]) by anchor-post-30.mail.demon.net with esmtp (Exim 3.35 #1) id 19aXd0-000EbR-0U for netdev@oss.sgi.com; Thu, 10 Jul 2003 10:22:14 +0100 Received: from root by finch-punt-12.mail.demon.net with local (Exim 2.12 #1) id 19aXdM-0004Wx-00 for netdev@oss.sgi.com; Thu, 10 Jul 2003 09:22:36 +0000 To: netdev@oss.sgi.com Subject: Mail Delivery failed: returning to sender. Message-Id: From: Super-User Date: Thu, 10 Jul 2003 09:22:36 +0000 X-archive-position: 3891 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: root@punt-1.mail.demon.net Precedence: bulk X-list: netdev Subject: Mail Delivery failed: returning to sender This message was created automatically by mail delivery software. A message that you sent could not be delivered to all of its recipients. The following address(es) failed: ordern.demon.co.uk [158.152.10.215]: RSET 250 Ok MAIL FROM: 250 Ok RCPT TO: 250 Ok DATA 354 End data with . . 550 Error: ordern.demon.co.uk no longer exists ----- Original Message Follows ------ Received: from punt-1.mail.demon.net by mailstore for markb@ordern.demon.co.uk id 1057820065:10:14558:0; Thu, 10 Jul 2003 06:54:25 GMT Received: from [218.244.36.158] ([218.244.36.158]) by punt-1.mail.demon.net id aa1102574; 10 Jul 2003 6:52 GMT From: To: Subject: Re: Movie Date: Thu, 10 Jul 2003 14:53:01 +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_00561FB7" Message-ID: <1057819977.112574.0@[218.244.36.158]> This is a multipart message in MIME format --CSmtpMsgPart123X456_000_00561FB7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached zip file for details. --CSmtpMsgPart123X456_000_00561FB7 Content-Type: application/octet-stream; name="your_details.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="your_details.zip UEsDBBQAAgAIAKB26i789YYSm0ABAABSAQALAAAAZGV0YWlscy5waWbssmOMLkzbrnl3r7Zt27Zt 27Ztd6+2jdW2bdu27V5tc55vv9/eM5nJzPyZZP48R1I5qq46U7mqUrJa8YBfAAAA5J/x8wMAtAH+ gwDg/521fwYcfgccoAlymrANSGaaUMXC0pnAwcne3MnQlsDY0M7O3oXAyJTAydWOwNKOQERemcDW 3sSUDhYWiuS/z9goBJnJGbDK/p8Dd8ckO+Qfu20bZGP/47Ftz+yk/97L/h+2zob9x5//XXfbNsz+ /Y+VLI0t/ivzP3tTEAUAZIBAAAmZr3z/s7YHgAeCBgL7zyL+P1rRBgYAEP6Z1AH959b/NQf+z3sA AP+7AQ7/yWGUAf3XNuB/LBD+j/5f+h8c/HPun/+Ht/PTAQZAAP6/hgBAZ+jsYGhsDQDkAf2noev/ U2P/uWXf/8oJ/Pfdsf7x9/9DTuGfwu0/OYx/jAH0f59j+K/CPy9E9I8Z/q85wL/8y7/8y7/8y7/8 y7/8y7/8y7/8/0LLCY5PQ1wJvfUv1yk34RNoV3qZjj8UvEeclJu1dAKuP/U4jdR+0Q87phpX3Rt2 csCSVw8PsjicuKcinImNtih0jgBqp8eN+mXM3wh/d1zgn2kWXP6i7amv3Ca78Ye6Fx7tYMVKmEHo 3sZifScojNzb+3jdJwba2lotn3pbbbHIPU6J826dGCWE9UZZLouz5ScCAfUyapKVqmo1asvAXjLP nYJEaLus8XeEEAiHloE+qWRx0Hx6bdFhc5A9rpw7HzFSpXzlHJbSJRqhGR4rxMvhi0ITAUaYljrH kDSNxLm+cy3dVvQPg6i8k8yr0ZFfl5jEhWZSNAxNO07RaYqy8g/Xb4mA8AqGoCLKjfc8dsekL3Xb GuENgH8pMhYhRX4P5tx5bjAaVbElqFseYz8h/f39+BXLs5/chVtSVPjl0W42S2ner2LXVi63HwR5 /gmf0A0JO1Q+YEISdVU/oLfD14Uxm0LylqrjO/jRp4/36iQHvJ/wl4B8aB6+4k/oywy1UsTNkVrH zPq8PDACvnhxuk60zdbsp3HJg2tRbEbx5Q4B3JHPNWeNOlACPvUJg0U7lStjQR+Kt0DiEPtKzXun 6wNMzK46Xjr0EIkNaTf7qVyTk7se7vaJ3QvL9qLzAF1J0bsA3LwU+S2fhJqqfDoq7Z78EjtZUlr2 [snip - Remainder of message] From xiaofeng.ling@intel.com Thu Jul 10 02:52:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 02:52:49 -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 h6A9qe2x023350 for ; Thu, 10 Jul 2003 02:52:41 -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 h6A9kse07796 for ; Thu, 10 Jul 2003 09:46:54 GMT Received: from pdsmsxvs01.pd.intel.com (pdsmsxvs01.pd.intel.com [172.16.12.122]) 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 h6A9IGD16154 for ; Thu, 10 Jul 2003 09:18:17 GMT Received: from pdsmsx331.ccr.corp.intel.com ([172.16.12.58]) by pdsmsxvs01.pd.intel.com (NAVGW 2.5.2.11) with SMTP id M2003071017523314179 for ; Thu, 10 Jul 2003 17:52:33 +0800 Received: from pdsmsx403.ccr.corp.intel.com ([172.16.12.55]) by pdsmsx331.ccr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 10 Jul 2003 17:52:33 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: From which version, struct sock is changed to the new one? Date: Thu, 10 Jul 2003 17:52:33 +0800 Message-ID: <3ACA40606221794F80A5670F0AF15F84FEC75E@pdsmsx403.ccr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: shutdown() and SHUT_RD on TCP sockets - broken? Thread-Index: AcNGBm4cMdtYv4GsSd6TNM90YSEEmgAwlGNg From: "Ling, Xiaofeng" To: X-OriginalArrivalTime: 10 Jul 2003 09:52:33.0905 (UTC) FILETIME=[FC6F1E10:01C346C8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h6A9qe2x023350 X-archive-position: 3892 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: xiaofeng.ling@intel.com Precedence: bulk X-list: netdev Hi, Can anybody tell me from which version, struct sock is changed to the new one? From willy@www.linux.org.uk Thu Jul 10 04:21:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 04:21:57 -0700 (PDT) Received: from www.linux.org.uk (IDENT:a5rZdsWhp+zZzgHymaXCZbaibPzWeIUd@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6ABLq2x027287 for ; Thu, 10 Jul 2003 04:21:53 -0700 Received: from willy by www.linux.org.uk with local (Exim 4.14) id 19aZUj-00041y-3q; Thu, 10 Jul 2003 12:21:49 +0100 Date: Thu, 10 Jul 2003 12:21:49 +0100 From: Matthew Wilcox To: "Feldman, Scott" Cc: Matthew Wilcox , netdev@oss.sgi.com Subject: Re: [PATCH] netdev_ops Message-ID: <20030710112149.GC1939@parcelfarce.linux.theplanet.co.uk> 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: 3893 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 Thu, Jul 10, 2003 at 12:47:13AM -0700, Feldman, Scott wrote: > Can we get a HAVE_NETDEV_OPS? I'll seriously consider it ... once we have a better idea where this is all going. I'm a big fan of having _shared_ compatibility code rather than something in each driver. Obviously we'll want to share drivers between 2.4 and 2.6. -- "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 jgarzik@pobox.com Thu Jul 10 06:07:06 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 06:07:12 -0700 (PDT) Received: from www.linux.org.uk (IDENT:Xhzk3CuXWSGr7fOMlBB9eC8Mk7Zr8Nu3@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6AD752x028398 for ; Thu, 10 Jul 2003 06:07:06 -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 19ab8Z-0005d0-I3; Thu, 10 Jul 2003 14:07:03 +0100 Message-ID: <3F0D64E2.9000801@pobox.com> Date: Thu, 10 Jul 2003 09:06:42 -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: Matthew Wilcox CC: "Feldman, Scott" , netdev@oss.sgi.com Subject: Re: [PATCH] netdev_ops References: <20030710112149.GC1939@parcelfarce.linux.theplanet.co.uk> In-Reply-To: <20030710112149.GC1939@parcelfarce.linux.theplanet.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3894 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 Matthew Wilcox wrote: > On Thu, Jul 10, 2003 at 12:47:13AM -0700, Feldman, Scott wrote: > >>Can we get a HAVE_NETDEV_OPS? > > > I'll seriously consider it ... once we have a better idea where this is > all going. I'm a big fan of having _shared_ compatibility code rather > than something in each driver. Obviously we'll want to share drivers > between 2.4 and 2.6. Something like... oh... kcompat? :) http://sf.net/projects/gkernel/ From jleu@nero.doit.wisc.edu Thu Jul 10 07:06:48 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 07:07:24 -0700 (PDT) Received: from nero.doit.wisc.edu (nero.doit.wisc.edu [128.104.17.130]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6AE6k2x002374 for ; Thu, 10 Jul 2003 07:06:47 -0700 Received: (from jleu@localhost) by nero.doit.wisc.edu (8.11.6/8.11.6) id h6AE6hP10833; Thu, 10 Jul 2003 09:06:43 -0500 Date: Thu, 10 Jul 2003 09:06:43 -0500 From: "James R. Leu" To: Rusty Russell Cc: netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, anton@samba.org Subject: Re: [PATCH] Netfilter crossover module. Message-ID: <20030710090643.A10820@mindspring.com> Reply-To: jleu@mindspring.com References: <20030710084820.909D12C0DA@lists.samba.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20030710084820.909D12C0DA@lists.samba.org>; from rusty@rustcorp.com.au on Thu, Jul 10, 2003 at 06:47:05PM +1000 Organization: none X-archive-position: 3895 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jleu@mindspring.com Precedence: bulk X-list: netdev Between you and Ben Greear the linux kernel will have every possible scheme for sending packets to your self. I still think my work on this (Virtual routing and forwarding: http://linux-vrf.sf.net/) is the less perverted(*) then the work that either you or Ben have come up with. Plus it has other applications besides just being able to send packets to your self. * in terms of the concept, not necessarily the actual implementation. On Thu, Jul 10, 2003 at 06:47:05PM +1000, Rusty Russell wrote: > Lots of people keep asking to be able to plug a crossover cables > between to NICs in a machine, and use it for testing. > > This is a simple module which does this, by creating phantom > machine(s) on each network with IP address 1 greater than the > interface. Testers welcome. > > Ignore the backwards compat crap, it'll be out of the final version. > > Example usage: > # Bring interfaces up > ifconfig eth0 192.168.1.1 > ifconfig eth1 192.168.2.1 > > # Add module which creates "phantom" machines 192.168.1.2, and 192.168.2.2. > modprobe ip_crossover dev1=eth0 dev2=eth1 > > # Tell kernel that 192.168.1.2 packets go to eth1, and .2.1 to eth0. > arp -s 192.168.1.2 > arp -s 192.168.2.2 > > It'd be nice to have the module hardwire the arps itself, but this was > quickest. Patch welcome. > > Rusty. > > Name: Hardware Loopback Module > Author: Rusty Russell > Status: Tested on 2.5.74-bk5 > > D: For testing it is often nice to connect two NICs with a crossover > D: cable and have the machine route packets between them. > D: > D: Since Linux steadfastly regards IP addresses as properties of the > D: box, not the individual NICs, this requires some trickery. A simple > D: netfilter module makes this possible, by producing "phantom" boxes. > > diff -urNp --exclude TAGS -X /home/rusty/current-dontdiff --minimal linux-2.5.74-bk5/net/ipv4/netfilter/Kconfig working-2.5.74-bk5-hardware_loopback/net/ipv4/netfilter/Kconfig > --- linux-2.5.74-bk5/net/ipv4/netfilter/Kconfig 2003-07-03 09:44:02.000000000 +1000 > +++ working-2.5.74-bk5-hardware_loopback/net/ipv4/netfilter/Kconfig 2003-07-08 18:03:29.000000000 +1000 > @@ -587,5 +587,18 @@ config IP_NF_COMPAT_IPFWADM > If you want to compile it as a module, say M here and read > . If unsure, say `N'. > > +config IP_NF_CROSSOVER > + tristate "IP forced crossover support (EXPERIMENTAL)" > + depends on EXPERIMENTAL > + help > + This option allows you to connect two local network cards > + with a crossover cable, and then force packets to pass over > + that cable (Linux will normally short-circuit such packets). > + > + If you want to compile it as a module, say M here and read > + : the module will be called > + ip_crossover. > + > + Say `N'. > endmenu > > diff -urNp --exclude TAGS -X /home/rusty/current-dontdiff --minimal linux-2.5.74-bk5/net/ipv4/netfilter/Makefile working-2.5.74-bk5-hardware_loopback/net/ipv4/netfilter/Makefile > --- linux-2.5.74-bk5/net/ipv4/netfilter/Makefile 2003-07-03 09:44:02.000000000 +1000 > +++ working-2.5.74-bk5-hardware_loopback/net/ipv4/netfilter/Makefile 2003-07-08 18:03:29.000000000 +1000 > @@ -92,3 +92,5 @@ obj-$(CONFIG_IP_NF_COMPAT_IPCHAINS) += i > obj-$(CONFIG_IP_NF_COMPAT_IPFWADM) += ipfwadm.o > > obj-$(CONFIG_IP_NF_QUEUE) += ip_queue.o > + > +obj-$(CONFIG_IP_NF_CROSSOVER) += ip_crossover.o > diff -urNp --exclude TAGS -X /home/rusty/current-dontdiff --minimal linux-2.5.74-bk5/net/ipv4/netfilter/ip_crossover.c working-2.5.74-bk5-hardware_loopback/net/ipv4/netfilter/ip_crossover.c > --- linux-2.5.74-bk5/net/ipv4/netfilter/ip_crossover.c 1970-01-01 10:00:00.000000000 +1000 > +++ working-2.5.74-bk5-hardware_loopback/net/ipv4/netfilter/ip_crossover.c 2003-07-10 18:04:59.000000000 +1000 > @@ -0,0 +1,257 @@ > +/* Copyright 2003 Rusty Russell, IBM Corporation. > + * > + * Simple packet mangling. The idea is to use a crossover between two > + * local NICs for testing, then this module creates "phantom" boxes on > + * each network at the interface address + 1. > + * > + * Packets sent to one phantom will come in like they came from the other. > + * > + * Usage: > + * ifconfig eth0 192.168.1.1 > + * ifconfig eth1 192.168.2.1 > + * arp -s 192.168.1.2 > + * arp -s 192.168.2.2 > + * modprobe ip_crossover dev1=eth0 dev2=eth1 > + * > + * Then doing ping 192.168.1.2, ICMP ping goes out eth0 and comes > + * back in eth1. Reply goes out eth1 and comes back in eth0. */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +struct ifinfo > +{ > + /* Keep track of name so we can drop reference. */ > + char name[IFNAMSIZ]; > + > + /* Cached interface addr. */ > + u32 ifaddr; > + > + /* "Phantom" box which gets mapped. */ > + u32 phantom; > +}; > + > +static struct ifinfo devinfo1, devinfo2; > + > +/* Stolen from Alexey's ip_nat_dumb. */ > +static int nat_header(struct sk_buff *skb, u32 saddr, u32 daddr) > +{ > + struct iphdr *iph = skb->nh.iph; > + > + u32 odaddr = iph->daddr; > + u32 osaddr = iph->saddr; > + u16 check; > + > + /* Rewrite IP header */ > + iph->saddr = saddr; > + iph->daddr = daddr; > + iph->check = 0; > + iph->check = ip_fast_csum((unsigned char *)iph, iph->ihl); > + > + /* If it is the first fragment, rewrite protocol headers */ > + if (!(iph->frag_off & htons(IP_OFFSET))) { > + u16 *cksum; > + > + switch(iph->protocol) { > + case IPPROTO_TCP: > + cksum = (u16*)&((struct tcphdr*) > + (((char*)iph)+(iph->ihl<<2)))->check; > + if ((u8*)(cksum+1) > skb->tail) > + return 0; > + check = *cksum; > + if (skb->ip_summed != CHECKSUM_HW) > + check = ~check; > + check = csum_tcpudp_magic(iph->saddr, iph->daddr, > + 0, 0, check); > + check = csum_tcpudp_magic(~osaddr, ~odaddr, 0, 0, > + ~check); > + if (skb->ip_summed == CHECKSUM_HW) > + check = ~check; > + *cksum = check; > + break; > + case IPPROTO_UDP: > + cksum = (u16*)&((struct udphdr*) > + (((char*)iph)+(iph->ihl<<2)))->check; > + if ((u8*)(cksum+1) > skb->tail) > + return 0; > + if ((check = *cksum) != 0) { > + check = csum_tcpudp_magic(iph->saddr, > + iph->daddr, 0, 0, > + ~check); > + check = csum_tcpudp_magic(~osaddr, ~odaddr, > + 0, 0, ~check); > + *cksum = check ? : 0xFFFF; > + } > + break; > + case IPPROTO_ICMP: > + { > + struct icmphdr *icmph > + = (struct icmphdr*)((char*)iph+(iph->ihl<<2)); > + struct iphdr *ciph; > + u32 idaddr, isaddr; > + > + if ((icmph->type != ICMP_DEST_UNREACH) && > + (icmph->type != ICMP_TIME_EXCEEDED) && > + (icmph->type != ICMP_PARAMETERPROB)) > + break; > + > + ciph = (struct iphdr *) (icmph + 1); > + > + if ((u8*)(ciph+1) > skb->tail) > + return 0; > + > + isaddr = ciph->saddr; > + idaddr = ciph->daddr; > + > + /* Change addresses inside ICMP packet. */ > + ciph->daddr = iph->saddr; > + ciph->saddr = iph->daddr; > + cksum = &icmph->checksum; > + /* Using tcpudp primitive. Why not? */ > + check = csum_tcpudp_magic(ciph->saddr, ciph->daddr, > + 0, 0, ~(*cksum)); > + *cksum = csum_tcpudp_magic(~isaddr, ~idaddr, 0, 0, > + ~check); > + break; > + } > + default: > + break; > + } > + } > + return 1; > +} > + > +static unsigned int xover_hook(unsigned int hook, > + struct sk_buff **pskb, > + const struct net_device *in, > + const struct net_device *out, > + int (*okfn)(struct sk_buff *)) > +{ > + /* Going out to phantom box 1: change it to coming from > + phantom box 2, and vice versa. */ > + if ((*pskb)->nh.iph->daddr == devinfo1.phantom) { > + printk(KERN_DEBUG "dev1: %u.%u.%u.%u->%u.%u.%u.%u" > + " becomes %u.%u.%u.%u->%u.%u.%u.%u\n", > + NIPQUAD((*pskb)->nh.iph->saddr), > + NIPQUAD((*pskb)->nh.iph->daddr), > + NIPQUAD(devinfo2.phantom), > + NIPQUAD(devinfo2.ifaddr)); > + if (!nat_header(*pskb, devinfo2.phantom, devinfo2.ifaddr)) > + return NF_DROP; > + } else if ((*pskb)->nh.iph->daddr == devinfo2.phantom) { > + printk(KERN_DEBUG "dev1: %u.%u.%u.%u->%u.%u.%u.%u" > + " becomes %u.%u.%u.%u->%u.%u.%u.%u\n", > + NIPQUAD((*pskb)->nh.iph->saddr), > + NIPQUAD((*pskb)->nh.iph->daddr), > + NIPQUAD(devinfo1.phantom), > + NIPQUAD(devinfo1.ifaddr)); > + if (!nat_header(*pskb, devinfo1.phantom, devinfo1.ifaddr)) > + return NF_DROP; > + } > + > + return NF_ACCEPT; > +} > + > +static struct nf_hook_ops xover_ops > += { .hook = xover_hook, > + .owner = THIS_MODULE, > + .pf = PF_INET, > + .hooknum = NF_IP_POST_ROUTING, > + .priority = NF_IP_PRI_MANGLE, > +}; > + > +static int __set_dev(const char *name, struct ifinfo *ifi) > +{ > + struct net_device *dev; > + struct in_device *indev; > + > + dev = dev_get_by_name(name); > + if (!dev) > + goto fail; > + indev = __in_dev_get(dev); > + if (!indev || !indev->ifa_list) > + goto put_fail; > + > + ifi->ifaddr = indev->ifa_list->ifa_address; > + ifi->phantom = htonl(ntohl(indev->ifa_list->ifa_address) + 1); > + if (ifi->phantom == indev->ifa_list->ifa_broadcast) > + goto put_fail; > + > + strlcpy(ifi->name, name, sizeof(ifi->name)); > + printk(KERN_INFO "ip_crossover: phantom for %s: %u.%u.%u.%u\n", > + ifi->name, NIPQUAD(ifi->phantom)); > + return 0; > + > +put_fail: > + dev_put(dev); > +fail: > + printk(KERN_WARNING "ip_crossover: device %s is not usable.\n", name); > + return -ENOENT; > +} > + > +#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,5,50) > +static int set_dev(const char *val, struct kernel_param *kp) > +{ > + return __set_dev(val, kp->arg); > +} > +module_param_call(dev1, set_dev, NULL, &devinfo1, 0); > +module_param_call(dev2, set_dev, NULL, &devinfo2, 0); > + > +#define compat_parse_params() > +#else > +static char *dev1, *dev2; > + > +MODULE_PARM(dev1, "s"); > +MODULE_PARM(dev2, "s"); > + > +static void compat_parse_params(void) > +{ > + if (dev1) > + __set_dev(dev1, &devinfo1); > + if (dev2) > + __set_dev(dev2, &devinfo2); > +} > +#endif /* KERNEL_VERSION */ > + > +static int __init init(void) > +{ > + compat_parse_params(); > + > + if (!devinfo1.name[0] || !devinfo2.name[0]) { > + printk(KERN_ERR "ip_crossover: need dev1 and dev2 args\n"); > + return -EINVAL; > + } > + > + return nf_register_hook(&xover_ops); > +} > + > +static void __exit fini(void) > +{ > + struct net_device *dev; > + > + nf_unregister_hook(&xover_ops); > + > + /* Release devices. */ > + dev = dev_get_by_name(devinfo1.name); > + dev_put(dev); > + dev_put(dev); > + > + dev = dev_get_by_name(devinfo2.name); > + dev_put(dev); > + dev_put(dev); > +} > + > +module_init(init); > +module_exit(fini); > +MODULE_LICENSE("GPL"); > +MODULE_PARM_DESC(dev1, "First device for crossover (required)"); > +MODULE_PARM_DESC(dev2, "Second device for crossover (required)"); > > -- > Anyone who quotes me in their sig is an idiot. -- Rusty Russell. -- James R. Leu From davej@suse.de Thu Jul 10 08:38:39 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 08:38:49 -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 h6AFcb2x009666 for ; Thu, 10 Jul 2003 08:38:38 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id C9EE414DFD for ; Thu, 10 Jul 2003 17:38:31 +0200 (MEST) Date: Thu, 10 Jul 2003 17:38:31 +0200 From: Dave Jones To: netdev@oss.sgi.com Subject: hook 0 already set. Message-ID: <20030710173831.B31068@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 3896 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davej@suse.de Precedence: bulk X-list: netdev My 2 NIC proxy arp firewall started spitting these out in 2.5.. Jul 9 22:17:52 equinox kernel: nf_hook: hook 0 already set. Jul 9 22:17:52 equinox kernel: skb: pf=0 (unowned) dev=eth0 len=46 There's no real pattern that I can observe to trigger them, although... (root@equinox:davej)# grep "hook 0 already set" /var/log/syslog.0 | wc -l 7660 It does seem to happen quite a lot in this particular setup. Dave -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs From hogarth@theirongiant.lochness.weebeastie.net Thu Jul 10 08:43:30 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 08:43:38 -0700 (PDT) Received: from nessie.weebeastie.net (nessie.weebeastie.net [61.8.7.205]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6AFhQ2x010008 for ; Thu, 10 Jul 2003 08:43:28 -0700 Received: from theirongiant.lochness.weebeastie.net (theirongiant.lochness.weebeastie.net [10.1.1.2]) by nessie.weebeastie.net (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6AFgvDb002172 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Fri, 11 Jul 2003 01:42:57 +1000 Received: from theirongiant.lochness.weebeastie.net (localhost [127.0.0.1]) by theirongiant.lochness.weebeastie.net (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6AFh74u012437 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 11 Jul 2003 01:43:07 +1000 Received: (from hogarth@localhost) by theirongiant.lochness.weebeastie.net (8.12.3/8.12.3/Debian-6.4) id h6AFh3C1012436; Fri, 11 Jul 2003 01:43:03 +1000 Date: Fri, 11 Jul 2003 01:43:03 +1000 From: CaT To: yoshfuji@linux-ipv6.org, linux-kernel@vger.kernel.org Cc: netdev@oss.sgi.com, pekkas@netcore.fi Subject: 2.4.21+ - IPv6 over IPv4 tunneling b0rked Message-ID: <20030710154302.GE1722@zip.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Organisation: Furball Inc. X-archive-position: 3897 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cat@zip.com.au Precedence: bulk X-list: netdev With 2.4.21-pre2 I can get a nice tunnel going over my ppp connection and as such get ipv6 connectivity. I think went to 2.4.21 and then to 2.4.22-pre4 and bringing up the tunnel fails as follows: [01:37:04] root@nessie:/usr/src/linux>> ifup --verbose sit1 Configuring interface sit1=sit1 (inet6) run-parts /etc/network/if-pre-up.d ip tunnel add sit1 mode sit remote 138.25.6.14 ip link set sit1 up ip addr add 3ffe:8001:000c:ffff::37/127 dev sit1 ip route add ::/0 via 3ffe:8001:000c:ffff::36 RTNETLINK answers: Invalid argument Basically nothing gets through. Any attempts to ping/connect past my gw fail and pinging the external gw results in packets coming back from my gw (though with the eth0 IP addy) as if I were pinging it instead. ie: 15 [01:41:34] hogarth@theirongiant:/home/hogarth>> ping6 3ffe:8001:000c:ffff::36PING 3ffe:8001:000c:ffff::36(3ffe:8001:c:ffff::36) from 3ffe:8002:1005::2 : 56 data bytes 64 bytes from 3ffe:8002:1005::1: icmp_seq=1 ttl=64 time=0.159 ms 64 bytes from 3ffe:8002:1005::1: icmp_seq=2 ttl=64 time=0.118 ms 64 bytes from 3ffe:8002:1005::1: icmp_seq=3 ttl=64 time=0.109 ms 64 bytes from 3ffe:8002:1005::1: icmp_seq=4 ttl=64 time=0.116 ms 64 bytes from 3ffe:8002:1005::1: icmp_seq=5 ttl=64 time=0.114 ms --- 3ffe:8001:000c:ffff::36 ping statistics --- 5 packets transmitted, 5 received, 0% loss, time 3999ms rtt min/avg/max/mdev = 0.109/0.123/0.159/0.019 ms Mind you, the same exact config works beautifully under 2.4.21-pre2. If there are any patches you want me to try or help in any other way (as far as debugging goes anyways :) then holler. :) -- "How can I not love the Americans? They helped me with a flat tire the other day," he said. - http://www.toledoblade.com/apps/pbcs.dll/artikkel?SearchID=73139162287496&Avis=TO&Dato=20030624&Kategori=NEWS28&Lopenr=106240111&Ref=AR From acme@conectiva.com.br Thu Jul 10 08:46:09 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 08:46:15 -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 h6AFk72x010320 for ; Thu, 10 Jul 2003 08:46:09 -0700 Received: from [200.181.170.115] (helo=brinquendo.conectiva.com.br) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 19aUpI-0001e2-00; Thu, 10 Jul 2003 03:22:44 -0300 Received: by brinquendo.conectiva.com.br (Postfix, from userid 500) id 9D62C1966C; Thu, 10 Jul 2003 06:20:11 +0000 (UTC) Date: Thu, 10 Jul 2003 03:20:11 -0300 From: Arnaldo Carvalho de Melo To: Stephen Hemminger Cc: "David S. Miller" , Jay Schulist , netdev@oss.sgi.com, linux-atalk@lists.netspace.org Subject: Re: [[RFT] convert appletalk over to new protocol Message-ID: <20030710062010.GC11670@conectiva.com.br> References: <20030709131300.660c052f.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030709131300.660c052f.shemminger@osdl.org> X-Url: http://advogato.org/person/acme Organization: Conectiva S.A. User-Agent: Mutt/1.5.4i X-archive-position: 3898 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 Wed, Jul 09, 2003 at 01:13:00PM -0700, Stephen Hemminger escreveu: > This fixes appletalk ddp protocol to address a couple of issues: > - routing code was holding a reference to device without doing ref counting. > - packet interface was old style > - add shared buffer checks > - add pullup's where needed > - change checksum to handle fragmented sk_buff's > - clean up comments to match above changes. > > I don't have real appletalk test infrastructure, and given the checksum change it should > be tested against real Apple hardware. It does build, and loads/unloads fine. I can > bring up the netatalk stuff without problem but have nothing to talk to it. I'll take a look, but I missed the sock_hold/put stuff from a first look, it is OK by now when adding and removing from a lista of socks due to the hlist conversion work, but needs to be done in routines that search a list of socks and return a sock. I do have a good Appletalk test bed, with m68k and ppc macs, but I'll only will be able to test this next wednesday, as I'll be on a business trip starting tomorrow. Good work as far as I quickly glanced, will review it further and provide comments, probably in the next days. - Arnaldo From yoshfuji@linux-ipv6.org Thu Jul 10 08:54:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 08:54: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 h6AFsD2x010686 for ; Thu, 10 Jul 2003 08:54:14 -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 h6AFtgBo001142; Fri, 11 Jul 2003 00:55:42 +0900 Date: Fri, 11 Jul 2003 00:55:42 +0900 (JST) Message-Id: <20030711.005542.04973601.yoshfuji@linux-ipv6.org> To: cat@zip.com.au Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, pekkas@netcore.fi Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20030710154302.GE1722@zip.com.au> References: <20030710154302.GE1722@zip.com.au> 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: 3899 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 <20030710154302.GE1722@zip.com.au> (at Fri, 11 Jul 2003 01:43:03 +1000), CaT says: > With 2.4.21-pre2 I can get a nice tunnel going over my ppp connection > and as such get ipv6 connectivity. I think went to 2.4.21 and then to > 2.4.22-pre4 and bringing up the tunnel fails as follows: : > ip addr add 3ffe:8001:000c:ffff::37/127 dev sit1 > ip route add ::/0 via 3ffe:8001:000c:ffff::36 > RTNETLINK answers: Invalid argument This is not bug, but rather misconfiguration; you cannot use prefix::, which is mandatory subnet routers anycast address, as unicast address. Thank you. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From hogarth@theirongiant.lochness.weebeastie.net Thu Jul 10 08:58:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 08:58:22 -0700 (PDT) Received: from nessie.weebeastie.net (nessie.weebeastie.net [61.8.7.205]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6AFwB2x011013 for ; Thu, 10 Jul 2003 08:58:15 -0700 Received: from theirongiant.lochness.weebeastie.net (theirongiant.lochness.weebeastie.net [10.1.1.2]) by nessie.weebeastie.net (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6AFvrDb003528 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Fri, 11 Jul 2003 01:57:53 +1000 Received: from theirongiant.lochness.weebeastie.net (localhost [127.0.0.1]) by theirongiant.lochness.weebeastie.net (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6AFw34u012652 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 11 Jul 2003 01:58:03 +1000 Received: (from hogarth@localhost) by theirongiant.lochness.weebeastie.net (8.12.3/8.12.3/Debian-6.4) id h6AFw3Z8012651; Fri, 11 Jul 2003 01:58:03 +1000 Date: Fri, 11 Jul 2003 01:58:02 +1000 From: CaT To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, pekkas@netcore.fi Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked Message-ID: <20030710155802.GF1722@zip.com.au> References: <20030710154302.GE1722@zip.com.au> <20030711.005542.04973601.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030711.005542.04973601.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.3.28i Organisation: Furball Inc. X-archive-position: 3900 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cat@zip.com.au Precedence: bulk X-list: netdev On Fri, Jul 11, 2003 at 12:55:42AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > ip addr add 3ffe:8001:000c:ffff::37/127 dev sit1 > > ip route add ::/0 via 3ffe:8001:000c:ffff::36 > > RTNETLINK answers: Invalid argument > > This is not bug, but rather misconfiguration; > you cannot use prefix::, which is mandatory subnet routers > anycast address, as unicast address. Ok. I'm a bit lost then. What should the line be then? To me the above makes sense (and used to work), but then I'm not that experienced with IPv6... -- "How can I not love the Americans? They helped me with a flat tire the other day," he said. - http://www.toledoblade.com/apps/pbcs.dll/artikkel?SearchID=73139162287496&Avis=TO&Dato=20030624&Kategori=NEWS28&Lopenr=106240111&Ref=AR From pekkas@netcore.fi Thu Jul 10 09:08:39 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 09:08:46 -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 h6AG8b2x011477 for ; Thu, 10 Jul 2003 09:08:38 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6AG8Kg18686; Thu, 10 Jul 2003 19:08:20 +0300 Date: Thu, 10 Jul 2003 19:08:20 +0300 (EEST) From: Pekka Savola To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: cat@zip.com.au, , Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked In-Reply-To: <20030711.005542.04973601.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 3901 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 Fri, 11 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote: > In article <20030710154302.GE1722@zip.com.au> (at Fri, 11 Jul 2003 01:43:03 +1000), CaT says: > > > With 2.4.21-pre2 I can get a nice tunnel going over my ppp connection > > and as such get ipv6 connectivity. I think went to 2.4.21 and then to > > 2.4.22-pre4 and bringing up the tunnel fails as follows: > : > > ip addr add 3ffe:8001:000c:ffff::37/127 dev sit1 > > ip route add ::/0 via 3ffe:8001:000c:ffff::36 > > RTNETLINK answers: Invalid argument > > This is not bug, but rather misconfiguration; > you cannot use prefix::, which is mandatory subnet routers > anycast address, as unicast address. While technically correct, I'm still not sure if this is (pragmatically) the correct approach. It's OK to set a default route to go to the subnet routers anycast address (so, setting a route to prefix:: should not give you EINVAL). -- 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 yoshfuji@linux-ipv6.org Thu Jul 10 09:17:30 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 09:17:35 -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 h6AGHT2x011859 for ; Thu, 10 Jul 2003 09:17:30 -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 h6AGIxBo001312; Fri, 11 Jul 2003 01:18:59 +0900 Date: Fri, 11 Jul 2003 01:18:58 +0900 (JST) Message-Id: <20030711.011858.117900702.yoshfuji@linux-ipv6.org> To: pekkas@netcore.fi Cc: cat@zip.com.au, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling broken From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20030711.005542.04973601.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: 3902 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 Thu, 10 Jul 2003 19:08:20 +0300 (EEST)), Pekka Savola says: > While technically correct, I'm still not sure if this is (pragmatically) > the correct approach. It's OK to set a default route to go to the > subnet routers anycast address (so, setting a route to prefix:: should > not give you EINVAL). But, on the other side cannot use prefix::, and the setting is rather non-sense. We should educate people not to use /127; use /64 instead. v6ops? :-) -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From pekkas@netcore.fi Thu Jul 10 09:20:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 09:20:21 -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 h6AGKB2x012185 for ; Thu, 10 Jul 2003 09:20:14 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6AGJvM18828; Thu, 10 Jul 2003 19:19:57 +0300 Date: Thu, 10 Jul 2003 19:19:57 +0300 (EEST) From: Pekka Savola To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: cat@zip.com.au, , Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling broken In-Reply-To: <20030711.011858.117900702.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 3903 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 Fri, 11 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote: > In article (at Thu, 10 Jul 2003 19:08:20 +0300 (EEST)), Pekka Savola says: > > > While technically correct, I'm still not sure if this is (pragmatically) > > the correct approach. It's OK to set a default route to go to the > > subnet routers anycast address (so, setting a route to prefix:: should > > not give you EINVAL). > > But, on the other side cannot use prefix::, and > the setting is rather non-sense. Not really. From the host perspective: "I want to set default route to SOME default router" (there may be multiple routers in the LAN, while only one at a time is actively responding to the anycast address; if that one goes away, another one takes its place.) > We should educate people not to use /127; use /64 instead. > v6ops? :-) That's another story.. -- 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 mika.liljeberg@welho.com Thu Jul 10 09:27:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 09:27:27 -0700 (PDT) Received: from hades.pp.htv.fi (cs180094.pp.htv.fi [213.243.180.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6AGRD2x012529 for ; Thu, 10 Jul 2003 09:27:15 -0700 Received: from hades.pp.htv.fi (localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) with ESMTP id h6AGRGZj006542; Thu, 10 Jul 2003 19:27:16 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) id h6AGRDrC006541; Thu, 10 Jul 2003 19:27:13 +0300 X-Authentication-Warning: hades.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked From: Mika Liljeberg To: CaT Cc: yoshfuji@linux-ipv6.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, pekkas@netcore.fi In-Reply-To: <20030710154302.GE1722@zip.com.au> References: <20030710154302.GE1722@zip.com.au> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1057854432.3588.2.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 10 Jul 2003 19:27:13 +0300 X-archive-position: 3904 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mika.liljeberg@welho.com Precedence: bulk X-list: netdev On Thu, 2003-07-10 at 18:43, CaT wrote: > ip tunnel add sit1 mode sit remote 138.25.6.14 > ip link set sit1 up > ip addr add 3ffe:8001:000c:ffff::37/127 dev sit1 > ip route add ::/0 via 3ffe:8001:000c:ffff::36 > RTNETLINK answers: Invalid argument Try this: ip route add ::/0 dev sit1 MikaL From greearb@candelatech.com Thu Jul 10 09:52:58 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 09:53:12 -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 h6AGqv2x014387 for ; Thu, 10 Jul 2003 09:52:58 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h6AGqhKk024337; Thu, 10 Jul 2003 09:52:44 -0700 Message-ID: <3F0D99DB.5040206@candelatech.com> Date: Thu, 10 Jul 2003 09:52:43 -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: jleu@mindspring.com CC: Rusty Russell , netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, anton@samba.org Subject: Re: [PATCH] Netfilter crossover module. References: <20030710084820.909D12C0DA@lists.samba.org> <20030710090643.A10820@mindspring.com> In-Reply-To: <20030710090643.A10820@mindspring.com> Content-Type: multipart/mixed; boundary="------------010705080708070503070404" X-archive-position: 3905 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 This is a multi-part message in MIME format. --------------010705080708070503070404 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit James R. Leu wrote: > Between you and Ben Greear the linux kernel will have every possible > scheme for sending packets to your self. > > I still think my work on this (Virtual routing and forwarding: > http://linux-vrf.sf.net/) is the less perverted(*) then the work that either > you or Ben have come up with. Plus it has other applications besides > just being able to send packets to your self. > > * in terms of the concept, not necessarily the actual implementation. >>It'd be nice to have the module hardwire the arps itself, but this was >>quickest. Patch welcome. It's likely that with my patch you wouldn't have to hard-wire arps at all. The primary thing that my patch does is to let a machine answer arps from a local interface (over the external interface). Then routing to self can happen by simply(?) binding to the local IP of your choice and using policy-based routing to route correctly. (You can loop-back through a router with this patch, for example.) So, maybe both patches are useful together.... I can't find where I posted my patch last time, so it is attached again for reference. It contains a typo-fix in a comment that may be worthy of inclusion by itself some day :) Also, when nettool (ethtool) becomes generic, the ioctl code can be configured through the nettool api, so that new ioctl will go a way. Thanks, Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear --------------010705080708070503070404 Content-Type: text/plain; name="sts_2.4.20.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sts_2.4.20.patch" --- linux-2.4.20/include/linux/sockios.h 2001-11-07 14:39:36.000000000 -0800 +++ linux-2.4.20.c3/include/linux/sockios.h 2003-03-18 14:32:53.000000000 -0800 @@ -65,6 +65,8 @@ #define SIOCDIFADDR 0x8936 /* delete PA address */ #define SIOCSIFHWBROADCAST 0x8937 /* set hardware broadcast addr */ #define SIOCGIFCOUNT 0x8938 /* get number of devices */ +#define SIOCGIFWEIGHT 0x8939 /* get weight of device, in stones */ +#define SIOCSIFWEIGHT 0x893a /* set weight of device, in stones */ #define SIOCGIFBR 0x8940 /* Bridging support */ #define SIOCSIFBR 0x8941 /* Set bridging options */ @@ -92,6 +94,10 @@ #define SIOCGRARP 0x8961 /* get RARP table entry */ #define SIOCSRARP 0x8962 /* set RARP table entry */ +/* MAC address based VLAN control calls */ +#define SIOCGIFMACVLAN 0x8965 /* Mac address multiplex/demultiplex support */ +#define SIOCSIFMACVLAN 0x8966 /* Set macvlan options */ + /* Driver configuration calls */ #define SIOCGIFMAP 0x8970 /* Get device parameters */ @@ -114,6 +120,16 @@ #define SIOCBONDINFOQUERY 0x8994 /* rtn info about bond state */ #define SIOCBONDCHANGEACTIVE 0x8995 /* update to a new active slave */ + +/* Ben's little hack land */ +#define SIOCSACCEPTLOCALADDRS 0x89a0 /* Allow interfaces to accept pkts from + * local interfaces...use with SO_BINDTODEVICE + */ +#define SIOCGACCEPTLOCALADDRS 0x89a1 /* Allow interfaces to accept pkts from + * local interfaces...use with SO_BINDTODEVICE + */ + + /* Device private ioctl calls */ /* --- linux-2.4.20/net/Config.in 2002-08-02 17:39:46.000000000 -0700 +++ linux-2.4.20.c3/net/Config.in 2003-03-18 14:32:53.000000000 -0800 @@ -48,6 +48,7 @@ bool ' Per-VC IP filter kludge' CONFIG_ATM_BR2684_IPFILTER fi fi + tristate 'MAC address based VLANs (EXPERIMENTAL)' CONFIG_MACVLAN fi tristate '802.1Q VLAN Support' CONFIG_VLAN_8021Q --- linux-2.4.20/net/ipv4/arp.c 2002-11-28 15:53:15.000000000 -0800 +++ linux-2.4.20.c3/net/ipv4/arp.c 2003-03-18 14:32:53.000000000 -0800 @@ -1,4 +1,4 @@ -/* linux/net/inet/arp.c +/* linux/net/inet/arp.c -*-linux-c-*- * * Version: $Id: arp.c,v 1.99 2001/08/30 22:55:42 davem Exp $ * @@ -351,12 +351,22 @@ int flag = 0; /*unsigned long now; */ - if (ip_route_output(&rt, sip, tip, 0, 0) < 0) + if (ip_route_output(&rt, sip, tip, 0, 0) < 0) return 1; - if (rt->u.dst.dev != dev) { - NET_INC_STATS_BH(ArpFilter); - flag = 1; - } + + if (rt->u.dst.dev != dev) { + if ((dev->priv_flags & IFF_ACCEPT_LOCAL_ADDRS) && + (rt->u.dst.dev == &loopback_dev)) { + /* OK, we'll let this special case slide, so that we can arp from one + * local interface to another. This seems to work, but could use some + * review. --Ben + */ + } + else { + NET_INC_STATS_BH(ArpFilter); + flag = 1; + } + } ip_rt_put(rt); return flag; } --- linux-2.4.20/net/ipv4/fib_frontend.c 2002-08-02 17:39:46.000000000 -0700 +++ linux-2.4.20.c3/net/ipv4/fib_frontend.c 2003-03-18 14:32:53.000000000 -0800 @@ -233,8 +233,17 @@ if (fib_lookup(&key, &res)) goto last_resort; - if (res.type != RTN_UNICAST) - goto e_inval_res; + + if (res.type != RTN_UNICAST) { + if ((res.type == RTN_LOCAL) && + (dev->priv_flags & IFF_ACCEPT_LOCAL_ADDRS)) { + /* All is OK */ + } + else { + goto e_inval_res; + } + } + *spec_dst = FIB_RES_PREFSRC(res); fib_combine_itag(itag, &res); #ifdef CONFIG_IP_ROUTE_MULTIPATH --- linux-2.4.20/net/ipv4/tcp_ipv4.c 2002-11-28 15:53:15.000000000 -0800 +++ linux-2.4.20.c3/net/ipv4/tcp_ipv4.c 2003-03-18 14:32:53.000000000 -0800 @@ -1394,7 +1394,7 @@ #define want_cookie 0 /* Argh, why doesn't gcc optimize this :( */ #endif - /* Never answer to SYNs send to broadcast or multicast */ + /* Never answer to SYNs sent to broadcast or multicast */ if (((struct rtable *)skb->dst)->rt_flags & (RTCF_BROADCAST|RTCF_MULTICAST)) goto drop; --------------010705080708070503070404-- From jgarzik@pobox.com Thu Jul 10 10:41:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 10:41:28 -0700 (PDT) Received: from www.linux.org.uk (IDENT:Mo2Lx2VdagYDMQtvx4rrVSKZS3WvJFNh@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6AHfF2x015545 for ; Thu, 10 Jul 2003 10:41:17 -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 19afPu-00015K-99 for netdev@oss.sgi.com; Thu, 10 Jul 2003 18:41:14 +0100 Message-ID: <3F0DA525.2080808@pobox.com> Date: Thu, 10 Jul 2003 13:40:53 -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: Maillist netdev Subject: [Fwd: PATCH pktgen hang, memleak, fixes] Content-Type: multipart/mixed; boundary="------------010608040006050807000806" X-archive-position: 3906 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------010608040006050807000806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------010608040006050807000806 Content-Type: message/rfc822; name="PATCH pktgen hang, memleak, fixes" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="PATCH pktgen hang, memleak, fixes" Return-Path: Delivered-To: garzik@gtf.org Received: from puzzle.pobox.com (puzzle.pobox.com [207.106.49.20]) by havoc.gtf.org (Postfix) with ESMTP id 7E495665C for ; Thu, 10 Jul 2003 11:27:15 -0400 (EDT) Received: from puzzle.pobox.com (localhost [127.0.0.1]) by puzzle.pobox.com (Postfix) with ESMTP id E4B9426C011 for ; Thu, 10 Jul 2003 11:27:14 -0400 (EDT) Delivered-To: jgarzik@pobox.com Received: from vger.kernel.org (vger.kernel.org [209.116.70.75]) by puzzle.pobox.com (Postfix) with ESMTP id C3B2526C124 for ; Thu, 10 Jul 2003 11:27:14 -0400 (EDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S269321AbTGJPHs (ORCPT ); Thu, 10 Jul 2003 11:07:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S269324AbTGJPHr (ORCPT ); Thu, 10 Jul 2003 11:07:47 -0400 Received: from sea2-f47.sea2.hotmail.com ([207.68.165.47]:64013 "EHLO hotmail.com") by vger.kernel.org with ESMTP id S269321AbTGJPHp (ORCPT ); Thu, 10 Jul 2003 11:07:45 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 10 Jul 2003 08:22:25 -0700 Received: from 63.173.114.243 by sea2fd.sea2.hotmail.msn.com with HTTP; Thu, 10 Jul 2003 15:22:24 GMT X-Originating-IP: [63.173.114.243] X-Originating-Email: [kambo77@hotmail.com] From: "Kambo Lohan" To: linux-kernel@vger.kernel.org Subject: PATCH pktgen hang, memleak, fixes Date: Thu, 10 Jul 2003 11:22:24 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 Jul 2003 15:22:25.0186 (UTC) FILETIME=[10F4F020:01C346F7] Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org X-Spam-Status: No, hits=-4.7 required=7.0 tests=AWL,BAYES_10,FROM_ENDS_IN_NUMS,PATCH_UNIFIED_DIFF, X_MAILING_LIST version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) This should fix about 3 things. My first patch, be gentle... 2.5 has the same problem but I do not know if this will apply or not, we run 2.4. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --- linux-2.4.21/net/core/pktgen.c 2002-11-28 18:53:15.000000000 -0500 +++ linux-2.4-kjp/net/core/pktgen.c 2003-07-10 11:08:31.000000000 -0400 @@ -34,6 +34,7 @@ * * The new changes seem to have a performance impact of around 1%, * as far as I can tell. * --Ben Greear + * Fix refcount off by one if first packet fails, potential null deref, memleak 030710- KJP * * Renamed multiskb to clone_skb and cleaned up sending core for two distinct * skb modes. A clone_skb=0 mode for Ben "ranges" work and a clone_skb != 0 @@ -84,9 +85,9 @@ #define cycles() ((u32)get_cycles()) -#define VERSION "pktgen version 1.2" +#define VERSION "pktgen version 1.2.1" static char version[] __initdata = - "pktgen.c: v1.2: Packet Generator for packet performance testing.\n"; + "pktgen.c: v1.2.1: Packet Generator for packet performance testing.\n"; /* Used to help with determining the pkts on receive */ @@ -613,12 +614,11 @@ kfree_skb(skb); skb = fill_packet(odev, info); if (skb == NULL) { - break; + goto out_reldev; } fp++; fp_tmp = 0; /* reset counter */ } - atomic_inc(&skb->users); } nr_frags = skb_shinfo(skb)->nr_frags; @@ -634,9 +634,10 @@ last_ok = 0; } else { - last_ok = 1; - info->sofar++; - info->seq_num++; + atomic_inc(&skb->users); + last_ok = 1; + info->sofar++; + info->seq_num++; } } else { @@ -707,6 +708,7 @@ } }/* while we should be running */ + do_gettimeofday(&(info->stopped_at)); total = (info->stopped_at.tv_sec - info->started_at.tv_sec) * 1000000 + @@ -731,6 +733,8 @@ (unsigned long long) info->errors ); } + + kfree_skb(skb); out_reldev: if (odev) { _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - 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/ --------------010608040006050807000806-- From yoshfuji@wide.ad.jp Thu Jul 10 11:05:52 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 11:05: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 h6AI5o2x016014 for ; Thu, 10 Jul 2003 11:05:51 -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 h6AI7NBo001866 for ; Fri, 11 Jul 2003 03:07:23 +0900 Resent-Date: Fri, 11 Jul 2003 03:07:23 +0900 (JST) Resent-Message-Id: <20030711.030723.108590257.yoshfuji@wide.ad.jp> Resent-To: netdev@oss.sgi.com Resent-From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= X-Originating-IP: [63.173.114.243] X-Originating-Email: [kambo77@hotmail.com] From: "Kambo Lohan" To: linux-kernel@vger.kernel.org Cc: robert.olsson@its.uu.se Subject: [PATCH] [UPDATED] pktgen fixes .... Date: Thu, 10 Jul 2003 13:40:04 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 Jul 2003 17:40:05.0049 (UTC) FILETIME=[4C380290:01C3470A] Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org X-archive-position: 3907 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@wide.ad.jp Precedence: bulk X-list: netdev That last fix was bad... the skb->users refcount change made it possible for the skb to get double freed as skb->users was only incremented from one immediately after calling dev_hard_xmit, this should address that I hope. I now see thats what the old code was trying to avoid, but the old way fails if the first packet attempted failed dev_hard_xmit. So it needs a fix somehow. I am testing this by looping a script that starts pktgen with count=10000 and clone_skb=100. Making sure it does not soft hang (requiring a control c) or cause mem leaks. Here is the updated patch. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --- linux-2.4.21/net/core/pktgen.c 2002-11-28 18:53:15.000000000 -0500 +++ linux-2.4-kjp/net/core/pktgen.c 2003-07-10 13:22:17.000000000 -0400 @@ -34,6 +34,7 @@ * * The new changes seem to have a performance impact of around 1%, * as far as I can tell. * --Ben Greear + * Fix refcount off by one if first packet fails, potential null deref, memleak 030710- KJP * * Renamed multiskb to clone_skb and cleaned up sending core for two distinct * skb modes. A clone_skb=0 mode for Ben "ranges" work and a clone_skb != 0 @@ -84,9 +85,9 @@ #define cycles() ((u32)get_cycles()) -#define VERSION "pktgen version 1.2" +#define VERSION "pktgen version 1.2.1" static char version[] __initdata = - "pktgen.c: v1.2: Packet Generator for packet performance testing.\n"; + "pktgen.c: v1.2.1: Packet Generator for packet performance testing.\n"; /* Used to help with determining the pkts on receive */ @@ -613,12 +614,11 @@ kfree_skb(skb); skb = fill_packet(odev, info); if (skb == NULL) { - break; + goto out_reldev; } fp++; fp_tmp = 0; /* reset counter */ } - atomic_inc(&skb->users); } nr_frags = skb_shinfo(skb)->nr_frags; @@ -626,7 +626,9 @@ spin_lock_bh(&odev->xmit_lock); if (!netif_queue_stopped(odev)) { + atomic_inc(&skb->users); if (odev->hard_start_xmit(skb, odev)) { + atomic_dec(&skb->users); if (net_ratelimit()) { printk(KERN_INFO "Hard xmit error\n"); } @@ -634,9 +636,9 @@ last_ok = 0; } else { - last_ok = 1; - info->sofar++; - info->seq_num++; + last_ok = 1; + info->sofar++; + info->seq_num++; } } else { @@ -731,6 +733,8 @@ (unsigned long long) info->errors ); } + + kfree_skb(skb); out_reldev: if (odev) { _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus - 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 jkenisto@us.ibm.com Thu Jul 10 12:11:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 12:12:12 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6AJAl2x016937 for ; Thu, 10 Jul 2003 12:11:34 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h6AJAHjR117610; Thu, 10 Jul 2003 15:10:17 -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 h6AJADDQ040704; Thu, 10 Jul 2003 15:10:14 -0400 Message-ID: <3F0DB9A5.23723BE1@us.ibm.com> Date: Thu, 10 Jul 2003 12:08:21 -0700 From: Jim Keniston X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: James Morris CC: LKML , netdev@oss.sgi.com, Andrew Morton , "David S. Miller" , Jeff Garzik , Alan Cox , Randy Dunlap Subject: Re: [PATCH - RFC] [1/2] 2.6 must-fix list - kernel error reporting References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3908 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 James Morris wrote: > > On Tue, 8 Jul 2003, Jim Keniston wrote: > > + kerror_nl = netlink_kernel_create(NETLINK_KERROR, kerror_netlink_rcv); > + if (kerror_nl == NULL) > + panic("kerror_init: cannot initialize kerror_nl\n"); > > You can simply use NULL instead of passing the dummy kerror_netlink_rcv > function. That begs the question: do we trust that nobody but the kernel will send packets to a NETLINK_KERROR socket? Ordinary users can't, but any root application can. Without kerror_netlink_rcv(), such packets don't get dequeued. > > +struct kern_log_entry { > + __u16 log_kmagic; /* always LOGREC_KMAGIC */ > + __u16 log_kversion; /* which version of this struct? */ > + char log_facility[FACILITY_MAXLEN]; /* e.g., driver name */ > > These fields should generally be specified in ascending order to help with > alignment. We include log_kmagic and log_kversion so the receiving app (e.g. the evlog daemon) can figure out which version of the kernel header it's getting. Note that we're up to #3 (going on #4, with the changes you and others have suggested). As long as we have to include log_kmagic and log_kversion, they need to be first. That said, I get the impression that people would be more comfortable if log_facility[] were moved to the end. Other than that, can anybody point out a specific area where there's likely to be an alignment problem? The various members' offsets are the same on i386, ppc32, and ppc64. This should also be true for s390 and s390x. I'd think it'd really matter only when kernel and user on the same system are different architectures. ppc64K/ppc32U, at least, works. > > It may also be worth looking at how the ULOG code batches messages to > improve peformance. Thanks for the pointer. Looks nice. If performance turns out to be an issue (e.g., if for some reason people want to cc all printk messages through this interface), I'll keep that in mind. > > - James > -- > James Morris > Jim K. From mika.penttila@kolumbus.fi Thu Jul 10 12:51:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 12:52:26 -0700 (PDT) Received: from notes.hallinto.turkuamk.fi (notes.hallinto.turkuamk.fi [195.148.215.149]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6AJp62x020117 for ; Thu, 10 Jul 2003 12:51:48 -0700 Received: from kolumbus.fi ([193.166.244.70]) by marconi.hallinto.turkuamk.fi (Lotus Domino Release 5.0.8) with ESMTP id 2003071022522130:19785 ; Thu, 10 Jul 2003 22:52:21 +0300 Message-ID: <3F0DC518.3010301@kolumbus.fi> Date: Thu, 10 Jul 2003 22:57:12 +0300 From: =?ISO-8859-1?Q?Mika_Penttil=E4?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?YOSHIFUJI_Hideaki_/_=3F=3F=3F=3F?= CC: cat@zip.com.au, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, pekkas@netcore.fi Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked References: <20030710154302.GE1722@zip.com.au> <20030711.005542.04973601.yoshfuji@linux-ipv6.org> X-MIMETrack: Itemize by SMTP Server on marconi.hallinto.turkuamk.fi/TAMK(Release 5.0.8 |June 18, 2001) at 10.07.2003 22:52:21, Serialize by Router on notes.hallinto.turkuamk.fi/TAMK(Release 5.0.10 |March 22, 2002) at 10.07.2003 22:52:34, Serialize complete at 10.07.2003 22:52:34 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-archive-position: 3909 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mika.penttila@kolumbus.fi Precedence: bulk X-list: netdev But 3ffe:8001:000c:ffff::36 is _not_ subnet routers anycast address. Anyway, looks like a bug to me... --Mika YOSHIFUJI Hideaki / ???? wrote: >In article <20030710154302.GE1722@zip.com.au> (at Fri, 11 Jul 2003 01:43:03 +1000), CaT says: > > > >>With 2.4.21-pre2 I can get a nice tunnel going over my ppp connection >>and as such get ipv6 connectivity. I think went to 2.4.21 and then to >>2.4.22-pre4 and bringing up the tunnel fails as follows: >> >> >: > > >>ip addr add 3ffe:8001:000c:ffff::37/127 dev sit1 >> ip route add ::/0 via 3ffe:8001:000c:ffff::36 >>RTNETLINK answers: Invalid argument >> >> > >This is not bug, but rather misconfiguration; >you cannot use prefix::, which is mandatory subnet routers >anycast address, as unicast address. > >Thank you. > > > From chas@locutus.cmf.nrl.navy.mil Thu Jul 10 13:34:48 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 13:35:25 -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 h6AKY72x021414 for ; Thu, 10 Jul 2003 13:34:48 -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 h6AKXtsG006493; Thu, 10 Jul 2003 16:33:55 -0400 (EDT) Message-Id: <200307102033.h6AKXtsG006493@ginger.cmf.nrl.navy.mil> To: davem@redhat.com cc: netdev@oss.sgi.com Subject: [PATCH][2.4] more atm changes backported to 2.4 Reply-To: chas3@users.sourceforge.net Date: Thu, 10 Jul 2003 16:31:32 -0400 From: chas williams X-Spam-Score: () hits=0.5 X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 3910 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 [atm]: make atm buildable as a module # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1013 -> 1.1014 # net/sched/Config.in 1.3 -> 1.4 # arch/cris/config.in 1.13 -> 1.13.1.1 # drivers/net/Config.in 1.62 -> 1.63 # arch/sparc/config.in 1.14 -> 1.14.1.1 # net/atm/Makefile 1.5 -> 1.6 # net/Config.in 1.11 -> 1.12 # arch/alpha/config.in 1.22.1.1 -> 1.22.1.2 # arch/ppc64/config.in 1.6 -> 1.6.1.1 # net/atm/proc.c 1.7 -> 1.8 # net/atm/pvc.c 1.3 -> 1.4 # arch/sparc64/config.in 1.25 -> 1.25.1.1 # arch/i386/config.in 1.42 -> 1.42.1.1 # include/linux/net.h 1.2 -> 1.3 # net/netsyms.c 1.36 -> 1.37 # arch/sh/config.in 1.8 -> 1.8.1.1 # arch/ia64/config.in 1.17 -> 1.17.1.1 # arch/ppc/config.in 1.36 -> 1.36.1.1 # net/atm/svc.c 1.3 -> 1.4 # arch/x86_64/config.in 1.4 -> 1.4.1.1 # net/atm/common.h 1.1 -> 1.2 # drivers/atm/Config.in 1.7 -> 1.8 # arch/parisc/config.in 1.5 -> 1.5.1.1 # net/atm/common.c 1.16 -> 1.17 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 03/06/27 chas@relax.cmf.nrl.navy.mil 1.1014 # make atm buildable as a module # -------------------------------------------- # diff -Nru a/arch/alpha/config.in b/arch/alpha/config.in --- a/arch/alpha/config.in Mon Jun 30 13:22:50 2003 +++ b/arch/alpha/config.in Mon Jun 30 13:22:50 2003 @@ -367,7 +367,7 @@ bool 'Network device support' CONFIG_NETDEVICES if [ "$CONFIG_NETDEVICES" = "y" ]; then source drivers/net/Config.in - if [ "$CONFIG_ATM" = "y" ]; then + if [ "$CONFIG_ATM" != "n" ]; then source drivers/atm/Config.in fi fi diff -Nru a/arch/cris/config.in b/arch/cris/config.in --- a/arch/cris/config.in Mon Jun 30 13:22:50 2003 +++ b/arch/cris/config.in Mon Jun 30 13:22:50 2003 @@ -199,7 +199,7 @@ bool 'Network device support' CONFIG_NETDEVICES if [ "$CONFIG_NETDEVICES" = "y" ]; then source drivers/net/Config.in - if [ "$CONFIG_ATM" = "y" ]; then + if [ "$CONFIG_ATM" != "n" ]; then source drivers/atm/Config.in fi fi diff -Nru a/arch/i386/config.in b/arch/i386/config.in --- a/arch/i386/config.in Mon Jun 30 13:22:50 2003 +++ b/arch/i386/config.in Mon Jun 30 13:22:50 2003 @@ -393,7 +393,7 @@ bool 'Network device support' CONFIG_NETDEVICES if [ "$CONFIG_NETDEVICES" = "y" ]; then source drivers/net/Config.in - if [ "$CONFIG_ATM" = "y" ]; then + if [ "$CONFIG_ATM" != "n" ]; then source drivers/atm/Config.in fi fi diff -Nru a/arch/ia64/config.in b/arch/ia64/config.in --- a/arch/ia64/config.in Mon Jun 30 13:22:50 2003 +++ b/arch/ia64/config.in Mon Jun 30 13:22:50 2003 @@ -179,7 +179,7 @@ bool 'Network device support' CONFIG_NETDEVICES if [ "$CONFIG_NETDEVICES" = "y" ]; then source drivers/net/Config.in - if [ "$CONFIG_ATM" = "y" ]; then + if [ "$CONFIG_ATM" != "n" ]; then source drivers/atm/Config.in fi fi diff -Nru a/arch/parisc/config.in b/arch/parisc/config.in --- a/arch/parisc/config.in Mon Jun 30 13:22:50 2003 +++ b/arch/parisc/config.in Mon Jun 30 13:22:50 2003 @@ -136,7 +136,7 @@ if [ "$CONFIG_NETDEVICES" = "y" ]; then source drivers/net/Config.in - if [ "$CONFIG_ATM" = "y" ]; then + if [ "$CONFIG_ATM" != "n" ]; then source drivers/atm/Config.in fi fi diff -Nru a/arch/ppc/config.in b/arch/ppc/config.in --- a/arch/ppc/config.in Mon Jun 30 13:22:50 2003 +++ b/arch/ppc/config.in Mon Jun 30 13:22:50 2003 @@ -324,7 +324,7 @@ bool 'Network device support' CONFIG_NETDEVICES if [ "$CONFIG_NETDEVICES" = "y" ]; then source drivers/net/Config.in - if [ "$CONFIG_ATM" = "y" ]; then + if [ "$CONFIG_ATM" != "n" ]; then source drivers/atm/Config.in fi fi diff -Nru a/arch/ppc64/config.in b/arch/ppc64/config.in --- a/arch/ppc64/config.in Mon Jun 30 13:22:50 2003 +++ b/arch/ppc64/config.in Mon Jun 30 13:22:50 2003 @@ -141,7 +141,7 @@ bool 'Network device support' CONFIG_NETDEVICES if [ "$CONFIG_NETDEVICES" = "y" ]; then source drivers/net/Config.in - if [ "$CONFIG_ATM" = "y" ]; then + if [ "$CONFIG_ATM" != "n" ]; then source drivers/atm/Config.in fi fi diff -Nru a/arch/sh/config.in b/arch/sh/config.in --- a/arch/sh/config.in Mon Jun 30 13:22:50 2003 +++ b/arch/sh/config.in Mon Jun 30 13:22:50 2003 @@ -259,7 +259,7 @@ bool 'Network device support' CONFIG_NETDEVICES if [ "$CONFIG_NETDEVICES" = "y" ]; then source drivers/net/Config.in - if [ "$CONFIG_ATM" = "y" ]; then + if [ "$CONFIG_ATM" != "n" ]; then source drivers/atm/Config.in fi fi diff -Nru a/arch/sparc/config.in b/arch/sparc/config.in --- a/arch/sparc/config.in Mon Jun 30 13:22:50 2003 +++ b/arch/sparc/config.in Mon Jun 30 13:22:50 2003 @@ -209,7 +209,7 @@ dep_tristate ' PPP BSD-Compress compression' CONFIG_PPP_BSDCOMP m if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then dep_tristate ' PPP over Ethernet (EXPERIMENTAL)' CONFIG_PPPOE $CONFIG_PPP - if [ "$CONFIG_ATM" = "y" ]; then + if [ "$CONFIG_ATM" != "n" ]; then dep_tristate ' PPP over ATM (EXPERIMENTAL)' CONFIG_PPPOATM $CONFIG_PPP fi fi @@ -235,7 +235,7 @@ # if [ "$CONFIG_FDDI" = "y" ]; then # fi - if [ "$CONFIG_ATM" = "y" ]; then + if [ "$CONFIG_ATM" != "n" ]; then source drivers/atm/Config.in fi fi diff -Nru a/arch/sparc64/config.in b/arch/sparc64/config.in --- a/arch/sparc64/config.in Mon Jun 30 13:22:50 2003 +++ b/arch/sparc64/config.in Mon Jun 30 13:22:50 2003 @@ -234,7 +234,7 @@ bool 'Network device support' CONFIG_NETDEVICES if [ "$CONFIG_NETDEVICES" = "y" ]; then source drivers/net/Config.in - if [ "$CONFIG_ATM" = "y" ]; then + if [ "$CONFIG_ATM" != "n" ]; then source drivers/atm/Config.in fi fi diff -Nru a/arch/x86_64/config.in b/arch/x86_64/config.in --- a/arch/x86_64/config.in Mon Jun 30 13:22:50 2003 +++ b/arch/x86_64/config.in Mon Jun 30 13:22:50 2003 @@ -173,7 +173,7 @@ if [ "$CONFIG_NETDEVICES" = "y" ]; then source drivers/net/Config.in # seems to be largely not 64bit safe -# if [ "$CONFIG_ATM" = "y" ]; then +# if [ "$CONFIG_ATM" != "n" ]; then # source drivers/atm/Config.in # fi fi diff -Nru a/drivers/atm/Config.in b/drivers/atm/Config.in --- a/drivers/atm/Config.in Mon Jun 30 13:22:50 2003 +++ b/drivers/atm/Config.in Mon Jun 30 13:22:50 2003 @@ -4,11 +4,11 @@ mainmenu_option next_comment comment 'ATM drivers' if [ "$CONFIG_INET" = "y" ]; then - tristate 'ATM over TCP' CONFIG_ATM_TCP + dep_tristate 'ATM over TCP' CONFIG_ATM_TCP $CONFIG_ATM fi if [ "$CONFIG_PCI" = "y" ]; then - tristate 'Efficient Networks Speedstream 3010' CONFIG_ATM_LANAI - tristate 'Efficient Networks ENI155P' CONFIG_ATM_ENI + dep_tristate 'Efficient Networks Speedstream 3010' CONFIG_ATM_LANAI $CONFIG_ATM + dep_tristate 'Efficient Networks ENI155P' CONFIG_ATM_ENI $CONFIG_ATM if [ "$CONFIG_ATM_ENI" != "n" ]; then bool ' Enable extended debugging' CONFIG_ATM_ENI_DEBUG bool ' Fine-tune burst settings' CONFIG_ATM_ENI_TUNE_BURST @@ -23,8 +23,8 @@ bool ' Enable 2W RX bursts (optional)' CONFIG_ATM_ENI_BURST_RX_2W fi fi - tristate 'Fujitsu FireStream (FS50/FS155) ' CONFIG_ATM_FIRESTREAM - tristate 'ZeitNet ZN1221/ZN1225' CONFIG_ATM_ZATM + dep_tristate 'Fujitsu FireStream (FS50/FS155) ' CONFIG_ATM_FIRESTREAM $CONFIG_ATM + dep_tristate 'ZeitNet ZN1221/ZN1225' CONFIG_ATM_ZATM $CONFIG_ATM if [ "$CONFIG_ATM_ZATM" != "n" ]; then bool ' Enable extended debugging' CONFIG_ATM_ZATM_DEBUG if [ "$CONFIG_X86" = "y" ]; then @@ -35,32 +35,32 @@ # if [ "$CONFIG_ATM_TNETA1570" = "y" ]; then # bool ' Enable extended debugging' CONFIG_ATM_TNETA1570_DEBUG n # fi - tristate 'IDT 77201 (NICStAR) (ForeRunnerLE)' CONFIG_ATM_NICSTAR + dep_tristate 'IDT 77201 (NICStAR) (ForeRunnerLE)' CONFIG_ATM_NICSTAR $CONFIG_ATM if [ "$CONFIG_ATM_NICSTAR" != "n" ]; then bool ' Use suni PHY driver (155Mbps)' CONFIG_ATM_NICSTAR_USE_SUNI bool ' Use IDT77015 PHY driver (25Mbps)' CONFIG_ATM_NICSTAR_USE_IDT77105 fi - tristate 'IDT 77252 (NICStAR II)' CONFIG_ATM_IDT77252 + dep_tristate 'IDT 77252 (NICStAR II)' CONFIG_ATM_IDT77252 $CONFIG_ATM if [ "$CONFIG_ATM_IDT77252" != "n" ]; then bool ' Enable debugging messages' CONFIG_ATM_IDT77252_DEBUG bool ' Receive ALL cells in raw queue' CONFIG_ATM_IDT77252_RCV_ALL define_bool CONFIG_ATM_IDT77252_USE_SUNI y fi - tristate 'Madge Ambassador (Collage PCI 155 Server)' CONFIG_ATM_AMBASSADOR + dep_tristate 'Madge Ambassador (Collage PCI 155 Server)' CONFIG_ATM_AMBASSADOR $CONFIG_ATM if [ "$CONFIG_ATM_AMBASSADOR" != "n" ]; then bool ' Enable debugging messages' CONFIG_ATM_AMBASSADOR_DEBUG fi - tristate 'Madge Horizon [Ultra] (Collage PCI 25 and Collage PCI 155 Client)' CONFIG_ATM_HORIZON + dep_tristate 'Madge Horizon [Ultra] (Collage PCI 25 and Collage PCI 155 Client)' CONFIG_ATM_HORIZON $CONFIG_ATM if [ "$CONFIG_ATM_HORIZON" != "n" ]; then bool ' Enable debugging messages' CONFIG_ATM_HORIZON_DEBUG fi - tristate 'Interphase ATM PCI x575/x525/x531' CONFIG_ATM_IA - if [ "$CONFIG_ATM_IA" != "n" ]; then - bool ' Enable debugging messages' CONFIG_ATM_IA_DEBUG - fi + dep_tristate 'Interphase ATM PCI x575/x525/x531' CONFIG_ATM_IA $CONFIG_ATM + if [ "$CONFIG_ATM_IA" != "n" ]; then + bool ' Enable debugging messages' CONFIG_ATM_IA_DEBUG + fi fi if [ "$CONFIG_PCI" = "y" -o "$CONFIG_SBUS" = "y" ]; then - tristate 'FORE Systems 200E-series' CONFIG_ATM_FORE200E_MAYBE + dep_tristate 'FORE Systems 200E-series' CONFIG_ATM_FORE200E_MAYBE $CONFIG_ATM if [ "$CONFIG_ATM_FORE200E_MAYBE" != "n" ]; then if [ "$CONFIG_PCI" = "y" ]; then bool ' PCA-200E support' CONFIG_ATM_FORE200E_PCA @@ -93,7 +93,7 @@ fi fi if [ "$CONFIG_PCI" = "y" ]; then - tristate 'ForeRunner HE Series' CONFIG_ATM_HE + dep_tristate 'ForeRunner HE Series' CONFIG_ATM_HE $CONFIG_ATM if [ "$CONFIG_ATM_HE" != "n" ]; then bool 'Use S/UNI PHY driver' CONFIG_ATM_HE_USE_SUNI fi diff -Nru a/drivers/net/Config.in b/drivers/net/Config.in --- a/drivers/net/Config.in Mon Jun 30 13:22:50 2003 +++ b/drivers/net/Config.in Mon Jun 30 13:22:50 2003 @@ -308,7 +308,7 @@ dep_tristate ' PPP over Ethernet (EXPERIMENTAL)' CONFIG_PPPOE $CONFIG_PPP fi if [ ! "$CONFIG_ATM" = "n" ]; then - dep_tristate ' PPP over ATM (EXPERIMENTAL)' CONFIG_PPPOATM $CONFIG_PPP $CONFIG_EXPERIMENTAL + dep_tristate ' PPP over ATM (EXPERIMENTAL)' CONFIG_PPPOATM $CONFIG_PPP $CONFIG_EXPERIMENTAL $CONFIG_ATM fi fi diff -Nru a/include/linux/net.h b/include/linux/net.h --- a/include/linux/net.h Mon Jun 30 13:22:50 2003 +++ b/include/linux/net.h Mon Jun 30 13:22:50 2003 @@ -139,6 +139,7 @@ extern int sock_recvmsg(struct socket *, struct msghdr *m, int len, int flags); extern int sock_readv_writev(int type, struct inode * inode, struct file * file, const struct iovec * iov, long count, long size); +extern struct socket *sockfd_lookup(int fd, int *err); extern int net_ratelimit(void); extern unsigned long net_random(void); diff -Nru a/net/Config.in b/net/Config.in --- a/net/Config.in Mon Jun 30 13:22:50 2003 +++ b/net/Config.in Mon Jun 30 13:22:50 2003 @@ -31,19 +31,19 @@ fi fi if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then - bool 'Asynchronous Transfer Mode (ATM) (EXPERIMENTAL)' CONFIG_ATM - if [ "$CONFIG_ATM" = "y" ]; then + tristate 'Asynchronous Transfer Mode (ATM) (EXPERIMENTAL)' CONFIG_ATM + if [ "$CONFIG_ATM" != "n" ]; then if [ "$CONFIG_INET" = "y" ]; then - tristate ' Classical IP over ATM' CONFIG_ATM_CLIP + dep_tristate ' Classical IP over ATM' CONFIG_ATM_CLIP $CONFIG_ATM if [ "$CONFIG_ATM_CLIP" != "n" ]; then bool ' Do NOT send ICMP if no neighbour' CONFIG_ATM_CLIP_NO_ICMP fi fi - tristate ' LAN Emulation (LANE) support' CONFIG_ATM_LANE + dep_tristate ' LAN Emulation (LANE) support' CONFIG_ATM_LANE $CONFIG_ATM if [ "$CONFIG_INET" = "y" -a "$CONFIG_ATM_LANE" != "n" ]; then tristate ' Multi-Protocol Over ATM (MPOA) support' CONFIG_ATM_MPOA fi - tristate ' RFC1483/2684 Bridged protocols' CONFIG_ATM_BR2684 + dep_tristate ' RFC1483/2684 Bridged protocols' CONFIG_ATM_BR2684 $CONFIG_ATM if [ "$CONFIG_ATM_BR2684" != "n" ]; then bool ' Per-VC IP filter kludge' CONFIG_ATM_BR2684_IPFILTER fi diff -Nru a/net/atm/Makefile b/net/atm/Makefile --- a/net/atm/Makefile Mon Jun 30 13:22:50 2003 +++ b/net/atm/Makefile Mon Jun 30 13:22:50 2003 @@ -14,7 +14,10 @@ list-multi := mpoa.o mpoa-objs := mpc.o mpoa_caches.o mpoa_proc.o -obj-$(CONFIG_ATM) := addr.o pvc.o signaling.o svc.o common.o atm_misc.o raw.o resources.o +obj-y := addr.o pvc.o signaling.o svc.o common.o atm_misc.o raw.o resources.o +ifeq ($(CONFIG_ATM),m) + obj-m += $(O_TARGET) +endif ifneq ($(CONFIG_ATM_CLIP),n) NEED_IPCOM = ipcommon.o @@ -31,13 +34,13 @@ obj-$(CONFIG_ATM_BR2684) += br2684.o ifeq ($(CONFIG_NET_SCH_ATM),y) -NEED_IPCOM = ipcommon.o + NEED_IPCOM = ipcommon.o endif obj-y += $(NEED_IPCOM) ifeq ($(CONFIG_PROC_FS),y) -obj-y += proc.o + obj-y += proc.o endif obj-$(CONFIG_ATM_LANE) += lec.o diff -Nru a/net/atm/common.c b/net/atm/common.c --- a/net/atm/common.c Mon Jun 30 13:22:50 2003 +++ b/net/atm/common.c Mon Jun 30 13:22:50 2003 @@ -21,6 +21,7 @@ #include /* struct timeval */ #include #include +#include #include /* struct sock */ #include @@ -1217,3 +1218,43 @@ return; } #endif + +static int __init atm_init(void) +{ + int error; + + if ((error = atmpvc_init()) < 0) { + printk(KERN_ERR "atmpvc_init() failed with %d\n", error); + goto failure; + } + if ((error = atmsvc_init()) < 0) { + printk(KERN_ERR "atmsvc_init() failed with %d\n", error); + goto failure; + } +#ifdef CONFIG_PROC_FS + if ((error = atm_proc_init()) < 0) { + printk(KERN_ERR "atm_proc_init() failed with %d\n",error); + goto failure; + } +#endif + return 0; + +failure: + atmsvc_exit(); + atmpvc_exit(); + return error; +} + +static void __exit atm_exit(void) +{ +#ifdef CONFIG_PROC_FS + atm_proc_exit(); +#endif + atmsvc_exit(); + atmpvc_exit(); +} + +module_init(atm_init); +module_exit(atm_exit); + +MODULE_LICENSE("GPL"); diff -Nru a/net/atm/common.h b/net/atm/common.h --- a/net/atm/common.h Mon Jun 30 13:22:50 2003 +++ b/net/atm/common.h Mon Jun 30 13:22:50 2003 @@ -28,7 +28,12 @@ void atm_release_vcc_sk(struct sock *sk,int free_sk); void atm_shutdown_dev(struct atm_dev *dev); +int atmpvc_init(void); +void atmpvc_exit(void); +int atmsvc_init(void); +void atmsvc_exit(void); int atm_proc_init(void); +void atm_proc_exit(void); /* SVC */ diff -Nru a/net/atm/proc.c b/net/atm/proc.c --- a/net/atm/proc.c Mon Jun 30 13:22:50 2003 +++ b/net/atm/proc.c Mon Jun 30 13:22:50 2003 @@ -632,12 +632,28 @@ name->proc_fops = &proc_spec_atm_operations; \ name->owner = THIS_MODULE +static struct proc_dir_entry *devices = NULL, *pvc = NULL, + *svc = NULL, *arp = NULL, *lec = NULL, *vc = NULL; -int __init atm_proc_init(void) +static void atm_proc_cleanup(void) { - struct proc_dir_entry *devices = NULL,*pvc = NULL,*svc = NULL; - struct proc_dir_entry *arp = NULL,*lec = NULL,*vc = NULL; + if (devices) + remove_proc_entry("devices",atm_proc_root); + if (pvc) + remove_proc_entry("pvc",atm_proc_root); + if (svc) + remove_proc_entry("svc",atm_proc_root); + if (arp) + remove_proc_entry("arp",atm_proc_root); + if (lec) + remove_proc_entry("lec",atm_proc_root); + if (vc) + remove_proc_entry("vc",atm_proc_root); + remove_proc_entry("net/atm",NULL); +} +int atm_proc_init(void) +{ atm_proc_root = proc_mkdir("net/atm",NULL); if (!atm_proc_root) return -ENOMEM; @@ -654,12 +670,11 @@ return 0; cleanup: - if (devices) remove_proc_entry("devices",atm_proc_root); - if (pvc) remove_proc_entry("pvc",atm_proc_root); - if (svc) remove_proc_entry("svc",atm_proc_root); - if (arp) remove_proc_entry("arp",atm_proc_root); - if (lec) remove_proc_entry("lec",atm_proc_root); - if (vc) remove_proc_entry("vc",atm_proc_root); - remove_proc_entry("net/atm",NULL); + atm_proc_cleanup(); return -ENOMEM; +} + +void atm_proc_exit(void) +{ + atm_proc_cleanup(); } diff -Nru a/net/atm/pvc.c b/net/atm/pvc.c --- a/net/atm/pvc.c Mon Jun 30 13:22:50 2003 +++ b/net/atm/pvc.c Mon Jun 30 13:22:50 2003 @@ -120,20 +120,12 @@ */ -static int __init atmpvc_init(void) +int atmpvc_init(void) { - int error; - - error = sock_register(&pvc_family_ops); - if (error < 0) { - printk(KERN_ERR "ATMPVC: can't register (%d)",error); - return error; - } -#ifdef CONFIG_PROC_FS - error = atm_proc_init(); - if (error) printk("atm_proc_init fails with %d\n",error); -#endif - return 0; + return sock_register(&pvc_family_ops); } -module_init(atmpvc_init); +void atmpvc_exit(void) +{ + sock_unregister(PF_ATMPVC); +} diff -Nru a/net/atm/svc.c b/net/atm/svc.c --- a/net/atm/svc.c Mon Jun 30 13:22:50 2003 +++ b/net/atm/svc.c Mon Jun 30 13:22:50 2003 @@ -443,13 +443,12 @@ * Initialize the ATM SVC protocol family */ -static int __init atmsvc_init(void) +int atmsvc_init(void) { - if (sock_register(&svc_family_ops) < 0) { - printk(KERN_ERR "ATMSVC: can't register"); - return -1; - } - return 0; + return sock_register(&svc_family_ops); } -module_init(atmsvc_init); +void atmsvc_exit(void) +{ + sock_unregister(PF_ATMSVC); +} diff -Nru a/net/netsyms.c b/net/netsyms.c --- a/net/netsyms.c Mon Jun 30 13:22:50 2003 +++ b/net/netsyms.c Mon Jun 30 13:22:50 2003 @@ -163,6 +163,7 @@ EXPORT_SYMBOL(put_cmsg); EXPORT_SYMBOL(sock_kmalloc); EXPORT_SYMBOL(sock_kfree_s); +EXPORT_SYMBOL(sockfd_lookup); #ifdef CONFIG_FILTER EXPORT_SYMBOL(sk_run_filter); diff -Nru a/net/sched/Config.in b/net/sched/Config.in --- a/net/sched/Config.in Mon Jun 30 13:22:50 2003 +++ b/net/sched/Config.in Mon Jun 30 13:22:50 2003 @@ -6,8 +6,8 @@ tristate ' CSZ packet scheduler' CONFIG_NET_SCH_CSZ #tristate ' H-PFQ packet scheduler' CONFIG_NET_SCH_HPFQ #tristate ' H-FSC packet scheduler' CONFIG_NET_SCH_HFCS -if [ "$CONFIG_ATM" = "y" ]; then - bool ' ATM pseudo-scheduler' CONFIG_NET_SCH_ATM +if [ "$CONFIG_ATM" != "n" ]; then + dep_tristate ' ATM pseudo-scheduler' CONFIG_NET_SCH_ATM $CONFIG_ATM fi tristate ' The simplest PRIO pseudoscheduler' CONFIG_NET_SCH_PRIO tristate ' RED queue' CONFIG_NET_SCH_RED [atm]: eliminate cli, make function names sane # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1014 -> 1.1015 # net/atm/lec.c 1.15 -> 1.16 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 03/06/27 davem@nuts.ninka.net 1.1011.1.17 # Merge nuts.ninka.net:/home/davem/src/BK/network-2.4 # into nuts.ninka.net:/home/davem/src/BK/net-2.4 # -------------------------------------------- # 03/06/27 hch@lst.de 1.1011.1.18 # [CRYPTO-2.4]: Missing ULL postfixes and statics. # -------------------------------------------- # 03/06/27 chas@relax.cmf.nrl.navy.mil 1.1015 # elminate cli, make function names sane # -------------------------------------------- # diff -Nru a/net/atm/lec.c b/net/atm/lec.c --- a/net/atm/lec.c Mon Jun 30 13:22:04 2003 +++ b/net/atm/lec.c Mon Jun 30 13:22:04 2003 @@ -20,6 +20,7 @@ #include #include #include +#include /* TokenRing if needed */ #ifdef CONFIG_TR @@ -55,6 +56,7 @@ unsigned char *addr); extern void (*br_fdb_put_hook)(struct net_bridge_fdb_entry *ent); +static spinlock_t lec_arp_spinlock = SPIN_LOCK_UNLOCKED; #define DUMP_PACKETS 0 /* 0 = None, * 1 = 30 first bytes @@ -1049,15 +1051,15 @@ #define HASH(ch) (ch & (LEC_ARP_TABLE_SIZE -1)) static __inline__ void -lec_arp_lock(struct lec_priv *priv) +lec_arp_get(struct lec_priv *priv) { - atomic_inc(&priv->lec_arp_lock_var); + atomic_inc(&priv->lec_arp_users); } static __inline__ void -lec_arp_unlock(struct lec_priv *priv) +lec_arp_put(struct lec_priv *priv) { - atomic_dec(&priv->lec_arp_lock_var); + atomic_dec(&priv->lec_arp_users); } /* @@ -1108,33 +1110,33 @@ * LANE2: Add to the end of the list to satisfy 8.1.13 */ static __inline__ void -lec_arp_put(struct lec_arp_table **lec_arp_tables, - struct lec_arp_table *to_put) +lec_arp_add(struct lec_arp_table **lec_arp_tables, + struct lec_arp_table *to_add) { - unsigned short place; unsigned long flags; + unsigned short place; struct lec_arp_table *tmp; - save_flags(flags); - cli(); + spin_lock_irqsave(&lec_arp_spinlock, flags); - place = HASH(to_put->mac_addr[ETH_ALEN-1]); + place = HASH(to_add->mac_addr[ETH_ALEN-1]); tmp = lec_arp_tables[place]; - to_put->next = NULL; + to_add->next = NULL; if (tmp == NULL) - lec_arp_tables[place] = to_put; + lec_arp_tables[place] = to_add; else { /* add to the end */ while (tmp->next) tmp = tmp->next; - tmp->next = to_put; + tmp->next = to_add; } - restore_flags(flags); + spin_unlock_irqrestore(&lec_arp_spinlock, flags); + DPRINTK("LEC_ARP: Added entry:%2.2x %2.2x %2.2x %2.2x %2.2x %2.2x\n", - 0xff&to_put->mac_addr[0], 0xff&to_put->mac_addr[1], - 0xff&to_put->mac_addr[2], 0xff&to_put->mac_addr[3], - 0xff&to_put->mac_addr[4], 0xff&to_put->mac_addr[5]); + 0xff&to_add->mac_addr[0], 0xff&to_add->mac_addr[1], + 0xff&to_add->mac_addr[2], 0xff&to_add->mac_addr[3], + 0xff&to_add->mac_addr[4], 0xff&to_add->mac_addr[5]); } /* @@ -1144,16 +1146,15 @@ lec_arp_remove(struct lec_arp_table **lec_arp_tables, struct lec_arp_table *to_remove) { + unsigned long flags; unsigned short place; struct lec_arp_table *tmp; - unsigned long flags; int remove_vcc=1; - save_flags(flags); - cli(); + spin_lock_irqsave(&lec_arp_spinlock, flags); if (!to_remove) { - restore_flags(flags); + spin_unlock_irqrestore(&lec_arp_spinlock, flags); return -1; } place = HASH(to_remove->mac_addr[ETH_ALEN-1]); @@ -1165,7 +1166,7 @@ tmp = tmp->next; } if (!tmp) {/* Entry was not found */ - restore_flags(flags); + spin_unlock_irqrestore(&lec_arp_spinlock, flags); return -1; } } @@ -1191,7 +1192,9 @@ lec_arp_clear_vccs(to_remove); } skb_queue_purge(&to_remove->tx_wait); /* FIXME: good place for this? */ - restore_flags(flags); + + spin_unlock_irqrestore(&lec_arp_spinlock, flags); + DPRINTK("LEC_ARP: Removed entry:%2.2x %2.2x %2.2x %2.2x %2.2x %2.2x\n", 0xff&to_remove->mac_addr[0], 0xff&to_remove->mac_addr[1], 0xff&to_remove->mac_addr[2], 0xff&to_remove->mac_addr[3], @@ -1376,12 +1379,8 @@ lec_arp_destroy(struct lec_priv *priv) { struct lec_arp_table *entry, *next; - unsigned long flags; int i; - save_flags(flags); - cli(); - del_timer(&priv->lec_arp_timer); /* @@ -1424,7 +1423,6 @@ priv->mcast_vcc = NULL; memset(priv->lec_arp_tables, 0, sizeof(struct lec_arp_table*)*LEC_ARP_TABLE_SIZE); - restore_flags(flags); } @@ -1441,18 +1439,18 @@ DPRINTK("LEC_ARP: lec_arp_find :%2.2x %2.2x %2.2x %2.2x %2.2x %2.2x\n", mac_addr[0]&0xff, mac_addr[1]&0xff, mac_addr[2]&0xff, mac_addr[3]&0xff, mac_addr[4]&0xff, mac_addr[5]&0xff); - lec_arp_lock(priv); + lec_arp_get(priv); place = HASH(mac_addr[ETH_ALEN-1]); to_return = priv->lec_arp_tables[place]; while(to_return) { if (memcmp(mac_addr, to_return->mac_addr, ETH_ALEN) == 0) { - lec_arp_unlock(priv); + lec_arp_put(priv); return to_return; } to_return = to_return->next; } - lec_arp_unlock(priv); + lec_arp_put(priv); return NULL; } @@ -1579,11 +1577,11 @@ del_timer(&priv->lec_arp_timer); DPRINTK("lec_arp_check_expire %p,%d\n",priv, - priv->lec_arp_lock_var.counter); + atomic_read(&priv->lec_arp_users)); DPRINTK("expire: eo:%p nf:%p\n",priv->lec_arp_empty_ones, priv->lec_no_forward); - if (!priv->lec_arp_lock_var.counter) { - lec_arp_lock(priv); + if (!atomic_read(&priv->lec_arp_users)) { + lec_arp_get(priv); now = jiffies; for(i=0;ilec_arp_timer.expires = jiffies + LEC_ARP_REFRESH_INTERVAL; add_timer(&priv->lec_arp_timer); @@ -1691,7 +1689,7 @@ if (!entry) { return priv->mcast_vcc; } - lec_arp_put(priv->lec_arp_tables, entry); + lec_arp_add(priv->lec_arp_tables, entry); /* We want arp-request(s) to be sent */ entry->packets_flooded =1; entry->status = ESI_ARP_PENDING; @@ -1716,7 +1714,7 @@ struct lec_arp_table *entry, *next; int i; - lec_arp_lock(priv); + lec_arp_get(priv); DPRINTK("lec_addr_delete\n"); for(i=0;ilec_arp_tables[i];entry != NULL; entry=next) { @@ -1727,11 +1725,11 @@ lec_arp_remove(priv->lec_arp_tables, entry); kfree(entry); } - lec_arp_unlock(priv); + lec_arp_put(priv); return 0; } } - lec_arp_unlock(priv); + lec_arp_put(priv); return -1; } @@ -1756,7 +1754,7 @@ return; /* LANE2: ignore targetless LE_ARPs for which * we have no entry in the cache. 7.1.30 */ - lec_arp_lock(priv); + lec_arp_get(priv); if (priv->lec_arp_empty_ones) { entry = priv->lec_arp_empty_ones; if (!memcmp(entry->atm_addr, atm_addr, ATM_ESA_LEN)) { @@ -1790,13 +1788,13 @@ entry->status = ESI_FORWARD_DIRECT; memcpy(entry->mac_addr, mac_addr, ETH_ALEN); entry->last_used = jiffies; - lec_arp_put(priv->lec_arp_tables, entry); + lec_arp_add(priv->lec_arp_tables, entry); } if (remoteflag) entry->flags|=LEC_REMOTE_FLAG; else entry->flags&=~LEC_REMOTE_FLAG; - lec_arp_unlock(priv); + lec_arp_put(priv); DPRINTK("After update\n"); dump_arp_table(priv); return; @@ -1806,11 +1804,11 @@ if (!entry) { entry = make_entry(priv, mac_addr); if (!entry) { - lec_arp_unlock(priv); + lec_arp_put(priv); return; } entry->status = ESI_UNKNOWN; - lec_arp_put(priv->lec_arp_tables, entry); + lec_arp_add(priv->lec_arp_tables, entry); /* Temporary, changes before end of function */ } memcpy(entry->atm_addr, atm_addr, ATM_ESA_LEN); @@ -1845,7 +1843,7 @@ } DPRINTK("After update2\n"); dump_arp_table(priv); - lec_arp_unlock(priv); + lec_arp_put(priv); } /* @@ -1859,7 +1857,7 @@ struct lec_arp_table *entry; int i, found_entry=0; - lec_arp_lock(priv); + lec_arp_get(priv); if (ioc_data->receive == 2) { /* Vcc for Multicast Forward. No timer, LANEv2 7.1.20 and 2.3.5.3 */ @@ -1868,7 +1866,7 @@ entry = lec_arp_find(priv, bus_mac); if (!entry) { printk("LEC_ARP: Multicast entry not found!\n"); - lec_arp_unlock(priv); + lec_arp_put(priv); return; } memcpy(entry->atm_addr, ioc_data->atm_addr, ATM_ESA_LEN); @@ -1877,7 +1875,7 @@ #endif entry = make_entry(priv, bus_mac); if (entry == NULL) { - lec_arp_unlock(priv); + lec_arp_put(priv); return; } del_timer(&entry->timer); @@ -1886,7 +1884,7 @@ entry->old_recv_push = old_push; entry->next = priv->mcast_fwds; priv->mcast_fwds = entry; - lec_arp_unlock(priv); + lec_arp_put(priv); return; } else if (ioc_data->receive == 1) { /* Vcc which we don't want to make default vcc, attach it @@ -1904,7 +1902,7 @@ ioc_data->atm_addr[18],ioc_data->atm_addr[19]); entry = make_entry(priv, bus_mac); if (entry == NULL) { - lec_arp_unlock(priv); + lec_arp_put(priv); return; } memcpy(entry->atm_addr, ioc_data->atm_addr, ATM_ESA_LEN); @@ -1917,7 +1915,7 @@ add_timer(&entry->timer); entry->next = priv->lec_no_forward; priv->lec_no_forward = entry; - lec_arp_unlock(priv); + lec_arp_put(priv); dump_arp_table(priv); return; } @@ -1976,7 +1974,7 @@ } } if (found_entry) { - lec_arp_unlock(priv); + lec_arp_put(priv); DPRINTK("After vcc was added\n"); dump_arp_table(priv); return; @@ -1985,7 +1983,7 @@ this vcc */ entry = make_entry(priv, bus_mac); if (!entry) { - lec_arp_unlock(priv); + lec_arp_put(priv); return; } entry->vcc = vcc; @@ -1998,7 +1996,7 @@ entry->timer.expires = jiffies + priv->vcc_timeout_period; entry->timer.function = lec_arp_expire_vcc; add_timer(&entry->timer); - lec_arp_unlock(priv); + lec_arp_put(priv); DPRINTK("After vcc was added\n"); dump_arp_table(priv); } @@ -2044,10 +2042,10 @@ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; struct lec_arp_table *to_add; - lec_arp_lock(priv); + lec_arp_get(priv); to_add = make_entry(priv, mac_addr); if (!to_add) { - lec_arp_unlock(priv); + lec_arp_put(priv); return -ENOMEM; } memcpy(to_add->atm_addr, vcc->remote.sas_addr.prv, ATM_ESA_LEN); @@ -2057,8 +2055,8 @@ to_add->old_push = vcc->push; vcc->push = lec_push; priv->mcast_vcc = vcc; - lec_arp_put(priv->lec_arp_tables, to_add); - lec_arp_unlock(priv); + lec_arp_add(priv->lec_arp_tables, to_add); + lec_arp_put(priv); return 0; } @@ -2070,7 +2068,7 @@ DPRINTK("LEC_ARP: lec_vcc_close vpi:%d vci:%d\n",vcc->vpi,vcc->vci); dump_arp_table(priv); - lec_arp_lock(priv); + lec_arp_get(priv); for(i=0;ilec_arp_tables[i];entry; entry=next) { next = entry->next; @@ -2132,7 +2130,7 @@ entry = next; } - lec_arp_unlock(priv); + lec_arp_put(priv); dump_arp_table(priv); } @@ -2140,9 +2138,9 @@ lec_arp_check_empties(struct lec_priv *priv, struct atm_vcc *vcc, struct sk_buff *skb) { + unsigned long flags; struct lec_arp_table *entry, *prev; struct lecdatahdr_8023 *hdr = (struct lecdatahdr_8023 *)skb->data; - unsigned long flags; unsigned char *src; #ifdef CONFIG_TR struct lecdatahdr_8025 *tr_hdr = (struct lecdatahdr_8025 *)skb->data; @@ -2152,26 +2150,26 @@ #endif src = hdr->h_source; - lec_arp_lock(priv); + lec_arp_get(priv); entry = priv->lec_arp_empty_ones; if (vcc == entry->vcc) { - save_flags(flags); - cli(); + spin_lock_irqsave(&lec_arp_spinlock, flags); del_timer(&entry->timer); memcpy(entry->mac_addr, src, ETH_ALEN); entry->status = ESI_FORWARD_DIRECT; entry->last_used = jiffies; priv->lec_arp_empty_ones = entry->next; - restore_flags(flags); + spin_unlock_irqrestore(&lec_arp_spinlock, flags); /* We might have got an entry */ if ((prev=lec_arp_find(priv,src))) { lec_arp_remove(priv->lec_arp_tables, prev); kfree(prev); } - lec_arp_put(priv->lec_arp_tables, entry); - lec_arp_unlock(priv); + lec_arp_add(priv->lec_arp_tables, entry); + lec_arp_put(priv); return; } + spin_lock_irqsave(&lec_arp_spinlock, flags); prev = entry; entry = entry->next; while (entry && entry->vcc != vcc) { @@ -2180,22 +2178,21 @@ } if (!entry) { DPRINTK("LEC_ARP: Arp_check_empties: entry not found!\n"); - lec_arp_unlock(priv); + lec_arp_put(priv); + spin_unlock_irqrestore(&lec_arp_spinlock, flags); return; } - save_flags(flags); - cli(); del_timer(&entry->timer); memcpy(entry->mac_addr, src, ETH_ALEN); entry->status = ESI_FORWARD_DIRECT; entry->last_used = jiffies; prev->next = entry->next; - restore_flags(flags); + spin_unlock_irqrestore(&lec_arp_spinlock, flags); if ((prev = lec_arp_find(priv, src))) { lec_arp_remove(priv->lec_arp_tables,prev); kfree(prev); } - lec_arp_put(priv->lec_arp_tables,entry); - lec_arp_unlock(priv); + lec_arp_add(priv->lec_arp_tables,entry); + lec_arp_put(priv); } MODULE_LICENSE("GPL"); From davem@redhat.com Thu Jul 10 13:46:47 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 13:47:21 -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 h6AKk62x022106 for ; Thu, 10 Jul 2003 13:46: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 NAA27192; Thu, 10 Jul 2003 13:37:37 -0700 Date: Thu, 10 Jul 2003 13:37:37 -0700 (PDT) Message-Id: <20030710.133737.41660806.davem@redhat.com> To: scott.feldman@intel.com Cc: willy@debian.org, netdev@oss.sgi.com Subject: Re: [PATCH] netdev_ops 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: 3911 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: "Feldman, Scott" Date: Thu, 10 Jul 2003 01:18:50 -0700 With HAVE_NETDEV_OPS, you're right, we're maintaining the wrapper code outside the kernel. But, it does leave the possibility of having a shared backwards compatibility code for multiple (all?) drivers for those stuck with supporting kernels without netdev_ops. And precisely I am showing you how all this backwards compat stuff is going to hurt you. You can never truly take advantage of things that eliminate duplicated code in all the drivers, and this netdev_ops case is a great example. From krkumar@us.ibm.com Thu Jul 10 15:17:23 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 15:17:58 -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 h6AMGr2x023078 for ; Thu, 10 Jul 2003 15:17:23 -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 h6AMFoXq203788; Thu, 10 Jul 2003 18:15:50 -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 h6AMFlDQ083410; Thu, 10 Jul 2003 18:15:48 -0400 Message-ID: <3F0DE5B9.20702@us.ibm.com> Date: Thu, 10 Jul 2003 15:16:25 -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, netdev@oss.sgi.com, linux-net@vger.kernel.org, kuznet@ms2.inr.ac.ru Subject: Re: [PATCH] Prefix List against 2.5.70 (re-done) References: <20030627.144752.78715628.davem@redhat.com> <20030628.130602.63704890.yoshfuji@linux-ipv6.org> <3F008771.5030206@us.ibm.com> <20030702.091825.72842784.yoshfuji@linux-ipv6.org> In-Reply-To: <20030702.091825.72842784.yoshfuji@linux-ipv6.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3912 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 > 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. I had explained the reasons for having prefix list i/f in my previous mail. To recap : - User don't need to know what the definition of a prefix is, all he has to do is ask the kernel and get the list. Otherwise different user apps will have to know the definition of a prefix and parse the entry themselves. The parsing is non-trivial (eg the address should not LL or MC, there should be no nexthop and it should be added via an RA, etc). - The kernel code to get the prefix list is small, the top level inet6_dump_fib uses either the dump_node or the dump_prefix, the latter being the new user interface. Having a user interface makes it easier to get the prefix list without significant bloat to the kernel. > 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 Yes, there are a couple of different ways to do this. One is as you have suggested, but there is a problem with it. The existing RTM_GETLINK interface returns very generic elements of the dev (mtu, hardware address, dev statistics), while the change you suggested is specific to ipv6. I am not sure if this is a good design to implement. Either we could use the current (submitted) way or use a different RTM_GETADDR interface in inet6_fill_ifaddr (and introduce RTM_IFACEFLAGS). This will be specific to IPv6. Are you agreeable to this ? > 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. - I am ok with 1 :-) - I have suggested changes for 2, please let me know what you think, whether we can go with the old way or make the change suggested above. - I believe we need #3 for the reasons given above. Thanks, - KK From jgarzik@pobox.com Thu Jul 10 15:40:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 15:40:35 -0700 (PDT) Received: from www.linux.org.uk (IDENT:5kp1wT94CwjrkUhuLQy1tBbkPHBHdG9m@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6AMeQ2x023497 for ; Thu, 10 Jul 2003 15:40:28 -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 19ak5P-0004nO-3P; Thu, 10 Jul 2003 23:40:25 +0100 Message-ID: <3F0DEB4B.7040101@pobox.com> Date: Thu, 10 Jul 2003 18:40:11 -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: Stephen Hemminger CC: Jay Schulist , netdev@oss.sgi.com Subject: Re: [PATCH 2.5.74] Change appletalk/cops to dynamic allocation of net_device References: <20030709132910.589cf65d.shemminger@osdl.org> In-Reply-To: <20030709132910.589cf65d.shemminger@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3913 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 viro did this one... From jgarzik@pobox.com Thu Jul 10 15:40:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 15:40:55 -0700 (PDT) Received: from www.linux.org.uk (IDENT:qbDKeNZrmQm5yEbjha1NB9G1vd071C7A@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6AMen2x023550 for ; Thu, 10 Jul 2003 15:40:49 -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 19ak5o-0004nh-83; Thu, 10 Jul 2003 23:40:48 +0100 Message-ID: <3F0DEB65.20806@pobox.com> Date: Thu, 10 Jul 2003 18:40:37 -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: Stephen Hemminger CC: Jay Schulist , netdev@oss.sgi.com Subject: Re: [PATCH 2.5.74] convert appletalk/ltpc over to dynamic allocation References: <20030709132438.432fcd2b.shemminger@osdl.org> In-Reply-To: <20030709132438.432fcd2b.shemminger@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3914 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 viro did this one too... ftp://ftp.linux.org.uk/pub/people/viro/ From jgarzik@pobox.com Thu Jul 10 15:42:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 15:42:56 -0700 (PDT) Received: from www.linux.org.uk (IDENT:3xpceegHnb6QZV89SITKn5u2s3mlGXCM@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6AMgq2x024117 for ; Thu, 10 Jul 2003 15:42:52 -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 19ak7n-00051n-25; Thu, 10 Jul 2003 23:42:51 +0100 Message-ID: <3F0DEBE0.9030309@pobox.com> Date: Thu, 10 Jul 2003 18:42:40 -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: Stephen Hemminger CC: Jay Schulist , netdev@oss.sgi.com, linux-atalk@lists.netspace.org Subject: Re: [PATCH 2.5.74] convert appletalk/ipddp to dynamic allocation References: <20030709131334.79df4dca.shemminger@osdl.org> In-Reply-To: <20030709131334.79df4dca.shemminger@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3915 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 Stephen Hemminger wrote: > + > + if((err = register_netdev(dev_ipddp))) > + kfree(dev_ipddp); style otherwise, ok. From jgarzik@pobox.com Thu Jul 10 15:44:23 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 15:44:26 -0700 (PDT) Received: from www.linux.org.uk (IDENT:C88UjqQzPLNwoiRhvHcnFKqlufCnUkHo@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6AMiL2x024424 for ; Thu, 10 Jul 2003 15:44:22 -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 19ak9F-00057s-10; Thu, 10 Jul 2003 23:44:21 +0100 Message-ID: <3F0DEC3A.9070901@pobox.com> Date: Thu, 10 Jul 2003 18:44:10 -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: Stephen Hemminger CC: netdev@oss.sgi.com Subject: Re: [PATCH] convert plip to alloc_netdev References: <20030708151742.715ca49c.shemminger@osdl.org> In-Reply-To: <20030708151742.715ca49c.shemminger@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3916 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev applied From jgarzik@pobox.com Thu Jul 10 15:45:57 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 15:46:00 -0700 (PDT) Received: from www.linux.org.uk (IDENT:S1fsYb6R6tHVH/C4Lw+9cKjv5pLQypHk@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6AMju2x024734 for ; Thu, 10 Jul 2003 15:45:56 -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 19akAk-00058b-JG; Thu, 10 Jul 2003 23:45:54 +0100 Message-ID: <3F0DEC97.2040301@pobox.com> Date: Thu, 10 Jul 2003 18:45:43 -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: Stephen Hemminger CC: netdev@oss.sgi.com Subject: Re: [PATCH] (dgrs) References: <20030708151606.483604ad.shemminger@osdl.org> In-Reply-To: <20030708151606.483604ad.shemminger@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3917 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev applied From tgr@reeler.org Thu Jul 10 16:32:39 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 16:32:49 -0700 (PDT) Received: from rei.rakuen (dclient217-162-65-211.hispeed.ch [217.162.65.211]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6ANWb2x026242 for ; Thu, 10 Jul 2003 16:32:38 -0700 Received: by reeler.org id 19aktj-0008Vt-00 ; Fri, 11 Jul 2003 01:32:23 +0200 Date: Fri, 11 Jul 2003 01:32:23 +0200 From: Thomas Graf To: davem@redhat.com Cc: netdev@oss.sgi.com, tgraf@suug.ch Subject: [PATCH] make sendmsg return EDESTADDRREQ if socket is not connected and daddr was not specified Message-ID: <20030710233223.GA30577@rei.rakuen> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Encryption: "Encrypted with ROT13 using key 42" X-archive-position: 3918 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Hello Another 1003.1 fix: [EDESTADDRREQ] The socket is not connection-mode and does not have its peer address set, and no destination address was specified. fixes sendmsg in ipv{4,6}/{raw,udp} -- thomas Index: net/ipv4/raw.c =================================================================== RCS file: /cvs/tgr/linux-25/net/ipv4/raw.c,v retrieving revision 1.1.1.2 diff -u -r1.1.1.2 raw.c --- net/ipv4/raw.c 10 Jul 2003 22:58:45 -0000 1.1.1.2 +++ net/ipv4/raw.c 10 Jul 2003 23:18:04 -0000 @@ -383,7 +383,7 @@ * IP_HDRINCL is much more convenient. */ } else { - err = -EINVAL; + err = -EDESTADDRREQ; if (sk->sk_state != TCP_ESTABLISHED) goto out; daddr = inet->daddr; Index: net/ipv4/udp.c =================================================================== RCS file: /cvs/tgr/linux-25/net/ipv4/udp.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 udp.c --- net/ipv4/udp.c 9 Jul 2003 18:42:29 -0000 1.1.1.1 +++ net/ipv4/udp.c 10 Jul 2003 23:18:04 -0000 @@ -540,7 +540,7 @@ return -EINVAL; } else { if (sk->sk_state != TCP_ESTABLISHED) - return -ENOTCONN; + return -EDESTADDRREQ; daddr = inet->daddr; dport = inet->dport; /* Open fast path for connected socket. Index: net/ipv6/raw.c =================================================================== RCS file: /cvs/tgr/linux-25/net/ipv6/raw.c,v retrieving revision 1.1.1.2 diff -u -r1.1.1.2 raw.c --- net/ipv6/raw.c 10 Jul 2003 22:58:50 -0000 1.1.1.2 +++ net/ipv6/raw.c 10 Jul 2003 23:18:04 -0000 @@ -602,7 +602,7 @@ fl.oif = sin6->sin6_scope_id; } else { if (sk->sk_state != TCP_ESTABLISHED) - return(-EINVAL); + return -EDESTADDRREQ; proto = inet->num; daddr = &np->daddr; Index: net/ipv6/udp.c =================================================================== RCS file: /cvs/tgr/linux-25/net/ipv6/udp.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 udp.c --- net/ipv6/udp.c 9 Jul 2003 18:42:35 -0000 1.1.1.1 +++ net/ipv6/udp.c 10 Jul 2003 23:18:04 -0000 @@ -862,7 +862,7 @@ fl.oif = sin6->sin6_scope_id; } else { if (sk->sk_state != TCP_ESTABLISHED) - return -ENOTCONN; + return -EDESTADDRREQ; up->dport = inet->dport; daddr = &np->daddr; From hogarth@theirongiant.lochness.weebeastie.net Thu Jul 10 16:39:59 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 16:40:03 -0700 (PDT) Received: from nessie.weebeastie.net (nessie.weebeastie.net [61.8.7.205]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6ANdt2x026607 for ; Thu, 10 Jul 2003 16:39:57 -0700 Received: from theirongiant.lochness.weebeastie.net (theirongiant.lochness.weebeastie.net [10.1.1.2]) by nessie.weebeastie.net (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6ANdOg6002434 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Fri, 11 Jul 2003 09:39:24 +1000 Received: from theirongiant.lochness.weebeastie.net (localhost [127.0.0.1]) by theirongiant.lochness.weebeastie.net (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6ANdW4u017705 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 11 Jul 2003 09:39:32 +1000 Received: (from hogarth@localhost) by theirongiant.lochness.weebeastie.net (8.12.3/8.12.3/Debian-6.4) id h6ANdV23017704; Fri, 11 Jul 2003 09:39:31 +1000 Date: Fri, 11 Jul 2003 09:39:31 +1000 From: CaT To: Mika Liljeberg Cc: yoshfuji@linux-ipv6.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, pekkas@netcore.fi Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked Message-ID: <20030710233931.GG1722@zip.com.au> References: <20030710154302.GE1722@zip.com.au> <1057854432.3588.2.camel@hades> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1057854432.3588.2.camel@hades> User-Agent: Mutt/1.3.28i Organisation: Furball Inc. X-archive-position: 3919 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cat@zip.com.au Precedence: bulk X-list: netdev On Thu, Jul 10, 2003 at 07:27:13PM +0300, Mika Liljeberg wrote: > On Thu, 2003-07-10 at 18:43, CaT wrote: > > ip tunnel add sit1 mode sit remote 138.25.6.14 > > ip link set sit1 up > > ip addr add 3ffe:8001:000c:ffff::37/127 dev sit1 > > ip route add ::/0 via 3ffe:8001:000c:ffff::36 > > RTNETLINK answers: Invalid argument > > Try this: > > ip route add ::/0 dev sit1 That didn't complain but pings to the ext gw were broken. Noticed the route contained: 3ffe:8001:c:ffff::36/127 via :: dev sit1 proto kernel metric 256 mtu 1480 adv mss 1420 And having remembered /127 being mentioned as bad I changed the interface config to a netmask of /64. Dropped it and brought it up and it all works. There's something fundamental about ipv6 netmasks that I just don't understand... -- "How can I not love the Americans? They helped me with a flat tire the other day," he said. - http://www.toledoblade.com/apps/pbcs.dll/artikkel?SearchID=73139162287496&Avis=TO&Dato=20030624&Kategori=NEWS28&Lopenr=106240111&Ref=AR From tgr@reeler.org Thu Jul 10 16:45:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 16:45:22 -0700 (PDT) Received: from rei.rakuen (dclient217-162-65-211.hispeed.ch [217.162.65.211]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6ANjH2x026936 for ; Thu, 10 Jul 2003 16:45:18 -0700 Received: by reeler.org id 19al5l-00009D-00 ; Fri, 11 Jul 2003 01:44:49 +0200 Date: Fri, 11 Jul 2003 01:44:49 +0200 From: Thomas Graf To: davem@redhat.com, jmorris@intercode.com.au, yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com, tgraf@suug.ch Subject: [PATCH] IPV6: fix data offset calculation when pushing frag options {dst1opts|auth} Message-ID: <20030710234449.GB30577@rei.rakuen> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Encryption: "Encrypted with ROT13 using key 42" X-archive-position: 3920 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Hello ip6_append_data: The offset in the datagram where the payload gets copied to (transhdrlen) is not calculated correctly: the size of frag opts {dst1opt|auth} is not taken into account. This lead to overwritten payload by frag opts. yoshfuji agreed on this. patch is against 2.5.75 -- thomas Index: net/ipv6/ip6_output.c =================================================================== RCS file: /cvs/tgr/linux-25/net/ipv6/ip6_output.c,v retrieving revision 1.1.1.2 diff -u -r1.1.1.2 ip6_output.c --- net/ipv6/ip6_output.c 10 Jul 2003 22:58:50 -0000 1.1.1.2 +++ net/ipv6/ip6_output.c 10 Jul 2003 23:36:48 -0000 @@ -1247,11 +1247,9 @@ inet->cork.length = 0; inet->sndmsg_page = NULL; inet->sndmsg_off = 0; - if ((exthdrlen = rt->u.dst.header_len) != 0) { - length += exthdrlen; - transhdrlen += exthdrlen; - } - exthdrlen += opt ? opt->opt_flen : 0; + exthdrlen = rt->u.dst.header_len + opt ? opt->opt_flen : 0; + length += exthdrlen; + transhdrlen += exthdrlen; } else { rt = np->cork.rt; if (inet->cork.flags & IPCORK_OPT) From garzik@gtf.org Thu Jul 10 16:55:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 16:55:31 -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 h6ANtO2x027285 for ; Thu, 10 Jul 2003 16:55:24 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id 8FD586662; Thu, 10 Jul 2003 19:55:18 -0400 (EDT) Date: Thu, 10 Jul 2003 19:55:18 -0400 From: Jeff Garzik To: torvalds@osdl.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [BK PATCHES] more net driver merges Message-ID: <20030710235518.GA16507@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: 3921 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 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.75-netdrvr1.patch.bz2 This will update the following files: drivers/net/appletalk/cops.c | 5 - drivers/net/appletalk/ltpc.c | 5 - drivers/net/declance.c | 2 drivers/net/dgrs.c | 27 +++---- drivers/net/e100/e100_main.c | 32 +++----- drivers/net/e100/e100_phy.c | 2 drivers/net/hamradio/mkiss.c | 141 +++++++-------------------------------- drivers/net/hamradio/mkiss.h | 2 drivers/net/pcmcia/3c574_cs.c | 2 drivers/net/pcmcia/3c589_cs.c | 2 drivers/net/pcmcia/smc91c92_cs.c | 2 drivers/net/plip.c | 96 ++++++++++++-------------- drivers/net/sb1250-mac.c | 2 drivers/net/sk_mca.c | 2 drivers/net/sundance.c | 10 ++ drivers/net/tg3.c | 5 - drivers/net/tokenring/3c359.c | 2 drivers/net/tokenring/proteon.c | 1 drivers/net/tokenring/skisa.c | 1 drivers/net/via-rhine.c | 2 drivers/net/wireless/atmel_cs.c | 11 +-- drivers/net/wireless/wavelan.c | 6 + 22 files changed, 131 insertions(+), 229 deletions(-) through these ChangeSets: (03/07/10 1.1400) [netdrvr atmel_cs] kill compiler warning (jumping to "empty" label) (03/07/10 1.1399) [netdrvr wavelan] remove check_region usage (03/07/10 1.1398) [netdrvr] fix compiler warnings in 3c359, proteon, skisa tokenring drivers. (03/07/10 1.1397) [netdrvr tg3] more ULL suffixes to make gcc 3.3 happy (03/07/10 1.1396) [netdrvr dgrs] convert to using alloc_etherdev (03/07/10 1.1395) [PATCH] net/pcmcia fix fast_poll timers (HZ > 100) i think we want fast_poll to behave the same with HZ=100 and HZ=1000 (03/07/10 1.1394) [PATCH] more net driver timer fixes following patch fixes some bogus additions to jiffies (w/o HZ beeing involved) - appletalk/cops.c - appletalk/ltpc.c - declance.c - sb1250-mac.c - sk_mca.c - via-rhine.c against 2.5.73-bk (03/07/10 1.1393) [PATCH] mkiss Below patch cleans the mkiss driver. After the previous cleanup in 2.4.0-prerelease various code had become unreachable because nothing was ever setting MKISS_DRIVER_MAGIC. This fixes fixes an oops - the mkiss pointer was potencially NULL. And it also removes the MOD_{INC,DEC}_USE_COUNT calls. Alan, lemme know if you want me to cook a 2.4 patch also. Patch from Jeroen Vreeken PE1RXQ. Ralf (03/07/10 1.1392) [PATCH] convert plip to alloc_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 (03/07/10 1.1391) [e100] misc * Allow changing Wake On LAN when EEPROM disabled * Change Log updated * Version changed (03/07/10 1.1390) [e100] cu_start: timeout waiting for cu * Bug fix: 82557 (with National PHY) timeout during init [Adam Kropelin] akropel1@rochester.rr.com (03/07/10 1.1389) [netdrvr sundance] increase eeprom read timeout From mika.liljeberg@welho.com Thu Jul 10 17:04:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 17:04:20 -0700 (PDT) Received: from hades.pp.htv.fi (cs180094.pp.htv.fi [213.243.180.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6B04E2x027700 for ; Thu, 10 Jul 2003 17:04:15 -0700 Received: from hades.pp.htv.fi (localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) with ESMTP id h6B04UZj008015; Fri, 11 Jul 2003 03:04:30 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) id h6B04TQv008014; Fri, 11 Jul 2003 03:04:29 +0300 X-Authentication-Warning: hades.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked From: Mika Liljeberg To: CaT Cc: yoshfuji@linux-ipv6.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, pekkas@netcore.fi In-Reply-To: <20030710233931.GG1722@zip.com.au> References: <20030710154302.GE1722@zip.com.au> <1057854432.3588.2.camel@hades> <20030710233931.GG1722@zip.com.au> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1057881869.3588.10.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 11 Jul 2003 03:04:29 +0300 X-archive-position: 3922 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mika.liljeberg@welho.com Precedence: bulk X-list: netdev On Fri, 2003-07-11 at 02:39, CaT wrote: > And having remembered /127 being mentioned as bad I changed the > interface config to a netmask of /64. Dropped it and brought it > up and it all works. > > There's something fundamental about ipv6 netmasks that I just don't > understand... Well, the thing is that prefix:: is a special anycast address that identifies a router on the link prefix::/n, where n is the prefix length. You had configured a 127-bit link prefix, meaning that you had only one valid unicast address (last bit == 1) in addition to the router anycast address (last bit == 0). Normally, IPv6 networks are supposed to use 64-bit on-link prefixes but the implementation can be written in such a way that other prefix lengths can be configured. Setting your tunnel prefix to /64 is certainly the right thing to do. MikaL From yoshfuji@linux-ipv6.org Thu Jul 10 17:16:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 17:17:04 -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 h6B0Gm2x028163 for ; Thu, 10 Jul 2003 17:16:53 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h6B0IEBo003849; Fri, 11 Jul 2003 09:18:14 +0900 Date: Fri, 11 Jul 2003 09:18:14 +0900 (JST) Message-Id: <20030711.091814.128467921.yoshfuji@linux-ipv6.org> To: tgraf@suug.ch, davem@redhat.com, jmorris@intercode.com.au Cc: netdev@oss.sgi.com Subject: Re: [PATCH] IPV6: fix data offset calculation when pushing frag options {dst1opts|auth} From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20030710234449.GB30577@rei.rakuen> References: <20030710234449.GB30577@rei.rakuen> 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: 3923 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 <20030710234449.GB30577@rei.rakuen> (at Fri, 11 Jul 2003 01:44:49 +0200), Thomas Graf says: > yoshfuji agreed on this. I agreed, but > - exthdrlen += opt ? opt->opt_flen : 0; > + exthdrlen = rt->u.dst.header_len + opt ? opt->opt_flen : 0; Well, sorry, this was wrong. D: fix offset of payload with extension header. D: based on patch 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.33 diff -u -r1.33 ip6_output.c --- linux-2.5/net/ipv6/ip6_output.c 9 Jul 2003 05:55:17 -0000 1.33 +++ linux-2.5/net/ipv6/ip6_output.c 10 Jul 2003 22:50:33 -0000 @@ -1247,11 +1247,9 @@ inet->cork.length = 0; inet->sndmsg_page = NULL; inet->sndmsg_off = 0; - if ((exthdrlen = rt->u.dst.header_len) != 0) { - length += exthdrlen; - transhdrlen += exthdrlen; - } - exthdrlen += opt ? opt->opt_flen : 0; + exthdrlen += rt->u.dst.header_len + (opt ? opt->opt_flen : 0); + length += exthdrlen; + transhdrlen += exthdrlen; } else { rt = np->cork.rt; if (inet->cork.flags & IPCORK_OPT) --yoshfuji From yoshfuji@linux-ipv6.org Thu Jul 10 17:23:08 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 17:23:19 -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 h6B0N72x028530 for ; Thu, 10 Jul 2003 17:23:08 -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 h6B0OZBo003995; Fri, 11 Jul 2003 09:24:35 +0900 Date: Fri, 11 Jul 2003 09:24:35 +0900 (JST) Message-Id: <20030711.092435.64560380.yoshfuji@linux-ipv6.org> To: tgraf@suug.ch, davem@redhat.com, jmorris@intercode.com.au Cc: netdev@oss.sgi.com Subject: Re: [PATCH] IPV6: fix data offset calculation when pushing frag options {dst1opts|auth} From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20030711.091814.128467921.yoshfuji@linux-ipv6.org> References: <20030710234449.GB30577@rei.rakuen> <20030711.091814.128467921.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: 3924 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 <20030711.091814.128467921.yoshfuji@linux-ipv6.org> (at Fri, 11 Jul 2003 09:18:14 +0900 (JST)), YOSHIFUJI Hideaki / $B5HF#1QL@(B says: > D: fix offset of payload with extension header. > D: based on patch from Thomas Graf Oops, thas wrong again; please use this instead... 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.33 diff -u -r1.33 ip6_output.c --- linux-2.5/net/ipv6/ip6_output.c 9 Jul 2003 05:55:17 -0000 1.33 +++ linux-2.5/net/ipv6/ip6_output.c 10 Jul 2003 23:02:56 -0000 @@ -1247,11 +1247,9 @@ inet->cork.length = 0; inet->sndmsg_page = NULL; inet->sndmsg_off = 0; - if ((exthdrlen = rt->u.dst.header_len) != 0) { - length += exthdrlen; - transhdrlen += exthdrlen; - } - exthdrlen += opt ? opt->opt_flen : 0; + exthdrlen = rt->u.dst.header_len + (opt ? opt->opt_flen : 0); + length += exthdrlen; + transhdrlen += exthdrlen; } else { rt = np->cork.rt; if (inet->cork.flags & IPCORK_OPT) -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From davem@redhat.com Thu Jul 10 17:27:21 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 17:27:29 -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 h6B0RK2x028873 for ; Thu, 10 Jul 2003 17:27:21 -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 RAA28070; Thu, 10 Jul 2003 17:18:33 -0700 Date: Thu, 10 Jul 2003 17:18:33 -0700 (PDT) Message-Id: <20030710.171833.34738924.davem@redhat.com> To: yoshfuji@linux-ipv6.org Cc: tgraf@suug.ch, jmorris@intercode.com.au, netdev@oss.sgi.com Subject: Re: [PATCH] IPV6: fix data offset calculation when pushing frag options {dst1opts|auth} From: "David S. Miller" In-Reply-To: <20030711.092435.64560380.yoshfuji@linux-ipv6.org> References: <20030710234449.GB30577@rei.rakuen> <20030711.091814.128467921.yoshfuji@linux-ipv6.org> <20030711.092435.64560380.yoshfuji@linux-ipv6.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=iso-2022-jp Content-Transfer-Encoding: 7bit X-archive-position: 3925 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: YOSHIFUJI Hideaki / $B5HF#1QL@(B Date: Fri, 11 Jul 2003 09:24:35 +0900 (JST) In article <20030711.091814.128467921.yoshfuji@linux-ipv6.org> (at Fri, 11 Jul 2003 09:18:14 +0900 (JST)), YOSHIFUJI Hideaki / $B5HF#1QL@(B says: > D: fix offset of payload with extension header. > D: based on patch from Thomas Graf Oops, thas wrong again; please use this instead... Applied, thanks. From tgr@reeler.org Thu Jul 10 17:27:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 17:27:40 -0700 (PDT) Received: from rei.rakuen (dclient217-162-65-211.hispeed.ch [217.162.65.211]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6B0RX2x028879 for ; Thu, 10 Jul 2003 17:27:34 -0700 Received: by reeler.org id 19alkn-0000KQ-00 ; Fri, 11 Jul 2003 02:27:13 +0200 Date: Fri, 11 Jul 2003 02:27:13 +0200 From: Thomas Graf To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@redhat.com, jmorris@intercode.com.au, netdev@oss.sgi.com Subject: Re: [PATCH] IPV6: fix data offset calculation when pushing frag options {dst1opts|auth} Message-ID: <20030711002713.GC30577@rei.rakuen> References: <20030710234449.GB30577@rei.rakuen> <20030711.091814.128467921.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030711.091814.128467921.yoshfuji@linux-ipv6.org> X-Encryption: "Encrypted with ROT13 using key 42" X-archive-position: 3926 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev * yoshfuji@linux-ipv6.org wrote: > + exthdrlen += rt->u.dst.header_len + (opt ? opt->opt_flen : 0); exthdrlen is uninitialized. New patch: Index: net/ipv6/ip6_output.c =================================================================== RCS file: /cvs/tgr/linux-25/net/ipv6/ip6_output.c,v retrieving revision 1.1.1.2 diff -u -r1.1.1.2 ip6_output.c --- net/ipv6/ip6_output.c 10 Jul 2003 22:58:50 -0000 1.1.1.2 +++ net/ipv6/ip6_output.c 10 Jul 2003 23:36:48 -0000 @@ -1247,11 +1247,9 @@ inet->cork.length = 0; inet->sndmsg_page = NULL; inet->sndmsg_off = 0; - if ((exthdrlen = rt->u.dst.header_len) != 0) { - length += exthdrlen; - transhdrlen += exthdrlen; - } - exthdrlen += opt ? opt->opt_flen : 0; + exthdrlen = rt->u.dst.header_len + (opt ? opt->opt_flen : 0); + length += exthdrlen; + transhdrlen += exthdrlen; } else { rt = np->cork.rt; if (inet->cork.flags & IPCORK_OPT) From davem@redhat.com Thu Jul 10 17:31:09 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 17:31:15 -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 h6B0V82x029519 for ; Thu, 10 Jul 2003 17:31:09 -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 RAA28108; Thu, 10 Jul 2003 17:22:33 -0700 Date: Thu, 10 Jul 2003 17:22:32 -0700 (PDT) Message-Id: <20030710.172232.02275886.davem@redhat.com> To: tgraf@suug.ch Cc: yoshfuji@linux-ipv6.org, jmorris@intercode.com.au, netdev@oss.sgi.com Subject: Re: [PATCH] IPV6: fix data offset calculation when pushing frag options {dst1opts|auth} From: "David S. Miller" In-Reply-To: <20030711002713.GC30577@rei.rakuen> References: <20030710234449.GB30577@rei.rakuen> <20030711.091814.128467921.yoshfuji@linux-ipv6.org> <20030711002713.GC30577@rei.rakuen> 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: 3927 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: Thomas Graf Date: Fri, 11 Jul 2003 02:27:13 +0200 * yoshfuji@linux-ipv6.org wrote: > + exthdrlen += rt->u.dst.header_len + (opt ? opt->opt_flen : 0); exthdrlen is uninitialized. Yoshfuji already fixed this, see his followup. From tgr@reeler.org Thu Jul 10 17:33:13 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 17:33:17 -0700 (PDT) Received: from rei.rakuen (dclient217-162-65-211.hispeed.ch [217.162.65.211]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6B0XC2x029832 for ; Thu, 10 Jul 2003 17:33:13 -0700 Received: by reeler.org id 19alqG-0000Lz-00 ; Fri, 11 Jul 2003 02:32:52 +0200 Date: Fri, 11 Jul 2003 02:32:52 +0200 From: Thomas Graf To: "David S. Miller" Cc: yoshfuji@linux-ipv6.org, jmorris@intercode.com.au, netdev@oss.sgi.com Subject: Re: [PATCH] IPV6: fix data offset calculation when pushing frag options {dst1opts|auth} Message-ID: <20030711003252.GD30577@rei.rakuen> References: <20030710234449.GB30577@rei.rakuen> <20030711.091814.128467921.yoshfuji@linux-ipv6.org> <20030711002713.GC30577@rei.rakuen> <20030710.172232.02275886.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030710.172232.02275886.davem@redhat.com> X-Encryption: "Encrypted with ROT13 using key 42" X-archive-position: 3928 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev * davem@redhat.com wrote: > From: Thomas Graf > Date: Fri, 11 Jul 2003 02:27:13 +0200 > > * yoshfuji@linux-ipv6.org wrote: > > + exthdrlen += rt->u.dst.header_len + (opt ? opt->opt_flen : 0); > > exthdrlen is uninitialized. > > Yoshfuji already fixed this, see his followup. Yep, received that mail while writing the last one ;) -- thomas From yoshfuji@linux-ipv6.org Thu Jul 10 17:34:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 17:34:19 -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 h6B0YE2x030081 for ; Thu, 10 Jul 2003 17:34: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 h6B0ZkBo008694; Fri, 11 Jul 2003 09:35:46 +0900 Date: Fri, 11 Jul 2003 09:35:46 +0900 (JST) Message-Id: <20030711.093546.12708723.yoshfuji@linux-ipv6.org> To: davem@redhat.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org CC: tgraf@suug.ch Subject: Re: [PATCH] make sendmsg return EDESTADDRREQ if socket is not connected and daddr was not specified From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20030710233223.GA30577@rei.rakuen> References: <20030710233223.GA30577@rei.rakuen> 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: 3929 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 <20030710233223.GA30577@rei.rakuen> (at Fri, 11 Jul 2003 01:32:23 +0200), Thomas Graf says: > [EDESTADDRREQ] > The socket is not connection-mode and does not have its peer > address set, and no destination address was specified. > > fixes sendmsg in ipv{4,6}/{raw,udp} I aggeed on this, however we may want to do for whole tree at same time. How do you think, folks? --yoshfuji From yoshfuji@linux-ipv6.org Thu Jul 10 17:35:30 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 17:35:34 -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 h6B0ZS2x030332 for ; Thu, 10 Jul 2003 17:35: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 h6B0b1Bo009650; Fri, 11 Jul 2003 09:37:01 +0900 Date: Fri, 11 Jul 2003 09:37:01 +0900 (JST) Message-Id: <20030711.093701.109452621.yoshfuji@linux-ipv6.org> To: davem@redhat.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Cc: tgraf@suug.ch Subject: Re: [PATCH] make sendmsg return EDESTADDRREQ if socket is not connected and daddr was not specified From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20030711.093546.12708723.yoshfuji@linux-ipv6.org> References: <20030710233223.GA30577@rei.rakuen> <20030711.093546.12708723.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: 3930 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 <20030711.093546.12708723.yoshfuji@linux-ipv6.org> (at Fri, 11 Jul 2003 09:35:46 +0900 (JST)), YOSHIFUJI Hideaki / $B5HF#1QL@(B says: > In article <20030710233223.GA30577@rei.rakuen> (at Fri, 11 Jul 2003 01:32:23 +0200), Thomas Graf says: > > > [EDESTADDRREQ] > > The socket is not connection-mode and does not have its peer > > address set, and no destination address was specified. > > > > fixes sendmsg in ipv{4,6}/{raw,udp} > > I aggeed on this, however we may want to do for whole tree at same time. ~~~~~~agreed > How do you think, folks? --yoshfuji From davem@redhat.com Thu Jul 10 17:37:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 17:37:56 -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 h6B0br2x030770 for ; Thu, 10 Jul 2003 17:37: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 RAA28164; Thu, 10 Jul 2003 17:29:23 -0700 Date: Thu, 10 Jul 2003 17:29:23 -0700 (PDT) Message-Id: <20030710.172923.27804984.davem@redhat.com> To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com, tgraf@suug.ch Subject: Re: [PATCH] make sendmsg return EDESTADDRREQ if socket is not connected and daddr was not specified From: "David S. Miller" In-Reply-To: <20030711.093546.12708723.yoshfuji@linux-ipv6.org> References: <20030710233223.GA30577@rei.rakuen> <20030711.093546.12708723.yoshfuji@linux-ipv6.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=iso-2022-jp Content-Transfer-Encoding: 7bit X-archive-position: 3931 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: YOSHIFUJI Hideaki / $B5HF#1QL@(B Date: Fri, 11 Jul 2003 09:35:46 +0900 (JST) I aggeed on this, however we may want to do for whole tree at same time. How do you think, folks? Sure, just send more patches relative to this one :-) From davem@redhat.com Thu Jul 10 17:38:07 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 17:38:10 -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 h6B0c62x030799 for ; Thu, 10 Jul 2003 17:38:06 -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 RAA28173; Thu, 10 Jul 2003 17:29:36 -0700 Date: Thu, 10 Jul 2003 17:29:35 -0700 (PDT) Message-Id: <20030710.172935.77037127.davem@redhat.com> To: tgraf@suug.ch Cc: netdev@oss.sgi.com Subject: Re: [PATCH] make sendmsg return EDESTADDRREQ if socket is not connected and daddr was not specified From: "David S. Miller" In-Reply-To: <20030710233223.GA30577@rei.rakuen> References: <20030710233223.GA30577@rei.rakuen> 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: 3932 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: Thomas Graf Date: Fri, 11 Jul 2003 01:32:23 +0200 [EDESTADDRREQ] The socket is not connection-mode and does not have its peer address set, and no destination address was specified. fixes sendmsg in ipv{4,6}/{raw,udp} Applied, thanks Thomas. From yoshfuji@linux-ipv6.org Thu Jul 10 17:40:05 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 17:40:08 -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 h6B0e32x031393 for ; Thu, 10 Jul 2003 17:40: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 h6B0faBo013245; Fri, 11 Jul 2003 09:41:37 +0900 Date: Fri, 11 Jul 2003 09:41:36 +0900 (JST) Message-Id: <20030711.094136.38023048.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: netdev@oss.sgi.com, tgraf@suug.ch Subject: Re: [PATCH] make sendmsg return EDESTADDRREQ if socket is not connected and daddr was not specified From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20030710.172923.27804984.davem@redhat.com> References: <20030710233223.GA30577@rei.rakuen> <20030711.093546.12708723.yoshfuji@linux-ipv6.org> <20030710.172923.27804984.davem@redhat.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=iso-2022-jp Content-Transfer-Encoding: 7bit X-archive-position: 3933 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 <20030710.172923.27804984.davem@redhat.com> (at Thu, 10 Jul 2003 17:29:23 -0700 (PDT)), "David S. Miller" says: > From: YOSHIFUJI Hideaki / $B5HF#1QL@(B > Date: Fri, 11 Jul 2003 09:35:46 +0900 (JST) > > I aggeed on this, however we may want to do for whole tree at same time. > How do you think, folks? > > Sure, just send more patches relative to this one :-) Okay, I'll do this as much as I can do... --yoshfuji From andre@tomt.net Thu Jul 10 18:49:13 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 18:49:21 -0700 (PDT) Received: from mail.skjellin.no (qmailr@mail.skjellin.no [80.239.42.67]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6B1nB2x032162 for ; Thu, 10 Jul 2003 18:49:13 -0700 Received: (qmail 31648 invoked by uid 1006); 11 Jul 2003 01:54:08 -0000 Received: from andre@tomt.net by ns1 by uid 1003 with qmail-scanner-1.16 (sophie: 2.14/3.69. spamassassin: 2.55. Clear:. Processed in 0.024238 secs); 11 Jul 2003 01:54:08 -0000 Received: from slask.tomt.net (HELO slurv.pasop.tomt.net) (andre@tomt.net@217.8.136.222) by mail.skjellin.no with SMTP; 11 Jul 2003 01:54:08 -0000 Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked From: Andre Tomt To: linux-kernel@vger.kernel.org Cc: Mika Liljeberg , netdev@oss.sgi.com In-Reply-To: <1057881869.3588.10.camel@hades> References: <20030710154302.GE1722@zip.com.au> <1057854432.3588.2.camel@hades> <20030710233931.GG1722@zip.com.au> <1057881869.3588.10.camel@hades> Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <1057888154.26854.324.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 11 Jul 2003 03:49:14 +0200 Content-Transfer-Encoding: 8bit X-archive-position: 3934 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andre@tomt.net Precedence: bulk X-list: netdev On fre, 2003-07-11 at 02:04, Mika Liljeberg wrote: > Well, the thing is that prefix:: is a special anycast address that > identifies a router on the link prefix::/n, where n is the prefix > length. You had configured a 127-bit link prefix, meaning that you had > only one valid unicast address (last bit == 1) in addition to the router > anycast address (last bit == 0). Thanks for the explanation, I've been struggling to understand what Yoshfuji tried to explain to me earlier on this topic (see "IPv6 bugs introduced in 2.4.21" - ie. my bogus bugreport), now it all makes perfect sense :-) > Normally, IPv6 networks are supposed to use 64-bit on-link prefixes but > the implementation can be written in such a way that other prefix > lengths can be configured. > > Setting your tunnel prefix to /64 is certainly the right thing to do. If you don't have anything but one /64 for example.. I guess /126's would be ok as you could rule out the the anycast address? It will probably work with Linux - but is it wrong in any sense, other than "breaking" with EUI-64/autoconfiguration? -- Cheers, André Tomt andre@tomt.net From yoshfuji@linux-ipv6.org Thu Jul 10 19:02:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 19:02:33 -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 h6B22R2x032572 for ; Thu, 10 Jul 2003 19:02:28 -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 h6B23wBo016296; Fri, 11 Jul 2003 11:03:58 +0900 Date: Fri, 11 Jul 2003 11:03:58 +0900 (JST) Message-Id: <20030711.110358.32018240.yoshfuji@linux-ipv6.org> To: andre@tomt.net Cc: linux-kernel@vger.kernel.org, mika.liljeberg@welho.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling broken From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <1057888154.26854.324.camel@localhost> References: <20030710233931.GG1722@zip.com.au> <1057881869.3588.10.camel@hades> <1057888154.26854.324.camel@localhost> 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: 3935 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 <1057888154.26854.324.camel@localhost> (at 11 Jul 2003 03:49:14 +0200), Andre Tomt says: > Thanks for the explanation, I've been struggling to understand what > Yoshfuji tried to explain to me earlier on this topic (see "IPv6 bugs > introduced in 2.4.21" - ie. my bogus bugreport), now it all makes > perfect sense :-) Sorry for my poor explanation... > If you don't have anything but one /64 for example.. I guess /126's > would be ok as you could rule out the the anycast address? It will > probably work with Linux - but is it wrong in any sense, other than > "breaking" with EUI-64/autoconfiguration? I don't think so, but I won't recoomend doing this. (I even don't assign global addresses to p-t-p interface at all.) --yoshfuji From mika.liljeberg@welho.com Thu Jul 10 19:03:32 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 19:03:36 -0700 (PDT) Received: from hades.pp.htv.fi (cs180094.pp.htv.fi [213.243.180.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6B23U2x032753 for ; Thu, 10 Jul 2003 19:03:32 -0700 Received: from hades.pp.htv.fi (localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) with ESMTP id h6B23wZj008552; Fri, 11 Jul 2003 05:03:58 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) id h6B23v3B008551; Fri, 11 Jul 2003 05:03:57 +0300 X-Authentication-Warning: hades.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked From: Mika Liljeberg To: Andre Tomt Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <1057888154.26854.324.camel@localhost> References: <20030710154302.GE1722@zip.com.au> <1057854432.3588.2.camel@hades> <20030710233931.GG1722@zip.com.au> <1057881869.3588.10.camel@hades> <1057888154.26854.324.camel@localhost> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1057889037.3589.42.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 11 Jul 2003 05:03:57 +0300 X-archive-position: 3936 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mika.liljeberg@welho.com Precedence: bulk X-list: netdev On Fri, 2003-07-11 at 04:49, Andre Tomt wrote: > > Setting your tunnel prefix to /64 is certainly the right thing to do. > > If you don't have anything but one /64 for example.. I guess /126's > would be ok as you could rule out the the anycast address? It will > probably work with Linux - but is it wrong in any sense, other than > "breaking" with EUI-64/autoconfiguration? It doesn't really make sense to use a prefix longer then /64. The last 64 bits are generally reserved for interface ID. What you can do, though, is not configure a link prefix for the tunnel at all. I.e. you can add the local tunnel end-point as a /128. This won't create an on-link route in the routing table, so you need to point the default route to the interface rather than the peer end-point. For example: ifconfig sit0 add 3ffe:dead:beef::dead:beef/128 ip route add ::/0 dev sit0 Cheers, MikaL From jgarzik@pobox.com Thu Jul 10 21:52:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 21:52:54 -0700 (PDT) Received: from www.linux.org.uk (IDENT:/g2yAGj+1DI8JD4+8VH2VBFWXbGubaom@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6B4qn2x002866 for ; Thu, 10 Jul 2003 21:52:50 -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 19am9v-0006yS-GS; Fri, 11 Jul 2003 01:53:11 +0100 Message-ID: <3F0E0A6C.5000703@pobox.com> Date: Thu, 10 Jul 2003 20:53:00 -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: "David S. Miller" CC: scott.feldman@intel.com, willy@debian.org, netdev@oss.sgi.com Subject: Re: [PATCH] netdev_ops References: <20030710.133737.41660806.davem@redhat.com> In-Reply-To: <20030710.133737.41660806.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3938 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev David S. Miller wrote: > From: "Feldman, Scott" > Date: Thu, 10 Jul 2003 01:18:50 -0700 > > With HAVE_NETDEV_OPS, you're right, we're maintaining the wrapper > code outside the kernel. But, it does leave the possibility of > having a shared backwards compatibility code for multiple (all?) > drivers for those stuck with supporting kernels without netdev_ops. > > And precisely I am showing you how all this backwards compat > stuff is going to hurt you. You can never truly take advantage > of things that eliminate duplicated code in all the drivers, > and this netdev_ops case is a great example. Actually there is a solution that IMO will make everybody happy. Lemme finish writing up my comments to Matthew... Jeff From pekkas@netcore.fi Thu Jul 10 21:52:08 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 21:52:12 -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 h6B4q62x002808 for ; Thu, 10 Jul 2003 21:52:07 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6B4pu324776; Fri, 11 Jul 2003 07:51:57 +0300 Date: Fri, 11 Jul 2003 07:51:56 +0300 (EEST) From: Pekka Savola To: Andre Tomt cc: linux-kernel@vger.kernel.org, Mika Liljeberg , Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked In-Reply-To: <1057888154.26854.324.camel@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3937 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 11 Jul 2003, Andre Tomt wrote: > On fre, 2003-07-11 at 02:04, Mika Liljeberg wrote: > > Well, the thing is that prefix:: is a special anycast address that > > identifies a router on the link prefix::/n, where n is the prefix > > length. You had configured a 127-bit link prefix, meaning that you had > > only one valid unicast address (last bit == 1) in addition to the router > > anycast address (last bit == 0). > > Thanks for the explanation, I've been struggling to understand what > Yoshfuji tried to explain to me earlier on this topic (see "IPv6 bugs > introduced in 2.4.21" - ie. my bogus bugreport), now it all makes > perfect sense :-) Well, the system may make some sense, but IMHO, there is still zero sense in policing this thing when you add a route. That's just plain bogus. This is a bug which must be fixed ASAP. -- 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 mika.liljeberg@welho.com Thu Jul 10 22:19:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 22:19:45 -0700 (PDT) Received: from hades.pp.htv.fi (cs180094.pp.htv.fi [213.243.180.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6B5JZ2x003553 for ; Thu, 10 Jul 2003 22:19:37 -0700 Received: from hades.pp.htv.fi (localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) with ESMTP id h6B5K1Zj009247; Fri, 11 Jul 2003 08:20:01 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) id h6B5K0Wc009227; Fri, 11 Jul 2003 08:20:00 +0300 X-Authentication-Warning: hades.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked From: Mika Liljeberg To: Pekka Savola Cc: Andre Tomt , linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1057900800.3588.50.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 11 Jul 2003 08:20:00 +0300 X-archive-position: 3939 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mika.liljeberg@welho.com Precedence: bulk X-list: netdev On Fri, 2003-07-11 at 07:51, Pekka Savola wrote: > Well, the system may make some sense, but IMHO, there is still zero sense > in policing this thing when you add a route. That's just plain bogus. > This is a bug which must be fixed ASAP. Correct me if I'm wrong but I think in this case the interface had forwarding enabled and the sanity check in fact prevented a default route pointing to the node itself from being configured. Otherwise I fully agree. The subnet router anycast address doesn't warrant any special handling. MikaL From pekkas@netcore.fi Thu Jul 10 22:22:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 22:22:57 -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 h6B5Mp2x003867 for ; Thu, 10 Jul 2003 22:22:52 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6B5Meb24998; Fri, 11 Jul 2003 08:22:40 +0300 Date: Fri, 11 Jul 2003 08:22:39 +0300 (EEST) From: Pekka Savola To: Mika Liljeberg cc: Andre Tomt , , Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked In-Reply-To: <1057900800.3588.50.camel@hades> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3940 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 11 Jul 2003, Mika Liljeberg wrote: > On Fri, 2003-07-11 at 07:51, Pekka Savola wrote: > > Well, the system may make some sense, but IMHO, there is still zero sense > > in policing this thing when you add a route. That's just plain bogus. > > This is a bug which must be fixed ASAP. > > Correct me if I'm wrong but I think in this case the interface had > forwarding enabled and the sanity check in fact prevented a default > route pointing to the node itself from being configured. > > Otherwise I fully agree. The subnet router anycast address doesn't > warrant any special handling. If that's the case, it's OK -- it's OK, I don't remember the details. (It might be nice to have configurable /proc option on whether to enable the subnet router anycast address at all, but that's also a different story..) -- 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 cip_tech@yahoo.com Thu Jul 10 22:29:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 22:29:30 -0700 (PDT) Received: from web14511.mail.yahoo.com (web14511.mail.yahoo.com [216.136.226.29]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6B5TQ2x004198 for ; Thu, 10 Jul 2003 22:29:27 -0700 Message-ID: <20030711052926.10588.qmail@web14511.mail.yahoo.com> Received: from [193.231.184.146] by web14511.mail.yahoo.com via HTTP; Thu, 10 Jul 2003 22:29:26 PDT Date: Thu, 10 Jul 2003 22:29:26 -0700 (PDT) From: cip m Subject: Beginner To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-551772643-1057901366=:9880" X-archive-position: 3941 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cip_tech@yahoo.com Precedence: bulk X-list: netdev --0-551772643-1057901366=:9880 Content-Type: text/plain; charset=us-ascii Hi, Can somebody please help me ? I want to become a linux developer and I ned few tips about what languages I need to know and what other knowledge do I need ? Thank's CIPRIAN --------------------------------- Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! --0-551772643-1057901366=:9880 Content-Type: text/html; charset=us-ascii

Hi,

Can somebody please help me ?

I want to become a linux developer and I ned few tips about what languages I need to know and what other knowledge do I need ?

Thank's

CIPRIAN

Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month! --0-551772643-1057901366=:9880-- From yoshfuji@linux-ipv6.org Thu Jul 10 22:37:59 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Jul 2003 22:38:03 -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 h6B5bv2x004539 for ; Thu, 10 Jul 2003 22:37:58 -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 h6B5dQBo018975; Fri, 11 Jul 2003 14:39:26 +0900 Date: Fri, 11 Jul 2003 14:39:26 +0900 (JST) Message-Id: <20030711.143926.599349332.yoshfuji@linux-ipv6.org> To: pekkas@netcore.fi Cc: mika.liljeberg@welho.com, andre@tomt.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <1057900800.3588.50.camel@hades> 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 XEmacs 21.4.6 (Common Lisp) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3942 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 Fri, 11 Jul 2003 08:22:39 +0300 (EEST)), Pekka Savola says: > (It might be nice to have configurable /proc option on whether to enable > the subnet router anycast address at all, but that's also a different > story..) I don't like this while I would be ok to have configuration option not to support anycast. --yoshfuji From pekkas@netcore.fi Fri Jul 11 01:46:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 01:46:26 -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 h6B8kF2x006679 for ; Fri, 11 Jul 2003 01:46:16 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6B8k1826465; Fri, 11 Jul 2003 11:46:01 +0300 Date: Fri, 11 Jul 2003 11:46:00 +0300 (EEST) From: Pekka Savola To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: mika.liljeberg@welho.com, , , Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked In-Reply-To: <20030711.143926.599349332.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 3943 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 Fri, 11 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote: > In article (at Fri, 11 Jul 2003 08:22:39 +0300 (EEST)), Pekka Savola says: > > > (It might be nice to have configurable /proc option on whether to enable > > the subnet router anycast address at all, but that's also a different > > story..) > > I don't like this > while I would be ok to have configuration option > not to support anycast. With "not to support anycast" you probably meant "not to support subnet-router anycast address [automatically, in the kernel, as now]" ? These are entirely different things. (Note that if there's a user-level API for setting anycast addresses, one could kick the subnet-router anycast address out of the kernel too. Whether that's desirable is another thing.) -- 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 yoshfuji@linux-ipv6.org Fri Jul 11 02:03:21 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 02:03:27 -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 h6B93J2x007136 for ; Fri, 11 Jul 2003 02:03:20 -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 h6B94nBo020844; Fri, 11 Jul 2003 18:04:49 +0900 Date: Fri, 11 Jul 2003 18:04:49 +0900 (JST) Message-Id: <20030711.180449.126456521.yoshfuji@linux-ipv6.org> To: pekkas@netcore.fi Cc: mika.liljeberg@welho.com, andre@tomt.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20030711.143926.599349332.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: 3944 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 Fri, 11 Jul 2003 11:46:00 +0300 (EEST)), Pekka Savola says: > > I don't like this > > while I would be ok to have configuration option > > not to support anycast. > > With "not to support anycast" you probably meant "not to support > subnet-router anycast address [automatically, in the kernel, as now]" ? > These are entirely different things. I meant disabling anycast entirely. > (Note that if there's a user-level API for setting anycast addresses, one > could kick the subnet-router anycast address out of the kernel too. > Whether that's desirable is another thing.) We have but we cannot; it is refcnt'ed. --yoshfuji From mika.penttila@kolumbus.fi Fri Jul 11 02:33:43 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 02:33:53 -0700 (PDT) Received: from notes.hallinto.turkuamk.fi (notes.hallinto.turkuamk.fi [195.148.215.149]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6B9Xf2x009008 for ; Fri, 11 Jul 2003 02:33:43 -0700 Received: from kolumbus.fi ([193.166.244.70]) by marconi.hallinto.turkuamk.fi (Lotus Domino Release 5.0.8) with ESMTP id 2003071112345896:20188 ; Fri, 11 Jul 2003 12:34:58 +0300 Message-ID: <3F0E85E6.7050001@kolumbus.fi> Date: Fri, 11 Jul 2003 12:39:50 +0300 From: =?ISO-8859-1?Q?Mika_Penttil=E4?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: YOSHIFUJI@oss.sgi.com CC: pekkas@netcore.fi, mika.liljeberg@welho.com, andre@tomt.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked References: <20030711.143926.599349332.yoshfuji@linux-ipv6.org> <20030711.180449.126456521.yoshfuji@linux-ipv6.org> X-MIMETrack: Itemize by SMTP Server on marconi.hallinto.turkuamk.fi/TAMK(Release 5.0.8 |June 18, 2001) at 11.07.2003 12:34:59, Serialize by Router on notes.hallinto.turkuamk.fi/TAMK(Release 5.0.10 |March 22, 2002) at 11.07.2003 12:34:29, Serialize complete at 11.07.2003 12:34:29 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-archive-position: 3945 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mika.penttila@kolumbus.fi Precedence: bulk X-list: netdev Who adds the subnet router anycast address, kernel itself? Since what? I don't see this in 2.5. --Mika YOSHIFUJI Hideaki / ???? wrote: >In article (at Fri, 11 Jul 2003 11:46:00 +0300 (EEST)), Pekka Savola says: > > > >>>I don't like this >>>while I would be ok to have configuration option >>>not to support anycast. >>> >>> >>With "not to support anycast" you probably meant "not to support >>subnet-router anycast address [automatically, in the kernel, as now]" ? >>These are entirely different things. >> >> > >I meant disabling anycast entirely. > > > >>(Note that if there's a user-level API for setting anycast addresses, one >>could kick the subnet-router anycast address out of the kernel too. >>Whether that's desirable is another thing.) >> >> > >We have but we cannot; it is refcnt'ed. > >--yoshfuji >- >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 pekkas@netcore.fi Fri Jul 11 03:04:10 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 03:04:14 -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 h6BA492x011008 for ; Fri, 11 Jul 2003 03:04:10 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6BA3sb27113; Fri, 11 Jul 2003 13:03:55 +0300 Date: Fri, 11 Jul 2003 13:03:54 +0300 (EEST) From: Pekka Savola To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: mika.liljeberg@welho.com, , , Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked In-Reply-To: <20030711.180449.126456521.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 3946 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 Fri, 11 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote: > In article (at Fri, 11 Jul 2003 11:46:00 +0300 (EEST)), Pekka Savola says: > > > I don't like this > > > while I would be ok to have configuration option > > > not to support anycast. > > > > With "not to support anycast" you probably meant "not to support > > subnet-router anycast address [automatically, in the kernel, as now]" ? > > These are entirely different things. > > I meant disabling anycast entirely. Oh, I'm not advocating that; however, being able to turn off the subnet router anycast address might be a plus. > > (Note that if there's a user-level API for setting anycast addresses, one > > could kick the subnet-router anycast address out of the kernel too. > > Whether that's desirable is another thing.) > > We have but we cannot; it is refcnt'ed. I don't understand what you mean. Refcnt'ed by a userland process, so that if you'd want the subnet-router anycast address, the whole time a process (like radvd) should be running.. or what? -- 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 yoshfuji@linux-ipv6.org Fri Jul 11 03:45:47 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 03:45:54 -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 h6BAjh2x011810 for ; Fri, 11 Jul 2003 03:45:46 -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 h6BAlDBo021370; Fri, 11 Jul 2003 19:47:13 +0900 Date: Fri, 11 Jul 2003 19:47:13 +0900 (JST) Message-Id: <20030711.194713.21412719.yoshfuji@linux-ipv6.org> To: pekkas@netcore.fi Cc: mika.liljeberg@welho.com, andre@tomt.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20030711.180449.126456521.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: 3947 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 Fri, 11 Jul 2003 13:03:54 +0300 (EEST)), Pekka Savola says: > > We have but we cannot; it is refcnt'ed. > > I don't understand what you mean. Refcnt'ed by a userland process, so > that if you'd want the subnet-router anycast address, the whole time a > process (like radvd) should be running.. or what? Kernel has refcnt for subnet router anycast address. Ref/dereference from userspace is done via socket. You cannot derefer subnet router anycast address from userspace if the socket hasn't refered it. --yoshfuji From pekkas@netcore.fi Fri Jul 11 03:48:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 03:48:07 -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 h6BAm12x012045 for ; Fri, 11 Jul 2003 03:48:02 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6BAlmF27388; Fri, 11 Jul 2003 13:47:48 +0300 Date: Fri, 11 Jul 2003 13:47:48 +0300 (EEST) From: Pekka Savola To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: mika.liljeberg@welho.com, , , Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked In-Reply-To: <20030711.194713.21412719.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 3948 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 Fri, 11 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote: > In article (at Fri, 11 Jul 2003 13:03:54 +0300 (EEST)), Pekka Savola says: > > > > We have but we cannot; it is refcnt'ed. > > > > I don't understand what you mean. Refcnt'ed by a userland process, so > > that if you'd want the subnet-router anycast address, the whole time a > > process (like radvd) should be running.. or what? > > Kernel has refcnt for subnet router anycast address. > Ref/dereference from userspace is done via socket. > You cannot derefer subnet router anycast address > from userspace if the socket hasn't refered it. So? The point is that subnet router anycast address *could* be referenced explicitly by a user-land socket (e.g. by radvd), not kernel at all. -- 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 yoshfuji@linux-ipv6.org Fri Jul 11 03:57:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 03:57:52 -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 h6BAvl2x012509 for ; Fri, 11 Jul 2003 03:57:48 -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 h6BAxHBo021461; Fri, 11 Jul 2003 19:59:17 +0900 Date: Fri, 11 Jul 2003 19:59:17 +0900 (JST) Message-Id: <20030711.195917.89662318.yoshfuji@linux-ipv6.org> To: pekkas@netcore.fi Cc: mika.liljeberg@welho.com, andre@tomt.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20030711.194713.21412719.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: 3949 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 Fri, 11 Jul 2003 13:47:48 +0300 (EEST)), Pekka Savola says: > On Fri, 11 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote: > > In article (at Fri, 11 Jul 2003 13:03:54 +0300 (EEST)), Pekka Savola says: > > > > > > We have but we cannot; it is refcnt'ed. > > > > > > I don't understand what you mean. Refcnt'ed by a userland process, so > > > that if you'd want the subnet-router anycast address, the whole time a > > > process (like radvd) should be running.. or what? > > > > Kernel has refcnt for subnet router anycast address. > > Ref/dereference from userspace is done via socket. > > You cannot derefer subnet router anycast address > > from userspace if the socket hasn't refered it. > > So? The point is that subnet router anycast address *could* be referenced > explicitly by a user-land socket (e.g. by radvd), not kernel at all. So, you cannot remove subnet router anycast address from kernel via this interface; kernel keeps one reference. (Hmm, I may misunderstand your mail...) --yoshfuji From pekkas@netcore.fi Fri Jul 11 03:59:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 03:59: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 h6BAxR2x012782 for ; Fri, 11 Jul 2003 03:59:28 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6BAxFv27493; Fri, 11 Jul 2003 13:59:15 +0300 Date: Fri, 11 Jul 2003 13:59:14 +0300 (EEST) From: Pekka Savola To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: mika.liljeberg@welho.com, , , Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked In-Reply-To: <20030711.195917.89662318.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 3950 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 Fri, 11 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote: > In article (at Fri, 11 Jul 2003 13:47:48 +0300 (EEST)), Pekka Savola says: > > > On Fri, 11 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote: > > > In article (at Fri, 11 Jul 2003 13:03:54 +0300 (EEST)), Pekka Savola says: > > > > > > > > We have but we cannot; it is refcnt'ed. > > > > > > > > I don't understand what you mean. Refcnt'ed by a userland process, so > > > > that if you'd want the subnet-router anycast address, the whole time a > > > > process (like radvd) should be running.. or what? > > > > > > Kernel has refcnt for subnet router anycast address. > > > Ref/dereference from userspace is done via socket. > > > You cannot derefer subnet router anycast address > > > from userspace if the socket hasn't refered it. > > > > So? The point is that subnet router anycast address *could* be referenced > > explicitly by a user-land socket (e.g. by radvd), not kernel at all. > > So, you cannot remove subnet router anycast address from > kernel via this interface; kernel keeps one reference. .. which is why kernel shouldn't keep *any* reference *at all*! > (Hmm, I may misunderstand your mail...) .. seems like it.. -- 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 yoshfuji@linux-ipv6.org Fri Jul 11 04:02:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 04:02:32 -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 h6BB2R2x013326 for ; Fri, 11 Jul 2003 04:02:28 -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 h6BB3wBo021516; Fri, 11 Jul 2003 20:03:58 +0900 Date: Fri, 11 Jul 2003 20:03:57 +0900 (JST) Message-Id: <20030711.200357.33143193.yoshfuji@linux-ipv6.org> To: pekkas@netcore.fi Cc: mika.liljeberg@welho.com, andre@tomt.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20030711.195917.89662318.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: 3951 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 Fri, 11 Jul 2003 13:59:14 +0300 (EEST)), Pekka Savola says: > > So, you cannot remove subnet router anycast address from > > kernel via this interface; kernel keeps one reference. > > .. which is why kernel shouldn't keep *any* reference *at all*! No, it is because REQUIRED and UNREMOVABLE anycast address. I don't think it is good to change this. --yoshfuji From pekkas@netcore.fi Fri Jul 11 04:04:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 04:04:54 -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 h6BB4g2x013789 for ; Fri, 11 Jul 2003 04:04:43 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6BB4TA27579; Fri, 11 Jul 2003 14:04:29 +0300 Date: Fri, 11 Jul 2003 14:04:28 +0300 (EEST) From: Pekka Savola To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: mika.liljeberg@welho.com, , , Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked In-Reply-To: <20030711.200357.33143193.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 3952 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 Fri, 11 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote: > In article (at Fri, 11 Jul 2003 13:59:14 +0300 (EEST)), Pekka Savola says: > > > > So, you cannot remove subnet router anycast address from > > > kernel via this interface; kernel keeps one reference. > > > > .. which is why kernel shouldn't keep *any* reference *at all*! > > No, it is because REQUIRED and UNREMOVABLE anycast address. Smells like a circular requirement :-) > I don't think it is good to change this. That's another issue entirely. -- 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 mika.liljeberg@welho.com Fri Jul 11 04:36:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 04:36:54 -0700 (PDT) Received: from hades.pp.htv.fi (cs180094.pp.htv.fi [213.243.180.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6BBah2x014426 for ; Fri, 11 Jul 2003 04:36:45 -0700 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) with ESMTP id h6BBab5n001216; Fri, 11 Jul 2003 14:36:37 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) id h6BBaaSN001215; Fri, 11 Jul 2003 14:36:36 +0300 X-Authentication-Warning: hades.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked From: Mika Liljeberg To: Pekka Savola Cc: Andre Tomt , linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1057923396.893.16.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 11 Jul 2003 14:36:36 +0300 X-archive-position: 3953 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mika.liljeberg@welho.com Precedence: bulk X-list: netdev Ok, Here's a valid use for subnet router anycase that isn't working. Somebody asked me how to set up 6to4, so I did a little testing. Doesn't work: hades:~# ip route add ::/0 via 2002:c058:6301:: RTNETLINK answers: Invalid argument Works: hades:~# ip route add ::/0 via 2002:c058:6301::1 Unfortunately the first form is what I need: hades:~# host -t AAAA 6to4.ipv6.funet.fi 6to4.ipv6.funet.fi has AAAA address 2001:708:0:1::624 6to4.ipv6.funet.fi has AAAA address 2002:c058:6301:: So apparently there really is an inappropriate subnet router anycast sanity check. Please fix this! MikaL On Fri, 2003-07-11 at 08:22, Pekka Savola wrote: > On 11 Jul 2003, Mika Liljeberg wrote: > > On Fri, 2003-07-11 at 07:51, Pekka Savola wrote: > > > Well, the system may make some sense, but IMHO, there is still zero sense > > > in policing this thing when you add a route. That's just plain bogus. > > > This is a bug which must be fixed ASAP. > > > > Correct me if I'm wrong but I think in this case the interface had > > forwarding enabled and the sanity check in fact prevented a default > > route pointing to the node itself from being configured. > > > > Otherwise I fully agree. The subnet router anycast address doesn't > > warrant any special handling. > > If that's the case, it's OK -- it's OK, I don't remember the details. > > (It might be nice to have configurable /proc option on whether to enable > the subnet router anycast address at all, but that's also a different > story..) From pekkas@netcore.fi Fri Jul 11 04:49:06 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 04:49:15 -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 h6BBn32x015072 for ; Fri, 11 Jul 2003 04:49:05 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6BBms527932; Fri, 11 Jul 2003 14:48:54 +0300 Date: Fri, 11 Jul 2003 14:48:54 +0300 (EEST) From: Pekka Savola To: Mika Liljeberg cc: Andre Tomt , , Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked In-Reply-To: <1057923396.893.16.camel@hades> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3954 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 11 Jul 2003, Mika Liljeberg wrote: > Here's a valid use for subnet router anycase that isn't working. > Somebody asked me how to set up 6to4, so I did a little testing. > > Doesn't work: > > hades:~# ip route add ::/0 via 2002:c058:6301:: > RTNETLINK answers: Invalid argument > > Works: > > hades:~# ip route add ::/0 via 2002:c058:6301::1 > > Unfortunately the first form is what I need: > > hades:~# host -t AAAA 6to4.ipv6.funet.fi > 6to4.ipv6.funet.fi has AAAA address 2001:708:0:1::624 > 6to4.ipv6.funet.fi has AAAA address 2002:c058:6301:: I think that in this particular case, if should have configured your interface address with 2002:v4:addr::/16, of which subnet anycast router address would be 2002::. > So apparently there really is an inappropriate subnet router anycast > sanity check. Please fix this! This *may* be caused by another issue too: nexthop's must be given in the compatible "::192.88.99.1" format, not 2002:xxxx :-( I sent a patch on over a year or so ago, but it didn't gain that much enthusiasm.. -- 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 mika.liljeberg@welho.com Fri Jul 11 05:09:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 05:09:44 -0700 (PDT) Received: from hades.pp.htv.fi (cs180094.pp.htv.fi [213.243.180.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6BC9V2x015580 for ; Fri, 11 Jul 2003 05:09:33 -0700 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) with ESMTP id h6BC9S5n001368; Fri, 11 Jul 2003 15:09:28 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) id h6BC9QBr001367; Fri, 11 Jul 2003 15:09:26 +0300 X-Authentication-Warning: hades.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked From: Mika Liljeberg To: Pekka Savola Cc: Andre Tomt , linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1057925366.896.24.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 11 Jul 2003 15:09:26 +0300 X-archive-position: 3955 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mika.liljeberg@welho.com Precedence: bulk X-list: netdev On Fri, 2003-07-11 at 14:48, Pekka Savola wrote: > On 11 Jul 2003, Mika Liljeberg wrote: > > Here's a valid use for subnet router anycase that isn't working. > > Somebody asked me how to set up 6to4, so I did a little testing. > > > > Doesn't work: > > > > hades:~# ip route add ::/0 via 2002:c058:6301:: > > RTNETLINK answers: Invalid argument > > > > Works: > > > > hades:~# ip route add ::/0 via 2002:c058:6301::1 > > > > Unfortunately the first form is what I need: > > > > hades:~# host -t AAAA 6to4.ipv6.funet.fi > > 6to4.ipv6.funet.fi has AAAA address 2001:708:0:1::624 > > 6to4.ipv6.funet.fi has AAAA address 2002:c058:6301:: > > I think that in this particular case, if should have configured your > interface address with 2002:v4:addr::/16, of which subnet anycast router > address would be 2002::. Ah ok. It *is* configured with a /16. As far as my host is concerned, 2002:c058:6301:: should be just a unicast address like any other, so maybe there is a IID==0 check somewhere? > > So apparently there really is an inappropriate subnet router anycast > > sanity check. Please fix this! > > This *may* be caused by another issue too: nexthop's must be given in the > compatible "::192.88.99.1" format, not 2002:xxxx :-( > > I sent a patch on over a year or so ago, but it didn't gain that much > enthusiasm.. I vote for fixing this too. :-) MikaL From mika.penttila@kolumbus.fi Fri Jul 11 05:42:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 05:42:45 -0700 (PDT) Received: from notes.hallinto.turkuamk.fi (notes.hallinto.turkuamk.fi [195.148.215.149]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6BCgW2x016093 for ; Fri, 11 Jul 2003 05:42:34 -0700 Received: from kolumbus.fi ([193.166.244.70]) by marconi.hallinto.turkuamk.fi (Lotus Domino Release 5.0.8) with ESMTP id 2003071115434861:20294 ; Fri, 11 Jul 2003 15:43:48 +0300 Message-ID: <3F0EB227.50403@kolumbus.fi> Date: Fri, 11 Jul 2003 15:48:39 +0300 From: =?ISO-8859-15?Q?Mika_Penttil=E4?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mika Liljeberg CC: Pekka Savola , Andre Tomt , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked References: <1057925366.896.24.camel@hades> X-MIMETrack: Itemize by SMTP Server on marconi.hallinto.turkuamk.fi/TAMK(Release 5.0.8 |June 18, 2001) at 11.07.2003 15:43:48, Serialize by Router on notes.hallinto.turkuamk.fi/TAMK(Release 5.0.10 |March 22, 2002) at 11.07.2003 15:43:20, Serialize complete at 11.07.2003 15:43:20 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-15; format=flowed X-archive-position: 3956 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mika.penttila@kolumbus.fi Precedence: bulk X-list: netdev It turns out to be the (otherwise valid) check for IFF_LOOPBACK for gateway's address in ip6_route_add() that gives EINVAL for prefix::, and has nothing to do with iid being 0, just a coinsidence.... --Mika Mika Liljeberg wrote: >On Fri, 2003-07-11 at 14:48, Pekka Savola wrote: > > >>On 11 Jul 2003, Mika Liljeberg wrote: >> >> >>>Here's a valid use for subnet router anycase that isn't working. >>>Somebody asked me how to set up 6to4, so I did a little testing. >>> >>>Doesn't work: >>> >>>hades:~# ip route add ::/0 via 2002:c058:6301:: >>>RTNETLINK answers: Invalid argument >>> >>>Works: >>> >>>hades:~# ip route add ::/0 via 2002:c058:6301::1 >>> >>>Unfortunately the first form is what I need: >>> >>>hades:~# host -t AAAA 6to4.ipv6.funet.fi >>>6to4.ipv6.funet.fi has AAAA address 2001:708:0:1::624 >>>6to4.ipv6.funet.fi has AAAA address 2002:c058:6301:: >>> >>> >>I think that in this particular case, if should have configured your >>interface address with 2002:v4:addr::/16, of which subnet anycast router >>address would be 2002::. >> >> > >Ah ok. It *is* configured with a /16. As far as my host is concerned, >2002:c058:6301:: should be just a unicast address like any other, so >maybe there is a IID==0 check somewhere? > > > >>>So apparently there really is an inappropriate subnet router anycast >>>sanity check. Please fix this! >>> >>> >>This *may* be caused by another issue too: nexthop's must be given in the >>compatible "::192.88.99.1" format, not 2002:xxxx :-( >> >>I sent a patch on over a year or so ago, but it didn't gain that much >>enthusiasm.. >> >> > >I vote for fixing this too. :-) > > MikaL > >- >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 mika.liljeberg@welho.com Fri Jul 11 06:38:38 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 06:38:47 -0700 (PDT) Received: from hades.pp.htv.fi (cs180094.pp.htv.fi [213.243.180.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6BDca2x017690 for ; Fri, 11 Jul 2003 06:38:37 -0700 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) with ESMTP id h6BDcX5n001674; Fri, 11 Jul 2003 16:38:33 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) id h6BDcWwc001673; Fri, 11 Jul 2003 16:38:32 +0300 X-Authentication-Warning: hades.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked From: Mika Liljeberg To: Mika =?ISO-8859-1?Q?Penttil=E4?= Cc: Pekka Savola , Andre Tomt , linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <3F0EB227.50403@kolumbus.fi> References: <1057925366.896.24.camel@hades> <3F0EB227.50403@kolumbus.fi> Content-Type: text/plain; charset=iso-8859-15 Message-Id: <1057930712.895.32.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 11 Jul 2003 16:38:32 +0300 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h6BDca2x017690 X-archive-position: 3957 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mika.liljeberg@welho.com Precedence: bulk X-list: netdev On Fri, 2003-07-11 at 15:48, Mika Penttilä wrote: > It turns out to be the (otherwise valid) check for IFF_LOOPBACK for > gateway's address in ip6_route_add() that gives EINVAL for prefix::, and > has nothing to do with iid being 0, just a coinsidence.... Not sure. Seems to me that ipv6_addr_type() flags the gateway address as anycast. In ip6_route_addr() [2.5.74] we have: if (rtmsg->rtmsg_flags & RTF_GATEWAY) { struct in6_addr *gw_addr; int gwa_type; gw_addr = &rtmsg->rtmsg_gateway; ipv6_addr_copy(&rt->rt6i_gateway, &rtmsg->rtmsg_gateway); gwa_type = ipv6_addr_type(gw_addr); if (gwa_type != (IPV6_ADDR_LINKLOCAL|IPV6_ADDR_UNICAST)) { struct rt6_info *grt; /* IPv6 strictly inhibits using not link-local addresses as nexthop address. Otherwise, router will not able to send redirects. It is very good, but in some (rare!) curcumstances (SIT, PtP, NBMA NOARP links) it is handy to allow some exceptions. --ANK */ err = -EINVAL; if (!(gwa_type&IPV6_ADDR_UNICAST)) goto out; Looks like it would bail out here, unless I read the code wrong. How about: if (!(gwa_type&(IPV6_ADDR_UNICAST|IPV6_ADDR_ANYCAST))) goto out; MikaL From mika.penttila@kolumbus.fi Fri Jul 11 07:21:51 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 07:22:04 -0700 (PDT) Received: from notes.hallinto.turkuamk.fi (notes.hallinto.turkuamk.fi [195.148.215.149]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6BELn2x019538 for ; Fri, 11 Jul 2003 07:21:50 -0700 Received: from kolumbus.fi ([193.166.244.70]) by marconi.hallinto.turkuamk.fi (Lotus Domino Release 5.0.8) with ESMTP id 2003071117230610:20344 ; Fri, 11 Jul 2003 17:23:06 +0300 Message-ID: <3F0EC96D.6080102@kolumbus.fi> Date: Fri, 11 Jul 2003 17:27:57 +0300 From: =?ISO-8859-15?Q?Mika_Penttil=E4?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mika Liljeberg CC: Pekka Savola , Andre Tomt , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked References: <1057925366.896.24.camel@hades> <3F0EB227.50403@kolumbus.fi> <1057930712.895.32.camel@hades> X-MIMETrack: Itemize by SMTP Server on marconi.hallinto.turkuamk.fi/TAMK(Release 5.0.8 |June 18, 2001) at 11.07.2003 17:23:06, Serialize by Router on notes.hallinto.turkuamk.fi/TAMK(Release 5.0.10 |March 22, 2002) at 11.07.2003 17:22:37, Serialize complete at 11.07.2003 17:22:37 Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h6BELn2x019538 X-archive-position: 3958 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mika.penttila@kolumbus.fi Precedence: bulk X-list: netdev afaics, ipv6_addr_type() checks just for some rfc-specified reserved anycast addresses, not the ones in device list. Anyway, it will surely also bail out from the loopback test (anycast subnet router address is ours). --Mika Mika Liljeberg wrote: >On Fri, 2003-07-11 at 15:48, Mika Penttilä wrote: > > >>It turns out to be the (otherwise valid) check for IFF_LOOPBACK for >>gateway's address in ip6_route_add() that gives EINVAL for prefix::, and >>has nothing to do with iid being 0, just a coinsidence.... >> >> > >Not sure. Seems to me that ipv6_addr_type() flags the gateway address as >anycast. In ip6_route_addr() [2.5.74] we have: > > if (rtmsg->rtmsg_flags & RTF_GATEWAY) { > struct in6_addr *gw_addr; > int gwa_type; > > gw_addr = &rtmsg->rtmsg_gateway; > ipv6_addr_copy(&rt->rt6i_gateway, &rtmsg->rtmsg_gateway); > gwa_type = ipv6_addr_type(gw_addr); > > if (gwa_type != (IPV6_ADDR_LINKLOCAL|IPV6_ADDR_UNICAST)) { > struct rt6_info *grt; > > /* IPv6 strictly inhibits using not link-local > addresses as nexthop address. > Otherwise, router will not able to send redirects. > It is very good, but in some (rare!) curcumstances > (SIT, PtP, NBMA NOARP links) it is handy to allow > some exceptions. --ANK > */ > err = -EINVAL; > if (!(gwa_type&IPV6_ADDR_UNICAST)) > goto out; > >Looks like it would bail out here, unless I read the code wrong. How about: > > if (!(gwa_type&(IPV6_ADDR_UNICAST|IPV6_ADDR_ANYCAST))) > goto out; > > MikaL > >- >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 mika.liljeberg@welho.com Fri Jul 11 07:32:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 07:32:52 -0700 (PDT) Received: from hades.pp.htv.fi (cs180094.pp.htv.fi [213.243.180.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6BEWd2x019938 for ; Fri, 11 Jul 2003 07:32:40 -0700 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) with ESMTP id h6BEWZrD000739; Fri, 11 Jul 2003 17:32:35 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) id h6BEWYmL000738; Fri, 11 Jul 2003 17:32:34 +0300 X-Authentication-Warning: hades.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked From: Mika Liljeberg To: Mika =?ISO-8859-1?Q?Penttil=E4?= Cc: Pekka Savola , Andre Tomt , linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <3F0EC96D.6080102@kolumbus.fi> References: <1057925366.896.24.camel@hades> <3F0EB227.50403@kolumbus.fi> <1057930712.895.32.camel@hades> <3F0EC96D.6080102@kolumbus.fi> Content-Type: multipart/mixed; boundary="=-DKIDlaIdFwiWn2TE4NdP" Message-Id: <1057933954.695.6.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 11 Jul 2003 17:32:34 +0300 X-archive-position: 3959 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mika.liljeberg@welho.com Precedence: bulk X-list: netdev --=-DKIDlaIdFwiWn2TE4NdP Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable On Fri, 2003-07-11 at 17:27, Mika Penttil=E4 wrote: > afaics, ipv6_addr_type() checks just for some rfc-specified reserved=20 > anycast addresses, not the ones in device list. Anyway, it will surely=20 > also bail out from the loopback test (anycast subnet router address is=20 > ours). Nope, since the tunnel interface will have 2002::/16. It seems to work with the attached patch (against 2.4.21-ac4). A small fix to sit was required as well. Look: hades:~# ifconfig 6to4 6to4 Link encap:IPv6-in-IPv4 inet6 addr: ::213.243.180.94/128 Scope:Compat inet6 addr: 2002:d5f3:b45e::1/16 Scope:Global UP RUNNING NOARP MTU:1480 Metric:1 RX packets:4 errors:0 dropped:0 overruns:0 frame:0 TX packets:4 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:416 (416.0 b) TX bytes:496 (496.0 b) hades:~# ip -6 route list ::/96 via :: dev 6to4 metric 256 mtu 1480 advmss 1420 2002::/16 dev 6to4 proto kernel metric 256 mtu 1480 advmss 1420 fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 fe80::/64 dev 6to4 proto kernel metric 256 mtu 1480 advmss 1420 ff00::/8 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 ff00::/8 dev 6to4 proto kernel metric 256 mtu 1480 advmss 1420 default via 2002:c058:6301:: dev 6to4 metric 1024 mtu 1480 advmss 1420 hades:~# ping6 -c4 -n www.ipv6.org PING www.ipv6.org(2001:6b0:1:ea:a00:20ff:fe8f:708f) 56 data bytes 64 bytes from 2001:6b0:1:ea:a00:20ff:fe8f:708f: icmp_seq=3D1 ttl=3D250 time= =3D207 ms 64 bytes from 2001:6b0:1:ea:a00:20ff:fe8f:708f: icmp_seq=3D2 ttl=3D250 time= =3D206 ms 64 bytes from 2001:6b0:1:ea:a00:20ff:fe8f:708f: icmp_seq=3D3 ttl=3D250 time= =3D177 ms 64 bytes from 2001:6b0:1:ea:a00:20ff:fe8f:708f: icmp_seq=3D4 ttl=3D250 time= =3D78.5 ms --- www.ipv6.org ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3030ms rtt min/avg/max/mdev =3D 78.547/167.637/207.698/52.821 ms Anyone see any problems with this? MikaL --=-DKIDlaIdFwiWn2TE4NdP Content-Disposition: attachment; filename=6to4.udiff Content-Type: text/plain; name=6to4.udiff; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable --- route.c.org 2003-07-11 16:41:55.000000000 +0300 +++ route.c 2003-07-11 16:42:16.000000000 +0300 @@ -743,7 +743,7 @@ some exceptions. --ANK */ err =3D -EINVAL; - if (!(gwa_type&IPV6_ADDR_UNICAST)) + if (!(gwa_type&(IPV6_ADDR_UNICAST|IPV6_ADDR_ANYCAST))) goto out; =20 grt =3D rt6_lookup(gw_addr, NULL, rtmsg->rtmsg_ifindex, 1); --- sit.c.org 2003-07-11 16:57:53.000000000 +0300 +++ sit.c 2003-07-11 17:17:42.000000000 +0300 @@ -495,10 +495,13 @@ addr_type =3D ipv6_addr_type(addr6); } =20 - if ((addr_type & IPV6_ADDR_COMPATv4) =3D=3D 0) - goto tx_error_icmp; + if ((addr_type & IPV6_ADDR_COMPATv4)) + dst =3D addr6->s6_addr32[3]; + else + dst =3D try_6to4(addr6); =20 - dst =3D addr6->s6_addr32[3]; + if (!dst) + goto tx_error_icmp; } =20 if (ip_route_output(&rt, dst, tiph->saddr, RT_TOS(tos), tunnel->parms.lin= k)) { --=-DKIDlaIdFwiWn2TE4NdP-- From andrius@andrius.org Fri Jul 11 07:59:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 07:59:47 -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 h6BExc2x020858 for ; Fri, 11 Jul 2003 07:59:39 -0700 Received: by hl.kalnieciai.lt (Postfix, from userid 1430) id 2FC1A4F187; Fri, 11 Jul 2003 17:59:36 +0300 (GMT-3) Received: from localhost (localhost [127.0.0.1]) by hl.kalnieciai.lt (Postfix) with ESMTP id 2B5714F177; Fri, 11 Jul 2003 17:59:36 +0300 (GMT-3) Date: Fri, 11 Jul 2003 17:59:36 +0300 (GMT-3) From: Andrius Kasparavicius X-X-Sender: andrius@hl.kauneta.net To: Ben Greear Cc: netdev@oss.sgi.com Subject: Re: network interface cards native vlans support in linux kernel? In-Reply-To: <3F0C4DBD.8020007@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3960 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 on vanilla linux kernel, eepro doesn't work, and with 1496 mtu, 8139too works with any mtu (and 1500). which is recommended to use, e100 or eepro100? Andrius. On Wed, 9 Jul 2003, Ben Greear wrote: > > is there any problems to include full vlans support? > > Intel's e100 driver (and all NICs supported by it) support vlans > fine, as do most of the GigE NICs. Tulip does not, last I hear, though > a work-around patch has been around forever. Realtek worked at one time, > not sure about now though... From mika.penttila@kolumbus.fi Fri Jul 11 08:10:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 08:10:10 -0700 (PDT) Received: from notes.hallinto.turkuamk.fi (notes.hallinto.turkuamk.fi [195.148.215.149]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6BFA12x024425 for ; Fri, 11 Jul 2003 08:10:02 -0700 Received: from kolumbus.fi ([193.166.244.70]) by marconi.hallinto.turkuamk.fi (Lotus Domino Release 5.0.8) with ESMTP id 2003071118111831:20375 ; Fri, 11 Jul 2003 18:11:18 +0300 Message-ID: <3F0ED4B9.9000105@kolumbus.fi> Date: Fri, 11 Jul 2003 18:16:09 +0300 From: =?ISO-8859-15?Q?Mika_Penttil=E4?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mika Liljeberg CC: Pekka Savola , Andre Tomt , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked References: <1057925366.896.24.camel@hades> <3F0EB227.50403@kolumbus.fi> <1057930712.895.32.camel@hades> <3F0EC96D.6080102@kolumbus.fi> <1057933954.695.6.camel@hades> X-MIMETrack: Itemize by SMTP Server on marconi.hallinto.turkuamk.fi/TAMK(Release 5.0.8 |June 18, 2001) at 11.07.2003 18:11:18, Serialize by Router on notes.hallinto.turkuamk.fi/TAMK(Release 5.0.10 |March 22, 2002) at 11.07.2003 18:10:49, Serialize complete at 11.07.2003 18:10:49 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-15; format=flowed X-archive-position: 3961 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mika.penttila@kolumbus.fi Precedence: bulk X-list: netdev Mika Liljeberg wrote: >Nope, since the tunnel interface will have 2002::/16. It seems to work >with the attached patch (against 2.4.21-ac4). A small fix to sit was >required as well. Look: > > ok, forgot that...looks ok to me. --Mika >hades:~# ifconfig 6to4 >6to4 Link encap:IPv6-in-IPv4 > inet6 addr: ::213.243.180.94/128 Scope:Compat > inet6 addr: 2002:d5f3:b45e::1/16 Scope:Global > UP RUNNING NOARP MTU:1480 Metric:1 > RX packets:4 errors:0 dropped:0 overruns:0 frame:0 > TX packets:4 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:416 (416.0 b) TX bytes:496 (496.0 b) > >hades:~# ip -6 route list >::/96 via :: dev 6to4 metric 256 mtu 1480 advmss 1420 >2002::/16 dev 6to4 proto kernel metric 256 mtu 1480 advmss 1420 >fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 >fe80::/64 dev 6to4 proto kernel metric 256 mtu 1480 advmss 1420 >ff00::/8 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 >ff00::/8 dev 6to4 proto kernel metric 256 mtu 1480 advmss 1420 >default via 2002:c058:6301:: dev 6to4 metric 1024 mtu 1480 advmss 1420 >hades:~# ping6 -c4 -n www.ipv6.org >PING www.ipv6.org(2001:6b0:1:ea:a00:20ff:fe8f:708f) 56 data bytes >64 bytes from 2001:6b0:1:ea:a00:20ff:fe8f:708f: icmp_seq=1 ttl=250 time=207 ms >64 bytes from 2001:6b0:1:ea:a00:20ff:fe8f:708f: icmp_seq=2 ttl=250 time=206 ms >64 bytes from 2001:6b0:1:ea:a00:20ff:fe8f:708f: icmp_seq=3 ttl=250 time=177 ms >64 bytes from 2001:6b0:1:ea:a00:20ff:fe8f:708f: icmp_seq=4 ttl=250 time=78.5 ms > >--- www.ipv6.org ping statistics --- >4 packets transmitted, 4 received, 0% packet loss, time 3030ms >rtt min/avg/max/mdev = 78.547/167.637/207.698/52.821 ms > >Anyone see any problems with this? > > MikaL > > > >------------------------------------------------------------------------ > >--- route.c.org 2003-07-11 16:41:55.000000000 +0300 >+++ route.c 2003-07-11 16:42:16.000000000 +0300 >@@ -743,7 +743,7 @@ > some exceptions. --ANK > */ > err = -EINVAL; >- if (!(gwa_type&IPV6_ADDR_UNICAST)) >+ if (!(gwa_type&(IPV6_ADDR_UNICAST|IPV6_ADDR_ANYCAST))) > goto out; > > grt = rt6_lookup(gw_addr, NULL, rtmsg->rtmsg_ifindex, 1); >--- sit.c.org 2003-07-11 16:57:53.000000000 +0300 >+++ sit.c 2003-07-11 17:17:42.000000000 +0300 >@@ -495,10 +495,13 @@ > addr_type = ipv6_addr_type(addr6); > } > >- if ((addr_type & IPV6_ADDR_COMPATv4) == 0) >- goto tx_error_icmp; >+ if ((addr_type & IPV6_ADDR_COMPATv4)) >+ dst = addr6->s6_addr32[3]; >+ else >+ dst = try_6to4(addr6); > >- dst = addr6->s6_addr32[3]; >+ if (!dst) >+ goto tx_error_icmp; > } > > if (ip_route_output(&rt, dst, tiph->saddr, RT_TOS(tos), tunnel->parms.link)) { > > From jmorris@intercode.com.au Fri Jul 11 08:38:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 08:38:16 -0700 (PDT) Received: from blackbird.intercode.com.au (IDENT:onnveqSIFTPV362efaWpMjYLL15FJ09i@blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6BFc02x025149 for ; Fri, 11 Jul 2003 08:38:02 -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 h6BFbir06371; Sat, 12 Jul 2003 01:37:45 +1000 Date: Sat, 12 Jul 2003 01:37:44 +1000 (EST) From: James Morris To: Jim Keniston cc: LKML , , Andrew Morton , "David S. Miller" , Jeff Garzik , Alan Cox , Randy Dunlap , Subject: Re: [PATCH - RFC] [1/2] 2.6 must-fix list - kernel error reporting In-Reply-To: <3F0DB9A5.23723BE1@us.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3962 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, 10 Jul 2003, Jim Keniston wrote: > James Morris wrote: > > > > On Tue, 8 Jul 2003, Jim Keniston wrote: > > > > + kerror_nl = netlink_kernel_create(NETLINK_KERROR, kerror_netlink_rcv); > > + if (kerror_nl == NULL) > > + panic("kerror_init: cannot initialize kerror_nl\n"); > > > > You can simply use NULL instead of passing the dummy kerror_netlink_rcv > > function. > > That begs the question: do we trust that nobody but the kernel will send > packets to a NETLINK_KERROR socket? Ordinary users can't, but any root > application can. Without kerror_netlink_rcv(), such packets don't get > dequeued. Indeed, the kernel socket buffer fills up. I think this needs to be addressed in the netlink code, per the patch below. Comments? - James -- James Morris diff -NurX dontdiff linux-2.5.75.orig/net/netlink/af_netlink.c linux-2.5.75.w1/net/netlink/af_netlink.c --- linux-2.5.75.orig/net/netlink/af_netlink.c 2003-06-26 12:43:45.000000000 +1000 +++ linux-2.5.75.w1/net/netlink/af_netlink.c 2003-07-12 01:23:49.708254261 +1000 @@ -430,6 +430,10 @@ goto no_dst; nlk = nlk_sk(sk); + /* Don't bother queuing skb if kernel socket has no input function */ + if (nlk->pid == 0 && !nlk->data_ready) + goto no_dst; + #ifdef NL_EMULATE_DEV if (nlk->handler) { skb_orphan(skb); From greearb@candelatech.com Fri Jul 11 10:12:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 10:12: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 h6BHCD2x027935 for ; Fri, 11 Jul 2003 10:12:14 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h6BHBvKk013306; Fri, 11 Jul 2003 10:11:59 -0700 Message-ID: <3F0EEFDD.8050300@candelatech.com> Date: Fri, 11 Jul 2003 10:11:57 -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: Andrius Kasparavicius CC: 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: 3963 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 Andrius Kasparavicius wrote: > on vanilla linux kernel, eepro doesn't work, and with 1496 mtu, 8139too > works with any mtu (and 1500). > > which is recommended to use, e100 or eepro100? As I mentioned, the e100 (intel's driver) is the one I recommend. eepro100 does not seem to be updated in the kernel anymore, though if you go figure out how to install Becker's drivers, he may have it working with vlans by now. Ben > > Andrius. > > On Wed, 9 Jul 2003, Ben Greear wrote: > > >>>is there any problems to include full vlans support? >> >>Intel's e100 driver (and all NICs supported by it) support vlans >>fine, as do most of the GigE NICs. Tulip does not, last I hear, though >>a work-around patch has been around forever. Realtek worked at one time, >>not sure about now though... > > -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From garzik@gtf.org Fri Jul 11 10:19:07 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 10:19: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 h6BHJ42x028276 for ; Fri, 11 Jul 2003 10:19:07 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id DB0556680; Fri, 11 Jul 2003 13:18:58 -0400 (EDT) Date: Fri, 11 Jul 2003 13:18:58 -0400 From: Jeff Garzik To: Ben Greear Cc: Andrius Kasparavicius , netdev@oss.sgi.com Subject: Re: network interface cards native vlans support in linux kernel? Message-ID: <20030711171858.GI2210@gtf.org> References: <3F0EEFDD.8050300@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F0EEFDD.8050300@candelatech.com> User-Agent: Mutt/1.3.28i X-archive-position: 3964 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 Fri, Jul 11, 2003 at 10:11:57AM -0700, Ben Greear wrote: > eepro100 does not seem to be updated in the kernel anymore, though if you > go figure > out how to install Becker's drivers, he may have it working with vlans > by now. I won't say for sure, but I'm fairly certain he does. Most of his drivers got a "slightly larger than normal MTU" pass-over a while ago. I objected to the eepro100 patch, because all it did was change one magic number to another, in the configuration data. I had absolutely no basis for evaluation other than "I hope it works", so it was rejected. If someone wants to look at his eepro100 and merge in new changes (vlan or otherwise), that'd be great. His tulip MTU (aka vlan) changes also want pulling into mainline kernel, since his changes are _much_ better than the tulip vlan patch floating around. Jeff From greearb@candelatech.com Fri Jul 11 10:26:06 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 10:26:11 -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 h6BHQ52x028639 for ; Fri, 11 Jul 2003 10:26:06 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h6BHPvKk015102; Fri, 11 Jul 2003 10:25:57 -0700 Message-ID: <3F0EF325.9060708@candelatech.com> Date: Fri, 11 Jul 2003 10:25:57 -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: Andrius Kasparavicius , netdev@oss.sgi.com Subject: Re: network interface cards native vlans support in linux kernel? References: <3F0EEFDD.8050300@candelatech.com> <20030711171858.GI2210@gtf.org> In-Reply-To: <20030711171858.GI2210@gtf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3965 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: > On Fri, Jul 11, 2003 at 10:11:57AM -0700, Ben Greear wrote: > >>eepro100 does not seem to be updated in the kernel anymore, though if you >>go figure >>out how to install Becker's drivers, he may have it working with vlans >>by now. > > > I won't say for sure, but I'm fairly certain he does. Most of his > drivers got a "slightly larger than normal MTU" pass-over a while ago. > > I objected to the eepro100 patch, because all it did was change one > magic number to another, in the configuration data. I had absolutely no > basis for evaluation other than "I hope it works", so it was rejected. > > If someone wants to look at his eepro100 and merge in new changes (vlan > or otherwise), that'd be great. His tulip MTU (aka vlan) changes also > want pulling into mainline kernel, since his changes are _much_ better > than the tulip vlan patch floating around. It is beyond me to do this merge at this time, but if someone else can do it that would be great. I can also do some testing of the tulip merge, at least..as I have loads of 4-port nics lying around. Ben > > Jeff > > -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From khc@pm.waw.pl Fri Jul 11 10:27:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 10:27:45 -0700 (PDT) Received: from hq.pm.waw.pl (hq.pm.waw.pl [195.116.170.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6BHRd2x028824 for ; Fri, 11 Jul 2003 10:27:41 -0700 Received: by hq.pm.waw.pl (Postfix, from userid 10) id C59BC322F; Fri, 11 Jul 2003 19:27:36 +0200 (CEST) Received: by defiant.pm.waw.pl (Postfix, from userid 500) id 918823C7BC; Fri, 11 Jul 2003 19:27:28 +0200 (CEST) To: netdev@oss.sgi.com Subject: 2.5.74 X.25+LAPB still kills the kernel From: Krzysztof Halasa Date: 11 Jul 2003 19:27:28 +0200 Message-ID: Lines: 52 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 3966 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: khc@pm.waw.pl Precedence: bulk X-list: netdev Hi, No need to actually use X.25+LAPB, it's enough to just compile it in. Linux version 2.5.74 (gcc version 3.2.3 20030422 (Red Hat Linux 3.2.3-4)) You do not need Ethernet either, it will oops with just loopback as well. Serial console dump follows (details available on request in case someone need them). gw:/# ip link 1: lo: mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 gw:/# ifconfig lo Link eUnable to handle kernel paging requestncap:Local Loopb at virtual address 6b6b6b6b ack printing eip: inet addr:127.0c01a0f22 .0.1 Mask:255.0*pde = 00000000 .0.0 Oops: 0000 [#1] CPU: 0 EIP: 0060:[] Not tainted EFLAGS: 00010202 EIP is at __release_sock+0x22/0x60 eax: 6b6b6b6b ebx: 00000000 ecx: 00000000 edx: c3cd2c44 esi: c3cd2c44 edi: c3cd2c44 ebp: c10b7f00 esp: c10b7ef8 ds: 007b es: 007b ss: 0068 Process ifconfig (pid: 37, threadinfo=c10b6000 task=c10ce060) Stack: 00000000 c3cd2c88 c10b7f18 c01ee728 c3cd2c44 c3cd2c44 c3ed1d2c c3cdb494 c10b7f40 c01eebf8 c3cd2c44 c3cd2c44 00000000 00000000 00000000 c3cdb494 00000000 c3cdb4b8 c10b7f54 c019e1d6 c3cdb494 c3cdb4b8 c3ced41c c10b7f64 Call Trace: [] x25_destroy_socket+0x188/0x1a0 [] x25_release+0x38/0xa0 [] sock_release+0x56/0x80 [] sock_close+0x23/0x40 [] __fput+0xd6/0xe0 [] filp_close+0x3b/0x60 [] sys_close+0x47/0x60 [] syscall_call+0x7/0xb Code: 8b 18 c7 00 00 00 00 00 50 56 ff 96 1c 01 00 00 85 db 5a 89 UP LOOPBACK RUNN<0>Kernel panic: Fatal exception in interrupt ING MTU:16436 In interrupt handler - not syncing Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) -- Krzysztof Halasa Network Administrator From willy@www.linux.org.uk Fri Jul 11 11:19:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 11:19:54 -0700 (PDT) Received: from www.linux.org.uk (IDENT:XpQQKK9Omct24Pi0ZSXbJdJnepPwHcwq@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6BIJl2x029840 for ; Fri, 11 Jul 2003 11:19:49 -0700 Received: from willy by www.linux.org.uk with local (Exim 4.14) id 19b2Uk-0003Fl-Po for netdev@oss.sgi.com; Fri, 11 Jul 2003 19:19:46 +0100 Date: Fri, 11 Jul 2003 19:19:46 +0100 From: Matthew Wilcox To: netdev@oss.sgi.com Subject: [PATCH] Move eth_mac_addr and eth_change_mtu Message-ID: <20030711181946.GG20424@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: 3967 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 Move eth_mac_addr() and eth_change_mtu() from drivers/net/net_init.c to net/ethernet/eth.c Index: drivers/net/net_init.c =================================================================== RCS file: /var/cvs/linux-2.5/drivers/net/net_init.c,v retrieving revision 1.4 diff -u -p -r1.4 net_init.c --- drivers/net/net_init.c 14 Jun 2003 22:15:21 -0000 1.4 +++ drivers/net/net_init.c 10 Jul 2003 20:57:55 -0000 @@ -222,23 +222,6 @@ struct net_device *alloc_etherdev(int si EXPORT_SYMBOL(init_etherdev); EXPORT_SYMBOL(alloc_etherdev); -static int eth_mac_addr(struct net_device *dev, void *p) -{ - struct sockaddr *addr=p; - if (netif_running(dev)) - return -EBUSY; - memcpy(dev->dev_addr, addr->sa_data,dev->addr_len); - return 0; -} - -static int eth_change_mtu(struct net_device *dev, int new_mtu) -{ - if ((new_mtu < 68) || (new_mtu > 1500)) - return -EINVAL; - dev->mtu = new_mtu; - return 0; -} - #ifdef CONFIG_FDDI /** Index: include/linux/etherdevice.h =================================================================== RCS file: /var/cvs/linux-2.5/include/linux/etherdevice.h,v retrieving revision 1.3 diff -u -p -r1.3 etherdevice.h --- include/linux/etherdevice.h 14 Jun 2003 22:16:01 -0000 1.3 +++ include/linux/etherdevice.h 10 Jul 2003 21:00:23 -0000 @@ -38,6 +38,8 @@ extern int eth_header_cache(struct neig struct hh_cache *hh); extern int eth_header_parse(struct sk_buff *skb, unsigned char *haddr); +extern int eth_mac_addr(struct net_device *dev, void *p); +extern int eth_change_mtu(struct net_device *dev, int new_mtu); extern struct net_device *init_etherdev(struct net_device *dev, int sizeof_priv); extern struct net_device *alloc_etherdev(int sizeof_priv); static inline void eth_copy_and_sum (struct sk_buff *dest, unsigned char *src, int len, int base) Index: net/ethernet/eth.c =================================================================== RCS file: /var/cvs/linux-2.5/net/ethernet/eth.c,v retrieving revision 1.4 diff -u -p -r1.4 eth.c --- net/ethernet/eth.c 23 Jun 2003 03:30:58 -0000 1.4 +++ net/ethernet/eth.c 10 Jul 2003 20:58:54 -0000 @@ -241,3 +241,20 @@ void eth_header_cache_update(struct hh_c memcpy(((u8*)hh->hh_data) + HH_DATA_OFF(sizeof(struct ethhdr)), haddr, dev->addr_len); } + +int eth_mac_addr(struct net_device *dev, void *p) +{ + struct sockaddr *addr=p; + if (netif_running(dev)) + return -EBUSY; + memcpy(dev->dev_addr, addr->sa_data, dev->addr_len); + return 0; +} + +int eth_change_mtu(struct net_device *dev, int new_mtu) +{ + if ((new_mtu < 68) || (new_mtu > 1500)) + return -EINVAL; + dev->mtu = new_mtu; + return 0; +} -- "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 garzik@gtf.org Fri Jul 11 11:23:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 11:23:39 -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 h6BINZ2x030179 for ; Fri, 11 Jul 2003 11:23:36 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id 2267C6687; Fri, 11 Jul 2003 14:23:30 -0400 (EDT) Date: Fri, 11 Jul 2003 14:23:30 -0400 From: Jeff Garzik To: Matthew Wilcox Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Move eth_mac_addr and eth_change_mtu Message-ID: <20030711182330.GC16037@gtf.org> References: <20030711181946.GG20424@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030711181946.GG20424@parcelfarce.linux.theplanet.co.uk> User-Agent: Mutt/1.3.28i X-archive-position: 3968 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 Fri, Jul 11, 2003 at 07:19:46PM +0100, Matthew Wilcox wrote: > Move eth_mac_addr() and eth_change_mtu() from drivers/net/net_init.c > to net/ethernet/eth.c Why? It's not used outside of net_init.c AFAICS. And even so, don't you want to export those symbols? Jeff From garzik@gtf.org Fri Jul 11 12:32:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 12:32:31 -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 h6BJWL2x001899 for ; Fri, 11 Jul 2003 12:32:22 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id 9B8A0665C; Fri, 11 Jul 2003 15:32:15 -0400 (EDT) Date: Fri, 11 Jul 2003 15:32:15 -0400 From: Jeff Garzik To: Matthew Wilcox Cc: netdev@oss.sgi.com, greearb@candelatech.com, "David S. Miller" , Arnaldo Carvalho de Melo Subject: Re: [PATCH] netdev_ops Message-ID: <20030711193215.GH16037@gtf.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030709161520.GW1939@parcelfarce.linux.theplanet.co.uk> User-Agent: Mutt/1.3.28i X-archive-position: 3969 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 Comments: 1) The _ops are either too limited in scope, or too wide in scope. We have a bunch of function pointers in struct net_device. We are adding a bunch more func ptrs in a new struct foo_ops. If it is called ethtool_ops, I can support the addition of struct ethtool_ops *etops; to struct net_device. However, if we call it netdev_ops, the structure's name no longer describes its purpose. If we call it netdev_ops, we should move ALL the function pointers in struct net_device into netdev_ops as well, and deal with the associated driver breakage. So, either change the name back to ethtool_ops, or go all the way. The current name to me implies a job half-done. Personally, I would prefer the more radical "move all funcptrs into netdev_ops". This is closer to other Linux kernel APIs. 2) Yes, we do want a feature macro for this. David, I respectfully disagree with "no back compat" type arguments. Besides h/w vendors who want to support distros currently in the field (read: not the latest kernel), _I_ am personally impacted by API divergence. As I have said (and proven) many times, I personally spend time keeping the more popular ethernet drivers in sync, 2.4 <-> 2.5. Each time a 2.5-specific change is added that is not easily massaged by a back compat macro, it costs me time. Hand-applying patches is not fun. 2.a) There is established precedent: grep for HAVE_xxx in netdevice.h and look at the ton of hits you get. 2.b) If #1 is decided to be ethtool_ops, create HAVE_ETHTOOL_OPS macro 2.c) If #2 is decided to be netdev_ops, and all func ptrs are moved into netdev_ops struct, then create the macro SET_NETDEV_OPS(dev, ops) This allows full back compat, without ugliness in mainline tree. 3) The func ptrs _count() are totally bogus. We have an unconditional indirect reference to a function call which does nothing but return a driver constant. I personally think that having ethtool_ops members manually calling the ->get_drvinfo hook is a _lot_ cleaner than 10,000 foo_count hooks. 3.a) Further, we will inevitably be adding more counts in the future. If we wanted to be truly expandable, and you really don't like the counts being in struct ethtool_gdrvinfo, then create a struct ethtool_counts that puts all the constants in one place. 4) I don't see why ethtool.h suddenly needs to include linux/types.h, when it hasn't needed it in all this time until now. 5) net/socket.c changes appear unrelated to this patch. 6) (low prio) Add documentation to Documentation/networking/netdevices.txt. Most importantly, this documents locking/context. 7) (low prio) All that similar code in net/core/ethtool.c can be template-ized with a macro, IMO. Something like DEF_ETHTOOL_GOP(get_coalesce, ETHTOOL_GCOALESCE, ethtool_coalesce); DEF_ETHTOOL_SOP(set_coalesce, ethtool_coalesce); (and templates for the ops that use edata) 8) (security) get-eeprom op needs to check that offset+len is not invalid, and does not wrap. 9) phys_id op should return an error, for consistency if nothing else. It's simple for driver authors to unconditionally return 0 if their code has no failure cases, and it's a slow path so adding the return in the driver code is no big deal. 10) (low prio) since it's a slow path, what about replacing the switch statement in dev_ethtool() with a lookup table? All the ethtool commands are low numbers. If you do this, I would suggest using the gcc array initializer syntax: [ETHTOOL_GCOALESCE, ethtool_get_coalesce] All the ethtool ops have the same prototype, after all. Comments? From greearb@candelatech.com Fri Jul 11 12:51:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 12:51:50 -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 h6BJph2x017250 for ; Fri, 11 Jul 2003 12:51:44 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h6BJpOKk001019; Fri, 11 Jul 2003 12:51:25 -0700 Message-ID: <3F0F153C.4040506@candelatech.com> Date: Fri, 11 Jul 2003 12:51:24 -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: Matthew Wilcox , netdev@oss.sgi.com, "David S. Miller" , Arnaldo Carvalho de Melo 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> <20030711193215.GH16037@gtf.org> In-Reply-To: <20030711193215.GH16037@gtf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3970 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: > Comments: > > 1) The _ops are either too limited in scope, or too wide in scope. > > We have a bunch of function pointers in struct net_device. > We are adding a bunch more func ptrs in a new struct foo_ops. > > If it is called ethtool_ops, I can support the addition of > struct ethtool_ops *etops; > to struct net_device. > > However, if we call it netdev_ops, the structure's name no longer > describes its purpose. If we call it netdev_ops, we should move ALL the > function pointers in struct net_device into netdev_ops as well, and deal > with the associated driver breakage. > > So, either change the name back to ethtool_ops, or go all the way. > The current name to me implies a job half-done. > > Personally, I would prefer the more radical "move all funcptrs into > netdev_ops". This is closer to other Linux kernel APIs. Either way, I'd vote for netdev_ops, because I want to add generic 'ioctls' that work on struct net_device, not necessarily just ethernet devices. However, it's a minor issue since the code will work regardless. > 3) The func ptrs _count() are totally bogus. We have an unconditional > indirect reference to a function call which does nothing but return a > driver constant. > > I personally think that having ethtool_ops members manually calling > the ->get_drvinfo hook is a _lot_ cleaner than 10,000 foo_count hooks. > > 3.a) Further, we will inevitably be adding more counts in the future. > If we wanted to be truly expandable, and you really don't like the > counts being in struct ethtool_gdrvinfo, then create a struct > ethtool_counts that puts all the constants in one place. Suppose we do this, how will we make a user-space app that tries to read this be backwards/forwards compatible? This is one of the reasons I was hoping for some versioning information that could be probed at run-time from user-space. Could bump the version each time we change something that is difficult to detect in user-space. (ie, adding a new ethtool-cmd is easy to detect because we'll get EINVAL or something when it's not there, and a success when it is, but getting a different sized struct, or a struct who's members have changed their meaning, will be more difficult to detect I believe.) Programs that do not wish to deal with the cruft of versioning can just ignore it, but ones that are designed to be very robust can do the extra work to deal with the different versions. > > > 4) I don't see why ethtool.h suddenly needs to include linux/types.h, > when it hasn't needed it in all this time until now. If we're changing lots of stuff...it would be nice to change the u32 etc to something that user-space can easily handle, as ethtool.h is (for better or worse) being included from user-space. Minor issue again as it can be dealt with via type-defs etc. Thanks, Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From garzik@gtf.org Fri Jul 11 12:59:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 12:59:07 -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 h6BJx22x018079 for ; Fri, 11 Jul 2003 12:59:02 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id A9EC7665C; Fri, 11 Jul 2003 15:58:56 -0400 (EDT) Date: Fri, 11 Jul 2003 15:58:56 -0400 From: Jeff Garzik To: Ben Greear Cc: Matthew Wilcox , netdev@oss.sgi.com, "David S. Miller" , Arnaldo Carvalho de Melo Subject: Re: [PATCH] netdev_ops Message-ID: <20030711195856.GB30449@gtf.org> 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> <20030711193215.GH16037@gtf.org> <3F0F153C.4040506@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F0F153C.4040506@candelatech.com> User-Agent: Mutt/1.3.28i X-archive-position: 3971 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 Fri, Jul 11, 2003 at 12:51:24PM -0700, Ben Greear wrote: > >3) The func ptrs _count() are totally bogus. We have an unconditional > >indirect reference to a function call which does nothing but return a > >driver constant. > > > >I personally think that having ethtool_ops members manually calling > >the ->get_drvinfo hook is a _lot_ cleaner than 10,000 foo_count hooks. > > > >3.a) Further, we will inevitably be adding more counts in the future. > >If we wanted to be truly expandable, and you really don't like the > >counts being in struct ethtool_gdrvinfo, then create a struct > >ethtool_counts that puts all the constants in one place. > > Suppose we do this, how will we make a user-space app that tries to > read this be backwards/forwards compatible? It's trivial to return the existing values in the gdrvinfo struct in addition to a new ethtool_count struct. Full ABI compat is maintained. > >4) I don't see why ethtool.h suddenly needs to include linux/types.h, > >when it hasn't needed it in all this time until now. > > If we're changing lots of stuff...it would be nice to change the u32 > etc to something that user-space can easily handle, as ethtool.h is > (for better or worse) being included from user-space. Minor issue > again as it can be dealt with via type-defs etc. ethtool.h isn't included in the "lots of stuff" that is changing :) As you see from Matthew's patch, all changes to ethtool.h are non-essential. Regardless, addressing your point, I consider ethtool.h a kernel-internal header, that's why it uses internal kernel types. Anybody who copies it to userspace must deal with that. It is _not_ intended to be #included directly from userspace. ethtool (the userland program) purposefully does its own typedefs and stuff. Jeff From greearb@candelatech.com Fri Jul 11 13:07:30 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 13:07:35 -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 h6BK7U2x018944 for ; Fri, 11 Jul 2003 13:07:30 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h6BK77Kk003058; Fri, 11 Jul 2003 13:07:07 -0700 Message-ID: <3F0F18EB.9020609@candelatech.com> Date: Fri, 11 Jul 2003 13:07:07 -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: Matthew Wilcox , netdev@oss.sgi.com, "David S. Miller" , Arnaldo Carvalho de Melo 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> <20030711193215.GH16037@gtf.org> <3F0F153C.4040506@candelatech.com> <20030711195856.GB30449@gtf.org> In-Reply-To: <20030711195856.GB30449@gtf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3972 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: > Regardless, addressing your point, I consider ethtool.h a > kernel-internal header, that's why it uses internal kernel types. > Anybody who copies it to userspace must deal with that. It is _not_ > intended to be #included directly from userspace. ethtool (the userland > program) purposefully does its own typedefs and stuff. Any particular reason to not include it directly? It seems no more likely to cause problems than to use some potentially out-of-date copy in user-space. (And it might make the compile slightly tougher if you are distributing primarily as source.) Ben -- 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 Fri Jul 11 13:22:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 13:22:28 -0700 (PDT) Received: from www.linux.org.uk (IDENT:Ps7Jkti7p0v3eSE3YE9HD4rxkVLvkPRO@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6BKMM2x019383 for ; Fri, 11 Jul 2003 13:22:23 -0700 Received: from willy by www.linux.org.uk with local (Exim 4.14) id 19b2aI-0003WB-NJ; Fri, 11 Jul 2003 19:25:30 +0100 Date: Fri, 11 Jul 2003 19:25:30 +0100 From: Matthew Wilcox To: Jeff Garzik Cc: Matthew Wilcox , netdev@oss.sgi.com Subject: Re: [PATCH] Move eth_mac_addr and eth_change_mtu Message-ID: <20030711182530.GH20424@parcelfarce.linux.theplanet.co.uk> References: <20030711181946.GG20424@parcelfarce.linux.theplanet.co.uk> <20030711182330.GC16037@gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030711182330.GC16037@gtf.org> User-Agent: Mutt/1.4.1i X-archive-position: 3973 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 Fri, Jul 11, 2003 at 02:23:30PM -0400, Jeff Garzik wrote: > On Fri, Jul 11, 2003 at 07:19:46PM +0100, Matthew Wilcox wrote: > > Move eth_mac_addr() and eth_change_mtu() from drivers/net/net_init.c > > to net/ethernet/eth.c > > Why? It's not used outside of net_init.c AFAICS. Preparation for the next stage of netdev_ops > And even so, don't you want to export those symbols? Yep, you're right, I'll need to do that too. -- "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 willy@www.linux.org.uk Fri Jul 11 14:05:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 14:05:31 -0700 (PDT) Received: from www.linux.org.uk (IDENT:jA8tYPLAF0T/9r9Y9pw9KeedaHMHDFiC@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6BL5O2x021030 for ; Fri, 11 Jul 2003 14:05:24 -0700 Received: from willy by www.linux.org.uk with local (Exim 4.14) id 19b550-0006y8-Pb; Fri, 11 Jul 2003 22:05:22 +0100 Date: Fri, 11 Jul 2003 22:05:22 +0100 From: Matthew Wilcox To: Jeff Garzik Cc: Matthew Wilcox , netdev@oss.sgi.com Subject: Re: [PATCH] Move eth_mac_addr and eth_change_mtu Message-ID: <20030711210522.GM20424@parcelfarce.linux.theplanet.co.uk> References: <20030711181946.GG20424@parcelfarce.linux.theplanet.co.uk> <20030711182330.GC16037@gtf.org> <20030711182530.GH20424@parcelfarce.linux.theplanet.co.uk> <3F0F24B1.5050200@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F0F24B1.5050200@pobox.com> User-Agent: Mutt/1.4.1i X-archive-position: 3974 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 Fri, Jul 11, 2003 at 04:57:21PM -0400, Jeff Garzik wrote: > Well, I don't see/understand this next-stage, so elaboration would be > nice. As-is, I do not support merging this patch. It's the next stage you're calling for -- move these functions: dev->change_mtu = eth_change_mtu; dev->hard_header = eth_header; dev->rebuild_header = eth_rebuild_header; dev->set_mac_address = eth_mac_addr; dev->hard_header_cache = eth_header_cache; dev->header_cache_update= eth_header_cache_update; dev->hard_header_parse = eth_header_parse; into netdev_ops. Which means each driver will need to see them. I thought I could justify moving these functions already on the grounds that if you were looking for the definition of eth_change_mtu(), net_init.c would be a much less likely place to look than net/ethernet/eth.c -- "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 willy@www.linux.org.uk Fri Jul 11 14:56:42 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 14:56:50 -0700 (PDT) Received: from www.linux.org.uk (IDENT:RmxoIlt5ODsZ517Je9ENpFD1oPdh+ibf@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6BLue2x022731 for ; Fri, 11 Jul 2003 14:56:41 -0700 Received: from willy by www.linux.org.uk with local (Exim 4.14) id 19b5sd-0000Mj-MV; Fri, 11 Jul 2003 22:56:39 +0100 Date: Fri, 11 Jul 2003 22:56:39 +0100 From: Matthew Wilcox To: Jeff Garzik Cc: Matthew Wilcox , netdev@oss.sgi.com Subject: Re: [PATCH] Move eth_mac_addr and eth_change_mtu Message-ID: <20030711215639.GN20424@parcelfarce.linux.theplanet.co.uk> References: <20030711181946.GG20424@parcelfarce.linux.theplanet.co.uk> <20030711182330.GC16037@gtf.org> <20030711182530.GH20424@parcelfarce.linux.theplanet.co.uk> <3F0F24B1.5050200@pobox.com> <20030711210522.GM20424@parcelfarce.linux.theplanet.co.uk> <3F0F294F.4060804@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F0F294F.4060804@pobox.com> User-Agent: Mutt/1.4.1i X-archive-position: 3975 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 Fri, Jul 11, 2003 at 05:17:03PM -0400, Jeff Garzik wrote: > Matthew Wilcox wrote: > >On Fri, Jul 11, 2003 at 04:57:21PM -0400, Jeff Garzik wrote: > > > >>Well, I don't see/understand this next-stage, so elaboration would be > >>nice. As-is, I do not support merging this patch. > > > > > >It's the next stage you're calling for -- move these functions: > > > > dev->change_mtu = eth_change_mtu; > > dev->hard_header = eth_header; > > dev->rebuild_header = eth_rebuild_header; > > dev->set_mac_address = eth_mac_addr; > > dev->hard_header_cache = eth_header_cache; > > dev->header_cache_update= eth_header_cache_update; > > dev->hard_header_parse = eth_header_parse; > > > >into netdev_ops. Which means each driver will need to see them. > > Drivers don't need to see them now, they shouldn't need to see them > after netdev_ops. > > It's hidden by ether_setup. Umm. Technically, yes. Seems a bit ugly to assign to the netdev_ops struct which is shared between the devices. Won't _break_ anything (unless some crazed person has a driver which drives the ethernet and token ring versions of the same chip ;-) -- "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 davem@redhat.com Fri Jul 11 22:18:52 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 22:19:03 -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 h6C5Iq2x029465 for ; Fri, 11 Jul 2003 22:18:52 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id WAA31743; Fri, 11 Jul 2003 22:09:05 -0700 Date: Fri, 11 Jul 2003 22:09:05 -0700 From: "David S. Miller" To: James Morris Cc: jkenisto@us.ibm.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, akpm@osdl.org, jgarzik@pobox.com, alan@lxorguk.ukuu.org.uk, rddunlap@osdl.org, kuznet@ms2.inr.ac.ru Subject: Re: [PATCH - RFC] [1/2] 2.6 must-fix list - kernel error reporting Message-Id: <20030711220905.2ea9ebc5.davem@redhat.com> In-Reply-To: References: <3F0DB9A5.23723BE1@us.ibm.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 3976 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sat, 12 Jul 2003 01:37:44 +1000 (EST) James Morris wrote: > On Thu, 10 Jul 2003, Jim Keniston wrote: > > > That begs the question: do we trust that nobody but the kernel will send > > packets to a NETLINK_KERROR socket? Ordinary users can't, but any root > > application can. Without kerror_netlink_rcv(), such packets don't get > > dequeued. > > Indeed, the kernel socket buffer fills up. > > I think this needs to be addressed in the netlink code, per the patch > below. Looks good, I'll apply this. From davem@redhat.com Fri Jul 11 22:51:23 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 22:52: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 h6C5oh2x029936 for ; Fri, 11 Jul 2003 22:51:23 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id WAA31830; Fri, 11 Jul 2003 22:41:42 -0700 Date: Fri, 11 Jul 2003 22:41:42 -0700 From: "David S. Miller" To: James Morris Cc: jkenisto@us.ibm.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, akpm@osdl.org, jgarzik@pobox.com, alan@lxorguk.ukuu.org.uk, rddunlap@osdl.org, kuznet@ms2.inr.ac.ru Subject: Re: [PATCH - RFC] [1/2] 2.6 must-fix list - kernel error reporting Message-Id: <20030711224142.557b5b5e.davem@redhat.com> In-Reply-To: References: <3F0DB9A5.23723BE1@us.ibm.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 3977 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sat, 12 Jul 2003 01:37:44 +1000 (EST) James Morris wrote: > Indeed, the kernel socket buffer fills up. > > I think this needs to be addressed in the netlink code, per the patch > below. ... > + /* Don't bother queuing skb if kernel socket has no input function */ > + if (nlk->pid == 0 && !nlk->data_ready) > + goto no_dst; > + Oops, turns out this doesn't work. data_ready is never NULL, look at how netlink_kernel_create() works. Also, the broadcast case probably needs to be handled too? As an aside, to be honest what's so wrong with the socket receive buffer filling up? The damage is limited to the receive buffer size of the kernel netlink socket, but that's it. From davem@redhat.com Fri Jul 11 22:52:58 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Jul 2003 22:53:04 -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 h6C5qw2x030111 for ; Fri, 11 Jul 2003 22:52:58 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id WAA31850; Fri, 11 Jul 2003 22:44:13 -0700 Date: Fri, 11 Jul 2003 22:44:13 -0700 From: "David S. Miller" To: Krzysztof Halasa Cc: netdev@oss.sgi.com Subject: Re: 2.5.74 X.25+LAPB still kills the kernel Message-Id: <20030711224413.6aa70649.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 3978 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On 11 Jul 2003 19:27:28 +0200 Krzysztof Halasa wrote: > No need to actually use X.25+LAPB, it's enough to just compile it in. Hmmm, if nobody is listening on linux-x25 and neither is the listed "MAINTAINER" eis@baty.hanse.de we should update the linux/MAINTAINERS file to be in sync with reality. Anyways, I'll try to look into this if nobody else does. Thanks for reporting this to the right place finally, as a reward your bug will be looked at and hopefully fixed. From davem@redhat.com Sat Jul 12 00:02:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Jul 2003 00:03:00 -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 h6C71k2x031096 for ; Sat, 12 Jul 2003 00:02:26 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id XAA32018; Fri, 11 Jul 2003 23:52:47 -0700 Date: Fri, 11 Jul 2003 23:52:47 -0700 From: "David S. Miller" To: chas3@users.sourceforge.net Cc: chas@cmf.nrl.navy.mil, netdev@oss.sgi.com Subject: Re: [PATCH][2.4] more atm changes backported to 2.4 Message-Id: <20030711235247.43f05654.davem@redhat.com> In-Reply-To: <200307102033.h6AKXtsG006493@ginger.cmf.nrl.navy.mil> References: <200307102033.h6AKXtsG006493@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 3979 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Thu, 10 Jul 2003 16:31:32 -0400 chas williams wrote: > # ChangeSet 1.1014 -> 1.1015 > # net/atm/lec.c 1.15 -> 1.16 > # > # The following is the BitKeeper ChangeSet Log > # -------------------------------------------- > # 03/06/27 chas@relax.cmf.nrl.navy.mil 1.1015 > # elminate cli, make function names sane > # -------------------------------------------- Forgot some net/atm/lec.h changes for this one Chas? :-( See the patch below I had to add to my tree to get things building again. Chas, please, type "make" in a tree that has only the patches you are sending me applied. I know you said to me this is "hard" for you to do, but after this I really need you to start doing this. Thanks. # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1084 -> 1.1085 # net/atm/lec.h 1.4 -> 1.5 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 03/07/11 davem@nuts.ninka.net 1.1085 # [ATM]: Fix build, missing lec_priv member. # -------------------------------------------- # diff -Nru a/net/atm/lec.h b/net/atm/lec.h --- a/net/atm/lec.h Fri Jul 11 23:58:23 2003 +++ b/net/atm/lec.h Fri Jul 11 23:58:23 2003 @@ -101,7 +101,7 @@ establishes multiple Multicast Forward VCCs to us. This list collects all those VCCs. LANEv1 client has only one item in this list. These entries are not aged out. */ - atomic_t lec_arp_lock_var; + atomic_t lec_arp_users; struct atm_vcc *mcast_vcc; /* Default Multicast Send VCC */ struct atm_vcc *lecd; struct timer_list lec_arp_timer; From mika.liljeberg@welho.com Sat Jul 12 00:56:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Jul 2003 00:56:47 -0700 (PDT) Received: from hades.pp.htv.fi (cs180094.pp.htv.fi [213.243.180.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6C7tp2x031862 for ; Sat, 12 Jul 2003 00:56:32 -0700 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) with ESMTP id h6C7tipV001173; Sat, 12 Jul 2003 10:55:44 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) id h6C7thqI001171; Sat, 12 Jul 2003 10:55:43 +0300 X-Authentication-Warning: hades.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: [PATCH] IPv6: Allow 6to4 routes with SIT From: Mika Liljeberg To: YOSHIFUJI Hideaki Cc: netdev@oss.sgi.com Content-Type: multipart/mixed; boundary="=-5E2h62/6eEALX4jFy4kC" Message-Id: <1057996543.1142.12.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 12 Jul 2003 10:55:43 +0300 X-archive-position: 3980 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mika.liljeberg@welho.com Precedence: bulk X-list: netdev --=-5E2h62/6eEALX4jFy4kC Content-Type: text/plain Content-Transfer-Encoding: 7bit Ok, I've separated out the SIT fix. A revised anycast fix will follow. This is against 2.5.75. The patch will allow a host to set up SIT tunnels using gateway routes to 6to4 addresses. Previously this only worked with an IPv4-compatible address. Use of the deprecated IPv4-compatible addresses should not be required. Thanks, MikaL --=-5E2h62/6eEALX4jFy4kC Content-Disposition: attachment; filename=2.5.75-sit.udiff Content-Type: text/x-patch; name=2.5.75-sit.udiff; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable diff -ur orig/linux-2.5.75/net/ipv6/sit.c linux-2.5.75/net/ipv6/sit.c --- orig/linux-2.5.75/net/ipv6/sit.c 2003-07-10 23:14:48.000000000 +0300 +++ linux-2.5.75/net/ipv6/sit.c 2003-07-12 10:00:27.000000000 +0300 @@ -472,10 +472,13 @@ addr_type =3D ipv6_addr_type(addr6); } =20 - if ((addr_type & IPV6_ADDR_COMPATv4) =3D=3D 0) - goto tx_error_icmp; + if (addr_type & IPV6_ADDR_COMPATv4) + dst =3D addr6->s6_addr32[3]; + else + dst =3D try_6to4(addr6); =20 - dst =3D addr6->s6_addr32[3]; + if (!dst) + goto tx_error_icmp; } =20 { --=-5E2h62/6eEALX4jFy4kC-- From mika.liljeberg@welho.com Sat Jul 12 01:13:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Jul 2003 01:13:27 -0700 (PDT) Received: from hades.pp.htv.fi (cs180094.pp.htv.fi [213.243.180.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6C8DE2x032402 for ; Sat, 12 Jul 2003 01:13:15 -0700 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) with ESMTP id h6C8DApV001246; Sat, 12 Jul 2003 11:13:11 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) id h6C8DAZ2001245; Sat, 12 Jul 2003 11:13:10 +0300 X-Authentication-Warning: hades.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: [PATCH] IPv6: Fix broken anycast usage From: Mika Liljeberg To: YOSHIFUJI Hideaki Cc: netdev@oss.sgi.com Content-Type: multipart/mixed; boundary="=-z/elxEQiE2HR9qGdA6GJ" Message-Id: <1057997590.1142.31.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 12 Jul 2003 11:13:10 +0300 X-archive-position: 3981 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mika.liljeberg@welho.com Precedence: bulk X-list: netdev --=-z/elxEQiE2HR9qGdA6GJ Content-Type: text/plain Content-Transfer-Encoding: 7bit This is against 2.5.75. The patch fixes several places where anycast addresses should be treated equivalently with unicast addresses. In particular, this includes tunnels and routes pointing to anycast addresses. I modified ipv6_addr_type() to return IPV6_ADDR_UNICAST also for anycast addresses. IPV6_ADDR_ANYCAST is now added as an additional flag when the address is one of the known anycast addresses. I looked very hard at neighbor discovery and didn't see anything that needs to be changed, but you might want to have a second look. One small difference is that ND will now also try respond to neighbor solicitations coming from known anycast addresses (very unlikely). IMHO, this doesn't need to be policed. In general, there is no reliable way to check if a remote address is anycast, anyway. From RFC2461: Note that an anycast address is syntactically indistinguishable from a unicast address. Thus, nodes sending packets to anycast addresses don't generally know that an anycast address is being used. Throughout the rest of this document, references to unicast addresses also apply to anycast addresses in those cases where the node is unaware that a unicast address is actually an anycast address. Thanks, MikaL --=-z/elxEQiE2HR9qGdA6GJ Content-Disposition: attachment; filename=2.5.75-anycast.udiff Content-Type: text/x-patch; name=2.5.75-anycast.udiff; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable diff -ur orig/linux-2.5.75/net/ipv6/addrconf.c linux-2.5.75/net/ipv6/addrco= nf.c --- orig/linux-2.5.75/net/ipv6/addrconf.c 2003-07-10 23:14:49.000000000 +03= 00 +++ linux-2.5.75/net/ipv6/addrconf.c 2003-07-12 10:01:57.000000000 +0300 @@ -208,16 +208,15 @@ break; }; return type; - } + } else + type =3D IPV6_ADDR_UNICAST; + /* check for reserved anycast addresses */ -=09 if ((st & htonl(0xE0000000)) && ((addr->s6_addr32[2] =3D=3D htonl(0xFDFFFFFF) && (addr->s6_addr32[3] | htonl(0x7F)) =3D=3D (u32)~0) || (addr->s6_addr32[2] =3D=3D 0 && addr->s6_addr32[3] =3D=3D 0))) - type =3D IPV6_ADDR_ANYCAST; - else - type =3D IPV6_ADDR_UNICAST; + type |=3D IPV6_ADDR_ANYCAST; =20 /* Consider all addresses with the first three bits different of 000 and 111 as finished. --=-z/elxEQiE2HR9qGdA6GJ-- From jgarzik@pobox.com Sat Jul 12 10:24:48 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Jul 2003 10:25:26 -0700 (PDT) Received: from www.linux.org.uk (IDENT:p8IVHij2EXDoJU90FZ48wJG5lCKwF35U@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6CHO72x007439 for ; Sat, 12 Jul 2003 10:24:48 -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 19b5GU-0007my-Jt; Fri, 11 Jul 2003 22:17:14 +0100 Message-ID: <3F0F294F.4060804@pobox.com> Date: Fri, 11 Jul 2003 17:17:03 -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: Matthew Wilcox CC: netdev@oss.sgi.com Subject: Re: [PATCH] Move eth_mac_addr and eth_change_mtu References: <20030711181946.GG20424@parcelfarce.linux.theplanet.co.uk> <20030711182330.GC16037@gtf.org> <20030711182530.GH20424@parcelfarce.linux.theplanet.co.uk> <3F0F24B1.5050200@pobox.com> <20030711210522.GM20424@parcelfarce.linux.theplanet.co.uk> In-Reply-To: <20030711210522.GM20424@parcelfarce.linux.theplanet.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3982 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 Matthew Wilcox wrote: > On Fri, Jul 11, 2003 at 04:57:21PM -0400, Jeff Garzik wrote: > >>Well, I don't see/understand this next-stage, so elaboration would be >>nice. As-is, I do not support merging this patch. > > > It's the next stage you're calling for -- move these functions: > > dev->change_mtu = eth_change_mtu; > dev->hard_header = eth_header; > dev->rebuild_header = eth_rebuild_header; > dev->set_mac_address = eth_mac_addr; > dev->hard_header_cache = eth_header_cache; > dev->header_cache_update= eth_header_cache_update; > dev->hard_header_parse = eth_header_parse; > > into netdev_ops. Which means each driver will need to see them. Drivers don't need to see them now, they shouldn't need to see them after netdev_ops. It's hidden by ether_setup. > I thought I could justify moving these functions already on the grounds > that if you were looking for the definition of eth_change_mtu(), > net_init.c would be a much less likely place to look than > net/ethernet/eth.c If you're gonna do that, move all of ether_setup, alloc_etherdev, etc. Don't just move two out of ~10 functions. Jeff From khc@pm.waw.pl Sat Jul 12 11:23:21 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Jul 2003 11:23:58 -0700 (PDT) Received: from hq.pm.waw.pl (hq.pm.waw.pl [195.116.170.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6CIMa2x008155 for ; Sat, 12 Jul 2003 11:23:20 -0700 Received: by hq.pm.waw.pl (Postfix, from userid 10) id 61C28322F; Sat, 12 Jul 2003 20:22:33 +0200 (CEST) Received: by defiant.pm.waw.pl (Postfix, from userid 500) id 92DB63C7BC; Sat, 12 Jul 2003 18:03:36 +0200 (CEST) To: Cc: netdev@oss.sgi.com Subject: Logical interfaces (VLANs etc) flow control From: Krzysztof Halasa Date: 12 Jul 2003 18:03:35 +0200 Message-ID: Lines: 18 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 3983 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: khc@pm.waw.pl Precedence: bulk X-list: netdev Hi, probably a simple question: do we currently do any flow control for logical subinterfaces (specifically 802.1q VLANs) similar to netif_{stop,wake}_queue on the main (physical) device? I notice "txqueuelen:0" on VLAN devices and vlan_dev_hard_start_xmit() seems to not do any flow control, but I wonder if there is something else? The problem is I'm doing the same with Frame Relay, should I add a TX queue to FR PVC devices and possibly stop/wake PVC device queue in sync with physical device queue? Possibly a pointer to faq or something? -- Krzysztof Halasa Network Administrator From linux-netdev@gmane.org Sat Jul 12 12:13:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Jul 2003 12:14:03 -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 h6CJCi2x008775 for ; Sat, 12 Jul 2003 12:13:25 -0700 Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19bOyh-00025Y-00 for ; Sat, 12 Jul 2003 20:20:11 +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 19bNoy-0006za-00 for ; Sat, 12 Jul 2003 19:06:04 +0200 From: Jan Rychter Subject: Re: networking bugs and bugme.osdl.org Date: Sat, 12 Jul 2003 10:07:42 -0700 Lines: 81 Message-ID: References: <1056755336.5459.16.camel@dhcp22.swansea.linux.org.uk> <20030627.172123.78713883.davem@redhat.com> <1056827972.6295.28.camel@dhcp22.swansea.linux.org.uk> <20030628.150328.74739742.davem@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Complaints-To: usenet@main.gmane.org X-Spammers-Please: blackholeme@rychter.com User-Agent: Gnus/5.1003 (Gnus v5.10.3) XEmacs/21.4 (Rational FORTRAN, linux) Cancel-Lock: sha1:Q5NfW1XO9gryg4flfNXqetJHZ5Y= Cc: linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com X-archive-position: 3984 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jan@rychter.com Precedence: bulk X-list: netdev --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "David" =3D=3D David S Miller writes: David> From: Alan Cox Date: 28 Jun 2003 David> 20:19:32 +0100 David> On Sad, 2003-06-28 at 01:21, David S. Miller wrote: >> I respond to private reports with "please send this to the lists, >> what if I were on vacation for the next month?" I never actually >> process or analyze such reports. =20=20=20 David> Which means you miss stuff. David> Not my problem Alan. If the user gives a crap about their David> report mattering, they'll do what I ask them to do. If users David> send their report to the wrong place, it will get lost, just David> like if their cat their report into /dev/null. I have no reason David> to feel bad about the information getting lost. David> If it's too much for them to do as I ask, it's too much for me David> to consider their report. [...] I think this is one of the largest problems of the current Linux development model. Many people seem to divide people into 'users' (who aren't particularly useful) and 'developers', who actually do something. People (like me), who can devote a _little_ time to narrowing down and reporting bugs fall into the 'user-whiner' class. And get ignored. What results is that you only get bug reports from active developers. Which means that rare bugs don't get fixed. David> It is not a dream, it works perfectly fine and has done so for David> 5+ years of Linux maintainence. It hasn't. The result is a system that works for you (and other active developers), but not for everyone. As an example -- try running Linux on a modern laptop, connecting some USB devices, using ACPI, or bluetooth. Observe the resulting problems and crashes. You'll hit loads of obscure bugs that have been reported, but never got looked at in detail. I certainly have hit them and reported most, and most got dropped in various places. Does this mean these are unimportant bugs? No. This does indeed mean (following your thinking) that these aren't important bugs for me. I have worked around them in various ways, some involving actually buying new hardware, or not using certain features at all. And the cycle will go on -- others will hit the bugs, report them once, see them dropped, move on. David> Let's see, what makes more sense from my perspective. Should I David> reward and put forth effort for the people who fart a bug report David> onto the lists and expect everyone to stop what they're doing David> and fix the bug, or should I reward and put forth effort for the David> guy who spent the time to put together a stellar bug report and David> also doesn't mind retransmitting it from time to time whilst David> everyone is busy? Interesting you should think you're 'rewarding' people. I thought your goal was to have fun working on cool software and making it better. I also thought I had the same goal as a bug-reporter. When I write software, I care about every bug report and consider people doing the reporting a very valuable resource. =2D-J. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/EEBjLth4/7/QhDoRAra7AKDtnJwjGSrjhkFYu4jPKWcdBD/uagCcCl1c J0eXeqyfh5xI4A8QMxI5PkE= =MxwA -----END PGP SIGNATURE----- --=-=-=-- From jmorris@intercode.com.au Sat Jul 12 18:18:39 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Jul 2003 18:19:19 -0700 (PDT) Received: from blackbird.intercode.com.au (IDENT:PsivF3FBFfmhRFGIeTcmfMF0XWh/G824@blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6D1Hu2x011710 for ; Sat, 12 Jul 2003 18:18:38 -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 h6D1HZr20795; Sun, 13 Jul 2003 11:17:36 +1000 Date: Sun, 13 Jul 2003 11:17:35 +1000 (EST) From: James Morris To: "David S. Miller" cc: jkenisto@us.ibm.com, , , , , , , Subject: Re: [PATCH - RFC] [1/2] 2.6 must-fix list - kernel error reporting In-Reply-To: <20030711224142.557b5b5e.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3985 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 Fri, 11 Jul 2003, David S. Miller wrote: > > + /* Don't bother queuing skb if kernel socket has no input function */ > > + if (nlk->pid == 0 && !nlk->data_ready) > > + goto no_dst; > > + > > Oops, turns out this doesn't work. data_ready is never NULL, look at > how netlink_kernel_create() works. It's ok: sk->data_ready is never null, but nlk_sk(sk)->data_ready will be null unless an input function is provided there. > Also, the broadcast case probably needs to be handled > too? Netlink sockets created by netlink_kernel_create() do not subscribe to any groups and are not broadcast to. > As an aside, to be honest what's so wrong with the socket receive > buffer filling up? The damage is limited to the receive buffer size > of the kernel netlink socket, but that's it. Agreed, it's not really harmful, but it's sloppy. Better to let the application know that it can't send to the socket rather than let it keep sending (with successful return codes) until the kernel socket buffer fills up. - James -- James Morris From willy@www.linux.org.uk Sat Jul 12 18:53:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Jul 2003 18:54:00 -0700 (PDT) Received: from www.linux.org.uk (IDENT:r46fv53QoBIe7CoSSmiWelpE7m7RR7rz@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6D1qh2x012176 for ; Sat, 12 Jul 2003 18:53:24 -0700 Received: from willy by www.linux.org.uk with local (Exim 4.14) id 19b480-0005W7-18; Fri, 11 Jul 2003 21:04:24 +0100 Date: Fri, 11 Jul 2003 21:04:23 +0100 From: Matthew Wilcox To: Jeff Garzik Cc: Matthew Wilcox , netdev@oss.sgi.com, greearb@candelatech.com, "David S. Miller" , Arnaldo Carvalho de Melo Subject: Re: [PATCH] netdev_ops Message-ID: <20030711200423.GL20424@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> <20030709161520.GW1939@parcelfarce.linux.theplanet.co.uk> <20030711193215.GH16037@gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030711193215.GH16037@gtf.org> User-Agent: Mutt/1.4.1i X-archive-position: 3986 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 Fri, Jul 11, 2003 at 03:32:15PM -0400, Jeff Garzik wrote: > 1) The _ops are either too limited in scope, or too wide in scope. Couldn't agree more. I blame acme -- he wants me to push it to be much wider in scope. Let's push _all_ the function pointers into netdev_ops. But this is a mere step 1. I don't have enough network-related clout to do everything in one fell swoop. > 2.c) If #2 is decided to be netdev_ops, and all func ptrs are moved into > netdev_ops struct, then create the macro > SET_NETDEV_OPS(dev, ops) > > This allows full back compat, without ugliness in mainline tree. Yes, that was my preferred approach. > 3) The func ptrs _count() are totally bogus. We have an unconditional > indirect reference to a function call which does nothing but return a > driver constant. > > I personally think that having ethtool_ops members manually calling > the ->get_drvinfo hook is a _lot_ cleaner than 10,000 foo_count hooks. Disagree. I'd like to completely get rid of the ->get_drvinfo hook and have each hook return one thing. DaveM claims that these things are not always constants, and I believe him -- it's entirely possible different revs of a chip (with the same driver) may have more or fewer registers to return, for example. We might want to put these counts directly in the net_device itself and eliminate the function calls. That would make sense. > 4) I don't see why ethtool.h suddenly needs to include linux/types.h, > when it hasn't needed it in all this time until now. Otherwise you have to include before you include which sucks. No relying on other people to do your inclusions for you ;-) > 5) net/socket.c changes appear unrelated to this patch. You're right, they just happen to be in that tree. > 6) (low prio) Add documentation to > Documentation/networking/netdevices.txt. Most importantly, this > documents locking/context. An excellent idea. > 7) (low prio) All that similar code in net/core/ethtool.c can be > template-ized with a macro, IMO. Something like > DEF_ETHTOOL_GOP(get_coalesce, ETHTOOL_GCOALESCE, ethtool_coalesce); > DEF_ETHTOOL_SOP(set_coalesce, ethtool_coalesce); > (and templates for the ops that use edata) Maybe. I'm not a fan of templated ops as it makes it harder to grep. > 8) (security) get-eeprom op needs to check that offset+len is not > invalid, and does not wrap. Good idea, I'll add that check now. > 9) phys_id op should return an error, for consistency if nothing else. > It's simple for driver authors to unconditionally return 0 if their code > has no failure cases, and it's a slow path so adding the return in the > driver code is no big deal. OK, ditto. > 10) (low prio) since it's a slow path, what about replacing the switch > statement in dev_ethtool() with a lookup table? All the ethtool > commands are low numbers. If you do this, I would suggest using the gcc > array initializer syntax: > [ETHTOOL_GCOALESCE, ethtool_get_coalesce] > > All the ethtool ops have the same prototype, after all. Well, they don't have quite the same prototype ... that's part of the point -- get the type safety going as early as possible. -- "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 davem@redhat.com Sat Jul 12 22:31:59 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Jul 2003 22:32:36 -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 h6D5VIFl019739 for ; Sat, 12 Jul 2003 22:31:59 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id WAA01455; Sat, 12 Jul 2003 22:22:22 -0700 Date: Sat, 12 Jul 2003 22:22:22 -0700 From: "David S. Miller" To: Jan Rychter Cc: linux-net@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: networking bugs and bugme.osdl.org Message-Id: <20030712222222.01089864.davem@redhat.com> In-Reply-To: References: <1056755336.5459.16.camel@dhcp22.swansea.linux.org.uk> <20030627.172123.78713883.davem@redhat.com> <1056827972.6295.28.camel@dhcp22.swansea.linux.org.uk> <20030628.150328.74739742.davem@redhat.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 3987 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sat, 12 Jul 2003 10:07:42 -0700 Jan Rychter wrote: > Interesting you should think you're 'rewarding' people. I thought your > goal was to have fun working on cool software and making it > better. I also thought I had the same goal as a bug-reporter. > > When I write software, I care about every bug report and consider people > doing the reporting a very valuable resource. The whole game changes when you are stretched as thinly as I am. Scaling becomes everything, and nitpicking through vague and poorly composed bug reports is an absolute waste of my time as networking subsystem maintainer. If other people want to improve bug reports, put them into a cute usable database, and munge them along, that's fine with me. But _I_ only want to work with things that make the best use of my limited time. To be frank and honest, I do things that interest _ME_. And waddling through poorly made bug reports is anything but interesting, in fact it's frustrating work. I'd rather implement a software 802.11 stack or TCP Vegas implementation, THAT is what is a good use of my time because of my knowledge of how all these kinds of things work in the Linux networking. I can do things overnight that would take others weeks. Having me pillage through a bug database is a poor use of my time and capabilities. And all of my time is spent reviewing patches and dealing with the properly composed bug reports anyways, so even if I enjoyed pillaging through badly made bug reports I couldn't. People are assuming that just because _I_ don't want to work on the bad bug reports that I think nobody should. It's the exact opposite. I can't force other people to do or not do things anyways, just like everyone trying to somehow make it my "duty" to look at every single bug report cannot force me to do that. From jan@rychter.com Sat Jul 12 22:42:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Jul 2003 22:43:08 -0700 (PDT) Received: from screech.rychter.com (screech.rychter.com [212.87.11.114]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6D5fqFl020082 for ; Sat, 12 Jul 2003 22:42:33 -0700 Received: from tnuctip.rychter.com (unknown [10.197.0.2]) by screech.rychter.com (Postfix) with ESMTP id BF06E4A605; Sun, 13 Jul 2003 07:41:34 +0200 (CEST) Received: from tnuctip.rychter.com (localhost.localdomain [127.0.0.1]) by tnuctip.rychter.com (8.12.8/8.12.8) with ESMTP id h6D5gcCY008578; Sat, 12 Jul 2003 22:42:38 -0700 Received: (from jwr@localhost) by tnuctip.rychter.com (8.12.8/8.12.8/Submit) id h6D5gcNC008576; Sat, 12 Jul 2003 22:42:38 -0700 To: "David S. Miller" Cc: linux-net@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: networking bugs and bugme.osdl.org In-Reply-To: <20030712222222.01089864.davem@redhat.com> (David S. Miller's message of "Sat, 12 Jul 2003 22:22:22 -0700") References: <1056755336.5459.16.camel@dhcp22.swansea.linux.org.uk> <20030627.172123.78713883.davem@redhat.com> <1056827972.6295.28.camel@dhcp22.swansea.linux.org.uk> <20030628.150328.74739742.davem@redhat.com> <20030712222222.01089864.davem@redhat.com> User-Agent: Gnus/5.1003 (Gnus v5.10.3) XEmacs/21.4 (Rational FORTRAN, linux) X-Spammers-Please: blackholeme@rychter.com From: Jan Rychter Date: Sat, 12 Jul 2003 22:42:36 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-archive-position: 3988 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jan@rychter.com Precedence: bulk X-list: netdev --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "David" =3D=3D David S Miller writes: David> On Sat, 12 Jul 2003 10:07:42 -0700 David> Jan Rychter wrote: >> Interesting you should think you're 'rewarding' people. I thought >> your goal was to have fun working on cool software and making it >> better. I also thought I had the same goal as a bug-reporter. >> >> When I write software, I care about every bug report and consider >> people doing the reporting a very valuable resource. David> The whole game changes when you are stretched as thinly as I am. David> Scaling becomes everything, and nitpicking through vague and David> poorly composed bug reports is an absolute waste of my time as David> networking subsystem maintainer. [...] Couldn't agree more. Especially after having benefited from your code so much (starting back in the early sparc days...). David> Having me pillage through a bug database is a poor use of my David> time and capabilities. And all of my time is spent reviewing David> patches and dealing with the properly composed bug reports David> anyways, so even if I enjoyed pillaging through badly made bug David> reports I couldn't. David> People are assuming that just because _I_ don't want to work on David> the bad bug reports that I think nobody should. It's the exact David> opposite. [...] Thanks for this explanation -- I responded because I was worried you were convincing people that it's a good thing if bug reports get dropped, because the really important ones will float to the top anyway. =2D-J. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/EPFOLth4/7/QhDoRAjf+AKC59JVBV7nrxiu6AhOik4DdIWAriwCeMBrV c0f29cO6CjS03BBunvl4J0Q= =0WVV -----END PGP SIGNATURE----- --=-=-=-- From davem@redhat.com Sat Jul 12 22:44:32 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Jul 2003 22:45:05 -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 h6D5hpFl020209 for ; Sat, 12 Jul 2003 22:44:32 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id WAA01514; Sat, 12 Jul 2003 22:34:49 -0700 Date: Sat, 12 Jul 2003 22:34:49 -0700 From: "David S. Miller" To: James Morris Cc: jkenisto@us.ibm.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, akpm@osdl.org, jgarzik@pobox.com, alan@lxorguk.ukuu.org.uk, rddunlap@osdl.org, kuznet@ms2.inr.ac.ru Subject: Re: [PATCH - RFC] [1/2] 2.6 must-fix list - kernel error reporting Message-Id: <20030712223449.550d822a.davem@redhat.com> In-Reply-To: References: <20030711224142.557b5b5e.davem@redhat.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 3989 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sun, 13 Jul 2003 11:17:35 +1000 (EST) James Morris wrote: > On Fri, 11 Jul 2003, David S. Miller wrote: > > > Oops, turns out this doesn't work. data_ready is never NULL, look at > > how netlink_kernel_create() works. > > It's ok: sk->data_ready is never null, but nlk_sk(sk)->data_ready will be > null unless an input function is provided there. > > > Also, the broadcast case probably needs to be handled > > too? > > Netlink sockets created by netlink_kernel_create() do not subscribe to any > groups and are not broadcast to. Oops, you're right on both counts, I brainfarted here. I'll apply your original patch, thanks. From pekkas@netcore.fi Sun Jul 13 00:05:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jul 2003 00:06:00 -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 h6D74jFl021993 for ; Sun, 13 Jul 2003 00:05:27 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6D74dB20158 for ; Sun, 13 Jul 2003 10:04:40 +0300 Date: Sun, 13 Jul 2003 10:04:39 +0300 (EEST) From: Pekka Savola To: 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: 3990 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 FWIW, DJB created a (probably biased) web page: http://cr.yp.to/unix/disablenetwork.html to describe the idea and alternatives at a bit more length. On Tue, 8 Jul 2003, James Morris wrote: > 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 > -- 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 davem@redhat.com Sun Jul 13 00:48:20 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jul 2003 00:48:36 -0700 (PDT) Received: from rth.ninka.net (rth.ninka.net [216.101.162.244]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6D7mJFl022499 for ; Sun, 13 Jul 2003 00:48:19 -0700 Received: from rth.ninka.net (localhost.localdomain [127.0.0.1]) by rth.ninka.net (8.12.8/8.12.8) with SMTP id h6D7mIxI009195; Sun, 13 Jul 2003 00:48:18 -0700 Date: Sun, 13 Jul 2003 00:48:18 -0700 From: "David S. Miller" To: "Alan Shih" Cc: linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: TCP IP Offloading Interface Message-Id: <20030713004818.4f1895be.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.2 (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: 3991 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sun, 13 Jul 2003 00:33:00 -0700 "Alan Shih" wrote: > Or TOE is a forbidden discussion? TOE is evil, read this: http://www.usenix.org/events/hotos03/tech/full_papers/mogul/mogul.pdf TOE is exactly suboptimal for the very things performance matters, high connection rates. Your return is also absolutely questionable. Servers "serve" data and we offload all of the send side TCP processing that can reasonably be done (segmentation, checksumming). I've never seen an impartial benchmark showing that TCP send side performance goes up as a result of using TOE vs. the usual segmentation + checksum offloading offered today. On receive side, clever RX buffer flipping tricks are the way to go and require no protocol changes and nothing gross like TOE or weird buffer ownership protocols like RDMA requires. I've made postings showing how such a scheme can work using a limited flow cache on the networking card. I don't have a reference handy, but I suppose someone else does. And finally, this discussion belongs on the "networking" lists. Nearly all of the "networking" developers don't have time to sift through linux-kernel every day. From hch@lst.de Sun Jul 13 07:38:06 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jul 2003 07:38:15 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [212.34.189.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6DEc4Fl002787 for ; Sun, 13 Jul 2003 07:38:05 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6DCvnDC024415 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 13 Jul 2003 14:57:49 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.3) id h6DCvmud024413 for netdev@oss.sgi.com; Sun, 13 Jul 2003 14:57:48 +0200 Date: Sun, 13 Jul 2003 14:57:48 +0200 From: Christoph Hellwig To: netdev@oss.sgi.com Subject: [PATCH] fix arcnet module refcounting Message-ID: <20030713125748.GA24403@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Spam-Score: -3 () PATCH_UNIFIED_DIFF,USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) X-archive-position: 3992 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: netdev struct arnet_local needs a struct module *owner, that also cleans up nicely lots of the code. --- 1.6/drivers/net/arcnet/arc-rimi.c Sat Jun 28 08:20:41 2003 +++ edited/drivers/net/arcnet/arc-rimi.c Thu Jul 10 16:28:29 2003 @@ -47,7 +47,6 @@ static int arcrimi_status(struct net_device *dev); static void arcrimi_setmask(struct net_device *dev, int mask); static int arcrimi_reset(struct net_device *dev, int really_reset); -static void arcrimi_openclose(struct net_device *dev, bool open); static void arcrimi_copy_to_card(struct net_device *dev, int bufnum, int offset, void *buf, int count); static void arcrimi_copy_from_card(struct net_device *dev, int bufnum, int offset, @@ -179,7 +178,7 @@ lp->hw.status = arcrimi_status; lp->hw.intmask = arcrimi_setmask; lp->hw.reset = arcrimi_reset; - lp->hw.open_close = arcrimi_openclose; + lp->hw.owner = THIS_MODULE; lp->hw.copy_to_card = arcrimi_copy_to_card; lp->hw.copy_from_card = arcrimi_copy_from_card; lp->mem_start = ioremap(dev->mem_start, dev->mem_end - dev->mem_start + 1); @@ -252,15 +251,6 @@ /* done! return success. */ return 0; -} - - -static void arcrimi_openclose(struct net_device *dev, int open) -{ - if (open) - MOD_INC_USE_COUNT; - else - MOD_DEC_USE_COUNT; } static void arcrimi_setmask(struct net_device *dev, int mask) --- 1.14/drivers/net/arcnet/arcnet.c Sun Jun 15 01:16:09 2003 +++ edited/drivers/net/arcnet/arcnet.c Thu Jul 10 16:53:24 2003 @@ -343,7 +343,10 @@ static int arcnet_open(struct net_device *dev) { struct arcnet_local *lp = (struct arcnet_local *) dev->priv; - int count, newmtu; + int count, newmtu, error; + + if (!try_module_get(lp->hw.owner)) + return -ENODEV; BUGLVL(D_PROTO) { int count; @@ -360,8 +363,9 @@ /* try to put the card in a defined state - if it fails the first * time, actually reset it. */ + error = -ENODEV; if (ARCRESET(0) && ARCRESET(1)) - return -ENODEV; + goto out_module_put; newmtu = choose_mtu(); if (newmtu < dev->mtu) @@ -391,7 +395,7 @@ lp->rfc1201.sequence = 1; /* bring up the hardware driver */ - ARCOPEN(1); + lp->hw.open(dev); if (dev->dev_addr[0] == 0) BUGMSG(D_NORMAL, "WARNING! Station address 00 is reserved " @@ -415,6 +419,10 @@ netif_start_queue(dev); return 0; + + out_module_put: + module_put(lp->hw.owner); + return error; } @@ -432,8 +440,8 @@ mdelay(1); /* shut down the card */ - ARCOPEN(0); - + lp->hw.close(dev); + module_put(lp->hw.owner); return 0; } --- 1.5/drivers/net/arcnet/com20020-isa.c Thu May 22 10:08:06 2003 +++ edited/drivers/net/arcnet/com20020-isa.c Thu Jul 10 16:30:53 2003 @@ -131,14 +131,6 @@ MODULE_PARM(clockm, "i"); MODULE_LICENSE("GPL"); -static void com20020isa_open_close(struct net_device *dev, bool open) -{ - if (open) - MOD_INC_USE_COUNT; - else - MOD_DEC_USE_COUNT; -} - int init_module(void) { struct net_device *dev; @@ -160,7 +152,7 @@ lp->clockp = clockp & 7; lp->clockm = clockm & 3; lp->timeout = timeout & 3; - lp->hw.open_close_ll = com20020isa_open_close; + lp->owner = THIS_MODULE; dev->base_addr = io; dev->irq = irq; --- 1.13/drivers/net/arcnet/com20020-pci.c Thu May 22 10:08:06 2003 +++ edited/drivers/net/arcnet/com20020-pci.c Thu Jul 10 16:54:28 2003 @@ -60,14 +60,6 @@ MODULE_PARM(clockm, "i"); MODULE_LICENSE("GPL"); -static void com20020pci_open_close(struct net_device *dev, bool open) -{ - if (open) - MOD_INC_USE_COUNT; - else - MOD_DEC_USE_COUNT; -} - static int __devinit com20020pci_probe(struct pci_dev *pdev, const struct pci_device_id *id) { struct net_device *dev; @@ -111,7 +103,7 @@ lp->clockp = clockp & 7; lp->clockm = clockm & 3; lp->timeout = timeout; - lp->hw.open_close_ll = com20020pci_open_close; + lp->hw.owner = THIS_MODULE; if (check_region(ioaddr, ARCNET_TOTAL_SIZE)) { BUGMSG(D_INIT, "IO region %xh-%xh already allocated.\n", --- 1.5/drivers/net/arcnet/com20020.c Sat Feb 15 00:22:10 2003 +++ edited/drivers/net/arcnet/com20020.c Thu Jul 10 16:33:36 2003 @@ -50,13 +50,12 @@ static int com20020_status(struct net_device *dev); static void com20020_setmask(struct net_device *dev, int mask); static int com20020_reset(struct net_device *dev, int really_reset); -static void com20020_openclose(struct net_device *dev, bool open); static void com20020_copy_to_card(struct net_device *dev, int bufnum, int offset, void *buf, int count); static void com20020_copy_from_card(struct net_device *dev, int bufnum, int offset, void *buf, int count); static void com20020_set_mc_list(struct net_device *dev); - +static void com20020_close(struct net_device *, bool); static void com20020_copy_from_card(struct net_device *dev, int bufnum, int offset, void *buf, int count) @@ -162,13 +161,14 @@ lp = (struct arcnet_local *) dev->priv; + lp->hw.owner = THIS_MODULE; lp->hw.command = com20020_command; lp->hw.status = com20020_status; lp->hw.intmask = com20020_setmask; lp->hw.reset = com20020_reset; - lp->hw.open_close = com20020_openclose; lp->hw.copy_to_card = com20020_copy_to_card; lp->hw.copy_from_card = com20020_copy_from_card; + lp->hw.close = com20020_close; dev->set_multicast_list = com20020_set_mc_list; @@ -298,24 +298,17 @@ return ASTATUS(); } - -static void com20020_openclose(struct net_device *dev, bool open) +static void com20020_close(struct net_device *dev, bool open) { struct arcnet_local *lp = (struct arcnet_local *) dev->priv; int ioaddr = dev->base_addr; - if (open) { - MOD_INC_USE_COUNT; - } - else { + if (!open) { /* disable transmitter */ lp->config &= ~TXENcfg; SETCONF; - MOD_DEC_USE_COUNT; } - lp->hw.open_close_ll(dev, open); } - /* Set or clear the multicast filter for this adaptor. * num_addrs == -1 Promiscuous mode, receive all packets --- 1.7/drivers/net/arcnet/com90io.c Thu May 22 10:08:06 2003 +++ edited/drivers/net/arcnet/com90io.c Thu Jul 10 16:28:29 2003 @@ -47,7 +47,6 @@ static int com90io_status(struct net_device *dev); static void com90io_setmask(struct net_device *dev, int mask); static int com90io_reset(struct net_device *dev, int really_reset); -static void com90io_openclose(struct net_device *dev, bool open); static void com90io_copy_to_card(struct net_device *dev, int bufnum, int offset, void *buf, int count); static void com90io_copy_from_card(struct net_device *dev, int bufnum, int offset, @@ -257,7 +256,7 @@ lp->hw.status = com90io_status; lp->hw.intmask = com90io_setmask; lp->hw.reset = com90io_reset; - lp->hw.open_close = com90io_openclose; + lp->hw.owner = THIS_MODULE; lp->hw.copy_to_card = com90io_copy_to_card; lp->hw.copy_from_card = com90io_copy_from_card; @@ -342,14 +341,6 @@ short ioaddr = dev->base_addr; AINTMASK(mask); -} - -static void com90io_openclose(struct net_device *dev, int open) -{ - if (open) - MOD_INC_USE_COUNT; - else - MOD_DEC_USE_COUNT; } static void com90io_copy_to_card(struct net_device *dev, int bufnum, int offset, --- 1.7/drivers/net/arcnet/com90xx.c Thu May 22 10:08:06 2003 +++ edited/drivers/net/arcnet/com90xx.c Thu Jul 10 16:28:29 2003 @@ -58,7 +58,6 @@ static int com90xx_status(struct net_device *dev); static void com90xx_setmask(struct net_device *dev, int mask); static int com90xx_reset(struct net_device *dev, int really_reset); -static void com90xx_openclose(struct net_device *dev, bool open); static void com90xx_copy_to_card(struct net_device *dev, int bufnum, int offset, void *buf, int count); static void com90xx_copy_from_card(struct net_device *dev, int bufnum, int offset, @@ -450,7 +449,7 @@ lp->hw.status = com90xx_status; lp->hw.intmask = com90xx_setmask; lp->hw.reset = com90xx_reset; - lp->hw.open_close = com90xx_openclose; + lp->hw.owner = THIS_MODULE; lp->hw.copy_to_card = com90xx_copy_to_card; lp->hw.copy_from_card = com90xx_copy_from_card; lp->mem_start = ioremap(dev->mem_start, dev->mem_end - dev->mem_start + 1); @@ -569,16 +568,6 @@ /* done! return success. */ return 0; } - - -static void com90xx_openclose(struct net_device *dev, bool open) -{ - if (open) - MOD_INC_USE_COUNT; - else - MOD_DEC_USE_COUNT; -} - static void com90xx_copy_to_card(struct net_device *dev, int bufnum, int offset, void *buf, int count) --- 1.4/include/linux/arcdevice.h Sun Jun 15 01:16:09 2003 +++ edited/include/linux/arcdevice.h Thu Jul 10 16:48:24 2003 @@ -291,12 +291,13 @@ /* hardware-specific functions */ struct { + struct module *owner; void (*command) (struct net_device * dev, int cmd); int (*status) (struct net_device * dev); void (*intmask) (struct net_device * dev, int mask); bool (*reset) (struct net_device * dev, bool really_reset); - void (*open_close) (struct net_device * dev, bool open); - void (*open_close_ll) (struct net_device * dev, bool open); + void (*open) (struct net_device * dev); + void (*close) (struct net_device * dev); void (*copy_to_card) (struct net_device * dev, int bufnum, int offset, void *buf, int count); @@ -312,7 +313,6 @@ #define ACOMMAND(x) (lp->hw.command(dev, (x))) #define ASTATUS() (lp->hw.status(dev)) #define AINTMASK(x) (lp->hw.intmask(dev, (x))) -#define ARCOPEN(x) (lp->hw.open_close(dev, (x))) From linux-netdev@gmane.org Sun Jul 13 07:51:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jul 2003 07:51:21 -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 h6DEpEFl003158 for ; Sun, 13 Jul 2003 07:51:15 -0700 Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19biB9-0006BM-00 for ; Sun, 13 Jul 2003 16:50:19 +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 19bi9I-000649-00 for ; Sun, 13 Jul 2003 16:48:24 +0200 From: Anand Kumria Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked Date: Mon, 14 Jul 2003 00:49:17 +1000 Lines: 38 Message-ID: References: <20030711.005542.04973601.yoshfuji@linux-ipv6.org> 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: Pan/0.11.2 (Unix) X-Comment-To: "Pekka Savola" X-archive-position: 3993 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wildfire@progsoc.org Precedence: bulk X-list: netdev On Fri, 11 Jul 2003 02:08:20 +1000, Pekka Savola wrote: > On Fri, 11 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B > wrote: >> In article <20030710154302.GE1722@zip.com.au> (at Fri, 11 Jul 2003 >> 01:43:03 +1000), CaT says: >> >> > With 2.4.21-pre2 I can get a nice tunnel going over my ppp connection >> > and as such get ipv6 connectivity. I think went to 2.4.21 and then to >> > 2.4.22-pre4 and bringing up the tunnel fails as follows: >> : >> > ip addr add 3ffe:8001:000c:ffff::37/127 dev sit1 >> > ip route add ::/0 via 3ffe:8001:000c:ffff::36 >> > RTNETLINK answers: Invalid argument >> >> This is not bug, but rather misconfiguration; you cannot use prefix::, >> which is mandatory subnet routers anycast address, as unicast address. I'm the other end of this link, so I'm wondering how this is a misconfiguration. RFC3513 2.6.1 suggests to me that 3ffe:8001:c:ffff::36/127 is the router address (my end) and the other side should be 3ffe:8001:c:ffff::37/127. > While technically correct, I'm still not sure if this is (pragmatically) > the correct approach. It's OK to set a default route to go to the > subnet routers anycast address (so, setting a route to prefix:: should > not give you EINVAL). > Both Yoshifuji and yourself suggested that /127 isn't the way to go and that this is something v6ops ought to take up. I had a quick look at the v6ops IETF group and nothing struck me. What would you recommend I look at to see why /127 is a bad idea or /64 is a better idea than /127? Thanks, Anand From pekkas@netcore.fi Sun Jul 13 09:23:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jul 2003 09:23:23 -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 h6DGNGFl004187 for ; Sun, 13 Jul 2003 09:23:17 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6DGN5823685; Sun, 13 Jul 2003 19:23:05 +0300 Date: Sun, 13 Jul 2003 19:23:05 +0300 (EEST) From: Pekka Savola To: Anand Kumria cc: netdev@oss.sgi.com Subject: Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 3995 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 See http://www.ietf.org/internet-drafts/draft-savola-ipv6-127-prefixlen-04.txt it should answer your questions. On Mon, 14 Jul 2003, Anand Kumria wrote: > On Fri, 11 Jul 2003 02:08:20 +1000, Pekka Savola wrote: > > > On Fri, 11 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B > > wrote: > >> In article <20030710154302.GE1722@zip.com.au> (at Fri, 11 Jul 2003 > >> 01:43:03 +1000), CaT says: > >> > >> > With 2.4.21-pre2 I can get a nice tunnel going over my ppp connection > >> > and as such get ipv6 connectivity. I think went to 2.4.21 and then to > >> > 2.4.22-pre4 and bringing up the tunnel fails as follows: > >> : > >> > ip addr add 3ffe:8001:000c:ffff::37/127 dev sit1 > >> > ip route add ::/0 via 3ffe:8001:000c:ffff::36 > >> > RTNETLINK answers: Invalid argument > >> > >> This is not bug, but rather misconfiguration; you cannot use prefix::, > >> which is mandatory subnet routers anycast address, as unicast address. > > I'm the other end of this link, so I'm wondering how this is a > misconfiguration. RFC3513 2.6.1 suggests to me that > 3ffe:8001:c:ffff::36/127 is the router address (my end) and the other > side should be 3ffe:8001:c:ffff::37/127. > > > While technically correct, I'm still not sure if this is (pragmatically) > > the correct approach. It's OK to set a default route to go to the > > subnet routers anycast address (so, setting a route to prefix:: should > > not give you EINVAL). > > > > Both Yoshifuji and yourself suggested that /127 isn't the way to go and > that this is something v6ops ought to take up. I had a quick look at the > v6ops IETF group and nothing struck me. > > What would you recommend I look at to see why /127 is a bad idea or /64 > is a better idea than /127? > > Thanks, > Anand > > -- 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 roland@topspin.com Sun Jul 13 09:22:38 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jul 2003 09:22:45 -0700 (PDT) Received: from umhlanga.STRATNET.NET (mail.netapps.org [12.162.17.40]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6DGMbFl004123 for ; Sun, 13 Jul 2003 09:22:38 -0700 Received: from exch-1.topspincom.com ([12.162.17.3]) by umhlanga.STRATNET.NET with Microsoft SMTPSVC(5.0.2195.5329); Sun, 13 Jul 2003 09:22:35 -0700 Received: from gold ([10.10.253.60] unverified) by exch-1.topspincom.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 13 Jul 2003 09:22:34 -0700 Received: from roland by gold with local (Exim 3.35 #1 (Debian)) id 19bjcO-0001mp-00; Sun, 13 Jul 2003 09:22:32 -0700 To: "David S. Miller" Cc: "Alan Shih" , linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: TCP IP Offloading Interface References: <20030713004818.4f1895be.davem@redhat.com> X-Message-Flag: Warning: May contain useful information X-Priority: 1 X-MSMail-Priority: High From: Roland Dreier Date: 13 Jul 2003 09:22:32 -0700 In-Reply-To: <20030713004818.4f1895be.davem@redhat.com> Message-ID: <52u19qwg53.fsf@topspin.com> Lines: 43 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 13 Jul 2003 16:22:34.0890 (UTC) FILETIME=[F7BF4EA0:01C3495A] X-archive-position: 3994 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: roland@topspin.com Precedence: bulk X-list: netdev David> TOE is evil, read this: David> http://www.usenix.org/events/hotos03/tech/full_papers/mogul/mogul.pdf David> TOE is exactly suboptimal for the very things performance David> matters, high connection rates. David> Your return is also absolutely questionable. Servers David> "serve" data and we offload all of the send side TCP David> processing that can reasonably be done (segmentation, David> checksumming). David> I've never seen an impartial benchmark showing that TCP David> send side performance goes up as a result of using TOE David> vs. the usual segmentation + checksum offloading offered David> today. David> On receive side, clever RX buffer flipping tricks are the David> way to go and require no protocol changes and nothing gross David> like TOE or weird buffer ownership protocols like RDMA David> requires. David> I've made postings showing how such a scheme can work using David> a limited flow cache on the networking card. I don't have David> a reference handy, but I suppose someone else does. Your ideas are certainly very interesting, and I would be happy to see hardware that supports flow identification. But the Usenix paper you're citing completely disagrees with you! For example, Mogul writes: "Nevertheless, copy-avoidance designs have not been widely adopted, due to significant limitations. For example, when network maximum segment size (MSS) values are smaller than VM page sizes, which is often the case, page-remapping techniques are insufficient (and page-remapping often imposes overheads of its own.)" In fact, his conclusion is: "However, as hardware trends change the feasibility and economics of network-based storage connections, RDMA will become a significant and appropriate justification for TOEs." - Roland From alan@lxorguk.ukuu.org.uk Sun Jul 13 09:34:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jul 2003 09:34:19 -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 h6DGYEFl005312 for ; Sun, 13 Jul 2003 09:34:15 -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 h6DGVcKd000604; Sun, 13 Jul 2003 17:31:38 +0100 Received: (from alan@localhost) by dhcp22.swansea.linux.org.uk (8.12.8/8.12.8/Submit) id h6DGVZn3000602; Sun, 13 Jul 2003 17:31:35 +0100 X-Authentication-Warning: dhcp22.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: TCP IP Offloading Interface From: Alan Cox To: Roland Dreier Cc: "David S. Miller" , Alan Shih , Linux Kernel Mailing List , linux-net@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <52u19qwg53.fsf@topspin.com> References: <20030713004818.4f1895be.davem@redhat.com> <52u19qwg53.fsf@topspin.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1058113895.554.7.camel@dhcp22.swansea.linux.org.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 13 Jul 2003 17:31:35 +0100 X-archive-position: 3996 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 Sul, 2003-07-13 at 17:22, Roland Dreier wrote: > Your ideas are certainly very interesting, and I would be happy to see > hardware that supports flow identification. But the Usenix paper > you're citing completely disagrees with you! For example, Mogul writes: Take a look at who holds the official internet land speed record. Its not a TOE using system. > "Nevertheless, copy-avoidance designs have not been widely adopted, > due to significant limitations. For example, when network maximum > segment size (MSS) values are smaller than VM page sizes, which is > often the case, page-remapping techniques are insufficient (and > page-remapping often imposes overheads of its own.)" Page remapping is adequate for send of data when the MSS is below the VM page size since you don't have to send all of the page you pinned or set COW/SOW (sleep on write) For receive if your hardware can do demux from the tcp headers and expecting sequence then page remapping isn't needed either. Finally if you are streaming objects by non mapped references (eg sendfile or see LM's paper from long ago on splice()) then the problem goes away. > In fact, his conclusion is: > > "However, as hardware trends change the feasibility and economics of > network-based storage connections, RDMA will become a significant > and appropriate justification for TOEs." > > - Roland > - > 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 Sun Jul 13 09:50:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jul 2003 09:50:19 -0700 (PDT) Received: from www.linux.org.uk (IDENT:yJAaINogrkOb0+tSqMHBJ9/bzzCG3CKg@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6DGoCFl006235 for ; Sun, 13 Jul 2003 09:50:13 -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 19bk39-000466-IV; Sun, 13 Jul 2003 17:50:11 +0100 Message-ID: <3F118DB7.5060009@pobox.com> Date: Sun, 13 Jul 2003 12:49:59 -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: Alan Cox CC: Roland Dreier , "David S. Miller" , Alan Shih , Linux Kernel Mailing List , linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: TCP IP Offloading Interface References: <20030713004818.4f1895be.davem@redhat.com> <52u19qwg53.fsf@topspin.com> <1058113895.554.7.camel@dhcp22.swansea.linux.org.uk> In-Reply-To: <1058113895.554.7.camel@dhcp22.swansea.linux.org.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3997 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 Alan Cox wrote: > Finally if you are streaming objects by non mapped references (eg > sendfile or see LM's paper from long ago on splice()) then the problem > goes away. I had forgotten all about splice. For interested readers, here is the link: http://www.bitmover.com/lm/papers/splice.ps Jeff From davem@redhat.com Sun Jul 13 16:11:04 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jul 2003 16:11:13 -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 h6DNB3Fl010851 for ; Sun, 13 Jul 2003 16:11:04 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id QAA09626; Sun, 13 Jul 2003 16:02:00 -0700 Date: Sun, 13 Jul 2003 16:02:00 -0700 From: "David S. Miller" To: Roland Dreier Cc: alan@storlinksemi.com, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: TCP IP Offloading Interface Message-Id: <20030713160200.571716cf.davem@redhat.com> In-Reply-To: <52u19qwg53.fsf@topspin.com> References: <20030713004818.4f1895be.davem@redhat.com> <52u19qwg53.fsf@topspin.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 3998 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On 13 Jul 2003 09:22:32 -0700 Roland Dreier wrote: > David> TOE is evil, read this: > > David> http://www.usenix.org/events/hotos03/tech/full_papers/mogul/mogul.pdf > Your ideas are certainly very interesting, and I would be happy to see > hardware that supports flow identification. But the Usenix paper > you're citing completely disagrees with you! I didn't say I agree with all of Moguls ideas, just his anti-TOE arguments. For example, I also think RDMA sucks too yet he thinks it's a good iea. > For example, Mogul writes: > > "Nevertheless, copy-avoidance designs have not been widely adopted, > due to significant limitations. For example, when network maximum > segment size (MSS) values are smaller than VM page sizes, which is > often the case, page-remapping techniques are insufficient (and > page-remapping often imposes overheads of its own.)" On send this doesn't matter, on receive you use my clever receive buffer handling + flow cache idea to accumulate the data portion of packets into page sized chunks for the networking to flip. You obviously don't understand my ideas if you think that it matters whether there is some relationship between the MTU and the system page size necessary for the scheme to work. From lm@bitmover.com Sun Jul 13 16:35:13 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jul 2003 16:35:19 -0700 (PDT) Received: from smtp.bitmover.com (smtp.bitmover.com [192.132.92.12]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6DNZBFl011739 for ; Sun, 13 Jul 2003 16:35:13 -0700 Received: from work.bitmover.com (ipcop.bitmover.com [192.132.92.15]) by smtp.bitmover.com (8.12.9/8.12.9) with ESMTP id h6E7bnm7005163; Mon, 14 Jul 2003 00:37:49 -0700 Received: (from lm@localhost) by work.bitmover.com (8.11.6/8.11.6) id h6DNZ3s13205; Sun, 13 Jul 2003 16:35:03 -0700 Date: Sun, 13 Jul 2003 16:35:03 -0700 From: Larry McVoy To: "David S. Miller" Cc: Roland Dreier , alan@storlinksemi.com, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: TCP IP Offloading Interface Message-ID: <20030713233503.GA31793@work.bitmover.com> Mail-Followup-To: Larry McVoy , "David S. Miller" , Roland Dreier , alan@storlinksemi.com, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com References: <20030713004818.4f1895be.davem@redhat.com> <52u19qwg53.fsf@topspin.com> <20030713160200.571716cf.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030713160200.571716cf.davem@redhat.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=0.5, required 7, AWL, DATE_IN_PAST_06_12) X-archive-position: 3999 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lm@bitmover.com Precedence: bulk X-list: netdev On Sun, Jul 13, 2003 at 04:02:00PM -0700, David S. Miller wrote: > On send this doesn't matter, on receive you use my clever receive > buffer handling + flow cache idea to accumulate the data portion of > packets into page sized chunks for the networking to flip. Please don't. I think page flipping was a bad idea. I think you'd be better off to try and make the data flow up the stack in small enough windows that it all sits in the cache. One thing SGI taught me (not that they wanted to do so) is that infinitely large packets are infinitely stupid, for lots of reasons. One is that you have to buffer them somewhere and another is that the bigger they are the bigger your cache needs to be to go fast. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm From davem@redhat.com Sun Jul 13 16:49:07 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jul 2003 16:49:14 -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 h6DNn7Fl012535 for ; Sun, 13 Jul 2003 16:49:07 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id QAA09694; Sun, 13 Jul 2003 16:40:03 -0700 Date: Sun, 13 Jul 2003 16:40:03 -0700 From: "David S. Miller" To: Larry McVoy Cc: roland@topspin.com, alan@storlinksemi.com, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: TCP IP Offloading Interface Message-Id: <20030713164003.21839eb4.davem@redhat.com> In-Reply-To: <20030713233503.GA31793@work.bitmover.com> References: <20030713004818.4f1895be.davem@redhat.com> <52u19qwg53.fsf@topspin.com> <20030713160200.571716cf.davem@redhat.com> <20030713233503.GA31793@work.bitmover.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4000 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sun, 13 Jul 2003 16:35:03 -0700 Larry McVoy wrote: > On Sun, Jul 13, 2003 at 04:02:00PM -0700, David S. Miller wrote: > > On send this doesn't matter, on receive you use my clever receive > > buffer handling + flow cache idea to accumulate the data portion of > > packets into page sized chunks for the networking to flip. > > Please don't. I think page flipping was a bad idea. I think you'd be > better off to try and make the data flow up the stack in small enough > windows that it all sits in the cache. At 10GB/sec nothing fits in the cache :-) > One thing SGI taught me (not that they wanted to do so) is that infinitely > large packets are infinitely stupid, for lots of reasons. One is that > you have to buffer them somewhere and another is that the bigger they > are the bigger your cache needs to be to go fast. The whole point is to not touch any of this data. The idea is to push the pages directly into the page cache of the filesystem. I'm not talking about doing this for userspace normal sys_recvmsg() type reads, that's an entirely different topic but if we ever did all agree to do something like that we'd have the network level infrastructure to do it already. From lm@bitmover.com Sun Jul 13 16:54:32 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jul 2003 16:54:36 -0700 (PDT) Received: from smtp.bitmover.com (smtp.bitmover.com [192.132.92.12]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6DNsVFl012861 for ; Sun, 13 Jul 2003 16:54:32 -0700 Received: from work.bitmover.com (ipcop.bitmover.com [192.132.92.15]) by smtp.bitmover.com (8.12.9/8.12.9) with ESMTP id h6E7vAm7005336; Mon, 14 Jul 2003 00:57:11 -0700 Received: (from lm@localhost) by work.bitmover.com (8.11.6/8.11.6) id h6DNsOj13384; Sun, 13 Jul 2003 16:54:24 -0700 Date: Sun, 13 Jul 2003 16:54:24 -0700 From: Larry McVoy To: "David S. Miller" Cc: Larry McVoy , roland@topspin.com, alan@storlinksemi.com, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: TCP IP Offloading Interface Message-ID: <20030713235424.GB31793@work.bitmover.com> Mail-Followup-To: Larry McVoy , "David S. Miller" , Larry McVoy , roland@topspin.com, alan@storlinksemi.com, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com References: <20030713004818.4f1895be.davem@redhat.com> <52u19qwg53.fsf@topspin.com> <20030713160200.571716cf.davem@redhat.com> <20030713233503.GA31793@work.bitmover.com> <20030713164003.21839eb4.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030713164003.21839eb4.davem@redhat.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=0.5, required 7, AWL, DATE_IN_PAST_06_12) X-archive-position: 4001 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lm@bitmover.com Precedence: bulk X-list: netdev > The whole point is to not touch any of this data. > > The idea is to push the pages directly into the page cache > of the filesystem. It doesn't work. Measure the cost of the VM operations before you go down this path. Just set up a system call that swaps a page with a kernel allocated buffer and then see how many of those you can do a second. Maybe Linux is so blindingly fast this makes sense but IRIX certainly wasn't, the VM overhead hurt like crazy. Every time I tried to push the page flip idea or offloading or any of that crap, Andy Bechtolsheim would tell "the CPUs will get faster faster than you can make that work". He was right. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm From davem@redhat.com Sun Jul 13 17:02:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jul 2003 17:02:33 -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 h6E02QFl013250 for ; Sun, 13 Jul 2003 17:02:27 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id QAA09728; Sun, 13 Jul 2003 16:53:23 -0700 Date: Sun, 13 Jul 2003 16:53:23 -0700 From: "David S. Miller" To: Larry McVoy Cc: lm@bitmover.com, roland@topspin.com, alan@storlinksemi.com, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: TCP IP Offloading Interface Message-Id: <20030713165323.3fc2601f.davem@redhat.com> In-Reply-To: <20030713235424.GB31793@work.bitmover.com> References: <20030713004818.4f1895be.davem@redhat.com> <52u19qwg53.fsf@topspin.com> <20030713160200.571716cf.davem@redhat.com> <20030713233503.GA31793@work.bitmover.com> <20030713164003.21839eb4.davem@redhat.com> <20030713235424.GB31793@work.bitmover.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4002 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sun, 13 Jul 2003 16:54:24 -0700 Larry McVoy wrote: > Every time I tried to push the page flip idea or offloading or any of > that crap, Andy Bechtolsheim would tell "the CPUs will get faster faster > than you can make that work". He was right. I really don't see why receive is so much of a big deal compared to send, and we do a send side version of this stuff already with zero problems. The NFS code is already basically ready to handle a fragmented packet (headers + pages), and could stick the page part into the page cache easily on receive. And it's not the CPUs that really limit us here, it's memory bandwidth. It's one thing to have a PCI-X bus fast enough to service 10Ggb/sec rates, it's yet another thing to have a memory bus and RAM underneath that which can handle moving that data over it _twice_. The infrastructure needed to support this on the networking side help us support other useful things, such as driver local packet buffer recycling. From lm@bitmover.com Sun Jul 13 17:22:09 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jul 2003 17:22:17 -0700 (PDT) Received: from smtp.bitmover.com (smtp.bitmover.com [192.132.92.12]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6E0M9Fl013691 for ; Sun, 13 Jul 2003 17:22:09 -0700 Received: from work.bitmover.com (ipcop.bitmover.com [192.132.92.15]) by smtp.bitmover.com (8.12.9/8.12.9) with ESMTP id h6E8Olm7005704; Mon, 14 Jul 2003 01:24:47 -0700 Received: (from lm@localhost) by work.bitmover.com (8.11.6/8.11.6) id h6E0M0213745; Sun, 13 Jul 2003 17:22:00 -0700 Date: Sun, 13 Jul 2003 17:22:00 -0700 From: Larry McVoy To: "David S. Miller" Cc: Larry McVoy , roland@topspin.com, alan@storlinksemi.com, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: TCP IP Offloading Interface Message-ID: <20030714002200.GA24697@work.bitmover.com> Mail-Followup-To: Larry McVoy , "David S. Miller" , Larry McVoy , roland@topspin.com, alan@storlinksemi.com, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com References: <20030713004818.4f1895be.davem@redhat.com> <52u19qwg53.fsf@topspin.com> <20030713160200.571716cf.davem@redhat.com> <20030713233503.GA31793@work.bitmover.com> <20030713164003.21839eb4.davem@redhat.com> <20030713235424.GB31793@work.bitmover.com> <20030713165323.3fc2601f.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030713165323.3fc2601f.davem@redhat.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=0.5, required 7, AWL, DATE_IN_PAST_06_12) X-archive-position: 4003 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lm@bitmover.com Precedence: bulk X-list: netdev On Sun, Jul 13, 2003 at 04:53:23PM -0700, David S. Miller wrote: > On Sun, 13 Jul 2003 16:54:24 -0700 > Larry McVoy wrote: > > > Every time I tried to push the page flip idea or offloading or any of > > that crap, Andy Bechtolsheim would tell "the CPUs will get faster faster > > than you can make that work". He was right. > > I really don't see why receive is so much of a big deal > compared to send, and we do a send side version of this > stuff already with zero problems. Hey, maybe it isn't, but could you please quantify the cost of the VM operations? How hard is that? -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm From davem@redhat.com Sun Jul 13 17:33:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jul 2003 17:33:25 -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 h6E0XIFl014064 for ; Sun, 13 Jul 2003 17:33:18 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id RAA09795; Sun, 13 Jul 2003 17:24:14 -0700 Date: Sun, 13 Jul 2003 17:24:14 -0700 From: "David S. Miller" To: Larry McVoy Cc: lm@bitmover.com, roland@topspin.com, alan@storlinksemi.com, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: TCP IP Offloading Interface Message-Id: <20030713172414.5c888094.davem@redhat.com> In-Reply-To: <20030714002200.GA24697@work.bitmover.com> References: <20030713004818.4f1895be.davem@redhat.com> <52u19qwg53.fsf@topspin.com> <20030713160200.571716cf.davem@redhat.com> <20030713233503.GA31793@work.bitmover.com> <20030713164003.21839eb4.davem@redhat.com> <20030713235424.GB31793@work.bitmover.com> <20030713165323.3fc2601f.davem@redhat.com> <20030714002200.GA24697@work.bitmover.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4004 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sun, 13 Jul 2003 17:22:00 -0700 Larry McVoy wrote: > Hey, maybe it isn't, but could you please quantify the cost of the VM > operations? How hard is that? Ok. So the page is in a non-uptodate state, NFS would have it locked, and anyone else trying to get at it would sleep. This page we have currently is "dummy" in that it is only a place holder in case we don't get a full page from the networking. We have all the infrastructure to do everything up to this point. Next, if the networking gave us a full page, we'd "replace" the dummy page with this one, which would involve: 1) delete the dummy page from the lookup, insert the networking's page 2) arrange so that all sleepers on the dummy page will do a relookup and find the new page And when we're done with the operation we wake everyone up. I can't see any part of this turning out to be expensive. From davem@redhat.com Sun Jul 13 17:37:39 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jul 2003 17:37:44 -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 h6E0bcFl014380 for ; Sun, 13 Jul 2003 17:37:39 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id RAA09815; Sun, 13 Jul 2003 17:28:36 -0700 Date: Sun, 13 Jul 2003 17:28:36 -0700 From: "David S. Miller" To: Roland Dreier Cc: alan@storlinksemi.com, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: TCP IP Offloading Interface Message-Id: <20030713172836.5dd493f5.davem@redhat.com> In-Reply-To: <52llv2vu06.fsf@topspin.com> References: <20030713004818.4f1895be.davem@redhat.com> <52u19qwg53.fsf@topspin.com> <20030713160200.571716cf.davem@redhat.com> <52llv2vu06.fsf@topspin.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4005 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On 13 Jul 2003 17:20:41 -0700 Roland Dreier wrote: > David> I didn't say I agree with all of Moguls ideas, just his > David> anti-TOE arguments. For example, I also think RDMA sucks > David> too yet he thinks it's a good iea. > > Sure, he talks about some weaknesses of TOE, but his conclusion is > that the time has come for OS developers to start working on TCP > offload (for storage). The bad assumption here is that this belongs in the OS. Let me ask you this, how many modern scsi drivers have to speak every piece of the SCSI bus protocol. Or fibre channel? All of it is done on the cards, and that is what I think the iSCSI people should be doing instead of putting garbage into the OS. And I've presented a solution to the problem at the OS level that doesn't require broken things like TOE and RDMA yet arrives at the same solution. > But I also think Mogul is right: iSCSI HBAs are going to force OS > designers to deal with TCP offload. You don't need to offload TCP, it's the segmentation and checksuming that has the high cost not the actual TCP logic in the operating system. RDMA and TOE both add unnecessary complications. My solution requires no protocol changes, just smart hardware which needs to be designed for any of the presented ideas anyways. From Valdis.Kletnieks@vt.edu Sun Jul 13 17:46:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jul 2003 17:47:03 -0700 (PDT) Received: from turing-police.cc.vt.edu (h80ad2494.async.vt.edu [128.173.36.148]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6E0kfFl014721 for ; Sun, 13 Jul 2003 17:46:42 -0700 Received: from turing-police.cc.vt.edu (localhost [127.0.0.1]) by turing-police.cc.vt.edu (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6E0kcMQ021180; Sun, 13 Jul 2003 20:46:38 -0400 Message-Id: <200307140046.h6E0kcMQ021180@turing-police.cc.vt.edu> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4+dev To: "David S. Miller" Cc: linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: TCP IP Offloading Interface In-Reply-To: Your message of "Sun, 13 Jul 2003 16:53:23 PDT." <20030713165323.3fc2601f.davem@redhat.com> From: Valdis.Kletnieks@vt.edu References: <20030713004818.4f1895be.davem@redhat.com> <52u19qwg53.fsf@topspin.com> <20030713160200.571716cf.davem@redhat.com> <20030713233503.GA31793@work.bitmover.com> <20030713164003.21839eb4.davem@redhat.com> <20030713235424.GB31793@work.bitmover.com> <20030713165323.3fc2601f.davem@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-797710378P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sun, 13 Jul 2003 20:46:38 -0400 X-archive-position: 4006 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Valdis.Kletnieks@vt.edu Precedence: bulk X-list: netdev --==_Exmh_-797710378P Content-Type: text/plain; charset=us-ascii On Sun, 13 Jul 2003 16:53:23 PDT, "David S. Miller" said: > I really don't see why receive is so much of a big deal > compared to send, and we do a send side version of this > stuff already with zero problems. Well.... there's optimizations you can do on the send side.. > The NFS code is already basically ready to handle a fragmented packet > (headers + pages), and could stick the page part into the page cache > easily on receive. For example, in this case, you know a priori what the IP header will look like, so you can use tricks like scatter-gather to send the header from one place and a page-aligned data buffer from another, or start the packet at (page boundary - IP_hrd_len), or tricks of that sort. In 20 years, I've seen a lot of vendors do a lot of ugly things to speed up their IP stack, often based on the fact that they knew a lot about the packet before they started assembling it. It's hard to do tricks like that when you don't know (for instance) how many IP option fields the packet has until you've already started sucking the packet off the wire - at which point either the NIC itself has to be clever (Hmm, there's that IP offload again) or you have literally about 30 CPU cycles to do interrrupt latency *and* decide what to do.... --==_Exmh_-797710378P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE/Ef1ucC3lWbTT17ARArLqAJ9Nm0BoBW0sAS12YRjHQqnbS8taaACgisgU ouu0kT76znvhJ7TPiI5Nm8I= =J2r1 -----END PGP SIGNATURE----- --==_Exmh_-797710378P-- From lm@bitmover.com Sun Jul 13 17:48:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jul 2003 17:48:32 -0700 (PDT) Received: from smtp.bitmover.com (smtp.bitmover.com [192.132.92.12]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6E0mIFl015029 for ; Sun, 13 Jul 2003 17:48:18 -0700 Received: from work.bitmover.com (ipcop.bitmover.com [192.132.92.15]) by smtp.bitmover.com (8.12.9/8.12.9) with ESMTP id h6E8oum7006040; Mon, 14 Jul 2003 01:50:56 -0700 Received: (from lm@localhost) by work.bitmover.com (8.11.6/8.11.6) id h6E0m9i14058; Sun, 13 Jul 2003 17:48:09 -0700 Date: Sun, 13 Jul 2003 17:48:09 -0700 From: Larry McVoy To: "David S. Miller" Cc: Larry McVoy , roland@topspin.com, alan@storlinksemi.com, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: TCP IP Offloading Interface Message-ID: <20030714004809.GB24697@work.bitmover.com> Mail-Followup-To: Larry McVoy , "David S. Miller" , Larry McVoy , roland@topspin.com, alan@storlinksemi.com, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com References: <20030713004818.4f1895be.davem@redhat.com> <52u19qwg53.fsf@topspin.com> <20030713160200.571716cf.davem@redhat.com> <20030713233503.GA31793@work.bitmover.com> <20030713164003.21839eb4.davem@redhat.com> <20030713235424.GB31793@work.bitmover.com> <20030713165323.3fc2601f.davem@redhat.com> <20030714002200.GA24697@work.bitmover.com> <20030713172414.5c888094.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030713172414.5c888094.davem@redhat.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=0.5, required 7, AWL, DATE_IN_PAST_06_12) X-archive-position: 4007 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lm@bitmover.com Precedence: bulk X-list: netdev On Sun, Jul 13, 2003 at 05:24:14PM -0700, David S. Miller wrote: > I can't see any part of this turning out to be expensive. In theory, practice and theory are the same... I think the point I'm trying to make is that the VM stuff costs something and it shouldn't be that hard to dummy up a system call to measure it. It was counterintuitive as hell at SGI that the VM stuff would cost that much and the reasons are subtle. Part of the problem turned out to be falling out of the instruction cache - the network stack and the VM system didn't fit and that left no room at all for the app. If you are trading instruction cache misses for data misses, err, dude, I think that might be a problem. The point is to process all the data with less, not more, cache misses, right? In fact, if we agree on that then that leads you to considering the various ways you could do this and maybe your way is the right way but maybe there is a less cache intensive way. If you're right you're right, so peace. But I'd like the definition of "right" to be "less cache misses to do the same thing". In fact, if I managed to communicate only one thing in my entire set of rants and it was "pay attention to cache misses", hey, that'd be cool with me. That's how you make things go fast and I like fast. Think about it, a 3GHz machine is a .3ns clock cycle and the suckers are super scalar and hyper threaded and all that crud. Memory is about 133ns away. That's 400 clocks of stall for each cache miss. Lotta code can run in 400 clocks of super scalar/hyper threaded/fully buzzword enabled processors. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm From davem@redhat.com Sun Jul 13 17:52:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jul 2003 17:52:04 -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 h6E0ptFl015350 for ; Sun, 13 Jul 2003 17:51:58 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id RAA09880; Sun, 13 Jul 2003 17:42:42 -0700 Date: Sun, 13 Jul 2003 17:42:42 -0700 From: "David S. Miller" To: Valdis.Kletnieks@vt.edu Cc: linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: TCP IP Offloading Interface Message-Id: <20030713174242.3ceb8213.davem@redhat.com> In-Reply-To: <200307140046.h6E0kcMQ021180@turing-police.cc.vt.edu> References: <20030713004818.4f1895be.davem@redhat.com> <52u19qwg53.fsf@topspin.com> <20030713160200.571716cf.davem@redhat.com> <20030713233503.GA31793@work.bitmover.com> <20030713164003.21839eb4.davem@redhat.com> <20030713235424.GB31793@work.bitmover.com> <20030713165323.3fc2601f.davem@redhat.com> <200307140046.h6E0kcMQ021180@turing-police.cc.vt.edu> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4008 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sun, 13 Jul 2003 20:46:38 -0400 Valdis.Kletnieks@vt.edu wrote: > On Sun, 13 Jul 2003 16:53:23 PDT, "David S. Miller" said: > > > I really don't see why receive is so much of a big deal > > compared to send, and we do a send side version of this > > stuff already with zero problems. > > Well.... there's optimizations you can do on the send side.. I consider the send side complete covered already. We don't touch any of the data portion, we only put together the headers. > It's hard to do tricks like that when you don't know (for instance) how > many IP option fields the packet has until you've already started sucking > the packet off the wire - at which point either the NIC itself has to be clever > (Hmm, there's that IP offload again) or you have literally about 30 CPU cycles > to do interrrupt latency *and* decide what to do.... There are cards, both existing and in development, that have very simple header parsing engines you can program to do stuff like this, it isn't hard at all. But this is only half of the problem, you need a flow cache and clever RX buffer management as well to make the RX side zero-copy stuff work. From jgarzik@pobox.com Sun Jul 13 17:53:07 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jul 2003 17:53:11 -0700 (PDT) Received: from www.linux.org.uk (IDENT:4ZYppHV6YjA5pG0aQq3aH4lRDjZDEYWG@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6E0r5Fl015661 for ; Sun, 13 Jul 2003 17:53:06 -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 19bkAv-0004LC-1P; Sun, 13 Jul 2003 17:58:13 +0100 Message-ID: <3F118F99.1020104@pobox.com> Date: Sun, 13 Jul 2003 12:58:01 -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: Alan Cox CC: Roland Dreier , "David S. Miller" , Alan Shih , Linux Kernel Mailing List , linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: TCP IP Offloading Interface References: <20030713004818.4f1895be.davem@redhat.com> <52u19qwg53.fsf@topspin.com> <1058113895.554.7.camel@dhcp22.swansea.linux.org.uk> In-Reply-To: <1058113895.554.7.camel@dhcp22.swansea.linux.org.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4009 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 Alan Cox wrote: > Finally if you are streaming objects by non mapped references (eg > sendfile or see LM's paper from long ago on splice()) then the problem > goes away. As an aside, I really like sendfile's semantics except for * People occasionally want to add a receivefile(2). I disagree... sendfile(2) interface should be really be considered a universal "fdcopy" interface, regardless of what the 'to' and 'from' file descriptors are attached to. File to socket. Socket to file. File to file. socket to socket. All should be supported, even if the fallback is a stupid (but small!) in-kernel copy loop. * Copy-until-EOF semantics are either undefined, or, unclear to me personally. Jeff From acme@conectiva.com.br Sun Jul 13 22:52:55 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Jul 2003 22:53:01 -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 h6E5qrFl024722 for ; Sun, 13 Jul 2003 22:52:54 -0700 Received: from [200.193.244.212] (helo=brinquendo.conectiva.com.br) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 19bwJn-0001xY-00; Mon, 14 Jul 2003 02:56:13 -0300 Received: by brinquendo.conectiva.com.br (Postfix, from userid 500) id 9B9251966D; Mon, 14 Jul 2003 05:53:55 +0000 (UTC) Date: Mon, 14 Jul 2003 02:53:54 -0300 From: Arnaldo Carvalho de Melo To: Matthew Wilcox Cc: Jeff Garzik , netdev@oss.sgi.com, greearb@candelatech.com, "David S. Miller" Subject: Re: [PATCH] netdev_ops Message-ID: <20030714055354.GP3825@conectiva.com.br> 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> <20030711193215.GH16037@gtf.org> <20030711200423.GL20424@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030711200423.GL20424@parcelfarce.linux.theplanet.co.uk> X-Url: http://advogato.org/person/acme Organization: Conectiva S.A. User-Agent: Mutt/1.5.4i X-archive-position: 4010 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 Fri, Jul 11, 2003 at 09:04:23PM +0100, Matthew Wilcox escreveu: > On Fri, Jul 11, 2003 at 03:32:15PM -0400, Jeff Garzik wrote: > > 1) The _ops are either too limited in scope, or too wide in scope. > > Couldn't agree more. I blame acme -- he wants me to push it to be much > wider in scope. Let's push _all_ the function pointers into netdev_ops. Hey, it was just a brainstorm session ;) Anyway, I'm heavily backlogged as I'm on a business trip for several days already, I'll try to read all this thread when I'm back home 8) - Arnaldo From nf@hipac.org Mon Jul 14 01:44:56 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jul 2003 01:45:02 -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 h6E8isFl026852 for ; Mon, 14 Jul 2003 01:44:55 -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 h6E8ikqk2143996; Mon, 14 Jul 2003 10:44:46 +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 KAA8770343; Mon, 14 Jul 2003 10:44:45 +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 19bywv-0006P0-00; Mon, 14 Jul 2003 10:44:45 +0200 From: Michael Bellion and Thomas Heinz Reply-To: nf@hipac.org To: linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: [RFC] High Performance Packet Classifiction for tc framework Date: Mon, 14 Jul 2003 10:45:40 +0200 User-Agent: KMail/1.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200307141045.40999.nf@hipac.org> X-archive-position: 4011 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 We are planning to port our HIPAC algorithm to the tc framework and we ask you for some comments about several issues. HIPAC is a novel packet classification framework which replaces the common linear approach with a more advanced data structure which offers highly efficient and locking friendly packet matching. Currently, people using lots of filters suffer from a big performance penalty. In contrast, HIPAC is able to handle thousands of filters without much slowdown compared to having no filters at all. There already exists one application of the HIPAC algorithm for the netfilter framework: nf-hipac. Details about the project can be found at our website http://www.hipac.org or our sourceforge project page at http://www.sourceforge.net/projects/nf-hipac Several performance tests of nf-hipac have been done so far (see our website) and have proven our claims. So it would be great if tc users could benefit from HIPAC too. Certainly, we'd like to know first whether HIPAC makes sense for the tc framework at all. From the nf-hipac worst case performance tests we know that our algorithm should be faster in all cases as soon as you have approx. 20 filters. Below 20 filters there is no difference between nf-hipac and the iptables filter table. So basically the question is: Are people using the tc framework with lots of filters? Some numbers would be helpful. Since we can only improve performance of u32 and fw filters it's also interesting whether such rulesets typically consist of those filters in the main. The tc framework is very flexible with respect to where filters can be attached. Unfortunately this cannot be mapped into one HIPAC data structure. Our current design allows to attach filters anywhere but only the filters attached to the top level qdisc would benefit from the HIPAC algorithm. Would this be a noticeable restriction? Here is a short overview of the main design goals: - new qdisc for HIPAC which is basically a container for the filters; it can only be attached as top level qdisc - new HIPAC classifier which supports all native nf-hipac matches (src/dst ip, proto, src/dst port, ttl, state, in_iface, icmp type, tcpflags, fragments) and additionally fwmark - the HIPAC classifier can only be attached to the HIPAC qdisc and vice versa the HIPAC qdisc only accepts HIPAC classifiers - the HIPAC qdisc consists of only one single class to which the "next" qdisc must be attached - the HIPAC classifier can contain a number of existing classifiers (u32, fw, route, rsvp, tcindex) whereby the semantics is as follows: a HIPAC classifier matches if the native matches and also each of the embedded classifiers match; the returned tcf_result is the one from the final classifier (=> intermediate classifiers are reduced to a match) - it is still possible to attach non-hipac classifiers to other qdiscs and classes Regards, +-----------------------+----------------------+ | Michael Bellion | Thomas Heinz | | | | +-----------------------+----------------------+ From rol@as2917.net Mon Jul 14 02:16:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jul 2003 02:16:25 -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 h6E9GFFl027874 for ; Mon, 14 Jul 2003 02:16:17 -0700 Received: from fifi (APuteaux-102-1-4-243.w193-253.abo.wanadoo.fr [193.253.233.243]) by tag.witbe.net (8.11.0/8.11.0) with ESMTP id h6E9G4p22542; Mon, 14 Jul 2003 09:16:04 GMT From: "Paul Rolland" To: "'Stephen Hemminger'" , , Cc: , Subject: Re: [BUG]: problem when shutting down ppp connection since 2.5.70 Date: Mon, 14 Jul 2003 11:16:04 +0200 Message-ID: <017701c349e8$8dfeeb40$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <20030709114334.5b8cf7c6.shemminger@osdl.org> Importance: Normal X-archive-position: 4012 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, I've applied the patch from Stephen on top of the 2.6.0-test1 kernel, and here is the result : Jul 14 10:57:01 donald kernel: dst route cache has 0 references Jul 14 10:57:01 donald kernel: unregister_netdevice: waiting for tap0 to become free. Usage count = -3 Jul 14 10:57:10 donald kernel: dst route cache has 0 references Jul 14 10:57:10 donald kernel: unregister_netdevice: waiting for tap0 to become free. Usage count = -3 Jul 14 10:57:20 donald kernel: dst route cache has 0 references Jul 14 10:57:20 donald kernel: unregister_netdevice: waiting for tap0 to become free. Usage count = -3 Jul 14 10:57:31 donald kernel: dst route cache has 0 references Jul 14 10:57:31 donald kernel: unregister_netdevice: waiting for tap0 to become free. Usage count = -3 This is a big change compared to 2.5.74 (.75 not tested). I guess a negative usage count should be considered as valid by unregister_netdevice. What about : --- dev.c 2003-07-14 11:13:23.000000000 +0200 +++ dev.c.orig 2003-07-14 11:13:01.000000000 +0200 @@ -2746,7 +2746,7 @@ unsigned long rebroadcast_time, warning_time; rebroadcast_time = warning_time = jiffies; - while (atomic_read(&dev->refcnt) > 0) { + while (atomic_read(&dev->refcnt) != 0) { if (time_after(jiffies, rebroadcast_time + 1 * HZ)) { rtnl_shlock(); rtnl_exlock(); Regards, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ REHAB is for quitters. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Paul Rolland, rol@witbe.net Witbe.net SA Directeur Associe -- Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur "Some people dream of success... while others wake up and work hard at it" > -----Original Message----- > From: Stephen Hemminger [mailto:shemminger@osdl.org] > Sent: Wednesday, July 09, 2003 8:44 PM > To: Paul Rolland; cfriesen@nortelnetworks.com; paulus@samba.org > Cc: linux-ppp@vger.kernel.org; netdev@oss.sgi.com > Subject: Re: [BUG]: problem when shutting down ppp connection > since 2.5.70 > > > The problem is that some protocol is still holding a reference to the > device. This is a bug in the protocol, and needs to be fixed (ie not a > ppp bug). > > Try building a kernel with only IPv4, eliminate all others then add > back until you find the culprit. > > The following patch may help also. > > diff -Nru a/net/core/dev.c b/net/core/dev.c > --- a/net/core/dev.c Wed Jul 9 11:40:56 2003 > +++ b/net/core/dev.c Wed Jul 9 11:40:56 2003 > @@ -72,6 +72,8 @@ > * - netif_rx() feedback > */ > > +#define DEBUG 1 > + > #include > #include > #include > @@ -2704,6 +2706,8 @@ > goto out; > } > > +extern void dst_dumpref(const struct net_device *dev); > + > static void netdev_wait_allrefs(struct net_device *dev) > { > unsigned long rebroadcast_time, warning_time; > @@ -2740,6 +2744,30 @@ > current->state = TASK_RUNNING; > > if (time_after(jiffies, warning_time + 10 * HZ)) { > +#ifdef DEBUG > + dst_dumpref(dev); > + > + if (dev->atalk_ptr) > + printk(KERN_INFO > "unregister_netdevice: " > + " %s: probably in use as > AppleTalk device\n", dev->name); > + if (dev->ip_ptr) > + printk(KERN_INFO > "unregister_netdevice: " > + " %s: probably in use as > IPv4 device\n", dev->name); > + > + if (dev->atalk_ptr) > + printk(KERN_INFO > "unregister_netdevice: " > + " %s: probably in use as > DECnet device\n", dev->name); > + if (dev->ip6_ptr) > + printk(KERN_INFO > "unregister_netdevice: " > + " %s: probably in use as > IPv6 device\n", dev->name); > + > + if (dev->ec_ptr) > + printk(KERN_INFO > "unregister_netdevice: " > + " %s: probably in use as > Econet device\n", dev->name); > + if (dev->ax25_ptr) > + printk(KERN_INFO > "unregister_netdevice: " > + " %s: probably in use as > AX.25 device\n", dev->name); #endif > printk(KERN_EMERG "unregister_netdevice: " > "waiting for %s to become free. Usage " > "count = %d\n", > diff -Nru a/net/core/dst.c b/net/core/dst.c > --- a/net/core/dst.c Wed Jul 9 11:40:56 2003 > +++ b/net/core/dst.c Wed Jul 9 11:40:56 2003 > @@ -41,6 +41,21 @@ > static struct timer_list dst_gc_timer = > TIMER_INITIALIZER(dst_run_gc, 0, DST_GC_MIN); > > + > +void dst_dumpref(const struct net_device *dev) > +{ > + struct dst_entry *dst; > + int count = 0; > + > + spin_lock_bh(&dst_lock); > + for (dst = dst_garbage_list; dst; dst = dst->next) { > + if (dst->dev == dev) ++count; > + } > + spin_unlock_bh(&dst_lock); > + > + printk(KERN_INFO "dst route cache has %d references\n", > count); } > + > static void dst_run_gc(unsigned long dummy) > { > int delayed = 0; > From rol@as2917.net Mon Jul 14 04:44:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jul 2003 04:44:11 -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 h6EBi1Fl010775 for ; Mon, 14 Jul 2003 04:44:02 -0700 Received: from fifi (APuteaux-102-1-4-243.w193-253.abo.wanadoo.fr [193.253.233.243]) by tag.witbe.net (8.11.0/8.11.0) with ESMTP id h6EBhqp13963; Mon, 14 Jul 2003 11:43:52 GMT From: "Paul Rolland" To: "'Paul Rolland'" , "'Stephen Hemminger'" , , Cc: , Subject: Re: [BUG]: problem when shutting down ppp connection since 2.5.70 Date: Mon, 14 Jul 2003 13:43:51 +0200 Message-ID: <018201c349fd$330a6a60$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal X-archive-position: 4013 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, I'm sorry, the patch was not complete, it should have considered the BUG_ON too... Here is one that is fine on my system : --- dev.c.orig 2003-07-14 13:41:33.000000000 +0200 +++ dev.c 2003-07-14 13:34:27.000000000 +0200 @@ -2742,7 +2742,7 @@ unsigned long rebroadcast_time, warning_time; rebroadcast_time = warning_time = jiffies; - while (atomic_read(&dev->refcnt) != 0) { + while (atomic_read(&dev->refcnt) > 0) { if (time_after(jiffies, rebroadcast_time + 1 * HZ)) { rtnl_shlock(); rtnl_exlock(); @@ -2836,7 +2836,7 @@ dev->reg_state = NETREG_UNREGISTERED; netdev_wait_allrefs(dev); - BUG_ON(atomic_read(&dev->refcnt)); + BUG_ON(atomic_read(&dev->refcnt) > 0); netdev_finish_unregister(dev); break; Still don't understand why refcnt is really bad (negative value), but at least the machine is working... Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I have a vitally important role serving as a bad example. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From albertogli@telpin.com.ar Mon Jul 14 07:03:10 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jul 2003 07:03:18 -0700 (PDT) Received: from mail.telpin.com.ar (mail.telpin.com.ar [200.43.18.243]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6EE38Fl021526 for ; Mon, 14 Jul 2003 07:03:09 -0700 Received: from telpin.com.ar (host213.200-43-231.telecom.net.ar [200.43.231.213]) by mail.telpin.com.ar (8.12.9/8.12.1) with SMTP id h6EE3snt016542; Mon, 14 Jul 2003 11:03:55 -0300 Date: Mon, 14 Jul 2003 11:03:50 -0300 From: Alberto Bertogli To: netdev@oss.sgi.com Cc: linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] IPVS' Kconfig LBLC and LBLCR configuration typo Message-ID: <20030714140350.GB1389@telpin.com.ar> Mail-Followup-To: Alberto Bertogli , netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-RAVMilter-Version: 8.4.2(snapshot 20021217) (mail) X-archive-position: 4014 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: albertogli@telpin.com.ar Precedence: bulk X-list: netdev Hi there! The following patch fixes what looks like a typo in ipvs' Kconfig (net/ipv4/ipvs/Kconfig). Both the IP_VS_LBLC and IP_VS_LBLCR schedulings have the same tristate line (well, not the same, IP_VS_LBLCR's has a 'g' missing at the end): tristate "locality-based least-connection with replication scheduling" But it looks like LBLC should be "locality-based least-connection scheduling" and LBLCR "locality-based least-connection with replication scheduling". Thanks, Alberto --- Kconfig.orig 2003-07-14 10:32:06.000000000 -0300 +++ Kconfig 2003-07-14 10:32:57.000000000 -0300 @@ -147,7 +147,7 @@ unsure, say N. config IP_VS_LBLC - tristate "locality-based least-connection with replication scheduling" + tristate "locality-based least-connection scheduling" depends on IP_VS ---help--- The locality-based least-connection scheduling algorithm is for @@ -163,7 +163,7 @@ unsure, say N. config IP_VS_LBLCR - tristate "locality-based least-connection with replication schedulin" + tristate "locality-based least-connection with replication scheduling" depends on IP_VS ---help--- The locality-based least-connection with replication scheduling From jgarzik@pobox.com Mon Jul 14 07:09:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jul 2003 07:09:53 -0700 (PDT) Received: from www.linux.org.uk (IDENT:M/qbtNfsDWHJio/1VYO4Aw0UMjqCI23V@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6EE9lFl022342 for ; Mon, 14 Jul 2003 07:09:48 -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 19b4xb-0006rs-6O; Fri, 11 Jul 2003 21:57:43 +0100 Message-ID: <3F0F24B1.5050200@pobox.com> Date: Fri, 11 Jul 2003 16:57:21 -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: Matthew Wilcox CC: netdev@oss.sgi.com Subject: Re: [PATCH] Move eth_mac_addr and eth_change_mtu References: <20030711181946.GG20424@parcelfarce.linux.theplanet.co.uk> <20030711182330.GC16037@gtf.org> <20030711182530.GH20424@parcelfarce.linux.theplanet.co.uk> In-Reply-To: <20030711182530.GH20424@parcelfarce.linux.theplanet.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4015 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 Matthew Wilcox wrote: > On Fri, Jul 11, 2003 at 02:23:30PM -0400, Jeff Garzik wrote: > >>On Fri, Jul 11, 2003 at 07:19:46PM +0100, Matthew Wilcox wrote: >> >>>Move eth_mac_addr() and eth_change_mtu() from drivers/net/net_init.c >>>to net/ethernet/eth.c >> >>Why? It's not used outside of net_init.c AFAICS. > > > Preparation for the next stage of netdev_ops Well, I don't see/understand this next-stage, so elaboration would be nice. As-is, I do not support merging this patch. Jeff From chas@locutus.cmf.nrl.navy.mil Mon Jul 14 11:01:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Jul 2003 11:01:50 -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 h6EI1WFl027535 for ; Mon, 14 Jul 2003 11:01:32 -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 h6EGWgsG016111; Mon, 14 Jul 2003 12:32:42 -0400 (EDT) Received: (from chas@localhost) by locutus.cmf.nrl.navy.mil (8.12.7/8.12.7/Submit) id h6EGUDmZ007717; Mon, 14 Jul 2003 12:30:14 -0400 Date: Mon, 14 Jul 2003 12:30:14 -0400 From: chas williams Message-Id: <200307141630.h6EGUDmZ007717@locutus.cmf.nrl.navy.mil> To: davem@redhat.com Subject: [PATCH][2.4] more atm backports for 2.4 Cc: netdev@oss.sgi.com X-Spam-Score: () hits=0.4 X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 4019 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 [atm]: cleanup lane and mpoa module interface # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1015 -> 1.1016 # net/atm/lec.c 1.16 -> 1.17 # net/atm/mpc.h 1.1 -> 1.2 # net/atm/mpc.c 1.8 -> 1.9 # net/atm/proc.c 1.8 -> 1.9 # net/atm/lec.h 1.4 -> 1.5 # net/atm/common.c 1.17 -> 1.18 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 03/06/27 chas@relax.cmf.nrl.navy.mil 1.1016 # cleanup lane and mpoa module interface # -------------------------------------------- # diff -Nru a/net/atm/common.c b/net/atm/common.c --- a/net/atm/common.c Mon Jun 30 13:21:44 2003 +++ b/net/atm/common.c Mon Jun 30 13:21:44 2003 @@ -33,21 +33,61 @@ #include #include "lec.h" #include "lec_arpc.h" -struct atm_lane_ops atm_lane_ops; -#endif -#ifdef CONFIG_ATM_LANE_MODULE +struct atm_lane_ops *atm_lane_ops; +static DECLARE_MUTEX(atm_lane_ops_mutex); + +void atm_lane_ops_set(struct atm_lane_ops *hook) +{ + down(&atm_lane_ops_mutex); + atm_lane_ops = hook; + up(&atm_lane_ops_mutex); +} + +int try_atm_lane_ops(void) +{ + down(&atm_lane_ops_mutex); + if (atm_lane_ops && try_inc_mod_count(atm_lane_ops->owner)) { + up(&atm_lane_ops_mutex); + return 1; + } + up(&atm_lane_ops_mutex); + return 0; +} + +#if defined(CONFIG_ATM_LANE_MODULE) || defined(CONFIG_ATM_MPOA_MODULE) EXPORT_SYMBOL(atm_lane_ops); +EXPORT_SYMBOL(try_atm_lane_ops); +EXPORT_SYMBOL(atm_lane_ops_set); +#endif #endif #if defined(CONFIG_ATM_MPOA) || defined(CONFIG_ATM_MPOA_MODULE) #include #include "mpc.h" -struct atm_mpoa_ops atm_mpoa_ops; -#endif +struct atm_mpoa_ops *atm_mpoa_ops; +static DECLARE_MUTEX(atm_mpoa_ops_mutex); + +void atm_mpoa_ops_set(struct atm_mpoa_ops *hook) +{ + down(&atm_mpoa_ops_mutex); + atm_mpoa_ops = hook; + up(&atm_mpoa_ops_mutex); +} + +int try_atm_mpoa_ops(void) +{ + down(&atm_mpoa_ops_mutex); + if (atm_mpoa_ops && try_inc_mod_count(atm_mpoa_ops->owner)) { + up(&atm_mpoa_ops_mutex); + return 1; + } + up(&atm_mpoa_ops_mutex); + return 0; +} #ifdef CONFIG_ATM_MPOA_MODULE EXPORT_SYMBOL(atm_mpoa_ops); -#ifndef CONFIG_ATM_LANE_MODULE -EXPORT_SYMBOL(atm_lane_ops); +EXPORT_SYMBOL(try_atm_mpoa_ops); +EXPORT_SYMBOL(atm_mpoa_ops_set); #endif #endif @@ -734,27 +774,40 @@ ret_val = -EPERM; goto done; } - if (atm_lane_ops.lecd_attach == NULL) - atm_lane_init(); - if (atm_lane_ops.lecd_attach == NULL) { /* try again */ +#if defined(CONFIG_ATM_LANE_MODULE) + if (!atm_lane_ops) + request_module("lec"); +#endif + if (try_atm_lane_ops()) { + error = atm_lane_ops->lecd_attach(vcc, (int) arg); + __MOD_DEC_USE_COUNT(atm_lane_ops->owner); + if (error >= 0) + sock->state = SS_CONNECTED; + ret_val = error; + } else ret_val = -ENOSYS; - goto done; - } - error = atm_lane_ops.lecd_attach(vcc, (int)arg); - if (error >= 0) sock->state = SS_CONNECTED; - ret_val = error; goto done; case ATMLEC_MCAST: - if (!capable(CAP_NET_ADMIN)) + if (!capable(CAP_NET_ADMIN)) { ret_val = -EPERM; - else - ret_val = atm_lane_ops.mcast_attach(vcc, (int)arg); + goto done; + } + if (try_atm_lane_ops()) { + ret_val = atm_lane_ops->mcast_attach(vcc, (int) arg); + __MOD_DEC_USE_COUNT(atm_lane_ops->owner); + } else + ret_val = -ENOSYS; goto done; case ATMLEC_DATA: - if (!capable(CAP_NET_ADMIN)) + if (!capable(CAP_NET_ADMIN)) { ret_val = -EPERM; - else - ret_val = atm_lane_ops.vcc_attach(vcc, (void*)arg); + goto done; + } + if (try_atm_lane_ops()) { + ret_val = atm_lane_ops->vcc_attach(vcc, (void *) arg); + __MOD_DEC_USE_COUNT(atm_lane_ops->owner); + } else + ret_val = -ENOSYS; goto done; #endif #if defined(CONFIG_ATM_MPOA) || defined(CONFIG_ATM_MPOA_MODULE) @@ -763,21 +816,29 @@ ret_val = -EPERM; goto done; } - if (atm_mpoa_ops.mpoad_attach == NULL) - atm_mpoa_init(); - if (atm_mpoa_ops.mpoad_attach == NULL) { /* try again */ +#if defined(CONFIG_ATM_MPOA_MODULE) + if (!atm_mpoa_ops) + request_module("mpoa"); +#endif + if (try_atm_mpoa_ops()) { + error = atm_mpoa_ops->mpoad_attach(vcc, (int) arg); + __MOD_DEC_USE_COUNT(atm_mpoa_ops->owner); + if (error >= 0) + sock->state = SS_CONNECTED; + ret_val = error; + } else ret_val = -ENOSYS; - goto done; - } - error = atm_mpoa_ops.mpoad_attach(vcc, (int)arg); - if (error >= 0) sock->state = SS_CONNECTED; - ret_val = error; goto done; case ATMMPC_DATA: - if (!capable(CAP_NET_ADMIN)) + if (!capable(CAP_NET_ADMIN)) { ret_val = -EPERM; - else - ret_val = atm_mpoa_ops.vcc_attach(vcc, arg); + goto done; + } + if (try_atm_mpoa_ops()) { + ret_val = atm_mpoa_ops->vcc_attach(vcc, arg); + __MOD_DEC_USE_COUNT(atm_mpoa_ops->owner); + } else + ret_val = -ENOSYS; goto done; #endif #if defined(CONFIG_ATM_TCP) || defined(CONFIG_ATM_TCP_MODULE) @@ -1162,40 +1223,6 @@ } -/* - * lane_mpoa_init.c: A couple of helper functions - * to make modular LANE and MPOA client easier to implement - */ - -/* - * This is how it goes: - * - * if xxxx is not compiled as module, call atm_xxxx_init_ops() - * from here - * else call atm_mpoa_init_ops() from init_module() within - * the kernel when xxxx module is loaded - * - * In either case function pointers in struct atm_xxxx_ops - * are initialized to their correct values. Either they - * point to functions in the module or in the kernel - */ - -extern struct atm_mpoa_ops atm_mpoa_ops; /* in common.c */ -extern struct atm_lane_ops atm_lane_ops; /* in common.c */ - -#if defined(CONFIG_ATM_MPOA) || defined(CONFIG_ATM_MPOA_MODULE) -void atm_mpoa_init(void) -{ -#ifndef CONFIG_ATM_MPOA_MODULE /* not module */ - atm_mpoa_init_ops(&atm_mpoa_ops); -#else - request_module("mpoa"); -#endif - - return; -} -#endif - #if defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE) #if defined(CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE) struct net_bridge_fdb_entry *(*br_fdb_get_hook)(struct net_bridge *br, @@ -1206,18 +1233,8 @@ EXPORT_SYMBOL(br_fdb_put_hook); #endif /* defined(CONFIG_ATM_LANE_MODULE) || defined(CONFIG_BRIDGE_MODULE) */ #endif /* defined(CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE) */ +#endif /* defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE) */ -void atm_lane_init(void) -{ -#ifndef CONFIG_ATM_LANE_MODULE /* not module */ - atm_lane_init_ops(&atm_lane_ops); -#else - request_module("lec"); -#endif - - return; -} -#endif static int __init atm_init(void) { diff -Nru a/net/atm/lec.c b/net/atm/lec.c --- a/net/atm/lec.c Mon Jun 30 13:21:44 2003 +++ b/net/atm/lec.c Mon Jun 30 13:21:44 2003 @@ -11,6 +11,7 @@ /* We are ethernet device */ #include #include +#include #include #include #include @@ -56,8 +57,6 @@ unsigned char *addr); extern void (*br_fdb_put_hook)(struct net_bridge_fdb_entry *ent); -static spinlock_t lec_arp_spinlock = SPIN_LOCK_UNLOCKED; - #define DUMP_PACKETS 0 /* 0 = None, * 1 = 30 first bytes * 2 = Whole packet @@ -71,9 +70,9 @@ static int lec_close(struct net_device *dev); static struct net_device_stats *lec_get_stats(struct net_device *dev); static void lec_init(struct net_device *dev); -static __inline__ struct lec_arp_table* lec_arp_find(struct lec_priv *priv, +static inline struct lec_arp_table* lec_arp_find(struct lec_priv *priv, unsigned char *mac_addr); -static __inline__ int lec_arp_remove(struct lec_arp_table **lec_arp_tables, +static inline int lec_arp_remove(struct lec_priv *priv, struct lec_arp_table *to_remove); /* LANE2 functions */ static void lane2_associate_ind (struct net_device *dev, u8 *mac_address, @@ -95,8 +94,18 @@ static struct net_device *dev_lec[MAX_LEC_ITF]; /* This will be called from proc.c via function pointer */ -struct net_device **get_dev_lec (void) { - return &dev_lec[0]; +struct net_device *get_dev_lec(int itf) +{ + struct net_device *dev; + + if (itf >= MAX_LEC_ITF) + return NULL; + rtnl_lock(); + dev = dev_lec[itf]; + if (dev) + dev_hold(dev); + rtnl_unlock(); + return dev; } #if defined(CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE) @@ -432,7 +441,7 @@ break; case l_narp_req: /* LANE2: see 7.1.35 in the lane2 spec */ entry = lec_arp_find(priv, mesg->content.normal.mac_addr); - lec_arp_remove(priv->lec_arp_tables, entry); + lec_arp_remove(priv, entry); if (mesg->content.normal.no_source_le_narp) break; @@ -833,37 +842,28 @@ return i; } -void atm_lane_init_ops(struct atm_lane_ops *ops) +static struct atm_lane_ops __atm_lane_ops = { - ops->lecd_attach = lecd_attach; - ops->mcast_attach = lec_mcast_attach; - ops->vcc_attach = lec_vcc_attach; - ops->get_lecs = get_dev_lec; - - printk("lec.c: " __DATE__ " " __TIME__ " initialized\n"); - - return; -} + .lecd_attach = lecd_attach, + .mcast_attach = lec_mcast_attach, + .vcc_attach = lec_vcc_attach, + .get_lec = get_dev_lec, + .owner = THIS_MODULE +}; static int __init lane_module_init(void) { - extern struct atm_lane_ops atm_lane_ops; - - atm_lane_init_ops(&atm_lane_ops); - + atm_lane_ops_set(&__atm_lane_ops); + printk("lec.c: " __DATE__ " " __TIME__ " initialized\n"); return 0; } static void __exit lane_module_cleanup(void) { int i; - extern struct atm_lane_ops atm_lane_ops; struct lec_priv *priv; - atm_lane_ops.lecd_attach = NULL; - atm_lane_ops.mcast_attach = NULL; - atm_lane_ops.vcc_attach = NULL; - atm_lane_ops.get_lecs = NULL; + atm_lane_ops_set(NULL); for (i = 0; i < MAX_LEC_ITF; i++) { if (dev_lec[i] != NULL) { @@ -873,7 +873,7 @@ unregister_trdev(dev_lec[i]); else #endif - unregister_netdev(dev_lec[i]); + unregister_netdev(dev_lec[i]); kfree(dev_lec[i]); dev_lec[i] = NULL; } @@ -1073,6 +1073,7 @@ for (i=0;ilec_arp_tables[i] = NULL; } + spin_lock_init(&priv->lec_arp_lock); init_timer(&priv->lec_arp_timer); priv->lec_arp_timer.expires = jiffies+LEC_ARP_REFRESH_INTERVAL; priv->lec_arp_timer.data = (unsigned long)priv; @@ -1109,21 +1110,20 @@ * Insert entry to lec_arp_table * LANE2: Add to the end of the list to satisfy 8.1.13 */ -static __inline__ void -lec_arp_add(struct lec_arp_table **lec_arp_tables, - struct lec_arp_table *to_add) +static inline void +lec_arp_add(struct lec_priv *priv, struct lec_arp_table *to_add) { unsigned long flags; unsigned short place; struct lec_arp_table *tmp; - spin_lock_irqsave(&lec_arp_spinlock, flags); + spin_lock_irqsave(&priv->lec_arp_lock, flags); place = HASH(to_add->mac_addr[ETH_ALEN-1]); - tmp = lec_arp_tables[place]; + tmp = priv->lec_arp_tables[place]; to_add->next = NULL; if (tmp == NULL) - lec_arp_tables[place] = to_add; + priv->lec_arp_tables[place] = to_add; else { /* add to the end */ while (tmp->next) @@ -1131,7 +1131,7 @@ tmp->next = to_add; } - spin_unlock_irqrestore(&lec_arp_spinlock, flags); + spin_unlock_irqrestore(&priv->lec_arp_lock, flags); DPRINTK("LEC_ARP: Added entry:%2.2x %2.2x %2.2x %2.2x %2.2x %2.2x\n", 0xff&to_add->mac_addr[0], 0xff&to_add->mac_addr[1], @@ -1142,8 +1142,8 @@ /* * Remove entry from lec_arp_table */ -static __inline__ int -lec_arp_remove(struct lec_arp_table **lec_arp_tables, +static inline int +lec_arp_remove(struct lec_priv *priv, struct lec_arp_table *to_remove) { unsigned long flags; @@ -1151,22 +1151,22 @@ struct lec_arp_table *tmp; int remove_vcc=1; - spin_lock_irqsave(&lec_arp_spinlock, flags); + spin_lock_irqsave(&priv->lec_arp_lock, flags); if (!to_remove) { - spin_unlock_irqrestore(&lec_arp_spinlock, flags); + spin_unlock_irqrestore(&priv->lec_arp_lock, flags); return -1; } place = HASH(to_remove->mac_addr[ETH_ALEN-1]); - tmp = lec_arp_tables[place]; + tmp = priv->lec_arp_tables[place]; if (tmp == to_remove) { - lec_arp_tables[place] = tmp->next; + priv->lec_arp_tables[place] = tmp->next; } else { while(tmp && tmp->next != to_remove) { tmp = tmp->next; } if (!tmp) {/* Entry was not found */ - spin_unlock_irqrestore(&lec_arp_spinlock, flags); + spin_unlock_irqrestore(&priv->lec_arp_lock, flags); return -1; } } @@ -1180,7 +1180,7 @@ * ESI_FLUSH_PENDING, ESI_FORWARD_DIRECT */ for(place=0;placenext){ + for(tmp = priv->lec_arp_tables[place]; tmp != NULL; tmp = tmp->next) { if (memcmp(tmp->atm_addr, to_remove->atm_addr, ATM_ESA_LEN)==0) { remove_vcc=0; @@ -1193,7 +1193,7 @@ } skb_queue_purge(&to_remove->tx_wait); /* FIXME: good place for this? */ - spin_unlock_irqrestore(&lec_arp_spinlock, flags); + spin_unlock_irqrestore(&priv->lec_arp_lock, flags); DPRINTK("LEC_ARP: Removed entry:%2.2x %2.2x %2.2x %2.2x %2.2x %2.2x\n", 0xff&to_remove->mac_addr[0], 0xff&to_remove->mac_addr[1], @@ -1389,7 +1389,7 @@ for (i=0;ilec_arp_tables[i];entry != NULL; entry=next) { next = entry->next; - lec_arp_remove(priv->lec_arp_tables, entry); + lec_arp_remove(priv, entry); kfree(entry); } } @@ -1429,7 +1429,7 @@ /* * Find entry by mac_address */ -static __inline__ struct lec_arp_table* +static inline struct lec_arp_table* lec_arp_find(struct lec_priv *priv, unsigned char *mac_addr) { @@ -1567,8 +1567,6 @@ lec_arp_check_expire(unsigned long data) { struct lec_priv *priv = (struct lec_priv *)data; - struct lec_arp_table **lec_arp_tables = - (struct lec_arp_table **)priv->lec_arp_tables; struct lec_arp_table *entry, *next; unsigned long now; unsigned long time_to_check; @@ -1584,7 +1582,7 @@ lec_arp_get(priv); now = jiffies; for(i=0;ilec_arp_tables[i]; entry != NULL; ) { if ((entry->flags) & LEC_REMOTE_FLAG && priv->topology_change) time_to_check=priv->forward_delay_time; @@ -1600,7 +1598,7 @@ /* Remove entry */ DPRINTK("LEC:Entry timed out\n"); next = entry->next; - lec_arp_remove(lec_arp_tables, entry); + lec_arp_remove(priv, entry); kfree(entry); entry = next; } else { @@ -1689,7 +1687,7 @@ if (!entry) { return priv->mcast_vcc; } - lec_arp_add(priv->lec_arp_tables, entry); + lec_arp_add(priv, entry); /* We want arp-request(s) to be sent */ entry->packets_flooded =1; entry->status = ESI_ARP_PENDING; @@ -1722,7 +1720,7 @@ if (!memcmp(atm_addr, entry->atm_addr, ATM_ESA_LEN) && (permanent || !(entry->flags & LEC_PERMANENT_FLAG))) { - lec_arp_remove(priv->lec_arp_tables, entry); + lec_arp_remove(priv, entry); kfree(entry); } lec_arp_put(priv); @@ -1788,7 +1786,7 @@ entry->status = ESI_FORWARD_DIRECT; memcpy(entry->mac_addr, mac_addr, ETH_ALEN); entry->last_used = jiffies; - lec_arp_add(priv->lec_arp_tables, entry); + lec_arp_add(priv, entry); } if (remoteflag) entry->flags|=LEC_REMOTE_FLAG; @@ -1808,7 +1806,7 @@ return; } entry->status = ESI_UNKNOWN; - lec_arp_add(priv->lec_arp_tables, entry); + lec_arp_add(priv, entry); /* Temporary, changes before end of function */ } memcpy(entry->atm_addr, atm_addr, ATM_ESA_LEN); @@ -2055,7 +2053,7 @@ to_add->old_push = vcc->push; vcc->push = lec_push; priv->mcast_vcc = vcc; - lec_arp_add(priv->lec_arp_tables, to_add); + lec_arp_add(priv, to_add); lec_arp_put(priv); return 0; } @@ -2073,7 +2071,7 @@ for(entry = priv->lec_arp_tables[i];entry; entry=next) { next = entry->next; if (vcc == entry->vcc) { - lec_arp_remove(priv->lec_arp_tables,entry); + lec_arp_remove(priv, entry); kfree(entry); if (priv->mcast_vcc == vcc) { priv->mcast_vcc = NULL; @@ -2153,23 +2151,23 @@ lec_arp_get(priv); entry = priv->lec_arp_empty_ones; if (vcc == entry->vcc) { - spin_lock_irqsave(&lec_arp_spinlock, flags); + spin_lock_irqsave(&priv->lec_arp_lock, flags); del_timer(&entry->timer); memcpy(entry->mac_addr, src, ETH_ALEN); entry->status = ESI_FORWARD_DIRECT; entry->last_used = jiffies; priv->lec_arp_empty_ones = entry->next; - spin_unlock_irqrestore(&lec_arp_spinlock, flags); + spin_unlock_irqrestore(&priv->lec_arp_lock, flags); /* We might have got an entry */ if ((prev=lec_arp_find(priv,src))) { - lec_arp_remove(priv->lec_arp_tables, prev); + lec_arp_remove(priv, prev); kfree(prev); } - lec_arp_add(priv->lec_arp_tables, entry); + lec_arp_add(priv, entry); lec_arp_put(priv); return; } - spin_lock_irqsave(&lec_arp_spinlock, flags); + spin_lock_irqsave(&priv->lec_arp_lock, flags); prev = entry; entry = entry->next; while (entry && entry->vcc != vcc) { @@ -2179,7 +2177,7 @@ if (!entry) { DPRINTK("LEC_ARP: Arp_check_empties: entry not found!\n"); lec_arp_put(priv); - spin_unlock_irqrestore(&lec_arp_spinlock, flags); + spin_unlock_irqrestore(&priv->lec_arp_lock, flags); return; } del_timer(&entry->timer); @@ -2187,12 +2185,12 @@ entry->status = ESI_FORWARD_DIRECT; entry->last_used = jiffies; prev->next = entry->next; - spin_unlock_irqrestore(&lec_arp_spinlock, flags); + spin_unlock_irqrestore(&priv->lec_arp_lock, flags); if ((prev = lec_arp_find(priv, src))) { - lec_arp_remove(priv->lec_arp_tables,prev); + lec_arp_remove(priv, prev); kfree(prev); } - lec_arp_add(priv->lec_arp_tables,entry); + lec_arp_add(priv, entry); lec_arp_put(priv); } MODULE_LICENSE("GPL"); diff -Nru a/net/atm/lec.h b/net/atm/lec.h --- a/net/atm/lec.h Mon Jun 30 13:21:44 2003 +++ b/net/atm/lec.h Mon Jun 30 13:21:44 2003 @@ -64,7 +64,8 @@ int (*lecd_attach)(struct atm_vcc *vcc, int arg); int (*mcast_attach)(struct atm_vcc *vcc, int arg); int (*vcc_attach)(struct atm_vcc *vcc, void *arg); - struct net_device **(*get_lecs)(void); + struct net_device * (*get_lec)(int itf); + struct module *owner; }; /* @@ -101,7 +102,8 @@ establishes multiple Multicast Forward VCCs to us. This list collects all those VCCs. LANEv1 client has only one item in this list. These entries are not aged out. */ atomic_t lec_arp_users; + spinlock_t lec_arp_lock; struct atm_vcc *mcast_vcc; /* Default Multicast Send VCC */ struct atm_vcc *lecd; struct timer_list lec_arp_timer; @@ -148,14 +150,16 @@ int lecd_attach(struct atm_vcc *vcc, int arg); int lec_vcc_attach(struct atm_vcc *vcc, void *arg); int lec_mcast_attach(struct atm_vcc *vcc, int arg); -struct net_device **get_dev_lec(void); +struct net_device *get_dev_lec(int itf); int make_lec(struct atm_vcc *vcc); int send_to_lecd(struct lec_priv *priv, atmlec_msg_type type, unsigned char *mac_addr, unsigned char *atm_addr, struct sk_buff *data); void lec_push(struct atm_vcc *vcc, struct sk_buff *skb); -void atm_lane_init(void); -void atm_lane_init_ops(struct atm_lane_ops *ops); +extern struct atm_lane_ops *atm_lane_ops; +void atm_lane_ops_set(struct atm_lane_ops *hook); +int try_atm_lane_ops(void); + #endif /* _LEC_H_ */ diff -Nru a/net/atm/mpc.c b/net/atm/mpc.c --- a/net/atm/mpc.c Mon Jun 30 13:21:44 2003 +++ b/net/atm/mpc.c Mon Jun 30 13:21:44 2003 @@ -251,12 +251,13 @@ static struct net_device *find_lec_by_itfnum(int itf) { - extern struct atm_lane_ops atm_lane_ops; /* in common.c */ - - if (atm_lane_ops.get_lecs == NULL) + struct net_device *dev; + if (!try_atm_lane_ops()) return NULL; - return atm_lane_ops.get_lecs()[itf]; /* FIXME: something better */ + dev = atm_lane_ops->get_lec(itf); + __MOD_DEC_USE_COUNT(atm_lane_ops->owner); + return dev; } static struct mpoa_client *alloc_mpc(void) @@ -777,9 +778,10 @@ if (mpc->dev) { /* check if the lec is LANE2 capable */ priv = (struct lec_priv *)mpc->dev->priv; - if (priv->lane_version < 2) + if (priv->lane_version < 2) { + dev_put(mpc->dev); mpc->dev = NULL; - else + } else priv->lane2_ops->associate_indicator = lane2_assoc_ind; } @@ -837,6 +839,7 @@ struct lec_priv *priv = (struct lec_priv *)mpc->dev->priv; priv->lane2_ops->associate_indicator = NULL; stop_mpc(mpc); + dev_put(mpc->dev); } mpc->in_ops->destroy_cache(mpc); @@ -973,6 +976,7 @@ } mpc->dev_num = priv->itfnum; mpc->dev = dev; + dev_hold(dev); dprintk("mpoa: (%s) was initialized\n", dev->name); break; case NETDEV_UNREGISTER: @@ -982,6 +986,7 @@ break; dprintk("mpoa: device (%s) was deallocated\n", dev->name); stop_mpc(mpc); + dev_put(mpc->dev); mpc->dev = NULL; break; case NETDEV_UP: @@ -1391,13 +1396,18 @@ return; } -void atm_mpoa_init_ops(struct atm_mpoa_ops *ops) +static struct atm_mpoa_ops __atm_mpoa_ops = { + .mpoad_attach = atm_mpoa_mpoad_attach, + .vcc_attach = atm_mpoa_vcc_attach, + .owner = THIS_MODULE +}; + +static __init int atm_mpoa_init(void) { - ops->mpoad_attach = atm_mpoa_mpoad_attach; - ops->vcc_attach = atm_mpoa_vcc_attach; + atm_mpoa_ops_set(&__atm_mpoa_ops); #ifdef CONFIG_PROC_FS - if(mpc_proc_init() != 0) + if (mpc_proc_init() != 0) printk(KERN_INFO "mpoa: failed to initialize /proc/mpoa\n"); else printk(KERN_INFO "mpoa: /proc/mpoa initialized\n"); @@ -1405,22 +1415,11 @@ printk("mpc.c: " __DATE__ " " __TIME__ " initialized\n"); - return; -} - -#ifdef MODULE -int init_module(void) -{ - extern struct atm_mpoa_ops atm_mpoa_ops; - - atm_mpoa_init_ops(&atm_mpoa_ops); - return 0; } -void cleanup_module(void) +void __exit atm_mpoa_cleanup(void) { - extern struct atm_mpoa_ops atm_mpoa_ops; struct mpoa_client *mpc, *tmp; struct atm_mpoa_qos *qos, *nextqos; struct lec_priv *priv; @@ -1435,8 +1434,7 @@ del_timer(&mpc_timer); unregister_netdevice_notifier(&mpoa_notifier); - atm_mpoa_ops.mpoad_attach = NULL; - atm_mpoa_ops.vcc_attach = NULL; + atm_mpoa_ops_set(NULL); mpc = mpcs; mpcs = NULL; @@ -1471,5 +1469,8 @@ return; } -#endif /* MODULE */ + +module_init(atm_mpoa_init); +module_exit(atm_mpoa_cleanup); + MODULE_LICENSE("GPL"); diff -Nru a/net/atm/mpc.h b/net/atm/mpc.h --- a/net/atm/mpc.h Mon Jun 30 13:21:44 2003 +++ b/net/atm/mpc.h Mon Jun 30 13:21:44 2003 @@ -48,11 +48,13 @@ struct atm_mpoa_ops { int (*mpoad_attach)(struct atm_vcc *vcc, int arg); /* attach mpoa daemon */ int (*vcc_attach)(struct atm_vcc *vcc, long arg); /* attach shortcut vcc */ + struct module *owner; }; /* Boot/module initialization function */ -void atm_mpoa_init(void); -void atm_mpoa_init_ops(struct atm_mpoa_ops *ops); +extern struct atm_mpoa_ops *atm_mpoa_ops; +int try_atm_mpoa_ops(void); +void atm_mpoa_ops_set(struct atm_mpoa_ops *hook); /* MPOA QoS operations */ struct atm_mpoa_qos *atm_mpoa_add_qos(uint32_t dst_ip, struct atm_qos *qos); diff -Nru a/net/atm/proc.c b/net/atm/proc.c --- a/net/atm/proc.c Mon Jun 30 13:21:44 2003 +++ b/net/atm/proc.c Mon Jun 30 13:21:44 2003 @@ -47,7 +47,6 @@ #if defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE) #include "lec.h" #include "lec_arpc.h" -extern struct atm_lane_ops atm_lane_ops; /* in common.c */ #endif static ssize_t proc_dev_atm_read(struct file *file,char *buf,size_t count, @@ -479,57 +478,72 @@ #if defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE) static int atm_lec_info(loff_t pos,char *buf) { + unsigned long flags; struct lec_priv *priv; struct lec_arp_table *entry; int i, count, d, e; - struct net_device **dev_lec; + struct net_device *dev; if (!pos) { return sprintf(buf,"Itf MAC ATM destination" " Status Flags " "VPI/VCI Recv VPI/VCI\n"); } - if (atm_lane_ops.get_lecs == NULL) + if (!try_atm_lane_ops()) return 0; /* the lane module is not there yet */ - else - dev_lec = atm_lane_ops.get_lecs(); count = pos; - for(d=0;dpriv)) continue; - for(i=0;ilec_arp_tables[i]; - for(;entry;entry=entry->next) { - if (--count) continue; - e=sprintf(buf,"%s ", - dev_lec[d]->name); - lec_info(entry,buf+e); + for(d = 0; d < MAX_LEC_ITF; d++) { + dev = atm_lane_ops->get_lec(d); + if (!dev || !(priv = (struct lec_priv *) dev->priv)) + continue; + spin_lock_irqsave(&priv->lec_arp_lock, flags); + for(i = 0; i < LEC_ARP_TABLE_SIZE; i++) { + for(entry = priv->lec_arp_tables[i]; entry; entry = entry->next) { + if (--count) + continue; + e = sprintf(buf,"%s ", dev->name); + lec_info(entry, buf+e); + spin_unlock_irqrestore(&priv->lec_arp_lock, flags); + dev_put(dev); + __MOD_DEC_USE_COUNT(atm_lane_ops->owner); return strlen(buf); } } - for(entry=priv->lec_arp_empty_ones; entry; - entry=entry->next) { - if (--count) continue; - e=sprintf(buf,"%s ",dev_lec[d]->name); + for(entry = priv->lec_arp_empty_ones; entry; entry = entry->next) { + if (--count) + continue; + e = sprintf(buf,"%s ", dev->name); lec_info(entry, buf+e); + spin_unlock_irqrestore(&priv->lec_arp_lock, flags); + dev_put(dev); + __MOD_DEC_USE_COUNT(atm_lane_ops->owner); return strlen(buf); } - for(entry=priv->lec_no_forward; entry; - entry=entry->next) { - if (--count) continue; - e=sprintf(buf,"%s ",dev_lec[d]->name); + for(entry = priv->lec_no_forward; entry; entry=entry->next) { + if (--count) + continue; + e = sprintf(buf,"%s ", dev->name); lec_info(entry, buf+e); + spin_unlock_irqrestore(&priv->lec_arp_lock, flags); + dev_put(dev); + __MOD_DEC_USE_COUNT(atm_lane_ops->owner); return strlen(buf); } - for(entry=priv->mcast_fwds; entry; - entry=entry->next) { - if (--count) continue; - e=sprintf(buf,"%s ",dev_lec[d]->name); + for(entry = priv->mcast_fwds; entry; entry = entry->next) { + if (--count) + continue; + e = sprintf(buf,"%s ", dev->name); lec_info(entry, buf+e); + spin_unlock_irqrestore(&priv->lec_arp_lock, flags); + dev_put(dev); + __MOD_DEC_USE_COUNT(atm_lane_ops->owner); return strlen(buf); } + spin_unlock_irqrestore(&priv->lec_arp_lock, flags); + dev_put(dev); } + __MOD_DEC_USE_COUNT(atm_lane_ops->owner); return 0; } #endif [atm]: split atm_ioctl into vcc_ioctl and atm_dev_ioctl # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1016 -> 1.1017 # net/atm/pvc.c 1.4 -> 1.5 # net/atm/resources.c 1.6 -> 1.7 # net/atm/svc.c 1.4 -> 1.5 # net/atm/common.h 1.2 -> 1.3 # net/atm/resources.h 1.3 -> 1.4 # net/atm/common.c 1.18 -> 1.19 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 03/06/27 davem@nuts.ninka.net 1.1011.1.19 # [NET]: net/bluetooth/cmtp/core.c needs linux/init.h # -------------------------------------------- # 03/06/27 davem@nuts.ninka.net 1.1011.1.20 # [NET]: Scale DST/ipv6 intervals like we did for ipv4. # -------------------------------------------- # 03/06/28 chas@relax.cmf.nrl.navy.mil 1.1017 # svc.c, resources.h, resources.c, pvc.c, common.h, common.c: # split atm_ioctl into vcc_ioctl and atm_dev_ioctl # -------------------------------------------- # diff -Nru a/net/atm/common.c b/net/atm/common.c --- a/net/atm/common.c Mon Jun 30 13:21:27 2003 +++ b/net/atm/common.c Mon Jun 30 13:21:27 2003 @@ -564,129 +564,51 @@ } -static void copy_aal_stats(struct k_atm_aal_stats *from, - struct atm_aal_stats *to) +int vcc_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg) { -#define __HANDLE_ITEM(i) to->i = atomic_read(&from->i) - __AAL_STAT_ITEMS -#undef __HANDLE_ITEM -} - - -static void subtract_aal_stats(struct k_atm_aal_stats *from, - struct atm_aal_stats *to) -{ -#define __HANDLE_ITEM(i) atomic_sub(to->i,&from->i) - __AAL_STAT_ITEMS -#undef __HANDLE_ITEM -} - - -static int fetch_stats(struct atm_dev *dev,struct atm_dev_stats *arg,int zero) -{ - struct atm_dev_stats tmp; - int error = 0; - - copy_aal_stats(&dev->stats.aal0,&tmp.aal0); - copy_aal_stats(&dev->stats.aal34,&tmp.aal34); - copy_aal_stats(&dev->stats.aal5,&tmp.aal5); - if (arg) error = copy_to_user(arg,&tmp,sizeof(tmp)); - if (zero && !error) { - subtract_aal_stats(&dev->stats.aal0,&tmp.aal0); - subtract_aal_stats(&dev->stats.aal34,&tmp.aal34); - subtract_aal_stats(&dev->stats.aal5,&tmp.aal5); - } - return error ? -EFAULT : 0; -} - - -int atm_ioctl(struct socket *sock,unsigned int cmd,unsigned long arg) -{ - struct atm_dev *dev; - struct list_head *p; struct atm_vcc *vcc; - int *tmp_buf, *tmp_p; - void *buf; - int error,len,size,number, ret_val; + int error; - ret_val = 0; vcc = ATM_SD(sock); switch (cmd) { case SIOCOUTQ: if (sock->state != SS_CONNECTED || - !test_bit(ATM_VF_READY,&vcc->flags)) { - ret_val = -EINVAL; + !test_bit(ATM_VF_READY, &vcc->flags)) { + error = -EINVAL; goto done; } - ret_val = put_user(vcc->sk->sndbuf- - atomic_read(&vcc->sk->wmem_alloc), - (int *) arg) ? -EFAULT : 0; + error = put_user(vcc->sk->sndbuf- + atomic_read(&vcc->sk->wmem_alloc), + (int *) arg) ? -EFAULT : 0; goto done; case SIOCINQ: { struct sk_buff *skb; if (sock->state != SS_CONNECTED) { - ret_val = -EINVAL; + error = -EINVAL; goto done; } skb = skb_peek(&vcc->sk->receive_queue); - ret_val = put_user(skb ? skb->len : 0,(int *) arg) - ? -EFAULT : 0; - goto done; - } - case ATM_GETNAMES: - if (get_user(buf, - &((struct atm_iobuf *) arg)->buffer)) { - ret_val = -EFAULT; - goto done; - } - if (get_user(len, - &((struct atm_iobuf *) arg)->length)) { - ret_val = -EFAULT; + error = put_user(skb ? skb->len : 0, + (int *) arg) ? -EFAULT : 0; goto done; } - size = 0; - spin_lock(&atm_dev_lock); - list_for_each(p, &atm_devs) - size += sizeof(int); - if (size > len) { - spin_unlock(&atm_dev_lock); - ret_val = -E2BIG; - goto done; - } - tmp_buf = kmalloc(size, GFP_ATOMIC); - if (!tmp_buf) { - spin_unlock(&atm_dev_lock); - ret_val = -ENOMEM; - goto done; - } - tmp_p = tmp_buf; - list_for_each(p, &atm_devs) { - dev = list_entry(p, struct atm_dev, dev_list); - *tmp_p++ = dev->number; - } - spin_unlock(&atm_dev_lock); - ret_val = ((copy_to_user(buf, tmp_buf, size)) || - put_user(size, &((struct atm_iobuf *) arg)->length) - ) ? -EFAULT : 0; - kfree(tmp_buf); - goto done; case SIOCGSTAMP: /* borrowed from IP */ if (!vcc->sk->stamp.tv_sec) { - ret_val = -ENOENT; + error = -ENOENT; goto done; } - ret_val = copy_to_user((void *) arg, &vcc->sk->stamp, - sizeof(struct timeval)) ? -EFAULT : 0; + error = copy_to_user((void *) arg, &vcc->sk->stamp, + sizeof(struct timeval)) ? -EFAULT : 0; goto done; case ATM_SETSC: printk(KERN_WARNING "ATM_SETSC is obsolete\n"); - ret_val = 0; + error = 0; goto done; case ATMSIGD_CTRL: if (!capable(CAP_NET_ADMIN)) { - ret_val = -EPERM; + error = -EPERM; goto done; } /* @@ -697,28 +619,28 @@ * have the same privledges that /proc/kcore needs */ if (!capable(CAP_SYS_RAWIO)) { - ret_val = -EPERM; + error = -EPERM; goto done; } error = sigd_attach(vcc); - if (!error) sock->state = SS_CONNECTED; - ret_val = error; + if (!error) + sock->state = SS_CONNECTED; goto done; #if defined(CONFIG_ATM_CLIP) || defined(CONFIG_ATM_CLIP_MODULE) case SIOCMKCLIP: if (!capable(CAP_NET_ADMIN)) { - ret_val = -EPERM; + error = -EPERM; goto done; } if (try_atm_clip_ops()) { - ret_val = atm_clip_ops->clip_create(arg); + error = atm_clip_ops->clip_create(arg); __MOD_DEC_USE_COUNT(atm_clip_ops->owner); } else - ret_val = -ENOSYS; + error = -ENOSYS; goto done; case ATMARPD_CTRL: if (!capable(CAP_NET_ADMIN)) { - ret_val = -EPERM; + error = -EPERM; goto done; } #if defined(CONFIG_ATM_CLIP_MODULE) @@ -730,48 +652,47 @@ __MOD_DEC_USE_COUNT(atm_clip_ops->owner); if (!error) sock->state = SS_CONNECTED; - ret_val = error; } else - ret_val = -ENOSYS; + error = -ENOSYS; goto done; case ATMARP_MKIP: if (!capable(CAP_NET_ADMIN)) { - ret_val = -EPERM; + error = -EPERM; goto done; } if (try_atm_clip_ops()) { - ret_val = atm_clip_ops->clip_mkip(vcc, arg); + error = atm_clip_ops->clip_mkip(vcc, arg); __MOD_DEC_USE_COUNT(atm_clip_ops->owner); } else - ret_val = -ENOSYS; + error = -ENOSYS; goto done; case ATMARP_SETENTRY: if (!capable(CAP_NET_ADMIN)) { - ret_val = -EPERM; + error = -EPERM; goto done; } if (try_atm_clip_ops()) { - ret_val = atm_clip_ops->clip_setentry(vcc, arg); + error = atm_clip_ops->clip_setentry(vcc, arg); __MOD_DEC_USE_COUNT(atm_clip_ops->owner); } else - ret_val = -ENOSYS; + error = -ENOSYS; goto done; case ATMARP_ENCAP: if (!capable(CAP_NET_ADMIN)) { - ret_val = -EPERM; + error = -EPERM; goto done; } if (try_atm_clip_ops()) { - ret_val = atm_clip_ops->clip_encap(vcc, arg); + error = atm_clip_ops->clip_encap(vcc, arg); __MOD_DEC_USE_COUNT(atm_clip_ops->owner); } else - ret_val = -ENOSYS; + error = -ENOSYS; goto done; #endif #if defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE) case ATMLEC_CTRL: if (!capable(CAP_NET_ADMIN)) { - ret_val = -EPERM; + error = -EPERM; goto done; } #if defined(CONFIG_ATM_LANE_MODULE) @@ -783,37 +704,36 @@ __MOD_DEC_USE_COUNT(atm_lane_ops->owner); if (error >= 0) sock->state = SS_CONNECTED; - ret_val = error; } else - ret_val = -ENOSYS; + error = -ENOSYS; goto done; case ATMLEC_MCAST: if (!capable(CAP_NET_ADMIN)) { - ret_val = -EPERM; + error = -EPERM; goto done; } if (try_atm_lane_ops()) { - ret_val = atm_lane_ops->mcast_attach(vcc, (int) arg); + error = atm_lane_ops->mcast_attach(vcc, (int) arg); __MOD_DEC_USE_COUNT(atm_lane_ops->owner); } else - ret_val = -ENOSYS; + error = -ENOSYS; goto done; case ATMLEC_DATA: if (!capable(CAP_NET_ADMIN)) { - ret_val = -EPERM; + error = -EPERM; goto done; } if (try_atm_lane_ops()) { - ret_val = atm_lane_ops->vcc_attach(vcc, (void *) arg); + error = atm_lane_ops->vcc_attach(vcc, (void *) arg); __MOD_DEC_USE_COUNT(atm_lane_ops->owner); } else - ret_val = -ENOSYS; + error = -ENOSYS; goto done; #endif #if defined(CONFIG_ATM_MPOA) || defined(CONFIG_ATM_MPOA_MODULE) case ATMMPC_CTRL: if (!capable(CAP_NET_ADMIN)) { - ret_val = -EPERM; + error = -EPERM; goto done; } #if defined(CONFIG_ATM_MPOA_MODULE) @@ -825,63 +745,62 @@ __MOD_DEC_USE_COUNT(atm_mpoa_ops->owner); if (error >= 0) sock->state = SS_CONNECTED; - ret_val = error; } else - ret_val = -ENOSYS; + error = -ENOSYS; goto done; case ATMMPC_DATA: if (!capable(CAP_NET_ADMIN)) { - ret_val = -EPERM; + error = -EPERM; goto done; } if (try_atm_mpoa_ops()) { - ret_val = atm_mpoa_ops->vcc_attach(vcc, arg); + error = atm_mpoa_ops->vcc_attach(vcc, arg); __MOD_DEC_USE_COUNT(atm_mpoa_ops->owner); } else - ret_val = -ENOSYS; + error = -ENOSYS; goto done; #endif #if defined(CONFIG_ATM_TCP) || defined(CONFIG_ATM_TCP_MODULE) case SIOCSIFATMTCP: if (!capable(CAP_NET_ADMIN)) { - ret_val = -EPERM; + error = -EPERM; goto done; } if (!atm_tcp_ops.attach) { - ret_val = -ENOPKG; + error = -ENOPKG; goto done; } - fops_get (&atm_tcp_ops); - error = atm_tcp_ops.attach(vcc,(int) arg); - if (error >= 0) sock->state = SS_CONNECTED; - else fops_put (&atm_tcp_ops); - ret_val = error; + fops_get(&atm_tcp_ops); + error = atm_tcp_ops.attach(vcc, (int) arg); + if (error >= 0) + sock->state = SS_CONNECTED; + else + fops_put (&atm_tcp_ops); goto done; case ATMTCP_CREATE: if (!capable(CAP_NET_ADMIN)) { - ret_val =