From davem@redhat.com Sun Jun 1 01:33:01 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 Jun 2003 01:33:16 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h518Wt2x021058 for ; Sun, 1 Jun 2003 01:33:01 -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 BAA15160; Sun, 1 Jun 2003 01:30:40 -0700 Date: Sun, 01 Jun 2003 01:30:40 -0700 (PDT) Message-Id: <20030601.013040.116362760.davem@redhat.com> To: mk@linux-ipv6.org Cc: jmorris@intercode.com.au, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] xfrm ip6ip6 From: "David S. Miller" In-Reply-To: <87fzmv5ejc.wl@karaba.org> References: <87fzmv5ejc.wl@karaba.org> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-archive-position: 2798 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: Mitsuru KANDA / 神田 充 Date: Sun, 01 Jun 2003 00:20:07 +0900 Hello Mitsuru-san! + t->id.spi = xfrm6_tunnel_addr_hash((xfrm_address_t *)&x->props.saddr); You misunderstood what I tried to explain to you. Consider, how do you guarentee that this t->id.spi value is unique across all xfrm6_tunnel tunnels using the same t->id.daddr and t->id.prot? The answer is that you cannot. You must generate fake "spi" values, they have no meaning outside of xfrm6_tunnel.c They serve purpose only to map 128-bit ipv6 address to 32-bit "xfrm6_tunnel" SPI value. I would suggest following implementation: 1) Implement something similar to xfrm_alloc_spi(t, 1, ~(u32)0) It just needs to allocate unique SPI numbers local to xfrm6_tunnel.c We mark "SPI" value zero as reserved and to indicate failed lookup. 2) Create hash table, it is keyed by ipv6 address and hash table entries give SPI values. So on input you would say something like: u32 spi; spi = spihash_lookup(&iph->saddr); if (!spi) goto drop; x = xfrm_state_lookup((xfrm_address_t *)&iph->daddr, spi, IPPROTO_IPV6, AF_INET6); Is the idea more clear now? Once you fix this up I'll apply your xfrm6_tunnel.c work. Thank you. From davem@redhat.com Sun Jun 1 01:37:04 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 Jun 2003 01:37:08 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h518b32x021371 for ; Sun, 1 Jun 2003 01:37:04 -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 BAA15174; Sun, 1 Jun 2003 01:34:52 -0700 Date: Sun, 01 Jun 2003 01:34:52 -0700 (PDT) Message-Id: <20030601.013452.68050592.davem@redhat.com> To: jmorris@intercode.com.au Cc: mk@linux-ipv6.org, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] xfrm ip6ip6 From: "David S. Miller" In-Reply-To: References: <87fzmv5ejc.wl@karaba.org> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2799 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: James Morris Date: Sun, 1 Jun 2003 02:01:42 +1000 (EST) We need to either filter them out or make sure they are displayed as ipip. Part of the answer will depend on whether we want to expose xfrm-based ipip tunnels for general use, or only use them internally for ipcomp. I think it is an error to extend PF_KEY for our Linux purposes. Our API here is basically defined to be whatever is in KAME :-) However, setkey should filter entries it does not understand. Currently I see no use for exposing these tunnel transforms outside of the kernel. Mobile IPV6, if it decides to use xfrm6_tunnel, can configure them itself in the kernel side support. Or, if user side is more appropriate for MIPV6 access, we may allow it to use xfrm netlink interface somehow. From aj@dungeon.inka.de Sun Jun 1 04:48:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 Jun 2003 04:48:22 -0700 (PDT) Received: from mail.inka.de (mail@quechua.inka.de [193.197.184.2]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h51BmG2x032765 for ; Sun, 1 Jun 2003 04:48:17 -0700 Received: from dungeon.inka.de (uucp@[127.0.0.1]) by mail.inka.de with uucp (rmailwrap 0.5) id 19MQ81-0008Ud-00; Sun, 01 Jun 2003 12:31:53 +0200 Received: from 192.168.1.12 (unknown [192.168.1.12]) by dungeon.inka.de (Postfix) with ESMTP id 2FBA420FAA; Sun, 1 Jun 2003 12:31:50 +0200 (CEST) From: Andreas Jellinghaus To: netdev@oss.sgi.com Subject: ipsec / pppoe Date: Sun, 1 Jun 2003 12:33:22 +0200 User-Agent: KMail/1.5.2 Cc: howto@lartc.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200306011233.22544.aj@dungeon.inka.de> X-archive-position: 2800 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: aj@dungeon.inka.de Precedence: bulk X-list: netdev with pppoe it is usualy necessary to clamp the maximum segment size down to 1452 bytes. This can be done with a netfilter module or with "-m 1452" option to pppoe. with ipsec (esp, tunnel mode) even on a wlan interface before the ppp connection I needed to clamp the mss down further to 1384 bytes. now all connections are working fine. my calculation gave me 1500 mtu (wlan0) - 20 (ip) - 48 (esp) - 20 (ip) - 20 (tcp) = 1392 or 1492 (ppp(oe)) - 20 (ip) - 20 (tcp) = 1452, so the min of 1392 should have been the right value. Don't know why I need to clamp the mss down to 1384, but e.g. http connections to www.microsoft.com work fine with 1384 and do not work at all with 1392. still I don't know why some machines don't respond to icmp packet to big errors with a smaller packet but not act on it at all. maybe some broken firewall thinks it is some kind of attack? I don't know what exactly is between me and websites such as www.google.com or www.microsoft.com, so I can't figure out. sorry to have bothered everyone and many thanks to james for his help. cc: to howto@lartc.org, it think this would make a nice howto entry. Regards, Andreas From jmorris@intercode.com.au Sun Jun 1 05:19:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 Jun 2003 05:19:35 -0700 (PDT) Received: from blackbird.intercode.com.au (IDENT:ypEXYr5lpcO3McCfmTLAPa7YYYHO+9Ax@blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h51CJQ2x004280 for ; Sun, 1 Jun 2003 05:19:28 -0700 Received: from excalibur.intercode.com.au (excalibur.intercode.com.au [203.32.101.12]) by blackbird.intercode.com.au (8.11.6p2/8.9.3) with ESMTP id h51CIwr12637; Sun, 1 Jun 2003 22:18:58 +1000 Date: Sun, 1 Jun 2003 22:18:56 +1000 (EST) From: James Morris To: Andreas Jellinghaus cc: netdev@oss.sgi.com, Subject: Re: ipsec / pppoe In-Reply-To: <200306011233.22544.aj@dungeon.inka.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2801 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@intercode.com.au Precedence: bulk X-list: netdev On Sun, 1 Jun 2003, Andreas Jellinghaus wrote: > cc: to howto@lartc.org, it think this would make a nice > howto entry. Actually, there is a bug in the way icmp pmtu messages are being generated here, which should be fixed soon. - James -- James Morris From gandalf@wlug.westbo.se Sun Jun 1 16:05:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 Jun 2003 16:05:12 -0700 (PDT) Received: from tux.rsn.bth.se (postfix@tux.rsn.bth.se [194.47.143.135]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h51N512x016698 for ; Sun, 1 Jun 2003 16:05:02 -0700 Received: by tux.rsn.bth.se (Postfix, from userid 501) id 6AE3836FE0; Mon, 2 Jun 2003 01:04:58 +0200 (CEST) Subject: [PATCH] fix use after free in e100 From: Martin Josefsson To: scott.feldman@intel.com Cc: netdev@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1054508698.24777.17.camel@tux.rsn.bth.se> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 02 Jun 2003 01:04:58 +0200 X-archive-position: 2802 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gandalf@wlug.westbo.se Precedence: bulk X-list: netdev Hi Scott. Here's a fix for a use-after-free in the e100 driver. You can't touch the skb after a call to netif_rx(), it might have been free'd. Caught with Manfred's unmap-page-debugging patch in -mm. Applies to both 2.4 and 2.5 --- linux-2.5.69-mm9/drivers/net/e100/e100_main.c.orig 2003-06-02 00:48:13.000000000 +0200 +++ linux-2.5.69-mm9/drivers/net/e100/e100_main.c 2003-06-02 00:50:09.000000000 +0200 @@ -2052,13 +2052,14 @@ skb->ip_summed = CHECKSUM_NONE; } + bdp->drv_stats.net_stats.rx_bytes += skb->len; + if(bdp->vlgrp && (rfd_status & CB_STATUS_VLAN)) { vlan_hwaccel_rx(skb, bdp->vlgrp, be16_to_cpu(rfd->vlanid)); } else { netif_rx(skb); } dev->last_rx = jiffies; - bdp->drv_stats.net_stats.rx_bytes += skb->len; rfd_cnt++; } /* end of rfd loop */ -- /Martin From Robert.Olsson@data.slu.se Mon Jun 2 03:59:13 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 03:59:19 -0700 (PDT) Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h52AxB2x012408 for ; Mon, 2 Jun 2003 03:59:12 -0700 Received: (from robert@localhost) by robur.slu.se (8.9.3p2/8.9.3) id MAA08655; Mon, 2 Jun 2003 12:58:32 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16091.11735.721251.925522@robur.slu.se> Date: Mon, 2 Jun 2003 12:58:31 +0200 To: Simon Kirby Cc: "David S. Miller" , netdev@oss.sgi.com, linux-net@vger.kernel.org, kuznet@ms2.inr.ac.ru Subject: Re: Route cache performance under stress In-Reply-To: <20030529205125.GA30058@netnation.com> References: <20030522.015815.91322249.davem@redhat.com> <20030522.034058.71558626.davem@redhat.com> <20030522114438.GD2961@netnation.com> <20030522.153330.74735095.davem@redhat.com> <20030529205125.GA30058@netnation.com> X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 2803 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Simon Kirby writes: > Full profile output available here: > > http://blue.netnation.com/sim/ref/ > readprofile.full_route_table_hash_fixed_napi.* > > Note that if I increase the packet rate and NAPI kicks in, all of the > handle_IRQ and similar overhead basically disappears because it no longer > uses IRQs. Pretty spiffy. Here is a profile of that: > Full profile output available as: 8896 rt_garbage_collect 9.4237 8959 ip_route_input_slow 3.8885 10516 dst_alloc 73.0278 10666 kmem_cache_free 66.6625 15339 tg3_rx 16.2489 16553 ipt_do_table 14.9937 20193 fn_hash_lookup 70.1146 26833 rt_intern_hash 34.9388 64803 ip_route_input 150.0069 From DoS perspective a more interesting experiment compared to where you limited input rate to have 30% idle CPU. New dst is coming all the time first seached in hash (ip_route_input) and not found so ip_route_input_slow/fn_hash_lookup/dst_alloc/rt_intern_hash path is taken to add a new dst entry... And later GC have to remove all enties with spin_lock_bh hold (no packet processing runs). I see packet drops exactly when GC runs. Tuning GC might help but it's something to observe. I had some idea to rate-limit new flows and try to isolate the device causing the DoS Something like (ip_route_input): [We don't have an hash entry] /* DoS check... Rate down but do not stop GC and creation of new hash entries until GC frees resources. We limit per interface so hogger dev(s) will be hit hardest. As a side effect we get dst_overrun per device. */ entries = atomic_read(&ipv4_dst_ops.entries); if (entries > ip_rt_max_size) { int drp = 4; if( dev->dst_hash_overrun++ % drp ) { if (net_ratelimit()) printk(KERN_WARNING "dst creation throttled\n"); return -ECONNREFUSED; } /* Also make sure the slow path gets a chance to create the dst entry */ if (ipv4_dst_ops.gc && ipv4_dst_ops.gc()) { RT_CACHE_STAT_INC(gc_dst_overflow); return -ENOBUFS; } } [ip_route_input_slow comes here] But more thinking is needed... Cheers. --ro From sim@netnation.com Mon Jun 2 08:18:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 08:19:05 -0700 (PDT) Received: from peace.netnation.com (newpeace.netnation.com [204.174.223.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h52FIr2x022153 for ; Mon, 2 Jun 2003 08:18:53 -0700 Received: from sim by peace.netnation.com with local (Exim 4.20) id 19Mr5I-0002Cv-6H; Mon, 02 Jun 2003 08:18:52 -0700 Date: Mon, 2 Jun 2003 08:18:52 -0700 From: Simon Kirby To: Robert Olsson Cc: "David S. Miller" , netdev@oss.sgi.com, linux-net@vger.kernel.org, kuznet@ms2.inr.ac.ru Subject: Re: Route cache performance under stress Message-ID: <20030602151852.GA6070@netnation.com> References: <20030522.015815.91322249.davem@redhat.com> <20030522.034058.71558626.davem@redhat.com> <20030522114438.GD2961@netnation.com> <20030522.153330.74735095.davem@redhat.com> <20030529205125.GA30058@netnation.com> <16091.11735.721251.925522@robur.slu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16091.11735.721251.925522@robur.slu.se> User-Agent: Mutt/1.5.4i X-archive-position: 2804 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sim@netnation.com Precedence: bulk X-list: netdev On Mon, Jun 02, 2003 at 12:58:31PM +0200, Robert Olsson wrote: > New dst is coming all the time first seached in hash (ip_route_input) and not found > so ip_route_input_slow/fn_hash_lookup/dst_alloc/rt_intern_hash path is taken to add > a new dst entry... > > And later GC have to remove all enties with spin_lock_bh hold (no packet processing > runs). I see packet drops exactly when GC runs. Tuning GC might help but it's something > to observe. > > I had some idea to rate-limit new flows and try to isolate the device causing the DoS > Something like (ip_route_input): ... > if (net_ratelimit()) > printk(KERN_WARNING "dst creation throttled\n"); > > return -ECONNREFUSED; This reminds me of the situation we experienced with the dst cache overflowing in early 2.2 kernels. This was a long time ago, when our traffic was only about 10 Mbits/second. We had recently upgraded from a 2.0 kernel. The dst cache was overflowing due to a bug in the garbage collector, and at the time, no messages were printed. It took me a _long_ time to figure out why connections to a server I hadn't previously connected to in a while would only work every so often, and not immediately like they should. I'm affraid this approach will have a similar effect, albeit (hopefully) only under an attack. Is it possible to have a dst LRU or a simpler approximation of such and recycle dst entries rather than deallocating/reallocating them? This would relieve a lot of work from the garbage collector and avoid the periodic large garbage collection latency. It could be tuned to only occur in an attack (I remember Alexey saying that the deferred garbage collection was implemented to reduce latency in normal opreation). Would this work? Cross-CPU thrashing issues? Simon- [ Simon Kirby ][ Network Operations ] [ sim@netnation.com ][ NetNation Communications Inc. ] [ Opinions expressed are not necessarily those of my employer. ] From Robert.Olsson@data.slu.se Mon Jun 2 09:37:19 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 09:37:29 -0700 (PDT) Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h52GbH2x023431 for ; Mon, 2 Jun 2003 09:37:19 -0700 Received: (from robert@localhost) by robur.slu.se (8.9.3p2/8.9.3) id SAA14178; Mon, 2 Jun 2003 18:36:37 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16091.32021.75335.227150@robur.slu.se> Date: Mon, 2 Jun 2003 18:36:37 +0200 To: Simon Kirby Cc: Robert Olsson , "David S. Miller" , netdev@oss.sgi.com, linux-net@vger.kernel.org, kuznet@ms2.inr.ac.ru Subject: Re: Route cache performance under stress In-Reply-To: <20030602151852.GA6070@netnation.com> References: <20030522.015815.91322249.davem@redhat.com> <20030522.034058.71558626.davem@redhat.com> <20030522114438.GD2961@netnation.com> <20030522.153330.74735095.davem@redhat.com> <20030529205125.GA30058@netnation.com> <16091.11735.721251.925522@robur.slu.se> <20030602151852.GA6070@netnation.com> X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 2805 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Simon Kirby writes: > This reminds me of the situation we experienced with the dst cache > overflowing in early 2.2 kernels. This was a long time ago, when our > traffic was only about 10 Mbits/second. We had recently upgraded from a > 2.0 kernel. The dst cache was overflowing due to a bug in the garbage > collector, and at the time, no messages were printed. It took me a > _long_ time to figure out why connections to a server I hadn't previously > connected to in a while would only work every so often, and not > immediately like they should. I'm affraid this approach will have a > similar effect, albeit (hopefully) only under an attack. We are given more work than we have resources for (max_size) what else than refuse can we do? But yes we have invested pretty much work already. Also remember we are looking into runs were 100% of incoming traffic has one new dst for every packet. So how is the situation in "real life"? In case of multiple devices at least NAPI gives all devs it's share. > Is it possible to have a dst LRU or a simpler approximation of such and > recycle dst entries rather than deallocating/reallocating them? This > would relieve a lot of work from the garbage collector and avoid the > periodic large garbage collection latency. It could be tuned to only > occur in an attack (I remember Alexey saying that the deferred garbage > collection was implemented to reduce latency in normal opreation). I don't see how this can be done. Others may? Cheers. --ro From rddunlap@osdl.org Mon Jun 2 10:08:30 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 10:08:39 -0700 (PDT) Received: from mail.osdl.org (air-2.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h52H8T2x024261 for ; Mon, 2 Jun 2003 10:08:30 -0700 Received: from dragon.pdx.osdl.net (dragon.pdx.osdl.net [172.20.1.27]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h52H8GX20706; Mon, 2 Jun 2003 10:08:16 -0700 Date: Mon, 2 Jun 2003 10:07:54 -0700 From: "Randy.Dunlap" To: Andi Kleen Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: netlink tester program Message-Id: <20030602100754.1e3e1ca8.rddunlap@osdl.org> In-Reply-To: <20030531120940.GB11898@wotan.suse.de> References: <20030530090015.7c435c9a.rddunlap@osdl.org> <20030530.171111.71099698.davem@redhat.com> <32804.4.64.196.31.1054351332.squirrel@www.osdl.org> <20030530.234211.102567405.davem@redhat.com> <20030531120940.GB11898@wotan.suse.de> Organization: OSDL X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i586-pc-linux-gnu) X-Face: +5V?h'hZQPB9kW Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2806 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev On Sat, 31 May 2003 14:09:40 +0200 Andi Kleen wrote: | > You really need something like rtnl_talk() or rtnl_dump_filter() | > from libnetlink to do this properly. | | In case it's helpful I wrote manpages for libnetlink some time ago. | | I also have some simple example programs using it. Other examples | can be found in the zebra or bird source code. Does this man page live somewhere? Do some distros ship it? Where can I find your example programs that use it? Couple of corrections below.... | rtnl_listen | Receive netlink data after a request and pass it to | handler. handler is a callback that gets the mes- | sage source address, the message itself, and the | jarg cookie as arguments. It will get called for + It will be called for {'get' should usually be avoided when easily done} | all received messages. Only one message bundle is | received. Unless there is no message pending this | function does not block. | | | rta_addattr32 | Initialize the rtnetlink attribute rta with a __u32 | data value. | | | rta_addattr32 + rta_addattr_l | Initialize the rtnetlink attribute rta with a vari- | able length data value. -- ~Randy From krkumar@us.ibm.com Mon Jun 2 10:33:59 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 10:34:04 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h52HXp2x024952 for ; Mon, 2 Jun 2003 10:33:58 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h52HWdE2115688; Mon, 2 Jun 2003 13:32:39 -0400 Received: from us.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h52HWbTC245356; Mon, 2 Jun 2003 13:32:37 -0400 Message-ID: <3EDB8A41.2080305@us.ibm.com> Date: Mon, 02 Jun 2003 10:32:49 -0700 From: Krishna Kumar Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: davem@redhat.com, kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: [PATCH] Prefix List patch against 2.5.70 References: <3ED80230.2030508@us.ibm.com> <20030531.110249.12960077.yoshfuji@linux-ipv6.org> In-Reply-To: <20030531.110249.12960077.yoshfuji@linux-ipv6.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2807 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: krkumar@us.ibm.com Precedence: bulk X-list: netdev Hi Yoshifuji, Thanks for your comments. >>+/* prefix list returned to user space in this structure */ >>+struct plist_user_info { > > ^ip6 or ipv6 or so. > >>+ char name[IFNAMSIZ]; /* interface name */ > > ~~~~~~~~~~~~~~~~~~~duplicate information. > Point noted. That can be removed (prefer to have name instead of ifindex). >>+ int ifindex; /* interface index */ >>+ int nprefixes; /* number of elements in 'prefix' */ >>+ struct var_plist_user_info { /* multiple elements */ >>+ char flags[3]; /* router advertised flags */ > > ~~~~~~~~this is not good interface. This is my mistake. When I added the original interface, it was using the proc filesystem and it made sense at that time for a user to cat /proc/net/ and actually see the flags. While converting to use netlink, I forgot to change this to real flags. This was not intended interface :-) >>+ int plen; /* prefix length */ >>+ __u32 valid; /* valid lifetime */ >>+ struct in6_addr ra_addr;/* advertising router */ >>+ struct in6_addr prefix; /* prefix */ >>+ } plist_vars[0]; >>+}; >>+ >> extern void addrconf_init(void); >> extern void addrconf_cleanup(void); >> > > > : > > I think we should use 1 fixed-length message per prefix, > instead of variable length message. I had got this idea from "struct fib_info" which also has variable size structure, but probably it is not worth the extra effort to save a few bytes. >>+ ipv6_addr_copy(&pinfo->plist_vars[count].ra_addr, >>+ &p_el->ra_addr); >>+ for (i = 0; i < 8; i++) >>+ pinfo->plist_vars[count].ra_addr.s6_addr16[i] = >>+ __constant_ntohs(pinfo->plist_vars[count].ra_addr.s6_addr16[i]); >>+ ipv6_addr_copy(&pinfo->plist_vars[count].prefix, >>+ &p_el->pinfo.prefix); >>+ for (i = 0; i < p_el->pinfo.prefix_len/16; i++) >>+ pinfo->plist_vars[count].prefix.s6_addr16[i] = >>+ __constant_ntohs(pinfo->plist_vars[count].prefix.s6_addr16[i]); > > > Absoletely nasty. > - don't use charaters to represent flags; use real flags. > - use network-byte order. network-byte order ? User will get prefix in network byte order, is that correct ? >>+static int prefix_list_proc_dump(char *buffer, char **start, off_t offset, >>+ int length) >>+{ > > : > > Please use seq_file. OK. > Again, what I proposed was to store prefix information on fib with > some flags to represent advertised by routers and give user-space > the RA information using new rtattr (RTA_RA6INFO or something like that). > > struct rta_ra6info { > u32 rta_ra6flags; > }; > In my mail, I had given problems with doing that in the fib. I can look to convert to fib, but please let me know which kernel routines I should look at. Thanks, - KK From sim@netnation.com Mon Jun 2 11:05:38 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 11:05:50 -0700 (PDT) Received: from peace.netnation.com (newpeace.netnation.com [204.174.223.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h52I5b2x025880 for ; Mon, 2 Jun 2003 11:05:38 -0700 Received: from sim by peace.netnation.com with local (Exim 4.20) id 19Mtgf-0000n4-A7; Mon, 02 Jun 2003 11:05:37 -0700 Date: Mon, 2 Jun 2003 11:05:37 -0700 From: Simon Kirby To: Robert Olsson Cc: "David S. Miller" , netdev@oss.sgi.com, linux-net@vger.kernel.org, kuznet@ms2.inr.ac.ru Subject: Re: Route cache performance under stress Message-ID: <20030602180537.GB30957@netnation.com> References: <20030522.015815.91322249.davem@redhat.com> <20030522.034058.71558626.davem@redhat.com> <20030522114438.GD2961@netnation.com> <20030522.153330.74735095.davem@redhat.com> <20030529205125.GA30058@netnation.com> <16091.11735.721251.925522@robur.slu.se> <20030602151852.GA6070@netnation.com> <16091.32021.75335.227150@robur.slu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16091.32021.75335.227150@robur.slu.se> User-Agent: Mutt/1.5.4i X-archive-position: 2808 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sim@netnation.com Precedence: bulk X-list: netdev On Mon, Jun 02, 2003 at 06:36:37PM +0200, Robert Olsson wrote: > We are given more work than we have resources for (max_size) what else than > refuse can we do? But yes we have invested pretty much work already. Well, this is the problem. We do not and cannot know which entries we really want to remember (legitimate traffic). Adding code to actually refuse new dst entries is just going to make the DoS effective, which is NOT what we want. > Also remember we are looking into runs were 100% of incoming traffic has one > new dst for every packet. So how is the situation in "real life"? > In case of multiple devices at least NAPI gives all devs it's share. Right, so, when we are traffic saturated, we want to make sure the whole route cache and route path is as fast as possible. Recycling dst entries by simpy rewriting and rehashing them rather than allocating new and eventually freeing them all in the garbage collection cycle should reduce allocator overhead. If this is only done when the table is full, I don't see any downside...if this is in fact doable, that is. :) Simon- From kumarkr@us.ibm.com Mon Jun 2 12:48:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 12:48:44 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h52JmR2x029134 for ; Mon, 2 Jun 2003 12:48:34 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h52JlbXD283444; Mon, 2 Jun 2003 15:47:38 -0400 Received: from d03nm801.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h52JlZhO019342; Mon, 2 Jun 2003 13:47:36 -0600 Subject: Re: [PATCH] Prefix List patch against 2.5.70 To: davem@redhat.com Cc: kuznet@ms2.inr.ac.ru, linux-net@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Krishna Kumar Date: Mon, 2 Jun 2003 12:46:55 -0700 X-MIMETrack: Serialize by Router on D03NM801/03/M/IBM(Release 6.0.1 [IBM]|May 27, 2003) at 06/02/2003 13:45:07 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-archive-position: 2809 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kumarkr@us.ibm.com Precedence: bulk X-list: netdev Regarding my previous mail : > > Again, what I proposed was to store prefix information on fib with > > some flags to represent advertised by routers and give user-space > > the RA information using new rtattr (RTA_RA6INFO or something like that). > > > > struct rta_ra6info { > > u32 rta_ra6flags; > > }; > In my mail, I had given problems with doing that in the fib. I can look to > convert to fib, but please let me know which kernel routines I should look at What I meant is whether you are referring to addrconf_prefix_route() when you mention storing prefix on fib ? > > Again, what I proposed was to store prefix information on fib with > > some flags to represent advertised by routers and give user-space > > the RA information using new rtattr (RTA_RA6INFO or something like that). > > This sounds very reasonable. Also since you prefer it to be implemented as part of routing table, would it be OK to return the prefix list via netstat or route command (this uses rt6_info_route() to print the information). The current user for prefix list has no problem using a command instead of writing netlink user code to get the list. I am not sure why rtnetlink is needed in this case. thanks, - KK From dlstevens@us.ibm.com Mon Jun 2 14:03:09 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 14:03:21 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h52L322x032636 for ; Mon, 2 Jun 2003 14:03:09 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h52L2EQs218628; Mon, 2 Jun 2003 17:02:14 -0400 Received: from d03nm121.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h52L2Dba153836; Mon, 2 Jun 2003 15:02:13 -0600 Importance: Normal Sensitivity: Subject: Re: [PATCH] Prefix List patch against 2.5.70 To: YOSHIFUJI Hideaki / =?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?= Cc: krkumar@us.ibm.com, davem@redhat.com, kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com, linux-net@vger.kernel.org X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: David Stevens Date: Mon, 2 Jun 2003 15:02:03 -0600 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.1 [IBM]|April 28, 2003) at 06/02/2003 15:02:13 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-2022-JP X-archive-position: 2810 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev On the "location of the data" issue, I have some comment. The users of prefix list data don't know the prefix or the prefix length; they know the interface index, and need to get the prefixes. The data is fundamentally per-interface, and the routing table is per-destination. So, adding the prefixes to the routing table doesn't seem like the best choice because everything that currently uses the routing table will have to skip over these extra entries (which they'll never be interested in) and the users of the prefix data will have to skip over all existing routing table entries (which they're never interested in). Routes and prefixes are independent of each other, so throwing them in the same table to me seems like it only creates work to skip entries that aren't related, and because the users of the prefix data don't have the key needed for a fast look-up in the routing table, prefix users in particular have to skip through everything currently in the routing table, linearly, with no benefit at all for being there. I also see no relation between prefix list data and the FIB; current users are completely independent from prefix list users, and it appears to only slow both of them down. The prefix data is always looked-up by interface index, so I think it really belongs in the inet6 per-interface structure, unless I'm missing something. What benefits are there for lumping this with existing data structures that aren't per-interface, or keyed per-interface? +-DLS YOSHIFUJI Hideaki / 吉藤英明 @vger.kernel.org on 05/30/2003 07:02:49 PM Sent by: linux-net-owner@vger.kernel.org To: krkumar@us.ltcfwd.linux.ibm.com cc: davem@redhat.com, kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: [PATCH] Prefix List patch against 2.5.70 In article <3ED80230.2030508@us.ibm.com> (at Fri, 30 May 2003 18:15:28 -0700), Krishna Kumar says: > +/* prefix list returned to user space in this structure */ > +struct plist_user_info { ^ip6 or ipv6 or so. > + char name[IFNAMSIZ]; /* interface name */ ~~~~~~~~~~~~~~~~~~~duplicate information. > + int ifindex; /* interface index */ > + int nprefixes; /* number of elements in 'prefix' */ > + struct var_plist_user_info { /* multiple elements */ > + char flags[3]; /* router advertised flags */ ~~~~~~~~this is not good interface. > + int plen; /* prefix length */ > + __u32 valid; /* valid lifetime */ > + struct in6_addr ra_addr;/* advertising router */ > + struct in6_addr prefix; /* prefix */ > + } plist_vars[0]; > +}; > + > extern void addrconf_init(void); > extern void addrconf_cleanup(void); > : I think we should use 1 fixed-length message per prefix, instead of variable length message. > + pinfo->plist_vars[count].plen = p_el->pinfo.prefix_len; > + pinfo->plist_vars[count].valid = p_el->pinfo.valid - > + (jiffies - p_el->timestamp)/HZ; > + if ((p_el->ra_flags & (ND_RA_FLAG_MANAGED | > + ND_RA_FLAG_OTHER)) > + == (ND_RA_FLAG_MANAGED|ND_RA_FLAG_OTHER)) > + strcpy(pinfo->plist_vars[count].flags, "MO"); > + else if (p_el->ra_flags & ND_RA_FLAG_MANAGED) > + strcpy(pinfo->plist_vars[count].flags, "M"); > + else if (p_el->ra_flags & ND_RA_FLAG_OTHER) > + strcpy(pinfo->plist_vars[count].flags, "O"); > + else > + strcpy(pinfo->plist_vars[count].flags, "-"); > + ipv6_addr_copy(&pinfo->plist_vars[count].ra_addr, > + &p_el->ra_addr); > + for (i = 0; i < 8; i++) > + pinfo->plist_vars[count].ra_addr.s6_addr16[i] = > + __constant_ntohs(pinfo->plist_vars[count].ra_addr.s6_addr16[i]); > + ipv6_addr_copy(&pinfo->plist_vars[count].prefix, > + &p_el->pinfo.prefix); > + for (i = 0; i < p_el->pinfo.prefix_len/16; i++) > + pinfo->plist_vars[count].prefix.s6_addr16[i] = > + __constant_ntohs(pinfo->plist_vars[count].prefix.s6_addr16[i]); Absoletely nasty. - don't use charaters to represent flags; use real flags. - use network-byte order. > +static int prefix_list_proc_dump(char *buffer, char **start, off_t offset, > + int length) > +{ : Please use seq_file. Again, what I proposed was to store prefix information on fib with some flags to represent advertised by routers and give user-space the RA information using new rtattr (RTA_RA6INFO or something like that). struct rta_ra6info { u32 rta_ra6flags; }; -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA - To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From rddunlap@osdl.org Mon Jun 2 14:05:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 14:05:52 -0700 (PDT) Received: from mail.osdl.org (air-2.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h52L5d2x000551 for ; Mon, 2 Jun 2003 14:05:40 -0700 Received: from dragon.pdx.osdl.net (dragon.pdx.osdl.net [172.20.1.27]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h52L5FX04868; Mon, 2 Jun 2003 14:05:15 -0700 Date: Mon, 2 Jun 2003 14:04:52 -0700 From: "Randy.Dunlap" To: "David S. Miller" Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: netlink tester program Message-Id: <20030602140452.039248de.rddunlap@osdl.org> In-Reply-To: <20030530.234211.102567405.davem@redhat.com> References: <20030530090015.7c435c9a.rddunlap@osdl.org> <20030530.171111.71099698.davem@redhat.com> <32804.4.64.196.31.1054351332.squirrel@www.osdl.org> <20030530.234211.102567405.davem@redhat.com> Organization: OSDL X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i586-pc-linux-gnu) X-Face: +5V?h'hZQPB9kW Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2811 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev On Fri, 30 May 2003 23:42:11 -0700 (PDT) "David S. Miller" wrote: | From: "Randy.Dunlap" | Date: Fri, 30 May 2003 20:22:12 -0700 (PDT) | | Oh well, it's at this URL, bugs and all. | | http://www.xenotime.net/linux/ipv6/rtnl_test.c | | I know you don't want to use libnetlink from iproute2, but I want to | stress that it takes care of all of the minutae of netlink socket | usage that you have to duplicate in your little test program and this | duplication leads to bugs. | | Firstly, you needs to be fixed to call recvmsg() multiple times, | you'll get one entry for each recvmsg call in the table you are | querying. Yes, I noticed that I was getting only 1 msg there. | You really need something like rtnl_talk() or rtnl_dump_filter() | from libnetlink to do this properly. Does anyone have documentation (or semantics) for rtnl_talk()? or just some blurb about it? Andi's libnetlink man page missed it somehow. Thanks, -- ~Randy From pb@bieringer.de Mon Jun 2 14:52:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 14:52:39 -0700 (PDT) Received: from smtp2.aerasec.de (gromit.aerasec.de [195.226.187.57]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h52Lq02x002042 for ; Mon, 2 Jun 2003 14:52:21 -0700 Received: by smtp2.aerasec.de (Postfix, from userid 995) id 098561387A; Mon, 2 Jun 2003 23:12:13 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by smtp2.aerasec.de (Postfix) with SMTP id 302D21387D; Mon, 2 Jun 2003 23:12:12 +0200 (CEST) X-AV-Checked: Mon Jun 2 23:12:12 2003 smtp2.aerasec.de Received: from [192.168.1.2] (p50805317.dip.t-dialin.net [80.128.83.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by smtp2.aerasec.de (Postfix) with ESMTP id D80391387A; Mon, 2 Jun 2003 23:12:10 +0200 (CEST) Date: Mon, 02 Jun 2003 23:12:08 +0200 From: Peter Bieringer To: Maillist netdev Cc: Maillist USAGI-users Subject: Is there already a doc available for the new IPsec code? Message-ID: <36990000.1054588328@worker.muc.bieringer.de> X-Mailer: Mulberry/3.0.3 (Linux/x86) X-URL: http://www.bieringer.de/pb/ X-OS: Linux MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 2812 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pb@bieringer.de Precedence: bulk X-list: netdev Hi, i want to play a little bit with the new IPsec code. Is there already a doc available how to use it (config file of IKE daemon, etc., e.g. compared against the FreeS/WAN code). Thank you very much for input, Peter -- Dr. Peter Bieringer http://www.bieringer.de/pb/ GPG/PGP Key 0x958F422D mailto: pb at bieringer dot de Deep Space 6 Co-Founder and Core Member http://www.deepspace6.net/ From acme@conectiva.com.br Mon Jun 2 14:57:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 14:57:57 -0700 (PDT) Received: from orion.netbank.com.br (orion.netbank.com.br [200.203.199.90]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h52LvV2x002424 for ; Mon, 2 Jun 2003 14:57:52 -0700 Received: from [200.181.171.58] (helo=brinquendo.conectiva.com.br) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 19YC5G-0004y9-00; Thu, 03 Jul 2003 18:57:43 -0300 Received: by brinquendo.conectiva.com.br (Postfix, from userid 500) id 8850C1966C; Mon, 2 Jun 2003 21:58:16 +0000 (UTC) Date: Mon, 2 Jun 2003 18:58:15 -0300 From: Arnaldo Carvalho de Melo To: Peter Bieringer Cc: Maillist netdev , Maillist USAGI-users Subject: Re: Is there already a doc available for the new IPsec code? Message-ID: <20030602215815.GL9312@conectiva.com.br> References: <36990000.1054588328@worker.muc.bieringer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <36990000.1054588328@worker.muc.bieringer.de> X-Url: http://advogato.org/person/acme Organization: Conectiva S.A. User-Agent: Mutt/1.5.4i X-archive-position: 2813 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Em Mon, Jun 02, 2003 at 11:12:08PM +0200, Peter Bieringer escreveu: > Hi, > > i want to play a little bit with the new IPsec code. > > Is there already a doc available how to use it (config file of IKE daemon, > etc., e.g. compared against the FreeS/WAN code). > > Thank you very much for input, Look at Bert Hubert's LART - Arnaldo From davem@redhat.com Mon Jun 2 14:58:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 14:58:37 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h52LwC2x002530 for ; Mon, 2 Jun 2003 14:58:33 -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 OAA24872; Mon, 2 Jun 2003 14:56:20 -0700 Date: Mon, 02 Jun 2003 14:56:19 -0700 (PDT) Message-Id: <20030602.145619.71112623.davem@redhat.com> To: rddunlap@osdl.org Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: netlink tester program From: "David S. Miller" In-Reply-To: <20030602140452.039248de.rddunlap@osdl.org> References: <32804.4.64.196.31.1054351332.squirrel@www.osdl.org> <20030530.234211.102567405.davem@redhat.com> <20030602140452.039248de.rddunlap@osdl.org> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2814 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: "Randy.Dunlap" Date: Mon, 2 Jun 2003 14:04:52 -0700 Does anyone have documentation (or semantics) for rtnl_talk()? or just some blurb about it? I always have to wonder about someone who can't live with just working code to study, and absolutely requires some document describing it. What is better or more accurate description than code itself!?!?! From rddunlap@osdl.org Mon Jun 2 15:00:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 15:00:25 -0700 (PDT) Received: from mail.osdl.org (air-2.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h52M012x003050 for ; Mon, 2 Jun 2003 15:00:21 -0700 Received: from dragon.pdx.osdl.net (dragon.pdx.osdl.net [172.20.1.27]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h52LxfX22069; Mon, 2 Jun 2003 14:59:41 -0700 Date: Mon, 2 Jun 2003 14:59:17 -0700 From: "Randy.Dunlap" To: Arnaldo Carvalho de Melo Cc: pb@bieringer.de, netdev@oss.sgi.com, usagi-users@linux-ipv6.org Subject: Re: Is there already a doc available for the new IPsec code? Message-Id: <20030602145917.33fbd05d.rddunlap@osdl.org> In-Reply-To: <20030602215815.GL9312@conectiva.com.br> References: <36990000.1054588328@worker.muc.bieringer.de> <20030602215815.GL9312@conectiva.com.br> Organization: OSDL X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i586-pc-linux-gnu) X-Face: +5V?h'hZQPB9kW Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2815 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev On Mon, 2 Jun 2003 18:58:15 -0300 Arnaldo Carvalho de Melo wrote: | Em Mon, Jun 02, 2003 at 11:12:08PM +0200, Peter Bieringer escreveu: | > Hi, | > | > i want to play a little bit with the new IPsec code. | > | > Is there already a doc available how to use it (config file of IKE daemon, | > etc., e.g. compared against the FreeS/WAN code). | > | > Thank you very much for input, | | Look at Bert Hubert's LART | | - Arnaldo that's www.lartc.org ... -- ~Randy From david-b@pacbell.net Mon Jun 2 18:56:07 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 18:56:11 -0700 (PDT) Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h531u62x010771 for ; Mon, 2 Jun 2003 18:56:06 -0700 Received: from pacbell.net (ppp-67-118-246-97.dialup.pltn13.pacbell.net [67.118.246.97]) by mta7.pltn13.pbi.net (8.12.9/8.12.3) with ESMTP id h531trEQ002137; Mon, 2 Jun 2003 18:55:54 -0700 (PDT) Message-ID: <3EDC0047.7030007@pacbell.net> Date: Mon, 02 Jun 2003 18:56:23 -0700 From: David Brownell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: "David S. Miller" CC: rddunlap@osdl.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: netlink tester program References: <32804.4.64.196.31.1054351332.squirrel@www.osdl.org> <20030530.234211.102567405.davem@redhat.com> <20030602140452.039248de.rddunlap@osdl.org> <20030602.145619.71112623.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2816 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: david-b@pacbell.net Precedence: bulk X-list: netdev David S. Miller wrote: > From: "Randy.Dunlap" > Date: Mon, 2 Jun 2003 14:04:52 -0700 > > Does anyone have documentation (or semantics) for rtnl_talk()? > or just some blurb about it? > > I always have to wonder about someone who can't live with just > working code to study, and absolutely requires some document > describing it. > > What is better or more accurate description than code itself!?!?! Well, the difference between code and its spec is generally a bug that needs to be fixed ... which can be in the code as well as in the spec. And for reasonable design specs, it's more likely in the code. But if there's only the code, it gets a lot more troublesome when things don't behave "as expected". People who are in a position to change the code to meet their expectations may not care, but that's rarely a significant chunk of the user community. And in particular, writing tests against the code is generally the wrong way to go. They need to be written against some kind of spec. - Dave From davem@redhat.com Mon Jun 2 19:04:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 19:04:42 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h5324a2x011315 for ; Mon, 2 Jun 2003 19:04:36 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id TAA25475; Mon, 2 Jun 2003 19:02:41 -0700 Date: Mon, 02 Jun 2003 19:02:40 -0700 (PDT) Message-Id: <20030602.190240.74724523.davem@redhat.com> To: david-b@pacbell.net Cc: rddunlap@osdl.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: netlink tester program From: "David S. Miller" In-Reply-To: <3EDC0047.7030007@pacbell.net> References: <20030602140452.039248de.rddunlap@osdl.org> <20030602.145619.71112623.davem@redhat.com> <3EDC0047.7030007@pacbell.net> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2817 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: David Brownell Date: Mon, 02 Jun 2003 18:56:23 -0700 Well, the difference between code and its spec is generally a bug that needs to be fixed ... See, a document is NOT the spec, the code is the spec. Because where the document is wrong, the code determines the final answer. This is true in all cases. I cannot tell you how much time I've seen people waste because they went for documents first, only to find them to be inaccurate for some corner case whilst the code has all of the accurate answers. When I see someone want docs, I interpret this as "I don't want to have to think or have to comprehend something, I'm too lazy to read the code." Well, such laziness leads the person in question only to be suscpetible to all of the inaccuracies and disconnect that always will exist between said docs (if they even exist) and the code. It is also the mechanism that leads people to send patches that add arbitrary crap all over the ipv4/ipv6 code, totally missing the point that the routing and/or netlink layer did %99 of what they wanted already. For example, I added a hoplimit route attribute to RTNETLINK. Who documented this? What document can you read that would teach you about this feature? None. And don't tell me this is a doc bug, every time I make a change the documentation will be instantly buggy and I'm not going to be required to document every diff I make to the tree. From jsd@monmouth.com Mon Jun 2 19:34:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 19:34:31 -0700 (PDT) Received: from av8n.net (pcp03191463pcs.midltn01.nj.comcast.net [68.37.175.11]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h532Y42x012360 for ; Mon, 2 Jun 2003 19:34:25 -0700 Received: (qmail 4037 invoked from network); 3 Jun 2003 02:33:59 -0000 Received: from localhost (HELO monmouth.com) (127.0.0.1) by localhost with SMTP; 3 Jun 2003 02:33:59 -0000 Message-ID: <3EDC0915.1080109@monmouth.com> Date: Mon, 02 Jun 2003 22:33:57 -0400 From: "John S. Denker" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: rddunlap@osdl.org, linux-net@vger.kernel.org, netdev@oss.sgi.com, David Brownell Subject: Re: netlink tester program References: <32804.4.64.196.31.1054351332.squirrel@www.osdl.org> <20030530.234211.102567405.davem@redhat.com> <20030602140452.039248de.rddunlap@osdl.org> <20030602.145619.71112623.davem@redhat.com> In-Reply-To: <20030602.145619.71112623.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2818 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jsd@monmouth.com Precedence: bulk X-list: netdev On 06/02/2003 05:56 PM, David S. Miller wrote: >> >> I always have to wonder about someone who can't live with just >> working code to study, and absolutely requires some document >> describing it. >> >> What is better or more accurate description than code itself!?!?! I am very grateful for the kindness of those who have written the code in question and made it available to help others. I wish to repay that with help and kindness, not the opposite. Today I can help by speaking the truth, and the truth is that documentation is sorely needed. There's no point in writing code if few people use it. Linux is hanging in there at a few percent market share. That's not going to grow unless there is better documentation. On 06/02/2003 09:56 PM, David Brownell replied: > > Well, the difference between code and its spec is > generally a bug that needs to be fixed ... which > can be in the code as well as in the spec. And for > reasonable design specs, it's more likely in the code. > > But if there's only the code, it gets a lot more > troublesome when things don't behave "as expected". > > People who are in a position to change the code > to meet their expectations may not care, but that's > rarely a significant chunk of the user community. > > And in particular, writing tests against the code > is generally the wrong way to go. They need to be > written against some kind of spec. I have to agree with Mr. Brownell on this one. >> What is better or more accurate description than code itself!?!?! There are two ideas mixed up there. -- Better documentation. -- Accurate description. 1) Yes, code is the most accurate description of the code. But it is not to be confused with good documentation. 2) Documentation should be clear and concise. Code must attend to all the details. 3) Sometimes efficiency requires that the code be tricky. Documentation must not be tricky. 4) In theory, very well-commented code might approximate its own documentation. But I haven't seen any such code lately. Here are _all_ the comments from xfrm_input.c, a 454-line file: /* Fetch spi and seq frpm ipsec header */ /* Allocate new secpath or COW existing one. */ /* Fetch spi and seq frpm ipsec header */ iph = skb->nh.ipv6h; /* ??? */ if (x->props.mode) { /* XXX */ /* Allocate new secpath or COW existing one. */ #endif /* CONFIG_IPV6 || CONFIG_IPV6_MODULE */ If you were teaching a programming course, how would you grade an assignment turned in with that level of commenting? 5) In the engine of a piston-driven airplane, there are two spark plugs in every cylinder. Obviously that costs twice as much and weighs twice as much as having only one. But the redundancy makes the system thousands of times more reliable. Similarly, writing code _and_ documetation is about twice as expensive as writing the code alone. But the redundancy makes it possible to achieve much greater reliability. Also maintainability and extensibility. 6) Adding extra vehemence '!?!?!' does not add clarity to the discussion. *) et cetera. From davem@redhat.com Mon Jun 2 19:40:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 19:40:56 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h532en2x012713 for ; Mon, 2 Jun 2003 19:40:50 -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 TAA25623; Mon, 2 Jun 2003 19:38:53 -0700 Date: Mon, 02 Jun 2003 19:38:53 -0700 (PDT) Message-Id: <20030602.193853.112598236.davem@redhat.com> To: jsd@monmouth.com Cc: rddunlap@osdl.org, linux-net@vger.kernel.org, netdev@oss.sgi.com, david-b@pacbell.net Subject: Re: netlink tester program From: "David S. Miller" In-Reply-To: <3EDC0915.1080109@monmouth.com> References: <20030602140452.039248de.rddunlap@osdl.org> <20030602.145619.71112623.davem@redhat.com> <3EDC0915.1080109@monmouth.com> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2819 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: "John S. Denker" Date: Mon, 02 Jun 2003 22:33:57 -0400 There's no point in writing code if few people use it. People use this "undocumented" area of the kernel every time their machine boots up. From jsd@monmouth.com Mon Jun 2 20:21:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 20:21:10 -0700 (PDT) Received: from av8n.net (pcp03191463pcs.midltn01.nj.comcast.net [68.37.175.11]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h533L12x013419 for ; Mon, 2 Jun 2003 20:21:02 -0700 Received: (qmail 4663 invoked from network); 3 Jun 2003 03:20:56 -0000 Received: from localhost (HELO monmouth.com) (127.0.0.1) by localhost with SMTP; 3 Jun 2003 03:20:56 -0000 Message-ID: <3EDC1418.6080808@monmouth.com> Date: Mon, 02 Jun 2003 23:20:56 -0400 From: "John S. Denker" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: netlink tester program References: <20030602140452.039248de.rddunlap@osdl.org> <20030602.145619.71112623.davem@redhat.com> <3EDC0915.1080109@monmouth.com> <20030602.193853.112598236.davem@redhat.com> In-Reply-To: <20030602.193853.112598236.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2820 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jsd@monmouth.com Precedence: bulk X-list: netdev I wrote in part: > > There's no point in writing code if few people > use it. On 06/02/2003 10:38 PM, David S. Miller wrote: > > People use this "undocumented" area of the kernel every > time their machine boots up. That's not inconsistent with what I was saying. Mr. Miller said people use it. That's true. Some people use it. I said few people use it. That's true. The context of my original statement was: > Linux is hanging in there at a few > percent market share. That's not going to grow > unless there is better documentation. This is supposed to be open-source software, n'est-ce pas? Software that is copylefted but not documented is open according to the letter of the law, but lacks the spirit of openness. Mr. Miller is very smart and has spent years getting up to speed in this area. Is the code to be open only to those who are equally smart and willing to invest equally huge amounts of time? When people ask for help in understanding the code, it might mean they need help in understanding the code. From davem@redhat.com Mon Jun 2 20:24:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 20:24:31 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h533OR2x013749 for ; Mon, 2 Jun 2003 20:24:27 -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 UAA25722; Mon, 2 Jun 2003 20:22:33 -0700 Date: Mon, 02 Jun 2003 20:22:33 -0700 (PDT) Message-Id: <20030602.202233.39180859.davem@redhat.com> To: jsd@monmouth.com Cc: netdev@oss.sgi.com Subject: Re: netlink tester program From: "David S. Miller" In-Reply-To: <3EDC1418.6080808@monmouth.com> References: <3EDC0915.1080109@monmouth.com> <20030602.193853.112598236.davem@redhat.com> <3EDC1418.6080808@monmouth.com> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2821 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: "John S. Denker" Date: Mon, 02 Jun 2003 23:20:56 -0400 Mr. Miller is very smart and has spent years getting up to speed in this area. Is the code to be open only to those who are equally smart and willing to invest equally huge amounts of time? Are legal rights only available to people who understand the law and have a legal degree? No, this is why we hire lawyers if we choose not to study law ourselves. Your logic is heavily flawed. From david-b@pacbell.net Mon Jun 2 20:32:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 20:32:48 -0700 (PDT) Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h533WO2x014086 for ; Mon, 2 Jun 2003 20:32:44 -0700 Received: from pacbell.net (ppp-67-118-247-59.dialup.pltn13.pacbell.net [67.118.247.59]) by mta4.rcsntx.swbell.net (8.12.9/8.12.3) with ESMTP id h533WDhi012216; Mon, 2 Jun 2003 22:32:18 -0500 (CDT) Message-ID: <3EDC173B.80909@pacbell.net> Date: Mon, 02 Jun 2003 20:34:19 -0700 From: David Brownell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: "David S. Miller" CC: rddunlap@osdl.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: netlink tester program References: <20030602140452.039248de.rddunlap@osdl.org> <20030602.145619.71112623.davem@redhat.com> <3EDC0047.7030007@pacbell.net> <20030602.190240.74724523.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2823 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: david-b@pacbell.net Precedence: bulk X-list: netdev > Well, the difference between code and its spec is > generally a bug that needs to be fixed ... > > See, a document is NOT the spec, the code is the spec. That's hardly the only development model. > Because where the document is wrong, the code determines > the final answer. This is true in all cases. Not "all". "Code-as-spec" works well when there's only one code base, but otherwise it's flawed. Even the model of a "reference implementation" is trouble ... since it invariably evolves into "everyone should use this code". Of course, bugs that stay unfixed for a long time can force the "spec" to change. It's a great vendor lock-in tool, and it can happen accidentally too. But most folk view such interop problems as bugs, not features. > I cannot tell you how much time I've seen people waste because they > went for documents first, only to find them to be inaccurate for some > corner case whilst the code has all of the accurate answers. Or where they notice the code is wrong in that corner case, and they can prove that easily since the spec (implemented correctly in several other places) and the code disagree. Or where this implementation uses this answer, and that one uses that answer ... and the poor user gets caught in the middle of a finger pointing war, which can't be resolved since each implementation's developers claim to be "the spec", and the user eventually gives up saying "a pox on you all!" You clipped out the text where I pointed out that bugs can be in specs as well as code. They can be fixed there, too. > When I see someone want docs, I interpret this as "I don't want to > have to think or have to comprehend something, I'm too lazy to read > the code." Well, such laziness leads the person in question only > to be suscpetible to all of the inaccuracies and disconnect that > always will exist between said docs (if they even exist) and the > code. That's an *extremely negative interpretation*, and while I've seen people that are that lazy, they happen to be in the minority of people I've known to ask for docs/specs. (Thank the Gods!) Consider one thing that docs/specs do that code can't: give the "30,000 foot view" rather than the "tree level view". It's not "lazy" to avoid using the tree-level view; sometimes such low-level perspectives can be counterproductive. People ask for docs for lots of reasons, and most of them have nothing at all to do with laziness. - Dave From rddunlap@osdl.org Mon Jun 2 20:32:30 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 20:32:34 -0700 (PDT) Received: from mail.osdl.org (air-2.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h533WS2x014085 for ; Mon, 2 Jun 2003 20:32:29 -0700 Received: from fire-1.osdl.org (air1.pdx.osdl.net [172.20.0.5]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id h533WMX27576; Mon, 2 Jun 2003 20:32:22 -0700 Received: from osdl.org (fire.osdl.org [65.172.181.4]) by fire-1.osdl.org (8.12.8/8.11.6) with SMTP id h533WM5C029705; Mon, 2 Jun 2003 20:32:22 -0700 Received: from 4.64.196.31 (SquirrelMail authenticated user rddunlap) by www.osdl.org with HTTP; Mon, 2 Jun 2003 20:32:22 -0700 (PDT) Message-ID: <33001.4.64.196.31.1054611142.squirrel@www.osdl.org> Date: Mon, 2 Jun 2003 20:32:22 -0700 (PDT) Subject: Re: netlink tester program From: "Randy.Dunlap" To: In-Reply-To: <20030602.145619.71112623.davem@redhat.com> References: <32804.4.64.196.31.1054351332.squirrel@www.osdl.org> <20030530.234211.102567405.davem@redhat.com> <20030602140452.039248de.rddunlap@osdl.org> <20030602.145619.71112623.davem@redhat.com> X-Priority: 3 Importance: Normal Cc: , , X-Mailer: SquirrelMail (version 1.2.11) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 2822 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev > From: "Randy.Dunlap" > Date: Mon, 2 Jun 2003 14:04:52 -0700 > > Does anyone have documentation (or semantics) for rtnl_talk()? > or just some blurb about it? > > I always have to wonder about someone who can't live with just > working code to study, and absolutely requires some document > describing it. > > What is better or more accurate description than code itself!?!?! The code is absolute, no doubt about it. It is the authority. That doesn't make it right in all cases AFAIK. And it lacks documentation, even in the source files. There are no semantics or meaning associated with that code except by the people who developed it. I'm not one of them, so I'm trying to ask them or others who know. And yes, I'm looking for the way that it should be done (IMHO) instead of the way it is done. Now, given that I think that the netlink interface is poorly documented, and that I'm trying to add some kernel code that uses it, and that I'm trying to test said kernel code with a userspace test program, I also plan to add such documentation that I think is warranted to make it easy to use, even by non-kernel devevlopers. This documentation might end up living outside of the kernel tree -- that's OK. But in any case, from both private and mailing list emails, I'm not alone in thinking that it's needed. ~Randy From david-b@pacbell.net Mon Jun 2 20:35:07 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 20:35:10 -0700 (PDT) Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h533Z62x014700 for ; Mon, 2 Jun 2003 20:35:06 -0700 Received: from pacbell.net (ppp-67-118-247-59.dialup.pltn13.pacbell.net [67.118.247.59]) by mta4.rcsntx.swbell.net (8.12.9/8.12.3) with ESMTP id h533Z1hi017198; Mon, 2 Jun 2003 22:35:01 -0500 (CDT) Message-ID: <3EDC17E4.6070506@pacbell.net> Date: Mon, 02 Jun 2003 20:37:08 -0700 From: David Brownell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: "John S. Denker" CC: "David S. Miller" , rddunlap@osdl.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: netlink tester program References: <32804.4.64.196.31.1054351332.squirrel@www.osdl.org> <20030530.234211.102567405.davem@redhat.com> <20030602140452.039248de.rddunlap@osdl.org> <20030602.145619.71112623.davem@redhat.com> <3EDC0915.1080109@monmouth.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2824 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: david-b@pacbell.net Precedence: bulk X-list: netdev John S. Denker wrote: > Similarly, writing code _and_ documetation is about > twice as expensive as writing the code alone. But > the redundancy makes it possible to achieve much > greater reliability. Also maintainability and > extensibility. Excellent points. The developement process needs to address communities other than the folk writing the code ... like the people who inherit that code, and the ones trying to use it. (Testing being a rather specialize type of "use".) - Dave From davem@redhat.com Mon Jun 2 20:37:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 20:37:07 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h533b12x015003 for ; Mon, 2 Jun 2003 20:37:01 -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 UAA25846; Mon, 2 Jun 2003 20:35:05 -0700 Date: Mon, 02 Jun 2003 20:35:05 -0700 (PDT) Message-Id: <20030602.203505.59678701.davem@redhat.com> To: rddunlap@osdl.org Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: netlink tester program From: "David S. Miller" In-Reply-To: <33001.4.64.196.31.1054611142.squirrel@www.osdl.org> References: <20030602140452.039248de.rddunlap@osdl.org> <20030602.145619.71112623.davem@redhat.com> <33001.4.64.196.31.1054611142.squirrel@www.osdl.org> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2825 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: "Randy.Dunlap" Date: Mon, 2 Jun 2003 20:32:22 -0700 (PDT) The code is absolute, no doubt about it. It is the authority. That doesn't make it right in all cases AFAIK. I totally agree. Now, given that I think that the netlink interface is poorly documented, and that I'm trying to add some kernel code that uses it, and that I'm trying to test said kernel code with a userspace test program, I also plan to add such documentation that I think is warranted to make it easy to use, even by non-kernel devevlopers. This is exactly how things should work. Where there is a need for X _AND_ someone willing to create X, it will be created. No arguments from me on this :-) From jsd@monmouth.com Mon Jun 2 20:41:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 20:41:48 -0700 (PDT) Received: from av8n.net (pcp03191463pcs.midltn01.nj.comcast.net [68.37.175.11]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h533fi2x015402 for ; Mon, 2 Jun 2003 20:41:44 -0700 Received: (qmail 4890 invoked from network); 3 Jun 2003 03:41:39 -0000 Received: from localhost (HELO monmouth.com) (127.0.0.1) by localhost with SMTP; 3 Jun 2003 03:41:39 -0000 Message-ID: <3EDC18F2.6090505@monmouth.com> Date: Mon, 02 Jun 2003 23:41:38 -0400 From: "John S. Denker" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: netlink tester program References: <3EDC0915.1080109@monmouth.com> <20030602.193853.112598236.davem@redhat.com> <3EDC1418.6080808@monmouth.com> <20030602.202233.39180859.davem@redhat.com> In-Reply-To: <20030602.202233.39180859.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2826 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jsd@monmouth.com Precedence: bulk X-list: netdev On 06/02/2003 11:22 PM, David S. Miller wrote: > > Are legal rights only available to people who understand > the law and have a legal degree? > > No, this is why we hire lawyers if we choose not to study > law ourselves. If we are taking the legal system as our model of openness, then open-source software has come to a sorry pass indeed. ========= It is also important to distinguish what's best for *you* and what's best for the project. Maybe *you* don't want to be responsible for doing all the documentation. I can understand that. But the project as a whole would be better off it it had better documentation. Perhaps you could recruit other folks to help with this. But disdaining the whole concept isn't a good way to start the recruiting. From davem@redhat.com Mon Jun 2 20:44:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 20:44:21 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h533iH2x015769 for ; Mon, 2 Jun 2003 20:44:18 -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 UAA25861; Mon, 2 Jun 2003 20:38:35 -0700 Date: Mon, 02 Jun 2003 20:38:34 -0700 (PDT) Message-Id: <20030602.203834.115933659.davem@redhat.com> To: david-b@pacbell.net Cc: rddunlap@osdl.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: netlink tester program From: "David S. Miller" In-Reply-To: <3EDC173B.80909@pacbell.net> References: <3EDC0047.7030007@pacbell.net> <20030602.190240.74724523.davem@redhat.com> <3EDC173B.80909@pacbell.net> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2827 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: David Brownell Date: Mon, 02 Jun 2003 20:34:19 -0700 > See, a document is NOT the spec, the code is the spec. That's hardly the only development model. It's the one that works for _me_ and Alexey and myself, and we're the ones doing all the work. When someone doing the work desires the docs and desires to WRITE it, it will appear. You can expect exactly nothing more in our development model. If you require me to write the docs, you misunderstand how the system works :) You clipped out the text where I pointed out that bugs can be in specs as well as code. They can be fixed there, too. Very true. So when Randy writes the more detailed netlink/rtnetlink docs, we'll be happy :-) There is even an official IETF RFC written by Jamal, Alexey, and others documenting netlink btw :-)))))))))))) Did anybody notice this? From davem@redhat.com Mon Jun 2 20:48:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 20:48:44 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h533me2x016214 for ; Mon, 2 Jun 2003 20:48:40 -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 UAA25892; Mon, 2 Jun 2003 20:46:45 -0700 Date: Mon, 02 Jun 2003 20:46:45 -0700 (PDT) Message-Id: <20030602.204645.48505284.davem@redhat.com> To: jsd@monmouth.com Cc: netdev@oss.sgi.com Subject: Re: netlink tester program From: "David S. Miller" In-Reply-To: <3EDC18F2.6090505@monmouth.com> References: <3EDC1418.6080808@monmouth.com> <20030602.202233.39180859.davem@redhat.com> <3EDC18F2.6090505@monmouth.com> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2828 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: "John S. Denker" Date: Mon, 02 Jun 2003 23:41:38 -0400 If we are taking the legal system as our model of openness, then open-source software has come to a sorry pass indeed. It does have connections where a "user" wants to do something with FOO but does not wish to do the legwork necessary to be an expert in FOO. They hire an expert. Or, in our case, they make an expert interested in the thing they want to do :-))) It is also important to distinguish what's best for *you* and what's best for the project. Maybe *you* don't want to be responsible for doing all the documentation. I'm not even going to attempt to document something that moves as fast as the kernel. I go to bookstores and I see many excellent attempts to document kernel internals, but these books are frozen in time. Specifically they are frozen in the time of the moment the kernel they write for is published. As a consequence they are all obsolete the moment they are published. Some poor student reads these books, written against 2.4.8 or whatever, then they go and try to contribute to 2.5.x and it doesn't work except for certain kinds of drivers where we've kept the APIs more or less the same. But I don't care that people do this, just don't require that I do it. I think this extra fluidity we get from being able to change so fast is a strength not a weakness. From rddunlap@osdl.org Mon Jun 2 20:49:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 20:49:43 -0700 (PDT) Received: from mail.osdl.org (air-2.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h533nd2x016498 for ; Mon, 2 Jun 2003 20:49:39 -0700 Received: from fire-1.osdl.org (air1.pdx.osdl.net [172.20.0.5]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id h533nWX32403; Mon, 2 Jun 2003 20:49:32 -0700 Received: from osdl.org (fire.osdl.org [65.172.181.4]) by fire-1.osdl.org (8.12.8/8.11.6) with SMTP id h533nW5C030705; Mon, 2 Jun 2003 20:49:32 -0700 Received: from 4.64.196.31 (SquirrelMail authenticated user rddunlap) by www.osdl.org with HTTP; Mon, 2 Jun 2003 20:49:32 -0700 (PDT) Message-ID: <33060.4.64.196.31.1054612172.squirrel@www.osdl.org> Date: Mon, 2 Jun 2003 20:49:32 -0700 (PDT) Subject: Re: netlink tester program From: "Randy.Dunlap" To: In-Reply-To: <20030602.203834.115933659.davem@redhat.com> References: <3EDC0047.7030007@pacbell.net> <20030602.190240.74724523.davem@redhat.com> <3EDC173B.80909@pacbell.net> <20030602.203834.115933659.davem@redhat.com> X-Priority: 3 Importance: Normal Cc: , , , X-Mailer: SquirrelMail (version 1.2.11) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 2829 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev > From: David Brownell > Date: Mon, 02 Jun 2003 20:34:19 -0700 > > > See, a document is NOT the spec, the code is the spec. > > That's hardly the only development model. > > It's the one that works for _me_ and Alexey and myself, and we're the ones > doing all the work. Do you want it to remain that way? > When someone doing the work desires the docs and desires to > WRITE it, it will appear. > > You can expect exactly nothing more in our development model. > If you require me to write the docs, you misunderstand how the > system works :) > > You clipped out the text where I pointed out that bugs can > be in specs as well as code. They can be fixed there, too. > > Very true. So when Randy writes the more detailed netlink/rtnetlink docs, > we'll be happy :-) > > There is even an official IETF RFC written by Jamal, Alexey, and > others documenting netlink btw :-)))))))))))) > > Did anybody notice this? Yes. ~Randy From rddunlap@osdl.org Mon Jun 2 20:54:08 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 20:54:11 -0700 (PDT) Received: from mail.osdl.org (air-2.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h533s62x016967 for ; Mon, 2 Jun 2003 20:54:07 -0700 Received: from fire-1.osdl.org (air1.pdx.osdl.net [172.20.0.5]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id h533s1X00402; Mon, 2 Jun 2003 20:54:01 -0700 Received: from osdl.org (fire.osdl.org [65.172.181.4]) by fire-1.osdl.org (8.12.8/8.11.6) with SMTP id h533s15C030774; Mon, 2 Jun 2003 20:54:01 -0700 Received: from 4.64.196.31 (SquirrelMail authenticated user rddunlap) by www.osdl.org with HTTP; Mon, 2 Jun 2003 20:54:01 -0700 (PDT) Message-ID: <33078.4.64.196.31.1054612441.squirrel@www.osdl.org> Date: Mon, 2 Jun 2003 20:54:01 -0700 (PDT) Subject: Re: netlink tester program From: "Randy.Dunlap" To: In-Reply-To: <20030602.204645.48505284.davem@redhat.com> References: <3EDC1418.6080808@monmouth.com> <20030602.202233.39180859.davem@redhat.com> <3EDC18F2.6090505@monmouth.com> <20030602.204645.48505284.davem@redhat.com> X-Priority: 3 Importance: Normal Cc: , X-Mailer: SquirrelMail (version 1.2.11) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 2831 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev > It is also important to distinguish what's best > for *you* and what's best for the project. > Maybe *you* don't want to be responsible for > doing all the documentation. > > I'm not even going to attempt to document something that > moves as fast as the kernel. That point is a real problem... > I go to bookstores and I see many excellent attempts to document > kernel internals, but these books are frozen in time. Specifically they are > frozen in the time of the moment the kernel they write for is published. As > a consequence they are all obsolete the moment they are published. No doubt. > Some poor student reads these books, written against 2.4.8 or > whatever, then they go and try to contribute to 2.5.x and it > doesn't work except for certain kinds of drivers where we've > kept the APIs more or less the same. > > But I don't care that people do this, just don't require that I do it. Sure. Are you willing to answer questions about it at least? > I think this extra fluidity we get from being able to change so fast is a > strength not a weakness. If it were only a strength, that would be great. I believe that it's both, however. ~Randy From davem@redhat.com Mon Jun 2 20:53:56 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 20:53:59 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h533rt2x016943 for ; Mon, 2 Jun 2003 20:53:56 -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 UAA25928; Mon, 2 Jun 2003 20:51:56 -0700 Date: Mon, 02 Jun 2003 20:51:56 -0700 (PDT) Message-Id: <20030602.205156.08346169.davem@redhat.com> To: rddunlap@osdl.org Cc: david-b@pacbell.net, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: netlink tester program From: "David S. Miller" In-Reply-To: <33060.4.64.196.31.1054612172.squirrel@www.osdl.org> References: <3EDC173B.80909@pacbell.net> <20030602.203834.115933659.davem@redhat.com> <33060.4.64.196.31.1054612172.squirrel@www.osdl.org> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2830 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: "Randy.Dunlap" Date: Mon, 2 Jun 2003 20:49:32 -0700 (PDT) > It's the one that works for _me_ and Alexey and myself, and we're > the ones doing all the work. Do you want it to remain that way? Doesn't matter to _us_, _we_ know how these things work and how to use them. If we don't, we'll read the code to learn this. Other's care, and if someone writes the docs for _them_, that is _fine_. What I object to is "hey we have to have docs, why didn't dave and alexey write them". :) Franks a lot, David S. Miller davem@redhat.com From davem@redhat.com Mon Jun 2 20:56:21 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 20:56:24 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h533uL2x017606 for ; Mon, 2 Jun 2003 20:56:21 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id UAA25955; Mon, 2 Jun 2003 20:54:26 -0700 Date: Mon, 02 Jun 2003 20:54:25 -0700 (PDT) Message-Id: <20030602.205425.21904841.davem@redhat.com> To: rddunlap@osdl.org Cc: jsd@monmouth.com, netdev@oss.sgi.com Subject: Re: netlink tester program From: "David S. Miller" In-Reply-To: <33078.4.64.196.31.1054612441.squirrel@www.osdl.org> References: <3EDC18F2.6090505@monmouth.com> <20030602.204645.48505284.davem@redhat.com> <33078.4.64.196.31.1054612441.squirrel@www.osdl.org> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2832 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: "Randy.Dunlap" Date: Mon, 2 Jun 2003 20:54:01 -0700 (PDT) > But I don't care that people do this, just don't require that I do it. Sure. Are you willing to answer questions about it at least? As long as others like Alexey and Jamal help field these questions and it's not just me sitting here becoming a Linux development support service :-) From pekkas@netcore.fi Mon Jun 2 21:48:43 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 21:48:56 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h534mf2x019134 for ; Mon, 2 Jun 2003 21:48:42 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h534mDd09020; Tue, 3 Jun 2003 07:48:13 +0300 Date: Tue, 3 Jun 2003 07:48:13 +0300 (EEST) From: Pekka Savola To: David Stevens cc: YOSHIFUJI Hideaki / =?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?= , , , , , Subject: Re: [PATCH] Prefix List patch against 2.5.70 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 2833 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev On Mon, 2 Jun 2003, David Stevens wrote: > The users of prefix list data don't know the prefix or the prefix > length; they know the interface index, and need to get the prefixes. > > The data is fundamentally per-interface, and the routing table is > per-destination. So, adding the prefixes to the routing table doesn't seem > like the best choice because everything that currently uses the routing > table will have to skip over these extra entries (which they'll never be > interested in) Umm.. every prefix should have an interface route, so they're a required subset of the routing table, correct? > and the users of the prefix data will have to skip over all > existing routing table entries (which they're never interested in). ... > Routes and prefixes are independent of each other, so throwing them in the > same table to me seems like it only creates work to skip entries that > aren't related, and because the users of the prefix data don't have the key > needed for a fast look-up in the routing table, prefix users in particular > have to skip through everything currently in the routing table, linearly, > with no benefit at all for being there. > > I also see no relation between prefix list data and the FIB; current users > are completely independent from prefix list users, and it appears to only > slow both of them down. The prefix data is always looked-up by interface > index, so I think it really belongs in the inet6 per-interface structure, > unless I'm missing something. What benefits are there for lumping this with > existing data structures that aren't per-interface, or keyed per-interface? > > +-DLS > > > YOSHIFUJI Hideaki / 吉藤英明 @vger.kernel.org on > 05/30/2003 07:02:49 PM > > Sent by: linux-net-owner@vger.kernel.org > > > To: krkumar@us.ltcfwd.linux.ibm.com > cc: davem@redhat.com, kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, > netdev@oss.sgi.com, linux-net@vger.kernel.org > Subject: Re: [PATCH] Prefix List patch against 2.5.70 > > > > In article <3ED80230.2030508@us.ibm.com> (at Fri, 30 May 2003 18:15:28 > -0700), Krishna Kumar says: > > > +/* prefix list returned to user space in this structure */ > > +struct plist_user_info { > ^ip6 or ipv6 or so. > > + char name[IFNAMSIZ]; /* interface name */ > ~~~~~~~~~~~~~~~~~~~duplicate information. > > + int ifindex; /* interface index */ > > + int nprefixes; /* number of elements in 'prefix' */ > > + struct var_plist_user_info { /* multiple elements */ > > + char flags[3]; /* router advertised flags */ > ~~~~~~~~this is not good interface. > > + int plen; /* prefix length */ > > + __u32 valid; /* valid lifetime */ > > + struct in6_addr ra_addr;/* advertising router */ > > + struct in6_addr prefix; /* prefix */ > > + } plist_vars[0]; > > +}; > > + > > extern void addrconf_init(void); > > extern void addrconf_cleanup(void); > > > > : > > I think we should use 1 fixed-length message per prefix, > instead of variable length message. > > > > + pinfo->plist_vars[count].plen = p_el->pinfo.prefix_len; > > + pinfo->plist_vars[count].valid = p_el->pinfo.valid - > > + (jiffies - p_el->timestamp)/HZ; > > + if ((p_el->ra_flags & (ND_RA_FLAG_MANAGED | > > + ND_RA_FLAG_OTHER)) > > + == (ND_RA_FLAG_MANAGED|ND_RA_FLAG_OTHER)) > > + strcpy(pinfo->plist_vars[count].flags, "MO"); > > + else if (p_el->ra_flags & ND_RA_FLAG_MANAGED) > > + strcpy(pinfo->plist_vars[count].flags, "M"); > > + else if (p_el->ra_flags & ND_RA_FLAG_OTHER) > > + strcpy(pinfo->plist_vars[count].flags, "O"); > > + else > > + strcpy(pinfo->plist_vars[count].flags, "-"); > > + ipv6_addr_copy(&pinfo->plist_vars[count].ra_addr, > > + &p_el->ra_addr); > > + for (i = 0; i < 8; i++) > > + pinfo->plist_vars[count].ra_addr.s6_addr16[i] = > > + > __constant_ntohs(pinfo->plist_vars[count].ra_addr.s6_addr16[i]); > > + ipv6_addr_copy(&pinfo->plist_vars[count].prefix, > > + &p_el->pinfo.prefix); > > + for (i = 0; i < p_el->pinfo.prefix_len/16; i++) > > + pinfo->plist_vars[count].prefix.s6_addr16[i] = > > + > __constant_ntohs(pinfo->plist_vars[count].prefix.s6_addr16[i]); > > Absoletely nasty. > - don't use charaters to represent flags; use real flags. > - use network-byte order. > > > > +static int prefix_list_proc_dump(char *buffer, char **start, off_t > offset, > > + int length) > > +{ > : > > Please use seq_file. > > > Again, what I proposed was to store prefix information on fib with > some flags to represent advertised by routers and give user-space > the RA information using new rtattr (RTA_RA6INFO or something like that). > > struct rta_ra6info { > u32 rta_ra6flags; > }; > > -- > Hideaki YOSHIFUJI @ USAGI Project > GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA > > > - > To unsubscribe from this list: send the line "unsubscribe linux-net" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > - > To unsubscribe from this list: send the line "unsubscribe linux-net" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From davem@redhat.com Mon Jun 2 21:52:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 21:52:18 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h534qE2x019507 for ; Mon, 2 Jun 2003 21:52:15 -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 VAA26095; Mon, 2 Jun 2003 21:49:41 -0700 Date: Mon, 02 Jun 2003 21:49:41 -0700 (PDT) Message-Id: <20030602.214941.102551312.davem@redhat.com> To: pekkas@netcore.fi Cc: dlstevens@us.ibm.com, yoshfuji@linux-ipv6.org, krkumar@us.ibm.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: [PATCH] Prefix List patch against 2.5.70 From: "David S. Miller" In-Reply-To: References: X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2834 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: Pekka Savola Date: Tue, 3 Jun 2003 07:48:13 +0300 (EEST) Umm.. every prefix should have an interface route, so they're a required subset of the routing table, correct? That's entirely correct, thanks for noticing this :-) This is why I said that they could add to a global list all routes that meet this criteria. Thus making any querying mechanism simple to implement. From vnuorval@tcs.hut.fi Mon Jun 2 23:41:59 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 23:42:09 -0700 (PDT) Received: from saturn.tcs.hut.fi (root@saturn.tcs.hut.fi [130.233.215.2]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h536fv2x023287 for ; Mon, 2 Jun 2003 23:41:58 -0700 Received: from rhea.tcs.hut.fi (really [130.233.215.147]) by tcs.hut.fi via smail with esmtp id (Debian Smail3.2.0.102) for ; Tue, 3 Jun 2003 09:35:54 +0300 (EEST) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-5) with ESMTP id h536ZqjH019079; Tue, 3 Jun 2003 09:35:52 +0300 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-5) with ESMTP id h536ZjF1019075; Tue, 3 Jun 2003 09:35:46 +0300 Date: Tue, 3 Jun 2003 09:35:45 +0300 (EEST) From: Ville Nuorvala To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: davem@redhat.com, , , , , , Subject: Re: [patch]: CONFIG_IPV6_SUBTREES fix for MIPv6 In-Reply-To: <20030531.000319.114704530.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-15 X-archive-position: 2836 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev On Sat, 31 May 2003, YOSHIFUJI Hideaki / [iso-2022-jp] 吉藤英明 wrote: > Let us test the patch. It seemed buggy when USAGI tested before. Any feedback would have been (and still is) of course welcome. The bugs are much easier to locate and fix if people report about them :-) -Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From dlstevens@us.ibm.com Mon Jun 2 23:43:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Jun 2003 23:43:29 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h536hP2x023608 for ; Mon, 2 Jun 2003 23:43:25 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h536gXuT188876; Tue, 3 Jun 2003 02:42:33 -0400 Received: from d03nm121.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h536gWba166304; Tue, 3 Jun 2003 00:42:33 -0600 Importance: Normal Sensitivity: Subject: Re: [PATCH] Prefix List patch against 2.5.70 To: Pekka Savola Cc: YOSHIFUJI Hideaki / =?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?= , krkumar@us.ibm.com, , , , X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: David Stevens Date: Tue, 3 Jun 2003 00:42:25 -0600 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.1 [IBM]|April 28, 2003) at 06/03/2003 00:42:32 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-archive-position: 2837 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev >Umm.. every prefix should have an interface route, so they're a required >subset of the routing table, correct? I'm not sure that it has to be, except if you make that the only way to access prefix list information. :-) Administrators and routing daemons are free to mess with the routing table in creative ways (aggregating, creating static routes to enforce some policy, whatever), but when the routing table holds more than just routing information, either those routes can't be messed with, or the prefix information is lost. And that's more relevant when not using address autoconfiguration. The prefix list information that's relevant is the prefix, the prefix length and the M and O bits, as they were in the router advertisement. For routing purposes, it wouldn't be a problem to aggregate interface routes that cover a contiguous portion of the address space, but doing that would lose the prefix information if the routing table is your only source. So, routing daemons would have to check a funky flag and leave prefix-list-relevant routes alone. M and O bits are per-interface; they have no relevance at all in the routing table, but they'd all have to be updated if they changed. There is an example already where routes are installed for per-interface information: local addresses. There are host routes corresponding to local addresses in the routing table now, but there is also a list of local addresses associated with the interface. Is that a bad idea? Certainly, it's possible to flag all of the host routes that are for local addresses (really, just check for interface loopback) and search the entire routing table when trying to answer the question "what addresses are on this interface," but it's much better to have that address list associated directly with the interface (especially for source selection). The consumers of prefix list (DHCPv6 and mobile IPv6) need the entire prefix list, length and M&O bits for a given interface. The prefixes (the key) aren't known for the search, and no other interfaces or destination routes are ever interesting for those consumers. The interface routes can be deleted, forced to something else, or modified now without losing any information, because they are only relevant for packet routing. If the prefix information is divined from the routing table, the interface routes suddenly contain more than routing information, and should then have special restrictions on them that other routes don't have (they should be immutable). I don't think that's a good idea, when you can hang the prefix list right off the interface and return the full list whenever you need it. The interface routes can be overridden or aggregated without messing at all with the prefix list information. That seems pretty simple to me. +-DLS From etsh_cucu@yahoo.com Tue Jun 3 00:57:42 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 Jun 2003 00:57:46 -0700 (PDT) Received: from web14305.mail.yahoo.com (web14305.mail.yahoo.com [216.136.173.81]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h537vg2x025791 for ; Tue, 3 Jun 2003 00:57:42 -0700 Message-ID: <20030603075742.34434.qmail@web14305.mail.yahoo.com> Received: from [213.158.161.140] by web14305.mail.yahoo.com via HTTP; Tue, 03 Jun 2003 00:57:42 PDT Date: Tue, 3 Jun 2003 00:57:42 -0700 (PDT) From: Hisham Kotry Subject: Re: netlink tester program To: david-b@pacbell.net Cc: rddunlap@osdl.org, linux-net@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <20030602.203834.115933659.davem@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 2838 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: etsh_cucu@yahoo.com Precedence: bulk X-list: netdev --- "David S. Miller" wrote: > There is even an official IETF RFC written by Jamal, > Alexey, and > others documenting netlink btw :-)))))))))))) > > Did anybody notice this? It was defenitly a nice read, but the netlink2 draft is somewhat inconsistent, it mentions reducing the 32-bit length field to 16-bits and equally distributing the remaining 16-bits between the new version and extended flags fields, but the draft makes no further refrence to the version field. Infact the netlink2 message header diagram on page 16, as well as the pseudo message on page 28, show a 16-bits extended flags field with no version field in the header. So this is probably one of those cases in wich specs aren't clear enough and code usually has the final word in such situations. I mailed Jamal about this a while ago but never got a reply back. BTW, is netlink2 support planned for linux in the near future? David, sorry for the private mail, but it was unintentional as I (by mistake) pressed reply instead of reply all. Chaow, kotry __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com From hch@lst.de Tue Jun 3 01:23:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 Jun 2003 01:23:43 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [212.34.189.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h538NT2x028700 for ; Tue, 3 Jun 2003 01:23:31 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h538NRJT022960 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 3 Jun 2003 10:23:27 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.3) id h538NQ0w022958 for netdev@oss.sgi.com; Tue, 3 Jun 2003 10:23:26 +0200 Date: Tue, 3 Jun 2003 10:23:26 +0200 From: Christoph Hellwig To: netdev@oss.sgi.com Subject: [PATCH] move dmascc away from setup.c Message-ID: <20030603082326.GA22946@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Spam-Score: -3 () PATCH_UNIFIED_DIFF,USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) X-archive-position: 2839 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: netdev Yeah, it's a isa driver but it already was in the setup.c pci probes list. Also use SET_MODULE_OWNER instead of MOD_{INC,DEC}_USE_COUNT. --- 1.15/drivers/net/setup.c Thu May 29 11:57:13 2003 +++ edited/drivers/net/setup.c Mon Jun 2 12:16:07 2003 @@ -9,8 +9,6 @@ #include #include -extern int dmascc_init(void); - extern int scc_enet_init(void); extern int fec_enet_init(void); @@ -29,10 +27,6 @@ /* * Early setup devices */ - -#if defined(CONFIG_DMASCC) - {dmascc_init, 0}, -#endif #if defined(CONFIG_SCC_ENET) {scc_enet_init, 0}, #endif --- 1.15/drivers/net/hamradio/dmascc.c Fri May 30 08:50:31 2003 +++ edited/drivers/net/hamradio/dmascc.c Mon Jun 2 12:31:48 2003 @@ -250,8 +250,6 @@ /* Function declarations */ - -int dmascc_init(void) __init; static int setup_adapter(int card_base, int type, int n) __init; static void write_scc(struct scc_priv *priv, int reg, int val); @@ -299,23 +297,12 @@ static unsigned long rand; -/* Module functions */ - -#ifdef MODULE - - MODULE_AUTHOR("Klaus Kudielka"); MODULE_DESCRIPTION("Driver for high-speed SCC boards"); MODULE_PARM(io, "1-" __MODULE_STRING(MAX_NUM_DEVS) "i"); MODULE_LICENSE("GPL"); - -int init_module(void) { - return dmascc_init(); -} - - -void cleanup_module(void) { +static void __exit dmascc_exit(void) { int i; struct scc_info *info; @@ -341,24 +328,16 @@ } } - -#else - - +#ifndef MODULE void __init dmascc_setup(char *str, int *ints) { int i; for (i = 0; i < MAX_NUM_DEVS && i < ints[0]; i++) io[i] = ints[i+1]; } - - #endif - -/* Initialization functions */ - -int __init dmascc_init(void) { +static int __init dmascc_init(void) { int h, i, j, n; int base[MAX_NUM_DEVS], tcmd[MAX_NUM_DEVS], t0[MAX_NUM_DEVS], t1[MAX_NUM_DEVS]; @@ -461,6 +440,9 @@ return -EIO; } +module_init(dmascc_init); +module_exit(dmascc_exit); + int __init setup_adapter(int card_base, int type, int n) { int i, irq, chip; @@ -580,6 +562,7 @@ if (sizeof(dev->name) == sizeof(char *)) dev->name = priv->name; #endif sprintf(dev->name, "dmascc%i", 2*n+i); + SET_MODULE_OWNER(dev); dev->base_addr = card_base; dev->irq = irq; dev->open = scc_open; @@ -707,12 +690,9 @@ struct scc_info *info = priv->info; int card_base = priv->card_base; - MOD_INC_USE_COUNT; - /* Request IRQ if not already used by other channel */ if (!info->irq_used) { if (request_irq(dev->irq, scc_isr, 0, "dmascc", info)) { - MOD_DEC_USE_COUNT; return -EAGAIN; } } @@ -722,7 +702,6 @@ if (priv->param.dma >= 0) { if (request_dma(priv->param.dma, "dmascc")) { if (--info->irq_used == 0) free_irq(dev->irq, info); - MOD_DEC_USE_COUNT; return -EAGAIN; } else { unsigned long flags = claim_dma_lock(); @@ -866,7 +845,6 @@ } if (--info->irq_used == 0) free_irq(dev->irq, info); - MOD_DEC_USE_COUNT; return 0; } From aj@dungeon.inka.de Tue Jun 3 02:10:08 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 Jun 2003 02:10:14 -0700 (PDT) Received: from mail.inka.de (mail@quechua.inka.de [193.197.184.2]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h539A72x032064 for ; Tue, 3 Jun 2003 02:10:08 -0700 Received: from dungeon.inka.de (uucp@[127.0.0.1]) by mail.inka.de with uucp (rmailwrap 0.5) id 19N7nx-0002K9-00; Tue, 03 Jun 2003 11:10:05 +0200 Received: from 192.168.1.12 (unknown [192.168.1.12]) by dungeon.inka.de (Postfix) with ESMTP id 9D90820FAD; Tue, 3 Jun 2003 10:11:10 +0200 (CEST) From: Andreas Jellinghaus To: Peter Bieringer , Maillist netdev Subject: Re: Is there already a doc available for the new IPsec code? Date: Tue, 3 Jun 2003 10:13:02 +0200 User-Agent: KMail/1.5.2 Cc: Maillist USAGI-users References: <36990000.1054588328@worker.muc.bieringer.de> In-Reply-To: <36990000.1054588328@worker.muc.bieringer.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200306031013.02982.aj@dungeon.inka.de> X-archive-position: 2840 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: aj@dungeon.inka.de Precedence: bulk X-list: netdev I will send him my notes (too large for this list). except for the kernel config, the netbsd ipsec howto is a very good source. Andreas From bunk@fs.tum.de Tue Jun 3 06:03:39 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 Jun 2003 06:03:44 -0700 (PDT) Received: from hermes.fachschaften.tu-muenchen.de (hermes.fachschaften.tu-muenchen.de [129.187.202.12]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h53D3H2x009171 for ; Tue, 3 Jun 2003 06:03:39 -0700 Received: (qmail 3223 invoked from network); 3 Jun 2003 13:03:10 -0000 Received: from mimas.fachschaften.tu-muenchen.de (129.187.202.58) by hermes.fachschaften.tu-muenchen.de with QMQP; 3 Jun 2003 13:03:10 -0000 Date: Tue, 3 Jun 2003 15:03:08 +0200 From: Adrian Bunk To: Margit Schubert-While , lksctp-developers@lists.sourceforge.net Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: SCTP config 2.5.70(-bk) Message-ID: <20030603130308.GC27168@fs.tum.de> References: <5.1.0.14.2.20030602094232.00aeda18@pop.t-online.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20030602094232.00aeda18@pop.t-online.de> User-Agent: Mutt/1.4.1i X-archive-position: 2841 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@fs.tum.de Precedence: bulk X-list: netdev On Mon, Jun 02, 2003 at 09:53:04AM +0200, Margit Schubert-While wrote: > CONFIG_IPV6_SCTP__ is always being set to "y" even though > not selected (CONFIG_IPV6 not set) First, this doesn't do any harm since CONFIG_IPV6_SCTP__ alone doensn't result in anything getting compiled. But besides, it seems a bit broken. From net/sctp/Kconfig: <-- snip --> ... config IPV6_SCTP__ tristate default y if IPV6=n default IPV6 if IPV6 config IP_SCTP tristate "The SCTP Protocol (EXPERIMENTAL)" depends on IPV6_SCTP__ ... <-- snip --> Semantically equivalent is the following for IPV6_SCTP__: config IPV6_SCTP__ tristate default y if IPV6=n || IPV6=y default m if IPV6=m If it was intended to disallow a static IP_SCTP with a modular IPV6 it doesn't work: It's perfectly allowed to set IPV6=n and IP_SCTP=y and later compile and install a modular IPV6 for the same kernel. Could someone from the SCTP developers comment on the intentions behind IPV6_SCTP__ ? > Margit cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From gandalf@wlug.westbo.se Tue Jun 3 10:41:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 Jun 2003 10:41:29 -0700 (PDT) Received: from tux.rsn.bth.se (postfix@tux.rsn.bth.se [194.47.143.135]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h53HfE2x016462 for ; Tue, 3 Jun 2003 10:41:17 -0700 Received: by tux.rsn.bth.se (Postfix, from userid 501) id A13E036FED; Tue, 3 Jun 2003 19:41:11 +0200 (CEST) Subject: Re: fix TCP roundtrip time update code From: Martin Josefsson To: davidm@hpl.hp.com Cc: kuznet@ms2.inr.ac.ru, linux-kernel@vger.kernel.org, linux-ia64@linuxia64.org, netdev@oss.sgi.com In-Reply-To: <200306031552.h53FqknC023999@napali.hpl.hp.com> References: <200306031552.h53FqknC023999@napali.hpl.hp.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1054662070.701.6.camel@tux.rsn.bth.se> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 03 Jun 2003 19:41:11 +0200 X-archive-position: 2842 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gandalf@wlug.westbo.se Precedence: bulk X-list: netdev (trimmed CC line and added netdev) On Tue, 2003-06-03 at 17:52, David Mosberger wrote: > One of those very-hard-to-track-down, trivial-to-fix kind of problems: > without this patch, TCP roundtrip time measurements will corrupt the > routing cache's RTT estimates under heavy network load (the bug causes > RTAX_RTT to go negative, but since its type is u32, you end up with a > huge positive value...). From there on, later TCP connections quickly > will go south. > > The typo was introduced 8 months ago in v1.29 of the file by the patch > entitled "Cleanup DST metrics and abstrct MSS/PMTU further". I tested this patch and it looks like it has cured my mysterious TCP stalls. without patch: cache mtu 1500 rtt 479411ms rttvar 953813ms cwnd 46 advmss 1460 I see that before and during the stall if not using this patch. (rtt is never above 20ms accoring to ping) With the patch I see normal rtt and rttvar times. Havn't seen a stall yet (~30 kernelcompiles with distcc over a sometimes congested link), will continue testing. > ===== net/ipv4/tcp_input.c 1.36 vs edited ===== > --- 1.36/net/ipv4/tcp_input.c Mon Apr 28 09:27:57 2003 > +++ edited/net/ipv4/tcp_input.c Tue Jun 3 08:19:36 2003 > @@ -556,8 +556,8 @@ > if (m >= dst_metric(dst, RTAX_RTTVAR)) > dst->metrics[RTAX_RTTVAR-1] = m; > else > - dst->metrics[RTAX_RTT-1] -= > - (dst->metrics[RTAX_RTT-1] - m)>>2; > + dst->metrics[RTAX_RTTVAR-1] -= > + (dst->metrics[RTAX_RTTVAR-1] - m)>>2; > } > > if (tp->snd_ssthresh >= 0xFFFF) { -- /Martin From garzik@gtf.org Tue Jun 3 10:59:43 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 Jun 2003 10:59:48 -0700 (PDT) Received: from havoc.gtf.org (host-64-213-145-173.atlantasolutions.com [64.213.145.173] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h53HxM2x017048 for ; Tue, 3 Jun 2003 10:59:43 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id 983EF6641; Tue, 3 Jun 2003 13:59:21 -0400 (EDT) Date: Tue, 3 Jun 2003 13:59:21 -0400 From: Jeff Garzik To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Regarding SET_NETDEV_DEV Message-ID: <20030603175921.GE2079@gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-archive-position: 2843 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev For janitors and other developers placing this in net drivers... please don't :) This can be done in upper layers, accomplishing the same goal without changing the low-level net driver code at all. Jeff From davidm@napali.hpl.hp.com Tue Jun 3 11:45:47 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 Jun 2003 11:45:51 -0700 (PDT) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h53IjQ2x018031 for ; Tue, 3 Jun 2003 11:45:47 -0700 Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) by palrel12.hp.com (Postfix) with ESMTP id 434C41C011B1; Tue, 3 Jun 2003 11:45:26 -0700 (PDT) Received: from napali.hpl.hp.com (napali.hpl.hp.com [15.4.89.123]) by hplms2.hpl.hp.com (8.12.9/8.12.9/HPL-PA Hub) with ESMTP id h53IjOxV004188; Tue, 3 Jun 2003 11:45:25 -0700 (PDT) Received: from napali.hpl.hp.com (localhost [127.0.0.1]) by napali.hpl.hp.com (8.12.3/8.12.3/Debian-5) with ESMTP id h53IjOrK025527; Tue, 3 Jun 2003 11:45:24 -0700 Received: (from davidm@localhost) by napali.hpl.hp.com (8.12.3/8.12.3/Debian-5) id h53IjOlS025523; Tue, 3 Jun 2003 11:45:24 -0700 From: David Mosberger MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16092.60612.352739.581639@napali.hpl.hp.com> Date: Tue, 3 Jun 2003 11:45:24 -0700 To: Martin Josefsson Cc: davidm@hpl.hp.com, kuznet@ms2.inr.ac.ru, linux-kernel@vger.kernel.org, linux-ia64@linuxia64.org, netdev@oss.sgi.com Subject: Re: fix TCP roundtrip time update code In-Reply-To: <1054662070.701.6.camel@tux.rsn.bth.se> References: <200306031552.h53FqknC023999@napali.hpl.hp.com> <1054662070.701.6.camel@tux.rsn.bth.se> X-Mailer: VM 7.07 under Emacs 21.2.1 Reply-To: davidm@hpl.hp.com X-URL: http://www.hpl.hp.com/personal/David_Mosberger/ X-archive-position: 2844 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davidm@napali.hpl.hp.com Precedence: bulk X-list: netdev >>>>> On 03 Jun 2003 19:41:11 +0200, Martin Josefsson said: Martin> (trimmed CC line and added netdev) On Tue, 2003-06-03 at Martin> 17:52, David Mosberger wrote: >> One of those very-hard-to-track-down, trivial-to-fix kind of >> problems: without this patch, TCP roundtrip time measurements >> will corrupt the routing cache's RTT estimates under heavy >> network load (the bug causes RTAX_RTT to go negative, but since >> its type is u32, you end up with a huge positive value...). From >> there on, later TCP connections quickly will go south. >> The typo was introduced 8 months ago in v1.29 of the file by the >> patch entitled "Cleanup DST metrics and abstrct MSS/PMTU >> further". Martin> I tested this patch and it looks like it has cured my Martin> mysterious TCP stalls. Yes, this sounds reasonable. I wasn't very clear on this point, but "by going south" I meant that TCP is starting to misbehave. In particular, you'll likely end up with the kernel aborting ESTABLISHED TCP connections with extreme prejudice (and in violation of the TCP protocol), because it thought that it had been unable to communicate with the remote end for a _very_ long time. The net effect typically is that you end up with one end having a connection that's in the ESTABLISHED state and the other end having no trace of that connection. --david From scott.feldman@intel.com Tue Jun 3 13:01:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 Jun 2003 13:01:57 -0700 (PDT) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h53K1X2x023590 for ; Tue, 3 Jun 2003 13:01:54 -0700 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h53JrfA01302 for ; Tue, 3 Jun 2003 19:53:41 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h53JssK05729 for ; Tue, 3 Jun 2003 19:54:54 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003060313013015442 ; Tue, 03 Jun 2003 13:01:30 -0700 Received: from orsmsx402.amr.corp.intel.com ([192.168.65.208]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Jun 2003 13:01:30 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [PATCH] fix use after free in e100 Date: Tue, 3 Jun 2003 13:01:29 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] fix use after free in e100 Thread-Index: AcMokjx3yixGSrs6TK+86kV3QlMsXwBeFFag From: "Feldman, Scott" To: "Martin Josefsson" Cc: X-OriginalArrivalTime: 03 Jun 2003 20:01:30.0686 (UTC) FILETIME=[ECC4B5E0:01C32A0A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h53K1X2x023590 X-archive-position: 2845 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev > Here's a fix for a use-after-free in the e100 driver. > You can't touch the skb after a call to netif_rx(), it might > have been free'd. Caught with Manfred's unmap-page-debugging > patch in -mm. Thanks Martin. We'll pick this patch up in our dev driver and propagate the change from there. -scott From jgrimm2@us.ibm.com Tue Jun 3 14:09:30 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 Jun 2003 14:09:39 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h53L8v2x025658 for ; Tue, 3 Jun 2003 14:09:30 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h53L6AuT258362; Tue, 3 Jun 2003 17:06:10 -0400 Received: from austin.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h53L66h7148720; Tue, 3 Jun 2003 15:06:07 -0600 Received: from popmail.austin.ibm.com (popmail.austin.ibm.com [9.41.248.164]) by austin.ibm.com (8.12.9/8.12.9) with ESMTP id h53L65sQ056046; Tue, 3 Jun 2003 16:06:05 -0500 Received: from us.ibm.com (sig-9-65-53-56.mts.ibm.com [9.65.53.56]) by popmail.austin.ibm.com (AIX4.3/8.9.3p2/8.7-client1.01) with ESMTP id QAA20796; Tue, 3 Jun 2003 16:06:04 -0500 Message-ID: <3EDD0DFC.4080806@us.ibm.com> Date: Tue, 03 Jun 2003 16:07:08 -0500 From: Jon Grimm Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Bunk CC: Margit Schubert-While , lksctp-developers@lists.sourceforge.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [Lksctp-developers] Re: SCTP config 2.5.70(-bk) References: <5.1.0.14.2.20030602094232.00a