From owner-netdev@oss.sgi.com Wed May 1 11:00:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41I0kwJ029700 for ; Wed, 1 May 2002 11:00:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41I0jkn029699 for netdev-outgoing; Wed, 1 May 2002 11:00:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from mailrelay2.inwind.it (mailrelay2.inwind.it [212.141.54.102]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41I0WwJ029694 for ; Wed, 1 May 2002 11:00:41 -0700 Message-Id: <200205011800.g41I0WwJ029694@oss.sgi.com> Received: from there (62.98.199.51) by mailrelay2.inwind.it (6.5.015) id 3CAA382B0126CA3D for netdev@oss.sgi.com; Wed, 1 May 2002 19:19:21 +0200 Content-Type: text/plain; charset="iso-8859-15" From: d_vangreg Organization: N/A To: netdev@oss.sgi.com Subject: kern-25-net-core-bug Date: Wed, 1 May 2002 19:22:07 +0200 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-netdev@oss.sgi.com Precedence: bulk --> jgarzik@mandrakesoft.com --> pavel@atrey.karlin.mff.cuni.cz --> netdev@oss.sgi.com kernel-2.5.11 & kernel-2.4.12 Bug-REPORT(net-core-dev) Action: kernel-compilation from sources. "make bzImage" stopped in error at: net/core/dev.c: 1465 .. using return value of function declared void ... I guessed (as errata): ret=handle_diverter(skb); & tried (as corrige): handle_diverter(skb); it worked: bzImage did compile, but I'm not sure this was the correct solution. System=Linux-Slakware-8.0 arch=i386 (CPU=athlon) compile-tools: gcc-3.0.4, glibc-2.2.5 GUI: KDE-3.0b2 END REPORT Sender: From owner-netdev@oss.sgi.com Wed May 1 11:34:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g41IYjwJ030898 for ; Wed, 1 May 2002 11:34:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g41IYjfg030897 for netdev-outgoing; Wed, 1 May 2002 11:34:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from loewe.cosy.sbg.ac.at (loewe.cosy.sbg.ac.at [141.201.2.12]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g41IYfwJ030894 for ; Wed, 1 May 2002 11:34:42 -0700 Received: from mausmaki.cosy.sbg.ac.at (mausmaki.cosy.sbg.ac.at [141.201.2.18]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id UAA18734; Wed, 1 May 2002 20:35:37 +0200 (MET DST) Date: Wed, 1 May 2002 20:35:37 +0200 (MET DST) From: "Thomas 'Dent' Mirlacher" To: d_vangreg cc: netdev@oss.sgi.com Subject: Re: kern-25-net-core-bug In-Reply-To: <200205011800.g41I0WwJ029694@oss.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk --snip/snip > I guessed (as errata): ret=handle_diverter(skb); > > & tried (as corrige): handle_diverter(skb); well, a cleaner thing would be to set ret=0 or ret= ... but on the other hand, the return value for netif_receive_skb isn't checked (at least in process_backlog) btw. is someone auditing the network code? - like check all return values from functions which could fail. ++dent -- in some way i do, and in some way i don't. From owner-netdev@oss.sgi.com Thu May 2 15:55:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g42MtEwJ024602 for ; Thu, 2 May 2002 15:55:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g42MtEUD024601 for netdev-outgoing; Thu, 2 May 2002 15:55:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g42MtBwJ024598 for ; Thu, 2 May 2002 15:55:11 -0700 From: "Xiaoning He" To: Subject: Neighbor cache Date: Thu, 2 May 2002 15:54:16 -0700 Message-ID: <000001c1f22c$4a894f00$4e6015ac@VAIO> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi All I have a question related to the Neighbor cache. I am currently trying to modify the neighbor cache but I can not find where the code in the IPv6 kernel. Could you please let me know in the IPv6 kernel, where the Neighbor cache is maintained and which file contains them? Thank you very much. Xiaoning He From owner-netdev@oss.sgi.com Thu May 2 17:10:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g430AEwJ025223 for ; Thu, 2 May 2002 17:10:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g430AE0A025222 for netdev-outgoing; Thu, 2 May 2002 17:10:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g430A5wJ025217; Thu, 2 May 2002 17:10:06 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g430AooB029324; Thu, 2 May 2002 20:10:50 -0400 Received: from d03nm801.boulder.ibm.com (d03nm801.boulder.ibm.com [9.17.194.244]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g430Amb239108; Thu, 2 May 2002 18:10:48 -0600 Subject: Re: Neighbor cache To: "Xiaoning He" Cc: netdev@oss.sgi.com, owner-netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Krishna Kumar" Date: Thu, 2 May 2002 17:07:20 -0700 X-MIMETrack: Serialize by Router on D03NM801/03/M/IBM(Release 5.0.9 |November 16, 2001) at 05/02/2002 06:10:48 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Look for "struct neighbour" and "struct neigh_table" in neighbour.h and it's usage. Functions are neigh_lookup(), neigh_create(), neigh_destroy(), etc. - KK "Xiaoning He" bs-usa.com> cc: Sent by: Subject: Neighbor cache owner-netdev@oss.s gi.com 05/02/2002 03:54 PM Hi All I have a question related to the Neighbor cache. I am currently trying to modify the neighbor cache but I can not find where the code in the IPv6 kernel. Could you please let me know in the IPv6 kernel, where the Neighbor cache is maintained and which file contains them? Thank you very much. Xiaoning He From owner-netdev@oss.sgi.com Thu May 2 17:52:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g430qZwJ025480 for ; Thu, 2 May 2002 17:52:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g430qZN8025479 for netdev-outgoing; Thu, 2 May 2002 17:52:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from yue.hongo.wide.ad.jp (root@yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g430qTwJ025476 for ; Thu, 2 May 2002 17:52:32 -0700 Received: from localhost (yoshfuji@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 JAA07559; Fri, 3 May 2002 09:54:02 +0900 To: xiaoning@docomolabs-usa.com Cc: netdev@oss.sgi.com Subject: Re: Neighbor cache In-Reply-To: <000001c1f22c$4a894f00$4e6015ac@VAIO> References: <000001c1f22c$4a894f00$4e6015ac@VAIO> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (AOI) X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020503095402W.yoshfuji@wide.ad.jp> Date: Fri, 03 May 2002 09:54:02 +0900 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= X-Dispatcher: imput version 991025(IM133) Lines: 11 Sender: owner-netdev@oss.sgi.com Precedence: bulk In article <000001c1f22c$4a894f00$4e6015ac@VAIO> (at Thu, 2 May 2002 15:54:16 -0700), "Xiaoning He" says: > > Could you please let me know in the IPv6 kernel, where the Neighbor > cache is maintained and which file contains them? net/core/neighbour.c -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From owner-netdev@oss.sgi.com Fri May 3 07:10:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g43EA3wJ013244 for ; Fri, 3 May 2002 07:10:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g43EA3Xj013243 for netdev-outgoing; Fri, 3 May 2002 07:10:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from resolver.webbskolan.com (resolver.webbskolan.com [195.22.79.6]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g43E9uwJ013233 for ; Fri, 3 May 2002 07:09:57 -0700 Received: from oskar (veruca.webbskolan.com [195.22.79.46]) by resolver.webbskolan.com (8.10.1/8.10.1) with SMTP id g43EE3h23992 for ; Fri, 3 May 2002 16:14:04 +0200 (CEST) Message-ID: <10d601c1f2ab$ee7b6c40$6501a8c0@multisofteducation.com> From: "Oskar Andreasson" To: Subject: [possibly O-T] ip-sysctl calls and a few questions. Date: Fri, 3 May 2002 16:07:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g43E9wwJ013234 Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi All, I hope this is no intrusion to this list or that it is off-topic, however, I will try to keep it as much to the core ipv4 area as possible. If you do respond, please CC replies directly to me since I am not on the list. First off, I'm working on a larger document which contains a reference to all ipv4 sysctl calls available in linux. The reference part of the document is heavily based upon linux/Documentation/networking/ip-sysctl.txt document written by various writers, as it looks now. The main problem is that I have quite a problem understanding the behaviours of some variables/sysctl calls, and what they do. I will (try to :-)) briefly sum up all questions I have at this moment below: ip_nonlocal_bind - how does this affect the ip stack? How and why will it break certain applications (according to ip-sysctl.txt)? A possible scenario when it may be used? INET peer storage - one of the subtopics from the ip-sysctl.txt. What does this refer to? ARP tables and storage I assume, but I am not 100% sure? Would anyone care to give a very very brief explanation to this "section" and why a specific subsection on this in the document, but not tcp_max_syn_backlog - I haven't looked in the source code for this one myself, but the default values listed in the ip-sysctl.txt document are faulty in comparison to the default values I get on my own systems. Are these calculated at boot time, or is the document simply old? tcp_fack - Does this variable turn on Fast Acknowledgement, and if so, in which RFC is this documented? RFC 2018, 2883 or some other? tcp_reordering - What does it mean? How does it work? Is there any RFC documenting this and what the default behaviour should be? tcp_adv_win_scale - I can say nothing but "hmmm" about the explanation in the ip-sysctl.txt document, and I understand pretty much nothing from what I've read in the source, though I haven't even tried very much so far. What do the different equations do as specified in ip-sysctl.txt? What do the variables used in them mean? Perhaps I'm just dumb or something :-). icmp_ratelimit icmp_ratemask - Both these are interconnected afaik, but they are not listed in the ip-sysctl.txt (seems they override the old variables that where available). From what I understand, ratemask tells which ICMP types (and codes?) are specified, and if to ratelimit these. How is this mask calculated? How is the ratelimit set, and in what measurement? Those are the questions I have for now.. Sorry for the massive amount of questions, but I have collected them for a week or so :-). I really really hope this is not offtopic for this list and that noone will get too annoyed over the questions and that someone is able to reply to them. Have nice day, Oskar Andreasson http://www.boingworld.com http://people.unix-fu.org/andreasson/ mailto: blueflux@koffein.net PS. I will be gone over the weekend so there is no rush with any replies really, just thought I'd get them away before the list of questions grows too large. DS. From owner-netdev@oss.sgi.com Fri May 3 09:35:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g43GZCwJ026212 for ; Fri, 3 May 2002 09:35:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g43GZCmL026211 for netdev-outgoing; Fri, 3 May 2002 09:35:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g43GZ4wJ026208 for ; Fri, 3 May 2002 09:35:04 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g43Ga2oB056910; Fri, 3 May 2002 12:36:02 -0400 Received: from d03nm035.boulder.ibm.com (d03nm035.boulder.ibm.com [9.17.194.35]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g43GZvW80306; Fri, 3 May 2002 10:35:57 -0600 From: "Nivedita Singhvi" Importance: Normal Sensitivity: Subject: Re: [possibly O-T] ip-sysctl calls and a few questions. To: "Oskar Andreasson" Cc: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Fri, 3 May 2002 09:31:46 -0700 X-MIMETrack: Serialize by Router on D03NM035/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/03/2002 10:35:57 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk > First off, I'm working on a larger document which contains > a reference to all ipv4 sysctl calls available in linux. > The reference part of the document is heavily based upon > linux/Documentation/networking/ip-sysctl.txt document written > by various writers, as it looks now. The main problem is that > I have quite a problem understanding the behaviours of some > variables/sysctl calls, and what they do. Thats good! I've just updated the TCP man page with the TCP sysctls. Will send it out shortly, that will cover some of your questions below, but I thought I'd send a brief response now: > I will (try to :-)) briefly sum up all questions I have at > this moment below: > tcp_max_syn_backlog - I haven't looked in the source code for > this one myself, but the default values listed in the > ip-sysctl.txt document are faulty in comparison to the default > values I get on my own systems. Are these calculated at boot > time, or is the document simply old? The default val is 256 - but is adjusted at boot time depending on memory available in the system (1024 if > 128MB). > tcp_fack - Does this variable turn on Fast Acknowledgement, > and if so, in which RFC is this documented? RFC 2018, 2883 > or some other? Forward Acknowledgement. Not an RFC - but there is a paper, Alexey might have to confirm that..I'll add a ptr to it.. > tcp_reordering - What does it mean? How does it work? > Is there any RFC documenting this and what the default behaviour > should be? Again, no RFC. Its a mechanism to detect the reordering of packets and avoid unnecessary retransmission and back off.. > tcp_adv_win_scale - I can say nothing but "hmmm" about the > explanation in the ip-sysctl.txt document, and I understand > pretty much nothing from what I've read in the source, though > I haven't even tried very much so far. What do the different > equations do as specified in ip-sysctl.txt? What do the variables > used in them mean? Perhaps I'm just dumb or something :-). It determines how to share the buffer space between the application and the kernel - if the default is 2, the buffering overhead (system space is one fourth of the buffer... > Those are the questions I have for now.. Sorry for the massive amount > of questions, but I have collected them for a week or so :-). > I really really hope this is not offtopic for this list and that noone > will get too annoyed over the questions and that someone is able to > reply to them. thanks, Nivedita From owner-netdev@oss.sgi.com Sun May 5 08:41:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g45FfEwJ000428 for ; Sun, 5 May 2002 08:41:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g45FfEkP000427 for netdev-outgoing; Sun, 5 May 2002 08:41:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from luxik.cdi.cz (root@inway106.cdi.cz [213.151.81.106]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g45Ff7wJ000415 for ; Sun, 5 May 2002 08:41:08 -0700 Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 174O8V-0003hW-00; Sun, 05 May 2002 17:41:20 +0200 Date: Sun, 5 May 2002 17:41:19 +0200 (CEST) From: Martin Devera To: kuznet@ms2.inr.ac.ru cc: netdev@oss.sgi.com Subject: PSCHED_TDIFF_SAFE bug introduced in 2.4.19-pre5 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello Alexey, from this: - long __delta = (tv1) - (tv2); \ - if ( __delta > (bound)) { __delta = (bound); guard; } \ + long long __delta = (tv1) - (tv2); \ + if ( __delta > (long long)(bound)) { __delta = (bound); guard; } \ (02/03/19 1.181.2.12) Make pkt_sched.h:PSCHED_TDIFF_SAFE behave sane when measuring I think you are responsible for the change. I hope it wasn't me who suggested this change ;) Old code was ok in sense that in CBQ you used unsigned bound. Then the diff was safe even if tv1 (long long)(bound)) { __delta = (bound); guard; + long __delta = (tv1) - (tv2); \ + if ( __delta > (u32)(bound)) { __delta = (bound); guard; } \ Here the return value will be always positive and < bound. any objections ? devik From owner-netdev@oss.sgi.com Tue May 7 11:01:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47I1EwJ003898 for ; Tue, 7 May 2002 11:01:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47I1Et1003897 for netdev-outgoing; Tue, 7 May 2002 11:01:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from smtp-4.hut.fi (root@smtp-4.hut.fi [130.233.228.94]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47I1AwJ003894 for ; Tue, 7 May 2002 11:01:11 -0700 Received: from kosh.hut.fi (kosh.hut.fi [130.233.228.10]) by smtp-4.hut.fi (8.12.3/8.12.3) with ESMTP id g47I2VkG004343 for ; Tue, 7 May 2002 21:02:31 +0300 Received: from localhost (dima@localhost) by kosh.hut.fi (8.9.3/8.9.3) with ESMTP id VAA04139 for ; Tue, 7 May 2002 21:02:31 +0300 (EET DST) X-Authentication-Warning: kosh.hut.fi: dima owned process doing -bs Date: Tue, 7 May 2002 21:02:31 +0300 (EET DST) From: Dmitrii Tisnek To: Subject: packet socket can't steal packets Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 679 Lines: 18 hey, I've been trying to change certain network packet mangling software such that it would not need a kernel module, and it seems to me that, unfortunately there's no way to make packet socket "steal" packets it deliveres to the user mode. The behaviour I see is it gives userland a copy and give the native network stack a copy. unless I missed something, perhaps there could be an ioctl/setsockopt which would turn this behaviour into "pass packet to user mode or drop altogether" that would never result in network stack getting a packet directly. I realise same functionality can be achieved through netfilter QUEUE command, but that doesn't seem as nice. cheers, dima From owner-netdev@oss.sgi.com Tue May 7 11:15:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47IFBwJ004158 for ; Tue, 7 May 2002 11:15:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47IFBU5004157 for netdev-outgoing; Tue, 7 May 2002 11:15:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from loewe.cosy.sbg.ac.at (loewe.cosy.sbg.ac.at [141.201.2.12]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47IF5wJ004154 for ; Tue, 7 May 2002 11:15:06 -0700 Received: from mausmaki.cosy.sbg.ac.at (mausmaki.cosy.sbg.ac.at [141.201.2.18]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id UAA27308; Tue, 7 May 2002 20:16:27 +0200 (MET DST) Date: Tue, 7 May 2002 20:16:27 +0200 (MET DST) From: "Thomas 'Dent' Mirlacher" To: Dmitrii Tisnek cc: netdev@oss.sgi.com Subject: Re: packet socket can't steal packets 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: 951 Lines: 28 On Tue, 7 May 2002, Dmitrii Tisnek wrote: > hey, I've been trying to change certain network packet mangling software > such that it would not need a kernel module, and it seems to me that, > unfortunately there's no way to make packet socket "steal" packets it > deliveres to the user mode. > > The behaviour I see is it gives userland a copy and give the native > network stack a copy. right - take a look at net/core/dev.c netif_receive_skb. > unless I missed something, perhaps there could be an ioctl/setsockopt > which would turn this behaviour into "pass packet to user mode or drop > altogether" that would never result in network stack getting a packet > directly. well, that would be nice for certain applications, but wouldn't it also be a security problem? ... well there would be a way how you could implement this kind of feature now, but you need to write a module also :( ++dent -- in some way i do, and in some way i don't. From owner-netdev@oss.sgi.com Tue May 7 11:27:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47IRgwJ004431 for ; Tue, 7 May 2002 11:27:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47IRgZx004430 for netdev-outgoing; Tue, 7 May 2002 11:27:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from smtp-4.hut.fi (root@smtp-4.hut.fi [130.233.228.94]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47IRcwJ004427 for ; Tue, 7 May 2002 11:27:39 -0700 Received: from kosh.hut.fi (kosh.hut.fi [130.233.228.10]) by smtp-4.hut.fi (8.12.3/8.12.3) with ESMTP id g47ISxkG005027; Tue, 7 May 2002 21:28:59 +0300 Received: from localhost (dima@localhost) by kosh.hut.fi (8.9.3/8.9.3) with ESMTP id VAA31406; Tue, 7 May 2002 21:28:59 +0300 (EET DST) X-Authentication-Warning: kosh.hut.fi: dima owned process doing -bs Date: Tue, 7 May 2002 21:28:59 +0300 (EET DST) From: Dmitrii Tisnek To: "Thomas 'Dent' Mirlacher" cc: Subject: Re: packet socket can't steal packets 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: 599 Lines: 19 On Tue, 7 May 2002, Thomas 'Dent' Mirlacher wrote: > > > unless I missed something, perhaps there could be an ioctl/setsockopt > > which would turn this behaviour into "pass packet to user mode or drop > > altogether" that would never result in network stack getting a packet > > directly. > > well, that would be nice for certain applications, but wouldn't it > also be a security problem? no. read-only access to network traffic already requires priviledges. and theres' already a way to insert packets via socket send/write. all I'm proposing is a way to "delete" packets too. cheers, dima. From owner-netdev@oss.sgi.com Tue May 7 11:38:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47IcKwJ004618 for ; Tue, 7 May 2002 11:38:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47IcJ5G004617 for netdev-outgoing; Tue, 7 May 2002 11:38:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from loewe.cosy.sbg.ac.at (loewe.cosy.sbg.ac.at [141.201.2.12]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47IcDwJ004614 for ; Tue, 7 May 2002 11:38:14 -0700 Received: from mausmaki.cosy.sbg.ac.at (mausmaki.cosy.sbg.ac.at [141.201.2.18]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id UAA27995; Tue, 7 May 2002 20:39:35 +0200 (MET DST) Date: Tue, 7 May 2002 20:39:35 +0200 (MET DST) From: "Thomas 'Dent' Mirlacher" To: Dmitrii Tisnek cc: netdev@oss.sgi.com Subject: Re: packet socket can't steal packets 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: 1315 Lines: 39 On Tue, 7 May 2002, Dmitrii Tisnek wrote: > On Tue, 7 May 2002, Thomas 'Dent' Mirlacher wrote: > > > > > unless I missed something, perhaps there could be an ioctl/setsockopt > > > which would turn this behaviour into "pass packet to user mode or drop > > > altogether" that would never result in network stack getting a packet > > > directly. > > > > well, that would be nice for certain applications, but wouldn't it > > also be a security problem? > > no. > > read-only access to network traffic already requires priviledges. > and theres' already a way to insert packets via socket send/write. seen from this perspective you're right. and seen from the perspective that the kernel should provide functionality and the user/admin is responsible for restricting this access, you're right too. > all I'm proposing is a way to "delete" packets too. well you've a problem here: 1) how can you be sure you're the first one to see that packet? what about two applications which want to do the same thing? should tcpdump (on the local machine of course :) see the packet at all? and the really minor problem is, you've to change all the protocols which register + af_packet to return an NET_RX_DONTCARE instead of NET_RX_DROP. just my $0.02 ++dent -- in some way i do, and in some way i don't. From owner-netdev@oss.sgi.com Wed May 8 07:16:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g48EGvwJ029458 for ; Wed, 8 May 2002 07:16:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g48EGvFQ029457 for netdev-outgoing; Wed, 8 May 2002 07:16:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from ratula.moonlight.se (c49.ryd.student.liu.se [130.236.234.49]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g48EGpwJ029454 for ; Wed, 8 May 2002 07:16:52 -0700 Received: (qmail 4659 invoked by uid 1000); 3 Jan 1990 20:25:00 -0000 Date: Wed, 3 Jan 1990 21:25:00 +0100 From: Carl-Johan Bostorp To: netdev@oss.sgi.com Subject: Re: packet socket can't steal packets Message-ID: <19900103212500.A4614@ratula.chimaira.se> Mail-Followup-To: Carl-Johan Bostorp , netdev@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from dima@cc.hut.fi on Tue, May 07, 2002 at 09:02:31PM +0300 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1048 Lines: 29 On Tue, May 07, 2002 at 09:02:31PM +0300, Dmitrii Tisnek wrote: > hey, I've been trying to change certain network packet mangling software > such that it would not need a kernel module, and it seems to me that, > unfortunately there's no way to make packet socket "steal" packets it > deliveres to the user mode. "Divert Sockets for Linux" springs to my mind.. http://www.anr.mcnc.org/~divert/index.shtml --- Divert sockets enable both IP packet interception and injection on the end-hosts as well as on routers. Interception and injection happen at the IP layer. The intercepted packets are diverted to sockets in the user space, thus they will not be able to reach their destination unless they are reinjected by the user space sockets. This allows different tricks (e.g., routing and firewall) to be played, outside the operating system kernel, in between the packet interception and reinjection. --- -- ~~~<*>~~~ Web: http://elemental.webservices.se/ ICQ: 3534707 PGP: 0xA6B5C43B IRCnet: ctor ~~~<*>~~~ From owner-netdev@oss.sgi.com Wed May 8 07:40:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g48EeWwJ029986 for ; Wed, 8 May 2002 07:40:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g48EeW7s029985 for netdev-outgoing; Wed, 8 May 2002 07:40:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g48EdZwJ029953 for ; Wed, 8 May 2002 07:39:35 -0700 Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g48Ec4K05338; Wed, 8 May 2002 10:38:04 -0400 (EDT) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KH1XG5GL; Wed, 8 May 2002 10:38:09 -0400 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JZJYRNNT; Wed, 8 May 2002 10:38:27 -0400 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 241415419; Wed, 8 May 2002 09:49:54 -0400 (EDT) Message-ID: <3CD92D01.A4AD708@nortelnetworks.com> Date: Wed, 08 May 2002 09:49:53 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Chris Friesen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Carl-Johan Bostorp Cc: netdev@oss.sgi.com Subject: Re: packet socket can't steal packets References: <19900103212500.A4614@ratula.chimaira.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1064 Lines: 28 Carl-Johan Bostorp wrote: > > On Tue, May 07, 2002 at 09:02:31PM +0300, Dmitrii Tisnek wrote: > > hey, I've been trying to change certain network packet mangling software > > such that it would not need a kernel module, and it seems to me that, > > unfortunately there's no way to make packet socket "steal" packets it > > deliveres to the user mode. > > "Divert Sockets for Linux" springs to my mind.. > > http://www.anr.mcnc.org/~divert/index.shtml Except that the original poster is using the 2.4 kernel, for which divert sockets do not work. For 2.4 the netfilter module is cleanest, followed by netfilter QUEUE to userspace (although this will give a performance hit). When I had to move from 2.2 with divert sockets to 2.4, I used a netfilter module with commandline parameters to pass in arguments. Chris -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com From owner-netdev@oss.sgi.com Thu May 9 02:46:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g499kawJ025492 for ; Thu, 9 May 2002 02:46:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g499kZ8h025491 for netdev-outgoing; Thu, 9 May 2002 02:46:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g499kUwJ025480 for ; Thu, 9 May 2002 02:46:30 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id CAA26659; Thu, 9 May 2002 02:35:27 -0700 Date: Thu, 09 May 2002 02:35:26 -0700 (PDT) Message-Id: <20020509.023526.12918037.davem@redhat.com> To: Robert.Olsson@data.slu.se Cc: kuznet@ms2.inr.ac.ru, hadi@cyberus.ca, netdev@oss.sgi.com, jensl@robur.slu.se Subject: Re: route cache GC monitoring From: "David S. Miller" In-Reply-To: <15561.20004.964497.762468@robur.slu.se> References: <15561.20004.964497.762468@robur.slu.se> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 82 Lines: 3 Sorry for taking so long, I've added your patch to both 2.4.x and 2.5.x, thanks. From owner-netdev@oss.sgi.com Thu May 9 16:07:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g49N78wJ023701 for ; Thu, 9 May 2002 16:07:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g49N78h3023699 for netdev-outgoing; Thu, 9 May 2002 16:07:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g49N73wJ023696 for ; Thu, 9 May 2002 16:07:04 -0700 From: "Xiaoning He" To: Subject: Neighbor cache behavior Date: Thu, 9 May 2002 16:06:37 -0700 Message-ID: <000201c1f7ae$2c5c2110$4f6015ac@VAIO> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <20020503095402W.yoshfuji@wide.ad.jp> Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1090 Lines: 36 Hi all Thank you for answering my previous question about the neighbor cache. I have a couple of more questions regarding the neighbor cache. Would you please give me some help? My understanding about the behavior of neighbor cache is that when a AR receives a packet for a destination, it will Check NC If match, send the packet If not Multicast NS Wait for NA Send the packet Is this the correct behavior? If so, I have looked into the Linux kernel, however, I don't know where in the Linux kernel the code will check the Neighbor. I tried to search the function ndisc_send_ns() because I think that's the function who will handle the sending the NS is there is no entry in the NC. However, it doesn't help. Could anyone provide me with some hints? Also, I think I really need to know the Linux Kernel so that I don't need always ask this kind of question. Is there any good book and tutorial available which can give me a overall picture about how to program the networking program for both user-land and kernel in the Linux? Thank you so much for your help. Xiaoning He From owner-netdev@oss.sgi.com Thu May 9 16:33:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g49NXrwJ027429 for ; Thu, 9 May 2002 16:33:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g49NXr7m027428 for netdev-outgoing; Thu, 9 May 2002 16:33:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from yue.hongo.wide.ad.jp (root@yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g49NXnwJ027425 for ; Thu, 9 May 2002 16:33:50 -0700 Received: from localhost (yoshfuji@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 IAA05344; Fri, 10 May 2002 08:35:58 +0900 To: xiaoning@docomolabs-usa.com Cc: netdev@oss.sgi.com Subject: Re: Neighbor cache behavior In-Reply-To: <000201c1f7ae$2c5c2110$4f6015ac@VAIO> References: <20020503095402W.yoshfuji@wide.ad.jp> <000201c1f7ae$2c5c2110$4f6015ac@VAIO> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (AOI) X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020510083558C.yoshfuji@wide.ad.jp> Date: Fri, 10 May 2002 08:35:58 +0900 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= X-Dispatcher: imput version 991025(IM133) Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 858 Lines: 21 In article <000201c1f7ae$2c5c2110$4f6015ac@VAIO> (at Thu, 9 May 2002 16:06:37 -0700), "Xiaoning He" says: > If so, I have looked into the Linux kernel, however, I don't know where > in the Linux kernel the code will check the Neighbor. I tried to search > the function ndisc_send_ns() because I think that's the function who > will handle the sending the NS is there is no entry in the NC. However, > it doesn't help. skb->dst->output() is the entry to resolve neighbor when sending packets. > Also, I think I really need to know the Linux Kernel so that I don't > need always ask this kind of question. Is there any good book and > tutorial available which can give me a overall picture about how to > program the networking program for both user-land and kernel in the > Linux? keep reading source codes.:-) --yoshfuji From owner-netdev@oss.sgi.com Sun May 12 09:34:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4CGY2wJ011210 for ; Sun, 12 May 2002 09:34:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4CGY2Es011209 for netdev-outgoing; Sun, 12 May 2002 09:34:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from mops.inr.ac.ru (mops.inr.ac.ru [193.233.7.60]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4CGXtwJ011203 for ; Sun, 12 May 2002 09:33:57 -0700 Received: (from kuznet@localhost) by mops.inr.ac.ru (8.6.13/ANK) id UAA01437; Sun, 12 May 2002 20:35:47 +0400 Message-Id: <200205121635.UAA01437@mops.inr.ac.ru> Subject: Re: PSCHED_TDIFF_SAFE bug introduced in 2.4.19-pre5 To: devik@cdi.cz (Martin Devera) Date: Sun, 12 May 2002 20:35:47 +0400 (MSD) Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com In-Reply-To: from "Martin Devera" at May 5, 2 05:41:19 pm From: Alexey Kuznetsov X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 902 Lines: 31 Hello! > I think you are responsible for the change. Yes. > even if tv1 at least with PSCHED_TIME_SOURCE == JIFFIES) No, psched_time_t cannot wrap for our life. > one HTB user switched to 2.4.19-pre7. I think this discipline simply calls the function with tv1 < tv2. In this case the function is supposed to return a negative number and used to do this. Actually, invalid behaviour with unsigned bound was one of bugs fixed. > Here the return value will be always positive and < bound. It must not be positive when tv1 < tv2, psched_diff_t is signed. Well, taking into account that it is not used in current kernel with tv1 < tv2, it can be changed to return 0, but surely not to "bound". I did not see HTB qdisc, but plain logic tells me that otherwise you will see a delay ~bound, when an immediate send is expected instead. Alexey From owner-netdev@oss.sgi.com Sun May 12 12:31:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4CJVSwJ012478 for ; Sun, 12 May 2002 12:31:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4CJVSvm012477 for netdev-outgoing; Sun, 12 May 2002 12:31:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from luxik.cdi.cz (root@inway106.cdi.cz [213.151.81.106]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4CJVOwJ012474 for ; Sun, 12 May 2002 12:31:26 -0700 Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 176z59-0003vj-00; Sun, 12 May 2002 21:32:36 +0200 Date: Sun, 12 May 2002 21:32:35 +0200 (CEST) From: Martin Devera To: Alexey Kuznetsov cc: netdev@oss.sgi.com Subject: Re: PSCHED_TDIFF_SAFE bug introduced in 2.4.19-pre5 In-Reply-To: <200205121635.UAA01437@mops.inr.ac.ru> Message-ID: References: <200205121635.UAA01437@mops.inr.ac.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 349 Lines: 12 > > even if tv1 > at least with PSCHED_TIME_SOURCE == JIFFIES) > > No, psched_time_t cannot wrap for our life. aarrrgh ... oh well I just found the PSCHED_WATCHER logic. Then I'm sorry for my objection - I'll have to add BUG_TRAP(!PSCHED_TLESS(tv1,tv2)) into my code .. Thanks anyway, devik From owner-netdev@oss.sgi.com Tue May 14 01:09:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4E89NnC011411 for ; Tue, 14 May 2002 01:09:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4E89MDg011410 for netdev-outgoing; Tue, 14 May 2002 01:09:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from blackhole.kfki.hu (blackhole.kfki.hu [148.6.0.114]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4E89FnC011407 for ; Tue, 14 May 2002 01:09:16 -0700 Received: by blackhole.kfki.hu (Postfix, from userid 311) id 642C811BD5; Tue, 14 May 2002 10:09:36 +0200 (CEST) Date: Tue, 14 May 2002 10:09:36 +0200 (CEST) From: Jozsef Kadlecsik To: Subject: 2.4.18 and out of window packets Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1793 Lines: 48 Hello, I administer ftp.kfki.hu [148.6.0.24] running Linux 2.4.18 - and wrote the TCP window tracking patch for netfilter. Some guys sent me a mail that they tried to measure the different troughputs by setting different window scale values and using our ftp server as target, but at a given value the transfer stopped completely. Checking our firewall logs I saw that the firewall dropped the packets as out of window ones. 148.6.0.24 runs 2.4.18 with the default TCP settings i.e no window scaling enabled. The other side runs 2.4.18/2.4.19-pre3 with the following setting: echo "4096 895450 1747600" > /proc/sys/net/ipv4/tcp_rmem tcpdumping the traffic on the internal side, the first four packets were: 11:28:34.212520 x.x.x.x.33299 > 148.6.0.24.39413: S [tcp sum ok] 4065695110:4065695110(0) win 5840 (DF) (ttl 44, id 12537, len 60) 11:28:34.212696 148.6.0.24.39413 > x.x.x.x.33299: S [tcp sum ok] 4249346209:4249346209(0) ack 4065695111 win 5792 (DF) (ttl 63, id 0, len 60) 11:28:34.266715 x.x.x.x.33299 > 148.6.0.24.39413: . [tcp sum ok] 4065695111:4065695111(0) ack 4249346210 win 365 (DF) (ttl 44, id 12538, len 52) 11:28:34.267237 148.6.0.24.39413 > x.x.x.x.33299: . 4249346210:4249347658(1448) ack 4065695111 win 5792 (DF) [tos 0x8] (ttl 63, id 7026, len 1500) The fourth packet seems to be truly out of window. How could the problem be fixed? Regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu WWW-Home: http://www.kfki.hu/~kadlec Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary From owner-netdev@oss.sgi.com Tue May 14 10:31:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4EHV6nC006656 for ; Tue, 14 May 2002 10:31:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4EHV5HI006655 for netdev-outgoing; Tue, 14 May 2002 10:31:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from angateway.acceleratednetworks.com ([12.44.127.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4EHV4nC006649 for ; Tue, 14 May 2002 10:31:04 -0700 Received: from CALVIN.acceleratednetworks.com (calvin.acceleratednetworks.com [199.107.109.14]) by angateway.acceleratednetworks.com (8.8.8/8.8.8) with ESMTP id KAA21884 for ; Tue, 14 May 2002 10:21:10 -0700 (PDT) Received: by CALVIN.acceleratednetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 May 2002 10:25:21 -0700 Message-ID: <8B57A2E9423E844C911DF3BC5DB06E500FA146@CALVIN.acceleratednetworks.com> From: Shridhar Kulkarni To: "'netdev@oss.sgi.com'" Subject: iproute2 question Date: Tue, 14 May 2002 10:24:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 470 Lines: 7 i am trying to send "iproute2 get" requests in async fashion to the kernel.....i mean i send a new request to get new route even before i have response to the earlier request...the "route get" implementation in iproute2 library is synchronous...it uses "rtnl_talk" routine and works great...i am breaking it up for my application into "rtnl_send" and "rtnl_recv" for async operation.....but it looks like i dont get responses for some of my requests....any clues ????? From owner-netdev@oss.sgi.com Wed May 15 02:37:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4F9bNnC022154 for ; Wed, 15 May 2002 02:37:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4F9bN5T022153 for netdev-outgoing; Wed, 15 May 2002 02:37:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from castle.nmd.msu.ru (castle.nmd.msu.ru [193.232.112.53]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4F9bJnC022145 for ; Wed, 15 May 2002 02:37:19 -0700 Received: (qmail 697 invoked by uid 577); 15 May 2002 09:46:32 -0000 Message-ID: <20020515134631.A624@castle.nmd.msu.ru> Date: Wed, 15 May 2002 13:46:31 +0400 From: Andrey Savochkin To: Jozsef Kadlecsik , netdev@oss.sgi.com Subject: Re: 2.4.18 and out of window packets References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from "Jozsef Kadlecsik" on Tue, May 14, 2002 at 10:09:36AM Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 988 Lines: 22 On Tue, May 14, 2002 at 10:09:36AM +0200, Jozsef Kadlecsik wrote: > 11:28:34.212520 x.x.x.x.33299 > 148.6.0.24.39413: S [tcp sum ok] > 4065695110:4065695110(0) win 5840 > > (DF) (ttl 44, id 12537, len 60) > 11:28:34.212696 148.6.0.24.39413 > x.x.x.x.33299: S [tcp sum ok] > 4249346209:4249346209(0) ack 4065695111 win 5792 > > (DF) (ttl 63, id 0, len 60) > 11:28:34.266715 x.x.x.x.33299 > 148.6.0.24.39413: . [tcp sum ok] > 4065695111:4065695111(0) ack 4249346210 win 365 > > (DF) (ttl 44, id 12538, len 52) > 11:28:34.267237 148.6.0.24.39413 > x.x.x.x.33299: . > 4249346210:4249347658(1448) ack 4065695111 win 5792 > > (DF) [tos 0x8] (ttl 63, id 7026, len 1500) > > The fourth packet seems to be truly out of window. It is in window. The window size is 365*2^4=5840, starting at 4249346210. From owner-netdev@oss.sgi.com Wed May 15 06:36:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FDaXnC032661 for ; Wed, 15 May 2002 06:36:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FDaXkr032660 for netdev-outgoing; Wed, 15 May 2002 06:36:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from loewe.cosy.sbg.ac.at (loewe.cosy.sbg.ac.at [141.201.2.12]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FDaRnC032657 for ; Wed, 15 May 2002 06:36:28 -0700 Received: from mausmaki.cosy.sbg.ac.at (mausmaki.cosy.sbg.ac.at [141.201.2.18]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id PAA26072 for ; Wed, 15 May 2002 15:36:53 +0200 (MET DST) Date: Wed, 15 May 2002 15:36:52 +0200 (MET DST) From: "Thomas 'Dent' Mirlacher" To: netdev@oss.sgi.com Subject: [RFC] datalink layer rx side -> move up to network stack Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1447 Lines: 38 hi list here is a small RFC: what about moving the datalink layer handling out from the driver to the network stack. (e.g. netif_receive_skb) - if packet is invalid, we're wasting some time (and possible space) ... but most datalink implementation today are not checking for valid frames anyway - if we've some LLC processing to do, we add some more time to respond - problems with datalink protocols which need to do SAR (segmentation and reassembly) on SMP machines (explaination: the network features a queue per CPU, and so after having placed a frame (skb) into one of the per CPU queues order cannot be guaranteed) solutions: 1) use the IRQ affinity to bind the device to a single CPU 2) do SAR at the driver layer - this ensures order + TAPs (like tcpdump) will be able to see EVERYTHING which comes in the wire - finally use tcpdump as a tool to dump everything the kernel sees :) + possibility to establish a clean interface to the datalink layers (the dll need some cleanup IMHO) + possibility to reuse datalink layers (today there are several implementation of the same protocol spread around the kernel tree - drivers/net/* isdn/*) + shorter ISRs for the drivers - the datalink stuff is usually handled within the driver ISR (by calling e.g. eth_type_trans) right before passing the data up to the network subsystem (via netif_rx) what do you think? tm -- in some way i do, and in some way i don't. From owner-netdev@oss.sgi.com Wed May 15 09:54:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FGswnC011610 for ; Wed, 15 May 2002 09:54:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FGswHp011609 for netdev-outgoing; Wed, 15 May 2002 09:54:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FGsnnC011592 for ; Wed, 15 May 2002 09:54:50 -0700 Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4FGt4b7165076 for ; Wed, 15 May 2002 12:55:07 -0400 Received: from w-nivedita2.des.beaverton.ibm.com (w-nivedita2.des.beaverton.ibm.com [9.47.18.16]) by northrelay01.pok.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4FGt1r22806 for ; Wed, 15 May 2002 12:55:01 -0400 Date: Wed, 15 May 2002 09:55:01 -0700 (PDT) From: Nivedita Singhvi X-X-Sender: To: Subject: [PATCH] SNMP MIB for TCP variables 2.4.18+ Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2495 Lines: 66 This is a patch to support some SNMP TCP MIB variables currently not provided by Linux (reqd by RFC 2012). Patch applies to 2.4.18+ cleanly. Can provide diffs against 2.5+ separately as well if needed. I'm following up on work done by Mark Price a while ago which included some larger changes. Will be working those separately. thanks, Nivedita diff -urN linux-2.4.18/include/net/tcp.h linux-2.4.18statp/include/net/tcp.h --- linux-2.4.18/include/net/tcp.h Thu Nov 22 11:47:22 2001 +++ linux-2.4.18statp/include/net/tcp.h Mon Apr 22 20:21:02 2002 @@ -331,6 +331,7 @@ #define TCP_DELACK_MIN 4U #define TCP_ATO_MIN 4U #endif +#define TCP_RTO_OTHER 1 #define TCP_RTO_MAX ((unsigned)(120*HZ)) #define TCP_RTO_MIN ((unsigned)(HZ/5)) #define TCP_TIMEOUT_INIT ((unsigned)(3*HZ)) /* RFC 1122 initial RTO value */ diff -urN linux-2.4.18/net/ipv4/proc.c linux-2.4.18statp/net/ipv4/proc.c --- linux-2.4.18/net/ipv4/proc.c Wed May 16 10:21:45 2001 +++ linux-2.4.18statp/net/ipv4/proc.c Mon Apr 22 22:45:52 2002 @@ -134,9 +134,17 @@ len += sprintf (buffer + len, "\nTcp: RtoAlgorithm RtoMin RtoMax MaxConn ActiveOpens PassiveOpens AttemptFails EstabResets CurrEstab InSegs OutSegs RetransSegs InErrs OutRsts\n" "Tcp:"); - for (i=0; i; Wed, 15 May 2002 23:17:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4G6HWXh013894 for netdev-outgoing; Wed, 15 May 2002 23:17:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from dmz1.procket.com (dmz1.procket.com [65.174.124.36]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4G6HSnC013888 for ; Wed, 15 May 2002 23:17:28 -0700 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id D946523C37 for ; Wed, 15 May 2002 13:41:29 -0700 (PDT) Received: from email.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g4FKdovM002374 for ; Wed, 15 May 2002 13:39:51 -0700 (PDT) Received: from Procket.com ([10.1.2.202]) by email.procket.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 15 May 2002 13:39:50 -0700 Message-ID: <3CE2C796.B18FB3E2@Procket.com> Date: Wed, 15 May 2002 13:39:50 -0700 From: John Zwiebel Organization: Procket Networks X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com, jzwiebel@procket.com Subject: [Fwd: Re: IGMPv3 in linux] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 May 2002 20:39:50.0742 (UTC) FILETIME=[A9156760:01C1FC50] Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1058 Lines: 30 When will IGMPv3 be standard in Linux? What can I do to make it happen sooner? Who should I contact? IGMPv3 is in Windows XP. IGMPv3 is required for general Source Specific Multicast (SSM). SSM across the internet is much more reliable than MSDP/PIM/MBGP (ASM: any source multicast). Although Microsoft doesn't yet have an IGMPv3 application, IP/TV from cisco will be (does already, at least in a beta app) use it. There are a number of Linux applications that use it, but since it requires a special kernel installation, many people who would benefit from SSM are now denied. I am working also to get IGMPv3 into FreeBSD from which it should "automagically" get into Opendarwin and then MacOSX. Thanks John Zwiebel -------- Original Message -------- Subject: Re: IGMPv3 in linux Date: Wed, 15 May 2002 21:36:43 +0100 (BST) From: Alan Cox To: jzwiebel@procket.com (John Zwiebel) Long time since I was involved in the net code. I believe IGMPv3 is still not in the kernel. Dunno if its planned - ask netdev@oss.sgi.com From owner-netdev@oss.sgi.com Thu May 16 06:53:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GDr3nC023564 for ; Thu, 16 May 2002 06:53:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GDr3hD023563 for netdev-outgoing; Thu, 16 May 2002 06:53:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from luxik.cdi.cz (root@inway106.cdi.cz [213.151.81.106]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GDqtnC023560 for ; Thu, 16 May 2002 06:52:57 -0700 Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 178LgR-0000Sm-00; Thu, 16 May 2002 15:52:43 +0200 Date: Thu, 16 May 2002 15:52:43 +0200 (CEST) From: Martin Devera To: Alexey Kuznetsov cc: netdev@oss.sgi.com Subject: ANK's PSCHED_TDIFF_SAFE change unmasked old bug (~0UL != 0xFFFFFFFF) In-Reply-To: <200205121635.UAA01437@mops.inr.ac.ru> Message-ID: References: <200205121635.UAA01437@mops.inr.ac.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1043 Lines: 32 > > even if tv1 > at least with PSCHED_TIME_SOURCE == JIFFIES) > > No, psched_time_t cannot wrap for our life. Ok. It did. I looked for the reason and probably find another bug. In all kernels (example given for 2.4.19pre8) include/net/pkt_sched.h line 224: #if ~0UL == 0xFFFFFFFF this test delimits part which decides about PSCHED_WATCHER usage. The test is FALSE on gcc: gcc version 2.95.2 20000220 (Debian GNU/Linux) gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) gcc version 3.0.2 I tested by: echo -e "#if ~0UL == 0xffffffff\nTST\n#endif"|gcc -E - echo -e "#if ~0UL == 0xffffffffffffffff\nTST\n#endif"|gcc -E - and the second line displays TST !! So that the test is never TRUE and PSCHED_WATCHER is never used. Thus psched_time_t wraps every 40 minutes and your change (althought correct one) to PSCHED_TDIFF_SAFE made it more visible than before. Probably the test should be changed. I'm not sure how. How to detect that long is 64 bit in cpp ? regards devik From owner-netdev@oss.sgi.com Thu May 16 07:37:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GEbMnC025760 for ; Thu, 16 May 2002 07:37:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GEbLNk025759 for netdev-outgoing; Thu, 16 May 2002 07:37:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from loewe.cosy.sbg.ac.at (loewe.cosy.sbg.ac.at [141.201.2.12]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GEb9nC025755 for ; Thu, 16 May 2002 07:37:19 -0700 Received: from mausmaki.cosy.sbg.ac.at (mausmaki.cosy.sbg.ac.at [141.201.2.18]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id QAA15564; Thu, 16 May 2002 16:35:32 +0200 (MET DST) Date: Thu, 16 May 2002 16:35:31 +0200 (MET DST) From: "Thomas 'Dent' Mirlacher" To: Martin Devera cc: Alexey Kuznetsov , netdev@oss.sgi.com Subject: Re: ANK's PSCHED_TDIFF_SAFE change unmasked old bug (~0UL != 0xFFFFFFFF) 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: 234 Lines: 11 --snip/snip > Probably the test should be changed. I'm not sure how. How to detect > that long is 64 bit in cpp ? by using BITS_PER_LONG (which is defined in include/asm/types.h) tm -- in some way i do, and in some way i don't. From owner-netdev@oss.sgi.com Thu May 16 07:59:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GExwnC026164 for ; Thu, 16 May 2002 07:59:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GExwTj026163 for netdev-outgoing; Thu, 16 May 2002 07:59:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GExsnC026160 for ; Thu, 16 May 2002 07:59:55 -0700 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id SAA22026; Thu, 16 May 2002 18:59:51 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200205161459.SAA22026@sex.inr.ac.ru> Subject: Re: ANK's PSCHED_TDIFF_SAFE change unmasked old bug (~0UL != 0xFFFFFFFF) To: devik@cdi.cz (Martin Devera) Date: Thu, 16 May 2002 18:59:51 +0400 (MSD) Cc: davem@sex.inr.ac.ru (Dave Miller), netdev@oss.sgi.com In-Reply-To: from "Martin Devera" at May 16, 2 03:52:43 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 283 Lines: 12 Hello! > echo -e "#if ~0UL == 0xffffffff\nTST\n#endif"|gcc -E - > echo -e "#if ~0UL == 0xffffffffffffffff\nTST\n#endif"|gcc -E - > > and the second line displays TST !! With old good 2.7.2 this worked... Dave, do you know a theory explaining this change in gcc behavior? Alexey From owner-netdev@oss.sgi.com Thu May 16 08:22:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GFMNnC026670 for ; Thu, 16 May 2002 08:22:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GFMNhL026669 for netdev-outgoing; Thu, 16 May 2002 08:22:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GFMInC026664 for ; Thu, 16 May 2002 08:22:18 -0700 Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) 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 IAA08188 for ; Thu, 16 May 2002 08:22:35 -0700 (PDT) mail_from (devik@cdi.cz) Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 178Mup-0001qf-00; Thu, 16 May 2002 17:11:39 +0200 Date: Thu, 16 May 2002 17:11:39 +0200 (CEST) From: Martin Devera To: "Thomas 'Dent' Mirlacher" cc: Alexey Kuznetsov , Subject: Re: ANK's PSCHED_TDIFF_SAFE change unmasked old bug (~0UL != 0xFFFFFFFF) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 725 Lines: 34 Well, so that the patch below should be ok. At least it works for IA32. I'll make it part of htb tarball for now to make users happy .. devik --- ../linux-2.4orig/include/net/pkt_sched.h Sun Dec 9 21:15:25 2001 +++ include/net/pkt_sched.h Thu May 16 16:45:00 2002 @@ -221,7 +221,7 @@ #define PSCHED_EXPORTLIST_2 -#if ~0UL == 0xFFFFFFFF +#if BITS_PER_LONG <= 32 #define PSCHED_WATCHER unsigned long On Thu, 16 May 2002, Thomas 'Dent' Mirlacher wrote: > --snip/snip > > Probably the test should be changed. I'm not sure how. How to detect > > that long is 64 bit in cpp ? > > by using BITS_PER_LONG (which is defined in include/asm/types.h) > > tm > > -- > in some way i do, and in some way i don't. > > > From owner-netdev@oss.sgi.com Thu May 16 08:35:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GFZRnC027317 for ; Thu, 16 May 2002 08:35:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GFZRN3027316 for netdev-outgoing; Thu, 16 May 2002 08:35:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GFZMnC027313 for ; Thu, 16 May 2002 08:35:22 -0700 Received: from luxik.cdi.cz (inway106.cdi.cz [213.151.81.106]) 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 IAA01978 for ; Thu, 16 May 2002 08:35:49 -0700 (PDT) mail_from (devik@cdi.cz) Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 178N7r-00024D-00; Thu, 16 May 2002 17:25:07 +0200 Date: Thu, 16 May 2002 17:25:06 +0200 (CEST) From: Martin Devera To: kuznet@ms2.inr.ac.ru cc: Dave Miller , Subject: Re: ANK's PSCHED_TDIFF_SAFE change unmasked old bug (~0UL != 0xFFFFFFFF) In-Reply-To: <200205161459.SAA22026@sex.inr.ac.ru> Message-ID: References: <200205161459.SAA22026@sex.inr.ac.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1085 Lines: 30 Btw the text below is from gcc 3.0.2 cpp parser: /* Find HOST_WIDEST_INT and set its bit size, type and print macros. It will be the largest integer mode supported by the host which may (or may not) be larger than HOST_WIDE_INT. This must appear after since we only use `long long' if its bigger than a `long' and also if it is supported by macros in limits.h. For old hosts which don't have a limits.h (and thus won't include it in stage2 cause we don't rerun configure) we assume gcc supports long long.) Note, you won't get these defined if you don't include {ht}config.h before this file to set the HOST_BITS_PER_* macros. */ and the HOST_WIDEST_INT is used for all arithmetic in CPP. On Thu, 16 May 2002 kuznet@ms2.inr.ac.ru wrote: > Hello! > > > echo -e "#if ~0UL == 0xffffffff\nTST\n#endif"|gcc -E - > > echo -e "#if ~0UL == 0xffffffffffffffff\nTST\n#endif"|gcc -E - > > > > and the second line displays TST !! > > With old good 2.7.2 this worked... > > Dave, do you know a theory explaining this change in gcc behavior? > > Alexey > > From owner-netdev@oss.sgi.com Thu May 16 09:46:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GGkDnC003628 for ; Thu, 16 May 2002 09:46:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GGkDwm003627 for netdev-outgoing; Thu, 16 May 2002 09:46:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from EXCHANGE.telegea.com ([63.116.180.23]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GGk7nC003624 for ; Thu, 16 May 2002 09:46:07 -0700 Received: from telegea.com (172.16.30.86 [172.16.30.86]) by EXCHANGE.telegea.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LARCHQY7; Thu, 16 May 2002 12:58:57 -0400 Message-ID: <3CE3E262.2AA7AEA6@telegea.com> Date: Thu, 16 May 2002 12:46:26 -0400 From: Srinivasa Rao Katta Organization: Telegea X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Hi Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 786 Lines: 39 Hi, How are you ?. I have installed Redhat-7.2 on the Dell server. It was running fine. I am trying to set my nic card to 100MB full-duplex. But,It was not succeeded. Here is the my nic card info. 3Com Corporation 3c905C-TX [Fast Etherlink] Here is my /etc/modules.conf info. ------------------------------------ # cat /etc/modules.conf alias parport_lowlevel parport_pc alias eth0 3c59x alias scsi_hostadapter aic7xxx alias sound-slot-0 i810_audio post-install sound-slot-0 /bin/aumix-minimal -f /etc/.aumixrc -L >/dev/null 2>&1 || : pre-remove sound-slot-0 /bin/aumix-minimal -f /etc/.aumixrc -S >/dev/null 2>&1 || : alias usb-controller usb-uhci -------------------------------------- Please advice me,How can I set my nic card for 100mb fullduplex. Thanks, Srinivas. From owner-netdev@oss.sgi.com Thu May 16 09:56:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GGuAnC003799 for ; Thu, 16 May 2002 09:56:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GGuA3Q003798 for netdev-outgoing; Thu, 16 May 2002 09:56:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from yue.hongo.wide.ad.jp (root@yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GGtpnC003788 for ; Thu, 16 May 2002 09:55:51 -0700 Received: from localhost (yoshfuji@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 BAA02524; Fri, 17 May 2002 01:57:14 +0900 To: netdev@oss.sgi.com CC: usagi@linux-ipv6.org Subject: RFC2292(bis) checksum support X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (AOI) X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020517015714M.yoshfuji@linux-ipv6.org> Date: Fri, 17 May 2002 01:57:14 +0900 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= X-Dispatcher: imput version 991025(IM133) Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 5453 Lines: 166 Hello! According to RFC2292 and its successor RFC2292bis, kernel compute and store checksum for output, and verify the recieved checksum on input (and discard it if it is in error) if the socket is for ICMPv6 IPV6_CHECKSUM socket option is set to the raw socket. Linux does not support this. Note: (1) RFC2292bis denies usage of this interface for ICMPv6 socket, but we allow it for a single case (offset is 2, which is correct value for ICMPv6 checksum) for backward compatibility for older applications. (2) RFC2292bis clarify that positive odd value is invalid, which cause problems on interoperability. 3.1. Checksums The kernel will calculate and insert the ICMPv6 checksum for ICMPv6 raw sockets, since this checksum is mandatory. For other raw IPv6 sockets (that is, for raw IPv6 sockets created with a third argument other than IPPROTO_ICMPV6), the application must set the new IPV6_CHECKSUM socket option to have the kernel (1) compute and store a checksum for output, and (2) verify the received checksum on input, discarding the packet if the checksum is in error. This option prevents applications from having to perform source address selection on the packets they send. The checksum will incorporate the IPv6 pseudo-header, defined in Section 8.1 of [RFC-2460]. This new socket option also specifies an integer offset into the user data of where the checksum is located. int offset = 2; setsockopt(fd, IPPROTO_IPV6, IPV6_CHECKSUM, &offset, sizeof(offset)); By default, this socket option is disabled. Setting the offset to -1 also disables the option. By disabled we mean (1) the kernel will not calculate and store a checksum for outgoing packets, and (2) the kernel will not verify a checksum for received packets. This option assumes the use of the 16-bit one's complement of the one's complement sum as the checksum algorithm and that the checksum field is aligned on a 16-bit boundary. Thus, specifying a positive odd value as offset is invalid, and setsockopt() will fail for such offset values. An attempt to set IPV6_CHECKSUM for an ICMPv6 socket will fail. Also, an attempt to set or get IPV6_CHECKSUM for a non-raw IPv6 socket will fail. (Note: Since the checksum is always calculated by the kernel for an ICMPv6 socket, applications are not able to generate ICMPv6 packets with incorrect checksums (presumably for testing purposes) using this API.) This patch is for linux-2.4.18. Index: net/ipv6/raw.c =================================================================== RCS file: /cvsroot/usagi/kernel/linux24/net/ipv6/raw.c,v retrieving revision 1.1.1.10 retrieving revision 1.1.1.10.6.1 diff -u -r1.1.1.10 -r1.1.1.10.6.1 --- net/ipv6/raw.c 2001/09/24 07:07:15 1.1.1.10 +++ net/ipv6/raw.c 2002/05/16 00:25:21 1.1.1.10.6.1 @@ -11,6 +11,7 @@ * * Fixes: * Hideaki YOSHIFUJI : sin6_scope_id support + * YOSHIFUJI,H.@USAGI : raw checksum (RFC2292(bis)) support * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License @@ -278,15 +279,34 @@ static inline int rawv6_rcv_skb(struct sock * sk, struct sk_buff * skb) { - /* Charge it to the socket. */ - if (sock_queue_rcv_skb(sk,skb)<0) { - IP6_INC_STATS_BH(Ip6InDiscards); - kfree_skb(skb); - return 0; + struct in6_addr *saddr = &skb->nh.ipv6h->saddr; + struct in6_addr *daddr = &skb->nh.ipv6h->daddr; + + if (sk->tp_pinfo.tp_raw.checksum) { + if (skb->ip_summed == CHECKSUM_HW) { + skb->ip_summed = CHECKSUM_UNNECESSARY; + if (csum_ipv6_magic(saddr, daddr, skb->len, sk->num, + skb->csum)) + skb->ip_summed = CHECKSUM_NONE; + } + if (skb->ip_summed == CHECKSUM_NONE) { + if (csum_ipv6_magic(saddr, daddr, skb->len, sk->num, + skb_checksum(skb, 0, skb->len, 0))) + goto discard_it; + } } + /* Charge it to the socket. */ + if (sock_queue_rcv_skb(sk,skb)<0) + goto discard_it; + IP6_INC_STATS_BH(Ip6InDelivers); return 0; + +discard_it: + IP6_INC_STATS_BH(Ip6InDiscards); + kfree_skb(skb); + return 0; } /* @@ -415,11 +435,19 @@ hdr->cksum = csum_ipv6_magic(addr, daddr, hdr->len, hdr->proto, hdr->cksum); - if (opt->offset < len) { + if (opt->offset + 1 < len) { __u16 *csum; csum = (__u16 *) (buff + opt->offset); *csum = hdr->cksum; + if (*csum) { + /* in case cksum was not initialized */ + __u32 sum = hdr->cksum; + sum += *csum; + *csum = hdr->cksum = (sum + (sum>>16)); + } else { + *csum = hdr->cksum; + } } else { if (net_ratelimit()) printk(KERN_DEBUG "icmp: cksum offset too big\n"); @@ -647,6 +675,12 @@ switch (optname) { case IPV6_CHECKSUM: + if (sk->num == IPPROTO_ICMPV6 && val != 2) + return(-EINVAL); + /* You may get strange result with a positive odd offset; + RFC2292bis agrees with me. */ + if (val > 0 && (val&1)) + return(-EINVAL); if (val < 0) { opt->checksum = 0; } else { @@ -744,6 +778,11 @@ static int rawv6_init_sk(struct sock *sk) { + if (sk->num == IPPROTO_ICMPV6){ + struct raw6_opt *opt = &sk->tp_pinfo.tp_raw; + opt->checksum = 1; + opt->offset = 2; + } return(0); } -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From owner-netdev@oss.sgi.com Thu May 16 10:08:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GH82nC004003 for ; Thu, 16 May 2002 10:08:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GH82m9004002 for netdev-outgoing; Thu, 16 May 2002 10:08:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GH7qnC003998 for ; Thu, 16 May 2002 10:07:59 -0700 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id VAA22517; Thu, 16 May 2002 21:08:01 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200205161708.VAA22517@sex.inr.ac.ru> Subject: Re: ANK's PSCHED_TDIFF_SAFE change unmasked old bug (~0UL != To: devik@cdi.cz (Martin Devera) Date: Thu, 16 May 2002 21:08:01 +0400 (MSD) Cc: davem@sex.inr.ac.ru, netdev@oss.sgi.com In-Reply-To: from "Martin Devera" at May 16, 2 05:25:06 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 732 Lines: 20 Hello! > and the HOST_WIDEST_INT is used for all arithmetic in CPP. This is not answer to the question. This behaviour was proven experimentally. :-) One question is _why_. Why the rules are so drastically different between C and CPP? C in CPP stands for C eventually. I can guess that this was caused by some problems with cross compiling 64bit <-> 32 bit, but I still do not understand why the fix was so strange. Another question is that this does not matter. UL is an explicit type specifier. In the experession there is no place for ambiguity at least from viewpoint of C. Apparently, before doing such strong change of rules it was discussed among gcc people. It would be intersting to know how it was motivated. Alexey From owner-netdev@oss.sgi.com Thu May 16 15:49:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GMnAnC016107 for ; Thu, 16 May 2002 15:49:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GMnAUI016106 for netdev-outgoing; Thu, 16 May 2002 15:49:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from smtp2.terra.com (smtp2.terra.com [66.119.66.53] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GMn8nC016074 for ; Thu, 16 May 2002 15:49:08 -0700 Date: Thu, 16 May 2002 15:49:08 -0700 From: netdev@terra.com Message-Id: <200205162249.g4GMn8nC016074@oss.sgi.com> Received: from localhost.bhz.virtua.com.br ([200.167.244.169]) by smtp2.terra.com (Netscape Messaging Server 4.15) with ESMTP id GW870T00.UAY for ; Thu, 16 May 2002 18:41:17 -0400 Subject: Re: netdev Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 124 Lines: 6 Hello, I'm waiting for you in my bedroom with my web cam on-line now, Hurry come to www.anitawebcam.da.ru I'ts 100% free! From owner-netdev@oss.sgi.com Thu May 16 15:49:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GMnBnC016114 for ; Thu, 16 May 2002 15:49:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GMnBeT016111 for netdev-outgoing; Thu, 16 May 2002 15:49:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from smtp4.terra.com (smtp4.terra.com [66.119.66.55] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GMn9nC016075 for ; Thu, 16 May 2002 15:49:09 -0700 Date: Thu, 16 May 2002 15:49:09 -0700 From: netdev@terra.com Message-Id: <200205162249.g4GMn9nC016075@oss.sgi.com> Received: from localhost.bhz.virtua.com.br ([200.167.244.169]) by smtp4.terra.com (Netscape Messaging Server 4.15) with ESMTP id GW870X03.H7U for ; Thu, 16 May 2002 18:41:21 -0400 Subject: Re: netdev Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 124 Lines: 6 Hello, I'm waiting for you in my bedroom with my web cam on-line now, Hurry come to www.anitawebcam.da.ru I'ts 100% free! From owner-netdev@oss.sgi.com Thu May 16 16:58:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GNwanC018660 for ; Thu, 16 May 2002 16:58:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GNwaE6018659 for netdev-outgoing; Thu, 16 May 2002 16:58:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from el-zoido.localnet (port-213-20-224-85.reverse.qdsl-home.de [213.20.224.85]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GNwUnC018656 for ; Thu, 16 May 2002 16:58:31 -0700 Received: from ws.localnet (ws.localnet [192.168.0.100]) by el-zoido.localnet (8.11.6/linuxconf) with ESMTP id g4GNwsR27741 for ; Fri, 17 May 2002 01:58:54 +0200 Message-ID: <3CE447BD.8040107@ws.localnet> Date: Fri, 17 May 2002 01:58:53 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Usage of skb->cb and dev->xmit_lock Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1748 Lines: 39 Hi. I'm looking for some advice concerning two things. First a little introduction: I've written a software device used as a placeholder for qdiscs to perform ingress shaping / shaping over multiple interfaces. It feeds itself packets marked by an iptables target through netfilter hooks. For marked packets NF_QUEUE is returned and the packet is then enqueued to the attached qdisc. The device's xmit function later reinjects them to the network stack. Now my problems: For reinjecting i need to keep the struct nf_info passed to my netfilter queue handler. I therefore introduced a new field in struct sk_buff. I don't really like this solution so i though of using skb->cb. It says "This is owned by whoever has the skb queued ATM." which of course if not the device but the qdisc. But i haven't found any refernece to it in any qdisc so my question is: is it safe to use skb->cb in this altered code flow ? The second problem arises when used with tunnels (only gre tested). If packets going to a gre tunnel are redirected though imq and the gre packets themselves are redirected too then qdisc_restart starts complaining about the tunnel device beeing deadlooped. (why the tunnel device and not mine?). I thought releasing dev->xmit_lock before calling nf_reinject and grabing it back afterwards would solve the problem, but i'm not sure about the consequences .. i guess on UP it doesn't matter, on SMP the worst thing i can imagine is one processor waiting until the lock becomes free for grabbing it back if in the meantime another processor has taken it. Can someone please enlighten me ? :) Thanks for your help, Patrick PS: If you want to look at the source, it is available at http://luxik.cdi.cz/~patrick/imq From owner-netdev@oss.sgi.com Thu May 16 17:48:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4H0mVnC019686 for ; Thu, 16 May 2002 17:48:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4H0mVa7019685 for netdev-outgoing; Thu, 16 May 2002 17:48:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from smtp4.terra.com (smtp4.terra.com [66.119.66.55] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4H0mTnC019682 for ; Thu, 16 May 2002 17:48:30 -0700 Date: Thu, 16 May 2002 17:48:29 -0700 From: netdev@terra.com Message-Id: <200205170048.g4H0mTnC019682@oss.sgi.com> Received: from localhost.bhz.virtua.com.br ([200.167.244.169]) by smtp4.terra.com (Netscape Messaging Server 4.15) with ESMTP id GW8CJU01.YAY for ; Thu, 16 May 2002 20:40:42 -0400 Subject: Re: netdev Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 124 Lines: 6 Hello, I'm waiting for you in my bedroom with my web cam on-line now, Hurry come to www.anitawebcam.da.ru I'ts 100% free! From owner-netdev@oss.sgi.com Sun May 19 14:47:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4JLlInC008326 for ; Sun, 19 May 2002 14:47:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4JLlIXJ008325 for netdev-outgoing; Sun, 19 May 2002 14:47:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4JLlAnC008290 for ; Sun, 19 May 2002 14:47:11 -0700 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id BAA00826; Mon, 20 May 2002 01:46:48 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200205192146.BAA00826@sex.inr.ac.ru> Subject: Re: RFC2292(bis) checksum support To: yoshfuji@linux-ipv6.ORG (YOSHIFUJI Hideaki) Date: Mon, 20 May 2002 01:46:48 +0400 (MSD) Cc: netdev@oss.sgi.com In-Reply-To: <20020517015714M.yoshfuji@linux-ipv6.org> from "YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=" at May 16, 2 09:15:08 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1324 Lines: 41 Hello! > According to RFC2292 and its successor RFC2292bis, kernel compute and > store checksum for output, and verify the recieved checksum on input > (and discard it if it is in error) if the socket is for ICMPv6 IPV6_CHECKSUM > socket option is set to the raw socket. > Linux does not support this. This is supposed to be fixed in recent 2.4.19 and 2.5. > (1) RFC2292bis denies usage of this interface for ICMPv6 socket, OK. Yes, we can set default value for such sockets to 2, but I do not see any good reasons to limit functionality of the API just to follow evident mistake in the rfc. So, I would apply the last three chunks of the patch except for these lines: + if (sk->num == IPPROTO_ICMPV6 && val != 2) + return(-EINVAL); One question only: what did you mean in the following chunk? Apparently, you forgot to delete marked line. csum = (__u16 *) (buff + opt->offset); *csum = hdr->cksum; ^^^^^^^^^^^^^^^^^^^ + if (*csum) { + /* in case cksum was not initialized */ + __u32 sum = hdr->cksum; + sum += *csum; + *csum = hdr->cksum = (sum + (sum>>16)); + } else { + *csum = hdr->cksum; + } Do I guess correctly that you wanted to compensate for occasionally ununitialized checksum bits in data supplied by user? Alexey From owner-netdev@oss.sgi.com Sun May 19 20:03:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4K334nC016830 for ; Sun, 19 May 2002 20:03:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4K334JJ016829 for netdev-outgoing; Sun, 19 May 2002 20:03:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from yue.hongo.wide.ad.jp (root@yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4K32wnC016796 for ; Sun, 19 May 2002 20:02:59 -0700 Received: from localhost (yoshfuji@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 MAA22542; Mon, 20 May 2002 12:04:06 +0900 To: kuznet@ms2.inr.ac.ru Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: RFC2292(bis) checksum support In-Reply-To: <200205192146.BAA00826@sex.inr.ac.ru> References: <20020517015714M.yoshfuji@linux-ipv6.org> <200205192146.BAA00826@sex.inr.ac.ru> X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020520120406A.yoshfuji@linux-ipv6.org> Date: Mon, 20 May 2002 12:04:06 +0900 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= X-Dispatcher: imput version 991025(IM133) Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1298 Lines: 38 In article <200205192146.BAA00826@sex.inr.ac.ru> (at Mon, 20 May 2002 01:46:48 +0400 (MSD)), kuznet@ms2.inr.ac.ru says: > This is supposed to be fixed in recent 2.4.19 and 2.5. thanks!!! > > (1) RFC2292bis denies usage of this interface for ICMPv6 socket, > > OK. Yes, we can set default value for such sockets to 2, but I do not see > any good reasons to limit functionality of the API just to follow evident > mistake in the rfc. So, I would apply the last three chunks of the patch > except for these lines: > > + if (sk->num == IPPROTO_ICMPV6 && val != 2) > + return(-EINVAL); Would you tell us what the "evident mistake in the rfc" is, please? Checksum for ICMPv6 is mandatory like ones for TCP and UDP (for IPv6) are. We should not (be able to) disable checksum for TCP, UDP AND ICMPv6, should we? > One question only: what did you mean in the following chunk? > Apparently, you forgot to delete marked line. > > csum = (__u16 *) (buff + opt->offset); > *csum = hdr->cksum; > ^^^^^^^^^^^^^^^^^^^ : > Do I guess correctly that you wanted to compensate for occasionally > ununitialized checksum bits in data supplied by user? yes. I just forgot to delete that original line while making this patch; sorry. --yoshfuji From owner-netdev@oss.sgi.com Sun May 19 20:51:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4K3prnC027708 for ; Sun, 19 May 2002 20:51:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4K3prMQ027707 for netdev-outgoing; Sun, 19 May 2002 20:51:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4K3pnnC027693 for ; Sun, 19 May 2002 20:51:49 -0700 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id HAA01589; Mon, 20 May 2002 07:51:38 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200205200351.HAA01589@sex.inr.ac.ru> Subject: Re: RFC2292(bis) checksum support To: yoshfuji@linux-ipv6.org (YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) Date: Mon, 20 May 2002 07:51:37 +0400 (MSD) Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com, usagi@linux-ipv6.org In-Reply-To: <20020520120406A.yoshfuji@linux-ipv6.org> from "YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=" at May 20, 2 12:04:06 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 719 Lines: 23 Hello! > Checksum for ICMPv6 is mandatory like ones for TCP and UDP (for IPv6) are. > We should not (be able to) disable checksum for TCP, UDP AND ICMPv6, > should we? It is mandatory on _network level_, not on api level. F.e. checksum is mandatory for ICMPv4 too, however, we used to calculate it in user space and nobody cries about this. Do you see what is the mistake in the rfc? Authors did a wrong sillogism and had to write several paragraphs of meaningless text to explain the mess. Shortly, you may consider this as a compatible extension of standard API. (which costs deleting several lines of code. :-)) > yes. I just forgot to delete that original line while making this patch; > sorry. OK. Alexey From owner-netdev@oss.sgi.com Mon May 20 02:55:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4K9t6nC018058 for ; Mon, 20 May 2002 02:55:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4K9t6of018057 for netdev-outgoing; Mon, 20 May 2002 02:55:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from balu.sch.bme.hu (balu.sch.bme.hu [152.66.208.40]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4K9t1nC018052 for ; Mon, 20 May 2002 02:55:02 -0700 Received: from localhost.localdomain (kisza@hoi.sch.bme.hu [152.66.213.231]) by balu.sch.bme.hu (8.12.1/8.12.1) with ESMTP id g4K9tiAu010089 for ; Mon, 20 May 2002 11:55:45 +0200 (MEST) Subject: IPv6 RFC2292, 1883 and 2460 (was: RFC2292(bis)) From: Andras Kis-Szabo To: Netdev Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 20 May 2002 11:55:27 +0200 Message-Id: <1021888528.8107.25.camel@hoi> Mime-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 622 Lines: 21 Hi, The RFC2292 based on the RFC1883 (and the Linux network (api/libc level) implementation, too). The RFC1883 obsolated by the RFC2460. The Type0 routing header has changed between the two version: the S/L bits were removed from it. (Changes 01.3) (And the address limit was deleted, too) Do the other implementations support the S/L bits? (The current Netfilter implementation based on the RFC2460.) regards kisza -- Andras Kis-Szabo Security Development, Design and Audit -------------------------/ Zorp, NetFilter and IPv6 kisza@SecurityAudit.hu /-----Member of the BUTE-MIS-SEARCHlab------> From owner-netdev@oss.sgi.com Mon May 20 13:00:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KK0InC021894 for ; Mon, 20 May 2002 13:00:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KK0I9Y021893 for netdev-outgoing; Mon, 20 May 2002 13:00:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KK00nC021880 for ; Mon, 20 May 2002 13:00:00 -0700 Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) 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 NAA06491 for ; Mon, 20 May 2002 13:00:36 -0700 (PDT) mail_from (george@mvista.com) Received: from data.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id MAA08762; Mon, 20 May 2002 12:42:07 -0700 Received: from mvista.com (IDENT:george@localhost [127.0.0.1]) by data.mvista.com (8.9.3/8.9.3) with ESMTP id MAA04893; Mon, 20 May 2002 12:42:09 -0700 Message-ID: <3CE95190.75C52E2D@mvista.com> Date: Mon, 20 May 2002 12:42:08 -0700 From: george anzinger Organization: Monta Vista Software X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12-20b i686) X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com, linux-net@vger.kernel.org, davem@redhat.com, ak@muc.de, kuznet@ms2.inr.ac.ru, pekkas@netcore.fi Subject: System crash in tcp_fragment() Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 3527 Lines: 106 I wonder if you could help me squash a bug in the tcp code. Here is what we know thus far: An SMP (x386 dual) 2.4.17 kernel crashes with an attempt to deference NULL at the end of tcp_fragment() (in net/ipv4/tcp_output.c) while attempting to link in the newly created fragment. The bugzilla report is: http://www.telecomlinux.org/bugzilla/show_bug.cgi?id=503 Incase you can not see this, it appears that the addresses of each skb are alright, so the assumption is that the skb passed to tcp_fragment() has been unlinked while tcp_fragment() was doing its thing. This implies a need for locking at some higher level and we don't know enough about the tcp code to divine where this might best be done. Here is the call stack: Panic screen: <1>Unable to handle kernel NULL pointer deference at virtual address 00000004 <4> printing eip: <4>c0256fb2 <1>*pde = 00000000 <4>Oops: 0002 <4>CPU: 1 <4>EIP: 0010:[] Not tainted <4>EFLAGS: 00010296 <4>eax: 00000000 ebx: c4d3ada0 ecx: c4d3ada0 edx: 00000000 <4>esi: c4e60780 edi: 000005a8 ebp: 00000610 esp: c1219e78 <4>ds: 0018 es: 0018 ss: 0018 <4>Process swapper (pid: 0, stackpage=c1219000) <4>Stack: c4c84478 00000064 c88937cd 00006270 00000010 c4e60780 c4c84478 000005a8 <4> 000005a8 c025787f c4c843a0 c4e60780 000005a8 c4c843a0 c4c84478 c4c843a0 <4> 004bd6a9 c0259a32 c4c843a0 c4e60780 c4c843a0 00000000 c1219ee8 00004050 <4>Call Trace: [] [] [] [] [] <4> [] [] [] [] [] [] <4> [] [] [] [] [] [] <4> <4>Code: 89 5a 04 89 1e 89 43 08 ff 40 08 31 c0 83 c4 14 5b 5e 5f 5d <1>Dumping from interrupt handler ! <1>Uncertain scenario - but will try my best <4> <4>dump: Dumping to device 0x806 [sd(8,6)] on CPU 1 ... <4>dump: Compression value is 0x0, Writing dump header <4> <4>dump: Pass 1: Saving Reserved Pages: <4>dump: Memory Bank[0]: 0 ... 7feffff: [...] lcrash backtrace: >> bt ================================================================ STACK TRACE FOR TASK: 0xc1218000(swapper) 0 tcp_fragment+674 [0xc0256fb2] 1 tcp_retransmit_skb+170 [0xc025787a] 2 tcp_retransmit_timer+493 [0xc0259a2d] 3 tcp_write_timer+225 [0xc0259c31] 4 timer_bh+710 [0xc0128d66] 5 timer_softirq+40 [0xc0128e68] 6 do_softirq+185 [0xc01246f9] 7 do_IRQ+511 [0xc01095ff] 8 do_IRQ+511 [0xc01095ff] TRACE ERROR 0x1 ================================================================ We assumed that this might be related to preempt code in the kernel, however, this now appears unlikely. The primary reason for preempt related failures is the use of unprotected "cpu ids" to access "per cpu" data structures. To this end we have made changes to the "skb" management code to include the smp_processor_id() calls in the relevant interrupt off areas, however, this problem does not seem to have any such issues. Is is possible for the other cpu (or even this one given the ksoftirqd stuff) to remove or alter the skb that tcp_fragment() is processing? What locks, if any, are needed to prevent this. -- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Real time sched: http://sourceforge.net/projects/rtsched/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml From owner-netdev@oss.sgi.com Mon May 20 13:39:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KKdInC026049 for ; Mon, 20 May 2002 13:39:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KKdIc7026048 for netdev-outgoing; Mon, 20 May 2002 13:39:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KKdFnC026045 for ; Mon, 20 May 2002 13:39:15 -0700 Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by deliverator.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 NAA04782 for ; Mon, 20 May 2002 13:40:01 -0700 (PDT) mail_from (andi@firstfloor.org) Received: from fwd05.sul.t-online.de by mailout01.sul.t-online.com with smtp id 179tmr-0000kW-0A; Mon, 20 May 2002 22:29:45 +0200 Received: from averell.firstfloor.org (520003261363-0001@[217.82.110.248]) by fmrl05.sul.t-online.com with esmtp id 179tmn-0hIeTwC; Mon, 20 May 2002 22:29:41 +0200 Received: by averell.firstfloor.org (Postfix on SuSE Linux 7.3 (i386), from userid 500) id 1642B699B6; Mon, 20 May 2002 22:29:38 +0200 (CEST) Date: Mon, 20 May 2002 22:29:37 +0200 From: Andi Kleen To: george anzinger Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org, davem@redhat.com, ak@muc.de, kuznet@ms2.inr.ac.ru, pekkas@netcore.fi Subject: Re: System crash in tcp_fragment() Message-ID: <20020520222937.A1467@averell> References: <3CE95190.75C52E2D@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CE95190.75C52E2D@mvista.com> User-Agent: Mutt/1.3.22.1i X-Sender: 520003261363-0001@t-dialin.net Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 506 Lines: 11 > Incase you can not see this, it appears that the addresses > of each skb are alright, so the assumption is that the skb > passed to tcp_fragment() has been unlinked while > tcp_fragment() was doing its thing. This implies a need for > locking at some higher level and we don't know enough about > the tcp code to divine where this might best be done. 2.4 TCP should in theory already have enough locking to prevent this (the socket lock that is aquired by timers and user context socket users) -Andi From owner-netdev@oss.sgi.com Mon May 20 13:52:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KKqLnC026478 for ; Mon, 20 May 2002 13:52:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KKqLtA026477 for netdev-outgoing; Mon, 20 May 2002 13:52:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KKqEnC026474 for ; Mon, 20 May 2002 13:52:14 -0700 Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4KKqvg5241172 for ; Mon, 20 May 2002 16:52:58 -0400 Received: from w-nivedita2.des.beaverton.ibm.com (w-nivedita2.des.beaverton.ibm.com [9.47.18.16]) by northrelay01.pok.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4KKqtG58880 for ; Mon, 20 May 2002 16:52:55 -0400 Date: Mon, 20 May 2002 13:52:55 -0700 (PDT) From: Nivedita Singhvi X-X-Sender: To: Subject: [PATCH] RFC save a few atomics in tcp_memory_schedule() Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1556 Lines: 55 The patch below tries to save a few atomic reads, based on the assumption that we can tolerate slightly stale data here, given that actions are "relaxed". (Otherwise we should be locking whole thing anyway).. Would this be reasonable, or what am I missing? thanks, Nivedita diff -urN linux-2.4.18/net/ipv4/tcp.c linux-2.4.18new/net/ipv4/tcp.c --- linux-2.4.18/net/ipv4/tcp.c Fri Dec 21 09:42:05 2001 +++ linux-2.4.18new/net/ipv4/tcp.c Mon May 20 12:40:00 2002 @@ -286,25 +286,27 @@ int tcp_mem_schedule(struct sock *sk, int size, int kind) { int amt = TCP_PAGES(size); + int allocated; sk->forward_alloc += amt*TCP_MEM_QUANTUM; atomic_add(amt, &tcp_memory_allocated); + allocated = atomic_read(&tcp_memory_allocated); /* Under limit. */ - if (atomic_read(&tcp_memory_allocated) < sysctl_tcp_mem[0]) { + if (allocated < sysctl_tcp_mem[0]) { if (tcp_memory_pressure) tcp_memory_pressure = 0; return 1; } /* Over hard limit. */ - if (atomic_read(&tcp_memory_allocated) > sysctl_tcp_mem[2]) { + if (allocated > sysctl_tcp_mem[2]) { tcp_enter_memory_pressure(); goto suppress_allocation; } /* Under pressure. */ - if (atomic_read(&tcp_memory_allocated) > sysctl_tcp_mem[1]) + if (allocated > sysctl_tcp_mem[1]) tcp_enter_memory_pressure(); if (kind) { @@ -316,7 +318,7 @@ } if (!tcp_memory_pressure || - sysctl_tcp_mem[2] > atomic_read(&tcp_sockets_allocated) + sysctl_tcp_mem[2] > allocated * TCP_PAGES(sk->wmem_queued+atomic_read(&sk->rmem_alloc)+ sk->forward_alloc)) return 1; From owner-netdev@oss.sgi.com Mon May 20 13:57:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KKvdnC026681 for ; Mon, 20 May 2002 13:57:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KKvdfD026680 for netdev-outgoing; Mon, 20 May 2002 13:57:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KKvZnC026676 for ; Mon, 20 May 2002 13:57:35 -0700 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4KKwNFD147434 for ; Mon, 20 May 2002 16:58:23 -0400 Received: from w-nivedita2.des.beaverton.ibm.com (w-nivedita2.des.beaverton.ibm.com [9.47.18.16]) by westrelay01.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4KKwLJ64348 for ; Mon, 20 May 2002 14:58:22 -0600 Date: Mon, 20 May 2002 13:58:21 -0700 (PDT) From: Nivedita Singhvi X-X-Sender: To: Subject: [PATCH] 2.4.18+ minor nit in tcp_delack_timer() Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 738 Lines: 28 On the assumption that we want to save a cycle wherever possible. Since we've just done an unconditional tcp_mem_reclaim(), we can save the repeat check(?).. thanks, Nivedita diff -urN linux-2.4.18/net/ipv4/tcp_timer.c linux-2.4.18tmr1/net/ipv4/tcp_timer.c --- linux-2.4.18/net/ipv4/tcp_timer.c Mon Oct 1 09:19:57 2001 +++ linux-2.4.18tmr1/net/ipv4/tcp_timer.c Sun May 19 11:23:40 2002 @@ -225,12 +225,12 @@ tcp_mem_reclaim(sk); if (sk->state == TCP_CLOSE || !(tp->ack.pending&TCP_ACK_TIMER)) - goto out; + goto out_unlock; if ((long)(tp->ack.timeout - jiffies) > 0) { if (!mod_timer(&tp->delack_timer, tp->ack.timeout)) sock_hold(sk); - goto out; + goto out_unlock; } tp->ack.pending &= ~TCP_ACK_TIMER; From owner-netdev@oss.sgi.com Mon May 20 14:19:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KLJJnC027422 for ; Mon, 20 May 2002 14:19:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KLJJoI027421 for netdev-outgoing; Mon, 20 May 2002 14:19:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KLIunC027354 for ; Mon, 20 May 2002 14:18:56 -0700 Received: from data.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id OAA11777; Mon, 20 May 2002 14:18:33 -0700 Received: from mvista.com (IDENT:george@localhost [127.0.0.1]) by data.mvista.com (8.9.3/8.9.3) with ESMTP id OAA05047; Mon, 20 May 2002 14:18:34 -0700 Message-ID: <3CE9682A.2CC13644@mvista.com> Date: Mon, 20 May 2002 14:18:34 -0700 From: george anzinger Organization: Monta Vista Software X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12-20b i686) X-Accept-Language: en MIME-Version: 1.0 To: Andi Kleen CC: netdev@oss.sgi.com, linux-net@vger.kernel.org, davem@redhat.com, kuznet@ms2.inr.ac.ru, pekkas@netcore.fi Subject: Re: System crash in tcp_fragment() References: <3CE95190.75C52E2D@mvista.com> <20020520222937.A1467@averell> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 6237 Lines: 196 Andi Kleen wrote: > > > Incase you can not see this, it appears that the addresses > > of each skb are alright, so the assumption is that the skb > > passed to tcp_fragment() has been unlinked while > > tcp_fragment() was doing its thing. This implies a need for > > locking at some higher level and we don't know enough about > > the tcp code to divine where this might best be done. > > 2.4 TCP should in theory already have enough locking to prevent this > (the socket lock that is aquired by timers and user context socket users) > > -Andi Here is another oops, not quite the same, AND with an assert failure ahead of it. I append the whole report and some and some observations: We had two more panics over the weekend. Here is the analysis from one of them. ---------comments from Dave Howell-------------- Looking at the sysint4l dump, some observations: - Panic was due to an Oops (Null pointer dereference kernel incident) - Full system configuration is in kernel startup logs (memory, disks, chipsets, etc) - Last part of kernel log has oops info, follows kernel assertion failed warning: <4>KERNRL: assertion (atomic_read(&sk->wmem_alloc) == 0) failed at af_inet.c <============== (174):inet_sock_destruct <1>Unable to handle kernel NULL pointer dereference at virtual address 00000049 <4> printing eip: <4>c0255196 <1>*pde = 00000000 <4>Oops: 0000 <4>CPU: 1 <4>EIP: 0010:[] Not tainted <4>EFLAGS: 00010213 <4>eax: c6ace4c8 ebx: 00000000 ecx: 00000004 edx: 00000000 <4>esi: c6ace538 edi: c6ace460 ebp: 00000026 esp: c1219eb4 <4>ds: 0018 es: 0018 ss: 0018 <4>Process swapper (pid: 0, stackpage=c1219000) <4>Stack: c6ace460 c6ace538 c6ace460 004ec3ef c025de3e c6ace460 00000000 c72011a0 <4> c1218050 004ec2d2 c02395b2 c6ace460 c6ace538 c1218000 004ec3ef c025e056 <4> c6ace460 c1218000 00000046 004ebfe7 00000000 c1218000 00cf70a0 c0128eaa <4>Call Trace: [] [] [] [] [] <4> [] [] [] [] [] [] <4> [] [] [] [] <4> <4>Code: 0f b6 4b 49 45 f6 c1 82 74 0c 31 d2 89 96 78 01 00 00 0f b6 - Finally at the bottom of the trace the active backtrace, a bit suspect because it's on the interrupt side (not trace but process it's attributed to). =========================== STACK TRACE OF FAILING TASK =========================== ================================================================ STACK TRACE FOR TASK: 0xc1218000 (swapper) 0 tcp_enter_loss+198 [0xc0255196] 1 tcp_retransmit_timer+473 [0xc025de39] 2 tcp_write_timer+225 [0xc025e051] 3 timer_bh+710 [0xc0128ea6] 4 timer_softirq+40 [0xc0128fa8] 5 do_softirq+185 [0xc0124839] 6 do_IRQ+511 [0xc01096ff] 7 do_IRQ+511 [0xc01096ff] TRACE ERROR 0x1 ================================================================ - In comparison with previous dump looks like the same upstream event occured, with a timer bottom half running and invoking the tcp_retransmit_timer. Last one caught it oopsing in the tcp_fragment code, this is a bit different but the upstream path there is the same. - Same pile of unknown symbol references bringing up dump manually in lcrash, must be corrupt or wrong system.0 or kerntypes.0. Needs a look. - Dumped tcp_enter_loss+0 to tcp_enter_loss+200 to see site at tcp_enter_loss+198. Code at this site is: movzbl 0x49(%ebx),%ecx %ebx is NULL at this point (see above), hence the oops at 00000049. Code for function is in net/ipv4/tcp_input.c starting at line 987. - The failure is in the loop starting at line 1002: for_retrans_queue(skb, sk, tp) { cnt++; if (TCP_SKB_CB(skb)->sacked&TCPCB_RETRANS) tp->undo_marker = 0; TCP_SKB_CB(skb)->sacked &= (~TCPCB_TAGBITS)|TCPCB_SACKED_ACKED; if (!(TCP_SKB_CB(skb)->sacked&TCPCB_SACKED_ACKED) || how) { TCP_SKB_CB(skb)->sacked &= ~TCPCB_SACKED_ACKED; TCP_SKB_CB(skb)->sacked |= TCPCB_LOST; tp->lost_out++; } else { tp->sacked_out++; tp->fackets_out = cnt; } } I didn't fully map the code but think that the expansion of: if (TCP_SKB_CB(skb)->sacked&TCPCB_RETRANS) is where the zeroed pointer is used. Looks like the intent is that skp is the iterater variable to loop through the retrans_queue and it got the zero value set on some iteration, not the first. So my guess is a corrupted queue element pointer being picked up and used. - I still would look upstream at the timer bottom half invocation as in both of the dumps this upstream trace is present, and it seems like an exception path for a timeout that leads to a retransmit. - Also needs a look is the kernel assertion that failed and likely led to the oops, looks a lot like an allocation failed and returned a NULL value, this would be my top culprit to pursue. Code from af_net.c at line 174: void inet_sock_destruct(struct sock *sk) { __skb_queue_purge(&sk->receive_queue); __skb_queue_purge(&sk->error_queue); if (sk->type == SOCK_STREAM && sk->state != TCP_CLOSE) { printk("Attempt to release TCP socket in state %d %p\n", sk->state, sk); return; } if (!sk->dead) { printk("Attempt to release alive inet socket %p\n", sk); return; } BUG_TRAP(atomic_read(&sk->rmem_alloc) == 0); BUG_TRAP(atomic_read(&sk->wmem_alloc) == 0); <<-- assert reported here BUG_TRAP(sk->wmem_queued == 0); BUG_TRAP(sk->forward_alloc == 0); if (sk->protinfo.af_inet.opt) kfree(sk->protinfo.af_inet.opt); Continuing on after this likely led to the oops that killed us. -- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Real time sched: http://sourceforge.net/projects/rtsched/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml From owner-netdev@oss.sgi.com Mon May 20 14:26:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KLQ7nC027825 for ; Mon, 20 May 2002 14:26:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KLQ7hr027824 for netdev-outgoing; Mon, 20 May 2002 14:26:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KLQ2nC027821 for ; Mon, 20 May 2002 14:26:03 -0700 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id BAA03545; Tue, 21 May 2002 01:25:53 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200205202125.BAA03545@sex.inr.ac.ru> Subject: Re: System crash in tcp_fragment() To: george@mvista.com (george anzinger) Date: Tue, 21 May 2002 01:25:53 +0400 (MSD) Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org, davem@redhat.com, ak@muc.de, pekkas@netcore.fi In-Reply-To: <3CE95190.75C52E2D@mvista.com> from "george anzinger" at May 20, 2 12:42:08 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 854 Lines: 29 Hello! > Is is possible for the other cpu (or even this one given the > ksoftirqd stuff) to remove or alter the skb that > tcp_fragment() is processing? No. > What locks, if any, are needed to prevent this. They are already applied. Looking at the last lines of the bugzilla thread, I see the answer: > - Observation, the BUG_TRAP assertion likely should have done something better > than just report the condition, wonder if an earlier panic or other corrective > action may have kept the TCP stack moving instead of the oops? Looks lazy to > me... Well, add BUG() to BIG_TRAP() to oops it earlier. Maybe this will move you closer to real problem. And also your reasoning about smp_processor_id() sounds strange, preemption code must reschedule thread preemted in the kernel to the same cpu, it is enough to avoid troubles with this. Alexey From owner-netdev@oss.sgi.com Mon May 20 15:21:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KMLZnC028901 for ; Mon, 20 May 2002 15:21:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KMLZUU028900 for netdev-outgoing; Mon, 20 May 2002 15:21:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KMLWnC028897 for ; Mon, 20 May 2002 15:21:32 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id PAA08552; Mon, 20 May 2002 15:08:33 -0700 Date: Mon, 20 May 2002 15:08:33 -0700 (PDT) Message-Id: <20020520.150833.26960938.davem@redhat.com> To: george@mvista.com Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org, ak@muc.de, kuznet@ms2.inr.ac.ru, pekkas@netcore.fi Subject: Re: System crash in tcp_fragment() From: "David S. Miller" In-Reply-To: <3CE95190.75C52E2D@mvista.com> References: <3CE95190.75C52E2D@mvista.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 683 Lines: 18 From: george anzinger Date: Mon, 20 May 2002 12:42:08 -0700 I wonder if you could help me squash a bug in the tcp code. Here is what we know thus far: An SMP (x386 dual) 2.4.17 kernel crashes with an attempt to deference NULL at the end of tcp_fragment() (in net/ipv4/tcp_output.c) while attempting to link in the newly created fragment. The bugzilla report is: %99 of all such bug reports turn out to be driver bugs where the net driver frees SKBs improperly or there is some missing internal locking in the net device driver. I think you efforts are better spent auditing what net drivers are being used on this machine :-) From owner-netdev@oss.sgi.com Mon May 20 16:08:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KN84nC029691 for ; Mon, 20 May 2002 16:08:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KN84kZ029690 for netdev-outgoing; Mon, 20 May 2002 16:08:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KN7tnC029687 for ; Mon, 20 May 2002 16:07:56 -0700 Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) 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 QAA00681 for ; Mon, 20 May 2002 16:08:38 -0700 (PDT) mail_from (george@mvista.com) Received: from data.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id QAA14811; Mon, 20 May 2002 16:01:15 -0700 Received: from mvista.com (IDENT:george@localhost [127.0.0.1]) by data.mvista.com (8.9.3/8.9.3) with ESMTP id QAA07030; Mon, 20 May 2002 16:01:01 -0700 Message-ID: <3CE9802A.6F3839DB@mvista.com> Date: Mon, 20 May 2002 16:01:00 -0700 From: george anzinger Organization: Monta Vista Software X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12-20b i686) X-Accept-Language: en MIME-Version: 1.0 To: kuznet@ms2.inr.ac.ru CC: netdev@oss.sgi.com, linux-net@vger.kernel.org, davem@redhat.com, ak@muc.de, pekkas@netcore.fi Subject: Re: System crash in tcp_fragment() References: <200205202125.BAA03545@sex.inr.ac.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1391 Lines: 43 kuznet@ms2.inr.ac.ru wrote: > > Hello! > > > Is is possible for the other cpu (or even this one given the > > ksoftirqd stuff) to remove or alter the skb that > > tcp_fragment() is processing? > > No. > > What locks, if any, are needed to prevent this. > > They are already applied. > > Looking at the last lines of the bugzilla thread, I see the answer: > > > - Observation, the BUG_TRAP assertion likely should have done something better > > than just report the condition, wonder if an earlier panic or other corrective > > action may have kept the TCP stack moving instead of the oops? Looks lazy to > > me... > > Well, add BUG() to BIG_TRAP() to oops it earlier. Maybe this will move > you closer to real problem. Right. Will do. > > And also your reasoning about smp_processor_id() sounds strange, > preemption code must reschedule thread preemted in the kernel to the > same cpu, it is enough to avoid troubles with this. That (ahem) hack was tried and rejected by the powers that be. I admit that is it more work to find the resulting problems, but the fixes seem to be easy and do not to add to overhead, at least thus far. > > Alexey -- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Real time sched: http://sourceforge.net/projects/rtsched/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml From owner-netdev@oss.sgi.com Mon May 20 16:53:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KNrSnC030373 for ; Mon, 20 May 2002 16:53:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KNrS7s030372 for netdev-outgoing; Mon, 20 May 2002 16:53:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KNrPnC030369 for ; Mon, 20 May 2002 16:53:26 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id C1AB61EDBA; Tue, 21 May 2002 01:54:10 +0200 (MEST) Date: Tue, 21 May 2002 01:54:07 +0200 From: Andi Kleen To: kuznet@ms2.inr.ac.ru Cc: george anzinger , netdev@oss.sgi.com, linux-net@vger.kernel.org, davem@redhat.com, ak@muc.de, pekkas@netcore.fi Subject: Re: System crash in tcp_fragment() Message-ID: <20020521015407.A1296@wotan.suse.de> References: <3CE95190.75C52E2D@mvista.com> <200205202125.BAA03545@sex.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200205202125.BAA03545@sex.inr.ac.ru> User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 289 Lines: 9 > And also your reasoning about smp_processor_id() sounds strange, > preemption code must reschedule thread preemted in the kernel to the > same cpu, it is enough to avoid troubles with this. It's unfortunately the truth. Even in_interrupt() is buggy current on SMP preemptive. -Andi From owner-netdev@oss.sgi.com Mon May 20 17:11:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4L0BFnC030669 for ; Mon, 20 May 2002 17:11:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4L0BFg4030668 for netdev-outgoing; Mon, 20 May 2002 17:11:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4L0BCnC030665 for ; Mon, 20 May 2002 17:11:12 -0700 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id EAA04286; Tue, 21 May 2002 04:11:01 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200205210011.EAA04286@sex.inr.ac.ru> Subject: Re: System crash in tcp_fragment() To: ak@suse.de (Andi Kleen) Date: Tue, 21 May 2002 04:11:00 +0400 (MSD) Cc: george@mvista.com, netdev@oss.sgi.com, linux-net@vger.kernel.org, davem@redhat.com, ak@muc.de, pekkas@netcore.fi In-Reply-To: <20020521015407.A1296@wotan.suse.de> from "Andi Kleen" at May 21, 2 01:54:07 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 217 Lines: 9 Hello! > It's unfortunately the truth. Even in_interrupt() is buggy current > on SMP preemptive. And why folks working on preemtive kernel do not repair this? To all that I remember it is well known issue. Alexey From owner-netdev@oss.sgi.com Mon May 20 17:19:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4L0JpnC030879 for ; Mon, 20 May 2002 17:19:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4L0JpuH030878 for netdev-outgoing; Mon, 20 May 2002 17:19:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4L0JMnC030872 for ; Mon, 20 May 2002 17:19:25 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 698FF1EDBB; Tue, 21 May 2002 02:20:07 +0200 (MEST) Date: Tue, 21 May 2002 02:20:07 +0200 From: Andi Kleen To: kuznet@ms2.inr.ac.ru Cc: Andi Kleen , george@mvista.com, netdev@oss.sgi.com, linux-net@vger.kernel.org, davem@redhat.com, ak@muc.de, pekkas@netcore.fi Subject: Re: System crash in tcp_fragment() Message-ID: <20020521022007.A6248@wotan.suse.de> References: <20020521015407.A1296@wotan.suse.de> <200205210011.EAA04286@sex.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200205210011.EAA04286@sex.inr.ac.ru> User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 401 Lines: 17 On Tue, May 21, 2002 at 04:11:00AM +0400, A.N.Kuznetsov wrote: > Hello! > > > It's unfortunately the truth. Even in_interrupt() is buggy current > > on SMP preemptive. > > And why folks working on preemtive kernel do not repair this? > To all that I remember it is well known issue. It is fixed on x86-64 @) if [ "$CONFIG_SMP" = "n" ]; then bool 'Preemptible Kernel' CONFIG_PREEMPT fi -Andi From owner-netdev@oss.sgi.com Mon May 20 17:27:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4L0RanC031008 for ; Mon, 20 May 2002 17:27:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4L0RaMb031007 for netdev-outgoing; Mon, 20 May 2002 17:27:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4L0RXnC031004 for ; Mon, 20 May 2002 17:27:33 -0700 Received: from data.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id RAA17597; Mon, 20 May 2002 17:26:27 -0700 Received: from mvista.com (IDENT:george@localhost [127.0.0.1]) by data.mvista.com (8.9.3/8.9.3) with ESMTP id RAA12809; Mon, 20 May 2002 17:26:29 -0700 Message-ID: <3CE99434.20E7479C@mvista.com> Date: Mon, 20 May 2002 17:26:29 -0700 From: george anzinger Organization: Monta Vista Software X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12-20b i686) X-Accept-Language: en MIME-Version: 1.0 To: kuznet@ms2.inr.ac.ru CC: Andi Kleen , netdev@oss.sgi.com, linux-net@vger.kernel.org, davem@redhat.com, ak@muc.de, pekkas@netcore.fi Subject: Re: System crash in tcp_fragment() References: <200205210011.EAA04286@sex.inr.ac.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 637 Lines: 21 kuznet@ms2.inr.ac.ru wrote: > > Hello! > > > It's unfortunately the truth. Even in_interrupt() is buggy current > > on SMP preemptive. > > And why folks working on preemtive kernel do not repair this? > To all that I remember it is well known issue. > Ah, but we have. in_interrupt() was fixed about a month ago. I think Robert got it into all the patches. Whats more, it is a bit faster too :) -- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Real time sched: http://sourceforge.net/projects/rtsched/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml From owner-netdev@oss.sgi.com Mon May 20 17:31:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4L0VsnC031129 for ; Mon, 20 May 2002 17:31:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4L0VsYI031128 for netdev-outgoing; Mon, 20 May 2002 17:31:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4L0VqnC031125 for ; Mon, 20 May 2002 17:31:52 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id RAA09615; Mon, 20 May 2002 17:18:19 -0700 Date: Mon, 20 May 2002 17:18:19 -0700 (PDT) Message-Id: <20020520.171819.71992193.davem@redhat.com> To: george@mvista.com Cc: kuznet@ms2.inr.ac.ru, ak@suse.de, netdev@oss.sgi.com, linux-net@vger.kernel.org, ak@muc.de, pekkas@netcore.fi Subject: Re: System crash in tcp_fragment() From: "David S. Miller" In-Reply-To: <3CE99434.20E7479C@mvista.com> References: <200205210011.EAA04286@sex.inr.ac.ru> <3CE99434.20E7479C@mvista.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 407 Lines: 12 From: george anzinger Date: Mon, 20 May 2002 17:26:29 -0700 Ah, but we have. in_interrupt() was fixed about a month ago. I think Robert got it into all the patches. Whats more, it is a bit faster too :) Well, back to the main point, this code is pretty stable by any measurement. I truly believe it is some side effect of either a preemption gotcha or a driver bug. From owner-netdev@oss.sgi.com Mon May 20 17:35:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4L0ZcnC031246 for ; Mon, 20 May 2002 17:35:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4L0ZciT031245 for netdev-outgoing; Mon, 20 May 2002 17:35:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4L0ZZnC031242 for ; Mon, 20 May 2002 17:35:35 -0700 Received: from data.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id RAA17791; Mon, 20 May 2002 17:34:26 -0700 Received: from mvista.com (IDENT:george@localhost [127.0.0.1]) by data.mvista.com (8.9.3/8.9.3) with ESMTP id RAA13364; Mon, 20 May 2002 17:34:22 -0700 Message-ID: <3CE9960D.15D41380@mvista.com> Date: Mon, 20 May 2002 17:34:21 -0700 From: george anzinger Organization: Monta Vista Software X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12-20b i686) X-Accept-Language: en MIME-Version: 1.0 To: Andi Kleen CC: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-net@vger.kernel.org, davem@redhat.com, ak@muc.de, pekkas@netcore.fi Subject: Re: System crash in tcp_fragment() References: <20020521015407.A1296@wotan.suse.de> <200205210011.EAA04286@sex.inr.ac.ru> <20020521022007.A6248@wotan.suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 725 Lines: 26 Andi Kleen wrote: > > On Tue, May 21, 2002 at 04:11:00AM +0400, A.N.Kuznetsov wrote: > > Hello! > > > > > It's unfortunately the truth. Even in_interrupt() is buggy current > > > on SMP preemptive. > > > > And why folks working on preemtive kernel do not repair this? > > To all that I remember it is well known issue. > > It is fixed on x86-64 @) > > if [ "$CONFIG_SMP" = "n" ]; then > bool 'Preemptible Kernel' CONFIG_PREEMPT > fi > That is not a fix! It is dodging the issue. ;) -- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Real time sched: http://sourceforge.net/projects/rtsched/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml From owner-netdev@oss.sgi.com Mon May 20 17:41:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4L0fqnC031415 for ; Mon, 20 May 2002 17:41:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4L0fq0C031414 for netdev-outgoing; Mon, 20 May 2002 17:41:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4L0flnC031411 for ; Mon, 20 May 2002 17:41:48 -0700 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id EAA04407; Tue, 21 May 2002 04:41:39 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200205210041.EAA04407@sex.inr.ac.ru> Subject: Re: System crash in tcp_fragment() To: george@mvista.com (george anzinger) Date: Tue, 21 May 2002 04:41:39 +0400 (MSD) Cc: ak@suse.de, netdev@oss.sgi.com, linux-net@vger.kernel.org, davem@redhat.com, ak@muc.de, pekkas@netcore.fi In-Reply-To: <3CE9960D.15D41380@mvista.com> from "george anzinger" at May 20, 2 05:34:21 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 971 Lines: 29 Hello! > > if [ "$CONFIG_SMP" = "n" ]; then > > bool 'Preemptible Kernel' CONFIG_PREEMPT > > fi > > > That is not a fix! It is dodging the issue. ;) It is the only real fix, if you are going to follow this instruction: +RULE #1: Per-CPU data structures need explicit protection + + +Two similar problems arise. An example code snippet: + + struct this_needs_locking tux[NR_CPUS]; + tux[smp_processor_id()] = some_value; + /* task is preempted here... */ + something = tux[smp_processor_id()]; + +First, since the data is per-CPU, it may not have explicit SMP locking, but +require it otherwise. Second, when a preempted task is finally rescheduled, +the previous value of smp_processor_id may not equal the current. You must +protect these situations by disabling preemption around them. If you are not going to break all the kernel just make sure that tasks preempted in the kernel do not migrate. That's all, simple & stupid. Alexey From owner-netdev@oss.sgi.com Mon May 20 17:43:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4L0hNnC031522 for ; Mon, 20 May 2002 17:43:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4L0hNQo031521 for netdev-outgoing; Mon, 20 May 2002 17:43:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from nacho.alt.net (IDENT:qmailr@nacho.alt.net [207.14.113.18]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4L0hKnC031518 for ; Mon, 20 May 2002 17:43:20 -0700 Received: (qmail 20473 invoked by uid 500); 21 May 2002 00:44:10 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 21 May 2002 00:44:10 -0000 Date: Mon, 20 May 2002 17:44:10 -0700 (PDT) From: Chris Caputo To: netdev@oss.sgi.com cc: linux-kernel@vger.kernel.org, Subject: [PATCH] net/core/sock.c - 2.4.18 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 684 Lines: 20 This patch corrects a typo in net/core/sock.c. The assignment to sysctl_wmem_default was done twice in a row, rather than to sysctl_wmem_default and sysctl_rmem_default. This patch applies to 2.4.18. Chris --- net/core/sock.c.orig Fri Dec 21 09:42:05 2001 +++ net/core/sock.c Mon May 20 17:35:43 2002 @@ -626,7 +626,7 @@ sysctl_wmem_max = 32767; sysctl_rmem_max = 32767; sysctl_wmem_default = 32767; - sysctl_wmem_default = 32767; + sysctl_rmem_default = 32767; } else if (num_physpages >= 131072) { sysctl_wmem_max = 131071; sysctl_rmem_max = 131071; From owner-netdev@oss.sgi.com Mon May 20 17:47:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4L0lvnC031645 for ; Mon, 20 May 2002 17:47:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4L0lvRI031644 for netdev-outgoing; Mon, 20 May 2002 17:47:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4L0lqnC031641 for ; Mon, 20 May 2002 17:47:52 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id RAA09843; Mon, 20 May 2002 17:34:17 -0700 Date: Mon, 20 May 2002 17:34:16 -0700 (PDT) Message-Id: <20020520.173416.105610032.davem@redhat.com> To: kuznet@ms2.inr.ac.ru Cc: george@mvista.com, ak@suse.de, netdev@oss.sgi.com, linux-net@vger.kernel.org, ak@muc.de, pekkas@netcore.fi Subject: Re: System crash in tcp_fragment() From: "David S. Miller" In-Reply-To: <200205210041.EAA04407@sex.inr.ac.ru> References: <3CE9960D.15D41380@mvista.com> <200205210041.EAA04407@sex.inr.ac.ru> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1061 Lines: 30 From: kuznet@ms2.inr.ac.ru Date: Tue, 21 May 2002 04:41:39 +0400 (MSD) +Two similar problems arise. An example code snippet: + + struct this_needs_locking tux[NR_CPUS]; + tux[smp_processor_id()] = some_value; + /* task is preempted here... */ + something = tux[smp_processor_id()]; If you are not going to break all the kernel just make sure that tasks preempted in the kernel do not migrate. That's all, simple & stupid. Such rule does not even make this piece of code legal. Consider: task1:cpu0: x = counters[smp_processor_id()]; cpu0: PREEMPT task2:cpu0: x = counters[smp_processor_id()]; task2:cpu0: counters[smp_processor_id()] = x + 1; cpu0: PREEMPT task1:cpu0: counters[smp_processor_id()] = x + 1; full garbage But it does bring up important point, preemption people need to fully audit entire networking. It is totally broken by preemption the more I think about it. At the very beginning, all the SNMP counter bumping tricks will totally fail with preemption enabled. From owner-netdev@oss.sgi.com Mon May 20 17:49:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4L0nCnC031753 for ; Mon, 20 May 2002 17:49:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4L0nCA7031752 for netdev-outgoing; Mon, 20 May 2002 17:49:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4L0mmnC031749 for ; Mon, 20 May 2002 17:48:48 -0700 Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) 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 RAA09584 for ; Mon, 20 May 2002 17:49:32 -0700 (PDT) mail_from (andi@firstfloor.org) Received: from fwd01.sul.t-online.de by mailout11.sul.t-online.com with smtp id 179xgT-0000GF-02; Tue, 21 May 2002 02:39:25 +0200 Received: from averell.firstfloor.org (520003261363-0001@[217.82.110.248]) by fmrl01.sul.t-online.com with esmtp id 179xgP-14LjeaC; Tue, 21 May 2002 02:39:21 +0200 Received: by averell.firstfloor.org (Postfix on SuSE Linux 7.3 (i386), from userid 500) id 74CAE699B6; Tue, 21 May 2002 02:39:19 +0200 (CEST) Date: Tue, 21 May 2002 02:39:19 +0200 From: Andi Kleen To: george anzinger Cc: kuznet@ms2.inr.ac.ru, Andi Kleen , netdev@oss.sgi.com, linux-net@vger.kernel.org, davem@redhat.com, ak@muc.de, pekkas@netcore.fi Subject: Re: System crash in tcp_fragment() Message-ID: <20020521023919.A6593@averell> References: <200205210011.EAA04286@sex.inr.ac.ru> <3CE99434.20E7479C@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CE99434.20E7479C@mvista.com> User-Agent: Mutt/1.3.22.1i X-Sender: 520003261363-0001@t-dialin.net Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 564 Lines: 18 On Tue, May 21, 2002 at 02:26:29AM +0200, george anzinger wrote: > kuznet@ms2.inr.ac.ru wrote: > > > > Hello! > > > > > It's unfortunately the truth. Even in_interrupt() is buggy current > > > on SMP preemptive. > > > > And why folks working on preemtive kernel do not repair this? > > To all that I remember it is well known issue. > > > Ah, but we have. in_interrupt() was fixed about a month > ago. I think Robert got it into all the patches. Whats > more, it is a bit faster too :) It's not fixed in 2.5.15/16. I don't know about your patches. -Andi From owner-netdev@oss.sgi.com Mon May 20 18:00:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4L10WnC031955 for ; Mon, 20 May 2002 18:00:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4L10WS9031954 for netdev-outgoing; Mon, 20 May 2002 18:00:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4L10RnC031951 for ; Mon, 20 May 2002 18:00:27 -0700 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id FAA04437; Tue, 21 May 2002 05:00:12 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200205210100.FAA04437@sex.inr.ac.ru> Subject: Re: System crash in tcp_fragment() To: davem@redhat.com (David S. Miller) Date: Tue, 21 May 2002 05:00:11 +0400 (MSD) Cc: george@mvista.com, ak@suse.de, netdev@oss.sgi.com, linux-net@vger.kernel.org, ak@muc.de, pekkas@netcore.fi In-Reply-To: <20020520.173416.105610032.davem@redhat.com> from "David S. Miller" at May 20, 2 05:34:16 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 605 Lines: 22 Hello! > Such rule does not even make this piece of code legal. Consider: > > task1:cpu0: x = counters[smp_processor_id()]; > cpu0: PREEMPT > task2:cpu0: x = counters[smp_processor_id()]; > task2:cpu0: counters[smp_processor_id()] = x + 1; > cpu0: PREEMPT > task1:cpu0: counters[smp_processor_id()] = x + 1; > full garbage Yup. And this has nothing to do with SMP... > But it does bring up important point, preemption people need to > fully audit entire networking. Well, we can make this. It is too serious. Anyway, this means that preemptive patch for 2.4 is "tainting" :-) Alexey From owner-netdev@oss.sgi.com Mon May 20 18:49:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4L1nwnC032636 for ; Mon, 20 May 2002 18:49:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4L1nwpA032635 for netdev-outgoing; Mon, 20 May 2002 18:49:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4L1nrnC032631 for ; Mon, 20 May 2002 18:49:53 -0700 Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4L1nUg5141834; Mon, 20 May 2002 21:49:30 -0400 Received: from w-nivedita2.des.beaverton.ibm.com (w-nivedita2.des.beaverton.ibm.com [9.47.18.16]) by northrelay01.pok.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4L1nRG59200; Mon, 20 May 2002 21:49:27 -0400 Date: Mon, 20 May 2002 18:49:27 -0700 (PDT) From: Nivedita Singhvi X-X-Sender: To: "David S. Miller" cc: , , , , , , Subject: Re: System crash in tcp_fragment() In-Reply-To: <20020520.173416.105610032.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1097 Lines: 36 On Mon, 20 May 2002, David S. Miller wrote: > Such rule does not even make this piece of code legal. Consider: > > task1:cpu0: x = counters[smp_processor_id()]; > cpu0: PREEMPT > task2:cpu0: x = counters[smp_processor_id()]; > task2:cpu0: counters[smp_processor_id()] = x + 1; > cpu0: PREEMPT > task1:cpu0: counters[smp_processor_id()] = x + 1; > full garbage > > But it does bring up important point, preemption people need to > fully audit entire networking. > > It is totally broken by preemption the more I think about it. > > At the very beginning, all the SNMP counter bumping tricks will > totally fail with preemption enabled. > A lot of the synchronization between process context and interrupt context is based on per-cpu data structures or simple locks (without disabling irq's globally) eg: softnet_data queue (we only disable local interrupts), and synchronization between tcp_readmsg() and tcp_rcv() over the receive queue would get confused (lock.users flag would be different on another CPU).. Wonder how any of it could possibly work.. thanks, Nivedita From owner-netdev@oss.sgi.com Mon May 20 21:59:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4L4xYnC026067 for ; Mon, 20 May 2002 21:59:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4L4xY5d026066 for netdev-outgoing; Mon, 20 May 2002 21:59:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4L4xVnC026062 for ; Mon, 20 May 2002 21:59:31 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g4L50MX21484 for netdev@oss.sgi.com; Mon, 20 May 2002 22:00:22 -0700 Received: from 21cn.com ([202.104.32.249]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4JCsBnC008096 for ; Sun, 19 May 2002 05:54:12 -0700 Received: from arpabox([211.80.41.107]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jmd23ce7ebc5; Sun, 19 May 2002 20:55:41 +0800 Date: Sun, 19 May 2002 20:59:51 +0800 From: "Laudney Ren" Reply-To: laudney@21cn.com To: netdev Subject: T/TCP for Linux major update again. X-mailer: Foxmail 4.1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Message-ID: Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1009 Lines: 28 T/TCP for Linux has seen major progress in the last 1.5 months: 1. Documents updated Some core documents, including some graphs such as T/TCP sending and receiving flowgraphs and T/TCP state transition graph, have been carefully reviewed and modified. 2. Tools added "SourceInsight" has been added to the downloadable tools list. It's a Windows-based IDE especially suitable for complex projects involving plenty of files and functions. It enables you to jump directly from one variable to its type definition or from one function to called functions within it. A lot of other features prove incredibly useful. 3. First phase of debugging completed. The patch for 2.4.2 has successfully gone through kernel compilcation. The next phase of debugging will focus on function correctness based on RFC1644. The codes will be released soon along with guidance documents, so anyone interested can participate. Any comment is welcomed at laudney@21cn.com Laudney, Admin of Sourceforge project T/TCP for Linux From owner-netdev@oss.sgi.com Mon May 20 22:00:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4L50BnC026132 for ; Mon, 20 May 2002 22:00:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4L50BAa026131 for netdev-outgoing; Mon, 20 May 2002 22:00:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4L50AnC026128 for ; Mon, 20 May 2002 22:00:10 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g4L511Z21509 for netdev@oss.sgi.com; Mon, 20 May 2002 22:01:01 -0700 Received: from 21cn.com ([202.104.32.249]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4JCsdnC008192 for ; Sun, 19 May 2002 05:54:40 -0700 Received: from arpabox([211.80.41.107]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm183ce7ebe9; Sun, 19 May 2002 20:56:16 +0800 Date: Sun, 19 May 2002 21:0:35 +0800 From: "Laudney Ren" Reply-To: laudney@21cn.com To: netdev Subject: T/TCP for Linux major update again. X-mailer: Foxmail 4.1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Message-ID: Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1008 Lines: 27 T/TCP for Linux has seen major progress in the last 1.5 months: 1. Documents updated Some core documents, including some graphs such as T/TCP sending and receiving flowgraphs and T/TCP state transition graph, have been carefully reviewed and modified. 2. Tools added "SourceInsight" has been added to the downloadable tools list. It's a Windows-based IDE especially suitable for complex projects involving plenty of files and functions. It enables you to jump directly from one variable to its type definition or from one function to called functions within it. A lot of other features prove incredibly useful. 3. First phase of debugging completed. The patch for 2.4.2 has successfully gone through kernel compilcation. The next phase of debugging will focus on function correctness based on RFC1644. The codes will be released soon along with guidance documents, so anyone interested can participate. Any comment is welcomed at laudney@21cn.com Laudney, Admin of Sourceforge project T/TCP for Linux From owner-netdev@oss.sgi.com Mon May 20 23:09:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4L69JnC026809 for ; Mon, 20 May 2002 23:09:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4L69JCF026808 for netdev-outgoing; Mon, 20 May 2002 23:09:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4L69CnC026802 for ; Mon, 20 May 2002 23:09:12 -0700 Received: from data.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id XAA22738; Mon, 20 May 2002 23:08:24 -0700 Received: from mvista.com (IDENT:george@localhost [127.0.0.1]) by data.mvista.com (8.9.3/8.9.3) with ESMTP id XAA14596; Mon, 20 May 2002 23:08:38 -0700 Message-ID: <3CE9E466.AC2358EE@mvista.com> Date: Mon, 20 May 2002 23:08:38 -0700 From: george anzinger Organization: Monta Vista Software X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12-20b i686) X-Accept-Language: en MIME-Version: 1.0 To: Nivedita Singhvi CC: "David S. Miller" , kuznet@ms2.inr.ac.ru, ak@suse.de, netdev@oss.sgi.com, linux-net@vger.kernel.org, ak@muc.de, pekkas@netcore.fi Subject: Re: System crash in tcp_fragment() References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1925 Lines: 54 Nivedita Singhvi wrote: > > On Mon, 20 May 2002, David S. Miller wrote: > > > Such rule does not even make this piece of code legal. Consider: > > > > task1:cpu0: x = counters[smp_processor_id()]; > > cpu0: PREEMPT > > task2:cpu0: x = counters[smp_processor_id()]; > > task2:cpu0: counters[smp_processor_id()] = x + 1; > > cpu0: PREEMPT > > task1:cpu0: counters[smp_processor_id()] = x + 1; > > full garbage > > > > But it does bring up important point, preemption people need to > > fully audit entire networking. > > > > It is totally broken by preemption the more I think about it. > > > > At the very beginning, all the SNMP counter bumping tricks will > > totally fail with preemption enabled. May be someone could tell me if these matter. If you are bumping a counter and you switch cpus in the middle, a.) does it matter? and b.) if so which cpu should get the count? I sort of thought that, if this were going on, it did not really matter as long as some counter was bumped. > > > > A lot of the synchronization between process context and interrupt > context is based on per-cpu data structures or simple locks > (without disabling irq's globally) eg: > > softnet_data queue (we only disable local interrupts), and > synchronization between tcp_readmsg() and tcp_rcv() over > the receive queue would get confused (lock.users flag would > be different on another CPU).. Disabling local interrupts also disables preemption, as does interrupt context. > > Wonder how any of it could possibly work.. It seems to take a LOT of work to break it. Even then, I think this problem at hand is in the driver (a new one from the intel folks). -- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Real time sched: http://sourceforge.net/projects/rtsched/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml From owner-netdev@oss.sgi.com Mon May 20 23:14:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4L6E6nC026949 for ; Mon, 20 May 2002 23:14:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4L6E6kQ026948 for netdev-outgoing; Mon, 20 May 2002 23:14:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4L6DvnC026942 for ; Mon, 20 May 2002 23:13:57 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id XAA11744; Mon, 20 May 2002 23:00:22 -0700 Date: Mon, 20 May 2002 23:00:21 -0700 (PDT) Message-Id: <20020520.230021.29510217.davem@redhat.com> To: george@mvista.com Cc: niv@us.ibm.com, kuznet@ms2.inr.ac.ru, ak@suse.de, netdev@oss.sgi.com, linux-net@vger.kernel.org, ak@muc.de, pekkas@netcore.fi Subject: Re: System crash in tcp_fragment() From: "David S. Miller" In-Reply-To: <3CE9E466.AC2358EE@mvista.com> References: <3CE9E466.AC2358EE@mvista.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1936 Lines: 58 From: george anzinger Date: Mon, 20 May 2002 23:08:38 -0700 Nivedita Singhvi wrote: > > On Mon, 20 May 2002, David S. Miller wrote: > > > Such rule does not even make this piece of code legal. Consider: > > > > task1:cpu0: x = counters[smp_processor_id()]; > > cpu0: PREEMPT > > task2:cpu0: x = counters[smp_processor_id()]; > > task2:cpu0: counters[smp_processor_id()] = x + 1; > > cpu0: PREEMPT > > task1:cpu0: counters[smp_processor_id()] = x + 1; > > full garbage May be someone could tell me if these matter. If you are bumping a counter and you switch cpus in the middle, a.) does it matter? and b.) if so which cpu should get the count? I sort of thought that, if this were going on, it did not really matter as long as some counter was bumped. That's not the problem. We use per-cpu values for each counter (and when the user asks for the value, we add together the values from each processor). Please review the example I quote above, you aren't reading it carefully enough. Let us imagine that we are dealing with counter "X", and that the values at the beginning of the example are: X[0] = 5 X[1] = 7 X[2] = ... Actually, no values matter for the purposes of this example except the one for cpu 0. Here is what happens, watch carefully: > > task1:cpu0: x = counters[smp_processor_id()]; > > cpu0: PREEMPT task1 sees 'x' as '5' > > task2:cpu0: x = counters[smp_processor_id()]; > > task2:cpu0: counters[smp_processor_id()] = x + 1; > > cpu0: PREEMPT task2 bumps the counter to '6' > > task1:cpu0: counters[smp_processor_id()] = x + 1; > > full garbage task1 also bumps the counter to '6' This is the problem. We make these counters non-atomic on purpose for performance reasons, so do not mention that as a possible fix. From owner-netdev@oss.sgi.com Tue May 21 00:26:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4L7QVnC027846 for ; Tue, 21 May 2002 00:26:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4L7QViO027845 for netdev-outgoing; Tue, 21 May 2002 00:26:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4L7QMnC027842 for ; Tue, 21 May 2002 00:26:22 -0700 Received: from data.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id AAA23560; Tue, 21 May 2002 00:25:32 -0700 Received: from mvista.com (IDENT:george@localhost [127.0.0.1]) by data.mvista.com (8.9.3/8.9.3) with ESMTP id AAA17867; Tue, 21 May 2002 00:25:46 -0700 Message-ID: <3CE9F679.90ACF597@mvista.com> Date: Tue, 21 May 2002 00:25:46 -0700 From: george anzinger Organization: Monta Vista Software X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12-20b i686) X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: niv@us.ibm.com, kuznet@ms2.inr.ac.ru, ak@suse.de, netdev@oss.sgi.com, linux-net@vger.kernel.org, ak@muc.de, pekkas@netcore.fi Subject: Re: System crash in tcp_fragment() References: <3CE9E466.AC2358EE@mvista.com> <20020520.230021.29510217.davem@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2744 Lines: 78 "David S. Miller" wrote: > > From: george anzinger > Date: Mon, 20 May 2002 23:08:38 -0700 > > Nivedita Singhvi wrote: > > > > On Mon, 20 May 2002, David S. Miller wrote: > > > > > Such rule does not even make this piece of code legal. Consider: > > > > > > task1:cpu0: x = counters[smp_processor_id()]; > > > cpu0: PREEMPT > > > task2:cpu0: x = counters[smp_processor_id()]; > > > task2:cpu0: counters[smp_processor_id()] = x + 1; > > > cpu0: PREEMPT > > > task1:cpu0: counters[smp_processor_id()] = x + 1; > > > full garbage > > May be someone could tell me if these matter. If you are > bumping a counter and you switch cpus in the middle, a.) > does it matter? and b.) if so which cpu should get the > count? I sort of thought that, if this were going on, it > did not really matter as long as some counter was bumped. > > That's not the problem. We use per-cpu values for each counter (and > when the user asks for the value, we add together the values from > each processor). > > Please review the example I quote above, you aren't reading it > carefully enough. > > Let us imagine that we are dealing with counter "X", and > that the values at the beginning of the example are: > > X[0] = 5 > X[1] = 7 > X[2] = ... > > Actually, no values matter for the purposes of this example > except the one for cpu 0. Here is what happens, watch carefully: > > > > task1:cpu0: x = counters[smp_processor_id()]; > > > cpu0: PREEMPT > > task1 sees 'x' as '5' > > > > task2:cpu0: x = counters[smp_processor_id()]; > > > task2:cpu0: counters[smp_processor_id()] = x + 1; > > > cpu0: PREEMPT > > task2 bumps the counter to '6' > > > > task1:cpu0: counters[smp_processor_id()] = x + 1; > > > full garbage > > task1 also bumps the counter to '6' > > This is the problem. We make these counters non-atomic on purpose > for performance reasons, so do not mention that as a possible fix. I understand the issue. The question is what is the result. Bogus numbers do.. what? Does the kernel crash or does the user think strange things while every thing just keeps on working? As for the fix, I would think that would be more up to the network folks than me. Atomic is one option, but you can also disable preemption. It is really light weight, and may already be disabled in some of these cases. -- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Real time sched: http://sourceforge.net/projects/rtsched/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml From owner-netdev@oss.sgi.com Tue May 21 00:36:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4L7aSnC028031 for ; Tue, 21 May 2002 00:36:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4L7aS2H028030 for netdev-outgoing; Tue, 21 May 2002 00:36:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4L7aPnC028027 for ; Tue, 21 May 2002 00:36:25 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id AAA12081; Tue, 21 May 2002 00:22:50 -0700 Date: Tue, 21 May 2002 00:22:49 -0700 (PDT) Message-Id: <20020521.002249.96290519.davem@redhat.com> To: george@mvista.com Cc: niv@us.ibm.com, kuznet@ms2.inr.ac.ru, ak@suse.de, netdev@oss.sgi.com, linux-net@vger.kernel.org, ak@muc.de, pekkas@netcore.fi Subject: Re: System crash in tcp_fragment() From: "David S. Miller" In-Reply-To: <3CE9F679.90ACF597@mvista.com> References: <3CE9E466.AC2358EE@mvista.com> <20020520.230021.29510217.davem@redhat.com> <3CE9F679.90ACF597@mvista.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 437 Lines: 12 From: george anzinger Date: Tue, 21 May 2002 00:25:46 -0700 I understand the issue. The question is what is the result. Bogus numbers do.. what? Does the kernel crash or does the user think strange things while every thing just keeps on working? It's a quality of implementation issue. It is just one example of a place where we use these kinds of assumptions to index tables and the like. From owner-netdev@oss.sgi.com Tue May 21 00:58:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4L7wWnC028332 for ; Tue, 21 May 2002 00:58:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4L7wWoM028331 for netdev-outgoing; Tue, 21 May 2002 00:58:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4L7wTnC028323 for ; Tue, 21 May 2002 00:58:29 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id AAA12174; Tue, 21 May 2002 00:45:25 -0700 Date: Tue, 21 May 2002 00:45:24 -0700 (PDT) Message-Id: <20020521.004524.34353384.davem@redhat.com> To: ccaputo@alt.net Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org Subject: Re: [PATCH] net/core/sock.c - 2.4.18 From: "David S. Miller" In-Reply-To: References: X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 342 Lines: 10 From: Chris Caputo Date: Mon, 20 May 2002 17:44:10 -0700 (PDT) This patch corrects a typo in net/core/sock.c. The assignment to sysctl_wmem_default was done twice in a row, rather than to sysctl_wmem_default and sysctl_rmem_default. This patch applies to 2.4.18. Thanks, I've applied your patch. From owner-netdev@oss.sgi.com Tue May 21 02:48:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4L9mdnC029852 for ; Tue, 21 May 2002 02:48:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4L9mdhL029851 for netdev-outgoing; Tue, 21 May 2002 02:48:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4L9manC029848 for ; Tue, 21 May 2002 02:48:37 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 8E4211E475; Tue, 21 May 2002 11:49:23 +0200 (MEST) Date: Tue, 21 May 2002 11:49:22 +0200 From: Andi Kleen To: "David S. Miller" Cc: george@mvista.com, niv@us.ibm.com, kuznet@ms2.inr.ac.ru, ak@suse.de, netdev@oss.sgi.com, linux-net@vger.kernel.org, ak@muc.de, pekkas@netcore.fi Subject: Re: System crash in tcp_fragment() Message-ID: <20020521114922.B6519@wotan.suse.de> References: <3CE9E466.AC2358EE@mvista.com> <20020520.230021.29510217.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020520.230021.29510217.davem@redhat.com> User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 411 Lines: 13 > That's not the problem. We use per-cpu values for each counter (and > when the user asks for the value, we add together the values from > each processor). At least on x86 gcc usually seems to just generate an incl, which should be ok because it is atomic enough (even when a reschedule happens it will act as a full memory barrier) So it'll likely just be a problem for load-store architectures. -Andi From owner-netdev@oss.sgi.com Tue May 21 05:45:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4LCj8nC032516 for ; Tue, 21 May 2002 05:45:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4LCj8Ku032515 for netdev-outgoing; Tue, 21 May 2002 05:45:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from acaro.org (hwadsl-213-155-200-58.telvia.it [213.155.200.58]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4LCj3nC032509 for ; Tue, 21 May 2002 05:45:04 -0700 Received: (qmail 2393 invoked from network); 21 May 2002 12:47:55 -0000 Received: from unknown (HELO tyler) (192.168.1.4) by 0 with SMTP; 21 May 2002 12:47:55 -0000 Received: by tyler (Postfix, from userid 1000) id 0DCA36C; Wed, 22 May 2002 14:39:13 +0200 (CEST) Date: Wed, 22 May 2002 14:39:13 +0200 From: thefly To: netdev@oss.sgi.com Subject: scm_cookie Message-ID: <20020522123913.GA357@tyler> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Mailer: Mutt 1.3.28i (2002-03-13) X-Editor: VIM - Vi IMproved 6.1 (2002 Mar 24, compiled May 4 2002 18:29:30) Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 426 Lines: 13 hi, would anyone be so kind to explain me what scm_cookie function & stuff is about? I've searched google but can't find anything except questions about this. TIA P.S.= if more of this email arrive on the ml it's because i've sent 2 to different addresses, and i suspect both to be linked to the same ml. -- Claudio "thefly" Martella thefly@acaro.org claudio.martella@polimi.it ... Powered by Debian GNU/Linux From owner-netdev@oss.sgi.com Tue May 21 05:48:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4LCmMnC032631 for ; Tue, 21 May 2002 05:48:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4LCmMYS032630 for netdev-outgoing; Tue, 21 May 2002 05:48:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4LCmHnC032627 for ; Tue, 21 May 2002 05:48:18 -0700 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id QAA05603; Tue, 21 May 2002 16:47:40 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200205211247.QAA05603@sex.inr.ac.ru> Subject: Re: System crash in tcp_fragment() To: george@mvista.com (george anzinger) Date: Tue, 21 May 2002 16:47:40 +0400 (MSD) Cc: davem@redhat.com, niv@us.ibm.com, ak@suse.de, netdev@oss.sgi.com, linux-net@vger.kernel.org, ak@muc.de, pekkas@netcore.fi In-Reply-To: <3CE9F679.90ACF597@mvista.com> from "george anzinger" at May 21, 2 00:25:46 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 183 Lines: 16 Hello! > I understand the issue. I do not. +#define preempt_disable() \ +do { \ + ++current->preempt_count; \ + barrier(); \ +} while (0) Why does this work? Alexey From owner-netdev@oss.sgi.com Tue May 21 05:54:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4LCsAnC032757 for ; Tue, 21 May 2002 05:54:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4LCsAPX032756 for netdev-outgoing; Tue, 21 May 2002 05:54:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4LCs8nC032753 for ; Tue, 21 May 2002 05:54:08 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 6291F1E65F; Tue, 21 May 2002 14:54:55 +0200 (MEST) Date: Tue, 21 May 2002 14:54:52 +0200 From: Andi Kleen To: george anzinger Cc: "David S. Miller" , niv@us.ibm.com, kuznet@ms2.inr.ac.ru, ak@suse.de, netdev@oss.sgi.com, linux-net@vger.kernel.org, ak@muc.de, pekkas@netcore.fi Subject: Re: System crash in tcp_fragment() Message-ID: <20020521145452.A13073@wotan.suse.de> References: <3CE9E466.AC2358EE@mvista.com> <20020520.230021.29510217.davem@redhat.com> <3CE9F679.90ACF597@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CE9F679.90ACF597@mvista.com> User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 361 Lines: 9 > As for the fix, I would think that would be more up to the > network folks than me. Atomic is one option, but you can > also disable preemption. It is really light weight, and may > already be disabled in some of these cases. In most of them because it is running in a softirq. Just the user context stuff has a possible problem on non i386/x86-64. -Andi From owner-netdev@oss.sgi.com Tue May 21 08:43:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4LFhjnC002847 for ; Tue, 21 May 2002 08:43:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4LFhjGU002846 for netdev-outgoing; Tue, 21 May 2002 08:43:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4LFhenC002843 for ; Tue, 21 May 2002 08:43:40 -0700 Received: from data.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id IAA32445; Tue, 21 May 2002 08:42:48 -0700 Received: from mvista.com (IDENT:george@localhost [127.0.0.1]) by data.mvista.com (8.9.3/8.9.3) with ESMTP id IAA19587; Tue, 21 May 2002 08:42:52 -0700 Message-ID: <3CEA6AFB.D9797E5@mvista.com> Date: Tue, 21 May 2002 08:42:51 -0700 From: george anzinger Organization: Monta Vista Software X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12-20b i686) X-Accept-Language: en MIME-Version: 1.0 To: kuznet@ms2.inr.ac.ru CC: davem@redhat.com, niv@us.ibm.com, ak@suse.de, netdev@oss.sgi.com, linux-net@vger.kernel.org, ak@muc.de, pekkas@netcore.fi Subject: Re: System crash in tcp_fragment() References: <200205211247.QAA05603@sex.inr.ac.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 688 Lines: 28 kuznet@ms2.inr.ac.ru wrote: > > Hello! > > > I understand the issue. > > I do not. > > +#define preempt_disable() \ > +do { \ > + ++current->preempt_count; \ > + barrier(); \ > +} while (0) > > Why does this work? > > Alexey Preemption can only happen if the task is interrupted. The interrupt exit code will not preempt if preempt_count is more than zero. The barrier() forces the result to memory so the interrupt code can find it. -- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Real time sched: http://sourceforge.net/projects/rtsched/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml From owner-netdev@oss.sgi.com Wed May 22 08:05:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4MF5InC007685 for ; Wed, 22 May 2002 08:05:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4MF5HEI007684 for netdev-outgoing; Wed, 22 May 2002 08:05:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from aol.com ([212.0.215.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4MF58nC007662 for ; Wed, 22 May 2002 08:05:11 -0700 Received: from unknown (HELO rly-yk05.pesdets.com) (117.243.97.158) by asy100.as122.sol-superunderline.com with NNFMP; Tue, 21 May 0102 23:08:50 -0100 Received: from unknown (HELO sparc.zubilam.net) (23.206.52.60) by rly-yk05.pesdets.com with QMQP; 21 May 0102 22:06:03 +1100 Received: from [83.55.62.39] by sydint1.microthink.com.au with local; Wed, 22 May 0102 09:03:16 +0600 Reply-To: Message-ID: <033e81a41a5e$7737e5d7$0de61da2@nbighl> From: To: vincent@oss.sgi.com Subject: suite a notre conversation 5623lwnA2-00-11 Date: Wed, 22 May 0102 05:43:00 +0900 MiME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00C6_81A50A7B.D3078C12" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: MIME-tools 5.503 (Entity 5.501) Importance: Normal Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1315 Lines: 25 ------=_NextPart_000_00C6_81A50A7B.D3078C12 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 c2FsdXQgbmljbyAgIQ0KDQpzdWl0ZSDgIG5vdHJlIGRpc2N1c3Npb24gZCdo aWVyLA0KamUgdGUgY29uZmlybWUgYmllbiBsYSBub3V2ZWxsZToNCg0KQ2Vj aWxlIGVzdCBFTkNFSU5URSEhIQ0KDQpPbiBzJ2VuIGRvdXRhaXQgYmllbiwg ZWxsZSBuJ2EgdnJhaW1lbnQNCnBhcyBwZXJkdSBkZSB0ZW1wcywgY2VsbGUg bGEuDQpUZXMgZG91dGVzIGV0YWllbnQgYmllbiBmb25kZXMhDQpqZSB0ZSBk b2lzIGRvbmMgMTAwIGV1cm9zIGNvbW1lIHByb21pcyENCk1haXMgcXVlbGxl IGNvbm5lIGNldHRlIENlY2lsZSwgZWxsZSBhDQpyZXVzc2kgc29uIGNvdXAh ISEgUGF1dnJlIGp1bGllbiENCkxlIHZvaWxhIHBhcGEgbWFpbnRlbmFudCEN CkZpbmkgbGVzIGJvaXRlcyBkZSBudWl0cyBldCBsZXMgZmlsbGVzIGEgZ29n byENCg0KYXUgZmFpdCwgZW4gcGFybGFudCBkZSBmaWxsZXM6IHZhcyBkb25j IGZhaXJlDQp1biB0b3VyIHN1ciBjZSBzaXRlOg0KDQpodHRwOi8vd3d3LnNl eC1hbm51YWlyZS5jb20NCg0KKGMnZXN0IGhhbGx1Y2luYW50LCB5IGEgcXVh c2ltZW50IHF1ZSBkZXMgdHJ1Y3MNCmdyYXR1aXRzIGV0IGVuIHBsdXMgeSBh IGRlIHRvdXQ6IGRlcyBsZXNiaWVubmVzLA0KZHUgZmV0aWNoaXNtZSwgZGVz IGJsYWNrcywgZHUgY3JhZGUuLi4pDQoNCkJvbiBhbGxleiBqZSB0ZSBsYWlz c2UhDQoNCkEgc2FtZWRpIHNvaXIhDQoNClZpbmNlbnQuDQoNClBTOiAgUGF1 dnJlIGp1bGllbiENCg0KUFMyOiBWYSB2aXRlIHZvaXIgaHR0cDovL3d3dy5z ZXgtYW5udWFpcmUuY29tIChjJ2VzdCBncmF0dWl0ISEhKQ0KDQpQUzM6IE9u IHNlIHZvaXQgc2FtZWRpIHNvaXIhIA0KNDg1M1FhZ1A5LTk5M1Z4TmU4OTI3 bEt1RjktNjYzTklvUzQ0MTFsMzY= From owner-netdev@oss.sgi.com Thu May 23 02:08:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4N98RnC007674 for ; Thu, 23 May 2002 02:08:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4N98Rbq007673 for netdev-outgoing; Thu, 23 May 2002 02:08:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from luxik.cdi.cz (root@inway106.cdi.cz [213.151.81.106]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4N98LnC007665 for ; Thu, 23 May 2002 02:08:23 -0700 Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 17AoaQ-0004H3-00; Thu, 23 May 2002 11:08:42 +0200 Date: Thu, 23 May 2002 11:08:41 +0200 (CEST) From: Martin Devera To: kuznet@ms2.inr.ac.ru cc: netdev@oss.sgi.com Subject: PSCHED_GET_TIME related bug: jiffies wraparound In-Reply-To: <200205161708.VAA22517@sex.inr.ac.ru> Message-ID: References: <200205161708.VAA22517@sex.inr.ac.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 931 Lines: 29 Hello Alexey, I hope the 0xffffffff change will go into pre9. I've another potential bug for you ;) The clock watcher uses this code in psched_tick: unsigned long now = jiffies; psched_time_base = ((u64)now)<; Thu, 23 May 2002 07:44:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4NEi9Hm020587 for netdev-outgoing; Thu, 23 May 2002 07:44:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4NEi5nC020584 for ; Thu, 23 May 2002 07:44:06 -0700 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id SAA11574; Thu, 23 May 2002 18:44:07 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200205231444.SAA11574@sex.inr.ac.ru> Subject: Re: PSCHED_GET_TIME related bug: jiffies wraparound To: devik@cdi.cz (Martin Devera) Date: Thu, 23 May 2002 18:44:07 +0400 (MSD) Cc: netdev@oss.sgi.com In-Reply-To: from "Martin Devera" at May 23, 2 11:08:41 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 199 Lines: 11 Hello! > I hope the 0xffffffff change will go into pre9. Did Dave ack that patch? I did not resend it, to be honest. > I've another potential bug for you ;) OK. I will pack both of them. Alexey From owner-netdev@oss.sgi.com Thu May 23 08:22:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4NFM2nC021571 for ; Thu, 23 May 2002 08:22:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4NFM2g5021570 for netdev-outgoing; Thu, 23 May 2002 08:22:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from luxik.cdi.cz (root@inway106.cdi.cz [213.151.81.106]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4NFLwnC021566 for ; Thu, 23 May 2002 08:21:59 -0700 Received: from localhost ([127.0.0.1] ident=devik) by luxik.cdi.cz with esmtp (Exim 3.34 #3) id 17AuPw-0005zC-00; Thu, 23 May 2002 17:22:16 +0200 Date: Thu, 23 May 2002 17:22:16 +0200 (CEST) From: Martin Devera To: kuznet@ms2.inr.ac.ru cc: netdev@oss.sgi.com Subject: Re: PSCHED_GET_TIME related bug: jiffies wraparound In-Reply-To: <200205231444.SAA11574@sex.inr.ac.ru> Message-ID: References: <200205231444.SAA11574@sex.inr.ac.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 599 Lines: 19 Hello, > > I hope the 0xffffffff change will go into pre9. > > Did Dave ack that patch? I did not resend it, to be honest. He didn't (at least not to me). I've to admit I've no experience with submitting patches to main kernel. A sent them to you because you are author of these parts and I haven't wanted to bypass you. > > I've another potential bug for you ;) > > OK. I will pack both of them. Thanks. I should say that I didn't tested the change extensively but seems to work (I didn't tested it 497 days however :). Probably the change is simple enough to be validated at the first sight. From owner-netdev@oss.sgi.com Thu May 23 11:15:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4NIFqnC026642 for ; Thu, 23 May 2002 11:15:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4NIFqe6026641 for netdev-outgoing; Thu, 23 May 2002 11:15:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4NIErnC026633 for ; Thu, 23 May 2002 11:14:53 -0700 Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4NIFmL24655 for ; Thu, 23 May 2002 14:15:48 -0400 (EDT) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KWNA5ZQ2; Thu, 23 May 2002 14:15:41 -0400 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K4QLQ2S3; Thu, 23 May 2002 14:16:11 -0400 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 6A0A63E4 for ; Thu, 23 May 2002 14:15:47 -0400 (EDT) Message-ID: <3CED31D3.B5892DF4@nortelnetworks.com> Date: Thu, 23 May 2002 14:15:47 -0400 From: Chris Friesen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: how to get per-socket stats on udp rx buffer overflow? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 446 Lines: 14 Is there any way for me to see how many incoming packets were dropped on a udp socket due to overflowing the input buffer? I specifically want this information on a per-socket basis. Thanks, Chris -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com From owner-netdev@oss.sgi.com Fri May 24 10:42:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4OHgRnC010230 for ; Fri, 24 May 2002 10:42:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4OHgRdD010229 for netdev-outgoing; Fri, 24 May 2002 10:42:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from files.ssi.bg (qmailr@files.ssi.bg [212.95.166.21]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4OHgGnC010223 for ; Fri, 24 May 2002 10:42:17 -0700 Received: (qmail 13228 invoked from network); 24 May 2002 17:43:21 -0000 Received: from mars.z.ssi.bg (alex@212.95.167.194) by mail.ssi.bg with SMTP; 24 May 2002 17:43:21 -0000 Date: Fri, 24 May 2002 20:43:41 +0300 (EEST) From: Alexander Atanasov X-Sender: alex@mars.z.ssi.bg To: rusty@rustcorp.com.au, kuznet@ms2.inr.ac.ru cc: netfilter@lists.samba.org, netdev@oss.sgi.com Subject: [PATCH] ipchains bugs in 2.2/2.4/2.5 related to netlink calls Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1607778983-1170993050-1022262221=:208" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 3125 Lines: 71 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1607778983-1170993050-1022262221=:208 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi there! oom-loop fixes error handling after a netlink failure - it does not do a cleanup and it makes every next call to ip_fw_check to detect a loop and drop the packet. nlma fixes a call to netlink_broadcast with GFP_KERNEL ( passed to skb_clone ) while we are in_interrupt() ( catched by a BUG() in slab.c:1109 ). 2.4 patches apply to 2.5 too , tested on 2.5.15. -- Best Regards, Alexander Atanasov --1607778983-1170993050-1022262221=:208 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="ipchains_core.c-oom-loop-2.4.18.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="ipchains_core.c-oom-loop-2.4.18.diff" LS0tIG5ldC9pcHY0L25ldGZpbHRlci9pcGNoYWluc19jb3JlLmMub3JpZwlG cmkgTWF5IDI0IDE5OjI3OjAxIDIwMDINCisrKyBuZXQvaXB2NC9uZXRmaWx0 ZXIvaXBjaGFpbnNfY29yZS5jCUZyaSBNYXkgMjQgMTk6MzE6MjQgMjAwMg0K QEAgLTcyMyw2ICs3MjMsNyBAQA0KIAkJCQkJCSAgICAgIHNyY19wb3J0LCBk c3RfcG9ydCwNCiAJCQkJCQkgICAgICBjb3VudCwgdGNwc3luKSkgew0KIAkJ CQkJcmV0ID0gRldfQkxPQ0s7DQorCQkJCQljbGVhbnVwKGNoYWluLCAwLCBz bG90KTsNCiAJCQkJCWdvdG8gb3V0Ow0KIAkJCQl9DQogCQkJCWJyZWFrOw0K --1607778983-1170993050-1022262221=:208 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="ipchains_core.c-nlma-2.4.18.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="ipchains_core.c-nlma-2.4.18.diff" LS0tIG5ldC9pcHY0L25ldGZpbHRlci9pcGNoYWluc19jb3JlLmMub3JpZwlG cmkgTWF5IDI0IDE5OjI3OjAxIDIwMDINCisrKyBuZXQvaXB2NC9uZXRmaWx0 ZXIvaXBjaGFpbnNfY29yZS5jCUZyaSBNYXkgMjQgMTk6Mjc6MzQgMjAwMg0K QEAgLTU0OSw3ICs1NDksNyBAQA0KIAkJCXN0cmNweShvdXRza2ItPmRhdGEr c2l6ZW9mKF9fdTMyKSoyLCByaWYpOw0KIAkJCW1lbWNweShvdXRza2ItPmRh dGErc2l6ZW9mKF9fdTMyKSoyK0lGTkFNU0laLCBpcCwNCiAJCQkgICAgICAg bGVuLShzaXplb2YoX191MzIpKjIrSUZOQU1TSVopKTsNCi0JCQluZXRsaW5r X2Jyb2FkY2FzdChpcGZ3c2ssIG91dHNrYiwgMCwgfjAsIEdGUF9LRVJORUwp Ow0KKwkJCW5ldGxpbmtfYnJvYWRjYXN0KGlwZndzaywgb3V0c2tiLCAwLCB+ MCwgR0ZQX0FUT01JQyk7DQogCQl9DQogCQllbHNlIHsNCiAjZW5kaWYNCg== --1607778983-1170993050-1022262221=:208 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="ip_fw.c-oom-loop-2.2.20.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="ip_fw.c-oom-loop-2.2.20.diff" LS0tIG5ldC9pcHY0L2lwX2Z3LmMub3JpZwlGcmkgTWF5IDI0IDE5OjMzOjUy IDIwMDINCisrKyBuZXQvaXB2NC9pcF9mdy5jCUZyaSBNYXkgMjQgMTk6MzQ6 MTggMjAwMg0KQEAgLTc0Nyw2ICs3NDcsNyBAQA0KIAkJCQkJCSAgICAgIHNy Y19wb3J0LCBkc3RfcG9ydCwNCiAJCQkJCQkgICAgICBjb3VudCwgdGNwc3lu KSkgew0KIAkJCQkJcmV0ID0gRldfQkxPQ0s7DQorCQkJCQljbGVhbnVwKGNo YWluLCAwLCBzbG90KTsNCiAJCQkJCWdvdG8gb3V0Ow0KIAkJCQl9DQogCQkJ CWJyZWFrOw0K --1607778983-1170993050-1022262221=:208-- From owner-netdev@oss.sgi.com Sat May 25 05:07:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4PC7UnC001181 for ; Sat, 25 May 2002 05:07:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4PC7U0j001180 for netdev-outgoing; Sat, 25 May 2002 05:07:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from loewe.cosy.sbg.ac.at (loewe.cosy.sbg.ac.at [141.201.2.12]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4PC7QnC001177 for ; Sat, 25 May 2002 05:07:27 -0700 Received: from mausmaki.cosy.sbg.ac.at (mausmaki.cosy.sbg.ac.at [141.201.2.18]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id OAA08322 for ; Sat, 25 May 2002 14:08:35 +0200 (MET DST) Date: Sat, 25 May 2002 14:08:35 +0200 (MET DST) From: "Thomas 'Dent' Mirlacher" To: netdev@oss.sgi.com Subject: 802.2 question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 176 Lines: 11 hi list, do we have to check for the OUI in 802.2 SNAP? or is it sufficient to check for the 16bit type field? thanks, tm -- in some way i do, and in some way i don't. From owner-netdev@oss.sgi.com Sun May 26 12:37:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4QJbSnC022352 for ; Sun, 26 May 2002 12:37:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4QJbSX4022351 for netdev-outgoing; Sun, 26 May 2002 12:37:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from ghanima.endorphin.org (nil@chello080108023209.34.11.vie.surfer.at [80.108.23.209]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4QJbJnC022348 for ; Sun, 26 May 2002 12:37:22 -0700 Received: (qmail 3784 invoked by uid 1000); 26 May 2002 19:38:28 -0000 Date: Sun, 26 May 2002 21:38:28 +0200 To: netdev@oss.sgi.com Subject: extending dst_entry Message-ID: <20020526193828.GA3366@ghanima.endorphin.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline User-Agent: Mutt/1.3.28i From: "Fruhwirth Clemens" X-Delivery-Agent: TMDA/0.47 (Python 2.1.3 on linux2) Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1160 Lines: 38 --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi! i'd like to add an netfilter module, which limits the diversity of tcp/udp ports for a given remote peer via a tocken bucket filter. the aim of that is mainly an instant response to port scans. it's quite easy to modify the "limit" module that netfilter has right now, but in opposite to this module my module will need to store information with every remote peer instead of a global match rule state. so i'm thinking about extending dst_entry and further dst.c to contain netfilter specific code, which lead to a not so nice spagetti code architecture. any other suggestions how i could store peer specific information without implementing an dst_entry styled hashtable on my own? clemens please CC me, not on list. --82I3+IH0IqGh5yIs 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 iD8DBQE88Tm0HkYGUbdPrgQRApw0AJ9wpEGby4CH+CvFAumeRQgMpJO95QCfWFrF W1vmy6/1jlBftfAM3yIjY2o= =voQX -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs-- From owner-netdev@oss.sgi.com Sun May 26 20:08:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4R385nC025053 for ; Sun, 26 May 2002 20:08:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4R385fi025052 for netdev-outgoing; Sun, 26 May 2002 20:08:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4R37xnC025049 for ; Sun, 26 May 2002 20:07:59 -0700 Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4R399g5156646 for ; Sun, 26 May 2002 23:09:10 -0400 Received: from w-nivedita2.des.beaverton.ibm.com (w-nivedita2.des.beaverton.ibm.com [9.47.18.16]) by northrelay01.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4R397n118940 for ; Sun, 26 May 2002 23:09:07 -0400 Date: Sun, 26 May 2002 20:09:08 -0700 (PDT) From: Nivedita Singhvi X-X-Sender: To: Subject: [PATCH RFC] 2.4.18+ cache align some tcp globals Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1304 Lines: 40 This makes some of the tcp globals cache aligned in SMP systems (trying to address cacheline bouncing on busy systems). Patch applies to 2.4.18. thanks, Nivedita --- tcp.c Fri Dec 21 09:42:05 2001 +++ tcp.c.new Sun May 26 19:55:45 2002 @@ -266,20 +266,22 @@ kmem_cache_t *tcp_bucket_cachep; kmem_cache_t *tcp_timewait_cachep; -atomic_t tcp_orphan_count = ATOMIC_INIT(0); +atomic_t tcp_orphan_count ____cacheline_aligned_in_smp = ATOMIC_INIT(0); int sysctl_tcp_mem[3]; int sysctl_tcp_wmem[3] = { 4*1024, 16*1024, 128*1024 }; int sysctl_tcp_rmem[3] = { 4*1024, 87380, 87380*2 }; -atomic_t tcp_memory_allocated; /* Current allocated memory. */ -atomic_t tcp_sockets_allocated; /* Current number of TCP sockets. */ +/* Current allocated memory. */ +atomic_t tcp_memory_allocated ____cacheline_aligned_in_smp; +/* Current number of TCP sockets. */ +atomic_t tcp_sockets_allocated ____cacheline_aligned_in_smp; /* Pressure flag: try to collapse. * Technical note: it is used by multiple contexts non atomically. * All the tcp_mem_schedule() is of this nature: accounting * is strict, actions are advisory and have some latency. */ -int tcp_memory_pressure; +int tcp_memory_pressure ____cacheline_aligned_in_smp; #define TCP_PAGES(amt) (((amt)+TCP_MEM_QUANTUM-1)/TCP_MEM_QUANTUM) From owner-netdev@oss.sgi.com Sun May 26 21:55:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4R4tfnC025833 for ; Sun, 26 May 2002 21:55:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4R4tf5N025832 for netdev-outgoing; Sun, 26 May 2002 21:55:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from Bangalore (user4.s146.samsung.co.kr [203.241.146.4]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4R4tCnC025828 for ; Sun, 26 May 2002 21:55:14 -0700 Subject: Doubt on PPP! To: netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: Debasis.Ratha@lntinfotech.com Date: Mon, 27 May 2002 10:23:32 +0530 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/27/2002 10:23:43 AM MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=65256BC6001A4E248f9e8a93df938690918c65256BC6001A4E24" Content-Disposition: inline Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 13221 Lines: 208 --0__=65256BC6001A4E248f9e8a93df938690918c65256BC6001A4E24 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hi All, I have a doubt on PPP over serial. Can you please help me out... My doubt goes like this; Test Set-Up: (Embedded image moved to file: pic00041.pcx) System Details: All the three machines are standard Pentium PCs with Linux-2.4.2 loaded. The PPP has been enabled in machine-1 and machine-3= . Requirement: Is to establish a PPP session between machine-1 and machin= e-3. Machine-2 should do nothing with the PPP frame. It should receive the P= PP frame on the serial and maybe send it to machine-3 on the Ethernet. Approach: Have written a small module in machine-2, that should receive= the PPP frame from the serial interface and send it on the Ethernet interfa= ce. Also tested the module on machine-2 with a simulator working from machi= ne-1 (instead of the actual PPP). The simulator would send packets of varied= sizes, from 3 bytes upto 1500 bytes, with the header and trailer as the= same no. like 7E as in ppp. For the simulator the character 7E wasn't repeated anywhere inside the data. Tests and Findings: With the simulator, the module seems to work fine,= if anything less than 8 bytes is sent, the module in machine-2 receives it= in one go. If anything above 8-bytes, the machine-2 module receives it multiple times, but the logic in the module converts it into a single message and sends it on the ethernet using UDP to machine-3. when runni= ng the actual PPP module from machine-1, the module behaves erroneously. P= PP has header and trailer as 7E but the module is printing characters like= 4f. If anyone has done similar testings, can u please point out what the problem could be with respect to PPP. Or is there any better way of doi= ng whatever I am trying to do. The requirement section would help u people= in knowing what is required. = --0__=65256BC6001A4E248f9e8a93df938690918c65256BC6001A4E24 Content-type: application/octet-stream; name="pic00041.pcx" Content-Disposition: attachment; filename="pic00041.pcx" Content-transfer-encoding: base64 CgUBCAAAAAAQApsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABEQIBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD//////////8L/yQD////////n/9T/yv/F/8L/wf/////////6/8UAzv/E AP///////+T/0v/J/8T/wv/B//////////T/xADb/wD////////i/9H/yf/E/8L/wf/////////x /wDi/8QA////////4P/Q/8j/xP/C/8H/////////7v/EAOj/wgD//////v/f/8//yP/E/8L///// ////6/8A8P/CAP/////9/97/z//I/8T/wv/////////q/wD////////3/9v/zv/H/8P/wv////// ///o/8IA9v/EAP/////6/93/zv/H/8T/wv///////////////////+3/1v/L/8b/w//B//////// /+X/AP//wf8A//////j/3P/O/8f/xP/C////////////5//DAP/////3/9z/zv/H/8P/wv////// /////+n/wgD/////9//b/87/x//D/8L/////////3/8A/////////P/e/8//yP/E/8L///////// 3v/CAP//zf8A//////X/2//N/8f/w//C/////////9z/wwD//8//AP/////1/9r/zf/H/8P/wv// /////////+//AP/////0/9r/zf/H/8P/wv/////////a/wD//////////9//0P/I/8T/wv////// ///Z/8IA///////////f/9D/yP/E/8L/////////2P/CAP//2f8A//////L/2f/N/8b/w//C//// /////9f/wgD//9v/AP/////y/9n/zP/G/8P/wv///////////////////+3/1v/L/8b/w//B//// /////9X/AP//////////4v/R/8j/xP/C/8H/////////1f8A///////////i/9H/yP/E/8L/wf// ///////U/wD//+P/AP/////w/9j/zP/G/8P/wf////////////n/AP/////v/9j/zP/G/8P/wf// /////////////////+3/1v/L/8b/w//B/////////9H/AP//////////5P/S/8n/xP/C/8H///// ////0P/CANX/xfzu/8T8x//C/NP/AP/////u/9f/zP/G/8P/wf/////////P/8IA1f/B/MX/wfzs /8H8xP/B/MX/wfzW/wD/////7v/X/8v/xv/D/8H/////////zv/CANX/wfzH/8H86v/B/Mb/wfzE /8H81/8A/////+3/1//L/8b/w//B/////////+X/wfzM/8P8xf/D/MT/wfzB/8P8xv/D/Mj/wfzI /8H8wv/E/NX/AP/////t/9f/y//G/8P/wf/////////N/wDY/8H8yv/B/MP/wfzD/8H8w//B/MP/ wvzD/8H8xP/B/MP/wfzH/8H8yP/B/MP/wfz/////+f/d/87/x//E/8L/////////zf8A2f/D/Mb/ wfzH/8H8xf/B/ML/wfzF/8H8wv/B/MX/wfzG/8H8yP/B/MP/wfz/////+f/d/87/x//E/8L///// ////zf8A3P/D/MP/wfzH/8H8xf/B/ML/wfzF/8H8wv/B/MX/wfzG/8H8yP/B/MP/wfzZ/wD///// 7P/W/8v/xv/D/8H/////////zP8A4P/B/ML/wfzH/8H8xf/B/ML/wfzF/8H8wv/H/Mb/wfzI/8H8 w//B/Nr/AP/////s/9b/y//F/8P/wf/////////L/wDh/8H8wv/B/Mf/wfzF/8H8wv/B/MX/wfzC /8H8zP/B/Mj/wfzD/8H82v8A/////+z/1v/L/8X/w//B/////////+X/wfzH/8H8wv/B/Mf/wfzF /8H8wv/B/MX/wfzC/8H8xf/B/Mf/wfzG/8H8xP/B/P/////5/93/zv/H/8T/wv/////////m/8H8 xf/B/MT/wfzD/8H8w//B/MP/wfzD/8L8w//B/MT/wfzD/8H8yf/B/MT/wfzF/8H8//////n/3f/O /8f/xP/C/////////8r/ANz/xfzG/8P8xf/D/MT/wfzB/8P8xv/D/Mv/xPzG/8H83P8A/////+v/ 1f/L/8X/w//B/////////8r/APb/wfz//8H/AP/////q/9X/y//F/8P/wf/////////J/wD3/8H8 ///B/wD/////6v/V/8v/xf/D/8H/////////yP8A+P/B/P//wf8A/////+r/1f/L/8X/w//B//// ////////////////7f/W/8v/xv/D/8H/////////x/8A///////////p/9T/yv/F/8P/wf////// ///H/wD///z/AP/////q/9X/yv/F/8P/wf/////////H/wDr/8H8xv/B/Mb/wfzQ/8H88P/CAP// ///p/9X/yv/F/8P/wf/////////H/wDr/8H8xf/B/MH/wfzF/8H80P/B/PH/AP/////p/9X/yv/F /8P/wf/////////G/wDt/8H8xP/B/MH/wfzE/8H80f/B/PH/AP/////p/9X/yv/F/8P/wf////// ///0/8H8xP/B/MH/wfzE/8H8xP/D/MT/wfzB/8L8wv/B/MX/wfz////////g/9D/yP/E/8L///// ////9P/B/MP/wfzD/8H8w//B/MP/wfzD/8H8w//C/MT/wfzE/8H8////////4P/Q/8j/xP/C/8H/ ////////xf8A7v/B/MP/wfzD/8H8w//B/ML/wfzF/8H8wv/B/MX/wfzD/8H8////////4f/Q/8j/ xP/C/8H/////////xf8A7//B/ML/wfzD/8H8wv/B/MP/wfzF/8H8wv/B/MX/wfzC/8H87/8A//// /+n/1P/K/8X/w//B/////////8X/AO//wfzB/8H8xf/B/MH/wfzD/8H8xf/B/ML/wfzF/8H8wf/C /PD/AP/////o/9T/yv/F/8P/wf/////////E/wDw/8H8wf/B/MX/wfzB/8H8w//B/MX/wfzC/8H8 xf/C/ML/wfzv/wD/////6P/U/8r/xf/D/8H/////////9f/B/MH/wfzF/8H8wf/B/MP/wfzF/8H8 wv/B/MX/wfzD/8H87/8A/////+j/1P/K/8X/w//B//////////b/wfzH/8H8xf/B/MP/wfzD/8H8 xf/B/MT/wfz////////g/9D/yP/E/8L/wf/////////2/8H8x//B/Mb/w/zE/8H8xf/B/MX/wfz/ ///////g/9D/yP/E/8L/////////xP8A/////8P/AP/////o/9T/yv/F/8P/wf/////////E/wD/ ////w//CAP/////o/9T/yv/F/8L/wf/////////D/8IA/////8T/AP/////o/9T/yv/F/8L/wf/B //8A1QD//+z/ANj//wDVANf/AP//+f/rANUAywDFAMMAAMH/AP//0/8A/////8b/AP//0/8A1/8A ///5/wDq/9X/y//F/8P/AMH/AP//0/8A/////8b/AP//0/8A/////9L/AOr/1f/L/8X/w/8Awf8A ///T/wD//+z/ANj/AP//0/8A/////9L/AOr/1f/L/8X/w/8Awf8A///T/wD//+z/ANj/AP//0/8A 1/8A///5/wDq/9X/y//F/8P/AMH/AP//0/8A///s/wDY/wD//9P/ANf/AP//+f8A6v/V/8v/xf/D /wDB/wD//9P/AP//7P8A2P8A///T/wDX/wD///n/AOr/1f/L/8X/w/8Awf8A///T/wD//+z/ANj/ AP//0/8A1/8A///5/wDq/9X/y//F/8P/AMH/AP//0/8A/////8b/AP//0/8A/////9L/AOr/1f/L /8X/w/8Awf8Ayf/DAMX/wwDN/wDG/wDU/wDU/wD/////xv8Ayf/DAMX/wwDN/wDG/wDT/8MA0/8A /////9L/AMn/wwDF/8MAzf8Axv8A0//DAMv/xf/D/wDB/wDK/8IAxf/CAM3/wgDa/8IA1P8A///s /wDY/wDK/8IAxf/CAM3/wgDZ/wDD/wDS/wD/////0v8Ayv/CAMX/wgDN/8IA2f8Aw/8Ayv/F/8P/ AMH/AMr/AMH/AMP/AMH/AM7/ANv/ANT/AP//7P8A2P8Ayv8Awf8Aw/8Awf8Azv8A3f8A0v8A1/8A ///5/wDK/wDB/wDD/wDB/wDO/wDZ/8T/AMr/xf/D/wDB/wDK/wDB/wDD/wDB/wDD/8IAxP/DAML/ AMH/wgDD/wDD/wDB/8IAw//CAMj/ANT/AP//7P8A2P8Ayv8Awf8Aw/8Awf8Aw//CAMT/wwDC/wDB /8IAw/8Aw/8Awf/CAMP/wgDK/wDS/wDX/wD///n/AMr/AMH/AMP/AMH/AMP/wgDE/8MAwv8Awf/C AMP/AMP/AMH/wgDD/8IAyf8Ay//F/8P/AMH/AMr/AMH/AMP/AMH/AML/AML/AML/AML/AML/wgDC /wDB/8IAwv/DAML/AMH/AML/AMf/ANT/AP//7P8A2P8Ayv8Awf8Aw/8Awf8Awv8Awv8Awv8Awv8A wv/CAML/AMH/wgDC/8MAwv8Awf8Awv8AyP8A0/8A1/8A///5/wDK/wDB/wDD/wDB/wDC/wDC/wDC /wDC/wDC/8IAwv8Awf/CAML/wwDC/wDB/wDC/wDH/8IAy//F/8P/AMH/AMr/AML/AMH/AML/AMP/ wwDC/wDF/wDD/wDC/wDD/wDD/wDB/8QAx/8A1P8A/////8b/AMr/AML/AMH/AML/AMP/wwDC/wDF /wDD/wDC/wDD/wDD/wDB/8QAyP8A0/8A1/8A///5/wDK/wDC/wDB/wDC/wDD/8MAwv8Axf8Aw/8A wv8Aw/8Aw/8Awf/EAMn/AMr/xf/D/wDB/wDK/wDC/wDB/wDC/wDC/wDC/wDC/wDF/wDD/wDC/wDD /wDD/wDB/wDE/8MAw/8A1P8A/////8b/AMr/AML/AMH/AML/AML/AML/AML/AMX/AMP/AML/AMP/ AMP/AMH/AMT/wwDD/wDU/wD/////0v8Ayv8Awv8Awf8Awv8Awv8Awv8Awv8Axf8Aw/8Awv8Aw/8A w/8Awf8AxP/DAMX/AMr/xf/D/wDB/wDK/wDC/wDB/wDC/wDC/wDC/wDC/wDC/wDC/wDD/wDC/wDD /wDD/wDB/wDC/wDH/wDU/wD//+3/ANf/AMr/AML/AMH/AML/AML/AML/AML/AML/AML/AMP/AML/ AMP/AMP/AMH/AML/AMb/AML/ANL/AP/////S/wDK/wDC/wDB/wDC/wDC/wDC/wDC/wDC/wDC/wDD /wDC/wDD/wDD/wDB/wDC/wDJ/wDK/8X/w/8Awf8Ayf/DAML/AML/wwDC/8QAwv/CAML/wwDB/8YA wf/DAMH/wwDB/8IAx//DANP/AP//7f8A1/8Ayf/DAML/AML/wwDC/8QAwv/CAML/wwDB/8YAwf/D AMH/wwDB/8IAxv/FANL/ANb/AP//+v8Ayf/DAML/AML/wwDC/8QAwv/CAML/wwDB/8YAwf/DAMH/ wwDB/8IAxv/EAMv/xf/D/wDB/wD//9P/AP//7f8A1/8A///T/wDW/wD///r/AOr/1f/L/8X/w/8A wf8A///T/wD//+3/ANf/AP//0/8A1v8A///6/wDq/9X/y//F/8P/AMH/AP//0/8A///t/8IA1v8A ///T/wDW/wD///r/AOr/1f/L/8X/w/8Awf8A///T/wD/////xv8A///T/wDV/wD///v/AOr/1f/L /8X/w/8Awf8A///T/wD/////xv8A///T/wD/////0v8A6v/V/8v/xf/D/wDB/wD//9P/AP//7v8A 1v8A///T/wD/////0v8A6v/V/8v/xf/D/wDB/wD//9P/AP//7/8A1f8A///T/wD/////0v8A6v/V /8v/xf/D/wDB/wD//9P/AP//7/8A1f8A///T/wD/////0v8A6v/V/8v/xf/D/wDB/wD//9P/AP// 7/8A1f8A///T/wDU/wD///z/AOr/1f/L/8X/w/8Awf8A///T/wD/////xv8A///T/wDU/wD///z/ AOr/1f/L/8X/w/8Awf8A///T/wD/////xv8A///T/wD/////0v8A6v/V/8v/xf/D/wDB/wD//9P/ AP/////G/wD//9P/AP/////S/wDq/9X/y//F/8P/AMH/AP//0/8A///x/wDT/wD//9P/ANL/AP// /v8A6v/V/8v/xf/D/wDB/wD//9P/AP//8f8A0/8A///T/wDS/wD///7/AOr/1f/L/8X/w/8Awf8A ///T/wD///H/ANP/AP//0/8A0v8A///+/wDq/9X/y//F/8P/AMH/AP//0/8A///y/wDS/wD//9P/ ANL/AP///v8A6v/V/8v/xf/D/wDB/wD//9P/AP/////G/wD//9P/AP/////S/wDq/9X/y//F/8P/ AMH//wDVAP/////G//8A1QD/////0v/rANUAywDFAMMAAOX/AP/////j/wDd/wD7/wDb/wD///// 5f8A2P/M/8b/w//C/+X/AP/////k/wDc/wD7/wDb/wD/////5f8A2P/M/8b/w//C/+X/AP/////k /8IA2/8A+/8A2v8A/////+b/ANj/zP/G/8P/wv/l/wD/////5f8A2/8A+/8A2v8A/////+b/ANj/ zP/G/8P/wv/l/wD////////C/wD7/wD/////+f/I/wDY/8z/xv/D/8L/5f8A////////wv8A+/8A //////n/yP8A2P/M/8b/w//C/+X/AP///////8L/APv/ANf/AP/////p/wDY/8z/xv/D/8L/5f8A /////+f/ANn/APv/ANf/AP/////p/wDY/8z/xv/D/8L/5f8A/////+j/ANj/APv/ANb/wgD///// 6f8A2P/M/8b/w//C/+X/AP///////8L/APv/ANX/wgD/////6v8A2P/M/8b/w//C/+X/AP////// /8L/APv/AP/////5/8j/ANj/zP/G/8P/wv/l/wD/////6v8A1v8A+/8A0/8A/////+3/ANj/zP/G /8P/wv/l/wD/////6/8A1f8A+/8A0/8A/////+3/ANj/zP/G/8P/wv/l/wD/////7P8A1P8A+/8A 0v/CAP/////t/wDY/8z/xv/D/8L/5f8A/////+3/ANP/APv/ANH/wgD/////7v8A2P/M/8b/w//C /+X/AP///////8L/APv/AP/////5/8j/ANj/zP/G/8P/wv/l/wD/////7/8A0f8A+/8Az/8A//// //H/ANj/zP/G/8P/wv/l/wD////////C/wD7/wDP/wD/////8f8A2P/M/8b/w//C/+X/AP/////x /wDP/wD7/wDO/wD/////8v8A2P/M/8b/w//C/+X/AP///////8L/APv/AMz/wgD/////8v/B/wDY /8z/xv/D/8L/5f8A//////T/AMz/APv/AP/////5/8j/ANj/zP/G/8P/wv/l/wD//8j/wwDB/wDO /wDL/wD//8z/AMz/APv/AMr/AO3/yADH/wD///X/w/8A2P/M/8b/w//C/+X/AP//x/8Aw//CANn/ wgD//83/wgDK/wD7/wDJ/8IA7/8AxP8Axv/CAP//9f/D/wDY/8z/xv/D/8L/5f8A///G/wDF/wDa /wD//87/wgDJ/wD7/wDH/8MA8P8AyP8Aw/8A4/8A///U/wDY/8z/xv/D/8L/5f8A///G/wDg/wD/ /9H/AMf/APv/APr/AMj/AMP/AOP/AP//1P8A2P/M/8b/w//C/+X/AP//x//CAMf/wwDD/wDB/8IA wf8Axf/DAMP/AP//0f/DAMX/APv/APr/AMP/AMP/xADB/wDB/8IAxf/DAMP/AMH/wgDC/wDB/8IA xf/DAML/xAD//9L/ANj/zP/G/8P/wv/l/wD//8n/wgDE/wDD/wDB/8MAwv/CAMT/AMP/AML/AP// 0//CAMT/APv/AMP/wgD1/8UAxP8Aw//CAML/AMP/AMP/AMH/wwDD/8MAwv8Aw/8Aw/8Awv8A///U /wDY/8z/xv/D/8L/5f8A///L/wDD/8UAwv8AxP8Ax//CAML/AP//2f8A+/8Awf/DAPb/AMP/AMT/ AMP/AMP/AMP/xQDC/wDF/wDD/wDD/8UAwv8A///U/wDY/8z/xv/D/8L/5f8A///M/wDC/wDG/wDE /wDF/8IAwf8Awv8A///Z/wD7/wD6/wDI/wDD/wDD/wDD/wDG/wDF/wDD/wDD/wDG/wD//9T/ANj/ zP/G/8P/wv/l/wD//8b/AMX/AML/AMb/AMT/AMT/AMP/AML/AP//1//EAPn/wgD6/wDF/wDC/wDD /wDD/wDD/wDG/wDF/wDD/wDD/wDG/wD//9T/ANj/zP/G/8P/wv/l/wD//8b/wgDD/wDD/wDD/wDC /wDE/wDE/wDC/8IAwv8A///Z/wD3/8MAwf8A+v8AxP8Aw/8Awf8Awf8Aw/8Aw/8Aw/8Awv8Axf8A w/8Aw/8Aw/8Awv8Awf8A///S/wDY/8z/xv/D/8L/5f8A///G/wDB/8MAxf/DAML/wwDC/8MAw//D AMH/xQD//9j/AMP/APH/AMX/APj/yADD/8IAwf/DAMH/wwDD/8MAwv/DAMP/wwDB/8MAw//DAMP/ wgD//9P/ANj/zP/G/8P/wv/l/wD////////C/wDD/8UA6f/EAMb/AP/////5/8j/ANj/zP/G/8P/ wv/l/wD////////C/wDJ/wDx/wD/////+f/I/wDY/8z/xv/D/8L/5f8A////////wv8Ayv/EAN3/ xADM/wD/////+f/I/wDY/8z/xv/D/8L/5f8A////////wv8A0P/FAML/wgDH/8IAwv/EANP/AP// ///5/8j/ANj/zP/G/8P/wv/l//8A/wD/AMMA2v/CAML/wwDb//8A/wD6AMgA2f/M/8b/w//C//// ////////////////7f/W/8v/xv/D/8H////////////////////t/9b/y//G/8P/wf////////// /////////+3/1v/L/8b/w//B////////////////////7f/W/8v/xv/D/8H///////////////// ///t/9b/y//G/8P/wf///////////////////+3/1v/L/8b/w//B////////////////////7f/W /8v/xv/D/8H////////////////////t/9b/y//G/8P/wf///////////////////+3/1v/L/8b/ w//B////////////////////7f/W/8v/xv/D/8H////////////////////t/9b/y//G/8P/wf// /////////////////+3/1v/L/8b/w//B////////////////////7f/W/8v/xv/D/8H///////// ///////////t/9b/y//G/8P/wf///////////////////+3/1v/L/8b/w//B//////////////// ////7f/W/8v/xv/D/8H////////////////////t/9b/y//G/8P/wf///////////////////+3/ 1v/L/8b/w//B////////////////////7f/W/8v/xv/D/8H////////////////////t/9b/y//G /8P/wf///////////////////+3/1v/L/8b/w//B////////////////////7f/W/8v/xv/D/8H/ ///////////////////t/9b/y//G/8P/wf8MAAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw QCAAYCAAgCAAoCAAwCAA4CAAAEAAIEAAQEAAYEAAgEAAoEAAwEAA4EAAAGAAIGAAQGAAYGAAgGAA oGAAwGAA4GAAAIAAIIAAQIAAYIAAgIAAoIAAwIAA4IAAAKAAIKAAQKAAYKAAgKAAoKAAwKAA4KAA AMAAIMAAQMAAYMAAgMAAoMAAwMAA4MAAAOAAIOAAQOAAYOAAgOAAoOAAwOAA4OAAAABAIABAQABA YABAgABAoABAwABA4ABAACBAICBAQCBAYCBAgCBAoCBAwCBA4CBAAEBAIEBAQEBAYEBAgEBAoEBA wEBA4EBAAGBAIGBAQGBAYGBAgGBAoGBAwGBA4GBAAIBAIIBAQIBAYIBAgIBAoIBAwIBA4IBAAKBA IKBAQKBAYKBAgKBAoKBAwKBA4KBAAMBAIMBAQMBAYMBAgMBAoMBAwMBA4MBAAOBAIOBAQOBAYOBA gOBAoOBAwOBA4OBAAACAIACAQACAYACAgACAoACAwACA4ACAACCAICCAQCCAYCCAgCCAoCCAwCCA 4CCAAECAIECAQECAYECAgECAoECAwECA4ECAAGCAIGCAQGCAYGCAgGCAoGCAwGCA4GCAAICAIICA QICAYICAgICAoICAwICA4ICAAKCAIKCAQKCAYKCAgKCAoKCAwKCA4KCAAMCAIMCAQMCAYMCAgMCA oMCAwMCA4MCAAOCAIOCAQOCAYOCAgOCAoOCAwOCA4OCAAADAIADAQADAYADAgADAoADAwADA4ADA ACDAICDAQCDAYCDAgCDAoCDAwCDA4CDAAEDAIEDAQEDAYEDAgEDAoEDAwEDA4EDAAGDAIGDAQGDA YGDAgGDAoGDAwGDA4GDAAIDAIIDAQIDAYIDAgIDAoIDAwIDA4IDAAKDAIKDAQKDAYKDAgKDAoKDA wKDA4KDAAMDAIMDAQMDAYMDAgMDAoMDA//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP////// --0__=65256BC6001A4E248f9e8a93df938690918c65256BC6001A4E24-- From owner-netdev@oss.sgi.com Tue May 28 07:59:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4SExHnC022706 for ; Tue, 28 May 2002 07:59:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4SExHa6022705 for netdev-outgoing; Tue, 28 May 2002 07:59:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from mg01.austin.ibm.com (mg01.austin.ibm.com [192.35.232.18]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4SEx8nC022691 for ; Tue, 28 May 2002 07:59:08 -0700 Received: from austin.ibm.com (netmail.austin.ibm.com [9.3.7.137]) by mg01.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id JAA17228; Tue, 28 May 2002 09:59:45 -0500 Received: from popmail.austin.ibm.com (popmail.austin.ibm.com [9.53.247.178]) by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id KAA65376; Tue, 28 May 2002 10:00:20 -0500 Received: from us.ibm.com (sctptest.dynamic.austin.ibm.com [9.111.216.54] (may be forged)) by popmail.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) with ESMTP id KAA17790; Tue, 28 May 2002 10:00:20 -0500 Message-ID: <3CF399DA.2EC18D7C@us.ibm.com> Date: Tue, 28 May 2002 09:53:14 -0500 From: Jon Grimm X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.5.15lksctp i686) X-Accept-Language: en MIME-Version: 1.0 To: "lksctp-developers@lists.sourceforge.net" CC: linux-net@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [ANNOUNCE] New lksctp release: lksctp-2_5_15-0_4_9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2814 Lines: 68 Linux Kernel SCTP Developer Release lksctp-2_5_15-0_4_9 is now available for download. The lksctp project was created to develop a Linux kernel implementation of the SCTP transport protocol. For more information, as well as, source tarballs and patches, please visit: http://www.sourceforge.net/projects/lksctp/ Best Regards, Jon Grimm The following is the list of changes since the last public release lksctp-2_5_15-0_4_9: Patch 554705 Locking phase 1 (off the BH, use socklock and backlog) (jgrimm) Bug 550363 Shutdown handling of CTSN incorrect (jgrimm) Patch 558565 testframe ipv4 only, doesn't compile (samudarala) Patch 556572 Fix INADDR_ANY and some IPv4 scoping (daisyc) Patch 559801 Cleanup old locking stuff and various naming/style (jgrimm) lksctp-2_5_15-0_4_8: Patch 557034 Port to 2.5.15 (samudrala) Patch 550903 sys_bindx removal (inaky, samudarala) Mon May 20 08:55:12 CDT 2002 lksctp-2_4_18-0_4_8: Patch 546328 sctp_transport cleanup (jgrimm) Bug 545852 sk->err cleanup (samudrala) Bug 547147 association leaks the inqueue->in_progress chunk (jgrimm) Bug 541065 fix port_rover race conditition in bind path (jgrimm) Patch 544577 heartbeat ack and failover (dajiang) NA Make lksctp a module (inaky) NA bindx over sockopt (inaky) Patch 547885 Split out v6 code and cleanup module patch (jgrimm) Patch 544583 ft_frame_hbACK updates (dajiang, huang) Patch 547340 fix testframe for "run once" (samudrala) Patch 548772 sctp_lock primitives (jgrimm) Patch 547319 naming cleanup in statefuns (daisyc) Patch 549266 sctp_lock unittests (jgrimm) Patch 548815 Disable fragments option and more tests. (samudrala) Patch 550400 Add OOTB testcase (daisyc) Patch 550520 transport & association error thresholds (samudrala) NA fix ft_frame_init_timer to not conflict with OOTB (jgrimm) Patch 549356 Small fixes and cleanup of bindx code (inaky) Patch 549360 bindx through sockopt (inaky) Patch 551716 Start using sctp_opts field instead of endpoint (jgrimm) Patch 551657 RTT Measurements and RTO updates (samudrala) Patch 552084 sctp_endpoint_common (jgrimm) Patch 553100 Testcase for RTT Measurements (samudrala) Bug 553329 Sendmsg + INIT CMSG has path which can corrupt assoc (jgrimm) Patch 553394 Move sctp_association to use endpoint_common (jgrimm) Patch 553528 rtx and heartbeat failures cleanup (samudrala) Patch 553844 OOTB packet processing (daisyc) Fri Apr 19 10:47:41 CDT 2002 lksctp-2_4_18-0_4_7: Bug 541198 Old-style retval->state races with CMD (jgrimm) Patch 541820 listen auto-bind support (samudrala) Patch 543421 Complete removal of retval structs/processing (jgrimm) Patch 544908 Object Count Debugging facilities (jgrimm) Patch 544806 Fix inqueue leak of chunks (daisyc) Patch 544460 Fragmentation/Reassembly support (samudrala) From owner-netdev@oss.sgi.com Tue May 28 12:23:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4SJN7nC028111 for ; Tue, 28 May 2002 12:23:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4SJN7A4028110 for netdev-outgoing; Tue, 28 May 2002 12:23:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from mx.rocnet.de (pD95024D6.dip.t-dialin.net [217.80.36.214]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4SJN3nC028107 for ; Tue, 28 May 2002 12:23:04 -0700 Received: from rocnet.de (localhost [127.0.0.1]) by mx.rocnet.de (Postfix) with SMTP id 58C2716D95 for ; Tue, 28 May 2002 21:24:20 +0200 (CEST) Received: from 192.168.100.10 (SquirrelMail authenticated user crosenbe) by deathstar.rocnet.de with HTTP; Tue, 28 May 2002 21:24:20 +0200 (CEST) Message-ID: <4416.192.168.100.10.1022613860.squirrel@deathstar.rocnet.de> Date: Tue, 28 May 2002 21:24:20 +0200 (CEST) Subject: vortex From: "Claus Rosenberger" To: X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal Reply-To: Claus.Rosenberger@rocnet.de X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 234 Lines: 9 Hi, i have to 3c59x cards staticly linked into the kernel and now want to load them in specific order. how to do ? i tried "ether=irq,io,eth0 ether=irq,io,eth1" but no success. how i can change the order to load the cards ? thanks From owner-netdev@oss.sgi.com Thu May 30 05:32:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4UCWDnC002260 for ; Thu, 30 May 2002 05:32:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4UCWDCQ002259 for netdev-outgoing; Thu, 30 May 2002 05:32:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from vieo.com (66-106-235-35.customer.algx.net [66.106.235.35]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4UCW7nC002255 for ; Thu, 30 May 2002 05:32:07 -0700 Received: (from root@localhost) by vieo.com (8.11.2/8.11.2) id g4UCXXL99091 for netdev@oss.sgi.com; Thu, 30 May 2002 07:33:33 -0500 (CDT) (envelope-from golio@vieo.com) Received: from vieo.com (golio@[10.3.0.111]) by vieo.com (8.11.2/8.11.2) with ESMTP id g4UCXWZ99033 for ; Thu, 30 May 2002 07:33:32 -0500 (CDT) (envelope-from golio@vieo.com) Message-ID: <3CF61BE0.BDF0F05B@vieo.com> Date: Thu, 30 May 2002 07:32:32 -0500 From: Joseph Golio Organization: Development X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4 i686) X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: [Fwd: IPoIB] X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1133 Lines: 41 Joseph Golio wrote: To whom it may concern, I originally sent this note to Alan Cox, but he has suggested that I send it to you folks. I'm new at this process so please bare with me... So, here goes. > Alan, > > I have a question. I am working on developing a Linux driver for IP over > Infiniband (IPoIB) and > have run into an issue that I need your advice. The draft standard from the > IETF on IPoIB > encapsulation and address resolution over Infiniband networks (see the link > below - section 6.1.1) > defines the hardware address as being 20 bytes in length. It appears that > the "netdevice.h" file in > Linux has MAX_ADDR_LEN set to 7 (at least in my version which is SuSe 7.3 - > kernel 2.4.4). > > http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ip-over-infiniband-01.txt > > Obviously, this will not. > > What do you suggest as a good solution to this problem ? > > Thanks in advance for a quick response. > > Thanks for your time, > > Joe Golio > golio@vieo.com > 651-698-9350 (ext. 111) > VIEO Inc. > > VIEO: The Adaptive Application Infrastructure Management (AAIM) Company From owner-netdev@oss.sgi.com Thu May 30 08:55:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4UFtPnC018620 for ; Thu, 30 May 2002 08:55:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4UFtPFM018619 for netdev-outgoing; Thu, 30 May 2002 08:55:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from loewe.cosy.sbg.ac.at (loewe.cosy.sbg.ac.at [141.201.2.12]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4UFtJnC018616 for ; Thu, 30 May 2002 08:55:20 -0700 Received: from mausmaki.cosy.sbg.ac.at (mausmaki.cosy.sbg.ac.at [141.201.2.18]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id RAA14235; Thu, 30 May 2002 17:56:43 +0200 (MET DST) Date: Thu, 30 May 2002 17:56:43 +0200 (MET DST) From: "Thomas 'Dent' Mirlacher" To: Joseph Golio cc: netdev@oss.sgi.com Subject: Re: [Fwd: IPoIB] In-Reply-To: <3CF61BE0.BDF0F05B@vieo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1048 Lines: 35 --snip/snip > > I have a question. I am working on developing a Linux driver for IP over > > Infiniband (IPoIB) and > > have run into an issue that I need your advice. The draft standard from the > > IETF on IPoIB > > encapsulation and address resolution over Infiniband networks (see the link > > below - section 6.1.1) > > defines the hardware address as being 20 bytes in length. It appears that > > the "netdevice.h" file in > > Linux has MAX_ADDR_LEN set to 7 (at least in my version which is SuSe 7.3 - for 2.5.18 at least it's set to 8, but there is no reason to not change it to 20 beside wasting some memory n time for a) broadcast address b) device address int netdevice sum(m[n]) times for the multicast list where n == number of network devices, m == number of MC entries per device as i can see it. and this "overhead" should be really acceptable :) ... probably you will break some "external" stuff like freeswan, but this shouldn't be your problem. tm -- in some way i do, and in some way i don't. From owner-netdev@oss.sgi.com Thu May 30 09:13:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4UGDUnC019261 for ; Thu, 30 May 2002 09:13:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4UGDT4d019260 for netdev-outgoing; Thu, 30 May 2002 09:13:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from vieo.com (66-106-235-35.customer.algx.net [66.106.235.35]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4UGDNnC019257 for ; Thu, 30 May 2002 09:13:23 -0700 Received: (from root@localhost) by vieo.com (8.11.2/8.11.2) id g4UGEo840896 for netdev@oss.sgi.com; Thu, 30 May 2002 11:14:50 -0500 (CDT) (envelope-from golio@vieo.com) Received: from vieo.com (golio@[10.3.0.111]) by vieo.com (8.11.2/8.11.2) with ESMTP id g4UGElZ40713; Thu, 30 May 2002 11:14:47 -0500 (CDT) (envelope-from golio@vieo.com) Message-ID: <3CF64FB9.A5F5CC21@vieo.com> Date: Thu, 30 May 2002 11:13:45 -0500 From: Joseph Golio Organization: Development X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Thomas 'Dent' Mirlacher" CC: netdev@oss.sgi.com, gary klesk , jeff young Subject: Re: [Fwd: IPoIB] References: X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1467 Lines: 45 Thomas 'Dent' Mirlacher wrote: That's what I thought. Now, I can make the change to my local systems for development and we could even give instructions to our customers to make the change to their systems also. However, how would I get this change propogated to the next release of the Linux kernel (2.5.18 plus...) ? Thanks, Joe > --snip/snip > > > > I have a question. I am working on developing a Linux driver for IP over > > > Infiniband (IPoIB) and > > > have run into an issue that I need your advice. The draft standard from the > > > IETF on IPoIB > > > encapsulation and address resolution over Infiniband networks (see the link > > > below - section 6.1.1) > > > defines the hardware address as being 20 bytes in length. It appears that > > > the "netdevice.h" file in > > > Linux has MAX_ADDR_LEN set to 7 (at least in my version which is SuSe 7.3 - > > for 2.5.18 at least it's set to 8, but there is no reason to not change it to > 20 beside wasting some memory > > n time for > a) broadcast address > b) device address > int netdevice > sum(m[n]) times for the multicast list > > where n == number of network devices, m == number of MC entries per device > as i can see it. > > and this "overhead" should be really acceptable :) > > ... probably you will break some "external" stuff like freeswan, but this > shouldn't be your problem. > > tm > > -- > in some way i do, and in some way i don't.