From owner-netdev@oss.sgi.com Fri Nov 2 00:26:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA28Qif03491 for netdev-outgoing; Fri, 2 Nov 2001 00:26:44 -0800 Received: from junk.nocrew.org (mail@junk.nocrew.org [212.73.17.42]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA28Qe003488 for ; Fri, 2 Nov 2001 00:26:40 -0800 Received: from lars by junk.nocrew.org with local (Exim 3.31 #1 (Debian)) for netdev@oss.sgi.com id 15zZeu-0002em-00; Fri, 02 Nov 2001 09:26:36 +0100 To: netdev@oss.sgi.com Subject: Re: af_packet bug? References: <200110291843.VAA01641@ms2.inr.ac.ru> <85lmht1sri.fsf@junk.nocrew.org> <20011030164411.A10318@wotan.suse.de> From: Lars Brinkhoff Organization: nocrew Date: 02 Nov 2001 09:26:36 +0100 In-Reply-To: <20011030164411.A10318@wotan.suse.de> Message-ID: <85snbxtw77.fsf@junk.nocrew.org> Lines: 35 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk I wrote: > > The emulated machine communicates with other network hosts by sending > > ethernet packets using af_packet. But since this doesn't work for > > talking to the host machine the emulator is running on, the emulator > > must strip off the ethernet header and send those packets to the > > loopback device. Does that sound like a plausible solution? Andi Kleen writes: > The tun and/or ethertap devices have been exactly designed to make such > things possible. kuznet@ms2.inr.ac.ru writes: > I guess you want ethertap. Michael Richardson writes: > Or, use ethertap0, and use bridging on the host to get onto the real > wire. That will solve all the problems with host communications. Thank you. Since af_packet is almost the right thing, could the TAP device be used just to inject packets into the host TCP/IP stack? The emulator sends packets to the network with af_packet as usual, except when sending packets to the hosting machine. In that case, the packet is written to the TAP device. Linux would see this as a packet coming from the tap0 interface, right? To send packets from Linux to the emulator, the ARP table could be manipulated to indicate that the IP address of the emulator is on the network connected to tap0. The emulator would read those packets off the TAP device. -- Lars Brinkhoff http://lars.nocrew.org/ Linux, GCC, PDP-10 Brinkhoff Consulting http://www.brinkhoff.se/ programming From owner-netdev@oss.sgi.com Mon Nov 5 19:43:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA63hiW02470 for netdev-outgoing; Mon, 5 Nov 2001 19:43:44 -0800 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA63hb002467 for ; Mon, 5 Nov 2001 19:43:38 -0800 Received: from marajade.sandelman.ottawa.on.ca ([2001:410:402:2:204:76ff:fe2d:8c]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id fA63g3902634 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Mon, 5 Nov 2001 22:42:06 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.6/8.11.0) with ESMTP id fA63d6j01897 for ; Mon, 5 Nov 2001 22:39:08 -0500 (EST) Message-Id: <200111060339.fA63d6j01897@marajade.sandelman.ottawa.on.ca> To: netdev@oss.sgi.com Subject: IPv6 src address selection rules and 2.2.19 Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 05 Nov 2001 22:39:05 -0500 From: Michael Richardson Sender: owner-netdev@oss.sgi.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Are there known problems with src address selection with IPv6 on 2.2.19? (I am reluctant to upgrade this box to 2.4 until Debian Woody ships..) Using lukemftp, this is what I see: tcp 0 1 2002:c08b:2e21:2:2:1817 2001:410:401:c::2:21 SYN_SENT cassidy-[~] mcr 1003 %ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:60:97:04:3D:70 inet addr:192.139.46.28 Bcast:192.139.46.31 Mask:255.255.255.240 inet6 addr: 2002:c08b:2e21:2:260:97ff:fe04:3d70/64 Scope:Global inet6 addr: 2001:410:402:2:260:97ff:fe04:3d70/64 Scope:Global inet6 addr: fe80::260:97ff:fe04:3d70/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1744309 errors:0 dropped:0 overruns:0 frame:0 TX packets:2195004 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:466277893 (444.6 Mb) TX bytes:2748556151 (2621.2 Mb) Interrupt:11 Base address:0xdc00 cassidy-[~] mcr 1007 %ip -f inet6 route show 2001:410:402:2::/64 dev eth0 proto kernel metric 256 expires 2591536sec mtu 1280 rtt 375ms 2002:c08b:2e21:2::/64 dev eth0 proto kernel metric 256 expires 2591536sec mtu 1280 rtt 375ms fe80::/10 dev eth0 proto kernel metric 256 mtu 1280 rtt 375ms ff00::/8 dev eth0 proto kernel metric 256 mtu 1280 rtt 375ms default via fe80::280:c8ff:feca:766b dev eth0 proto kernel metric 1024 expires 3136sec mtu 1280 rtt 375ms unreachable default dev lo metric -1 error -101 Both routes were learnt from rtadvd from my gateway box. Since I have a 2001:401: address, I believe that it should pick that source address. For whatever reasons, crc.ca does not have a 6to4 gate. I also can't remove the 2002: address: cassidy:/home/mcr# ip -f inet6 addr del 2002:c08b:2e21:2:260:97ff:fe04:3d70 dev eth0 RTNETLINK answers: Cannot assign requested address (ifconfig gives even less traction) ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBO+dbVoqHRg3pndX9AQFbUQQAzlfB5UpoHSiki+iT0u8tXv4HImGwF58d jxrcPuLUgk0/2u1TjU94EcNiwQ6CxxjR7y5T3J5xd0Iptau7rjuXrKyQ/iMvDaBU +c7f3+X72ahW48ltDCyoqaAFsOo97TMCvHLd26N0jEtDgLrD0x8dcMILf4tT3Wn1 gdxyKJPvvno= =Odis -----END PGP SIGNATURE----- From owner-netdev@oss.sgi.com Mon Nov 5 23:51:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA67p6l07599 for netdev-outgoing; Mon, 5 Nov 2001 23:51:06 -0800 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA67p2007596 for ; Mon, 5 Nov 2001 23:51:02 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fA67oQB24359; Tue, 6 Nov 2001 09:50:28 +0200 Date: Tue, 6 Nov 2001 09:50:26 +0200 (EET) From: Pekka Savola To: Michael Richardson cc: Subject: Re: IPv6 src address selection rules and 2.2.19 In-Reply-To: <200111060339.fA63d6j01897@marajade.sandelman.ottawa.on.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Mon, 5 Nov 2001, Michael Richardson wrote: > Are there known problems with src address selection with IPv6 on 2.2.19? > (I am reluctant to upgrade this box to 2.4 until Debian Woody ships..) The same problems as with 2.4; source address selection is .. very simple, one could say. USAGI have implemented new RFC-candidate src address selection rules from KAME, and those will hopefully be merged to mainstream at some point; I view this as rather important (one reason is because 3ffe/2001 vs 2002 selection does not work, which could optimize traffic enermously in some cases :-) > I also can't remove the 2002: address: > > cassidy:/home/mcr# ip -f inet6 addr del 2002:c08b:2e21:2:260:97ff:fe04:3d70 dev eth0 > RTNETLINK answers: Cannot assign requested address Use: # ip -f inet6 addr del 2002:c08b:2e21:2:260:97ff:fe04:3d70/64 dev eth0 (or just ip -6 addr del [...]) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Tue Nov 6 01:57:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA69vII11231 for netdev-outgoing; Tue, 6 Nov 2001 01:57:18 -0800 Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA69vF011225 for ; Tue, 6 Nov 2001 01:57:15 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id SAA17673; Tue, 6 Nov 2001 18:57:06 +0900 To: pekkas@netcore.fi Cc: mcr@sandelman.ottawa.on.ca, netdev@oss.sgi.com Subject: Re: IPv6 src address selection rules and 2.2.19 In-Reply-To: References: <200111060339.fA63d6j01897@marajade.sandelman.ottawa.on.ca> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (AOI) X-URL: http://www.hongo.wide.ad.jp/%7Eyoshfuji/ 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://cerberus.hongo.wide.ad.jp/%7Eyoshfuji/hideaki@yoshifuji.org.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20011106185706O.yoshfuji@wide.ad.jp> Date: Tue, 06 Nov 2001 18:57:06 +0900 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= X-Dispatcher: imput version 991025(IM133) Lines: 19 Sender: owner-netdev@oss.sgi.com Precedence: bulk In article (at Tue, 6 Nov 2001 09:50:26 +0200 (EET)), Pekka Savola says: > The same problems as with 2.4; source address selection is .. very simple, > one could say. USAGI have implemented new RFC-candidate src address > selection rules from KAME, and those will hopefully be merged to > mainstream at some point; I view this as rather important (one reason is > because 3ffe/2001 vs 2002 selection does not work, which could optimize > traffic enermously in some cases :-) Our implimentation done by ourselves (me...); not from KAME. Anyway, we have a plan to merge our improvements included in our next stable release, inclding the "double bind" feature and source address selection algorithms. Note: we need further enhancements for the source address selection; policy label is needed. --yoshfuji From owner-netdev@oss.sgi.com Tue Nov 6 10:38:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6IcRI01835 for netdev-outgoing; Tue, 6 Nov 2001 10:38:27 -0800 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA6IcL001832 for ; Tue, 6 Nov 2001 10:38:22 -0800 Received: from marajade.sandelman.ottawa.on.ca ([2001:410:402:2:204:76ff:fe2d:8c]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id fA6IcH903834 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Tue, 6 Nov 2001 13:38:19 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.6/8.11.0) with ESMTP id fA6IZED07314; Tue, 6 Nov 2001 13:35:16 -0500 (EST) Message-Id: <200111061835.fA6IZED07314@marajade.sandelman.ottawa.on.ca> To: Pekka Savola cc: netdev@oss.sgi.com Subject: Re: IPv6 src address selection rules and 2.2.19 In-reply-to: Your message of "Tue, 06 Nov 2001 09:50:26 +0200." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 06 Nov 2001 13:35:13 -0500 From: Michael Richardson Sender: owner-netdev@oss.sgi.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Pekka" == Pekka Savola writes: Pekka> On Mon, 5 Nov 2001, Michael Richardson wrote: >> Are there known problems with src address selection with IPv6 on 2.2.19? >> (I am reluctant to upgrade this box to 2.4 until Debian Woody ships..) Pekka> The same problems as with 2.4; source address selection is .. very simple, Pekka> one could say. USAGI have implemented new RFC-candidate src address okay, so that won't encourage an upgrade for me. >> I also can't remove the 2002: address: >> >> cassidy:/home/mcr# ip -f inet6 addr del 2002:c08b:2e21:2:260:97ff:fe04:3d70 dev eth0 >> RTNETLINK answers: Cannot assign requested address Pekka> Use: Pekka> # ip -f inet6 addr del 2002:c08b:2e21:2:260:97ff:fe04:3d70/64 dev eth0 Yup, that works... not I can download kernels from my closest mirror using v6. (ftp.crc.ca is four v4 hops away now that there is an IX in town) ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBO+gtYIqHRg3pndX9AQED0gQA28P0qnp3r5472bWhjHYfoY7+vo0Zf7/m ci14d6MguFF3+JFR0Im0L05uMto43iQ3onG/3eDADPCWz6a4DhC2U/o5AeupkIOG nUGkrIbZ+qhRdrUtKF2QVFCAULFqiCOwYDdrz+GHpYVXsuNjq2+49G8Np7ePU7FE R820ZU68eOA= =higu -----END PGP SIGNATURE----- From owner-netdev@oss.sgi.com Tue Nov 6 23:00:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA770Qc00736 for netdev-outgoing; Tue, 6 Nov 2001 23:00:26 -0800 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA770K000727 for ; Tue, 6 Nov 2001 23:00:21 -0800 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id fA770EI04681; Wed, 7 Nov 2001 00:00:14 -0700 Date: Wed, 7 Nov 2001 00:00:14 -0700 Message-Id: <200111070700.fA770EI04681@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Mark Bainter Cc: netdev@oss.sgi.com Subject: Re: dri/card0 permissions / devfs + devfsd In-Reply-To: <20010924112852.D2634@firinn.org> References: <20010924112852.D2634@firinn.org> Sender: owner-netdev@oss.sgi.com Precedence: bulk Mark Bainter writes: > I am using devfs (fully) and I'm running into a problem trying to > get DRI working. I have tried everything I can think of, and no > matter what when I start X the permissions look like this: > > crw-rw---- 1 root root 226, 0 Sep 24 10:25 card0 > > What's odd is I've had no trouble before this getting devfs > perms working right. The sound card/etc all work fine. And > when I run devfsd in trace mode I see this: > > Looking for "dri/card0" (0) > update permissions for "dri/card0" from 20660 to 20666, user.group from 0.0 to -1.-1 > Set permission 20666 on "dri/card0" > Set user.group -1.-1 on "dri/card0" > > With a devfsd.conf that looks like: > LOOKUP mixer MODLOAD > LOOKUP audio MODLOAD > LOOKUP dsp MODLOAD > REGISTER mixer PERMISSIONS -1.-1 666 > REGISTER dsp PERMISSIONS -1.-1 666 > REGISTER agpgart PERMISSIONS -1.-1 666 > REGISTER dri/.* PERMISSIONS -1.-1 666 > > agpgart works fine. As does mixer and dsp. > And if I restart devfsd after starting X the permissions get > set right on dri/card0 too. But of course, at that time it's > too late. > > In case I was missing an event somewhere, I've gone through and > tried each of the other events I thought relevent (lookup, > create, and change) The first two had no effect, the third > (obv) created a lot of load on my system but didn't help really. > I also tried combinations of them together, which also didn't work. It might be that X is changing the permissions of the device, and that this isn't a devfs problem at all! Something you can do to catch X in the act is to kill your existing devfsd and run it thus: # devfsd /dev -d This will show the devfs->devfsd events, without devfsd doing any other processing. Then start X and see if there is a change event. If so, it shows that X has stuck in it's grubby hands. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-netdev@oss.sgi.com Wed Nov 7 00:26:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA78QLt02489 for netdev-outgoing; Wed, 7 Nov 2001 00:26:21 -0800 Received: from bosvwl01 ([216.52.49.35]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA78QJ002486 for ; Wed, 7 Nov 2001 00:26:19 -0800 Received: from 192.168.200.83 by bosvwl01 (InterScan E-Mail VirusWall NT); Wed, 07 Nov 2001 03:16:40 -0500 Received: from BLRKECIMR01.ad.infosys.com ([192.168.200.58]) by INDHUBBHS03.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 7 Nov 2001 13:55:02 +0530 Received: from kecmsg06.ad.infosys.com ([192.168.200.75]) by BLRKECIMR01.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 7 Nov 2001 13:55:01 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: how do you unsubscribe from this list? Date: Wed, 7 Nov 2001 13:55:01 +0530 Message-ID: <56E2573C375A414191118970BDE06A15033A94BD@kecmsg06.ad.infosys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: dri/card0 permissions / devfs + devfsd Thread-Index: AcFnWnvH66f67LFjThW+28emLQZa4QACwXDr From: "Jithesh K" To: X-OriginalArrivalTime: 07 Nov 2001 08:25:01.0889 (UTC) FILETIME=[B2019310:01C16765] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id fA78QK002487 Sender: owner-netdev@oss.sgi.com Precedence: bulk Can somebody help me with this. thanks, -Jithesh From owner-netdev@oss.sgi.com Wed Nov 7 09:41:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7HfK000387 for netdev-outgoing; Wed, 7 Nov 2001 09:41:20 -0800 Received: from grok.yi.org (IDENT:dzzsq644caDvYooIsJFjYjQ1R9JnCP8t@cx97923-a.phnx3.az.home.com [24.9.112.194] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA7HfH000383 for ; Wed, 7 Nov 2001 09:41:17 -0800 Received: from candelatech.com (IDENT:LpYdSmIaYOni0CUTrcsHzIiGCLXufGJR@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id fA7HfGl18986 for ; Wed, 7 Nov 2001 10:41:16 -0700 Message-ID: <3BE9723C.5050004@candelatech.com> Date: Wed, 07 Nov 2001 10:41:16 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: "netdev@oss.sgi.com" Subject: [OT] Question on RPC & portmap Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Suppose I have a program that uses RPC. It registers it's protocol and starts talking with another machine.... Now, I want to run both (many) processes on the same machine to simulate a bigger system. The problem seems to be that when an RPC program registers, it cannot (easily?) register itself as bound only to a particular IP/interface... I can hack the portmap code if I have to, but I definately can't change the RPC API. Does anyone have any ideas, or any pointers to more appropriate forums in which to ask this question? Thanks, Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From owner-netdev@oss.sgi.com Wed Nov 7 11:43:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7Jhqt10523 for netdev-outgoing; Wed, 7 Nov 2001 11:43:52 -0800 Received: from pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA7Jhl010520 for ; Wed, 7 Nov 2001 11:43:47 -0800 Received: from krypton ([206.170.6.229]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GMG007AZ44GG7@mta7.pltn13.pbi.net> for netdev@oss.sgi.com; Wed, 07 Nov 2001 11:43:29 -0800 (PST) Date: Wed, 07 Nov 2001 11:41:58 -0800 From: David Brownell Subject: Re: [OT] Question on RPC & portmap To: Ben Greear Cc: netdev@oss.sgi.com Message-id: <041401c167c4$441eba80$6800000a@brownell.org> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal References: <3BE9723C.5050004@candelatech.com> Sender: owner-netdev@oss.sgi.com Precedence: bulk You may need to use the "Transport Independent" RPC (ti-rpc) calls rather than the older calls that are more widely available. I remember having that gripe ages ago, but thought that it finally got fixed when SVr4 came out. Of course they depend on streams and similar non-Linux things... Alternatively, you can do low level registration to the RPC infrastructure using svc_register(), then implement your own smarter rpc binding policy that doesn't use portmap. When I've needed to do nontrivial things with ONC RPC, that kind of solution has been all too essential. The portmap model is "one machine, one service", which is annoyingly inappropriate except for certain simple application classes. - Dave ----- Original Message ----- From: "Ben Greear" To: Sent: Wednesday, November 07, 2001 9:41 AM Subject: [OT] Question on RPC & portmap > Suppose I have a program that uses RPC. It registers it's protocol > and starts talking with another machine.... > > Now, I want to run both (many) processes on the same machine to > simulate a bigger system. The problem seems to be that when an > RPC program registers, it cannot (easily?) register itself as bound > only to a particular IP/interface... > > I can hack the portmap code if I have to, but I definately > can't change the RPC API. > > Does anyone have any ideas, or any pointers to more appropriate forums > in which to ask this question? > > Thanks, > Ben > > -- > Ben Greear > President of Candela Technologies Inc http://www.candelatech.com > ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear > > From owner-netdev@oss.sgi.com Wed Nov 7 16:01:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA801I316575 for netdev-outgoing; Wed, 7 Nov 2001 16:01:18 -0800 Received: from gans.physik3.uni-rostock.de (root@gans.physik3.uni-rostock.de [139.30.44.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA800l016550 for ; Wed, 7 Nov 2001 16:00:48 -0800 Received: from localhost (tim@localhost) by gans.physik3.uni-rostock.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA29655; Thu, 8 Nov 2001 01:00:24 +0100 Date: Thu, 8 Nov 2001 01:00:24 +0100 (CET) From: Tim Schmielau To: cc: Jeff Garzik , Andrew Morton , , Linus Torvalds , Andreas Dilger , Networking Team , Andi Kleen , Alexey Kuznetsov Subject: [PATCH] net/ipv4/*, net/core/neighbour.c jiffies cleanup Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi all, jiffies cleanup patch of the day follows. Mostly boring changes of jiffies comparisons to use time_{before,after} in order to handle jiffies wraparound correctly. However, two interesting points: - deciding on whether or not it is a problem on 64 bit platforms to declare the jiffies argument to ic_bootp_send_if as u32. Result: It's probably not a big deal to impose the condition on alphas, that DHCP/BOOTP must succeed within 48 days. On the other hand, it doesn't hurt to change it to unsigned long either, so I did that. - syn_flood_warning. No big deal that it did not warn within the first 60 seconds after boot. However, it also turns of warnings after 248 days on 32 bit platforms. While pretty much any other event may safely be assumed to happen more often than that, less than one synflood attack per year seems totally reasonable (desirable, in fact). I did not do anything about that yet. When I have submitted the patch to supply a get_jiffies64() routine, we should probably reexamine whether or not a call to a locking get_jiffies64() is acceptable in this place. Extra measures taken this time to not again loose a compiler message ;-) Tim --- linux-2.4.14/net/core/neighbour.c Mon Oct 1 18:19:56 2001 +++ linux-2.4.14-jiffies64/net/core/neighbour.c Wed Nov 7 23:37:36 2001 @@ -136,7 +136,7 @@ if (atomic_read(&n->refcnt) == 1 && !(n->nud_state&NUD_PERMANENT) && (n->nud_state != NUD_INCOMPLETE || - jiffies - n->used > n->parms->retrans_time)) { + time_after(jiffies, n->used + n->parms->retrans_time))) { *np = n->next; n->dead = 1; shrunk = 1; @@ -234,7 +234,7 @@ if (tbl->entries > tbl->gc_thresh3 || (tbl->entries > tbl->gc_thresh2 && - now - tbl->last_flush > 5*HZ)) { + time_after(now, tbl->last_flush + 5*HZ))) { if (neigh_forced_gc(tbl) == 0 && tbl->entries > tbl->gc_thresh3) return NULL; @@ -533,12 +533,12 @@ if (state&(NUD_NOARP|NUD_PERMANENT)) return; if (state&NUD_REACHABLE) { - if (now - n->confirmed > n->parms->reachable_time) { + if (time_after(now, n->confirmed + n->parms->reachable_time)) { n->nud_state = NUD_STALE; neigh_suspect(n); } } else if (state&NUD_VALID) { - if (now - n->confirmed < n->parms->reachable_time) { + if (time_before(now, n->confirmed + n->parms->reachable_time)) { neigh_del_timer(n); n->nud_state = NUD_REACHABLE; neigh_connect(n); @@ -559,7 +559,7 @@ * periodicly recompute ReachableTime from random function */ - if (now - tbl->last_rand > 300*HZ) { + if (time_after(now, tbl->last_rand + 300*HZ)) { struct neigh_parms *p; tbl->last_rand = now; for (p=&tbl->parms; p; p = p->next) @@ -585,7 +585,7 @@ n->used = n->confirmed; if (atomic_read(&n->refcnt) == 1 && - (state == NUD_FAILED || now - n->used > n->parms->gc_staletime)) { + (state == NUD_FAILED || time_after(now, n->used + n->parms->gc_staletime))) { *np = n->next; n->dead = 1; write_unlock(&n->lock); @@ -594,7 +594,7 @@ } if (n->nud_state&NUD_REACHABLE && - now - n->confirmed > n->parms->reachable_time) { + time_after(now, n->confirmed + n->parms->reachable_time)) { n->nud_state = NUD_STALE; neigh_suspect(n); } @@ -646,7 +646,7 @@ } if ((state&NUD_VALID) && - now - neigh->confirmed < neigh->parms->reachable_time) { + time_before(now, neigh->confirmed + neigh->parms->reachable_time)) { neigh->nud_state = NUD_REACHABLE; NEIGH_PRINTK2("neigh %p is still alive.\n", neigh); neigh_connect(neigh); --- linux-2.4.14/net/ipv4/arp.c Fri Sep 7 20:01:20 2001 +++ linux-2.4.14-jiffies64/net/ipv4/arp.c Wed Nov 7 22:35:19 2001 @@ -811,7 +811,7 @@ agents are active. Taking the first reply prevents arp trashing and chooses the fastest router. */ - if (jiffies - n->updated >= n->parms->locktime) + if (time_after_eq(jiffies, n->updated + n->parms->locktime)) override = 1; /* Broadcast replies and request packets --- linux-2.4.14/net/ipv4/route.c Wed Oct 31 00:08:12 2001 +++ linux-2.4.14-jiffies64/net/ipv4/route.c Wed Nov 7 22:51:23 2001 @@ -346,7 +346,7 @@ goto out; ret = 1; - if (rth->u.dst.expires && (long)(rth->u.dst.expires - jiffies) <= 0) + if (rth->u.dst.expires && time_after_eq(jiffies, rth->u.dst.expires)) goto out; age = jiffies - rth->u.dst.lastuse; @@ -377,7 +377,7 @@ while ((rth = *rthp) != NULL) { if (rth->u.dst.expires) { /* Entry is expired even if it is in use */ - if ((long)(now - rth->u.dst.expires) <= 0) { + if (time_before_eq(now, rth->u.dst.expires)) { tmo >>= 1; rthp = &rth->u.rt_next; continue; @@ -395,7 +395,7 @@ write_unlock(&rt_hash_table[i].lock); /* Fallback loop breaker. */ - if ((jiffies - now) > 0) + if (time_after(jiffies, now)) break; } rover = i; @@ -499,7 +499,7 @@ * Garbage collection is pretty expensive, * do not make it too frequently. */ - if (now - last_gc < ip_rt_gc_min_interval && + if (time_before(now, last_gc + ip_rt_gc_min_interval) && atomic_read(&ipv4_dst_ops.entries) < ip_rt_max_size) goto out; @@ -522,7 +522,7 @@ equilibrium = atomic_read(&ipv4_dst_ops.entries) - goal; } - if (now - last_gc >= ip_rt_gc_min_interval) + if (time_after_eq(now, last_gc + ip_rt_gc_min_interval)) last_gc = now; if (goal <= 0) { @@ -578,7 +578,7 @@ if (atomic_read(&ipv4_dst_ops.entries) < ip_rt_max_size) goto out; - } while (!in_softirq() && jiffies - now < 1); + } while (!in_softirq() && !time_after(jiffies, now)); if (atomic_read(&ipv4_dst_ops.entries) < ip_rt_max_size) goto out; @@ -949,8 +949,8 @@ /* Check for load limit; set rate_last to the latest sent * redirect. */ - if (jiffies - rt->u.dst.rate_last > - (ip_rt_redirect_load << rt->u.dst.rate_tokens)) { + if (time_after(jiffies, rt->u.dst.rate_last + + (ip_rt_redirect_load << rt->u.dst.rate_tokens))) { icmp_send(skb, ICMP_REDIRECT, ICMP_REDIR_HOST, rt->rt_gateway); rt->u.dst.rate_last = jiffies; ++rt->u.dst.rate_tokens; --- linux-2.4.14/net/ipv4/igmp.c Sat Jul 28 21:12:38 2001 +++ linux-2.4.14-jiffies64/net/ipv4/igmp.c Wed Nov 7 22:55:00 2001 @@ -121,7 +121,7 @@ * contradict to specs provided this delay is small enough. */ -#define IGMP_V1_SEEN(in_dev) ((in_dev)->mr_v1_seen && (long)(jiffies - (in_dev)->mr_v1_seen) < 0) +#define IGMP_V1_SEEN(in_dev) ((in_dev)->mr_v1_seen && time_before(jiffies, (in_dev)->mr_v1_seen)) #endif @@ -165,7 +165,7 @@ spin_lock_bh(&im->lock); im->unsolicit_count = 0; if (del_timer(&im->timer)) { - if ((long)(im->timer.expires-jiffies) < max_delay) { + if (time_before(im->timer.expires, jiffies + max_delay)) { add_timer(&im->timer); im->tm_running=1; spin_unlock_bh(&im->lock); --- linux-2.4.14/net/ipv4/ip_gre.c Wed Oct 31 00:08:12 2001 +++ linux-2.4.14-jiffies64/net/ipv4/ip_gre.c Wed Nov 7 22:56:37 2001 @@ -390,7 +390,7 @@ if (t->parms.iph.ttl == 0 && type == ICMP_TIME_EXCEEDED) goto out; - if (jiffies - t->err_time < IPTUNNEL_ERR_TIMEO) + if (time_before(jiffies, t->err_time + IPTUNNEL_ERR_TIMEO)) t->err_count++; else t->err_count = 1; @@ -796,7 +796,7 @@ #endif if (tunnel->err_count > 0) { - if (jiffies - tunnel->err_time < IPTUNNEL_ERR_TIMEO) { + if (time_before(jiffies, tunnel->err_time + IPTUNNEL_ERR_TIMEO)) { tunnel->err_count--; dst_link_failure(skb); --- linux-2.4.14/net/ipv4/ipmr.c Thu Sep 20 23:12:56 2001 +++ linux-2.4.14-jiffies64/net/ipv4/ipmr.c Wed Nov 7 22:58:00 2001 @@ -1268,7 +1268,7 @@ large chunk of pimd to kernel. Ough... --ANK */ (mroute_do_pim || cache->mfc_un.res.ttls[true_vifi] < 255) && - jiffies - cache->mfc_un.res.last_assert > MFC_ASSERT_THRESH) { + time_after(jiffies, cache->mfc_un.res.last_assert + MFC_ASSERT_THRESH)) { cache->mfc_un.res.last_assert = jiffies; ipmr_cache_report(skb, true_vifi, IGMPMSG_WRONGVIF); } --- linux-2.4.14/net/ipv4/tcp_timer.c Mon Oct 1 18:19:57 2001 +++ linux-2.4.14-jiffies64/net/ipv4/tcp_timer.c Wed Nov 7 23:01:23 2001 @@ -227,7 +227,7 @@ if (sk->state == TCP_CLOSE || !(tp->ack.pending&TCP_ACK_TIMER)) goto out; - if ((long)(tp->ack.timeout - jiffies) > 0) { + if (time_before(jiffies, tp->ack.timeout)) { if (!mod_timer(&tp->delack_timer, tp->ack.timeout)) sock_hold(sk); goto out; @@ -429,7 +429,7 @@ if (sk->state == TCP_CLOSE || !tp->pending) goto out; - if ((long)(tp->timeout - jiffies) > 0) { + if (time_before(jiffies, tp->timeout)) { if (!mod_timer(&tp->retransmit_timer, tp->timeout)) sock_hold(sk); goto out; @@ -509,7 +509,7 @@ do { reqp=&lopt->syn_table[i]; while ((req = *reqp) != NULL) { - if ((long)(now - req->expires) >= 0) { + if (time_after_eq(now, req->expires)) { if ((req->retrans < thresh || (req->acked && req->retrans < max_retries)) && !req->class->rtx_syn_ack(sk, req, NULL)) { --- linux-2.4.14/net/ipv4/tcp_ipv4.c Mon Nov 5 18:46:12 2001 +++ linux-2.4.14-jiffies64/net/ipv4/tcp_ipv4.c Wed Nov 7 23:10:21 2001 @@ -1213,10 +1213,10 @@ static inline void syn_flood_warning(struct sk_buff *skb) { - static unsigned long warntime; + static unsigned long next_warntime; - if (jiffies - warntime > HZ*60) { - warntime = jiffies; + if (time_after(jiffies, next_warntime)) { + next_warntime = jiffies + 60*HZ; printk(KERN_INFO "possible SYN flooding on port %d. Sending cookies.\n", ntohs(skb->h.th->dest)); --- linux-2.4.14/net/ipv4/ipconfig.c Wed Oct 31 00:08:12 2001 +++ linux-2.4.14-jiffies64/net/ipv4/ipconfig.c Wed Nov 7 23:28:47 2001 @@ -630,7 +630,7 @@ /* * Send DHCP/BOOTP request to single interface. */ -static void __init ic_bootp_send_if(struct ic_device *d, u32 jiffies) +static void __init ic_bootp_send_if(struct ic_device *d, unsigned long jiffies) { struct net_device *dev = d->dev; struct sk_buff *skb; @@ -1000,7 +1000,7 @@ #endif jiff = jiffies + (d->next ? CONF_INTER_TIMEOUT : timeout); - while (jiffies < jiff && !ic_got_reply) + while (time_before(jiffies, jiff) && !ic_got_reply) barrier(); #ifdef IPCONFIG_DHCP /* DHCP isn't done until we get a DHCPACK. */ @@ -1113,7 +1113,7 @@ try_try_again: /* Give hardware a chance to settle */ jiff = jiffies + CONF_PRE_OPEN; - while (jiffies < jiff) + while (time_before(jiffies, jiff)) ; /* Setup all network devices */ @@ -1122,7 +1122,7 @@ /* Give drivers a chance to settle */ jiff = jiffies + CONF_POST_OPEN; - while (jiffies < jiff) + while (time_before(jiffies, jiff)) ; /* --- linux-2.4.14/net/ipv4/tcp_minisocks.c Mon Oct 1 18:19:57 2001 +++ linux-2.4.14-jiffies64/net/ipv4/tcp_minisocks.c Thu Nov 8 00:40:37 2001 @@ -562,7 +562,7 @@ tcp_twcal_timer.expires = tcp_twcal_jiffie + (slot< (slot<; Wed, 7 Nov 2001 16:10:46 -0800 Received: from localhost (IDENT:davem@pizda.ninka.net [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id QAA15556; Wed, 7 Nov 2001 16:09:51 -0800 Date: Wed, 07 Nov 2001 16:09:50 -0800 (PST) Message-Id: <20011107.160950.57890584.davem@redhat.com> To: tim@physik3.uni-rostock.de Cc: jgarzik@mandrakesoft.com, andrewm@uow.edu.au, linux-kernel@vger.kernel.org, torvalds@transmeta.com, adilger@turbolabs.com, netdev@oss.sgi.com, ak@muc.de, kuznet@ms2.inr.ac.ru Subject: Re: [PATCH] net/ipv4/*, net/core/neighbour.c jiffies cleanup From: "David S. Miller" In-Reply-To: References: X-Mailer: Mew version 2.0 on Emacs 21.0 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk From: Tim Schmielau Date: Thu, 8 Nov 2001 01:00:24 +0100 (CET) jiffies cleanup patch of the day follows. Mostly boring changes of jiffies comparisons to use time_{before,after} in order to handle jiffies wraparound correctly. These cases handle wraparound correctly!!!! Please stop sending these changes, start thinking about what the code is doing. It is comparing a "DIFFERRENCE" not raw jiffy values with each other. It works just fine. Franks a lot, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Wed Nov 7 16:37:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA80bkq17261 for netdev-outgoing; Wed, 7 Nov 2001 16:37:46 -0800 Received: from lynx.adilger.int (h24-64-71-161.cg.shawcable.net [24.64.71.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA80bf017258 for ; Wed, 7 Nov 2001 16:37:41 -0800 Received: (from adilger@localhost) by lynx.adilger.int (8.11.2/8.11.2) id fA80aRd17674; Wed, 7 Nov 2001 17:36:27 -0700 Date: Wed, 7 Nov 2001 17:36:27 -0700 From: Andreas Dilger To: "David S. Miller" Cc: tim@physik3.uni-rostock.de, jgarzik@mandrakesoft.com, andrewm@uow.edu.au, linux-kernel@vger.kernel.org, torvalds@transmeta.com, netdev@oss.sgi.com, ak@muc.de, kuznet@ms2.inr.ac.ru Subject: Re: [PATCH] net/ipv4/*, net/core/neighbour.c jiffies cleanup Message-ID: <20011107173626.S5922@lynx.no> Mail-Followup-To: "David S. Miller" , tim@physik3.uni-rostock.de, jgarzik@mandrakesoft.com, andrewm@uow.edu.au, linux-kernel@vger.kernel.org, torvalds@transmeta.com, netdev@oss.sgi.com, ak@muc.de, kuznet@ms2.inr.ac.ru References: <20011107.160950.57890584.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20011107.160950.57890584.davem@redhat.com>; from davem@redhat.com on Wed, Nov 07, 2001 at 04:09:50PM -0800 X-GPG-Key: 1024D/0D35BED6 X-GPG-Fingerprint: 7A37 5D79 BF1B CECA D44F 8A29 A488 39F5 0D35 BED6 Sender: owner-netdev@oss.sgi.com Precedence: bulk On Nov 07, 2001 16:09 -0800, David S. Miller wrote: > From: Tim Schmielau > > jiffies cleanup patch of the day follows. Mostly boring changes of jiffies > comparisons to use time_{before,after} in order to handle jiffies > wraparound correctly. > > These cases handle wraparound correctly!!!! > > Please stop sending these changes, start thinking about what the > code is doing. > > It is comparing a "DIFFERRENCE" not raw jiffy values with each other. > It works just fine. No, only a limited number of them cast to a signed value, which means that a large number of them get the comparison wrong in the case of jiffies wrap (where the difference is a large unsigned value, and not a small negative number). This is not just idle change. Tim has problems when jiffies is initialized to a pre-wrap value at boot, and changing everything to use time_{before,after} is the only easy way to audit all of the code (and know that it is done). As I sent to Alan privately (and he agreed), there are three reasons to change this code (even if it is correct) to using time_{before,after}: 1) because it is non-obvious what "correct" is when dealing with jiffies wrap (some of the changes that Alan previously complained about as being already correct were in fact broken, and if _he_ can't get it right, who can?) 2) so that people see it more and are more likely to get it correct, instead of always adding in code that only breaks after 497 days of uptime 3) to isolate code from any changes if jiffies moves to a 64-bit value (where casts to "(long)" may not be appropriate anymore) Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/ From owner-netdev@oss.sgi.com Wed Nov 7 16:44:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA80ieg17381 for netdev-outgoing; Wed, 7 Nov 2001 16:44:40 -0800 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA80ib017378 for ; Wed, 7 Nov 2001 16:44:37 -0800 Received: from localhost (IDENT:davem@pizda.ninka.net [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id QAA15846; Wed, 7 Nov 2001 16:44:26 -0800 Date: Wed, 07 Nov 2001 16:44:26 -0800 (PST) Message-Id: <20011107.164426.35502643.davem@redhat.com> To: adilger@turbolabs.com Cc: tim@physik3.uni-rostock.de, jgarzik@mandrakesoft.com, andrewm@uow.edu.au, linux-kernel@vger.kernel.org, torvalds@transmeta.com, netdev@oss.sgi.com, ak@muc.de, kuznet@ms2.inr.ac.ru Subject: Re: [PATCH] net/ipv4/*, net/core/neighbour.c jiffies cleanup From: "David S. Miller" In-Reply-To: <20011107173626.S5922@lynx.no> References: <20011107.160950.57890584.davem@redhat.com> <20011107173626.S5922@lynx.no> X-Mailer: Mew version 2.0 on Emacs 21.0 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk From: Andreas Dilger Date: Wed, 7 Nov 2001 17:36:27 -0700 No, only a limited number of them cast to a signed value, which means that a large number of them get the comparison wrong in the case of jiffies wrap (where the difference is a large unsigned value, and not a small negative number). Why do they these cases that are actually in the code need to cast to a signed value to get a correct answer? They are not like your example. Almost all of these cases are: (jiffies - SOME_VALUE_KNOWN_TO_BE_IN_THE_PAST) > 5 * HZ So you say if we don't cast to signed, this won't get it right on wrap-around? I disagree, let's say "long" is 32-bits and jiffies wrapped around to "0x2" and SOME_VALUE... is 0xfffffff8. The subtraction above yields 10, and that is what we want. Please show me a bad case where casting to signed is necessary. I actually ran through the tree the other night myself starting to convert these things, then I noticed that I couldn't even convince myself that the code was incorrect. Franks a lot, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Wed Nov 7 16:59:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA80x8N17603 for netdev-outgoing; Wed, 7 Nov 2001 16:59:08 -0800 Received: from gans.physik3.uni-rostock.de (root@gans.physik3.uni-rostock.de [139.30.44.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA80x0017600 for ; Wed, 7 Nov 2001 16:59:00 -0800 Received: from localhost (tim@localhost) by gans.physik3.uni-rostock.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA29910; Thu, 8 Nov 2001 01:58:45 +0100 Date: Thu, 8 Nov 2001 01:58:45 +0100 (CET) From: Tim Schmielau To: "David S. Miller" cc: , , , , , , , Subject: Re: [PATCH] net/ipv4/*, net/core/neighbour.c jiffies cleanup In-Reply-To: <20011107.164426.35502643.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk > Why do they these cases that are actually in the code need to cast to > a signed value to get a correct answer? They are not like your > example. > > Almost all of these cases are: > > (jiffies - SOME_VALUE_KNOWN_TO_BE_IN_THE_PAST) > 5 * HZ > > So you say if we don't cast to signed, this won't get it right on > wrap-around? I disagree, let's say "long" is 32-bits and jiffies > wrapped around to "0x2" and SOME_VALUE... is 0xfffffff8. The > subtraction above yields 10, and that is what we want. > > Please show me a bad case where casting to signed is necessary. > > I actually ran through the tree the other night myself starting to > convert these things, then I noticed that I couldn't even convince > myself that the code was incorrect. > Please consider to change the appended ones. Tim --- linux-2.4.14/net/ipv4/route.c Wed Oct 31 00:08:12 2001 +++ linux-2.4.14-jiffies64/net/ipv4/route.c Wed Nov 7 22:51:23 2001 @@ -395,7 +395,7 @@ write_unlock(&rt_hash_table[i].lock); /* Fallback loop breaker. */ - if ((jiffies - now) > 0) + if ((long)(jiffies - now) > 0) break; } rover = i; --- linux-2.4.14/net/ipv4/ipconfig.c Wed Oct 31 00:08:12 2001 +++ linux-2.4.14-jiffies64/net/ipv4/ipconfig.c Wed Nov 7 23:28:47 2001 @@ -1000,7 +1000,7 @@ #endif jiff = jiffies + (d->next ? CONF_INTER_TIMEOUT : timeout); - while (jiffies < jiff && !ic_got_reply) + while ((long)(jiffies - jiff) < 0 && !ic_got_reply) barrier(); #ifdef IPCONFIG_DHCP /* DHCP isn't done until we get a DHCPACK. */ @@ -1113,7 +1113,7 @@ try_try_again: /* Give hardware a chance to settle */ jiff = jiffies + CONF_PRE_OPEN; - while (jiffies < jiff) + while ((long)(jiffies - jiff) < 0) ; /* Setup all network devices */ @@ -1122,7 +1122,7 @@ /* Give drivers a chance to settle */ jiff = jiffies + CONF_POST_OPEN; - while (jiffies < jiff) + while ((long)(jiffies - jiff) < 0) ; /* From owner-netdev@oss.sgi.com Wed Nov 7 17:09:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA819wG17855 for netdev-outgoing; Wed, 7 Nov 2001 17:09:58 -0800 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA819p017852 for ; Wed, 7 Nov 2001 17:09:52 -0800 Received: from localhost (IDENT:davem@pizda.ninka.net [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id RAA16112; Wed, 7 Nov 2001 17:09:41 -0800 Date: Wed, 07 Nov 2001 17:09:40 -0800 (PST) Message-Id: <20011107.170940.10246156.davem@redhat.com> To: tim@physik3.uni-rostock.de Cc: adilger@turbolabs.com, jgarzik@mandrakesoft.com, andrewm@uow.edu.au, linux-kernel@vger.kernel.org, torvalds@transmeta.com, netdev@oss.sgi.com, ak@muc.de, kuznet@ms2.inr.ac.ru Subject: Re: [PATCH] net/ipv4/*, net/core/neighbour.c jiffies cleanup From: "David S. Miller" In-Reply-To: References: <20011107.164426.35502643.davem@redhat.com> X-Mailer: Mew version 2.0 on Emacs 21.0 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk From: Tim Schmielau Date: Thu, 8 Nov 2001 01:58:45 +0100 (CET) Please consider to change the appended ones. --- linux-2.4.14/net/ipv4/route.c Wed Oct 31 00:08:12 2001 +++ linux-2.4.14-jiffies64/net/ipv4/route.c Wed Nov 7 22:51:23 2001 @@ -395,7 +395,7 @@ write_unlock(&rt_hash_table[i].lock); /* Fallback loop breaker. */ - if ((jiffies - now) > 0) + if ((long)(jiffies - now) > 0) break; } rover = i; Nothing is wrong with this case. Jiffies is guarenteed to be greater than or equal to "now". There is no need to cast it to a signed type. Let me say this again, in another way :-) SOME_WRAPPED_AROUND_SMALL_VALUE MINUS SOME_HUGE_ABOUT_TO_WRAP_AROUND_VALUE will have the same result, signed or not. Check this out! (gdb) p (long)0x2 - (long)0xfffffff8 $1 = 10 (gdb) p (unsigned long)0x2 - (unsigned long)0xfffffff8 $2 = 10 It's math and the computer comfirms it! :-))) Please show me a failure case for this statement if you disagree with me. --- linux-2.4.14/net/ipv4/ipconfig.c Wed Oct 31 00:08:12 2001 +++ linux-2.4.14-jiffies64/net/ipv4/ipconfig.c Wed Nov 7 23:28:47 2001 These cases are indeed buggy. I'd rather fix these ones with time_{after,before}() though. And again, your "signed" casts are totally superfluous. Franks a lot, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Wed Nov 7 17:20:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA81KJD18034 for netdev-outgoing; Wed, 7 Nov 2001 17:20:19 -0800 Received: from gans.physik3.uni-rostock.de (root@gans.physik3.uni-rostock.de [139.30.44.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA81KG018030 for ; Wed, 7 Nov 2001 17:20:16 -0800 Received: from localhost (tim@localhost) by gans.physik3.uni-rostock.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA30016; Thu, 8 Nov 2001 02:20:02 +0100 Date: Thu, 8 Nov 2001 02:20:02 +0100 (CET) From: Tim Schmielau To: "David S. Miller" cc: , , , , , , , Subject: Re: [PATCH] net/ipv4/*, net/core/neighbour.c jiffies cleanup In-Reply-To: <20011107.170940.10246156.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk > > --- linux-2.4.14/net/ipv4/ipconfig.c Wed Oct 31 00:08:12 2001 > +++ linux-2.4.14-jiffies64/net/ipv4/ipconfig.c Wed Nov 7 23:28:47 2001 > > These cases are indeed buggy. I'd rather fix these ones with > time_{after,before}() though. And again, your "signed" casts > are totally superfluous. > They actually are necessary as unsigned values can never become less than zero. Tim From owner-netdev@oss.sgi.com Wed Nov 7 17:27:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA81RtK18222 for netdev-outgoing; Wed, 7 Nov 2001 17:27:55 -0800 Received: from neon-gw.transmeta.com (neon-gw-l3.transmeta.com [63.209.4.196]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA81Rq018213 for ; Wed, 7 Nov 2001 17:27:52 -0800 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id RAA03636; Wed, 7 Nov 2001 17:26:09 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma003630; Wed, 7 Nov 01 17:25:43 -0800 Received: from penguin.transmeta.com (penguin.transmeta.com [10.10.27.78]) by deepthought.transmeta.com (8.9.3/8.9.3) with ESMTP id RAA12171; Wed, 7 Nov 2001 17:25:46 -0800 (PST) Received: from localhost (torvalds@localhost) by penguin.transmeta.com (8.11.2/8.7.3) with ESMTP id fA81MZB23865; Wed, 7 Nov 2001 17:22:35 -0800 X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs Date: Wed, 7 Nov 2001 17:22:35 -0800 (PST) From: Linus Torvalds To: Andreas Dilger cc: "David S. Miller" , , , , , , , Subject: Re: [PATCH] net/ipv4/*, net/core/neighbour.c jiffies cleanup In-Reply-To: <20011107173626.S5922@lynx.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Wed, 7 Nov 2001, Andreas Dilger wrote: > > No, only a limited number of them cast to a signed value, which means > that a large number of them get the comparison wrong in the case of > jiffies wrap (where the difference is a large unsigned value, and not > a small negative number). No. Unsigned arithmetic is fine. The _correct_ way to test whether something is in within [ start , start+HZ ] is to do if (jiffies - start <= HZ) try it. The C language guarantees that unsigned arithmetic works in a "modulo power of two" fashion, which means that it _is_ ok to do arithmetic on unsigned longs, and jiffy wrapping does not matter. No need to cast to "signed" or anything else. In short: It is wrong to do if (jiffies <= start+HZ) and it is _right_ to do if (jiffies - start <= HZ) (as long as "start" is "unsigned long" like jiffies). Linus From owner-netdev@oss.sgi.com Wed Nov 7 17:37:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA81bDH18464 for netdev-outgoing; Wed, 7 Nov 2001 17:37:13 -0800 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA81bB018461 for ; Wed, 7 Nov 2001 17:37:11 -0800 Received: from localhost (IDENT:davem@pizda.ninka.net [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id RAA16358; Wed, 7 Nov 2001 17:36:50 -0800 Date: Wed, 07 Nov 2001 17:36:49 -0800 (PST) Message-Id: <20011107.173649.94552736.davem@redhat.com> To: tim@physik3.uni-rostock.de Cc: adilger@turbolabs.com, jgarzik@mandrakesoft.com, andrewm@uow.edu.au, linux-kernel@vger.kernel.org, torvalds@transmeta.com, netdev@oss.sgi.com, ak@muc.de, kuznet@ms2.inr.ac.ru Subject: Re: [PATCH] net/ipv4/*, net/core/neighbour.c jiffies cleanup From: "David S. Miller" In-Reply-To: References: <20011107.170940.10246156.davem@redhat.com> X-Mailer: Mew version 2.0 on Emacs 21.0 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk From: Tim Schmielau Date: Thu, 8 Nov 2001 02:20:02 +0100 (CET) They actually are necessary as unsigned values can never become less than zero. I definitely stand corrected. Franks a lot, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Wed Nov 7 19:12:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA83CsZ20885 for netdev-outgoing; Wed, 7 Nov 2001 19:12:54 -0800 Received: from e32.bld.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA83Cl020882; Wed, 7 Nov 2001 19:12:47 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e32.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id WAA42688; Wed, 7 Nov 2001 22:10:07 -0500 Received: from d03nm066.boulder.ibm.com (d03nm066.boulder.ibm.com [9.99.140.50]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.00) with ESMTP id fA83BRO23202; Wed, 7 Nov 2001 20:11:27 -0700 Subject: Re: [PATCH] net/ipv4/*, net/core/neighbour.c jiffies cleanup To: Linus Torvalds Cc: Andreas Dilger , ak@muc.de, andrewm@uow.edu.au, "David S. Miller" , jgarzik@mandrakesoft.com, kuznet@ms2.inr.ac.ru, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, owner-netdev@oss.sgi.com, tim@physik3.uni-rostock.de X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Krishna Kumar" Date: Wed, 7 Nov 2001 19:07:47 -0800 X-MIMETrack: Serialize by Router on D03NM066/03/M/IBM(Release 5.0.8 |June 18, 2001) at 11/07/2001 08:11:26 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk > Unsigned arithmetic is fine. The _correct_ way to test whether something > is in within > > [ start , start+HZ ] > > is to do > > if (jiffies - start <= HZ) > > try it. The C language guarantees that unsigned arithmetic works in a > "modulo power of two" fashion, which means that it _is_ ok to do > arithmetic on unsigned longs, and jiffy wrapping does not matter. No need > to cast to "signed" or anything else. > > In short: It is wrong to do > > if (jiffies <= start+HZ) > > and it is _right_ to do > > if (jiffies - start <= HZ) Actually this last part is wrong, isn't it ? jiffies <= start + HZ is also a correct way to do it, since start+HZ will overflow to the current value of jiffies when HZ time elapses. So the above two statements are IDENTICAL. I agree with the rest of the statements, and especially that you don't need to worry about wrapping using unsigned numbers. Regards, - KK > (as long as "start" is "unsigned long" like jiffies). > > Linus From owner-netdev@oss.sgi.com Wed Nov 7 20:33:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA84XX522477 for netdev-outgoing; Wed, 7 Nov 2001 20:33:33 -0800 Received: from lynx.adilger.int (h24-64-71-161.cg.shawcable.net [24.64.71.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA84XR022474 for ; Wed, 7 Nov 2001 20:33:27 -0800 Received: (from adilger@localhost) by lynx.adilger.int (8.11.2/8.11.2) id fA84WId18092; Wed, 7 Nov 2001 21:32:18 -0700 Date: Wed, 7 Nov 2001 21:32:18 -0700 From: Andreas Dilger To: "David S. Miller" Cc: tim@physik3.uni-rostock.de, jgarzik@mandrakesoft.com, andrewm@uow.edu.au, linux-kernel@vger.kernel.org, torvalds@transmeta.com, netdev@oss.sgi.com, ak@muc.de, kuznet@ms2.inr.ac.ru Subject: Re: [PATCH] net/ipv4/*, net/core/neighbour.c jiffies cleanup Message-ID: <20011107213218.U5922@lynx.no> Mail-Followup-To: "David S. Miller" , tim@physik3.uni-rostock.de, jgarzik@mandrakesoft.com, andrewm@uow.edu.au, linux-kernel@vger.kernel.org, torvalds@transmeta.com, netdev@oss.sgi.com, ak@muc.de, kuznet@ms2.inr.ac.ru References: <20011107.160950.57890584.davem@redhat.com> <20011107173626.S5922@lynx.no> <20011107.164426.35502643.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20011107.164426.35502643.davem@redhat.com>; from davem@redhat.com on Wed, Nov 07, 2001 at 04:44:26PM -0800 X-GPG-Key: 1024D/0D35BED6 X-GPG-Fingerprint: 7A37 5D79 BF1B CECA D44F 8A29 A488 39F5 0D35 BED6 Sender: owner-netdev@oss.sgi.com Precedence: bulk On Nov 07, 2001 16:44 -0800, David S. Miller wrote: > Why do they these cases that are actually in the code need to cast to > a signed value to get a correct answer? They are not like your > example. > > Almost all of these cases are: > > (jiffies - SOME_VALUE_KNOWN_TO_BE_IN_THE_PAST) > 5 * HZ > > So you say if we don't cast to signed, this won't get it right on > wrap-around? I disagree, let's say "long" is 32-bits and jiffies > wrapped around to "0x2" and SOME_VALUE... is 0xfffffff8. The > subtraction above yields 10, and that is what we want. OK, in this code it mostly appears that the wraparound is correct, but in some cases it is very hard to say without specific knowledge of the code: neigh->confirmed = jiffies - (n->parms->base_reachable_time<<1); . . . if ((state&NUD_VALID) && now - neigh->confirmed < neigh->parms->reachable_time) { How are we to know that the above calculation won't be wrong because of jiffies wrap? > Please show me a bad case where casting to signed is necessary. I don't know enough about the net code to say for sure, but for example in drivers/sound/sb_common.c: limit = jiffies + HZ / 10; /* Timeout */ for (i = 0; i < 500000 && (limit-jiffies)>0; i++) Since limit and jiffies are both unsigned, the value will always be > 0, unless they are equal. > I actually ran through the tree the other night myself starting to > convert these things, then I noticed that I couldn't even convince > myself that the code was incorrect. I don't disagree that it is possible to make correct code without the macros, but it is easier to guarantee that it IS correct with the macros. Rather than evaluate each jiffies usage on a case-by-case basis, it is much easier to do a code audit and fix all comparisons. I don't see that it harms anything to use the macros instead. Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/ From owner-netdev@oss.sgi.com Wed Nov 7 20:40:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA84eRd22574 for netdev-outgoing; Wed, 7 Nov 2001 20:40:27 -0800 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA84eQ022571 for ; Wed, 7 Nov 2001 20:40:26 -0800 Received: from localhost (IDENT:davem@pizda.ninka.net [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id UAA22088; Wed, 7 Nov 2001 20:39:55 -0800 Date: Wed, 07 Nov 2001 20:39:54 -0800 (PST) Message-Id: <20011107.203954.118627544.davem@redhat.com> To: adilger@turbolabs.com Cc: tim@physik3.uni-rostock.de, jgarzik@mandrakesoft.com, andrewm@uow.edu.au, linux-kernel@vger.kernel.org, torvalds@transmeta.com, netdev@oss.sgi.com, ak@muc.de, kuznet@ms2.inr.ac.ru Subject: Re: [PATCH] net/ipv4/*, net/core/neighbour.c jiffies cleanup From: "David S. Miller" In-Reply-To: <20011107213218.U5922@lynx.no> References: <20011107173626.S5922@lynx.no> <20011107.164426.35502643.davem@redhat.com> <20011107213218.U5922@lynx.no> X-Mailer: Mew version 2.0 on Emacs 21.0 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk From: Andreas Dilger Date: Wed, 7 Nov 2001 21:32:18 -0700 I don't see that it harms anything to use the macros instead. Maybe if this code were literally etched into the back your skull like it is for some of us, you'd understand what a detriment it is to make changes like this when it isn't necessary :-) Franks a lot, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Wed Nov 7 21:29:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA85Tlm23398 for netdev-outgoing; Wed, 7 Nov 2001 21:29:47 -0800 Received: from neon-gw.transmeta.com (neon-gw-l3.transmeta.com [63.209.4.196]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA85Tg023395; Wed, 7 Nov 2001 21:29:42 -0800 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id VAA16820; Wed, 7 Nov 2001 21:29:18 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma016814; Wed, 7 Nov 01 21:29:18 -0800 Received: from penguin.transmeta.com (penguin.transmeta.com [10.10.27.78]) by deepthought.transmeta.com (8.9.3/8.9.3) with ESMTP id VAA00185; Wed, 7 Nov 2001 21:29:23 -0800 (PST) Received: from localhost (torvalds@localhost) by penguin.transmeta.com (8.11.2/8.7.3) with ESMTP id fA85QBW01139; Wed, 7 Nov 2001 21:26:11 -0800 X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs Date: Wed, 7 Nov 2001 21:26:11 -0800 (PST) From: Linus Torvalds To: Krishna Kumar cc: Andreas Dilger , , , "David S. Miller" , , , , , , Subject: Re: [PATCH] net/ipv4/*, net/core/neighbour.c jiffies cleanup In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Wed, 7 Nov 2001, Krishna Kumar wrote: > > > > In short: It is wrong to do > > > > if (jiffies <= start+HZ) > > > > and it is _right_ to do > > > > if (jiffies - start <= HZ) > > Actually this last part is wrong, isn't it ? jiffies <= start + HZ is also > a correct way to do it, since start+HZ will overflow to the current value > of jiffies when HZ time elapses. So the above two statements are IDENTICAL. No. Try it out with a few examples. You'll see. Linus From owner-netdev@oss.sgi.com Thu Nov 8 09:00:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8H07f11221 for netdev-outgoing; Thu, 8 Nov 2001 09:00:07 -0800 Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8Gxt011185; Thu, 8 Nov 2001 08:59:55 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA33256; Thu, 8 Nov 2001 10:57:00 -0600 Received: from d03nm066.boulder.ibm.com (d03nm066.boulder.ibm.com [9.99.140.50]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.00) with ESMTP id fA8Gxa649036; Thu, 8 Nov 2001 09:59:36 -0700 Subject: Re: [PATCH] net/ipv4/*, net/core/neighbour.c jiffies cleanup To: Linus Torvalds Cc: Andreas Dilger , ak@muc.de, andrewm@uow.edu.au, "David S. Miller" , jgarzik@mandrakesoft.com, kuznet@ms2.inr.ac.ru, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, owner-netdev@oss.sgi.com, tim@physik3.uni-rostock.de X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Krishna Kumar" Date: Thu, 8 Nov 2001 08:55:51 -0800 X-MIMETrack: Serialize by Router on D03NM066/03/M/IBM(Release 5.0.8 |June 18, 2001) at 11/08/2001 09:59:35 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi Linus, > > > > In short: It is wrong to do > > > > if (jiffies <= start+HZ) > > > > and it is _right_ to do > > > > if (jiffies - start <= HZ) > > Actually this last part is wrong, isn't it ? jiffies <= start + HZ is also > a correct way to do it, since start+HZ will overflow to the current value > of jiffies when HZ time elapses. So the above two statements are IDENTICAL. > > No. > > Try it out with a few examples. You'll see. > > Linus I am sorry, but I still don't see the difference. I wrote a small program with different cases, but the values still come same irrespective of the input arguments to the checks. Could you tell under what conditions the checks wuold fail ? The 2's complement works the same for addition and subtraction. I have included the test program below. Thanks, - KK --------------------------------------------------------------------------------------------- /* if (jiffies <= start+HZ) if (jiffies - start <= HZ) */ #define HZ 100 main() { unsigned long start, jiffies; /* Case 1 */ start = ((unsigned long) -1); jiffies = start + HZ; if (jiffies <= start + HZ) { printf("Less Case 1\n"); } if (jiffies - start <= HZ) { printf("Less Case 2\n"); } /* Case 2 */ start = ((unsigned long) -10); jiffies = start + HZ + 1; if (jiffies <= start + HZ) { printf("Less Case 3\n"); } if (jiffies - start <= HZ) { printf("Less Case 4\n"); } /* Case 3 */ start = ((unsigned long) -10); jiffies = start + HZ - 1; if (jiffies <= start + HZ) { printf("Less Case 5\n"); } if (jiffies - start <= HZ) { printf("Less Case 6\n"); } } From owner-netdev@oss.sgi.com Thu Nov 8 09:14:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8HEfT11687 for netdev-outgoing; Thu, 8 Nov 2001 09:14:41 -0800 Received: from neon-gw.transmeta.com (neon-gw-l3.transmeta.com [63.209.4.196]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8HET011679; Thu, 8 Nov 2001 09:14:29 -0800 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id JAA21438; Thu, 8 Nov 2001 09:14:08 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma021407; Thu, 8 Nov 01 09:13:55 -0800 Received: from penguin.transmeta.com (penguin.transmeta.com [10.10.27.78]) by deepthought.transmeta.com (8.9.3/8.9.3) with ESMTP id JAA04640; Thu, 8 Nov 2001 09:13:57 -0800 (PST) Received: from localhost (torvalds@localhost) by penguin.transmeta.com (8.11.2/8.7.3) with ESMTP id fA8HAfE01523; Thu, 8 Nov 2001 09:10:41 -0800 X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs Date: Thu, 8 Nov 2001 09:10:41 -0800 (PST) From: Linus Torvalds To: Krishna Kumar cc: Andreas Dilger , , , "David S. Miller" , , , , , , Subject: Re: [PATCH] net/ipv4/*, net/core/neighbour.c jiffies cleanup In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Thu, 8 Nov 2001, Krishna Kumar wrote: > > > > > > In short: It is wrong to do > > > > > > if (jiffies <= start+HZ) > > > > > > and it is _right_ to do > > > > > > if (jiffies - start <= HZ) > > I am sorry, but I still don't see the difference. I wrote a small > program with different cases, but the values still come same > irrespective of the input arguments to the checks. Could you tell > under what conditions the checks wuold fail ? The 2's complement works > the same for addition and subtraction. I have included the test > program below. Ok. Let's give an example. HZ is 100, and we started just before jiffies wrapped, and we want to check that we're within one second. So "start" equals 0xfffffff0, and "jiffies" equals 0xfffffff5. The first if-statement will say if (0xfffffff5 <= 0xfffffff0+100) which is the same as if (0xfffffff5 <= 0x54) which is if (0) in short, the first statement will say that jiffies is _not_ within 100 ticks of "start", which is obviously wrong. Jiffies _is_ within 100 ticks, it is in fact just 5 ticks after "start". The second statement will say if (0xfffffff5 - 0xfffffff0 <= 100) which is if (5 <= 100) which is if (1) which is _correct_. We _are_ within 100 ticks. See? Ok, that was wrap-around one way: the "+HZ" wrapped. Let's see the other case, which is that "jiffies" has wrapped: start is still 0xfffffff0, but jiffies has wrapped around and is 0x00000001. The first if-statement will say if (0x00000001 <= 0xfffffff0+100) which is if (0x00000001 <= 0x54) which is if (1) which is correct. The second one will say if (0x00000001 - 0xfffffff0 <= 100) which is if (11 <= 100) which is if (1) which is correct. In short, the _correct_ one ALWAYS gets the right answer. Even when the subtraction overflows. While the first (and incorrect one) gets the wrong answer when the addition overflows. Do you see the difference now? Linus From owner-netdev@oss.sgi.com Thu Nov 8 09:51:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8Hpdq12509 for netdev-outgoing; Thu, 8 Nov 2001 09:51:39 -0800 Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8HpT012505; Thu, 8 Nov 2001 09:51:29 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA70530; Thu, 8 Nov 2001 12:48:41 -0500 Received: from d03nm066.boulder.ibm.com (d03nm066.boulder.ibm.com [9.99.140.50]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.00) with ESMTP id fA8HpF6277910; Thu, 8 Nov 2001 10:51:16 -0700 Subject: Re: [PATCH] net/ipv4/*, net/core/neighbour.c jiffies cleanup To: Linus Torvalds Cc: Andreas Dilger , ak@muc.de, andrewm@uow.edu.au, "David S. Miller" , jgarzik@mandrakesoft.com, kuznet@ms2.inr.ac.ru, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, owner-netdev@oss.sgi.com, tim@physik3.uni-rostock.de X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Krishna Kumar" Date: Thu, 8 Nov 2001 09:47:17 -0800 X-MIMETrack: Serialize by Router on D03NM066/03/M/IBM(Release 5.0.8 |June 18, 2001) at 11/08/2001 10:51:16 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi Linus, Thanks for your clarification, it does make sense. I did only the jiffies overflowing case, and missed the case where it does not overflow. Thanks, - KK ----------------------------------------------------------------------------- Ok. Let's give an example. HZ is 100, and we started just before jiffies wrapped, and we want to check that we're within one second. So "start" equals 0xfffffff0, and "jiffies" equals 0xfffffff5. The first if-statement will say if (0xfffffff5 <= 0xfffffff0+100) which is the same as if (0xfffffff5 <= 0x54) which is if (0) in short, the first statement will say that jiffies is _not_ within 100 ticks of "start", which is obviously wrong. Jiffies _is_ within 100 ticks, it is in fact just 5 ticks after "start". The second statement will say if (0xfffffff5 - 0xfffffff0 <= 100) which is if (5 <= 100) which is if (1) which is _correct_. We _are_ within 100 ticks. See? Ok, that was wrap-around one way: the "+HZ" wrapped. Let's see the other case, which is that "jiffies" has wrapped: start is still 0xfffffff0, but jiffies has wrapped around and is 0x00000001. The first if-statement will say if (0x00000001 <= 0xfffffff0+100) which is if (0x00000001 <= 0x54) which is if (1) which is correct. The second one will say if (0x00000001 - 0xfffffff0 <= 100) which is if (11 <= 100) which is if (1) which is correct. In short, the _correct_ one ALWAYS gets the right answer. Even when the subtraction overflows. While the first (and incorrect one) gets the wrong answer when the addition overflows. Do you see the difference now? Linus From owner-netdev@oss.sgi.com Thu Nov 8 09:55:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8HtbV12709 for netdev-outgoing; Thu, 8 Nov 2001 09:55:37 -0800 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8HtX012704 for ; Thu, 8 Nov 2001 09:55:34 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id UAA24454; Thu, 8 Nov 2001 20:54:29 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200111081754.UAA24454@ms2.inr.ac.ru> Subject: Re: [PATCH] net/ipv4/*, net/core/neighbour.c jiffies cleanup To: davem@redhat.com (David S. Miller) Date: Thu, 8 Nov 2001 20:54:29 +0300 (MSK) Cc: tim@physik3.uni-rostock.de, jgarzik@mandrakesoft.com, andrewm@uow.edu.au, linux-kernel@vger.kernel.org, torvalds@transmeta.com, adilger@turbolabs.com, netdev@oss.sgi.com, ak@muc.de In-Reply-To: <20011107.160950.57890584.davem@redhat.com> from "David S. Miller" at Nov 7, 1 04:09:50 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello! > jiffies cleanup patch of the day follows. Mostly boring changes of jiffies > comparisons to use time_{before,after} in order to handle jiffies > wraparound correctly. I want to _ask_ one thing people working on these changes. _Please_, defer this edit to 2.5. The changes are very good, but time for them is very bad. When I wrote this code the macros did not exist. However, this code is right, take my word. Hence, it is pure maintanance problem and as soon as main reader of this code is me, I would be glad to see the changes, but only having no deadlines. Anyway, if someone want to try to define jiffies as somewhat different of "unsigned long", all code needs real checking rather than syntax changes. Alexey From owner-netdev@oss.sgi.com Thu Nov 8 10:03:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8I36213126 for netdev-outgoing; Thu, 8 Nov 2001 10:03:06 -0800 Received: from lynx.adilger.int (h24-64-71-161.cg.shawcable.net [24.64.71.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8I2u013123; Thu, 8 Nov 2001 10:02:56 -0800 Received: (from adilger@localhost) by lynx.adilger.int (8.11.2/8.11.2) id fA8I19424138; Thu, 8 Nov 2001 11:01:09 -0700 Date: Thu, 8 Nov 2001 11:01:09 -0700 From: Andreas Dilger To: Krishna Kumar Cc: Linus Torvalds , ak@muc.de, andrewm@uow.edu.au, "David S. Miller" , jgarzik@mandrakesoft.com, kuznet@ms2.inr.ac.ru, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, owner-netdev@oss.sgi.com, tim@physik3.uni-rostock.de Subject: Re: [PATCH] net/ipv4/*, net/core/neighbour.c jiffies cleanup Message-ID: <20011108110108.W5922@lynx.no> Mail-Followup-To: Krishna Kumar , Linus Torvalds , ak@muc.de, andrewm@uow.edu.au, "David S. Miller" , jgarzik@mandrakesoft.com, kuznet@ms2.inr.ac.ru, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, owner-netdev@oss.sgi.com, tim@physik3.uni-rostock.de References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from kumarkr@us.ibm.com on Thu, Nov 08, 2001 at 08:55:51AM -0800 X-GPG-Key: 1024D/0D35BED6 X-GPG-Fingerprint: 7A37 5D79 BF1B CECA D44F 8A29 A488 39F5 0D35 BED6 Sender: owner-netdev@oss.sgi.com Precedence: bulk On Nov 08, 2001 08:55 -0800, Krishna Kumar wrote: > > > In short: It is wrong to do > > > > > > if (jiffies <= start+HZ) > > > > > > and it is _right_ to do > > > > > > if (jiffies - start <= HZ) > > > > Actually this last part is wrong, isn't it ? jiffies <= start + HZ is > > also a correct way to do it, since start+HZ will overflow to the current > > value of jiffies when HZ time elapses. So the above two statements are > > IDENTICAL. > > I am sorry, but I still don't see the difference. I wrote a small program > with different cases, but the values still come same irrespective of the > input arguments to the checks. Could you tell under what conditions the > checks wuold fail ? The 2's complement works the same for addition and > subtraction. I have included the test program below. There are several cases where jiffies comparisons can be incorrect: unsigned long start = jiffies; /* say 0xfffffff8 */ unsigned long delta = 16; unsigned long end = jiffies + delta; /* wraps to 0x00000008 */ a) while (jiffies < end) { do something } If jiffies is near wrap when calculating end, end will wrap and your loop will never be executed, because 0xfffffff9 is greater than 0x00000008. b) while (jiffies - end < 0) { do something } Fails because both jiffies and end are unsigned, and the difference can never be negative. c) while ((long)jiffies - (long)end < 0) { do something } Correct. Hmm, this is just like while(time_before(jiffies, end)) { do something } d) while (jiffies - start < delta) { do something } This will also work because of modulo arithmetic, as long as we know in advance that "start" is always less than "jiffies". e) if (jiffies > end) { fail because of timeout } Incorrect for the same reason as (a) above, 0xfffffff9 > 0x00000008, where we really want to wait until 0x00000009 to timeout. f) if (jiffies - end > 0) { fail because of timeout } Fails for the same reason as (b) - both jiffies and end are unsigned, and the difference can never be negative. g) if ((long)jiffies - (long)end > 0) { fail because of timeout } Correct, which is just like: if (time_after(jiffies, end)) { fail because of timeout } h) if (jiffies - start > delta) { fail because of timeout } Correct because of modulo arithmetic, as long as we know in advance that "start" is less than "jiffies". So it appears there are lots of ways to get it wrong that appear to be correct. This is why I'm pushing for the use of the macros, so that there is no question about whether the comparison is right or wrong. This is just the same as Linus' pedantic min() and max() macros - sure people can get it right by themselves, but sometimes they get it wrong, and it is easier to just make sure they don't get it wrong. Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/ From owner-netdev@oss.sgi.com Thu Nov 8 10:12:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8ICFT13360 for netdev-outgoing; Thu, 8 Nov 2001 10:12:15 -0800 Received: from lynx.adilger.int (h24-64-71-161.cg.shawcable.net [24.64.71.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8ICC013356 for ; Thu, 8 Nov 2001 10:12:12 -0800 Received: (from adilger@localhost) by lynx.adilger.int (8.11.2/8.11.2) id fA8IAOY24155; Thu, 8 Nov 2001 11:10:24 -0700 Date: Thu, 8 Nov 2001 11:10:24 -0700 From: Andreas Dilger To: kuznet@ms2.inr.ac.ru Cc: "David S. Miller" , tim@physik3.uni-rostock.de, jgarzik@mandrakesoft.com, andrewm@uow.edu.au, linux-kernel@vger.kernel.org, torvalds@transmeta.com, netdev@oss.sgi.com, ak@muc.de Subject: Re: [PATCH] net/ipv4/*, net/core/neighbour.c jiffies cleanup Message-ID: <20011108111024.X5922@lynx.no> Mail-Followup-To: kuznet@ms2.inr.ac.ru, "David S. Miller" , tim@physik3.uni-rostock.de, jgarzik@mandrakesoft.com, andrewm@uow.edu.au, linux-kernel@vger.kernel.org, torvalds@transmeta.com, netdev@oss.sgi.com, ak@muc.de References: <20011107.160950.57890584.davem@redhat.com> <200111081754.UAA24454@ms2.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200111081754.UAA24454@ms2.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Thu, Nov 08, 2001 at 08:54:29PM +0300 X-GPG-Key: 1024D/0D35BED6 X-GPG-Fingerprint: 7A37 5D79 BF1B CECA D44F 8A29 A488 39F5 0D35 BED6 Sender: owner-netdev@oss.sgi.com Precedence: bulk On Nov 08, 2001 20:54 +0300, kuznet@ms2.inr.ac.ru wrote: > I want to _ask_ one thing people working on these changes. > _Please_, defer this edit to 2.5. The changes are very good, > but time for them is very bad. > > When I wrote this code the macros did not exist. Well, Alan said the same thing, and I went and checked - the macros existed since 2.1.106, probably the last time there was a "jiffies wrap" effort. It is more likely that nobody knows about them, because nobody uses them, because nobody knows about them, etc. > However, this code is right, take my word. Hence, it is pure maintanance > problem and as soon as main reader of this code is me, I would be glad to > see the changes, but only having no deadlines. If people don't want to see them, that is fine with me - they will stop. Tim and I were only trying to fix instability that he noticed when initializing jiffies to some large pre-wrap value. If people are OK with 2.4 Linux boxes hanging after 497 days, that is fine with me. The only box I have that could stay up that long is my router (486/33), and it does not have a UPS so it is not likely to actually make it (record is 6 months or so). Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/ From owner-netdev@oss.sgi.com Thu Nov 8 10:18:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8IIIV13526 for netdev-outgoing; Thu, 8 Nov 2001 10:18:18 -0800 Received: from gans.physik3.uni-rostock.de (root@gans.physik3.uni-rostock.de [139.30.44.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8IIE013523 for ; Thu, 8 Nov 2001 10:18:15 -0800 Received: from localhost (tim@localhost) by gans.physik3.uni-rostock.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA06595; Thu, 8 Nov 2001 19:10:05 +0100 Date: Thu, 8 Nov 2001 19:10:05 +0100 (CET) From: Tim Schmielau To: cc: "David S. Miller" , , , , , , , Subject: Re: [PATCH] net/ipv4/*, net/core/neighbour.c jiffies cleanup In-Reply-To: <200111081754.UAA24454@ms2.inr.ac.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk > > jiffies cleanup patch of the day follows. Mostly boring changes of jiffies > > comparisons to use time_{before,after} in order to handle jiffies > > wraparound correctly. > > I want to _ask_ one thing people working on these changes. > _Please_, defer this edit to 2.5. The changes are very good, > but time for them is very bad. > Agreed. For now I will only post patches for code that really _is_ broken. I've already learned that from the discussion with David Miller. This way I might miss some places getting the comparison wrong, but changes will be less intrusive. However, I definitely want to see a 2.4.x someday that is able to run for more that 497 days. Tim From owner-netdev@oss.sgi.com Thu Nov 8 10:36:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8IajM13856 for netdev-outgoing; Thu, 8 Nov 2001 10:36:45 -0800 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8Iaf013852 for ; Thu, 8 Nov 2001 10:36:42 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id VAA24875; Thu, 8 Nov 2001 21:32:32 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200111081832.VAA24875@ms2.inr.ac.ru> Subject: Re: [PATCH] net/ipv4/*, net/core/neighbour.c jiffies cleanup To: adilger@turbolabs.com (Andreas Dilger) Date: Thu, 8 Nov 2001 21:32:32 +0300 (MSK) Cc: davem@redhat.com, tim@physik3.uni-rostock.de, jgarzik@mandrakesoft.com, andrewm@uow.edu.au, linux-kernel@vger.kernel.org, torvalds@transmeta.com, netdev@oss.sgi.com, ak@muc.de In-Reply-To: <20011108111024.X5922@lynx.no> from "Andreas Dilger" at Nov 8, 1 11:10:24 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello! > is more likely that nobody knows about them, because nobody uses them, > because nobody knows about them, etc. Yes, it is thing which usually happens with good macros. :-) > If people don't want to see them, that is fine with me - they will stop. I talk only about neighbour.c. It is pretty hairy to bring it to brain cache fastly enough. And I am afraid (remember) that in the past I did some silly tricks, sort of using the fact that large positive now - mark means that mark is in future. Mostly likely killed together with another hacks, but I am not sure. Another places are trivial as rule and can be edited any time. Alexey From owner-netdev@oss.sgi.com Thu Nov 8 13:18:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8LIB306940 for netdev-outgoing; Thu, 8 Nov 2001 13:18:11 -0800 Received: from mail.zrz.tu-berlin.de (smtp.zrz.TU-Berlin.DE [130.149.4.15]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8LI6006916 for ; Thu, 8 Nov 2001 13:18:06 -0800 Received: from ftsu07.ee.tu-berlin.de ([130.149.49.87] helo=ftmail.ee.tu-berlin.de) by mail.zrz.tu-berlin.de with smtp (exim-3.33) for id 161wYi-0007UV-00; Thu, 08 Nov 2001 22:18:00 +0100 Received: from cs.tu-berlin.de (tyche.ee.TU-Berlin.DE [130.149.51.32]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id fA8LHxD01873 for ; Thu, 8 Nov 2001 22:17:59 +0100 Message-ID: <3BEAF686.CDC5D4C5@cs.tu-berlin.de> Date: Thu, 08 Nov 2001 22:17:58 +0100 From: root X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-me11 i686) X-Accept-Language: en MIME-Version: 1.0 To: "netdev@oss.sgi.com" Subject: IPV6_HOPOPTS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello out there, I'am trying to use the hop-by-hop options with ipv6 but I can't manage to resceive those options on an intermediate router along the packets deliverypath from source to destination. On the source I send an udp-ipv6-packet using ancillary data with : sensend_sd = socket(PF_INET6, SOCK_DGRAM, proto->p_proto); /* with proto->p_proto=udp=17 */ ... send_cmsgptr_1->cmsg_level = IPPROTO_IPV6; /*######*/ send_cmsgptr_1->cmsg_type = IPV6_HOPOPTS; /*######*/ ... sendmsg(send_sd, &send_msghdr, 0); and at the destination after passing an intermediate router get my TLV-encoded hopoption back with: ... recv_sd = socket(PF_INET6, SOCK_RAW, proto->p_proto) /* again proto->p_proto=udp=17 */ int on=1; setsockopt(recv_sd, IPPROTO_IPV6, IPV6_HOPOPTS, &on, sizeof(on)); ... recvmsg(recv_sd, &recv_msghdr, 0); where indeed the ancillary-data-object of recv_msghdr holds the two hops earlyer assigned value. But when i start the same deamon like on the destination on the intermediate router, recvmsg doesn't receive anything. Probably the socket must be created with proto->p_proto=hopopt=0 like recv_sd = socket(PF_INET6, SOCK_RAW, proto->p_proto) /* again proto->p_proto=hopopt=0 */ but then (after uncommenting hopopt in /etc/protocols) the kernel returns: Socket type not supported. Can anybody help me out with this ??? Thanks in advance... axel From owner-netdev@oss.sgi.com Thu Nov 8 19:41:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA93fR922769 for netdev-outgoing; Thu, 8 Nov 2001 19:41:27 -0800 Received: from whatever.local ([65.10.228.207]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA93fQ022766 for ; Thu, 8 Nov 2001 19:41:26 -0800 Received: (qmail 21293 invoked by uid 513); 9 Nov 2001 03:46:37 -0000 From: chuckw@ieee.org Date: Thu, 8 Nov 2001 22:46:37 -0500 To: netdev@oss.sgi.com Subject: Mailing list archive?? Message-ID: <20011108224637.A21266@ieee.org> Mail-Followup-To: netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-netdev@oss.sgi.com Precedence: bulk Would anyone happen to know if there is a mailing list archive for this list? Thanks, Chuck From owner-netdev@oss.sgi.com Thu Nov 8 21:15:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA95FRF24204 for netdev-outgoing; Thu, 8 Nov 2001 21:15:27 -0800 Received: from samrat.cisco.com (samrat.cisco.com [192.135.241.27]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA95FE024199; Thu, 8 Nov 2001 21:15:15 -0800 Received: from vjacob-pc.cisco.com (root@[192.135.240.108]) by samrat.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA27535; Fri, 9 Nov 2001 10:44:12 +0530 (IST) Received: from localhost (jvt@localhost) by vjacob-pc.cisco.com (8.9.3/8.9.3) with ESMTP id KAA00976; Fri, 9 Nov 2001 10:43:48 GMT X-Authentication-Warning: vjacob-pc.cisco.com: jvt owned process doing -bs Date: Fri, 9 Nov 2001 10:43:48 +0000 (/etc/localtime) From: Vino Thomas X-Sender: jvt@vjacob-pc.cisco.com To: Krishna Kumar cc: Linus Torvalds , Andreas Dilger , ak@muc.de, andrewm@uow.edu.au, "David S. Miller" , jgarzik@mandrakesoft.com, kuznet@ms2.inr.ac.ru, linux-kernel@vger.kernel.org, IPV6 Mailing List , owner-netdev@oss.sgi.com, tim@physik3.uni-rostock.de Subject: Re: [PATCH] net/ipv4/*, net/core/neighbour.c jiffies cleanup In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello Krishna, In 'Case 3' Change the line jiffies = start + HZ - 1; to jiffies = start + HZ - 91; and see the difference. Regards, Vino. On Thu, 8 Nov 2001, Krishna Kumar wrote: > > Hi Linus, > > > > > > > In short: It is wrong to do > > > > > > if (jiffies <= start+HZ) > > > > > > and it is _right_ to do > > > > > > if (jiffies - start <= HZ) > > > > Actually this last part is wrong, isn't it ? jiffies <= start + HZ is > also > > a correct way to do it, since start+HZ will overflow to the current value > > of jiffies when HZ time elapses. So the above two statements are > IDENTICAL. > > > > No. > > > > Try it out with a few examples. You'll see. > > > > Linus > > I am sorry, but I still don't see the difference. I wrote a small program > with different > cases, but the values still come same irrespective of the input arguments > to the > checks. Could you tell under what conditions the checks wuold fail ? The > 2's > complement works the same for addition and subtraction. I have included > the > test program below. > > Thanks, > > - KK > > --------------------------------------------------------------------------------------------- > /* > if (jiffies <= start+HZ) > if (jiffies - start <= HZ) > */ > > #define HZ 100 > > main() > { > unsigned long start, jiffies; > > /* Case 1 */ > start = ((unsigned long) -1); > jiffies = start + HZ; > if (jiffies <= start + HZ) { > printf("Less Case 1\n"); > } > if (jiffies - start <= HZ) { > printf("Less Case 2\n"); > } > > /* Case 2 */ > start = ((unsigned long) -10); > jiffies = start + HZ + 1; > if (jiffies <= start + HZ) { > printf("Less Case 3\n"); > } > if (jiffies - start <= HZ) { > printf("Less Case 4\n"); > } > > /* Case 3 */ > start = ((unsigned long) -10); > jiffies = start + HZ - 1; > if (jiffies <= start + HZ) { > printf("Less Case 5\n"); > } > if (jiffies - start <= HZ) { > printf("Less Case 6\n"); > } > } > > > From owner-netdev@oss.sgi.com Thu Nov 8 23:44:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA97ii726881 for netdev-outgoing; Thu, 8 Nov 2001 23:44:44 -0800 Received: from whatever.local ([65.10.228.207]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA97ig026878 for ; Thu, 8 Nov 2001 23:44:42 -0800 Received: (qmail 21730 invoked by uid 513); 9 Nov 2001 07:49:51 -0000 From: chuckw@ieee.org Date: Fri, 9 Nov 2001 02:49:51 -0500 To: netdev@oss.sgi.com Subject: More that 1 sock per socket? Message-ID: <20011109024951.C21266@ieee.org> Mail-Followup-To: netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello All, My question is in a couple of parts. First, can there be more than one sock per socket structure? If no, then why the sock list. If yes, what is the use of this? Thanks Much in Advance, Chuck From owner-netdev@oss.sgi.com Fri Nov 9 13:58:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9Lw0819344 for netdev-outgoing; Fri, 9 Nov 2001 13:58:00 -0800 Received: from tsmtp9.mail.isp (mailhost.teleline.es [195.235.113.141] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9Lvr019338 for ; Fri, 9 Nov 2001 13:57:54 -0800 Received: from terra.es ([213.99.201.186]) by tsmtp9.mail.isp (Netscape Messaging Server 4.15 tsmtp9 Jul 26 2001 13:10:38) with ESMTP id GMJZL001.1VY for ; Fri, 9 Nov 2001 22:55:48 +0100 Message-ID: <3BEC50F1.7EE8FF94@terra.es> Date: Fri, 09 Nov 2001 22:56:01 +0100 From: x X-Mailer: Mozilla 4.77 [es] (X11; U; Linux 2.4.9 i686) X-Accept-Language: es-ES, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: Mailing list archive?? References: <20011108224637.A21266@ieee.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk > Would anyone happen to know if there is a mailing list > archive for this list? > http://www.oss.sgi.com/projects/netdev/mail/netdev/threads.html From owner-netdev@oss.sgi.com Fri Nov 9 14:27:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9MRc619863 for netdev-outgoing; Fri, 9 Nov 2001 14:27:38 -0800 Received: from mail2.lsil.com (mail2.lsil.com [147.145.40.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9MRa019860 for ; Fri, 9 Nov 2001 14:27:36 -0800 Received: from mhbs.lsil.com (mhbs [147.145.31.100]) by mail2.lsil.com (8.9.3+Sun/8.9.1) with ESMTP id OAA07709 for ; Fri, 9 Nov 2001 14:27:35 -0800 (PST) Received: from inca.co.lsil.com by mhbs.lsil.com with ESMTP for netdev@oss.sgi.com; Fri, 9 Nov 2001 14:27:33 -0800 Received: from ra.ks.lsil.com (ra.ks.lsil.com [153.79.162.3]) by inca.co.lsil.com (8.9.3/8.9.3) with ESMTP id PAA24576 for ; Fri, 9 Nov 2001 15:27:32 -0700 (MST) Received: from lsil.com (nromernt.ks.lsil.com [153.79.8.107]) by ra.ks.lsil.com (8.8.8+Sun/8.8.8) with ESMTP id QAA29539; Fri, 9 Nov 2001 16:14:32 -0600 (CST) Message-Id: <3BEC5543.9060708@lsil.com> Date: Fri, 09 Nov 2001 16:14:27 -0600 From: Noah Romer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010917 X-Accept-Language: en-us MIME-Version: 1.0 To: chuckw@ieee.org CC: netdev@oss.sgi.com Subject: Re: Mailing list archive?? References: <20011108224637.A21266@ieee.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk chuckw@ieee.org wrote: > Would anyone happen to know if there is a mailing list > archive for this list? http://marc.theaimsgroup.com/?l=linux-netdev&r=1&w=2&b=200111 The Aims Group maintains an extensive archive of mailing lists related to Unix/Linux, the Internet & WWW, etc. -- Noah Romer Driver Developer, CM gopher and Linux Whipping Boy Storage Components Firmware LSI Logic Corp. From owner-netdev@oss.sgi.com Fri Nov 9 16:20:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAA0Kur21773 for netdev-outgoing; Fri, 9 Nov 2001 16:20:56 -0800 Received: from whatever.local ([65.10.228.207]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAA0Ks021769 for ; Fri, 9 Nov 2001 16:20:55 -0800 Received: (qmail 22877 invoked by uid 513); 10 Nov 2001 00:25:56 -0000 From: chuckw@ieee.org Date: Fri, 9 Nov 2001 19:25:56 -0500 To: netdev@oss.sgi.com Subject: Re: Mailing list archive?? Message-ID: <20011109192556.D21266@ieee.org> Mail-Followup-To: netdev@oss.sgi.com References: <20011108224637.A21266@ieee.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011108224637.A21266@ieee.org>; from chuckw@ieee.org on Thu, Nov 08, 2001 at 10:46:37PM -0500 Sender: owner-netdev@oss.sgi.com Precedence: bulk On Thu, Nov 08, 2001 at 10:46:37PM -0500, chuckw@ieee.org wrote: > Would anyone happen to know if there is a mailing list > archive for this list? > > Thanks, > Chuck Many Thanks Chuck From owner-netdev@oss.sgi.com Sat Nov 10 04:47:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAACl7621770 for netdev-outgoing; Sat, 10 Nov 2001 04:47:07 -0800 Received: from ratula.moonlight.se (qmailr@c49.ryd.student.liu.se [130.236.234.49]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAACl0021764 for ; Sat, 10 Nov 2001 04:47:02 -0800 Received: (qmail 19088 invoked by uid 1000); 10 Nov 2001 12:45:59 -0000 Date: Sat, 10 Nov 2001 13:45:59 +0100 From: Carl-Johan Bostorp To: netdev@oss.sgi.com Subject: Turning off CRC check in NIC Message-ID: <20011110134559.A19083@ratula.moonlight.se> Mail-Followup-To: Carl-Johan Bostorp , netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-netdev@oss.sgi.com Precedence: bulk --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, I want to turn off the CRC check on ethernet frames and pass every packet u= p to the kernel. I have an eepro100, so I mailed Intel about it and asked f= or specs. The reply I got was that the kernel may actually rely on the NIC = doing this check. So, what's the deal? What effects will there be if the NIC starts passing e= verything up to the kernel? --=20 ~~~<*>~~~ Web: http://elemental.webservices.se/ ICQ: 3534707 PGP: 0xA6B5C43B IRCnet: ctor ~~~<*>~~~ --Dxnq1zWXvFF0Q93v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE77SGFdzh7Laa1xDsRAqDXAKDMW0GGjr9/8AIaoUrf7aQJv6t+zACgiUSq MsXHX4/xLDkMPT4PJ3+cuDQ= =elGl -----END PGP SIGNATURE----- --Dxnq1zWXvFF0Q93v-- From owner-netdev@oss.sgi.com Sat Nov 10 09:55:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAAHt5S26609 for netdev-outgoing; Sat, 10 Nov 2001 09:55:05 -0800 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAAHt2026605 for ; Sat, 10 Nov 2001 09:55:03 -0800 Received: from mops.inr.ac.ru (root@mops.inr.ac.ru [193.233.7.60]) by ms2.inr.ac.ru (8.6.13/ANK) with ESMTP id UAA16839; Sat, 10 Nov 2001 20:54:58 +0300 Received: (from kuznet@localhost) by mops.inr.ac.ru (8.9.3/8.9.3) id IAA00423; Sat, 10 Nov 2001 08:36:06 +0300 Message-Id: <200111100536.IAA00423@mops.inr.ac.ru> Subject: Re: IPV6_HOPOPTS To: insel@cs.tu-berlin.DE (root) Date: Sat, 10 Nov 2001 08:36:06 +0300 (MSK) Cc: netdev@oss.sgi.com In-Reply-To: <3BEAF686.CDC5D4C5@cs.tu-berlin.de> from "root" at Nov 9, 1 00:45:01 am From: Alexey Kuznetsov X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello! > Can anybody help me out with this ??? Forwarded packets are not delivered to sockets. Apparently, you want to use Router Alert option, to reserve some ID and to instruct a socket to grab the packets using option IPV6_ROUTER_ALERT. Alexey From owner-netdev@oss.sgi.com Sat Nov 10 22:35:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAB6ZZ006766 for netdev-outgoing; Sat, 10 Nov 2001 22:35:35 -0800 Received: from vaio.greennet (pool-151-196-115-58.balt.east.verizon.net [151.196.115.58]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAB6ZU006763 for ; Sat, 10 Nov 2001 22:35:30 -0800 Received: from localhost (becker@localhost) by vaio.greennet (8.9.3/8.8.7) with ESMTP id SAA06658; Sat, 10 Nov 2001 18:31:37 -0500 Date: Sat, 10 Nov 2001 18:31:37 -0500 (EST) From: Donald Becker X-Sender: becker@vaio.greennet To: Carl-Johan Bostorp cc: netdev@oss.sgi.com Subject: Re: Turning off CRC check in NIC In-Reply-To: <20011110134559.A19083@ratula.moonlight.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Sat, 10 Nov 2001, Carl-Johan Bostorp wrote: > I want to turn off the CRC check on ethernet frames and pass every > packet up to the kernel. Why? > I have an eepro100, so I mailed Intel about > it and asked for specs. The reply I got was that the kernel may > actually rely on the NIC doing this check. > > So, what's the deal? What effects will there be if the NIC starts > passing everything up to the kernel? The network stack will interpret arbitrarily corrupted packets as valid data. Very Bad Things might happen, and you'll not know what occurred or why. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From owner-netdev@oss.sgi.com Sat Nov 10 23:29:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAB7TsS08009 for netdev-outgoing; Sat, 10 Nov 2001 23:29:54 -0800 Received: from grok.yi.org (IDENT:YttYD2MlR4QvYPoOFZFXG0VBfgSHrkOY@cx97923-a.phnx3.az.home.com [24.9.112.194] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAB7Tn008006 for ; Sat, 10 Nov 2001 23:29:49 -0800 Received: from candelatech.com (IDENT:c2axfTx8AGybjLy47aLGCnga4G7hpt7t@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id fAB7TZl11118; Sun, 11 Nov 2001 00:29:35 -0700 Message-ID: <3BEE28DE.9040606@candelatech.com> Date: Sun, 11 Nov 2001 00:29:34 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Donald Becker CC: Carl-Johan Bostorp , netdev@oss.sgi.com Subject: Re: Turning off CRC check in NIC References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Donald Becker wrote: > On Sat, 10 Nov 2001, Carl-Johan Bostorp wrote: > > >>I want to turn off the CRC check on ethernet frames and pass every >>packet up to the kernel. >> > > Why? > > >>I have an eepro100, so I mailed Intel about >>it and asked for specs. The reply I got was that the kernel may >>actually rely on the NIC doing this check. >> >>So, what's the deal? What effects will there be if the NIC starts >>passing everything up to the kernel? >> > > The network stack will interpret arbitrarily corrupted packets as valid > data. Very Bad Things might happen, and you'll not know what occurred or > why. I doubt that anything would crash because the protocols should already be hardened against any kind of malicious packet that might come along. Could you mess up a NIC/Driver with a corrupt packet?? The higher layers like TCP and UDP have their own checksums, so should catch most bad packets there... (UDP may ignore it's checksum, btw)... Ben > > > Donald Becker becker@scyld.com > Scyld Computing Corporation http://www.scyld.com > 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters > Annapolis MD 21403 410-990-9993 > > -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From owner-netdev@oss.sgi.com Sun Nov 11 01:41:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAB9fVN09590 for netdev-outgoing; Sun, 11 Nov 2001 01:41:31 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAB9fT009587 for ; Sun, 11 Nov 2001 01:41:29 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 918461E0A3; Sun, 11 Nov 2001 10:41:23 +0100 (MET) Date: Sun, 11 Nov 2001 10:41:22 +0100 From: Andi Kleen To: Ben Greear Cc: Donald Becker , Carl-Johan Bostorp , netdev@oss.sgi.com Subject: Re: Turning off CRC check in NIC Message-ID: <20011111104122.A29917@wotan.suse.de> References: <3BEE28DE.9040606@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i In-Reply-To: <3BEE28DE.9040606@candelatech.com>; from greearb@candelatech.com on Sun, Nov 11, 2001 at 12:29:34AM -0700 Sender: owner-netdev@oss.sgi.com Precedence: bulk On Sun, Nov 11, 2001 at 12:29:34AM -0700, Ben Greear wrote: > The higher layers like TCP and UDP have their own checksums, so should catch > most bad packets there... (UDP may ignore it's checksum, btw)... The TCP/UDP checksum is much weaker than the CRC used by ethernet and does not detect many errors. It is mostly a protection against bugs, not about real bit errors as they could occur on the wire. I would not turn the ethernet CRC off. -Andi From owner-netdev@oss.sgi.com Sun Nov 11 05:36:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fABDavO17825 for netdev-outgoing; Sun, 11 Nov 2001 05:36:57 -0800 Received: from evil.netppl.fi (evil.netppl.fi [195.242.209.201]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fABDas017821 for ; Sun, 11 Nov 2001 05:36:54 -0800 Received: (from pp@localhost) by evil.netppl.fi (8.11.6/8.11.6) id fABDc2928314 for netdev@oss.sgi.com; Sun, 11 Nov 2001 15:38:02 +0200 Date: Sun, 11 Nov 2001 15:38:02 +0200 From: =?iso-8859-1?Q?Pekka_Pietik=E4inen?= To: netdev@oss.sgi.com Subject: Re: Turning off CRC check in NIC Message-ID: <20011111153802.A25472@netppl.fi> References: <3BEE28DE.9040606@candelatech.com> <20011111104122.A29917@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011111104122.A29917@wotan.suse.de>; from ak@suse.de on Sun, Nov 11, 2001 at 10:41:22AM +0100 Sender: owner-netdev@oss.sgi.com Precedence: bulk On Sun, Nov 11, 2001 at 10:41:22AM +0100, Andi Kleen wrote: > On Sun, Nov 11, 2001 at 12:29:34AM -0700, Ben Greear wrote: > > The higher layers like TCP and UDP have their own checksums, so should catch > > most bad packets there... (UDP may ignore it's checksum, btw)... > > The TCP/UDP checksum is much weaker than the CRC used by ethernet and > does not detect many errors. It is mostly a protection against bugs, not > about real bit errors as they could occur on the wire. I would not turn > the ethernet CRC off. Well, I'd assume disabling CRC and having the NIC forward all packets (including the checksum) could be a useful feature for analyzing network problems. If you see random CRC errors on the network and your NIC drops packets with bad checksums, how can you find out what machine sent it? I don't know if any NICs support this. Best choice I can think of is acenic with some firmware hacks. You can probably find copper-based boards for pretty cheap ($150-200, not bad for a 1000baseT board. Will work on 10/100baseT too) -- Pekka Pietikainen From owner-netdev@oss.sgi.com Sun Nov 11 07:25:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fABFPHq19328 for netdev-outgoing; Sun, 11 Nov 2001 07:25:17 -0800 Received: from vaio.greennet (pool-151-196-114-10.balt.east.verizon.net [151.196.114.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fABFPC019325 for ; Sun, 11 Nov 2001 07:25:13 -0800 Received: from localhost (becker@localhost) by vaio.greennet (8.9.3/8.8.7) with ESMTP id KAA08642; Sun, 11 Nov 2001 10:26:26 -0500 Date: Sun, 11 Nov 2001 10:26:26 -0500 (EST) From: Donald Becker X-Sender: becker@vaio.greennet To: =?iso-8859-1?Q?Pekka_Pietik=E4inen?= cc: netdev@oss.sgi.com Subject: Re: Turning off CRC check in NIC In-Reply-To: <20011111153802.A25472@netppl.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id fABFPE019326 Sender: owner-netdev@oss.sgi.com Precedence: bulk On Sun, 11 Nov 2001, [iso-8859-1] Pekka Pietikäinen wrote: > On Sun, Nov 11, 2001 at 10:41:22AM +0100, Andi Kleen wrote: > > On Sun, Nov 11, 2001 at 12:29:34AM -0700, Ben Greear wrote: > > > The higher layers like TCP and UDP have their own checksums, so should catch > > > most bad packets there... (UDP may ignore it's checksum, btw)... Sun's original NFS implementation turned off UDP checksums to get usable performance. The concept was that the Ethernet CRC was all of the protection needed. This design decision was copied, and has led to many corrupted files over the years. > > The TCP/UDP checksum is much weaker than the CRC used by ethernet and > > does not detect many errors. It is mostly a protection against bugs, not > > about real bit errors as they could occur on the wire. I would not turn > > the ethernet CRC off. > > Well, I'd assume disabling CRC and having the NIC forward all packets > (including the checksum) could be a useful feature for analyzing > network problems. Or you could just look at /proc/net/dev for CRC errors. If you see any at all, something is broken. This doesn't specifically help you locate the problem, but CRC errors should be rare. > I don't know if any NICs support this. Almost all NICs support disabling CRC append on transmit and discarding on receive. The discard semantics vary. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From owner-netdev@oss.sgi.com Sun Nov 11 09:02:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fABH2XZ20680 for netdev-outgoing; Sun, 11 Nov 2001 09:02:33 -0800 Received: from gans.physik3.uni-rostock.de (root@gans.physik3.uni-rostock.de [139.30.44.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fABH1l020677 for ; Sun, 11 Nov 2001 09:01:48 -0800 Received: from localhost (tim@localhost) by gans.physik3.uni-rostock.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA11158; Sun, 11 Nov 2001 17:58:38 +0100 Date: Sun, 11 Nov 2001 17:58:38 +0100 (CET) From: Tim Schmielau To: cc: Linus Torvalds , Philip Blundell , Jeff Garzik , Simon Vogl , Andre Hedrick , Jens Axboe , Andrew Morton , "David S. Miller" , Andi Kleen , Alexey Kuznetsov , Tim Waugh , David Hinds , , Andreas Dilger Subject: [Patch] fix incorrect jiffies compares Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi all, this patch again changes comparisons of jiffies to use the time_{before,after} macros which are safe against wraparound. However, this time I only fix places that actually get the wraparound wrong. I hope that will silence the legitimate voices that accused my previous patches of being too intrusive. The parts of my previous patches that actually fix incorrect comparisons are included. I am about halfway through the list of suspicious files, so another patch like this is to be expected if no objections are raised. With these changes I do not see the solid lockups after jiffies wrap anymore that I have reported in the "Re: [Patch] Re: Nasty suprise with uptime" thread. I hope I have Cc:ed all maintainers. Excuses for Cc:ing so many people, but I also don't want to flood lkml with dozens of one-liner changes that all do essentially the same. Tim diff -u -r --exclude-from dontdiff linux-2.4.15-pre2/drivers/block/paride/pseudo.h linux-2.4.15-pre2-jiffies64/drivers/block/paride/pseudo.h --- linux-2.4.15-pre2/drivers/block/paride/pseudo.h Sun Feb 4 19:05:29 2001 +++ linux-2.4.15-pre2-jiffies64/drivers/block/paride/pseudo.h Sun Nov 11 10:40:13 2001 @@ -102,7 +102,7 @@ spin_unlock_irqrestore(&ps_spinlock,flags); return; } - if (!ps_ready || ps_ready() || (jiffies >= ps_timeout)) { + if (!ps_ready || ps_ready() || time_after_eq(jiffies, ps_timeout)) { ps_continuation = NULL; spin_unlock_irqrestore(&ps_spinlock,flags); con(); @@ -131,7 +131,7 @@ spin_unlock_irqrestore(&ps_spinlock,flags); return; } - if (!ps_ready || ps_ready() || (jiffies >= ps_timeout)) { + if (!ps_ready || ps_ready() || time_after_eq(jiffies, ps_timeout)) { ps_continuation = NULL; spin_unlock_irqrestore(&ps_spinlock,flags); con(); diff -u -r --exclude-from dontdiff linux-2.4.15-pre2/drivers/char/esp.c linux-2.4.15-pre2-jiffies64/drivers/char/esp.c --- linux-2.4.15-pre2/drivers/char/esp.c Sun Nov 11 10:23:37 2001 +++ linux-2.4.15-pre2-jiffies64/drivers/char/esp.c Sun Nov 11 10:40:13 2001 @@ -2162,7 +2162,7 @@ if (signal_pending(current)) break; - if (timeout && ((orig_jiffies + timeout) < jiffies)) + if (timeout && (time_after(jiffies, orig_jiffies + timeout))) break; serial_out(info, UART_ESI_CMD1, ESI_NO_COMMAND); diff -u -r --exclude-from dontdiff linux-2.4.15-pre2/drivers/char/ip2/i2lib.c linux-2.4.15-pre2-jiffies64/drivers/char/ip2/i2lib.c --- linux-2.4.15-pre2/drivers/char/ip2/i2lib.c Sat Nov 3 02:26:17 2001 +++ linux-2.4.15-pre2-jiffies64/drivers/char/ip2/i2lib.c Sun Nov 11 10:40:13 2001 @@ -1330,7 +1330,7 @@ // if expires == 0 then timer poped, then do not need to del_timer if ((timeout > 0) && pCh->BookmarkTimer.expires && - (pCh->BookmarkTimer.expires > jiffies)) { + time_before(jiffies, pCh->BookmarkTimer.expires)) { del_timer( &(pCh->BookmarkTimer) ); pCh->BookmarkTimer.expires = 0; diff -u -r --exclude-from dontdiff linux-2.4.15-pre2/drivers/char/mxser.c linux-2.4.15-pre2-jiffies64/drivers/char/mxser.c --- linux-2.4.15-pre2/drivers/char/mxser.c Thu Oct 25 22:53:47 2001 +++ linux-2.4.15-pre2-jiffies64/drivers/char/mxser.c Sun Nov 11 10:40:13 2001 @@ -847,7 +847,7 @@ while (!(inb(info->base + UART_LSR) & UART_LSR_TEMT)) { set_current_state(TASK_INTERRUPTIBLE); schedule_timeout(5); - if (jiffies > timeout) + if (time_after(jiffies, timeout)) break; } } diff -u -r --exclude-from dontdiff linux-2.4.15-pre2/drivers/i2c/i2c-adap-ite.c linux-2.4.15-pre2-jiffies64/drivers/i2c/i2c-adap-ite.c --- linux-2.4.15-pre2/drivers/i2c/i2c-adap-ite.c Thu Oct 11 17:05:47 2001 +++ linux-2.4.15-pre2-jiffies64/drivers/i2c/i2c-adap-ite.c Sun Nov 11 10:40:13 2001 @@ -82,7 +82,7 @@ unsigned long j = jiffies + 10; DEB3(printk(" Write 0x%02x to 0x%x\n",(unsigned short)val, ctl&0xff)); - DEB3({while (jiffies < j) schedule();}) + DEB3({while (time_before(jiffies, j)) schedule();}) outw(val,ctl); } diff -u -r --exclude-from dontdiff linux-2.4.15-pre2/drivers/i2c/i2c-algo-bit.c linux-2.4.15-pre2-jiffies64/drivers/i2c/i2c-algo-bit.c --- linux-2.4.15-pre2/drivers/i2c/i2c-algo-bit.c Thu Oct 11 17:05:47 2001 +++ linux-2.4.15-pre2-jiffies64/drivers/i2c/i2c-algo-bit.c Sun Nov 11 10:40:13 2001 @@ -49,7 +49,7 @@ /* respectively. This makes sure that the algorithm works. Some chips */ /* might not like this, as they have an internal timeout of some mils */ /* -#define SLO_IO jif=jiffies;while(jiffies<=jif+i2c_table[minor].veryslow)\ +#define SLO_IO jif=jiffies;while(time_before_eq(jiffies, jif+i2c_table[minor].veryslow))\ if (need_resched) schedule(); */ @@ -117,7 +117,7 @@ * while they are processing data internally. */ setscl(adap,1); - if (start+adap->timeout <= jiffies) { + if (time_after_eq(jiffies, start+adap->timeout)) { return -ETIMEDOUT; } if (current->need_resched) diff -u -r --exclude-from dontdiff linux-2.4.15-pre2/drivers/ide/ide-probe.c linux-2.4.15-pre2-jiffies64/drivers/ide/ide-probe.c --- linux-2.4.15-pre2/drivers/ide/ide-probe.c Thu Oct 11 18:14:32 2001 +++ linux-2.4.15-pre2-jiffies64/drivers/ide/ide-probe.c Sun Nov 11 10:40:13 2001 @@ -370,7 +370,7 @@ OUT_BYTE(EXABYTE_ENABLE_NEST, IDE_COMMAND_REG); timeout = jiffies + WAIT_WORSTCASE; do { - if (jiffies > timeout) { + if (time_after(jiffies, timeout)) { printk("failed (timeout)\n"); return; } diff -u -r --exclude-from dontdiff linux-2.4.15-pre2/drivers/ide/ide-tape.c linux-2.4.15-pre2-jiffies64/drivers/ide/ide-tape.c --- linux-2.4.15-pre2/drivers/ide/ide-tape.c Mon Aug 13 23:56:19 2001 +++ linux-2.4.15-pre2-jiffies64/drivers/ide/ide-tape.c Sun Nov 11 10:40:13 2001 @@ -2418,26 +2418,26 @@ idetape_tape_t *tape = drive->driver_data; int full = 125, empty = 75; - if (jiffies > tape->controlled_pipeline_head_time + 120 * HZ) { + if (time_after(jiffies, tape->controlled_pipeline_head_time + 120 * HZ)) { tape->controlled_previous_pipeline_head = tape->controlled_last_pipeline_head; tape->controlled_previous_head_time = tape->controlled_pipeline_head_time; tape->controlled_last_pipeline_head = tape->pipeline_head; tape->controlled_pipeline_head_time = jiffies; } - if (jiffies > tape->controlled_pipeline_head_time + 60 * HZ) + if (time_after(jiffies, tape->controlled_pipeline_head_time + 60 * HZ)) tape->controlled_pipeline_head_speed = (tape->pipeline_head - tape->controlled_last_pipeline_head) * 32 * HZ / (jiffies - tape->controlled_pipeline_head_time); - else if (jiffies > tape->controlled_previous_head_time) + else if (time_after(jiffies, tape->controlled_previous_head_time)) tape->controlled_pipeline_head_speed = (tape->pipeline_head - tape->controlled_previous_pipeline_head) * 32 * HZ / (jiffies - tape->controlled_previous_head_time); if (tape->nr_pending_stages < tape->max_stages /*- 1 */) { /* -1 for read mode error recovery */ - if (jiffies > tape->uncontrolled_previous_head_time + 10 * HZ) { + if (time_after(jiffies, tape->uncontrolled_previous_head_time + 10 * HZ)) { tape->uncontrolled_pipeline_head_time = jiffies; tape->uncontrolled_pipeline_head_speed = (tape->pipeline_head - tape->uncontrolled_previous_pipeline_head) * 32 * HZ / (jiffies - tape->uncontrolled_previous_head_time); } } else { tape->uncontrolled_previous_head_time = jiffies; tape->uncontrolled_previous_pipeline_head = tape->pipeline_head; - if (jiffies > tape->uncontrolled_pipeline_head_time + 30 * HZ) { + if (time_after(jiffies, tape->uncontrolled_pipeline_head_time + 30 * HZ)) { tape->uncontrolled_pipeline_head_time = jiffies; } } @@ -2500,7 +2500,7 @@ tape->insert_time = jiffies; tape->insert_size = 0; } - if (jiffies > tape->insert_time) + if (time_after(jiffies, tape->insert_time)) tape->insert_speed = tape->insert_size / 1024 * HZ / (jiffies - tape->insert_time); if (jiffies - tape->avg_time >= HZ) { tape->avg_speed = tape->avg_size * HZ / (jiffies - tape->avg_time) / 1024; @@ -2680,11 +2680,11 @@ tape->reads_since_buffer_fill = 0; tape->last_buffer_fill = jiffies; idetape_queue_onstream_buffer_fill(drive); - if (jiffies > tape->insert_time) + if (time_after(jiffies, tape->insert_time)) tape->insert_speed = tape->insert_size / 1024 * HZ / (jiffies - tape->insert_time); return ide_stopped; } - if (jiffies > tape->insert_time) + if (time_after(jiffies, tape->insert_time)) tape->insert_speed = tape->insert_size / 1024 * HZ / (jiffies - tape->insert_time); calculate_speeds(drive); if (tape->onstream && tape->max_frames && @@ -2756,7 +2756,7 @@ if (tape->onstream) { if (tape->cur_frames + tape->writes_since_buffer_fill >= tape->max_frames) tape->req_buffer_fill = 1; - if (jiffies > tape->last_buffer_fill + 5 * HZ / 100) + if (time_after(jiffies, tape->last_buffer_fill + 5 * HZ / 100)) tape->req_buffer_fill = 1; calculate_speeds(drive); } @@ -3214,7 +3214,7 @@ * Wait for the tape to become ready */ timeout += jiffies; - while (jiffies < timeout) { + while (time_before(jiffies, timeout)) { idetape_create_test_unit_ready_cmd(&pc); if (!__idetape_queue_pc_tail(drive, &pc)) return 0; diff -u -r --exclude-from dontdiff linux-2.4.15-pre2/drivers/net/arlan.c linux-2.4.15-pre2-jiffies64/drivers/net/arlan.c --- linux-2.4.15-pre2/drivers/net/arlan.c Sun Nov 11 10:23:38 2001 +++ linux-2.4.15-pre2-jiffies64/drivers/net/arlan.c Sun Nov 11 10:40:13 2001 @@ -677,7 +677,7 @@ arlan_retransmit_now(dev); } if (!registrationBad(dev) && - priv->tx_done_delayed < jiffies && + time_after(jiffies, priv->tx_done_delayed) && priv->tx_done_delayed != 0) { TXLAST(dev).offset = 0; diff -u -r --exclude-from dontdiff linux-2.4.15-pre2/drivers/net/rrunner.c linux-2.4.15-pre2-jiffies64/drivers/net/rrunner.c --- linux-2.4.15-pre2/drivers/net/rrunner.c Sun Nov 11 10:23:38 2001 +++ linux-2.4.15-pre2-jiffies64/drivers/net/rrunner.c Sun Nov 11 10:40:13 2001 @@ -770,7 +770,7 @@ * Give the FirmWare time to chew on the `get running' command. */ myjif = jiffies + 5 * HZ; - while ((jiffies < myjif) && !rrpriv->fw_running); + while (time_before(jiffies, myjif) && !rrpriv->fw_running); netif_start_queue(dev); diff -u -r --exclude-from dontdiff linux-2.4.15-pre2/drivers/net/sb1000.c linux-2.4.15-pre2-jiffies64/drivers/net/sb1000.c --- linux-2.4.15-pre2/drivers/net/sb1000.c Sun Sep 30 21:26:07 2001 +++ linux-2.4.15-pre2-jiffies64/drivers/net/sb1000.c Sun Nov 11 10:40:13 2001 @@ -403,7 +403,7 @@ } timeout = jiffies + Sb1000TimeOutJiffies; while (!(inb(ioaddr[1] + 6) & 0x40)) { - if (jiffies >= timeout) { + if (time_after_eq(jiffies, timeout)) { printk(KERN_WARNING "%s: sb1000_wait_for_ready timeout\n", name); return -ETIME; @@ -421,7 +421,7 @@ timeout = jiffies + Sb1000TimeOutJiffies; while (inb(ioaddr[1] + 6) & 0x80) { - if (jiffies >= timeout) { + if (time_after_eq(jiffies, timeout)) { printk(KERN_WARNING "%s: sb1000_wait_for_ready_clear timeout\n", name); return -ETIME; @@ -429,7 +429,7 @@ } timeout = jiffies + Sb1000TimeOutJiffies; while (inb(ioaddr[1] + 6) & 0x40) { - if (jiffies >= timeout) { + if (time_after_eq(jiffies, timeout)) { printk(KERN_WARNING "%s: sb1000_wait_for_ready_clear timeout\n", name); return -ETIME; diff -u -r --exclude-from dontdiff linux-2.4.15-pre2/drivers/sbus/char/aurora.c linux-2.4.15-pre2-jiffies64/drivers/sbus/char/aurora.c --- linux-2.4.15-pre2/drivers/sbus/char/aurora.c Wed Oct 31 00:08:11 2001 +++ linux-2.4.15-pre2-jiffies64/drivers/sbus/char/aurora.c Sun Nov 11 10:40:13 2001 @@ -180,7 +180,7 @@ #ifdef AURORA_DEBUG printk("aurora_long_delay: start\n"); #endif - for (i = jiffies + delay; i > jiffies; ) ; + for (i = jiffies + delay; time_before(jiffies, i); ) ; #ifdef AURORA_DEBUG printk("aurora_long_delay: end\n"); #endif diff -u -r --exclude-from dontdiff linux-2.4.15-pre2/drivers/scsi/53c7,8xx.c linux-2.4.15-pre2-jiffies64/drivers/scsi/53c7,8xx.c --- linux-2.4.15-pre2/drivers/scsi/53c7,8xx.c Thu Oct 25 22:53:48 2001 +++ linux-2.4.15-pre2-jiffies64/drivers/scsi/53c7,8xx.c Sun Nov 11 10:40:13 2001 @@ -1867,7 +1867,7 @@ */ timeout = jiffies + 5 * HZ / 10; - while ((hostdata->test_completed == -1) && jiffies < timeout) { + while ((hostdata->test_completed == -1) && time_before(jiffies, timeout)) { barrier(); cpu_relax(); } @@ -1953,7 +1953,7 @@ restore_flags(flags); timeout = jiffies + 5 * HZ; /* arbitrary */ - while ((hostdata->test_completed == -1) && jiffies < timeout) { + while ((hostdata->test_completed == -1) && time_before(jiffies, timeout)) { barrier(); cpu_relax(); } diff -u -r --exclude-from dontdiff linux-2.4.15-pre2/drivers/scsi/53c7xx.c linux-2.4.15-pre2-jiffies64/drivers/scsi/53c7xx.c --- linux-2.4.15-pre2/drivers/scsi/53c7xx.c Thu Oct 25 22:53:48 2001 +++ linux-2.4.15-pre2-jiffies64/drivers/scsi/53c7xx.c Sun Nov 11 10:40:13 2001 @@ -1627,7 +1627,7 @@ */ timeout = jiffies + 5 * HZ / 10; - while ((hostdata->test_completed == -1) && jiffies < timeout) + while ((hostdata->test_completed == -1) && time_before(jiffies, timeout)) barrier(); failed = 1; @@ -1713,7 +1713,7 @@ restore_flags(flags); timeout = jiffies + 5 * HZ; /* arbitrary */ - while ((hostdata->test_completed == -1) && jiffies < timeout) + while ((hostdata->test_completed == -1) && time_before(jiffies, timeout)) barrier(); NCR53c7x0_write32 (DSA_REG, 0); diff -u -r --exclude-from dontdiff linux-2.4.15-pre2/drivers/scsi/cpqfcTSstructs.h linux-2.4.15-pre2-jiffies64/drivers/scsi/cpqfcTSstructs.h --- linux-2.4.15-pre2/drivers/scsi/cpqfcTSstructs.h Thu Oct 25 22:53:50 2001 +++ linux-2.4.15-pre2-jiffies64/drivers/scsi/cpqfcTSstructs.h Sun Nov 11 10:40:13 2001 @@ -27,7 +27,7 @@ #define DbgDelay(secs) { int wait_time; printk( " DbgDelay %ds ", secs); \ for( wait_time=jiffies + (secs*HZ); \ - wait_time > jiffies ;) ; } + time_before(jiffies, wait_time) ;) ; } #define CPQFCTS_DRIVER_VER(maj,min,submin) ((maj<<16)|(min<<8)|(submin)) // don't forget to also change MODULE_DESCRIPTION in cpqfcTSinit.c diff -u -r --exclude-from dontdiff linux-2.4.15-pre2/drivers/scsi/gdth_proc.c linux-2.4.15-pre2-jiffies64/drivers/scsi/gdth_proc.c --- linux-2.4.15-pre2/drivers/scsi/gdth_proc.c Fri Sep 7 18:28:37 2001 +++ linux-2.4.15-pre2-jiffies64/drivers/scsi/gdth_proc.c Sun Nov 11 10:40:13 2001 @@ -1464,7 +1464,7 @@ timer_table[SCSI_TIMER].expires = jiffies + timeout; timer_active |= 1 << SCSI_TIMER; } else { - if (jiffies + timeout < timer_table[SCSI_TIMER].expires) + if (time_before(jiffies + timeout, timer_table[SCSI_TIMER].expires)) timer_table[SCSI_TIMER].expires = jiffies + timeout; } } diff -u -r --exclude-from dontdiff linux-2.4.15-pre2/drivers/scsi/mac_scsi.c linux-2.4.15-pre2-jiffies64/drivers/scsi/mac_scsi.c --- linux-2.4.15-pre2/drivers/scsi/mac_scsi.c Sun Nov 12 04:01:11 2000 +++ linux-2.4.15-pre2-jiffies64/drivers/scsi/mac_scsi.c Sun Nov 11 10:40:13 2001 @@ -353,7 +353,7 @@ NCR5380_write( INITIATOR_COMMAND_REG, ICR_BASE ); NCR5380_read( RESET_PARITY_INTERRUPT_REG ); - for( end = jiffies + AFTER_RESET_DELAY; jiffies < end; ) + for( end = jiffies + AFTER_RESET_DELAY; time_before(jiffies, end); ) barrier(); /* switch on SCSI IRQ again */ diff -u -r --exclude-from dontdiff linux-2.4.15-pre2/drivers/scsi/qlogicfas.c linux-2.4.15-pre2-jiffies64/drivers/scsi/qlogicfas.c --- linux-2.4.15-pre2/drivers/scsi/qlogicfas.c Thu Oct 25 22:53:51 2001 +++ linux-2.4.15-pre2-jiffies64/drivers/scsi/qlogicfas.c Sun Nov 11 10:40:13 2001 @@ -271,11 +271,11 @@ int i,k; k = 0; i = jiffies + WATCHDOG; - while ( i > jiffies && !qabort && !((k = inb(qbase + 4)) & 0xe0)) { + while (time_before(jiffies, i) && !qabort && !((k = inb(qbase + 4)) & 0xe0)) { barrier(); cpu_relax(); } - if (i <= jiffies) + if (time_after_eq(jiffies, i)) return (DID_TIME_OUT); if (qabort) return (qabort == 1 ? DID_ABORT : DID_RESET); @@ -405,8 +405,8 @@ } /*** Enter Status (and Message In) Phase ***/ k = jiffies + WATCHDOG; - while ( k > jiffies && !qabort && !(inb(qbase + 4) & 6)); /* wait for status phase */ - if ( k <= jiffies ) { + while ( time_before(jiffies, k) && !qabort && !(inb(qbase + 4) & 6)); /* wait for status phase */ + if ( time_after_eq(jiffies, k) ) { ql_zap(); return (DID_TIME_OUT << 16); } diff -u -r --exclude-from dontdiff linux-2.4.15-pre2/drivers/scsi/qlogicfc.c linux-2.4.15-pre2-jiffies64/drivers/scsi/qlogicfc.c --- linux-2.4.15-pre2/drivers/scsi/qlogicfc.c Thu Oct 25 22:53:51 2001 +++ linux-2.4.15-pre2-jiffies64/drivers/scsi/qlogicfc.c Sun Nov 11 10:40:13 2001 @@ -803,7 +803,7 @@ outw(HCCR_CLEAR_RISC_INTR, host->io_port + HOST_HCCR); isp2x00_enable_irqs(host); /* wait for the loop to come up */ - for (wait_time = jiffies + 10 * HZ; wait_time > jiffies && hostdata->adapter_state == AS_LOOP_DOWN;) { + for (wait_time = jiffies + 10 * HZ; time_before(jiffies, wait_time) && hostdata->adapter_state == AS_LOOP_DOWN;) { barrier(); cpu_relax(); } @@ -820,7 +820,7 @@ some time before recognizing it is attached to a fabric */ #if ISP2x00_FABRIC - for (wait_time = jiffies + 5 * HZ; wait_time > jiffies;) { + for (wait_time = jiffies + 5 * HZ; time_before(jiffies, wait_time);) { barrier(); cpu_relax(); } diff -u -r --exclude-from dontdiff linux-2.4.15-pre2/drivers/scsi/sun3_scsi.c linux-2.4.15-pre2-jiffies64/drivers/scsi/sun3_scsi.c --- linux-2.4.15-pre2/drivers/scsi/sun3_scsi.c Thu Oct 25 22:53:51 2001 +++ linux-2.4.15-pre2-jiffies64/drivers/scsi/sun3_scsi.c Sun Nov 11 10:40:13 2001 @@ -357,7 +357,7 @@ NCR5380_write( INITIATOR_COMMAND_REG, ICR_BASE ); NCR5380_read( RESET_PARITY_INTERRUPT_REG ); - for( end = jiffies + AFTER_RESET_DELAY; jiffies < end; ) + for( end = jiffies + AFTER_RESET_DELAY; time_before(jiffies, end); ) barrier(); /* switch on SCSI IRQ again */ diff -u -r --exclude-from dontdiff linux-2.4.15-pre2/drivers/scsi/sym53c416.c linux-2.4.15-pre2-jiffies64/drivers/scsi/sym53c416.c --- linux-2.4.15-pre2/drivers/scsi/sym53c416.c Sun Sep 30 21:26:07 2001 +++ linux-2.4.15-pre2-jiffies64/drivers/scsi/sym53c416.c Sun Nov 11 10:40:13 2001 @@ -277,7 +277,7 @@ { i = jiffies + timeout; restore_flags(flags); - while(jiffies < i && (inb(base + PIO_INT_REG) & EMPTY) && timeout) + while(time_before(jiffies, i) && (inb(base + PIO_INT_REG) & EMPTY) && timeout) if(inb(base + PIO_INT_REG) & SCI) timeout = 0; save_flags(flags); @@ -323,7 +323,7 @@ { i = jiffies + timeout; restore_flags(flags); - while(jiffies < i && (inb(base + PIO_INT_REG) & FULL) && timeout) + while(time_before(jiffies, i) && (inb(base + PIO_INT_REG) & FULL) && timeout) ; save_flags(flags); cli(); @@ -559,9 +559,9 @@ outb(0x00, base + DEST_BUS_ID); /* Wait for interrupt to occur */ i = jiffies + 20; - while(i > jiffies && !(inb(base + STATUS_REG) & SCI)) + while(time_before(jiffies, i) && !(inb(base + STATUS_REG) & SCI)) barrier(); - if(i <= jiffies) /* timed out */ + if(time_after_eq(jiffies, i)) /* timed out */ return 0; /* Get occurred irq */ irq = probe_irq_off(irqs); diff -u -r --exclude-from dontdiff linux-2.4.15-pre2/net/ipv4/ipconfig.c linux-2.4.15-pre2-jiffies64/net/ipv4/ipconfig.c --- linux-2.4.15-pre2/net/ipv4/ipconfig.c Sun Nov 11 10:23:42 2001 +++ linux-2.4.15-pre2-jiffies64/net/ipv4/ipconfig.c Sun Nov 11 10:40:14 2001 @@ -1009,7 +1009,7 @@ #endif jiff = jiffies + (d->next ? CONF_INTER_TIMEOUT : timeout); - while (jiffies < jiff && !ic_got_reply) { + while (time_before(jiffies, jiff) && !ic_got_reply) { barrier(); cpu_relax(); } @@ -1124,7 +1124,7 @@ try_try_again: /* Give hardware a chance to settle */ jiff = jiffies + CONF_PRE_OPEN; - while (jiffies < jiff) + while (time_before(jiffies, jiff)) ; /* Setup all network devices */ @@ -1133,7 +1133,7 @@ /* Give drivers a chance to settle */ jiff = jiffies + CONF_POST_OPEN; - while (jiffies < jiff) + while (time_before(jiffies, jiff)) ; /* From owner-netdev@oss.sgi.com Sun Nov 11 10:18:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fABIIF222150 for netdev-outgoing; Sun, 11 Nov 2001 10:18:15 -0800 Received: from ratula.moonlight.se (qmailr@c49.ryd.student.liu.se [130.236.234.49]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fABII2022147 for ; Sun, 11 Nov 2001 10:18:07 -0800 Received: (qmail 19629 invoked by uid 1000); 11 Nov 2001 17:56:44 -0000 Date: Sun, 11 Nov 2001 18:56:44 +0100 From: Carl-Johan Bostorp To: Donald Becker Cc: netdev@oss.sgi.com Subject: Re: Turning off CRC check in NIC Message-ID: <20011111185644.A32511@ratula.moonlight.se> Mail-Followup-To: Carl-Johan Bostorp , Donald Becker , netdev@oss.sgi.com References: <20011110134559.A19083@ratula.moonlight.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from becker@scyld.com on Sat, Nov 10, 2001 at 06:31:37PM -0500 Sender: owner-netdev@oss.sgi.com Precedence: bulk --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 10, 2001 at 06:31:37PM -0500, Donald Becker wrote: > > I want to turn off the CRC check on ethernet frames and pass every > > packet up to the kernel. >=20 > Why? The network I'm on is built with 3 24-port hubs in serial, who is then conn= ected to a switch. But the hubs use some kind of encryption for the packets= . Recently I was at a friends place to check out his net (same thing there)= and on his PPC with Linux, all frames were passed to the kernel. It was po= ssible to see the source MAC on the packets. The NIC was a 3Com of some sor= t. It seems some people on the net has full duplex turned on which of course r= uins performance pretty badly (ping varying between <1ms and 1000ms with pa= cket loss). The landlord who provides the connection doesn't really care, b= ut if I can view the source MAC of every packet I could view the amount of = traffic from each host and when ping suddenly starts going weird simply see= who started sending large amounts of packets. --=20 ~~~<*>~~~ Web: http://elemental.webservices.se/ ICQ: 3534707 PGP: 0xA6B5C43B IRCnet: ctor ~~~<*>~~~ --0OAP2g/MAC+5xKAE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE77rvadzh7Laa1xDsRAh+0AKDiabl7GTc/caaWD3Iw0wh0njUM8QCgmOOk 4ly5TrCarUZ3PLq6YeqX8fE= =Cb1T -----END PGP SIGNATURE----- --0OAP2g/MAC+5xKAE-- From owner-netdev@oss.sgi.com Sun Nov 11 10:19:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fABIJvg22225 for netdev-outgoing; Sun, 11 Nov 2001 10:19:57 -0800 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fABIJq022218 for ; Sun, 11 Nov 2001 10:19:52 -0800 Received: from marajade.sandelman.ottawa.on.ca ([2001:410:402:2:204:76ff:fe2d:8c]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id fABIIZc00346 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Sun, 11 Nov 2001 13:18:36 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.6/8.11.0) with ESMTP id fAALhg600585; Sat, 10 Nov 2001 16:43:47 -0500 (EST) Message-Id: <200111102143.fAALhg600585@marajade.sandelman.ottawa.on.ca> To: jleu@mindspring.com cc: design@lists.freeswan.org, netdev@oss.sgi.com Subject: Re: skb->security and friends In-reply-to: Your message of "Fri, 26 Oct 2001 10:14:37 CDT." <20011026101437.B11973@nero.doit.wisc.edu> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sat, 10 Nov 2001 16:43:41 -0500 From: Michael Richardson Sender: owner-netdev@oss.sgi.com Precedence: bulk >>>>> "James" == James R Leu writes: James> I've added a field to skbs called aux_protodata. Its an array of void*. James> Auxiliary protocols (one that don't fit the normal Linux network stack James> model) can mark interest in a particular protocol and store data here James> for later use. For example, MPLS uses this by coping data from fib_nodes James> into this field in the skb, at the same time it creates a dst_entry that James> redirect the skb to an mpls_output function. There the aux_protodata is James> used to find the next hop label forwarding entry needed to transmit this James> packet on a label switched path. This sounds precisely what IPsec wants. We need to attach some auxiliary data to the skb based upon a packet classifier, and then redirect the packet to our custom xmit routine. It sounds to me like we could very easily use the same, or similar mechanisms. (One concern is that we do not use precisely the same mechanism. After all, people will want to encrypt packets for a VPN, and then push a label on them to get them there with low latency, etc...) James> The short coming of this model so far is that it should use a netfilter like James> scheme for redirecting packets at certain points in the network stack. James> Why not use netfilter? The places that auxiliary protocols need to James> modify skbs or dst_entries are different then those provided by netfilter. I would argue that you should put netfilter calls into those places instead. James> Plus there should be a clear difference between what is being accomplished James> via netfilter (IPvX packet redirecting/mangling) and aux_protodata James> (protocol I don't think of netfilter as limited to "redirecting/mangling" --- it does classification. I'm also not clear that netfilter is limited to IPvX -- it (or rather iptables) has rather general facilities. You are, presumeable, making classification decisions on the packets in some way and sending them to MPLS processing routines. When can I expect to see your code in mainstream? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-netdev@oss.sgi.com Mon Nov 12 00:35:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAC8Zb313442 for netdev-outgoing; Mon, 12 Nov 2001 00:35:37 -0800 Received: from mail.zrz.tu-berlin.de (smtp.zrz.TU-Berlin.DE [130.149.4.15]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAC8ZX013439 for ; Mon, 12 Nov 2001 00:35:34 -0800 Received: from ftsu07.ee.tu-berlin.de ([130.149.49.87] helo=ftmail.ee.tu-berlin.de) by mail.zrz.tu-berlin.de with smtp (exim-3.33) id 163CYw-0003jj-00; Mon, 12 Nov 2001 09:35:26 +0100 Received: from cs.tu-berlin.de (tyche.ee.TU-Berlin.DE [130.149.51.32]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id fAC8ZPD09524; Mon, 12 Nov 2001 09:35:25 +0100 Message-ID: <3BEF7BD3.C6DAB8F8@cs.tu-berlin.de> Date: Mon, 12 Nov 2001 08:35:47 +0100 From: root X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-me11 i686) X-Accept-Language: en MIME-Version: 1.0 To: Alexey Kuznetsov CC: netdev@oss.sgi.com Subject: Re: IPV6_HOPOPTS References: <200111100536.IAA00423@mops.inr.ac.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi, > > Forwarded packets are not delivered to sockets. > > Apparently, you want to use Router Alert option, to reserve some ID > and to instruct a socket to grab the packets using option IPV6_ROUTER_ALERT. > I see that this is also a candidate for my purpose but as I understood IPv6 HopByHop-extension-headers they must be processed by every node (also the forwarding ) along the packets delivery path. RFC2292 provides a way of accessing these options and to add new ones to the ipv6-kernel-stack so there should be a way to get them out of the kernel-space with somekind of advanced API, maybe I'am wrong??? thanks ...axel From owner-netdev@oss.sgi.com Mon Nov 12 00:42:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAC8gmc13670 for netdev-outgoing; Mon, 12 Nov 2001 00:42:48 -0800 Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAC8gk013667 for ; Mon, 12 Nov 2001 00:42:47 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id RAA22103; Mon, 12 Nov 2001 17:39:36 +0900 To: insel@cs.tu-berlin.de Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: IPV6_HOPOPTS In-Reply-To: <3BEF7BD3.C6DAB8F8@cs.tu-berlin.de> References: <200111100536.IAA00423@mops.inr.ac.ru> <3BEF7BD3.C6DAB8F8@cs.tu-berlin.de> X-Mailer: Mew version 1.94.2 on XEmacs 21.1 (Capitol Reef) X-URL: http://www.hongo.wide.ad.jp/%7Eyoshfuji/ 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://cerberus.hongo.wide.ad.jp/%7Eyoshfuji/hideaki@yoshifuji.org.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20011112173936T.yoshfuji@wide.ad.jp> Date: Mon, 12 Nov 2001 17:39:36 +0900 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= X-Dispatcher: imput version 991025(IM133) Lines: 10 Sender: owner-netdev@oss.sgi.com Precedence: bulk In article <3BEF7BD3.C6DAB8F8@cs.tu-berlin.de> (at Mon, 12 Nov 2001 08:35:47 +0100), root says: > RFC2292 provides a way of accessing these options and to add new ones to > the ipv6-kernel-stack so there should be a way to get them out of the > kernel-space with somekind of advanced API, maybe I'am wrong??? IPV6_HOPOPTS is only for source / destination nodes. We cannot use it at intermediate nodes. --yoshfuji From owner-netdev@oss.sgi.com Mon Nov 12 02:22:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACAMmR15622 for netdev-outgoing; Mon, 12 Nov 2001 02:22:48 -0800 Received: from mail.zrz.tu-berlin.de (smtp.zrz.TU-Berlin.DE [130.149.4.15]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACAMj015619 for ; Mon, 12 Nov 2001 02:22:46 -0800 Received: from ftsu07.ee.tu-berlin.de ([130.149.49.87] helo=ftmail.ee.tu-berlin.de) by mail.zrz.tu-berlin.de with smtp (exim-3.33) id 163EEg-0006WF-00; Mon, 12 Nov 2001 11:22:38 +0100 Received: from cs.tu-berlin.de (tyche.ee.TU-Berlin.DE [130.149.51.32]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id fACAMbD13718; Mon, 12 Nov 2001 11:22:37 +0100 Message-ID: <3BEF94F2.FBF6080B@cs.tu-berlin.de> Date: Mon, 12 Nov 2001 10:22:58 +0100 From: root X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-me11 i686) X-Accept-Language: en MIME-Version: 1.0 CC: netdev@oss.sgi.com, yoshfuji@wide.ad.jp Subject: Re: IPV6_HOPOPTS References: <200111100536.IAA00423@mops.inr.ac.ru> <3BEF7BD3.C6DAB8F8@cs.tu-berlin.de> <20011112173936T.yoshfuji@wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk sorry for being so obstinate: > > RFC2292 provides a way of accessing these options and to add new ones to > > the ipv6-kernel-stack so there should be a way to get them out of the > > kernel-space with somekind of advanced API, maybe I'am wrong??? > > IPV6_HOPOPTS is only for source / destination nodes. > We cannot use it at intermediate nodes. We cannot use, not even intercept them at intermediate nodes? But why and whats the difference to IPV6_DSTOPTS then?? ... axel From owner-netdev@oss.sgi.com Mon Nov 12 03:22:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACBM1r17042 for netdev-outgoing; Mon, 12 Nov 2001 03:22:01 -0800 Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACBLv017034 for ; Mon, 12 Nov 2001 03:21:58 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id UAA22386; Mon, 12 Nov 2001 20:18:37 +0900 To: insel@cs.tu-berlin.de Cc: netdev@oss.sgi.com Subject: Re: IPV6_HOPOPTS In-Reply-To: <3BEF94F2.FBF6080B@cs.tu-berlin.de> References: <3BEF7BD3.C6DAB8F8@cs.tu-berlin.de> <20011112173936T.yoshfuji@wide.ad.jp> <3BEF94F2.FBF6080B@cs.tu-berlin.de> X-Mailer: Mew version 1.94.2 on XEmacs 21.1 (Capitol Reef) X-URL: http://www.hongo.wide.ad.jp/%7Eyoshfuji/ 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://cerberus.hongo.wide.ad.jp/%7Eyoshfuji/hideaki@yoshifuji.org.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20011112201837D.yoshfuji@linux-ipv6.org> Date: Mon, 12 Nov 2001 20:18:37 +0900 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= X-Dispatcher: imput version 991025(IM133) Lines: 27 Sender: owner-netdev@oss.sgi.com Precedence: bulk In article <3BEF94F2.FBF6080B@cs.tu-berlin.de> (at Mon, 12 Nov 2001 10:22:58 +0100), root says: > > > RFC2292 provides a way of accessing these options and to add new ones to > > > the ipv6-kernel-stack so there should be a way to get them out of the > > > kernel-space with somekind of advanced API, maybe I'am wrong??? > > > > IPV6_HOPOPTS is only for source / destination nodes. > > We cannot use it at intermediate nodes. > We cannot use, not even intercept them at intermediate nodes? > > But why and whats the difference to IPV6_DSTOPTS then?? Userland code (/ kernel) of source node can generate hbh / dst option(s). (userland code uses advanced API for this.) Kernels of intermediate and destination nodes handle hbh option(s), but userland code of intermediate destination nodes can NOT receive dst / hbh option(s) via the advanced API such as IPV6_{HOP,DEST}OPTS. Kernels of final destination node handles dst option(s), and also userland code of final destination node can receive dst / hbh option(s) via the advanced API. Note: Kernel of two or more nodes may act as destination if you use routing header. --yoshfuji From owner-netdev@oss.sgi.com Mon Nov 12 03:25:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACBPZx17157 for netdev-outgoing; Mon, 12 Nov 2001 03:25:35 -0800 Received: from mout04.kundenserver.de (mout04.kundenserver.de [195.20.224.89]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACBPW017154 for ; Mon, 12 Nov 2001 03:25:32 -0800 Received: from [195.20.224.219] (helo=mrvdom03.schlund.de) by mout04.kundenserver.de with esmtp (Exim 2.12 #2) id 163FDW-0001d7-00 for netdev@oss.sgi.com; Mon, 12 Nov 2001 12:25:30 +0100 Received: from pd950632c.dip0.t-ipconnect.de ([217.80.99.44] helo=student.uni-ulm.de) by mrvdom03.schlund.de with esmtp (Exim 2.12 #2) id 163FDW-0006xP-00 for netdev@oss.sgi.com; Mon, 12 Nov 2001 12:25:30 +0100 Message-ID: <3BEFB1BA.C71EC25D@student.uni-ulm.de> Date: Mon, 12 Nov 2001 12:25:46 +0100 From: =?iso-8859-15?Q?J=FCrgen?= Nagler X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.7-4GB i586) X-Accept-Language: de, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: IPV6_HOPOPTS References: <200111100536.IAA00423@mops.inr.ac.ru> <3BEF7BD3.C6DAB8F8@cs.tu-berlin.de> <20011112173936T.yoshfuji@wide.ad.jp> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-netdev@oss.sgi.com Precedence: bulk YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > > In article <3BEF7BD3.C6DAB8F8@cs.tu-berlin.de> (at Mon, 12 Nov 2001 08:35:47 +0100), root says: > > > RFC2292 provides a way of accessing these options and to add new ones to > > the ipv6-kernel-stack so there should be a way to get them out of the > > kernel-space with somekind of advanced API, maybe I'am wrong??? > > IPV6_HOPOPTS is only for source / destination nodes. > We cannot use it at intermediate nodes. RFC 1883 IPv6 Specification December 1995 4.3 Hop-by-Hop Options Header The Hop-by-Hop Options header is used to carry optional information that must be examined by every node along a packet's delivery path. The Hop-by-Hop Options header is identified by a Next Header value of 0 in the IPv6 header, and has the following format: ... Regards, Jürgen From owner-netdev@oss.sgi.com Mon Nov 12 09:02:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACH2I531547 for netdev-outgoing; Mon, 12 Nov 2001 09:02:18 -0800 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACH2E031544 for ; Mon, 12 Nov 2001 09:02:14 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id TAA12313; Mon, 12 Nov 2001 19:58:24 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200111121658.TAA12313@ms2.inr.ac.ru> Subject: Re: IPV6_HOPOPTS To: insel@cs.tu-berlin.de (root) Date: Mon, 12 Nov 2001 19:58:24 +0300 (MSK) Cc: netdev@oss.sgi.com In-Reply-To: <3BEF7BD3.C6DAB8F8@cs.tu-berlin.de> from "root" at Nov 12, 1 08:35:47 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello! > kernel-space with somekind of advanced API, maybe I'am wrong??? You are. Only router alert can withdraw packet from forwarding path. Alexey From owner-netdev@oss.sgi.com Tue Nov 13 18:00:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAE20Su32227 for netdev-outgoing; Tue, 13 Nov 2001 18:00:28 -0800 Received: from whatever.local ([65.10.228.207]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAE20R032224 for ; Tue, 13 Nov 2001 18:00:27 -0800 Received: (qmail 3094 invoked by uid 513); 14 Nov 2001 02:05:25 -0000 From: chuckw@ieee.org Date: Tue, 13 Nov 2001 21:05:25 -0500 To: netdev@oss.sgi.com Subject: dst_entry & rtable in 2.2.12 Message-ID: <20011113210525.B2841@ieee.org> Mail-Followup-To: netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-netdev@oss.sgi.com Precedence: bulk I am going through the code in 2.2.12 and I am having a little difficulty trying to figure out why and how in the routing code struct dst_entry is consistently casted to a struct rtable. I checked out their definitions and they don't match up. Thanks in advance, Chuck From owner-netdev@oss.sgi.com Tue Nov 13 18:23:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAE2NB432677 for netdev-outgoing; Tue, 13 Nov 2001 18:23:11 -0800 Received: from whatever.local ([65.10.228.207]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAE2N6032673 for ; Tue, 13 Nov 2001 18:23:07 -0800 Received: (qmail 3127 invoked by uid 513); 14 Nov 2001 02:28:05 -0000 From: chuckw@ieee.org Date: Tue, 13 Nov 2001 21:28:05 -0500 To: netdev@oss.sgi.com Subject: Re: Turning off CRC check in NIC Message-ID: <20011113212805.C2841@ieee.org> Mail-Followup-To: netdev@oss.sgi.com References: <20011110134559.A19083@ratula.moonlight.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011110134559.A19083@ratula.moonlight.se>; from ctor@ratula.moonlight.se.sgi.com on Sat, Nov 10, 2001 at 01:45:59PM +0100 Sender: owner-netdev@oss.sgi.com Precedence: bulk On Sat, Nov 10, 2001 at 01:45:59PM +0100, Carl-Johan Bostorp wrote: > Hello, > > I want to turn off the CRC check on ethernet frames and pass every packet up to the kernel. I have an eepro100, so I mailed Intel about it and asked for specs. The reply I got was that the kernel may actually rely on the NIC doing this check. > > So, what's the deal? What effects will there be if the NIC starts passing everything up to the kernel? > > > -- > ~~~<*>~~~ > > Web: http://elemental.webservices.se/ ICQ: 3534707 > PGP: 0xA6B5C43B IRCnet: ctor > > ~~~<*>~~~ I would think there would be many problems with this. One being that the protocol field may be mangled, then the kernel wouldn't know what to do with the packet. Chuck From owner-netdev@oss.sgi.com Tue Nov 13 19:17:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAE3HAo01260 for netdev-outgoing; Tue, 13 Nov 2001 19:17:10 -0800 Received: from grok.yi.org (IDENT:qPWIY30xBkb8oMcoNvBf41Y43UE1P8Wh@cx97923-a.phnx3.az.home.com [24.9.112.194] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAE3H5001255 for ; Tue, 13 Nov 2001 19:17:05 -0800 Received: from candelatech.com (IDENT:g1zvOCRDv8IdvqA3ITJcCGxJKE4LEEaG@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id fAE3H1l21662; Tue, 13 Nov 2001 20:17:02 -0700 Message-ID: <3BF1E22D.30400@candelatech.com> Date: Tue, 13 Nov 2001 20:17:01 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: chuckw@ieee.org CC: netdev@oss.sgi.com Subject: Re: Turning off CRC check in NIC References: <20011110134559.A19083@ratula.moonlight.se> <20011113212805.C2841@ieee.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk chuckw@ieee.org wrote: > On Sat, Nov 10, 2001 at 01:45:59PM +0100, Carl-Johan Bostorp wrote: > >>Hello, >> >>I want to turn off the CRC check on ethernet frames and pass every packet up to the kernel. I have an eepro100, so I mailed Intel about it and asked for specs. The reply I got was that the kernel may actually rely on the NIC doing this check. >> >>So, what's the deal? What effects will there be if the NIC starts passing everything up to the kernel? >> >> >>-- >>~~~<*>~~~ >> >>Web: http://elemental.webservices.se/ ICQ: 3534707 >>PGP: 0xA6B5C43B IRCnet: ctor >> >>~~~<*>~~~ >> > > I would think there would be many problems with this. One being > that the protocol field may be mangled, then the kernel wouldn't > know what to do with the packet. So the kernel drops it if that is the case, and you are no worse off than before (not counting processing time). No protocol should ever assume it will not be sent shitty packets of every imaginable type: the protocols must be able to handle such things gracefully, though they can surely toss the packet away or otherwise ignore it... Enjoy, Ben > > Chuck > > -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From owner-netdev@oss.sgi.com Wed Nov 14 07:35:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAEFZcB31922 for netdev-outgoing; Wed, 14 Nov 2001 07:35:38 -0800 Received: from unicorn.sch.bme.hu (mail@unicorn.sch.bme.hu [152.66.208.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAEFZZ031905 for ; Wed, 14 Nov 2001 07:35:35 -0800 Received: from cell by unicorn.sch.bme.hu with local (Exim 3.32 #1 (Debian)) id 16424b-00008j-00 for ; Wed, 14 Nov 2001 16:35:33 +0100 Date: Wed, 14 Nov 2001 16:35:33 +0100 To: netdev@oss.sgi.com Subject: SMC 9432 problem - epic100.c Message-ID: <20011114163533.A32700@unicorn.sch.bme.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i From: Gal Marcell Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi Guys, I'm having problems with SMC 9432 card under linux 2.4 (the card in the same machine is working with win9x and it also worked in earlier kernels (at least I was told) 11:08:52 fefo2 kernel: eth0: Transmit timeout using MII device, Tx status 4008. Nov 14 11:08:56 fefo2 kernel: NETDEV WATCHDOG: eth0: transmit timed out Nov 14 11:08:56 fefo2 kernel: eth0: Transmit timeout using MII device, Tx status 0008. Nov 14 11:09:00 fefo2 kernel: NETDEV WATCHDOG: eth0: transmit timed out the same happens weather in module or compiled in. (UP kernel, UP machine) more info: (.config, procpci, messagez.gz, diag-aa...) http://home.sch.bme.hu/~cell/epic100/ Is there any hope? Thanx: Marcell ZZ From owner-netdev@oss.sgi.com Wed Nov 14 11:03:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAEJ3sO32017 for netdev-outgoing; Wed, 14 Nov 2001 11:03:54 -0800 Received: from marraco.udl.es (gardeny.udl.es [193.144.12.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAEJ3n032014 for ; Wed, 14 Nov 2001 11:03:49 -0800 Received: from eup.udl.es (fermat.udl.net [10.50.54.28]) by marraco.udl.es (8.9.3/8.8.5) with ESMTP id SAA16308 for ; Wed, 14 Nov 2001 18:49:48 +0100 From: f1802782@alumnes.eup.udl.es Received: from alumnes.eup.udl.es by eup.udl.es (8.8.8+Sun/SMI-SVR4) id TAA25263; Wed, 14 Nov 2001 19:37:34 +0100 (MET) Received: from 0 (jupiter [172.16.2.2]) by alumnes.eup.udl.es (8.9.3+Sun/8.9.3) with ESMTP id TAA07193 for ; Wed, 14 Nov 2001 19:37:34 +0100 (MET) Message-Id: <200111141837.TAA07193@alumnes.eup.udl.es> Content-Transfer-Encoding: 8bit To: netdev@oss.sgi.com User-Agent: IMHO/0.98 (Webmail for Roxen) Date: Wed, 14 Nov 2001 19:37:34 +0100 Subject: the obscure net implementation Content-Type: text/plain; charset=iso-8859-1 MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi, Im a student from Spain thats beggining linux network hackery. Im have the hard task of start learning from kernel version 2.2.x in advance. But I've started to search the web looking for a description of the data structures and operations involved in communication process, and im not succeed. These manuals (if exits) will help me in my learning. When i mailed Alan Cox, he gave me this e-address, and I hope you can help me if you want, of course. Do you have any manual that explains my doubts? Can you tell me where are they? Im working about net statistics in pvm-process communication. I ve yet many documentation about pvm, but the net structs and buffers in kernel (like Qdisc, for example) and how kernel manages this structures is a black hole for me. Regards and thanks in advance, and hope you understand me (and my poor english)! --------------------- Javier Mendiara Cañardo Escola universitaria politecnica - http://www.eup.udl.es Universidad de Lleida - http://www.udl.es Lerida - Spain mailto:jmendiara@alumnes.udl.es or mailto:f1802782@alumnes.eup.udl.es From owner-netdev@oss.sgi.com Wed Nov 14 11:36:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAEJafX00323 for netdev-outgoing; Wed, 14 Nov 2001 11:36:41 -0800 Received: from enterprise.atl.lmco.com (mail.atl.external.lmco.com [192.35.37.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAEJab000319 for ; Wed, 14 Nov 2001 11:36:37 -0800 Received: from audubon.atl.lmco.com (audubon [166.17.242.190]) by enterprise.atl.lmco.com (Postfix) with ESMTP id 5FB85C1CD5 for ; Wed, 14 Nov 2001 14:36:04 -0500 (EST) Received: (from cwinters@localhost) by audubon.atl.lmco.com (8.11.2/8.11.2) id fAEJa4914003 for netdev@oss.sgi.com; Wed, 14 Nov 2001 14:36:04 -0500 Date: Wed, 14 Nov 2001 14:36:04 -0500 From: Chuck Winters To: netdev@oss.sgi.com Subject: Re: the obscure net implementation Message-ID: <20011114143604.A13999@atl.lmco.com> Mail-Followup-To: netdev@oss.sgi.com References: <200111141837.TAA07193@alumnes.eup.udl.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200111141837.TAA07193@alumnes.eup.udl.es> User-Agent: Mutt/1.3.23i Sender: owner-netdev@oss.sgi.com Precedence: bulk On Wed, Nov 14, 2001 at 07:37:34PM +0100, f1802782@alumnes.eup.udl.es wrote: > Hi, > Im a student from Spain thats beggining linux network hackery. Im have > the hard task of start learning from kernel version 2.2.x in advance. > But I've started to search the web looking for a description of the > data structures and operations involved in communication process, and > im not succeed. These manuals (if exits) will help me in my learning. > When i mailed Alan Cox, he gave me this e-address, and I hope you can > help me if you want, of course. Do you have any manual that explains > my doubts? Can you tell me where are they? > > Im working about net statistics in pvm-process communication. I ve yet > many documentation about pvm, but the net structs and buffers in > kernel (like Qdisc, for example) and how kernel manages this > structures is a black hole for me. > > Regards and thanks in advance, and hope you understand me (and my poor > english)! > > --------------------- > Javier Mendiara Ca?ardo > Escola universitaria politecnica - http://www.eup.udl.es > Universidad de Lleida - http://www.udl.es > Lerida - Spain > > mailto:jmendiara@alumnes.udl.es > or > mailto:f1802782@alumnes.eup.udl.es Try this link. http://www.kernelnewbies.org Chuck From owner-netdev@oss.sgi.com Wed Nov 14 11:49:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAEJnra02777 for netdev-outgoing; Wed, 14 Nov 2001 11:49:53 -0800 Received: from astrid2.nic.fr (astrid2.nic.fr [192.134.4.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAEJno002774 for ; Wed, 14 Nov 2001 11:49:50 -0800 Received: from noir.nic.fr (IDENT:root@noir.nic.fr [192.134.4.89]) by astrid2.nic.fr (8.9.1/jtpda-5.3.1) with ESMTP id UAA28830 ; Wed, 14 Nov 2001 20:49:47 +0100 (MET) Received: (from romieu@localhost) by noir.nic.fr (8.12.0.Beta7/8.9.3) id fAEJnlfX002631; Wed, 14 Nov 2001 20:49:47 +0100 Date: Wed, 14 Nov 2001 20:49:47 +0100 From: Francois romieu To: Gal Marcell Cc: netdev@oss.sgi.com Subject: Re: SMC 9432 problem - epic100.c Message-ID: <20011114204947.A2594@nic.fr> Reply-To: Francois romieu References: <20011114163533.A32700@unicorn.sch.bme.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011114163533.A32700@unicorn.sch.bme.hu>; from cell@unicorn.sch.bme.hu on Wed, Nov 14, 2001 at 04:35:33PM +0100 X-Organisation: Marie's fan club - II Sender: owner-netdev@oss.sgi.com Precedence: bulk The Wed, Nov 14, 2001 at 04:35:33PM +0100, Gal Marcell wrote : [epic100 failure] > 11:08:52 fefo2 kernel: eth0: Transmit timeout using MII device, Tx status 4008. > Nov 14 11:08:56 fefo2 kernel: NETDEV WATCHDOG: eth0: transmit timed out > Nov 14 11:08:56 fefo2 kernel: eth0: Transmit timeout using MII device, Tx status 0008. > Nov 14 11:09:00 fefo2 kernel: NETDEV WATCHDOG: eth0: transmit timed out [...] printk(KERN_WARNING "%s: Transmit timeout using MII device, " "Tx status %4.4x.\n", dev->name, (int)inw(ioaddr + TxSTAT)); [...] enum epic_registers { ... RxCtrl=96, TxCtrl=112, TxSTAT=0x74 My 83c171 datasheet says on page 55 that bits 31 to 13 are unused. Oops... Could you compile a recent 2.4.x kernel and see if the problem persists ? If it does, please include an output with debug=8 (any high value). Avoid gcc 2.95.2, it's known to miscompile this driver (and probably some others where I did the dma mapping api changes). -- Ueimor From owner-netdev@oss.sgi.com Thu Nov 15 07:11:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAFFBQG14921 for netdev-outgoing; Thu, 15 Nov 2001 07:11:26 -0800 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAFFBO014917 for ; Thu, 15 Nov 2001 07:11:24 -0800 Received: from localhost (IDENT:davem@pizda.ninka.net [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id HAA02218; Thu, 15 Nov 2001 07:11:05 -0800 Date: Thu, 15 Nov 2001 07:11:05 -0800 (PST) Message-Id: <20011115.071105.45157375.davem@redhat.com> To: summer@os2.ami.com.au Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: BOOTP and 2.4.14 From: "David S. Miller" In-Reply-To: <200111150629.fAF6SKg20602@numbat.os2.ami.com.au> References: <200111150629.fAF6SKg20602@numbat.os2.ami.com.au> X-Mailer: Mew version 2.0 on Emacs 21.0 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Set your kernel command line correctly, the format is: HOSTNAME.NIS_DOMAINNAME It has been like this since ancient times :-) From owner-netdev@oss.sgi.com Thu Nov 15 11:25:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAFJPwf23213 for netdev-outgoing; Thu, 15 Nov 2001 11:25:58 -0800 Received: from amdext.amd.com (amdext.amd.com [139.95.251.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAFJPv023210 for ; Thu, 15 Nov 2001 11:25:57 -0800 Received: from ssvlgs01.amd.com (ssvlgs01.amd.com [139.95.250.16]) by amdext.amd.com (8.9.3/8.9.3/AMD) with SMTP id LAA14793 for ; Thu, 15 Nov 2001 11:25:52 -0800 (PST) From: harish.vasudeva@amd.com Received: from 139.95.250.1 by ssvlgs01.amd.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.7)); Thu, 15 Nov 2001 11:25:51 -0800 X-Server-Uuid: 02753650-11b0-11d5-bbc5-00508bf987eb Received: from caexmta9.amd.com (caexmta9.amd.com [139.95.53.55]) by amdint.amd.com (8.9.3/8.9.3/AMD) with ESMTP id LAA25807 for ; Thu, 15 Nov 2001 11:25:51 -0800 (PST) Received: by caexmta9.amd.com with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Nov 2001 11:25:50 -0800 Message-ID: To: netdev@oss.sgi.com Subject: info on checksum offloading Date: Thu, 15 Nov 2001 11:25:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 17EAC93519638-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi All, Could any1 pls direct me wherein i could find some documentation about implementing checksum offloading for my ethernet LAN driver? thanx HARISH V From owner-netdev@oss.sgi.com Fri Nov 16 00:20:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAG8KEM20532 for netdev-outgoing; Fri, 16 Nov 2001 00:20:14 -0800 Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAG8K0020526 for ; Fri, 16 Nov 2001 00:20:00 -0800 Received: from zip.com.au (root@zipperii.zip.com.au [61.8.0.87]) by vasquez.zip.com.au (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id TAA21880; Fri, 16 Nov 2001 19:19:56 +1100 X-Authentication-Warning: vasquez.zip.com.au: Host root@zipperii.zip.com.au [61.8.0.87] claimed to be zip.com.au Message-ID: <3BF4CC10.118391C6@zip.com.au> Date: Fri, 16 Nov 2001 00:19:28 -0800 From: Andrew Morton X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.14-pre8 i686) X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com CC: =?iso-8859-1?Q?Fran=E7ois?= Cami Subject: [Fwd: 3C905x - too much work in interrupt, follow-up] Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by vasquez.zip.com.au id TAA21880 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id fAG8K1020529 Sender: owner-netdev@oss.sgi.com Precedence: bulk Some statistics here on how frequently the 3com driver exceeds its maximum-work-in-interrupt limit in a real environment. I found it interesting. There appears to be no substantial difference beteen 2.2 and 2.4 either. -------- Original Message -------- Subject: 3C905x - too much work in interrupt, follow-up Date: Fri, 16 Nov 2001 09:12:39 +0100 From: François Cami To: Andrew Morton CC: linux-kernel@vger.kernel.org References: <3BF4BD81.C3E4A4DC@zip.com.au> Hi Andrew ! Here are the promised stats (I'm sorry it took so long): testing procedure : each PC was rebooted at midnight on sundays, and data was collected for 4 days and then averaged. Network : 700 networked PCs, running different windows versions or linux, usually with 10MBits/s boards, some with 100MB. Network is partially switched with 3COM 1100s and 3300s ; fiber network (100MB/s I think [not too sure 'bout that]) between two stacks. Machine 1 ASUS P2B-DS / Dual PII350 / 512MB RAM / 3*18GB 10KT IBM / 3C905C [it got an upgrade] ; distro is slackware 8, kernel 2.2.19 serves as a proxy server running squid. Normal network load during the day is around 30MBits/s or so ; the machine transfers 1GB of data daily, which is not too much i think. the PC uses IO-APIC. cat /proc/interrupts always shows that the NIC pushes 3-10 times more interrupts than the timer. aic7xxx pushes 10 times less interrupts than the NIC. ifconfig shows that RX is 7 times less that TX max_interrupt_work set to 20 : eth0 : too much work in interrupt appears 21 times a day max_interrupt_work set to 32 : eth0 : too much work in interrupt appears 8 times a day max_interrupt_work set to 64 : eth0 : too much work in interrupt appears around 2 times a day max_interrupt_work set to 128 : eth0 : too much work in interrupt never appears in the log. Machine 2 ABIT LX6 / PII300 / 128MB RAM / 3C905C hard drives [all ide] : IBM 8GB as hda Maxtor 80GB 5400T as hdb Maxtor 60GB 5400T as hdc distro is slackware 8, kernel 2.4.4 serves as an ftp server running proftpd ; sometimes uses samba to send data to a W2K-server. Normal network load is 500MByte per day for RX, and the same for TX. max_interrupt_work set to 20 : eth0 : too much work in interrupt appears 17 times a day max_interrupt_work set to 32 : eth0 : too much work in interrupt appears 7 times a day max_interrupt_work set to 64 : eth0 : too much work in interrupt appears around 2 times a day max_interrupt_work set to 128 : eth0 : too much work in interrupt never appears in the log. Machine 3 ABIT BH6 / PII400 / 128MB RAM / 3C905C / Tekram DC-390F hard drives : IBM 9GB as sda IBM 4GB as sdb distro is slackware 8, kernel 2.2.19 tested as a proxy server instead of the dual PII350 max_interrupt_work set to 20 : eth0 : too much work in interrupt appears 5 times a day max_interrupt_work set to 32 : eth0 : too much work in interrupt appears 4 times a day max_interrupt_work set to 64 : eth0 : too much work in interrupt never appears in the log. I hope that helps... keep me informed, please. François Cami Andrew Morton wrote [20 April 2001]: > > Vibol Hou wrote: > ... > > > Apr 17 16:10:12 omega kernel: eth0: Too much work in interrupt, status e401. > > I got that one too, PC is ASUS P2B-DS with two PII-350, 384MB RAM, > 3C905B. If you were getting this message occasionally, and if increasing the max_interrupt_work module parm makes it stop, and everything is always working fine, then it's an OK thing to do. Question is: why is it happening? We're failing to get out of the interrupt loop after 32 loops. Each loop can reap up to 16 transmitted packets and 32 received packets. That's a lot. My suspicion is that something else in the system is causing the NIC interrupt routine to get held up for long periods of time. It has to be another interrupt. All reporters of this problem (ie: both of them) were using aic7xx SCSI. I wonder if that driver can sometimes spend a long time in its interrupt routine. Many times. Rapidly. Very odd. Ah. SMP. Perhaps the other CPU is generating the transmit load, some other interrupt source is slowing down *this* CPU. Could you test something for me? Try *decreasing* the value of max_interrupt_work. See if that increases the frequency of the message. Then, it if does, try to correlate the occurence of the message with some other form of system activity (especially disk I/O). Thanks. From owner-netdev@oss.sgi.com Fri Nov 16 00:59:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAG8xVK21239 for netdev-outgoing; Fri, 16 Nov 2001 00:59:31 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAG8xQ021235 for ; Fri, 16 Nov 2001 00:59:26 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fAG8xPq28381 for netdev@oss.sgi.com; Fri, 16 Nov 2001 19:59:25 +1100 Received: from netsrvr.ami.com.au (netsrvr.ami.com.au [203.55.31.38]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAFFlH015967 for ; Thu, 15 Nov 2001 07:47:20 -0800 Received: from dugite.os2.ami.com.au (c0s11.ami.com.au [203.55.31.76]) by netsrvr.ami.com.au (8.11.2/8.11.2) with ESMTP id fAFFkKg08502; Thu, 15 Nov 2001 23:46:20 +0800 Received: from numbat.os2.ami.com.au (numbat.os2.ami.com.au [192.168.1.9]) by dugite.os2.ami.com.au (8.11.6/8.11.2) with ESMTP id fAFFkFH13613; Thu, 15 Nov 2001 23:46:15 +0800 Received: from numbat.os2.ami.com.au (summer@localhost) by numbat.os2.ami.com.au (8.11.6/8.11.2) with ESMTP id fAF6SKg20602; Thu, 15 Nov 2001 14:29:00 +0800 Message-Id: <200111150629.fAF6SKg20602@numbat.os2.ami.com.au> X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 To: Linux kernel , netdev@oss.sgi.com cc: davem@redhat.com Subject: BOOTP and 2.4.14 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Nov 2001 14:28:19 +0800 From: summer@os2.ami.com.au Sender: owner-netdev@oss.sgi.com Precedence: bulk I'm trying to configure a system to boot with root on NFS. I have it working, but there are problems. The most serious are that the DNS domain name is set wrongly, and NIS domain's not set at all. The IP address offered and accepted in 192.168.1.20. The DNS domain name being set is 168.1.20, and the host name 192. I'm looking at the ipconfig.c source, around line 1324 where I see this code: case 4: if ((dp = strchr(ip, '.'))) { *dp++ = '\0'; strncpy(system_utsname.domainname, dp, __NEW_UTS_LEN); system_utsname.domainname[__NEW_UTS_LEN] = '\0'; } strncpy(system_utsname.nodename, ip, __NEW_UTS_LEN); system_utsname.nodename[__NEW_UTS_LEN] = '\0'; ic_host_name_set = 1; break; I can see how the dnsdomain name's being set, and it does not look right to me. If someone can prepare a patch for me, I'll be delighted to test it. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. From owner-netdev@oss.sgi.com Fri Nov 16 00:59:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAG8xgV21313 for netdev-outgoing; Fri, 16 Nov 2001 00:59:42 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAG8xb021293 for ; Fri, 16 Nov 2001 00:59:37 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fAG8xat28385 for netdev@oss.sgi.com; Fri, 16 Nov 2001 19:59:36 +1100 Received: from netsrvr.ami.com.au (netsrvr.ami.com.au [203.55.31.38]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAFJlW023818 for ; Thu, 15 Nov 2001 11:47:32 -0800 Received: from dugite.os2.ami.com.au (c0s11.ami.com.au [203.55.31.76]) by netsrvr.ami.com.au (8.11.2/8.11.2) with ESMTP id fAFJkag11426; Fri, 16 Nov 2001 03:46:43 +0800 Received: from numbat.os2.ami.com.au (numbat.os2.ami.com.au [192.168.1.9]) by dugite.os2.ami.com.au (8.11.6/8.11.2) with ESMTP id fAFJkFH21768; Fri, 16 Nov 2001 03:46:15 +0800 Received: from numbat.os2.ami.com.au (summer@localhost) by numbat.os2.ami.com.au (8.11.6/8.11.2) with ESMTP id fAFJ14x07788; Fri, 16 Nov 2001 03:01:05 +0800 Message-Id: <200111151901.fAFJ14x07788@numbat.os2.ami.com.au> X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 To: "David S. Miller" cc: summer@os2.ami.com.au, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, summer@numbat.os2.ami.com.au.sgi.com Subject: Re: BOOTP and 2.4.14 In-Reply-To: Message from "David S. Miller" of "Thu, 15 Nov 2001 07:11:05 PST." <20011115.071105.45157375.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Nov 2001 03:01:04 +0800 From: summer@os2.ami.com.au Sender: owner-netdev@oss.sgi.com Precedence: bulk > > Set your kernel command line correctly, the format is: > > HOSTNAME.NIS_DOMAINNAME > > It has been like this since ancient times :-) > I don't understand. According to nfsroot.txt all I need is this: [root@numbat root]# cat /misc/fd0/syslinux.cfg default linux prompt 1 timeout 1 label linux kernel vmlinuz append root=/dev/nfs ip=bootp initrd=initial.dsk [root@numbat root]# The kernel messages say it's got the domain name, but by the time it gets to init (I altered /etc/rc.d/rc.sysinit to see) it's using the IP address for host/domain names, and that's what I see in the code I cited. The nis domain's not being set, but I've not established the kernel's at failt. According to the debugging code which I've enabled, it's seeing extensions 1, 3, 6, 55, 45, 46 and 15. 1 looks like the netmask, 3, 6, 44 and 45 are all the IP address of the server (it does several things so that's probably okay), 46 has the value 08 and 15 is the DNS domain name. The client's IP address isn't reported by the debugging code, but is set to the value I expect. I see the extensions are parsed in ic_do_bootp_ext which silently ignores 44, 45 & 46. Here are some kernel messages from booting the client: Nov 16 02:46:51 192 kernel: IP-Config: Entered. Nov 16 02:46:52 192 kernel: IP-Config: eth0 UP (able=1, xid=46e93477) Nov 16 02:46:52 192 kernel: Sending BOOTP requests .DHCP/BOOTP: Got extension 1: ff ff ff 00 Nov 16 02:46:52 192 kernel: DHCP/BOOTP: Got extension 3: c0 a8 01 01 Nov 16 02:46:52 192 kernel: DHCP/BOOTP: Got extension 6: c0 a8 01 01 Nov 16 02:46:52 192 kernel: DHCP/BOOTP: Got extension 44: c0 a8 01 01 Nov 16 02:46:52 192 kernel: DHCP/BOOTP: Got extension 45: c0 a8 01 01 Nov 16 02:46:52 192 kernel: DHCP/BOOTP: Got extension 46: 08 Nov 16 02:46:52 192 kernel: DHCP/BOOTP: Got extension 15: 4f 73 32 2e 41 6d 69 2e 43 6f 6d 2e 41 75 Nov 16 02:46:52 192 kernel: OK Nov 16 02:46:52 192 kernel: IP-Config: Got BOOTP answer from 192.168.1.1, my address is 192.168.1.20 Nov 16 02:46:52 192 kernel: IP-Config: Complete: Nov 16 02:46:52 192 kernel: device=eth0, addr=192.168.1.20, mask=255.255.255.0, gw=192.168.1.1, Nov 16 02:46:52 192 kernel: host=192.168.1.20, domain=Os2.Ami.Com.Au, nis-domain=(none), Nov 16 02:46:52 192 kernel: bootserver=192.168.1.1, rootserver=192.168.1.1, rootpath= By the time init passes control to ins initialisation script, the hostname command reports 192 and dnsdomainname reports 168.0.1. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. From owner-netdev@oss.sgi.com Mon Nov 19 10:11:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAJIBL212464 for netdev-outgoing; Mon, 19 Nov 2001 10:11:21 -0800 Received: from amsfep14-int.chello.nl (amsfep14-int.chello.nl [213.46.243.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAJIBEW12458 for ; Mon, 19 Nov 2001 10:11:16 -0800 Received: from mail.brabant.chello.nl ([212.83.83.7]) by amsfep14-int.chello.nl (InterMail vM.5.01.03.06 201-253-122-118-106-20010523) with SMTP id <20011119171107.ZKUT1203.amsfep14-int.chello.nl@mail.brabant.chello.nl>; Mon, 19 Nov 2001 18:11:07 +0100 Date: Mon, 19 Nov 2001 18:11:06 +0100 From: Jeroen Vreeken To: linux-kernel@vger.kernel.org Cc: linux-hams , netdev@oss.sgi.com Subject: [PATCH] bug in sock.c Message-ID: <20011119181106.A604@jeroen.pe1rxq.ampr.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="AWniW0JNca5xppdA" Content-Transfer-Encoding: 8bit X-Mailer: Balsa 1.1.0 Lines: 39 Sender: owner-netdev@oss.sgi.com Precedence: bulk --AWniW0JNca5xppdA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hi, I finally found the reason ax25 was causing oopses on several systems with 2.4.x kernels. It was caused by a missing check for sk->dead in sock_def_write_space. The attached patch solved my problems. Jeroen --AWniW0JNca5xppdA Content-Type: application/octet-stream; charset=us-ascii Content-Disposition: attachment; filename="sock.c.diff" --- linux-2.4.13/net/core/sock.c Fri Nov 15 21:12:38 2001 +++ linux/net/core/sock.c Fri Nov 16 20:53:55 2001 @@ -81,6 +81,7 @@ * Andi Kleen : Fix write_space callback * Chris Evans : Security fixes - signedness again * Arnaldo C. Melo : cleanups, use skb_queue_purge + * Jeroen Vreeken : Add check for sk->dead in sock_def_write_space * * To Fix: * @@ -1130,7 +1131,7 @@ /* Do not wake up a writer until he can make "significant" * progress. --DaveM */ - if((atomic_read(&sk->wmem_alloc) << 1) <= sk->sndbuf) { + if(!sk->dead && (atomic_read(&sk->wmem_alloc) << 1) <= sk->sndbuf) { if (sk->sleep && waitqueue_active(sk->sleep)) wake_up_interruptible(sk->sleep); --AWniW0JNca5xppdA-- From owner-netdev@oss.sgi.com Thu Nov 22 05:36:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAMDaaB10477 for netdev-outgoing; Thu, 22 Nov 2001 05:36:36 -0800 Received: from hotmail.com (f188.pav2.hotmail.com [64.4.37.188]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAMDaWo10467 for ; Thu, 22 Nov 2001 05:36:32 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 22 Nov 2001 04:36:24 -0800 Received: from 211.191.219.75 by pv2fd.pav2.hotmail.msn.com with HTTP; Thu, 22 Nov 2001 12:36:23 GMT X-Originating-IP: [211.191.219.75] From: "Sung-jae. Lee." To: netdev@oss.sgi.com Subject: Hi~ I have stupid question. :) Date: Thu, 22 Nov 2001 21:36:23 +0900 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Nov 2001 12:36:24.0420 (UTC) FILETIME=[4C176A40:01C17352] Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 227 Lines: 8 How can I build dual stack kernel that can send IPv4 and IPv6 packets? thanks. :) _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-netdev@oss.sgi.com Thu Nov 22 08:06:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAMG6Zc15910 for netdev-outgoing; Thu, 22 Nov 2001 08:06:35 -0800 Received: from netbank.com.br (IDENT:postfix@garrincha.netbank.com.br [200.203.199.88]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAMG6Vo15901 for ; Thu, 22 Nov 2001 08:06:32 -0800 Received: from brinquedo.distro.conectiva (4-006.ctame701-2.telepar.net.br [200.181.168.6]) by netbank.com.br (Postfix) with ESMTP id 0C50846809; Thu, 22 Nov 2001 13:03:10 -0200 (BRDT) Received: by brinquedo.distro.conectiva (Postfix, from userid 501) id A34A8C450; Thu, 22 Nov 2001 13:06:01 -0200 (BRST) Date: Thu, 22 Nov 2001 13:06:01 -0200 From: Arnaldo Carvalho de Melo To: "Sung-jae. Lee." Cc: netdev@oss.sgi.com Subject: Re: Hi~ I have stupid question. :) Message-ID: <20011122130601.A1005@conectiva.com.br> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i X-Url: http://advogato.org/person/acme Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 300 Lines: 8 Em Thu, Nov 22, 2001 at 09:36:23PM +0900, Sung-jae. Lee. escreveu: > How can I build dual stack kernel that can send IPv4 and IPv6 packets? most distros come with ipv6 compiled as a module, just insmod ipv6 and you'll have IPv4 and IPv6 support, now is a matter of configuring userspace. - Arnaldo From owner-netdev@oss.sgi.com Thu Nov 22 08:27:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAMGRTR19132 for netdev-outgoing; Thu, 22 Nov 2001 08:27:29 -0800 Received: from netbank.com.br (IDENT:postfix@garrincha.netbank.com.br [200.203.199.88]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAMGRQo19120 for ; Thu, 22 Nov 2001 08:27:26 -0800 Received: from brinquedo.distro.conectiva (4-006.ctame701-2.telepar.net.br [200.181.168.6]) by netbank.com.br (Postfix) with ESMTP id 3A30846820; Thu, 22 Nov 2001 13:24:07 -0200 (BRDT) Received: by brinquedo.distro.conectiva (Postfix, from userid 501) id 531C3C450; Thu, 22 Nov 2001 13:27:01 -0200 (BRST) Date: Thu, 22 Nov 2001 13:27:01 -0200 From: Arnaldo Carvalho de Melo To: "Sung-jae. Lee." Cc: netdev@oss.sgi.com Subject: Re: Hi~ I have stupid question. :) Message-ID: <20011122132701.B1005@conectiva.com.br> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i X-Url: http://advogato.org/person/acme Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 320 Lines: 9 Em Fri, Nov 23, 2001 at 12:18:42AM +0900, Sung-jae. Lee. escreveu: > Hmm... How about this? > support ipv6 in kernel, and support ipv4 as a module. IPv4 cannot be compiled as a module, only IPv6 and with a little detail ;) : once loaded it cannot be unloaded like most modules, it gets a module count of -1. - Arnaldo From owner-netdev@oss.sgi.com Thu Nov 22 08:40:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAMGe3a21267 for netdev-outgoing; Thu, 22 Nov 2001 08:40:03 -0800 Received: from iri.emip.net ([210.231.222.206]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAMGe0o21257 for ; Thu, 22 Nov 2001 08:40:00 -0800 Received: from localhost (PPP1787.tokyo-ip.dti.ne.jp [211.132.79.37]) by iri.emip.net (Postfix) with ESMTP id 3E2F014401; Fri, 23 Nov 2001 00:42:17 +0900 (JST) Date: Fri, 23 Nov 2001 00:39:56 +0900 Subject: Re: Hi~ I have stupid question. :) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v475) Cc: "Sung-jae. Lee." , netdev@oss.sgi.com To: Arnaldo Carvalho de Melo From: KUSUNOKI Masanori In-Reply-To: <20011122130601.A1005@conectiva.com.br> Message-Id: <2DF83643-DF5F-11D5-8149-00039358A8E2@linux.or.jp> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.475) Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 649 Lines: 21 Hi! Some new distros (i.e, RedHat 7.2, Turbo 7.0) comes with IPv6 enabled userspace. But a lot of distros comes with IPv4 only userspace. If you want to use IPv6 on these distros, you must re-configure and rebuild userspace for turn to IPv6 enable. - KUSUNOKI, Masanori On 2001.11.23, at 00:06, Arnaldo Carvalho de Melo wrote: > Em Thu, Nov 22, 2001 at 09:36:23PM +0900, Sung-jae. Lee. escreveu: >> How can I build dual stack kernel that can send IPv4 and IPv6 packets? > > most distros come with ipv6 compiled as a module, just insmod ipv6 and > you'll have IPv4 and IPv6 support, now is a matter of configuring > userspace. > > - Arnaldo > From owner-netdev@oss.sgi.com Thu Nov 22 08:43:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAMGh0D21772 for netdev-outgoing; Thu, 22 Nov 2001 08:43:00 -0800 Received: from iri.emip.net ([210.231.222.206]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAMGgwo21766 for ; Thu, 22 Nov 2001 08:42:58 -0800 Received: from localhost (PPP1787.tokyo-ip.dti.ne.jp [211.132.79.37]) by iri.emip.net (Postfix) with ESMTP id 1F82914401; Fri, 23 Nov 2001 00:45:16 +0900 (JST) Date: Fri, 23 Nov 2001 00:42:55 +0900 Subject: Re: Hi~ I have stupid question. :) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v475) Cc: "Sung-jae. Lee." , netdev@oss.sgi.com To: Arnaldo Carvalho de Melo From: KUSUNOKI Masanori In-Reply-To: <20011122132701.B1005@conectiva.com.br> Message-Id: <98FF371E-DF5F-11D5-8149-00039358A8E2@linux.or.jp> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.475) Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 529 Lines: 20 You can't unload IPv6 module. This is specification. # Few years ago, you can unload ipv6 module, # but kernel will freeze B-p On 2001.11.23, at 00:27, Arnaldo Carvalho de Melo wrote: > Em Fri, Nov 23, 2001 at 12:18:42AM +0900, Sung-jae. Lee. escreveu: >> Hmm... How about this? >> support ipv6 in kernel, and support ipv4 as a module. > > IPv4 cannot be compiled as a module, only IPv6 and with a little > detail ;) : > once loaded it cannot be unloaded like most modules, it gets a module > count > of -1. > > - Arnaldo > From owner-netdev@oss.sgi.com Thu Nov 22 09:44:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAMHimW04944 for netdev-outgoing; Thu, 22 Nov 2001 09:44:48 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAMHiho04929 for ; Thu, 22 Nov 2001 09:44:43 -0800 Received: from zmailer.org (mail.zmailer.org [194.252.70.162]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA06013 for ; Thu, 22 Nov 2001 08:44:40 -0800 (PST) mail_from (matti.aarnio@zmailer.org) Received: (mea@zmailer.org) by mail.zmailer.org id ; Thu, 22 Nov 2001 18:25:32 +0200 Date: Thu, 22 Nov 2001 18:25:32 +0200 From: Matti Aarnio To: KUSUNOKI Masanori Cc: Arnaldo Carvalho de Melo , "Sung-jae. Lee." , netdev@oss.sgi.com Subject: Re: Hi~ I have stupid question. :) Message-ID: <20011122182532.R2682@mea-ext.zmailer.org> References: <20011122132701.B1005@conectiva.com.br> <98FF371E-DF5F-11D5-8149-00039358A8E2@linux.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <98FF371E-DF5F-11D5-8149-00039358A8E2@linux.or.jp>; from masanori@linux.or.jp on Fri, Nov 23, 2001 at 12:42:55AM +0900 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 692 Lines: 21 On Fri, Nov 23, 2001 at 12:42:55AM +0900, KUSUNOKI Masanori wrote: > You can't unload IPv6 module. > This is specification. > # Few years ago, you can unload ipv6 module, > # but kernel will freeze B-p I could unload at one point, but it really isn't worth the effort. Doing that is fairly easy -- took me a week at one point, but the real effort which I see interesting is to have IPv6-only stack without IPv4 in kernel at all. Developing that is -- likely a bit more of a challenge. There are: - IPv4 specific stuff - IPv6 specific stuff - generic TCP and UDP stuff Presently both the IPv4 specific, and generic TCP and UDP are in the IPv4 part. /Matti Aarnio From owner-netdev@oss.sgi.com Fri Nov 23 17:23:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAO1Nhi26446 for netdev-outgoing; Fri, 23 Nov 2001 17:23:43 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAO1Neo26430 for ; Fri, 23 Nov 2001 17:23:41 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fANDE2b29528 for netdev@oss.sgi.com; Sat, 24 Nov 2001 00:14:02 +1100 Received: from hotmail.com (f160.pav2.hotmail.com [64.4.37.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAMGIno17659 for ; Thu, 22 Nov 2001 08:18:50 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 22 Nov 2001 07:18:42 -0800 Received: from 211.191.219.75 by pv2fd.pav2.hotmail.msn.com with HTTP; Thu, 22 Nov 2001 15:18:42 GMT X-Originating-IP: [211.191.219.75] From: "Sung-jae. Lee." To: acme@conectiva.com.br, netdev@oss.sgi.com Subject: Re: Hi~ I have stupid question. :) Date: Fri, 23 Nov 2001 00:18:42 +0900 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Nov 2001 15:18:42.0840 (UTC) FILETIME=[F8A46180:01C17368] Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 766 Lines: 24 Hmm... How about this? support ipv6 in kernel, and support ipv4 as a module. do you have any idea? >From: Arnaldo Carvalho de Melo >To: "Sung-jae. Lee." >CC: netdev@oss.sgi.com >Subject: Re: Hi~ I have stupid question. :) >Date: Thu, 22 Nov 2001 13:06:01 -0200 > >Em Thu, Nov 22, 2001 at 09:36:23PM +0900, Sung-jae. Lee. escreveu: > > How can I build dual stack kernel that can send IPv4 and IPv6 packets? > >most distros come with ipv6 compiled as a module, just insmod ipv6 and >you'll have IPv4 and IPv6 support, now is a matter of configuring >userspace. > >- Arnaldo _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-netdev@oss.sgi.com Sat Nov 24 11:11:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAOJB9P30975 for netdev-outgoing; Sat, 24 Nov 2001 11:11:09 -0800 Received: from imf17bis.bellsouth.net (mail217.mail.bellsouth.net [205.152.58.157]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAOJB6o30972 for ; Sat, 24 Nov 2001 11:11:07 -0800 Received: from mandrakesoft.com ([208.63.170.233]) by imf17bis.bellsouth.net (InterMail vM.5.01.01.01 201-252-104) with ESMTP id <20011124181017.YMG10011.imf17bis.bellsouth.net@mandrakesoft.com>; Sat, 24 Nov 2001 13:10:17 -0500 Message-ID: <3BFFE244.44D734F0@mandrakesoft.com> Date: Sat, 24 Nov 2001 13:09:08 -0500 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.15-pre7 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: RFD: 2.5 net driver cmdline handling Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 691 Lines: 16 In 2.5 we should clean up device configuration overall. Make sane the ether=XXX crap. I do not think modern PCI net drivers need ether=XXX at all other than for a non-default interface name ("eth4" instead of "eth0"), for example. If we decided to handle this on a per-net-driver basis using __setup(), that would allow us to simply kill the ether=XXX code completely [get it out of the core rather]. Helper functions called from net driver's __setup routine would instead be where the common code would exist [in a smaller form]. -- Jeff Garzik | Only so many songs can be sung Building 1024 | with two lips, two lungs, and one tongue. MandrakeSoft | - nomeansno From owner-netdev@oss.sgi.com Sat Nov 24 11:43:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAOJhqR00373 for netdev-outgoing; Sat, 24 Nov 2001 11:43:52 -0800 Received: from imf06bis.bellsouth.net (mail006.mail.bellsouth.net [205.152.58.26]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAOJhno00369 for ; Sat, 24 Nov 2001 11:43:49 -0800 Received: from mandrakesoft.com ([208.63.170.233]) by imf06bis.bellsouth.net (InterMail vM.5.01.01.01 201-252-104) with ESMTP id <20011124184300.FKJS11170.imf06bis.bellsouth.net@mandrakesoft.com>; Sat, 24 Nov 2001 13:43:00 -0500 Message-ID: <3BFFE9EE.F3402F0A@mandrakesoft.com> Date: Sat, 24 Nov 2001 13:41:50 -0500 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.15-pre7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Linux-Kernel list , linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: ethtool 1.4 released Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 554 Lines: 16 ethtool has been made current with kernel 2.4.15/2.5.0. Only the natsemi driver in the kernel fully supports all capabilities at this time, but patches are available in gkernel cvs to implement ethtool support in many more drivers. Kudos to Tim Hockin @ Sun for most of the implementation work, both in natsemi and in userspace ethtool. ChangeLog and download at http://sf.net/projects/gkernel/ -- Jeff Garzik | Only so many songs can be sung Building 1024 | with two lips, two lungs, and one tongue. MandrakeSoft | - nomeansno From owner-netdev@oss.sgi.com Sat Nov 24 22:51:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAP6pMk28698 for netdev-outgoing; Sat, 24 Nov 2001 22:51:22 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAP6pKo28690 for ; Sat, 24 Nov 2001 22:51:20 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fAP5pJU08971 for netdev@oss.sgi.com; Sun, 25 Nov 2001 16:51:19 +1100 Received: from hotmail.com (f229.pav2.hotmail.com [64.4.37.229]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fANEiYo22584 for ; Fri, 23 Nov 2001 06:44:34 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 23 Nov 2001 05:44:28 -0800 Received: from 211.191.219.75 by pv2fd.pav2.hotmail.msn.com with HTTP; Fri, 23 Nov 2001 13:44:28 GMT X-Originating-IP: [211.191.219.75] From: "Sung-jae. Lee." To: acme@conectiva.com.br Cc: netdev@oss.sgi.com Subject: Re: Hi~ I have stupid question. :) Date: Fri, 23 Nov 2001 22:44:28 +0900 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Nov 2001 13:44:28.0773 (UTC) FILETIME=[F8F7F950:01C17424] Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 895 Lines: 28 Then, If I compile the kernel with IPv6 as a module(I mean dual stack.), can I config my computer that has only IPv6 address without IPv4 address? And that can send IPv6 and IPv4 packets? It will be OK? >From: Arnaldo Carvalho de Melo >To: "Sung-jae. Lee." >CC: netdev@oss.sgi.com >Subject: Re: Hi~ I have stupid question. :) >Date: Thu, 22 Nov 2001 13:27:01 -0200 > >Em Fri, Nov 23, 2001 at 12:18:42AM +0900, Sung-jae. Lee. escreveu: > > Hmm... How about this? > > support ipv6 in kernel, and support ipv4 as a module. > >IPv4 cannot be compiled as a module, only IPv6 and with a little detail ;) >: >once loaded it cannot be unloaded like most modules, it gets a module count >of -1. > >- Arnaldo _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-netdev@oss.sgi.com Sun Nov 25 10:21:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAPILMP29870 for netdev-outgoing; Sun, 25 Nov 2001 10:21:22 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAPILJo29867 for ; Sun, 25 Nov 2001 10:21:19 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fAPHLId22212 for netdev@oss.sgi.com; Mon, 26 Nov 2001 04:21:18 +1100 Received: from titan.bieringer.de (mail.bieringer.de [195.226.187.51]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAPIEIo29587 for ; Sun, 25 Nov 2001 10:14:18 -0800 Received: (qmail 28477 invoked from network); 25 Nov 2001 17:14:10 -0000 Received: from p50805298.dip.t-dialin.net (HELO worker.muc.bieringer.de) (80.128.82.152) by mail.bieringer.de with SMTP; 25 Nov 2001 17:14:10 -0000 Date: Sun, 25 Nov 2001 18:16:18 +0100 From: Peter Bieringer To: "Sung-jae. Lee." , acme@conectiva.com.br cc: netdev@oss.sgi.com Subject: Re: Hi~ I have stupid question. :) Message-ID: <57440000.1006708578@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 484 Lines: 14 --On Friday, November 23, 2001 10:44:28 PM +0900 "Sung-jae. Lee." wrote: > Then, If I compile the kernel with IPv6 as a module(I mean dual > stack.), > > can I config my computer that has only IPv6 address without IPv4 > address? And that can send IPv6 and IPv4 packets? Configure special addresses (0.0.0.0) on your external interfaces. IPv4 connections to outside of the host are no longer possible afterwards and also no longer displayed. Peter From owner-netdev@oss.sgi.com Sun Nov 25 10:25:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAPIP4a30132 for netdev-outgoing; Sun, 25 Nov 2001 10:25:04 -0800 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAPIOvo30123 for ; Sun, 25 Nov 2001 10:24:57 -0800 Received: from marajade.sandelman.ottawa.on.ca ([2001:410:402:2:204:76ff:fe2d:8c]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id fAPHNLR22148 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Sun, 25 Nov 2001 12:23:21 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.6/8.11.0) with ESMTP id fAP0UTH01038; Sat, 24 Nov 2001 19:30:31 -0500 (EST) Message-Id: <200111250030.fAP0UTH01038@marajade.sandelman.ottawa.on.ca> From: Michael Richardson To: netdev@oss.sgi.com cc: design@lists.freeswan.org Subject: what pointers does pskb_may_pull() nuke? Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sat, 24 Nov 2001 19:30:29 -0500 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2411 Lines: 64 -----BEGIN PGP SIGNED MESSAGE----- pskb_may_pull() is documented (well, __pskb_pull_tail) as: * 2. It may change skb pointers. I don't see that it actually moves or changes any of the pointers. However, since it may move the data around, clearly the may go bad. {We think we should be calling pskb_may_pull() on 2.4.4 and later to reassemble all the fragments of an ESP packet into a single skbuff so that we can decrypt it. Writing a decrypt routing to walk fragments isn't high on our list of things to do, although we could probably steal an mbuf-capable one from KAME} My guess is that this screws the "h" pointers, and the "nh" pointers, as well as the "mac" pointers. skb->data should be correct. mac.raw is trivially skb->data, I think. (At least, for ethernet) nh.iph may move depending on presence of 802.3 options, etc. Is there a simple call to have it recalculated? I don't that we can rely on dev->hard_header_len for incoming! h.raw can be determined by adding nh.iph->ihl<<2. Since we actually don't care about mac.raw at all, just nh.iph, if there is a way to preserve that we, would be happy. Perhaps advancing skb->data to nh.iph before calling pskb_may_pull(). Also, we have some code that says: #ifdef IPH_is_SKB_PULLED /* In Linux 2.4.4, the IP header has been skb_pull()ed before the packet is passed to us. So we'll skb_push() to get back to it. */ if (skb->data == skb->h.raw) { skb_push(skb, skb->h.raw - skb->nh.raw); } #endif /* IPH_is_SKB_PULLED */ It appears that we never enabled it, not is it clear when we should :-) But, is there a document that explains how the skbuff is arranged on different versions upon entry to the protocol_rcv() function? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPAA7o4qHRg3pndX9AQGsIAP/ZAT8btc8+pgGD1gGfpi77/h6nk67qyRz AcQpmr6nwgH5z0aiXRMK5WMvd04DVwPMTCYJiqIHG79kldGe93x4Szi2CtD/BnWX uDCm0vk9P3lbDNO99RZGf0OzuWxWHzzioS8+Fdbabjurnk/CKUbHduSIVtLQ6HYV dZyPYHcdswo= =8jmz -----END PGP SIGNATURE----- From owner-netdev@oss.sgi.com Sun Nov 25 11:29:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAPJTLo00446 for netdev-outgoing; Sun, 25 Nov 2001 11:29:21 -0800 Received: from u.domain.uli (ja.mac.ssi.bg [212.95.166.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAPJT9o00428 for ; Sun, 25 Nov 2001 11:29:10 -0800 Received: from localhost (IDENT:ja@localhost [127.0.0.1]) by u.domain.uli (8.11.0/8.11.0) with ESMTP id fAPKThr06962; Sun, 25 Nov 2001 20:29:44 GMT Date: Sun, 25 Nov 2001 20:29:43 +0000 (GMT) From: Julian Anastasov X-X-Sender: To: Michael Richardson cc: , Subject: Re: what pointers does pskb_may_pull() nuke? In-Reply-To: <200111250030.fAP0UTH01038@marajade.sandelman.ottawa.on.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 3853 Lines: 108 Hello, On Sat, 24 Nov 2001, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > > pskb_may_pull() is documented (well, __pskb_pull_tail) as: > > * 2. It may change skb pointers. > > I don't see that it actually moves or changes any of the pointers. > However, since it may move the data around, clearly the may go bad. > > {We think we should be calling pskb_may_pull() on 2.4.4 and later to > reassemble all the fragments of an ESP packet into a single skbuff so that we > can decrypt it. Writing a decrypt routing to walk fragments isn't high on our > list of things to do, although we could probably steal an mbuf-capable one > from KAME} pskb_may_pull does not assemble all fragments, even after ip_defrag you have to call skb_linearize if the skb is still non-linear, i.e. something like: // not needed in LOCAL_IN: if (skb->nh.iph->frag_off & htons(IP_MF|IP_OFFSET)) { skb = ip_defrag(skb); if (!skb) return NF_STOLEN; *skb_p = skb; } if (skb_is_nonlinear(skb)) { if (skb_linearize(skb, GFP_ATOMIC) != 0) return NF_DROP; ip_send_check(skb->nh.iph); // Not needed for local delivery } iph = skb->nh.iph; ihl = iph->ihl << 2; Note that ip_defrag is already called before LOCAL_IN. And also there are other details. > My guess is that this screws the "h" pointers, and the "nh" pointers, > as well as the "mac" pointers. > skb->data should be correct. No. You can look in pskb_expand_head which pointers are changed. All pointers to data can change because it can be reallocated - when the requested length is not present in first fragment or when the first skb is used (cloned) from other readers. > mac.raw is trivially skb->data, I think. > (At least, for ethernet) > > nh.iph may move depending on presence of 802.3 options, etc. Is there a simple > call to have it recalculated? I don't that we can rely on > dev->hard_header_len for incoming! > > h.raw can be determined by adding nh.iph->ihl<<2. > > Since we actually don't care about mac.raw at all, just nh.iph, if there is > a way to preserve that we, would be happy. Perhaps advancing skb->data to > nh.iph before calling pskb_may_pull(). Then after *_may_pull (or any other functions that move the data) you have to base everything on skb->nh.iph and to create your own h.raw and other pointers. > Also, we have some code that says: > > #ifdef IPH_is_SKB_PULLED > /* In Linux 2.4.4, the IP header has been skb_pull()ed before the > packet is passed to us. So we'll skb_push() to get back to it. */ > if (skb->data == skb->h.raw) { > skb_push(skb, skb->h.raw - skb->nh.raw); > } > #endif /* IPH_is_SKB_PULLED */ IIRC, skb->h.raw is changed by ihl after the LOCAL_IN chain, i.e. in ip_local_deliver_finish. You have to see how is that related to IPSec. There is __skb_pull call before that. So, skb->h.raw is changed only when we are sure the sk_buff goes to the protocols. > It appears that we never enabled it, not is it clear when we should :-) Hm, are you sure it is not enabled? I don't know how you are using skb->data in the protocol handlers as pointer to iphdr after 2.4.4 If in doubt, don't use skb->h.raw in your calcs, base everything on nh.raw (more portable for local delivery) > But, is there a document that explains how the skbuff is arranged on > different versions upon entry to the protocol_rcv() function? skb->data and h.raw point after ihl, nh.raw points to iphdr. While we played with sk_buffs during the Linux Virtual Server port we didn't found any docs. If you can't find any docs or don't have other options feel free to contact me directly. Regards -- Julian Anastasov From owner-netdev@oss.sgi.com Mon Nov 26 01:01:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQ91b711334 for netdev-outgoing; Mon, 26 Nov 2001 01:01:37 -0800 Received: from mta05ps.bigpond.com (mta05ps.bigpond.com [144.135.25.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQ91Yo11328 for ; Mon, 26 Nov 2001 01:01:34 -0800 Received: from bigpond.net.au ([144.135.25.72]) by mta05ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GNEELJ00.3N0 for ; Mon, 26 Nov 2001 18:08:07 +1000 Received: from CPE-61-9-171-166.vic.bigpond.net.au ([61.9.171.166]) by PSMAM02.mailsvc.email.bigpond.com(MailRouter V2.9k 8383/20527696); 26 Nov 2001 18:01:25 Message-ID: <3C01F755.82965AB5@bigpond.net.au> Date: Mon, 26 Nov 2001 19:03:33 +1100 From: Brad Hards X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.5.1-pre1 i686) X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Link State visibility to userspace Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 694 Lines: 20 G'day, I'm trying to test the netif_carrier_off() and netif_carrier_on() calls in my driver. However these don't seem to be visible to userspace. I searched likely bits of /proc, tried ethtool and ifconfig man pages, and looked though the linux/net directory. It doesn't seem that the link state is even used, let alone visible. Can someone enlighten me? If there isn't visibility of this already available, would /proc/net/link_state be a possible candidate? Interface | Link State lo: linked eth0: not linked I recognise that not all devices support link state reporting, but for some of the usb devices, it might be useful to detect changes for our hot-plug support. Brad From owner-netdev@oss.sgi.com Mon Nov 26 05:23:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQDNHa23826 for netdev-outgoing; Mon, 26 Nov 2001 05:23:17 -0800 Received: from mta01ps.bigpond.com (mta01ps.bigpond.com [144.135.25.133]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQDN7o23818 for ; Mon, 26 Nov 2001 05:23:07 -0800 Received: from bigpond.net.au ([144.135.25.72]) by mta01ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GNEQPH00.BN5; Mon, 26 Nov 2001 22:29:41 +1000 Received: from CPE-61-9-171-166.vic.bigpond.net.au ([61.9.171.166]) by PSMAM02.mailsvc.email.bigpond.com(MailRouter V2.9k 8383/20818347); 26 Nov 2001 22:22:59 Message-ID: <3C0234A5.767256DF@bigpond.net.au> Date: Mon, 26 Nov 2001 23:25:09 +1100 From: Brad Hards X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.5.1-pre1 i686) X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com, vojtech@suse.cz, becker@scyld.com Subject: [patch] Link state reporting Content-Type: multipart/mixed; boundary="------------9B2CC68FCCEF73E712FA67E4" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 5173 Lines: 88 This is a multi-part message in MIME format. --------------9B2CC68FCCEF73E712FA67E4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In a momentary fit of coding over designing, I copied some vaguely related code and made a link state reporting proc interface. I also patched a couple of drivers (USB CATC and PCMCIA 3c574) to give me something to test with. Here is what the /proc interface looks like, this example showing what happens when you disconnect the crossover cable between the two test devices: Inter-| Link face | Status lo:Link Good eth0:Link Good eth1:Link Failed eth2:Link Failed Any comments or thoughts on this? Brad --------------9B2CC68FCCEF73E712FA67E4 Content-Type: application/octet-stream; name="linkstate.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="linkstate.patch" ZGlmZiAtTmF1ciAtWCAvdXNyL3NyYy9kb250ZGlmZiBjbGVhbi9saW51eC0yLjUuMS1wcmUx L2RyaXZlcnMvbmV0L3BjbWNpYS8zYzU3NF9jcy5jIGxpbnV4L2RyaXZlcnMvbmV0L3BjbWNp YS8zYzU3NF9jcy5jCi0tLSBjbGVhbi9saW51eC0yLjUuMS1wcmUxL2RyaXZlcnMvbmV0L3Bj bWNpYS8zYzU3NF9jcy5jCVdlZCBOb3YgMTQgMDQ6MDI6MzAgMjAwMQorKysgbGludXgvZHJp dmVycy9uZXQvcGNtY2lhLzNjNTc0X2NzLmMJTW9uIE5vdiAyNiAyMjoyMToyNSAyMDAxCkBA IC0xMDQ5LDkgKzEwNDksMTUgQEAKIAlyZXN0b3JlX2ZsYWdzKGZsYWdzKTsKIAogCWlmICht ZWRpYSAhPSBscC0+bWVkaWFfc3RhdHVzKSB7Ci0JCWlmICgobWVkaWEgXiBscC0+bWVkaWFf c3RhdHVzKSAmIDB4MDAwNCkKLQkJCXByaW50ayhLRVJOX0lORk8gIiVzOiAlcyBsaW5rIGJl YXRcbiIsIGRldi0+bmFtZSwKLQkJCQkgICAobHAtPm1lZGlhX3N0YXR1cyAmIDB4MDAwNCkg PyAibG9zdCIgOiAiZm91bmQiKTsKKwkJaWYgKChtZWRpYSBeIGxwLT5tZWRpYV9zdGF0dXMp ICYgMHgwMDA0KSB7CisJCQlpZiAobHAtPm1lZGlhX3N0YXR1cyAmIDB4MDAwNCkgeworCQkJ CXByaW50ayhLRVJOX0lORk8gIiVzOiBsb3N0IGxpbmsgYmVhdFxuIiwgZGV2LT5uYW1lKTsK KwkJCQluZXRpZl9jYXJyaWVyX29mZihkZXYpOworCQkJfSBlbHNlIHsKKwkJCQlwcmludGso S0VSTl9JTkZPICIlczogZm91bmQgbGluayBiZWF0XG4iLCBkZXYtPm5hbWUpOworCQkJCW5l dGlmX2NhcnJpZXJfb24oZGV2KTsKKwkJCX0KKwkJfQogCQlpZiAoKG1lZGlhIF4gbHAtPm1l ZGlhX3N0YXR1cykgJiAweDAwMjApIHsKIAkJCWxwLT5wYXJ0bmVyID0gMDsKIAkJCWlmIChs cC0+bWVkaWFfc3RhdHVzICYgMHgwMDIwKSB7CmRpZmYgLU5hdXIgLVggL3Vzci9zcmMvZG9u dGRpZmYgY2xlYW4vbGludXgtMi41LjEtcHJlMS9kcml2ZXJzL3VzYi9jYXRjLmMgbGludXgv ZHJpdmVycy91c2IvY2F0Yy5jCi0tLSBjbGVhbi9saW51eC0yLjUuMS1wcmUxL2RyaXZlcnMv dXNiL2NhdGMuYwlXZWQgTm92IDE0IDA0OjE5OjQxIDIwMDEKKysrIGxpbnV4L2RyaXZlcnMv dXNiL2NhdGMuYwlNb24gTm92IDI2IDIyOjM1OjA3IDIwMDEKQEAgLTQwLDcgKzQwLDcgQEAK ICNpbmNsdWRlIDxsaW51eC9zcGlubG9jay5oPgogI2luY2x1ZGUgPGFzbS9iaXRvcHMuaD4K IAotI3VuZGVmIERFQlVHCisjZGVmaW5lIERFQlVHCiAKICNpbmNsdWRlIDxsaW51eC91c2Iu aD4KIApAQCAtMjU5LDExICsyNTksMTUgQEAKIAkJfSAKIAl9CiAKLQlpZiAoZGF0YVsxXSAm IDB4NDApCisJaWYgKGRhdGFbMV0gJiAweDQwKSB7CisJCW5ldGlmX2NhcnJpZXJfb24oY2F0 Yy0+bmV0ZGV2KTsKIAkJZGJnKCJsaW5rIG9rIik7CisJfQogCi0JaWYgKGRhdGFbMV0gJiAw eDIwKSAKKwlpZiAoZGF0YVsxXSAmIDB4MjApIHsKKwkJbmV0aWZfY2Fycmllcl9vZmYoY2F0 Yy0+bmV0ZGV2KTsKIAkJZGJnKCJsaW5rIGJhZCIpOworCX0KIH0KIAogLyoKZGlmZiAtTmF1 ciAtWCAvdXNyL3NyYy9kb250ZGlmZiBjbGVhbi9saW51eC0yLjUuMS1wcmUxL25ldC9jb3Jl L2Rldi5jIGxpbnV4L25ldC9jb3JlL2Rldi5jCi0tLSBjbGVhbi9saW51eC0yLjUuMS1wcmUx L25ldC9jb3JlL2Rldi5jCVRodSBOb3YgIDggMDk6Mzk6MzYgMjAwMQorKysgbGludXgvbmV0 L2NvcmUvZGV2LmMJTW9uIE5vdiAyNiAyMTo1NDozMyAyMDAxCkBAIC0xNzU1LDYgKzE3NTUs NTMgQEAKIAlyZXR1cm4gbGVuOwogfQogCisvKgorICoJQ2FsbGVkIGZyb20gdGhlIFBST0Nm cyBtb2R1bGUuIAorICoJQ3JlYXRlcyAvcHJvYy9uZXQvbGlua19zdGF0dXMKKyAqLworIAor c3RhdGljIGludCBsaW5rX3N0YXR1c19nZXRfaW5mbyhjaGFyICpidWZmZXIsIGNoYXIgKipz dGFydCwgb2ZmX3Qgb2Zmc2V0LCBpbnQgbGVuZ3RoKQoreworCWludCBsZW4gPSAwOworCW9m Zl90IGJlZ2luID0gMDsKKwlvZmZfdCBwb3MgPSAwOworCWludCBzaXplOworCXN0cnVjdCBu ZXRfZGV2aWNlICpkZXY7CisKKworCXNpemUgPSBzcHJpbnRmKGJ1ZmZlciwgCisJCSJJbnRl ci18IExpbmsgXG4iCisJCSIgZmFjZSB8IFN0YXR1c1xuIik7CisJCisJcG9zICs9IHNpemU7 CisJbGVuICs9IHNpemU7CisJCisJcmVhZF9sb2NrKCZkZXZfYmFzZV9sb2NrKTsKKwlmb3Ig KGRldiA9IGRldl9iYXNlOyBkZXYgIT0gTlVMTDsgZGV2ID0gZGV2LT5uZXh0KSB7CisJCXNp emUgPSBzcHJpbnRmKGJ1ZmZlcitsZW4sICIlNnM6JXNcbiIsCisJCQkgICAgICAgZGV2LT5u YW1lLAorCQkJICAgICAgIChuZXRpZl9jYXJyaWVyX29rKGRldik/ICJMaW5rIEdvb2QiIDog IkxpbmsgRmFpbGVkIikpOworCQlsZW4gKz0gc2l6ZTsKKwkJcG9zID0gYmVnaW4gKyBsZW47 CisJCQkJCisJCWlmIChwb3MgPCBvZmZzZXQpIHsKKwkJCWxlbiA9IDA7CisJCQliZWdpbiA9 IHBvczsKKwkJfQorCQlpZiAocG9zID4gb2Zmc2V0ICsgbGVuZ3RoKQorCQkJYnJlYWs7CisJ fQorCXJlYWRfdW5sb2NrKCZkZXZfYmFzZV9sb2NrKTsKKworCSpzdGFydCA9IGJ1ZmZlciAr IChvZmZzZXQgLSBiZWdpbik7CS8qIFN0YXJ0IG9mIHdhbnRlZCBkYXRhICovCisJbGVuIC09 IChvZmZzZXQgLSBiZWdpbik7CQkvKiBTdGFydCBzbG9wICovCisJaWYgKGxlbiA+IGxlbmd0 aCkKKwkJbGVuID0gbGVuZ3RoOwkJCS8qIEVuZGluZyBzbG9wICovCisJaWYgKGxlbiA8IDAp CisJCWxlbiA9IDA7CisJcmV0dXJuIGxlbjsKK30KKwogc3RhdGljIGludCBkZXZfcHJvY19z dGF0cyhjaGFyICpidWZmZXIsIGNoYXIgKipzdGFydCwgb2ZmX3Qgb2Zmc2V0LAogCQkJICBp bnQgbGVuZ3RoLCBpbnQgKmVvZiwgdm9pZCAqZGF0YSkKIHsKQEAgLTI4NTQsNiArMjkwMSw3 IEBACiAKICNpZmRlZiBDT05GSUdfUFJPQ19GUwogCXByb2NfbmV0X2NyZWF0ZSgiZGV2Iiwg MCwgZGV2X2dldF9pbmZvKTsKKwlwcm9jX25ldF9jcmVhdGUoImxpbmtfc3RhdHVzIiwgMCwg bGlua19zdGF0dXNfZ2V0X2luZm8pOwogCWNyZWF0ZV9wcm9jX3JlYWRfZW50cnkoIm5ldC9z b2Z0bmV0X3N0YXQiLCAwLCAwLCBkZXZfcHJvY19zdGF0cywgTlVMTCk7CiAjaWZkZWYgV0lS RUxFU1NfRVhUCiAJcHJvY19uZXRfY3JlYXRlKCJ3aXJlbGVzcyIsIDAsIGRldl9nZXRfd2ly ZWxlc3NfaW5mbyk7Cg== --------------9B2CC68FCCEF73E712FA67E4-- From owner-netdev@oss.sgi.com Mon Nov 26 06:04:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQE43s25694 for netdev-outgoing; Mon, 26 Nov 2001 06:04:03 -0800 Received: from mail.pha.ha-vel.cz (mail.pha.ha-vel.cz [195.39.72.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQE40o25691 for ; Mon, 26 Nov 2001 06:04:00 -0800 Received: (qmail 9531 invoked from network); 26 Nov 2001 13:03:56 -0000 Received: from twilight.ucw.cz (HELO twilight.suse.cz) (root@195.39.74.230) by mail.pha.ha-vel.cz with SMTP; 26 Nov 2001 13:03:56 -0000 Received: (from vojtech@localhost) by twilight.suse.cz (8.10.2/8.9.3) id fAQD3uD11432; Mon, 26 Nov 2001 14:03:56 +0100 Date: Mon, 26 Nov 2001 14:03:56 +0100 From: Vojtech Pavlik To: Brad Hards Cc: netdev@oss.sgi.com, becker@scyld.com Subject: Re: [patch] Link state reporting Message-ID: <20011126140356.C11383@suse.cz> References: <3C0234A5.767256DF@bigpond.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C0234A5.767256DF@bigpond.net.au>; from bhards@bigpond.net.au on Mon, Nov 26, 2001 at 11:25:09PM +1100 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 647 Lines: 21 On Mon, Nov 26, 2001 at 11:25:09PM +1100, Brad Hards wrote: > In a momentary fit of coding over designing, I copied some vaguely related > code and made a link state reporting proc interface. I also patched a couple > of drivers (USB CATC and PCMCIA 3c574) to give me something to test with. > Here is what the /proc interface looks like, this example showing what happens > when you disconnect the crossover cable between the two test devices: > Inter-| Link > face | Status > lo:Link Good > eth0:Link Good > eth1:Link Failed > eth2:Link Failed > > Any comments or thoughts on this? Looks good to me. -- Vojtech Pavlik SuSE Labs From owner-netdev@oss.sgi.com Mon Nov 26 09:49:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQHn8G13287 for netdev-outgoing; Mon, 26 Nov 2001 09:49:08 -0800 Received: from snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQHn2o13284 for ; Mon, 26 Nov 2001 09:49:02 -0800 Received: from krypton ([206.170.6.242]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GNF004362POK0@mta5.snfc21.pbi.net> for netdev@oss.sgi.com; Mon, 26 Nov 2001 08:49:02 -0800 (PST) Date: Mon, 26 Nov 2001 08:47:35 -0800 From: David Brownell Subject: Re: [patch] Link state reporting To: Brad Hards , netdev@oss.sgi.com, vojtech@suse.cz, becker@scyld.com Message-id: <0d5601c1769a$0dad8000$6800000a@brownell.org> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal References: <3C0234A5.767256DF@bigpond.net.au> Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1405 Lines: 43 How about simpler reporting and labeling? Specifically: - single header line, "interface status\n" (or none) - simpler status: "%s %s\n", dev->name and "up" or"down Easier for programs to work with that way. Example: the "ifup" scripts for "usbnet" links would be simpler, at least for the links that can detect peer presence. (It's likely too much to change just now to tristate status: up, down, and "can't tell".) Leading to an issue I've raised before: don't we need to see more active link state reporting too? Along the lines of running "/sbin/hotplug net up" (or down) to report INTERFACE= going up or down. - Dave ----- Original Message ----- From: "Brad Hards" To: ; ; Sent: Monday, November 26, 2001 4:25 AM Subject: [patch] Link state reporting > In a momentary fit of coding over designing, I copied some vaguely related > code and made a link state reporting proc interface. I also patched a couple > of drivers (USB CATC and PCMCIA 3c574) to give me something to test with. > Here is what the /proc interface looks like, this example showing what happens > when you disconnect the crossover cable between the two test devices: > Inter-| Link > face | Status > lo:Link Good > eth0:Link Good > eth1:Link Failed > eth2:Link Failed > > Any comments or thoughts on this? > > Brad From owner-netdev@oss.sgi.com Mon Nov 26 10:22:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQIMt015027 for netdev-outgoing; Mon, 26 Nov 2001 10:22:55 -0800 Received: from stud.uni-goettingen.de (root@s2.stud.uni-goettingen.de [134.76.60.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQIMpo15018 for ; Mon, 26 Nov 2001 10:22:51 -0800 Received: from [10.10.65.104] (helo=stud.uni-goettingen.de) by stud.uni-goettingen.de with esmtp (Exim 2.12 #8) id 168PSv-0006CL-00 for netdev@oss.sgi.com; Mon, 26 Nov 2001 18:22:45 +0100 Message-ID: <3C027768.1010806@stud.uni-goettingen.de> Date: Mon, 26 Nov 2001 18:10:00 +0100 From: Tobias Edler User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5+) Gecko/20011022 X-Accept-Language: de, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: alsa and devfs Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1467 Lines: 29 Hi Folks ! I hava a ALS4000 soundcard, and used to use the ALSA drivers for it( since there ar no others for it AFAIK). Now, i tried to use devfs. looks cool, but doesn't seem to cooperate. i installed devfsd(1.3.18), then re-compiled the alsa stuff (0.9.beta9). now, wher i boot my system, basically nothing hapens. The ALSA modules loaded, there is /dev/snd/ . it contains : crw-rw---- 1 root user 116, 0 Jan 1 1970 controlC0 crw-rw---- 1 root user 116, 32 Jan 1 1970 controlC1 crw-rw---- 1 root user 116, 64 Jan 1 1970 controlC2 crw-rw---- 1 root user 116, 96 Jan 1 1970 controlC3 crw-rw---- 1 root user 116, 128 Jan 1 1970 controlC4 crw-rw---- 1 root user 116, 160 Jan 1 1970 controlC5 crw-rw---- 1 root user 116, 192 Jan 1 1970 controlC6 crw-rw---- 1 root user 116, 224 Jan 1 1970 controlC7 crw-rw---- 1 root user 116, 33 Jan 1 1970 timer nice. Are these the sound-devices ? The old-style devices don't exist. no /dev/mixer, nothing. so still no sound. After i executed the snddevices script included in the alsa-driver, everything wokks fine. but that shouldn't be necessary, how i understood the philosophy of devfs. I included the recommended lines in /etc/devfs.conf: # For alsa modules ... hope this helps .... LOOKUP snd MODLOAD ACTION snd REGISTER sound/.* PERMISSIONS root.user 660 REGISTER snd/.* PERMISSIONS root.user 660 From owner-netdev@oss.sgi.com Mon Nov 26 10:56:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQIu7e16071 for netdev-outgoing; Mon, 26 Nov 2001 10:56:07 -0800 Received: from imf05bis.bellsouth.net (mail305.mail.bellsouth.net [205.152.58.165]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQIu4o16066 for ; Mon, 26 Nov 2001 10:56:04 -0800 Received: from mandrakesoft.com ([208.63.170.233]) by imf05bis.bellsouth.net (InterMail vM.5.01.01.01 201-252-104) with ESMTP id <20011126175706.BTUA7147.imf05bis.bellsouth.net@mandrakesoft.com>; Mon, 26 Nov 2001 12:57:06 -0500 Message-ID: <3C02822D.6E103FAD@mandrakesoft.com> Date: Mon, 26 Nov 2001 12:55:57 -0500 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.15-pre7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Brad Hards CC: netdev@oss.sgi.com, vojtech@suse.cz, becker@scyld.com Subject: Re: [patch] Link state reporting References: <3C0234A5.767256DF@bigpond.net.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 350 Lines: 11 There is already two ways to report link state to userspace. We do not need a third. First, ETHTOOL_GLINK. Second, netif_carrier_off causes IFF_RUNNING to disappear when the interface is up. -- Jeff Garzik | Only so many songs can be sung Building 1024 | with two lips, two lungs, and one tongue. MandrakeSoft | - nomeansno From owner-netdev@oss.sgi.com Mon Nov 26 10:57:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQIv6016176 for netdev-outgoing; Mon, 26 Nov 2001 10:57:06 -0800 Received: from imf05bis.bellsouth.net (mail305.mail.bellsouth.net [205.152.58.165]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQIv4o16173 for ; Mon, 26 Nov 2001 10:57:04 -0800 Received: from mandrakesoft.com ([208.63.170.233]) by imf05bis.bellsouth.net (InterMail vM.5.01.01.01 201-252-104) with ESMTP id <20011126175806.BUIO7147.imf05bis.bellsouth.net@mandrakesoft.com>; Mon, 26 Nov 2001 12:58:06 -0500 Message-ID: <3C02826A.DD72F232@mandrakesoft.com> Date: Mon, 26 Nov 2001 12:56:58 -0500 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.15-pre7 i686) X-Accept-Language: en MIME-Version: 1.0 To: David Brownell CC: Brad Hards , netdev@oss.sgi.com, vojtech@suse.cz, becker@scyld.com Subject: Re: [patch] Link state reporting References: <3C0234A5.767256DF@bigpond.net.au> <0d5601c1769a$0dad8000$6800000a@brownell.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 457 Lines: 13 David Brownell wrote: > Leading to an issue I've raised before: don't we need > to see more active link state reporting too? Along > the lines of running "/sbin/hotplug net up" (or down) > to report INTERFACE= going up or down. As has been stated many times, netlink needs to provide this message. -- Jeff Garzik | Only so many songs can be sung Building 1024 | with two lips, two lungs, and one tongue. MandrakeSoft | - nomeansno From owner-netdev@oss.sgi.com Mon Nov 26 11:03:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQJ3Pb16529 for netdev-outgoing; Mon, 26 Nov 2001 11:03:25 -0800 Received: from mail.pha.ha-vel.cz (mail.pha.ha-vel.cz [195.39.72.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQJ3Mo16525 for ; Mon, 26 Nov 2001 11:03:22 -0800 Received: (qmail 27694 invoked from network); 26 Nov 2001 18:03:19 -0000 Received: from twilight.ucw.cz (HELO twilight.suse.cz) (root@195.39.74.230) by mail.pha.ha-vel.cz with SMTP; 26 Nov 2001 18:03:19 -0000 Received: (from vojtech@localhost) by twilight.suse.cz (8.10.2/8.9.3) id fAQI3JW27682; Mon, 26 Nov 2001 19:03:19 +0100 Date: Mon, 26 Nov 2001 19:03:19 +0100 From: Vojtech Pavlik To: Jeff Garzik Cc: Brad Hards , netdev@oss.sgi.com, becker@scyld.com Subject: Re: [patch] Link state reporting Message-ID: <20011126190319.A27663@suse.cz> References: <3C0234A5.767256DF@bigpond.net.au> <3C02822D.6E103FAD@mandrakesoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C02822D.6E103FAD@mandrakesoft.com>; from jgarzik@mandrakesoft.com on Mon, Nov 26, 2001 at 12:55:57PM -0500 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 769 Lines: 19 On Mon, Nov 26, 2001 at 12:55:57PM -0500, Jeff Garzik wrote: > There is already two ways to report link state to userspace. We do not > need a third. > > First, ETHTOOL_GLINK. Second, netif_carrier_off causes IFF_RUNNING to > disappear when the interface is up. That's from the ethernet point of view. But if I understand correctly, there is no means for the userspace to be notified of a link state *change*. And hotplug is quite the way to do that. I'd like it to report things as they appear and go, be it USB devices, be it PCI/CardBus/PCMCIA devices, be it virtual devices like input ones, it even makes sense for char and blockdevices at the interface-to-userspace layer. And it makes sense for ethernet link status as well ... -- Vojtech Pavlik SuSE Labs From owner-netdev@oss.sgi.com Mon Nov 26 11:14:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQJEnJ16855 for netdev-outgoing; Mon, 26 Nov 2001 11:14:49 -0800 Received: from imf07bis.bellsouth.net (mail207.mail.bellsouth.net [205.152.58.147]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQJEjo16852 for ; Mon, 26 Nov 2001 11:14:45 -0800 Received: from mandrakesoft.com ([208.63.170.233]) by imf07bis.bellsouth.net (InterMail vM.5.01.01.01 201-252-104) with ESMTP id <20011126181547.CCNI8736.imf07bis.bellsouth.net@mandrakesoft.com>; Mon, 26 Nov 2001 13:15:47 -0500 Message-ID: <3C02868E.F53EB0A7@mandrakesoft.com> Date: Mon, 26 Nov 2001 13:14:38 -0500 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.15-pre7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Vojtech Pavlik CC: Brad Hards , netdev@oss.sgi.com, becker@scyld.com Subject: Re: [patch] Link state reporting References: <3C0234A5.767256DF@bigpond.net.au> <3C02822D.6E103FAD@mandrakesoft.com> <20011126190319.A27663@suse.cz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 841 Lines: 25 Vojtech Pavlik wrote: > > On Mon, Nov 26, 2001 at 12:55:57PM -0500, Jeff Garzik wrote: > > > There is already two ways to report link state to userspace. We do not > > need a third. > > > > First, ETHTOOL_GLINK. Second, netif_carrier_off causes IFF_RUNNING to > > disappear when the interface is up. > > That's from the ethernet point of view. But if I understand correctly, > there is no means for the userspace to be notified of a link state > *change*. Userspace can be notified if you poll ETHTOOL_GLINK. If you want notification immediately upon state change, netlink is the way to do this. That is the plan for 2.5, but it has not been implemented yet. Patches welcome. -- Jeff Garzik | Only so many songs can be sung Building 1024 | with two lips, two lungs, and one tongue. MandrakeSoft | - nomeansno From owner-netdev@oss.sgi.com Mon Nov 26 11:21:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQJLDS17191 for netdev-outgoing; Mon, 26 Nov 2001 11:21:13 -0800 Received: from mail.pha.ha-vel.cz (mail.pha.ha-vel.cz [195.39.72.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQJL9o17188 for ; Mon, 26 Nov 2001 11:21:09 -0800 Received: (qmail 24632 invoked from network); 26 Nov 2001 16:52:18 -0000 Received: from twilight.ucw.cz (HELO twilight.suse.cz) (root@195.39.74.230) by mail.pha.ha-vel.cz with SMTP; 26 Nov 2001 16:52:18 -0000 Received: (from vojtech@localhost) by twilight.suse.cz (8.10.2/8.9.3) id fAQGqHP26915; Mon, 26 Nov 2001 17:52:17 +0100 Date: Mon, 26 Nov 2001 17:52:17 +0100 From: Vojtech Pavlik To: David Brownell Cc: Brad Hards , netdev@oss.sgi.com, becker@scyld.com Subject: Re: [patch] Link state reporting Message-ID: <20011126175217.A26905@suse.cz> References: <3C0234A5.767256DF@bigpond.net.au> <0d5601c1769a$0dad8000$6800000a@brownell.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0d5601c1769a$0dad8000$6800000a@brownell.org>; from david-b@pacbell.net on Mon, Nov 26, 2001 at 08:47:35AM -0800 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 783 Lines: 24 On Mon, Nov 26, 2001 at 08:47:35AM -0800, David Brownell wrote: > How about simpler reporting and labeling? > Specifically: > > - single header line, "interface status\n" (or none) > - simpler status: "%s %s\n", dev->name and "up" or"down > > Easier for programs to work with that way. Example: > the "ifup" scripts for "usbnet" links would be simpler, > at least for the links that can detect peer presence. > (It's likely too much to change just now to tristate > status: up, down, and "can't tell".) > > Leading to an issue I've raised before: don't we need > to see more active link state reporting too? Along > the lines of running "/sbin/hotplug net up" (or down) > to report INTERFACE= going up or down. Yes, that's needed, too. -- Vojtech Pavlik SuSE Labs From owner-netdev@oss.sgi.com Tue Nov 27 12:51:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARKpqO30930 for netdev-outgoing; Tue, 27 Nov 2001 12:51:52 -0800 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARKpio30926 for ; Tue, 27 Nov 2001 12:51:44 -0800 Received: from marajade.sandelman.ottawa.on.ca ([2001:410:402:2:204:76ff:fe2d:8c]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id fARJntR27044 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Tue, 27 Nov 2001 14:51:11 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.6/8.11.0) with ESMTP id fARJiGv01467; Tue, 27 Nov 2001 14:44:18 -0500 (EST) Message-Id: <200111271944.fARJiGv01467@marajade.sandelman.ottawa.on.ca> To: netdev@oss.sgi.com, design@lists.freeswan.org Subject: Re: what pointers does pskb_may_pull() nuke? In-reply-to: Your message of "Sun, 25 Nov 2001 20:29:43 GMT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 27 Nov 2001 14:44:16 -0500 From: Michael Richardson Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2645 Lines: 67 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Julian" == Julian Anastasov writes: Julian> pskb_may_pull does not assemble all fragments, even after Julian> ip_defrag you have to call skb_linearize if the skb is still Julian> non-linear, i.e. something like: Julian> // not needed in LOCAL_IN: Julian> if (skb->nh.iph->frag_off & htons(IP_MF|IP_OFFSET)) { Julian> skb = ip_defrag(skb); Julian> if (!skb) Julian> return NF_STOLEN; Julian> *skb_p = skb; Julian> } Do I really need to this? I'm a transport protocol (i.e. above IP, like TCP) in this context, not a net filter module. Julian> if (skb_is_nonlinear(skb)) { Julian> if (skb_linearize(skb, GFP_ATOMIC) != 0) Julian> return NF_DROP; Julian> ip_send_check(skb->nh.iph); // Not needed for local delivery Julian> } Can I just call skb_linearize()? Julian> Then after *_may_pull (or any other functions that move the Julian> data) you have to base everything on skb->nh.iph and to create your Julian> own h.raw and other pointers. If skb->nh.iph is correct, then I don't care about the other stuff. >> It appears that we never enabled it, not is it clear when we should :-) Julian> Hm, are you sure it is not enabled? I don't know how you are Julian> using skb->data in the protocol handlers as pointer to iphdr after 2.4.4 Is IPH_is_SKB_PULLED set by some other part of the system? Julian> If in doubt, don't use skb->h.raw in your calcs, base Julian> everything on nh.raw (more portable for local delivery) okay. Julian> While we played with sk_buffs during the Linux Virtual Server Julian> port we didn't found any docs. If you can't find any docs or don't Julian> have other options feel free to contact me directly. thanks. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPAPtCoqHRg3pndX9AQHy6AP/XJqgp7tFUIXGz+SPCtRBKA6dTjBVMTQz XAwEdh9DYnkqwUfr/Ff06vwxielILC0JD+o1Q5iQ22GqHG8dtPEw2Gm86Ft3RHA8 cm5yLktGwrMqMvPVwF2fTgmPuf00aXqGxOg7txvYj74R1dWjjaekoJmtCKOMXg5f ULvuQuadhLU= =seQv -----END PGP SIGNATURE----- From owner-netdev@oss.sgi.com Tue Nov 27 13:46:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARLk6q32069 for netdev-outgoing; Tue, 27 Nov 2001 13:46:06 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARLk0o32066 for ; Tue, 27 Nov 2001 13:46:00 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 146091E5DA; Tue, 27 Nov 2001 21:45:54 +0100 (MET) Date: Tue, 27 Nov 2001 21:45:51 +0100 From: Andi Kleen To: Michael Richardson Cc: netdev@oss.sgi.com, design@lists.freeswan.org Subject: Re: what pointers does pskb_may_pull() nuke? Message-ID: <20011127214551.A23804@wotan.suse.de> References: <200111271944.fARJiGv01467@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i In-Reply-To: <200111271944.fARJiGv01467@marajade.sandelman.ottawa.on.ca>; from mcr@sandelman.ottawa.on.ca on Tue, Nov 27, 2001 at 02:44:16PM -0500 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2147 Lines: 58 On Tue, Nov 27, 2001 at 02:44:16PM -0500, Michael Richardson wrote: > Julian> // not needed in LOCAL_IN: > Julian> if (skb->nh.iph->frag_off & htons(IP_MF|IP_OFFSET)) { > Julian> skb = ip_defrag(skb); > Julian> if (!skb) > Julian> return NF_STOLEN; > Julian> *skb_p = skb; > Julian> } > > Do I really need to this? I'm a transport protocol (i.e. above IP, like > TCP) in this context, not a net filter module. As protocol you don't. > > Julian> if (skb_is_nonlinear(skb)) { > Julian> if (skb_linearize(skb, GFP_ATOMIC) != 0) > Julian> return NF_DROP; > Julian> ip_send_check(skb->nh.iph); // Not needed for local delivery > Julian> } > > Can I just call skb_linearize()? Yes. > > Julian> Then after *_may_pull (or any other functions that move the > Julian> data) you have to base everything on skb->nh.iph and to create your > Julian> own h.raw and other pointers. > > If skb->nh.iph is correct, then I don't care about the other stuff. It should be correct at protocol level. > > >> It appears that we never enabled it, not is it clear when we should :-) > > Julian> Hm, are you sure it is not enabled? I don't know how you are > Julian> using skb->data in the protocol handlers as pointer to iphdr after 2.4.4 > > Is IPH_is_SKB_PULLED set by some other part of the system? It is not a linux symbol. > Julian> While we played with sk_buffs during the Linux Virtual Server > Julian> port we didn't found any docs. If you can't find any docs or don't > Julian> have other options feel free to contact me directly. > > thanks. There is only Alan Cox's outdated document on (pre zerocopy linear) skbs. It gives the basics which are still mostly correct modulo the changes for non linear skbs. You'll likely find it somewhere on http://www.linux.org.uk A new one should be probably written or included as inline docs that covers skb_linearize(), pskb_* et.al. too. -Andi From owner-netdev@oss.sgi.com Tue Nov 27 15:34:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARNYNt02626 for netdev-outgoing; Tue, 27 Nov 2001 15:34:23 -0800 Received: from u.domain.uli (ja.mac.ssi.bg [212.95.166.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARNYGo02623 for ; Tue, 27 Nov 2001 15:34:16 -0800 Received: from localhost (IDENT:ja@localhost [127.0.0.1]) by u.domain.uli (8.11.0/8.11.0) with ESMTP id fAS0Wjd01351; Wed, 28 Nov 2001 00:32:45 GMT Date: Wed, 28 Nov 2001 00:32:45 +0000 (GMT) From: Julian Anastasov X-X-Sender: To: Michael Richardson cc: , Subject: Re: what pointers does pskb_may_pull() nuke? In-Reply-To: <200111271944.fARJiGv01467@marajade.sandelman.ottawa.on.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1542 Lines: 50 Hello, On Tue, 27 Nov 2001, Michael Richardson wrote: > Julian> if (skb_is_nonlinear(skb)) { > Julian> if (skb_linearize(skb, GFP_ATOMIC) != 0) > Julian> return NF_DROP; > Julian> ip_send_check(skb->nh.iph); // Not needed for local delivery > Julian> } > > Can I just call skb_linearize()? It is safe but without checking with skb_is_nonlinear skb_linearize will copy the data always (even for non-fragmented packets). So, you can use such code: if (skb_is_nonlinear(skb) && skb_linearize(skb, GFP_ATOMIC) != 0) return NF_DROP; Then you have read access to data but write access (IMO, you don't need it) is still not guaranteed if the packet was not fragmented. Why do you need to skip the check? It is a short inline function that will save you so many CPU cycles with most of the packets, i.e. for the common case where the packet is not fragmented. > Julian> Hm, are you sure it is not enabled? I don't know how you are > Julian> using skb->data in the protocol handlers as pointer to iphdr after 2.4.4 > > Is IPH_is_SKB_PULLED set by some other part of the system? I see it in your own code, not in kernel: lib/freeswan.h (1.91) #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,4) #define IP_SELECT_IDENT_NEW #define IPH_is_SKB_PULLED ... but you better know it. IMO, this code should be really enabled because in the other case skb->data will be used wrongly in ipsec_rcv(). Regards -- Julian Anastasov From owner-netdev@oss.sgi.com Tue Nov 27 15:50:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARNobc02989 for netdev-outgoing; Tue, 27 Nov 2001 15:50:37 -0800 Received: from u.domain.uli (ja.mac.ssi.bg [212.95.166.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARNoXo02986 for ; Tue, 27 Nov 2001 15:50:33 -0800 Received: from localhost (IDENT:ja@localhost [127.0.0.1]) by u.domain.uli (8.11.0/8.11.0) with ESMTP id fAS0njd01391; Wed, 28 Nov 2001 00:49:45 GMT Date: Wed, 28 Nov 2001 00:49:45 +0000 (GMT) From: Julian Anastasov X-X-Sender: To: Michael Richardson cc: , Subject: Re: what pointers does pskb_may_pull() nuke? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 367 Lines: 20 Hello, On Wed, 28 Nov 2001, Julian Anastasov wrote: > On Tue, 27 Nov 2001, Michael Richardson wrote: > > > Can I just call skb_linearize()? > > if (skb_is_nonlinear(skb) && skb_linearize(skb, GFP_ATOMIC) != 0) > return NF_DROP; and, of course, don't return exactly NF_DROP (just drop skb and return 0, you know...) Regards -- Julian Anastasov