From vnuorval@tcs.hut.fi Fri Aug 1 04:15:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 04:15:42 -0700 (PDT) Received: from mail.tcs.hut.fi (mail.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71BFPFl004394 for ; Fri, 1 Aug 2003 04:15:26 -0700 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by mail.tcs.hut.fi (Postfix) with ESMTP id 61FB38001D1; Fri, 1 Aug 2003 14:15:23 +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 h71BFN5L016559; Fri, 1 Aug 2003 14:15:23 +0300 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-5) with ESMTP id h71BFLaU016555; Fri, 1 Aug 2003 14:15:22 +0300 Date: Fri, 1 Aug 2003 14:15:21 +0300 (EEST) From: Ville Nuorvala To: yoshfuji@linux-ipv6.org, Cc: netdev@oss.sgi.com Subject: [PATCH] IPV6: Incorrect hoplimit in ip6_push_pending_frames() In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4419 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Hi, I noticed the hop limit passed to ip6_append_data() isn't used by ip6_push_pending_frames(), which might lead to unexpected behavior with multicast and (ipv6-in-ipv6) tunneled packets. This patch (against Linux 2.6.0-test2 and cset 1.1595) fixes the problem. Thanks, Ville diff -Nur linux-2.5.OLD/include/linux/ipv6.h linux-2.5/include/linux/ipv6.h --- linux-2.5.OLD/include/linux/ipv6.h Thu Jul 31 18:07:13 2003 +++ linux-2.5/include/linux/ipv6.h Wed Jul 30 15:53:12 2003 @@ -189,6 +189,7 @@ struct ipv6_txoptions *opt; struct rt6_info *rt; struct flowi *fl; + int hop_limit; } cork; }; diff -Nur linux-2.5.OLD/net/ipv6/ip6_output.c linux-2.5/net/ipv6/ip6_output.c --- linux-2.5.OLD/net/ipv6/ip6_output.c Thu Jul 31 18:07:30 2003 +++ linux-2.5/net/ipv6/ip6_output.c Wed Jul 30 22:11:51 2003 @@ -1243,6 +1243,7 @@ dst_hold(&rt->u.dst); np->cork.rt = rt; np->cork.fl = fl; + np->cork.hop_limit = hlimit; inet->cork.fragsize = mtu = dst_pmtu(&rt->u.dst); inet->cork.length = 0; inet->sndmsg_page = NULL; @@ -1465,7 +1466,7 @@ hdr->payload_len = htons(skb->len - sizeof(struct ipv6hdr)); else hdr->payload_len = 0; - hdr->hop_limit = np->hop_limit; + hdr->hop_limit = np->cork.hop_limit; hdr->nexthdr = proto; ipv6_addr_copy(&hdr->saddr, &fl->fl6_src); ipv6_addr_copy(&hdr->daddr, final_dst); -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From chas@locutus.cmf.nrl.navy.mil Fri Aug 1 07:02:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 07:02:26 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71E2CFn021118 for ; Fri, 1 Aug 2003 07:02:13 -0700 Received: from locutus.cmf.nrl.navy.mil (locutus.cmf.nrl.navy.mil [134.207.10.66]) by ginger.cmf.nrl.navy.mil (8.12.7/8.12.7) with ESMTP id h6THHosG027846; Tue, 29 Jul 2003 13:17:51 -0400 (EDT) Message-Id: <200307291717.h6THHosG027846@ginger.cmf.nrl.navy.mil> To: Mitchell Blank Jr cc: davem@redhat.com, netdev@oss.sgi.com Reply-To: chas3@users.sourceforge.net Subject: Re: [atmdrvr zatm] Remove obsolete EXACT_TS support In-reply-to: Your message of "Mon, 28 Jul 2003 00:13:23 PDT." <20030728071323.GT32831@gaz.sfgoth.com> Date: Tue, 29 Jul 2003 13:15:09 -0400 From: chas williams X-Spam-Score: () hits=-2.9 X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 4420 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev dave, please apply the following patch (hopefully one will arrive shortly that removes cli() et al from zatm as well): In message <20030728071323.GT32831@gaz.sfgoth.com>,Mitchell Blank Jr writes: >Chas - here's another 2.6 atm driver patch. Please push it upstream. > >This removes the obsolete "exact timestamp" support from the zatm driver. >My understanding is that it was part of a research thing Werner did 8 or >so years ago. It has no purpose for any production use. I think 2.6 is >its time to die. > >Besides, these days we use do_gettimeofday() instead of xtime so we should >have a reasonably accurate timestamp anyways. > >The only program that uses the ZATM_GETTHIST ioctl is the src/debug/znth.c >from the userland distribution. This isn't even compiled as part of the >make process so I don't feel any guilt about breaking it. It should >probably also just go away. > >I don't have the hardware (and really doubt anyone else does either, but >that's another matter entirely) but it still compiles and insmod's. > >Patch is versus 2.6.0-test2. # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1596 -> 1.1597 # drivers/atm/zatm.c 1.12 -> 1.13 # drivers/atm/Kconfig 1.5 -> 1.6 # drivers/atm/zatm.h 1.1 -> 1.2 # include/linux/atm_zatm.h 1.1 -> 1.2 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 03/07/28 chas@relax.cmf.nrl.navy.mil 1.1597 # remove EXACT_TS remove from zatm (untested) # -------------------------------------------- # diff -Nru a/drivers/atm/Kconfig b/drivers/atm/Kconfig --- a/drivers/atm/Kconfig Tue Jul 29 13:15:41 2003 +++ b/drivers/atm/Kconfig Tue Jul 29 13:15:41 2003 @@ -164,18 +164,6 @@ Note that extended debugging may create certain race conditions itself. Enable this ONLY if you suspect problems with the driver. -config ATM_ZATM_EXACT_TS - bool "Enable usec resolution timestamps" - depends on ATM_ZATM && X86 - help - The uPD98401 SAR chip supports a high-resolution timer (approx. 30 - MHz) that is used for very accurate reception timestamps. Because - that timer overflows after 140 seconds, and also to avoid timer - drift, time measurements need to be periodically synchronized with - the normal system time. Enabling this feature will add some general - overhead for timer synchronization and also per-packet overhead for - time conversion. - # bool 'Rolfs TI TNETA1570' CONFIG_ATM_TNETA1570 y # if [ "$CONFIG_ATM_TNETA1570" = "y" ]; then # bool ' Enable extended debugging' CONFIG_ATM_TNETA1570_DEBUG n diff -Nru a/drivers/atm/zatm.c b/drivers/atm/zatm.c --- a/drivers/atm/zatm.c Tue Jul 29 13:15:41 2003 +++ b/drivers/atm/zatm.c Tue Jul 29 13:15:41 2003 @@ -52,13 +52,6 @@ #define DPRINTK(format,args...) #endif -#ifndef __i386__ -#ifdef CONFIG_ATM_ZATM_EXACT_TS -#warning Precise timestamping only available on i386 platform -#undef CONFIG_ATM_ZATM_EXACT_TS -#endif -#endif - #ifndef CONFIG_ATM_ZATM_DEBUG @@ -347,150 +340,6 @@ restore_flags(flags); } - -/*----------------------- high-precision timestamps -------------------------*/ - - -#ifdef CONFIG_ATM_ZATM_EXACT_TS - -static struct timer_list sync_timer; - - -/* - * Note: the exact time is not normalized, i.e. tv_usec can be > 1000000. - * This must be handled by higher layers. - */ - -static inline struct timeval exact_time(struct zatm_dev *zatm_dev,u32 ticks) -{ - struct timeval tmp; - - tmp = zatm_dev->last_time; - tmp.tv_usec += ((s64) (ticks-zatm_dev->last_clk)* - (s64) zatm_dev->factor) >> TIMER_SHIFT; - return tmp; -} - - -static void zatm_clock_sync(unsigned long dummy) -{ - struct atm_dev *atm_dev; - struct zatm_dev *zatm_dev; - - for (atm_dev = zatm_boards; atm_dev; atm_dev = zatm_dev->more) { - unsigned long flags,interval; - int diff; - struct timeval now,expected; - u32 ticks; - - zatm_dev = ZATM_DEV(atm_dev); - save_flags(flags); - cli(); - ticks = zpeekl(zatm_dev,uPD98401_TSR); - do_gettimeofday(&now); - restore_flags(flags); - expected = exact_time(zatm_dev,ticks); - diff = 1000000*(expected.tv_sec-now.tv_sec)+ - (expected.tv_usec-now.tv_usec); - zatm_dev->timer_history[zatm_dev->th_curr].real = now; - zatm_dev->timer_history[zatm_dev->th_curr].expected = expected; - zatm_dev->th_curr = (zatm_dev->th_curr+1) & - (ZATM_TIMER_HISTORY_SIZE-1); - interval = 1000000*(now.tv_sec-zatm_dev->last_real_time.tv_sec) - +(now.tv_usec-zatm_dev->last_real_time.tv_usec); - if (diff >= -ADJ_REP_THRES && diff <= ADJ_REP_THRES) - zatm_dev->timer_diffs = 0; - else -#ifndef AGGRESSIVE_DEBUGGING - if (++zatm_dev->timer_diffs >= ADJ_MSG_THRES) -#endif - { - zatm_dev->timer_diffs = 0; - printk(KERN_INFO DEV_LABEL ": TSR update after %ld us:" - " calculation differed by %d us\n",interval,diff); -#ifdef AGGRESSIVE_DEBUGGING - printk(KERN_DEBUG " %d.%08d -> %d.%08d (%lu)\n", - zatm_dev->last_real_time.tv_sec, - zatm_dev->last_real_time.tv_usec, - now.tv_sec,now.tv_usec,interval); - printk(KERN_DEBUG " %u -> %u (%d)\n", - zatm_dev->last_clk,ticks,ticks-zatm_dev->last_clk); - printk(KERN_DEBUG " factor %u\n",zatm_dev->factor); -#endif - } - if (diff < -ADJ_IGN_THRES || diff > ADJ_IGN_THRES) { - /* filter out any major changes (e.g. time zone setup and - such) */ - zatm_dev->last_time = now; - zatm_dev->factor = - (1000 << TIMER_SHIFT)/(zatm_dev->khz+1); - } - else { - zatm_dev->last_time = expected; - /* - * Is the accuracy of udelay really only about 1:300 on - * a 90 MHz Pentium ? Well, the following line avoids - * the problem, but ... - * - * What it does is simply: - * - * zatm_dev->factor = (interval << TIMER_SHIFT)/ - * (ticks-zatm_dev->last_clk); - */ -#define S(x) #x /* "stringification" ... */ -#define SX(x) S(x) - asm("movl %2,%%ebx\n\t" - "subl %3,%%ebx\n\t" - "xorl %%edx,%%edx\n\t" - "shldl $" SX(TIMER_SHIFT) ",%1,%%edx\n\t" - "shl $" SX(TIMER_SHIFT) ",%1\n\t" - "divl %%ebx\n\t" - : "=a" (zatm_dev->factor) - : "0" (interval-diff),"g" (ticks), - "g" (zatm_dev->last_clk) - : "ebx","edx","cc"); -#undef S -#undef SX -#ifdef AGGRESSIVE_DEBUGGING - printk(KERN_DEBUG " (%ld << %d)/(%u-%u) = %u\n", - interval,TIMER_SHIFT,ticks,zatm_dev->last_clk, - zatm_dev->factor); -#endif - } - zatm_dev->last_real_time = now; - zatm_dev->last_clk = ticks; - } - mod_timer(&sync_timer,sync_timer.expires+POLL_INTERVAL*HZ); -} - - -static void __init zatm_clock_init(struct zatm_dev *zatm_dev) -{ - static int start_timer = 1; - unsigned long flags; - - zatm_dev->factor = (1000 << TIMER_SHIFT)/(zatm_dev->khz+1); - zatm_dev->timer_diffs = 0; - memset(zatm_dev->timer_history,0,sizeof(zatm_dev->timer_history)); - zatm_dev->th_curr = 0; - save_flags(flags); - cli(); - do_gettimeofday(&zatm_dev->last_time); - zatm_dev->last_clk = zpeekl(zatm_dev,uPD98401_TSR); - if (start_timer) { - start_timer = 0; - init_timer(&sync_timer); - sync_timer.expires = jiffies+POLL_INTERVAL*HZ; - sync_timer.function = zatm_clock_sync; - add_timer(&sync_timer); - } - restore_flags(flags); -} - - -#endif - - /*----------------------------------- RX ------------------------------------*/ @@ -581,11 +430,7 @@ EVENT("error code 0x%x/0x%x\n",(here[3] & uPD98401_AAL5_ES) >> uPD98401_AAL5_ES_SHIFT,error); skb = ((struct rx_buffer_head *) bus_to_virt(here[2]))->skb; -#ifdef CONFIG_ATM_ZATM_EXACT_TS - skb->stamp = exact_time(zatm_dev,here[1]); -#else do_gettimeofday(&skb->stamp); -#endif #if 0 printk("[-3..0] 0x%08lx 0x%08lx 0x%08lx 0x%08lx\n",((unsigned *) skb->data)[-3], ((unsigned *) skb->data)[-2],((unsigned *) skb->data)[-1], @@ -1455,9 +1300,6 @@ "MHz\n",dev->number, (zin(VER) & uPD98401_MAJOR) >> uPD98401_MAJOR_SHIFT, zin(VER) & uPD98401_MINOR,zatm_dev->khz/1000,zatm_dev->khz % 1000); -#ifdef CONFIG_ATM_ZATM_EXACT_TS - zatm_clock_init(zatm_dev); -#endif return uPD98402_init(dev); } @@ -1699,22 +1541,6 @@ restore_flags(flags); return 0; } -#ifdef CONFIG_ATM_ZATM_EXACT_TS - case ZATM_GETTHIST: - { - int i; - struct zatm_t_hist hs[ZATM_TIMER_HISTORY_SIZE]; - save_flags(flags); - cli(); - for (i = 0; i < ZATM_TIMER_HISTORY_SIZE; i++) - hs[i] = zatm_dev->timer_history[ - (zatm_dev->th_curr+i) & - (ZATM_TIMER_HISTORY_SIZE-1)]; - restore_flags(flags); - return copy_to_user((struct zatm_t_hist *) arg, - hs, sizeof(hs)) ? -EFAULT : 0; - } -#endif default: if (!dev->phy->ioctl) return -ENOIOCTLCMD; return dev->phy->ioctl(dev,cmd,arg); diff -Nru a/drivers/atm/zatm.h b/drivers/atm/zatm.h --- a/drivers/atm/zatm.h Tue Jul 29 13:15:41 2003 +++ b/drivers/atm/zatm.h Tue Jul 29 13:15:41 2003 @@ -40,31 +40,6 @@ #define MBX_TX_0 2 #define MBX_TX_1 3 - -/* - * mkdep doesn't spot this dependency, but that's okay, because zatm.c uses - * CONFIG_ATM_ZATM_EXACT_TS too. - */ - -#ifdef CONFIG_ATM_ZATM_EXACT_TS -#define POLL_INTERVAL 60 /* TSR poll interval in seconds; must be <= - (2^31-1)/clock */ -#define TIMER_SHIFT 20 /* scale factor for fixed-point arithmetic; - 1 << TIMER_SHIFT must be - (1) <= (2^64-1)/(POLL_INTERVAL*clock), - (2) >> clock/10^6, and - (3) <= (2^32-1)/1000 */ -#define ADJ_IGN_THRES 1000000 /* don't adjust if we're off by more than that - many usecs - this filters clock corrections, - time zone changes, etc. */ -#define ADJ_REP_THRES 20000 /* report only differences of more than that - many usecs (don't mention single lost timer - ticks; 10 msec is only 0.03% anyway) */ -#define ADJ_MSG_THRES 5 /* issue complaints only if getting that many - significant timer differences in a row */ -#endif - - struct zatm_vcc { /*-------------------------------- RX part */ int rx_chan; /* RX channel, 0 if none */ @@ -103,17 +78,6 @@ u32 pool_base; /* Free buffer pool dsc (word addr) */ /*-------------------------------- ZATM links */ struct atm_dev *more; /* other ZATM devices */ -#ifdef CONFIG_ATM_ZATM_EXACT_TS - /*-------------------------------- timestamp calculation */ - u32 last_clk; /* results of last poll: clock, */ - struct timeval last_time; /* virtual time and */ - struct timeval last_real_time; /* real time */ - u32 factor; /* multiplication factor */ - int timer_diffs; /* number of significant deviations */ - struct zatm_t_hist timer_history[ZATM_TIMER_HISTORY_SIZE]; - /* record of timer synchronizations */ - int th_curr; /* current position */ -#endif /*-------------------------------- general information */ int mem; /* RAM on board (in bytes) */ int khz; /* timer clock */ diff -Nru a/include/linux/atm_zatm.h b/include/linux/atm_zatm.h --- a/include/linux/atm_zatm.h Tue Jul 29 13:15:41 2003 +++ b/include/linux/atm_zatm.h Tue Jul 29 13:15:41 2003 @@ -21,9 +21,6 @@ /* get statistics and zero */ #define ZATM_SETPOOL _IOW('a',ATMIOC_SARPRV+3,struct atmif_sioc) /* set pool parameters */ -#define ZATM_GETTHIST _IOW('a',ATMIOC_SARPRV+4,struct atmif_sioc) - /* get a history of timer - differences */ struct zatm_pool_info { int ref_count; /* free buffer pool usage counters */ From chas@locutus.cmf.nrl.navy.mil Fri Aug 1 07:02:13 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 07:02:26 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71E2CFl021118 for ; Fri, 1 Aug 2003 07:02:12 -0700 Received: from locutus.cmf.nrl.navy.mil (locutus.cmf.nrl.navy.mil [134.207.10.66]) by ginger.cmf.nrl.navy.mil (8.12.7/8.12.7) with ESMTP id h6VEQgsG023826; Thu, 31 Jul 2003 10:26:42 -0400 (EDT) Message-Id: <200307311426.h6VEQgsG023826@ginger.cmf.nrl.navy.mil> To: Mitchell Blank Jr cc: davem@redhat.com, netdev@oss.sgi.com Reply-To: chas3@users.sourceforge.net Subject: Re: [Linux-ATM-General] Re: [atmdrvr zatm] Remove obsolete EXACT_TS support In-reply-to: Your message of "Wed, 30 Jul 2003 15:57:42 PDT." <20030730225741.GA57991@gaz.sfgoth.com> Date: Thu, 31 Jul 2003 10:23:58 -0400 From: chas williams X-Spam-Score: () hits=-0.3 X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 4420 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev please apply to 2.6. zatm will now compile on smp. it might actually work if someone had some hardware to test it. [atm]: [zatm] convert cli() to spinlock # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1597 -> 1.1598 # drivers/atm/zatm.c 1.13 -> 1.14 # drivers/atm/uPD98402.c 1.4 -> 1.5 # drivers/atm/zatm.h 1.2 -> 1.3 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 03/07/31 chas@relax.cmf.nrl.navy.mil 1.1598 # [zatm] convert cli() to spinlock # -------------------------------------------- # diff -Nru a/drivers/atm/uPD98402.c b/drivers/atm/uPD98402.c --- a/drivers/atm/uPD98402.c Thu Jul 31 10:25:25 2003 +++ b/drivers/atm/uPD98402.c Thu Jul 31 10:25:25 2003 @@ -27,6 +27,7 @@ struct k_sonet_stats sonet_stats;/* link diagnostics */ unsigned char framing; /* SONET/SDH framing */ int loop_mode; /* loopback mode */ + spinlock_t lock; }; @@ -71,14 +72,13 @@ default: return -EINVAL; } - save_flags(flags); - cli(); + spin_lock_irqsave(&PRIV(dev)->lock, flags); PUT(set[0],C11T); PUT(set[1],C12T); PUT(set[2],C13T); PUT((GET(MDR) & ~uPD98402_MDR_SS_MASK) | (set[3] << uPD98402_MDR_SS_SHIFT),MDR); - restore_flags(flags); + spin_unlock_irqrestore(&PRIV(dev)->lock, flags); return 0; } @@ -88,12 +88,11 @@ unsigned long flags; unsigned char s[3]; - save_flags(flags); - cli(); + spin_lock_irqsave(&PRIV(dev)->lock, flags); s[0] = GET(C11R); s[1] = GET(C12R); s[2] = GET(C13R); - restore_flags(flags); + spin_unlock_irqrestore(&PRIV(dev)->lock, flags); return (put_user(s[0], arg) || put_user(s[1], arg+1) || put_user(s[2], arg+2) || put_user(0xff, arg+3) || put_user(0xff, arg+4) || put_user(0xff, arg+5)) ? -EFAULT : 0; @@ -214,6 +213,7 @@ DPRINTK("phy_start\n"); if (!(PRIV(dev) = kmalloc(sizeof(struct uPD98402_priv),GFP_KERNEL))) return -ENOMEM; + spin_lock_init(&PRIV(dev)->lock); memset(&PRIV(dev)->sonet_stats,0,sizeof(struct k_sonet_stats)); (void) GET(PCR); /* clear performance events */ PUT(uPD98402_PFM_FJ,PCMR); /* ignore frequency adj */ diff -Nru a/drivers/atm/zatm.c b/drivers/atm/zatm.c --- a/drivers/atm/zatm.c Thu Jul 31 10:25:25 2003 +++ b/drivers/atm/zatm.c Thu Jul 31 10:25:25 2003 @@ -195,11 +195,10 @@ sizeof(struct rx_buffer_head); } size += align; - save_flags(flags); - cli(); + spin_lock_irqsave(&zatm_dev->lock, flags); free = zpeekl(zatm_dev,zatm_dev->pool_base+2*pool) & uPD98401_RXFP_REMAIN; - restore_flags(flags); + spin_unlock_irqrestore(&zatm_dev->lock, flags); if (free >= zatm_dev->pool_info[pool].low_water) return; EVENT("starting ... POOL: 0x%x, 0x%x\n", zpeekl(zatm_dev,zatm_dev->pool_base+2*pool), @@ -228,22 +227,22 @@ head->skb = skb; EVENT("enq skb 0x%08lx/0x%08lx\n",(unsigned long) skb, (unsigned long) head); - cli(); + spin_lock_irqsave(&zatm_dev->lock, flags); if (zatm_dev->last_free[pool]) ((struct rx_buffer_head *) (zatm_dev->last_free[pool]-> data))[-1].link = virt_to_bus(head); zatm_dev->last_free[pool] = skb; skb_queue_tail(&zatm_dev->pool[pool],skb); - restore_flags(flags); + spin_unlock_irqrestore(&zatm_dev->lock, flags); free++; } if (first) { - cli(); + spin_lock_irqsave(&zatm_dev->lock, flags); zwait; zout(virt_to_bus(first),CER); zout(uPD98401_ADD_BAT | (pool << uPD98401_POOL_SHIFT) | count, CMR); - restore_flags(flags); + spin_unlock_irqrestore(&zatm_dev->lock, flags); EVENT ("POOL: 0x%x, 0x%x\n", zpeekl(zatm_dev,zatm_dev->pool_base+2*pool), zpeekl(zatm_dev,zatm_dev->pool_base+2*pool+1)); @@ -286,8 +285,7 @@ size = pool-ZATM_AAL5_POOL_BASE; if (size < 0) size = 0; /* 64B... */ else if (size > 10) size = 10; /* ... 64kB */ - save_flags(flags); - cli(); + spin_lock_irqsave(&zatm_dev->lock, flags); zpokel(zatm_dev,((zatm_dev->pool_info[pool].low_water/4) << uPD98401_RXFP_ALERT_SHIFT) | (1 << uPD98401_RXFP_BTSZ_SHIFT) | @@ -295,7 +293,7 @@ zatm_dev->pool_base+pool*2); zpokel(zatm_dev,(unsigned long) dummy,zatm_dev->pool_base+ pool*2+1); - restore_flags(flags); + spin_unlock_irqrestore(&zatm_dev->lock, flags); zatm_dev->last_free[pool] = NULL; refill_pool(dev,pool); } @@ -315,29 +313,29 @@ { struct zatm_pool_info *pool; unsigned long offset,flags; + struct zatm_dev *zatm_dev = ZATM_DEV(vcc->dev); DPRINTK("start 0x%08lx dest 0x%08lx len %d\n",start,dest,len); if (len < PAGE_SIZE) return; - pool = &ZATM_DEV(vcc->dev)->pool_info[ZATM_VCC(vcc)->pool]; + pool = &zatm_dev->pool_info[ZATM_VCC(vcc)->pool]; offset = (dest-start) & (PAGE_SIZE-1); - save_flags(flags); - cli(); + spin_lock_irqsave(&zatm_dev->lock, flags); if (!offset || pool->offset == offset) { pool->next_cnt = 0; - restore_flags(flags); + spin_unlock_irqrestore(&zatm_dev->lock, flags); return; } if (offset != pool->next_off) { pool->next_off = offset; pool->next_cnt = 0; - restore_flags(flags); + spin_unlock_irqrestore(&zatm_dev->lock, flags); return; } if (++pool->next_cnt >= pool->next_thres) { pool->offset = pool->next_off; pool->next_cnt = 0; } - restore_flags(flags); + spin_unlock_irqrestore(&zatm_dev->lock, flags); } /*----------------------------------- RX ------------------------------------*/ @@ -535,20 +533,19 @@ zatm_vcc->pool = ZATM_AAL0_POOL; } if (zatm_vcc->pool < 0) return -EMSGSIZE; - save_flags(flags); - cli(); + spin_lock_irqsave(&zatm_dev->lock, flags); zwait; zout(uPD98401_OPEN_CHAN,CMR); zwait; DPRINTK("0x%x 0x%x\n",zin(CMR),zin(CER)); chan = (zin(CMR) & uPD98401_CHAN_ADDR) >> uPD98401_CHAN_ADDR_SHIFT; - restore_flags(flags); + spin_unlock_irqrestore(&zatm_dev->lock, flags); DPRINTK("chan is %d\n",chan); if (!chan) return -EAGAIN; use_pool(vcc->dev,zatm_vcc->pool); DPRINTK("pool %d\n",zatm_vcc->pool); /* set up VC descriptor */ - cli(); + spin_lock_irqsave(&zatm_dev->lock, flags); zpokel(zatm_dev,zatm_vcc->pool << uPD98401_RXVC_POOL_SHIFT, chan*VC_SIZE/4); zpokel(zatm_dev,uPD98401_RXVC_OD | (vcc->qos.aal == ATM_AAL5 ? @@ -556,7 +553,7 @@ zpokel(zatm_dev,0,chan*VC_SIZE/4+2); zatm_vcc->rx_chan = chan; zatm_dev->rx_map[chan] = vcc; - restore_flags(flags); + spin_unlock_irqrestore(&zatm_dev->lock, flags); return 0; } @@ -572,14 +569,13 @@ zatm_dev = ZATM_DEV(vcc->dev); zatm_vcc = ZATM_VCC(vcc); if (!zatm_vcc->rx_chan) return 0; - save_flags(flags); - cli(); + spin_lock_irqsave(&zatm_dev->lock, flags); /* should also handle VPI @@@ */ pos = vcc->vci >> 1; shift = (1-(vcc->vci & 1)) << 4; zpokel(zatm_dev,(zpeekl(zatm_dev,pos) & ~(0xffff << shift)) | ((zatm_vcc->rx_chan | uPD98401_RXLT_ENBL) << shift),pos); - restore_flags(flags); + spin_unlock_irqrestore(&zatm_dev->lock, flags); return 0; } @@ -596,9 +592,8 @@ if (!zatm_vcc->rx_chan) return; DPRINTK("close_rx\n"); /* disable receiver */ - save_flags(flags); if (vcc->vpi != ATM_VPI_UNSPEC && vcc->vci != ATM_VCI_UNSPEC) { - cli(); + spin_lock_irqsave(&zatm_dev->lock, flags); pos = vcc->vci >> 1; shift = (1-(vcc->vci & 1)) << 4; zpokel(zatm_dev,zpeekl(zatm_dev,pos) & ~(0xffff << shift),pos); @@ -606,9 +601,9 @@ zout(uPD98401_NOP,CMR); zwait; zout(uPD98401_NOP,CMR); - restore_flags(flags); + spin_unlock_irqrestore(&zatm_dev->lock, flags); } - cli(); + spin_lock_irqsave(&zatm_dev->lock, flags); zwait; zout(uPD98401_DEACT_CHAN | uPD98401_CHAN_RT | (zatm_vcc->rx_chan << uPD98401_CHAN_ADDR_SHIFT),CMR); @@ -620,7 +615,7 @@ if (!(zin(CMR) & uPD98401_CHAN_ADDR)) printk(KERN_CRIT DEV_LABEL "(itf %d): can't close RX channel " "%d\n",vcc->dev->number,zatm_vcc->rx_chan); - restore_flags(flags); + spin_unlock_irqrestore(&zatm_dev->lock, flags); zatm_dev->rx_map[zatm_vcc->rx_chan] = NULL; zatm_vcc->rx_chan = 0; unuse_pool(vcc->dev,zatm_vcc->pool); @@ -673,11 +668,10 @@ zatm_dev = ZATM_DEV(vcc->dev); zatm_vcc = ZATM_VCC(vcc); EVENT("iovcnt=%d\n",skb_shinfo(skb)->nr_frags,0); - save_flags(flags); - cli(); + spin_lock_irqsave(&zatm_dev->lock, flags); if (!skb_shinfo(skb)->nr_frags) { if (zatm_vcc->txing == RING_ENTRIES-1) { - restore_flags(flags); + spin_unlock_irqrestore(&zatm_dev->lock, flags); return RING_BUSY; } zatm_vcc->txing++; @@ -732,7 +726,7 @@ zwait; zout(uPD98401_TX_READY | (zatm_vcc->tx_chan << uPD98401_CHAN_ADDR_SHIFT),CMR); - restore_flags(flags); + spin_unlock_irqrestore(&zatm_dev->lock, flags); EVENT("done\n",0,0); return 0; } @@ -866,15 +860,14 @@ if (zatm_dev->tx_bw < *pcr) return -EAGAIN; zatm_dev->tx_bw -= *pcr; } - save_flags(flags); - cli(); + spin_lock_irqsave(&zatm_dev->lock, flags); DPRINTK("i = %d, m = %d, PCR = %d\n",i,m,*pcr); zpokel(zatm_dev,(i << uPD98401_IM_I_SHIFT) | m,uPD98401_IM(shaper)); zpokel(zatm_dev,c << uPD98401_PC_C_SHIFT,uPD98401_PC(shaper)); zpokel(zatm_dev,0,uPD98401_X(shaper)); zpokel(zatm_dev,0,uPD98401_Y(shaper)); zpokel(zatm_dev,uPD98401_PS_E,uPD98401_PS(shaper)); - restore_flags(flags); + spin_unlock_irqrestore(&zatm_dev->lock, flags); return shaper; } @@ -889,11 +882,10 @@ if (--zatm_dev->ubr_ref_cnt) return; zatm_dev->ubr = -1; } - save_flags(flags); - cli(); + spin_lock_irqsave(&zatm_dev->lock, flags); zpokel(zatm_dev,zpeekl(zatm_dev,uPD98401_PS(shaper)) & ~uPD98401_PS_E, uPD98401_PS(shaper)); - restore_flags(flags); + spin_unlock_irqrestore(&zatm_dev->lock, flags); zatm_dev->free_shapers |= 1 << shaper; } @@ -912,8 +904,6 @@ chan = zatm_vcc->tx_chan; if (!chan) return; DPRINTK("close_tx\n"); - save_flags(flags); - cli(); while (skb_peek(&zatm_vcc->backlog)) { if (once) { printk("waiting for backlog to drain ...\n"); @@ -932,6 +922,7 @@ DPRINTK("waiting for TX queue to drain ... %p\n",skb); sleep_on(&zatm_vcc->tx_wait); } + spin_lock_irqsave(&zatm_dev->lock, flags); #if 0 zwait; zout(uPD98401_DEACT_CHAN | (chan << uPD98401_CHAN_ADDR_SHIFT),CMR); @@ -942,7 +933,7 @@ if (!(zin(CMR) & uPD98401_CHAN_ADDR)) printk(KERN_CRIT DEV_LABEL "(itf %d): can't close TX channel " "%d\n",vcc->dev->number,chan); - restore_flags(flags); + spin_unlock_irqrestore(&zatm_dev->lock, flags); zatm_vcc->tx_chan = 0; zatm_dev->tx_map[chan] = NULL; if (zatm_vcc->shaper != zatm_dev->ubr) { @@ -967,14 +958,13 @@ zatm_vcc = ZATM_VCC(vcc); zatm_vcc->tx_chan = 0; if (vcc->qos.txtp.traffic_class == ATM_NONE) return 0; - save_flags(flags); - cli(); + spin_lock_irqsave(&zatm_dev->lock, flags); zwait; zout(uPD98401_OPEN_CHAN,CMR); zwait; DPRINTK("0x%x 0x%x\n",zin(CMR),zin(CER)); chan = (zin(CMR) & uPD98401_CHAN_ADDR) >> uPD98401_CHAN_ADDR_SHIFT; - restore_flags(flags); + spin_unlock_irqrestore(&zatm_dev->lock, flags); DPRINTK("chan is %d\n",chan); if (!chan) return -EAGAIN; unlimited = vcc->qos.txtp.traffic_class == ATM_UBR && @@ -1022,15 +1012,14 @@ zatm_dev = ZATM_DEV(vcc->dev); zatm_vcc = ZATM_VCC(vcc); if (!zatm_vcc->tx_chan) return 0; - save_flags(flags); /* set up VC descriptor */ - cli(); + spin_lock_irqsave(&zatm_dev->lock, flags); zpokel(zatm_dev,0,zatm_vcc->tx_chan*VC_SIZE/4); zpokel(zatm_dev,uPD98401_TXVC_L | (zatm_vcc->shaper << uPD98401_TXVC_SHP_SHIFT) | (vcc->vpi << uPD98401_TXVC_VPI_SHIFT) | vcc->vci,zatm_vcc->tx_chan*VC_SIZE/4+1); zpokel(zatm_dev,0,zatm_vcc->tx_chan*VC_SIZE/4+2); - restore_flags(flags); + spin_unlock_irqrestore(&zatm_dev->lock, flags); zatm_dev->tx_map[zatm_vcc->tx_chan] = vcc; return 0; } @@ -1236,6 +1225,7 @@ DPRINTK(">zatm_init\n"); zatm_dev = ZATM_DEV(dev); + spin_lock_init(&zatm_dev->lock); pci_dev = zatm_dev->pci_dev; zatm_dev->base = pci_resource_start(pci_dev, 0); zatm_dev->irq = pci_dev->irq; @@ -1285,14 +1275,13 @@ do { unsigned long flags; - save_flags(flags); - cli(); + spin_lock_irqsave(&zatm_dev->lock, flags); t0 = zpeekl(zatm_dev,uPD98401_TSR); udelay(10); t1 = zpeekl(zatm_dev,uPD98401_TSR); udelay(1010); t2 = zpeekl(zatm_dev,uPD98401_TSR); - restore_flags(flags); + spin_unlock_irqrestore(&zatm_dev->lock, flags); } while (t0 > t1 || t1 > t2); /* loop if wrapping ... */ zatm_dev->khz = t2-2*t1+t0; @@ -1492,14 +1481,13 @@ return -EFAULT; if (pool < 0 || pool > ZATM_LAST_POOL) return -EINVAL; - save_flags(flags); - cli(); + spin_lock_irqsave(&zatm_dev->lock, flags); info = zatm_dev->pool_info[pool]; if (cmd == ZATM_GETPOOLZ) { zatm_dev->pool_info[pool].rqa_count = 0; zatm_dev->pool_info[pool].rqu_count = 0; } - restore_flags(flags); + spin_unlock_irqrestore(&zatm_dev->lock, flags); return copy_to_user( &((struct zatm_pool_req *) arg)->info, &info,sizeof(info)) ? -EFAULT : 0; @@ -1530,15 +1518,14 @@ if (info.low_water >= info.high_water || info.low_water < 0) return -EINVAL; - save_flags(flags); - cli(); + spin_lock_irqsave(&zatm_dev->lock, flags); zatm_dev->pool_info[pool].low_water = info.low_water; zatm_dev->pool_info[pool].high_water = info.high_water; zatm_dev->pool_info[pool].next_thres = info.next_thres; - restore_flags(flags); + spin_unlock_irqrestore(&zatm_dev->lock, flags); return 0; } default: diff -Nru a/drivers/atm/zatm.h b/drivers/atm/zatm.h --- a/drivers/atm/zatm.h Thu Jul 31 10:25:25 2003 +++ b/drivers/atm/zatm.h Thu Jul 31 10:25:25 2003 @@ -85,6 +85,7 @@ unsigned char irq; /* IRQ */ unsigned int base; /* IO base address */ struct pci_dev *pci_dev; /* PCI stuff */ + spinlock_t lock; }; From willy@www.linux.org.uk Fri Aug 1 08:02:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 08:02:45 -0700 (PDT) Received: from www.linux.org.uk (IDENT:zD29xXS/6K4bSxwPbxUDl3tjJbe2uGQJ@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71F2XFl030278 for ; Fri, 1 Aug 2003 08:02:35 -0700 Received: from willy by www.linux.org.uk with local (Exim 4.14) id 19ibQO-0003NL-OB for netdev@oss.sgi.com; Fri, 01 Aug 2003 16:02:32 +0100 Date: Fri, 1 Aug 2003 16:02:32 +0100 From: Matthew Wilcox To: netdev@oss.sgi.com Subject: [PATCH] ethtool_ops rev 4 Message-ID: <20030801150232.GV22222@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 4421 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@debian.org Precedence: bulk X-list: netdev At 55k, I doubt you want to see it posted to the list; patch is available from http://ftp.linux.org.uk/pub/linux/willy/patches/ethtool4.diff and here's the diffstat drivers/net/8139too.c | 330 ++++++++-------------- drivers/net/tg3.c | 584 ++++++++++++++++------------------------ include/linux/ethtool.h | 100 ++++++ include/linux/netdevice.h | 5 net/core/Makefile | 4 net/core/dev.c | 16 - net/core/ethtool.c | 671 ++++++++++++++++++++++++++++++++++++++++++++++ 7 files changed, 1154 insertions(+), 556 deletions(-) Patch has received light testing on an rtl8139c card: Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 32 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: d Current message level: 0xffffffff (-1) Link detected: yes but obviously it doesn't support all the ethtool options that some cards do. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From garzik@gtf.org Fri Aug 1 08:40:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 08:40:34 -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 h71FeSFl027853 for ; Fri, 1 Aug 2003 08:40:29 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id D82626698; Fri, 1 Aug 2003 11:40:21 -0400 (EDT) Date: Fri, 1 Aug 2003 11:40:21 -0400 From: Jeff Garzik To: Matthew Wilcox Cc: netdev@oss.sgi.com Subject: Re: [PATCH] ethtool_ops rev 4 Message-ID: <20030801154021.GA7696@gtf.org> References: <20030801150232.GV22222@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030801150232.GV22222@parcelfarce.linux.theplanet.co.uk> User-Agent: Mutt/1.3.28i X-archive-position: 4422 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev On Fri, Aug 01, 2003 at 04:02:32PM +0100, Matthew Wilcox wrote: > and here's the diffstat > > drivers/net/8139too.c | 330 ++++++++-------------- > drivers/net/tg3.c | 584 ++++++++++++++++------------------------ > include/linux/ethtool.h | 100 ++++++ > include/linux/netdevice.h | 5 > net/core/Makefile | 4 > net/core/dev.c | 16 - > net/core/ethtool.c | 671 ++++++++++++++++++++++++++++++++++++++++++++++ > 7 files changed, 1154 insertions(+), 556 deletions(-) Comments: * need SET_ETHTOOL_OPS macro or HAVE_ETHTOOL_OPS test macro or similar * I still do not see the need to change a simple storage of a constant (into ethtool_gdrvinfo) into _four_ separate function call hooks (reg dump len, eeprom dump len, nic-specific stats len, self-test len). Internal kernel code that needs this information is always a slow path anyway, so just call the ->get_drvinfo hook internally. * I prefer not to add '#include ' to ethtool.h Other than those, looks real good. Jeff From jmorris@intercode.com.au Fri Aug 1 08:51:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 08:51:20 -0700 (PDT) Received: from blackbird.intercode.com.au (IDENT:TamECck9nHItRCfvPti5PCOPYy+eE6V7@blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71FpEFl029615 for ; Fri, 1 Aug 2003 08:51:16 -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 h71Fowr27206; Sat, 2 Aug 2003 01:50:58 +1000 Date: Sat, 2 Aug 2003 01:50:57 +1000 (EST) From: James Morris To: Zwane Mwaikambo cc: netdev@oss.sgi.com Subject: Re: oops in raw_rcv_skb In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4423 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@intercode.com.au Precedence: bulk X-list: netdev On Fri, 1 Aug 2003, Zwane Mwaikambo wrote: > You can reproduce this one easily by doing 5-6 ping -f of a system on the > network (not loopback), originally picked up at http://bugme.osdl.org/show_bug.cgi?id=937 Any chance of getting a gdb traceback on this one? :-) - James -- James Morris From garzik@gtf.org Fri Aug 1 09:25:42 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 09:25: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 h71GPfFl001543 for ; Fri, 1 Aug 2003 09:25:42 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id 6EBE76696; Fri, 1 Aug 2003 12:25:36 -0400 (EDT) Date: Fri, 1 Aug 2003 12:25:36 -0400 From: Jeff Garzik To: Matthew Wilcox Cc: netdev@oss.sgi.com Subject: Re: [PATCH] ethtool_ops rev 4 Message-ID: <20030801162536.GA18574@gtf.org> References: <20030801150232.GV22222@parcelfarce.linux.theplanet.co.uk> <20030801154021.GA7696@gtf.org> <20030801154656.GW22222@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030801154656.GW22222@parcelfarce.linux.theplanet.co.uk> User-Agent: Mutt/1.3.28i X-archive-position: 4424 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev On Fri, Aug 01, 2003 at 04:46:56PM +0100, Matthew Wilcox wrote: > On Fri, Aug 01, 2003 at 11:40:21AM -0400, Jeff Garzik wrote: > > Comments: > > > > * need SET_ETHTOOL_OPS macro or HAVE_ETHTOOL_OPS test macro or similar > > DaveM disagreed with that... It's standard netdevice.h practice, and, he didn't disagree w/ my rebuttal. It is needed. > > * I still do not see the need to change a simple storage of a constant > > (into ethtool_gdrvinfo) into _four_ separate function call hooks (reg > > dump len, eeprom dump len, nic-specific stats len, self-test len). > > Internal kernel code that needs this information is always a slow path > > anyway, so just call the ->get_drvinfo hook internally. > > slow path, sure, but increased stack usage. it's a tradeoff, and this way > feels more clean to me. Additing a function hook each time you want to retrieve a new integer value? That's feels overly excessive to me. > > * I prefer not to add '#include ' to ethtool.h > > That means that any code which includes ethtool.h has to include types.h > first (either implicitly or explicitly). The rule so far has been that > header files should call out their dependencies explictly with an include > of the appropriate file. So why *don't* you want it? Because I copy it to userspace :) Jeff From zwane@arm.linux.org.uk Fri Aug 1 09:26:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 09:26:30 -0700 (PDT) Received: from hemi.commfireservices.com ([66.212.224.118]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71GQMFl002069 for ; Fri, 1 Aug 2003 09:26:23 -0700 Received: from montezuma.mastecende.com (cuda.commfireservices.com [24.202.53.9]) by hemi.commfireservices.com (Postfix) with ESMTP id 0AB23BC54; Fri, 1 Aug 2003 12:15:16 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by montezuma.mastecende.com (8.12.8/8.12.8) with ESMTP id h71GEftE031939; Fri, 1 Aug 2003 12:14:42 -0400 Date: Fri, 1 Aug 2003 12:14:41 -0400 (EDT) From: Zwane Mwaikambo X-X-Sender: zwane@montezuma.mastecende.com To: James Morris Cc: netdev@oss.sgi.com Subject: Re: oops in raw_rcv_skb In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4425 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zwane@arm.linux.org.uk Precedence: bulk X-list: netdev On Sat, 2 Aug 2003, James Morris wrote: > On Fri, 1 Aug 2003, Zwane Mwaikambo wrote: > > > You can reproduce this one easily by doing 5-6 ping -f of a system on the > > network (not loopback), originally picked up at http://bugme.osdl.org/show_bug.cgi?id=937 > > Any chance of getting a gdb traceback on this one? :-) Here is a new oops with the corresponding code. 2.6.0-test2-mm2 (gdb) list *raw_rcv_skb+0x1b5 0xc04e2235 is in raw_rcv_skb (sock.h:942). 937 938 skb->dev = NULL; 939 skb_set_owner_r(skb, sk); 940 skb_queue_tail(&sk->sk_receive_queue, skb); 941 if (!sock_flag(sk, SOCK_DEAD)) 942 sk->sk_data_ready(sk, skb->len); 943 out: 944 return err; 945 } Unable to handle kernel paging request at virtual address c3148068 printing eip: c04e2235 *pde = 0000d067 Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC CPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00010246 EIP is at raw_rcv_skb+0x1b5/0x270 eax: 00000000 ebx: 00000104 ecx: 00000104 edx: 00000001 esi: c7fae004 edi: 00000000 ebp: c3148004 esp: cbf4fecc ds: 007b es: 007b ss: 0068 Process ksoftirqd/0 (pid: 3, threadinfo=cbf4e000 task=cbf81000) Stack: c7fae06c cbf4e000 00000206 00000000 c3148000 0000005a c3148004 c96e7024 c7fae004 cab51004 c04e237c c7fae004 c3148004 00000020 c7fae004 c96e7024 c04e1ead c7fae004 c3148004 00000001 ca214004 cab51004 0a00a8c0 c04bd389 Call Trace: [] raw_rcv+0x8c/0xe0 [] raw_v4_input+0xbd/0x150 [] ip_local_deliver+0xc9/0x270 [] ip_rcv+0x37c/0x4e0 [] netif_receive_skb+0x153/0x1d0 [] process_backlog+0x87/0x160 [] net_rx_action+0x84/0x160 [] do_softirq+0xd3/0xe0 [] ksoftirqd+0xbc/0x100 [] ksoftirqd+0x0/0x100 [] kernel_thread_helper+0x5/0x10 Code: 43 86 56 68 ff 74 24 08 9d 8b 54 24 04 8b 5a 14 4b 89 5a 14 8b 42 08 83 e0 08 <0>Kernel panic: Fatal exception in interrupt In interrupt handler - not syncing -- function.linuxpower.ca From zwane@arm.linux.org.uk Fri Aug 1 09:29:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 09:29:57 -0700 (PDT) Received: from hemi.commfireservices.com ([66.212.224.118]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71GTrFl002789 for ; Fri, 1 Aug 2003 09:29:53 -0700 Received: from montezuma.mastecende.com (cuda.commfireservices.com [24.202.53.9]) by hemi.commfireservices.com (Postfix) with ESMTP id 38570BC56; Fri, 1 Aug 2003 12:18:47 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by montezuma.mastecende.com (8.12.8/8.12.8) with ESMTP id h71GIDtE031957; Fri, 1 Aug 2003 12:18:13 -0400 Date: Fri, 1 Aug 2003 12:18:13 -0400 (EDT) From: Zwane Mwaikambo X-X-Sender: zwane@montezuma.mastecende.com To: James Morris Cc: netdev@oss.sgi.com Subject: Re: oops in raw_rcv_skb In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4426 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zwane@arm.linux.org.uk Precedence: bulk X-list: netdev On Fri, 1 Aug 2003, Zwane Mwaikambo wrote: > Here is a new oops with the corresponding code. 2.6.0-test2-mm2 > > (gdb) list *raw_rcv_skb+0x1b5 > 0xc04e2235 is in raw_rcv_skb (sock.h:942). > 937 > 938 skb->dev = NULL; > 939 skb_set_owner_r(skb, sk); > 940 skb_queue_tail(&sk->sk_receive_queue, skb); > 941 if (!sock_flag(sk, SOCK_DEAD)) > 942 sk->sk_data_ready(sk, skb->len); > 943 out: > 944 return err; > 945 } seems to be the same bug as the previous one i posted. From nebuchadnezzar@nerim.net Fri Aug 1 10:53:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 10:53:43 -0700 (PDT) Received: from cerbere (nebuchadnezzar.net1.nerim.net [213.41.153.130]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71HrVFl009240 for ; Fri, 1 Aug 2003 10:53:35 -0700 Received: from [2001:7a8:5982:1:209:5bff:fe1c:f0b8] (helo=zion.matrix) by cerbere with esmtp (Exim 4.20) id 19ie5k-0000Lz-JF for netdev@oss.sgi.com; Fri, 01 Aug 2003 19:53:24 +0200 Received: from localhost ([::1] helo=zion.nerim.net) by zion.matrix with esmtp (Exim 4.20) id 19ie5k-0007tc-0j for netdev@oss.sgi.com; Fri, 01 Aug 2003 19:53:24 +0200 To: netdev@oss.sgi.com Subject: [PATCH] 2.4.x USAGI mipv6_ha_ipsec From: "Daniel 'NebuchadnezzaR' Dehennin" Organisation: CaLviX Date: Fri, 01 Aug 2003 19:53:23 +0200 Message-ID: <87n0etgt7w.fsf@zion.matrix> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4427 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nebuchadnezzar@nerim.net Precedence: bulk X-list: netdev Hello, My 2.4.21 with USAGI 20030801 don't build /net/ipv6/mobile_ip6/mipv6_ha_ipsec.c : mipv6_ha_ipsec.c: In function `mipv6_change_sa_index': mipv6_ha_ipsec.c:118: warning: implicit declaration of function `in6_ntop' mipv6_ha_ipsec.c:118: warning: format argument is not a pointer (arg 4) mipv6_ha_ipsec.c:119: warning: format argument is not a pointer (arg 4) mipv6_ha_ipsec.c:126: warning: format argument is not a pointer (arg 4) mipv6_ha_ipsec.c:127: warning: format argument is not a pointer (arg 4) [...] I search for the definition of in6_ntop, it in include/linux/inet.h so I make that patch. Thanks. --- linux-2.4.21/net/ipv6/mobile_ip6/mipv6_ha_ipsec.c.orig 2003-08-01 19:37:22.000000000 +0200 +++ linux-2.4.21/net/ipv6/mobile_ip6/mipv6_ha_ipsec.c 2003-08-01 19:03:42.000000000 +0200 @@ -62,6 +62,7 @@ #include #include #include +#include #include #include #include -- Daniel 'NebuchadnezzaR' Dehennin From nebuchadnezzar@nerim.net Fri Aug 1 11:09:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 11:09:36 -0700 (PDT) Received: from cerbere (nebuchadnezzar.net1.nerim.net [213.41.153.130]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71I9VFl010664 for ; Fri, 1 Aug 2003 11:09:32 -0700 Received: from zion.matrix ([2001:7a8:5982:1:209:5bff:fe1c:f0b8]) by cerbere with esmtp (Exim 4.20) id 19ieLF-0000M2-NW for netdev@oss.sgi.com; Fri, 01 Aug 2003 20:09:25 +0200 Received: from localhost ([::1] helo=zion.nerim.net) by zion.matrix with esmtp (Exim 4.20) id 19ieLF-0007xu-Db for netdev@oss.sgi.com; Fri, 01 Aug 2003 20:09:25 +0200 To: Linux Networking List Subject: [PATCH 2] 2.4.x USAGI unused variables in mipv6_ha_ipsec.c From: "Daniel 'NebuchadnezzaR' Dehennin" Organisation: CaLviX Date: Fri, 01 Aug 2003 20:09:25 +0200 Message-ID: <87fzklgsh6.fsf@zion.matrix> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4428 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nebuchadnezzar@nerim.net Precedence: bulk X-list: netdev Hello again ;-), A patch to remove unused variables : mipv6_ha_ipsec.c: In function `__mipv6_mn_change_tunnel_ipsec_by_proto': mipv6_ha_ipsec.c:216: warning: unused variable `ret' mipv6_ha_ipsec.c: In function `__mipv6_ha_change_tunnel_ipsec_by_proto': mipv6_ha_ipsec.c:338: warning: unused variable `ret' See you. --- linux-2.4.21/net/ipv6/mobile_ip6/mipv6_ha_ipsec.c.orig 2003-08-01 20:06:15.000000000 +0200 +++ linux-2.4.21/net/ipv6/mobile_ip6/mipv6_ha_ipsec.c 2003-08-01 20:06:42.000000000 +0200 @@ -213,7 +213,6 @@ int __mipv6_mn_change_tunnel_ipsec_by_pr struct in6_addr dst; struct in6_addr src; struct in6_addr *coa = &entry->coa; - int ret = 0; /* * Phase 1: Change the following SA/SPD @@ -335,7 +334,6 @@ int __mipv6_ha_change_tunnel_ipsec_by_pr struct in6_addr dst; struct in6_addr src; struct in6_addr *coa = &entry->coa; - int ret = 0; /* * Phase 1: Change the following SA/SPD -- Daniel 'NebuchadnezzaR' Dehennin From willy@www.linux.org.uk Fri Aug 1 12:17:11 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 12:17:20 -0700 (PDT) Received: from www.linux.org.uk (IDENT:dWRqvOFfILtpyOjLUmme1m8+W8uXBtM7@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71JH9Fl005257 for ; Fri, 1 Aug 2003 12:17:10 -0700 Received: from willy by www.linux.org.uk with local (Exim 4.14) id 19ic7M-0004BK-Kb; Fri, 01 Aug 2003 16:46:56 +0100 Date: Fri, 1 Aug 2003 16:46:56 +0100 From: Matthew Wilcox To: Jeff Garzik Cc: Matthew Wilcox , netdev@oss.sgi.com Subject: Re: [PATCH] ethtool_ops rev 4 Message-ID: <20030801154656.GW22222@parcelfarce.linux.theplanet.co.uk> References: <20030801150232.GV22222@parcelfarce.linux.theplanet.co.uk> <20030801154021.GA7696@gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030801154021.GA7696@gtf.org> User-Agent: Mutt/1.4.1i X-archive-position: 4429 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@debian.org Precedence: bulk X-list: netdev On Fri, Aug 01, 2003 at 11:40:21AM -0400, Jeff Garzik wrote: > Comments: > > * need SET_ETHTOOL_OPS macro or HAVE_ETHTOOL_OPS test macro or similar DaveM disagreed with that... > * I still do not see the need to change a simple storage of a constant > (into ethtool_gdrvinfo) into _four_ separate function call hooks (reg > dump len, eeprom dump len, nic-specific stats len, self-test len). > Internal kernel code that needs this information is always a slow path > anyway, so just call the ->get_drvinfo hook internally. slow path, sure, but increased stack usage. it's a tradeoff, and this way feels more clean to me. > * I prefer not to add '#include ' to ethtool.h That means that any code which includes ethtool.h has to include types.h first (either implicitly or explicitly). The rule so far has been that header files should call out their dependencies explictly with an include of the appropriate file. So why *don't* you want it? -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From garzik@gtf.org Fri Aug 1 12:44:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 12:44:38 -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 h71JiRFl006741 for ; Fri, 1 Aug 2003 12:44:28 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id 458486698; Fri, 1 Aug 2003 15:44:22 -0400 (EDT) Date: Fri, 1 Aug 2003 15:44:20 -0400 From: Jeff Garzik To: torvalds@osdl.org Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [BK PATCHES] 2.6.x net driver merges Message-ID: <20030801194420.GD3571@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: 4430 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Linus, please do a bk pull bk://gkernel.bkbits.net/net-drivers-2.5 Others may download the patch from ftp://ftp.??.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.0-test2-netdrvr1.patch.bz2 This will update the following files: Documentation/networking/bonding.txt | 343 ++++++++++++++++++++++++----------- Documentation/networking/ifenslave.c | 3 drivers/net/arcnet/com20020-isa.c | 2 drivers/net/tokenring/ibmtr.c | 3 drivers/net/wireless/airo.c | 104 +++++++--- 5 files changed, 309 insertions(+), 146 deletions(-) through these ChangeSets: (03/08/01 1.1547.8.10) Cset exclude: jgarzik@redhat.com|ChangeSet|20030731201437|53548 My fix was wrong, and, mainline now has a better fix. (03/07/31 1.1547.8.9) [tokenring ibmtr_cs] fix build, due to missing ibmtr.c build Note: Better fix is needed. Contributed by Mike Phillips. (03/07/31 1.1547.8.8) [arcnet com20020-isa] fix build broken by lack of ->owner (03/07/31 1.1547.8.7) [netdrvr bonding] fix ifenslave build on ia64 Forward port from 2.4. (03/07/31 1.1547.8.6) [netdrvr bonding] update docs (03/07/29 1.1547.8.5) [wireless airo] adds support for noise level reporting (if available) (03/07/29 1.1547.8.4) [wireless airo] makes the card passive when entering monitor mode (03/07/29 1.1547.8.3) [wireless airo] eliminate infinite loop makes sure a possible (never happened, but just in case) infinite loop in the transmission code terminates. (03/07/29 1.1547.8.2) [wireless airo] safer shutdown sequence changes the card shutdown sequence to a safer one (03/07/29 1.1547.8.1) [wireless airo] fix Tx race From davem@redhat.com Fri Aug 1 13:24:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 13:24:39 -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 h71KOUFl008291 for ; Fri, 1 Aug 2003 13:24:31 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id NAA07798; Fri, 1 Aug 2003 13:20:37 -0700 Date: Fri, 1 Aug 2003 13:20:37 -0700 From: "David S. Miller" To: Jeff Garzik Cc: willy@debian.org, netdev@oss.sgi.com Subject: Re: [PATCH] ethtool_ops rev 4 Message-Id: <20030801132037.3f3542ae.davem@redhat.com> In-Reply-To: <20030801162536.GA18574@gtf.org> References: <20030801150232.GV22222@parcelfarce.linux.theplanet.co.uk> <20030801154021.GA7696@gtf.org> <20030801154656.GW22222@parcelfarce.linux.theplanet.co.uk> <20030801162536.GA18574@gtf.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4431 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 1 Aug 2003 12:25:36 -0400 Jeff Garzik wrote: > On Fri, Aug 01, 2003 at 04:46:56PM +0100, Matthew Wilcox wrote: > > On Fri, Aug 01, 2003 at 11:40:21AM -0400, Jeff Garzik wrote: > > > Comments: > > > > > > * need SET_ETHTOOL_OPS macro or HAVE_ETHTOOL_OPS test macro or similar > > > > DaveM disagreed with that... > > It's standard netdevice.h practice, and, he didn't disagree w/ my > rebuttal. > > It is needed. Absolutely not, it makes no sense whatsoever to have this. Jeff, stop and think. The whole _POINT_ of these ops are to avoid duplicated code. If someone is absolutely adament about supporting kernels without ops support they should not support it at all. The point is to avoid code duplication, but what you suggest can only be used to keep the duplicated code around "just in case". This makes exactly no sense at all, it severs only to defeat the whole purpose of the change in the first place. I totally am against making an ifdef test available for this, it can only result in illogical things being done by driver maintainers. From jgarzik@pobox.com Fri Aug 1 15:35:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 15:35:49 -0700 (PDT) Received: from www.linux.org.uk (IDENT:rg5SenHWUdrUH12rD8TwSji2gubj2u02@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71MZiFl015583 for ; Fri, 1 Aug 2003 15:35:44 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19iiUw-0000tp-Gp; Fri, 01 Aug 2003 23:35:42 +0100 Message-ID: <3F2AEB33.9050506@pobox.com> Date: Fri, 01 Aug 2003 18:35:31 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: willy@debian.org, netdev@oss.sgi.com Subject: Re: [PATCH] ethtool_ops rev 4 References: <20030801150232.GV22222@parcelfarce.linux.theplanet.co.uk> <20030801154021.GA7696@gtf.org> <20030801154656.GW22222@parcelfarce.linux.theplanet.co.uk> <20030801162536.GA18574@gtf.org> <20030801132037.3f3542ae.davem@redhat.com> <3F2AE91D.5090705@pobox.com> In-Reply-To: <3F2AE91D.5090705@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4432 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Jeff Garzik wrote: > It's an explicit goal to avoid changing the driver API in such a way > that there is a remotely sane path to supporting older kernels. I, of course, meant the exact opposite here :) We want to provide a sane, ifdef-free path to kcompat, where feasible. From davem@redhat.com Fri Aug 1 15:36:55 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 15:37:00 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71MatFl015832 for ; Fri, 1 Aug 2003 15:36:55 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id PAA08138; Fri, 1 Aug 2003 15:32:55 -0700 Date: Fri, 1 Aug 2003 15:32:55 -0700 From: "David S. Miller" To: Jeff Garzik Cc: willy@debian.org, netdev@oss.sgi.com Subject: Re: [PATCH] ethtool_ops rev 4 Message-Id: <20030801153255.204baf66.davem@redhat.com> In-Reply-To: <3F2AE91D.5090705@pobox.com> References: <20030801150232.GV22222@parcelfarce.linux.theplanet.co.uk> <20030801154021.GA7696@gtf.org> <20030801154656.GW22222@parcelfarce.linux.theplanet.co.uk> <20030801162536.GA18574@gtf.org> <20030801132037.3f3542ae.davem@redhat.com> <3F2AE91D.5090705@pobox.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4433 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 01 Aug 2003 18:26:37 -0400 Jeff Garzik wrote: > Strangely enough, creating a SET_ETHTOOL_OPS() macro (or > netif_ethtool_ops or pick your name) reduces ifdefs. And then we'll have all of these functions present in the driver, unused, and we'll get tons of warning from gcc. The duplication of code is still there, and this is the main point. > I feel that I've helped shepherd the net driver and PCI APIs to maintain > something fairly interesting: It's not interesting in this case. > It's an explicit goal to avoid changing the driver API in such a way > that there is a remotely sane path to supporting older kernels. This enhancement we're talking about basically has no value unless you accept an appearance of breakage in this particular area. You can't get rid of the duplicated code without accepting that you will have seperate 2.6.x and 2.4.x strains of your driver. If you aren't willing to accept seperate strains of your driver, you simply don't use netdev_ops. It is the end of the conversation. > the few things that is not easily work-around-able is new additions to > existing structures (which wouldn't exist in older kernels). That's > what SET_ETHTOOL_OPS would wrap, while also providing a trigger for > generic compat glue. What gets rid of the static functions that do the work when SET_ETHTOOL_OPS() is a nop? I do not accept a scheme where the functions stay there in the driver anyways. All you seem to be talking about is a compat library which provides netdev_ops in library form or something silly like that. > This (IMO) feature continually saves me real time I don't argue that, just don't use netdev_ops in drivers you wish to keep doing this with :-) Look at drivers/net/acenic.c, that's similar to what your drivers will begin to look like if you don't start accepting a disconnect in certain areas. From davem@redhat.com Fri Aug 1 15:38:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 15:38:36 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71McWFl016352 for ; Fri, 1 Aug 2003 15:38:32 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id PAA08157; Fri, 1 Aug 2003 15:34:39 -0700 Date: Fri, 1 Aug 2003 15:34:39 -0700 From: "David S. Miller" To: Jeff Garzik Cc: willy@debian.org, netdev@oss.sgi.com Subject: Re: [PATCH] ethtool_ops rev 4 Message-Id: <20030801153439.4a324c36.davem@redhat.com> In-Reply-To: <3F2AEB33.9050506@pobox.com> References: <20030801150232.GV22222@parcelfarce.linux.theplanet.co.uk> <20030801154021.GA7696@gtf.org> <20030801154656.GW22222@parcelfarce.linux.theplanet.co.uk> <20030801162536.GA18574@gtf.org> <20030801132037.3f3542ae.davem@redhat.com> <3F2AE91D.5090705@pobox.com> <3F2AEB33.9050506@pobox.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4434 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 01 Aug 2003 18:35:31 -0400 Jeff Garzik wrote: > We want to provide a sane, ifdef-free path to kcompat, where feasible. I don't believe it's possible with netdev_ops, without undoing the entire purpose of what netdev_ops is trying to accomplish (elimination of code duplication). Show me, in code not words, how you are able to accomplish this with SET_NETDEV_OPS() or whatever. I will not read english text describing the scheme, I will read only code :) From greearb@candelatech.com Fri Aug 1 15:55:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 15:55:07 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-074.evrtwa1.dsl-verizon.net [4.33.45.74]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71Mt1Fl017421 for ; Fri, 1 Aug 2003 15:55:02 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h71Msttf013879 for ; Fri, 1 Aug 2003 15:54:56 -0700 Message-ID: <3F2AEFBF.3040604@candelatech.com> Date: Fri, 01 Aug 2003 15:54:55 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030718 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'netdev@oss.sgi.com'" Subject: 2.4.21: bug report for tg3: tx lockup when changing MTU Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4435 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev I just noticed that if you change the MTU of a tg3 NIC, it will not work untill you ifdown/ifup it. This problem is repeatable on tg3, and does not happen with the e1000 driver/cards. I am setting the MTU via an ioctl call, not via ifconfig or something like that. When the tg3 is locked up, I see this on the console: Aug 1 15:05:44 demo2 kernel: NETDEV WATCHDOG: eth5: transmit timed out Aug 1 15:05:44 demo2 kernel: tg3: eth5: transmit timed out, resetting Aug 1 15:05:44 demo2 kernel: tg3: tg3_stop_block timed out, ofs=2400 enable_bit=2 Aug 1 15:05:44 demo2 kernel: tg3: tg3_stop_block timed out, ofs=1400 enable_bit=2 Aug 1 15:05:44 demo2 kernel: tg3: tg3_stop_block timed out, ofs=c00 enable_bit=2 Aug 1 15:05:54 demo2 kernel: NETDEV WATCHDOG: eth5: transmit timed out Aug 1 15:05:54 demo2 kernel: tg3: eth5: transmit timed out, resetting Aug 1 15:05:54 demo2 kernel: tg3: tg3_stop_block timed out, ofs=2400 enable_bit=2 Aug 1 15:05:54 demo2 kernel: tg3: tg3_stop_block timed out, ofs=1400 enable_bit=2 ... Kernel is 2.4.21 + custom patches (which should not affect tg3). lspci says the NIC is: Altima AC9100 (rev 15) I will be happy to provide more information as needed. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From jgarzik@pobox.com Fri Aug 1 16:01:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 16:01:40 -0700 (PDT) Received: from www.linux.org.uk (IDENT:Zn4088h0c9junvtyMz48dB3BmWWWI3H8@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71N1YFl018056 for ; Fri, 1 Aug 2003 16:01:35 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19iitw-000162-PQ; Sat, 02 Aug 2003 00:01:32 +0100 Message-ID: <3F2AF141.2010308@pobox.com> Date: Fri, 01 Aug 2003 19:01:21 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: willy@debian.org, netdev@oss.sgi.com Subject: Re: [PATCH] ethtool_ops rev 4 References: <20030801150232.GV22222@parcelfarce.linux.theplanet.co.uk> <20030801154021.GA7696@gtf.org> <20030801154656.GW22222@parcelfarce.linux.theplanet.co.uk> <20030801162536.GA18574@gtf.org> <20030801132037.3f3542ae.davem@redhat.com> <3F2AE91D.5090705@pobox.com> <20030801153255.204baf66.davem@redhat.com> In-Reply-To: <20030801153255.204baf66.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4436 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev David S. Miller wrote: > On Fri, 01 Aug 2003 18:26:37 -0400 > Jeff Garzik wrote: > > >>Strangely enough, creating a SET_ETHTOOL_OPS() macro (or >>netif_ethtool_ops or pick your name) reduces ifdefs. > > > And then we'll have all of these functions present in > the driver, unused, and we'll get tons of warning from > gcc. > > The duplication of code is still there, and this is the > main point. Not correct: there is nothing unused, there are no warnings, in either the in-kernel case or the older-kernel case. Look at kcompat. That is code that is working, and producing the 2.4/2.6-ready vendor drivers I spoke of. I'm apparently not communicating the design that exists in kcompat, if you think this. The design is: code for 2.6, and it magically works in 2.4 It's a back-compat system that is so good you don't even know it's there. It's completely invisible to the mainline kernel -- as it should be -- presuming that one pays attention to subtle API change effects. Do you see yet how there is no code duplication, no ifdefs, no warnings about unused functions? That is the key point of the whole design, and key to the thread of discussion here. > You can't get rid of the duplicated code without accepting that you > will have seperate 2.6.x and 2.4.x strains of your driver. > > If you aren't willing to accept seperate strains of your driver, you > simply don't use netdev_ops. Look at kcompat. That is real, working code that demonstrates the approach. >>the few things that is not easily work-around-able is new additions to >>existing structures (which wouldn't exist in older kernels). That's >>what SET_ETHTOOL_OPS would wrap, while also providing a trigger for >>generic compat glue. > > > What gets rid of the static functions that do the work when > SET_ETHTOOL_OPS() is a nop? SET_ETHTOOL_OPS is never a no-op. The back-compat form of SET_ETHTOOL_OPS registers the ethtool_ops pointer in storage for later use. A DO_ETHTOOL_OPS macro in the driver's ->do_ioctl -- intentionally not included in the kernel -- does the rest, calling kcompat's backported net/core/ethtool.c, which in turn calls the ethtool_ops hooks in the driver. Making the kcompat'd net driver ready for 2.6 would then involve simply deleting one line. That's why there is no code duplication or unused driver code. Jeff From davem@redhat.com Fri Aug 1 16:05:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 16:05: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 h71N5XFl018589 for ; Fri, 1 Aug 2003 16:05:33 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id QAA08249; Fri, 1 Aug 2003 16:01:36 -0700 Date: Fri, 1 Aug 2003 16:01:36 -0700 From: "David S. Miller" To: Jeff Garzik Cc: willy@debian.org, netdev@oss.sgi.com Subject: Re: [PATCH] ethtool_ops rev 4 Message-Id: <20030801160136.3342c5cc.davem@redhat.com> In-Reply-To: <3F2AF141.2010308@pobox.com> References: <20030801150232.GV22222@parcelfarce.linux.theplanet.co.uk> <20030801154021.GA7696@gtf.org> <20030801154656.GW22222@parcelfarce.linux.theplanet.co.uk> <20030801162536.GA18574@gtf.org> <20030801132037.3f3542ae.davem@redhat.com> <3F2AE91D.5090705@pobox.com> <20030801153255.204baf66.davem@redhat.com> <3F2AF141.2010308@pobox.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4437 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 01 Aug 2003 19:01:21 -0400 Jeff Garzik wrote: > A DO_ETHTOOL_OPS macro in the driver's ->do_ioctl -- intentionally not > included in the kernel -- does the rest, I don't understand. Where does this DO_ETHTOOL_OPS macro come from? Is it defined by kcompat? If so, how will drivers in vanilla 2.4.x trees end up with the DO_ETHTOOL_OPS define? From davem@redhat.com Fri Aug 1 16:12:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 16:12:52 -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 h71NCnFl019319 for ; Fri, 1 Aug 2003 16:12:49 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id QAA08283; Fri, 1 Aug 2003 16:08:57 -0700 Date: Fri, 1 Aug 2003 16:08:57 -0700 From: "David S. Miller" To: Jeff Garzik Cc: willy@debian.org, netdev@oss.sgi.com Subject: Re: [PATCH] ethtool_ops rev 4 Message-Id: <20030801160857.32ebbf22.davem@redhat.com> In-Reply-To: <3F2AF32F.7090201@pobox.com> References: <20030801150232.GV22222@parcelfarce.linux.theplanet.co.uk> <20030801154021.GA7696@gtf.org> <20030801154656.GW22222@parcelfarce.linux.theplanet.co.uk> <20030801162536.GA18574@gtf.org> <20030801132037.3f3542ae.davem@redhat.com> <3F2AE91D.5090705@pobox.com> <3F2AEB33.9050506@pobox.com> <20030801153439.4a324c36.davem@redhat.com> <3F2AF32F.7090201@pobox.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4438 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 01 Aug 2003 19:09:35 -0400 Jeff Garzik wrote: > #define SET_ETHTOOL_OPS kcompat_set_ethtool_ops > > #define DO_ETHTOOL_OPS /* duplicate net/core/ethtool.c, basically */ Where does kcompat_set_ethtool_ops store the pointer if it does not exist in struct netdevice? From jgarzik@pobox.com Fri Aug 1 16:18:11 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 16:18:15 -0700 (PDT) Received: from www.linux.org.uk (IDENT:iDc7ycOqp9NNPy2+dMfDWg8UaR/Y+gOS@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71NIAFl019905 for ; Fri, 1 Aug 2003 16:18:10 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19ijA0-0001GK-DD; Sat, 02 Aug 2003 00:18:08 +0100 Message-ID: <3F2AF525.3000605@pobox.com> Date: Fri, 01 Aug 2003 19:17:57 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: willy@debian.org, netdev@oss.sgi.com Subject: Re: [PATCH] ethtool_ops rev 4 References: <20030801150232.GV22222@parcelfarce.linux.theplanet.co.uk> <20030801154021.GA7696@gtf.org> <20030801154656.GW22222@parcelfarce.linux.theplanet.co.uk> <20030801162536.GA18574@gtf.org> <20030801132037.3f3542ae.davem@redhat.com> <3F2AE91D.5090705@pobox.com> <20030801153255.204baf66.davem@redhat.com> <3F2AF141.2010308@pobox.com> <20030801160136.3342c5cc.davem@redhat.com> In-Reply-To: <20030801160136.3342c5cc.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4439 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev David S. Miller wrote: > On Fri, 01 Aug 2003 19:01:21 -0400 > Jeff Garzik wrote: > > >>A DO_ETHTOOL_OPS macro in the driver's ->do_ioctl -- intentionally not >>included in the kernel -- does the rest, > > > I don't understand. > > Where does this DO_ETHTOOL_OPS macro come from? Is it defined > by kcompat? If so, how will drivers in vanilla 2.4.x trees end > up with the DO_ETHTOOL_OPS define? If one wishes to implement kcompat design ("it looks like a 2.6 driver"), then you have two needs over and above Matthew's current ethtool_ops patch: (1) naked struct deref of netdev->ethtool_ops will break immediately on older kernels, and (2) to avoid code duplication, you need to insert a call to kcompat's do_ethtool_handling_the_old_way... i.e. basically what net/core/ethtool.c does now. Problem #1 is solved with a wrapper macro that disguises the naked struct deref to ->ethtool_ops. Problem #2 is solved by adding a call to DO_ETHTOOL_OPS macro in a driver's ->do_ioctl handler. So, with those two minor changes, a 2.6 driver will work on an older kernel. To answer your question above, DO_ETHTOOL_OPS can occur one of two ways: (1) my preferred approach, define a no-op DO_ETHTOOL_OPS macro in-kernel -- but I did not think this would get accepted, so I chose (2) DO_ETHTOOL_OPS exists entirely in kcompat, and people submitting kcompat users to mainline would simply delete the one line calling DO_ETHTOOL_OPS. Solution #2 chooses to create a tiny bit more merge-to-mainline pain, but also keeps the mainline kernel drivers more clean. Jeff From davem@redhat.com Fri Aug 1 16:23:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 16:23:34 -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 h71NNVFl020521 for ; Fri, 1 Aug 2003 16:23:31 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id QAA08330; Fri, 1 Aug 2003 16:19:38 -0700 Date: Fri, 1 Aug 2003 16:19:37 -0700 From: "David S. Miller" To: Jeff Garzik Cc: willy@debian.org, netdev@oss.sgi.com Subject: Re: [PATCH] ethtool_ops rev 4 Message-Id: <20030801161937.1d9a7126.davem@redhat.com> In-Reply-To: <3F2AF525.3000605@pobox.com> References: <20030801150232.GV22222@parcelfarce.linux.theplanet.co.uk> <20030801154021.GA7696@gtf.org> <20030801154656.GW22222@parcelfarce.linux.theplanet.co.uk> <20030801162536.GA18574@gtf.org> <20030801132037.3f3542ae.davem@redhat.com> <3F2AE91D.5090705@pobox.com> <20030801153255.204baf66.davem@redhat.com> <3F2AF141.2010308@pobox.com> <20030801160136.3342c5cc.davem@redhat.com> <3F2AF525.3000605@pobox.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4440 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 01 Aug 2003 19:17:57 -0400 Jeff Garzik wrote: > Solution #2 chooses to create a tiny bit more > merge-to-mainline pain, but also keeps the mainline kernel drivers more > clean. You don't need DO_ETHTOOL_OPS and thus the merge-to-mainline pain at all if you do something like: 1) SET_ETHDEV_OPS() also overrides the ->do_ioctl() setting to a kcompat_netdev_ioctl() one, but remembers the original pointer somewhere. 2) kcompat_netdev_ioctl() does the things DO_ETHTOOL_OPS would have done, failing that it calls the saved ->do_ioctl() pointer. From jgarzik@pobox.com Fri Aug 1 16:35:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 16:35:39 -0700 (PDT) Received: from www.linux.org.uk (IDENT:J3yO/Z/hGYogdXpUd6WP37Z2oMWhXKE3@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71NZWFl021452 for ; Fri, 1 Aug 2003 16:35:33 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19ijQp-0001NP-4x; Sat, 02 Aug 2003 00:35:31 +0100 Message-ID: <3F2AF938.7050608@pobox.com> Date: Fri, 01 Aug 2003 19:35:20 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: willy@debian.org, netdev@oss.sgi.com Subject: Re: [PATCH] ethtool_ops rev 4 References: <20030801150232.GV22222@parcelfarce.linux.theplanet.co.uk> <20030801154021.GA7696@gtf.org> <20030801154656.GW22222@parcelfarce.linux.theplanet.co.uk> <20030801162536.GA18574@gtf.org> <20030801132037.3f3542ae.davem@redhat.com> <3F2AE91D.5090705@pobox.com> <3F2AEB33.9050506@pobox.com> <20030801153439.4a324c36.davem@redhat.com> <3F2AF32F.7090201@pobox.com> <20030801160857.32ebbf22.davem@redhat.com> In-Reply-To: <20030801160857.32ebbf22.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4441 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev David S. Miller wrote: > On Fri, 01 Aug 2003 19:09:35 -0400 > Jeff Garzik wrote: > > >>#define SET_ETHTOOL_OPS kcompat_set_ethtool_ops >> >>#define DO_ETHTOOL_OPS /* duplicate net/core/ethtool.c, basically */ > > > Where does kcompat_set_ethtool_ops store the pointer if > it does not exist in struct netdevice? Inside an area allocated by the kcompat lib. SET_ETHTOOL_OPS takes 'struct net_device *' and 'struct ethtool_ops *' arguments, so it simply needs to create a lookup list/table somewhere. You keep asking for code, read kcompat :) kcompat_set_ethtool_ops has exactly the same task as the 2.2.x-era backcompat implementation of pci_{get,set}_drvdata. The perfect back-porting/back-compat system would magically make all Linus-tree drivers work without any change on older kernels. I really think the kcompat design is as close as you can come to that. Here is a linux-kernel-friendly version of the kcompat design: "naked struct derefs hurt. otherwise, happy hacking!" And further, experience shows that the number of naked struct derefs that matter is fairly small. (Another less-common area that hurts besides naked-struct-deref is function return type, which is why Linus created irqreturn_t) Jeff From davem@redhat.com Fri Aug 1 16:38:11 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 16:38:19 -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 h71NcAFl021877 for ; Fri, 1 Aug 2003 16:38:10 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id QAA08362; Fri, 1 Aug 2003 16:34:15 -0700 Date: Fri, 1 Aug 2003 16:34:15 -0700 From: "David S. Miller" To: Jeff Garzik Cc: willy@debian.org, netdev@oss.sgi.com Subject: Re: [PATCH] ethtool_ops rev 4 Message-Id: <20030801163415.1c3fd6fb.davem@redhat.com> In-Reply-To: <3F2AF938.7050608@pobox.com> References: <20030801150232.GV22222@parcelfarce.linux.theplanet.co.uk> <20030801154021.GA7696@gtf.org> <20030801154656.GW22222@parcelfarce.linux.theplanet.co.uk> <20030801162536.GA18574@gtf.org> <20030801132037.3f3542ae.davem@redhat.com> <3F2AE91D.5090705@pobox.com> <3F2AEB33.9050506@pobox.com> <20030801153439.4a324c36.davem@redhat.com> <3F2AF32F.7090201@pobox.com> <20030801160857.32ebbf22.davem@redhat.com> <3F2AF938.7050608@pobox.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4442 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 01 Aug 2003 19:35:20 -0400 Jeff Garzik wrote: > Inside an area allocated by the kcompat lib. SET_ETHTOOL_OPS takes > 'struct net_device *' and 'struct ethtool_ops *' arguments, so it simply > needs to create a lookup list/table somewhere. Ok ok ok, we're converging :-) Please just comment on my other email suggesting a way to do away with DO_ETHTOOL_OPS. I'm OK with a SET_ETHTOOL_OPS() macro. From davem@redhat.com Fri Aug 1 16:47:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 16:47:29 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71NlMFl022685 for ; Fri, 1 Aug 2003 16:47:22 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id QAA08392; Fri, 1 Aug 2003 16:43:29 -0700 Date: Fri, 1 Aug 2003 16:43:28 -0700 From: "David S. Miller" To: Jeff Garzik Cc: willy@debian.org, netdev@oss.sgi.com Subject: Re: [PATCH] ethtool_ops rev 4 Message-Id: <20030801164328.5b5bc145.davem@redhat.com> In-Reply-To: <3F2AFAF4.3040604@pobox.com> References: <20030801150232.GV22222@parcelfarce.linux.theplanet.co.uk> <20030801154021.GA7696@gtf.org> <20030801154656.GW22222@parcelfarce.linux.theplanet.co.uk> <20030801162536.GA18574@gtf.org> <20030801132037.3f3542ae.davem@redhat.com> <3F2AE91D.5090705@pobox.com> <20030801153255.204baf66.davem@redhat.com> <3F2AF141.2010308@pobox.com> <20030801160136.3342c5cc.davem@redhat.com> <3F2AF525.3000605@pobox.com> <20030801161937.1d9a7126.davem@redhat.com> <3F2AFAF4.3040604@pobox.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4443 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 01 Aug 2003 19:42:44 -0400 Jeff Garzik wrote: > Still need the boring and obvious definition of SET_ETHTOOL_OPS in > mainline, though. Like I said, I've got no problem with that part. From jgarzik@pobox.com Fri Aug 1 16:58:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 16:58:06 -0700 (PDT) Received: from www.linux.org.uk (IDENT:SvMafmN//vZSJhMjuzBvSDjdG3jdClZ3@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h71NvwFl023495 for ; Fri, 1 Aug 2003 16:57:59 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19ijmW-0001WQ-Qd; Sat, 02 Aug 2003 00:57:56 +0100 Message-ID: <3F2AFE7A.10203@pobox.com> Date: Fri, 01 Aug 2003 19:57:46 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: Ben Greear CC: "'netdev@oss.sgi.com'" Subject: Re: 2.4.21: bug report for tg3: tx lockup when changing MTU References: <3F2AEFBF.3040604@candelatech.com> In-Reply-To: <3F2AEFBF.3040604@candelatech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4444 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 Ben Greear wrote: > I just noticed that if you change the MTU of a tg3 NIC, it will not work > untill you ifdown/ifup it. This problem is repeatable on tg3, and does not > happen with the e1000 driver/cards. > > I am setting the MTU via an ioctl call, not via ifconfig or something like > that. Can you provide the ioctl call info, so I can reproduce? And, are you changing MTU when the interface is up or down? From jgarzik@pobox.com Fri Aug 1 17:00:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 17:00:32 -0700 (PDT) Received: from www.linux.org.uk (IDENT:mbLF7vnQT6LUjTsH4zlXT2XhjWraHjZQ@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7200PFl023951 for ; Fri, 1 Aug 2003 17:00:26 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19ij1u-0001Be-Az; Sat, 02 Aug 2003 00:09:46 +0100 Message-ID: <3F2AF32F.7090201@pobox.com> Date: Fri, 01 Aug 2003 19:09:35 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: willy@debian.org, netdev@oss.sgi.com Subject: Re: [PATCH] ethtool_ops rev 4 References: <20030801150232.GV22222@parcelfarce.linux.theplanet.co.uk> <20030801154021.GA7696@gtf.org> <20030801154656.GW22222@parcelfarce.linux.theplanet.co.uk> <20030801162536.GA18574@gtf.org> <20030801132037.3f3542ae.davem@redhat.com> <3F2AE91D.5090705@pobox.com> <3F2AEB33.9050506@pobox.com> <20030801153439.4a324c36.davem@redhat.com> In-Reply-To: <20030801153439.4a324c36.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4446 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev David S. Miller wrote: > On Fri, 01 Aug 2003 18:35:31 -0400 > Jeff Garzik wrote: > > >>We want to provide a sane, ifdef-free path to kcompat, where feasible. > > > I don't believe it's possible with netdev_ops, without > undoing the entire purpose of what netdev_ops is trying > to accomplish (elimination of code duplication). > > Show me, in code not words, how you are able to accomplish > this with SET_NETDEV_OPS() or whatever. I will not read > english text describing the scheme, I will read only code :) Read kcompat. Then: #define SET_ETHTOOL_OPS kcompat_set_ethtool_ops #define DO_ETHTOOL_OPS /* duplicate net/core/ethtool.c, basically */ I would define both of these in Matthew's patch, but one only _needs_ to define SET_ETHTOOL_OPS, so I pushed for the latter course. So why is SET_ETHTOOL_OPS needed? It covered up the one place It intentionally follows the same design as SET_MODULE_OWNER, and for the same purpose: hiding what would otherwise be a naked struct deref to a struct member that does not exist on an older kernel. Hiding naked struct derefs is also the reason I created pci_{get,drv}_drvdata, pci_resource_*, etc. Back compat is really a big syntactic sugar game, and naked struct derefs are really the only big thorn in the side. Everything else can be beaten down with syntactic sugar behind the scenes, that never ever gets merged into the upstream kernel. Jeff From jgarzik@pobox.com Fri Aug 1 17:00:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 17:00:31 -0700 (PDT) Received: from www.linux.org.uk (IDENT:allKiZwinkLTubXzBheWp6K1ooOLy/4T@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7200NFl023944 for ; Fri, 1 Aug 2003 17:00:23 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19iiMK-0000pf-0I; Fri, 01 Aug 2003 23:26:48 +0100 Message-ID: <3F2AE91D.5090705@pobox.com> Date: Fri, 01 Aug 2003 18:26:37 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: willy@debian.org, netdev@oss.sgi.com Subject: Re: [PATCH] ethtool_ops rev 4 References: <20030801150232.GV22222@parcelfarce.linux.theplanet.co.uk> <20030801154021.GA7696@gtf.org> <20030801154656.GW22222@parcelfarce.linux.theplanet.co.uk> <20030801162536.GA18574@gtf.org> <20030801132037.3f3542ae.davem@redhat.com> In-Reply-To: <20030801132037.3f3542ae.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4445 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev David S. Miller wrote: > The whole _POINT_ of these ops are to avoid duplicated code. > If someone is absolutely adament about supporting kernels > without ops support they should not support it at all. > > The point is to avoid code duplication, but what you suggest can only > be used to keep the duplicated code around "just in case". This makes > exactly no sense at all, it severs only to defeat the whole purpose > of the change in the first place. > > I totally am against making an ifdef test available for this, it can > only result in illogical things being done by driver maintainers. Strangely enough, creating a SET_ETHTOOL_OPS() macro (or netif_ethtool_ops or pick your name) reduces ifdefs. I feel that I've helped shepherd the net driver and PCI APIs to maintain something fairly interesting: a driver API that [for the most part...] allows one to write a driver completely without compatibility ifdefs, and ancient-kernel junk. When married with a compat glue lib outside the tree, the same ifdef-free driver works on older kernels. It's an explicit goal to avoid changing the driver API in such a way that there is a remotely sane path to supporting older kernels. One of the few things that is not easily work-around-able is new additions to existing structures (which wouldn't exist in older kernels). That's what SET_ETHTOOL_OPS would wrap, while also providing a trigger for generic compat glue. This trigger is what _reduces_ code duplication. Given such a trigger, a generic library can implement compat code on older kernels. The drivers remain ifdef-free and compat-junk-free. This is method used by the kcompat toolkit (http://sf.net/projects/gkernel/). This (IMO) feature continually saves me real time, again and again, when merging a new net driver into the kernel. It saves me time debugging a driver in both 2.4 and 2.6. The time savings is in the minimization (is that a word?) of changes across kernel versions, and this particular ethtool_ops change will be a thorn in particular. This ethtool_ops change _is_ trivially made backward-compatible, with a simple macro. Look at the future, where vendors are submitting 2.6-ready net drivers, because we made it easier for them to support their existing platform. Over and above the time savings, vendors _will_ start submitting drivers that actually look like Linux drivers. This has already started happening :) Just today I received a Via-rhine gbit driver (GPL'd) at Red Hat, which I am preparing to merge into the kernel. After removing the awful Hungarian notation and silly procfs apis, the driver's actually pretty close to a mergeable driver. It uses the kcompat stuff, and as such isn't full of ifdefs and typical vendor cpp maze. So, for the benefits of saving me real wall-clock hours, and pushing the vendors to create ready-for-the-kernel drivers more often, the cost is a simple one-line wrapper macro that in-kernel drivers would rarely use. In the long run, I'm trying to use and abuse Intel as an example for other vendors to follow (using netdev@, splitting up patches, etc.), and push the driver maintenance load onto the vendors (where they're willing, etc., like Intel). If vendors are willing to respond to feedback and follow standard linux-kernel email development, I'm more than happy for them to become a learned funnel of patches to netdev for review :) This kcompat strategy -- back-compat without ifdefs -- goes a long way towards that, and SET_ETHTOOL_OPS is a big piece of that puzzle right now. Jeff From greearb@candelatech.com Fri Aug 1 17:24:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 17:24:54 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-074.evrtwa1.dsl-verizon.net [4.33.45.74]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h720OFFl025687 for ; Fri, 1 Aug 2003 17:24:16 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h720O0tf025224; Fri, 1 Aug 2003 17:24:10 -0700 Message-ID: <3F2B04A0.9030101@candelatech.com> Date: Fri, 01 Aug 2003 17:24:00 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030718 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: "'netdev@oss.sgi.com'" Subject: Re: 2.4.21: bug report for tg3: tx lockup when changing MTU References: <3F2AEFBF.3040604@candelatech.com> <3F2AFE7A.10203@pobox.com> In-Reply-To: <3F2AFE7A.10203@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4447 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Jeff Garzik wrote: > Ben Greear wrote: > >> I just noticed that if you change the MTU of a tg3 NIC, it will not work >> untill you ifdown/ifup it. This problem is repeatable on tg3, and >> does not >> happen with the e1000 driver/cards. >> >> I am setting the MTU via an ioctl call, not via ifconfig or something >> like >> that. > > > > Can you provide the ioctl call info, so I can reproduce? > > And, are you changing MTU when the interface is up or down? Interface is up and transmitting/receiving pkts at the time. I just reproduced it with commands below. It is probably a race, so not sure that either of these will always fail. Running about 10kpps rx+tx. Was sending pktgen (UDP) traffic of fixed length, so the actual transmitted packet sizes remains the same in this case. # MTU is at 1500 ifconfig eth5 mtu 4096 #worked ifconfig eth5 mtu 4000 # failed. -- Ben Greear Candela Technologies Inc http://www.candelatech.com From jgarzik@pobox.com Fri Aug 1 18:07:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 18:07:05 -0700 (PDT) Received: from www.linux.org.uk (IDENT:w1RYSqFLki8rczBJvztL9jiQ2bgDrUfw@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7216xFl028005 for ; Fri, 1 Aug 2003 18:07:00 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19ijXz-0001Q9-5p; Sat, 02 Aug 2003 00:42:55 +0100 Message-ID: <3F2AFAF4.3040604@pobox.com> Date: Fri, 01 Aug 2003 19:42:44 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: willy@debian.org, netdev@oss.sgi.com Subject: Re: [PATCH] ethtool_ops rev 4 References: <20030801150232.GV22222@parcelfarce.linux.theplanet.co.uk> <20030801154021.GA7696@gtf.org> <20030801154656.GW22222@parcelfarce.linux.theplanet.co.uk> <20030801162536.GA18574@gtf.org> <20030801132037.3f3542ae.davem@redhat.com> <3F2AE91D.5090705@pobox.com> <20030801153255.204baf66.davem@redhat.com> <3F2AF141.2010308@pobox.com> <20030801160136.3342c5cc.davem@redhat.com> <3F2AF525.3000605@pobox.com> <20030801161937.1d9a7126.davem@redhat.com> In-Reply-To: <20030801161937.1d9a7126.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4448 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev David S. Miller wrote: > On Fri, 01 Aug 2003 19:17:57 -0400 > Jeff Garzik wrote: > > >>Solution #2 chooses to create a tiny bit more >>merge-to-mainline pain, but also keeps the mainline kernel drivers more >>clean. > > > You don't need DO_ETHTOOL_OPS and thus the merge-to-mainline pain > at all if you do something like: > > 1) SET_ETHDEV_OPS() also overrides the ->do_ioctl() setting to > a kcompat_netdev_ioctl() one, but remembers the original pointer > somewhere. > > 2) kcompat_netdev_ioctl() does the things DO_ETHTOOL_OPS would > have done, failing that it calls the saved ->do_ioctl() pointer. Certainly. That's a bit nicer than the back-compat gunk I was plotting, even. Still need the boring and obvious definition of SET_ETHTOOL_OPS in mainline, though. Jeff From takamiya@po.ntts.co.jp Fri Aug 1 19:59:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Aug 2003 19:59:20 -0700 (PDT) Received: from mail1.ics.ntts.co.jp (mail1.ics.ntts.co.jp [202.32.24.45]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h722xDFl001702 for ; Fri, 1 Aug 2003 19:59:16 -0700 Received: from mail26.silk.ntts.co.jp by mail1.ics.ntts.co.jp (8.9.3p2/3.7W-NTTSOFT-SUR2.0) id LAA11990 for ; Sat, 2 Aug 2003 11:59:12 +0900 (JST) (envelope-from takamiya@po.ntts.co.jp) Received: from daemon.inl.ntts.co.jp by mail26.silk.ntts.co.jp (8.11.7/3.7W-silk-4.6) id h722xB316268 for ; Sat, 2 Aug 2003 11:59:11 +0900 (JST) (envelope-from takamiya@po.ntts.co.jp) Received: (qmail 54448 invoked by alias); 2 Aug 2003 11:59:10 +0900 Received: (qmail 54428 invoked from network); 2 Aug 2003 11:59:10 +0900 Received: from localhost by localhost with SMTP; 2 Aug 2003 11:59:10 +0900 Date: Sat, 02 Aug 2003 11:59:09 +0900 (JST) Message-Id: <20030802.115909.576029077.takamiya@po.ntts.co.jp> To: nebuchadnezzar@nerim.net Cc: netdev@oss.sgi.com, takamiya@po.ntts.co.jp Subject: Re: [PATCH] 2.4.x USAGI mipv6_ha_ipsec From: Noriaki Takamiya In-Reply-To: <87n0etgt7w.fsf@zion.matrix> <87fzklgsh6.fsf@zion.matrix> References: <87n0etgt7w.fsf@zion.matrix> X-Face: +<)&j!Ce24nM@a.\f6TA,]^9Q76[_QN_[QR-(bT&>b40Oo[:`R(>b7!b-|q5k&.8CO[_Oh_ !9Nk0rikK70~?|08EFH|:]iF6pwPlnfEn-wo-voY:rP?%7p%cxjnbf'hglO'se&QwZN7/RVX!U7*P% cTV('HfHp+?g1+hx7\+J.W]G zYWv%LsDc X-Mailer: Mew version 3.2rc1 on XEmacs 21.4.8 (Honest Recruiter) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4449 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: takamiya@po.ntts.co.jp Precedence: bulk X-list: netdev Hi, >> Fri, 01 Aug 2003 19:53:23 +0200 >> [Subject: [PATCH] 2.4.x USAGI mipv6_ha_ipsec] >> "Daniel 'NebuchadnezzaR' Dehennin" wrote... nebuchadnezzar> I search for the definition of in6_ntop, it in include/linux/inet.h nebuchadnezzar> so I make that patch. >> Fri, 01 Aug 2003 20:09:25 +0200 >> [Subject: [PATCH 2] 2.4.x USAGI unused variables in mipv6_ha_ipsec.c] >> "Daniel 'NebuchadnezzaR' Dehennin" wrote... nebuchadnezzar> Hello again ;-), nebuchadnezzar> nebuchadnezzar> A patch to remove unused variables : Applied both fixes. Thakns. -- Noriaki Takamiya From akpm@osdl.org Sat Aug 2 01:12:08 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Aug 2003 01:12:16 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h728BxFl020572 for ; Sat, 2 Aug 2003 01:12:07 -0700 Received: from mnm (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id h728BnI26175 for ; Sat, 2 Aug 2003 01:11:51 -0700 Date: Sat, 2 Aug 2003 01:12:48 -0700 From: Andrew Morton To: netdev@oss.sgi.com Subject: Fw: [Bugme-new] [Bug 1030] New: racoon causes oops when implementing IPSec key Message-Id: <20030802011248.6772c9cd.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4450 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Begin forwarded message: Date: Sat, 2 Aug 2003 01:01:24 -0700 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 1030] New: racoon causes oops when implementing IPSec key http://bugme.osdl.org/show_bug.cgi?id=1030 Summary: racoon causes oops when implementing IPSec key Kernel Version: 2.6.0-test1 Status: NEW Severity: normal Owner: acme@conectiva.com.br Submitter: jsanchez@cs.ucf.edu Distribution: SuSE and LFS Hardware Environment: e100 cards Software Environment: ipsec-tools 0.2.2 Problem Description: I setkey with a policy to use esp and ah on each box. I start racoon on each box. I punch up a web page on one from the other. Insta-oops x 2. Unable to handle kernel NULL pointer dereference at virtual address 00000000 printing eip: c02bbd06 *pde = 00000000 Oops: 0000 [#1] CPU: 0 EIP: 0060:[] Not tainted EFLAGS: 00010206 EIP is at memcpy+0x1e/0x39 eax: 00000018 ebx: f6fe8a00 ecx: 00000006 edx: 00000000 esi: 00000000 edi: 00000000 ebp: c0562520 esp: f6fb5ccc ds: 007b es: 007b ss:0068 Process racoon (pid: 418, threadinfo=f6fb4000 task=f6fbb300) Stack: Call Trace: xfrm_state_update pfkey_add parse_exthdrs pfkey_process pfkey_sendmsg sock_sendmsg verify_iovec sys_sendmsg sockfd_lookup sys_sendto sys_getsockname __pollwait update_process sys_send sys_socketcall syscall_call Code: f3 a5 a8 02 74 02 66 a5 a8 01 74 01 a4 89 d0 8b 74 24 02 8b <0>Kernel panic: Fatal exception in interrupt In interrupt handler = not syncing For some of the other numbers that didn't get copied, check 67.9.9.32/oops.jpg. Email me if its dead, which it will be after 20 august. Steps to reproduce: >From each box: #!setkey -f flush; spdflush; spdadd $this_box $other_box any -P out ipsec esp/transport//use ah/transport//use; spdadd $other_box $this_box any -P in ipsec esp/transport//use ah/transport//use; Set up racoon (the default config would probably work, here is the gist of mine) remote anonymous { exchange_mode main; my_identifier address; peers_identifier address; lifetime time 1 min; # sec,min,hour proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key ; dh_group 2; } } sainfo anonymous { lifetime time 20 min; encryption_algorithm 3des ; authentication_algorithm hmac_sha1; compression_algorithm deflate ; } Start racoon on each box. Open a new connection to cause a key exchange. Hit the reset button on each box. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From davem@redhat.com Sat Aug 2 01:17:58 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Aug 2003 01:18:02 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h728HvFl020948 for ; Sat, 2 Aug 2003 01:17:58 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id BAA09115; Sat, 2 Aug 2003 01:13:58 -0700 Date: Sat, 2 Aug 2003 01:13:58 -0700 From: "David S. Miller" To: Andrew Morton Cc: netdev@oss.sgi.com Subject: Re: Fw: [Bugme-new] [Bug 1030] New: racoon causes oops when implementing IPSec key Message-Id: <20030802011358.0524c88c.davem@redhat.com> In-Reply-To: <20030802011248.6772c9cd.akpm@osdl.org> References: <20030802011248.6772c9cd.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4451 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 Old bug, fixed in current sources. From sascha@schumann.cx Sat Aug 2 02:44:47 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Aug 2003 02:44:55 -0700 (PDT) Received: from milton.schell.de (kdserv.de [217.160.72.35]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h729ijFl027701 for ; Sat, 2 Aug 2003 02:44:46 -0700 Received: (qmail 29266 invoked by uid 501); 2 Aug 2003 09:44:44 -0000 Received: from unknown (HELO eco.foo) (80.143.24.176) by kdserv.de with SMTP; 2 Aug 2003 09:44:44 -0000 Received: from localhost (localhost [127.0.0.1]) by eco.foo (Postfix) with ESMTP id 554E437045; Sat, 2 Aug 2003 11:44:43 +0200 (CEST) Date: Sat, 2 Aug 2003 11:44:43 +0200 (CEST) From: Sascha Schumann X-X-Sender: sas@eco.foo To: Ben Greear Cc: "'netdev@oss.sgi.com'" Subject: Re: 2.4.21: bug report for tg3: tx lockup when changing MTU In-Reply-To: <3F2AEFBF.3040604@candelatech.com> Message-ID: References: <3F2AEFBF.3040604@candelatech.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4452 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sascha@schumann.cx Precedence: bulk X-list: netdev > Kernel is 2.4.21 + custom patches (which should not affect tg3). > > lspci says the NIC is: Altima AC9100 (rev 15) [1] says that the AC9100 based Netgear GA302T cards don't support jumbo frames. I'm seeing regular lockups once packets larger than 1500bytes flow through the NIC. It would be cool though if this turned out to be a driver limitation and not a (crippled) chipset issue. [1] http://www.google.de/search?q=cache:y_kVF_dR3TkJ:www.lanshop.co.uk/html/ga302tq.htm+netgear+ga302t+jumbo+frames&hl=de&ie=UTF-8 - Sascha From daniel.ritz@gmx.ch Sat Aug 2 04:53:56 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Aug 2003 04:54:03 -0700 (PDT) Received: from ritz.dnsalias.org (dclient217-162-108-200.hispeed.ch [217.162.108.200]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h72BrsFl002495 for ; Sat, 2 Aug 2003 04:53:56 -0700 Received: from toshba.local (toshba.local [192.168.100.12]) by ritz.dnsalias.org (Postfix) with ESMTP id C83ED4FD7F; Sat, 2 Aug 2003 13:55:45 +0200 (CEST) From: Daniel Ritz To: "David S. Miller" Subject: [PATCH 2.6] Fix IPv6 esp mem leak in esp6_input Date: Sat, 2 Aug 2003 13:50:23 +0200 User-Agent: KMail/1.5.2 Cc: linux-net , "linux-netdev" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200308021350.23342.daniel.ritz@gmx.ch> X-archive-position: 4453 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: daniel.ritz@gmx.ch Precedence: bulk X-list: netdev fixes a mem leak in esp6_input() in the error paths. and return -ENOMEM, not -EINVAL when out of memory. against 2.6.0-test2-bk --- 1.19/net/ipv6/esp6.c Mon Jul 21 02:46:12 2003 +++ edited/net/ipv6/esp6.c Sat Aug 2 13:02:11 2003 @@ -200,18 +200,24 @@ int hdr_len = skb->h.raw - skb->nh.raw; int nfrags; - u8 ret_nexthdr = 0; unsigned char *tmp_hdr = NULL; + int ret = 0; - if (!pskb_may_pull(skb, sizeof(struct ipv6_esp_hdr))) - goto out; + if (!pskb_may_pull(skb, sizeof(struct ipv6_esp_hdr))) { + ret = -EINVAL; + goto out_nofree; + } - if (elen <= 0 || (elen & (blksize-1))) - goto out; + if (elen <= 0 || (elen & (blksize-1))) { + ret = -EINVAL; + goto out_nofree; + } tmp_hdr = kmalloc(hdr_len, GFP_ATOMIC); - if (!tmp_hdr) - goto out; + if (!tmp_hdr) { + ret = -ENOMEM; + goto out_nofree; + } memcpy(tmp_hdr, skb->nh.raw, hdr_len); /* If integrity check is required, do this. */ @@ -226,12 +232,15 @@ if (unlikely(memcmp(sum, sum1, alen))) { x->stats.integrity_failed++; + ret = -EINVAL; goto out; } } - if ((nfrags = skb_cow_data(skb, 0, &trailer)) < 0) + if ((nfrags = skb_cow_data(skb, 0, &trailer)) < 0) { + ret = -EINVAL; goto out; + } skb->ip_summed = CHECKSUM_NONE; @@ -251,8 +260,10 @@ if (unlikely(nfrags > MAX_SG_ONSTACK)) { sg = kmalloc(sizeof(struct scatterlist)*nfrags, GFP_ATOMIC); - if (!sg) + if (!sg) { + ret = -ENOMEM; goto out; + } } skb_to_sgvec(skb, sg, sizeof(struct ipv6_esp_hdr) + esp->conf.ivlen, elen); crypto_cipher_decrypt(esp->conf.tfm, sg, sg, elen); @@ -267,6 +278,7 @@ if (net_ratelimit()) { printk(KERN_WARNING "ipsec esp packet is garbage padlen=%d, elen=%d\n", padlen+2, elen); } + ret = -EINVAL; goto out; } /* ... check padding bits here. Silly. :-) */ @@ -277,13 +289,13 @@ memcpy(skb->nh.raw, tmp_hdr, hdr_len); skb->nh.ipv6h->payload_len = htons(skb->len - sizeof(struct ipv6hdr)); ip6_find_1stfragopt(skb, &prevhdr); - ret_nexthdr = *prevhdr = nexthdr[1]; + ret = *prevhdr = nexthdr[1]; } - kfree(tmp_hdr); - return ret_nexthdr; out: - return -EINVAL; + kfree(tmp_hdr); +out_nofree: + return ret; } static u32 esp6_get_max_size(struct xfrm_state *x, int mtu) From daniel.ritz@gmx.ch Sat Aug 2 08:46:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Aug 2003 08:46:49 -0700 (PDT) Received: from ritz.dnsalias.org (dclient217-162-108-200.hispeed.ch [217.162.108.200]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h72FkhFl016663 for ; Sat, 2 Aug 2003 08:46:44 -0700 Received: from toshba.local (toshba.local [192.168.100.12]) by ritz.dnsalias.org (Postfix) with ESMTP id C3B4C4FD7F; Sat, 2 Aug 2003 17:48:35 +0200 (CEST) From: Daniel Ritz To: Jeff Garzik Subject: [PATCH] fix airo memory leak Date: Sat, 2 Aug 2003 17:43:12 +0200 User-Agent: KMail/1.5.2 Cc: linux-net , "linux-netdev" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200308021743.12635.daniel.ritz@gmx.ch> X-archive-position: 4454 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: daniel.ritz@gmx.ch Precedence: bulk X-list: netdev fixes a memory leak: memory for the airo_devices list is allocated but never freed. against 2.6.0-test2-bk, but should apply to 2.4 as well... --- 1.54/drivers/net/wireless/airo.c Sun Jul 20 05:17:02 2003 +++ edited/drivers/net/wireless/airo.c Sat Aug 2 17:33:24 2003 @@ -4038,12 +4038,23 @@ return 0; } -static void del_airo_dev( struct net_device *dev ) { - struct net_device_list **p = &airo_devices; - while( *p && ( (*p)->dev != dev ) ) - p = &(*p)->next; - if ( *p && (*p)->dev == dev ) - *p = (*p)->next; +static void del_airo_dev(struct net_device *dev) +{ + struct net_device_list *this = airo_devices, *prev = NULL; + + while (this) { + if (this->dev == dev) { + if (prev) + prev->next = this->next; + else + airo_devices = this->next; + kfree(this); + break; + } + + prev = this; + this = this->next; + } } #ifdef CONFIG_PCI From werner@almesberger.net Sat Aug 2 10:04:56 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Aug 2003 10:05:08 -0700 (PDT) Received: from host.almesberger.net (almesberger.net [63.105.73.239] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h72H4uFl022817 for ; Sat, 2 Aug 2003 10:04:56 -0700 Received: from almesberger.net (vpnwa-home [10.200.0.2]) by host.almesberger.net (8.11.6/8.9.3) with ESMTP id h72H4oG24090; Sat, 2 Aug 2003 10:04:50 -0700 Received: (from werner@localhost) by almesberger.net (8.11.6/8.11.6) id h72H4i330124; Sat, 2 Aug 2003 14:04:44 -0300 Date: Sat, 2 Aug 2003 14:04:44 -0300 From: Werner Almesberger To: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: TOE brain dump Message-ID: <20030802140444.E5798@almesberger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 4455 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: werner@almesberger.net Precedence: bulk X-list: netdev At OLS, there was a bit of discussion on (true and false *) TOEs (TCP Offload Engines). In the course of this discussion, I've suggested what might be a novel approach, so in case this is a good idea, I'd like to dump my thoughts on it, before someone tries to patent my ideas. (Most likely, some of this has already been done or tried elsewhere, but it can't hurt to try to err on the safe side.) (*) The InfiniBand people unfortunately call also their TCP/IP bypass "TOE" (for which they promptly get shouted down, every time they use that word). This is misleading, because there is no TCP that's getting offloaded, but TCP is simply never done. I would consider it to be more accurate to view this as a separate networking technology, with semantics different from TCP/IP, similar to ATM and AAL5. While I'm not entirely convinced about the usefulness of TOE in all the cases it's been suggested for, I can see value in certain areas, e.g. when TCP per-packet overhead becomes an issue. However, I consider the approach of putting a new or heavily modified stack, which duplicates a considerable amount of the functionality in the main kernel, on a separate piece of hardware questionable at best. Some of the issues: - if this stack is closed source or generally hard to modify, security fixes will be slowed down - if this stack is closed source or generally hard to modify, TOE will not be available to projects modifying the stack, e.g. any of the research projects trying to make TCP work at gigabit speeds - this stack either needs to implement all administrative interfaces of the regular kernel, or such a system would have non-uniform configuration/monitoring across interfaces - in some cases, administrative interfaces will require a NIC/TOE-specific switch in the kernel (netlink helps here) - route changes on multi-homed hosts (or any similar kind of failover) are difficult if the state of TCP connections is tied to specific NICs (I've discussed some issues when "migrating" TCP connections in the documentation of tcpcp, http://www.almesberger.net/tcpcp/) - new kernel features will always lag behind on this kind of TOE, and different kernels will require different "firmware" - last but not least, keeping TOE firmware up to date with the TCP/IP stack in the mainstream kernel will require - for each such TOE device - a significant and continuous effort over a long period of time In short, I think such a solution is either a pain to use, or unmaintainable, or - most likely - both. So, how to do better ? Easy: use the Source, Luke. Here's my idea: - instead of putting a different stack on the TOE, a general-purpose processor (probably with some enhancements, and certainly with optimized data paths) is added to the NIC - that processor runs the same Linux kernel image as the host, acting like a NUMA system - a selectable part of TCP/IP is handled on the NIC, and the rest of the system runs on the host processor - instrumentation is added to the mainstream kernel to ensure that as little data as possible is shared between the main CPU and such peripheral CPUs. Note that such instrumentation would be generic, outlining possible boundaries, and not tied to a specific TOE design. - depending on hardware details (cache coherence, etc.), the instrumentation mentioned above may even be necessary for correctness. This would have the unfortunate effect of making the design very fragile with respect to changes in the mainstream kernel. (Performance loss in the case of imperfect instrumentation would be preferable.) - further instrumentation may be needed to let the kernel switch CPUs (i.e. host to NIC, and vice versa) at the right time - since the NIC would probably use a CPU design different from the host CPU, we'd need "fat" kernel binaries: - data structures are the same, i.e. word sizes, byte order, bit numbering, etc. are compatible, and alignments are chosen such that all CPUs involved are reasonably happy - kernels live in the same address space - function pointers become arrays, with one pointer per architecture. When comparing pointers, the first element is used. - if one should choose to also run parts of user space on the NIC, fat binaries would also be needed for this (along with other complications) Benefits: - putting the CPU next to the NIC keeps data paths short, and allows for all kinds of optimizations (e.g. a pipelined memory architecture) - the design is fairly generic, and would equally apply to other areas of the kernel than TCP/IP - using the same kernel image eliminates most maintenance problems, and encourages experimenting with the stack - using the same kernel image (and compatible data structures) guarantees that administrative interfaces are uniform in the entire system - such a design is likely to be able to allow TCP state to be moved to a different NIC, if necessary Possible problems, that may kill this idea: - it may be too hard to achieve correctness - it may be too hard to switch CPUs properly - it may not be possible to express copy operations efficiently in such a context - there may be no way to avoid sharing of hardware-specific data structures, such as page tables, or to emulate their use - people may consider the instrumentation required for this, although fairly generic, too intrusive - all this instrumentation may eat too much performance - nobody may be interested in building hardware for this - nobody may be patient enough to pursue such long-termish development, with uncertain outcome - something I haven't thought of I lack the resources (hardware, financial, and otherwise) to actually do something with these ideas, so please feel free to put them to some use. - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina werner@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From niv@us.ibm.com Sat Aug 2 10:32:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Aug 2003 10:33:04 -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 h72HWkFl024975 for ; Sat, 2 Aug 2003 10:32:53 -0700 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h72HWVc8270888; Sat, 2 Aug 2003 13:32:31 -0400 Received: from us.ibm.com (d03av03.boulder.ibm.com [9.17.193.83]) by westrelay03.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h72HWUYc053666; Sat, 2 Aug 2003 11:32:31 -0600 Message-ID: <3F2BF5C7.90400@us.ibm.com> Date: Sat, 02 Aug 2003 10:32:55 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Werner Almesberger CC: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: TOE brain dump References: <20030802140444.E5798@almesberger.net> In-Reply-To: <20030802140444.E5798@almesberger.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4456 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Werner Almesberger wrote: > (*) The InfiniBand people unfortunately call also their TCP/IP > bypass "TOE" (for which they promptly get shouted down, > every time they use that word). This is misleading, because Thank you! Yes! All in favor say Aye..AYE!!! Motion passes, the infiniband people don't get to call it TOE anymore.. > While I'm not entirely convinced about the usefulness of TOE in > all the cases it's been suggested for, I can see value in certain > areas, e.g. when TCP per-packet overhead becomes an issue. Ditto, but I see it being used to rollout the idea and process, rather than anything of value now, and the lessons are being learned for the future, when we reach 20Gb, 40Gb, even faster networks of tommorow. The processors might keep up, but nothing else will, for sure. > However, I consider the approach of putting a new or heavily > modified stack, which duplicates a considerable amount of the > functionality in the main kernel, on a separate piece of hardware > questionable at best. Some of the issues: > > - if this stack is closed source or generally hard to modify, > security fixes will be slowed down as will bug fixes, and debugging becomes a right royal pain. Also, most profiles of networking applications show the largest blip is essentially the user<->kernel transfer, and that would still remain the unaddressed bottleneck. > So, how to do better ? Easy: use the Source, Luke. Here's my > idea: > > - instead of putting a different stack on the TOE, a > general-purpose processor (probably with some enhancements, > and certainly with optimized data paths) is added to the NIC The thing is, all the TOE efforts are propietary ones, to my limited knowledge. Thus all the design is occurring in confidential, vendor internal forums. How will they/we come up with really the needed, _common_ design approach? Or is this not so needed? thanks, Nivedita From werner@almesberger.net Sat Aug 2 11:06:12 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Aug 2003 11:06:21 -0700 (PDT) Received: from host.almesberger.net (almesberger.net [63.105.73.239] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h72I6BFl027777 for ; Sat, 2 Aug 2003 11:06:11 -0700 Received: from almesberger.net (vpnwa-home [10.200.0.2]) by host.almesberger.net (8.11.6/8.9.3) with ESMTP id h72I65G24280; Sat, 2 Aug 2003 11:06:06 -0700 Received: (from werner@localhost) by almesberger.net (8.11.6/8.11.6) id h72I60t30481; Sat, 2 Aug 2003 15:06:00 -0300 Date: Sat, 2 Aug 2003 15:06:00 -0300 From: Werner Almesberger To: Nivedita Singhvi Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: TOE brain dump Message-ID: <20030802150600.F5798@almesberger.net> References: <20030802140444.E5798@almesberger.net> <3F2BF5C7.90400@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F2BF5C7.90400@us.ibm.com>; from niv@us.ibm.com on Sat, Aug 02, 2003 at 10:32:55AM -0700 X-archive-position: 4457 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: werner@almesberger.net Precedence: bulk X-list: netdev Nivedita Singhvi wrote: > Also, most profiles of networking applications show the > largest blip is essentially the user<->kernel transfer, and > that would still remain the unaddressed bottleneck. I have some hope that sendfile plus a NUMA-like approach will be sufficient for keeping transfers away from buses and memory they don't need to touch. > The thing is, all the TOE efforts are propietary ones, to > my limited knowledge. Many companies default to "closed" designs if they're not given a convincing reason for going "open". The approach I've described may provide that reason. There are also historicial reasons, e.g. if you want to interface with the stack of Windows, or any proprietary Unix, you probably need to obtain some of their source under NDA, and use some of that information in your own drivers or firmware. Of course, none of this is an issue here. Since we're talking about 1-2 years of development time anyway, legacy hardware (i.e. hardware choices influenced by information obtained under an NDA) will be quite obsolete by then and doesn't matter. > Or is this not so needed? Exactly. The "NUMA" approach would avoid the "common TOE design" problem. All you need is a reasonably well documented "general-purpose" CPU (that doesn't mean it has to be an off-the-shelf design, but most likely, the core would be an off-the-shelf one), plus some NIC hardware. Now, if that NIC in turn has some hidden secrets, this isn't an issue as long as one can still write a GPLed driver for it. Of course, there would be elements in such a system that vendors would like to keep secret. But then, there always are, and so far, we've found reasonable compromises most of the time, so I don't see why this couldn't happen here, too. Also, if "classical TOE" patches keep getting rejected, but an open and maintainable approach makes it into the mainstream kernel, also the business aspects should become fairly clear. - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina werner@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From jgarzik@pobox.com Sat Aug 2 12:09:07 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Aug 2003 12:09:18 -0700 (PDT) Received: from www.linux.org.uk (IDENT:yTEIorJOZS7ZcYhSCsBkoXNszRdAMY2B@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h72J96Fl032752 for ; Sat, 2 Aug 2003 12:09:07 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19j1kV-0003a8-LU; Sat, 02 Aug 2003 20:09:03 +0100 Message-ID: <3F2C0C44.6020002@pobox.com> Date: Sat, 02 Aug 2003 15:08:52 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: Nivedita Singhvi CC: Werner Almesberger , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: TOE brain dump References: <20030802140444.E5798@almesberger.net> <3F2BF5C7.90400@us.ibm.com> In-Reply-To: <3F2BF5C7.90400@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4458 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 My own brain dump: If one wants to go straight from disk to network, why is anyone bothering to involve the host CPU and host memory bus at all? Memory bandwidth and PCI bus bandwidth are still bottlenecks, no much how much of the net stack you offload. Regardless of how fast your network zooms packets, you've gotta keep that pipeline full to make use of it. And you've gotta do something intelligent with it, which in TCP's case involves the host CPU quite a bit. TCP is sufficiently complex, for a reason. It has to handle all manner of disturbingly slow and disturbing fast net connections, all jabbering at the same time. TCP is a "one size fits all" solution, but it doesn't work well for everyone. The "TCP Offload Everything" people really need to look at what data your users want to push, at such high speeds. It's obviously not over a WAN... so steer users away from TCP, to an IP protocol that is tuned for your LAN needs, and more friendly to some sort of h/w offloading solution. A "foo over ipv6" protocol that was designed for h/w offloading from the start, would be a far better idea than full TCP offload will ever be. In any case, when you approach these high speeds, you really must take a good look at the other end of the pipeline: what are you serving at 10Gb/s, 20Gb/s, 40Gb/s? For some time, I think the answer will be "highly specialized stuff" At some point, Intel networking gear will be able to transfer more bits per second than there exist atoms on planet Earth :) Garbage in, garbage out. So, fix the other end of the pipeline too, otherwise this fast network stuff is flashly but pointless. If you want to serve up data from disk, then start creating PCI cards that have both Serial ATA and ethernet connectors on them :) Cut out the middleman of the host CPU and host memory bus instead of offloading portions of TCP that do not need to be offloaded. Jeff From alan@lxorguk.ukuu.org.uk Sat Aug 2 14:01:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Aug 2003 14:01:52 -0700 (PDT) Received: from lxorguk.ukuu.org.uk (pc1-cwma1-5-cust4.swan.cable.ntl.com [80.5.120.4]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h72L1hFl024055 for ; Sat, 2 Aug 2003 14:01:44 -0700 Received: from dhcp22.swansea.linux.org.uk (dhcp22.swansea.linux.org.uk [127.0.0.1]) by lxorguk.ukuu.org.uk (8.12.8/8.12.5) with ESMTP id h72KvkC3020394; Sat, 2 Aug 2003 21:57:47 +0100 Received: (from alan@localhost) by dhcp22.swansea.linux.org.uk (8.12.8/8.12.8/Submit) id h72KvjLd020392; Sat, 2 Aug 2003 21:57:45 +0100 X-Authentication-Warning: dhcp22.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: TOE brain dump From: Alan Cox To: Werner Almesberger Cc: netdev@oss.sgi.com, Linux Kernel Mailing List In-Reply-To: <20030802140444.E5798@almesberger.net> References: <20030802140444.E5798@almesberger.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1059857864.20305.14.camel@dhcp22.swansea.linux.org.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 02 Aug 2003 21:57:44 +0100 X-archive-position: 4459 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: netdev On Sad, 2003-08-02 at 18:04, Werner Almesberger wrote: > - last but not least, keeping TOE firmware up to date with the > TCP/IP stack in the mainstream kernel will require - for each > such TOE device - a significant and continuous effort over a > long period of time or even the protocol and protocol refinements.. > - instead of putting a different stack on the TOE, a > general-purpose processor (probably with some enhancements, > and certainly with optimized data paths) is added to the NIC Like say an opteron in the 2nd socket on the motherboard > Benefits: > > - putting the CPU next to the NIC keeps data paths short, and > allows for all kinds of optimizations (e.g. a pipelined > memory architecture) It moves the cost it doesnt make it vanish If I read you right you are arguing for a second processor running Linux.with its own independant memory bus. AMD make those already its called AMD64. I don't know anyone thinking at that level about partitioning one as an I/O processor. From werner@almesberger.net Sat Aug 2 14:49:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Aug 2003 14:49:28 -0700 (PDT) Received: from host.almesberger.net (almesberger.net [63.105.73.239] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h72LnGFl028183 for ; Sat, 2 Aug 2003 14:49:17 -0700 Received: from almesberger.net (vpnwa-home [10.200.0.2]) by host.almesberger.net (8.11.6/8.9.3) with ESMTP id h72Ln8G25059; Sat, 2 Aug 2003 14:49:08 -0700 Received: (from werner@localhost) by almesberger.net (8.11.6/8.11.6) id h72Ln1e31495; Sat, 2 Aug 2003 18:49:01 -0300 Date: Sat, 2 Aug 2003 18:49:01 -0300 From: Werner Almesberger To: Jeff Garzik Cc: Nivedita Singhvi , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: TOE brain dump Message-ID: <20030802184901.G5798@almesberger.net> References: <20030802140444.E5798@almesberger.net> <3F2BF5C7.90400@us.ibm.com> <3F2C0C44.6020002@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F2C0C44.6020002@pobox.com>; from jgarzik@pobox.com on Sat, Aug 02, 2003 at 03:08:52PM -0400 X-archive-position: 4460 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: werner@almesberger.net Precedence: bulk X-list: netdev Jeff Garzik wrote: > jabbering at the same time. TCP is a "one size fits all" solution, but > it doesn't work well for everyone. But then, ten "optimized xxPs" that work well in two different scenarios each, but not so good in the 98 others, wouldn't be much fun either. It's been tried a number of times. Usually, real life sneaks in at one point or another, leaving behind a complex mess. When they've sorted out these problems, regular TCP has caught up with the great optimized transport protocols. At that point, they return to their niche, sometimes tail between legs and muttering curses, sometimes shaking their fist and boldly proclaiming how badly they'll rub TCP in the dirt in the next round. Maybe they shed off some of the complexity, and trade it for even more aggressive optimization, which puts them into their niche even more firmly. Eventually, they fade away. There are cases where TCP doesn't work well, like a path of badly mismatched link layers, but such paths don't treat any protocol following the end-to-end principle kindly. Another problem of TCP is that it has grown a bit too many knobs you need to turn before it works over your really fast really long pipe. (In one of the OLS after dinner speeches, this was quite appropriately called the "wizard gap".) > It's obviously not over a WAN... That's why NFS turned off UDP checksums ;-) As soon as you put it on IP, it will crawl to distances you didn't imagine in your wildest dreams. It always does. > So, fix the other end of the pipeline too, otherwise this fast network > stuff is flashly but pointless. If you want to serve up data from disk, > then start creating PCI cards that have both Serial ATA and ethernet > connectors on them :) Cut out the middleman of the host CPU and host > memory bus instead of offloading portions of TCP that do not need to be > offloaded. That's a good point. A hierarchical memory structure can help here. Moving one end closer to the hardware, and letting it know (e.g. through sendfile) that also the other end is close (or can be reached more directly that through some hopelessly crowded main bus) may help too. - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina werner@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From werner@almesberger.net Sat Aug 2 15:14:19 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Aug 2003 15:14:22 -0700 (PDT) Received: from host.almesberger.net (almesberger.net [63.105.73.239] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h72MEJFl030541 for ; Sat, 2 Aug 2003 15:14:19 -0700 Received: from almesberger.net (vpnwa-home [10.200.0.2]) by host.almesberger.net (8.11.6/8.9.3) with ESMTP id h72MEGG25185; Sat, 2 Aug 2003 15:14:17 -0700 Received: (from werner@localhost) by almesberger.net (8.11.6/8.11.6) id h72MEBR31594; Sat, 2 Aug 2003 19:14:11 -0300 Date: Sat, 2 Aug 2003 19:14:11 -0300 From: Werner Almesberger To: Alan Cox Cc: netdev@oss.sgi.com, Linux Kernel Mailing List Subject: Re: TOE brain dump Message-ID: <20030802191411.H5798@almesberger.net> References: <20030802140444.E5798@almesberger.net> <1059857864.20305.14.camel@dhcp22.swansea.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1059857864.20305.14.camel@dhcp22.swansea.linux.org.uk>; from alan@lxorguk.ukuu.org.uk on Sat, Aug 02, 2003 at 09:57:44PM +0100 X-archive-position: 4461 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: werner@almesberger.net Precedence: bulk X-list: netdev Alan Cox wrote: > It moves the cost it doesnt make it vanish I don't think it really can. What it can do is reduce the overhead (which usually translates to latency and burstiness) and the sharing. > If I read you right you are arguing for a second processor running > Linux.with its own independant memory bus. AMD make those already its > called AMD64. I don't know anyone thinking at that level about > partitioning one as an I/O processor. That's taking this idea to an extreme, yes. I'd think of using something as big as an amd64 for this as "too expensive", but perhaps it's cheap enough in the long run, compared to some "optimized" design. It would certainly have the advantage of already solving various consistency and compatibility issues. (That is, if your host CPUs is/are also amd64.) - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina werner@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From willy@www.linux.org.uk Sat Aug 2 15:21:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Aug 2003 15:21:54 -0700 (PDT) Received: from www.linux.org.uk (IDENT:UcG6xcZ7ts6X+JIzSklM4po5qU39agf+@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h72MLlFl031389 for ; Sat, 2 Aug 2003 15:21:48 -0700 Received: from willy by www.linux.org.uk with local (Exim 4.14) id 19j4kz-0004pd-Mh; Sat, 02 Aug 2003 23:21:45 +0100 Date: Sat, 2 Aug 2003 23:21:45 +0100 From: Matthew Wilcox To: Jeff Garzik Cc: Matthew Wilcox , netdev@oss.sgi.com Subject: Re: [PATCH] ethtool_ops rev 4 Message-ID: <20030802222145.GE22222@parcelfarce.linux.theplanet.co.uk> References: <20030801150232.GV22222@parcelfarce.linux.theplanet.co.uk> <20030801154021.GA7696@gtf.org> <20030801154656.GW22222@parcelfarce.linux.theplanet.co.uk> <20030801162536.GA18574@gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030801162536.GA18574@gtf.org> User-Agent: Mutt/1.4.1i X-archive-position: 4462 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@debian.org Precedence: bulk X-list: netdev On Fri, Aug 01, 2003 at 12:25:36PM -0400, Jeff Garzik wrote: > On Fri, Aug 01, 2003 at 04:46:56PM +0100, Matthew Wilcox wrote: > > On Fri, Aug 01, 2003 at 11:40:21AM -0400, Jeff Garzik wrote: > > > * need SET_ETHTOOL_OPS macro or HAVE_ETHTOOL_OPS test macro or similar > > It's standard netdevice.h practice, and, he didn't disagree w/ my > rebuttal. OK, now that the two of you thrashed out a design, here's my implementation: diff -u drivers/net/8139too.c drivers/net/8139too.c --- drivers/net/8139too.c 31 Jul 2003 17:09:52 -0000 +++ drivers/net/8139too.c 2 Aug 2003 18:38:25 -0000 @@ -973,7 +973,7 @@ dev->do_ioctl = netdev_ioctl; dev->tx_timeout = rtl8139_tx_timeout; dev->watchdog_timeo = TX_TIMEOUT; - dev->ethtool_ops = &rtl8139_ethtool_ops; + set_ethtool_ops(dev, &rtl8139_ethtool_ops); /* note: the hardware is not capable of sg/csum/highdma, however * through the use of skb_copy_and_csum_dev we enable these diff -u drivers/net/tg3.c drivers/net/tg3.c --- drivers/net/tg3.c 31 Jul 2003 11:12:10 -0000 +++ drivers/net/tg3.c 2 Aug 2003 18:37:54 -0000 @@ -6724,11 +6724,11 @@ dev->do_ioctl = tg3_ioctl; dev->tx_timeout = tg3_tx_timeout; dev->poll = tg3_poll; - dev->ethtool_ops = &tg3_ethtool_ops; dev->weight = 64; dev->watchdog_timeo = TG3_TX_TIMEOUT; dev->change_mtu = tg3_change_mtu; dev->irq = pdev->irq; + set_ethtool_ops(dev, &tg3_ethtool_ops); err = tg3_get_invariants(tp); if (err) { diff -u include/linux/netdevice.h include/linux/netdevice.h --- include/linux/netdevice.h 31 Jul 2003 13:06:23 -0000 +++ include/linux/netdevice.h 2 Aug 2003 18:37:16 -0000 @@ -477,6 +477,10 @@ */ #define SET_NETDEV_DEV(net, pdev) ((net)->class_dev.dev = (pdev)) +static inline void set_ethtool_ops(struct net_device *dev, struct ethtool_ops * ops) +{ + dev->ethtool_ops = ops; +} struct packet_type { Happy with that? > > > * I still do not see the need to change a simple storage of a constant > > > (into ethtool_gdrvinfo) into _four_ separate function call hooks (reg > > > dump len, eeprom dump len, nic-specific stats len, self-test len). > > > Internal kernel code that needs this information is always a slow path > > > anyway, so just call the ->get_drvinfo hook internally. > > > > slow path, sure, but increased stack usage. it's a tradeoff, and this way > > feels more clean to me. > > Additing a function hook each time you want to retrieve a new integer > value? That's feels overly excessive to me. Actually, it's a useful thing to do because it specifies what kind of answer we want. For example, up here, you called them all foo_len. That's not true. Some of them are a byte-count (== len), but some of them are a count of N-byte quantities. That's an unfortunate bit of design, but at least we can make it obvious to the driver-writer what we're expecting of them. > > > * I prefer not to add '#include ' to ethtool.h > > > > That means that any code which includes ethtool.h has to include types.h > > first (either implicitly or explicitly). The rule so far has been that > > header files should call out their dependencies explictly with an include > > of the appropriate file. So why *don't* you want it? > > Because I copy it to userspace :) linux/types.h exists in userspace ;-) You even _expect_ userspce to have already included it -- or where else are the `u32' quantities defined? -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From jgarzik@pobox.com Sat Aug 2 15:35:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Aug 2003 15:35:04 -0700 (PDT) Received: from www.linux.org.uk (IDENT:VMLs27LF89sjE5OoM6LvqsoQ8uGmYllr@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h72MYwFl032658 for ; Sat, 2 Aug 2003 15:34:59 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19j4xl-0004tx-Rf; Sat, 02 Aug 2003 23:34:57 +0100 Message-ID: <3F2C3C86.6000202@pobox.com> Date: Sat, 02 Aug 2003 18:34:46 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: Matthew Wilcox CC: netdev@oss.sgi.com Subject: Re: [PATCH] ethtool_ops rev 4 References: <20030801150232.GV22222@parcelfarce.linux.theplanet.co.uk> <20030801154021.GA7696@gtf.org> <20030801154656.GW22222@parcelfarce.linux.theplanet.co.uk> <20030801162536.GA18574@gtf.org> <20030802222145.GE22222@parcelfarce.linux.theplanet.co.uk> In-Reply-To: <20030802222145.GE22222@parcelfarce.linux.theplanet.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4463 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Matthew Wilcox wrote: > On Fri, Aug 01, 2003 at 12:25:36PM -0400, Jeff Garzik wrote: > >>On Fri, Aug 01, 2003 at 04:46:56PM +0100, Matthew Wilcox wrote: >> >>>On Fri, Aug 01, 2003 at 11:40:21AM -0400, Jeff Garzik wrote: >>> >>>>* need SET_ETHTOOL_OPS macro or HAVE_ETHTOOL_OPS test macro or similar >> >>It's standard netdevice.h practice, and, he didn't disagree w/ my >>rebuttal. > > > OK, now that the two of you thrashed out a design, here's my implementation: > > diff -u drivers/net/8139too.c drivers/net/8139too.c > --- drivers/net/8139too.c 31 Jul 2003 17:09:52 -0000 > +++ drivers/net/8139too.c 2 Aug 2003 18:38:25 -0000 > @@ -973,7 +973,7 @@ > dev->do_ioctl = netdev_ioctl; > dev->tx_timeout = rtl8139_tx_timeout; > dev->watchdog_timeo = TX_TIMEOUT; > - dev->ethtool_ops = &rtl8139_ethtool_ops; > + set_ethtool_ops(dev, &rtl8139_ethtool_ops); > > /* note: the hardware is not capable of sg/csum/highdma, however > * through the use of skb_copy_and_csum_dev we enable these > diff -u drivers/net/tg3.c drivers/net/tg3.c > --- drivers/net/tg3.c 31 Jul 2003 11:12:10 -0000 > +++ drivers/net/tg3.c 2 Aug 2003 18:37:54 -0000 > @@ -6724,11 +6724,11 @@ > dev->do_ioctl = tg3_ioctl; > dev->tx_timeout = tg3_tx_timeout; > dev->poll = tg3_poll; > - dev->ethtool_ops = &tg3_ethtool_ops; > dev->weight = 64; > dev->watchdog_timeo = TG3_TX_TIMEOUT; > dev->change_mtu = tg3_change_mtu; > dev->irq = pdev->irq; > + set_ethtool_ops(dev, &tg3_ethtool_ops); > > err = tg3_get_invariants(tp); > if (err) { > diff -u include/linux/netdevice.h include/linux/netdevice.h > --- include/linux/netdevice.h 31 Jul 2003 13:06:23 -0000 > +++ include/linux/netdevice.h 2 Aug 2003 18:37:16 -0000 > @@ -477,6 +477,10 @@ > */ > #define SET_NETDEV_DEV(net, pdev) ((net)->class_dev.dev = (pdev)) > > +static inline void set_ethtool_ops(struct net_device *dev, struct ethtool_ops * > ops) > +{ > + dev->ethtool_ops = ops; > +} It needs to be a macro for maximum flexibility. Also, no need to convert in-kernel drivers over to using it... Let driver authors use it or not as they choose. Jeff From davem@redhat.com Sat Aug 2 17:32:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Aug 2003 17:32:22 -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 h730WBFl009320 for ; Sat, 2 Aug 2003 17:32:14 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id RAA10269; Sat, 2 Aug 2003 17:28:07 -0700 Date: Sat, 2 Aug 2003 17:28:07 -0700 From: "David S. Miller" To: Jeff Garzik Cc: willy@debian.org, netdev@oss.sgi.com Subject: Re: [PATCH] ethtool_ops rev 4 Message-Id: <20030802172807.3d56b4ea.davem@redhat.com> In-Reply-To: <3F2C3C86.6000202@pobox.com> References: <20030801150232.GV22222@parcelfarce.linux.theplanet.co.uk> <20030801154021.GA7696@gtf.org> <20030801154656.GW22222@parcelfarce.linux.theplanet.co.uk> <20030801162536.GA18574@gtf.org> <20030802222145.GE22222@parcelfarce.linux.theplanet.co.uk> <3F2C3C86.6000202@pobox.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4464 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sat, 02 Aug 2003 18:34:46 -0400 Jeff Garzik wrote: > Matthew Wilcox wrote: > > +static inline void set_ethtool_ops(struct net_device *dev, struct ethtool_ops * > > ops) > > +{ > > + dev->ethtool_ops = ops; > > +} > > > It needs to be a macro for maximum flexibility. Yes, and please name it with capitol letters, ie. SET_ETHTOOL_OPS(), I have no idea why you used lower-case letters when Jeff and I referred to it consistently with caps. :-) From davem@redhat.com Sat Aug 2 18:37:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Aug 2003 18:37:35 -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 h731bUFl014661 for ; Sat, 2 Aug 2003 18:37:31 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id SAA10442; Sat, 2 Aug 2003 18:33:10 -0700 Date: Sat, 2 Aug 2003 18:33:10 -0700 From: "David S. Miller" To: chas3@users.sourceforge.net Cc: chas@cmf.nrl.navy.mil, mitch@sfgoth.com, netdev@oss.sgi.com Subject: Re: [Linux-ATM-General] Re: [atmdrvr zatm] Remove obsolete EXACT_TS support Message-Id: <20030802183310.05e2cbbc.davem@redhat.com> In-Reply-To: <200307311426.h6VEQgsG023826@ginger.cmf.nrl.navy.mil> References: <20030730225741.GA57991@gaz.sfgoth.com> <200307311426.h6VEQgsG023826@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4465 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Thu, 31 Jul 2003 10:23:58 -0400 chas williams wrote: > please apply to 2.6. zatm will now compile on smp. it might > actually work if someone had some hardware to test it. Applied. From jgarzik@pobox.com Sat Aug 2 20:14:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Aug 2003 20:14:49 -0700 (PDT) Received: from www.linux.org.uk (IDENT:KG4N4yt9e4roVKuUrU9+s/Z/FMeFYkHk@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h733EdFl022330 for ; Sat, 2 Aug 2003 20:14:40 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19j9KQ-0006uX-5l; Sun, 03 Aug 2003 04:14:38 +0100 Message-ID: <3F2C7E12.8070904@pobox.com> Date: Sat, 02 Aug 2003 23:14:26 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: Matthew Wilcox CC: netdev@oss.sgi.com Subject: Re: [PATCH] ethtool_ops rev 4 References: <20030801150232.GV22222@parcelfarce.linux.theplanet.co.uk> <20030801154021.GA7696@gtf.org> <20030801154656.GW22222@parcelfarce.linux.theplanet.co.uk> <20030801162536.GA18574@gtf.org> <20030802222145.GE22222@parcelfarce.linux.theplanet.co.uk> <3F2C3C86.6000202@pobox.com> <20030803002744.GF22222@parcelfarce.linux.theplanet.co.uk> In-Reply-To: <20030803002744.GF22222@parcelfarce.linux.theplanet.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4466 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Matthew Wilcox wrote: > On Sat, Aug 02, 2003 at 06:34:46PM -0400, Jeff Garzik wrote: > >>>diff -u include/linux/netdevice.h include/linux/netdevice.h >>>--- include/linux/netdevice.h 31 Jul 2003 13:06:23 -0000 >>>+++ include/linux/netdevice.h 2 Aug 2003 18:37:16 -0000 >>>@@ -477,6 +477,10 @@ >>> */ >>>#define SET_NETDEV_DEV(net, pdev) ((net)->class_dev.dev = (pdev)) >>> >>>+static inline void set_ethtool_ops(struct net_device *dev, struct >>>ethtool_ops * >>>ops) >>>+{ >>>+ dev->ethtool_ops = ops; >>>+} >> >> >>It needs to be a macro for maximum flexibility. > > > Nothing stops it being implemented as a macro in kcompat. Having it as > an inline function gives it argument typechecking which always gives me > the warm fuzzies. No, it _needs_ to be a macro for maximum flexibility. Most importantly, kcompat code may use '#ifndef SET_ETHTOOL_OPS' as a trigger, to signal that compat code is needed. No need for drivers to create tons of kernel-version-code ifdefs, just to test for when ethtool_ops appeared in 2.6, for when it starts appearing in 2.4 vendor backports, and (possibly) 2.4 itself. Also, doing it at the cpp level allows compat code to #undef it, if it _really_ knows what its doing, and the situation calls for it. >>Also, no need to convert in-kernel drivers over to using it... Let >>driver authors use it or not as they choose. > > > I took "Like pci_set_drvdata" as the most important part of your > argument... having everyone use it is no bad thing. Certainly. I have no real preferences either way, just noting that in-kernel drivers don't _need_ to use this macro. Jeff From greearb@candelatech.com Sat Aug 2 20:48:59 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Aug 2003 20:49:08 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-074.evrtwa1.dsl-verizon.net [4.33.45.74]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h733mwFl025313 for ; Sat, 2 Aug 2003 20:48:58 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h733mptf003818; Sat, 2 Aug 2003 20:48:52 -0700 Message-ID: <3F2C8623.2080106@candelatech.com> Date: Sat, 02 Aug 2003 20:48:51 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030718 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sascha Schumann CC: "'netdev@oss.sgi.com'" Subject: Re: 2.4.21: bug report for tg3: tx lockup when changing MTU References: <3F2AEFBF.3040604@candelatech.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4467 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Sascha Schumann wrote: >>Kernel is 2.4.21 + custom patches (which should not affect tg3). >> >>lspci says the NIC is: Altima AC9100 (rev 15) > > > [1] says that the AC9100 based Netgear GA302T cards don't > support jumbo frames. I'm seeing regular lockups once > packets larger than 1500bytes flow through the NIC. > > It would be cool though if this turned out to be a driver > limitation and not a (crippled) chipset issue. It definately handles 4000 byte frames just fine, you just need to ifdown and ifup it after changing the MTU much of the time...or maybe only when running it under heavy load when you make the MTU change... Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb@candelatech.com Sat Aug 2 21:01:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Aug 2003 21:01:54 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-074.evrtwa1.dsl-verizon.net [4.33.45.74]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7341iFl026650 for ; Sat, 2 Aug 2003 21:01:44 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h7341Vtf005412; Sat, 2 Aug 2003 21:01:31 -0700 Message-ID: <3F2C891B.7080004@candelatech.com> Date: Sat, 02 Aug 2003 21:01:31 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030718 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: Nivedita Singhvi , Werner Almesberger , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: TOE brain dump References: <20030802140444.E5798@almesberger.net> <3F2BF5C7.90400@us.ibm.com> <3F2C0C44.6020002@pobox.com> In-Reply-To: <3F2C0C44.6020002@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4468 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Jeff Garzik wrote: > So, fix the other end of the pipeline too, otherwise this fast network > stuff is flashly but pointless. If you want to serve up data from disk, > then start creating PCI cards that have both Serial ATA and ethernet > connectors on them :) Cut out the middleman of the host CPU and host I for one would love to see something like this, and not just Serial ATA.. but maybe 8x Serial ATA and RAID :) Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From scott.feldman@intel.com Sat Aug 2 21:34:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Aug 2003 21:34:58 -0700 (PDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h734YmFl028503 for ; Sat, 2 Aug 2003 21:34:49 -0700 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h734Sid08681 for ; Sun, 3 Aug 2003 04:28:44 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h733wGY02567 for ; Sun, 3 Aug 2003 03:58:17 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 M2003080221344226801 for ; Sat, 02 Aug 2003 21:34:42 -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); Sat, 2 Aug 2003 21:34:42 -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: e100 "Ferguson" release Date: Sat, 2 Aug 2003 21:34:42 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: e100 "Ferguson" release Thread-Index: AcNZeI636C/uaYjsSwqQ/jrIhuMDyw== From: "Feldman, Scott" To: X-OriginalArrivalTime: 03 Aug 2003 04:34:42.0802 (UTC) FILETIME=[8F15BD20:01C35978] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h734YmFl028503 X-archive-position: 4469 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 New development version: http://sf.net/projects/e1000, e100-3.0.0_dev11.tar.gz Many thanks to JC [jchapman@katalix.com] for exploring the small packet performance w/ and w/o NAPI. This version includes one of his optimization; others may follow, but I wanted to get this goodness out now. * added opportunistic fast loop (no udelays) in e100_exec_cmd to wait for previous cmd to be accepted before queuing next cmd. Boost small packet performance. [jchapman@katalix.com]. * Use correct versions of dev_kfree_skb for depending on possible contexts. [jchapman@katalix.com]. * Added SET_NETDEV_DEV(). Looking for more testing on non-IA archs, power management, cardbus nics, and WoL. -scott From willy@www.linux.org.uk Sat Aug 2 22:01:08 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Aug 2003 22:01:14 -0700 (PDT) Received: from www.linux.org.uk (IDENT:xUszKN2jPgzXzfcq0ScA0iCxK31fnXwn@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h73516Fl030805 for ; Sat, 2 Aug 2003 22:01:08 -0700 Received: from willy by www.linux.org.uk with local (Exim 4.14) id 19j6iu-0005dM-4h; Sun, 03 Aug 2003 01:27:44 +0100 Date: Sun, 3 Aug 2003 01:27:44 +0100 From: Matthew Wilcox To: Jeff Garzik Cc: Matthew Wilcox , netdev@oss.sgi.com Subject: Re: [PATCH] ethtool_ops rev 4 Message-ID: <20030803002744.GF22222@parcelfarce.linux.theplanet.co.uk> References: <20030801150232.GV22222@parcelfarce.linux.theplanet.co.uk> <20030801154021.GA7696@gtf.org> <20030801154656.GW22222@parcelfarce.linux.theplanet.co.uk> <20030801162536.GA18574@gtf.org> <20030802222145.GE22222@parcelfarce.linux.theplanet.co.uk> <3F2C3C86.6000202@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F2C3C86.6000202@pobox.com> User-Agent: Mutt/1.4.1i X-archive-position: 4470 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@debian.org Precedence: bulk X-list: netdev On Sat, Aug 02, 2003 at 06:34:46PM -0400, Jeff Garzik wrote: > >diff -u include/linux/netdevice.h include/linux/netdevice.h > >--- include/linux/netdevice.h 31 Jul 2003 13:06:23 -0000 > >+++ include/linux/netdevice.h 2 Aug 2003 18:37:16 -0000 > >@@ -477,6 +477,10 @@ > > */ > > #define SET_NETDEV_DEV(net, pdev) ((net)->class_dev.dev = (pdev)) > > > >+static inline void set_ethtool_ops(struct net_device *dev, struct > >ethtool_ops * > >ops) > >+{ > >+ dev->ethtool_ops = ops; > >+} > > > It needs to be a macro for maximum flexibility. Nothing stops it being implemented as a macro in kcompat. Having it as an inline function gives it argument typechecking which always gives me the warm fuzzies. > Also, no need to convert in-kernel drivers over to using it... Let > driver authors use it or not as they choose. I took "Like pci_set_drvdata" as the most important part of your argument... having everyone use it is no bad thing. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From jsanchez@cs.ucf.edu Sat Aug 2 22:50:58 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Aug 2003 22:51:04 -0700 (PDT) Received: from longwood.cs.ucf.edu (longwood.cs.ucf.edu [132.170.108.1]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h735ouFl002605 for ; Sat, 2 Aug 2003 22:50:57 -0700 Received: from mobile (eola [132.170.108.2]) by longwood.cs.ucf.edu (8.12.2/8.12.2) with ESMTP id h735oqB4001424 for ; Sun, 3 Aug 2003 01:50:52 -0400 (EDT) Subject: Re: [Bug 1030] New: racoon causes oops when implementing IPSec key From: Justin Sanchez To: netdev@oss.sgi.com In-Reply-To: <20030802212018.B14141@electric-eye.fr.zoreil.com> References: <89550000.1059833972@[10.10.2.4]> <20030802163333.A12217@electric-eye.fr.zoreil.com> <1059850039.1187.2.camel@mobile> <20030802212018.B14141@electric-eye.fr.zoreil.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-2Y8LE63gCCNUG9OvqJTX" X-Mailer: Ximian Evolution 1.0.8 Date: 03 Aug 2003 01:51:22 -0400 Message-Id: <1059889883.1187.15.camel@mobile> Mime-Version: 1.0 X-archive-position: 4471 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jsanchez@cs.ucf.edu Precedence: bulk X-list: netdev --=-2Y8LE63gCCNUG9OvqJTX Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi. I had this problem on 2.6.0-test1 and -test2 and -test2-bk2, so I'll try to report it. I'm new to the scene, so I apologize in advance for this post. Background. 2 machines. e100 cards on each, if it matters. ipsec-tools 0.2.2. I give each of them directives to use esp and ah in transport mode. I turn on racoon on each box. I ping. Both panic. Following is about the message:. Unable to handle kernel NULL pointer dereference at virtual address 00000000 printing eip: c02bbd06 *pde =3D 00000000 Oops: 0000 [#1] CPU: 0 EIP: 0060:[] Not tainted EFLAGS: 00010206 EIP is at memcpy+0x1e/0x39 eax: 00000018 ebx: f6fe8a00 ecx: 00000006 edx: 00000000 esi: 00000000 edi: 00000000 ebp: c0562520 esp: f6fb5ccc ds: 007b es: 007b ss:0068 Process racoon (pid: 418, threadinfo=3Df6fb4000 task=3Df6fbb300) Stack: Call Trace: xfrm_state_update pfkey_add parse_exthdrs pfkey_process pfkey_sendmsg sock_sendmsg verify_iovec sys_sendmsg sockfd_lookup sys_sendto sys_getsockname __pollwait update_process sys_send sys_socketcall syscall_call Code: f3 a5 a8 02 74 02 66 a5 a8 01 74 01 a4 89 d0 8b 74 24 02 8b <0>Kernel panic: Fatal exception in interrupt In interrupt handler =3D not syncing If you want the full text of it, its at 67.9.9.32/oops.jpg. I'm probably just doing something stupid... On Sat, 2003-08-02 at 15:20, Francois Romieu wrote: > Justin Sanchez : > [...] > > How current? I've just seen it in -test2-bk2. >=20 > Forwarded to davem@redhat.com. >=20 > You may consider posting the data of the bug-report updated to -test2-bk2 > on netdev@oss.sgi.com. >=20 > -- > Ueimor >=20 --=-2Y8LE63gCCNUG9OvqJTX Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/LKLaiLmb/rWLQdQRAmWuAJ4g7wXLF1O+gFi+jrLeThezwWAsywCgkiao YUjA6YtWFR9yOVO/5JnRKZc= =6zEM -----END PGP SIGNATURE----- --=-2Y8LE63gCCNUG9OvqJTX-- From davem@redhat.com Sat Aug 2 23:00:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Aug 2003 23:00:32 -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 h7360SFl003649 for ; Sat, 2 Aug 2003 23:00:29 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id WAA10944; Sat, 2 Aug 2003 22:56:20 -0700 Date: Sat, 2 Aug 2003 22:56:19 -0700 From: "David S. Miller" To: Daniel Ritz Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH 2.6] Fix IPv6 esp mem leak in esp6_input Message-Id: <20030802225619.17d477e3.davem@redhat.com> In-Reply-To: <200308021350.23342.daniel.ritz@gmx.ch> References: <200308021350.23342.daniel.ritz@gmx.ch> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4472 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sat, 2 Aug 2003 13:50:23 +0200 Daniel Ritz wrote: > fixes a mem leak in esp6_input() in the error paths. and return -ENOMEM, > not -EINVAL when out of memory. against 2.6.0-test2-bk Patch applied, thanks Daniel. From davem@redhat.com Sat Aug 2 23:05:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Aug 2003 23:05: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 h73652Fl004305 for ; Sat, 2 Aug 2003 23:05:03 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id WAA10978; Sat, 2 Aug 2003 22:59:48 -0700 Date: Sat, 2 Aug 2003 22:59:48 -0700 From: "David S. Miller" To: Ville Nuorvala Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [PATCH] IPV6: Incorrect hoplimit in ip6_push_pending_frames() Message-Id: <20030802225948.01c96fb7.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4473 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 1 Aug 2003 14:15:21 +0300 (EEST) Ville Nuorvala wrote: > I noticed the hop limit passed to ip6_append_data() isn't used by > ip6_push_pending_frames(), which might lead to unexpected behavior with > multicast and (ipv6-in-ipv6) tunneled packets. This patch (against Linux > 2.6.0-test2 and cset 1.1595) fixes the problem. Applied, thank you. From jgarzik@pobox.com Sat Aug 2 23:13:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Aug 2003 23:13:06 -0700 (PDT) Received: from www.linux.org.uk (IDENT:brcXRjmAJ7+L5OReqrzNa8QAiyIV4/9i@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h736D1Fl005185 for ; Sat, 2 Aug 2003 23:13:02 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19jC72-0002bL-FW; Sun, 03 Aug 2003 07:13:00 +0100 Message-ID: <3F2CA7E1.6060800@pobox.com> Date: Sun, 03 Aug 2003 02:12:49 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: "Feldman, Scott" CC: netdev@oss.sgi.com Subject: Re: e100 "Ferguson" release References: <3F2CA65F.8060105@pobox.com> In-Reply-To: <3F2CA65F.8060105@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4474 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Jeff Garzik wrote: > * (extremely minor) some people (like me :)) consider dead reads like > the readb() call in e100_write_flush er, that was a bit incomplete. completing: ... needing to be marked explicitly with a "(void) " prefix, indicating it is intentionally a dead read. Maintainer's call, ultimately, though... From alan@storlinksemi.com Sat Aug 2 23:23:08 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Aug 2003 23:23:12 -0700 (PDT) Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h736N7Fl006172 for ; Sat, 2 Aug 2003 23:23:08 -0700 Received: from cpe-66-1-155-95.ca.sprintbbd.net (HELO AlanLap) (alansuntzishih@66.1.155.95 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 3 Aug 2003 06:23:06 -0000 From: "Alan Shih" To: "Ben Greear" , "Jeff Garzik" Cc: "Nivedita Singhvi" , "Werner Almesberger" , , Subject: RE: TOE brain dump Date: Sat, 2 Aug 2003 23:22:52 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 In-Reply-To: <3F2C891B.7080004@candelatech.com> X-archive-position: 4475 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@storlinksemi.com Precedence: bulk X-list: netdev A DMA xfer that fills the NIC pipe with IDE source. That's not very hard... need a lot of bufferring/FIFO though. May require large modification to the file serving applications? Alan -----Original Message----- From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Ben Greear Sent: Saturday, August 02, 2003 9:02 PM To: Jeff Garzik Cc: Nivedita Singhvi; Werner Almesberger; netdev@oss.sgi.com; linux-kernel@vger.kernel.org Subject: Re: TOE brain dump Jeff Garzik wrote: > So, fix the other end of the pipeline too, otherwise this fast network > stuff is flashly but pointless. If you want to serve up data from disk, > then start creating PCI cards that have both Serial ATA and ethernet > connectors on them :) Cut out the middleman of the host CPU and host I for one would love to see something like this, and not just Serial ATA.. but maybe 8x Serial ATA and RAID :) Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From jgarzik@pobox.com Sat Aug 2 23:40:47 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Aug 2003 23:41:00 -0700 (PDT) Received: from www.linux.org.uk (IDENT:NELjEc2FssOMkU3BYyvJ/bjDS2/IyxUi@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h736ejFl007715 for ; Sat, 2 Aug 2003 23:40:46 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19jCXs-0002jd-97; Sun, 03 Aug 2003 07:40:44 +0100 Message-ID: <3F2CAE61.7070401@pobox.com> Date: Sun, 03 Aug 2003 02:40:33 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com, linux-kernel@vger.kernel.org CC: Werner Almesberger , Nivedita Singhvi Subject: Re: TOE brain dump References: <20030802140444.E5798@almesberger.net> <3F2BF5C7.90400@us.ibm.com> <3F2C0C44.6020002@pobox.com> <20030802184901.G5798@almesberger.net> In-Reply-To: <20030802184901.G5798@almesberger.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4476 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 Werner Almesberger wrote: > Jeff Garzik wrote: > >>jabbering at the same time. TCP is a "one size fits all" solution, but >>it doesn't work well for everyone. > > > But then, ten "optimized xxPs" that work well in two different > scenarios each, but not so good in the 98 others, wouldn't be > much fun either. > > It's been tried a number of times. Usually, real life sneaks > in at one point or another, leaving behind a complex mess. > When they've sorted out these problems, regular TCP has caught > up with the great optimized transport protocols. At that point, > they return to their niche, sometimes tail between legs and > muttering curses, sometimes shaking their fist and boldly > proclaiming how badly they'll rub TCP in the dirt in the next > round. Maybe they shed off some of the complexity, and trade it > for even more aggressive optimization, which puts them into > their niche even more firmly. Eventually, they fade away. > > There are cases where TCP doesn't work well, like a path of > badly mismatched link layers, but such paths don't treat any > protocol following the end-to-end principle kindly. > > Another problem of TCP is that it has grown a bit too many > knobs you need to turn before it works over your really fast > really long pipe. (In one of the OLS after dinner speeches, > this was quite appropriately called the "wizard gap".) > > >>It's obviously not over a WAN... > > > That's why NFS turned off UDP checksums ;-) As soon as you put > it on IP, it will crawl to distances you didn't imagine in your > wildest dreams. It always does. Really fast, really long pipes in practice don't exist for 99.9% of all Internet users. When you approach traffic levels that push you want to offload most of the TCP net stack, then TCP isn't the right solution for you anymore, all things considered. The Linux net stack just isn't built to be offloaded. TOE engines will either need to (1) fall back to Linux software for all-but-the-common case (otherwise netfilter, etc. break), or, (2) will need to be hideously complex beasts themselves. And I can't see ASIC and firmware designers being excited about implementing netfilter on a PCI card :) Unfortunately some vendors seem to choosing TOE option #3: TCP offload which introduces many limitations (connection limits, netfilter not supported, etc.) which Linux never had before. Vendors don't seem to realize TOE has real potential to damage the "good network neighbor" image the net stack has. The Linux net stack's behavior is known, documented, predictable. TOE changes all that. There is one interesting TOE solution, that I have yet to see created: run Linux on an embedded processor, on the NIC. This stripped-down Linux kernel would perform all the header parsing, checksumming, etc. into the NIC's local RAM. The Linux OS driver interface becomes a virtual interface with a large MTU, that communicates from host CPU to NIC across the PCI bus using jumbo-ethernet-like data frames. Management frames would control the ethernet interface on the other side of the PCI bus "tunnel". >>So, fix the other end of the pipeline too, otherwise this fast network >>stuff is flashly but pointless. If you want to serve up data from disk, >>then start creating PCI cards that have both Serial ATA and ethernet >>connectors on them :) Cut out the middleman of the host CPU and host >>memory bus instead of offloading portions of TCP that do not need to be >>offloaded. > > > That's a good point. A hierarchical memory structure can help > here. Moving one end closer to the hardware, and letting it > know (e.g. through sendfile) that also the other end is close > (or can be reached more directly that through some hopelessly > crowded main bus) may help too. Definitely. Jeff From jgarzik@pobox.com Sat Aug 2 23:41:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 02 Aug 2003 23:41:53 -0700 (PDT) Received: from www.linux.org.uk (IDENT:r2QFDDBea5MOAjl2dLgz0iK1HyGBBbZ4@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h736fmFl008008 for ; Sat, 2 Aug 2003 23:41:49 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19jCYr-0002jy-5D; Sun, 03 Aug 2003 07:41:45 +0100 Message-ID: <3F2CAE9D.5090401@pobox.com> Date: Sun, 03 Aug 2003 02:41:33 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: Alan Shih CC: Ben Greear , Nivedita Singhvi , Werner Almesberger , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: TOE brain dump References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4477 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Alan Shih wrote: > A DMA xfer that fills the NIC pipe with IDE source. That's not very hard... > need a lot of bufferring/FIFO though. May require large modification to the > file serving applications? Nope, that's using the existing sendfile(2) facility. Jeff From jgarzik@pobox.com Sun Aug 3 00:00:30 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 00:00:36 -0700 (PDT) Received: from www.linux.org.uk (IDENT:f0VnXDXUgPOR/pJVSNM/K9f0DO93mSKY@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7370SFl009721 for ; Sun, 3 Aug 2003 00:00:29 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19jC0o-0002Yz-G8; Sun, 03 Aug 2003 07:06:34 +0100 Message-ID: <3F2CA65F.8060105@pobox.com> Date: Sun, 03 Aug 2003 02:06:23 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: "Feldman, Scott" CC: netdev@oss.sgi.com Subject: Re: e100 "Ferguson" release References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4478 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Comments: * Given that e100 is only 10/100 hardware, I like the decision to not support rx/tx checksumming and zero-copy. Particularly with some e100's, this eliminates various worries related to chip errata. And as with any "do it in software" solution, you guarantee that the chip never screws up and "acks" a checksum incorrectly, thus passing corrupted data up into the net stack. * (API) Does the out-of-tx-resources condition in e100_xmit_frame ever really happen? I am under the impression that returning non-zero in ->hard_start_xmit results in the packet sometimes being requeued and sometimes dropped. I prefer to guarantee a more-steady state, by simply dropping the packet unconditionally, when this uncommon condition occurs. So, I would a) mark the failure condition with unlikely(), and b) if the condition occurs, simply drop the packet (tx_dropped++, kfree skb), and return zero. Though, ultimately, I wish the net stack would support some way to _guarantee_ that the skb is requeued for transmit. Some packet schedulers in the kernel will drop the skb even if the ->hard_start_xmit return code indicates "requeue". This makes sense from the rule of "skbs are lossy, and can be dropped"... but it really sucks on hardware where unexpected -- but temporary -- loss of TX resources occurs. One can prevent 20-50% (or more) packet loss on certain classes of connections, simply by being able to tell the net stack "hey, if I could go back in time and issue a netif_stop_queue, before you called ->hard_start_xmit, I would" :) * (minor) for completeness, you should limit the PCI class in the pci_device_id table to PCI_CLASS_NETWORK_ETHERNET. There are one-in-a-million cases where this matters, but it's usually a BIOS bug. Still, it's there in pci_device_id table, and it's an easy change, so might as well use it. This is a good janitor task for other PCI net drivers, too. * (long term) I really like Ben H.'s work in drivers/net/sungem_phy.[ch] -- and similar benh code in ibm_emac -- and want to make his code generic for most MII phys. Just something to read and keep in mind. * (style) your struct config definition is terribly clever. perhaps too clever, making it unreadable? Not a specific complaint, mind you, just something that caught my eye. * (minor) in tg3, my own benchmarks and experiments showed it helped to explictly use ____cacheline_aligned markers when defining certain sections of members in struct tg3 (or struct nic, in e100's case). You already clearly pay attention to member layout WRT cache effects, but if you have a clear dividing line, or lines, in struct nic you can use _____cacheline_aligned for even greater benefit. At a minimum test it with a cpu-usage-measuring benchmark like ttcp, though, of course :) IIRC I divided tg3's struct into rx, tx, and "other" sections. * (extremely minor) some people (like me :)) consider dead reads like the readb() call in e100_write_flush * (major?) Aren't there some clunky e100 adapters that don't do MMIO? Do we care? * I would love to see feedback from people testing this driver on ppc64 and sparc64, particularly. * (style, minor) My eyes would prefer functions like e100_hw_reset to have a few more blank lines in them, spreading code+comment blocks out a bit. * (extremely minor) one wonders if you really need the write flush in mdio_ctrl. If the flush is removed, the same net effect appears to occur. * (boring but needed) convert all the magic numbers in e100_configure into constants, or at least add comments describing the magic numbers. If the value is just one bit, you might simply append "/* true */", for example. The general idea is to make the "member name = value" list a little bit more readable to somebody who doesn't know the hardware, and struct config, intimately. * IIRC Donald's MII phy scanning code scans MII phy ids like this: 1..31,0. Or maybe 1..31, and then 0 iff no MII phys were found. In general I would prefer to follow his eepro100.c probe order. Some phys need this because they will report on both phy id #0 (which is magical) and phy id #(non-zero). Donald would know more than me, here. * I like the e100_exec_cb stuff, with the callbacks. * Is it easy to support MII phy interrupts? It would be nice to get a callback that was handled immediately, on phys that do support such interrupts. * do we care about spinlocks around the update_stats and get_stats code? * (bugs) in e100_up, you should undo mod_timer [major] and netif_start_queue [minor], if request_irq fails. And maybe stop the receiver, too? * for all constants 0xffffffff (and others as well if you so choose), prefer the C99 suffix to a cast. This is particularly relevant in pci_set_dma_mask calls, where one should be using 0xffffffffULL, but applies to other constants as well. * (potential races) in e100_probe, you want to call register_netdev as basically the last operation that can fail, if possible. Particularly, you need to move the PCI API operations above register_netdev. Remember, register_netdev winds up calling /sbin/hotplug, which in turn calls programs that will want to start using the interface. So you need to have everything set up by that point, really. * in e100_probe, "if(nic->csr == 0UL) {" should really just test for NULL, because ioremap is defined to return a pointer... * (minor) use a netif_msg_xxx wrapper/constant in e100_init_module test? From greearb@candelatech.com Sun Aug 3 00:32:09 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 00:32:19 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-074.evrtwa1.dsl-verizon.net [4.33.45.74]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h737W8Fl012468 for ; Sun, 3 Aug 2003 00:32:09 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h737W1tf031554; Sun, 3 Aug 2003 00:32:01 -0700 Message-ID: <3F2CBA71.2070503@candelatech.com> Date: Sun, 03 Aug 2003 00:32:01 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030718 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: "Feldman, Scott" , netdev@oss.sgi.com Subject: Re: e100 "Ferguson" release References: <3F2CA65F.8060105@pobox.com> In-Reply-To: <3F2CA65F.8060105@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4479 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Jeff Garzik wrote: > Comments: > * (API) Does the out-of-tx-resources condition in e100_xmit_frame ever > really happen? I am under the impression that returning non-zero in > ->hard_start_xmit results in the packet sometimes being requeued and > sometimes dropped. I prefer to guarantee a more-steady state, by simply > dropping the packet unconditionally, when this uncommon condition > occurs. So, I would > a) mark the failure condition with unlikely(), and > b) if the condition occurs, simply drop the packet (tx_dropped++, kfree > skb), and return zero. > > Though, ultimately, I wish the net stack would support some way to > _guarantee_ that the skb is requeued for transmit. Some packet > schedulers in the kernel will drop the skb even if the ->hard_start_xmit > return code indicates "requeue". This makes sense from the rule of > "skbs are lossy, and can be dropped"... but it really sucks on hardware > where unexpected -- but temporary -- loss of TX resources occurs. One > can prevent 20-50% (or more) packet loss on certain classes of > connections, simply by being able to tell the net stack "hey, if I could > go back in time and issue a netif_stop_queue, before you called > ->hard_start_xmit, I would" :) Although I have not tried this latest patch, the existing e100 and e1000 in 2.4.21 seldom seem to return true to this method: netif_queue_stopped(odev), even when the next hard_start_xmit() call fails. For instance, this is the code I use in pktgen.c: if (!netif_queue_stopped(odev)) { if (odev->hard_start_xmit(next->skb, odev)) { if (net_ratelimit()) { printk(KERN_INFO "Hard xmit error\n"); } next->errors++; next->last_ok = 0; queue_stopped++; } else { queue_stopped = 0; next->last_ok = 1; next->sofar++; next->tx_bytes += (next->cur_pkt_size + 4); /* count csum */ } With e100 and e1000, I see the very large numbers of the hard_start_xmit failure when running very high packets-per-second rates (small packets). I see virtually no failures with tulip. pktgen knows how to re-queue, but it's curious it has to so often. For code that does not requeue, this could be even more of a bummer. To point b), I think if the driver accepts the packet in hard_start_xmit, it should be able to send the packet out, otherwise return the 'requeue' value and let the calling code know. It is very important to me, at least, to know if a packet has really been sent or not. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From davem@redhat.com Sun Aug 3 00:36:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 00:37:01 -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 h737aqFl013180 for ; Sun, 3 Aug 2003 00:36:53 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id AAA11387; Sun, 3 Aug 2003 00:32:39 -0700 Date: Sun, 3 Aug 2003 00:32:39 -0700 From: "David S. Miller" To: Ben Greear Cc: jgarzik@pobox.com, scott.feldman@intel.com, netdev@oss.sgi.com Subject: Re: e100 "Ferguson" release Message-Id: <20030803003239.4257ef24.davem@redhat.com> In-Reply-To: <3F2CBA71.2070503@candelatech.com> References: <3F2CA65F.8060105@pobox.com> <3F2CBA71.2070503@candelatech.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4480 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 > Although I have not tried this latest patch, the existing e100 and e1000 in > 2.4.21 seldom seem to return true to this method: netif_queue_stopped(odev), > even when the next hard_start_xmit() call fails. Returning an error from hard_start_xmit() from normal ethernet drivers is, frankly, a driver bug and should never happen. I don't know if there is somehow something special about the e100, but even if there is hard_start_xmit() failures can be avoided by properly doing netif_queue_{stop,wakeup}() in the right places. From david.lang@digitalinsight.com Sun Aug 3 01:27:39 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 01:27:50 -0700 (PDT) Received: from warden.diginsite.com (warden-p.diginsite.com [208.29.163.248]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h738RcFl017767 for ; Sun, 3 Aug 2003 01:27:39 -0700 Received: from wlvims01.diginsite.com by warden.diginsite.com via smtpd (for oss.SGI.COM [192.48.159.27]) with SMTP; Sun, 3 Aug 2003 01:27:38 -0700 Received: from calexc01.digitalinsight.com ([10.200.0.20]) by wlvims01.digitalinsight.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Sun, 3 Aug 2003 01:26:48 -0700 Received: by calexc01.diginsite.com with Internet Mail Service (5.5.2653.19) id ; Sun, 3 Aug 2003 01:27:31 -0700 Received: from dlang.diginsite.com ([10.201.10.67]) by wlvexc00.digitalinsight.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id P0FXW757; Sun, 3 Aug 2003 01:27:21 -0700 From: David Lang To: Alan Shih Cc: Ben Greear , Jeff Garzik , Nivedita Singhvi , Werner Almesberger , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Date: Sun, 3 Aug 2003 01:25:48 -0700 (PDT) Subject: RE: TOE brain dump In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4481 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: david.lang@digitalinsight.com Precedence: bulk X-list: netdev do you really want the processor on the card to be tunning apache/NFS/Samba/etc ? putting enough linux on the card to act as a router (which would include the netfilter stuff) is one thing. putting the userspace code that interfaces with the outside world for file transfers is something else. if you really want the disk connected to your network card you are just talking a low-end linux box. forget all this stuff about it being on a card and just use a full box (economys of scale will make this cheaper) making a firewall that's a core system with a dozen slave systems attached to it (the network cards) sounds like the type of clustering that Linux has been used for for compute nodes. complicated to setup, but extremely powerful and scalable once configured. if you want more then a router on the card then Alan Cox is right, just add another processor to the system, it's easier and cheaper. David Lang On Sat, 2 Aug 2003, Alan Shih wrote: > Date: Sat, 2 Aug 2003 23:22:52 -0700 > From: Alan Shih > To: Ben Greear , Jeff Garzik > Cc: Nivedita Singhvi , > Werner Almesberger , netdev@oss.sgi.com, > linux-kernel@vger.kernel.org > Subject: RE: TOE brain dump > > A DMA xfer that fills the NIC pipe with IDE source. That's not very hard... > need a lot of bufferring/FIFO though. May require large modification to the > file serving applications? > > Alan > > -----Original Message----- > From: linux-kernel-owner@vger.kernel.org > [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Ben Greear > Sent: Saturday, August 02, 2003 9:02 PM > To: Jeff Garzik > Cc: Nivedita Singhvi; Werner Almesberger; netdev@oss.sgi.com; > linux-kernel@vger.kernel.org > Subject: Re: TOE brain dump > > > Jeff Garzik wrote: > > > So, fix the other end of the pipeline too, otherwise this fast network > > stuff is flashly but pointless. If you want to serve up data from disk, > > then start creating PCI cards that have both Serial ATA and ethernet > > connectors on them :) Cut out the middleman of the host CPU and host > > I for one would love to see something like this, and not just Serial ATA.. > but maybe 8x Serial ATA and RAID :) > > Ben > > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > From willy@www.linux.org.uk Sun Aug 3 07:57:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 07:57:05 -0700 (PDT) Received: from www.linux.org.uk (IDENT:dxP8jV70pveQkX3/KA355Yf9YCtbJJSj@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h73EuwFl025115 for ; Sun, 3 Aug 2003 07:57:00 -0700 Received: from willy by www.linux.org.uk with local (Exim 4.14) id 19jKI4-0006o5-8W; Sun, 03 Aug 2003 15:56:56 +0100 Date: Sun, 3 Aug 2003 15:56:56 +0100 From: Matthew Wilcox To: Jeff Garzik Cc: Matthew Wilcox , netdev@oss.sgi.com Subject: Re: [PATCH] ethtool_ops rev 4 Message-ID: <20030803145656.GI22222@parcelfarce.linux.theplanet.co.uk> References: <20030801150232.GV22222@parcelfarce.linux.theplanet.co.uk> <20030801154021.GA7696@gtf.org> <20030801154656.GW22222@parcelfarce.linux.theplanet.co.uk> <20030801162536.GA18574@gtf.org> <20030802222145.GE22222@parcelfarce.linux.theplanet.co.uk> <3F2C3C86.6000202@pobox.com> <20030803002744.GF22222@parcelfarce.linux.theplanet.co.uk> <3F2C7E12.8070904@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F2C7E12.8070904@pobox.com> User-Agent: Mutt/1.4.1i X-archive-position: 4482 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@debian.org Precedence: bulk X-list: netdev On Sat, Aug 02, 2003 at 11:14:26PM -0400, Jeff Garzik wrote: > Matthew Wilcox wrote: > >Nothing stops it being implemented as a macro in kcompat. Having it as > >an inline function gives it argument typechecking which always gives me > >the warm fuzzies. > > No, it _needs_ to be a macro for maximum flexibility. > > Most importantly, kcompat code may use '#ifndef SET_ETHTOOL_OPS' as a > trigger, to signal that compat code is needed. No need for drivers to > create tons of kernel-version-code ifdefs, just to test for when > ethtool_ops appeared in 2.6, for when it starts appearing in 2.4 vendor > backports, and (possibly) 2.4 itself. Also, doing it at the cpp level > allows compat code to #undef it, if it _really_ knows what its doing, > and the situation calls for it. OK. At this point, I really feel like I'm getting in the way and hindering more than I'm helping. Can I pass the torch to you and let you finish the job? -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From wsx@6com.sk Sun Aug 3 08:44:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 08:44:40 -0700 (PDT) Received: from mail.6com.sk (cement.ksp.edi.fmph.uniba.sk [158.195.16.151]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h73FiXFl028554 for ; Sun, 3 Aug 2003 08:44:33 -0700 Received: by mail.6com.sk (Postfix, from userid 501) id 84173630E; Sun, 3 Aug 2003 17:44:27 +0200 (CEST) Date: Sun, 3 Aug 2003 17:44:27 +0200 From: Jan Oravec To: netdev@oss.sgi.com Subject: problem setting net.ipvX.conf.all.forwarding via sysctl() system call Message-ID: <20030803154427.GA12926@wsx.ksp.sk> Reply-To: Jan Oravec Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: UNIX X-archive-position: 4483 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jan.oravec@6com.sk Precedence: bulk X-list: netdev Hello, When net.ipvX.conf.all.forwarding is enabled via sysctl() system call, forwarding is not enabled on all interfaces as it is when it is changed using /proc filesystem. For IPv6, it is obviously because sysctl 'strategy' handler is not defined. For IPv4, it is because ipv4_sysctl_forward_strategy only copy new value to check whether it has changed and does not update ipv4_devconf.forwarding before calling inet_forward_change(). (it is copied internally by sysctl after ipv4_sysctl_forward_strategy because we return positive number) I am not good in kernel parallel computing strategy, whether it requires some locking or it is safe to do: --- sysctl_net_ipv4.c.old 2003-08-03 17:37:44.000000000 +0200 +++ sysctl_net_ipv4.c 2003-08-03 17:38:18.000000000 +0200 @@ -109,8 +109,9 @@ static int ipv4_sysctl_forward_strategy( } } + ipv4_devconf.forwarding=new; inet_forward_change(); - return 1; + return 0; } ctl_table ipv4_table[] = { Best Regards, -- Jan Oravec XS26 coordinator 6COM s.r.o. 'Access to IPv6' http://www.6com.sk http://www.xs26.net From jgarzik@pobox.com Sun Aug 3 11:00:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 11:00:36 -0700 (PDT) Received: from www.linux.org.uk (IDENT:sjW7I344dNw6uUHLQE/tIbYI710RnggI@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h73I0RFl007871 for ; Sun, 3 Aug 2003 11:00:28 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19jMMR-0007pt-LH; Sun, 03 Aug 2003 18:09:35 +0100 Message-ID: <3F2D41B7.7040205@pobox.com> Date: Sun, 03 Aug 2003 13:09:11 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: Matthew Wilcox CC: netdev@oss.sgi.com Subject: Re: [PATCH] ethtool_ops rev 4 References: <20030801150232.GV22222@parcelfarce.linux.theplanet.co.uk> <20030801154021.GA7696@gtf.org> <20030801154656.GW22222@parcelfarce.linux.theplanet.co.uk> <20030801162536.GA18574@gtf.org> <20030802222145.GE22222@parcelfarce.linux.theplanet.co.uk> <3F2C3C86.6000202@pobox.com> <20030803002744.GF22222@parcelfarce.linux.theplanet.co.uk> <3F2C7E12.8070904@pobox.com> <20030803145656.GI22222@parcelfarce.linux.theplanet.co.uk> In-Reply-To: <20030803145656.GI22222@parcelfarce.linux.theplanet.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4484 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Matthew Wilcox wrote: > On Sat, Aug 02, 2003 at 11:14:26PM -0400, Jeff Garzik wrote: > >>Matthew Wilcox wrote: >> >>>Nothing stops it being implemented as a macro in kcompat. Having it as >>>an inline function gives it argument typechecking which always gives me >>>the warm fuzzies. >> >>No, it _needs_ to be a macro for maximum flexibility. >> >>Most importantly, kcompat code may use '#ifndef SET_ETHTOOL_OPS' as a >>trigger, to signal that compat code is needed. No need for drivers to >>create tons of kernel-version-code ifdefs, just to test for when >>ethtool_ops appeared in 2.6, for when it starts appearing in 2.4 vendor >>backports, and (possibly) 2.4 itself. Also, doing it at the cpp level >>allows compat code to #undef it, if it _really_ knows what its doing, >>and the situation calls for it. > > > OK. At this point, I really feel like I'm getting in the way and > hindering more than I'm helping. Can I pass the torch to you and let > you finish the job? Sorry to give that impression :( I think we're pretty much "there". But if you wanna hand it off to me for the last little bits, and merging, that's fine too. I'll leave it up to you. Jeff From werner@almesberger.net Sun Aug 3 11:05:57 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 11:06:00 -0700 (PDT) Received: from host.almesberger.net (almesberger.net [63.105.73.239] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h73I5uFl008556 for ; Sun, 3 Aug 2003 11:05:57 -0700 Received: from almesberger.net (vpnwa-home [10.200.0.2]) by host.almesberger.net (8.11.6/8.9.3) with ESMTP id h73I5oG04155; Sun, 3 Aug 2003 11:05:50 -0700 Received: (from werner@localhost) by almesberger.net (8.11.6/8.11.6) id h73I5c110505; Sun, 3 Aug 2003 15:05:38 -0300 Date: Sun, 3 Aug 2003 15:05:37 -0300 From: Werner Almesberger To: David Lang Cc: Alan Shih , Ben Greear , Jeff Garzik , Nivedita Singhvi , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: TOE brain dump Message-ID: <20030803150537.C10280@almesberger.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from david.lang@digitalinsight.com on Sun, Aug 03, 2003 at 01:25:48AM -0700 X-archive-position: 4485 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: werner@almesberger.net Precedence: bulk X-list: netdev David Lang wrote: > do you really want the processor on the card to be tunning > apache/NFS/Samba/etc ? If it runs a Linux kernel, that's not a problem. Whether you actually want to do this or not, becomes an entirely separate issue. - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina werner@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From hadi@cyberus.ca Sun Aug 3 11:15:10 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 11:15:19 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h73IF9Fl009421 for ; Sun, 3 Aug 2003 11:15:10 -0700 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.12) id 19jNNq-000OgI-00; Sun, 03 Aug 2003 14:15:06 -0400 Subject: Re: [RFC] High Performance Packet Classifiction for tc framework From: jamal Reply-To: hadi@cyberus.ca To: Michael Bellion and Thomas Heinz Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <3F16A0E5.1080007@hipac.org> References: <200307141045.40999.nf@hipac.org> <1058328537.1797.24.camel@jzny.localdomain> <3F16A0E5.1080007@hipac.org> Content-Type: text/plain Organization: jamalopolis Message-Id: <1059934468.1103.41.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Aug 2003 14:14:28 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4486 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Hi, Apologies for late response. Its funny how i thought i was going to have more time in the last 2 weeks but due to bad scheduling that wasnt the case. On Thu, 2003-07-17 at 09:13, Michael Bellion and Thomas Heinz wrote: > Hi Jamal > > You wrote: > > This is good.I may have emailed you about this topic before? > > Yes, but at that time we had not any concrete plans to > integrate hipac into tc. We focussed on making nf-hipac as > expressive as iptables first. > Good goal. > > It's a classifier therefore it makes sense ;-> > > :-) > > > nice. What would be interesting is to see your rule update rates vs > > iptables (i expect iptables to suck) - but how do you compare aginst any > > of the tc classifiers for example? > > Regarding the rule update rates we have not done any measurements > yet but nf-hipac should be faster than iptables (even more when > we have implemented the selective cloning stuff). On the other > hand we are probably slower than tc because in addition to the > insert operation into an internal chain there is the actual hipac > insert operation. The insertion in the internal chain is quicker > than the tc insert operation because we use doubly linked lists. > I think i will have to look at your code to make comments. > Regarding the matching performance one has to consider a few things. > The currently existing tc classifiers are an abstraction for rules > (iptables "slang") whilst hipac is an abstraction for a set of rules > (including the chain semantics known from iptables), i.e. a table in > the iptables world. Not entirely accurate. Depends which tc classifier. u32 hash tables are infact like iptables chains. Note, the concept of priorities which is used for conflict resolution as well as further separating sets of rules doesnt exist in iptables. > Of course it is possible to have some sort > of extended classifying in tc too, True, i overlooked this. > i.e. you can add several fw or u32 > filters with the same prio which allows the filters to be hashed. You can also have them use different priorities and with the continue operator first clasify based on packet data then on metadata or on another packet header filter. > One disadvantage of this concept is that the hashed filters > must be compact, i.e. there cannot be other classifiers in between. I didnt understand this. Are you talking about conflict resolving of overlapping filters? > Another major disadvantage is caused by the hashing scheme. > If you use the hash for 1 dimension you have to make sure that > either all filters in a certain bucket are disjoint or you must have > an implicit ordering of the rules (according to the insertion order > or something). This scheme is not extendable to 2 or more dimensions, > i.e. 1 hash for src ip, #(src ip buckets) many dst ip hashes and so > on, because you simply cannot express arbitrary rulesets. If i understood you - you are refering to a way to reduce the number of lookups by having disjoint hashes. I suppose for something as simple as a five tuple lookup, this is almost solvable by hardcoding the different fields into multiway hashes. Its when you try to generalize that it becomes an issue. > Another general problem is of course that the user has to manually > setup the hash which is rather inconvenient. > Yes. Take a look at Werners tcng - he has a clever way to hide things from the user. I did experimentation on u32 with a kernel thread which rearranged things when they seemed out of balance but i havent experimented with a lot of rules. > Now, what are the implications on the matching performance: > tc vs. nf-hipac? As long as the extended hashing stuff is not used > nf-hipac is clearly superior to tc. You are refering to u32. You mean as long as u32 stored things in a single linked list, you win - correct? > When hashing is used it _really_ > depends. If there is only one classifier (with hashing) per interface > and the number of rules per bucket is very small the performance should > be comparable. As soon as you add other classifiers nf-hipac will > outperform tc again. > If we take a simple user interface abstraction like tcng which hides the evil of u32 and then take simple 5 tuple rules - i doubt you will see any difference. For more generic setup, the kernel thread i refer to would work - but may slow insertion. > >>The tc framework is very flexible with respect to where filters can be > >>attached. Unfortunately this cannot be mapped into one HIPAC data > >>structure. Our current design allows to attach filters anywhere but > >>only the filters attached to the top level qdisc would benefit from the > >>HIPAC algorithm. Would this be a noticeable restriction? > > > > I dont think so, but can ytou describe this restriction? > > Well, we thought a little more about the design and came to the > conclusion that it is not necessary to have a HIPAC qdisc at root > but it suffices to ensure that the HIPAC classifier occurs only > once per interface. As you can guess from the last sentence we > dropped the HIPAC qdisc design and changed to the following scheme: > > - there no special HIPAC qdisc at all :-) > - the HIPAC classifier is no longer a simple rule but represents > the whole table > - the HIPAC classifier can occur in any qdisc but at most once > per interface > > So, basically HIPAC is just a normal classifier like any other > with two exceptions: > a) it can occur only once per interface > b) the rules within the classifier can contain other classifiers, > e.g. u32, fw, tc_index, as matches > But why restriction a)? Also why should we need hipac to hold other filters when the infrastructure itself can hold the extended filters just fine? I think you may actually be trying to say why somewhere in the email, but it must not be making a significant impression on my brain. > There is just one problem with the current tc framework. Once > a new filter is inserted into the chain it is not removed even > if the change function of the classifier returns < 0 > (2.6.0-test1: net/sched/cls_api.c: line 280f). > This should be changed anyway, shouldn't it? > Are you refering to this piece of code?: ---- err = tp->ops->change(tp, cl, t->tcm_handle, tca, &fh); if (err == 0) tfilter_notify(skb, n, tp, fh, RTM_NEWTFILTER); errout: if (cl) cops->put(q, cl); return err; --- change() should not return <0 if it has installed the filter i think. Should the top level code be responsible for removing filters? > >>- new HIPAC classifier which supports all native nf-hipac matches > >> (src/dst ip, proto, src/dst port, ttl, state, in_iface, icmp type, > >> tcpflags, fragments) and additionally fwmark > > > > I would think for cleanliness fwmark or any metadata related > > classification would be separate from one that is based on packet bits. > > Since our classifier represents a table of rules and the rules are > based on different matches, like src/dst ip and also fwmark (native) > or u32 (subclassifier as match), this is definitely a clean design. > I think we need to have the infrastructure in the main tc code. Its already there - may not be very clean right now. > >>- the HIPAC classifier can only be attached to the HIPAC qdisc and vice > >> versa the HIPAC qdisc only accepts HIPAC classifiers > > > > > > We do have an issue with being able to do extended classification > > but building a qdisc for it is a no no. Building a qdisc that will force > > other classifier to structure themselves after it is even a bigger sin. > > Look at the action code i have (i can send you an updated patch); a > > better idea is to make extended classifiers an action based on another > > filter match. At least this is what i have been toying with and i dont > > think it is clean enough. what we need is to extend the filtering > > framework itself to have extended classifiers. > > The new design should be much cleaner. Originally we also thought about > making HIPAC a classifier only but we expected some problems related > to this approach. Finally we discovered that this is not the case :) > Consider what i said above. I'll try n cobble together some examples to demonstrate (although it seems you already know this). To allow for anyone to install classifiers-du-jour without being dependet on hipac would be very useful. So ideas that you have for enabling this cleanly should be moved to cls_api. cheers, jamal From andersen@codepoet.org Sun Aug 3 11:28:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 11:28:14 -0700 (PDT) Received: from winder.codepoet.org (postfix@codepoet.org [166.70.99.138]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h73IS2Fl010527 for ; Sun, 3 Aug 2003 11:28:03 -0700 Received: by winder.codepoet.org (Codepoet.org Mail Daemon, from userid 1000) id 2E763157577; Sun, 3 Aug 2003 12:27:56 -0600 (MDT) Date: Sun, 3 Aug 2003 12:27:55 -0600 From: Erik Andersen To: Werner Almesberger Cc: Jeff Garzik , netdev@oss.sgi.com, linux-kernel@vger.kernel.org, Nivedita Singhvi Subject: Re: TOE brain dump Message-ID: <20030803182755.GA16770@codepoet.org> Reply-To: andersen@codepoet.org Mail-Followup-To: Erik Andersen , Werner Almesberger , Jeff Garzik , netdev@oss.sgi.com, linux-kernel@vger.kernel.org, Nivedita Singhvi References: <20030802140444.E5798@almesberger.net> <3F2BF5C7.90400@us.ibm.com> <3F2C0C44.6020002@pobox.com> <20030802184901.G5798@almesberger.net> <3F2CAE61.7070401@pobox.com> <20030803145737.B10280@almesberger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030803145737.B10280@almesberger.net> User-Agent: Mutt/1.3.28i X-Operating-System: Linux 2.4.19-rmk7, Rebel-NetWinder(Intel StrongARM 110 rev 3), 185.95 BogoMips X-No-Junk-Mail: I do not want to get *any* junk mail. X-archive-position: 4487 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andersen@codepoet.org Precedence: bulk X-list: netdev On Sun Aug 03, 2003 at 02:57:37PM -0300, Werner Almesberger wrote: > > There is one interesting TOE solution, that I have yet to see created: > > run Linux on an embedded processor, on the NIC. > > That's basically what I've been talking about all the > while :-) http://www.snapgear.com/pci630.html -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From akpm@osdl.org Sun Aug 3 12:01:38 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 12:01:43 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h73J1bFl013068 for ; Sun, 3 Aug 2003 12:01:37 -0700 Received: from mnm (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id h73J17I30784; Sun, 3 Aug 2003 12:01:07 -0700 Date: Sun, 3 Aug 2003 12:02:23 -0700 From: Andrew Morton To: Stephen Rothwell Cc: netdev@oss.sgi.com, janfrode@parallab.no Subject: Fw: [Bugme-new] [Bug 1036] New: Badness in local_bh_enable at kernel/softirq.c:113 Message-Id: <20030803120223.738a7453.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4488 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev (The "badness" warning is a tty locking problem. It does not explain the pptp client failures) Begin forwarded message: Date: Sun, 3 Aug 2003 04:53:31 -0700 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 1036] New: Badness in local_bh_enable at kernel/softirq.c:113 http://bugme.osdl.org/show_bug.cgi?id=1036 Summary: Badness in local_bh_enable at kernel/softirq.c:113 Kernel Version: 2.6.0-test2 Status: NEW Severity: high Owner: bugme-janitors@lists.osdl.org Submitter: janfrode@parallab.no Distribution: gentoo Hardware Environment: AMD AthlonXP Software Environment: ppp-2.4.1-r14 pptpclient-1.2.0 Problem Description: My pptp client connections keeps dying, syslogging: Aug 3 13:35:36 [pppd] Using interface ppp0 Aug 3 13:35:36 [pppd] Connect: ppp0 <--> /dev/pts/4 Aug 3 13:35:36 [/etc/hotplug/net.agent] NET add event not supported Aug 3 13:35:38 [pptp] anon log[decaps_hdlc:pptp_gre.c:198]: PPP mode seems to be Asynchronous._ Aug 3 13:35:39 [pppd] Remote message: Welcome^M^J Aug 3 13:35:41 [pppd] local IP address 129.177.43.23 Aug 3 13:35:41 [pppd] remote IP address 129.177.43.1 Aug 3 13:36:07 [pppd] Unsupported protocol 0xd44a received Aug 3 13:36:57 [pppd] Unsupported protocol 0xcc4a received aug 3 13:38:20 [su(pam_unix)] session opened for user root by (uid=1001) Aug 3 13:39:21 [anacron] Job `cron.daily' started Aug 3 13:39:29 [crontab] (root) LIST (root)_ Aug 3 13:39:37 [pptp] anon warn[decaps_gre:pptp_gre.c:300]: short read (-1): Message too long Aug 3 13:39:37 [pptp] anon log[callmgr_main:pptp_callmgr.c:234]: Closing connection Aug 3 13:39:37 [pptp] anon log[pptp_conn_close:pptp_ctrl.c:308]: Closing PPTP connection Aug 3 13:39:39 [pptp] anon log[call_callback:pptp_callmgr.c:74]: Closing connection Aug 3 13:39:39 [pppd] Hangup (SIGHUP) Aug 3 13:39:39 [kernel] Badness in local_bh_enable at kernel/softirq.c:113 Aug 3 13:39:39 [pppd] Modem hangup Aug 3 13:39:39 [pppd] Connection terminated. Aug 3 13:39:39 [pppd] Connect time 4.1 minutes. Aug 3 13:39:39 [pppd] Sent 310556 bytes, received 1615363 bytes. Aug 3 13:39:39 [/etc/hotplug/net.agent] NET remove event not supported Aug 3 13:39:39 [pppd] Failed to open /dev/pts/4: No such file or directory - Last output repeated 9 times - Aug 3 13:39:39 [pppd] Exit. And giving this call trace in the kernel log: Badness in local_bh_enable at kernel/softirq.c:113 Call Trace: [] local_bh_enable+0x88/0x90 [] ppp_async_push+0xa4/0x1b0 [] __lookup_hash+0x64/0xd0 [] ppp_asynctty_wakeup+0x31/0x60 [] pty_unthrottle+0x56/0x60 [] check_unthrottle+0x3a/0x40 [] n_tty_flush_buffer+0x14/0x50 [] pty_flush_buffer+0x5e/0x60 [] do_tty_hangup+0x3ac/0x420 [] release_dev+0x5b3/0x600 [] snd_pcm_oss_init_substream+0x50/0x90 [] zap_pmd_range+0x4e/0x70 [] unmap_page_range+0x4e/0x90 [] tty_release+0x2b/0x60 [] __fput+0xce/0xe0 [] filp_close+0x4b/0x80 [] put_files_struct+0x6c/0xe0 [] do_exit+0x165/0x340 [] sys_exit+0x15/0x20 [] syscall_call+0x7/0xb Steps to reproduce: Don't know how to trigger it, but it happens all the time. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From hadi@cyberus.ca Sun Aug 3 12:06:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 12:06:51 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h73J6jFl013745 for ; Sun, 3 Aug 2003 12:06:46 -0700 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.12) id 19jOBo-0002VY-00; Sun, 03 Aug 2003 15:06:44 -0400 Subject: Re: multiple unicast mac address (was Re: netdev_ops retraction) From: jamal Reply-To: hadi@cyberus.ca To: Rick Payne Cc: Jeff Garzik , netdev@oss.sgi.com In-Reply-To: <2147483647.1059667766@fozzy.rossfell.co.uk> References: <20030730184416.GI22222@parcelfarce.linux.theplanet.co.uk> <2147483647.1059659359@fozzy.rossfell.co.uk> <3F292B38.4070508@pobox.com> <2147483647.1059667766@fozzy.rossfell.co.uk> Content-Type: text/plain Organization: jamalopolis Message-Id: <1059937567.1102.77.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Aug 2003 15:06:07 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4489 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Last discussion that happened: http://marc.theaimsgroup.com/?t=104163060100001&r=1&w=2 cheers, jamal On Thu, 2003-07-31 at 11:09, Rick Payne wrote: > --On Thursday, July 31, 2003 10:44 am -0400 Jeff Garzik > wrote: > > > Hardware that filters N MAC addresses (unicast filtering) doesn't have a > > terribly standard interface, and the unicast filter must be adjusted at > > Indeed but where its possible to support it, it can be - and those cards > will be specified by those who need it (for HA, VRRP etc). > > > different times on different hardware. Also, chip bugs lead one to think > > unicast filtering will work where it doesn't. Also, chip limits for some > > of the more popular chips are unknown. Also, the need for this feature > > is very uncommon, and can be achieved in other ways. > > As I said - promiscuous mode and filtering on the receive side - which is > what you have to resort to anyway for those cards that don't support it. > > Alternatively, its just another patch people need to add to make things do > what they want - just like the ARP patch. > > Rick > > From ebiederm@xmission.com Sun Aug 3 12:24:39 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 12:24:51 -0700 (PDT) Received: from frodo.biederman.org (ebiederm.dsl.xmission.com [166.70.28.69]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h73JOcFl015227 for ; Sun, 3 Aug 2003 12:24:39 -0700 Received: (from eric@localhost) by frodo.biederman.org (8.9.3/8.9.3) id NAA26235; Sun, 3 Aug 2003 13:21:09 -0600 To: Werner Almesberger Cc: Jeff Garzik , Nivedita Singhvi , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: TOE brain dump References: <20030802140444.E5798@almesberger.net> <3F2BF5C7.90400@us.ibm.com> <3F2C0C44.6020002@pobox.com> <20030802184901.G5798@almesberger.net> From: ebiederm@xmission.com (Eric W. Biederman) Date: 03 Aug 2003 13:21:09 -0600 In-Reply-To: <20030802184901.G5798@almesberger.net> Message-ID: Lines: 59 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4490 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ebiederm@xmission.com Precedence: bulk X-list: netdev Werner Almesberger writes: > Jeff Garzik wrote: > > jabbering at the same time. TCP is a "one size fits all" solution, but > > it doesn't work well for everyone. > > But then, ten "optimized xxPs" that work well in two different > scenarios each, but not so good in the 98 others, wouldn't be > much fun either. The optimized for low latency cases seem to have a strong market in clusters. And they are currently keeping alive quite a few technologies. Myrinet, Infiniband, Quadric's Elan, etc. Having low latency and switch technologies that scale is quite rare currently. > Another problem of TCP is that it has grown a bit too many > knobs you need to turn before it works over your really fast > really long pipe. (In one of the OLS after dinner speeches, > this was quite appropriately called the "wizard gap".) Does anyone know which knobs to turn to make TCP go fast over Infiniband. (A low latency high bandwidth network?) I get to deal with them on a regular basis... There is one place in low latency communications that I can think of where TCP/IP is not the proper solution. For low latency communication the checksum is at the wrong end of the packet. IB gets this one correct and places the checksum at the tail end of the packet. This allows the packet to start transmitting before the checksum is computed, possibly even having the receive start at the other end before the tail of the packet is transmitted. Would it make any sense to do a low latency variation on TCP that fixes that problem? For the IP header we are fine as the data precedes the checksum. But the problem appears to affect all of the upper level protocols that ride on IP, UDP, TCP, SCTP... > > So, fix the other end of the pipeline too, otherwise this fast network > > stuff is flashly but pointless. If you want to serve up data from disk, > > then start creating PCI cards that have both Serial ATA and ethernet > > connectors on them :) Cut out the middleman of the host CPU and host > > memory bus instead of offloading portions of TCP that do not need to be > > offloaded. > > That's a good point. A hierarchical memory structure can help > here. Moving one end closer to the hardware, and letting it > know (e.g. through sendfile) that also the other end is close > (or can be reached more directly that through some hopelessly > crowded main bus) may help too. On that score it is worth noting that the next generation of peripheral busses (Hypertransport, PCI Express, etc) are all switched. Which means that device to device communication may be more reasonable. Going from a bussed interconnect to a switched interconnect is certainly a dramatic change in infrastructure. How that will affect the tradeoffs I don't know. Eric From lm@bitmover.com Sun Aug 3 12:40:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 12:40:44 -0700 (PDT) Received: from smtp.bitmover.com (smtp.bitmover.com [192.132.92.12]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h73JeWFl018109 for ; Sun, 3 Aug 2003 12:40:33 -0700 Received: from work.bitmover.com (ipcop.bitmover.com [192.132.92.15]) by smtp.bitmover.com (8.12.9/8.12.9) with ESMTP id h743iem7002500; Sun, 3 Aug 2003 20:44:40 -0700 Received: (from lm@localhost) by work.bitmover.com (8.11.6/8.11.6) id h73JeB108493; Sun, 3 Aug 2003 12:40:11 -0700 Date: Sun, 3 Aug 2003 12:40:11 -0700 From: Larry McVoy To: Erik Andersen , Werner Almesberger , Jeff Garzik , netdev@oss.sgi.com, linux-kernel@vger.kernel.org, Nivedita Singhvi Subject: Re: TOE brain dump Message-ID: <20030803194011.GA8324@work.bitmover.com> Mail-Followup-To: Larry McVoy , Erik Andersen , Werner Almesberger , Jeff Garzik , netdev@oss.sgi.com, linux-kernel@vger.kernel.org, Nivedita Singhvi References: <20030802140444.E5798@almesberger.net> <3F2BF5C7.90400@us.ibm.com> <3F2C0C44.6020002@pobox.com> <20030802184901.G5798@almesberger.net> <3F2CAE61.7070401@pobox.com> <20030803145737.B10280@almesberger.net> <20030803182755.GA16770@codepoet.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030803182755.GA16770@codepoet.org> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=0.5, required 7, AWL, DATE_IN_PAST_06_12) X-archive-position: 4491 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lm@bitmover.com Precedence: bulk X-list: netdev On Sun, Aug 03, 2003 at 12:27:55PM -0600, Erik Andersen wrote: > On Sun Aug 03, 2003 at 02:57:37PM -0300, Werner Almesberger wrote: > > > There is one interesting TOE solution, that I have yet to see created: > > > run Linux on an embedded processor, on the NIC. > > > > That's basically what I've been talking about all the > > while :-) > > http://www.snapgear.com/pci630.html ipcop plus a new PC for $200 is way higher performance and does more. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm From david.lang@digitalinsight.com Sun Aug 3 13:15:08 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 13:15:18 -0700 (PDT) Received: from warden.diginsite.com (warden-p.diginsite.com [208.29.163.248]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h73KF7Fl020689 for ; Sun, 3 Aug 2003 13:15:07 -0700 Received: from wlvims01.diginsite.com by warden.diginsite.com via smtpd (for oss.SGI.COM [192.48.159.27]) with SMTP; Sun, 3 Aug 2003 13:15:07 -0700 Received: from calexc01.digitalinsight.com ([10.200.0.20]) by wlvims01.digitalinsight.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Sun, 3 Aug 2003 13:14:17 -0700 Received: by calexc01.diginsite.com with Internet Mail Service (5.5.2653.19) id ; Sun, 3 Aug 2003 13:15:01 -0700 Received: from dlang.diginsite.com ([10.201.10.67]) by wlvexc00.digitalinsight.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id QF5KMNL2; Sun, 3 Aug 2003 13:14:59 -0700 From: David Lang To: Larry McVoy Cc: Erik Andersen , Werner Almesberger , Jeff Garzik , netdev@oss.sgi.com, linux-kernel@vger.kernel.org, Nivedita Singhvi Date: Sun, 3 Aug 2003 13:13:24 -0700 (PDT) Subject: Re: TOE brain dump In-Reply-To: <20030803194011.GA8324@work.bitmover.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4492 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: david.lang@digitalinsight.com Precedence: bulk X-list: netdev On Sun, 3 Aug 2003, Larry McVoy wrote: > On Sun, Aug 03, 2003 at 12:27:55PM -0600, Erik Andersen wrote: > > On Sun Aug 03, 2003 at 02:57:37PM -0300, Werner Almesberger wrote: > > > > There is one interesting TOE solution, that I have yet to see created: > > > > run Linux on an embedded processor, on the NIC. > > > > > > That's basically what I've been talking about all the > > > while :-) > > > > http://www.snapgear.com/pci630.html > > ipcop plus a new PC for $200 is way higher performance and does more. however I can see situations where you would put multiple cards in one box and there could be an advantage to useing PCI (or PCI-X) for you communications between the different 'nodes' of you routing cluster instead of gig ethernet. if this is the approach that the networking guys really want to encourage how about defining an API that you would be willing to support and you can even implement it and then any card that is produced would be supported from day 1. this interface would not have to cover the configuration of the card (that can be done with userspace tools that talk to the card over the 'network', it just needs to cover the ability to do what is effectivly IP over PCI. Linus has commented that in mahy ways Linux is not designed for any existing CPU, it's designed for a virtual CPU that implements all the features we want and those features that aren't implemented in the chips get emulated as needed (obviously what is actually implemented and the speed of emulation are serious considerations for performance) why doesn't the network team define what they thing the ideal NIC interface would be. I can see three catagories of 'ideal' cards 1. cards that are directly driven by the kernel IP stack (similar to what we support now, but an ideal version) 2. router nodes that have access to main memory (PCI card running linux acting as a router/firewall/VPN to offload the main CPU's) 3. router nodes that don't have access to main memory (things like USB/fibrechannel/infiniband/etc versions of #2, the node can run linux and deal with the outside world, only sending the data that is needed to/from the host) even if nobody makes hardware that supports all the desired features directly having a 'this is the dieal driver' reference should impruve furture drivers by letting them use this as the core and implementing code to simulate the features not in hardware. they claim they need this sort of performance, you say 'not that way do it sanely' why not give them a sane way to do it? David Lang From lm@bitmover.com Sun Aug 3 13:31:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 13:31:08 -0700 (PDT) Received: from smtp.bitmover.com (smtp.bitmover.com [192.132.92.12]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h73KV1Fl021999 for ; Sun, 3 Aug 2003 13:31:02 -0700 Received: from work.bitmover.com (ipcop.bitmover.com [192.132.92.15]) by smtp.bitmover.com (8.12.9/8.12.9) with ESMTP id h744ZKm7003004; Sun, 3 Aug 2003 21:35:20 -0700 Received: (from lm@localhost) by work.bitmover.com (8.11.6/8.11.6) id h73KUp509118; Sun, 3 Aug 2003 13:30:51 -0700 Date: Sun, 3 Aug 2003 13:30:51 -0700 From: Larry McVoy To: David Lang Cc: Larry McVoy , Erik Andersen , Werner Almesberger , Jeff Garzik , netdev@oss.sgi.com, linux-kernel@vger.kernel.org, Nivedita Singhvi Subject: Re: TOE brain dump Message-ID: <20030803203051.GA9057@work.bitmover.com> Mail-Followup-To: Larry McVoy , David Lang , Larry McVoy , Erik Andersen , Werner Almesberger , Jeff Garzik , netdev@oss.sgi.com, linux-kernel@vger.kernel.org, Nivedita Singhvi References: <20030803194011.GA8324@work.bitmover.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=0.5, required 7, AWL, DATE_IN_PAST_06_12) X-archive-position: 4493 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lm@bitmover.com Precedence: bulk X-list: netdev On Sun, Aug 03, 2003 at 01:13:24PM -0700, David Lang wrote: > 2. router nodes that have access to main memory (PCI card running linux > acting as a router/firewall/VPN to offload the main CPU's) I can get an entire machine, memory, disk, > Ghz CPU, case, power supply, cdrom, floppy, onboard enet extra net card for routing, for $250 or less, quantity 1, shipped to my door. Why would I want to spend money on some silly offload card when I can get the whole PC for less than the card? -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm From alan@lxorguk.ukuu.org.uk Sun Aug 3 13:55:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 13:55:31 -0700 (PDT) Received: from lxorguk.ukuu.org.uk (pc1-cwma1-5-cust4.swan.cable.ntl.com [80.5.120.4]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h73KtOFl023931 for ; Sun, 3 Aug 2003 13:55:25 -0700 Received: from dhcp22.swansea.linux.org.uk (dhcp22.swansea.linux.org.uk [127.0.0.1]) by lxorguk.ukuu.org.uk (8.12.8/8.12.5) with ESMTP id h73KpOC3031925; Sun, 3 Aug 2003 21:51:25 +0100 Received: (from alan@localhost) by dhcp22.swansea.linux.org.uk (8.12.8/8.12.8/Submit) id h73KpMDK031923; Sun, 3 Aug 2003 21:51:22 +0100 X-Authentication-Warning: dhcp22.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: TOE brain dump From: Alan Cox To: Werner Almesberger Cc: netdev@oss.sgi.com, Linux Kernel Mailing List In-Reply-To: <20030802191411.H5798@almesberger.net> References: <20030802140444.E5798@almesberger.net> <1059857864.20305.14.camel@dhcp22.swansea.linux.org.uk> <20030802191411.H5798@almesberger.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1059943881.31900.1.camel@dhcp22.swansea.linux.org.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 03 Aug 2003 21:51:21 +0100 X-archive-position: 4494 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: netdev On Sad, 2003-08-02 at 23:14, Werner Almesberger wrote: > That's taking this idea to an extreme, yes. I'd think of > using something as big as an amd64 for this as "too > expensive", but perhaps it's cheap enough in the long run, > compared to some "optimized" design. Volume makes cheap. If you look at software v hardware raid controllers the hardware people are permanently being killed by the low volume of cards. From alan@lxorguk.ukuu.org.uk Sun Aug 3 13:56:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 13:56:21 -0700 (PDT) Received: from lxorguk.ukuu.org.uk (pc1-cwma1-5-cust4.swan.cable.ntl.com [80.5.120.4]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h73KuGFl024198 for ; Sun, 3 Aug 2003 13:56:16 -0700 Received: from dhcp22.swansea.linux.org.uk (dhcp22.swansea.linux.org.uk [127.0.0.1]) by lxorguk.ukuu.org.uk (8.12.8/8.12.5) with ESMTP id h73KqIC3031940; Sun, 3 Aug 2003 21:52:19 +0100 Received: (from alan@localhost) by dhcp22.swansea.linux.org.uk (8.12.8/8.12.8/Submit) id h73KqEOh031938; Sun, 3 Aug 2003 21:52:14 +0100 X-Authentication-Warning: dhcp22.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: TOE brain dump From: Alan Cox To: Ben Greear Cc: Jeff Garzik , Nivedita Singhvi , Werner Almesberger , netdev@oss.sgi.com, Linux Kernel Mailing List In-Reply-To: <3F2C891B.7080004@candelatech.com> References: <20030802140444.E5798@almesberger.net> <3F2BF5C7.90400@us.ibm.com> <3F2C0C44.6020002@pobox.com> <3F2C891B.7080004@candelatech.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1059943933.31901.3.camel@dhcp22.swansea.linux.org.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 03 Aug 2003 21:52:13 +0100 X-archive-position: 4495 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: netdev On Sul, 2003-08-03 at 05:01, Ben Greear wrote: > Jeff Garzik wrote: > > > So, fix the other end of the pipeline too, otherwise this fast network > > stuff is flashly but pointless. If you want to serve up data from disk, > > then start creating PCI cards that have both Serial ATA and ethernet > > connectors on them :) Cut out the middleman of the host CPU and host > > I for one would love to see something like this, and not just Serial ATA.. > but maybe 8x Serial ATA and RAID :) There is a protocol floating around for ATA over ethernet, no TCP layer or nasty latency eating complexities in the middle From hadi@cyberus.ca Sun Aug 3 14:17:06 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 14:17:18 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h73LH5Fl025960 for ; Sun, 3 Aug 2003 14:17:06 -0700 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.12) id 19jPZk-0008ov-00; Sun, 03 Aug 2003 16:35:33 -0400 Subject: Re: TOE brain dump From: jamal Reply-To: hadi@cyberus.ca To: Larry McVoy Cc: Erik Andersen , Werner Almesberger , Jeff Garzik , netdev@oss.sgi.com, linux-kernel@vger.kernel.org, Nivedita Singhvi In-Reply-To: <20030803194011.GA8324@work.bitmover.com> References: <20030802140444.E5798@almesberger.net> <3F2BF5C7.90400@us.ibm.com> <3F2C0C44.6020002@pobox.com> <20030802184901.G5798@almesberger.net> <3F2CAE61.7070401@pobox.com> <20030803145737.B10280@almesberger.net> <20030803182755.GA16770@codepoet.org> <20030803194011.GA8324@work.bitmover.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1059942894.1103.96.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Aug 2003 16:34:54 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4496 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sun, 2003-08-03 at 15:40, Larry McVoy wrote: > On Sun, Aug 03, 2003 at 12:27:55PM -0600, Erik Andersen wrote: > > On Sun Aug 03, 2003 at 02:57:37PM -0300, Werner Almesberger wrote: > > > > There is one interesting TOE solution, that I have yet to see created: > > > > run Linux on an embedded processor, on the NIC. > > > > > > That's basically what I've been talking about all the > > > while :-) > > > > http://www.snapgear.com/pci630.html > > ipcop plus a new PC for $200 is way higher performance and does more. ;-> Actually this proves that putting the whole stack on the NIC is the wrong way to go ;-> That poor piece of NIC was obsoleted before it was born on pricing alone and not just compute power it was supposed to liberate us from. I think the idea of hierachical memories and computation is certainly interesting. Put a CPU and memory on the NIC but not to do the work that Linux already does. Instead think of the NIC and its memeory + CPU as a L1 data and code cache for TCP processing. The idea posed from Davem is intriguing: The only thing the NIC should do is TCP fast path processing based on cached control data generated from the main CPU stack. Any time the fast path gets violated, the cache gets invalidate and it becomes an exception handling to be handled by the main CPU stack. IMO, the only time this will make sense is when the setup cost (downloading the cache or cookies as Dave calls them) is amortized by the data that follows. For example, may not make sense to worry about a HTTP1.0 flow which has 3-4 packets after the SYNack.Bulk transfers make sense (storage, file serving). I dont remember the Mogul paper details but i think this is what he was implying. cheers, jamal From david.lang@digitalinsight.com Sun Aug 3 14:23:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 14:23:03 -0700 (PDT) Received: from warden3.diginsite.com (warden3-p.diginsite.com [208.147.64.186]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h73LMxFl026639 for ; Sun, 3 Aug 2003 14:23:00 -0700 Received: from no.name.available by warden3.diginsite.com via smtpd (for oss.SGI.COM [192.48.159.27]) with SMTP; Sun, 3 Aug 2003 14:16:04 -0700 Received: from ata-navgw-how1.anytimeaccess.com ([10.210.80.95]) by ata-mail.anytimeaccess.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id com for ; Sun, 3 Aug 2003 14:19:17 -0700 Received: from sacexc01.digitalinsight.com ([10.210.80.155]) by ata-navgw-how1.anytimeaccess.com (NAVIEG 2.1 bld 63) with SMTP id M2003080314134107659 ; Sun, 03 Aug 2003 14:13:41 -0700 Received: by sacexc01.anytimeaccess.com with Internet Mail Service (5.5.2656.59) id ; Sun, 3 Aug 2003 14:22:50 -0700 Received: from dlang.diginsite.com ([10.201.10.67]) by wlvexc00.digitalinsight.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id QF5KMN9H; Sun, 3 Aug 2003 14:22:47 -0700 From: David Lang To: Larry McVoy Cc: Erik Andersen , Werner Almesberger, Jeff Garzik , netdev@oss.sgi.com, linux-kernel@vger.kernel.org, Nivedita Singhvi Date: Sun, 3 Aug 2003 14:21:12 -0700 (PDT) Subject: Re: TOE brain dump In-Reply-To: <20030803203051.GA9057@work.bitmover.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4497 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: david.lang@digitalinsight.com Precedence: bulk X-list: netdev On Sun, 3 Aug 2003, Larry McVoy wrote: > On Sun, Aug 03, 2003 at 01:13:24PM -0700, David Lang wrote: > > 2. router nodes that have access to main memory (PCI card running linux > > acting as a router/firewall/VPN to offload the main CPU's) > > I can get an entire machine, memory, disk, > Ghz CPU, case, power supply, > cdrom, floppy, onboard enet extra net card for routing, for $250 or less, > quantity 1, shipped to my door. > > Why would I want to spend money on some silly offload card when I can get > the whole PC for less than the card? you may want to do this for a database box where you want to dedicate your main processing power to the database task, if you use a seperate box you still have to talk to that box over a network, if you have it as a card you can talk to the card much more efficantly then you can talk to the seperate machine. if your 8-way opteron database box is already the bottleneck for your system you will have to spend a LOT of money to get anything that gives you more available processing power, getting a card to offload any processing from the main CPU's can be a win. yes this is somewhat of a niche market, but as you point out adding more and more processors in a SMP model is not the ideal way to go, either from performance or from the cost point of view. on the webserver front there are a lot of companies making a living by selling cards and boxes to offload processing from the main CPU's of the webservers (cards to do gzip compression are a relativly new addition, but cards to do SSL handshakes have been around for a while) used properly these can be a very worthwhile invenstment for high-volume webserver companies. also the cost of an extra box can be considerably higer then just the cost of the hardware. I know of one situation where between Linux OS license fees (redhat advanced server) and security software (intrusion detection, auditing, privilage management, etc) a company is looking at ~$4000 in licensing fees for every box they put in their datacenter (and this is for boxes just running apache, add something like an oracle or J2EE appserver software and the cost goes up even more). at this point the fact that the box only cost $200 doesn't really matter, spending an extra $500 each on 4 boxes to eliminate the need for a 5th is easily worth it. (and this company is re-examining hardwaare raid controllers after having run software raid for years becouse they are realizing that this is requiring them to run more servers due to the load on the CPU's) at the low end you are right, just add another box or add another CPU to an existing box, but there are conditions that make adding specialized cards to offload specific functionality a win (for that matter, even at the low end people routinly offload graphics processing to specialized cards, simply to make their games run faster) David Lang From alan@storlinksemi.com Sun Aug 3 15:02:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 15:02:33 -0700 (PDT) Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h73M2OFl029358 for ; Sun, 3 Aug 2003 15:02:24 -0700 Received: from cpe-66-1-155-95.ca.sprintbbd.net (HELO AlanLap) (alansuntzishih@66.1.155.95 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 3 Aug 2003 22:02:23 -0000 From: "Alan Shih" To: "David Lang" Cc: "Ben Greear" , "Jeff Garzik" , "Nivedita Singhvi" , "Werner Almesberger" , , Subject: RE: TOE brain dump Date: Sun, 3 Aug 2003 15:02:09 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 X-archive-position: 4498 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@storlinksemi.com Precedence: bulk X-list: netdev On an embedded system, no processor will be fast enough to compete with direct DMA xfer. So just provide sendfile hooks that allow the kernel to initiate data filling from source to dest then allow TSO to take place. Kernel still needs to take care of the TCP stack. I don't see this as building extensive customization though. Alan -----Original Message----- From: David Lang [mailto:david.lang@digitalinsight.com] Sent: Sunday, August 03, 2003 1:26 AM To: Alan Shih Cc: Ben Greear; Jeff Garzik; Nivedita Singhvi; Werner Almesberger; netdev@oss.sgi.com; linux-kernel@vger.kernel.org Subject: RE: TOE brain dump do you really want the processor on the card to be tunning apache/NFS/Samba/etc ? putting enough linux on the card to act as a router (which would include the netfilter stuff) is one thing. putting the userspace code that interfaces with the outside world for file transfers is something else. if you really want the disk connected to your network card you are just talking a low-end linux box. forget all this stuff about it being on a card and just use a full box (economys of scale will make this cheaper) making a firewall that's a core system with a dozen slave systems attached to it (the network cards) sounds like the type of clustering that Linux has been used for for compute nodes. complicated to setup, but extremely powerful and scalable once configured. if you want more then a router on the card then Alan Cox is right, just add another processor to the system, it's easier and cheaper. David Lang On Sat, 2 Aug 2003, Alan Shih wrote: > Date: Sat, 2 Aug 2003 23:22:52 -0700 > From: Alan Shih > To: Ben Greear , Jeff Garzik > Cc: Nivedita Singhvi , > Werner Almesberger , netdev@oss.sgi.com, > linux-kernel@vger.kernel.org > Subject: RE: TOE brain dump > > A DMA xfer that fills the NIC pipe with IDE source. That's not very hard... > need a lot of bufferring/FIFO though. May require large modification to the > file serving applications? > > Alan > > -----Original Message----- > From: linux-kernel-owner@vger.kernel.org > [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Ben Greear > Sent: Saturday, August 02, 2003 9:02 PM > To: Jeff Garzik > Cc: Nivedita Singhvi; Werner Almesberger; netdev@oss.sgi.com; > linux-kernel@vger.kernel.org > Subject: Re: TOE brain dump > > > Jeff Garzik wrote: > > > So, fix the other end of the pipeline too, otherwise this fast network > > stuff is flashly but pointless. If you want to serve up data from disk, > > then start creating PCI cards that have both Serial ATA and ethernet > > connectors on them :) Cut out the middleman of the host CPU and host > > I for one would love to see something like this, and not just Serial ATA.. > but maybe 8x Serial ATA and RAID :) > > Ben > > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > From lm@bitmover.com Sun Aug 3 16:44:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 16:44:46 -0700 (PDT) Received: from smtp.bitmover.com (smtp.bitmover.com [192.132.92.12]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h73NiYFl004045 for ; Sun, 3 Aug 2003 16:44:35 -0700 Received: from work.bitmover.com (ipcop.bitmover.com [192.132.92.15]) by smtp.bitmover.com (8.12.9/8.12.9) with ESMTP id h747mnm7005317; Mon, 4 Aug 2003 00:48:49 -0700 Received: (from lm@localhost) by work.bitmover.com (8.11.6/8.11.6) id h73NiJM13637; Sun, 3 Aug 2003 16:44:19 -0700 Date: Sun, 3 Aug 2003 16:44:19 -0700 From: Larry McVoy To: David Lang Cc: Larry McVoy , Erik Andersen , Werner Almesberger , Jeff Garzik , netdev@oss.sgi.com, linux-kernel@vger.kernel.org, Nivedita Singhvi Subject: Re: TOE brain dump Message-ID: <20030803234419.GA13604@work.bitmover.com> Mail-Followup-To: Larry McVoy , David Lang , Larry McVoy , Erik Andersen , Werner Almesberger , Jeff Garzik , netdev@oss.sgi.com, linux-kernel@vger.kernel.org, Nivedita Singhvi References: <20030803203051.GA9057@work.bitmover.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=0.5, required 7, AWL, DATE_IN_PAST_06_12) X-archive-position: 4499 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lm@bitmover.com Precedence: bulk X-list: netdev On Sun, Aug 03, 2003 at 02:21:12PM -0700, David Lang wrote: > if your 8-way opteron database box is already the bottleneck for your > system you will have to spend a LOT of money to get anything that gives > you more available processing power, getting a card to offload any > processing from the main CPU's can be a win. I'd like to see data which supports this. CPUs have gotten so fast and disk I/O still sucks. All the systems I've seen are CPU rich and I/O starved. The smartest thing you could do would be to get a cheap box with a GB of ram as a disk cache and make it be a SAN device. Make N of those and you have tons of disk space and tons of cache and your 8 way opteron database box is going to work just fine. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm From david-b@pacbell.net Sun Aug 3 20:06:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 20:06:37 -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 h7435xFl018707 for ; Sun, 3 Aug 2003 20:06:00 -0700 Received: from pacbell.net (ppp-67-118-247-123.dialup.pltn13.pacbell.net [67.118.247.123]) by mta4.rcsntx.swbell.net (8.12.9/8.12.3) with ESMTP id h7435gjA011136; Sun, 3 Aug 2003 22:05:43 -0500 (CDT) Message-ID: <3F2DCE56.6030601@pacbell.net> Date: Sun, 03 Aug 2003 20:09:10 -0700 From: David Brownell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: "David S. Miller" CC: Ben Greear , jgarzik@pobox.com, scott.feldman@intel.com, netdev@oss.sgi.com Subject: Re: e100 "Ferguson" release References: <3F2CA65F.8060105@pobox.com> <3F2CBA71.2070503@candelatech.com> <20030803003239.4257ef24.davem@redhat.com> In-Reply-To: <20030803003239.4257ef24.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4500 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: >>Although I have not tried this latest patch, the existing e100 and e1000 in >>2.4.21 seldom seem to return true to this method: netif_queue_stopped(odev), >>even when the next hard_start_xmit() call fails. > > > Returning an error from hard_start_xmit() from normal ethernet > drivers is, frankly, a driver bug and should never happen. What's "normal" mean? With the current USB stack, network adapters tend to need memory allocations there. Those can fail, though it seems that's not very common. Doesn't seem like a bug, for all that I'd rather see the those paths be zero-alloc in 2.7. - Dave From davem@redhat.com Sun Aug 3 20:13:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 20:13:19 -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 h743DDFl019496 for ; Sun, 3 Aug 2003 20:13:14 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id UAA18891; Sun, 3 Aug 2003 20:08:51 -0700 Date: Sun, 3 Aug 2003 20:08:51 -0700 From: "David S. Miller" To: David Brownell Cc: greearb@candelatech.com, jgarzik@pobox.com, scott.feldman@intel.com, netdev@oss.sgi.com Subject: Re: e100 "Ferguson" release Message-Id: <20030803200851.7d46a605.davem@redhat.com> In-Reply-To: <3F2DCE56.6030601@pacbell.net> References: <3F2CA65F.8060105@pobox.com> <3F2CBA71.2070503@candelatech.com> <20030803003239.4257ef24.davem@redhat.com> <3F2DCE56.6030601@pacbell.net> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4501 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sun, 03 Aug 2003 20:09:10 -0700 David Brownell wrote: > David S. Miller wrote: > >>Although I have not tried this latest patch, the existing e100 and e1000 in > >>2.4.21 seldom seem to return true to this method: netif_queue_stopped(odev), > >>even when the next hard_start_xmit() call fails. > > > > > > Returning an error from hard_start_xmit() from normal ethernet > > drivers is, frankly, a driver bug and should never happen. > > What's "normal" mean? One that can manage it's own TX resources. > With the current USB stack, network adapters tend to need > memory allocations there. Those can fail, though it seems > that's not very common. Doesn't seem like a bug, for all > that I'd rather see the those paths be zero-alloc in 2.7. Any particular reason why the SKB data itself can't be mapped directly? We created all of these DMA mapping abstractions remember? :-) Another option is to pre-allocate, such that while the TX queue is awake we know we have enough resources to send any given packet. Then in ->hard_start_xmit() after using a buffer we allocate a replacement buffer, if this fails in such a way that a subsequent ->hard_start_xmit() could possibly fail, we do netif_stop_queue(). Look to tg3 to see what I'm talking about in general. netif_stop_queue() is done at the moment at which it may be possible that we cannot accept the queueing of a TX packet. This means that when TX entries available <= MAX_SKB_FRAGS + 1, we stop the queue. This guarentees that we will always be able to handle any packet given to us via ->hard_start_xmit(). From david-b@pacbell.net Sun Aug 3 20:41:38 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 20:41:43 -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 h743fcFl021918 for ; Sun, 3 Aug 2003 20:41:38 -0700 Received: from pacbell.net (ppp-67-118-247-123.dialup.pltn13.pacbell.net [67.118.247.123]) by mta4.rcsntx.swbell.net (8.12.9/8.12.3) with ESMTP id h743fXjA026551; Sun, 3 Aug 2003 22:41:33 -0500 (CDT) Message-ID: <3F2DD6BD.7070504@pacbell.net> Date: Sun, 03 Aug 2003 20:45:01 -0700 From: David Brownell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: "David S. Miller" CC: greearb@candelatech.com, jgarzik@pobox.com, scott.feldman@intel.com, netdev@oss.sgi.com Subject: Re: e100 "Ferguson" release References: <3F2CA65F.8060105@pobox.com> <3F2CBA71.2070503@candelatech.com> <20030803003239.4257ef24.davem@redhat.com> <3F2DCE56.6030601@pacbell.net> <20030803200851.7d46a605.davem@redhat.com> In-Reply-To: <20030803200851.7d46a605.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4502 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 >>>>Although I have not tried this latest patch, the existing e100 and e1000 in >>>>2.4.21 seldom seem to return true to this method: netif_queue_stopped(odev), >>>>even when the next hard_start_xmit() call fails. >>> >>> >>>Returning an error from hard_start_xmit() from normal ethernet >>>drivers is, frankly, a driver bug and should never happen. >> >>What's "normal" mean? > > > One that can manage it's own TX resources. Which for the moment, would seem to exclude USB. >>With the current USB stack, network adapters tend to need >>memory allocations there. Those can fail, though it seems >>that's not very common. Doesn't seem like a bug, for all >>that I'd rather see the those paths be zero-alloc in 2.7. > > > Any particular reason why the SKB data itself can't be > mapped directly? We created all of these DMA mapping > abstractions remember? :-) Yes, but the network drivers weren't the ones that needed them! Some older drivers do copy the buffer out of (or for rx, into) the skb, but newer ones just pass the skb data, avoiding a copy. In either case, the buffer was always DMA mapped. Nowadays, some drivers will even set NETIF_F_HIGHDMA if they're going out through a host controller that allows it! (Intel boxes only, AFAIK.) > Another option is to pre-allocate, such that while the TX > queue is awake we know we have enough resources to send any > given packet. Then in ->hard_start_xmit() after using a buffer > we allocate a replacement buffer, if this fails in such a way > that a subsequent ->hard_start_xmit() could possibly fail, we > do netif_stop_queue(). Pre-allocation can be done for the URBs that wrap the data buffers, yes. Not often done today; but it could be. What can't be pre-allocated in a reliable way is the resources used by the host controller drivers, specifically the transfer descriptors. EHCI and OHCI usually need one per URB, unless MTU is over 4 KB. UHCI normally needs quite a few. The API that works inside USB "gadgets' does allow pre-allocation at all those levels, mostly because it's factored to make the submission and completion paths fast. So that "stop if can't pre-allocate" scheme would work, given an "ether.c" patch! :) - Dave From davem@redhat.com Sun Aug 3 20:51:30 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 20:51:34 -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 h743pUFl022879 for ; Sun, 3 Aug 2003 20:51:30 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id UAA19000; Sun, 3 Aug 2003 20:46:42 -0700 Date: Sun, 3 Aug 2003 20:46:42 -0700 From: "David S. Miller" To: David Brownell Cc: greearb@candelatech.com, jgarzik@pobox.com, scott.feldman@intel.com, netdev@oss.sgi.com Subject: Re: e100 "Ferguson" release Message-Id: <20030803204642.684c6075.davem@redhat.com> In-Reply-To: <3F2DD6BD.7070504@pacbell.net> References: <3F2CA65F.8060105@pobox.com> <3F2CBA71.2070503@candelatech.com> <20030803003239.4257ef24.davem@redhat.com> <3F2DCE56.6030601@pacbell.net> <20030803200851.7d46a605.davem@redhat.com> <3F2DD6BD.7070504@pacbell.net> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4503 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sun, 03 Aug 2003 20:45:01 -0700 David Brownell wrote: > What can't be pre-allocated in a reliable way is the resources > used by the host controller drivers, specifically the transfer > descriptors. EHCI and OHCI usually need one per URB, unless > MTU is over 4 KB. UHCI normally needs quite a few. Ok, that's interesting. Is there a callback that tells the USB driver that some host controller "resources" have become available? I mean, these host controllers either have to queue requests when out of resources or provide a callback so that the drivers can resubmit. Right? From david-b@pacbell.net Sun Aug 3 21:05:09 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 21:05:15 -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 h74458Fl024201 for ; Sun, 3 Aug 2003 21:05:09 -0700 Received: from pacbell.net (ppp-67-118-247-123.dialup.pltn13.pacbell.net [67.118.247.123]) by mta4.rcsntx.swbell.net (8.12.9/8.12.3) with ESMTP id h7444wjA026527; Sun, 3 Aug 2003 23:05:04 -0500 (CDT) Message-ID: <3F2DDC3A.2040707@pacbell.net> Date: Sun, 03 Aug 2003 21:08:26 -0700 From: David Brownell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: "David S. Miller" CC: greearb@candelatech.com, jgarzik@pobox.com, scott.feldman@intel.com, netdev@oss.sgi.com Subject: Re: e100 "Ferguson" release References: <3F2CA65F.8060105@pobox.com> <3F2CBA71.2070503@candelatech.com> <20030803003239.4257ef24.davem@redhat.com> <3F2DCE56.6030601@pacbell.net> <20030803200851.7d46a605.davem@redhat.com> <3F2DD6BD.7070504@pacbell.net> <20030803204642.684c6075.davem@redhat.com> In-Reply-To: <20030803204642.684c6075.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4504 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: > On Sun, 03 Aug 2003 20:45:01 -0700 > David Brownell wrote: > > >>What can't be pre-allocated in a reliable way is the resources >>used by the host controller drivers, specifically the transfer >>descriptors. EHCI and OHCI usually need one per URB, unless >>MTU is over 4 KB. UHCI normally needs quite a few. > > > Ok, that's interesting. All TDs get allocated in usb_submit_urb(), which is the first time the "real" core of USB connects an urb with an I/O queue. That's host-side, not device-side. > Is there a callback that tells the USB driver that some host > controller "resources" have become available? I mean, these host > controllers either have to queue requests when out of resources or > provide a callback so that the drivers can resubmit. No such callback. If no resources, they fail -ENOMEM and the caller must recover. Which is why hard_start_xmit() needs to do something. - Dave From davem@redhat.com Sun Aug 3 21:17:52 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 21:18:01 -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 h744HqFl025423 for ; Sun, 3 Aug 2003 21:17:52 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id VAA19041; Sun, 3 Aug 2003 21:13:34 -0700 Date: Sun, 3 Aug 2003 21:13:33 -0700 From: "David S. Miller" To: David Brownell Cc: greearb@candelatech.com, jgarzik@pobox.com, scott.feldman@intel.com, netdev@oss.sgi.com Subject: Re: e100 "Ferguson" release Message-Id: <20030803211333.12839f66.davem@redhat.com> In-Reply-To: <3F2DDC3A.2040707@pacbell.net> References: <3F2CA65F.8060105@pobox.com> <3F2CBA71.2070503@candelatech.com> <20030803003239.4257ef24.davem@redhat.com> <3F2DCE56.6030601@pacbell.net> <20030803200851.7d46a605.davem@redhat.com> <3F2DD6BD.7070504@pacbell.net> <20030803204642.684c6075.davem@redhat.com> <3F2DDC3A.2040707@pacbell.net> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4505 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sun, 03 Aug 2003 21:08:26 -0700 David Brownell wrote: > No such callback. If no resources, they fail -ENOMEM and the > caller must recover. Which is why hard_start_xmit() needs to > do something. I would suggest something different :-) For example, what do USB block device drivers do when -ENOMEM comes back? Do they just drop the request on the floor? No, rather they resubmit the request later without the scsi/block layer knowing anything about what happened, right? How do the USB block device drivers know when "later" is? This is why I can't believe there is not some kind of "some USB resources have been freed" event of some sort which USB drivers can use to deal with this. :-) From davem@redhat.com Sun Aug 3 22:26:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 22:26:09 -0700 (PDT) Received: from rth.ninka.net (rth.ninka.net [216.101.162.244]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h745Q1Fl030678 for ; Sun, 3 Aug 2003 22:26:02 -0700 Received: from rth.ninka.net (localhost.localdomain [127.0.0.1]) by rth.ninka.net (8.12.8/8.12.8) with SMTP id h745PsSG027235; Sun, 3 Aug 2003 22:25:55 -0700 Date: Sun, 3 Aug 2003 22:25:54 -0700 From: "David S. Miller" To: Glen Turner Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: TOE brain dump Message-Id: <20030803222554.7027a160.davem@redhat.com> In-Reply-To: <3F2DBB2B.9050803@aarnet.edu.au> References: <20030802140444.E5798@almesberger.net> <3F2BF5C7.90400@us.ibm.com> <3F2C0C44.6020002@pobox.com> <20030802184901.G5798@almesberger.net> <3F2CAE61.7070401@pobox.com> <3F2DBB2B.9050803@aarnet.edu.au> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4506 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 [ This discussion belongs on netdev, not linux-kernel. ] On Mon, 04 Aug 2003 11:17:23 +0930 Glen Turner wrote: > That's Matt Mathis's phrase. The Web100 project > has a set of patches to the kernel > which go a long way to reducing the wizard gap. It would be > nice to see those patches eventually appear in the Linux > mainstream. The web100 patches aren't in the kernel because 1) they've never even been submitted and 2) they need a large cleanup. I sort of get the impression that the web100 folks actually like that their changes are not in the main sources, it keeps their work "special". From werner@almesberger.net Sun Aug 3 22:51:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 22:51:44 -0700 (PDT) Received: from host.almesberger.net (almesberger.net [63.105.73.239] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h745pWFl000336 for ; Sun, 3 Aug 2003 22:51:32 -0700 Received: from almesberger.net (vpnwa-home [10.200.0.2]) by host.almesberger.net (8.11.6/8.9.3) with ESMTP id h73HvkG04076; Sun, 3 Aug 2003 10:57:50 -0700 Received: (from werner@localhost) by almesberger.net (8.11.6/8.11.6) id h73Hvc310464; Sun, 3 Aug 2003 14:57:38 -0300 Date: Sun, 3 Aug 2003 14:57:37 -0300 From: Werner Almesberger To: Jeff Garzik Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org, Nivedita Singhvi Subject: Re: TOE brain dump Message-ID: <20030803145737.B10280@almesberger.net> References: <20030802140444.E5798@almesberger.net> <3F2BF5C7.90400@us.ibm.com> <3F2C0C44.6020002@pobox.com> <20030802184901.G5798@almesberger.net> <3F2CAE61.7070401@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F2CAE61.7070401@pobox.com>; from jgarzik@pobox.com on Sun, Aug 03, 2003 at 02:40:33AM -0400 X-archive-position: 4507 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: werner@almesberger.net Precedence: bulk X-list: netdev Jeff Garzik wrote: > Really fast, really long pipes in practice don't exist for 99.9% of all > Internet users. It matters to some right now, i.e. the ones who are interested in TOE in the first place. (And there also those who try to tweak TCP to actually work over such links. Right now, its congestion control doesn't scale that well.) Also, IT has been good at making all that elitarian high-performance gear available to the common people rather quickly, and I don't see that changing. The Crisis just alters the pace a little. > When you approach traffic levels that push you want to offload most of > the TCP net stack, then TCP isn't the right solution for you anymore, > all things considered. No. Ironically, TCP is almost always the right solution. Sometimes people try to use something else. Eventually, their protocol wants to go over WANs or something that looks suspiciously like a WAN (MAN or such). At that point, they usually realize that TCP provides exactly the functionality they need. In theory, one could implement the same functionality in other protocols. There was even talk at IETF to support a generic congestion control manager for this purpose. That was many years ago, and I haven't seen anything come out of this. So it seems that, by the time your protocol grows up to want to play in the real world, it wants to be so much like TCP that you're better off using TCP. The amusing bit here is to watch all the "competitors" pop up, grow, fail, and eventually die. > The Linux net stack just isn't built to be offloaded. Yes ! And that's not a flaw of the stack, but it's simply a fact of life. I think that no "real life" stack can be offloaded (in the traditional sense). > And I can't see ASIC and firmware > designers being excited about implementing netfilter on a PCI card :) And when they're done with netfilter, you can throw IPsec, IPv6, or traffic control at them. Eventually, you'll wear them down ;-) > Unfortunately some vendors seem to choosing TOE option #3: TCP offload > which introduces many limitations (connection limits, netfilter not > supported, etc.) which Linux never had before. That's when that little word "no" comes into play, i.e. when their modifications to the stack show up on netdev or linux-kernel. Dave Miller seems to be pretty good at saying "no". I hope he keeps on being good at this ;-) > There is one interesting TOE solution, that I have yet to see created: > run Linux on an embedded processor, on the NIC. That's basically what I've been talking about all the while :-) > The Linux OS driver interface becomes a virtual interface > with a large MTU, Probably not. I think you also want to push some knowledge of where the data ultimately goes to the NIC. This could be something like sendfile, something new, or just a few bytes of user space code. - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina werner@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From jgarzik@pobox.com Sun Aug 3 23:00:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 23:00:34 -0700 (PDT) Received: from www.linux.org.uk (IDENT:LyFAj4hc+YOjEDA9RBFVQujz5PCEzoP5@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7460RFl001286 for ; Sun, 3 Aug 2003 23:00:28 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19jQrk-00026Y-PG; Sun, 03 Aug 2003 22:58:12 +0100 Message-ID: <3F2D8569.1010109@pobox.com> Date: Sun, 03 Aug 2003 17:58:01 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: Larry McVoy CC: David Lang , Erik Andersen , Werner Almesberger , netdev@oss.sgi.com, linux-kernel@vger.kernel.org, Nivedita Singhvi Subject: Re: TOE brain dump References: <20030803194011.GA8324@work.bitmover.com> <20030803203051.GA9057@work.bitmover.com> In-Reply-To: <20030803203051.GA9057@work.bitmover.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4508 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 Larry McVoy wrote: > I can get an entire machine, memory, disk, > Ghz CPU, case, power supply, > cdrom, floppy, onboard enet extra net card for routing, for $250 or less, > quantity 1, shipped to my door. > > Why would I want to spend money on some silly offload card when I can get > the whole PC for less than the card? Yep. I think we are entering the era of what I call RAIC (pronounced "rake") -- redundant array of inexpensive computers. For organizations that can handle the space/power/temperature load, a powerful cluster of supercheap PCs, the "Wal-Mart Supercomputer", can be built for a rock-bottom price. From pekkas@netcore.fi Sun Aug 3 23:06:13 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 23:06:16 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7466BFl002029 for ; Sun, 3 Aug 2003 23:06:12 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h74664b12177 for ; Mon, 4 Aug 2003 09:06:05 +0300 Date: Mon, 4 Aug 2003 09:06:04 +0300 (EEST) From: Pekka Savola To: netdev@oss.sgi.com Subject: multicast IP datagram forwarding bug and fix (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4509 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 I didn't see followups to this, so I'm re-sending to the list just in case it got dropped in the cracks.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ---------- Forwarded message ---------- Date: Mon, 28 Jul 2003 13:20:31 -0400 From: "Weng, Wending" To: netdev@oss.sgi.com Subject: multicast IP datagram forwarding bug and fix > Hi, > > LINUX doesn't forward multicast IP datagram if it has option(s), there is is a bug in the module ipmr.c, function > ipmr_forward_finish, below is the current version of this function: > > static inline int ipmr_forward_finish(struct sk_buff *skb) > { > struct dst_entry *dst = skb->dst; > > if (skb->len <= dst->pmtu) > return dst->output(skb); > else > return ip_fragment(skb, dst->output); > } > > it forgets to recalculate the checksum in case the option is modified. > > The following code works properly: > > static inline int ipmr_forward_finish(struct sk_buff *skb) > { > struct dst_entry *dst = skb->dst; > > ip_forward_options (skb); /* this line recalculates checksum if needed. */ > > if (skb->len <= dst->pmtu) > return dst->output(skb); > else > return ip_fragment(skb, dst->output); > } > > Wending Weng From davem@redhat.com Sun Aug 3 23:10:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 23:10:20 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h746AAFl002620 for ; Sun, 3 Aug 2003 23:10:13 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id XAA19251; Sun, 3 Aug 2003 23:05:52 -0700 Date: Sun, 3 Aug 2003 23:05:52 -0700 From: "David S. Miller" To: Pekka Savola Cc: netdev@oss.sgi.com Subject: Re: multicast IP datagram forwarding bug and fix (fwd) Message-Id: <20030803230552.1aab9411.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4510 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 4 Aug 2003 09:06:04 +0300 (EEST) Pekka Savola wrote: > I didn't see followups to this, so I'm re-sending to the list just in case > it got dropped in the cracks.. I've already checked in a correct fix for this problem from Alexey: # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1584.2.13 -> 1.1584.2.14 # net/ipv4/ipmr.c 1.27 -> 1.28 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 03/08/02 kuznet@ms2.inr.ac.ru 1.1584.2.14 # [IPV4]: IP options were not updated while forwarding multicasts. # -------------------------------------------- # diff -Nru a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c --- a/net/ipv4/ipmr.c Sun Aug 3 23:07:44 2003 +++ b/net/ipv4/ipmr.c Sun Aug 3 23:07:44 2003 @@ -1100,6 +1100,7 @@ skb->h.ipiph = skb->nh.iph; skb->nh.iph = iph; + memset(&(IPCB(skb)->opt), 0, sizeof(IPCB(skb)->opt)); #ifdef CONFIG_NETFILTER nf_conntrack_put(skb->nfct); skb->nfct = NULL; @@ -1108,12 +1109,14 @@ static inline int ipmr_forward_finish(struct sk_buff *skb) { - struct dst_entry *dst = skb->dst; + struct ip_options * opt = &(IPCB(skb)->opt); - if (skb->len <= dst_pmtu(dst)) - return dst_output(skb); - else - return ip_fragment(skb, dst_output); + IP_INC_STATS_BH(IpForwDatagrams); + + if (unlikely(opt->optlen)) + ip_forward_options(skb); + + return dst_output(skb); } /* From pekkas@netcore.fi Sun Aug 3 23:11:39 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 03 Aug 2003 23:11:44 -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 h746BbFl003012 for ; Sun, 3 Aug 2003 23:11:38 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h746AsA12243; Mon, 4 Aug 2003 09:11:00 +0300 Date: Mon, 4 Aug 2003 09:10:53 +0300 (EEST) From: Pekka Savola To: Lamont Granquist cc: Bill Davidsen , "David S. Miller" , Carlos Velasco , , , , , , , Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices In-Reply-To: <20030728213933.F81299@coredump.scriptkiddie.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4511 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev Hi, Just a thought.. How about consider this change for 2.6 kernel series at this point, and don't backport it 2.4 at least first and/or make the behaviour configurable? Upgrading from 2.4 to 2.6 should be a step big enough that folks should revisit their more advanced configurations, causing smaller surprises. Changing the behaviour inside 2.4.x series might not be reasonable. On Mon, 28 Jul 2003, Lamont Granquist wrote: > On Mon, 28 Jul 2003, Bill Davidsen wrote: > > On Sun, 27 Jul 2003, David S. Miller wrote: > > > This particular case has been discussed to death in the past > > > and I really recommend people read up there before dragging this > > > out further. > > > > It will keep coming back because it's a real problem. I do agree that the > > hidden patch is not the desired way to solve the problem, but until there > > is a reasonable (not requiring a guru or large manual effort) solution > > people will keep bringing it up. > > And it severely violates the principle of least surprise. Its unfortunate > that this principle isn't more widely discussed and considered on lkml. > -- 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 andi@averellmail.firstfloor.org Mon Aug 4 05:50:32 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Aug 2003 05:50:45 -0700 (PDT) Received: from zero.aec.at (Bishop.Potter@zero.aec.at [193.170.194.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h74CoSFl017874 for ; Mon, 4 Aug 2003 05:50:30 -0700 Received: from fred.muc.de (Jared.Oopf@localhost.localdomain [127.0.0.1]) by zero.aec.at (8.11.6/8.11.2) with ESMTP id h74CoLm04438 for ; Mon, 4 Aug 2003 14:50:21 +0200 Received: by fred.muc.de (Postfix on SuSE Linux 7.3 (i386), from userid 500) id C18D35BB86; Mon, 4 Aug 2003 14:50:22 +0200 (CEST) Date: Mon, 4 Aug 2003 14:50:22 +0200 From: Andi Kleen To: netdev@oss.sgi.com Subject: [PATCH] Make XFRM optional Message-ID: <20030804125022.GA8167@averell> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 4512 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Only compile in the xfrm subsystem when it's needed by any config options. This avoids some code/data structure bloat in case you don't use IP tunneling or IPsec. Also adds a net_ratelimit() to a unprotected printk. For 2.6.0test2 -Andi diff -u linux-work/include/net/dst.h-XFRM linux-work/include/net/dst.h --- linux-work/include/net/dst.h-XFRM 2003-07-18 02:40:02.000000000 +0200 +++ linux-work/include/net/dst.h 2003-08-03 23:12:24.000000000 +0200 @@ -247,8 +247,16 @@ extern void dst_init(void); struct flowi; +#ifndef CONFIG_XFRM +static inline int xfrm_lookup(struct dst_entry **dst_p, struct flowi *fl, + struct sock *sk, int flags) +{ + return 0; +} +#else extern int xfrm_lookup(struct dst_entry **dst_p, struct flowi *fl, struct sock *sk, int flags); #endif +#endif #endif /* _NET_DST_H */ diff -u linux-work/include/net/xfrm.h-XFRM linux-work/include/net/xfrm.h --- linux-work/include/net/xfrm.h-XFRM 2003-07-28 23:12:30.000000000 +0200 +++ linux-work/include/net/xfrm.h 2003-08-03 23:14:04.000000000 +0200 @@ -587,6 +587,8 @@ return !0; } +#ifdef CONFIG_XFRM + extern int __xfrm_policy_check(struct sock *, int dir, struct sk_buff *skb, unsigned short family); static inline int xfrm_policy_check(struct sock *sk, int dir, struct sk_buff *skb, unsigned short family) @@ -652,6 +654,26 @@ } } +#else + +static inline void xfrm_sk_free_policy(struct sock *sk) {} +static inline int xfrm_sk_clone_policy(struct sock *sk) { return 0; } +static inline int xfrm6_route_forward(struct sk_buff *skb) { return 1; } +static inline int xfrm4_route_forward(struct sk_buff *skb) { return 1; } +static inline int xfrm6_policy_check(struct sock *sk, int dir, struct sk_buff *skb) +{ + return 1; +} +static inline int xfrm4_policy_check(struct sock *sk, int dir, struct sk_buff *skb) +{ + return 1; +} +static inline int xfrm_policy_check(struct sock *sk, int dir, struct sk_buff *skb, unsigned short family) +{ + return 1; +} +#endif + static __inline__ xfrm_address_t *xfrm_flowi_daddr(struct flowi *fl, unsigned short family) { @@ -782,12 +804,32 @@ extern int xfrm_check_selectors(struct xfrm_state **x, int n, struct flowi *fl); extern int xfrm_check_output(struct xfrm_state *x, struct sk_buff *skb, unsigned short family); extern int xfrm4_rcv(struct sk_buff *skb); -extern int xfrm4_rcv_encap(struct sk_buff *skb, __u16 encap_type); extern int xfrm4_tunnel_register(struct xfrm_tunnel *handler); extern int xfrm4_tunnel_deregister(struct xfrm_tunnel *handler); extern int xfrm4_tunnel_check_size(struct sk_buff *skb); extern int xfrm6_rcv(struct sk_buff **pskb, unsigned int *nhoffp); + +#ifdef CONFIG_XFRM +extern int xfrm4_rcv_encap(struct sk_buff *skb, __u16 encap_type); extern int xfrm_user_policy(struct sock *sk, int optname, u8 *optval, int optlen); +extern int xfrm_dst_lookup(struct xfrm_dst **dst, struct flowi *fl, unsigned short family); +#else +static inline int xfrm_user_policy(struct sock *sk, int optname, u8 *optval, int optlen) +{ + return -ENOPROTOOPT; +} + +static inline int xfrm4_rcv_encap(struct sk_buff *skb, __u16 encap_type) +{ + /* should not happen */ + kfree_skb(skb); + return 0; +} +static inline int xfrm_dst_lookup(struct xfrm_dst **dst, struct flowi *fl, unsigned short family) +{ + return -EINVAL; +} +#endif void xfrm_policy_init(void); void xfrm4_policy_init(void); @@ -809,7 +851,6 @@ extern int xfrm_sk_policy_insert(struct sock *sk, int dir, struct xfrm_policy *pol); extern struct xfrm_policy *xfrm_sk_policy_lookup(struct sock *sk, int dir, struct flowi *fl); extern int xfrm_flush_bundles(struct xfrm_state *x); -extern int xfrm_dst_lookup(struct xfrm_dst **dst, struct flowi *fl, unsigned short family); extern wait_queue_head_t km_waitq; extern void km_state_expired(struct xfrm_state *x, int hard); diff -u linux-work/net/core/skbuff.c-XFRM linux-work/net/core/skbuff.c --- linux-work/net/core/skbuff.c-XFRM 2003-07-18 02:39:47.000000000 +0200 +++ linux-work/net/core/skbuff.c 2003-08-03 23:12:25.000000000 +0200 @@ -225,7 +225,7 @@ } dst_release(skb->dst); -#ifdef CONFIG_INET +#ifdef CONFIG_XFRM secpath_put(skb->sp); #endif if(skb->destructor) { diff -u linux-work/net/ipv4/Kconfig-XFRM linux-work/net/ipv4/Kconfig --- linux-work/net/ipv4/Kconfig-XFRM 2003-07-18 02:42:42.000000000 +0200 +++ linux-work/net/ipv4/Kconfig 2003-08-03 23:12:25.000000000 +0200 @@ -187,6 +187,7 @@ config NET_IPIP tristate "IP: tunneling" depends on INET + select XFRM ---help--- Tunneling means encapsulating data of one protocol type within another protocol and sending it over a channel that understands the @@ -205,6 +206,7 @@ config NET_IPGRE tristate "IP: GRE tunnels over IP" depends on INET + select XFRM help Tunneling means encapsulating data of one protocol type within another protocol and sending it over a channel that understands the @@ -343,6 +345,7 @@ config INET_AH tristate "IP: AH transformation" + select XFRM select CRYPTO select CRYPTO_HMAC select CRYPTO_MD5 @@ -354,6 +357,7 @@ config INET_ESP tristate "IP: ESP transformation" + select XFRM select CRYPTO select CRYPTO_HMAC select CRYPTO_MD5 @@ -366,6 +370,7 @@ config INET_IPCOMP tristate "IP: IPComp transformation" + select XFRM select CRYPTO select CRYPTO_DEFLATE ---help--- diff -u linux-work/net/ipv4/Makefile-XFRM linux-work/net/ipv4/Makefile --- linux-work/net/ipv4/Makefile-XFRM 2003-07-18 02:42:42.000000000 +0200 +++ linux-work/net/ipv4/Makefile 2003-08-03 23:12:25.000000000 +0200 @@ -23,4 +23,4 @@ obj-$(CONFIG_NETFILTER) += netfilter/ obj-$(CONFIG_IP_VS) += ipvs/ -obj-y += xfrm4_policy.o xfrm4_state.o xfrm4_input.o xfrm4_tunnel.o +obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o xfrm4_tunnel.o diff -u linux-work/net/ipv4/route.c-XFRM linux-work/net/ipv4/route.c --- linux-work/net/ipv4/route.c-XFRM 2003-07-18 02:39:31.000000000 +0200 +++ linux-work/net/ipv4/route.c 2003-08-03 23:12:25.000000000 +0200 @@ -2785,8 +2785,10 @@ create_proc_read_entry("net/rt_acct", 0, 0, ip_rt_acct_read, NULL); #endif #endif +#ifdef CONFIG_XFRM xfrm_init(); xfrm4_init(); +#endif out: return rc; out_enomem: diff -u linux-work/net/ipv4/udp.c-XFRM linux-work/net/ipv4/udp.c --- linux-work/net/ipv4/udp.c-XFRM 2003-07-18 02:42:43.000000000 +0200 +++ linux-work/net/ipv4/udp.c 2003-08-03 23:31:05.000000000 +0200 @@ -938,6 +938,9 @@ */ static int udp_encap_rcv(struct sock * sk, struct sk_buff *skb) { +#ifndef CONFIG_XFRM + return 1; +#else struct udp_opt *up = udp_sk(sk); struct udphdr *uh = skb->h.uh; struct iphdr *iph; @@ -997,10 +1000,12 @@ return -1; default: - printk(KERN_INFO "udp_encap_rcv(): Unhandled UDP encap type: %u\n", - encap_type); + if (net_ratelimit()) + printk(KERN_INFO "udp_encap_rcv(): Unhandled UDP encap type: %u\n", + encap_type); return 1; } +#endif } /* returns: diff -u linux-work/net/ipv6/Kconfig-XFRM linux-work/net/ipv6/Kconfig --- linux-work/net/ipv6/Kconfig-XFRM 2003-07-18 02:39:29.000000000 +0200 +++ linux-work/net/ipv6/Kconfig 2003-08-03 23:12:25.000000000 +0200 @@ -4,6 +4,7 @@ config IPV6_PRIVACY bool "IPv6: Privacy Extensions (RFC 3041) support" depends on IPV6 + select XFRM select CRYPTO select CRYPTO_MD5 ---help--- @@ -22,6 +23,7 @@ config INET6_AH tristate "IPv6: AH transformation" depends on IPV6 + select XFRM select CRYPTO select CRYPTO_HMAC select CRYPTO_MD5 @@ -34,6 +36,7 @@ config INET6_ESP tristate "IPv6: ESP transformation" depends on IPV6 + select XFRM select CRYPTO select CRYPTO_HMAC select CRYPTO_MD5 @@ -47,6 +50,7 @@ config INET6_IPCOMP tristate "IPv6: IPComp transformation" depends on IPV6 + select XFRM select CRYPTO select CRYPTO_DEFLATE ---help--- @@ -57,6 +61,7 @@ config IPV6_TUNNEL tristate "IPv6: IPv6-in-IPv6 tunnel" + select XFRM depends on IPV6 ---help--- Support for IPv6-in-IPv6 tunnels described in RFC 2473. diff -u linux-work/net/ipv6/Makefile-XFRM linux-work/net/ipv6/Makefile --- linux-work/net/ipv6/Makefile-XFRM 2003-07-18 02:39:29.000000000 +0200 +++ linux-work/net/ipv6/Makefile 2003-08-03 23:12:25.000000000 +0200 @@ -8,8 +8,9 @@ route.o ip6_fib.o ipv6_sockglue.o ndisc.o udp.o raw.o \ protocol.o icmp.o mcast.o reassembly.o tcp_ipv6.o \ exthdrs.o sysctl_net_ipv6.o datagram.o proc.o \ - ip6_flowlabel.o ipv6_syms.o \ - xfrm6_policy.o xfrm6_state.o xfrm6_input.o + ip6_flowlabel.o ipv6_syms.o + +obj-$(CONFIG_XFRM) += xfrm6_policy.o xfrm6_state.o xfrm6_input.o obj-$(CONFIG_INET6_AH) += ah6.o obj-$(CONFIG_INET6_ESP) += esp6.o diff -u linux-work/net/ipv6/ipv6_syms.c-XFRM linux-work/net/ipv6/ipv6_syms.c --- linux-work/net/ipv6/ipv6_syms.c-XFRM 2003-07-18 02:39:31.000000000 +0200 +++ linux-work/net/ipv6/ipv6_syms.c 2003-08-03 23:14:41.000000000 +0200 @@ -36,7 +36,9 @@ EXPORT_SYMBOL(in6addr_loopback); EXPORT_SYMBOL(in6_dev_finish_destroy); EXPORT_SYMBOL(ip6_find_1stfragopt); +#ifdef CONFIG_XFRM EXPORT_SYMBOL(xfrm6_rcv); +#endif EXPORT_SYMBOL(rt6_lookup); EXPORT_SYMBOL(fl6_sock_lookup); EXPORT_SYMBOL(ipv6_ext_hdr); diff -u linux-work/net/ipv6/route.c-XFRM linux-work/net/ipv6/route.c --- linux-work/net/ipv6/route.c-XFRM 2003-07-28 23:12:32.000000000 +0200 +++ linux-work/net/ipv6/route.c 2003-08-03 23:12:25.000000000 +0200 @@ -1988,7 +1988,9 @@ if (p) p->proc_fops = &rt6_stats_seq_fops; #endif +#ifdef CONFIG_XFRM xfrm6_init(); +#endif } #ifdef MODULE diff -u linux-work/net/xfrm/Kconfig-XFRM linux-work/net/xfrm/Kconfig --- linux-work/net/xfrm/Kconfig-XFRM 2003-05-27 03:00:40.000000000 +0200 +++ linux-work/net/xfrm/Kconfig 2003-08-03 23:12:25.000000000 +0200 @@ -1,9 +1,13 @@ # # XFRM configuration # +config XFRM + bool + depends on NET + config XFRM_USER tristate "IPsec user configuration interface" - depends on INET + depends on INET && XFRM ---help--- Support for IPsec user configuration interface used by native Linux tools. diff -u linux-work/net/xfrm/Makefile-XFRM linux-work/net/xfrm/Makefile --- linux-work/net/xfrm/Makefile-XFRM 2003-05-27 03:01:03.000000000 +0200 +++ linux-work/net/xfrm/Makefile 2003-08-03 23:12:25.000000000 +0200 @@ -2,6 +2,7 @@ # Makefile for the XFRM subsystem. # -obj-y := xfrm_policy.o xfrm_state.o xfrm_input.o xfrm_algo.o xfrm_output.o +obj-$(CONFIG_XFRM) := xfrm_policy.o xfrm_state.o xfrm_input.o xfrm_algo.o xfrm_output.o \ + xfrm_export.o obj-$(CONFIG_XFRM_USER) += xfrm_user.o diff -u linux-work/net/xfrm/xfrm_export.c-XFRM linux-work/net/xfrm/xfrm_export.c --- linux-work/net/xfrm/xfrm_export.c-XFRM 2003-08-03 23:12:25.000000000 +0200 +++ linux-work/net/xfrm/xfrm_export.c 2003-08-03 23:16:06.000000000 +0200 @@ -0,0 +1,76 @@ +#include +#include + +EXPORT_SYMBOL(xfrm_user_policy); +EXPORT_SYMBOL(km_waitq); +EXPORT_SYMBOL(km_new_mapping); +EXPORT_SYMBOL(xfrm_cfg_sem); +EXPORT_SYMBOL(xfrm_policy_alloc); +EXPORT_SYMBOL(__xfrm_policy_destroy); +EXPORT_SYMBOL(xfrm_lookup); +EXPORT_SYMBOL(__xfrm_policy_check); +EXPORT_SYMBOL(__xfrm_route_forward); +EXPORT_SYMBOL(xfrm_state_alloc); +EXPORT_SYMBOL(__xfrm_state_destroy); +EXPORT_SYMBOL(xfrm_state_find); +EXPORT_SYMBOL(xfrm_state_insert); +EXPORT_SYMBOL(xfrm_state_add); +EXPORT_SYMBOL(xfrm_state_update); +EXPORT_SYMBOL(xfrm_state_check_expire); +EXPORT_SYMBOL(xfrm_state_check_space); +EXPORT_SYMBOL(xfrm_state_lookup); +EXPORT_SYMBOL(xfrm_state_register_afinfo); +EXPORT_SYMBOL(xfrm_state_unregister_afinfo); +EXPORT_SYMBOL(xfrm_state_get_afinfo); +EXPORT_SYMBOL(xfrm_state_put_afinfo); +EXPORT_SYMBOL(xfrm_state_delete_tunnel); +EXPORT_SYMBOL(xfrm_replay_check); +EXPORT_SYMBOL(xfrm_replay_advance); +EXPORT_SYMBOL(xfrm_check_selectors); +EXPORT_SYMBOL(xfrm_check_output); +EXPORT_SYMBOL(__secpath_destroy); +EXPORT_SYMBOL(xfrm_get_acqseq); +EXPORT_SYMBOL(xfrm_parse_spi); +EXPORT_SYMBOL(xfrm4_rcv); +EXPORT_SYMBOL(xfrm4_tunnel_register); +EXPORT_SYMBOL(xfrm4_tunnel_deregister); +EXPORT_SYMBOL(xfrm4_tunnel_check_size); +EXPORT_SYMBOL(xfrm_register_type); +EXPORT_SYMBOL(xfrm_unregister_type); +EXPORT_SYMBOL(xfrm_get_type); +EXPORT_SYMBOL(inet_peer_idlock); +EXPORT_SYMBOL(xfrm_register_km); +EXPORT_SYMBOL(xfrm_unregister_km); +EXPORT_SYMBOL(xfrm_state_delete); +EXPORT_SYMBOL(xfrm_state_walk); +EXPORT_SYMBOL(xfrm_find_acq_byseq); +EXPORT_SYMBOL(xfrm_find_acq); +EXPORT_SYMBOL(xfrm_alloc_spi); +EXPORT_SYMBOL(xfrm_state_flush); +EXPORT_SYMBOL(xfrm_policy_kill); +EXPORT_SYMBOL(xfrm_policy_bysel); +EXPORT_SYMBOL(xfrm_policy_insert); +EXPORT_SYMBOL(xfrm_policy_walk); +EXPORT_SYMBOL(xfrm_policy_flush); +EXPORT_SYMBOL(xfrm_policy_byid); +EXPORT_SYMBOL(xfrm_policy_list); +EXPORT_SYMBOL(xfrm_dst_lookup); +EXPORT_SYMBOL(xfrm_policy_register_afinfo); +EXPORT_SYMBOL(xfrm_policy_unregister_afinfo); +EXPORT_SYMBOL(xfrm_policy_get_afinfo); +EXPORT_SYMBOL(xfrm_policy_put_afinfo); + +EXPORT_SYMBOL_GPL(xfrm_probe_algs); +EXPORT_SYMBOL_GPL(xfrm_count_auth_supported); +EXPORT_SYMBOL_GPL(xfrm_count_enc_supported); +EXPORT_SYMBOL_GPL(xfrm_aalg_get_byidx); +EXPORT_SYMBOL_GPL(xfrm_ealg_get_byidx); +EXPORT_SYMBOL_GPL(xfrm_calg_get_byidx); +EXPORT_SYMBOL_GPL(xfrm_aalg_get_byid); +EXPORT_SYMBOL_GPL(xfrm_ealg_get_byid); +EXPORT_SYMBOL_GPL(xfrm_calg_get_byid); +EXPORT_SYMBOL_GPL(xfrm_aalg_get_byname); +EXPORT_SYMBOL_GPL(xfrm_ealg_get_byname); +EXPORT_SYMBOL_GPL(xfrm_calg_get_byname); + +EXPORT_SYMBOL_GPL(skb_icv_walk); diff -u linux-work/net/Kconfig-XFRM linux-work/net/Kconfig --- linux-work/net/Kconfig-XFRM 2003-05-27 03:00:21.000000000 +0200 +++ linux-work/net/Kconfig 2003-08-03 23:12:24.000000000 +0200 @@ -143,6 +143,7 @@ config NET_KEY tristate "PF_KEY sockets" + select XFRM ---help--- PF_KEYv2 socket family, compatible to KAME ones. They are required if you are going to use IPsec tools ported diff -u linux-work/net/netsyms.c-XFRM linux-work/net/netsyms.c --- linux-work/net/netsyms.c-XFRM 2003-07-28 23:12:33.000000000 +0200 +++ linux-work/net/netsyms.c 2003-08-03 23:16:23.000000000 +0200 @@ -56,7 +56,6 @@ #include #include #include -#include #if defined(CONFIG_INET_AH) || defined(CONFIG_INET_AH_MODULE) || defined(CONFIG_INET6_AH) || defined(CONFIG_INET6_AH_MODULE) #include #endif @@ -294,78 +293,6 @@ /* needed for ip_gre -cw */ EXPORT_SYMBOL(ip_statistics); -EXPORT_SYMBOL(xfrm_user_policy); -EXPORT_SYMBOL(km_waitq); -EXPORT_SYMBOL(km_new_mapping); -EXPORT_SYMBOL(xfrm_cfg_sem); -EXPORT_SYMBOL(xfrm_policy_alloc); -EXPORT_SYMBOL(__xfrm_policy_destroy); -EXPORT_SYMBOL(xfrm_lookup); -EXPORT_SYMBOL(__xfrm_policy_check); -EXPORT_SYMBOL(__xfrm_route_forward); -EXPORT_SYMBOL(xfrm_state_alloc); -EXPORT_SYMBOL(__xfrm_state_destroy); -EXPORT_SYMBOL(xfrm_state_find); -EXPORT_SYMBOL(xfrm_state_insert); -EXPORT_SYMBOL(xfrm_state_add); -EXPORT_SYMBOL(xfrm_state_update); -EXPORT_SYMBOL(xfrm_state_check_expire); -EXPORT_SYMBOL(xfrm_state_check_space); -EXPORT_SYMBOL(xfrm_state_lookup); -EXPORT_SYMBOL(xfrm_state_register_afinfo); -EXPORT_SYMBOL(xfrm_state_unregister_afinfo); -EXPORT_SYMBOL(xfrm_state_get_afinfo); -EXPORT_SYMBOL(xfrm_state_put_afinfo); -EXPORT_SYMBOL(xfrm_state_delete_tunnel); -EXPORT_SYMBOL(xfrm_replay_check); -EXPORT_SYMBOL(xfrm_replay_advance); -EXPORT_SYMBOL(xfrm_check_selectors); -EXPORT_SYMBOL(xfrm_check_output); -EXPORT_SYMBOL(__secpath_destroy); -EXPORT_SYMBOL(xfrm_get_acqseq); -EXPORT_SYMBOL(xfrm_parse_spi); -EXPORT_SYMBOL(xfrm4_rcv); -EXPORT_SYMBOL(xfrm4_tunnel_register); -EXPORT_SYMBOL(xfrm4_tunnel_deregister); -EXPORT_SYMBOL(xfrm4_tunnel_check_size); -EXPORT_SYMBOL(xfrm_register_type); -EXPORT_SYMBOL(xfrm_unregister_type); -EXPORT_SYMBOL(xfrm_get_type); -EXPORT_SYMBOL(inet_peer_idlock); -EXPORT_SYMBOL(xfrm_register_km); -EXPORT_SYMBOL(xfrm_unregister_km); -EXPORT_SYMBOL(xfrm_state_delete); -EXPORT_SYMBOL(xfrm_state_walk); -EXPORT_SYMBOL(xfrm_find_acq_byseq); -EXPORT_SYMBOL(xfrm_find_acq); -EXPORT_SYMBOL(xfrm_alloc_spi); -EXPORT_SYMBOL(xfrm_state_flush); -EXPORT_SYMBOL(xfrm_policy_kill); -EXPORT_SYMBOL(xfrm_policy_bysel); -EXPORT_SYMBOL(xfrm_policy_insert); -EXPORT_SYMBOL(xfrm_policy_walk); -EXPORT_SYMBOL(xfrm_policy_flush); -EXPORT_SYMBOL(xfrm_policy_byid); -EXPORT_SYMBOL(xfrm_policy_list); -EXPORT_SYMBOL(xfrm_dst_lookup); -EXPORT_SYMBOL(xfrm_policy_register_afinfo); -EXPORT_SYMBOL(xfrm_policy_unregister_afinfo); -EXPORT_SYMBOL(xfrm_policy_get_afinfo); -EXPORT_SYMBOL(xfrm_policy_put_afinfo); - -EXPORT_SYMBOL_GPL(xfrm_probe_algs); -EXPORT_SYMBOL_GPL(xfrm_count_auth_supported); -EXPORT_SYMBOL_GPL(xfrm_count_enc_supported); -EXPORT_SYMBOL_GPL(xfrm_aalg_get_byidx); -EXPORT_SYMBOL_GPL(xfrm_ealg_get_byidx); -EXPORT_SYMBOL_GPL(xfrm_calg_get_byidx); -EXPORT_SYMBOL_GPL(xfrm_aalg_get_byid); -EXPORT_SYMBOL_GPL(xfrm_ealg_get_byid); -EXPORT_SYMBOL_GPL(xfrm_calg_get_byid); -EXPORT_SYMBOL_GPL(xfrm_aalg_get_byname); -EXPORT_SYMBOL_GPL(xfrm_ealg_get_byname); -EXPORT_SYMBOL_GPL(xfrm_calg_get_byname); -EXPORT_SYMBOL_GPL(skb_icv_walk); #if defined(CONFIG_INET_ESP) || defined(CONFIG_INET_ESP_MODULE) || defined(CONFIG_INET6_ESP) || defined(CONFIG_INET6_ESP_MODULE) EXPORT_SYMBOL_GPL(skb_cow_data); EXPORT_SYMBOL_GPL(pskb_put); From yoshfuji@linux-ipv6.org Mon Aug 4 05:58:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Aug 2003 05:58:08 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h74Cw1Fl018295 for ; Mon, 4 Aug 2003 05:58:03 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h74Cw11M000463; Mon, 4 Aug 2003 21:58:01 +0900 Date: Mon, 04 Aug 2003 21:58:01 +0900 (JST) Message-Id: <20030804.215801.124854897.yoshfuji@linux-ipv6.org> To: ak@muc.de Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] Make XFRM optional From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20030804125022.GA8167@averell> References: <20030804125022.GA8167@averell> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4513 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Hello. In article <20030804125022.GA8167@averell> (at Mon, 4 Aug 2003 14:50:22 +0200), Andi Kleen says: > diff -u linux-work/net/ipv6/Kconfig-XFRM linux-work/net/ipv6/Kconfig > --- linux-work/net/ipv6/Kconfig-XFRM 2003-07-18 02:39:29.000000000 +0200 > +++ linux-work/net/ipv6/Kconfig 2003-08-03 23:12:25.000000000 +0200 > @@ -4,6 +4,7 @@ > config IPV6_PRIVACY > bool "IPv6: Privacy Extensions (RFC 3041) support" > depends on IPV6 > + select XFRM > select CRYPTO > select CRYPTO_MD5 > ---help--- We do not need this. > @@ -57,6 +61,7 @@ > > config IPV6_TUNNEL > tristate "IPv6: IPv6-in-IPv6 tunnel" > + select XFRM > depends on IPV6 > ---help--- > Support for IPv6-in-IPv6 tunnels described in RFC 2473. We do not need this for now. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From ak@muc.de Mon Aug 4 06:04:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Aug 2003 06:04:29 -0700 (PDT) Received: from colin2.muc.de (qmailr@colin2.muc.de [193.149.48.15]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h74D4CFl018727 for ; Mon, 4 Aug 2003 06:04:14 -0700 Received: (qmail 39137 invoked by uid 3709); 4 Aug 2003 13:04:08 -0000 Date: 4 Aug 2003 15:04:08 +0200 Date: Mon, 4 Aug 2003 15:04:08 +0200 From: Andi Kleen To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: ak@muc.de, netdev@oss.sgi.com Subject: Re: [PATCH] Make XFRM optional Message-ID: <20030804130408.GA36367@colin2.muc.de> References: <20030804125022.GA8167@averell> <20030804.215801.124854897.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030804.215801.124854897.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.4.1i X-archive-position: 4514 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@colin2.muc.de Precedence: bulk X-list: netdev On Mon, Aug 04, 2003 at 09:58:01PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > Hello. > > In article <20030804125022.GA8167@averell> (at Mon, 4 Aug 2003 14:50:22 +0200), Andi Kleen says: > > > diff -u linux-work/net/ipv6/Kconfig-XFRM linux-work/net/ipv6/Kconfig > > --- linux-work/net/ipv6/Kconfig-XFRM 2003-07-18 02:39:29.000000000 +0200 > > +++ linux-work/net/ipv6/Kconfig 2003-08-03 23:12:25.000000000 +0200 > > @@ -4,6 +4,7 @@ > > config IPV6_PRIVACY > > bool "IPv6: Privacy Extensions (RFC 3041) support" > > depends on IPV6 > > + select XFRM > > select CRYPTO > > select CRYPTO_MD5 > > ---help--- > > We do not need this. Thanks for the feedback. Here is a new patch with the two hunks removed. -Andi diff -u linux-work/include/net/dst.h-XFRM linux-work/include/net/dst.h --- linux-work/include/net/dst.h-XFRM 2003-07-18 02:40:02.000000000 +0200 +++ linux-work/include/net/dst.h 2003-08-03 23:12:24.000000000 +0200 @@ -247,8 +247,16 @@ extern void dst_init(void); struct flowi; +#ifndef CONFIG_XFRM +static inline int xfrm_lookup(struct dst_entry **dst_p, struct flowi *fl, + struct sock *sk, int flags) +{ + return 0; +} +#else extern int xfrm_lookup(struct dst_entry **dst_p, struct flowi *fl, struct sock *sk, int flags); #endif +#endif #endif /* _NET_DST_H */ diff -u linux-work/include/net/xfrm.h-XFRM linux-work/include/net/xfrm.h --- linux-work/include/net/xfrm.h-XFRM 2003-07-28 23:12:30.000000000 +0200 +++ linux-work/include/net/xfrm.h 2003-08-03 23:14:04.000000000 +0200 @@ -587,6 +587,8 @@ return !0; } +#ifdef CONFIG_XFRM + extern int __xfrm_policy_check(struct sock *, int dir, struct sk_buff *skb, unsigned short family); static inline int xfrm_policy_check(struct sock *sk, int dir, struct sk_buff *skb, unsigned short family) @@ -652,6 +654,26 @@ } } +#else + +static inline void xfrm_sk_free_policy(struct sock *sk) {} +static inline int xfrm_sk_clone_policy(struct sock *sk) { return 0; } +static inline int xfrm6_route_forward(struct sk_buff *skb) { return 1; } +static inline int xfrm4_route_forward(struct sk_buff *skb) { return 1; } +static inline int xfrm6_policy_check(struct sock *sk, int dir, struct sk_buff *skb) +{ + return 1; +} +static inline int xfrm4_policy_check(struct sock *sk, int dir, struct sk_buff *skb) +{ + return 1; +} +static inline int xfrm_policy_check(struct sock *sk, int dir, struct sk_buff *skb, unsigned short family) +{ + return 1; +} +#endif + static __inline__ xfrm_address_t *xfrm_flowi_daddr(struct flowi *fl, unsigned short family) { @@ -782,12 +804,32 @@ extern int xfrm_check_selectors(struct xfrm_state **x, int n, struct flowi *fl); extern int xfrm_check_output(struct xfrm_state *x, struct sk_buff *skb, unsigned short family); extern int xfrm4_rcv(struct sk_buff *skb); -extern int xfrm4_rcv_encap(struct sk_buff *skb, __u16 encap_type); extern int xfrm4_tunnel_register(struct xfrm_tunnel *handler); extern int xfrm4_tunnel_deregister(struct xfrm_tunnel *handler); extern int xfrm4_tunnel_check_size(struct sk_buff *skb); extern int xfrm6_rcv(struct sk_buff **pskb, unsigned int *nhoffp); + +#ifdef CONFIG_XFRM +extern int xfrm4_rcv_encap(struct sk_buff *skb, __u16 encap_type); extern int xfrm_user_policy(struct sock *sk, int optname, u8 *optval, int optlen); +extern int xfrm_dst_lookup(struct xfrm_dst **dst, struct flowi *fl, unsigned short family); +#else +static inline int xfrm_user_policy(struct sock *sk, int optname, u8 *optval, int optlen) +{ + return -ENOPROTOOPT; +} + +static inline int xfrm4_rcv_encap(struct sk_buff *skb, __u16 encap_type) +{ + /* should not happen */ + kfree_skb(skb); + return 0; +} +static inline int xfrm_dst_lookup(struct xfrm_dst **dst, struct flowi *fl, unsigned short family) +{ + return -EINVAL; +} +#endif void xfrm_policy_init(void); void xfrm4_policy_init(void); @@ -809,7 +851,6 @@ extern int xfrm_sk_policy_insert(struct sock *sk, int dir, struct xfrm_policy *pol); extern struct xfrm_policy *xfrm_sk_policy_lookup(struct sock *sk, int dir, struct flowi *fl); extern int xfrm_flush_bundles(struct xfrm_state *x); -extern int xfrm_dst_lookup(struct xfrm_dst **dst, struct flowi *fl, unsigned short family); extern wait_queue_head_t km_waitq; extern void km_state_expired(struct xfrm_state *x, int hard); diff -u linux-work/net/core/skbuff.c-XFRM linux-work/net/core/skbuff.c --- linux-work/net/core/skbuff.c-XFRM 2003-07-18 02:39:47.000000000 +0200 +++ linux-work/net/core/skbuff.c 2003-08-03 23:12:25.000000000 +0200 @@ -225,7 +225,7 @@ } dst_release(skb->dst); -#ifdef CONFIG_INET +#ifdef CONFIG_XFRM secpath_put(skb->sp); #endif if(skb->destructor) { diff -u linux-work/net/ipv4/Kconfig-XFRM linux-work/net/ipv4/Kconfig --- linux-work/net/ipv4/Kconfig-XFRM 2003-07-18 02:42:42.000000000 +0200 +++ linux-work/net/ipv4/Kconfig 2003-08-03 23:12:25.000000000 +0200 @@ -187,6 +187,7 @@ config NET_IPIP tristate "IP: tunneling" depends on INET + select XFRM ---help--- Tunneling means encapsulating data of one protocol type within another protocol and sending it over a channel that understands the @@ -205,6 +206,7 @@ config NET_IPGRE tristate "IP: GRE tunnels over IP" depends on INET + select XFRM help Tunneling means encapsulating data of one protocol type within another protocol and sending it over a channel that understands the @@ -343,6 +345,7 @@ config INET_AH tristate "IP: AH transformation" + select XFRM select CRYPTO select CRYPTO_HMAC select CRYPTO_MD5 @@ -354,6 +357,7 @@ config INET_ESP tristate "IP: ESP transformation" + select XFRM select CRYPTO select CRYPTO_HMAC select CRYPTO_MD5 @@ -366,6 +370,7 @@ config INET_IPCOMP tristate "IP: IPComp transformation" + select XFRM select CRYPTO select CRYPTO_DEFLATE ---help--- diff -u linux-work/net/ipv4/Makefile-XFRM linux-work/net/ipv4/Makefile --- linux-work/net/ipv4/Makefile-XFRM 2003-07-18 02:42:42.000000000 +0200 +++ linux-work/net/ipv4/Makefile 2003-08-03 23:12:25.000000000 +0200 @@ -23,4 +23,4 @@ obj-$(CONFIG_NETFILTER) += netfilter/ obj-$(CONFIG_IP_VS) += ipvs/ -obj-y += xfrm4_policy.o xfrm4_state.o xfrm4_input.o xfrm4_tunnel.o +obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o xfrm4_tunnel.o diff -u linux-work/net/ipv4/route.c-XFRM linux-work/net/ipv4/route.c --- linux-work/net/ipv4/route.c-XFRM 2003-07-18 02:39:31.000000000 +0200 +++ linux-work/net/ipv4/route.c 2003-08-03 23:12:25.000000000 +0200 @@ -2785,8 +2785,10 @@ create_proc_read_entry("net/rt_acct", 0, 0, ip_rt_acct_read, NULL); #endif #endif +#ifdef CONFIG_XFRM xfrm_init(); xfrm4_init(); +#endif out: return rc; out_enomem: diff -u linux-work/net/ipv4/udp.c-XFRM linux-work/net/ipv4/udp.c --- linux-work/net/ipv4/udp.c-XFRM 2003-07-18 02:42:43.000000000 +0200 +++ linux-work/net/ipv4/udp.c 2003-08-03 23:31:05.000000000 +0200 @@ -938,6 +938,9 @@ */ static int udp_encap_rcv(struct sock * sk, struct sk_buff *skb) { +#ifndef CONFIG_XFRM + return 1; +#else struct udp_opt *up = udp_sk(sk); struct udphdr *uh = skb->h.uh; struct iphdr *iph; @@ -997,10 +1000,12 @@ return -1; default: - printk(KERN_INFO "udp_encap_rcv(): Unhandled UDP encap type: %u\n", - encap_type); + if (net_ratelimit()) + printk(KERN_INFO "udp_encap_rcv(): Unhandled UDP encap type: %u\n", + encap_type); return 1; } +#endif } /* returns: diff -u linux-work/net/ipv6/Kconfig-XFRM linux-work/net/ipv6/Kconfig --- linux-work/net/ipv6/Kconfig-XFRM 2003-07-18 02:39:29.000000000 +0200 +++ linux-work/net/ipv6/Kconfig 2003-08-03 23:12:25.000000000 +0200 @@ -22,6 +23,7 @@ config INET6_AH tristate "IPv6: AH transformation" depends on IPV6 + select XFRM select CRYPTO select CRYPTO_HMAC select CRYPTO_MD5 @@ -34,6 +36,7 @@ config INET6_ESP tristate "IPv6: ESP transformation" depends on IPV6 + select XFRM select CRYPTO select CRYPTO_HMAC select CRYPTO_MD5 @@ -47,6 +50,7 @@ config INET6_IPCOMP tristate "IPv6: IPComp transformation" depends on IPV6 + select XFRM select CRYPTO select CRYPTO_DEFLATE ---help--- diff -u linux-work/net/ipv6/Makefile-XFRM linux-work/net/ipv6/Makefile --- linux-work/net/ipv6/Makefile-XFRM 2003-07-18 02:39:29.000000000 +0200 +++ linux-work/net/ipv6/Makefile 2003-08-03 23:12:25.000000000 +0200 @@ -8,8 +8,9 @@ route.o ip6_fib.o ipv6_sockglue.o ndisc.o udp.o raw.o \ protocol.o icmp.o mcast.o reassembly.o tcp_ipv6.o \ exthdrs.o sysctl_net_ipv6.o datagram.o proc.o \ - ip6_flowlabel.o ipv6_syms.o \ - xfrm6_policy.o xfrm6_state.o xfrm6_input.o + ip6_flowlabel.o ipv6_syms.o + +obj-$(CONFIG_XFRM) += xfrm6_policy.o xfrm6_state.o xfrm6_input.o obj-$(CONFIG_INET6_AH) += ah6.o obj-$(CONFIG_INET6_ESP) += esp6.o diff -u linux-work/net/ipv6/ipv6_syms.c-XFRM linux-work/net/ipv6/ipv6_syms.c --- linux-work/net/ipv6/ipv6_syms.c-XFRM 2003-07-18 02:39:31.000000000 +0200 +++ linux-work/net/ipv6/ipv6_syms.c 2003-08-03 23:14:41.000000000 +0200 @@ -36,7 +36,9 @@ EXPORT_SYMBOL(in6addr_loopback); EXPORT_SYMBOL(in6_dev_finish_destroy); EXPORT_SYMBOL(ip6_find_1stfragopt); +#ifdef CONFIG_XFRM EXPORT_SYMBOL(xfrm6_rcv); +#endif EXPORT_SYMBOL(rt6_lookup); EXPORT_SYMBOL(fl6_sock_lookup); EXPORT_SYMBOL(ipv6_ext_hdr); diff -u linux-work/net/ipv6/route.c-XFRM linux-work/net/ipv6/route.c --- linux-work/net/ipv6/route.c-XFRM 2003-07-28 23:12:32.000000000 +0200 +++ linux-work/net/ipv6/route.c 2003-08-03 23:12:25.000000000 +0200 @@ -1988,7 +1988,9 @@ if (p) p->proc_fops = &rt6_stats_seq_fops; #endif +#ifdef CONFIG_XFRM xfrm6_init(); +#endif } #ifdef MODULE diff -u linux-work/net/xfrm/Kconfig-XFRM linux-work/net/xfrm/Kconfig --- linux-work/net/xfrm/Kconfig-XFRM 2003-05-27 03:00:40.000000000 +0200 +++ linux-work/net/xfrm/Kconfig 2003-08-03 23:12:25.000000000 +0200 @@ -1,9 +1,13 @@ # # XFRM configuration # +config XFRM + bool + depends on NET + config XFRM_USER tristate "IPsec user configuration interface" - depends on INET + depends on INET && XFRM ---help--- Support for IPsec user configuration interface used by native Linux tools. diff -u linux-work/net/xfrm/Makefile-XFRM linux-work/net/xfrm/Makefile --- linux-work/net/xfrm/Makefile-XFRM 2003-05-27 03:01:03.000000000 +0200 +++ linux-work/net/xfrm/Makefile 2003-08-03 23:12:25.000000000 +0200 @@ -2,6 +2,7 @@ # Makefile for the XFRM subsystem. # -obj-y := xfrm_policy.o xfrm_state.o xfrm_input.o xfrm_algo.o xfrm_output.o +obj-$(CONFIG_XFRM) := xfrm_policy.o xfrm_state.o xfrm_input.o xfrm_algo.o xfrm_output.o \ + xfrm_export.o obj-$(CONFIG_XFRM_USER) += xfrm_user.o diff -u linux-work/net/xfrm/xfrm_export.c-XFRM linux-work/net/xfrm/xfrm_export.c --- linux-work/net/xfrm/xfrm_export.c-XFRM 2003-08-03 23:12:25.000000000 +0200 +++ linux-work/net/xfrm/xfrm_export.c 2003-08-03 23:16:06.000000000 +0200 @@ -0,0 +1,76 @@ +#include +#include + +EXPORT_SYMBOL(xfrm_user_policy); +EXPORT_SYMBOL(km_waitq); +EXPORT_SYMBOL(km_new_mapping); +EXPORT_SYMBOL(xfrm_cfg_sem); +EXPORT_SYMBOL(xfrm_policy_alloc); +EXPORT_SYMBOL(__xfrm_policy_destroy); +EXPORT_SYMBOL(xfrm_lookup); +EXPORT_SYMBOL(__xfrm_policy_check); +EXPORT_SYMBOL(__xfrm_route_forward); +EXPORT_SYMBOL(xfrm_state_alloc); +EXPORT_SYMBOL(__xfrm_state_destroy); +EXPORT_SYMBOL(xfrm_state_find); +EXPORT_SYMBOL(xfrm_state_insert); +EXPORT_SYMBOL(xfrm_state_add); +EXPORT_SYMBOL(xfrm_state_update); +EXPORT_SYMBOL(xfrm_state_check_expire); +EXPORT_SYMBOL(xfrm_state_check_space); +EXPORT_SYMBOL(xfrm_state_lookup); +EXPORT_SYMBOL(xfrm_state_register_afinfo); +EXPORT_SYMBOL(xfrm_state_unregister_afinfo); +EXPORT_SYMBOL(xfrm_state_get_afinfo); +EXPORT_SYMBOL(xfrm_state_put_afinfo); +EXPORT_SYMBOL(xfrm_state_delete_tunnel); +EXPORT_SYMBOL(xfrm_replay_check); +EXPORT_SYMBOL(xfrm_replay_advance); +EXPORT_SYMBOL(xfrm_check_selectors); +EXPORT_SYMBOL(xfrm_check_output); +EXPORT_SYMBOL(__secpath_destroy); +EXPORT_SYMBOL(xfrm_get_acqseq); +EXPORT_SYMBOL(xfrm_parse_spi); +EXPORT_SYMBOL(xfrm4_rcv); +EXPORT_SYMBOL(xfrm4_tunnel_register); +EXPORT_SYMBOL(xfrm4_tunnel_deregister); +EXPORT_SYMBOL(xfrm4_tunnel_check_size); +EXPORT_SYMBOL(xfrm_register_type); +EXPORT_SYMBOL(xfrm_unregister_type); +EXPORT_SYMBOL(xfrm_get_type); +EXPORT_SYMBOL(inet_peer_idlock); +EXPORT_SYMBOL(xfrm_register_km); +EXPORT_SYMBOL(xfrm_unregister_km); +EXPORT_SYMBOL(xfrm_state_delete); +EXPORT_SYMBOL(xfrm_state_walk); +EXPORT_SYMBOL(xfrm_find_acq_byseq); +EXPORT_SYMBOL(xfrm_find_acq); +EXPORT_SYMBOL(xfrm_alloc_spi); +EXPORT_SYMBOL(xfrm_state_flush); +EXPORT_SYMBOL(xfrm_policy_kill); +EXPORT_SYMBOL(xfrm_policy_bysel); +EXPORT_SYMBOL(xfrm_policy_insert); +EXPORT_SYMBOL(xfrm_policy_walk); +EXPORT_SYMBOL(xfrm_policy_flush); +EXPORT_SYMBOL(xfrm_policy_byid); +EXPORT_SYMBOL(xfrm_policy_list); +EXPORT_SYMBOL(xfrm_dst_lookup); +EXPORT_SYMBOL(xfrm_policy_register_afinfo); +EXPORT_SYMBOL(xfrm_policy_unregister_afinfo); +EXPORT_SYMBOL(xfrm_policy_get_afinfo); +EXPORT_SYMBOL(xfrm_policy_put_afinfo); + +EXPORT_SYMBOL_GPL(xfrm_probe_algs); +EXPORT_SYMBOL_GPL(xfrm_count_auth_supported); +EXPORT_SYMBOL_GPL(xfrm_count_enc_supported); +EXPORT_SYMBOL_GPL(xfrm_aalg_get_byidx); +EXPORT_SYMBOL_GPL(xfrm_ealg_get_byidx); +EXPORT_SYMBOL_GPL(xfrm_calg_get_byidx); +EXPORT_SYMBOL_GPL(xfrm_aalg_get_byid); +EXPORT_SYMBOL_GPL(xfrm_ealg_get_byid); +EXPORT_SYMBOL_GPL(xfrm_calg_get_byid); +EXPORT_SYMBOL_GPL(xfrm_aalg_get_byname); +EXPORT_SYMBOL_GPL(xfrm_ealg_get_byname); +EXPORT_SYMBOL_GPL(xfrm_calg_get_byname); + +EXPORT_SYMBOL_GPL(skb_icv_walk); diff -u linux-work/net/Kconfig-XFRM linux-work/net/Kconfig --- linux-work/net/Kconfig-XFRM 2003-05-27 03:00:21.000000000 +0200 +++ linux-work/net/Kconfig 2003-08-03 23:12:24.000000000 +0200 @@ -143,6 +143,7 @@ config NET_KEY tristate "PF_KEY sockets" + select XFRM ---help--- PF_KEYv2 socket family, compatible to KAME ones. They are required if you are going to use IPsec tools ported diff -u linux-work/net/netsyms.c-XFRM linux-work/net/netsyms.c --- linux-work/net/netsyms.c-XFRM 2003-07-28 23:12:33.000000000 +0200 +++ linux-work/net/netsyms.c 2003-08-03 23:16:23.000000000 +0200 @@ -56,7 +56,6 @@ #include #include #include -#include #if defined(CONFIG_INET_AH) || defined(CONFIG_INET_AH_MODULE) || defined(CONFIG_INET6_AH) || defined(CONFIG_INET6_AH_MODULE) #include #endif @@ -294,78 +293,6 @@ /* needed for ip_gre -cw */ EXPORT_SYMBOL(ip_statistics); -EXPORT_SYMBOL(xfrm_user_policy); -EXPORT_SYMBOL(km_waitq); -EXPORT_SYMBOL(km_new_mapping); -EXPORT_SYMBOL(xfrm_cfg_sem); -EXPORT_SYMBOL(xfrm_policy_alloc); -EXPORT_SYMBOL(__xfrm_policy_destroy); -EXPORT_SYMBOL(xfrm_lookup); -EXPORT_SYMBOL(__xfrm_policy_check); -EXPORT_SYMBOL(__xfrm_route_forward); -EXPORT_SYMBOL(xfrm_state_alloc); -EXPORT_SYMBOL(__xfrm_state_destroy); -EXPORT_SYMBOL(xfrm_state_find); -EXPORT_SYMBOL(xfrm_state_insert); -EXPORT_SYMBOL(xfrm_state_add); -EXPORT_SYMBOL(xfrm_state_update); -EXPORT_SYMBOL(xfrm_state_check_expire); -EXPORT_SYMBOL(xfrm_state_check_space); -EXPORT_SYMBOL(xfrm_state_lookup); -EXPORT_SYMBOL(xfrm_state_register_afinfo); -EXPORT_SYMBOL(xfrm_state_unregister_afinfo); -EXPORT_SYMBOL(xfrm_state_get_afinfo); -EXPORT_SYMBOL(xfrm_state_put_afinfo); -EXPORT_SYMBOL(xfrm_state_delete_tunnel); -EXPORT_SYMBOL(xfrm_replay_check); -EXPORT_SYMBOL(xfrm_replay_advance); -EXPORT_SYMBOL(xfrm_check_selectors); -EXPORT_SYMBOL(xfrm_check_output); -EXPORT_SYMBOL(__secpath_destroy); -EXPORT_SYMBOL(xfrm_get_acqseq); -EXPORT_SYMBOL(xfrm_parse_spi); -EXPORT_SYMBOL(xfrm4_rcv); -EXPORT_SYMBOL(xfrm4_tunnel_register); -EXPORT_SYMBOL(xfrm4_tunnel_deregister); -EXPORT_SYMBOL(xfrm4_tunnel_check_size); -EXPORT_SYMBOL(xfrm_register_type); -EXPORT_SYMBOL(xfrm_unregister_type); -EXPORT_SYMBOL(xfrm_get_type); -EXPORT_SYMBOL(inet_peer_idlock); -EXPORT_SYMBOL(xfrm_register_km); -EXPORT_SYMBOL(xfrm_unregister_km); -EXPORT_SYMBOL(xfrm_state_delete); -EXPORT_SYMBOL(xfrm_state_walk); -EXPORT_SYMBOL(xfrm_find_acq_byseq); -EXPORT_SYMBOL(xfrm_find_acq); -EXPORT_SYMBOL(xfrm_alloc_spi); -EXPORT_SYMBOL(xfrm_state_flush); -EXPORT_SYMBOL(xfrm_policy_kill); -EXPORT_SYMBOL(xfrm_policy_bysel); -EXPORT_SYMBOL(xfrm_policy_insert); -EXPORT_SYMBOL(xfrm_policy_walk); -EXPORT_SYMBOL(xfrm_policy_flush); -EXPORT_SYMBOL(xfrm_policy_byid); -EXPORT_SYMBOL(xfrm_policy_list); -EXPORT_SYMBOL(xfrm_dst_lookup); -EXPORT_SYMBOL(xfrm_policy_register_afinfo); -EXPORT_SYMBOL(xfrm_policy_unregister_afinfo); -EXPORT_SYMBOL(xfrm_policy_get_afinfo); -EXPORT_SYMBOL(xfrm_policy_put_afinfo); - -EXPORT_SYMBOL_GPL(xfrm_probe_algs); -EXPORT_SYMBOL_GPL(xfrm_count_auth_supported); -EXPORT_SYMBOL_GPL(xfrm_count_enc_supported); -EXPORT_SYMBOL_GPL(xfrm_aalg_get_byidx); -EXPORT_SYMBOL_GPL(xfrm_ealg_get_byidx); -EXPORT_SYMBOL_GPL(xfrm_calg_get_byidx); -EXPORT_SYMBOL_GPL(xfrm_aalg_get_byid); -EXPORT_SYMBOL_GPL(xfrm_ealg_get_byid); -EXPORT_SYMBOL_GPL(xfrm_calg_get_byid); -EXPORT_SYMBOL_GPL(xfrm_aalg_get_byname); -EXPORT_SYMBOL_GPL(xfrm_ealg_get_byname); -EXPORT_SYMBOL_GPL(xfrm_calg_get_byname); -EXPORT_SYMBOL_GPL(skb_icv_walk); #if defined(CONFIG_INET_ESP) || defined(CONFIG_INET_ESP_MODULE) || defined(CONFIG_INET6_ESP) || defined(CONFIG_INET6_ESP_MODULE) EXPORT_SYMBOL_GPL(skb_cow_data); EXPORT_SYMBOL_GPL(pskb_put); From nf@hipac.org Mon Aug 4 06:18:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Aug 2003 06:19:00 -0700 (PDT) Received: from indyio.rz.uni-saarland.de (indyio.rz.uni-saarland.de [134.96.7.3]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h74DIhFl019267 for ; Mon, 4 Aug 2003 06:18:45 -0700 Received: from mars.rz.uni-saarland.de (mars.rz.uni-saarland.de [134.96.7.4]) by indyio.rz.uni-saarland.de (8.12.9/8.12.5) with ESMTP id h74DIZqk6640013; Mon, 4 Aug 2003 15:18:35 +0200 (CEST) Received: from e002.stw.stud.uni-saarland.de (e002.stw.stud.uni-saarland.de [134.96.65.17]) by mars.rz.uni-saarland.de (8.9.3p2/8.8.4/8.8.2) with ESMTP id PAA26020101; Mon, 4 Aug 2003 15:18:34 +0200 (CEST) Received: from e226.stw.stud.uni-saarland.de ([134.96.65.241] helo=hipac.org) by e002.stw.stud.uni-saarland.de with esmtp (Exim 3.35 #1 (Debian)) id 19jfEQ-0003Qv-00; Mon, 04 Aug 2003 15:18:34 +0200 Message-ID: <3F2E5CD6.4030500@hipac.org> Date: Mon, 04 Aug 2003 15:17:10 +0200 From: Michael Bellion and Thomas Heinz User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.4) Gecko/20030714 Debian/1.4-2 X-Accept-Language: de, en MIME-Version: 1.0 To: hadi@cyberus.ca CC: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [RFC] High Performance Packet Classifiction for tc framework References: <200307141045.40999.nf@hipac.org> <1058328537.1797.24.camel@jzny.localdomain> <3F16A0E5.1080007@hipac.org> <1059934468.1103.41.camel@jzny.localdomain> In-Reply-To: <1059934468.1103.41.camel@jzny.localdomain> X-Enigmail-Version: 0.76.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1F772C011F16724D016A230F" X-archive-position: 4515 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nf@hipac.org Precedence: bulk X-list: netdev This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1F772C011F16724D016A230F Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Jamal You wrote: > Apologies for late response. Its funny how i thought i was going to have > more time in the last 2 weeks but due to bad scheduling that wasnt the > case. No problemo ... > I think i will have to look at your code to make comments. Curious about it. > Not entirely accurate. Depends which tc classifier. u32 hash tables are > infact like iptables chains. Hm, we don't think so. Unfortunately, there does not seem to be much information about the inner workings of u32 and we currently don't have the time to deduce the whole algorithm from the code. Here is a short overview of our current view on u32: - each u32 filter "rule" consists of possibly several u32 matches, i.e. tc_u32_sel with nkeys tc_u32_key's => one rule is basically represented as a struct tc_u_knode - a set of u32 filter rules with same priority is in general a tree of hashes like for example: hash1: |--|--| / \ hash2: |--|--|--| hash3: |--|--|--|--| | | | | | | | r1 r2 r3 r4 r5 r6 r7 where the r_i are in fact lists of rules (-> hashing with chaining) => if there is more than one single filter with same prio there is always a tree of hashes (with possibly only 1 node (=hash)) - within such a tree of u32 filters (with same prio) there is no concept of prioritizing them any further => the rules must be conflict free - there is no way of optimizing filters with different priorities since one cannot assume that the intermediate classifiers are all of the same type If this is not the way it _really_ works we'd appreciate it if you could describe the general principles behind u32. > Note, the concept of priorities which is used for conflict resolution as > well as further separating sets of rules doesnt exist in iptables. Well, iptables rule position and tc filter priorities are just the same apart from the fact that iptables does not allow multiple rules to have the same priority (read: position). Therefore iptables rulesets don't suffer from conflicts. > You can also have them use different priorities and with the continue > operator first clasify based on packet data then on metadata or on > another packet header filter. Ok but then you fall back to the linear approach. Since with u32 only blocks of rules with same prio can be optimized one has to implement a ruleset using as few different prioritized blocks of filters as possible to achieve maximum performance. >>One disadvantage of this concept is that the hashed filters >>must be compact, i.e. there cannot be other classifiers in between. > > I didnt understand this. Are you talking about conflict resolving of > overlapping filters? No, the issue is just that within a block of filters with same prio there cannot be another type of filter, e.g. one cannot put a route classifier inside a hash of u32 classifiers. >>Another major disadvantage is caused by the hashing scheme. >>If you use the hash for 1 dimension you have to make sure that >>either all filters in a certain bucket are disjoint or you must have >>an implicit ordering of the rules (according to the insertion order >>or something). This scheme is not extendable to 2 or more dimensions, >>i.e. 1 hash for src ip, #(src ip buckets) many dst ip hashes and so >>on, because you simply cannot express arbitrary rulesets. > > If i understood you - you are refering to a way to reduce the number of > lookups by having disjoint hashes. I suppose for something as simple as > a five tuple lookup, this is almost solvable by hardcoding the different > fields into multiway hashes. Its when you try to generalize that it > becomes an issue. What do you mean exactly by "five tuple"? Do you refer to rules which consist of 5 punctiform matches, i.e. no masks or ranges or wildcards allowed, like (src ip 1.2.3.4, dst ip 3.4.5.6, proto tcp, src port 123, dst port 456)? Of course the scheme works for such cases (which consist of non-conflicting rules) although the user must be aware of the concrete hash function: divisor & u32_hash_fold(key, sel) because the mask would be 0xffffffff for the ip's. If ranges or overlapping masks are involved it gets really complicated and we doubt that people are able to manage such scenarios. >>Another general problem is of course that the user has to manually >>setup the hash which is rather inconvenient. > > Yes. Take a look at Werners tcng - he has a clever way to hide things > from the user. I did experimentation on u32 with a kernel thread which > rearranged things when they seemed out of balance but i havent > experimented with a lot of rules. We had a look at the tcng paper. Here it says that the u32 classifier is not used in the optimal way. Since we didn't have a look at the current tcng release it might well be that these problems are already addressed. Is that the case? BTW, why do you want to rearrange the tree of hashes and based on which heuristics? Why is there a kernel thread needed? Isn't it possible to arrange the tree directly after insert/delete operations? >>Now, what are the implications on the matching performance: >>tc vs. nf-hipac? As long as the extended hashing stuff is not used >>nf-hipac is clearly superior to tc. > > You are refering to u32. You mean as long as u32 stored things in a > single linked list, you win - correct? Yes, but this is not only true for u32. As long as the ruleset looks like: "n filters with n different priorities which can be translated into n nf-hipac rules" nf-hipac is clearly faster because in this case tc uses the linear approach. >>When hashing is used it _really_ >>depends. If there is only one classifier (with hashing) per interface >>and the number of rules per bucket is very small the performance should >>be comparable. As soon as you add other classifiers nf-hipac will >>outperform tc again. > > If we take a simple user interface abstraction like tcng which hides the > evil of u32 and then take simple 5 tuple rules - i doubt you will see > any difference. For more generic setup, the kernel thread i refer to > would work - but may slow insertion. For the simple punctiform examples like described above you may be right that nf-hipac and tc should perform similar but it's not clear to us how you want to achieve universality (including mask, ranges and wildcards) by this kernel thread rearranging approach. Basically you have to address the following problem: Given an arbitrary set of u32 rules with different priorities you have to compute an semantically equivalent representation with a tree of hashes. >>So, basically HIPAC is just a normal classifier like any other >>with two exceptions: >> a) it can occur only once per interface >> b) the rules within the classifier can contain other classifiers, >> e.g. u32, fw, tc_index, as matches > > But why restriction a)? Well, the restriction is necessary because of the new hipac design in which nf-hipac (i.e. firewalling), routing and cls_hipac (i.e. tc) are just applications for the classification framework. The basic idea is to reduce the number of classifications on the forwarding path to a single one (in the best case). In order to truly understand the requirement it would be necessary to explain the idea behind the new stage concept which is beyond the scope of this e-mail :-/. > Also why should we need hipac to hold other filters when the > infrastructure itself can hold the extended filters just fine? > I think you may actually be trying to say why somewhere in the email, > but it must not be making a significant impression on my brain. The idea is to reduce the embedded classifiers to a match, i.e. their return value is ignored. This offers the possibility of expressing a conjunction of native matches and classifiers in the very same way nf-hipac rules support iptables matches. This enhances the expressiveness of classification rules. A rule |nat. match 1|...|nat. match n|emb. cls 1|...|emb. cls m| matches if nat. match 1-n and emb. cls 1-m match. >>There is just one problem with the current tc framework. Once >>a new filter is inserted into the chain it is not removed even >>if the change function of the classifier returns < 0 >>(2.6.0-test1: net/sched/cls_api.c: line 280f). >>This should be changed anyway, shouldn't it? > > Are you refering to this piece of code?: > ---- > err = tp->ops->change(tp, cl, t->tcm_handle, tca, &fh); > if (err == 0) > tfilter_notify(skb, n, tp, fh, RTM_NEWTFILTER); > > errout: > if (cl) > cops->put(q, cl); > return err; > --- Yes. > change() should not return <0 if it has installed the filter i think. > Should the top level code be responsible for removing filters? The top level code (cls_hipac.c:tc_ctl_filter) is responsible for creating new tcf_proto structs (if not existent) and enqueuing the struct into the chain. Therefore it is also responsible for taking the stuff out of the chain again if necessary. In case we have just created a new tcf_proto and change fails it would be better if the new tcf_proto is removed afterwards, i.e. write_lock(&qdisc_tree_lock); spin_lock_bh(&dev->queue_lock); *back = tp->next; spin_unlock_bh(&dev->queue_lock); write_unlock(&qdisc_tree_lock); tp->ops->destroy(tp); module_put(tp->ops->owner); kfree(tp); is issued. Do you agree? > Consider what i said above. I'll try n cobble together some examples to > demonstrate (although it seems you already know this). > To allow for anyone to install classifiers-du-jour without being > dependet on hipac would be very useful. So ideas that you have for > enabling this cleanly should be moved to cls_api. Nobody will be forced to use hipac :-). It's just another classifier like u32. We don't even had to modify cls_api so far. Everything integrates just fine. Regards, +-----------------------+----------------------+ | Michael Bellion | Thomas Heinz | | | | +-----------------------+----------------------+ | High Performance Packet Classification | | nf-hipac: http://www.hipac.org/ | +----------------------------------------------+ --------------enig1F772C011F16724D016A230F Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQE/LlzdtXh2AYIMjggRAtcvAKCUZykozfMnI5MmRMo0j/zH6TDg7gCdGl20 ngF9kmhPF45vfAYjTq6sd/U= =qy5Z -----END PGP SIGNATURE----- --------------enig1F772C011F16724D016A230F-- From niv@us.ibm.com Mon Aug 4 08:51:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Aug 2003 08:51:07 -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 h74FotFl021660 for ; Mon, 4 Aug 2003 08:51:02 -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 h74FoHj3303868; Mon, 4 Aug 2003 11:50:17 -0400 Received: from us.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h74FoGiQ067578; Mon, 4 Aug 2003 09:50:17 -0600 Message-ID: <3F2E80CD.3090206@us.ibm.com> Date: Mon, 04 Aug 2003 08:50:37 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: netdev@oss.sgi.com Subject: Re: [PATCH] Make XFRM optional References: <20030804125022.GA8167@averell> In-Reply-To: <20030804125022.GA8167@averell> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4516 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Andi Kleen wrote: > Only compile in the xfrm subsystem when it's needed by any config options. > > This avoids some code/data structure bloat in case you don't use IP > tunneling or IPsec. Yes, I would like this too, please. thanks, Nivedita From hadi@cyberus.ca Mon Aug 4 08:51:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Aug 2003 08:51:53 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h74FpgFl021732 for ; Mon, 4 Aug 2003 08:51:43 -0700 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.12) id 19jhcb-000EBD-00; Mon, 04 Aug 2003 11:51:41 -0400 Subject: Re: [RFC] High Performance Packet Classifiction for tc framework From: jamal Reply-To: hadi@cyberus.ca To: Michael Bellion and Thomas Heinz Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <3F2E5CD6.4030500@hipac.org> References: <200307141045.40999.nf@hipac.org> <1058328537.1797.24.camel@jzny.localdomain> <3F16A0E5.1080007@hipac.org> <1059934468.1103.41.camel@jzny.localdomain> <3F2E5CD6.4030500@hipac.org> Content-Type: text/plain Organization: jamalopolis Message-Id: <1060012260.1103.380.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 04 Aug 2003 11:51:01 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4517 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Olla, On Mon, 2003-08-04 at 09:17, Michael Bellion and Thomas Heinz wrote: > > I think i will have to look at your code to make comments. > > Curious about it. > I promise i will. I dont think i will do it justice spending 5 minutes on it. I take it you have written extensive docs too ;-> > > Not entirely accurate. Depends which tc classifier. u32 hash tables are > > infact like iptables chains. > > Hm, we don't think so. Unfortunately, there does not seem to be much > information about the inner workings of u32 and we currently don't have > the time to deduce the whole algorithm from the code. > Unfortunately it is more exciting to write code than documents. I almost got someone to document at least its proper usage but they backed away at the last minute. > Here is a short overview of our current view on u32: > - each u32 filter "rule" consists of possibly several u32 matches, > i.e. tc_u32_sel with nkeys tc_u32_key's > => one rule is basically represented as a struct tc_u_knode > - a set of u32 filter rules with same priority is in general a > tree of hashes like for example: > hash1: |--|--| > / \ > hash2: |--|--|--| hash3: |--|--|--|--| > | | | | | | | > r1 r2 r3 r4 r5 r6 r7 > where the r_i are in fact lists of rules (-> hashing with > chaining) > => if there is more than one single filter with same prio > there is always a tree of hashes (with possibly only 1 node > (=hash)) > - within such a tree of u32 filters (with same prio) there is > no concept of prioritizing them any further => the rules must > be conflict free > - there is no way of optimizing filters with different priorities > since one cannot assume that the intermediate classifiers are all > of the same type > > If this is not the way it _really_ works we'd appreciate it if you could > describe the general principles behind u32. > u32 is a swiss knife so to go into general principles requires some time, motivation, and more importantly patience.I possess none of these nice attributes at the moment. You are doing a good job keep reading the code. I dont wanna go in a lot of details, but one important detail is that keynodes can also lead to other hash tables. So you can split the packet parsing across multiple hashes - this is where the comparison with chains comes in. There are several ways to do this. I'll show you the brute force way and you can make it more usable with "hashkey" and "sample" operator. Stealing from your example: hash1: |--|--| / hash2: |--|--|--| | | | r1 r2 r3 | | hash3 hash4 | | r4 r5 Example, you go into hash2 for all IP packets. The rules on the hash2 look at the protocol type and select a different hash table for TCP, UDP, ICMP etc. - so general rules is: Put your most hit rules at the highest priority so they are found first. Heres an example, i havent tested this (i can send you a tested example if you cant get this to work): ------- TCF=tc filter add dev eth0 parent ffff: protocol ip prio 10 # add hash table 1 $TCF handle 1::: u32 divisor 1 #add hash table 2 $TCF handle 2::: u32 divisor 1 #add your filter rules to specific tables: ICMP to table 1, TCP to table #6 etc . . #ICMP gets matched in table 1 $TCF match ip protocol 1 0xff link 1:0:0 . . ---------- Makes sense? Note, this doesnt say much about the user usability of u32 - it just says can be done. > > Note, the concept of priorities which is used for conflict resolution as > > well as further separating sets of rules doesnt exist in iptables. > > Well, iptables rule position and tc filter priorities are just the > same apart from the fact that iptables does not allow multiple rules > to have the same priority (read: position). Therefore iptables rulesets > don't suffer from conflicts. > sure position could be used as a priority. It is easier/intuitive to just have explicit priorities. > > You can also have them use different priorities and with the continue > > operator first clasify based on packet data then on metadata or on > > another packet header filter. > > Ok but then you fall back to the linear approach. Since with u32 only > blocks of rules with same prio can be optimized one has to implement a > ruleset using as few different prioritized blocks of filters as possible > to achieve maximum performance. > Read what i said above if you still hold the same opinion lets discuss. What "optimizes" could be a user interface or the thread i was talking about earlier. > >>One disadvantage of this concept is that the hashed filters > >>must be compact, i.e. there cannot be other classifiers in between. > > > > I didnt understand this. Are you talking about conflict resolving of > > overlapping filters? > > No, the issue is just that within a block of filters with same prio > there cannot be another type of filter, e.g. one cannot put a route > classifier inside a hash of u32 classifiers. > But you dont need to as i was pointing out earlier. You can have both fwmark,tcindex,u32, rsvp etc being invoked one after the other. > >>Another major disadvantage is caused by the hashing scheme. > >>If you use the hash for 1 dimension you have to make sure that > >>either all filters in a certain bucket are disjoint or you must have > >>an implicit ordering of the rules (according to the insertion order > >>or something). This scheme is not extendable to 2 or more dimensions, > >>i.e. 1 hash for src ip, #(src ip buckets) many dst ip hashes and so > >>on, because you simply cannot express arbitrary rulesets. > > > > If i understood you - you are refering to a way to reduce the number of > > lookups by having disjoint hashes. I suppose for something as simple as > > a five tuple lookup, this is almost solvable by hardcoding the different > > fields into multiway hashes. Its when you try to generalize that it > > becomes an issue. > > What do you mean exactly by "five tuple"? Do you refer to rules which > consist of 5 punctiform matches, i.e. no masks or ranges or wildcards > allowed, like (src ip 1.2.3.4, dst ip 3.4.5.6, proto tcp, src port 123, > dst port 456)? > above but with masks. "5 tuple" is a classical name for the above. > Of course the scheme works for such cases (which consist of > non-conflicting rules) although the user must be aware of the > concrete hash function: divisor & u32_hash_fold(key, sel) > because the mask would be 0xffffffff for the ip's. > > If ranges or overlapping masks are involved it gets really complicated > and we doubt that people are able to manage such scenarios. > I was refering to the cascaded hash tables i was refering to earlier. Depending on the rules, you could optimize differently. > >>Another general problem is of course that the user has to manually > >>setup the hash which is rather inconvenient. > > > > Yes. Take a look at Werners tcng - he has a clever way to hide things > > from the user. I did experimentation on u32 with a kernel thread which > > rearranged things when they seemed out of balance but i havent > > experimented with a lot of rules. > > We had a look at the tcng paper. Here it says that the u32 classifier > is not used in the optimal way. Since we didn't have a look at the > current tcng release it might well be that these problems are already > addressed. Is that the case? > He doesnt fix the u32, rather if you use his wrappers he outputs optimized u32 rules. All that is hidden from the user. > BTW, why do you want to rearrange the tree of hashes and based on which > heuristics? Why is there a kernel thread needed? Isn't it possible to > arrange the tree directly after insert/delete operations? > You can do that, but then you are adding delay to the insertion/deletion rates which are very important metrics. Another way to do it is to fire a netlink message every time a hash table's keynodes exceed a threshold value and have user space compute a rearrangement. Essentially you have to weigh your tradeoffs. > >>Now, what are the implications on the matching performance: > >>tc vs. nf-hipac? As long as the extended hashing stuff is not used > >>nf-hipac is clearly superior to tc. > > > > You are refering to u32. You mean as long as u32 stored things in a > > single linked list, you win - correct? > > Yes, but this is not only true for u32. As long as the ruleset > looks like: "n filters with n different priorities which can > be translated into n nf-hipac rules" nf-hipac is clearly faster > because in this case tc uses the linear approach. > If you still hold this opinion after my explanation on cascaded hash tables, then lets discuss again. > >>When hashing is used it _really_ > >>depends. If there is only one classifier (with hashing) per interface > >>and the number of rules per bucket is very small the performance should > >>be comparable. As soon as you add other classifiers nf-hipac will > >>outperform tc again. > > > > If we take a simple user interface abstraction like tcng which hides the > > evil of u32 and then take simple 5 tuple rules - i doubt you will see > > any difference. For more generic setup, the kernel thread i refer to > > would work - but may slow insertion. > > For the simple punctiform examples like described above you may be right > that nf-hipac and tc should perform similar but it's not clear to us > how you want to achieve universality (including mask, ranges and > wildcards) by this kernel thread rearranging approach. Basically you > have to address the following problem: Given an arbitrary set of u32 > rules with different priorities you have to compute an semantically > equivalent representation with a tree of hashes. > yes - that is the challenge to resolve;-> > >>So, basically HIPAC is just a normal classifier like any other > >>with two exceptions: > >> a) it can occur only once per interface > >> b) the rules within the classifier can contain other classifiers, > >> e.g. u32, fw, tc_index, as matches > > > > But why restriction a)? > > Well, the restriction is necessary because of the new hipac design in > which nf-hipac (i.e. firewalling), routing and cls_hipac (i.e. tc) are > just applications for the classification framework. The basic idea is > to reduce the number of classifications on the forwarding path to a > single one (in the best case). In order to truly understand the > requirement it would be necessary to explain the idea behind the new > stage concept which is beyond the scope of this e-mail :-/. > Ok - maybe when you explain the concept later i will get it. Is your plan to put this in other places other than Linux? > > Also why should we need hipac to hold other filters when the > > infrastructure itself can hold the extended filters just fine? > > I think you may actually be trying to say why somewhere in the email, > > but it must not be making a significant impression on my brain. > > The idea is to reduce the embedded classifiers to a match, i.e. > their return value is ignored. This offers the possibility of > expressing a conjunction of native matches and classifiers in the > very same way nf-hipac rules support iptables matches. This enhances > the expressiveness of classification rules. > A rule |nat. match 1|...|nat. match n|emb. cls 1|...|emb. cls m| > matches if nat. match 1-n and emb. cls 1-m match. > So you got this thought from iptables and took it to the next level? I am still not sure i understand why not use what already exists - but i'll just say i dont see it right now. > > The top level code (cls_hipac.c:tc_ctl_filter) is responsible for > creating new tcf_proto structs (if not existent) and enqueuing the > struct into the chain. Therefore it is also responsible for taking > the stuff out of the chain again if necessary. In case we have just > created a new tcf_proto and change fails it would be better if the new > tcf_proto is removed afterwards, i.e. > write_lock(&qdisc_tree_lock); > spin_lock_bh(&dev->queue_lock); > *back = tp->next; > spin_unlock_bh(&dev->queue_lock); > write_unlock(&qdisc_tree_lock); > tp->ops->destroy(tp); > module_put(tp->ops->owner); > kfree(tp); > is issued. > Do you agree? > It doesnt appear harmful to leave it there without destroying it. The next time someome adds a filter of the same protocol + priority, it will already exist. If you want to be accurate (because it does get destroyed when the init() fails), then destroy it but you need to put checks for "incase we have added a new tcf_proto" which may not look pretty. Is this causing you some discomfort? > > Consider what i said above. I'll try n cobble together some examples to > > demonstrate (although it seems you already know this). > > To allow for anyone to install classifiers-du-jour without being > > dependet on hipac would be very useful. So ideas that you have for > > enabling this cleanly should be moved to cls_api. > > Nobody will be forced to use hipac :-). It's just another classifier > like u32. We don't even had to modify cls_api so far. Everything > integrates just fine. > cool. Keep up the good work. cheers, jamal From mathis@psc.edu Mon Aug 4 09:21:04 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Aug 2003 09:21:12 -0700 (PDT) Received: from zippy.psc.edu (pa-monroeville3a-31.pit.adelphia.net [24.53.185.31]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h74GL2Fl023294 for ; Mon, 4 Aug 2003 09:21:03 -0700 Received: from localhost (mathis@localhost) by zippy.psc.edu (8.11.6/8.11.6) with ESMTP id h74GKlB27764; Mon, 4 Aug 2003 12:20:47 -0400 X-Authentication-Warning: zippy.psc.edu: mathis owned process doing -bs Date: Mon, 4 Aug 2003 12:20:47 -0400 (EDT) From: Matt Mathis To: "David S. Miller" cc: netdev@oss.sgi.com, John Heffner Subject: Web100 In-Reply-To: <20030803222554.7027a160.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4518 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mathis@psc.edu Precedence: bulk X-list: netdev On Sun, 3 Aug 2003, David S. Miller wrote: > The web100 patches aren't in the kernel because 1) they've > never even been submitted and 2) they need a large cleanup. Furthermore 1 is due to 2.... We know our code is not ready for kernel inclusion, and are having a little trouble seeing the path through to doing so ourselves. A big part of the problem is that I an not a kernel guy - my focus in on the protocol and measurement issues and not on the implementation details. Although John could probably get it together by himself, he is split between several projects and it isn't clear that incrementally submitting substandard patches is a cost effective strategy to getting it done. It would be a lot easier if we 1) had a mentor who was experienced at kernel inclusion, 2) specific guidance on some of the non-network components, such as the API (currently using /proc) and 3) a laundry list of things that we need to fix. > I sort of get the impression that the web100 folks actually like that > their changes are not in the main sources, it keeps their work > "special". Nope, not at all. Actually I find kernel inclusion rather daunting. One of our collaborators was asked some very pointed questions about the TCP ESTATS MIB by somebody at M$. I would hate to have the first general release be in anything but Linux. Any takers on helping us? Thanks, --MM-- ------------------------------------------- Matt Mathis http://www.psc.edu/~mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- From hadi@cyberus.ca Mon Aug 4 09:46:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Aug 2003 09:46:08 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h74GjxFl024775 for ; Mon, 4 Aug 2003 09:46:00 -0700 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.12) id 19jiT8-000JAa-00; Mon, 04 Aug 2003 12:45:59 -0400 Subject: Re: TOE brain dump From: jamal Reply-To: hadi@cyberus.ca To: netdev@oss.sgi.com Cc: "Ihar 'Philips' Filipau" Content-Type: text/plain Organization: jamalopolis Message-Id: <1060015518.1103.399.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 04 Aug 2003 12:45:18 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4519 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Can you please post to netdev? Posting networking related issues to linux kernel alone is considered rude. Posting them to netdev only is acceptable. > Ihar 'Philips' Filipau wrote: > > >Werner Almesberger wrote: > > Ihar 'Philips' Filipau wrote: > > > >| | | Modern NPUs generally do this. > > > > > > Unfortunately, they don't - they run *some* code, but that > > is rarely a Linux kernel, or a substantial part of it. > > > > Embedded CPU we are using is based MIPS, and has a lot of specialized > instructions. > It makes not that much sense to run kernel (especially Linux) on CPU > which is optimized for handling of network packets. (And has actually > several co-processors to help in this task). The coprocessors are useful, but that has nothing to do with the value of the NPU. You can add those within a general processor system. I am also in the camp that to be really useful these things need to run a real OS - Linux. > How much sense it makes to run general purpose OS (optimized for PCs > and servers) on devices which can make only couple of functions? (and no > MMU btw) > > It is a whole idea behind this kind of CPUs - to do a few of > functions - but to do them good. > > If you will start stretching CPUs like this to fit Linux kernel - it > will generally just increase price. Probably there are some markets > which can afford this. > Actually i believe it will lower the prices.I am waiting for intel to get hyperthreading right - then we'll see these things disapear. The only thing useful about NPUs is their ability to management the discrepency between memory latency and CPU speeds. Trust me i used to be in the same camp as you.If you note, a lot of these things appeared around the height of the .com days. VCs were looking for something new and exciting. > Remeber - "Small is beatiful" (c) - and linux kernel far from it. > Our routing code which handles two GE interfaces (actually not pure > GE, but up to 2.5GB) fits into 3k. 3k of code - and that's it. not 650kb > of bzip compressed bloat. And it handles two interfaces, handles fast > data path from siblign interfaces, handles up to 1E6 routes. 3k of code. > not 650k of bzip. If all you wanted was to do L3 - why not just buy a $5 chip that can do this for a lot more interfaces? Why sweat over optimizing L3 routing in a 3K space? to nit: Its no longer about routing or bridging, friend. Thats like getting fries at mcdonalds. cheers, jamal From alan@storlinksemi.com Mon Aug 4 10:19:39 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Aug 2003 10:19:49 -0700 (PDT) Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h74HJdFl025593 for ; Mon, 4 Aug 2003 10:19:39 -0700 Received: from adsl-63-203-236-74.dsl.snfc21.pacbell.net (HELO AlanLap) (alansuntzishih@63.203.236.74 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 4 Aug 2003 17:19:38 -0000 From: "Alan Shih" To: "Ingo Oeser" , "Jeff Garzik" Cc: "Nivedita Singhvi" , "Werner Almesberger" , , Subject: RE: TOE brain dump Date: Mon, 4 Aug 2003 10:19:21 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20030804163606.Q639@nightmaster.csn.tu-chemnitz.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 X-archive-position: 4520 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@storlinksemi.com Precedence: bulk X-list: netdev Hmm, So would main processor still need a copy of the data for re-transmission? Won't that defeat the purpose? Alan -----Original Message----- From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Ingo Oeser Sent: Monday, August 04, 2003 7:36 AM To: Jeff Garzik Cc: Nivedita Singhvi; Werner Almesberger; netdev@oss.sgi.com; linux-kernel@vger.kernel.org Subject: Re: TOE brain dump Hi Jeff, On Sat, Aug 02, 2003 at 03:08:52PM -0400, Jeff Garzik wrote: > So, fix the other end of the pipeline too, otherwise this fast network > stuff is flashly but pointless. If you want to serve up data from disk, > then start creating PCI cards that have both Serial ATA and ethernet > connectors on them :) Cut out the middleman of the host CPU and host > memory bus instead of offloading portions of TCP that do not need to be > offloaded. Exactly what I suggested: sys_ioroute() "Providing generic pipelines and io routing as Linux service" Msg-ID: <20030718134235.K639@nightmaster.csn.tu-chemnitz.de> on linux-kernel and linux-fsdevel Be my guest. I know, that you mean doing it in hardware, but you cannot accelerate sth. which the kernel doesn't do ;-) Regards Ingo Oeser - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From inaky.perez-gonzalez@intel.com Mon Aug 4 11:36:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Aug 2003 11:36:32 -0700 (PDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h74IaNFl027540 for ; Mon, 4 Aug 2003 11:36:24 -0700 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h74IUIQ07776 for ; Mon, 4 Aug 2003 18:30:18 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h74Hxgl00580 for ; Mon, 4 Aug 2003 17:59:42 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 M2003080411361613752 ; Mon, 04 Aug 2003 11:36:16 -0700 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 4 Aug 2003 11:36:16 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: TOE brain dump Date: Mon, 4 Aug 2003 11:36:15 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TOE brain dump Thread-Index: AcNZ/oaUAcgg0owhSWG6t+TBx1MScAAbhUUA From: "Perez-Gonzalez, Inaky" To: "Larry McVoy" , "David Lang" Cc: "Erik Andersen" , "Werner Almesberger" , "Jeff Garzik" , , , "Nivedita Singhvi" X-OriginalArrivalTime: 04 Aug 2003 18:36:16.0508 (UTC) FILETIME=[4A1793C0:01C35AB7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h74IaNFl027540 X-archive-position: 4521 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: inaky.perez-gonzalez@intel.com Precedence: bulk X-list: netdev > From: Larry McVoy [mailto:lm@bitmover.com] > > > 2. router nodes that have access to main memory (PCI card running linux > > acting as a router/firewall/VPN to offload the main CPU's) > > I can get an entire machine, memory, disk, > Ghz CPU, case, power supply, > cdrom, floppy, onboard enet extra net card for routing, for $250 or less, > quantity 1, shipped to my door. > > Why would I want to spend money on some silly offload card when I can get > the whole PC for less than the card? Because you want to stack 200 of those together in a huge data center interconnecting whatever you want to interconnect and you don't want your maintenance costs to go up to the sky? I see your point, though :) Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own (and my fault) From filia@softhome.net Mon Aug 4 11:47:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Aug 2003 11:47:53 -0700 (PDT) Received: from jive.SoftHome.net (jive.SoftHome.net [66.54.152.27]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h74IliFl028072 for ; Mon, 4 Aug 2003 11:47:45 -0700 Received: (qmail 8633 invoked by uid 417); 4 Aug 2003 18:47:44 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 4 Aug 2003 18:47:44 -0000 Received: from softhome.net ([212.18.200.6]) (AUTH: PLAIN filia@softhome.net) by softhome.net with esmtp; Mon, 04 Aug 2003 12:47:42 -0600 Message-ID: <3F2EAA78.60202@softhome.net> Date: Mon, 04 Aug 2003 20:48:24 +0200 From: "Ihar 'Philips' Filipau" Organization: Home Sweet Home User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca CC: netdev@oss.sgi.com Subject: Re: TOE brain dump References: <1060015518.1103.399.camel@jzny.localdomain> In-Reply-To: <1060015518.1103.399.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4522 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: filia@softhome.net Precedence: bulk X-list: netdev jamal wrote: > to nit: Its no longer about routing or bridging, friend. Thats like getting > fries at mcdonalds. > 1GE/10GE - for $5? I'm first in the shoping queue!!!-))) Since I see no reasonable out-come of this discussion I left it. TOE as I see - since my company utilizes several of them - are too different and too specialized to application/protocols. And yes - price of development/deployment maters too. Linux support for those protocols is inmature. It cannot handle or requirements even software-wise. I'm not talking about timing requirements - linux network in general is not (even soft) real-time. My personal flame-meter is out of scale ;-) I shall join the discussion back when I will see any real ideas. > If all you wanted was to do L3 - why not just buy a $5 chip that > can do this for a lot more interfaces? Why sweat over > optimizing L3 routing in a 3K space? We are doing not a teapot, and high level spec for this code takes around 15 pages. 3k - it is not optimized - we have limit around 2GB ;-) It just takes only 3k. And it handles some special (read - proprietary) functions too - some bugs of some other pieces of hardware. NPU does all stuff by itself, but sometimes we need to extract configuration information which is direct to us, for example. From davem@redhat.com Mon Aug 4 11:49:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Aug 2003 11:49:39 -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 h74InYFl028410 for ; Mon, 4 Aug 2003 11:49:35 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id LAA20777; Mon, 4 Aug 2003 11:45:07 -0700 Date: Mon, 4 Aug 2003 11:45:07 -0700 From: "David S. Miller" To: Andi Kleen Cc: yoshfuji@linux-ipv6.org, ak@muc.de, netdev@oss.sgi.com Subject: Re: [PATCH] Make XFRM optional Message-Id: <20030804114507.6e496c77.davem@redhat.com> In-Reply-To: <20030804130408.GA36367@colin2.muc.de> References: <20030804125022.GA8167@averell> <20030804.215801.124854897.yoshfuji@linux-ipv6.org> <20030804130408.GA36367@colin2.muc.de> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4523 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On 4 Aug 2003 15:04:08 +0200 Andi Kleen wrote: > Thanks for the feedback. Here is a new patch with the two hunks > removed. Still broken in two areas: 1) You moved inet_peer_idlock into net/xfrm/xfrm_exports.c, that looks quite wrong. 2) Your patch doesn't apply to Linus's current tree because "secpath_dup" got added to net/netsyms.c since 2.6.0-test2 got released. I wanted to merge this, but I can't until you fix the above problems. Thanks. From alan@lxorguk.ukuu.org.uk Mon Aug 4 12:07:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Aug 2003 12:07:30 -0700 (PDT) Received: from lxorguk.ukuu.org.uk (pc1-cwma1-5-cust4.swan.cable.ntl.com [80.5.120.4]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h74J7OFl029104 for ; Mon, 4 Aug 2003 12:07:26 -0700 Received: from dhcp22.swansea.linux.org.uk (dhcp22.swansea.linux.org.uk [127.0.0.1]) by lxorguk.ukuu.org.uk (8.12.8/8.12.5) with ESMTP id h74J3EC3001142; Mon, 4 Aug 2003 20:03:15 +0100 Received: (from alan@localhost) by dhcp22.swansea.linux.org.uk (8.12.8/8.12.8/Submit) id h74J3BPF001140; Mon, 4 Aug 2003 20:03:11 +0100 X-Authentication-Warning: dhcp22.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: RE: TOE brain dump From: Alan Cox To: "Perez-Gonzalez, Inaky" Cc: Larry McVoy , David Lang , Erik Andersen , Werner Almesberger , Jeff Garzik , netdev@oss.sgi.com, Linux Kernel Mailing List , Nivedita Singhvi In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1060023790.723.23.camel@dhcp22.swansea.linux.org.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 04 Aug 2003 20:03:11 +0100 X-archive-position: 4524 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: netdev On Llu, 2003-08-04 at 19:36, Perez-Gonzalez, Inaky wrote: > > Why would I want to spend money on some silly offload card when I can get > > the whole PC for less than the card? > > Because you want to stack 200 of those together in a huge > data center interconnecting whatever you want to interconnect > and you don't want your maintenance costs to go up to the sky? 17cm squared, fanless, network booting. Its not as big a cost as you might think, and TOE cards fail too, the difference being that if they are now out of production you have a nasty mess on your hands. From werner@almesberger.net Mon Aug 4 12:24:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Aug 2003 12:24:54 -0700 (PDT) Received: from host.almesberger.net (almesberger.net [63.105.73.239] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h74JOiFl029623 for ; Mon, 4 Aug 2003 12:24:45 -0700 Received: from almesberger.net (vpnwa-home [10.200.0.2]) by host.almesberger.net (8.11.6/8.9.3) with ESMTP id h74JOdG11924; Mon, 4 Aug 2003 12:24:39 -0700 Received: (from werner@localhost) by almesberger.net (8.11.6/8.11.6) id h74JOXM16998; Mon, 4 Aug 2003 16:24:33 -0300 Date: Mon, 4 Aug 2003 16:24:33 -0300 From: Werner Almesberger To: "Eric W. Biederman" Cc: Jeff Garzik , Nivedita Singhvi , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: TOE brain dump Message-ID: <20030804162433.L5798@almesberger.net> References: <20030802140444.E5798@almesberger.net> <3F2BF5C7.90400@us.ibm.com> <3F2C0C44.6020002@pobox.com> <20030802184901.G5798@almesberger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from ebiederm@xmission.com on Sun, Aug 03, 2003 at 01:21:09PM -0600 X-archive-position: 4525 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: werner@almesberger.net Precedence: bulk X-list: netdev Eric W. Biederman wrote: > The optimized for low latency cases seem to have a strong > market in clusters. Clusters have captive, no, _desperate_ customers ;-) And it seems that people are just as happy putting MPI as their transport on top of all those link-layer technologies. > There is one place in low latency communications that I can think > of where TCP/IP is not the proper solution. For low latency > communication the checksum is at the wrong end of the packet. That's one of the few things ATM's AAL5 got right. But in the end, I think it doesn't really matter. At 1 Gbps, an MTU-sized packet flies by within 13 us. At 10 Gbps, it's only 1.3 us. At that point, you may well treat it as an atomic unit. > On that score it is worth noting that the next generation of > peripheral busses (Hypertransport, PCI Express, etc) are all switched. And it's about time for that :-) - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina werner@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From davem@redhat.com Mon Aug 4 12:31:11 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Aug 2003 12:31: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 h74JVBFl030047 for ; Mon, 4 Aug 2003 12:31:11 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id MAA20942; Mon, 4 Aug 2003 12:26:32 -0700 Date: Mon, 4 Aug 2003 12:26:32 -0700 From: "David S. Miller" To: Werner Almesberger Cc: ebiederm@xmission.com, jgarzik@pobox.com, niv@us.ibm.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: TOE brain dump Message-Id: <20030804122632.65ba2122.davem@redhat.com> In-Reply-To: <20030804162433.L5798@almesberger.net> References: <20030802140444.E5798@almesberger.net> <3F2BF5C7.90400@us.ibm.com> <3F2C0C44.6020002@pobox.com> <20030802184901.G5798@almesberger.net> <20030804162433.L5798@almesberger.net> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4526 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 4 Aug 2003 16:24:33 -0300 Werner Almesberger wrote: > Eric W. Biederman wrote: > > There is one place in low latency communications that I can think > > of where TCP/IP is not the proper solution. For low latency > > communication the checksum is at the wrong end of the packet. > > That's one of the few things ATM's AAL5 got right. Let's recall how long the IFF_TRAILERS hack from BSD :-) > But in the end, I think it doesn't really matter. I tend to agree on this one. And on the transmit side if you have more than 1 pending TX frame, you can always be prefetching the next one into the fifo so that by the time the medium is ready all the checksum bits have been done. In fact I'd be surprised if current generation 1g/10g cards are not doing something like this. From hadi@cyberus.ca Mon Aug 4 12:43:12 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Aug 2003 12:43:17 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h74JhAFl030573 for ; Mon, 4 Aug 2003 12:43:11 -0700 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.12) id 19jlEc-0008eK-00; Mon, 04 Aug 2003 15:43:10 -0400 Subject: Re: TOE brain dump From: jamal Reply-To: hadi@cyberus.ca To: "Ihar 'Philips' Filipau" Cc: netdev@oss.sgi.com In-Reply-To: <3F2EAA78.60202@softhome.net> References: <1060015518.1103.399.camel@jzny.localdomain> <3F2EAA78.60202@softhome.net> Content-Type: text/plain Organization: jamalopolis Message-Id: <1060026149.1102.411.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 04 Aug 2003 15:42:29 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4527 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Mon, 2003-08-04 at 14:48, Ihar 'Philips' Filipau wrote: > jamal wrote: > > to nit: Its no longer about routing or bridging, friend. Thats like getting > > fries at mcdonalds. > > > > 1GE/10GE - for $5? > I'm first in the shoping queue!!!-))) > I thought you were talking about a 2 Gige interface doing routing, no? Do the math: Dell will happily sell you a (managed?) switch which has 8Giges on it for about $300. It does wire rate on all 8 interfaces. All ready to go in a 1U form factor. How much do you think that chip costs? Lets say it doesnt do L3, how much more do you think it will cost to do L3 in quantities? > Since I see no reasonable out-come of this discussion I left it. > > TOE as I see - since my company utilizes several of them - are too > different and too specialized to application/protocols. And yes - price > of development/deployment maters too. Linux support for those protocols > is inmature. It cannot handle or requirements even software-wise. I'm > not talking about timing requirements - linux network in general is not > (even soft) real-time. > Now this is anti-social talk;-> Why do you need to have realtime for any of this stuff? > My personal flame-meter is out of scale ;-) > I shall join the discussion back when I will see any real ideas. > Please dont dissapear, a lot of questions need answers;-> > > > If all you wanted was to do L3 - why not just buy a $5 chip that > > can do this for a lot more interfaces? Why sweat over > > optimizing L3 routing in a 3K space? > > We are doing not a teapot, and high level spec for this code takes > around 15 pages. > 3k - it is not optimized - we have limit around 2GB ;-) I am really confused now. We must be talking about different class of devices. NPUs as i know them are very limited in how much code you can stash them. In the 10K ranges is already overkill. Do you have any URL i can look at on what you are describing? > It just takes only 3k. And it handles some special (read - > proprietary) functions too - some bugs of some other pieces of hardware. > NPU does all stuff by itself, but sometimes we need to extract > configuration information which is direct to us, for example. Please provide me a pointer if you can - I am very interested in the 2G code space you mention. cheers, jamal > From filia@softhome.net Mon Aug 4 13:05:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Aug 2003 13:05:57 -0700 (PDT) Received: from jive.SoftHome.net (jive.SoftHome.net [66.54.152.27]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h74K5qFl031227 for ; Mon, 4 Aug 2003 13:05:53 -0700 Received: (qmail 22843 invoked by uid 417); 4 Aug 2003 20:05:52 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 4 Aug 2003 20:05:52 -0000 Received: from softhome.net ([212.18.200.6]) (AUTH: PLAIN filia@softhome.net) by softhome.net with esmtp; Mon, 04 Aug 2003 14:05:51 -0600 Message-ID: <3F2EBCCA.5060708@softhome.net> Date: Mon, 04 Aug 2003 22:06:34 +0200 From: "Ihar 'Philips' Filipau" Organization: Home Sweet Home User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca CC: netdev@oss.sgi.com Subject: Re: TOE brain dump References: <1060015518.1103.399.camel@jzny.localdomain> <3F2EAA78.60202@softhome.net> <1060026149.1102.411.camel@jzny.localdomain> In-Reply-To: <1060026149.1102.411.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4528 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: filia@softhome.net Precedence: bulk X-list: netdev jamal wrote: > >> It just takes only 3k. And it handles some special (read - >>proprietary) functions too - some bugs of some other pieces of hardware. >>NPU does all stuff by itself, but sometimes we need to extract >>configuration information which is direct to us, for example. > > > Please provide me a pointer if you can - I am very interested in the 2G > code space you mention. > I'm not sure - actually as I wrote - immediately gone checking specs. try: http://www.vitesse.com/products/categories.cfm?family_id=5&category_id=16 ... [ Okay I got to docs server. ] You are right - It has limit of 4K insns == 16k of executable memory. Sorry for confusion :( We really can address a lot of memory - we have 32MB for routing info and configuration - but for execution only 16kB of memory is available... From ak@muc.de Mon Aug 4 13:35:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Aug 2003 13:35:54 -0700 (PDT) Received: from colin2.muc.de (qmailr@colin2.muc.de [193.149.48.15]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h74KZgFl031967 for ; Mon, 4 Aug 2003 13:35:43 -0700 Received: (qmail 21559 invoked by uid 3709); 4 Aug 2003 20:35:24 -0000 Date: 4 Aug 2003 22:35:24 +0200 Date: Mon, 4 Aug 2003 22:35:24 +0200 From: Andi Kleen To: "David S. Miller" Cc: yoshfuji@linux-ipv6.org, ak@muc.de, netdev@oss.sgi.com Subject: Re: [PATCH] Make XFRM optional Message-ID: <20030804203524.GA15874@colin2.muc.de> References: <20030804125022.GA8167@averell> <20030804.215801.124854897.yoshfuji@linux-ipv6.org> <20030804130408.GA36367@colin2.muc.de> <20030804114507.6e496c77.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030804114507.6e496c77.davem@redhat.com> User-Agent: Mutt/1.4.1i X-archive-position: 4529 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@colin2.muc.de Precedence: bulk X-list: netdev Ok, here is a new patch again current BKCVS. It also moves the inet_peer_idlock only inside netsyms. -Andi diff -u linux-xfrm/include/net/dst.h-XFRM linux-xfrm/include/net/dst.h --- linux-xfrm/include/net/dst.h-XFRM 2003-06-29 12:29:21.000000000 +0200 +++ linux-xfrm/include/net/dst.h 2003-08-04 22:16:49.000000000 +0200 @@ -247,8 +247,16 @@ extern void dst_init(void); struct flowi; +#ifndef CONFIG_XFRM +static inline int xfrm_lookup(struct dst_entry **dst_p, struct flowi *fl, + struct sock *sk, int flags) +{ + return 0; +} +#else extern int xfrm_lookup(struct dst_entry **dst_p, struct flowi *fl, struct sock *sk, int flags); #endif +#endif #endif /* _NET_DST_H */ diff -u linux-xfrm/include/net/xfrm.h-XFRM linux-xfrm/include/net/xfrm.h --- linux-xfrm/include/net/xfrm.h-XFRM 2003-08-04 22:09:46.000000000 +0200 +++ linux-xfrm/include/net/xfrm.h 2003-08-04 22:16:49.000000000 +0200 @@ -588,6 +588,8 @@ return !0; } +#ifdef CONFIG_XFRM + extern int __xfrm_policy_check(struct sock *, int dir, struct sk_buff *skb, unsigned short family); static inline int xfrm_policy_check(struct sock *sk, int dir, struct sk_buff *skb, unsigned short family) @@ -653,6 +655,26 @@ } } +#else + +static inline void xfrm_sk_free_policy(struct sock *sk) {} +static inline int xfrm_sk_clone_policy(struct sock *sk) { return 0; } +static inline int xfrm6_route_forward(struct sk_buff *skb) { return 1; } +static inline int xfrm4_route_forward(struct sk_buff *skb) { return 1; } +static inline int xfrm6_policy_check(struct sock *sk, int dir, struct sk_buff *skb) +{ + return 1; +} +static inline int xfrm4_policy_check(struct sock *sk, int dir, struct sk_buff *skb) +{ + return 1; +} +static inline int xfrm_policy_check(struct sock *sk, int dir, struct sk_buff *skb, unsigned short family) +{ + return 1; +} +#endif + static __inline__ xfrm_address_t *xfrm_flowi_daddr(struct flowi *fl, unsigned short family) { @@ -783,12 +805,32 @@ extern int xfrm_check_selectors(struct xfrm_state **x, int n, struct flowi *fl); extern int xfrm_check_output(struct xfrm_state *x, struct sk_buff *skb, unsigned short family); extern int xfrm4_rcv(struct sk_buff *skb); -extern int xfrm4_rcv_encap(struct sk_buff *skb, __u16 encap_type); extern int xfrm4_tunnel_register(struct xfrm_tunnel *handler); extern int xfrm4_tunnel_deregister(struct xfrm_tunnel *handler); extern int xfrm4_tunnel_check_size(struct sk_buff *skb); extern int xfrm6_rcv(struct sk_buff **pskb, unsigned int *nhoffp); + +#ifdef CONFIG_XFRM +extern int xfrm4_rcv_encap(struct sk_buff *skb, __u16 encap_type); extern int xfrm_user_policy(struct sock *sk, int optname, u8 *optval, int optlen); +extern int xfrm_dst_lookup(struct xfrm_dst **dst, struct flowi *fl, unsigned short family); +#else +static inline int xfrm_user_policy(struct sock *sk, int optname, u8 *optval, int optlen) +{ + return -ENOPROTOOPT; +} + +static inline int xfrm4_rcv_encap(struct sk_buff *skb, __u16 encap_type) +{ + /* should not happen */ + kfree_skb(skb); + return 0; +} +static inline int xfrm_dst_lookup(struct xfrm_dst **dst, struct flowi *fl, unsigned short family) +{ + return -EINVAL; +} +#endif void xfrm_policy_init(void); void xfrm4_policy_init(void); @@ -810,7 +852,6 @@ extern int xfrm_sk_policy_insert(struct sock *sk, int dir, struct xfrm_policy *pol); extern struct xfrm_policy *xfrm_sk_policy_lookup(struct sock *sk, int dir, struct flowi *fl); extern int xfrm_flush_bundles(struct xfrm_state *x); -extern int xfrm_dst_lookup(struct xfrm_dst **dst, struct flowi *fl, unsigned short family); extern wait_queue_head_t km_waitq; extern void km_state_expired(struct xfrm_state *x, int hard); diff -u linux-xfrm/net/core/skbuff.c-XFRM linux-xfrm/net/core/skbuff.c --- linux-xfrm/net/core/skbuff.c-XFRM 2003-06-19 09:21:04.000000000 +0200 +++ linux-xfrm/net/core/skbuff.c 2003-08-04 22:16:49.000000000 +0200 @@ -225,7 +225,7 @@ } dst_release(skb->dst); -#ifdef CONFIG_INET +#ifdef CONFIG_XFRM secpath_put(skb->sp); #endif if(skb->destructor) { diff -u linux-xfrm/net/ipv4/Kconfig-XFRM linux-xfrm/net/ipv4/Kconfig --- linux-xfrm/net/ipv4/Kconfig-XFRM 2003-08-04 22:09:47.000000000 +0200 +++ linux-xfrm/net/ipv4/Kconfig 2003-08-04 22:16:49.000000000 +0200 @@ -187,6 +187,7 @@ config NET_IPIP tristate "IP: tunneling" depends on INET + select XFRM ---help--- Tunneling means encapsulating data of one protocol type within another protocol and sending it over a channel that understands the @@ -205,6 +206,7 @@ config NET_IPGRE tristate "IP: GRE tunnels over IP" depends on INET + select XFRM help Tunneling means encapsulating data of one protocol type within another protocol and sending it over a channel that understands the @@ -343,6 +345,7 @@ config INET_AH tristate "IP: AH transformation" + select XFRM select CRYPTO select CRYPTO_HMAC select CRYPTO_MD5 @@ -354,6 +357,7 @@ config INET_ESP tristate "IP: ESP transformation" + select XFRM select CRYPTO select CRYPTO_HMAC select CRYPTO_MD5 @@ -366,6 +370,7 @@ config INET_IPCOMP tristate "IP: IPComp transformation" + select XFRM select CRYPTO select CRYPTO_DEFLATE ---help--- diff -u linux-xfrm/net/ipv4/Makefile-XFRM linux-xfrm/net/ipv4/Makefile --- linux-xfrm/net/ipv4/Makefile-XFRM 2003-08-04 22:09:47.000000000 +0200 +++ linux-xfrm/net/ipv4/Makefile 2003-08-04 22:16:49.000000000 +0200 @@ -23,4 +23,4 @@ obj-$(CONFIG_NETFILTER) += netfilter/ obj-$(CONFIG_IP_VS) += ipvs/ -obj-y += xfrm4_policy.o xfrm4_state.o xfrm4_input.o xfrm4_tunnel.o +obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o xfrm4_tunnel.o diff -u linux-xfrm/net/ipv4/route.c-XFRM linux-xfrm/net/ipv4/route.c --- linux-xfrm/net/ipv4/route.c-XFRM 2003-06-19 09:21:04.000000000 +0200 +++ linux-xfrm/net/ipv4/route.c 2003-08-04 22:16:49.000000000 +0200 @@ -2785,8 +2785,10 @@ create_proc_read_entry("net/rt_acct", 0, 0, ip_rt_acct_read, NULL); #endif #endif +#ifdef CONFIG_XFRM xfrm_init(); xfrm4_init(); +#endif out: return rc; out_enomem: diff -u linux-xfrm/net/ipv4/udp.c-XFRM linux-xfrm/net/ipv4/udp.c --- linux-xfrm/net/ipv4/udp.c-XFRM 2003-08-04 22:09:47.000000000 +0200 +++ linux-xfrm/net/ipv4/udp.c 2003-08-04 22:16:49.000000000 +0200 @@ -938,6 +938,9 @@ */ static int udp_encap_rcv(struct sock * sk, struct sk_buff *skb) { +#ifndef CONFIG_XFRM + return 1; +#else struct udp_opt *up = udp_sk(sk); struct udphdr *uh = skb->h.uh; struct iphdr *iph; @@ -997,10 +1000,12 @@ return -1; default: - printk(KERN_INFO "udp_encap_rcv(): Unhandled UDP encap type: %u\n", - encap_type); + if (net_ratelimit()) + printk(KERN_INFO "udp_encap_rcv(): Unhandled UDP encap type: %u\n", + encap_type); return 1; } +#endif } /* returns: diff -u linux-xfrm/net/ipv6/Kconfig-XFRM linux-xfrm/net/ipv6/Kconfig --- linux-xfrm/net/ipv6/Kconfig-XFRM 2003-08-04 22:09:48.000000000 +0200 +++ linux-xfrm/net/ipv6/Kconfig 2003-08-04 22:16:49.000000000 +0200 @@ -22,6 +22,7 @@ config INET6_AH tristate "IPv6: AH transformation" depends on IPV6 + select XFRM select CRYPTO select CRYPTO_HMAC select CRYPTO_MD5 @@ -34,6 +35,7 @@ config INET6_ESP tristate "IPv6: ESP transformation" depends on IPV6 + select XFRM select CRYPTO select CRYPTO_HMAC select CRYPTO_MD5 @@ -47,6 +49,7 @@ config INET6_IPCOMP tristate "IPv6: IPComp transformation" depends on IPV6 + select XFRM select CRYPTO select CRYPTO_DEFLATE ---help--- diff -u linux-xfrm/net/ipv6/Makefile-XFRM linux-xfrm/net/ipv6/Makefile --- linux-xfrm/net/ipv6/Makefile-XFRM 2003-06-14 12:19:38.000000000 +0200 +++ linux-xfrm/net/ipv6/Makefile 2003-08-04 22:16:49.000000000 +0200 @@ -8,8 +8,9 @@ route.o ip6_fib.o ipv6_sockglue.o ndisc.o udp.o raw.o \ protocol.o icmp.o mcast.o reassembly.o tcp_ipv6.o \ exthdrs.o sysctl_net_ipv6.o datagram.o proc.o \ - ip6_flowlabel.o ipv6_syms.o \ - xfrm6_policy.o xfrm6_state.o xfrm6_input.o + ip6_flowlabel.o ipv6_syms.o + +obj-$(CONFIG_XFRM) += xfrm6_policy.o xfrm6_state.o xfrm6_input.o obj-$(CONFIG_INET6_AH) += ah6.o obj-$(CONFIG_INET6_ESP) += esp6.o diff -u linux-xfrm/net/ipv6/ipv6_syms.c-XFRM linux-xfrm/net/ipv6/ipv6_syms.c --- linux-xfrm/net/ipv6/ipv6_syms.c-XFRM 2003-06-16 09:04:50.000000000 +0200 +++ linux-xfrm/net/ipv6/ipv6_syms.c 2003-08-04 22:16:49.000000000 +0200 @@ -36,7 +36,9 @@ EXPORT_SYMBOL(in6addr_loopback); EXPORT_SYMBOL(in6_dev_finish_destroy); EXPORT_SYMBOL(ip6_find_1stfragopt); +#ifdef CONFIG_XFRM EXPORT_SYMBOL(xfrm6_rcv); +#endif EXPORT_SYMBOL(rt6_lookup); EXPORT_SYMBOL(fl6_sock_lookup); EXPORT_SYMBOL(ipv6_ext_hdr); diff -u linux-xfrm/net/ipv6/route.c-XFRM linux-xfrm/net/ipv6/route.c --- linux-xfrm/net/ipv6/route.c-XFRM 2003-08-04 22:09:48.000000000 +0200 +++ linux-xfrm/net/ipv6/route.c 2003-08-04 22:16:49.000000000 +0200 @@ -1988,7 +1988,9 @@ if (p) p->proc_fops = &rt6_stats_seq_fops; #endif +#ifdef CONFIG_XFRM xfrm6_init(); +#endif } #ifdef MODULE diff -u linux-xfrm/net/xfrm/Kconfig-XFRM linux-xfrm/net/xfrm/Kconfig --- linux-xfrm/net/xfrm/Kconfig-XFRM 2003-06-14 12:19:38.000000000 +0200 +++ linux-xfrm/net/xfrm/Kconfig 2003-08-04 22:16:49.000000000 +0200 @@ -1,9 +1,13 @@ # # XFRM configuration # +config XFRM + bool + depends on NET + config XFRM_USER tristate "IPsec user configuration interface" - depends on INET + depends on INET && XFRM ---help--- Support for IPsec user configuration interface used by native Linux tools. diff -u linux-xfrm/net/xfrm/Makefile-XFRM linux-xfrm/net/xfrm/Makefile --- linux-xfrm/net/xfrm/Makefile-XFRM 2003-06-14 12:19:38.000000000 +0200 +++ linux-xfrm/net/xfrm/Makefile 2003-08-04 22:16:49.000000000 +0200 @@ -2,6 +2,7 @@ # Makefile for the XFRM subsystem. # -obj-y := xfrm_policy.o xfrm_state.o xfrm_input.o xfrm_algo.o xfrm_output.o +obj-$(CONFIG_XFRM) := xfrm_policy.o xfrm_state.o xfrm_input.o xfrm_algo.o xfrm_output.o \ + xfrm_export.o obj-$(CONFIG_XFRM_USER) += xfrm_user.o diff -u linux-xfrm/net/Kconfig-XFRM linux-xfrm/net/Kconfig --- linux-xfrm/net/Kconfig-XFRM 2003-08-04 22:09:47.000000000 +0200 +++ linux-xfrm/net/Kconfig 2003-08-04 22:16:49.000000000 +0200 @@ -83,6 +83,7 @@ config NET_KEY tristate "PF_KEY sockets" + select XFRM ---help--- PF_KEYv2 socket family, compatible to KAME ones. They are required if you are going to use IPsec tools ported diff -u linux-xfrm/net/netsyms.c-XFRM linux-xfrm/net/netsyms.c --- linux-xfrm/net/netsyms.c-XFRM 2003-08-04 22:09:47.000000000 +0200 +++ linux-xfrm/net/netsyms.c 2003-08-04 22:19:14.000000000 +0200 @@ -56,7 +56,6 @@ #include #include #include -#include #if defined(CONFIG_INET_AH) || defined(CONFIG_INET_AH_MODULE) || defined(CONFIG_INET6_AH) || defined(CONFIG_INET6_AH_MODULE) #include #endif @@ -276,6 +275,7 @@ EXPORT_SYMBOL(inetdev_by_index); EXPORT_SYMBOL(in_dev_finish_destroy); EXPORT_SYMBOL(ip_defrag); +EXPORT_SYMBOL(inet_peer_idlock); /* Route manipulation */ EXPORT_SYMBOL(ip_rt_ioctl); @@ -293,80 +293,6 @@ /* needed for ip_gre -cw */ EXPORT_SYMBOL(ip_statistics); - -EXPORT_SYMBOL(xfrm_user_policy); -EXPORT_SYMBOL(km_waitq); -EXPORT_SYMBOL(km_new_mapping); -EXPORT_SYMBOL(xfrm_cfg_sem); -EXPORT_SYMBOL(xfrm_policy_alloc); -EXPORT_SYMBOL(__xfrm_policy_destroy); -EXPORT_SYMBOL(xfrm_lookup); -EXPORT_SYMBOL(__xfrm_policy_check); -EXPORT_SYMBOL(__xfrm_route_forward); -EXPORT_SYMBOL(xfrm_state_alloc); -EXPORT_SYMBOL(__xfrm_state_destroy); -EXPORT_SYMBOL(xfrm_state_find); -EXPORT_SYMBOL(xfrm_state_insert); -EXPORT_SYMBOL(xfrm_state_add); -EXPORT_SYMBOL(xfrm_state_update); -EXPORT_SYMBOL(xfrm_state_check_expire); -EXPORT_SYMBOL(xfrm_state_check_space); -EXPORT_SYMBOL(xfrm_state_lookup); -EXPORT_SYMBOL(xfrm_state_register_afinfo); -EXPORT_SYMBOL(xfrm_state_unregister_afinfo); -EXPORT_SYMBOL(xfrm_state_get_afinfo); -EXPORT_SYMBOL(xfrm_state_put_afinfo); -EXPORT_SYMBOL(xfrm_state_delete_tunnel); -EXPORT_SYMBOL(xfrm_replay_check); -EXPORT_SYMBOL(xfrm_replay_advance); -EXPORT_SYMBOL(xfrm_check_selectors); -EXPORT_SYMBOL(xfrm_check_output); -EXPORT_SYMBOL(__secpath_destroy); -EXPORT_SYMBOL(secpath_dup); -EXPORT_SYMBOL(xfrm_get_acqseq); -EXPORT_SYMBOL(xfrm_parse_spi); -EXPORT_SYMBOL(xfrm4_rcv); -EXPORT_SYMBOL(xfrm4_tunnel_register); -EXPORT_SYMBOL(xfrm4_tunnel_deregister); -EXPORT_SYMBOL(xfrm4_tunnel_check_size); -EXPORT_SYMBOL(xfrm_register_type); -EXPORT_SYMBOL(xfrm_unregister_type); -EXPORT_SYMBOL(xfrm_get_type); -EXPORT_SYMBOL(inet_peer_idlock); -EXPORT_SYMBOL(xfrm_register_km); -EXPORT_SYMBOL(xfrm_unregister_km); -EXPORT_SYMBOL(xfrm_state_delete); -EXPORT_SYMBOL(xfrm_state_walk); -EXPORT_SYMBOL(xfrm_find_acq_byseq); -EXPORT_SYMBOL(xfrm_find_acq); -EXPORT_SYMBOL(xfrm_alloc_spi); -EXPORT_SYMBOL(xfrm_state_flush); -EXPORT_SYMBOL(xfrm_policy_kill); -EXPORT_SYMBOL(xfrm_policy_bysel); -EXPORT_SYMBOL(xfrm_policy_insert); -EXPORT_SYMBOL(xfrm_policy_walk); -EXPORT_SYMBOL(xfrm_policy_flush); -EXPORT_SYMBOL(xfrm_policy_byid); -EXPORT_SYMBOL(xfrm_policy_list); -EXPORT_SYMBOL(xfrm_dst_lookup); -EXPORT_SYMBOL(xfrm_policy_register_afinfo); -EXPORT_SYMBOL(xfrm_policy_unregister_afinfo); -EXPORT_SYMBOL(xfrm_policy_get_afinfo); -EXPORT_SYMBOL(xfrm_policy_put_afinfo); - -EXPORT_SYMBOL_GPL(xfrm_probe_algs); -EXPORT_SYMBOL_GPL(xfrm_count_auth_supported); -EXPORT_SYMBOL_GPL(xfrm_count_enc_supported); -EXPORT_SYMBOL_GPL(xfrm_aalg_get_byidx); -EXPORT_SYMBOL_GPL(xfrm_ealg_get_byidx); -EXPORT_SYMBOL_GPL(xfrm_calg_get_byidx); -EXPORT_SYMBOL_GPL(xfrm_aalg_get_byid); -EXPORT_SYMBOL_GPL(xfrm_ealg_get_byid); -EXPORT_SYMBOL_GPL(xfrm_calg_get_byid); -EXPORT_SYMBOL_GPL(xfrm_aalg_get_byname); -EXPORT_SYMBOL_GPL(xfrm_ealg_get_byname); -EXPORT_SYMBOL_GPL(xfrm_calg_get_byname); -EXPORT_SYMBOL_GPL(skb_icv_walk); #if defined(CONFIG_INET_ESP) || defined(CONFIG_INET_ESP_MODULE) || defined(CONFIG_INET6_ESP) || defined(CONFIG_INET6_ESP_MODULE) EXPORT_SYMBOL_GPL(skb_cow_data); EXPORT_SYMBOL_GPL(pskb_put); From shemminger@osdl.org Mon Aug 4 16:43:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Aug 2003 16:43:34 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h74NhPFl004508 for ; Mon, 4 Aug 2003 16:43:26 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h74NLlI08855; Mon, 4 Aug 2003 16:21:47 -0700 Date: Mon, 4 Aug 2003 16:21:47 -0700 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] convert lp486e driver to dynamic allocation Message-Id: <20030804162147.591c55f6.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.3claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4530 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Convert this driver from static net_device to using alloc_etherdev. Patch against 2.6.0-test2. Loads and unloads, but don't have the actual hardware. diff -Nru a/drivers/net/lp486e.c b/drivers/net/lp486e.c --- a/drivers/net/lp486e.c Mon Aug 4 14:53:55 2003 +++ b/drivers/net/lp486e.c Mon Aug 4 14:53:55 2003 @@ -975,15 +975,7 @@ return -EBUSY; } - /* - * Allocate working memory, 16-byte aligned - */ - dev->mem_start = (unsigned long) kmalloc(sizeof(struct i596_private) + 0x0f, GFP_KERNEL); - if (!dev->mem_start) - goto err_out; - dev->priv = (void *)((dev->mem_start + 0xf) & 0xfffffff0); lp = (struct i596_private *) dev->priv; - memset((void *)lp, 0, sizeof(struct i596_private)); spin_lock_init(&lp->cmd_lock); /* @@ -997,7 +989,6 @@ dev->base_addr = IOADDR; dev->irq = IRQ; - ether_setup(dev); /* * How do we find the ethernet address? I don't know. @@ -1045,8 +1036,6 @@ return 0; err_out_kfree: - kfree ((void *) dev->mem_start); -err_out: release_region(IOADDR, LP486E_TOTAL_SIZE); return ret; } @@ -1318,29 +1307,36 @@ MODULE_PARM(options, "1-" __MODULE_STRING(MAX_UNITS) "i"); MODULE_PARM(full_duplex, "1-" __MODULE_STRING(MAX_UNITS) "i"); -static struct net_device dev_lp486e; +static struct net_device *dev_lp486e; static int full_duplex; static int options; static int io = IOADDR; static int irq = IRQ; static int __init lp486e_init_module(void) { - struct net_device *dev = &dev_lp486e; + struct net_device *dev; + + dev = alloc_etherdev(sizeof(struct i596_private)); + if (!dev) + return -ENOMEM; + dev->irq = irq; dev->base_addr = io; dev->init = lp486e_probe; - if (register_netdev(dev) != 0) + if (register_netdev(dev) != 0) { + kfree(dev); return -EIO; + } + dev_lp486e = dev; full_duplex = 0; options = 0; return 0; } static void __exit lp486e_cleanup_module(void) { - unregister_netdev(&dev_lp486e); - kfree((void *)dev_lp486e.mem_start); - dev_lp486e.priv = NULL; - release_region(dev_lp486e.base_addr, LP486E_TOTAL_SIZE); + unregister_netdev(dev_lp486e); + release_region(dev_lp486e->base_addr, LP486E_TOTAL_SIZE); + kfree(dev_lp486e); } module_init(lp486e_init_module); From davem@redhat.com Mon Aug 4 16:53:51 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Aug 2003 16:53:55 -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 h74NroFl004999 for ; Mon, 4 Aug 2003 16:53:51 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id QAA21337; Mon, 4 Aug 2003 16:49:20 -0700 Date: Mon, 4 Aug 2003 16:49:20 -0700 From: "David S. Miller" To: Andi Kleen Cc: yoshfuji@linux-ipv6.org, ak@muc.de, netdev@oss.sgi.com Subject: Re: [PATCH] Make XFRM optional Message-Id: <20030804164920.371d5afd.davem@redhat.com> In-Reply-To: <20030804203524.GA15874@colin2.muc.de> References: <20030804125022.GA8167@averell> <20030804.215801.124854897.yoshfuji@linux-ipv6.org> <20030804130408.GA36367@colin2.muc.de> <20030804114507.6e496c77.davem@redhat.com> <20030804203524.GA15874@colin2.muc.de> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4531 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On 4 Aug 2003 22:35:24 +0200 Andi Kleen wrote: > Ok, here is a new patch again current BKCVS. It also moves the > inet_peer_idlock only inside netsyms. Appied, thanks Andi. From davem@redhat.com Mon Aug 4 16:56:06 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Aug 2003 16:56:12 -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 h74Nu5Fl005356 for ; Mon, 4 Aug 2003 16:56:06 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id QAA21354; Mon, 4 Aug 2003 16:51:37 -0700 Date: Mon, 4 Aug 2003 16:51:37 -0700 From: "David S. Miller" To: Andi Kleen Cc: yoshfuji@linux-ipv6.org, ak@muc.de, netdev@oss.sgi.com Subject: Re: [PATCH] Make XFRM optional Message-Id: <20030804165137.40d744c5.davem@redhat.com> In-Reply-To: <20030804203524.GA15874@colin2.muc.de> References: <20030804125022.GA8167@averell> <20030804.215801.124854897.yoshfuji@linux-ipv6.org> <20030804130408.GA36367@colin2.muc.de> <20030804114507.6e496c77.davem@redhat.com> <20030804203524.GA15874@colin2.muc.de> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4532 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On 4 Aug 2003 22:35:24 +0200 Andi Kleen wrote: > Ok, here is a new patch again current BKCVS. It also moves the inet_peer_idlock > only inside netsyms. This one is missing net/xfrm/xfrm_export.c :-( Andi, please be more careful with your patches. I'd suggest use subversions or whatever source management system you like best to help avoid these problems in the future. You seem to be chronicly making mistakes like this, as if you're rushing things. From davem@redhat.com Mon Aug 4 17:02:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Aug 2003 17:02:51 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7502iFl005850 for ; Mon, 4 Aug 2003 17:02:44 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id QAA21376; Mon, 4 Aug 2003 16:57:46 -0700 Date: Mon, 4 Aug 2003 16:57:46 -0700 From: "David S. Miller" To: Krishna Kumar Cc: kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com, krkumar@us.ibm.com Subject: Re: O/M flags against 2.6.0-test1 Message-Id: <20030804165746.133f370a.davem@redhat.com> In-Reply-To: References: <20030730220223.4c25fcfe.davem@redhat.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4533 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Thu, 31 Jul 2003 13:33:27 -0700 (PDT) Krishna Kumar wrote: > > Ok, but then please use "__s32". > > OK, slowly getting there :-) > > Latest patch follows : Krishna is away, but let us make more progress on this patch. I see some problem with it that still need to be resolved: > +/* Subtype attributes for IFLA_PROTINFO */ > +enum > +{ > + IFLA_INET6_UNSPEC, > + IFLA_INET6_FLAGS, /* link flags */ > + IFLA_INET6_CONF, /* sysctl parameters */ > + IFLA_INET6_STATS, /* statistics */ > + IFLA_INET6_MCAST, /* MC things. What of them? */ > +}; > + > +#define IFLA_INET6_MAX IFLA_INET6_MCAST Ok, how does this actually work? The code does RTA_PUT(...IFLA_INET6_*...) but IFLA_PROTINFO is not actually used anywhere. This cannot work, it makes these RTA attributes just look like whatever IFLA_* ones have the same values as the inet6 ones in this enumeration. Alexey, how did you intend this stuff to be done? Cerainly not like this :-) > + /* return the device sysctl params */ > + if ((array = kmalloc(DEVCONF_MAX * sizeof(*array), GFP_KERNEL)) == NULL) > + goto rtattr_failure; > + ipv6_store_devconf(&idev->cnf, array); > + RTA_PUT(skb, IFLA_INET6_CONF, DEVCONF_MAX * sizeof(*array), array); This is what I'm talking about. Maybe there is something I'm missing. How does APP know to interpret IFLA_INET6_CONF as "sub-attribute" of IFLA_PROTINFO? Also, missing "memset(array, 0, sizeof(*array));" else we leak uninitialized kernel memory into user space. Another bug, GFP_KERNEL memory allocation with dev_base_lock held. Otherwise I am OK with the patch. From davem@redhat.com Mon Aug 4 17:03:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Aug 2003 17:03:33 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7503TFl006007 for ; Mon, 4 Aug 2003 17:03:29 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id QAA21402; Mon, 4 Aug 2003 16:59:04 -0700 Date: Mon, 4 Aug 2003 16:59:04 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH] convert lp486e driver to dynamic allocation Message-Id: <20030804165904.0e9f60ab.davem@redhat.com> In-Reply-To: <20030804162147.591c55f6.shemminger@osdl.org> References: <20030804162147.591c55f6.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4534 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 4 Aug 2003 16:21:47 -0700 Stephen Hemminger wrote: > Convert this driver from static net_device to using alloc_etherdev. Applied, thanks. From scott.feldman@intel.com Mon Aug 4 20:45:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Aug 2003 20:45:24 -0700 (PDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h753jFFl017502 for ; Mon, 4 Aug 2003 20:45:15 -0700 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h753h3x04231 for ; Tue, 5 Aug 2003 03:43:03 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h753eBv26263 for ; Tue, 5 Aug 2003 03:40:11 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003080420571626008 ; Mon, 04 Aug 2003 20:57:16 -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); Mon, 4 Aug 2003 20:45:09 -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: e100 "Ferguson" release Date: Mon, 4 Aug 2003 20:45:08 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: e100 "Ferguson" release Thread-Index: AcNZhWYRC0Gz1n9oToGU+hvgKaMpJwBWPZNQ From: "Feldman, Scott" To: "Jeff Garzik" Cc: X-OriginalArrivalTime: 05 Aug 2003 03:45:09.0070 (UTC) FILETIME=[F76DBEE0:01C35B03] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h753jFFl017502 X-archive-position: 4535 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 New one: http://sf.net/projects/e1000, e100-3.0.0_dev12.tar.gz > Comments: Thanks Jeff! > * (API) Does the out-of-tx-resources condition in > e100_xmit_frame ever really happen? I am under the > impression that returning non-zero in ->hard_start_xmit > results in the packet sometimes being requeued and > sometimes dropped. I prefer to guarantee a more-steady > state, by simply dropping the packet unconditionally, > when this uncommon condition occurs. So, I would > a) mark the failure condition with unlikely(), and > b) if the condition occurs, simply drop the packet > (tx_dropped++, kfree > skb), and return zero. Stop the queue also? if(unlikely(e100_exec_cb(nic, skb, e100_xmit_prepare) == -ENOMEM)) { netif_stop_queue(netdev); nic->net_stats.tx_dropped++; dev_kfree_skb(skb); return 0; } Added some more likely/unlikely's in the perf paths. > * (minor) for completeness, you should limit the PCI class in the > pci_device_id table to PCI_CLASS_NETWORK_ETHERNET. There are > one-in-a-million cases where this matters, but it's usually a > BIOS bug. Still, it's there in pci_device_id table, and it's an easy > change, so might as well use it. OK > * (style) your struct config definition is terribly clever. > perhaps too clever, making it unreadable? Not a specific complaint, > mind you, just something that caught my eye. Then the driver would be perfect. We can't have that. ;-) > * (minor) in tg3, my own benchmarks and experiments showed it > helped to explictly use ____cacheline_aligned markers when > defining certain sections of members in struct tg3 > (or struct nic, in e100's case). You already clearly pay > attention to member layout WRT cache effects, but if > you have a clear dividing line, or lines, in struct nic you can use > _____cacheline_aligned for even greater benefit. At a > minimum test it with a cpu-usage-measuring benchmark like ttcp, > though, of course :) OK > * (extremely minor) some people (like me :)) consider dead reads like > the readb() call in e100_write_flush OK > * (major?) Aren't there some clunky e100 adapters that don't do MMIO? > Do we care? Not that I'm aware of. Current e100 doesn't support them if they're out there. > * I would love to see feedback from people testing this > driver on ppc64 and sparc64, particularly. Me too. Things seem to work on ppc (Mac) and ia64. > * (style, minor) My eyes would prefer functions like e100_hw_reset to > have a few more blank lines in them, spreading code+comment > blocks out a bit. OK > * (extremely minor) one wonders if you really need the write flush in > mdio_ctrl. If the flush is removed, the same net effect > appears to occur. Good catch. > * (boring but needed) convert all the magic numbers in e100_configure > into constants, or at least add comments describing the magic > numbers. If the value is just one bit, you might simply append "/* > true */", for example. The general idea is to make the "member name = > value" list a little bit more readable to somebody who doesn't know the > hardware, and struct config, intimately. That _was_ boring. > * IIRC Donald's MII phy scanning code scans MII phy ids like this: > 1..31,0. Or maybe 1..31, and then 0 iff no MII phys were found. In > general I would prefer to follow his eepro100.c probe order. > Some phys need this because they will report on both phy id #0 (which > is magical) and phy id #(non-zero). Donald would know more than me, here. [kernel] eepro100 gets the ID from the eeprom, so no scanning there. Current e100 goes 1, 0..31, which is what we've always done, IIRC. > * Is it easy to support MII phy interrupts? It would be nice > to get a callback that was handled immediately, on phys that > do support such interrupts. I don't see those being passed through and handled by the MAC. > * do we care about spinlocks around the update_stats and > get_stats code? Not sure. update_stats runs in a timer callback. Can get_stats jump in? > * (bugs) in e100_up, you should undo mod_timer [major] and > netif_start_queue [minor], if request_irq fails. And maybe stop the > receiver, too? OK > * for all constants 0xffffffff (and others as well if you so choose), > prefer the C99 suffix to a cast. This is particularly relevant in > pci_set_dma_mask calls, where one should be using 0xffffffffULL, but > applies to other constants as well. I didn't see any other constant casts besides the pci_set_dma_mask call. That one is fixed. > * (potential races) in e100_probe, you want to call > register_netdev as basically the last operation that can > fail, if possible. Particularly, you need to move the > PCI API operations above register_netdev. > Remember, register_netdev winds up calling /sbin/hotplug, > which in turn calls programs that will want to start using > the interface. So you need to have everything set up by > that point, really. OK (nice catch). > * in e100_probe, "if(nic->csr == 0UL) {" should really just test for > NULL, because ioremap is defined to return a pointer... OK > * (minor) use a netif_msg_xxx wrapper/constant in > e100_init_module test? Can't - don't have nic->msg_enable allocated yet. :( -scott From jgarzik@pobox.com Mon Aug 4 22:29:55 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 04 Aug 2003 22:30:40 -0700 (PDT) Received: from www.linux.org.uk (IDENT:h2Rxu3GU7PMeJPrMvDTL9MOVi3QhHI88@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h755TsFl022666 for ; Mon, 4 Aug 2003 22:29:55 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19juOO-00060o-CI; Tue, 05 Aug 2003 06:29:52 +0100 Message-ID: <3F2F40C5.9070601@pobox.com> Date: Tue, 05 Aug 2003 01:29:41 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: "Feldman, Scott" CC: netdev@oss.sgi.com Subject: Re: e100 "Ferguson" release References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4536 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 Feldman, Scott wrote: >>* (API) Does the out-of-tx-resources condition in >>e100_xmit_frame ever really happen? I am under the >>impression that returning non-zero in ->hard_start_xmit >>results in the packet sometimes being requeued and >>sometimes dropped. I prefer to guarantee a more-steady >>state, by simply dropping the packet unconditionally, >>when this uncommon condition occurs. So, I would >>a) mark the failure condition with unlikely(), and >>b) if the condition occurs, simply drop the packet >>(tx_dropped++, kfree >>skb), and return zero. > > > Stop the queue also? > > if(unlikely(e100_exec_cb(nic, skb, e100_xmit_prepare) == -ENOMEM)) { > netif_stop_queue(netdev); > nic->net_stats.tx_dropped++; > dev_kfree_skb(skb); > return 0; > } Yes. I would also printk(KERN_ERR "we have a bug!") or somesuch, like several other drivers do, too. >>* IIRC Donald's MII phy scanning code scans MII phy ids like this: >>1..31,0. Or maybe 1..31, and then 0 iff no MII phys were found. In >>general I would prefer to follow his eepro100.c probe order. >>Some phys need this because they will report on both phy id #0 (which >>is magical) and phy id #(non-zero). Donald would know more than me, > > here. > > [kernel] eepro100 gets the ID from the eeprom, so no scanning there. > Current e100 goes 1, 0..31, which is what we've always done, IIRC. hmmm. I prefer the phy scanning to checking eeprom, since it reduces the chance of eeprom screwups. However, I still think there's some issue related to phy id #0. Oh well, fine for now, I guess. >>* do we care about spinlocks around the update_stats and >>get_stats code? > > > Not sure. update_stats runs in a timer callback. Can get_stats jump > in? Well, the ->get_stats only returns a pointer to the stats, which are then accessed in an unlocked manner. Since the net stats are unsigned longs, asynchronously reading and updating them isn't a big deal in practice. >>* (minor) use a netif_msg_xxx wrapper/constant in >>e100_init_module test? > > > Can't - don't have nic->msg_enable allocated yet. :( You could always use "(1 << debug) - 1"... :) I dunno if it's worth worrying about. Jeff From davem@redhat.com Tue Aug 5 00:21:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 00:22:20 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h757L0Fl030028 for ; Tue, 5 Aug 2003 00:21:41 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id AAA22135; Tue, 5 Aug 2003 00:16:31 -0700 Date: Tue, 5 Aug 2003 00:16:31 -0700 From: "David S. Miller" To: "Feldman, Scott" Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: e100 "Ferguson" release Message-Id: <20030805001631.2fb55f38.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4537 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 4 Aug 2003 20:45:08 -0700 "Feldman, Scott" wrote: > > * I would love to see feedback from people testing this > > driver on ppc64 and sparc64, particularly. > > Me too. Things seem to work on ppc (Mac) and ia64. This gets things building on sparc64, I'll stick an e100 into my workstation and use it for everything for a while using this driver. --- Makefile.~1~ 2003-08-04 20:20:42.000000000 -0700 +++ Makefile 2003-08-05 00:12:29.000000000 -0700 @@ -96,10 +96,15 @@ endif # pick a compiler -ifneq (,$(findstring egcs-2.91.66, $(shell cat /proc/version))) - CC := kgcc gcc cc +ARCH := $(shell uname -m | sed 's/i.86/i386/') +ifeq ($(ARCH),sparc64) +CC := $(shell if gcc -m64 -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo gcc; else echo sparc64-linux-gcc; fi ) else - CC := gcc cc + ifneq (,$(findstring egcs-2.91.66, $(shell cat /proc/version))) + CC := kgcc gcc cc + else + CC := gcc cc + endif endif test_cc = $(shell which $(cc) > /dev/null 2>&1 && echo $(cc)) CC := $(foreach cc, $(CC), $(test_cc)) @@ -198,10 +203,30 @@ # we need to know what platform the driver is being built on # some additional features are only built on Intel platforms -ARCH := $(shell uname -m | sed 's/i.86/i386/') ifeq ($(ARCH),alpha) CFLAGS += -ffixed-8 -mno-fp-regs endif +ifeq ($(ARCH),sparc64) + NEW_GCC := $(shell if $(CC) -m64 -mcmodel=medlow -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo y; else echo n; fi; ) + UNDECLARED_REGS := $(shell if $(CC) -c -x assembler /dev/null -Wa,--help | grep undeclared-regs > /dev/null; then echo y; else echo n; fi; ) + INLINE_LIMIT := $(shell if $(CC) -m64 -finline-limit=100000 -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo y; else echo n; fi; ) + ifneq ($(UNDECLARED_REGS),y) + CC_UNDECL = + else + CC_UNDECL = -Wa,--undeclared-regs + endif + ifneq ($(NEW_GCC),y) + CFLAGS += -pipe -mno-fpu -mtune=ultrasparc -mmedlow \ + -ffixed-g4 -fcall-used-g5 -fcall-used-g7 -Wno-sign-compare + else + CFLAGS += -m64 -pipe -mno-fpu -mcpu=ultrasparc -mcmodel=medlow \ + -ffixed-g4 -fcall-used-g5 -fcall-used-g7 -Wno-sign-compare \ + $(CC_UNDECL) + endif + ifeq ($(INLINE_LIMIT),y) + CFLAGS := $(CFLAGS) -finline-limit=100000 + endif +endif # depmod version for rpm builds DEPVER := $(shell /sbin/depmod -V 2>/dev/null | awk 'BEGIN {FS="."} NR==1 {print $$2}') --- e100.c.~1~ 2003-08-04 20:20:42.000000000 -0700 +++ e100.c 2003-08-05 00:13:23.000000000 -0700 @@ -150,6 +150,7 @@ #include #include #include +#include #include "kcompat.h" From felix@allot.com Tue Aug 5 01:23:06 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 01:23:14 -0700 (PDT) Received: from mxout3.netvision.net.il (mxout3.netvision.net.il [194.90.9.24]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h758N4Fl001990 for ; Tue, 5 Aug 2003 01:23:05 -0700 Received: from exg.allot.com ([199.203.223.202]) by mxout3.netvision.net.il (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HJ50039I0M9WZ@mxout3.netvision.net.il> for netdev@oss.sgi.com; Tue, 05 Aug 2003 11:22:57 +0300 (IDT) Received: from allot.com (199.203.223.201 [199.203.223.201]) by exg.allot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QG1CBB3A; Tue, 05 Aug 2003 11:25:57 +0200 Date: Tue, 05 Aug 2003 11:23:22 +0300 From: Felix Radensky Subject: Re: e100 "Ferguson" release To: Ben Greear Cc: Jeff Garzik , "Feldman, Scott" , netdev@oss.sgi.com Message-id: <3F2F697A.2020708@allot.com> Organization: Allot Communications Ltd. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 References: <3F2CA65F.8060105@pobox.com> <3F2CBA71.2070503@candelatech.com> X-archive-position: 4538 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: felix@allot.com Precedence: bulk X-list: netdev I've also noticed that the number of hard_start_xmit failures in e1000 has increased significantly in version 5.1.13-k1. In version 5.0.43-k1 the number of failures was much smaller. Felix. Ben Greear wrote: > > > > With e100 and e1000, I see the very large numbers of the > hard_start_xmit failure > when running very high packets-per-second rates (small packets). > I see virtually no failures with tulip. pktgen knows how to re-queue, > but it's > curious it has to so often. For code that does not requeue, this > could be even > more of a bummer. > > > From kuznet@ms2.inr.ac.ru Tue Aug 5 06:41:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 06:41:07 -0700 (PDT) Received: from dub.inr.ac.ru (dub.inr.ac.ru [193.233.7.105]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h75Df0Fl005543 for ; Tue, 5 Aug 2003 06:41:01 -0700 Received: (from kuznet@localhost) by dub.inr.ac.ru (8.6.13/ANK) id RAA28267; Tue, 5 Aug 2003 17:40:42 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200308051340.RAA28267@dub.inr.ac.ru> Subject: [PATCH] repairing rtcache killer To: davem@redhat.com, Robert.Olsson@data.slu.se, netdev@oss.sgi.com Date: Tue, 5 Aug 2003 17:40:42 +0400 (MSD) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4539 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Hello! Alexey # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1613 -> 1.1614 # net/ipv4/route.c 1.66 -> 1.67 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 03/08/05 kuznet@mops.inr.ac.ru 1.1614 # route.c: # [IPV4] Repair calculation of rtcache entries score # # Two serious and interesting mistakes were made in the patch of 2003-06-16. # 1. Variance of hash chain turned out to be unexpectedly high, so truncation # chain length at <=ip_rt_gc_elasticity results in strong growth of # cache misses. Set the threshould to 2*ip_rt_gc_elasticity. # And continue to think how to switch to mode when lots of cache # entries are used once or twice, so truncation should be done at 1. # 2. The selection rt_score() function based on use count resulted in killing # new fresh entries. Actually, it is clear when minimal brain efforts # are applied. :-) So, switch to scoring using last used time, which # should give real LRU behaviour. # -------------------------------------------- # diff -Nru a/net/ipv4/route.c b/net/ipv4/route.c --- a/net/ipv4/route.c Tue Aug 5 17:37:41 2003 +++ b/net/ipv4/route.c Tue Aug 5 17:37:41 2003 @@ -463,7 +463,9 @@ */ static inline u32 rt_score(struct rtable *rt) { - u32 score = rt->u.dst.__use; + u32 score = jiffies - rt->u.dst.lastuse; + + score = ~score & ~(3<<30); if (rt_valuable(rt)) score |= (1<<31); @@ -807,8 +809,7 @@ * The second limit is less certain. At the moment it allows * only 2 entries per bucket. We will see. */ - if (chain_length > ip_rt_gc_elasticity || - (chain_length > 1 && !(min_score & (1<<31)))) { + if (chain_length > 2*ip_rt_gc_elasticity) { *candp = cand->u.rt_next; rt_free(cand); } From vnuorval@tcs.hut.fi Tue Aug 5 07:20:09 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 07:20:17 -0700 (PDT) Received: from mail.tcs.hut.fi (mail.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h75EJwFl007784 for ; Tue, 5 Aug 2003 07:19:59 -0700 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by mail.tcs.hut.fi (Postfix) with ESMTP id E93028001CD; Tue, 5 Aug 2003 16:42:32 +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 h75DgW5L031191; Tue, 5 Aug 2003 16:42:32 +0300 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-5) with ESMTP id h75DgWhQ031187; Tue, 5 Aug 2003 16:42:32 +0300 Date: Tue, 5 Aug 2003 16:42:32 +0300 (EEST) From: Ville Nuorvala To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [PATCH] IPV6: Fix bugs in ip6ip6_tnl_xmit() In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-377318441-99616309-1060088089=:30970" Content-ID: X-archive-position: 4540 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---377318441-99616309-1060088089=:30970 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Hi, There were two bugs in ip6ip6_tnl_xmit() which are fixed in this patch (made against Linux 2.6.0-test2 + cset 1.1612): - ip6_tunnel must give its own getfrag function to ip6_append_data() - fix dst leakage when encapsulated packet too big Please apply! Thanks, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 ---377318441-99616309-1060088089=:30970 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="ip6_tnl_xmit.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="ip6_tnl_xmit.patch" ZGlmZiAtTnVyIC0tZXhjbHVkZT1SQ1MgLS1leGNsdWRlPUNWUyAtLWV4Y2x1 ZGU9U0NDUyAtLWV4Y2x1ZGU9Qml0S2VlcGVyIC0tZXhjbHVkZT1DaGFuZ2VT ZXQgbGludXgtMi41Lk9MRC9uZXQvaXB2Ni9pcDZfdHVubmVsLmMgbGludXgt Mi41L25ldC9pcHY2L2lwNl90dW5uZWwuYw0KLS0tIGxpbnV4LTIuNS5PTEQv bmV0L2lwdjYvaXA2X3R1bm5lbC5jCVR1ZSBBdWcgIDUgMTU6MTU6MDcgMjAw Mw0KKysrIGxpbnV4LTIuNS9uZXQvaXB2Ni9pcDZfdHVubmVsLmMJVHVlIEF1 ZyAgNSAxNTo0NTo0MSAyMDAzDQpAQCAtNjIxLDYgKzYyMSwxNCBAQA0KIAly ZXR1cm4gb3B0Ow0KIH0NCiANCitzdGF0aWMgaW50IA0KK2lwNmlwNl9nZXRm cmFnKHZvaWQgKmZyb20sIGNoYXIgKnRvLCBpbnQgb2Zmc2V0LCBpbnQgbGVu LCBpbnQgb2RkLCANCisJCXN0cnVjdCBza19idWZmICpza2IpDQorew0KKwlt ZW1jcHkodG8sIChjaGFyICopIGZyb20gKyBvZmZzZXQsIGxlbik7DQorCXJl dHVybiAwOw0KK30NCisNCiAvKioNCiAgKiBpcDZpcDZfdG5sX2FkZHJfY29u ZmxpY3QgLSBjb21wYXJlIHBhY2tldCBhZGRyZXNzZXMgdG8gdHVubmVsJ3Mg b3duDQogICogICBAdDogdGhlIG91dGdvaW5nIHR1bm5lbCBkZXZpY2UNCkBA IC03NTUsOSArNzYzLDkgQEANCiAJfQ0KIAlpZiAoc2tiLT5sZW4gPiBtdHUp IHsNCiAJCWljbXB2Nl9zZW5kKHNrYiwgSUNNUFY2X1BLVF9UT09CSUcsIDAs IG10dSwgZGV2KTsNCi0JCWdvdG8gdHhfZXJyX29wdF9yZWxlYXNlOw0KKwkJ Z290byB0eF9lcnJfZHN0X3JlbGVhc2U7DQogCX0NCi0JZXJyID0gaXA2X2Fw cGVuZF9kYXRhKHNrLCBpcF9nZW5lcmljX2dldGZyYWcsIHNrYi0+bmgucmF3 LCBza2ItPmxlbiwgMCwNCisJZXJyID0gaXA2X2FwcGVuZF9kYXRhKHNrLCBp cDZpcDZfZ2V0ZnJhZywgc2tiLT5uaC5yYXcsIHNrYi0+bGVuLCAwLA0KIAkJ CSAgICAgIHQtPnBhcm1zLmhvcF9saW1pdCwgb3B0LCAmZmwsIA0KIAkJCSAg ICAgIChzdHJ1Y3QgcnQ2X2luZm8gKilkc3QsIE1TR19ET05UV0FJVCk7DQog DQpAQCAtNzg1LDcgKzc5Myw2IEBADQogCXJldHVybiAwOw0KIHR4X2Vycl9k c3RfcmVsZWFzZToNCiAJZHN0X3JlbGVhc2UoZHN0KTsNCi10eF9lcnJfb3B0 X3JlbGVhc2U6DQogCWlmIChvcHQgJiYgb3B0ICE9IG9yaWdfb3B0KQ0KIAkJ c29ja19rZnJlZV9zKHNrLCBvcHQsIG9wdC0+dG90X2xlbik7DQogdHhfZXJy X2ZyZWVfZmxfbGJsOg0KZGlmZiAtTnVyIC0tZXhjbHVkZT1SQ1MgLS1leGNs dWRlPUNWUyAtLWV4Y2x1ZGU9U0NDUyAtLWV4Y2x1ZGU9Qml0S2VlcGVyIC0t ZXhjbHVkZT1DaGFuZ2VTZXQgbGludXgtMi41Lk9MRC9uZXQvbmV0c3ltcy5j IGxpbnV4LTIuNS9uZXQvbmV0c3ltcy5jDQotLS0gbGludXgtMi41Lk9MRC9u ZXQvbmV0c3ltcy5jCVR1ZSBBdWcgIDUgMTU6MTU6MDMgMjAwMw0KKysrIGxp bnV4LTIuNS9uZXQvbmV0c3ltcy5jCVR1ZSBBdWcgIDUgMTM6NTg6MzQgMjAw Mw0KQEAgLTQ4MiwxMCArNDgyLDggQEANCiBFWFBPUlRfU1lNQk9MKHN5c2N0 bF9tYXhfc3luX2JhY2tsb2cpOw0KICNlbmRpZg0KIA0KLSNlbmRpZg0KLQ0K LSNpZiBkZWZpbmVkIChDT05GSUdfSVBWNl9NT0RVTEUpIHx8IGRlZmluZWQg KENPTkZJR19JUF9TQ1RQX01PRFVMRSkgfHwgZGVmaW5lZCAoQ09ORklHX0lQ VjZfVFVOTkVMX01PRFVMRSkNCiBFWFBPUlRfU1lNQk9MKGlwX2dlbmVyaWNf Z2V0ZnJhZyk7DQorDQogI2VuZGlmDQogDQogRVhQT1JUX1NZTUJPTCh0Y3Bf cmVhZF9zb2NrKTsNCg== ---377318441-99616309-1060088089=:30970-- From scott.feldman@intel.com Tue Aug 5 07:29:07 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 07:29:10 -0700 (PDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h75ET6Fl008508 for ; Tue, 5 Aug 2003 07:29:06 -0700 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h75EQrw18915 for ; Tue, 5 Aug 2003 14:26:54 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h75EO1c21378 for ; Tue, 5 Aug 2003 14:24:01 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 M2003080507285928763 ; Tue, 05 Aug 2003 07:28:59 -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, 5 Aug 2003 07:28:59 -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: e100 "Ferguson" release Date: Tue, 5 Aug 2003 07:28:58 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: e100 "Ferguson" release Thread-Index: AcNbEppm4ua1VvpURRC1DmNP6YxZrAASpVCA From: "Feldman, Scott" To: "Jeff Garzik" Cc: X-OriginalArrivalTime: 05 Aug 2003 14:28:59.0646 (UTC) FILETIME=[E90BD9E0:01C35B5D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h75ET6Fl008508 X-archive-position: 4541 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 > > if(unlikely(e100_exec_cb(nic, skb, e100_xmit_prepare) == -ENOMEM)) { > > netif_stop_queue(netdev); > > nic->net_stats.tx_dropped++; > > dev_kfree_skb(skb); > > return 0; > > } > > Yes. I would also printk(KERN_ERR "we have a bug!") or > somesuch, like several other drivers do, too. It's there, sorry, was trying to keep the code snippet small. > >>* (minor) use a netif_msg_xxx wrapper/constant in > >>e100_init_module test? > > > > > > Can't - don't have nic->msg_enable allocated yet. :( > > You could always use "(1 << debug) - 1"... :) I dunno if it's worth > worrying about. (1 << debug) - 1) & NETIF_MSG_DRV is what's there now. -scott From david-b@pacbell.net Tue Aug 5 08:14:55 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 08:15:03 -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 h75FEsFl012006 for ; Tue, 5 Aug 2003 08:14:55 -0700 Received: from pacbell.net (ppp-67-118-247-188.dialup.pltn13.pacbell.net [67.118.247.188]) by mta7.pltn13.pbi.net (8.12.9/8.12.3) with ESMTP id h75FEgeC006162; Tue, 5 Aug 2003 08:14:43 -0700 (PDT) Message-ID: <3F2E9A09.7000707@pacbell.net> Date: Mon, 04 Aug 2003 10:38:17 -0700 From: David Brownell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: "David S. Miller" CC: greearb@candelatech.com, jgarzik@pobox.com, scott.feldman@intel.com, netdev@oss.sgi.com Subject: Re: e100 "Ferguson" release References: <3F2CA65F.8060105@pobox.com> <3F2CBA71.2070503@candelatech.com> <20030803003239.4257ef24.davem@redhat.com> <3F2DCE56.6030601@pacbell.net> <20030803200851.7d46a605.davem@redhat.com> <3F2DD6BD.7070504@pacbell.net> <20030803204642.684c6075.davem@redhat.com> <3F2DDC3A.2040707@pacbell.net> <20030803211333.12839f66.davem@redhat.com> In-Reply-To: <20030803211333.12839f66.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4542 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: > > For example, what do USB block device drivers do when -ENOMEM comes > back? Do they just drop the request on the floor? No, rather they > resubmit the request later without the scsi/block layer knowing > anything about what happened, right? I didn't notice any code to retry, but I did see some that morphed ENOMEM into a generic scsi "error". Scsi presumably does something more or less intelligent then. The network layer on the other hand _does_ have hooks for retrying, not that they're used much. - Dave From scott.feldman@intel.com Tue Aug 5 08:19:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 08:19:39 -0700 (PDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h75FJWFl013136 for ; Tue, 5 Aug 2003 08:19:32 -0700 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h75FHKw28917 for ; Tue, 5 Aug 2003 15:17:20 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h75FERc21323 for ; Tue, 5 Aug 2003 15:14:27 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003080508192629015 ; Tue, 05 Aug 2003 08:19:26 -0700 Received: from orsmsx402.amr.corp.intel.com ([192.168.65.208]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Aug 2003 08:19:26 -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: e100 "Ferguson" release Date: Tue, 5 Aug 2003 08:19:25 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: e100 "Ferguson" release Thread-Index: AcNbKsmh/6+8q5R8RsOBg+Su6l5c9gANLF4Q From: "Feldman, Scott" To: "Felix Radensky" , "Ben Greear" Cc: "Jeff Garzik" , X-OriginalArrivalTime: 05 Aug 2003 15:19:26.0092 (UTC) FILETIME=[F4F2DCC0:01C35B64] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h75FJWFl013136 X-archive-position: 4543 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 > I've also noticed that the number of hard_start_xmit failures > in e1000 has increased significantly in version 5.1.13-k1. In > version 5.0.43-k1 the number of failures was much smaller. Interesting. Felix, would you undo the change[1] below in 5.1.13-k1 and see what happens? With the change below, 5.1.13 would be more aggressive on Tx cleanup, so we'll be quicker waking the queue than before. -scott for(i = 0; i < E1000_MAX_INTR; i++) - if(!e1000_clean_rx_irq(adapter) && + if(!e1000_clean_rx_irq(adapter) & !e1000_clean_tx_irq(adapter)) break; [1] Something still bothers me about this new form where we're mixing a bit-wise operator with logical operands. Should this bother me? From garzik@gtf.org Tue Aug 5 08:24:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 08:24:30 -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 h75FOOFl013723 for ; Tue, 5 Aug 2003 08:24:25 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id EBC946663; Tue, 5 Aug 2003 11:24:18 -0400 (EDT) Date: Tue, 5 Aug 2003 11:24:18 -0400 From: Jeff Garzik To: "Feldman, Scott" Cc: Felix Radensky , Ben Greear , netdev@oss.sgi.com Subject: Re: e100 "Ferguson" release Message-ID: <20030805152418.GB6695@gtf.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-archive-position: 4544 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev On Tue, Aug 05, 2003 at 08:19:25AM -0700, Feldman, Scott wrote: > > I've also noticed that the number of hard_start_xmit failures > > in e1000 has increased significantly in version 5.1.13-k1. In > > version 5.0.43-k1 the number of failures was much smaller. > > Interesting. Felix, would you undo the change[1] below in 5.1.13-k1 and > see what happens? With the change below, 5.1.13 would be more > aggressive on Tx cleanup, so we'll be quicker waking the queue than > before. > > -scott > > for(i = 0; i < E1000_MAX_INTR; i++) > - if(!e1000_clean_rx_irq(adapter) && > + if(!e1000_clean_rx_irq(adapter) & > !e1000_clean_tx_irq(adapter)) > break; > > [1] Something still bothers me about this new form where we're mixing a > bit-wise operator with logical operands. Should this bother me? It doesn't matter to the compiler if you make it explicit: unsigned int rx_work = e1000_clean_rx_irq(); unsigned int tx_work = e1000_clean_tx_irq(); if (!rx_work && !tx_work) break; From Robert.Olsson@data.slu.se Tue Aug 5 10:08:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 10:08:42 -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 h75H8UFl019597 for ; Tue, 5 Aug 2003 10:08:33 -0700 Received: (from robert@localhost) by robur.slu.se (8.9.3p2/8.9.3) id TAA27260; Tue, 5 Aug 2003 19:08:23 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16175.58503.134543.310459@robur.slu.se> Date: Tue, 5 Aug 2003 19:08:23 +0200 To: kuznet@ms2.inr.ac.ru Cc: davem@redhat.com, Robert.Olsson@data.slu.se, netdev@oss.sgi.com Subject: [PATCH] repairing rtcache killer In-Reply-To: <200308051340.RAA28267@dub.inr.ac.ru> References: <200308051340.RAA28267@dub.inr.ac.ru> X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 4545 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 kuznet@ms2.inr.ac.ru writes: > # Two serious and interesting mistakes were made in the patch of 2003-06-16. > # 1. Variance of hash chain turned out to be unexpectedly high, so truncation > # chain length at <=ip_rt_gc_elasticity results in strong growth of > # cache misses. Set the threshould to 2*ip_rt_gc_elasticity. > # And continue to think how to switch to mode when lots of cache > # entries are used once or twice, so truncation should be done at 1. Hello! I'll guess the setting was very much affected by DoS attacs discussion which indicated very different flowlenths compared to our actual measurement for Uppsala University which had 65 pkts per new DST entry. Proably due to the "new" applications and lots of students. For autotuning I think we can have help from a ratio of warm cache hits (in_hit) and misses (in_slow_tot) to set threshhold to trim hash chain lengths. Cheers. --ro From ebiederm@xmission.com Tue Aug 5 10:22:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 10:22:46 -0700 (PDT) Received: from frodo.biederman.org (ebiederm.dsl.xmission.com [166.70.28.69]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h75HMYFl020574 for ; Tue, 5 Aug 2003 10:22:34 -0700 Received: (from eric@localhost) by frodo.biederman.org (8.9.3/8.9.3) id LAA05791; Tue, 5 Aug 2003 11:19:09 -0600 To: Werner Almesberger Cc: Jeff Garzik , Nivedita Singhvi , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: TOE brain dump References: <20030802140444.E5798@almesberger.net> <3F2BF5C7.90400@us.ibm.com> <3F2C0C44.6020002@pobox.com> <20030802184901.G5798@almesberger.net> <20030804162433.L5798@almesberger.net> From: ebiederm@xmission.com (Eric W. Biederman) Date: 05 Aug 2003 11:19:09 -0600 In-Reply-To: <20030804162433.L5798@almesberger.net> Message-ID: Lines: 68 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4546 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ebiederm@xmission.com Precedence: bulk X-list: netdev Werner Almesberger writes: > Eric W. Biederman wrote: > > The optimized for low latency cases seem to have a strong > > market in clusters. > > Clusters have captive, no, _desperate_ customers ;-) And it > seems that people are just as happy putting MPI as their > transport on top of all those link-layer technologies. MPI is not a transport. It an interface like the Berkeley sockets layer. The semantics it wants right now are usually mapped to TCP/IP when used on an IP network. Though I suspect SCTP might be a better fit. But right now nothing in the IP stack is a particularly good fit. Right now there is a very strong feeling among most of the people using and developing on clusters that by and large what they are doing is not of interest to the general kernel community, and so has no chance of going in. So you see hack piled on top of hack piled on top of hack. Mostly I think the that is less true, at least if they can stand the process of severe code review and cleaning up their code. If we can put in code to scale the kernel to 64 processors. NIC drivers for fast interconnects and a few similar tweaks can't hurt either. But of course to get through the peer review process people need to understand what they are doing. > > There is one place in low latency communications that I can think > > of where TCP/IP is not the proper solution. For low latency > > communication the checksum is at the wrong end of the packet. > > That's one of the few things ATM's AAL5 got right. But in the end, > I think it doesn't really matter. At 1 Gbps, an MTU-sized packet > flies by within 13 us. At 10 Gbps, it's only 1.3 us. At that point, > you may well treat it as an atomic unit. So store and forward of packets in a 3 layer switch hierarchy, at 1.3 us per copy. 1.3us to the NIC + 1.3us to the first switch chip + 1.3us to the second switch chip + 1.3us to the top level switch chip + 1.3us to a middle layer switch chip + 1.3us to the receiving NIC + 1.3us the receiver. 1.3us * 7 = 9.1us to deliver a packet to the other side. That is still quite painful. Right now I can get better latencies over any of the cluster interconnects. I think 5 us is the current low end, with the high end being about 1 us. Quite often in MPI when a message is sent the program cannot continue until the reply is received. Possibly this is a fundamental problem with the application programming model, encouraging applications to be latency sensitive. But it is a well established API and programming paradigm so it has to be lived with. All of this is pretty much the reverse of the TOE case. Things are latency sensitive because real work needs to be done. And the more latency you have the slower that work gets done. A lot of the NICs which are used for MPI tend to be smart for two reasons. 1) So they can do source routing. 2) So they can safely export some of their interface to user space, so in the fast path they can bypass the kernel. Eric From ebiederm@xmission.com Tue Aug 5 10:29:21 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 10:29:26 -0700 (PDT) Received: from frodo.biederman.org (ebiederm.dsl.xmission.com [166.70.28.69]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h75HTLFl021304 for ; Tue, 5 Aug 2003 10:29:21 -0700 Received: (from eric@localhost) by frodo.biederman.org (8.9.3/8.9.3) id LAA05837; Tue, 5 Aug 2003 11:25:57 -0600 To: "David S. Miller" Cc: Werner Almesberger jgarzik@pobox.com, niv@us.ibm.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: TOE brain dump References: <20030802140444.E5798@almesberger.net> <3F2BF5C7.90400@us.ibm.com> <3F2C0C44.6020002@pobox.com> <20030802184901.G5798@almesberger.net> <20030804162433.L5798@almesberger.net> <20030804122632.65ba2122.davem@redhat.com> From: ebiederm@xmission.com (Eric W. Biederman) Date: 05 Aug 2003 11:25:57 -0600 In-Reply-To: <20030804122632.65ba2122.davem@redhat.com> Message-ID: Lines: 48 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4547 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ebiederm@xmission.com Precedence: bulk X-list: netdev "David S. Miller" writes: > On Mon, 4 Aug 2003 16:24:33 -0300 > Werner Almesberger wrote: > > > Eric W. Biederman wrote: > > > There is one place in low latency communications that I can think > > > of where TCP/IP is not the proper solution. For low latency > > > communication the checksum is at the wrong end of the packet. > > > > That's one of the few things ATM's AAL5 got right. > > Let's recall how long the IFF_TRAILERS hack from BSD :-) Putting the variable length headers on the end of a packet? Or was that something other than RFC893? I think IPv6 solves that much more cleanly by simply deleting them. > > But in the end, I think it doesn't really matter. > > I tend to agree on this one. > > And on the transmit side if you have more than 1 pending TX frame, you > can always be prefetching the next one into the fifo so that by the > time the medium is ready all the checksum bits have been done. For large data transmissions that happens. > In fact I'd be surprised if current generation 1g/10g cards are not > doing something like this. Well at this point before I propose anything concrete I suspect I need to profile some actual application and see how things go. But from a very latency sensitive perspective, I would be surprised if the problem goes away with faster technology. For now I am happy just to insert the peculiar thought that latency across the entire cluster/lan is of great importance to some applications. Eric From ingo.oeser@informatik.tu-chemnitz.de Tue Aug 5 10:33:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 10:33:54 -0700 (PDT) Received: from meg.hrz.tu-chemnitz.de (meg.hrz.tu-chemnitz.de [134.109.132.57]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h75HXmFl021963 for ; Tue, 5 Aug 2003 10:33:50 -0700 Received: from tnt188.hrz.tu-chemnitz.de ([134.109.156.188] helo=nightmaster.csn.tu-chemnitz.de ident=root) by meg.hrz.tu-chemnitz.de with esmtp (Exim 4.12) id 19jhum-0003rB-00; Mon, 04 Aug 2003 18:10:30 +0200 Received: (from ioe@localhost) by nightmaster.csn.tu-chemnitz.de (8.9.1/8.9.1) id QAA23195; Mon, 4 Aug 2003 16:36:06 +0200 Date: Mon, 4 Aug 2003 16:36:06 +0200 From: Ingo Oeser To: Jeff Garzik Cc: Nivedita Singhvi , Werner Almesberger , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: TOE brain dump Message-ID: <20030804163606.Q639@nightmaster.csn.tu-chemnitz.de> References: <20030802140444.E5798@almesberger.net> <3F2BF5C7.90400@us.ibm.com> <3F2C0C44.6020002@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3F2C0C44.6020002@pobox.com>; from jgarzik@pobox.com on Sat, Aug 02, 2003 at 03:08:52PM -0400 X-Spam-Score: -5.0 (-----) X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *19jhum-0003rB-00*vFn3hP0u2Ks* X-archive-position: 4548 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ingo.oeser@informatik.tu-chemnitz.de Precedence: bulk X-list: netdev Hi Jeff, On Sat, Aug 02, 2003 at 03:08:52PM -0400, Jeff Garzik wrote: > So, fix the other end of the pipeline too, otherwise this fast network > stuff is flashly but pointless. If you want to serve up data from disk, > then start creating PCI cards that have both Serial ATA and ethernet > connectors on them :) Cut out the middleman of the host CPU and host > memory bus instead of offloading portions of TCP that do not need to be > offloaded. Exactly what I suggested: sys_ioroute() "Providing generic pipelines and io routing as Linux service" Msg-ID: <20030718134235.K639@nightmaster.csn.tu-chemnitz.de> on linux-kernel and linux-fsdevel Be my guest. I know, that you mean doing it in hardware, but you cannot accelerate sth. which the kernel doesn't do ;-) Regards Ingo Oeser From miller@techsource.com Tue Aug 5 12:15:39 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 12:15:50 -0700 (PDT) Received: from kinesis.swishmail.com (qmailr@kinesis.swishmail.com [209.10.110.86]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h75JFcFl028716 for ; Tue, 5 Aug 2003 12:15:39 -0700 Received: (qmail 42158 invoked by uid 89); 5 Aug 2003 19:15:37 -0000 Received: from unknown (HELO techsource.com) (209.208.48.130) by kinesis.swishmail.com with SMTP; 5 Aug 2003 19:15:37 -0000 Message-ID: <3F300549.60800@techsource.com> Date: Tue, 05 Aug 2003 15:28:09 -0400 From: Timothy Miller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Larry McVoy CC: David Lang , Erik Andersen , Werner Almesberger , Jeff Garzik , netdev@oss.sgi.com, linux-kernel@vger.kernel.org, Nivedita Singhvi Subject: Re: TOE brain dump References: <20030803194011.GA8324@work.bitmover.com> <20030803203051.GA9057@work.bitmover.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4549 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: miller@techsource.com Precedence: bulk X-list: netdev Larry McVoy wrote: > On Sun, Aug 03, 2003 at 01:13:24PM -0700, David Lang wrote: > >>2. router nodes that have access to main memory (PCI card running linux >>acting as a router/firewall/VPN to offload the main CPU's) > > > I can get an entire machine, memory, disk, > Ghz CPU, case, power supply, > cdrom, floppy, onboard enet extra net card for routing, for $250 or less, > quantity 1, shipped to my door. > > Why would I want to spend money on some silly offload card when I can get > the whole PC for less than the card? Physical space? Power usage? Heat dissipation? Optimization for the specific task? Fast, low latency communication between CPU and device (ie. local bus)? Maintenance? Lots of reasons why one might pay more for the offload card. If you're cheap, you'll just use the software stack and a $10 NIC and just live with the corresponding CPU usage. If you're a performance freak, you'll spend whatever you have to to squeeze out every last bit of performance you can. Mind you, another option is, if you're dealing with the kind of load that requires that much network performance, is to use redundant servers, like google. No one server is exceptionally fast, but it not many people are using it, it's fast enough. From shemminger@osdl.org Tue Aug 5 14:46:38 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 14:46:44 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h75LkbFl005904 for ; Tue, 5 Aug 2003 14:46:37 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h75LkNI01529; Tue, 5 Aug 2003 14:46:23 -0700 Date: Tue, 5 Aug 2003 14:46:22 -0700 From: Stephen Hemminger To: Ralf Baechle , "David S. Miller" Cc: linux-hams@vger.kernel.org, netdev@oss.sgi.com Subject: [PATCH] (2/2) Convert ROSE to seq_file Message-Id: <20030805144622.100f208d.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.3claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4551 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev The existing ROSE /proc interface has no module owner, and doesn't check for bounds overflow. Easier to just convert it to the seq_file wrapper functions. This patch is against 2.6.0-test2 (offsets assume earlier patch). diff -Nru a/include/net/rose.h b/include/net/rose.h --- a/include/net/rose.h Tue Aug 5 14:36:07 2003 +++ b/include/net/rose.h Tue Aug 5 14:36:07 2003 @@ -140,6 +140,9 @@ #define rose_sk(__sk) ((rose_cb *)(__sk)->sk_protinfo) +/* Magic value indicating first entry in /proc (ie header) */ +#define ROSE_PROC_START ((void *) 1) + /* af_rose.c */ extern ax25_address rose_callsign; extern int sysctl_rose_restart_request_timeout; @@ -154,7 +157,7 @@ extern int sysctl_rose_window_size; extern int rosecmp(rose_address *, rose_address *); extern int rosecmpm(rose_address *, rose_address *, unsigned short); -extern char *rose2asc(rose_address *); +extern const char *rose2asc(const rose_address *); extern struct sock *rose_find_socket(unsigned int, struct rose_neigh *); extern void rose_kill_by_neigh(struct rose_neigh *); extern unsigned int rose_new_lci(struct rose_neigh *); @@ -193,6 +196,9 @@ /* rose_route.c */ extern struct rose_neigh *rose_loopback_neigh; +extern struct file_operations rose_neigh_fops; +extern struct file_operations rose_nodes_fops; +extern struct file_operations rose_routes_fops; extern int rose_add_loopback_neigh(void); extern int rose_add_loopback_node(rose_address *); @@ -207,9 +213,6 @@ extern int rose_rt_ioctl(unsigned int, void *); extern void rose_link_failed(ax25_cb *, int); extern int rose_route_frame(struct sk_buff *, ax25_cb *); -extern int rose_nodes_get_info(char *, char **, off_t, int); -extern int rose_neigh_get_info(char *, char **, off_t, int); -extern int rose_routes_get_info(char *, char **, off_t, int); extern void rose_rt_free(void); /* rose_subr.c */ diff -Nru a/net/rose/af_rose.c b/net/rose/af_rose.c --- a/net/rose/af_rose.c Tue Aug 5 14:36:07 2003 +++ b/net/rose/af_rose.c Tue Aug 5 14:36:07 2003 @@ -39,6 +39,7 @@ #include #include #include +#include #include #include #include @@ -56,8 +57,8 @@ int sysctl_rose_maximum_vcs = ROSE_DEFAULT_MAXVC; int sysctl_rose_window_size = ROSE_DEFAULT_WINDOW_SIZE; -static HLIST_HEAD(rose_list); -static spinlock_t rose_list_lock = SPIN_LOCK_UNLOCKED; +HLIST_HEAD(rose_list); +spinlock_t rose_list_lock = SPIN_LOCK_UNLOCKED; static struct proto_ops rose_proto_ops; @@ -66,7 +67,7 @@ /* * Convert a ROSE address into text. */ -char *rose2asc(rose_address *addr) +const char *rose2asc(const rose_address *addr) { static char buffer[11]; @@ -1332,29 +1333,57 @@ return 0; } -static int rose_get_info(char *buffer, char **start, off_t offset, int length) +#ifdef CONFIG_PROC_FS +static void *rose_info_start(struct seq_file *seq, loff_t *pos) { + int i; struct sock *s; struct hlist_node *node; - struct net_device *dev; - const char *devname, *callsign; - int len = 0; - off_t pos = 0; - off_t begin = 0; spin_lock_bh(&rose_list_lock); + if (*pos == 0) + return ROSE_PROC_START; + + i = 1; + sk_for_each(s, node, &rose_list) { + if (i == *pos) + return s; + ++i; + } + return NULL; +} - len += sprintf(buffer, "dest_addr dest_call src_addr src_call dev lci neigh st vs vr va t t1 t2 t3 hb idle Snd-Q Rcv-Q inode\n"); +static void *rose_info_next(struct seq_file *seq, void *v, loff_t *pos) +{ + ++*pos; - sk_for_each(s, node, &rose_list) { + return (v == ROSE_PROC_START) ? sk_head(&rose_list) + : sk_next((struct sock *)v); +} + +static void rose_info_stop(struct seq_file *seq, void *v) +{ + spin_unlock_bh(&rose_list_lock); +} + +static int rose_info_show(struct seq_file *seq, void *v) +{ + if (v == ROSE_PROC_START) + seq_puts(seq, + "dest_addr dest_call src_addr src_call dev lci neigh st vs vr va t t1 t2 t3 hb idle Snd-Q Rcv-Q inode\n"); + + else { + struct sock *s = v; rose_cb *rose = rose_sk(s); + const char *devname, *callsign; + const struct net_device *dev = rose->device; - if ((dev = rose->device) == NULL) + if (!dev) devname = "???"; else devname = dev->name; - - len += sprintf(buffer + len, "%-10s %-9s ", + + seq_printf(seq, "%-10s %-9s ", rose2asc(&rose->dest_addr), ax2asc(&rose->dest_call)); @@ -1363,7 +1392,8 @@ else callsign = ax2asc(&rose->source_call); - len += sprintf(buffer + len, "%-10s %-9s %-5s %3.3X %05d %d %d %d %d %3lu %3lu %3lu %3lu %3lu %3lu/%03lu %5d %5d %ld\n", + seq_printf(seq, + "%-10s %-9s %-5s %3.3X %05d %d %d %d %d %3lu %3lu %3lu %3lu %3lu %3lu/%03lu %5d %5d %ld\n", rose2asc(&rose->source_addr), callsign, devname, @@ -1383,27 +1413,32 @@ atomic_read(&s->sk_wmem_alloc), atomic_read(&s->sk_rmem_alloc), s->sk_socket ? SOCK_INODE(s->sk_socket)->i_ino : 0L); - - pos = begin + len; - - if (pos < offset) { - len = 0; - begin = pos; - } - - if (pos > offset + length) - break; } - spin_unlock_bh(&rose_list_lock); - *start = buffer + (offset - begin); - len -= (offset - begin); + return 0; +} - if (len > length) len = length; +static struct seq_operations rose_info_seqops = { + .start = rose_info_start, + .next = rose_info_next, + .stop = rose_info_stop, + .show = rose_info_show, +}; - return len; +static int rose_info_open(struct inode *inode, struct file *file) +{ + return seq_open(file, &rose_info_seqops); } +static struct file_operations rose_info_fops = { + .owner = THIS_MODULE, + .open = rose_info_open, + .read = seq_read, + .llseek = seq_lseek, + .release = seq_release, +}; +#endif /* CONFIG_PROC_FS */ + static struct net_proto_family rose_family_ops = { .family = PF_ROSE, .create = rose_create, @@ -1499,10 +1534,11 @@ rose_add_loopback_neigh(); - proc_net_create("rose", 0, rose_get_info); - proc_net_create("rose_neigh", 0, rose_neigh_get_info); - proc_net_create("rose_nodes", 0, rose_nodes_get_info); - proc_net_create("rose_routes", 0, rose_routes_get_info); + proc_net_fops_create("rose", S_IRUGO, &rose_info_fops); + proc_net_fops_create("rose_neigh", S_IRUGO, &rose_neigh_fops); + proc_net_fops_create("rose_nodes", S_IRUGO, &rose_nodes_fops); + proc_net_fops_create("rose_routes", S_IRUGO, &rose_routes_fops); + return 0; } module_init(rose_proto_init); diff -Nru a/net/rose/rose_route.c b/net/rose/rose_route.c --- a/net/rose/rose_route.c Tue Aug 5 14:36:07 2003 +++ b/net/rose/rose_route.c Tue Aug 5 14:36:07 2003 @@ -35,12 +35,13 @@ #include #include #include +#include static unsigned int rose_neigh_no = 1; static struct rose_node *rose_node_list; static spinlock_t rose_node_list_lock = SPIN_LOCK_UNLOCKED; -static struct rose_neigh *rose_neigh_list; +struct rose_neigh *rose_neigh_list; static spinlock_t rose_neigh_list_lock = SPIN_LOCK_UNLOCKED; static struct rose_route *rose_route_list; static spinlock_t rose_route_list_lock = SPIN_LOCK_UNLOCKED; @@ -1066,165 +1067,248 @@ return res; } -int rose_nodes_get_info(char *buffer, char **start, off_t offset, int length) +#ifdef CONFIG_PROC_FS + +static void *rose_node_start(struct seq_file *seq, loff_t *pos) { struct rose_node *rose_node; - int len = 0; - off_t pos = 0; - off_t begin = 0; - int i; + int i = 1; spin_lock_bh(&rose_neigh_list_lock); + if (*pos == 0) + return ROSE_PROC_START; + + for (rose_node = rose_node_list; rose_node && i < *pos; + rose_node = rose_node->next, ++i); + + return (i == *pos) ? rose_node : NULL; +} - len += sprintf(buffer, "address mask n neigh neigh neigh\n"); +static void *rose_node_next(struct seq_file *seq, void *v, loff_t *pos) +{ + ++*pos; + + return (v == ROSE_PROC_START) ? rose_node_list + : ((struct rose_node *)v)->next; +} - for (rose_node = rose_node_list; rose_node != NULL; rose_node = rose_node->next) { +static void rose_node_stop(struct seq_file *seq, void *v) +{ + spin_unlock_bh(&rose_neigh_list_lock); +} + +static int rose_node_show(struct seq_file *seq, void *v) +{ + int i; + + if (v == ROSE_PROC_START) + seq_puts(seq, "address mask n neigh neigh neigh\n"); + else { + const struct rose_node *rose_node = v; /* if (rose_node->loopback) { - len += sprintf(buffer + len, "%-10s %04d 1 loopback\n", + seq_printf(seq, "%-10s %04d 1 loopback\n", rose2asc(&rose_node->address), rose_node->mask); } else { */ - len += sprintf(buffer + len, "%-10s %04d %d", + seq_printf(seq, "%-10s %04d %d", rose2asc(&rose_node->address), rose_node->mask, rose_node->count); for (i = 0; i < rose_node->count; i++) - len += sprintf(buffer + len, " %05d", + seq_printf(seq, " %05d", rose_node->neighbour[i]->number); - len += sprintf(buffer + len, "\n"); + seq_puts(seq, "\n"); /* } */ + } + return 0; +} - pos = begin + len; +static struct seq_operations rose_node_seqops = { + .start = rose_node_start, + .next = rose_node_next, + .stop = rose_node_stop, + .show = rose_node_show, +}; + +static int rose_nodes_open(struct inode *inode, struct file *file) +{ + return seq_open(file, &rose_node_seqops); +} + +struct file_operations rose_nodes_fops = { + .owner = THIS_MODULE, + .open = rose_nodes_open, + .read = seq_read, + .llseek = seq_lseek, + .release = seq_release, +}; - if (pos < offset) { - len = 0; - begin = pos; - } +static void *rose_neigh_start(struct seq_file *seq, loff_t *pos) +{ + struct rose_neigh *rose_neigh; + int i = 1; - if (pos > offset + length) - break; - } - spin_unlock_bh(&rose_neigh_list_lock); + spin_lock_bh(&rose_neigh_list_lock); + if (*pos == 0) + return ROSE_PROC_START; - *start = buffer + (offset - begin); - len -= (offset - begin); + for (rose_neigh = rose_neigh_list; rose_neigh && i < *pos; + rose_neigh = rose_neigh->next, ++i); - if (len > length) - len = length; + return (i == *pos) ? rose_neigh : NULL; +} - return len; +static void *rose_neigh_next(struct seq_file *seq, void *v, loff_t *pos) +{ + ++*pos; + + return (v == ROSE_PROC_START) ? rose_neigh_list + : ((struct rose_neigh *)v)->next; } -int rose_neigh_get_info(char *buffer, char **start, off_t offset, int length) +static void rose_neigh_stop(struct seq_file *seq, void *v) { - struct rose_neigh *rose_neigh; - int len = 0; - off_t pos = 0; - off_t begin = 0; - int i; + spin_unlock_bh(&rose_neigh_list_lock); +} - spin_lock_bh(&rose_neigh_list_lock); +static int rose_neigh_show(struct seq_file *seq, void *v) +{ + int i; - len += sprintf(buffer, "addr callsign dev count use mode restart t0 tf digipeaters\n"); + if (v == ROSE_PROC_START) + seq_puts(seq, + "addr callsign dev count use mode restart t0 tf digipeaters\n"); + else { + struct rose_neigh *rose_neigh = v; - for (rose_neigh = rose_neigh_list; rose_neigh != NULL; rose_neigh = rose_neigh->next) { /* if (!rose_neigh->loopback) { */ - len += sprintf(buffer + len, "%05d %-9s %-4s %3d %3d %3s %3s %3lu %3lu", - rose_neigh->number, - (rose_neigh->loopback) ? "RSLOOP-0" : ax2asc(&rose_neigh->callsign), - rose_neigh->dev ? rose_neigh->dev->name : "???", - rose_neigh->count, - rose_neigh->use, - (rose_neigh->dce_mode) ? "DCE" : "DTE", - (rose_neigh->restarted) ? "yes" : "no", - ax25_display_timer(&rose_neigh->t0timer) / HZ, - ax25_display_timer(&rose_neigh->ftimer) / HZ); - - if (rose_neigh->digipeat != NULL) { - for (i = 0; i < rose_neigh->digipeat->ndigi; i++) - len += sprintf(buffer + len, " %s", ax2asc(&rose_neigh->digipeat->calls[i])); - } - - len += sprintf(buffer + len, "\n"); - - pos = begin + len; - - if (pos < offset) { - len = 0; - begin = pos; - } + seq_printf(seq, "%05d %-9s %-4s %3d %3d %3s %3s %3lu %3lu", + rose_neigh->number, + (rose_neigh->loopback) ? "RSLOOP-0" : ax2asc(&rose_neigh->callsign), + rose_neigh->dev ? rose_neigh->dev->name : "???", + rose_neigh->count, + rose_neigh->use, + (rose_neigh->dce_mode) ? "DCE" : "DTE", + (rose_neigh->restarted) ? "yes" : "no", + ax25_display_timer(&rose_neigh->t0timer) / HZ, + ax25_display_timer(&rose_neigh->ftimer) / HZ); + + if (rose_neigh->digipeat != NULL) { + for (i = 0; i < rose_neigh->digipeat->ndigi; i++) + seq_printf(seq, " %s", ax2asc(&rose_neigh->digipeat->calls[i])); + } - if (pos > offset + length) - break; - /* } */ + seq_puts(seq, "\n"); } + return 0; +} - spin_unlock_bh(&rose_neigh_list_lock); - - *start = buffer + (offset - begin); - len -= (offset - begin); - if (len > length) - len = length; +static struct seq_operations rose_neigh_seqops = { + .start = rose_neigh_start, + .next = rose_neigh_next, + .stop = rose_neigh_stop, + .show = rose_neigh_show, +}; - return len; +static int rose_neigh_open(struct inode *inode, struct file *file) +{ + return seq_open(file, &rose_neigh_seqops); } -int rose_routes_get_info(char *buffer, char **start, off_t offset, int length) +struct file_operations rose_neigh_fops = { + .owner = THIS_MODULE, + .open = rose_neigh_open, + .read = seq_read, + .llseek = seq_lseek, + .release = seq_release, +}; + + +static void *rose_route_start(struct seq_file *seq, loff_t *pos) { struct rose_route *rose_route; - int len = 0; - off_t pos = 0; - off_t begin = 0; + int i = 1; spin_lock_bh(&rose_route_list_lock); + if (*pos == 0) + return ROSE_PROC_START; - len += sprintf(buffer, "lci address callsign neigh <-> lci address callsign neigh\n"); + for (rose_route = rose_route_list; rose_route && i < *pos; + rose_route = rose_route->next, ++i); - for (rose_route = rose_route_list; rose_route != NULL; rose_route = rose_route->next) { - if (rose_route->neigh1 != NULL) { - len += sprintf(buffer + len, "%3.3X %-10s %-9s %05d ", - rose_route->lci1, - rose2asc(&rose_route->src_addr), - ax2asc(&rose_route->src_call), - rose_route->neigh1->number); - } else { - len += sprintf(buffer + len, "000 * * 00000 "); - } + return (i == *pos) ? rose_route : NULL; +} + +static void *rose_route_next(struct seq_file *seq, void *v, loff_t *pos) +{ + ++*pos; + + return (v == ROSE_PROC_START) ? rose_route_list + : ((struct rose_route *)v)->next; +} - if (rose_route->neigh2 != NULL) { - len += sprintf(buffer + len, "%3.3X %-10s %-9s %05d\n", +static void rose_route_stop(struct seq_file *seq, void *v) +{ + spin_unlock_bh(&rose_route_list_lock); +} + +static int rose_route_show(struct seq_file *seq, void *v) +{ + if (v == ROSE_PROC_START) + seq_puts(seq, + "lci address callsign neigh <-> lci address callsign neigh\n"); + else { + struct rose_route *rose_route = v; + + if (rose_route->neigh1) + seq_printf(seq, + "%3.3X %-10s %-9s %05d ", + rose_route->lci1, + rose2asc(&rose_route->src_addr), + ax2asc(&rose_route->src_call), + rose_route->neigh1->number); + else + seq_puts(seq, + "000 * * 00000 "); + + if (rose_route->neigh2) + seq_printf(seq, + "%3.3X %-10s %-9s %05d\n", rose_route->lci2, rose2asc(&rose_route->dest_addr), ax2asc(&rose_route->dest_call), rose_route->neigh2->number); - } else { - len += sprintf(buffer + len, "000 * * 00000\n"); - } - - pos = begin + len; - - if (pos < offset) { - len = 0; - begin = pos; + else + seq_puts(seq, + "000 * * 00000\n"); } + return 0; +} - if (pos > offset + length) - break; - } - - spin_unlock_bh(&rose_route_list_lock); - - *start = buffer + (offset - begin); - len -= (offset - begin); - - if (len > length) - len = length; +static struct seq_operations rose_route_seqops = { + .start = rose_route_start, + .next = rose_route_next, + .stop = rose_route_stop, + .show = rose_route_show, +}; + +static int rose_route_open(struct inode *inode, struct file *file) +{ + return seq_open(file, &rose_route_seqops); +} + +struct file_operations rose_routes_fops = { + .owner = THIS_MODULE, + .open = rose_route_open, + .read = seq_read, + .llseek = seq_lseek, + .release = seq_release, +}; - return len; -} +#endif /* CONFIG_PROC_FS */ /* * Release all memory associated with ROSE routing structures. From shemminger@osdl.org Tue Aug 5 14:46:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 14:46:44 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h75LkYFl005901 for ; Tue, 5 Aug 2003 14:46:35 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h75LkHI01525; Tue, 5 Aug 2003 14:46:18 -0700 Date: Tue, 5 Aug 2003 14:46:17 -0700 From: Stephen Hemminger To: Ralf Baechle , "David S. Miller" Cc: linux-hams@vger.kernel.org, netdev@oss.sgi.com Subject: [PATCH 2.6.0-test2] (1/2) Dynamically allocate net_device structures for ROSE Message-Id: <20030805144617.2e856d6d.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.3claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4550 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev This patch changes the ROSE protocol to allocate an array of pointers and each network device separately. This sets up later change where network_device object's are released on last use which may be after the module is unloaded. The patch is against 2.6.0-test2 (though this code hasn't changed in a long time). Allocation is done via alloc_netdev so the dev->priv area is already reserved and doesn't need to be allocated separately. diff -Nru a/include/net/rose.h b/include/net/rose.h --- a/include/net/rose.h Tue Aug 5 14:35:52 2003 +++ b/include/net/rose.h Tue Aug 5 14:35:52 2003 @@ -163,7 +163,7 @@ /* rose_dev.c */ extern int rose_rx_ip(struct sk_buff *, struct net_device *); -extern int rose_init(struct net_device *); +extern void rose_setup(struct net_device *); /* rose_in.c */ extern int rose_process_rx_frame(struct sock *, struct sk_buff *); diff -Nru a/net/rose/af_rose.c b/net/rose/af_rose.c --- a/net/rose/af_rose.c Tue Aug 5 14:35:52 2003 +++ b/net/rose/af_rose.c Tue Aug 5 14:35:52 2003 @@ -43,7 +43,7 @@ #include #include -int rose_ndevs = 10; +static int rose_ndevs = 10; int sysctl_rose_restart_request_timeout = ROSE_DEFAULT_T0; int sysctl_rose_call_request_timeout = ROSE_DEFAULT_T1; @@ -56,7 +56,7 @@ int sysctl_rose_maximum_vcs = ROSE_DEFAULT_MAXVC; int sysctl_rose_window_size = ROSE_DEFAULT_WINDOW_SIZE; -HLIST_HEAD(rose_list); +static HLIST_HEAD(rose_list); static spinlock_t rose_list_lock = SPIN_LOCK_UNLOCKED; static struct proto_ops rose_proto_ops; @@ -1435,7 +1435,7 @@ .notifier_call = rose_device_event, }; -static struct net_device *dev_rose; +static struct net_device **dev_rose; static const char banner[] = KERN_INFO "F6FBB/G4KLX ROSE for Linux. Version 0.62 for AX25.037 Linux 2.4\n"; @@ -1450,17 +1450,39 @@ return -1; } - if ((dev_rose = kmalloc(rose_ndevs * sizeof(struct net_device), GFP_KERNEL)) == NULL) { + dev_rose = kmalloc(rose_ndevs * sizeof(struct net_device *), GFP_KERNEL); + if (dev_rose == NULL) { printk(KERN_ERR "ROSE: rose_proto_init - unable to allocate device structure\n"); return -1; } - memset(dev_rose, 0x00, rose_ndevs * sizeof(struct net_device)); + memset(dev_rose, 0x00, rose_ndevs * sizeof(struct net_device*)); + for (i = 0; i < rose_ndevs; i++) { + struct net_device *dev; + char name[IFNAMSIZ]; + + sprintf(name, "rose%d", i); + dev = alloc_netdev(sizeof(struct net_device_stats), + name, rose_setup); + if (!dev) { + printk(KERN_ERR "ROSE: rose_proto_init - unable to allocate memory\n"); + while (--i >= 0) + kfree(dev_rose[i]); + return -ENOMEM; + } + dev_rose[i] = dev; + } for (i = 0; i < rose_ndevs; i++) { - sprintf(dev_rose[i].name, "rose%d", i); - dev_rose[i].init = rose_init; - register_netdev(&dev_rose[i]); + if (register_netdev(dev_rose[i])) { + printk(KERN_ERR "ROSE: netdevice regeistration failed\n"); + while (--i >= 0) { + unregister_netdev(dev_rose[i]); + kfree(dev_rose[i]); + return -EIO; + } + } + } sock_register(&rose_family_ops); @@ -1518,10 +1540,11 @@ sock_unregister(PF_ROSE); for (i = 0; i < rose_ndevs; i++) { - if (dev_rose[i].priv != NULL) { - kfree(dev_rose[i].priv); - dev_rose[i].priv = NULL; - unregister_netdev(&dev_rose[i]); + struct net_device *dev = dev_rose[i]; + + if (dev) { + unregister_netdev(dev); + kfree(dev); } } diff -Nru a/net/rose/rose_dev.c b/net/rose/rose_dev.c --- a/net/rose/rose_dev.c Tue Aug 5 14:35:52 2003 +++ b/net/rose/rose_dev.c Tue Aug 5 14:35:52 2003 @@ -165,7 +165,7 @@ return (struct net_device_stats *)dev->priv; } -int rose_init(struct net_device *dev) +void rose_setup(struct net_device *dev) { SET_MODULE_OWNER(dev); dev->mtu = ROSE_MAX_PACKET_SIZE - 2; @@ -182,13 +182,5 @@ /* New-style flags. */ dev->flags = 0; - - if ((dev->priv = kmalloc(sizeof(struct net_device_stats), GFP_KERNEL)) == NULL) - return -ENOMEM; - - memset(dev->priv, 0, sizeof(struct net_device_stats)); - dev->get_stats = rose_get_stats; - - return 0; -}; +} From shemminger@osdl.org Tue Aug 5 14:57:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 14:57:23 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h75LvFFl007116 for ; Tue, 5 Aug 2003 14:57:16 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h75LuwI03721; Tue, 5 Aug 2003 14:56:58 -0700 Date: Tue, 5 Aug 2003 14:56:58 -0700 From: Stephen Hemminger To: Ralf Baechle , "David S. Miller" Cc: linux-hams@vger.kernel.org, netdev@oss.sgi.com Subject: [PATCH] Fix use after free in AX.25 Message-Id: <20030805145658.1b3f194b.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.3claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4552 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev This patch is against 2.6.0-test2. The problem is that the ax25_destroy_socket function frees the socket buffer, but then ax25_release dereferences this causing an OOPS. To reproduce: modprobe ax25; ifconfig -a Replaced sk_free with sock_put which will free if this is the last reference. diff -urNp -X dontdiff net-2.5/net/ax25/af_ax25.c linux-2.5-net/net/ax25/af_ax25.c --- net-2.5/net/ax25/af_ax25.c 2003-08-04 09:32:21.000000000 -0700 +++ linux-2.5-net/net/ax25/af_ax25.c 2003-08-05 14:34:21.000000000 -0700 @@ -349,7 +349,7 @@ void ax25_destroy_socket(ax25_cb *ax25) ax25->timer.data = (unsigned long)ax25; add_timer(&ax25->timer); } else { - sk_free(ax25->sk); + sock_put(ax25->sk); } } else { ax25_free_cb(ax25); @@ -944,15 +944,13 @@ static int ax25_release(struct socket *s switch (ax25->state) { case AX25_STATE_0: ax25_disconnect(ax25, 0); - ax25_destroy_socket(ax25); - break; + goto drop; case AX25_STATE_1: case AX25_STATE_2: ax25_send_control(ax25, AX25_DISC, AX25_POLLON, AX25_COMMAND); ax25_disconnect(ax25, 0); - ax25_destroy_socket(ax25); - break; + goto drop; case AX25_STATE_3: case AX25_STATE_4: @@ -995,13 +993,16 @@ static int ax25_release(struct socket *s sk->sk_shutdown |= SEND_SHUTDOWN; sk->sk_state_change(sk); sock_set_flag(sk, SOCK_DEAD); - ax25_destroy_socket(ax25); + goto drop; } sock->sk = NULL; sk->sk_socket = NULL; /* Not used, but we should do this */ release_sock(sk); - + return 0; + drop: + release_sock(sk); + ax25_destroy_socket(ax25); return 0; } From shemminger@osdl.org Tue Aug 5 15:01:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 15:01:30 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h75M1QFl007706 for ; Tue, 5 Aug 2003 15:01:26 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h75M1AI04456; Tue, 5 Aug 2003 15:01:10 -0700 Date: Tue, 5 Aug 2003 15:01:10 -0700 From: Stephen Hemminger To: Henner Eisen , "David S. Miller" Cc: linux-x25@vger.kernel.org, netdev@oss.sgi.com Subject: [PATCH] Fix X.25 use after free. Message-Id: <20030805150110.0e2753ab.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.3claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4553 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev The conversion from cli/sti to locking in X.25 must not have been tested on a real SMP with memory debugging enabled. It OOPS right away if I do: modprobe x25; ifconfig -a The problem is that it dereferences the socket after it has already been freed. The fix for this is to make the call to sock_put, later in x25_destroy_socket do the free. Also, need a go to avoid references in x25_release. This patch is against 2.6.0-test2. diff -urNp -X dontdiff net-2.5/net/x25/af_x25.c linux-2.5-net/net/x25/af_x25.c --- net-2.5/net/x25/af_x25.c 2003-08-01 11:12:02.000000000 -0700 +++ linux-2.5-net/net/x25/af_x25.c 2003-08-05 12:14:42.000000000 -0700 @@ -350,8 +350,11 @@ void x25_destroy_socket(struct sock *sk) sk->sk_timer.function = x25_destroy_timer; sk->sk_timer.data = (unsigned long)sk; add_timer(&sk->sk_timer); - } else - sk_free(sk); + } else { + /* drop last reference so sock_put will free */ + __sock_put(sk); + } + release_sock(sk); sock_put(sk); } @@ -553,7 +556,7 @@ static int x25_release(struct socket *so case X25_STATE_2: x25_disconnect(sk, 0, 0, 0); x25_destroy_socket(sk); - break; + goto out; case X25_STATE_1: case X25_STATE_3: From felix@allot.com Tue Aug 5 15:14:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 15:14:49 -0700 (PDT) Received: from mxout1.netvision.net.il (mxout1.netvision.net.il [194.90.9.20]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h75MEiFl008833 for ; Tue, 5 Aug 2003 15:14:45 -0700 Received: from exg.allot.com ([199.203.223.202]) by mxout1.netvision.net.il (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HJ5001RIL0W5P@mxout1.netvision.net.il> for netdev@oss.sgi.com; Tue, 05 Aug 2003 18:43:44 +0300 (IDT) Received: from allot.com (199.203.223.201 [199.203.223.201]) by exg.allot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QG1CBDM4; Tue, 05 Aug 2003 18:46:45 +0200 Date: Tue, 05 Aug 2003 18:44:10 +0300 From: Felix Radensky Subject: Re: e100 "Ferguson" release To: "Feldman, Scott" Cc: Ben Greear , Jeff Garzik , netdev@oss.sgi.com Message-id: <3F2FD0CA.1080403@allot.com> Organization: Allot Communications Ltd. MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Lg9l6CsjxHY6kAV0DHDKJw)" X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 References: X-archive-position: 4554 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: felix@allot.com Precedence: bulk X-list: netdev --Boundary_(ID_Lg9l6CsjxHY6kAV0DHDKJw) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Hi, Scott This change seems to fix the problem. Thanks a lot ! Felix. Feldman, Scott wrote: >>I've also noticed that the number of hard_start_xmit failures >>in e1000 has increased significantly in version 5.1.13-k1. In >>version 5.0.43-k1 the number of failures was much smaller. >> >> > >Interesting. Felix, would you undo the change[1] below in 5.1.13-k1 and >see what happens? With the change below, 5.1.13 would be more >aggressive on Tx cleanup, so we'll be quicker waking the queue than >before. > >-scott > > for(i = 0; i < E1000_MAX_INTR; i++) >- if(!e1000_clean_rx_irq(adapter) && >+ if(!e1000_clean_rx_irq(adapter) & > !e1000_clean_tx_irq(adapter)) > break; > >[1] Something still bothers me about this new form where we're mixing a >bit-wise operator with logical operands. Should this bother me? > > > --Boundary_(ID_Lg9l6CsjxHY6kAV0DHDKJw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Scott

This change seems to fix the problem.
Thanks a lot !

Felix.

Feldman, Scott wrote:
I've also noticed that the number of hard_start_xmit failures 
in e1000 has increased significantly in version 5.1.13-k1. In 
version 5.0.43-k1 the number of failures was much smaller.
    

Interesting.  Felix, would you undo the change[1] below in 5.1.13-k1 and
see what happens?  With the change below, 5.1.13 would be more
aggressive on Tx cleanup, so we'll be quicker waking the queue than
before. 

-scott

        for(i = 0; i < E1000_MAX_INTR; i++)
-               if(!e1000_clean_rx_irq(adapter) &&
+               if(!e1000_clean_rx_irq(adapter) &
                   !e1000_clean_tx_irq(adapter))
                        break;

[1] Something still bothers me about this new form where we're mixing a
bit-wise operator with logical operands.  Should this bother me?

--Boundary_(ID_Lg9l6CsjxHY6kAV0DHDKJw)-- From nf@hipac.org Tue Aug 5 15:23:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 15:23:34 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [62.67.200.157]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h75MNNFl009687 for ; Tue, 5 Aug 2003 15:23:24 -0700 Received: (qmail 18331 invoked from network); 5 Aug 2003 22:23:20 -0000 Received: from unknown (HELO portal.lan) (134300@[80.138.239.123]) (envelope-sender ) by smtprelay02.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 5 Aug 2003 22:23:20 -0000 Received: from hipac.org (tmobile.lan [192.168.0.6]) by portal.lan (Postfix) with ESMTP id 235E14B0B6; Tue, 5 Aug 2003 22:46:13 +0200 (CEST) Message-ID: <3F302E04.1090503@hipac.org> Date: Wed, 06 Aug 2003 00:21:56 +0200 From: Michael Bellion and Thomas Heinz User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.4) Gecko/20030714 Debian/1.4-2 X-Accept-Language: de, en MIME-Version: 1.0 To: hadi@cyberus.ca Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [RFC] High Performance Packet Classifiction for tc framework References: <200307141045.40999.nf@hipac.org> <1058328537.1797.24.camel@jzny.localdomain> <3F16A0E5.1080007@hipac.org> <1059934468.1103.41.camel@jzny.localdomain> <3F2E5CD6.4030500@hipac.org> <1060012260.1103.380.camel@jzny.localdomain> In-Reply-To: <1060012260.1103.380.camel@jzny.localdomain> X-Enigmail-Version: 0.76.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2AA484285077C06548045724" X-archive-position: 4555 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nf@hipac.org Precedence: bulk X-list: netdev This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2AA484285077C06548045724 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Jamal You wrote: > I promise i will. I dont think i will do it justice spending 5 minutes > on it. I take it you have written extensive docs too ;-> Of course ;-) Well, actually we are going to present an overview of the hipac algorithm at the netfilter developer workshop in Budapest. Hope to see you there. > Unfortunately it is more exciting to write code than documents. I almost > got someone to document at least its proper usage but they backed away > at the last minute. lol > I dont wanna go in a lot of details, but one important detail is that > keynodes can also lead to other hash tables. So you can split the packet > parsing across multiple hashes - this is where the comparison with > chains comes in. There are several ways to do this. I'll show you the > brute force way and you can make it more usable with "hashkey" and > "sample" operator. Stealing from your example: > > [example snipped] > > Makes sense? Yes, it does. Still the question is how to solve this generally. Consider the following example ruleset: 1) src ip 10.0.0.0/30 dst ip 20.0.0.0/20 2) src ip 10.0.0.0/28 dst ip 20.0.0.0/22 3) src ip 10.0.0.0/26 dst ip 20.0.0.0/24 4) src ip 10.0.0.0/24 dst ip 20.0.0.0/26 5) src ip 10.0.0.0/22 dst ip 20.0.0.0/28 6) src ip 10.0.0.0/20 dst ip 20.0.0.0/30 So you have 1 src ip hash and #buckets(src ip hash) many dst ip hashes. In order to achieve maximum performance you have to minimize the number of collisions in the hash buckets. How would you choose the hash function and what would the construction look like? In principle the tree of hashes approach is capable to express a general access list like ruleset, i.e. a set of terminal rules with different priorities. The problem is that the approach is only efficient if the number of collisions is O(1) -> no amortized analysis but rather per bucket. In theory you can do the following. Let's consider one dimension. The matches in one dimension form a set of elementary intervals which are overlapped by certain rules. Example: |------| |---------| |----------------| |------------------| |---------------| |----|---|--|---|-----|---|----|-------|--|------|-------| The '|-----|' reflect the matches and the bottom line represents the set of elementary intervals introduced by the matches. Now, you can decide for each elementary interval which rule matches since the rules are terminal and uniquely prioritized. The next step would be to create a hash with #elementary intervals many buckets and create a hash function which maps the keys to the appropriate buckets like in the picture. In this case you have exactly 1 entry per hash bucket. Sounds fine BUT it is not possible to generically deduce an easily (= fast) computable hash function with the described requirements. BTW, this approach can be extended to 2 or more dimensions where the hash function for each hash has to meet the requirement. Of course this information is not very helpful since the problem of defining appropriate hash functions remains ;) Obviously this way is not viable but supposedly the only one to achieve ultimate performance with the tree of hashes concept. BTW, the way hipac works is basically not so different from the idea described above but since we use efficient btrees we don't have to define hash functions. > sure position could be used as a priority. It is easier/intuitive to > just have explicit priorities. Merely a matter of taste. The way iptables and nf-hipac use priorities is somewhat more dynamic than the tc way because they are automatically adjusted if a rule is inserted in between others. > What "optimizes" could be a user interface or the thread i was talking > about earlier. Hm, this rebalancing is not clear to us. Do you want to rebalance the tree of hashes? This seems a little strange at the first glance because the performance of the tree of hashes is dominated by the number of collisions that need to be resolved and not the depth of the tree. > Is your plan to put this in other places other than Linux? Currently we are working on the integration in linux. In general the hipac core is OS and application independent, so basically it could also be used for some userspace program which is related to classification and of course in other OS's. Any special reason why you are asking this question? > So you got this thought from iptables and took it to the next level? Well, in order to support iptables matches and targets we had to create an appropriate abstraction for them on the hipac layer. This abstraction can also be used for tc classifiers if the tcf_result is ignored, i.e. you just consider whether the filter matched or not. > I am still not sure i understand why not use what already exists - but > i'll just say i dont see it right now. If hipac had no support for embedded classifiers you couldn't express a ruleset like: 1) [native hipac matches] [u32 filter] [classid] 2) [native hipac matches] [classid] You would have to construct rule 1) in a way that it "jumps" to an external u32 filter. Unfortunately, you cannot jump back to the hipac filter again in case the u32 filter does not match so rule 2) is unreachable. This problem is caused by the fact that cls_hipac can occur at most once per interface. > It doesnt appear harmful to leave it there without destroying it. > The next time someome adds a filter of the same protocol + priority, it > will already exist. If you want to be accurate (because it does get > destroyed when the init() fails), then destroy it but you need to put > checks for "incase we have added a new tcf_proto" which may not look > pretty. Is this causing you some discomfort? No, actually not. Regards, +-----------------------+----------------------+ | Michael Bellion | Thomas Heinz | | | | +-----------------------+----------------------+ | High Performance Packet Classification | | nf-hipac: http://www.hipac.org/ | +----------------------------------------------+ --------------enig2AA484285077C06548045724 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQE/MC4FtXh2AYIMjggRAvm5AJ4r5t7eKXHNt/mWCIcS93+l/Gh+tgCdH82Z 76Nh+wx5v75reDsjfY1SJY4= =NW50 -----END PGP SIGNATURE----- --------------enig2AA484285077C06548045724-- From shemminger@osdl.org Tue Aug 5 15:43:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 15:44:05 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h75MhrFl011720 for ; Tue, 5 Aug 2003 15:43:54 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h75MhZI14668; Tue, 5 Aug 2003 15:43:36 -0700 Date: Tue, 5 Aug 2003 15:43:35 -0700 From: Stephen Hemminger To: Henner Eisen , "David S. Miller" , linux-x25@vger.kernel.org, netdev@oss.sgi.com Subject: [PATCH] X.25 async net_device fixup Message-Id: <20030805154335.7abfcb92.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.3claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4556 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Convert X.25 async driver to have dynamic net_device's. This driver is a lot like SLIP so the code changes were similar. - Added similar locking to SLIP - replaced code that snooped for MTU changes with the net_device change mtu callback. - cleaned up the statistics by using the net_device_stats structure. Patch is against 2.6.0-test2. Not sure if anyone ever uses this. I tested by bringing up an x.25 async line using a modified version of slattach. diff -urNp -X dontdiff net-2.5/drivers/net/wan/x25_asy.c linux-2.5-net/drivers/net/wan/x25_asy.c --- net-2.5/drivers/net/wan/x25_asy.c 2003-08-01 11:11:42.000000000 -0700 +++ linux-2.5-net/drivers/net/wan/x25_asy.c 2003-07-31 13:22:41.000000000 -0700 @@ -34,81 +34,67 @@ #include #include "x25_asy.h" -typedef struct x25_ctrl { - struct x25_asy ctrl; /* X.25 things */ - struct net_device dev; /* the device */ -} x25_asy_ctrl_t; - -static x25_asy_ctrl_t **x25_asy_ctrls = NULL; - -int x25_asy_maxdev = SL_NRUNIT; /* Can be overridden with insmod! */ +static struct net_device **x25_asy_devs; +static int x25_asy_maxdev = SL_NRUNIT; MODULE_PARM(x25_asy_maxdev, "i"); MODULE_LICENSE("GPL"); static int x25_asy_esc(unsigned char *p, unsigned char *d, int len); static void x25_asy_unesc(struct x25_asy *sl, unsigned char c); +static void x25_asy_setup(struct net_device *dev); /* Find a free X.25 channel, and link in this `tty' line. */ -static inline struct x25_asy *x25_asy_alloc(void) +static struct x25_asy *x25_asy_alloc(void) { - x25_asy_ctrl_t *slp = NULL; + struct net_device *dev = NULL; + struct x25_asy *sl; int i; - if (x25_asy_ctrls == NULL) + if (x25_asy_devs == NULL) return NULL; /* Master array missing ! */ - for (i = 0; i < x25_asy_maxdev; i++) - { - slp = x25_asy_ctrls[i]; + for (i = 0; i < x25_asy_maxdev; i++) { + dev = x25_asy_devs[i]; + /* Not allocated ? */ - if (slp == NULL) + if (dev == NULL) break; + + sl = dev->priv; /* Not in use ? */ - if (!test_and_set_bit(SLF_INUSE, &slp->ctrl.flags)) - break; + if (!test_and_set_bit(SLF_INUSE, &sl->flags)) + return sl; } - /* SLP is set.. */ + /* Sorry, too many, all slots in use */ if (i >= x25_asy_maxdev) return NULL; /* If no channels are available, allocate one */ - if (!slp && - (x25_asy_ctrls[i] = (x25_asy_ctrl_t *)kmalloc(sizeof(x25_asy_ctrl_t), - GFP_KERNEL)) != NULL) { - slp = x25_asy_ctrls[i]; - memset(slp, 0, sizeof(x25_asy_ctrl_t)); + if (!dev) { + char name[IFNAMSIZ]; + sprintf(name, "x25asy%d", i); + + dev = alloc_netdev(sizeof(struct x25_asy), + name, x25_asy_setup); + if (!dev) + return NULL; /* Initialize channel control data */ - set_bit(SLF_INUSE, &slp->ctrl.flags); - slp->ctrl.tty = NULL; - sprintf(slp->dev.name, "x25asy%d", i); - slp->dev.base_addr = i; - slp->dev.priv = (void*)&(slp->ctrl); - slp->dev.next = NULL; - slp->dev.init = x25_asy_init; - } - if (slp != NULL) - { + sl = dev->priv; + dev->base_addr = i; /* register device so that it can be ifconfig'ed */ - /* x25_asy_init() will be called as a side-effect */ - /* SIDE-EFFECT WARNING: x25_asy_init() CLEARS slp->ctrl ! */ - - if (register_netdev(&(slp->dev)) == 0) - { + if (register_netdev(dev) == 0) { /* (Re-)Set the INUSE bit. Very Important! */ - set_bit(SLF_INUSE, &slp->ctrl.flags); - slp->ctrl.dev = &(slp->dev); - slp->dev.priv = (void*)&(slp->ctrl); - return (&(slp->ctrl)); - } - else - { - clear_bit(SLF_INUSE,&(slp->ctrl.flags)); + set_bit(SLF_INUSE, &sl->flags); + x25_asy_devs[i] = dev; + return sl; + } else { printk("x25_asy_alloc() - register_netdev() failure.\n"); + kfree(dev); } } return NULL; @@ -116,8 +102,7 @@ static inline struct x25_asy *x25_asy_al /* Free an X.25 channel. */ - -static inline void x25_asy_free(struct x25_asy *sl) +static void x25_asy_free(struct x25_asy *sl) { /* Free all X.25 frame buffers. */ if (sl->rbuff) { @@ -134,18 +119,11 @@ static inline void x25_asy_free(struct x } } -/* MTU has been changed by the IP layer. Unfortunately we are not told - about this, but we spot it ourselves and fix things up. We could be - in an upcall from the tty driver, or in an ip packet queue. */ - -static void x25_asy_changed_mtu(struct x25_asy *sl) -{ - struct net_device *dev = sl->dev; - unsigned char *xbuff, *rbuff, *oxbuff, *orbuff; - int len; - unsigned long flags; - - len = dev->mtu * 2; +static int x25_asy_change_mtu(struct net_device *dev, int newmtu) +{ + struct x25_asy *sl = dev->priv; + unsigned char *xbuff, *rbuff; + int len = 2* newmtu; xbuff = (unsigned char *) kmalloc (len + 4, GFP_ATOMIC); rbuff = (unsigned char *) kmalloc (len + 4, GFP_ATOMIC); @@ -153,52 +131,47 @@ static void x25_asy_changed_mtu(struct x if (xbuff == NULL || rbuff == NULL) { printk("%s: unable to grow X.25 buffers, MTU change cancelled.\n", - sl->dev->name); - dev->mtu = sl->mtu; + dev->name); if (xbuff != NULL) kfree(xbuff); if (rbuff != NULL) kfree(rbuff); - return; + return -ENOMEM; } - save_flags(flags); - cli(); - - oxbuff = sl->xbuff; - sl->xbuff = xbuff; - orbuff = sl->rbuff; - sl->rbuff = rbuff; - + spin_lock_bh(&sl->lock); + xbuff = xchg(&sl->xbuff, xbuff); if (sl->xleft) { if (sl->xleft <= len) { memcpy(sl->xbuff, sl->xhead, sl->xleft); } else { sl->xleft = 0; - sl->tx_dropped++; + sl->stats.tx_dropped++; } } sl->xhead = sl->xbuff; + rbuff = xchg(&sl->rbuff, rbuff); if (sl->rcount) { if (sl->rcount <= len) { - memcpy(sl->rbuff, orbuff, sl->rcount); + memcpy(sl->rbuff, rbuff, sl->rcount); } else { sl->rcount = 0; - sl->rx_over_errors++; + sl->stats.rx_over_errors++; set_bit(SLF_ERROR, &sl->flags); } } - sl->mtu = dev->mtu; + dev->mtu = newmtu; sl->buffsize = len; - restore_flags(flags); + spin_unlock_bh(&sl->lock); - if (oxbuff != NULL) - kfree(oxbuff); - if (orbuff != NULL) - kfree(orbuff); + if (xbuff != NULL) + kfree(xbuff); + if (rbuff != NULL) + kfree(rbuff); + return 0; } @@ -226,13 +199,13 @@ static void x25_asy_bump(struct x25_asy int err; count = sl->rcount; - sl->rx_bytes+=count; + sl->stats.rx_bytes+=count; skb = dev_alloc_skb(count+1); if (skb == NULL) { printk("%s: memory squeeze, dropping packet.\n", sl->dev->name); - sl->rx_dropped++; + sl->stats.rx_dropped++; return; } skb_push(skb,1); /* LAPB internal control */ @@ -249,7 +222,7 @@ static void x25_asy_bump(struct x25_asy { netif_rx(skb); sl->dev->last_rx = jiffies; - sl->rx_packets++; + sl->stats.rx_packets++; } } @@ -257,19 +230,13 @@ static void x25_asy_bump(struct x25_asy static void x25_asy_encaps(struct x25_asy *sl, unsigned char *icp, int len) { unsigned char *p; - int actual, count; - + int actual, count, mtu = sl->dev->mtu; - if (sl->mtu != sl->dev->mtu) { /* Someone has been ifconfigging */ - - x25_asy_changed_mtu(sl); - } - - if (len > sl->mtu) + if (len > mtu) { /* Sigh, shouldn't occur BUT ... */ - len = sl->mtu; + len = mtu; printk ("%s: truncating oversized transmit packet!\n", sl->dev->name); - sl->tx_dropped++; + sl->stats.tx_dropped++; x25_asy_unlock(sl); return; } @@ -310,7 +277,7 @@ static void x25_asy_write_wakeup(struct { /* Now serial buffer is almost free & we can start * transmission of another packet */ - sl->tx_packets++; + sl->stats.tx_packets++; tty->flags &= ~(1 << TTY_DO_WRITE_WAKEUP); x25_asy_unlock(sl); return; @@ -324,15 +291,20 @@ static void x25_asy_write_wakeup(struct static void x25_asy_timeout(struct net_device *dev) { struct x25_asy *sl = (struct x25_asy*)(dev->priv); - /* May be we must check transmitter timeout here ? - * 14 Oct 1994 Dmitry Gorodchanin. - */ - printk(KERN_WARNING "%s: transmit timed out, %s?\n", dev->name, - (sl->tty->driver->chars_in_buffer(sl->tty) || sl->xleft) ? - "bad line quality" : "driver error"); - sl->xleft = 0; - sl->tty->flags &= ~(1 << TTY_DO_WRITE_WAKEUP); - x25_asy_unlock(sl); + + spin_lock(&sl->lock); + if (netif_queue_stopped(dev)) { + /* May be we must check transmitter timeout here ? + * 14 Oct 1994 Dmitry Gorodchanin. + */ + printk(KERN_WARNING "%s: transmit timed out, %s?\n", dev->name, + (sl->tty->driver->chars_in_buffer(sl->tty) || sl->xleft) ? + "bad line quality" : "driver error"); + sl->xleft = 0; + sl->tty->flags &= ~(1 << TTY_DO_WRITE_WAKEUP); + x25_asy_unlock(sl); + } + spin_unlock(&sl->lock); } /* Encapsulate an IP datagram and kick it into a TTY queue. */ @@ -342,10 +314,10 @@ static int x25_asy_xmit(struct sk_buff * struct x25_asy *sl = (struct x25_asy*)(dev->priv); int err; - if (!netif_running(sl->dev)) - { + if (!netif_running(sl->dev)) { printk("%s: xmit call when iface is down\n", dev->name); - return 1; + kfree_skb(skb); + return 0; } switch(skb->data[0]) @@ -409,8 +381,11 @@ static int x25_asy_data_indication(void static void x25_asy_data_transmit(void *token, struct sk_buff *skb) { struct x25_asy *sl=token; - if (netif_queue_stopped(sl->dev)) + + spin_lock(&sl->lock); + if (netif_queue_stopped(sl->dev) || sl->tty == NULL) { + spin_unlock(&sl->lock); printk(KERN_ERR "x25_asy: tbusy drop\n"); kfree_skb(skb); return; @@ -419,10 +394,11 @@ static void x25_asy_data_transmit(void * if (skb != NULL) { x25_asy_lock(sl); - sl->tx_bytes+=skb->len; + sl->stats.tx_bytes+=skb->len; x25_asy_encaps(sl, skb->data, skb->len); dev_kfree_skb(skb); } + spin_unlock(&sl->lock); } /* @@ -475,12 +451,20 @@ static void x25_asy_disconnected(void *t sl->dev->last_rx = jiffies; } +static struct lapb_register_struct x25_asy_callbacks = { + .connect_confirmation = x25_asy_connected, + .connect_indication = x25_asy_connected, + .disconnect_confirmation = x25_asy_disconnected, + .disconnect_indication = x25_asy_disconnected, + .data_indication = x25_asy_data_indication, + .data_transmit = x25_asy_data_transmit, + +}; -/* Open the low-level part of the X.25 channel. Easy! */ +/* Open the low-level part of the X.25 channel. Easy! */ static int x25_asy_open(struct net_device *dev) { - struct lapb_register_struct x25_asy_callbacks; struct x25_asy *sl = (struct x25_asy*)(dev->priv); unsigned long len; int err; @@ -505,7 +489,7 @@ static int x25_asy_open(struct net_devic if (sl->xbuff == NULL) { goto noxbuff; } - sl->mtu = dev->mtu; + sl->buffsize = len; sl->rcount = 0; sl->xleft = 0; @@ -516,14 +500,6 @@ static int x25_asy_open(struct net_devic /* * Now attach LAPB */ - - x25_asy_callbacks.connect_confirmation=x25_asy_connected; - x25_asy_callbacks.connect_indication=x25_asy_connected; - x25_asy_callbacks.disconnect_confirmation=x25_asy_disconnected; - x25_asy_callbacks.disconnect_indication=x25_asy_disconnected; - x25_asy_callbacks.data_indication=x25_asy_data_indication; - x25_asy_callbacks.data_transmit=x25_asy_data_transmit; - if((err=lapb_register(sl, &x25_asy_callbacks))==LAPB_OK) return 0; @@ -542,13 +518,16 @@ static int x25_asy_close(struct net_devi struct x25_asy *sl = (struct x25_asy*)(dev->priv); int err; - if (sl->tty == NULL) - return -EBUSY; + spin_lock(&sl->lock); + if (sl->tty) + sl->tty->flags &= ~(1 << TTY_DO_WRITE_WAKEUP); - sl->tty->flags &= ~(1 << TTY_DO_WRITE_WAKEUP); netif_stop_queue(dev); + sl->rcount = 0; + sl->xleft = 0; if((err=lapb_unregister(sl))!=LAPB_OK) printk(KERN_ERR "x25_asy_close: lapb_unregister error -%d\n",err); + spin_unlock(&sl->lock); return 0; } @@ -571,20 +550,12 @@ static void x25_asy_receive_buf(struct t if (!sl || sl->magic != X25_ASY_MAGIC || !netif_running(sl->dev)) return; - /* - * Argh! mtu change time! - costs us the packet part received - * at the change - */ - if (sl->mtu != sl->dev->mtu) { - - x25_asy_changed_mtu(sl); - } /* Read the characters out of the buffer */ while (count--) { if (fp && *fp++) { if (!test_and_set_bit(SLF_ERROR, &sl->flags)) { - sl->rx_errors++; + sl->stats.rx_errors++; } cp++; continue; @@ -659,27 +630,14 @@ static void x25_asy_close_tty(struct tty tty->disc_data = 0; sl->tty = NULL; x25_asy_free(sl); - unregister_netdev(sl->dev); } static struct net_device_stats *x25_asy_get_stats(struct net_device *dev) { - static struct net_device_stats stats; struct x25_asy *sl = (struct x25_asy*)(dev->priv); - memset(&stats, 0, sizeof(struct net_device_stats)); - - stats.rx_packets = sl->rx_packets; - stats.tx_packets = sl->tx_packets; - stats.rx_bytes = sl->rx_bytes; - stats.tx_bytes = sl->tx_bytes; - stats.rx_dropped = sl->rx_dropped; - stats.tx_dropped = sl->tx_dropped; - stats.tx_errors = sl->tx_errors; - stats.rx_errors = sl->rx_errors; - stats.rx_over_errors = sl->rx_over_errors; - return (&stats); + return &sl->stats; } @@ -757,7 +715,7 @@ static void x25_asy_unesc(struct x25_asy sl->rbuff[sl->rcount++] = s; return; } - sl->rx_over_errors++; + sl->stats.rx_over_errors++; set_bit(SLF_ERROR, &sl->flags); } } @@ -799,18 +757,14 @@ static int x25_asy_open_dev(struct net_d } /* Initialise the X.25 driver. Called by the device init code */ -int x25_asy_init(struct net_device *dev) +static void x25_asy_setup(struct net_device *dev) { - struct x25_asy *sl = (struct x25_asy*)(dev->priv); - - if (sl == NULL) /* Allocation failed ?? */ - return -ENODEV; - - /* Set up the control block. (And clear statistics) */ + struct x25_asy *sl = dev->priv; - memset(sl, 0, sizeof (struct x25_asy)); sl->magic = X25_ASY_MAGIC; sl->dev = dev; + spin_lock_init(&sl->lock); + set_bit(SLF_INUSE, &sl->flags); /* * Finish setting up the DEVICE info. @@ -823,6 +777,7 @@ int x25_asy_init(struct net_device *dev) dev->open = x25_asy_open_dev; dev->stop = x25_asy_close; dev->get_stats = x25_asy_get_stats; + dev->change_mtu = x25_asy_change_mtu; dev->hard_header_len = 0; dev->addr_len = 0; dev->type = ARPHRD_X25; @@ -830,8 +785,6 @@ int x25_asy_init(struct net_device *dev) /* New-style flags. */ dev->flags = IFF_NOARP; - - return 0; } static struct tty_ldisc x25_ldisc = { @@ -853,13 +806,15 @@ static int __init init_x25_asy(void) printk(KERN_INFO "X.25 async: version 0.00 ALPHA " "(dynamic channels, max=%d).\n", x25_asy_maxdev ); - x25_asy_ctrls = kmalloc(sizeof(void*)*x25_asy_maxdev, GFP_KERNEL); - if (!x25_asy_ctrls) { + + x25_asy_devs = kmalloc(sizeof(struct net_device *)*x25_asy_maxdev, + GFP_KERNEL); + if (!x25_asy_devs) { printk(KERN_WARNING "X25 async: Can't allocate x25_asy_ctrls[] " "array! Uaargh! (-> No X.25 available)\n"); return -ENOMEM; } - memset(x25_asy_ctrls, 0, sizeof(void*)*x25_asy_maxdev); /* Pointers */ + memset(x25_asy_devs, 0, sizeof(struct net_device *)*x25_asy_maxdev); return tty_register_ldisc(N_X25, &x25_ldisc); } @@ -867,22 +822,29 @@ static int __init init_x25_asy(void) static void __exit exit_x25_asy(void) { + struct net_device *dev; int i; for (i = 0; i < x25_asy_maxdev; i++) { - if (x25_asy_ctrls[i]) { + dev = x25_asy_devs[i]; + if (dev) { + struct x25_asy *sl = dev->priv; + + spin_lock_bh(&sl->lock); + if (sl->tty) + tty_hangup(sl->tty); + + spin_unlock_bh(&sl->lock); /* * VSV = if dev->start==0, then device * unregistered while close proc. */ - if (netif_running(&(x25_asy_ctrls[i]->dev))) - unregister_netdev(&(x25_asy_ctrls[i]->dev)); - - kfree(x25_asy_ctrls[i]); + unregister_netdev(dev); + kfree(dev); } } - kfree(x25_asy_ctrls); + kfree(x25_asy_devs); tty_register_ldisc(N_X25, NULL); } diff -urNp -X dontdiff net-2.5/drivers/net/wan/x25_asy.h linux-2.5-net/drivers/net/wan/x25_asy.h --- net-2.5/drivers/net/wan/x25_asy.h 2003-08-01 11:11:42.000000000 -0700 +++ linux-2.5-net/drivers/net/wan/x25_asy.h 2003-07-30 14:29:19.000000000 -0700 @@ -18,8 +18,9 @@ struct x25_asy { int magic; /* Various fields. */ + spinlock_t lock; struct tty_struct *tty; /* ptr to TTY structure */ - struct net_device *dev; /* easy for intr handling */ + struct net_device *dev; /* easy for intr handling */ /* These are pointers to the malloc()ed frame buffers. */ unsigned char *rbuff; /* receiver buffer */ @@ -29,17 +30,8 @@ struct x25_asy { int xleft; /* bytes left in XMIT queue */ /* X.25 interface statistics. */ - unsigned long rx_packets; /* inbound frames counter */ - unsigned long tx_packets; /* outbound frames counter */ - unsigned long rx_bytes; /* inbound byte counte */ - unsigned long tx_bytes; /* outbound byte counter */ - unsigned long rx_errors; /* Parity, etc. errors */ - unsigned long tx_errors; /* Planned stuff */ - unsigned long rx_dropped; /* No memory for skb */ - unsigned long tx_dropped; /* When MTU change */ - unsigned long rx_over_errors; /* Frame bigger then X.25 buf. */ + struct net_device_stats stats; - int mtu; /* Our mtu (to spot changes!) */ int buffsize; /* Max buffers sizes */ unsigned long flags; /* Flag values/ mode etc */ From willy@www.linux.org.uk Tue Aug 5 17:00:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 17:00:45 -0700 (PDT) Received: from www.linux.org.uk (IDENT:19Zp21VAhIurssXahOjUtOITdxsgIIfO@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7600ZFl016767 for ; Tue, 5 Aug 2003 17:00:36 -0700 Received: from willy by www.linux.org.uk with local (Exim 4.14) id 19k2r7-0004ko-Gu; Tue, 05 Aug 2003 15:32:05 +0100 Date: Tue, 5 Aug 2003 15:32:05 +0100 From: Matthew Wilcox To: Jeff Garzik Cc: Matthew Wilcox , netdev@oss.sgi.com Subject: Re: [PATCH] ethtool_ops rev 4 Message-ID: <20030805143205.GP22222@parcelfarce.linux.theplanet.co.uk> References: <20030801150232.GV22222@parcelfarce.linux.theplanet.co.uk> <20030801154021.GA7696@gtf.org> <20030801154656.GW22222@parcelfarce.linux.theplanet.co.uk> <20030801162536.GA18574@gtf.org> <20030802222145.GE22222@parcelfarce.linux.theplanet.co.uk> <3F2C3C86.6000202@pobox.com> <20030803002744.GF22222@parcelfarce.linux.theplanet.co.uk> <3F2C7E12.8070904@pobox.com> <20030803145656.GI22222@parcelfarce.linux.theplanet.co.uk> <3F2D41B7.7040205@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F2D41B7.7040205@pobox.com> User-Agent: Mutt/1.4.1i X-archive-position: 4557 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@debian.org Precedence: bulk X-list: netdev On Sun, Aug 03, 2003 at 01:09:11PM -0400, Jeff Garzik wrote: > Matthew Wilcox wrote: > >OK. At this point, I really feel like I'm getting in the way and > >hindering more than I'm helping. Can I pass the torch to you and let > >you finish the job? > > Sorry to give that impression :( I think we're pretty much "there". > But if you wanna hand it off to me for the last little bits, and > merging, that's fine too. I'll leave it up to you. Oh, I completely agree, I think we're down to quibbling over the last tiny details. And I think that's exactly why I should bow out at this point; you know this area much better than I do. I'm not leaving in a huff or anything -- this was a weekend hack rather than a major project to me. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From greearb@candelatech.com Tue Aug 5 17:24:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 17:24:57 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-074.evrtwa1.dsl-verizon.net [4.33.45.74]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h760OnFl017694 for ; Tue, 5 Aug 2003 17:24:49 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h760Odtf023281 for ; Tue, 5 Aug 2003 17:24:43 -0700 Message-ID: <3F304AC7.6070808@candelatech.com> Date: Tue, 05 Aug 2003 17:24:39 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030718 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'netdev@oss.sgi.com'" Subject: PATCH: Add comment to make finding the priv_flags definition easier. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4558 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev This helps me, at least, remember where the definitions are at! --- linux-2.4.21/include/linux/netdevice.h 2003-06-13 07:51:38.000000000 -0700 +++ linux-2.4.21.amds/include/linux/netdevice.h 2003-07-30 16:27:20.000000000 -0700 @@ -296,7 +296,9 @@ unsigned short flags; /* interface flags (a la BSD) */ unsigned short gflags; - unsigned short priv_flags; /* Like 'flags' but invisible to userspace. */ + unsigned short priv_flags; /* Like 'flags' but invisible to userspace, + * see: if.h for flag definitions. + */ unsigned short unused_alignment_fixer; /* Because we need priv_flags, * and we want to be 32-bit aligned. */ -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb@candelatech.com Tue Aug 5 17:27:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 17:27:26 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-074.evrtwa1.dsl-verizon.net [4.33.45.74]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h760RMFl018032 for ; Tue, 5 Aug 2003 17:27:22 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h760REtf023621 for ; Tue, 5 Aug 2003 17:27:16 -0700 Message-ID: <3F304B62.3010505@candelatech.com> Date: Tue, 05 Aug 2003 17:27:14 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030718 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'netdev@oss.sgi.com'" Subject: VLAN patch for 2.4.21 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4559 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Here is a patch that adds a few new IOCTL options (not new IOCTLs per se) for the 802.1Q VLANs. One ioctl allows one to get the VID for a device by the interface name. A second gets the name of the underlying device for the VLAN device. Tested on x86 and PPC. Comments welcome! Thanks, Ben --- linux-2.4.21/net/8021q/vlan_dev.c 2003-06-13 07:51:39.000000000 -0700 +++ linux-2.4.21.amds/net/8021q/vlan_dev.c 2003-07-30 16:20:41.000000000 -0700 @@ -1,4 +1,4 @@ -/* +/* -*- linux-c -*- * INET 802.1Q VLAN * Ethernet-type device handling. * @@ -632,6 +632,59 @@ return -EINVAL; } + +int vlan_dev_get_realdev_name(const char *dev_name, char* result) +{ + struct net_device *dev = dev_get_by_name(dev_name); + int rv = 0; + + if (dev) { + if (dev->priv_flags & IFF_802_1Q_VLAN) { + strncpy(result, VLAN_DEV_INFO(dev)->real_dev->name, 23); + dev_put(dev); + rv = 0; + } else { + printk(KERN_ERR + "%s: %s is not a vlan device, priv_flags: %hX.\n", + __FUNCTION__, dev->name, dev->priv_flags); + dev_put(dev); + rv = -EINVAL; + } + } else { + printk(KERN_ERR "%s: Could not find device: %s\n", + __FUNCTION__, dev_name); + rv = -ENODEV; + } + + return rv; +} + +int vlan_dev_get_vid(const char *dev_name, unsigned short* result) +{ + struct net_device *dev = dev_get_by_name(dev_name); + int rv = 0; + + if (dev) { + if (dev->priv_flags & IFF_802_1Q_VLAN) { + *result = VLAN_DEV_INFO(dev)->vlan_id; + dev_put(dev); + rv = 0; + } else { + printk(KERN_ERR + "%s: %s is not a vlan device, priv_flags: %hX.\n", + __FUNCTION__, dev->name, dev->priv_flags); + dev_put(dev); + rv = -EINVAL; + } + } else { + printk(KERN_ERR "%s: Could not find device: %s\n", + __FUNCTION__, dev_name); + rv = -ENODEV; + } + + return rv; +} + int vlan_dev_set_mac_address(struct net_device *dev, void *addr_struct_p) { struct sockaddr *addr = (struct sockaddr *)(addr_struct_p); --- linux-2.4.21/net/8021q/vlan.c 2003-06-13 07:51:39.000000000 -0700 +++ linux-2.4.21.amds/net/8021q/vlan.c 2003-07-30 16:20:41.000000000 -0700 @@ -1,4 +1,4 @@ -/* +/* -*- linux-c -*- * INET 802.1Q VLAN * Ethernet-type device handling. * @@ -655,12 +655,9 @@ int vlan_ioctl_handler(unsigned long arg) { int err = 0; + unsigned short vid = 0; struct vlan_ioctl_args args; - /* everything here needs root permissions, except aguably the - * hack ioctls for sending packets. However, I know _I_ don't - * want users running that on my network! --BLG - */ if (!capable(CAP_NET_ADMIN)) return -EPERM; @@ -678,24 +675,32 @@ switch (args.cmd) { case SET_VLAN_INGRESS_PRIORITY_CMD: + if (!capable(CAP_NET_ADMIN)) + return -EPERM; err = vlan_dev_set_ingress_priority(args.device1, args.u.skb_priority, args.vlan_qos); break; case SET_VLAN_EGRESS_PRIORITY_CMD: + if (!capable(CAP_NET_ADMIN)) + return -EPERM; err = vlan_dev_set_egress_priority(args.device1, args.u.skb_priority, args.vlan_qos); break; case SET_VLAN_FLAG_CMD: + if (!capable(CAP_NET_ADMIN)) + return -EPERM; err = vlan_dev_set_vlan_flag(args.device1, args.u.flag, args.vlan_qos); break; case SET_VLAN_NAME_TYPE_CMD: + if (!capable(CAP_NET_ADMIN)) + return -EPERM; if ((args.u.name_type >= 0) && (args.u.name_type < VLAN_NAME_TYPE_HIGHEST)) { vlan_name_type = args.u.name_type; @@ -705,17 +710,9 @@ } break; - /* TODO: Figure out how to pass info back... - case GET_VLAN_INGRESS_PRIORITY_IOCTL: - err = vlan_dev_get_ingress_priority(args); - break; - - case GET_VLAN_EGRESS_PRIORITY_IOCTL: - err = vlan_dev_get_egress_priority(args); - break; - */ - case ADD_VLAN_CMD: + if (!capable(CAP_NET_ADMIN)) + return -EPERM; /* we have been given the name of the Ethernet Device we want to * talk to: args.dev1 We also have the * VLAN ID: args.u.VID @@ -728,12 +725,53 @@ break; case DEL_VLAN_CMD: + if (!capable(CAP_NET_ADMIN)) + return -EPERM; /* Here, the args.dev1 is the actual VLAN we want * to get rid of. */ err = unregister_vlan_device(args.device1); break; + case GET_VLAN_INGRESS_PRIORITY_CMD: + /* TODO: Implement + err = vlan_dev_get_ingress_priority(args); + if (copy_to_user((void*)arg, &args, + sizeof(struct vlan_ioctl_args))) { + err = -EFAULT; + } + */ + err = -EINVAL; + break; + + case GET_VLAN_EGRESS_PRIORITY_CMD: + /* TODO: Implement + err = vlan_dev_get_egress_priority(args.device1, &(args.args); + if (copy_to_user((void*)arg, &args, + sizeof(struct vlan_ioctl_args))) { + err = -EFAULT; + } + */ + err = -EINVAL; + break; + + case GET_VLAN_REALDEV_NAME_CMD: + err = vlan_dev_get_realdev_name(args.device1, args.u.device2); + if (copy_to_user((void*)arg, &args, + sizeof(struct vlan_ioctl_args))) { + err = -EFAULT; + } + break; + + case GET_VLAN_VID_CMD: + err = vlan_dev_get_vid(args.device1, &vid); + args.u.VID = vid; + if (copy_to_user((void*)arg, &args, + sizeof(struct vlan_ioctl_args))) { + err = -EFAULT; + } + break; + default: /* pass on to underlying device instead?? */ printk(VLAN_DBG "%s: Unknown VLAN CMD: %x \n", --- linux-2.4.21/net/8021q/vlan.h 2002-08-02 17:39:46.000000000 -0700 +++ linux-2.4.21.amds/net/8021q/vlan.h 2003-07-30 16:30:53.000000000 -0700 @@ -72,6 +72,8 @@ int vlan_dev_set_ingress_priority(char* dev_name, __u32 skb_prio, short vlan_prio); int vlan_dev_set_egress_priority(char* dev_name, __u32 skb_prio, short vlan_prio); int vlan_dev_set_vlan_flag(char* dev_name, __u32 flag, short flag_val); +int vlan_dev_get_realdev_name(const char* dev_name, char* result); +int vlan_dev_get_vid(const char* dev_name, unsigned short* result); void vlan_dev_set_multicast_list(struct net_device *vlan_dev); #endif /* !(__BEN_VLAN_802_1Q_INC__) */ --- linux-2.4.21/include/linux/if_vlan.h 2002-11-28 15:53:15.000000000 -0800 +++ linux-2.4.21.amds/include/linux/if_vlan.h 2003-07-30 16:29:30.000000000 -0700 @@ -212,7 +212,9 @@ GET_VLAN_INGRESS_PRIORITY_CMD, GET_VLAN_EGRESS_PRIORITY_CMD, SET_VLAN_NAME_TYPE_CMD, - SET_VLAN_FLAG_CMD + SET_VLAN_FLAG_CMD, + GET_VLAN_REALDEV_NAME_CMD, /* If this works, you know it's a VLAN device, btw */ + GET_VLAN_VID_CMD /* Get the VID of this VLAN (specified by name) */ }; enum vlan_name_types { -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb@candelatech.com Tue Aug 5 17:33:12 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 17:33:14 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-074.evrtwa1.dsl-verizon.net [4.33.45.74]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h760XBFl018375 for ; Tue, 5 Aug 2003 17:33:11 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h760X3tf024354 for ; Tue, 5 Aug 2003 17:33:06 -0700 Message-ID: <3F304CBF.6050902@candelatech.com> Date: Tue, 05 Aug 2003 17:33:03 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030718 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'netdev@oss.sgi.com'" Subject: MAC-VLANS Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4560 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev In order to get MAC-VLANs to work, the only way I can see to make it happen is to put a hook into dev.c in the: int netif_receive_skb(struct sk_buff *skb) method. The hook looks like this, and immediately follows the bridging code hook in the same method: #if defined(CONFIG_MACVLAN) || defined(CONFIG_MACVLAN_MODULE) if (skb->dev->macvlan_priv != NULL && macvlan_handle_frame_hook != NULL) { if (handle_macvlan(skb) >= 0) { /* consumed by mac-vlan...it would have been * re-sent to this method with a different * device... */ return 0; } else { /* Let it fall through and be processed normally */ } } #endif So, the question is: Will this feature be allowed to go in since it needs this hook, regardless of other issues? If it's possible, I'll break out the rest of the patch for inspection... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From jmorris@intercode.com.au Tue Aug 5 17:34:39 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 17:34:41 -0700 (PDT) Received: from blackbird.intercode.com.au (IDENT:f2CjXfr43uFTNwRG0cB0WMezYNuQ3wx7@blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h760YZFl018703 for ; Tue, 5 Aug 2003 17:34:37 -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 h760Y4r26614; Wed, 6 Aug 2003 10:34:04 +1000 Date: Wed, 6 Aug 2003 10:34:03 +1000 (EST) From: James Morris To: Stephen Hemminger cc: Ralf Baechle , "David S. Miller" , , Subject: Re: [PATCH] (2/2) Convert ROSE to seq_file In-Reply-To: <20030805144622.100f208d.shemminger@osdl.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4561 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 Applied to bk://kernel.bkbits.net/jmorris/net-2.5 - James -- James Morris From jmorris@intercode.com.au Tue Aug 5 17:34:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 17:34:47 -0700 (PDT) Received: from blackbird.intercode.com.au (IDENT:hoeVbT2rTMYdyvIW67JSUPZyRoC9OW6H@blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h760YfFl018709 for ; Tue, 5 Aug 2003 17:34:43 -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 h760YLr26620; Wed, 6 Aug 2003 10:34:21 +1000 Date: Wed, 6 Aug 2003 10:34:21 +1000 (EST) From: James Morris To: Stephen Hemminger cc: Ralf Baechle , "David S. Miller" , , Subject: Re: [PATCH 2.6.0-test2] (1/2) Dynamically allocate net_device structures for ROSE In-Reply-To: <20030805144617.2e856d6d.shemminger@osdl.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4562 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 Applied to bk://kernel.bkbits.net/jmorris/net-2.5 -- James Morris From jmorris@intercode.com.au Tue Aug 5 17:34:52 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 17:34:54 -0700 (PDT) Received: from blackbird.intercode.com.au (IDENT:Jlzxj8MKIjsXElf9D/uLWFqiRBt7Dl8R@blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h760YnFl018769 for ; Tue, 5 Aug 2003 17:34:50 -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 h760YTr26627; Wed, 6 Aug 2003 10:34:29 +1000 Date: Wed, 6 Aug 2003 10:34:29 +1000 (EST) From: James Morris To: Stephen Hemminger cc: Ralf Baechle , "David S. Miller" , , Subject: Re: [PATCH] Fix use after free in AX.25 In-Reply-To: <20030805145658.1b3f194b.shemminger@osdl.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4563 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 Applied to bk://kernel.bkbits.net/jmorris/net-2.5 -- James Morris From jmorris@intercode.com.au Tue Aug 5 17:35:13 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 17:35:16 -0700 (PDT) Received: from blackbird.intercode.com.au (IDENT:k3krbhVq4Bw3NqfG7XRvhOqSUlr5Pwa5@blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h760ZAFl018891 for ; Tue, 5 Aug 2003 17:35:12 -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 h760Yir26637; Wed, 6 Aug 2003 10:34:44 +1000 Date: Wed, 6 Aug 2003 10:34:43 +1000 (EST) From: James Morris To: Stephen Hemminger cc: Henner Eisen , "David S. Miller" , , Subject: Re: [PATCH] Fix X.25 use after free. In-Reply-To: <20030805150110.0e2753ab.shemminger@osdl.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4564 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 Applied to bk://kernel.bkbits.net/jmorris/net-2.5 -- James Morris From jmorris@intercode.com.au Tue Aug 5 17:35:42 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 17:35:45 -0700 (PDT) Received: from blackbird.intercode.com.au (IDENT:v1VYsOypAvseLXmDKGTfY8uAhfRd78CF@blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h760ZdFl019427 for ; Tue, 5 Aug 2003 17:35:40 -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 h760ZKr26651; Wed, 6 Aug 2003 10:35:20 +1000 Date: Wed, 6 Aug 2003 10:35:19 +1000 (EST) From: James Morris To: Stephen Hemminger cc: Henner Eisen , "David S. Miller" , , Subject: Re: [PATCH] X.25 async net_device fixup In-Reply-To: <20030805154335.7abfcb92.shemminger@osdl.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4565 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 Also applied to bk://kernel.bkbits.net/jmorris/net-2.5 -- James Morris From jgarzik@pobox.com Tue Aug 5 19:58:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 19:58:37 -0700 (PDT) Received: from www.linux.org.uk (IDENT:kFrzWfvhJzSSlooxnx+eUym2uOAeLT4I@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h762wQFl001953 for ; Tue, 5 Aug 2003 19:58:27 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19kEVM-0008Fs-3P; Wed, 06 Aug 2003 03:58:24 +0100 Message-ID: <3F306EC4.1030109@pobox.com> Date: Tue, 05 Aug 2003 22:58:12 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: "Feldman, Scott" CC: Samuel Flory , netdev@oss.sgi.com Subject: Re: More 2.4.22pre10 ACPI breakage References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4566 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 Feldman, Scott wrote: >> It appears that the intel Se7501BR mother is also having >>issues with ACPI. When ACPI support is enable the e1000 >>controller stops working printing "<6>NETDEV WATCHDOG: >>eth0: transmit timed out". > > > Must...have...interrupts. You are 100% correct. That said... I'm tempted to extend NAPI just a bit, to provide an "always poll" mode. It seems like all the bug reports I get these days for 8139too are caused by x86 ACPI/APIC/irq routing troubles completely unrelated to the driver. Tulip-almost-NAPI in 2.4 has an always-poll mode, so I have a convenient excuse :) Jeff From davem@redhat.com Tue Aug 5 20:45:04 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 20:45:10 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h763j3Fl014425 for ; Tue, 5 Aug 2003 20:45:04 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id UAA24203; Tue, 5 Aug 2003 20:40:28 -0700 Date: Tue, 5 Aug 2003 20:40:28 -0700 From: "David S. Miller" To: Ben Greear Cc: netdev@oss.sgi.com Subject: Re: MAC-VLANS Message-Id: <20030805204028.644895dc.davem@redhat.com> In-Reply-To: <3F304CBF.6050902@candelatech.com> References: <3F304CBF.6050902@candelatech.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4567 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 05 Aug 2003 17:33:03 -0700 Ben Greear wrote: > In order to get MAC-VLANs to work, the only way I can see to make > it happen is to put a hook into dev.c in the: Why not do it the same we do normal VLAN's? Ie. directly in the device driver receive method via something akin to the vlan_hwaccel_*() routines. From greearb@candelatech.com Tue Aug 5 21:10:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 21:10:59 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-074.evrtwa1.dsl-verizon.net [4.33.45.74]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h764ArFl016407 for ; Tue, 5 Aug 2003 21:10:54 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h764Altf019406; Tue, 5 Aug 2003 21:10:47 -0700 Message-ID: <3F307FC7.10908@candelatech.com> Date: Tue, 05 Aug 2003 21:10:47 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030718 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: MAC-VLANS References: <3F304CBF.6050902@candelatech.com> <20030805204028.644895dc.davem@redhat.com> In-Reply-To: <20030805204028.644895dc.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4568 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev David S. Miller wrote: > On Tue, 05 Aug 2003 17:33:03 -0700 > Ben Greear wrote: > > >>In order to get MAC-VLANs to work, the only way I can see to make >>it happen is to put a hook into dev.c in the: > > > Why not do it the same we do normal VLAN's? Ie. directly > in the device driver receive method via something akin to > the vlan_hwaccel_*() routines. You mean in eth.c or something? I don't want to have to put identical code in all drivers, if that's what you're suggesting. It could be done to common drivers if the feature is used enough to warrant it, but we definately need a fallback case to work with all generic drivers, just as .1q does. 802.1q works because we have an extra shim header in there..but MAC-vlans have no extra header info. It would be nice to have a separate 'protocol' list that was able to consume the pkt: that would allow this to work w/out additional hacks, and could work for pktgen rx and even bridging. Of course, not all could be active at once, but that is no worse than 'hooks' in that regard. And, evil ppl could re-write the IP stack, of course, but that doesn't bother me as much as some folks :) Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb@candelatech.com Tue Aug 5 21:15:06 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 21:15:15 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-074.evrtwa1.dsl-verizon.net [4.33.45.74]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h764F5Fl016979 for ; Tue, 5 Aug 2003 21:15:06 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h764F0tf019943 for ; Tue, 5 Aug 2003 21:15:00 -0700 Message-ID: <3F3080C4.9070507@candelatech.com> Date: Tue, 05 Aug 2003 21:15:00 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030718 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'netdev@oss.sgi.com'" Subject: VLAN patch try 2, tabs instead of spaces Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4569 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Same as last time, but now using tabs instead of spaces. --- linux-2.4.21/net/8021q/vlan_dev.c 2003-06-13 07:51:39.000000000 -0700 +++ linux-2.4.21.amds/net/8021q/vlan_dev.c 2003-08-05 20:38:25.000000000 -0700 @@ -1,18 +1,18 @@ -/* +/* -*- linux-c -*- * INET 802.1Q VLAN * Ethernet-type device handling. * * Authors: Ben Greear - * Please send support related email to: vlan@scry.wanfear.com - * VLAN Home Page: http://www.candelatech.com/~greear/vlan.html + * Please send support related email to: vlan@scry.wanfear.com + * VLAN Home Page: http://www.candelatech.com/~greear/vlan.html * - * Fixes: Mar 22 2001: Martin Bokaemper - * - reset skb->pkt_type on incoming packets when MAC was changed - * - see that changed MAC is saddr for outgoing packets - * Oct 20, 2001: Ard van Breeman: - * - Fix MC-list, finally. - * - Flush MC-list on VLAN destroy. - * + * Fixes: Mar 22 2001: Martin Bokaemper + * - reset skb->pkt_type on incoming packets when MAC was changed + * - see that changed MAC is saddr for outgoing packets + * Oct 20, 2001: Ard van Breeman: + * - Fix MC-list, finally. + * - Flush MC-list on VLAN destroy. + * * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License @@ -99,18 +99,18 @@ * NOTE: Should be similar to ethernet/eth.c. * * SANITY NOTE: This method is called when a packet is moving up the stack - * towards userland. To get here, it would have already passed - * through the ethernet/eth.c eth_type_trans() method. + * towards userland. To get here, it would have already passed + * through the ethernet/eth.c eth_type_trans() method. * SANITY NOTE 2: We are referencing to the VLAN_HDR frields, which MAY be - * stored UNALIGNED in the memory. RISC systems don't like - * such cases very much... + * stored UNALIGNED in the memory. RISC systems don't like + * such cases very much... * SANITY NOTE 2a: According to Dave Miller & Alexey, it will always be aligned, - * so there doesn't need to be any of the unaligned stuff. It has - * been commented out now... --Ben + * so there doesn't need to be any of the unaligned stuff. It has + * been commented out now... --Ben * */ int vlan_skb_recv(struct sk_buff *skb, struct net_device *dev, - struct packet_type* ptype) + struct packet_type* ptype) { unsigned char *rawp = NULL; struct vlan_hdr *vhdr = (struct vlan_hdr *)(skb->data); @@ -170,7 +170,7 @@ spin_unlock_bh(&vlan_group_lock); #ifdef VLAN_DEBUG - printk(VLAN_DBG "%s: dropping skb: %p because came in on wrong device, dev: %s real_dev: %s, skb_dev: %s\n", + printk(VLAN_DBG "%s: dropping skb: %p because came in on wrong device, dev: %s real_dev: %s, skb_dev: %s\n", __FUNCTION__ skb, dev->name, VLAN_DEV_INFO(skb->dev)->real_dev->name, skb->dev->name); @@ -324,8 +324,8 @@ * physical devices. */ int vlan_dev_hard_header(struct sk_buff *skb, struct net_device *dev, - unsigned short type, void *daddr, void *saddr, - unsigned len) + unsigned short type, void *daddr, void *saddr, + unsigned len) { struct vlan_hdr *vhdr; unsigned short veth_TCI = 0; @@ -613,7 +613,7 @@ dev_put(dev); return 0; } else { - printk(KERN_ERR "%s: flag %i is not valid.\n", + printk(KERN_ERR "%s: flag %i is not valid.\n", __FUNCTION__, (int)(flag)); dev_put(dev); return -EINVAL; @@ -625,13 +625,66 @@ dev_put(dev); } } else { - printk(KERN_ERR "%s: Could not find device: %s\n", + printk(KERN_ERR "%s: Could not find device: %s\n", __FUNCTION__, dev_name); } return -EINVAL; } + +int vlan_dev_get_realdev_name(const char *dev_name, char* result) +{ + struct net_device *dev = dev_get_by_name(dev_name); + int rv = 0; + + if (dev) { + if (dev->priv_flags & IFF_802_1Q_VLAN) { + strncpy(result, VLAN_DEV_INFO(dev)->real_dev->name, 23); + dev_put(dev); + rv = 0; + } else { + printk(KERN_ERR + "%s: %s is not a vlan device, priv_flags: %hX.\n", + __FUNCTION__, dev->name, dev->priv_flags); + dev_put(dev); + rv = -EINVAL; + } + } else { + printk(KERN_ERR "%s: Could not find device: %s\n", + __FUNCTION__, dev_name); + rv = -ENODEV; + } + + return rv; +} + +int vlan_dev_get_vid(const char *dev_name, unsigned short* result) +{ + struct net_device *dev = dev_get_by_name(dev_name); + int rv = 0; + + if (dev) { + if (dev->priv_flags & IFF_802_1Q_VLAN) { + *result = VLAN_DEV_INFO(dev)->vlan_id; + dev_put(dev); + rv = 0; + } else { + printk(KERN_ERR + "%s: %s is not a vlan device, priv_flags: %hX.\n", + __FUNCTION__, dev->name, dev->priv_flags); + dev_put(dev); + rv = -EINVAL; + } + } else { + printk(KERN_ERR "%s: Could not find device: %s\n", + __FUNCTION__, dev_name); + rv = -ENODEV; + } + + return rv; +} + int vlan_dev_set_mac_address(struct net_device *dev, void *addr_struct_p) { struct sockaddr *addr = (struct sockaddr *)(addr_struct_p); @@ -671,7 +724,7 @@ } static inline int vlan_dmi_equals(struct dev_mc_list *dmi1, - struct dev_mc_list *dmi2) + struct dev_mc_list *dmi2) { return ((dmi1->dmi_addrlen == dmi2->dmi_addrlen) && (memcmp(dmi1->dmi_addr, dmi2->dmi_addr, dmi1->dmi_addrlen) == 0)); --- linux-2.4.21/net/8021q/vlan.c 2003-06-13 07:51:39.000000000 -0700 +++ linux-2.4.21.amds/net/8021q/vlan.c 2003-08-05 20:53:31.000000000 -0700 @@ -1,13 +1,13 @@ -/* +/* -*- linux-c -*- * INET 802.1Q VLAN * Ethernet-type device handling. * * Authors: Ben Greear - * Please send support related email to: vlan@scry.wanfear.com - * VLAN Home Page: http://www.candelatech.com/~greear/vlan.html + * Please send support related email to: vlan@scry.wanfear.com + * VLAN Home Page: http://www.candelatech.com/~greear/vlan.html * * Fixes: - * Fix for packet capture - Nick Eggleston ; + * Fix for packet capture - Nick Eggleston ; * Add HW acceleration hooks - David S. Miller ; * Correct all the locking - David S. Miller ; * Use hash table for VLAN groups - David S. Miller @@ -173,7 +173,7 @@ *pprev = grp->next; } -/* Find the protocol handler. Assumes VID < VLAN_VID_MASK. +/* Find the protocol handler. Assumes VID < VLAN_VID_MASK. * * Must be invoked with vlan_group_lock held. */ @@ -183,7 +183,7 @@ struct vlan_group *grp = __vlan_find_group(real_dev->ifindex); if (grp) - return grp->vlan_devices[VID]; + return grp->vlan_devices[VID]; return NULL; } @@ -270,7 +270,7 @@ } } - return ret; + return ret; } static int unregister_vlan_device(const char *vlan_IF_name) @@ -655,17 +655,14 @@ int vlan_ioctl_handler(unsigned long arg) { int err = 0; + unsigned short vid = 0; struct vlan_ioctl_args args; - /* everything here needs root permissions, except aguably the - * hack ioctls for sending packets. However, I know _I_ don't - * want users running that on my network! --BLG - */ if (!capable(CAP_NET_ADMIN)) return -EPERM; if (copy_from_user(&args, (void*)arg, - sizeof(struct vlan_ioctl_args))) + sizeof(struct vlan_ioctl_args))) return -EFAULT; /* Null terminate this sucker, just in case. */ @@ -678,24 +675,32 @@ switch (args.cmd) { case SET_VLAN_INGRESS_PRIORITY_CMD: + if (!capable(CAP_NET_ADMIN)) + return -EPERM; err = vlan_dev_set_ingress_priority(args.device1, args.u.skb_priority, args.vlan_qos); break; case SET_VLAN_EGRESS_PRIORITY_CMD: + if (!capable(CAP_NET_ADMIN)) + return -EPERM; err = vlan_dev_set_egress_priority(args.device1, args.u.skb_priority, args.vlan_qos); break; case SET_VLAN_FLAG_CMD: + if (!capable(CAP_NET_ADMIN)) + return -EPERM; err = vlan_dev_set_vlan_flag(args.device1, args.u.flag, args.vlan_qos); break; case SET_VLAN_NAME_TYPE_CMD: + if (!capable(CAP_NET_ADMIN)) + return -EPERM; if ((args.u.name_type >= 0) && (args.u.name_type < VLAN_NAME_TYPE_HIGHEST)) { vlan_name_type = args.u.name_type; @@ -705,17 +710,9 @@ } break; - /* TODO: Figure out how to pass info back... - case GET_VLAN_INGRESS_PRIORITY_IOCTL: - err = vlan_dev_get_ingress_priority(args); - break; - - case GET_VLAN_EGRESS_PRIORITY_IOCTL: - err = vlan_dev_get_egress_priority(args); - break; - */ - case ADD_VLAN_CMD: + if (!capable(CAP_NET_ADMIN)) + return -EPERM; /* we have been given the name of the Ethernet Device we want to * talk to: args.dev1 We also have the * VLAN ID: args.u.VID @@ -728,12 +725,53 @@ break; case DEL_VLAN_CMD: + if (!capable(CAP_NET_ADMIN)) + return -EPERM; /* Here, the args.dev1 is the actual VLAN we want * to get rid of. */ err = unregister_vlan_device(args.device1); break; + case GET_VLAN_INGRESS_PRIORITY_CMD: + /* TODO: Implement + err = vlan_dev_get_ingress_priority(args); + if (copy_to_user((void*)arg, &args, + sizeof(struct vlan_ioctl_args))) { + err = -EFAULT; + } + */ + err = -EINVAL; + break; + + case GET_VLAN_EGRESS_PRIORITY_CMD: + /* TODO: Implement + err = vlan_dev_get_egress_priority(args.device1, &(args.args); + if (copy_to_user((void*)arg, &args, + sizeof(struct vlan_ioctl_args))) { + err = -EFAULT; + } + */ + err = -EINVAL; + break; + + case GET_VLAN_REALDEV_NAME_CMD: + err = vlan_dev_get_realdev_name(args.device1, args.u.device2); + if (copy_to_user((void*)arg, &args, + sizeof(struct vlan_ioctl_args))) { + err = -EFAULT; + } + break; + + case GET_VLAN_VID_CMD: + err = vlan_dev_get_vid(args.device1, &vid); + args.u.VID = vid; + if (copy_to_user((void*)arg, &args, + sizeof(struct vlan_ioctl_args))) { + err = -EFAULT; + } + break; + default: /* pass on to underlying device instead?? */ printk(VLAN_DBG "%s: Unknown VLAN CMD: %x \n", --- linux-2.4.21/net/8021q/vlan.h 2002-08-02 17:39:46.000000000 -0700 +++ linux-2.4.21.amds/net/8021q/vlan.h 2003-07-30 16:30:53.000000000 -0700 @@ -72,6 +72,8 @@ int vlan_dev_set_ingress_priority(char* dev_name, __u32 skb_prio, short vlan_prio); int vlan_dev_set_egress_priority(char* dev_name, __u32 skb_prio, short vlan_prio); int vlan_dev_set_vlan_flag(char* dev_name, __u32 flag, short flag_val); +int vlan_dev_get_realdev_name(const char* dev_name, char* result); +int vlan_dev_get_vid(const char* dev_name, unsigned short* result); void vlan_dev_set_multicast_list(struct net_device *vlan_dev); #endif /* !(__BEN_VLAN_802_1Q_INC__) */ --- linux-2.4.21/include/linux/if_vlan.h 2002-11-28 15:53:15.000000000 -0800 +++ linux-2.4.21.amds/include/linux/if_vlan.h 2003-07-30 16:29:30.000000000 -0700 @@ -212,7 +212,9 @@ GET_VLAN_INGRESS_PRIORITY_CMD, GET_VLAN_EGRESS_PRIORITY_CMD, SET_VLAN_NAME_TYPE_CMD, - SET_VLAN_FLAG_CMD + SET_VLAN_FLAG_CMD, + GET_VLAN_REALDEV_NAME_CMD, /* If this works, you know it's a VLAN device, btw */ + GET_VLAN_VID_CMD /* Get the VID of this VLAN (specified by name) */ }; enum vlan_name_types { -- Ben Greear Candela Technologies Inc http://www.candelatech.com From werner@almesberger.net Tue Aug 5 22:13:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 22:13:25 -0700 (PDT) Received: from host.almesberger.net (almesberger.net [63.105.73.239] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h765DGFl022080 for ; Tue, 5 Aug 2003 22:13:17 -0700 Received: from almesberger.net (vpnwa-home [10.200.0.2]) by host.almesberger.net (8.11.6/8.9.3) with ESMTP id h765DEG23709; Tue, 5 Aug 2003 22:13:14 -0700 Received: (from werner@localhost) by almesberger.net (8.11.6/8.11.6) id h765D4D31551; Wed, 6 Aug 2003 02:13:04 -0300 Date: Wed, 6 Aug 2003 02:13:04 -0300 From: Werner Almesberger To: "Eric W. Biederman" Cc: Jeff Garzik , Nivedita Singhvi , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: TOE brain dump Message-ID: <20030806021304.E5798@almesberger.net> References: <20030802140444.E5798@almesberger.net> <3F2BF5C7.90400@us.ibm.com> <3F2C0C44.6020002@pobox.com> <20030802184901.G5798@almesberger.net> <20030804162433.L5798@almesberger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from ebiederm@xmission.com on Tue, Aug 05, 2003 at 11:19:09AM -0600 X-archive-position: 4570 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: werner@almesberger.net Precedence: bulk X-list: netdev Eric W. Biederman wrote: > MPI is not a transport. It an interface like the Berkeley sockets > layer. Hmm, but doesn't it also unify transport semantics (i.e. chop TCP streams into messages), maybe add reliability to transports that don't have it, and provide addressing ? Okay, perhaps you wouldn't call this a transport in the OSI sense, but it still seems to have considerably more functionality than just providing an API. > Mostly I think the that is less true, at least if they can stand the > process of severe code review and cleaning up their code. Hmm, people putting dozens of millions into building clusters can't afford to have what is probably their most essential infrastructure code reviewed and cleaned up ? Oh dear. > But of course to get through the peer review process people need > to understand what they are doing. A good point :-) > So store and forward of packets in a 3 layer switch hierarchy, at 1.3 us > per copy. But your switch could just do cut-through, no ? Or do they need to recompute checksums ? > A lot of the NICs which are used for MPI tend to be smart for two > reasons. 1) So they can do source routing. 2) So they can safely > export some of their interface to user space, so in the fast path > they can bypass the kernel. The second part could be interesting for TOE, too. Only that the interface exported would just be the socket interface. - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina werner@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From davem@redhat.com Tue Aug 5 23:13:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 05 Aug 2003 23:13:20 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h766DFFl026190 for ; Tue, 5 Aug 2003 23:13:16 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id XAA24465; Tue, 5 Aug 2003 23:08:37 -0700 Date: Tue, 5 Aug 2003 23:08:37 -0700 From: "David S. Miller" To: Andi Kleen Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Make XFRM optional Message-Id: <20030805230837.5609f130.davem@redhat.com> In-Reply-To: <20030805135315.GB63394@colin2.muc.de> References: <20030804125022.GA8167@averell> <20030804.215801.124854897.yoshfuji@linux-ipv6.org> <20030804130408.GA36367@colin2.muc.de> <20030804114507.6e496c77.davem@redhat.com> <20030804203524.GA15874@colin2.muc.de> <20030804165137.40d744c5.davem@redhat.com> <20030805135315.GB63394@colin2.muc.de> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4571 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On 5 Aug 2003 15:53:15 +0200 Andi Kleen wrote: > Here is a new patch that includes the missing file. Something is still wrong, in particular it seems the net/ipv6/Makefile changes are wrong resulting in: *** Warning: "xfrm6_fini" [net/ipv6/ipv6.ko] undefined! *** Warning: "xfrm6_init" [net/ipv6/ipv6.ko] undefined! *** Warning: "xfrm6_rcv" [net/ipv6/ipv6.ko] undefined! When IPV6 is built modular. Please fix, thanks. From andre@linux-ide.org Wed Aug 6 00:23:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 00:23:18 -0700 (PDT) Received: from master.linux-ide.org (astound-64-85-224-253.ca.astound.net [64.85.224.253]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h767N2Fl031304 for ; Wed, 6 Aug 2003 00:23:03 -0700 Received: from localhost (andre@localhost) by master.linux-ide.org (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h767CaF25450; Wed, 6 Aug 2003 00:12:36 -0700 Date: Wed, 6 Aug 2003 00:12:36 -0700 (PDT) From: Andre Hedrick To: Jeff Garzik cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org, Werner Almesberger , Nivedita Singhvi Subject: Re: TOE brain dump In-Reply-To: <3F2CAE61.7070401@pobox.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4572 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andre@linux-ide.org Precedence: bulk X-list: netdev Jeff, Do be sure to check that your data payload is correct. Everyone knows that a router/gateway/switch with a sticky bit in its memory will recompute the net crc16 checksum insure it pass the to the nic regardless. It is amazing how much data can be corrupted by a network environment via all the NFS/NBD/etc wantabie storage products out there. Just a chuckle for you to ponder. --a On Sun, 3 Aug 2003, Jeff Garzik wrote: > Werner Almesberger wrote: > > Jeff Garzik wrote: > > > >>jabbering at the same time. TCP is a "one size fits all" solution, but > >>it doesn't work well for everyone. > > > > > > But then, ten "optimized xxPs" that work well in two different > > scenarios each, but not so good in the 98 others, wouldn't be > > much fun either. > > > > It's been tried a number of times. Usually, real life sneaks > > in at one point or another, leaving behind a complex mess. > > When they've sorted out these problems, regular TCP has caught > > up with the great optimized transport protocols. At that point, > > they return to their niche, sometimes tail between legs and > > muttering curses, sometimes shaking their fist and boldly > > proclaiming how badly they'll rub TCP in the dirt in the next > > round. Maybe they shed off some of the complexity, and trade it > > for even more aggressive optimization, which puts them into > > their niche even more firmly. Eventually, they fade away. > > > > There are cases where TCP doesn't work well, like a path of > > badly mismatched link layers, but such paths don't treat any > > protocol following the end-to-end principle kindly. > > > > Another problem of TCP is that it has grown a bit too many > > knobs you need to turn before it works over your really fast > > really long pipe. (In one of the OLS after dinner speeches, > > this was quite appropriately called the "wizard gap".) > > > > > >>It's obviously not over a WAN... > > > > > > That's why NFS turned off UDP checksums ;-) As soon as you put > > it on IP, it will crawl to distances you didn't imagine in your > > wildest dreams. It always does. > > Really fast, really long pipes in practice don't exist for 99.9% of all > Internet users. > > > When you approach traffic levels that push you want to offload most of > the TCP net stack, then TCP isn't the right solution for you anymore, > all things considered. > > > The Linux net stack just isn't built to be offloaded. TOE engines will > either need to (1) fall back to Linux software for all-but-the-common > case (otherwise netfilter, etc. break), or, (2) will need to be > hideously complex beasts themselves. And I can't see ASIC and firmware > designers being excited about implementing netfilter on a PCI card :) > > Unfortunately some vendors seem to choosing TOE option #3: TCP offload > which introduces many limitations (connection limits, netfilter not > supported, etc.) which Linux never had before. Vendors don't seem to > realize TOE has real potential to damage the "good network neighbor" > image the net stack has. The Linux net stack's behavior is known, > documented, predictable. TOE changes all that. > > There is one interesting TOE solution, that I have yet to see created: > run Linux on an embedded processor, on the NIC. This stripped-down > Linux kernel would perform all the header parsing, checksumming, etc. > into the NIC's local RAM. The Linux OS driver interface becomes a > virtual interface with a large MTU, that communicates from host CPU to > NIC across the PCI bus using jumbo-ethernet-like data frames. > Management frames would control the ethernet interface on the other side > of the PCI bus "tunnel". > > > >>So, fix the other end of the pipeline too, otherwise this fast network > >>stuff is flashly but pointless. If you want to serve up data from disk, > >>then start creating PCI cards that have both Serial ATA and ethernet > >>connectors on them :) Cut out the middleman of the host CPU and host > >>memory bus instead of offloading portions of TCP that do not need to be > >>offloaded. > > > > > > That's a good point. A hierarchical memory structure can help > > here. Moving one end closer to the hardware, and letting it > > know (e.g. through sendfile) that also the other end is close > > (or can be reached more directly that through some hopelessly > > crowded main bus) may help too. > > Definitely. > > Jeff > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > From kazunori@miyazawa.org Wed Aug 6 00:27:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 00:28:02 -0700 (PDT) Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h767RqFl031930 for ; Wed, 6 Aug 2003 00:27:54 -0700 Received: from monza.miyazawa.org ([::ffff:203.178.141.107]) (AUTH: LOGIN kazunori, ) by miyazawa.org with esmtp; Wed, 06 Aug 2003 16:20:16 +0900 Date: Wed, 6 Aug 2003 16:28:08 +0900 From: Kazunori Miyazawa To: davem@redhat.com, kuznet@ms2.inr.ac.ru Cc: netdev@oss.sgi.com, usagi@linux-ipv6.org, latten@austin.ibm.com Subject: [PATCH][IPV6] fix clearing in ah6 input Message-Id: <20030806162808.4edf9eeb.kazunori@miyazawa.org> X-Mailer: Sylpheed version 0.9.3 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4573 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kazunori@miyazawa.org Precedence: bulk X-list: netdev Hello, This patch fixes zero-clear in ah6_input. If calling pskb_expand_head, the kernel clears wrong memory. This patch is against linux-2.6.0-test2 Best regards, diff -ruN a/net/ipv6/ah6.c b/net/ipv6/ah6.c --- a/net/ipv6/ah6.c 2003-07-28 02:05:05.000000000 +0900 +++ b/net/ipv6/ah6.c 2003-08-06 12:57:19.000000000 +0900 @@ -262,13 +262,12 @@ * There is offset of AH before IPv6 header after the process. */ - struct ipv6hdr *iph = skb->nh.ipv6h; struct ipv6_auth_hdr *ah; struct ah_data *ahp; unsigned char *tmp_hdr = NULL; - u16 hdr_len = skb->data - skb->nh.raw; + u16 hdr_len; u16 ah_hlen; - u16 cleared_hlen = hdr_len; + u16 cleared_hlen; u16 nh_offset = 0; u8 nexthdr = 0; u8 *prevhdr; @@ -276,6 +275,14 @@ if (!pskb_may_pull(skb, sizeof(struct ip_auth_hdr))) goto out; + /* We are going to _remove_ AH header to keep sockets happy, + * so... Later this can change. */ + if (skb_cloned(skb) && + pskb_expand_head(skb, 0, 0, GFP_ATOMIC)) + goto out; + + hdr_len = skb->data - skb->nh.raw; + cleared_hlen = hdr_len; ah = (struct ipv6_auth_hdr*)skb->data; ahp = x->data; nexthdr = ah->nexthdr; @@ -294,27 +301,22 @@ if (!pskb_may_pull(skb, ah_hlen)) goto out; - /* We are going to _remove_ AH header to keep sockets happy, - * so... Later this can change. */ - if (skb_cloned(skb) && - pskb_expand_head(skb, 0, 0, GFP_ATOMIC)) - goto out; - tmp_hdr = kmalloc(cleared_hlen, GFP_ATOMIC); if (!tmp_hdr) goto out; memcpy(tmp_hdr, skb->nh.raw, cleared_hlen); ipv6_clear_mutable_options(skb, &nh_offset, XFRM_POLICY_IN); - iph->priority = 0; - iph->flow_lbl[0] = 0; - iph->flow_lbl[1] = 0; - iph->flow_lbl[2] = 0; - iph->hop_limit = 0; + skb->nh.ipv6h->priority = 0; + skb->nh.ipv6h->flow_lbl[0] = 0; + skb->nh.ipv6h->flow_lbl[1] = 0; + skb->nh.ipv6h->flow_lbl[2] = 0; + skb->nh.ipv6h->hop_limit = 0; { u8 auth_data[ahp->icv_trunc_len]; memcpy(auth_data, ah->auth_data, ahp->icv_trunc_len); + memset(ah->auth_data, 0, ahp->icv_trunc_len); skb_push(skb, skb->data - skb->nh.raw); ahp->icv(ahp, skb, ah->auth_data); if (memcmp(ah->auth_data, auth_data, ahp->icv_trunc_len)) { From kazunori@miyazawa.org Wed Aug 6 00:43:52 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 00:44:00 -0700 (PDT) Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h767hpFl000755 for ; Wed, 6 Aug 2003 00:43:52 -0700 Received: from monza.miyazawa.org ([::ffff:203.178.141.107]) (AUTH: LOGIN kazunori, ) by miyazawa.org with esmtp; Wed, 06 Aug 2003 16:36:15 +0900 Date: Wed, 6 Aug 2003 16:44:13 +0900 From: Kazunori Miyazawa To: davem@redhat.com, kuznet@ms2.inr.ac.ru Cc: netdev@oss.sgi.com, usagi@linux-ipv6.org, latten@austin.ibm.com Subject: [PATCH][IPV6] fixed authentication error with TCP Message-Id: <20030806164413.669ef5f8.kazunori@miyazawa.org> X-Mailer: Sylpheed version 0.9.3 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4574 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kazunori@miyazawa.org Precedence: bulk X-list: netdev Hello, Miss Joy (@IBM) and I investigated the bug that "authentication error" occured with using TCP and AH in IPv6. This patch fixes the bug. This patch makes the kernel consider extension header length in a dst. This pach works with my previous patch which fixes zero-clear in ah6_input. Please append the name "Joy Latten" into the log. #I'm in summer holidays until 10th August. I will response very slowly because I only have dial-up line with 30kbps :-p Best regards, diff -ruN a/include/net/ipv6.h b/include/net/ipv6.h --- a/include/net/ipv6.h 2003-07-28 02:07:24.000000000 +0900 +++ b/include/net/ipv6.h 2003-08-06 14:10:36.000000000 +0900 @@ -353,9 +353,7 @@ extern void ip6_flush_pending_frames(struct sock *sk); -extern int ip6_dst_lookup(struct sock *sk, - struct dst_entry **dst, - struct flowi *fl); +extern struct dst_entry * ip6_dst_lookup(struct sock *sk, struct flowi *fl); /* * skb processing functions diff -ruN a/net/ipv6/icmp.c b/net/ipv6/icmp.c --- a/net/ipv6/icmp.c 2003-07-28 01:59:40.000000000 +0900 +++ b/net/ipv6/icmp.c 2003-08-06 14:20:29.000000000 +0900 @@ -355,8 +355,8 @@ if (!fl.oif && ipv6_addr_is_multicast(&fl.fl6_dst)) fl.oif = np->mcast_oif; - err = ip6_dst_lookup(sk, &dst, &fl); - if (err) goto out; + dst = ip6_dst_lookup(sk, &fl); + if (dst->error) goto out; if (hlimit < 0) { if (ipv6_addr_is_multicast(&fl.fl6_dst)) @@ -434,9 +434,9 @@ if (!fl.oif && ipv6_addr_is_multicast(&fl.fl6_dst)) fl.oif = np->mcast_oif; - err = ip6_dst_lookup(sk, &dst, &fl); + dst = ip6_dst_lookup(sk, &fl); - if (err) goto out; + if (dst->error) goto out; if (hlimit < 0) { if (ipv6_addr_is_multicast(&fl.fl6_dst)) diff -ruN a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c --- a/net/ipv6/ip6_output.c 2003-07-28 01:57:01.000000000 +0900 +++ b/net/ipv6/ip6_output.c 2003-08-06 15:35:23.000000000 +0900 @@ -211,10 +211,6 @@ u32 mtu; int err = 0; - if ((err = xfrm_lookup(&skb->dst, fl, sk, 0)) < 0) { - return err; - } - if (opt) { int head_room; @@ -1141,72 +1137,73 @@ return err; } -int ip6_dst_lookup(struct sock *sk, struct dst_entry **dst, struct flowi *fl) +struct dst_entry *ip6_dst_lookup(struct sock *sk, struct flowi *fl) { - struct ipv6_pinfo *np = inet6_sk(sk); + struct dst_entry *dst = NULL; int err = 0; - *dst = __sk_dst_check(sk, np->dst_cookie); - if (*dst) { - struct rt6_info *rt = (struct rt6_info*)*dst; - - /* Yes, checking route validity in not connected - case is not very simple. Take into account, - that we do not support routing by source, TOS, - and MSG_DONTROUTE --ANK (980726) - - 1. If route was host route, check that - cached destination is current. - If it is network route, we still may - check its validity using saved pointer - to the last used address: daddr_cache. - We do not want to save whole address now, - (because main consumer of this service - is tcp, which has not this problem), - so that the last trick works only on connected - sockets. - 2. oif also should be the same. - */ - - if (((rt->rt6i_dst.plen != 128 || - ipv6_addr_cmp(&fl->fl6_dst, &rt->rt6i_dst.addr)) - && (np->daddr_cache == NULL || - ipv6_addr_cmp(&fl->fl6_dst, np->daddr_cache))) - || (fl->oif && fl->oif != (*dst)->dev->ifindex)) { - *dst = NULL; - } else - dst_hold(*dst); + if (sk) { + struct ipv6_pinfo *np = inet6_sk(sk); + + dst = __sk_dst_check(sk, np->dst_cookie); + if (dst) { + struct rt6_info *rt = (struct rt6_info*)dst; + + /* Yes, checking route validity in not connected + case is not very simple. Take into account, + that we do not support routing by source, TOS, + and MSG_DONTROUTE --ANK (980726) + + 1. If route was host route, check that + cached destination is current. + If it is network route, we still may + check its validity using saved pointer + to the last used address: daddr_cache. + We do not want to save whole address now, + (because main consumer of this service + is tcp, which has not this problem), + so that the last trick works only on connected + sockets. + 2. oif also should be the same. + */ + + if (((rt->rt6i_dst.plen != 128 || + ipv6_addr_cmp(&fl->fl6_dst, &rt->rt6i_dst.addr)) + && (np->daddr_cache == NULL || + ipv6_addr_cmp(&fl->fl6_dst, np->daddr_cache))) + || (fl->oif && fl->oif != dst->dev->ifindex)) { + dst = NULL; + } else + dst_hold(dst); + } } - if (*dst == NULL) - *dst = ip6_route_output(sk, fl); + if (dst == NULL) + dst = ip6_route_output(sk, fl); - if ((*dst)->error) { - IP6_INC_STATS(Ip6OutNoRoutes); - dst_release(*dst); - return -ENETUNREACH; - } + if (dst->error) + return dst; if (ipv6_addr_any(&fl->fl6_src)) { - err = ipv6_get_saddr(*dst, &fl->fl6_dst, &fl->fl6_src); + err = ipv6_get_saddr(dst, &fl->fl6_dst, &fl->fl6_src); if (err) { #if IP6_DEBUG >= 2 printk(KERN_DEBUG "ip6_build_xmit: " "no available source address\n"); #endif - return err; + dst->error = err; + return dst; } } - if (*dst) { - if ((err = xfrm_lookup(dst, fl, sk, 0)) < 0) { - dst_release(*dst); - return -ENETUNREACH; + if (dst) { + if ((err = xfrm_lookup(&dst, fl, sk, 0)) < 0) { + dst->error = -ENETUNREACH; } } - return 0; + return dst; } int ip6_append_data(struct sock *sk, int getfrag(void *from, char *to, int offset, int len, int odd, struct sk_buff *skb), diff -ruN a/net/ipv6/raw.c b/net/ipv6/raw.c --- a/net/ipv6/raw.c 2003-07-28 02:00:40.000000000 +0900 +++ b/net/ipv6/raw.c 2003-08-06 14:19:32.000000000 +0900 @@ -658,8 +658,8 @@ if (!fl.oif && ipv6_addr_is_multicast(&fl.fl6_dst)) fl.oif = np->mcast_oif; - err = ip6_dst_lookup(sk, &dst, &fl); - if (err) + dst = ip6_dst_lookup(sk, &fl); + if (dst->error) goto out; if (hlimit < 0) { diff -ruN a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c --- a/net/ipv6/tcp_ipv6.c 2003-07-28 02:03:09.000000000 +0900 +++ b/net/ipv6/tcp_ipv6.c 2003-08-06 16:13:21.000000000 +0900 @@ -663,7 +663,7 @@ ipv6_addr_copy(&fl.fl6_dst, rt0->addr); } - dst = ip6_route_output(sk, &fl); + dst = ip6_dst_lookup(sk, &fl); if ((err = dst->error) != 0) { dst_release(dst); @@ -691,6 +691,8 @@ tp->ext_header_len = 0; if (np->opt) tp->ext_header_len = np->opt->opt_flen + np->opt->opt_nflen; + tp->ext2_header_len = dst->header_len; + tp->mss_clamp = IPV6_MIN_MTU - sizeof(struct tcphdr) - sizeof(struct ipv6hdr); inet->dport = usin->sin6_port; @@ -788,7 +790,7 @@ fl.fl_ip_dport = inet->dport; fl.fl_ip_sport = inet->sport; - dst = ip6_route_output(sk, &fl); + dst = ip6_dst_lookup(sk, &fl); } else dst_hold(dst); @@ -889,7 +891,7 @@ ipv6_addr_copy(&fl.fl6_dst, rt0->addr); } - dst = ip6_route_output(sk, &fl); + dst = ip6_dst_lookup(sk, &fl); if (dst->error) goto done; } @@ -1018,7 +1020,7 @@ fl.fl_ip_sport = t1->source; /* sk = NULL, but it is safe for now. RST socket required. */ - buff->dst = ip6_route_output(NULL, &fl); + buff->dst = ip6_dst_lookup(NULL, &fl); if (buff->dst->error == 0) { ip6_xmit(NULL, buff, &fl, NULL, 0); @@ -1081,7 +1083,7 @@ fl.fl_ip_dport = t1->dest; fl.fl_ip_sport = t1->source; - buff->dst = ip6_route_output(NULL, &fl); + buff->dst = ip6_dst_lookup(NULL, &fl); if (buff->dst->error == 0) { ip6_xmit(NULL, buff, &fl, NULL, 0); @@ -1329,7 +1331,7 @@ fl.fl_ip_dport = req->rmt_port; fl.fl_ip_sport = inet_sk(sk)->sport; - dst = ip6_route_output(sk, &fl); + dst = ip6_dst_lookup(sk, &fl); } if (dst->error) @@ -1401,6 +1403,7 @@ if (newnp->opt) newtp->ext_header_len = newnp->opt->opt_nflen + newnp->opt->opt_flen; + newtp->ext2_header_len = dst->header_len; tcp_sync_mss(newsk, dst_pmtu(dst)); newtp->advmss = dst_metric(dst, RTAX_ADVMSS); @@ -1727,7 +1730,7 @@ ipv6_addr_copy(&fl.fl6_dst, rt0->addr); } - dst = ip6_route_output(sk, &fl); + dst = ip6_dst_lookup(sk, &fl); if (dst->error) { err = dst->error; @@ -1770,7 +1773,7 @@ dst = __sk_dst_check(sk, np->dst_cookie); if (dst == NULL) { - dst = ip6_route_output(sk, &fl); + dst = ip6_dst_lookup(sk, &fl); if (dst->error) { sk->sk_err_soft = -dst->error; diff -ruN a/net/ipv6/udp.c b/net/ipv6/udp.c --- a/net/ipv6/udp.c 2003-07-28 02:07:29.000000000 +0900 +++ b/net/ipv6/udp.c 2003-08-06 14:19:23.000000000 +0900 @@ -928,8 +928,8 @@ if (!fl.oif && ipv6_addr_is_multicast(&fl.fl6_dst)) fl.oif = np->mcast_oif; - err = ip6_dst_lookup(sk, &dst, &fl); - if (err) + dst = ip6_dst_lookup(sk, &fl); + if (dst->error) goto out; if (hlimit < 0) { From davem@redhat.com Wed Aug 6 00:57:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 00:57:45 -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 h767vdFl001909 for ; Wed, 6 Aug 2003 00:57:40 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id AAA24739; Wed, 6 Aug 2003 00:52:24 -0700 Date: Wed, 6 Aug 2003 00:52:24 -0700 From: "David S. Miller" To: Robert Olsson Cc: kuznet@ms2.inr.ac.ru, Robert.Olsson@data.slu.se, netdev@oss.sgi.com Subject: Re: [PATCH] repairing rtcache killer Message-Id: <20030806005224.4798f744.davem@redhat.com> In-Reply-To: <16175.58503.134543.310459@robur.slu.se> References: <200308051340.RAA28267@dub.inr.ac.ru> <16175.58503.134543.310459@robur.slu.se> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4575 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 5 Aug 2003 19:08:23 +0200 Robert Olsson wrote: > > kuznet@ms2.inr.ac.ru writes: > > # Two serious and interesting mistakes were made in the patch of 2003-06-16. Mama mia! This patch exists in 2.4.22-preX too, so full fix becomes more urgent. > For autotuning I think we can have help from a ratio of warm cache > hits (in_hit) and misses (in_slow_tot) to set threshhold to trim > hash chain lengths. Yes, I agree, and algorithm can be even not too smart, something like the following. Before scan loop, we compute: in_hit = in_slow_tot = 0; for (i = 0; i < NR_CPUS; i++) { if (!cpu_possible(i)) continue; in_hit += per_cpu_ptr(rt_cache_stat, i)->in_hit; in_slow_tot += per_cpu_ptr(rt_cache_stat, i)->in_slow_tot; } aggressive = 0; if (in_hit < (in_slow_tot >> 2)) aggressive = 1; thresh = ip_rt_gc_elasticity; if (!aggressive) thresh <<= 1; Then the purging test becomes: if (chain_length > thresh || (aggressive && chain_length > 1 && !(min_score & (1<<31)))) { *candp = cand->u.rt_next; rt_free(cand); } To make algorithm cheaper, we can even use only the current cpu's rt_cache_stat in order to make our decisions about whether to enter agressive mode or not. Alexey, given all this what would you like to do? Should I push your patch urgently into 2.4.x or spend some more time trying to solve this issue? From ebiederm@xmission.com Wed Aug 6 01:02:23 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 01:02:27 -0700 (PDT) Received: from frodo.biederman.org (ebiederm.dsl.xmission.com [166.70.28.69]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7682MFl002543 for ; Wed, 6 Aug 2003 01:02:23 -0700 Received: (from eric@localhost) by frodo.biederman.org (8.9.3/8.9.3) id BAA09468; Wed, 6 Aug 2003 01:58:56 -0600 To: Werner Almesberger Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: TOE brain dump References: <20030802140444.E5798@almesberger.net> <3F2BF5C7.90400@us.ibm.com> <3F2C0C44.6020002@pobox.com> <20030802184901.G5798@almesberger.net> <20030804162433.L5798@almesberger.net> <20030806021304.E5798@almesberger.net> From: ebiederm@xmission.com (Eric W. Biederman) Date: 06 Aug 2003 01:58:56 -0600 In-Reply-To: <20030806021304.E5798@almesberger.net> Message-ID: Lines: 63 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4576 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ebiederm@xmission.com Precedence: bulk X-list: netdev Werner Almesberger writes: > Eric W. Biederman wrote: > > MPI is not a transport. It an interface like the Berkeley sockets > > layer. > > Hmm, but doesn't it also unify transport semantics (i.e. chop > TCP streams into messages), maybe add reliability to transports > that don't have it, and provide addressing ? Okay, perhaps you > wouldn't call this a transport in the OSI sense, but it still > seems to have considerably more functionality than just > providing an API. Those are all features of the MPI implementation. It is not that MPI does not have an underlying transport. MPI has a lot of underlying transports. And there is a different MPI implementation for each transport. Although a lot of them start with a common base. > > Mostly I think the that is less true, at least if they can stand the > > process of severe code review and cleaning up their code. > > Hmm, people putting dozens of millions into building clusters > can't afford to have what is probably their most essential > infrastructure code reviewed and cleaned up ? Oh dear. Afford, they can do. A lot of the users are researchers and a lot of people doing the code are researchers. So corralling them up and getting production quality code can be a challenge, or getting them to take small enough steps that they don't frighten the rest of the world. Plus ten million dollars pretty much buys you a spot in the top 10 of the top 500 supercomputers. The bulk of the clusters are a lot less expensive than that. > > But of course to get through the peer review process people need > > to understand what they are doing. > > A good point :-) > > > So store and forward of packets in a 3 layer switch hierarchy, at 1.3 us > > per copy. > > But your switch could just do cut-through, no ? Or do they > need to recompute checksums ? Correct, switches can and generally do implement cut-through in that kind of environment. I was just showing that even at 10Gbps treating a packet as an atomic unit has issues. cut-through is necessary to keep your latency down. Do any ethernet switches do cut-through? > > A lot of the NICs which are used for MPI tend to be smart for two > > reasons. 1) So they can do source routing. 2) So they can safely > > export some of their interface to user space, so in the fast path > > they can bypass the kernel. > > The second part could be interesting for TOE, too. Only that > the interface exported would just be the socket interface. Agreed. Eric From klein@SANRAD.COM Wed Aug 6 01:07:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 01:07:33 -0700 (PDT) Received: from SANSRV1.SAN-RAD.CO.IL ([80.74.102.50]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7686mFl003584 for ; Wed, 6 Aug 2003 01:07:16 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: iSCSI driver for SGI X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 6 Aug 2003 11:08:25 +0300 Message-ID: <838D8D2617300146B7F47E4D9AE7FF1086F746@SANSRV1.SAN-RAD.CO.IL> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: iSCSI driver for SGI Thread-Index: AcNb8gqC4BtDU4xtSu2129FQuoH5cg== From: "Yaron Klein" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7686mFl003584 X-archive-position: 4577 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: klein@SANRAD.COM Precedence: bulk X-list: netdev Hi there, My name is Yaron Klein and I m the Technical Lead of Sanrad (www.sanrad.com). We manufacture iSCSI switches with virtualization capabilities. We have several clients with SGI servers that would like to connect them to our switch. Is there any iSCSI driver for SGI servers? Do you know of any company that distributes such driver? Thanks Yaron Klein Sanrad From ltd@cisco.com Wed Aug 6 01:20:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 01:20:35 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h768KOFl004789 for ; Wed, 6 Aug 2003 01:20:24 -0700 Received: from cisco.com (64.104.193.198) by sj-iport-2.cisco.com with ESMTP; 06 Aug 2003 01:24:53 -0700 Received: from cisco.com (localhost [127.0.0.1]) by syd-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h768KFQt008150; Wed, 6 Aug 2003 18:20:15 +1000 (EST) Received: from ltd-t30.cisco.com (syd-vpn-client-255-68.cisco.com [10.66.255.68]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id SAA25057; Wed, 6 Aug 2003 18:24:31 +1000 (EST) Message-Id: <5.1.0.14.2.20030806181359.02bf9570@mira-sjcm-3.cisco.com> X-Sender: ltd@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 06 Aug 2003 18:20:06 +1000 To: Andre Hedrick From: Lincoln Dale Subject: Re: TOE brain dump Cc: Jeff Garzik , netdev@oss.sgi.com, linux-kernel@vger.kernel.org, Werner Almesberger , Nivedita Singhvi In-Reply-To: References: <3F2CAE61.7070401@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 4578 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ltd@cisco.com Precedence: bulk X-list: netdev At 05:12 PM 6/08/2003, Andre Hedrick wrote: >Do be sure to check that your data payload is correct. >Everyone knows that a router/gateway/switch with a sticky bit in its >memory will recompute the net crc16 checksum insure it pass the to the nic >regardless. It is amazing how much data can be corrupted by a network >environment via all the NFS/NBD/etc wantabie storage products out there. Andre, you are wrong. firstly, do you REALLY think that most router(s)/switch(es) out there recompute IP checksums because they did a IP TTL decrement when routing an IP packet or NAT IP addresses? no, they don't. just like netfilter or router-on-linux is smart enough to be able to re-code an IP checksum by unmasking and re-masking the old/new values in a header, so does the most router vendor's code. secondly, why would a router or switch even be touching the data at layer-4 (TCP), let alone recalculating a CRC? i know you really like your "we do ERL 2 in iSCSI" pitch, but lets stick to facts here eh? cheers, lincoln. From davem@redhat.com Wed Aug 6 01:27:05 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 01:27:11 -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 h768R4Fl005507 for ; Wed, 6 Aug 2003 01:27:05 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id BAA24823; Wed, 6 Aug 2003 01:22:18 -0700 Date: Wed, 6 Aug 2003 01:22:18 -0700 From: "David S. Miller" To: Lincoln Dale Cc: andre@linux-ide.org, jgarzik@pobox.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, werner@almesberger.net, niv@us.ibm.com Subject: Re: TOE brain dump Message-Id: <20030806012218.4012d9e4.davem@redhat.com> In-Reply-To: <5.1.0.14.2.20030806181359.02bf9570@mira-sjcm-3.cisco.com> References: <3F2CAE61.7070401@pobox.com> <5.1.0.14.2.20030806181359.02bf9570@mira-sjcm-3.cisco.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4579 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 06 Aug 2003 18:20:06 +1000 Lincoln Dale wrote: > secondly, why would a router or switch even be touching the data at layer-4 > (TCP), let alone recalculating a CRC? To make sure emails about Falun Gong and other undesirable topics don't make it into China. From yoshfuji@linux-ipv6.org Wed Aug 6 03:28:20 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 03:28:38 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76ASIFl014451 for ; Wed, 6 Aug 2003 03:28:19 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h76ASO1M013276; Wed, 6 Aug 2003 19:28:24 +0900 Date: Wed, 06 Aug 2003 19:28:24 +0900 (JST) Message-Id: <20030806.192824.129498139.yoshfuji@linux-ipv6.org> To: vnuorval@tcs.hut.fi Cc: netdev@oss.sgi.com, usagi-core@linux-ipv6.org Subject: Re: (usagi-core 14846) [PATCH] IPv6: No fragmentation of packets with length <= mtu From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4580 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article (at Wed, 6 Aug 2003 13:00:41 +0300 (EEST)), Ville Nuorvala says: > I noticed ip6_append_data() always reserves space for the fragment header > at the cost of the payload data. This leads to the unnecessary > fragmentation of packets with lengths close (or equal) to the link-mtu. > This can for example be seen with ping6 -s 1448 (on an ethernet link). > > My attached patch _seems_ to fix the problem without breaking anything > else, but can you still verify this? Well, your patch breaks something; the idea of append_data. User may "push" multiple times to generate a packet. I'm chasing this bug. Since this bug is not grave, we do not need to fix this ASAP; We need to fix a grave issue with UDPv6 with MSG_MORE flag before this. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From vnuorval@tcs.hut.fi Wed Aug 6 03:36:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 03:36:56 -0700 (PDT) Received: from mail.tcs.hut.fi (mail.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76AadFl014813 for ; Wed, 6 Aug 2003 03:36:40 -0700 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by mail.tcs.hut.fi (Postfix) with ESMTP id 886078001E3; Wed, 6 Aug 2003 13:00:42 +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 h76A0g5L001820; Wed, 6 Aug 2003 13:00:42 +0300 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-5) with ESMTP id h76A0fT0001816; Wed, 6 Aug 2003 13:00:42 +0300 Date: Wed, 6 Aug 2003 13:00:41 +0300 (EEST) From: Ville Nuorvala To: usagi-core@linux-ipv6.org Cc: netdev@oss.sgi.com Subject: [PATCH] IPv6: No fragmentation of packets with length <= mtu Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-377318441-1293612270-1060158514=:1401" Content-ID: X-archive-position: 4581 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---377318441-1293612270-1060158514=:1401 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Hi guys, I noticed ip6_append_data() always reserves space for the fragment header at the cost of the payload data. This leads to the unnecessary fragmentation of packets with lengths close (or equal) to the link-mtu. This can for example be seen with ping6 -s 1448 (on an ethernet link). My attached patch _seems_ to fix the problem without breaking anything else, but can you still verify this? Thanks, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 ---377318441-1293612270-1060158514=:1401 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="ip6_output_frag.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="ip6_output_frag.patch" LS0tIGxpbnV4LTIuNS5PTEQvbmV0L2lwdjYvaXA2X291dHB1dC5jCTIwMDMt MDgtMDUgMTU6MTU6MDcuMDAwMDAwMDAwICswMzAwDQorKysgbGludXgtMi41 L25ldC9pcHY2L2lwNl9vdXRwdXQuYwkyMDAzLTA4LTA2IDExOjI3OjM4LjAw MDAwMDAwMCArMDMwMA0KQEAgLTEyMTcsNyArMTIxNyw3IEBADQogCXN0cnVj dCBpbmV0X29wdCAqaW5ldCA9IGluZXRfc2soc2spOw0KIAlzdHJ1Y3QgaXB2 Nl9waW5mbyAqbnAgPSBpbmV0Nl9zayhzayk7DQogCXN0cnVjdCBza19idWZm ICpza2I7DQotCXVuc2lnbmVkIGludCBtYXhmcmFnbGVuLCBmcmFnaGVhZGVy bGVuOw0KKwl1bnNpZ25lZCBpbnQgbWF4ZnJhZ2xlbiwgZnJhZ2hlYWRlcmxl biwgeHRyYV9maF9sZW47DQogCWludCBleHRoZHJsZW47DQogCWludCBoaF9s ZW47DQogCWludCBtdHU7DQpAQCAtMTI2Myw3ICsxMjYzLDEyIEBADQogCWho X2xlbiA9IChydC0+dS5kc3QuZGV2LT5oYXJkX2hlYWRlcl9sZW4mfjE1KSAr IDE2Ow0KIA0KIAlmcmFnaGVhZGVybGVuID0gc2l6ZW9mKHN0cnVjdCBpcHY2 aGRyKSArIChvcHQgPyBvcHQtPm9wdF9uZmxlbiA6IDApOw0KLQltYXhmcmFn bGVuID0gKChtdHUgLSBmcmFnaGVhZGVybGVuKSAmIH43KSArIGZyYWdoZWFk ZXJsZW4gLSBzaXplb2Yoc3RydWN0IGZyYWdfaGRyKTsNCisJbWF4ZnJhZ2xl biA9ICgobXR1IC0gZnJhZ2hlYWRlcmxlbikgJiB+NykgKyBmcmFnaGVhZGVy bGVuOw0KKw0KKwkvKiBPbmx5IHJlc2VydmUgc3BhY2UgZm9yIGZyYWdfaGRy IGlmIHRoZSBwYWNrZXQgd2lsbCBiZSBmcmFnbWVudGVkICovDQorCXh0cmFf ZmhfbGVuID0gKGxlbmd0aCA+IG1heGZyYWdsZW4gPyBzaXplb2Yoc3RydWN0 IGZyYWdfaGRyKSA6IDApOw0KKw0KKwltYXhmcmFnbGVuIC09IHh0cmFfZmhf bGVuOw0KIA0KIAlpZiAobXR1IDw9IHNpemVvZihzdHJ1Y3QgaXB2Nmhkcikg KyBJUFY2X01BWFBMRU4pIHsNCiAJCWlmIChpbmV0LT5jb3JrLmxlbmd0aCAr IGxlbmd0aCA+IHNpemVvZihzdHJ1Y3QgaXB2NmhkcikgKyBJUFY2X01BWFBM RU4gLSBmcmFnaGVhZGVybGVuKSB7DQpAQCAtMTI5NCw3ICsxMjk5LDcgQEAN CiAJCQkJYWxsb2NsZW4gPSBtYXhmcmFnbGVuOw0KIAkJCWVsc2UNCiAJCQkJ YWxsb2NsZW4gPSBmcmFnbGVuOw0KLQkJCWFsbG9jbGVuICs9IHNpemVvZihz dHJ1Y3QgZnJhZ19oZHIpOw0KKwkJCWFsbG9jbGVuICs9IHh0cmFfZmhfbGVu Ow0KIAkJCWlmICh0cmFuc2hkcmxlbikgew0KIAkJCQlza2IgPSBzb2NrX2Fs bG9jX3NlbmRfc2tiKHNrLA0KIAkJCQkJCWFsbG9jbGVuICsgaGhfbGVuICsg MTUsDQpAQCAtMTMxNyw3ICsxMzIyLDcgQEANCiAJCQlza2ItPmlwX3N1bW1l ZCA9IGNzdW1tb2RlOw0KIAkJCXNrYi0+Y3N1bSA9IDA7DQogCQkJLyogcmVz ZXJ2ZSA4IGJ5dGUgZm9yIGZyYWdtZW50YXRpb24gKi8NCi0JCQlza2JfcmVz ZXJ2ZShza2IsIGhoX2xlbitzaXplb2Yoc3RydWN0IGZyYWdfaGRyKSk7DQor CQkJc2tiX3Jlc2VydmUoc2tiLCBoaF9sZW4gKyB4dHJhX2ZoX2xlbik7DQog DQogCQkJLyoNCiAJCQkgKglGaW5kIHdoZXJlIHRvIHN0YXJ0IHB1dHRpbmcg Ynl0ZXMNCg== ---377318441-1293612270-1060158514=:1401-- From davem@redhat.com Wed Aug 6 03:51:21 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 03:51:29 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76ApKFl015260 for ; Wed, 6 Aug 2003 03:51:21 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id DAA24968; Wed, 6 Aug 2003 03:46:43 -0700 Date: Wed, 6 Aug 2003 03:46:42 -0700 From: "David S. Miller" To: Ben Greear Cc: netdev@oss.sgi.com Subject: Re: PATCH: Add comment to make finding the priv_flags definition easier. Message-Id: <20030806034642.4d91641c.davem@redhat.com> In-Reply-To: <3F304AC7.6070808@candelatech.com> References: <3F304AC7.6070808@candelatech.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4582 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 05 Aug 2003 17:24:39 -0700 Ben Greear wrote: > This helps me, at least, remember where the definitions are at! This is silly, adding one for 'priv_flags' and not one for 'flags'. I really don't have a taste for these "look in file foo for interesting stuff about bar" type comments :-) From vnuorval@tcs.hut.fi Wed Aug 6 04:43:30 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 04:43:38 -0700 (PDT) Received: from mail.tcs.hut.fi (mail.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76BhIFl016836 for ; Wed, 6 Aug 2003 04:43:19 -0700 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by mail.tcs.hut.fi (Postfix) with ESMTP id 693528001BC; Wed, 6 Aug 2003 14:00:21 +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 h76B0L5L002021; Wed, 6 Aug 2003 14:00:21 +0300 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-5) with ESMTP id h76B0LXF002017; Wed, 6 Aug 2003 14:00:21 +0300 Date: Wed, 6 Aug 2003 14:00:21 +0300 (EEST) From: Ville Nuorvala To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Cc: netdev@oss.sgi.com, Subject: Re: (usagi-core 14846) [PATCH] IPv6: No fragmentation of packets with length <= mtu In-Reply-To: <20030806.192824.129498139.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-15 X-archive-position: 4583 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 Wed, 6 Aug 2003, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote: > Well, your patch breaks something; the idea of append_data. > User may "push" multiple times to generate a packet. Yeah, I thought there might be something like this, since I'm not yet that familiar with the new fragmentation code. :) > I'm chasing this bug. > Since this bug is not grave, we do not need to fix this ASAP; > We need to fix a grave issue with UDPv6 with MSG_MORE flag > before this. No problem. Regards, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From jesse@cats-chateau.net Wed Aug 6 05:47:12 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 05:47:25 -0700 (PDT) Received: from tabby.cats.internal (34.mufa.noln.chcgil24.dsl.att.net [12.100.181.34]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76ClBFl017849 for ; Wed, 6 Aug 2003 05:47:12 -0700 Received: from localhost (localhost [[UNIX: localhost]]) by tabby.cats.internal (8.11.4/8.11.4) id h76CkuR08429; Wed, 6 Aug 2003 07:46:56 -0500 Content-Type: text/plain; charset="iso-8859-1" From: Jesse Pollard To: ebiederm@xmission.com (Eric W. Biederman), Werner Almesberger Subject: Re: TOE brain dump Date: Wed, 6 Aug 2003 07:46:33 -0500 X-Mailer: KMail [version 1.2] Cc: Jeff Garzik , Nivedita Singhvi , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20030802140444.E5798@almesberger.net> <20030804162433.L5798@almesberger.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <03080607463300.08387@tabby> Content-Transfer-Encoding: 8bit X-archive-position: 4584 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jesse@cats-chateau.net Precedence: bulk X-list: netdev On Tuesday 05 August 2003 12:19, Eric W. Biederman wrote: > Werner Almesberger writes: > > Eric W. Biederman wrote: > > > The optimized for low latency cases seem to have a strong > > > market in clusters. > > > > Clusters have captive, no, _desperate_ customers ;-) And it > > seems that people are just as happy putting MPI as their > > transport on top of all those link-layer technologies. > > MPI is not a transport. It an interface like the Berkeley sockets > layer. The semantics it wants right now are usually mapped to > TCP/IP when used on an IP network. Though I suspect SCTP might > be a better fit. > > But right now nothing in the IP stack is a particularly good fit. > > Right now there is a very strong feeling among most of the people > using and developing on clusters that by and large what they are doing > is not of interest to the general kernel community, and so has no > chance of going in. So you see hack piled on top of hack piled on > top of hack. > > Mostly I think the that is less true, at least if they can stand the > process of severe code review and cleaning up their code. If we can > put in code to scale the kernel to 64 processors. NIC drivers for > fast interconnects and a few similar tweaks can't hurt either. > > But of course to get through the peer review process people need > to understand what they are doing. > > > > There is one place in low latency communications that I can think > > > of where TCP/IP is not the proper solution. For low latency > > > communication the checksum is at the wrong end of the packet. > > > > That's one of the few things ATM's AAL5 got right. But in the end, > > I think it doesn't really matter. At 1 Gbps, an MTU-sized packet > > flies by within 13 us. At 10 Gbps, it's only 1.3 us. At that point, > > you may well treat it as an atomic unit. > > So store and forward of packets in a 3 layer switch hierarchy, at 1.3 us > per copy. 1.3us to the NIC + 1.3us to the first switch chip + 1.3us to the > second switch chip + 1.3us to the top level switch chip + 1.3us to a middle > layer switch chip + 1.3us to the receiving NIC + 1.3us the receiver. > > 1.3us * 7 = 9.1us to deliver a packet to the other side. That is > still quite painful. Right now I can get better latencies over any of > the cluster interconnects. I think 5 us is the current low end, with > the high end being about 1 us. I think you are off here since the second and third layer should not recompute checksums other than for the header (if they even did that). Most of the switches I used (mind, not configured) were wire speed. Only header checksums had recomputes, and I understood it was only for routing. > Quite often in MPI when a message is sent the program cannot continue > until the reply is received. Possibly this is a fundamental problem > with the application programming model, encouraging applications to > be latency sensitive. But it is a well established API and > programming paradigm so it has to be lived with. > > All of this is pretty much the reverse of the TOE case. Things are > latency sensitive because real work needs to be done. And the more > latency you have the slower that work gets done. > > A lot of the NICs which are used for MPI tend to be smart for two > reasons. 1) So they can do source routing. 2) So they can safely > export some of their interface to user space, so in the fast path > they can bypass the kernel. And bypass any security checks required. A single rogue MPI application using such an interface can/will bring the cluster down. Now this is not as much of a problem since many clusters use a standalone internal network, AND are single application clusters. These clusters tend to be relatively small (32 - 64 nodes? perhaps 16-32 is better. The clusters I've worked with have always been large 128-300 nodes, so I'm not a good judge of "small"). This is immediately broken when you schedule two or more batch jobs on a cluster in parallel. It is also broken if the two jobs require different security contexts. From jesse@cats-chateau.net Wed Aug 6 06:08:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 06:08:24 -0700 (PDT) Received: from tabby.cats.internal (34.mufa.noln.chcgil24.dsl.att.net [12.100.181.34]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76D8DFl018443 for ; Wed, 6 Aug 2003 06:08:14 -0700 Received: from localhost (localhost [[UNIX: localhost]]) by tabby.cats.internal (8.11.4/8.11.4) id h76D7wW08472; Wed, 6 Aug 2003 08:07:58 -0500 Content-Type: text/plain; charset="iso-8859-1" From: Jesse Pollard To: "David S. Miller" , Lincoln Dale Subject: Re: TOE brain dump Date: Wed, 6 Aug 2003 08:07:37 -0500 X-Mailer: KMail [version 1.2] Cc: andre@linux-ide.org, jgarzik@pobox.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, werner@almesberger.net, niv@us.ibm.com References: <3F2CAE61.7070401@pobox.com> <5.1.0.14.2.20030806181359.02bf9570@mira-sjcm-3.cisco.com> <20030806012218.4012d9e4.davem@redhat.com> In-Reply-To: <20030806012218.4012d9e4.davem@redhat.com> MIME-Version: 1.0 Message-Id: <03080608073701.08387@tabby> Content-Transfer-Encoding: 8bit X-archive-position: 4585 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jesse@cats-chateau.net Precedence: bulk X-list: netdev On Wednesday 06 August 2003 03:22, David S. Miller wrote: > On Wed, 06 Aug 2003 18:20:06 +1000 > > Lincoln Dale wrote: > > secondly, why would a router or switch even be touching the data at > > layer-4 (TCP), let alone recalculating a CRC? > > To make sure emails about Falun Gong and other undesirable topics > don't make it into China. Thats not a router, or switch... It's a firewall :-) From werner@almesberger.net Wed Aug 6 06:38:08 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 06:38:34 -0700 (PDT) Received: from host.almesberger.net (almesberger.net [63.105.73.239] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76Dc6Fl019724 for ; Wed, 6 Aug 2003 06:38:07 -0700 Received: from almesberger.net (vpnwa-home [10.200.0.2]) by host.almesberger.net (8.11.6/8.9.3) with ESMTP id h76Dc3G27530; Wed, 6 Aug 2003 06:38:03 -0700 Received: (from werner@localhost) by almesberger.net (8.11.6/8.11.6) id h76Dbwk01468; Wed, 6 Aug 2003 10:37:58 -0300 Date: Wed, 6 Aug 2003 10:37:58 -0300 From: Werner Almesberger To: "Eric W. Biederman" Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: TOE brain dump Message-ID: <20030806103758.H5798@almesberger.net> References: <20030802140444.E5798@almesberger.net> <3F2BF5C7.90400@us.ibm.com> <3F2C0C44.6020002@pobox.com> <20030802184901.G5798@almesberger.net> <20030804162433.L5798@almesberger.net> <20030806021304.E5798@almesberger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from ebiederm@xmission.com on Wed, Aug 06, 2003 at 01:58:56AM -0600 X-archive-position: 4586 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: werner@almesberger.net Precedence: bulk X-list: netdev Eric W. Biederman wrote: > Afford, they can do. A lot of the users are researchers and > a lot of people doing the code are researchers. So corralling > them up and getting production quality code can be a challenge, Ah, the joy of herding cats :-) But I guess you just need a sufficiently competent and sufficiently well-funded group that goes ahead and does it. There is usually little point in directly involving everyone who may have an opinion. > to keep your latency down. Do any ethernet switches do cut-through? According to Google, many at least claim to do this. - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina werner@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From adi@hexapodia.org Wed Aug 6 09:26:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 09:26:12 -0700 (PDT) Received: from pirx.hexapodia.org (postfix@pirx.hexapodia.org [208.42.114.113]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76GPwFl001281 for ; Wed, 6 Aug 2003 09:25:59 -0700 Received: by pirx.hexapodia.org (Postfix, from userid 22448) id D6341B404; Wed, 6 Aug 2003 11:25:56 -0500 (CDT) Date: Wed, 6 Aug 2003 11:25:56 -0500 From: Andy Isaacson To: Jesse Pollard Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: TOE brain dump Message-ID: <20030806112556.C26920@hexapodia.org> References: <20030802140444.E5798@almesberger.net> <20030804162433.L5798@almesberger.net> <03080607463300.08387@tabby> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <03080607463300.08387@tabby>; from jesse@cats-chateau.net on Wed, Aug 06, 2003 at 07:46:33AM -0500 X-PGP-Fingerprint: 48 01 21 E2 D4 E4 68 D1 B8 DF 39 B2 AF A3 16 B9 X-PGP-Key-URL: http://web.hexapodia.org/~adi/pgp.txt X-Domestic-Surveillance: money launder bomb tax evasion X-archive-position: 4587 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: adi@hexapodia.org Precedence: bulk X-list: netdev On Wed, Aug 06, 2003 at 07:46:33AM -0500, Jesse Pollard wrote: > On Tuesday 05 August 2003 12:19, Eric W. Biederman wrote: > > So store and forward of packets in a 3 layer switch hierarchy, at 1.3 us > > per copy. 1.3us to the NIC + 1.3us to the first switch chip + 1.3us to the > > second switch chip + 1.3us to the top level switch chip + 1.3us to a middle > > layer switch chip + 1.3us to the receiving NIC + 1.3us the receiver. > > > > 1.3us * 7 = 9.1us to deliver a packet to the other side. That is > > still quite painful. Right now I can get better latencies over any of > > the cluster interconnects. I think 5 us is the current low end, with > > the high end being about 1 us. > > I think you are off here since the second and third layer should not recompute > checksums other than for the header (if they even did that). Most of the > switches I used (mind, not configured) were wire speed. Only header checksums > had recomputes, and I understood it was only for routing. The switches may be "wire speed" but that doesn't help the latency any. AFAIK all GigE switches are store-and-forward, which automatically costs you the full 1.3us for each link hop. (I didn't check Eric's numbers, so I don't know that 1.3us is the right value, but it sounds right.) Also I think you might be confused about what Eric meant by "3 layer switch hierarchy"; he's referring to a tree topology network with layer-one switches connecting hosts, layer-two switches connecting layer-one switches, and layer-three switches connecting layer-two switches. This means that your worst-case node-to-node latency has 6 wire hops with 7 "read the entire packet into memory" operations, depending on how you count the initiating node's generation of the packet. [snip] > > Quite often in MPI when a message is sent the program cannot continue > > until the reply is received. Possibly this is a fundamental problem > > with the application programming model, encouraging applications to > > be latency sensitive. But it is a well established API and > > programming paradigm so it has to be lived with. This is true, in HPC. Some of the problem is the APIs encouraging such behavior; another part of the problem is that sometimes, the problem has fundamental latency dependencies that cannot be programmed around. > > A lot of the NICs which are used for MPI tend to be smart for two > > reasons. 1) So they can do source routing. 2) So they can safely > > export some of their interface to user space, so in the fast path > > they can bypass the kernel. > > And bypass any security checks required. A single rogue MPI application > using such an interface can/will bring the cluster down. This is just false. Kernel bypass (done properly) has no negative effect on system stability, either on-node or on-network. By "done properly" I mean that the NIC has mappings programmed into it by the kernel at app-startup time, and properly bounds-checks all remote DMA, and has a method for verifying that incoming packets are not rogue or corrupt. (Of course a rogue *kernel* can probably interfere with other *applications* on the network it's connected to, by inserting malicious packets into the datastream, but even that is soluble with cookies or routing checks. However, I don't believe any systems try to defend against rogue nodes today.) I believe that Myrinet's hardware has the capability to meet the "kernel bypass done properly" requirement I state above; I make no claim that their GM implementation actually meets the requirement (although I think it might). It's pretty likely that QSW's Elan hardware can, too, but I know even less about that. -andy From Robert.Olsson@data.slu.se Wed Aug 6 10:01:59 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 10:02:03 -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 h76H1vFl004216 for ; Wed, 6 Aug 2003 10:01:58 -0700 Received: (from robert@localhost) by robur.slu.se (8.9.3p2/8.9.3) id TAA32274; Wed, 6 Aug 2003 19:01:47 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16177.13435.45921.229742@robur.slu.se> Date: Wed, 6 Aug 2003 19:01:47 +0200 To: kuznet@ms2.inr.ac.ru Cc: davem@redhat.com, Robert.Olsson@data.slu.se, netdev@oss.sgi.com Subject: [PATCH] repairing rtcache killer In-Reply-To: <200308051340.RAA28267@dub.inr.ac.ru> References: <200308051340.RAA28267@dub.inr.ac.ru> X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 4588 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 kuznet@ms2.inr.ac.ru writes: > # This is a BitKeeper generated patch for the following project: > # Project Name: Linux kernel tree > # This patch format is intended for GNU patch command version 2.5 or higher. > # This patch includes the following deltas: > # ChangeSet 1.1613 -> 1.1614 > # net/ipv4/route.c 1.66 -> 1.67 Hello! Crap. We are back to the dst cache overflow again even with routing tables loaded. Well test is now on SMP and 2.6.0-test1. Undo the min_score test and give it retry? Or some new RCU stuff discover. It's current lab setup. Cheers. --ro From kuznet@ms2.inr.ac.ru Wed Aug 6 10:15:08 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 10:15:11 -0700 (PDT) Received: from dub.inr.ac.ru (dub.inr.ac.ru [193.233.7.105]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76HF6Fl005434 for ; Wed, 6 Aug 2003 10:15:08 -0700 Received: (from kuznet@localhost) by dub.inr.ac.ru (8.6.13/ANK) id VAA01614; Wed, 6 Aug 2003 21:14:56 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200308061714.VAA01614@dub.inr.ac.ru> Subject: Re: [PATCH] repairing rtcache killer To: Robert.Olsson@data.slu.se (Robert Olsson) Date: Wed, 6 Aug 2003 21:14:56 +0400 (MSD) Cc: davem@redhat.com, Robert.Olsson@data.slu.se, netdev@oss.sgi.com In-Reply-To: <16175.58503.134543.310459@robur.slu.se> from "Robert Olsson" at Aug 05, 2003 07:08:23 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4589 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Hello! > For autotuning I think we can have help from a ratio of warm cache hits (in_hit) > and misses (in_slow_tot) to set threshhold to trim hash chain lengths. Have you already forgotten the whole day lost staring to some impossible numbers for number of misses? :-) The only output which you can get from ratio hits/misses is to _increase_ size of cache when number of misses growth. It is not only useless, it is exactly opposite to the behaviour which you want to see. We want to shrink it at DoS, remember? I still do not know any criterium, apparently it should be based not on ratio hits/misses, but on absolute rates or something like that. average/max = 1/2 is always acceptable, perfect at normal flow rates and not disasterous even for 1packet/flow. Alexey From Robert.Olsson@data.slu.se Wed Aug 6 10:24:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 10:24:07 -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 h76HO1Fl006290 for ; Wed, 6 Aug 2003 10:24:02 -0700 Received: (from robert@localhost) by robur.slu.se (8.9.3p2/8.9.3) id TAA32372; Wed, 6 Aug 2003 19:23:52 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16177.14760.612648.582063@robur.slu.se> Date: Wed, 6 Aug 2003 19:23:52 +0200 To: "David S. Miller" Cc: Robert Olsson , kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: [PATCH] repairing rtcache killer In-Reply-To: <20030806005224.4798f744.davem@redhat.com> References: <200308051340.RAA28267@dub.inr.ac.ru> <16175.58503.134543.310459@robur.slu.se> <20030806005224.4798f744.davem@redhat.com> X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 4590 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 David S. Miller writes: > To make algorithm cheaper, we can even use only the current > cpu's rt_cache_stat in order to make our decisions about whether > to enter agressive mode or not. We get into complex senarios... we risk that not all CPU see "attacks" so they still contribute to the hash chain and spinning. We can run the chain length calculation at interval as alternative. One starts dreaming of having a route hash per cpu to avoid cache bouncing in the hash lookup. :-) Well not all cache bouncing well dissapear (read DoS) but as nowadays there is "more" affinity on input due to NAPI and scheduler etc. Somewhat reworked code: --- include/net/route.h.orig 2003-07-14 05:28:54.000000000 +0200 +++ include/net/route.h 2003-08-06 18:27:52.000000000 +0200 @@ -89,7 +89,9 @@ struct rt_cache_stat { unsigned int in_hit; + unsigned int in_hit_last; unsigned int in_slow_tot; + unsigned int in_slow_tot_last; unsigned int in_slow_mc; unsigned int in_no_route; unsigned int in_brd; --- net/ipv4/route.c.ank-repair-hash 2003-08-06 16:27:19.000000000 +0200 +++ net/ipv4/route.c 2003-08-06 17:53:43.000000000 +0200 @@ -118,6 +118,8 @@ int ip_rt_error_cost = HZ; int ip_rt_error_burst = 5 * HZ; int ip_rt_gc_elasticity = 8; +int ip_rt_gc_elasticity2 = 2 * 8; +int ip_rt_gc_elasticity2_recalc = 0; int ip_rt_mtu_expires = 10 * 60 * HZ; int ip_rt_min_pmtu = 512 + 20 + 20; int ip_rt_min_advmss = 256; @@ -747,6 +749,40 @@ int chain_length; int attempts = !in_softirq(); + + if (! (ip_rt_gc_elasticity2_recalc++ % 200 )) { + unsigned in_hit = 0, in_slow_tot = 0; + int i; + + for (i = 0; i < NR_CPUS; i++) { + if (!cpu_possible(i)) + continue; + + in_hit += per_cpu_ptr(rt_cache_stat, i)->in_hit - + per_cpu_ptr(rt_cache_stat, i)->in_hit_last; + + per_cpu_ptr(rt_cache_stat, i)->in_hit_last = + per_cpu_ptr(rt_cache_stat, i)->in_hit; + + in_slow_tot += per_cpu_ptr(rt_cache_stat, i)->in_slow_tot - + per_cpu_ptr(rt_cache_stat, i)->in_slow_tot_last; + + per_cpu_ptr(rt_cache_stat, i)->in_slow_tot_last = + per_cpu_ptr(rt_cache_stat, i)->in_slow_tot; + + } + + if (in_hit < in_slow_tot) { + /* Aggressive */ + if(ip_rt_gc_elasticity2 > 1) + ip_rt_gc_elasticity2 >>= 1; + } + else + if(ip_rt_gc_elasticity2 < 2*ip_rt_gc_elasticity) { + ip_rt_gc_elasticity2 <<= 1; + } + } + restart: chain_length = 0; min_score = ~(u32)0; @@ -801,13 +837,10 @@ } if (cand) { - /* ip_rt_gc_elasticity used to be average length of chain - * length, when exceeded gc becomes really aggressive. - * - * The second limit is less certain. At the moment it allows - * only 2 entries per bucket. We will see. + /* ip_rt_gc_elasticity2 used to limit length of chain + * when exceeded gc becomes really aggressive. */ - if (chain_length > 2*ip_rt_gc_elasticity) { + if (chain_length > ip_rt_gc_elasticity2) { *candp = cand->u.rt_next; rt_free(cand); } Cheers. --ro From greearb@candelatech.com Wed Aug 6 10:30:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 10:30:32 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-074.evrtwa1.dsl-verizon.net [4.33.45.74]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76HUNFl006981 for ; Wed, 6 Aug 2003 10:30:24 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h76HUItf023006; Wed, 6 Aug 2003 10:30:18 -0700 Message-ID: <3F313B2A.4080500@candelatech.com> Date: Wed, 06 Aug 2003 10:30:18 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030718 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: PATCH: Add comment to make finding the priv_flags definition easier. References: <3F304AC7.6070808@candelatech.com> <20030806034642.4d91641c.davem@redhat.com> In-Reply-To: <20030806034642.4d91641c.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4591 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev David S. Miller wrote: > On Tue, 05 Aug 2003 17:24:39 -0700 > Ben Greear wrote: > > >>This helps me, at least, remember where the definitions are at! > > > This is silly, adding one for 'priv_flags' and not one for 'flags'. > > I really don't have a taste for these "look in file foo for > interesting stuff about bar" type comments :-) Since they are not enums, it is hard to know where they are properly defined. For someone who is new to the code, I think it helps a great deal to say where the possible values are defined. I can add a comment for 'flags' as well, but not if no one cares anyway. Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From kuznet@ms2.inr.ac.ru Wed Aug 6 10:58:19 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 10:58:27 -0700 (PDT) Received: from dub.inr.ac.ru (dub.inr.ac.ru [193.233.7.105]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76HwHFl009056 for ; Wed, 6 Aug 2003 10:58:18 -0700 Received: (from kuznet@localhost) by dub.inr.ac.ru (8.6.13/ANK) id VAA01743; Wed, 6 Aug 2003 21:58:10 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200308061758.VAA01743@dub.inr.ac.ru> Subject: Re: [PATCH] repairing rtcache killer To: Robert.Olsson@data.slu.se (Robert Olsson) Date: Wed, 6 Aug 2003 21:58:09 +0400 (MSD) Cc: davem@redhat.com, Robert.Olsson@data.slu.se, netdev@oss.sgi.com In-Reply-To: <16177.13435.45921.229742@robur.slu.se> from "Robert Olsson" at Aug 06, 2003 07:01:47 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4592 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Hello! > Crap. We are back to the dst cache overflow again even with routing tables > loaded. Well test is now on SMP and 2.6.0-test1. Undo the min_score test > and give it retry? No. This patch is not related to RCU problem at all. It just sanitizes craziness of balancing introduced by chain truncation, that's why the subject is different. :-) I think you did not apply patch, which is responsible for repairing rcu troubles. Alexey From kuznet@ms2.inr.ac.ru Wed Aug 6 11:06:56 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 11:06:59 -0700 (PDT) Received: from dub.inr.ac.ru (dub.inr.ac.ru [193.233.7.105]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76I6sFl010003 for ; Wed, 6 Aug 2003 11:06:55 -0700 Received: (from kuznet@localhost) by dub.inr.ac.ru (8.6.13/ANK) id WAA01763; Wed, 6 Aug 2003 22:06:45 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200308061806.WAA01763@dub.inr.ac.ru> Subject: Re: [PATCH] repairing rtcache killer To: Robert.Olsson@data.slu.se (Robert Olsson) Date: Wed, 6 Aug 2003 22:06:45 +0400 (MSD) Cc: davem@redhat.com, Robert.Olsson@data.slu.se, netdev@oss.sgi.com In-Reply-To: <16177.14760.612648.582063@robur.slu.se> from "Robert Olsson" at Aug 06, 2003 07:23:52 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4593 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Hello! > + if (in_hit < in_slow_tot) { > + /* Aggressive */ > + if(ip_rt_gc_elasticity2 > 1) > + ip_rt_gc_elasticity2 >>= 1; > + } > + else > + if(ip_rt_gc_elasticity2 < 2*ip_rt_gc_elasticity) { > + ip_rt_gc_elasticity2 <<= 1; > + } It is the system with positive feedback. Reduction of chain length results in increasing amount of misses and so on. Under normal load it has the only stable state, zero chain length and will never leave it. hits/misses is wrong feedback, unless you use it to increase chain length. :-) Alexey From Robert.Olsson@data.slu.se Wed Aug 6 11:21:07 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 11:21:11 -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 h76IL6Fl011304 for ; Wed, 6 Aug 2003 11:21:06 -0700 Received: (from robert@localhost) by robur.slu.se (8.9.3p2/8.9.3) id UAA32639; Wed, 6 Aug 2003 20:20:59 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16177.18187.429888.128929@robur.slu.se> Date: Wed, 6 Aug 2003 20:20:59 +0200 To: kuznet@ms2.inr.ac.ru Cc: Robert.Olsson@data.slu.se (Robert Olsson), davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] repairing rtcache killer In-Reply-To: <200308061758.VAA01743@dub.inr.ac.ru> References: <16177.13435.45921.229742@robur.slu.se> <200308061758.VAA01743@dub.inr.ac.ru> X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 4594 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 kuznet@ms2.inr.ac.ru writes: > I think you did not apply patch, which is responsible for repairing > rcu troubles. > > Alexey No correct RCU patches are not applied but even before the RCU pathes we didn't see dst cache overflow during DoS if the routing table was fully loaded and we used hash chain limit patch. Cheers. --ro From kuznet@ms2.inr.ac.ru Wed Aug 6 11:35:07 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 11:35:14 -0700 (PDT) Received: from dub.inr.ac.ru (dub.inr.ac.ru [193.233.7.105]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76IZ4Fl012551 for ; Wed, 6 Aug 2003 11:35:07 -0700 Received: (from kuznet@localhost) by dub.inr.ac.ru (8.6.13/ANK) id WAA01878; Wed, 6 Aug 2003 22:34:56 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200308061834.WAA01878@dub.inr.ac.ru> Subject: Re: [PATCH] repairing rtcache killer To: Robert.Olsson@data.slu.se (Robert Olsson) Date: Wed, 6 Aug 2003 22:34:51 +0400 (MSD) Cc: Robert.Olsson@data.slu.se, davem@redhat.com, netdev@oss.sgi.com In-Reply-To: <16177.18187.429888.128929@robur.slu.se> from "Robert Olsson" at Aug 06, 2003 08:20:59 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4595 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Hello! > No correct RCU patches are not applied but even before the RCU pathes we > didn't see dst cache overflow during DoS if the routing table was fully > loaded and we used hash chain limit patch. Sure. :-) Robert, did not we discover a week ago that the reason of rcu stalls is rt_run_flush() which runs only when routes change? :-) By the way, to refresh your memory, months ago there was another reason for overflows. It was fixed by setting sane value to ip_rt_gc_min_interval. RCU showed on surface after this. Alexey From Robert.Olsson@data.slu.se Wed Aug 6 11:50:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 11:50:45 -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 h76IoZFl013910 for ; Wed, 6 Aug 2003 11:50:36 -0700 Received: (from robert@localhost) by robur.slu.se (8.9.3p2/8.9.3) id UAA32750; Wed, 6 Aug 2003 20:50:28 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16177.19956.596928.527997@robur.slu.se> Date: Wed, 6 Aug 2003 20:50:28 +0200 To: kuznet@ms2.inr.ac.ru Cc: Robert.Olsson@data.slu.se (Robert Olsson), davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] repairing rtcache killer In-Reply-To: <200308061806.WAA01763@dub.inr.ac.ru> References: <16177.14760.612648.582063@robur.slu.se> <200308061806.WAA01763@dub.inr.ac.ru> X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 4596 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 kuznet@ms2.inr.ac.ru writes: > It is the system with positive feedback. Reduction of chain length > results in increasing amount of misses and so on. Under normal load > it has the only stable state, zero chain length and will never leave it. > > hits/misses is wrong feedback, unless you use it to increase chain length. :-) > Well is was not the intention to find any optimum or equilibrium point the idea was just to get a different and more agressive setting pure DoS attacks to start with. Something like: if (in_hit < in_slow_tot) ip_rt_gc_elasticity2 = 1; else ip_rt_gc_elasticity2 = 2*ip_rt_gc_elasticity; would have been cleaner but maybe it's not worth it. Cheers. --ro From jesse@cats-chateau.net Wed Aug 6 11:59:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 11:59:30 -0700 (PDT) Received: from tabby.cats.internal (34.mufa.noln.chcgil24.dsl.att.net [12.100.181.34]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76IxLFl014762 for ; Wed, 6 Aug 2003 11:59:22 -0700 Received: from localhost (localhost [[UNIX: localhost]]) by tabby.cats.internal (8.11.4/8.11.4) id h76IxDo09250; Wed, 6 Aug 2003 13:59:13 -0500 Content-Type: text/plain; charset="iso-8859-1" From: Jesse Pollard To: Andy Isaacson Subject: Re: TOE brain dump Date: Wed, 6 Aug 2003 13:58:59 -0500 X-Mailer: KMail [version 1.2] Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20030802140444.E5798@almesberger.net> <03080607463300.08387@tabby> <20030806112556.C26920@hexapodia.org> In-Reply-To: <20030806112556.C26920@hexapodia.org> MIME-Version: 1.0 Message-Id: <03080613585900.09086@tabby> Content-Transfer-Encoding: 8bit X-archive-position: 4597 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jesse@cats-chateau.net Precedence: bulk X-list: netdev On Wednesday 06 August 2003 11:25, Andy Isaacson wrote: > On Wed, Aug 06, 2003 at 07:46:33AM -0500, Jesse Pollard wrote: > > On Tuesday 05 August 2003 12:19, Eric W. Biederman wrote: > > > So store and forward of packets in a 3 layer switch hierarchy, at 1.3 > > > us per copy. 1.3us to the NIC + 1.3us to the first switch chip + 1.3us > > > to the second switch chip + 1.3us to the top level switch chip + 1.3us > > > to a middle layer switch chip + 1.3us to the receiving NIC + 1.3us the > > > receiver. > > > > > > 1.3us * 7 = 9.1us to deliver a packet to the other side. That is > > > still quite painful. Right now I can get better latencies over any of > > > the cluster interconnects. I think 5 us is the current low end, with > > > the high end being about 1 us. > > > > I think you are off here since the second and third layer should not > > recompute checksums other than for the header (if they even did that). > > Most of the switches I used (mind, not configured) were wire speed. Only > > header checksums had recomputes, and I understood it was only for > > routing. > > The switches may be "wire speed" but that doesn't help the latency any. > AFAIK all GigE switches are store-and-forward, which automatically costs > you the full 1.3us for each link hop. (I didn't check Eric's numbers, > so I don't know that 1.3us is the right value, but it sounds right.) > Also I think you might be confused about what Eric meant by "3 layer > switch hierarchy"; he's referring to a tree topology network with > layer-one switches connecting hosts, layer-two switches connecting > layer-one switches, and layer-three switches connecting layer-two > switches. This means that your worst-case node-to-node latency has 6 > wire hops with 7 "read the entire packet into memory" operations, > depending on how you count the initiating node's generation of the > packet. If it reads the packet into memory before starting transmission, it isn't "wire speed". It is a router. > [snip] > > > > Quite often in MPI when a message is sent the program cannot continue > > > until the reply is received. Possibly this is a fundamental problem > > > with the application programming model, encouraging applications to > > > be latency sensitive. But it is a well established API and > > > programming paradigm so it has to be lived with. > > This is true, in HPC. Some of the problem is the APIs encouraging such > behavior; another part of the problem is that sometimes, the problem has > fundamental latency dependencies that cannot be programmed around. > > > > A lot of the NICs which are used for MPI tend to be smart for two > > > reasons. 1) So they can do source routing. 2) So they can safely > > > export some of their interface to user space, so in the fast path > > > they can bypass the kernel. > > > > And bypass any security checks required. A single rogue MPI application > > using such an interface can/will bring the cluster down. > > This is just false. Kernel bypass (done properly) has no negative > effect on system stability, either on-node or on-network. By "done > properly" I mean that the NIC has mappings programmed into it by the > kernel at app-startup time, and properly bounds-checks all remote DMA, > and has a method for verifying that incoming packets are not rogue or > corrupt. (Of course a rogue *kernel* can probably interfere with other > *applications* on the network it's connected to, by inserting malicious > packets into the datastream, but even that is soluble with cookies or > routing checks. However, I don't believe any systems try to defend > against rogue nodes today.) Just because the packet gets transfered to a buffer correctly does not mean that buffer is the one it should have been sent to. If it didn't have this problem, then there would be no kernel TCP/IP interaction. Just open the ethernet device and start writing/reading. Ooops. known security failure. > > I believe that Myrinet's hardware has the capability to meet the "kernel > bypass done properly" requirement I state above; I make no claim that > their GM implementation actually meets the requirement (although I think > it might). It's pretty likely that QSW's Elan hardware can, too, but I > know even less about that. since the routing is done is user mode, as part of the library, it can be used to directly affect processes NOT owned by the user. This bypasses the kernel security checks by definition. Already known to happen with raw myrinet, so there is a kernel layer on top of it to shield it (or at least try to). If there is no kernel involvement, then there can be no restrictions on what can be passed down the line to the device. Now some of the modifications for myrinet were to use normal TCP/IP to establish source/destination header information, then bypass any packet handshake, but force EACH packet to include the pre-established source/destination header info. This is equivalent to UDP, but without any checksums, and sometimes can bypass part of the kernel cache. Unfortunately, it also means that sometimes incoming data is NOT destined for the user, and must be erased/copied before the final destination is achieved. This introduces leaks due to the race condition caused by the transfer to the wrong buffer. You can't DMA directly to a users buffer, because you MUST verify the header before the data... and you can't do that until the buffer is in memory... So bypassing the kernel generates security failures. This is already a problem in fibre channel devices, and in other network devices. Anytime you bypass the kernel security you also void any restrictions on the network, and any hosts it is attached to. From kuznet@ms2.inr.ac.ru Wed Aug 6 12:01:23 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 12:01:26 -0700 (PDT) Received: from dub.inr.ac.ru (dub.inr.ac.ru [193.233.7.105]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76J1MFl015254 for ; Wed, 6 Aug 2003 12:01:22 -0700 Received: (from kuznet@localhost) by dub.inr.ac.ru (8.6.13/ANK) id XAA01942; Wed, 6 Aug 2003 23:01:13 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200308061901.XAA01942@dub.inr.ac.ru> Subject: Re: [PATCH] repairing rtcache killer To: Robert.Olsson@data.slu.se (Robert Olsson) Date: Wed, 6 Aug 2003 23:01:13 +0400 (MSD) Cc: Robert.Olsson@data.slu.se, davem@redhat.com, netdev@oss.sgi.com In-Reply-To: <16177.19956.596928.527997@robur.slu.se> from "Robert Olsson" at Aug 06, 2003 08:50:28 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4598 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Hello! > if (in_hit < in_slow_tot) > ip_rt_gc_elasticity2 = 1; > else > ip_rt_gc_elasticity2 = 2*ip_rt_gc_elasticity; > > would have been cleaner It is _much_ cleaner. > but maybe it's not worth it. Well, it is wrong before all. With default settings for number of flows at pktgen you will get always 1 not depending on length of flow at all. No hits just because cache is too small. See? It is the problem. Alexey From adi@hexapodia.org Wed Aug 6 12:39:59 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 12:40:06 -0700 (PDT) Received: from pirx.hexapodia.org (postfix@pirx.hexapodia.org [208.42.114.113]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76JdvFl019374 for ; Wed, 6 Aug 2003 12:39:58 -0700 Received: by pirx.hexapodia.org (Postfix, from userid 22448) id C396CB404; Wed, 6 Aug 2003 14:39:56 -0500 (CDT) Date: Wed, 6 Aug 2003 14:39:56 -0500 From: Andy Isaacson To: Jesse Pollard Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: TOE brain dump Message-ID: <20030806143956.B15543@hexapodia.org> References: <20030802140444.E5798@almesberger.net> <03080607463300.08387@tabby> <20030806112556.C26920@hexapodia.org> <03080613585900.09086@tabby> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <03080613585900.09086@tabby>; from jesse@cats-chateau.net on Wed, Aug 06, 2003 at 01:58:59PM -0500 X-PGP-Fingerprint: 48 01 21 E2 D4 E4 68 D1 B8 DF 39 B2 AF A3 16 B9 X-PGP-Key-URL: http://web.hexapodia.org/~adi/pgp.txt X-Domestic-Surveillance: money launder bomb tax evasion X-archive-position: 4599 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: adi@hexapodia.org Precedence: bulk X-list: netdev On Wed, Aug 06, 2003 at 01:58:59PM -0500, Jesse Pollard wrote: > On Wednesday 06 August 2003 11:25, Andy Isaacson wrote: > > The switches may be "wire speed" but that doesn't help the latency any. > > AFAIK all GigE switches are store-and-forward, which automatically costs > > you the full 1.3us for each link hop. (I didn't check Eric's numbers, > > so I don't know that 1.3us is the right value, but it sounds right.) > > Also I think you might be confused about what Eric meant by "3 layer > > switch hierarchy"; he's referring to a tree topology network with > > layer-one switches connecting hosts, layer-two switches connecting > > layer-one switches, and layer-three switches connecting layer-two > > switches. This means that your worst-case node-to-node latency has 6 > > wire hops with 7 "read the entire packet into memory" operations, > > depending on how you count the initiating node's generation of the > > packet. > > If it reads the packet into memory before starting transmission, it isn't > "wire speed". It is a router. [Please read an implied "I might be totally off base here, since I've never designed an Ethernet switch" disclaimer into this paragraph.] This statement is completely false. Ethernet switches *do* read the packet into memory before starting transmission. This must be so, because an Ethernet switch does not propagate runts, jabber frames, or frames with an incorrect ethernet crc. If the switch starts transmission before it's received the last bit, it is provably impossible for it to avoid propagating crc-failing-frames; ergo, switches must have the entire packet on hand before starting transmission. > > > > A lot of the NICs which are used for MPI tend to be smart for two > > > > reasons. 1) So they can do source routing. 2) So they can safely > > > > export some of their interface to user space, so in the fast path > > > > they can bypass the kernel. > > > > > > And bypass any security checks required. A single rogue MPI application > > > using such an interface can/will bring the cluster down. > > > > This is just false. Kernel bypass (done properly) has no negative > > effect on system stability, either on-node or on-network. By "done > > properly" I mean that the NIC has mappings programmed into it by the > > kernel at app-startup time, and properly bounds-checks all remote DMA, > > and has a method for verifying that incoming packets are not rogue or > > corrupt. (Of course a rogue *kernel* can probably interfere with other > > *applications* on the network it's connected to, by inserting malicious > > packets into the datastream, but even that is soluble with cookies or > > routing checks. However, I don't believe any systems try to defend > > against rogue nodes today.) > > Just because the packet gets transfered to a buffer correctly does not > mean that buffer is the one it should have been sent to. If it didn't > have this problem, then there would be no kernel TCP/IP interaction. Just > open the ethernet device and start writing/reading. Ooops. known security > failure. You're ignoring the fact that there's a complete, programmable RISC CPU on the Myrinet card which is running code (the MCP, Myrinet Control Program) installed into it by the kernel. The kernel tells the MCP to allow access to a given app (by mapping a page of PCI IO addresses into the user's virtual address space), and the MCP checks the user's DMA requests for validity. The user cannot generate arbitrary Myrinet routing requests, cannot write to arbitrary addresses, cannot send messages to hosts not in his allowed lists, et cetera. We do know that the buffer is the one it should have been sent to, because the MCP on the sending end verified that it was an allowed destination host, and the MCP on the receiving end verified that the destination address was valid. Myrinet Inc even offers a SDK allowing you to write your own MCP, if you so desire, and various research projects have done precisely that. Demonstrating that dumb Ethernet cards cannot be smart does not demonstrate that smart FooNet cards cannot be smart. (s/FooNet/$x/ as desired.) > > I believe that Myrinet's hardware has the capability to meet the "kernel > > bypass done properly" requirement I state above; I make no claim that > > their GM implementation actually meets the requirement (although I think > > it might). It's pretty likely that QSW's Elan hardware can, too, but I > > know even less about that. > > since the routing is done is user mode, as part of the library, it can be > used to directly affect processes NOT owned by the user. This > bypasses the kernel security checks by definition. The routing is done on the MCP, not in a library. (Or at least, it could be -- I don't know offhand how GM1 and GM2 work.) This is not an insoluble problem. > Already known to happen with raw myrinet, so there is a kernel layer > on top of it to shield it (or at least try to). Perhaps that's the case with GM1 (I don't know) but it is not a fundamental flaw of the hardware or the network. > If there is no kernel involvement, then there can be no restrictions > on what can be passed down the line to the device. The MCP provides the necessary checking. > Now some of the modifications for myrinet were to use normal TCP/IP to > establish source/destination header information, then bypass any > packet handshake, but force EACH packet to include the pre-established > source/destination header info. I don't know what you're talking about here; perhaps this was some early "TCP over Myrinet" thing. Currently on a host with GM1 running, the myri0 interface shows up as an almost-normal Ethernet interface, and most of the relevant networking ioctls work just fine. I can even tcpdump it. On a related topic, there is a Myrinet line card with a GigE port available. I haven't looked into the software end deeply, but apparently you just stick a standard Myrinet route to that switch port on the front of the Myrinet frame, append an Ethernet frame, and your Myrinet host can send GigE packets without bother. I don't know how incoming ethernet packets are routed, alas -- presumably a Myrinet route is encoded in the MAC somehow. > This is equivalent to UDP, but without any checksums, and sometimes > can bypass part of the kernel cache. Unfortunately, it also means that > sometimes incoming data is NOT destined for the user, and must be > erased/copied before the final destination is achieved. This introduces leaks > due to the race condition caused by the transfer to the wrong buffer. > > You can't DMA directly to a users buffer, because you MUST verify the header > before the data... and you can't do that until the buffer is in memory... > So bypassing the kernel generates security failures. Again, the security problems are solved by having the MCP check the necessary conditions. You bring up a good point WRT error resilience, though -- I don't know how Myrinet handles media bit errors. You *can* DMA directly to a user's buffer, because the necessary header information was checked on the MCP before the bits even touch the PCI bus. > This is already a problem in fibre channel devices, and in other network > devices. Anytime you bypass the kernel security you also void any > restrictions on the network, and any hosts it is attached to. Sufficiently advanced HBA hardware and software solve this problem. Please pick another windmill to tilt at. (Like the error one; I need to find out what the answer to that is.) -andy From rddunlap@osdl.org Wed Aug 6 13:24:30 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 13:24:36 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76KOTFl023067 for ; Wed, 6 Aug 2003 13:24: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 h76KONI02312; Wed, 6 Aug 2003 13:24:23 -0700 Date: Wed, 6 Aug 2003 13:20:32 -0700 From: "Randy.Dunlap" To: netdev@oss.sgi.com Cc: mlev@despammed.com Subject: Fw: TcpOutSegs in tcp_mib not RFC1213 compliant? Message-Id: <20030806132032.012d69f4.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-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: 4600 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 This would be more appropriate on the netdev mailing list. (from lkml) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Tue, 5 Aug 2003 20:01:22 -0400 From: Lev Makhlis To: linux-kernel@vger.kernel.org Subject: TcpOutSegs in tcp_mib not RFC1213 compliant? Hi, >From looking at net/ipv4/tcp_output.c, TcpOutSegs counts all outgoing packets, including pure retransmits. This seems to contradict RFC 1213 (MIB-II): tcpOutSegs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of segments sent, including those on current connections but excluding those containing only retransmitted octets." ::= { tcp 11 } Is that intentional or an oversight? Lev - From kuznet@ms2.inr.ac.ru Wed Aug 6 14:23:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 14:23:33 -0700 (PDT) Received: from dub.inr.ac.ru (dub.inr.ac.ru [193.233.7.105]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76LNRFl032108 for ; Wed, 6 Aug 2003 14:23:29 -0700 Received: (from kuznet@localhost) by dub.inr.ac.ru (8.6.13/ANK) id BAA02118; Thu, 7 Aug 2003 01:23:18 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200308062123.BAA02118@dub.inr.ac.ru> Subject: Re: [PATCH] repairing rtcache killer To: davem@redhat.com (David S. Miller) Date: Thu, 7 Aug 2003 01:23:18 +0400 (MSD) Cc: Robert.Olsson@data.slu.se, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com In-Reply-To: <20030806005224.4798f744.davem@redhat.com> from "David S. Miller" at Aug 06, 2003 12:52:24 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4601 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Hello! > > > # Two serious and interesting mistakes were made in the patch of 2003-06-16. > > Mama mia! This patch exists in 2.4.22-preX too, so full fix > becomes more urgent. I exaggerated saying "serious". The emphasize is rather on "interesting". :-) Mistake were not evident, Robert and me spent day and half to figure out what the hell is going on. :-) It shows only at high flow rate and it is just suboptimal thing, not a disaster. > Alexey, given all this what would you like to do? Should I push > your patch urgently into 2.4.x or spend some more time trying to > solve this issue? Hour ago I would say "yes". But this bus trip happened to be productive. :-) Seems, I know how to do right thing. I will code it now, and if Robert will be happy... Robert, look, the idea is: 1. Periodically we reset elasticity2 to 2*elasticity, f.e. from periodic gc timer. 2. We measure hits and misses with higher frequency, f.e. from forced gc. The measurement are suppressed for some time after each flush while cache collects new fresh entries. F.e. if (misses > rt_hash_mask+1 && hits < misses) elasticity2 = 0; else elasticity2 = 2*elasticity; misses > rt_hash_mask+1 guarantees that cache is populated and probed enough, rt_hash_mask+1 is not a random number, it corresponds to maximal size with elasticity2 = 0. Seems, it should work. And it is simple enough. Alexey From macro@ds2.pg.gda.pl Wed Aug 6 14:48:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 14:48:25 -0700 (PDT) Received: from delta.ds2.pg.gda.pl (root@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h76LmJFl001981 for ; Wed, 6 Aug 2003 14:48:20 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id XAA02537; Wed, 6 Aug 2003 23:05:20 +0200 (MET DST) X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs Date: Wed, 6 Aug 2003 23:05:19 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Linus Torvalds cc: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: [patch] defxx: Maintenance + DMA API fixes Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4602 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: netdev Hello Linus, all, Having necessary resources, I've decided to take over the maintenance of the defxx driver for the PDQ-based family of DEC FDDI controllers (the DEFEA for EISA and the DEFPA for PCI are the models currently handled). I've talked to Larry, the original author and the last maintainer of the code, and he's said he'd be happy about it. He's asked me to update his long-outdated contact information. Here is a patch to update the driver to the PCI version of the DMA API. It works for my system (using a DEFPA). I encourage everyone using one of the FDDI controllers to test the changes. In particular, I would like to hear from DEFEA owners as I don't have such a controller for testing (nor an EISA system at all). I have patches for the DMA API for 2.4.21 as well. I've made all these patches available at: 'ftp://ftp.ds2.pg.gda.pl/pub/macro/drivers/defxx/'. The patch includes appropriate status and contact information updates. Linus, please apply. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-2.6.0-test2-defxx-dma-5 diff -up --recursive --new-file linux-2.6.0-test2.macro/MAINTAINERS linux-2.6.0-test2/MAINTAINERS --- linux-2.6.0-test2.macro/MAINTAINERS 2003-08-02 13:53:58.000000000 +0000 +++ linux-2.6.0-test2/MAINTAINERS 2003-08-04 01:08:32.000000000 +0000 @@ -531,6 +531,11 @@ W: http://www.sucs.swan.ac.uk/~rohan/DEC L: linux-decnet-user@lists.sourceforge.net S: Maintained +DEFXX FDDI NETWORK DRIVER +P: Maciej W. Rozycki +M: macro@ds2.pg.gda.pl +S: Maintained + DELL LAPTOP SMM DRIVER P: Massimo Dal Zotto M: dz@debian.org diff -up --recursive --new-file linux-2.6.0-test2.macro/drivers/net/defxx.c linux-2.6.0-test2/drivers/net/defxx.c --- linux-2.6.0-test2.macro/drivers/net/defxx.c 2003-08-01 21:58:40.000000000 +0000 +++ linux-2.6.0-test2/drivers/net/defxx.c 2003-08-04 00:15:38.000000000 +0000 @@ -15,19 +15,11 @@ * DEC FDDIcontroller/EISA (DEFEA) * DEC FDDIcontroller/PCI (DEFPA) * - * Maintainers: - * LVS Lawrence V. Stefani - * - * Contact: - * The author may be reached at: + * The original author: + * LVS Lawrence V. Stefani * - * Inet: stefani@lkg.dec.com - * (NOTE! this address no longer works -jgarzik) - * - * Mail: Digital Equipment Corporation - * 550 King Street - * M/S: LKG1-3/M07 - * Littleton, MA 01460 + * Maintainers: + * macro Maciej W. Rozycki * * Credits: * I'd like to thank Patricia Cross for helping me get started with @@ -197,10 +189,9 @@ * Sep 2000 tjeerd Fix leak on unload, cosmetic code cleanup * Feb 2001 Skb allocation fixes * Feb 2001 davej PCI enable cleanups. + * 04 Aug 2003 macro Converted to the DMA API. */ -#error Please convert me to Documentation/DMA-mapping.txt - /* Include files */ #include @@ -226,7 +217,7 @@ /* Version information string - should be updated prior to each new release!!! */ static char version[] __devinitdata = - "defxx.c:v1.05e 2001/02/03 Lawrence V. Stefani and others\n"; + "defxx.c:v1.06 2003/08/04 Lawrence V. Stefani and others\n"; #define DYNAMIC_BUFFERS 1 @@ -413,6 +404,7 @@ static int __devinit dfx_init_one_pci_or { struct net_device *dev; DFX_board_t *bp; /* board pointer */ + int alloc_size; /* total buffer size used */ int err; #ifndef MODULE @@ -486,7 +478,16 @@ static int __devinit dfx_init_one_pci_or return 0; err_out_kfree: - if (bp->kmalloced) kfree(bp->kmalloced); + alloc_size = sizeof(PI_DESCR_BLOCK) + + PI_CMD_REQ_K_SIZE_MAX + PI_CMD_RSP_K_SIZE_MAX + +#ifndef DYNAMIC_BUFFERS + (bp->rcv_bufs_to_post * PI_RCV_DATA_K_SIZE_MAX) + +#endif + sizeof(PI_CONSUMER_BLOCK) + + (PI_ALIGN_K_DESC_BLK - 1); + if (bp->kmalloced) + pci_free_consistent(pdev, alloc_size, + bp->kmalloced, bp->kmalloced_dma); err_out_region: release_region(ioaddr, pdev ? PFI_K_CSR_IO_LEN : PI_ESIC_K_CSR_IO_LEN); err_out: @@ -781,8 +782,8 @@ static void __devinit dfx_bus_config_che * or read adapter MAC address * * Assumptions: - * Memory allocated from kmalloc() call is physically contiguous, locked - * memory whose physical address equals its virtual address. + * Memory allocated from pci_alloc_consistent() call is physically + * contiguous, locked memory. * * Side Effects: * Adapter is reset and should be in DMA_UNAVAILABLE state before @@ -794,7 +795,7 @@ static int __devinit dfx_driver_init(str DFX_board_t *bp = dev->priv; int alloc_size; /* total buffer size needed */ char *top_v, *curr_v; /* virtual addrs into memory block */ - u32 top_p, curr_p; /* physical addrs into memory block */ + dma_addr_t top_p, curr_p; /* physical addrs into memory block */ u32 data; /* host data register value */ DBG_printk("In dfx_driver_init...\n"); @@ -904,14 +905,15 @@ static int __devinit dfx_driver_init(str #endif sizeof(PI_CONSUMER_BLOCK) + (PI_ALIGN_K_DESC_BLK - 1); - bp->kmalloced = top_v = (char *) kmalloc(alloc_size, GFP_KERNEL); + bp->kmalloced = top_v = pci_alloc_consistent(bp->pci_dev, alloc_size, + &bp->kmalloced_dma); if (top_v == NULL) { printk("%s: Could not allocate memory for host buffers and structures!\n", dev->name); return(DFX_K_FAILURE); } memset(top_v, 0, alloc_size); /* zero out memory before continuing */ - top_p = virt_to_bus(top_v); /* get physical address of buffer */ + top_p = bp->kmalloced_dma; /* get physical address of buffer */ /* * To guarantee the 8K alignment required for the descriptor block, 8K - 1 @@ -925,7 +927,7 @@ static int __devinit dfx_driver_init(str * for allocating the needed memory. */ - curr_p = (u32) (ALIGN(top_p, PI_ALIGN_K_DESC_BLK)); + curr_p = ALIGN(top_p, PI_ALIGN_K_DESC_BLK); curr_v = top_v + (curr_p - top_p); /* Reserve space for descriptor block */ @@ -2744,7 +2746,10 @@ static int dfx_rcv_init(DFX_board_t *bp, */ my_skb_align(newskb, 128); - bp->descr_block_virt->rcv_data[i+j].long_1 = virt_to_bus(newskb->data); + bp->descr_block_virt->rcv_data[i + j].long_1 = + (u32)pci_map_single(bp->pci_dev, newskb->data, + NEW_SKB_SIZE, + PCI_DMA_FROMDEVICE); /* * p_rcv_buff_va is only used inside the * kernel so we put the skb pointer here. @@ -2858,9 +2863,17 @@ static void dfx_rcv_queue_process( my_skb_align(newskb, 128); skb = (struct sk_buff *)bp->p_rcv_buff_va[entry]; + pci_unmap_single(bp->pci_dev, + bp->descr_block_virt->rcv_data[entry].long_1, + NEW_SKB_SIZE, + PCI_DMA_FROMDEVICE); skb_reserve(skb, RCV_BUFF_K_PADDING); bp->p_rcv_buff_va[entry] = (char *)newskb; - bp->descr_block_virt->rcv_data[entry].long_1 = virt_to_bus(newskb->data); + bp->descr_block_virt->rcv_data[entry].long_1 = + (u32)pci_map_single(bp->pci_dev, + newskb->data, + NEW_SKB_SIZE, + PCI_DMA_FROMDEVICE); } else skb = NULL; } else @@ -2933,7 +2946,7 @@ static void dfx_rcv_queue_process( * is contained in a single physically contiguous buffer * in which the virtual address of the start of packet * (skb->data) can be converted to a physical address - * by using virt_to_bus(). + * by using pci_map_single(). * * Since the adapter architecture requires a three byte * packet request header to prepend the start of packet, @@ -3081,12 +3094,13 @@ static int dfx_xmt_queue_pkt( * skb->data. * 6. The physical address of the start of packet * can be determined from the virtual address - * by using virt_to_bus() and is only 32-bits + * by using pci_map_single() and is only 32-bits * wide. */ p_xmt_descr->long_0 = (u32) (PI_XMT_DESCR_M_SOP | PI_XMT_DESCR_M_EOP | ((skb->len) << PI_XMT_DESCR_V_SEG_LEN)); - p_xmt_descr->long_1 = (u32) virt_to_bus(skb->data); + p_xmt_descr->long_1 = (u32)pci_map_single(bp->pci_dev, skb->data, + skb->len, PCI_DMA_TODEVICE); /* * Verify that descriptor is actually available @@ -3170,6 +3184,7 @@ static int dfx_xmt_done(DFX_board_t *bp) { XMT_DRIVER_DESCR *p_xmt_drv_descr; /* ptr to transmit driver descriptor */ PI_TYPE_2_CONSUMER *p_type_2_cons; /* ptr to rcv/xmt consumer block register */ + u8 comp; /* local transmit completion index */ int freed = 0; /* buffers freed */ /* Service all consumed transmit frames */ @@ -3187,7 +3202,11 @@ static int dfx_xmt_done(DFX_board_t *bp) bp->xmt_total_bytes += p_xmt_drv_descr->p_skb->len; /* Return skb to operating system */ - + comp = bp->rcv_xmt_reg.index.xmt_comp; + pci_unmap_single(bp->pci_dev, + bp->descr_block_virt->xmt_data[comp].long_1, + p_xmt_drv_descr->p_skb->len, + PCI_DMA_TODEVICE); dev_kfree_skb_irq(p_xmt_drv_descr->p_skb); /* @@ -3296,6 +3315,7 @@ static void dfx_xmt_flush( DFX_board_t * { u32 prod_cons; /* rcv/xmt consumer block longword */ XMT_DRIVER_DESCR *p_xmt_drv_descr; /* ptr to transmit driver descriptor */ + u8 comp; /* local transmit completion index */ /* Flush all outstanding transmit frames */ @@ -3306,7 +3326,11 @@ static void dfx_xmt_flush( DFX_board_t * p_xmt_drv_descr = &(bp->xmt_drv_descr_blk[bp->rcv_xmt_reg.index.xmt_comp]); /* Return skb to operating system */ - + comp = bp->rcv_xmt_reg.index.xmt_comp; + pci_unmap_single(bp->pci_dev, + bp->descr_block_virt->xmt_data[comp].long_1, + p_xmt_drv_descr->p_skb->len, + PCI_DMA_TODEVICE); dev_kfree_skb(p_xmt_drv_descr->p_skb); /* Increment transmit error counter */ @@ -3336,11 +3360,22 @@ static void dfx_xmt_flush( DFX_board_t * static void __devexit dfx_remove_one_pci_or_eisa(struct pci_dev *pdev, struct net_device *dev) { - DFX_board_t *bp = dev->priv; + DFX_board_t *bp = dev->priv; + int alloc_size; /* total buffer size used */ unregister_netdev(dev); release_region(dev->base_addr, pdev ? PFI_K_CSR_IO_LEN : PI_ESIC_K_CSR_IO_LEN ); - if (bp->kmalloced) kfree(bp->kmalloced); + + alloc_size = sizeof(PI_DESCR_BLOCK) + + PI_CMD_REQ_K_SIZE_MAX + PI_CMD_RSP_K_SIZE_MAX + +#ifndef DYNAMIC_BUFFERS + (bp->rcv_bufs_to_post * PI_RCV_DATA_K_SIZE_MAX) + +#endif + sizeof(PI_CONSUMER_BLOCK) + + (PI_ALIGN_K_DESC_BLK - 1); + if (bp->kmalloced) + pci_free_consistent(pdev, alloc_size, bp->kmalloced, + bp->kmalloced_dma); kfree(dev); } diff -up --recursive --new-file linux-2.6.0-test2.macro/drivers/net/defxx.h linux-2.6.0-test2/drivers/net/defxx.h --- linux-2.6.0-test2.macro/drivers/net/defxx.h 2003-08-01 21:47:38.000000000 +0000 +++ linux-2.6.0-test2/drivers/net/defxx.h 2003-08-04 00:15:41.000000000 +0000 @@ -12,17 +12,11 @@ * Contains all definitions specified by port specification and required * by the defxx.c driver. * - * Maintainers: - * LVS Lawrence V. Stefani - * - * Contact: - * The author may be reached at: + * The original author: + * LVS Lawrence V. Stefani * - * Inet: stefani@lkg.dec.com - * Mail: Digital Equipment Corporation - * 550 King Street - * M/S: LKG1-3/M07 - * Littleton, MA 01460 + * Maintainers: + * macro Maciej W. Rozycki * * Modification History: * Date Name Description @@ -30,6 +24,7 @@ * 09-Sep-96 LVS Added group_prom field. Moved read/write I/O * macros to DEFXX.C. * 12-Sep-96 LVS Removed packet request header pointers. + * 04 Aug 2003 macro Converted to the DMA API. */ #ifndef _DEFXX_H_ @@ -1697,17 +1692,19 @@ typedef struct DFX_board_tag { /* Keep virtual and physical pointers to locked, physically contiguous memory */ - char *kmalloced; /* kfree this on unload */ + char *kmalloced; /* pci_free_consistent this on unload */ + dma_addr_t kmalloced_dma; + /* DMA handle for the above */ PI_DESCR_BLOCK *descr_block_virt; /* PDQ descriptor block virt address */ - u32 descr_block_phys; /* PDQ descriptor block phys address */ + dma_addr_t descr_block_phys; /* PDQ descriptor block phys address */ PI_DMA_CMD_REQ *cmd_req_virt; /* Command request buffer virt address */ - u32 cmd_req_phys; /* Command request buffer phys address */ + dma_addr_t cmd_req_phys; /* Command request buffer phys address */ PI_DMA_CMD_RSP *cmd_rsp_virt; /* Command response buffer virt address */ - u32 cmd_rsp_phys; /* Command response buffer phys address */ + dma_addr_t cmd_rsp_phys; /* Command response buffer phys address */ char *rcv_block_virt; /* LLC host receive queue buf blk virt */ - u32 rcv_block_phys; /* LLC host receive queue buf blk phys */ + dma_addr_t rcv_block_phys; /* LLC host receive queue buf blk phys */ PI_CONSUMER_BLOCK *cons_block_virt; /* PDQ consumer block virt address */ - u32 cons_block_phys; /* PDQ consumer block phys address */ + dma_addr_t cons_block_phys; /* PDQ consumer block phys address */ /* Keep local copies of Type 1 and Type 2 register data */ From Robert.Olsson@data.slu.se Wed Aug 6 15:57:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 15:57:44 -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 h76MvYFl004393 for ; Wed, 6 Aug 2003 15:57:36 -0700 Received: (from robert@localhost) by robur.slu.se (8.9.3p2/8.9.3) id AAA01287; Thu, 7 Aug 2003 00:57:28 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16177.34776.207150.232716@robur.slu.se> Date: Thu, 7 Aug 2003 00:57:28 +0200 To: kuznet@ms2.inr.ac.ru Cc: davem@redhat.com (David S. Miller), Robert.Olsson@data.slu.se, netdev@oss.sgi.com Subject: Re: [PATCH] repairing rtcache killer In-Reply-To: <200308062123.BAA02118@dub.inr.ac.ru> References: <20030806005224.4798f744.davem@redhat.com> <200308062123.BAA02118@dub.inr.ac.ru> X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 4603 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 kuznet@ms2.inr.ac.ru writes: > Robert, look, the idea is: > > 1. Periodically we reset elasticity2 to 2*elasticity, f.e. from > periodic gc timer. This solve the "positive" feedback. Actually the code I tested moved from elasticity2=1 to elasticity*2 as well but this seems more reliable. > 2. We measure hits and misses with higher frequency, f.e. from > forced gc. The measurement are suppressed for some time > after each flush while cache collects new fresh entries. And the measure (forced gc) should not be inhibited by any elastiticy2 setting. > if (misses > rt_hash_mask+1 && hits < misses) > elasticity2 = 0; > else > elasticity2 = 2*elasticity; ( hits < misses ) Delicate balancing point but actually it didn't look too bad in the lab setup. > misses > rt_hash_mask+1 guarantees that cache is populated and probed > enough, rt_hash_mask+1 is not a random number, it corresponds > to maximal size with elasticity2 = 0. Yes better. > Seems, it should work. And it is simple enough. Let's try... ;-) Cheers. --ro From sri@us.ibm.com Wed Aug 6 16:37:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 16:37:40 -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 h76NbaFl005914 for ; Wed, 6 Aug 2003 16:37:37 -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 h76NbSpW167892; Wed, 6 Aug 2003 19:37:28 -0400 Received: from w-sridhar.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h76NbPJD033516; Wed, 6 Aug 2003 19:37:26 -0400 Date: Wed, 6 Aug 2003 16:32:01 -0700 (PDT) From: Sridhar Samudrala X-X-Sender: sridhar@w-sridhar.beaverton.ibm.com To: davem@redhat.com cc: netdev@oss.sgi.com Subject: [BK PATCH] Minor updates to SCTP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4604 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sri@us.ibm.com Precedence: bulk X-list: netdev Hi Dave, Please do a bk pull http://linux-lksctp.bkbits.net/lksctp-2.5 to get the following updates to SCTP on top of linux 2.6.0-test2. # This patch includes the following deltas: # ChangeSet 1.1595 -> 1.1597 # net/sctp/associola.c 1.57 -> 1.58 # net/sctp/input.c 1.34 -> 1.35 # net/sctp/sm_statefuns.c 1.61 -> 1.62 # net/sctp/endpointola.c 1.27 -> 1.28 # net/sctp/sm_make_chunk.c 1.57 -> 1.58 # include/net/sctp/constants.h 1.15 -> 1.16 # net/sctp/debug.c 1.8 -> 1.9 # net/sctp/proc.c 1.6 -> 1.7 # include/net/sctp/sm.h 1.26 -> 1.27 # net/sctp/protocol.c 1.56 -> 1.57 # include/linux/sctp.h 1.6 -> 1.7 # net/sctp/sm_sideeffect.c 1.47 -> 1.48 # net/sctp/sm_statetable.c 1.18 -> 1.19 # include/net/sctp/command.h 1.13 -> 1.14 # include/net/sctp/structs.h 1.69 -> 1.71 # net/sctp/socket.c 1.88 -> 1.89 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 03/08/04 sri@us.ibm.com 1.1596 # [SCTP] ADDIP basic infrastructure support. (Ardelle.Fan) # -------------------------------------------- # 03/08/04 sri@us.ibm.com 1.1597 # [SCTP] Fix to avoid large kmalloc failures on 64-bit platforms. # # When spinlock debugging is enabled, the size of assoc hash table and # port hash table for a fixed value of 4096 entries exceeds the size # of the largest possible kmalloc() on 64-bit platforms. This problem is # avoided by using page allocations similar to the methodology followed # for tcp hash table allocations. # -------------------------------------------- Thanks Sridhar From davem@redhat.com Wed Aug 6 17:00:56 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 17:01:05 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7700tFl006460 for ; Wed, 6 Aug 2003 17:00:56 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id QAA26552; Wed, 6 Aug 2003 16:56:10 -0700 Date: Wed, 6 Aug 2003 16:56:10 -0700 From: "David S. Miller" To: Sridhar Samudrala Cc: netdev@oss.sgi.com Subject: Re: [BK PATCH] Minor updates to SCTP Message-Id: <20030806165610.47505d4e.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4605 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 6 Aug 2003 16:32:01 -0700 (PDT) Sridhar Samudrala wrote: > Please do a > bk pull http://linux-lksctp.bkbits.net/lksctp-2.5 Pulled, thanks. From scott.feldman@intel.com Wed Aug 6 17:33:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 17:33:33 -0700 (PDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h770XPFl007068 for ; Wed, 6 Aug 2003 17:33:26 -0700 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h770RIe27200 for ; Thu, 7 Aug 2003 00:27:18 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h76MTYn18377 for ; Wed, 6 Aug 2003 22:29:41 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003080615464411703 ; Wed, 06 Aug 2003 15:46:44 -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); Wed, 6 Aug 2003 15:34:33 -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: More 2.4.22pre10 ACPI breakage Date: Wed, 6 Aug 2003 15:34:33 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: More 2.4.22pre10 ACPI breakage Thread-Index: AcNbxpyURp/8RGKwQ4mmXlQY2KiudAAoMH1g From: "Feldman, Scott" To: "Jeff Garzik" Cc: "Samuel Flory" , X-OriginalArrivalTime: 06 Aug 2003 22:34:33.0716 (UTC) FILETIME=[E8B7E340:01C35C6A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h770XPFl007068 X-archive-position: 4606 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 > That said... I'm tempted to extend NAPI just a bit, to provide an > "always poll" mode. It seems like all the bug reports I get > these days for 8139too are caused by x86 ACPI/APIC/irq routing troubles > completely unrelated to the driver. Tulip-almost-NAPI in 2.4 has an > always-poll mode, so I have a convenient excuse :) NAPI always-poll mode...that would be fun to play with. JC was getting his best results for small packets when he modified the dev e100 driver to stay in polling mode, even if the quota wasn't met. Basically running without interrupts. If there is someway for the the driver to sample/ack the device for events when interrupts are disabled/unrouted, then these async events can be handled in the poll routine. I'm thinking of events like link-status-change. Is this what you're thinking: 1) block any place the driver enables interrupts so interrupts stay disabled, 2) ignore netif_rx_complete so we stay in polling mode, 3) ignore return code from netdev->poll. For 1), the driver needs some way to know that we're in always-poll-mode so enabling interrupts is a nop. Just thinking out loud - haven't tried any of this. -scott From pr@mrno.jp Wed Aug 6 18:37:09 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 18:37:14 -0700 (PDT) Received: from mail.mrno.jp ([219.163.205.181]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h771b8Fl008742 for ; Wed, 6 Aug 2003 18:37:09 -0700 Received: from localhost (mrno.jp [127.0.0.1]) by mail.mrno.jp (Postfix) with ESMTP id 5B4A1188FB8 for ; Thu, 7 Aug 2003 10:40:38 +0900 (JST) From: pr@mrno.jp To: netdev@oss.sgi.com Subject: =?ISO-8859-1?Q?=1B$B#N#O%/%j%C%/!y9b2AGc Date: Thu, 7 Aug 2003 10:40:38 +0900 (JST) X-archive-position: 4607 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pr@mrno.jp Precedence: bulk X-list: netdev $B%5%$%H%*!<%J!e$2$F$*$j$^$9!#(B $BJ@Z(B $B5Z$SF~B`=P5!9=$G$NHsF~<<%f!<%6!l9g!"(B $B!&7HBS%5%$%HMM$O#1%/%j%C%/!a#1#21_!JDL>o#71_!K(B $B!&#P#C%5%$%HMM$O#1%/%j%C%/!a#51_!JDL>o#21_!K(B $B$GGcu!"F~B`=P5!9=$r$*;}$A$G$J$$%*!<%J!]$H$J$j$^$9!#(B $BJ@]$K$J$i$J$+$C$?HsF~<<%f!<%6!<(B $B%/%j%C%/$rJ@u67E*$K$b#2#0#0#3G/#1#07n$+$iK!N'5,@)$K$h$k(B $B%"%@%k%H%5%$%H$X$NG/NpG'>Z5!9=$N5AL3IU$1$,;\9T$5$l(B $B$k;v$b$"$j$^$9$N$G!"$3$N5!2q$KG/NpG'>Z5!9=$NL5$$(B $B%5%$%HMM$OG/NpG'>Z5!9=$NF3F~$HF1;~$KJ@\$7$/$O2<5-$N%5%$%H$G$4Mw2<$5$$!#(B $B7HBSHG!X#M#r(B.$B#N#O!Y(B http://www.mrno.jp/i/ $B#P#CHG!X#M#r(B.$B#N#O!Y(B http://www.mrno.jp/ $B:G8e$K!"$3$A$i$Ne$2$^$9!#(B ////////////////////////////////////////////////// $B!!3t<02q>0f9,;R(B $B!!(Binfo@mrno.jp ////////////////////////////////////////////////// From shmulik.hen@intel.com Wed Aug 6 23:23:05 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 06 Aug 2003 23:23:13 -0700 (PDT) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h776N3Fl027308 for ; Wed, 6 Aug 2003 23:23:04 -0700 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h776HhK02664 for ; Thu, 7 Aug 2003 06:17:43 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h776PwZ01435 for ; Thu, 7 Aug 2003 06:25:58 GMT Received: from hasmsx331.ger.corp.intel.com ([143.185.63.144]) by hasmsxvs01.iil.intel.com (NAVGW 2.5.2.11) with SMTP id M2003080709300018391 ; Thu, 07 Aug 2003 09:30:00 +0300 Received: from hasmsx403.ger.corp.intel.com ([143.185.63.109]) by hasmsx331.ger.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 7 Aug 2003 09:22:53 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: VLAN patch for 2.4.21 Date: Thu, 7 Aug 2003 09:22:53 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VLAN patch for 2.4.21 Thread-Index: AcNbsZtW9W2htjy0TYejl3bEB6UcnQA+ibUg From: "Hen, Shmulik" To: "Ben Greear" , X-OriginalArrivalTime: 07 Aug 2003 06:22:53.0577 (UTC) FILETIME=[558A6790:01C35CAC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h776N3Fl027308 X-archive-position: 4608 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev > -----Original Message----- > From: Ben Greear [mailto:greearb@candelatech.com] > Sent: Wednesday, August 06, 2003 3:27 AM > To: 'netdev@oss.sgi.com' > Subject: VLAN patch for 2.4.21 > > > Here is a patch that adds a few new IOCTL options (not new > IOCTLs per se) for the 802.1Q VLANs. > One ioctl allows one to get the VID for a device by > the interface name. A second gets the name of the underlying > device for the VLAN device. Tested on x86 and PPC. > > Comments welcome! > > Thanks, > Ben > Oh, this is great. You just saved me the work I was going to do for fixing VLAN stuff over bonding :) Any idea how to export those in a way that would enable bonding and alike to include them without getting dependant on 8021q module being loaded ? (I'm guessing inline function in a .h file, but any other solution is welcome (coed sample ?). -- | Shmulik Hen Advanced Network Services | | Israel Design Center, Jerusalem | | LAN Access Division, Platform Networking | | Intel Communications Group, Intel corp. | From greearb@candelatech.com Thu Aug 7 00:28:20 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 00:28:32 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-074.evrtwa1.dsl-verizon.net [4.33.45.74]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h777SJFl031873 for ; Thu, 7 Aug 2003 00:28:20 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h777SCtf007851; Thu, 7 Aug 2003 00:28:13 -0700 Message-ID: <3F31FF8C.9080705@candelatech.com> Date: Thu, 07 Aug 2003 00:28:12 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030718 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hen, Shmulik" CC: netdev@oss.sgi.com Subject: Re: VLAN patch for 2.4.21 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4609 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Hen, Shmulik wrote: >>-----Original Message----- >>From: Ben Greear [mailto:greearb@candelatech.com] >>Sent: Wednesday, August 06, 2003 3:27 AM >>To: 'netdev@oss.sgi.com' >>Subject: VLAN patch for 2.4.21 >> >> >>Here is a patch that adds a few new IOCTL options (not new >>IOCTLs per se) for the 802.1Q VLANs. >>One ioctl allows one to get the VID for a device by >>the interface name. A second gets the name of the underlying >>device for the VLAN device. Tested on x86 and PPC. >> >>Comments welcome! >> >>Thanks, >>Ben >> > > > Oh, this is great. You just saved me the work I was going to do > for fixing VLAN stuff over bonding :) > Any idea how to export those in a way that would enable bonding > and alike to include them without getting dependant on 8021q module > being loaded ? (I'm guessing inline function in a .h file, but any > other solution is welcome (coed sample ?). You can just check the things in the net_device struct directly I imagine. The calls I added are mainly to provide the info to user-space. What information do you need, and where do you need it? Also, no word yet from the guys who actually take patches, so dunno if/when this will get into the tree. Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From davem@redhat.com Thu Aug 7 00:34:55 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 00:35:02 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h777YrFl032602 for ; Thu, 7 Aug 2003 00:34:54 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id AAA27518; Thu, 7 Aug 2003 00:30:04 -0700 Date: Thu, 7 Aug 2003 00:30:04 -0700 From: "David S. Miller" To: Ben Greear Cc: shmulik.hen@intel.com, netdev@oss.sgi.com Subject: Re: VLAN patch for 2.4.21 Message-Id: <20030807003004.53544de7.davem@redhat.com> In-Reply-To: <3F31FF8C.9080705@candelatech.com> References: <3F31FF8C.9080705@candelatech.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4610 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Thu, 07 Aug 2003 00:28:12 -0700 Ben Greear wrote: > Also, no word yet from the guys who actually take patches, so dunno > if/when this will get into the tree. I'll review and add your patch, I have some bigger fires to put out first :-) From felix@allot.com Thu Aug 7 02:11:52 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 02:12:02 -0700 (PDT) Received: from mxout2.netvision.net.il (mxout2.netvision.net.il [194.90.9.21]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h779BnFl004086 for ; Thu, 7 Aug 2003 02:11:51 -0700 Received: from exg.allot.com ([199.203.223.202]) by mxout2.netvision.net.il (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HJ80043US7FRK@mxout2.netvision.net.il> for netdev@oss.sgi.com; Thu, 07 Aug 2003 12:11:43 +0300 (IDT) Received: from allot.com (199.203.223.201 [199.203.223.201]) by exg.allot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QNW7ZTMQ; Thu, 07 Aug 2003 12:14:41 +0200 Date: Thu, 07 Aug 2003 12:12:07 +0300 From: Felix Radensky Subject: Ethernet bridge performance To: netdev@oss.sgi.com Message-id: <3F3217E7.2080903@allot.com> Organization: Allot Communications Ltd. MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_RVVz94TACxHZ39XZVjgHQQ)" X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-archive-position: 4611 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: felix@allot.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --Boundary_(ID_RVVz94TACxHZ39XZVjgHQQ) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Hi, I'm evaluating a performance of a dual port ethernet bridge, and the results are a bit disappointing. I would appreciate any hints on improving the results. I'm using a Dual Xeon 2.66 GHz box based on Intel 5701 chipset with 1G of RAM. NICs are e1000 82546 connected to PCIX bus. Kernel is 2.4.22-pre8, e1000 driver version 5.1.13-k1 with NAPI support. NICs' interrupts are bound to CPU0. The test consists of sending 200 byte UDP packets from 2 ports of Gigabit IXIA traffic generator to 2 bridge ports. The bridge is capable to sustain the rate of ~170000 pps from each IXIA port without drops. I was expecting it to be able to do at least 250000 pps (our own bridge code based on 2.2.x kernel sustains ~266000 pps on the same hardware). e1000 driver drops 0 packets, all drops occur at higher level. The output of oprofile attached. I'd be happy to provide any info you may need. Thanks in advance for your help. Felix. --Boundary_(ID_RVVz94TACxHZ39XZVjgHQQ) Content-type: text/plain; name=oprofile.log Content-transfer-encoding: 7BIT Content-disposition: inline; filename=oprofile.log CPU: P4 / Xeon, speed 2666.83 MHz (estimated) Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped) with a unit mask of 0x01 (count cycles when processor is active) count 1333415 vma samples % symbol name c01a13ac 7983 12.5065 eth_type_trans c01a1590 7629 11.9519 qdisc_restart c0197720 7365 11.5383 skb_release_data c010c170 5962 9.3403 do_gettimeofday c019a9b4 5207 8.1575 dev_queue_xmit c012df98 4243 6.6472 free_block c019ad44 3404 5.3328 netif_rx c01974e0 3266 5.1166 alloc_skb c012e1b4 2600 4.0733 kmalloc c012e3b8 2448 3.8351 kfree c019b284 2401 3.7615 process_backlog c012debc 1941 3.0408 kmem_cache_alloc_batch c0197790 1555 2.4361 kfree_skbmem c01977f8 1296 2.0304 __kfree_skb c012e07c 1203 1.8847 kmem_cache_alloc c019afa4 1079 1.6904 net_tx_action c019b0bc 932 1.4601 netif_receive_skb c01a1a04 750 1.1750 pfifo_fast_dequeue c019accc 445 0.6972 get_sample_stats c012e338 431 0.6752 kmem_cache_free c01a1990 222 0.3478 pfifo_fast_enqueue c01087f0 180 0.2820 do_IRQ c01142a8 152 0.2381 schedule c010c434 131 0.2052 timer_interrupt c010b04c 123 0.1927 IRQ0x31_interrupt c010b040 115 0.1802 IRQ0x30_interrupt c011c400 82 0.1285 cpu_raise_softirq c019b3ac 62 0.0971 net_rx_action c01052a0 57 0.0893 default_idle c011be40 55 0.0862 do_softirq c0112b28 47 0.0736 end_level_ioapic_irq c016b210 39 0.0611 add_timer_randomness c016afb0 38 0.0595 add_entropy_words c016b0a4 37 0.0580 batch_entropy_store c0105944 35 0.0548 __switch_to c0115778 32 0.0501 wake_up_process c0112de0 23 0.0360 do_check_pgt_cache c010b760 22 0.0345 apic_timer_interrupt c010ae10 21 0.0329 common_interrupt c01da960 13 0.0204 __rdtsc_delay c0106f3d 11 0.0172 restore_all c0111d0c 11 0.0172 smp_apic_timer_interrupt c01245a8 11 0.0172 check_pgt_cache c016b158 11 0.0172 batch_entropy_process c0107138 9 0.0141 page_fault c0108654 9 0.0141 handle_IRQ_event c010ae30 9 0.0141 IRQ0x00_interrupt c0125414 9 0.0141 do_wp_page c011f1b0 8 0.0125 update_one_process c011f36c 8 0.0125 timer_bh c011c33c 7 0.0110 ksoftirqd c0113eb8 6 0.0094 reschedule_idle c011c0cc 5 0.0078 tasklet_hi_action c011c204 5 0.0078 bh_action c010ae23 4 0.0063 call_do_IRQ c011eb90 4 0.0063 add_timer c011f284 4 0.0063 update_process_times c0125970 4 0.0063 do_anonymous_page c016b320 4 0.0063 add_interrupt_randomness c0106ef4 3 0.0047 system_call c010c78c 3 0.0047 inc_new_microsec_time c0124850 3 0.0047 zap_page_range c01daa70 3 0.0047 __generic_copy_to_user c010b778 2 0.0031 call_apic_timer_interrupt c0112ae8 2 0.0031 ack_edge_ioapic_irq c011327c 2 0.0031 do_page_fault c01147c8 2 0.0031 __wake_up c011ee88 2 0.0031 tqueue_bh c0124698 2 0.0031 copy_page_range c0125a5c 2 0.0031 do_no_page c01282d8 2 0.0031 __find_get_page c0128e1c 2 0.0031 file_read_actor c01d1880 2 0.0031 fn_hash_lookup c01db1b0 2 0.0031 number c01052f4 1 0.0016 cpu_idle c0106628 1 0.0016 setup_frame c0106fb0 1 0.0016 ret_from_intr c0106fb7 1 0.0016 ret_from_exception c0106fe4 1 0.0016 error_code c01114f8 1 0.0016 flush_tlb_page c01198ec 1 0.0016 get_module_list c0119d30 1 0.0016 s_show c011c2d0 1 0.0016 __run_task_queue c011f73c 1 0.0016 do_timer c012093c 1 0.0016 sys_rt_sigprocmask c0125bf8 1 0.0016 handle_mm_fault c0125cc8 1 0.0016 pte_alloc c0125fd8 1 0.0016 lock_vma_mappings c0126348 1 0.0016 do_mmap_pgoff c012ca90 1 0.0016 vmfree_area_pages c012dcac 1 0.0016 kmem_cache_grow c012f000 1 0.0016 __lru_cache_del c0130288 1 0.0016 rmqueue c01308a8 1 0.0016 __free_pages c0130acf 1 0.0016 .text.lock.page_alloc c0134460 1 0.0016 fd_install c013fb70 1 0.0016 link_path_walk c01557f8 1 0.0016 proc_pid_statm c016b078 1 0.0016 credit_entropy_store c01804dc 1 0.0016 ide_inb c0180524 1 0.0016 ide_outb c0180a60 1 0.0016 drive_is_ready c0198d3c 1 0.0016 skb_headerinit c01a58e4 1 0.0016 ip_route_input_slow c01a8324 1 0.0016 ip_rcv c01d0c68 1 0.0016 fib_semantic_match --Boundary_(ID_RVVz94TACxHZ39XZVjgHQQ)-- From shmulik.hen@intel.com Thu Aug 7 03:22:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 03:22:21 -0700 (PDT) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h77AMDFl008024 for ; Thu, 7 Aug 2003 03:22:16 -0700 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h77AGuJ03927 for ; Thu, 7 Aug 2003 10:16:56 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h77APBE02478 for ; Thu, 7 Aug 2003 10:25:11 GMT Received: from hasmsx331.ger.corp.intel.com ([143.185.63.144]) by hasmsxvs01.iil.intel.com (NAVGW 2.5.2.11) with SMTP id M2003080713291305899 ; Thu, 07 Aug 2003 13:29:13 +0300 Received: from hasmsx403.ger.corp.intel.com ([143.185.63.109]) by hasmsx331.ger.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 7 Aug 2003 13:22:06 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: VLAN patch for 2.4.21 Date: Thu, 7 Aug 2003 13:22:05 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VLAN patch for 2.4.21 Thread-Index: AcNctawwoqf9COSQT/e3elVv8xNmhQAFpVsA From: "Hen, Shmulik" To: "Ben Greear" Cc: X-OriginalArrivalTime: 07 Aug 2003 10:22:06.0546 (UTC) FILETIME=[C093AB20:01C35CCD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h77AMDFl008024 X-archive-position: 4612 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev > -----Original Message----- > From: Ben Greear [mailto:greearb@candelatech.com] > Sent: Thursday, August 07, 2003 10:28 AM > To: Hen, Shmulik > Cc: netdev@oss.sgi.com > Subject: Re: VLAN patch for 2.4.21 > > > You can just check the things in the net_device struct directly > I imagine. The calls I added are mainly to provide the info to > user-space. That was my guess too. I'll figure out a way to do that safely from kernel space. > What information do you need, and where do you need it? In bonding, to better handle self generated packets, I'll need to know what vlan ID's are on top of the bond device. So, I'll need to listen to net dev registration notifications and sort out which ones are for VLAN devices, and then see if they were added on top of a bond device. Once I've got that, I'll need to get the VID and store it in bonding, so both your additions do exactly what I need. I also heard from the bridge developers that they wanted similar support, so that's 2 birds... Shmulik. From ingo.oeser@informatik.tu-chemnitz.de Thu Aug 7 04:05:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 04:06:20 -0700 (PDT) Received: from tom.hrz.tu-chemnitz.de (tom.hrz.tu-chemnitz.de [134.109.132.38]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h77B5WFl009111 for ; Thu, 7 Aug 2003 04:05:38 -0700 Received: from tnt200.hrz.tu-chemnitz.de ([134.109.156.200] helo=nightmaster.csn.tu-chemnitz.de ident=root) by tom.hrz.tu-chemnitz.de with esmtp (Exim 4.12) id 19jwzG-00034j-00; Tue, 05 Aug 2003 10:16:07 +0200 Received: (from ioe@localhost) by nightmaster.csn.tu-chemnitz.de (8.9.1/8.9.1) id KAA29171; Tue, 5 Aug 2003 10:15:25 +0200 Date: Tue, 5 Aug 2003 10:15:25 +0200 From: Ingo Oeser To: Alan Shih Cc: Jeff Garzik , Nivedita Singhvi , Werner Almesberger , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: TOE brain dump Message-ID: <20030805101525.P670@nightmaster.csn.tu-chemnitz.de> References: <20030804163606.Q639@nightmaster.csn.tu-chemnitz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from alan@storlinksemi.com on Mon, Aug 04, 2003 at 10:19:21AM -0700 X-Spam-Score: -4.5 (----) X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *19jwzG-00034j-00*RgAXBNAHfIU* X-archive-position: 4613 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ingo.oeser@informatik.tu-chemnitz.de Precedence: bulk X-list: netdev On Mon, Aug 04, 2003 at 10:19:21AM -0700, Alan Shih wrote: > So would main processor still need a copy of the data for re-transmission? > Won't that defeat the purpose? No, since I didn't state that a retransmission is done along the pipe, because you cannot go back in a pipeline. A retransmission can be done at the end of the pipe, where this can also be done in hardware. Regards Ingo Oeser From davids@webmaster.com Thu Aug 7 08:05:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 08:05:35 -0700 (PDT) Received: from shell.webmaster.com (mail.webmaster.com [216.152.64.131]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h77F5OFl022065 for ; Thu, 7 Aug 2003 08:05:25 -0700 Received: from however ([206.171.168.138]) by shell.webmaster.com (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S10000V35) with SMTP id com; Wed, 6 Aug 2003 14:11:32 -0700 From: "David Schwartz" To: "Andy Isaacson" , "Jesse Pollard" Cc: , Subject: RE: TOE brain dump Date: Wed, 6 Aug 2003 14:13:47 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20030806143956.B15543@hexapodia.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-archive-position: 4614 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davids@webmaster.com Precedence: bulk X-list: netdev > This statement is completely false. Ethernet switches *do* read the > packet into memory before starting transmission. Some do. Some don't. Some are configurable. > This must be so, > because an Ethernet switch does not propagate runts, jabber frames, or > frames with an incorrect ethernet crc. If they use cut-through switching, they do. Some use adaptive switching, which means they use cut-through switching but change to store and forward if there are too many runts, jabber frames, bad CRCs, and so on. Obviously, you can't always do a cut-through. If the target port is busy, cut-through is impossible. If the ports are different speeds, cut-through is impossible. The Intel 510T switch for my home network does adaptive switching with configurable error thresholds. In fact, it's even smarter than that, with an intermediate mode that suppresses runts without doing a full store and forward. See: http://www.intel.com/support/express/switches/23188.htm > If the switch starts > transmission before it's received the last bit, it is provably > impossible for it to avoid propagating crc-failing-frames; ergo, > switches must have the entire packet on hand before starting > transmission. Except not all switches always avoid propogating bad frames. DS From akpm@osdl.org Thu Aug 7 08:48:55 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 08:49:03 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h77FmsFl025800 for ; Thu, 7 Aug 2003 08:48:54 -0700 Received: from mnm (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id h77FmjI18699; Thu, 7 Aug 2003 08:48:45 -0700 Date: Thu, 7 Aug 2003 08:50:43 -0700 From: Andrew Morton To: netdev@oss.sgi.com Cc: laforge@gnumonks.org, Rusty Russell , temnota@kmv.ru Subject: Fw: [Bugme-new] [Bug 1054] New: loading iptables modules kill raid5 kernel thread Message-Id: <20030807085043.3b794387.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4615 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev This is weird. It looks like something on the netfilter module initialisation path has called smp_call_function(garbage_address). But I cannot see where anything like that could happen. Begin forwarded message: Date: Thu, 7 Aug 2003 07:49:13 -0700 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 1054] New: loading iptables modules kill raid5 kernel thread http://bugme.osdl.org/show_bug.cgi?id=1054 Summary: loading iptables modules kill raid5 kernel thread Kernel Version: 2.4.22-pre10 Status: NEW Severity: normal Owner: laforge@gnumonks.org Submitter: temnota@kmv.ru Distribution: RedHat 7.1 Hardware Environment: HP NetServer 5/LS $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 5 model : 2 model name : Pentium 75 - 200 stepping : 5 fdiv_bug : no hlt_bug : no f00f_bug : yes coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse msr mce cx8 apic bogomips : 53.04 processor : 1 vendor_id : GenuineIntel cpu family : 5 model : 2 model name : Pentium 75 - 200 stepping : 5 fdiv_bug : no hlt_bug : no f00f_bug : yes coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse msr mce cx8 apic bogomips : 53.24 $ lspci -v 00:00.0 Host bridge: Intel Corporation 82452KX/GX [Orion] (rev 02) Flags: bus master, medium devsel, latency 6 00:0d.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 01) Flags: bus master, medium devsel, latency 66, IRQ 10 Memory at ffe7f000 (32-bit, prefetchable) [size=4K] I/O ports at ef80 [size=32] Memory at ff600000 (32-bit, non-prefetchable) [size=1M] Expansion ROM at [disabled] [size=1M] 00:0e.0 Non-VGA unclassified device: Intel Corporation 82375EB (rev 05) Flags: bus master, medium devsel, latency 248 00:0f.0 Class ff00: Intel Corporation: Unknown device 0008 Subsystem: Unknown device ec08:ffe7 Flags: fast devsel Memory at ffe7ec00 (32-bit, prefetchable) [size=1K] Memory at 12000000 (32-bit, prefetchable) [size=1K] Memory at 12000400 (32-bit, prefetchable) [size=1K] Memory at 12000800 (32-bit, prefetchable) [size=1K] Memory at 12000c00 (32-bit, prefetchable) [size=1K] Memory at 12001000 (32-bit, prefetchable) [size=1K] Expansion ROM at fffff800 [disabled] [size=2K] 01:00.0 Host bridge: Intel Corporation 82452KX/GX [Orion] (rev 02) Flags: bus master, medium devsel, latency 6 01:0c.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08) Subsystem: Intel Corporation EtherExpress PRO/100+ Management Adapter Flags: bus master, medium devsel, latency 66, IRQ 9 Memory at ffcfe000 (32-bit, non-prefetchable) [size=4K] I/O ports at f8c0 [size=64] Memory at ffb00000 (32-bit, non-prefetchable) [size=1M] Expansion ROM at [disabled] [size=1M] Capabilities: [dc] Power Management version 2 01:0d.0 SCSI storage controller: Adaptec AHA-294x / AIC-7870 (rev 03) Flags: bus master, medium devsel, latency 64, IRQ 11 I/O ports at fc00 [disabled] [size=256] Memory at ffcff000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at [disabled] [size=64K] 01:0e.0 SCSI storage controller: Adaptec AHA-294x / AIC-7870 (rev 03) Flags: bus master, medium devsel, latency 64, IRQ 9 I/O ports at f400 [disabled] [size=256] Memory at ffcfd000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at [disabled] [size=64K] $ cat /proc/modules ipt_TOS 1008 0 ipt_tos 448 0 (unused) iptable_mangle 2144 1 ipt_TCPMSS 2336 3 ipt_tcpmss 800 0 (unused) ipt_LOG 3568 20 ipt_MARK 720 0 (unused) ipt_REDIRECT 768 0 (unused) iptable_nat 23264 1 [ipt_REDIRECT] ipt_REJECT 3136 0 (unused) ipt_mac 656 12 ipt_mark 464 0 (unused) ipt_multiport 640 0 (unused) iptable_filter 1712 1 ipt_state 576 8 ipt_limit 1216 171 ip_conntrack_ftp 4512 0 (unused) ip_conntrack 29664 3 [ipt_REDIRECT iptable_nat ipt_state ip_conntrack_ftp] ip_tables 15008 18 [ipt_TOS ipt_tos iptable_mangle ipt_TCPMSS ipt_tcpmss ipt_LOG ipt_MARK ipt_REDIRECT iptable_nat ipt_REJECT ipt_mac ipt_mark ipt_multiport iptable_filter ipt_state ipt_limit] Software Environment: Software Raid5 + iptables modules Problem Description: When raid recovery discs (after unclean shutdown), loading iptables modules kill radi5 kernel thread Unable to handle kernel NULL pointer dereference at virtual address 00000212 c102c04d *pde = 00000000 Oops: 0002 CPU: 1 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010082 eax: d0355bb3 ebx: 00000001 ecx: c102c01c edx: 00000212 esi: 00000019 edi: d1af3000 ebp: d1af4000 esp: d1d95dec ds: 0018 es: 0018 ss: 0018 Process raid5d (pid: 13, stackpage=d1d95000) Stack: c0113b18 00000212 d1af3cc0 c010ca6a d1af3cc0 d1af5cc0 d1af4cc0 00000019 d1af3000 d1af4000 0080e85d 00000018 00000018 fffffffb c01fb83a 00000010 00000282 00000003 d1af6c00 c01fbef7 00001000 d1af4000 d1af3000 d1af5000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] Code: c0 02 c1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>EIP; c102c04d <_end+cae92d/124d9940> <===== Trace; c0113b18 Trace; c010ca6a Trace; c01fb83a Trace; c01fbef7 Trace; c01f734e Trace; c01b1261 Trace; c01f82e6 Trace; c01bb224 Trace; c01f8ae1 Trace; c01f8a10 Trace; c0200515 Trace; c0105883 Trace; c0200370 Code; c102c04d <_end+cae92d/124d9940> 00000000 <_EIP>: Code; c102c04d <_end+cae92d/124d9940> 0: c0 02 c1 rolb $0xc1,(%edx) Unable to handle kernel NULL pointer dereference at virtual address 00000217 c102c04d *pde = 00000000 Oops: 0002 CPU: 0 EIP: 0010:[] Not tainted EFLAGS: 00010082 eax: cb189bb3 ebx: 00000001 ecx: c102c01c edx: 00000217 esi: 00000021 edi: d1c51000 ebp: d1c52000 esp: d1d95dec ds: 0018 es: 0018 ss: 0018 Process raid5d (pid: 13, stackpage=d1d95000) Stack: c0113b18 00000217 d1c51bc0 c010ca6a d1c51bc0 d1c53be0 d1c52bc0 00000021 d1c51000 d1c52000 807944a9 00000018 00000018 fffffffb c01fb85b 00000010 00000286 00000003 d1c54c00 c01fbef7 00001000 d1c52000 d1c51000 d1c53000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] Code: c0 02 c1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>EIP; c102c04d <_end+cae92d/124d9940> <===== Trace; c0113b18 Trace; c010ca6a Trace; c01fb85b Trace; c01fbef7 Trace; c01f734e Trace; c01b1261 Trace; c01f82e6 Trace; c01bb224 Trace; c01f8ae1 Trace; c01f8a10 Trace; c0200515 Trace; c0105883 Trace; c0200370 Code; c102c04d <_end+cae92d/124d9940> 00000000 <_EIP>: Code; c102c04d <_end+cae92d/124d9940> 0: c0 02 c1 rolb $0xc1,(%edx) Steps to reproduce: raidsetfaulty /dev/md0 /dev/sde1 raidhotremove /dev/md0 /dev/sde1 raidhotadd /dev/md0 /dev/sde1 and load iptables modules. OOPS ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From greearb@candelatech.com Thu Aug 7 08:49:55 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 08:50:00 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-074.evrtwa1.dsl-verizon.net [4.33.45.74]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h77FnsFl026011 for ; Thu, 7 Aug 2003 08:49:55 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h77FnWtf001210; Thu, 7 Aug 2003 08:49:33 -0700 Message-ID: <3F32750C.4000600@candelatech.com> Date: Thu, 07 Aug 2003 08:49:32 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030718 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hen, Shmulik" CC: netdev@oss.sgi.com Subject: Re: VLAN patch for 2.4.21 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4616 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Hen, Shmulik wrote: >>-----Original Message----- >>From: Ben Greear [mailto:greearb@candelatech.com] >>Sent: Thursday, August 07, 2003 10:28 AM >>To: Hen, Shmulik >>Cc: netdev@oss.sgi.com >>Subject: Re: VLAN patch for 2.4.21 >> >> >>You can just check the things in the net_device struct directly >>I imagine. The calls I added are mainly to provide the info to >>user-space. > > > That was my guess too. I'll figure out a way to do that > safely from kernel space. > > >>What information do you need, and where do you need it? > > > In bonding, to better handle self generated packets, I'll need > to know what vlan ID's are on top of the bond device. So, I'll > need to listen to net dev registration notifications and sort > out which ones are for VLAN devices, and then see if they were > added on top of a bond device. Once I've got that, I'll need to > get the VID and store it in bonding, so both your additions > do exactly what I need. I also heard from the bridge developers > that they wanted similar support, so that's 2 birds... If it's a VLAN device, it will have priv_flags & 0x1 turned on, see dev->priv_flags and if.h for possible values that priv_flags can have: /* Private (from user) interface flags (netdevice->priv_flags). */ #define IFF_802_1Q_VLAN 0x1 /* 802.1Q VLAN device. */ You can then get it's vlan-ID by looking for: VLAN_DEV_INFO(dev)->vlan_id; VLAN_DEV_INFO is defined in if_vlan.h as: #define VLAN_DEV_INFO(x) ((struct vlan_dev_info *)(x->priv)) > > > Shmulik. > > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From shemminger@osdl.org Thu Aug 7 08:59:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 08:59:51 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h77FxjFl026997 for ; Thu, 7 Aug 2003 08:59:46 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h77FxaI22159; Thu, 7 Aug 2003 08:59:36 -0700 Date: Thu, 7 Aug 2003 08:59:30 -0700 From: Stephen Hemminger To: Felix Radensky Cc: netdev@oss.sgi.com Subject: Re: Ethernet bridge performance Message-Id: <20030807085930.032b0602.shemminger@osdl.org> In-Reply-To: <3F3217E7.2080903@allot.com> References: <3F3217E7.2080903@allot.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4617 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev What kernel version? 2.6 should be faster. On Thu, 07 Aug 2003 12:12:07 +0300 Felix Radensky wrote: > Hi, > > I'm evaluating a performance of a dual port ethernet bridge, and the > results are a bit disappointing. I would appreciate any hints on improving > the results. > > I'm using a Dual Xeon 2.66 GHz box based on Intel 5701 chipset with 1G > of RAM. NICs are e1000 82546 connected to PCIX bus. Kernel is 2.4.22-pre8, > e1000 driver version 5.1.13-k1 with NAPI support. NICs' interrupts are > bound > to CPU0. > > The test consists of sending 200 byte UDP packets from 2 ports of Gigabit > IXIA traffic generator to 2 bridge ports. The bridge is capable to sustain > the rate of ~170000 pps from each IXIA port without drops. I was > expecting it to be able to do at least 250000 pps (our own bridge code > based > on 2.2.x kernel sustains ~266000 pps on the same hardware). > e1000 driver drops 0 packets, all drops occur at higher level. > > The output of oprofile attached. I'd be happy to provide any info you may > need. > > Thanks in advance for your help. > > Felix. > From felix@allot.com Thu Aug 7 09:31:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 09:31:58 -0700 (PDT) Received: from mxout4.netvision.net.il (mxout4.netvision.net.il [194.90.9.27]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h77GVlFl029254 for ; Thu, 7 Aug 2003 09:31:48 -0700 Received: from exg.allot.com ([199.203.223.202]) by mxout4.netvision.net.il (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HJ900428BCEH8@mxout4.netvision.net.il> for netdev@oss.sgi.com; Thu, 07 Aug 2003 19:05:03 +0300 (IDT) Received: from allot.com (199.203.223.201 [199.203.223.201]) by exg.allot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QNW7ZVDG; Thu, 07 Aug 2003 19:08:06 +0200 Date: Thu, 07 Aug 2003 19:05:31 +0300 From: Felix Radensky Subject: Re: Ethernet bridge performance To: Stephen Hemminger Cc: netdev@oss.sgi.com Message-id: <3F3278CB.5070505@allot.com> Organization: Allot Communications Ltd. MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_5fAUGaz5oHMtphX6UtIryg)" X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 References: <3F3217E7.2080903@allot.com> <20030807085930.032b0602.shemminger@osdl.org> X-archive-position: 4618 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: felix@allot.com Precedence: bulk X-list: netdev --Boundary_(ID_5fAUGaz5oHMtphX6UtIryg) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT It's 2.4.22-pre8. I have to work with 2.4, 2.6 is not an option at this point. Felix. Stephen Hemminger wrote: >What kernel version? 2.6 should be faster. > >On Thu, 07 Aug 2003 12:12:07 +0300 >Felix Radensky wrote: > > > >>Hi, >> >>I'm evaluating a performance of a dual port ethernet bridge, and the >>results are a bit disappointing. I would appreciate any hints on improving >>the results. >> >>I'm using a Dual Xeon 2.66 GHz box based on Intel 5701 chipset with 1G >>of RAM. NICs are e1000 82546 connected to PCIX bus. Kernel is 2.4.22-pre8, >>e1000 driver version 5.1.13-k1 with NAPI support. NICs' interrupts are >>bound >>to CPU0. >> >>The test consists of sending 200 byte UDP packets from 2 ports of Gigabit >>IXIA traffic generator to 2 bridge ports. The bridge is capable to sustain >>the rate of ~170000 pps from each IXIA port without drops. I was >>expecting it to be able to do at least 250000 pps (our own bridge code >> based >>on 2.2.x kernel sustains ~266000 pps on the same hardware). >>e1000 driver drops 0 packets, all drops occur at higher level. >> >>The output of oprofile attached. I'd be happy to provide any info you may >>need. >> >>Thanks in advance for your help. >> >>Felix. >> >> >> > > > --Boundary_(ID_5fAUGaz5oHMtphX6UtIryg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT It's 2.4.22-pre8. I have to work with 2.4, 2.6 is not an option
at this point.

Felix.

Stephen Hemminger wrote:
What kernel version?  2.6 should be faster.

On Thu, 07 Aug 2003 12:12:07 +0300
Felix Radensky <felix@allot.com> wrote:

  
Hi,

I'm evaluating a performance of a dual port ethernet bridge, and the
results are a bit disappointing. I would appreciate any hints on improving
the results.

I'm using a Dual Xeon 2.66 GHz box based on Intel  5701 chipset with  1G
of RAM. NICs are e1000 82546 connected to PCIX bus. Kernel is 2.4.22-pre8,
e1000  driver version 5.1.13-k1 with NAPI support. NICs' interrupts are 
bound
to CPU0.

The test consists of sending 200 byte UDP packets from 2 ports of Gigabit
IXIA traffic generator to 2 bridge ports. The bridge is capable to sustain
the rate of ~170000 pps from each IXIA port without drops. I was
expecting it to be able to do at least 250000 pps (our own bridge code 
 based
on 2.2.x kernel sustains ~266000 pps on the same hardware).
e1000 driver drops 0 packets, all drops occur at higher level.

The output of oprofile attached. I'd be happy to provide any info you may
need.

Thanks in advance for your help.

Felix.

--Boundary_(ID_5fAUGaz5oHMtphX6UtIryg)-- From greearb@candelatech.com Thu Aug 7 09:57:23 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 09:57:32 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-074.evrtwa1.dsl-verizon.net [4.33.45.74]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h77GvMFl030528 for ; Thu, 7 Aug 2003 09:57:23 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h77GvEtf009001; Thu, 7 Aug 2003 09:57:14 -0700 Message-ID: <3F3284EA.5050406@candelatech.com> Date: Thu, 07 Aug 2003 09:57:14 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030718 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Felix Radensky CC: netdev@oss.sgi.com Subject: Re: Ethernet bridge performance References: <3F3217E7.2080903@allot.com> In-Reply-To: <3F3217E7.2080903@allot.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4619 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Felix Radensky wrote: > Hi, > > I'm evaluating a performance of a dual port ethernet bridge, and the > results are a bit disappointing. I would appreciate any hints on improving > the results. > c01a13ac 7983 12.5065 eth_type_trans > c01a1590 7629 11.9519 qdisc_restart > c0197720 7365 11.5383 skb_release_data > c010c170 5962 9.3403 do_gettimeofday If that do_gettimeofday is happening in the skb rx code, then you could gain ~10% by disabling it somehow..as it should not matter for a bridge. I bet Robert's skb-recycle patch would help here too, especially if you allowed the NICs to save up a large number of skbs so that alloc was less likely to fail. Btw, I've considered saving, say, 10k skbs on a list in my module, allocated by GFP_KERNEL at module load time, and using them when GFP_ATOMIC skb_alloc fails in the IRQ handling portion of the code.... Anyone think that's a good idea? :) Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From felix@allot.com Thu Aug 7 10:18:51 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 10:18:56 -0700 (PDT) Received: from mxout5.netvision.net.il (mxout5.netvision.net.il [194.90.9.29]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h77HInFl032042 for ; Thu, 7 Aug 2003 10:18:50 -0700 Received: from exg.allot.com ([199.203.223.202]) by mxout5.netvision.net.il (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HJ90073VER7OM@mxout5.netvision.net.il> for netdev@oss.sgi.com; Thu, 07 Aug 2003 20:18:43 +0300 (IDT) Received: from allot.com (199.203.223.201 [199.203.223.201]) by exg.allot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QNW7ZVML; Thu, 07 Aug 2003 20:21:46 +0200 Date: Thu, 07 Aug 2003 20:19:11 +0300 From: Felix Radensky Subject: Re: Ethernet bridge performance To: Ben Greear Cc: netdev@oss.sgi.com Message-id: <3F328A0F.3040005@allot.com> Organization: Allot Communications Ltd. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 References: <3F3217E7.2080903@allot.com> <3F3284EA.5050406@candelatech.com> X-archive-position: 4620 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: felix@allot.com Precedence: bulk X-list: netdev Thanks for your help, Ben. What is skb-recycle patch and where can I find it ? Felix. Ben Greear wrote: > Felix Radensky wrote: > >> Hi, >> >> I'm evaluating a performance of a dual port ethernet bridge, and the >> results are a bit disappointing. I would appreciate any hints on >> improving >> the results. > > >> c01a13ac 7983 12.5065 eth_type_trans >> c01a1590 7629 11.9519 qdisc_restart >> c0197720 7365 11.5383 skb_release_data >> c010c170 5962 9.3403 do_gettimeofday > > > If that do_gettimeofday is happening in the skb rx code, then > you could gain ~10% by disabling it somehow..as it should not > matter for a bridge. I bet Robert's skb-recycle patch would > help here too, especially if you allowed the NICs to save up a large > number of skbs so that alloc was less likely to fail. > > Btw, I've considered saving, say, 10k skbs on a list in my module, > allocated by GFP_KERNEL at module load time, and using them when > GFP_ATOMIC skb_alloc fails in the IRQ handling portion of the code.... > > Anyone think that's a good idea? :) > > Ben > From Robert.Olsson@data.slu.se Thu Aug 7 12:09:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 12:10:04 -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 h77J9qFl008522 for ; Thu, 7 Aug 2003 12:09:54 -0700 Received: (from robert@localhost) by robur.slu.se (8.9.3p2/8.9.3) id VAA05772; Thu, 7 Aug 2003 21:09:44 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16178.41976.3643.584516@robur.slu.se> Date: Thu, 7 Aug 2003 21:09:44 +0200 To: Felix Radensky Cc: Ben Greear , netdev@oss.sgi.com Subject: Re: Ethernet bridge performance In-Reply-To: <3F328A0F.3040005@allot.com> References: <3F3217E7.2080903@allot.com> <3F3284EA.5050406@candelatech.com> <3F328A0F.3040005@allot.com> X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 4621 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 Felix Radensky writes: > Thanks for your help, Ben. What is skb-recycle patch > and where can I find it ? It's experimental and not updated for almost a year and current implementation does not add anything to SMP. Got some idea how to improve this... but try to keep to slab as long as possible it has been improved. Routing/bridging on SMP has affinty problem. If you are passing skb's say from eth0 to eth1 and they are bound on different CPU's you get cache boucing since the TX-interrupts come on another CPU. In a recent test with pktgen: 300 kpps with TX interrupts on same CPU as sender. 198 kpps with TX intr on different CPU as sender. Recycling tries to address this but current implementation fails as said. But you are probably hit by something else... Check were the drops happens qdisc?. NIC ring RX/TX size, Number of interrupts. ksoftird priority, link HW_FLOW control, checksumming, affinity etc. Cheers. --ro From hadi@cyberus.ca Thu Aug 7 12:21:38 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 12:21:49 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h77JLbFl009582 for ; Thu, 7 Aug 2003 12:21:38 -0700 Received: from [216.209.86.2] (helo=[10.0.0.9] ident=jamal) by mail.cyberus.ca with esmtp (Exim 4.12) id 19kqKN-0009tM-00; Thu, 07 Aug 2003 15:21:35 -0400 Subject: Re: Ethernet bridge performance From: jamal Reply-To: hadi@cyberus.ca To: Robert Olsson Cc: Felix Radensky , Ben Greear , netdev@oss.sgi.com In-Reply-To: <16178.41976.3643.584516@robur.slu.se> References: <3F3217E7.2080903@allot.com> <3F3284EA.5050406@candelatech.com> <3F328A0F.3040005@allot.com> <16178.41976.3643.584516@robur.slu.se> Content-Type: text/plain Organization: jamalopolis Message-Id: <1060284094.1024.36.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Aug 2003 15:21:34 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4622 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Actually seems his biggest problem is he is not running the NAPI driver cheers, jamal On Thu, 2003-08-07 at 15:09, Robert Olsson wrote: > Felix Radensky writes: > > Thanks for your help, Ben. What is skb-recycle patch > > and where can I find it ? > > It's experimental and not updated for almost a year and current > implementation does not add anything to SMP. Got some idea how > to improve this... but try to keep to slab as long as possible > it has been improved. > > Routing/bridging on SMP has affinty problem. If you are passing > skb's say from eth0 to eth1 and they are bound on different CPU's > you get cache boucing since the TX-interrupts come on another CPU. > > In a recent test with pktgen: > 300 kpps with TX interrupts on same CPU as sender. > 198 kpps with TX intr on different CPU as sender. > > Recycling tries to address this but current implementation fails > as said. > > But you are probably hit by something else... Check were the drops > happens qdisc?. NIC ring RX/TX size, Number of interrupts. ksoftird > priority, link HW_FLOW control, checksumming, affinity etc. > > > Cheers. > --ro > > From davem@redhat.com Thu Aug 7 12:40:43 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 12:40:52 -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 h77JegFl011058 for ; Thu, 7 Aug 2003 12:40:43 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id MAA29280; Thu, 7 Aug 2003 12:35:48 -0700 Date: Thu, 7 Aug 2003 12:35:47 -0700 From: "David S. Miller" To: Ben Greear Cc: felix@allot.com, netdev@oss.sgi.com Subject: Re: Ethernet bridge performance Message-Id: <20030807123547.1dcf2353.davem@redhat.com> In-Reply-To: <3F3284EA.5050406@candelatech.com> References: <3F3217E7.2080903@allot.com> <3F3284EA.5050406@candelatech.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4623 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Thu, 07 Aug 2003 09:57:14 -0700 Ben Greear wrote: > Btw, I've considered saving, say, 10k skbs on a list in my module, > allocated by GFP_KERNEL at module load time, and using them when > GFP_ATOMIC skb_alloc fails in the IRQ handling portion of the code.... > > Anyone think that's a good idea? :) Not really. GFP_ATOMIC should not fail regularly under normal (even heavy load) operation. If it does, it means the amount of reserved pages the kernel keeps around is not set correctly for your system. In 2.6.x, play with /proc/sys/vm/min_free_kbytes From greearb@candelatech.com Thu Aug 7 12:51:08 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 12:51:12 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-074.evrtwa1.dsl-verizon.net [4.33.45.74]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h77Jp7Fl012026 for ; Thu, 7 Aug 2003 12:51:07 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h77Jostf031569; Thu, 7 Aug 2003 12:50:54 -0700 Message-ID: <3F32AD9D.4010504@candelatech.com> Date: Thu, 07 Aug 2003 12:50:53 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030718 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: felix@allot.com, netdev@oss.sgi.com Subject: Re: Ethernet bridge performance References: <3F3217E7.2080903@allot.com> <3F3284EA.5050406@candelatech.com> <20030807123547.1dcf2353.davem@redhat.com> In-Reply-To: <20030807123547.1dcf2353.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4624 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev David S. Miller wrote: > On Thu, 07 Aug 2003 09:57:14 -0700 > Ben Greear wrote: > > >>Btw, I've considered saving, say, 10k skbs on a list in my module, >>allocated by GFP_KERNEL at module load time, and using them when >>GFP_ATOMIC skb_alloc fails in the IRQ handling portion of the code.... >> >>Anyone think that's a good idea? :) > > > Not really. > > GFP_ATOMIC should not fail regularly under normal (even heavy load) > operation. If it does, it means the amount of reserved pages > the kernel keeps around is not set correctly for your system. > > In 2.6.x, play with /proc/sys/vm/min_free_kbytes Anything to set for 2.4? I've looked for how to tune the 2.4 VM for some time, but never found anything. Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From hadi@cyberus.ca Thu Aug 7 12:58:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 12:59:01 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h77JwqFl013273 for ; Thu, 7 Aug 2003 12:58:53 -0700 Received: from [216.209.86.2] (helo=[10.0.0.9] ident=jamal) by mail.cyberus.ca with esmtp (Exim 4.12) id 19kquS-000ECS-00; Thu, 07 Aug 2003 15:58:52 -0400 Subject: Re: [RFC] High Performance Packet Classifiction for tc framework From: jamal Reply-To: hadi@cyberus.ca To: Michael Bellion and Thomas Heinz Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <3F302E04.1090503@hipac.org> References: <200307141045.40999.nf@hipac.org> <1058328537.1797.24.camel@jzny.localdomain> <3F16A0E5.1080007@hipac.org> <1059934468.1103.41.camel@jzny.localdomain> <3F2E5CD6.4030500@hipac.org> <1060012260.1103.380.camel@jzny.localdomain> <3F302E04.1090503@hipac.org> Content-Type: text/plain Organization: jamalopolis Message-Id: <1060286331.1025.73.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Aug 2003 15:58:51 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4625 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Hi there, On Tue, 2003-08-05 at 18:21, Michael Bellion and Thomas Heinz wrote: > Hi Jamal > > You wrote: > > I promise i will. I dont think i will do it justice spending 5 minutes > > on it. I take it you have written extensive docs too ;-> > > Of course ;-) > Well, actually we are going to present an overview of the hipac > algorithm at the netfilter developer workshop in Budapest. > Hope to see you there. > Unfortunately due to economical reasons i wont be able to make it. I mentioned it to LaForge. > > Unfortunately it is more exciting to write code than documents. I almost > > got someone to document at least its proper usage but they backed away > > at the last minute. > > lol > It was very close ;-> The guy looked motivated i felt scared for a while that he will be asking a lot of questions. Then i never heard about it again ;-> I think he left town too. > Yes, it does. Still the question is how to solve this > generally. Consider the following example ruleset: > > 1) src ip 10.0.0.0/30 dst ip 20.0.0.0/20 > 2) src ip 10.0.0.0/28 dst ip 20.0.0.0/22 > 3) src ip 10.0.0.0/26 dst ip 20.0.0.0/24 > 4) src ip 10.0.0.0/24 dst ip 20.0.0.0/26 > 5) src ip 10.0.0.0/22 dst ip 20.0.0.0/28 > 6) src ip 10.0.0.0/20 dst ip 20.0.0.0/30 > > So you have 1 src ip hash and #buckets(src ip hash) many > dst ip hashes. In order to achieve maximum performance > you have to minimize the number of collisions in the > hash buckets. How would you choose the hash function > and what would the construction look like? > It can be done by using the masks - but it would look really ugly. I suppose just providing a good user interface is valuable. > In principle the tree of hashes approach is capable to > express a general access list like ruleset, i.e. a set > of terminal rules with different priorities. The problem > is that the approach is only efficient if the number of > collisions is O(1) -> no amortized analysis but rather > per bucket. > true. > In theory you can do the following. Let's consider one > dimension. The matches in one dimension form a set of > elementary intervals which are overlapped by certain rules. > Example: > > |------| |---------| > |----------------| > |------------------| > |---------------| > > |----|---|--|---|-----|---|----|-------|--|------|-------| > > The '|-----|' reflect the matches and the bottom line > represents the set of elementary intervals introduced > by the matches. Now, you can decide for each elementary > interval which rule matches since the rules are terminal > and uniquely prioritized. > right. Why do you refer to this as one dimension? > The next step would be to create a hash with #elementary > intervals many buckets and create a hash function which > maps the keys to the appropriate buckets like in the picture. > In this case you have exactly 1 entry per hash bucket. > Sounds fine BUT it is not possible to generically deduce > an easily (= fast) computable hash function with the > described requirements. > nod. > BTW, this approach can be extended to 2 or more dimensions > where the hash function for each hash has to meet the > requirement. Of course this information is not very helpful > since the problem of defining appropriate hash functions > remains ;) > Is that problem even solvable? > Obviously this way is not viable but supposedly the only > one to achieve ultimate performance with the tree of hashes > concept. > > BTW, the way hipac works is basically not so different > from the idea described above but since we use efficient > btrees we don't have to define hash functions. > This is why i was wondering how fast your instertions and deletions are. Seems to me you will have to sort the rules everytime. > > sure position could be used as a priority. It is easier/intuitive to > > just have explicit priorities. > > Merely a matter of taste. The way iptables and nf-hipac use > priorities is somewhat more dynamic than the tc way because > they are automatically adjusted if a rule is inserted in between > others. > Dont you think this "dynamic adjustment" is unnecessary. Essentially you enforce a model where every rule is a different priority. > > What "optimizes" could be a user interface or the thread i was talking > > about earlier. > > Hm, this rebalancing is not clear to us. Do you want to rebalance > the tree of hashes? This seems a little strange at the first > glance because the performance of the tree of hashes is dominated > by the number of collisions that need to be resolved and > not the depth of the tree. > The general idea is to recreate the tree if need be based on colisions. I just hope some idiot reading this doesnt go and patent it(has happened before). Think of it as dynamic hash adjustment. Talk to me in private if you are really interested. > > Is your plan to put this in other places other than Linux? > > Currently we are working on the integration in linux. > In general the hipac core is OS and application independent, > so basically it could also be used for some userspace program > which is related to classification and of course in other OS's. > > Any special reason why you are asking this question? > I was wondering why not just optimize it for Linux. You are trying to center the world around nf-hipac - I would just center it around Linux ;-> > > So you got this thought from iptables and took it to the next level? > > Well, in order to support iptables matches and targets we had > to create an appropriate abstraction for them on the hipac > layer. This abstraction can also be used for tc classifiers > if the tcf_result is ignored, i.e. you just consider whether > the filter matched or not. > I am not sure i understood the part about ignoring tcf_result. > > I am still not sure i understand why not use what already exists - but > > i'll just say i dont see it right now. > > If hipac had no support for embedded classifiers you couldn't > express a ruleset like: > 1) [native hipac matches] [u32 filter] [classid] > 2) [native hipac matches] [classid] > You would have to construct rule 1) in a way that it "jumps" > to an external u32 filter. Unfortunately, you cannot jump > back to the hipac filter again in case the u32 filter does > not match so rule 2) is unreachable. This problem is caused > by the fact that cls_hipac can occur at most once per interface. > You show only one classid per rule .. I think i can see what you meant by ignoring tcf_result - essentially you want to have a series of filter rules with different classification enngines, no? But could you not have the filters repeat the same classid for every filter? Also it seems you want to be able to have an action defined for "nomatch" as well as "match" - is that correct? Some form of reclassification when nomatch ? cheers, jamal From davem@redhat.com Thu Aug 7 13:03:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 13:03:27 -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 h77K3NFl013952 for ; Thu, 7 Aug 2003 13:03:24 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id MAA29325; Thu, 7 Aug 2003 12:58:29 -0700 Date: Thu, 7 Aug 2003 12:58:28 -0700 From: "David S. Miller" To: Ben Greear Cc: felix@allot.com, netdev@oss.sgi.com Subject: Re: Ethernet bridge performance Message-Id: <20030807125828.625b6640.davem@redhat.com> In-Reply-To: <3F32AD9D.4010504@candelatech.com> References: <3F3217E7.2080903@allot.com> <3F3284EA.5050406@candelatech.com> <20030807123547.1dcf2353.davem@redhat.com> <3F32AD9D.4010504@candelatech.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4626 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Thu, 07 Aug 2003 12:50:53 -0700 Ben Greear wrote: > David S. Miller wrote: > > In 2.6.x, play with /proc/sys/vm/min_free_kbytes > > Anything to set for 2.4? I've looked for how to tune the 2.4 VM for > some time, but never found anything. Good question. Nothing exists there. The per-zone ->pages_min value is what is controlled by this settting. It should be easy to backport the 2.6.x sysctl to 2.4.x, even for an amateur :-) From davem@redhat.com Thu Aug 7 13:10:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 13:10: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 h77KA1Fl014729 for ; Thu, 7 Aug 2003 13:10:02 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id NAA29361; Thu, 7 Aug 2003 13:05:03 -0700 Date: Thu, 7 Aug 2003 13:05:02 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: nf@hipac.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [RFC] High Performance Packet Classifiction for tc framework Message-Id: <20030807130502.4af9c815.davem@redhat.com> In-Reply-To: <1060286331.1025.73.camel@jzny.localdomain> References: <200307141045.40999.nf@hipac.org> <1058328537.1797.24.camel@jzny.localdomain> <3F16A0E5.1080007@hipac.org> <1059934468.1103.41.camel@jzny.localdomain> <3F2E5CD6.4030500@hipac.org> <1060012260.1103.380.camel@jzny.localdomain> <3F302E04.1090503@hipac.org> <1060286331.1025.73.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4627 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On 07 Aug 2003 15:58:51 -0400 jamal wrote: > > Yes, it does. Still the question is how to solve this > > generally. Consider the following example ruleset: > > > > 1) src ip 10.0.0.0/30 dst ip 20.0.0.0/20 > > 2) src ip 10.0.0.0/28 dst ip 20.0.0.0/22 > > 3) src ip 10.0.0.0/26 dst ip 20.0.0.0/24 > > 4) src ip 10.0.0.0/24 dst ip 20.0.0.0/26 > > 5) src ip 10.0.0.0/22 dst ip 20.0.0.0/28 > > 6) src ip 10.0.0.0/20 dst ip 20.0.0.0/30 > > > > So you have 1 src ip hash and #buckets(src ip hash) many > > dst ip hashes. In order to achieve maximum performance > > you have to minimize the number of collisions in the > > hash buckets. How would you choose the hash function > > and what would the construction look like? > > > > It can be done by using the masks - but it would look really ugly. I > suppose just providing a good user interface is valuable. If you input all the keys into the Jenkins hash, how does it perform? Has anyone even tried that and compared it to all of these fancy multi-level tree like hash things? I think Jenkins would work very well for exactly this kind of application. And it's fully available to the entire kernel via linux/jhash.h and already in use by other things such as the routing cache and the netfilter conntrack code. From shemminger@osdl.org Thu Aug 7 14:22:12 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 14:22:16 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h77LMAFl021019 for ; Thu, 7 Aug 2003 14:22:12 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h77LLvo06916; Thu, 7 Aug 2003 14:21:58 -0700 Date: Thu, 7 Aug 2003 14:21:51 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] skb_pull add unlikely Message-Id: <20030807142151.376e5b3c.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4628 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Yet another case where giving compiler hints may speed up packet fast path. diff -Nru a/include/linux/skbuff.h b/include/linux/skbuff.h --- a/include/linux/skbuff.h Thu Aug 7 14:20:09 2003 +++ b/include/linux/skbuff.h Thu Aug 7 14:20:09 2003 @@ -883,7 +883,7 @@ */ static inline unsigned char *skb_pull(struct sk_buff *skb, unsigned int len) { - return (len > skb->len) ? NULL : __skb_pull(skb, len); + return unlikely(len > skb->len) ? NULL : __skb_pull(skb, len); } extern unsigned char *__pskb_pull_tail(struct sk_buff *skb, int delta); From davem@redhat.com Thu Aug 7 14:34:12 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 14:34:15 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h77LYBFl022100 for ; Thu, 7 Aug 2003 14:34:11 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id OAA29639; Thu, 7 Aug 2003 14:29:15 -0700 Date: Thu, 7 Aug 2003 14:29:15 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] skb_pull add unlikely Message-Id: <20030807142915.64081139.davem@redhat.com> In-Reply-To: <20030807142151.376e5b3c.shemminger@osdl.org> References: <20030807142151.376e5b3c.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4629 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Thu, 7 Aug 2003 14:21:51 -0700 Stephen Hemminger wrote: > Yet another case where giving compiler hints may speed up packet fast path. Applied, thanks Stephen. From shemminger@osdl.org Thu Aug 7 15:45:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 15:45:47 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h77MjiFl024962 for ; Thu, 7 Aug 2003 15:45:45 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h77MjUo29143; Thu, 7 Aug 2003 15:45:30 -0700 Date: Thu, 7 Aug 2003 15:45:24 -0700 From: Stephen Hemminger To: bellucda@tiscali.it, "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] tun driver not cleaning up on module remove Message-Id: <20030807154524.4794ad45.shemminger@osdl.org> In-Reply-To: <200308051910.55823.bellucda@tiscali.it> References: <200308051630.28552.bellucda@tiscali.it> <20030805090647.691daa7e.shemminger@osdl.org> <200308051910.55823.bellucda@tiscali.it> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4630 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev This should fix module unload issues with tun driver in 2.6-test2. Driver was not cleaning up it's devices on module exit. diff -Nru a/drivers/net/tun.c b/drivers/net/tun.c --- a/drivers/net/tun.c Thu Aug 7 15:41:10 2003 +++ b/drivers/net/tun.c Thu Aug 7 15:41:10 2003 @@ -605,7 +605,18 @@ void tun_cleanup(void) { + struct net_device *dev, *nxt; + misc_deregister(&tun_miscdev); + + rtnl_lock(); + for (dev = dev_base; dev; dev = nxt) { + nxt = dev->next; + if (dev->init == tun_net_init) + unregister_netdevice(dev); + } + rtnl_unlock(); + } module_init(tun_init); From Robert.Olsson@data.slu.se Thu Aug 7 15:49:52 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 15:49:55 -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 h77MnoFl025286 for ; Thu, 7 Aug 2003 15:49:52 -0700 Received: (from robert@localhost) by robur.slu.se (8.9.3p2/8.9.3) id AAA06579; Fri, 8 Aug 2003 00:49:34 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16178.55166.157720.889528@robur.slu.se> Date: Fri, 8 Aug 2003 00:49:34 +0200 To: hadi@cyberus.ca Cc: Robert Olsson , Felix Radensky , Ben Greear , netdev@oss.sgi.com Subject: Re: Ethernet bridge performance In-Reply-To: <1060284094.1024.36.camel@jzny.localdomain> References: <3F3217E7.2080903@allot.com> <3F3284EA.5050406@candelatech.com> <3F328A0F.3040005@allot.com> <16178.41976.3643.584516@robur.slu.se> <1060284094.1024.36.camel@jzny.localdomain> X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 4631 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 jamal writes: > Actually seems his biggest problem is he is not running > the NAPI driver Oh! I missed this. Cheers. --ro From davem@redhat.com Thu Aug 7 16:04:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 16:04:03 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h77N3vFl025797 for ; Thu, 7 Aug 2003 16:04:00 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id PAA29885; Thu, 7 Aug 2003 15:59:01 -0700 Date: Thu, 7 Aug 2003 15:59:01 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: bellucda@tiscali.it, netdev@oss.sgi.com Subject: Re: [PATCH] tun driver not cleaning up on module remove Message-Id: <20030807155901.49f1a424.davem@redhat.com> In-Reply-To: <20030807154524.4794ad45.shemminger@osdl.org> References: <200308051630.28552.bellucda@tiscali.it> <20030805090647.691daa7e.shemminger@osdl.org> <200308051910.55823.bellucda@tiscali.it> <20030807154524.4794ad45.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4632 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Thu, 7 Aug 2003 15:45:24 -0700 Stephen Hemminger wrote: > This should fix module unload issues with tun driver in 2.6-test2. > Driver was not cleaning up it's devices on module exit. The fix looks correct, but the dev->init test looks kind of grotty. Why not add a list_head to tun_struct, and then maintain a list rooted in 'tun.c:tun_alldevs_list', then iterate over that in the module_exit() routine? From garzik@gtf.org Thu Aug 7 17:05:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 17:05:23 -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 h7805DFl031771 for ; Thu, 7 Aug 2003 17:05:14 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id 649D3667A; Thu, 7 Aug 2003 20:05:08 -0400 (EDT) Date: Thu, 7 Aug 2003 20:05:08 -0400 From: Jeff Garzik To: torvalds@osdl.org Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [bk patches] 2.6.x net driver updates Message-ID: <20030808000508.GA4464@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: 4633 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Linus, please do a bk pull bk://kernel.bkbits.net/jgarzik/net-drivers-2.6 Others may download the patch from ftp://ftp.??.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.0-test2-bk7-netdrvr1.patch.bz2 This will update the following files: CREDITS | 15 + MAINTAINERS | 8 drivers/net/arm/am79c961a.c | 7 drivers/net/arm/ether00.c | 81 ++++------ drivers/net/arm/ether1.c | 9 - drivers/net/arm/ether3.c | 7 drivers/net/arm/etherh.c | 16 + drivers/net/pcmcia/3c574_cs.c | 18 -- drivers/net/pcmcia/3c589_cs.c | 18 -- drivers/net/pcmcia/axnet_cs.c | 19 -- drivers/net/pcmcia/com20020_cs.c | 14 - drivers/net/pcmcia/fmvj18x_cs.c | 18 -- drivers/net/pcmcia/ibmtr_cs.c | 15 - drivers/net/pcmcia/nmclan_cs.c | 17 -- drivers/net/pcmcia/pcnet_cs.c | 17 -- drivers/net/pcmcia/smc91c92_cs.c | 17 -- drivers/net/pcmcia/xirc2ps_cs.c | 18 -- drivers/net/wireless/airo.c | 33 ++-- drivers/net/wireless/airo_cs.c | 22 -- drivers/net/wireless/netwave_cs.c | 20 -- drivers/net/wireless/orinoco_cs.c | 16 - drivers/net/wireless/ray_cs.c | 22 -- drivers/net/wireless/wavelan_cs.c | 15 - drivers/net/wireless/wavelan_cs.p.h | 2 drivers/net/wireless/wl3501.h | 244 ++++++++++++++++++------------ drivers/net/wireless/wl3501_cs.c | 290 +++++++++++++++++++++++------------- 26 files changed, 534 insertions(+), 444 deletions(-) through these ChangeSets: (03/08/07 1.1130) [netdrvr airo] now that it builds, re-enable wireless_ext (03/08/07 1.1129) [netdrvr airo] Fix adhoc config (03/08/07 1.1128) [netdrvr airo] safer unload code (03/08/07 1.1127) [netdrvr airo] MIC support with newer firmware (03/08/07 1.1126) [netdrvr airo] add missing lines for Wireless Extensions 16 (03/08/07 1.1125) [netdrvr airo] MAC type changed to unsigned (03/08/07 1.1124) [netdrvr airo] Missing defines (only for documentation) (03/08/07 1.1123) [netdrvr pcmcia] remove the release timer from all pcmcia net drivers Ack'd by Russell King as well. (03/08/05 1.1106.1.11) [netdrvr ARM] alloc_etherdev updates (03/07/20 1.1046.409.66) o MAINTAINERS: add acme as wl3501 maintainer Also add Niemeyer to CREDITS for his work on early stages of wireless extensions support for the wl3501 card. (03/07/20 1.1046.409.65) o wl3501: add a first cut, lazy scan triggering for set_scan (03/07/20 1.1046.409.64) o wl3501: implement {get,set}_scan wireless extensions set_scan still needs to trigger a scan, but for now doing something that resets the card, like iwconfig eth0 mode ad-hoc triggers a scanning, and even without that we report the last scan results, good enough for now 8) But it will be implemented, don't worry! :-) (03/07/20 1.1046.409.63) o wl3501: introduce iw_mgmt_data_rset and rate labels enum (03/07/20 1.1046.409.62) o wl3501: introduce struct iw_mgmt_cf_pset Just for completeness, it is included in the mgmt frames, but not used in this driver, i.e. it may well be that this driver supports contention free service, but the original driver had no use for it at all. (03/07/20 1.1046.409.61) o wl3501: introduce iw_mgmt_ibss_pset (03/07/20 1.1046.409.60) o wl3501: fix bug in iw_mgmt_info_element id field and more . unfortunately we can't use enum iw_mgmt_info_element_ids for the id field in iw_mgmt_info_element, as it has to be u8 and sizeof(enum) is bigger than that, but we use the enum in the relevant functions to help catch invalid elements being used. . also we can't have iw_mgmt_info_element with a fixed size data field, as it is variable as per the 802.11 specs, so I do a poor man's OOP by subclassing iw_mgmt_info_element into the standard element types. Done up to now with iw_mgmt_essid_pset and iw_mgmt_ds_pset, others will follow. (03/07/19 1.1046.409.59) o wl3501: fix set_essid wireless extension, using the flags for any (03/07/19 1.1046.409.58) o wl3501: use iw_mgmt_info_element for phy_pset (now ds_parameter_set) Clarifying stuff is good: with this I have fixed a bug in join, where the element id and size were not being set... longstanding one, since original driver times... (03/07/19 1.1046.409.57) o wl3501: introduce iw_mgmt_info_element & associate functions and enums Also aimed at inclusion on the core wireless extensions, with this we are closer to 802.11 specs with regards to frame management elements stuff. Next patches will deal with other elements that are done in a raw way such as the phys parameter set (DS in this driver). From jgarzik@pobox.com Thu Aug 7 17:13:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 17:13:35 -0700 (PDT) Received: from www.linux.org.uk (IDENT:iDu4psLct9F2vi2WRRZDaza09B0IHN9Q@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h780DQFl032207 for ; Thu, 7 Aug 2003 17:13:27 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19kusl-0005PP-QF; Fri, 08 Aug 2003 01:13:23 +0100 Message-ID: <3F32EB18.2040801@pobox.com> Date: Thu, 07 Aug 2003 20:13:12 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: Amir Noam CC: fubar@us.ibm.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH 2/5] [bonding] backport 2.6 changes to 2.4 References: <200307302007.09735.amir.noam@intel.com> In-Reply-To: <200307302007.09735.amir.noam@intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4634 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev applied to 2.4 From jgarzik@pobox.com Thu Aug 7 17:28:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 17:28:39 -0700 (PDT) Received: from www.linux.org.uk (IDENT:rrdIOIvwAUxWDfPPS1dqztE3tJNYzQJq@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h780SWFl000561 for ; Thu, 7 Aug 2003 17:28:33 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19kv7P-0005Vd-Bd; Fri, 08 Aug 2003 01:28:31 +0100 Message-ID: <3F32EEA3.2000507@pobox.com> Date: Thu, 07 Aug 2003 20:28:19 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: Amir Noam CC: fubar@us.ibm.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH 4/5] [bonding] backport 2.6 changes to 2.4 References: <200307302007.21369.amir.noam@intel.com> In-Reply-To: <200307302007.21369.amir.noam@intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4635 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 Amir Noam wrote: > Backported from 2.6: > Don't dynamically allocate a net_device_stats structure for each bond, > instead allocate it with the bonding structure. > > Since they are always allocated together anyway, we might as well put > the stats struct within the bond. applied to 2.4. From garzik@gtf.org Thu Aug 7 17:59:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 17:59:31 -0700 (PDT) Received: from havoc.gtf.org (host-64-213-145-173.atlantasolutions.com [64.213.145.173] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h780xOFl002085 for ; Thu, 7 Aug 2003 17:59:25 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id 2FAE16643; Thu, 7 Aug 2003 20:59:19 -0400 (EDT) Date: Thu, 7 Aug 2003 20:59:19 -0400 From: Jeff Garzik To: netdev@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: [bk patches] 2.4.x net driver updates Message-ID: <20030808005919.GA14081@gtf.org> Reply-To: netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-archive-position: 4636 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev (this will be sent to Marcelo when 2.4.23-pre1 opens) BK users: bk pull bk://kernel.bkbits.net/jgarzik/net-drivers-2.4 GNU diff: ftp://ftp.??.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.4/2.4.22-rc1-netdrvr1.patch.bz2 This will update the following files: drivers/net/bonding/bond_main.c | 17 +++-------------- drivers/net/bonding/bonding.h | 2 +- drivers/net/net_init.c | 3 ++- drivers/net/wireless/airo.c | 31 +++++++++++++++++++------------ include/linux/netdevice.h | 2 ++ 5 files changed, 27 insertions(+), 28 deletions(-) through these ChangeSets: (03/08/07 1.1072) [netdrvr bonding] embed stats struct inside bonding private struct Simplification: Don't allocate the stats struct via kmalloc, embed it inside it's parent bonding_t. (03/08/07 1.1071) [net] export alloc_netdev (03/08/07 1.1070) [PATCH] Fix adhoc config (03/08/07 1.1069) [PATCH] Safer unload code (03/08/07 1.1068) [PATCH] MIC support with newer firmware (03/08/07 1.1067) [PATCH] Missing lines for Wireless Extensions 16 (03/08/07 1.1066) [netdrvr airo] MAC type changed to unsigned (03/08/07 1.1065) [netdrvr airo] Missing defines (only for documentation) From minniewkitty@yahoo.com.cn Thu Aug 7 19:55:19 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 19:55:21 -0700 (PDT) Received: from web15211.mail.bjs.yahoo.com (web15211.mail.bjs.yahoo.com [202.3.77.141]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h782tGFl015323 for ; Thu, 7 Aug 2003 19:55:18 -0700 Message-ID: <20030808025509.4328.qmail@web15211.mail.bjs.yahoo.com> Received: from [218.90.189.254] by web15211.mail.bjs.yahoo.com via HTTP; Fri, 08 Aug 2003 10:55:09 CST Date: Fri, 8 Aug 2003 10:55:09 +0800 (CST) From: =?gb2312?q?minnie=20wu?= Subject: How to improve small packet performance? To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1326245407-1060311309=:1975" Content-Transfer-Encoding: 8bit X-archive-position: 4637 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: minniewkitty@yahoo.com.cn Precedence: bulk X-list: netdev --0-1326245407-1060311309=:1975 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Hi, all! I'm working on e100/eepro100, kernel version 2.4.20. I used NAPI, but the 64 bit small packet dual throughout is only 28M/s. How to improve small packet performance further? --------------------------------- Do You Yahoo!? ÊîÆÚ´óƬÆë¾ÛÑÅ»¢Í¨ ÍøÂçÉãÏñÍ·+ÑÅ»¢Í¨µ÷ƵÊÕÒô»úµÈÄãÀ´Äà --0-1326245407-1060311309=:1975 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 8bit
Hi, all!
     I'm working on e100/eepro100, kernel version 2.4.20. I used NAPI, but the 64 bit small packet dual throughout is only 28M/s. How to improve small packet performance further?


Do You Yahoo!?
ÊîÆÚ´óƬÆë¾ÛÑÅ»¢Í¨ ÍøÂçÉãÏñÍ·+ÑÅ»¢Í¨µ÷ƵÊÕÒô»úµÈÄãÀ´Äà --0-1326245407-1060311309=:1975-- From garzik@gtf.org Thu Aug 7 20:32:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 20:32:32 -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 h783WPFl018945 for ; Thu, 7 Aug 2003 20:32:26 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id 9B9616643; Thu, 7 Aug 2003 23:32:19 -0400 (EDT) Date: Thu, 7 Aug 2003 23:32:19 -0400 From: Jeff Garzik To: netdev@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: [bk patches 2.6] ethtool_ops Message-ID: <20030808033219.GA5779@gtf.org> Reply-To: netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-archive-position: 4638 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 Eventually destined for Linus, after some testing, and I after I merge willy's 8139too.c conversion. This ethtool_ops update doesn't break existing drivers, allowing for piecemeal migration. BK users: bk pull http://gkernel.bkbits.net/ethtool-2.6 GNU diff: ftp://ftp.??.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.0-test2-bk7-ethtool1.patch.bz2 This will update the following files: drivers/net/tg3.c | 664 +++++++++++++++++++-------------------------- include/linux/ethtool.h | 99 ++++++ include/linux/netdevice.h | 9 net/core/Makefile | 4 net/core/dev.c | 16 - net/core/ethtool.c | 672 ++++++++++++++++++++++++++++++++++++++++++++++ 6 files changed, 1076 insertions(+), 388 deletions(-) through these ChangeSets: (03/08/07 1.1119.3.3) [netdrvr] add SET_ETHTOOL_OPS back-compat hook (03/08/07 1.1119.3.2) [netdrvr tg3] convert to using ethtool_ops [also contributed by Matthew Wilcox -jg] (03/08/07 1.1119.3.1) [netdrvr] add ethtool_ops to struct net_device, and associated infrastructure Contributed by Matthew Wilcox. From davem@redhat.com Thu Aug 7 20:44:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 20:44:53 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h783imFl020861 for ; Thu, 7 Aug 2003 20:44:49 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id UAA30328; Thu, 7 Aug 2003 20:39:54 -0700 Date: Thu, 7 Aug 2003 20:39:53 -0700 From: "David S. Miller" To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, linux-kernel@vger.kernel.org Subject: Re: [bk patches 2.6] ethtool_ops Message-Id: <20030807203953.5b4bbc6f.davem@redhat.com> In-Reply-To: <20030808033219.GA5779@gtf.org> References: <20030808033219.GA5779@gtf.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4639 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Thu, 7 Aug 2003 23:32:19 -0400 Jeff Garzik wrote: > ftp://ftp.??.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.0-test2-bk7-ethtool1.patch.bz2 Two thumbs up :) From davem@redhat.com Thu Aug 7 21:38:57 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 21:39:01 -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 h784cuFl032707 for ; Thu, 7 Aug 2003 21:38:57 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id VAA30550; Thu, 7 Aug 2003 21:32:59 -0700 Date: Thu, 7 Aug 2003 21:32:59 -0700 From: "David S. Miller" To: Ville Nuorvala Cc: netdev@oss.sgi.com Subject: Re: [PATCH] IPV6: Fix bugs in ip6ip6_tnl_xmit() Message-Id: <20030807213259.56c953d5.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4640 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 5 Aug 2003 16:42:32 +0300 (EEST) Ville Nuorvala wrote: > There were two bugs in ip6ip6_tnl_xmit() which are fixed in this patch > (made against Linux 2.6.0-test2 + cset 1.1612): > > - ip6_tunnel must give its own getfrag function to ip6_append_data() > - fix dst leakage when encapsulated packet too big Patch applied, thank you Ville. From davem@redhat.com Thu Aug 7 21:53:04 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 21:53:09 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h784r3Fl000697 for ; Thu, 7 Aug 2003 21:53:04 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id VAA30601; Thu, 7 Aug 2003 21:47:33 -0700 Date: Thu, 7 Aug 2003 21:47:32 -0700 From: "David S. Miller" To: Kazunori Miyazawa Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, usagi@linux-ipv6.org, latten@austin.ibm.com Subject: Re: [PATCH][IPV6] fix clearing in ah6 input Message-Id: <20030807214732.1d16cc94.davem@redhat.com> In-Reply-To: <20030806162808.4edf9eeb.kazunori@miyazawa.org> References: <20030806162808.4edf9eeb.kazunori@miyazawa.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4641 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 6 Aug 2003 16:28:08 +0900 Kazunori Miyazawa wrote: > This patch fixes zero-clear in ah6_input. > If calling pskb_expand_head, the kernel clears wrong memory. Patch applied, thank you very much. From davem@redhat.com Thu Aug 7 22:11:09 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 22:11:13 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h785B9Fl002516 for ; Thu, 7 Aug 2003 22:11:09 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id WAA30648; Thu, 7 Aug 2003 22:05:39 -0700 Date: Thu, 7 Aug 2003 22:05:39 -0700 From: "David S. Miller" To: Kazunori Miyazawa Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, usagi@linux-ipv6.org, latten@austin.ibm.com Subject: Re: [PATCH][IPV6] fixed authentication error with TCP Message-Id: <20030807220539.4555db2d.davem@redhat.com> In-Reply-To: <20030806164413.669ef5f8.kazunori@miyazawa.org> References: <20030806164413.669ef5f8.kazunori@miyazawa.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4642 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 6 Aug 2003 16:44:13 +0900 Kazunori Miyazawa wrote: > Miss Joy (@IBM) and I investigated the bug that "authentication > error" occured with using TCP and AH in IPv6. This patch fixes the > bug. This patch makes the kernel consider extension header length in > a dst. > > This pach works with my previous patch which fixes zero-clear in ah6_input. > > Please append the name "Joy Latten" into the log. I have applied this patch, thank you. But I see a small area for improvement. Look at the place inside of ip6_dst_lookup() where we do source address selection. If this fails, we mark error to dst->error. Is it correct? This 'dst' route might otherwise be perfectly fine. But now that dst->error is set, it is poisoned for other users and they are not able to use it. A similar case occurs further down after the xfrm_lookup() call, but this one I think is correct. It seems to me that it is only OK for dst->error to be set on routes that may not be used validly for anything. Alexey, do I understand this stuff correctly? From davem@redhat.com Thu Aug 7 22:39:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Aug 2003 22:40:00 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h785dqFl004988 for ; Thu, 7 Aug 2003 22:39:52 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id WAA30718; Thu, 7 Aug 2003 22:34:22 -0700 Date: Thu, 7 Aug 2003 22:34:21 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: ipv6 UDP MSG_MORE oops fix Message-Id: <20030807223421.70497d61.davem@redhat.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4643 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 Yoshfuji-san, I found the MSG_MORE udp bug. If "np->pending" is true, we call ip_dst_store() with uninitialized dst, it could be any kind of garbage. This is dereferenced and we crash. If np->pending, we have some 'dst' stored into the socket already. So no need to relookup dst or anything like that. This is the fix I am using, on top of Miyazawa-san's ah6_input and authentication error patches. # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1167 -> 1.1168 # net/ipv6/ip6_output.c 1.40 -> 1.41 # net/ipv6/raw.c 1.38 -> 1.39 # net/ipv6/udp.c 1.45 -> 1.46 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 03/08/07 davem@nuts.ninka.net 1.1168 # [IPV6]: Make sure errors propagate properly in {udp,raw} sendmsg. # -------------------------------------------- # diff -Nru a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c --- a/net/ipv6/ip6_output.c Thu Aug 7 22:34:06 2003 +++ b/net/ipv6/ip6_output.c Thu Aug 7 22:34:06 2003 @@ -209,7 +209,6 @@ int seg_len = skb->len; int hlimit; u32 mtu; - int err = 0; if (opt) { int head_room; diff -Nru a/net/ipv6/raw.c b/net/ipv6/raw.c --- a/net/ipv6/raw.c Thu Aug 7 22:34:06 2003 +++ b/net/ipv6/raw.c Thu Aug 7 22:34:06 2003 @@ -659,7 +659,7 @@ fl.oif = np->mcast_oif; dst = ip6_dst_lookup(sk, &fl); - if (dst->error) + if ((err = dst->error)) goto out; if (hlimit < 0) { diff -Nru a/net/ipv6/udp.c b/net/ipv6/udp.c --- a/net/ipv6/udp.c Thu Aug 7 22:34:06 2003 +++ b/net/ipv6/udp.c Thu Aug 7 22:34:06 2003 @@ -811,8 +811,10 @@ * The socket lock must be held while it's corked. */ lock_sock(sk); - if (likely(up->pending)) + if (likely(up->pending)) { + dst = NULL; goto do_append_data; + } release_sock(sk); } ulen += sizeof(struct udphdr); @@ -929,7 +931,7 @@ fl.oif = np->mcast_oif; dst = ip6_dst_lookup(sk, &fl); - if (dst->error) + if ((err = dst->error)) goto out; if (hlimit < 0) { @@ -968,9 +970,10 @@ else if (!corkreq) err = udp_v6_push_pending_frames(sk, up); - ip6_dst_store(sk, dst, - !ipv6_addr_cmp(&fl.fl6_dst, &np->daddr) ? - &np->daddr : NULL); + if (dst) + ip6_dst_store(sk, dst, + !ipv6_addr_cmp(&fl.fl6_dst, &np->daddr) ? + &np->daddr : NULL); if (err > 0) err = np->recverr ? net_xmit_errno(err) : 0; release_sock(sk); From yoshfuji@linux-ipv6.org Fri Aug 8 01:08:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Aug 2003 01:08:46 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7888cFl017755 for ; Fri, 8 Aug 2003 01:08:39 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h7888d1M027014; Fri, 8 Aug 2003 17:08:40 +0900 Date: Fri, 08 Aug 2003 17:08:39 +0900 (JST) Message-Id: <20030808.170839.90822982.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: ipv6 UDP MSG_MORE oops fix From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20030807223421.70497d61.davem@redhat.com> References: <20030807223421.70497d61.davem@redhat.com> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4644 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <20030807223421.70497d61.davem@redhat.com> (at Thu, 7 Aug 2003 22:34:21 -0700), "David S. Miller" says: > Yoshfuji-san, I found the MSG_MORE udp bug. Yes, thanks. This is what I told you before. I'm going to test if problems go away with this patch. --yoshfuji From yoshfuji@linux-ipv6.org Fri Aug 8 01:45:08 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Aug 2003 01:45:18 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h788j6Fl001169 for ; Fri, 8 Aug 2003 01:45:07 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h788j51M029224; Fri, 8 Aug 2003 17:45:06 +0900 Date: Fri, 08 Aug 2003 17:45:04 +0900 (JST) Message-Id: <20030808.174504.14391608.yoshfuji@linux-ipv6.org> To: jan.oravec@6com.sk Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: problem setting net.ipvX.conf.all.forwarding via sysctl() system call From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20030803154427.GA12926@wsx.ksp.sk> References: <20030803154427.GA12926@wsx.ksp.sk> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4645 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <20030803154427.GA12926@wsx.ksp.sk> (at Sun, 3 Aug 2003 17:44:27 +0200), Jan Oravec says: > For IPv4, it is because ipv4_sysctl_forward_strategy only copy new value to > check whether it has changed and does not update ipv4_devconf.forwarding > before calling inet_forward_change(). (it is copied internally by sysctl > after ipv4_sysctl_forward_strategy because we return positive number) > > I am not good in kernel parallel computing strategy, whether it requires > some locking or it is safe to do: > > --- sysctl_net_ipv4.c.old 2003-08-03 17:37:44.000000000 +0200 > +++ sysctl_net_ipv4.c 2003-08-03 17:38:18.000000000 +0200 > @@ -109,8 +109,9 @@ static int ipv4_sysctl_forward_strategy( > } > } > > + ipv4_devconf.forwarding=new; = new; > inet_forward_change(); > - return 1; > + return 0; > } > > ctl_table ipv4_table[] = { It seems correct, however, this patch cannot apply against current tree. Pleaes resend the patch. And please make sure to diff like this: diff -u linux-2.6/net/ipv4/sysctl_net_ipv4.c.old linux-2.6/net/ipv4/sysctl_net_ipv4.c Thank you. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From yoshfuji@linux-ipv6.org Fri Aug 8 01:50:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Aug 2003 01:50:30 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h788oPFl001570 for ; Fri, 8 Aug 2003 01:50:26 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h788oU1M029268; Fri, 8 Aug 2003 17:50:31 +0900 Date: Fri, 08 Aug 2003 17:50:30 +0900 (JST) Message-Id: <20030808.175030.19527061.yoshfuji@linux-ipv6.org> To: davem@redhat.com CC: yoshfuji@linux-ipv6.org, jan.oravec@6com.sk, netdev@oss.sgi.com Subject: [PATCH] IPV6: strategy hander for net.ipv6.conf.*.forwarding (is Re: problem setting net.ipvX.conf.all.forwarding via sysctl() system call) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20030803154427.GA12926@wsx.ksp.sk> References: <20030803154427.GA12926@wsx.ksp.sk> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4646 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <20030803154427.GA12926@wsx.ksp.sk> (at Sun, 3 Aug 2003 17:44:27 +0200), Jan Oravec says: > For IPv6, it is obviously because sysctl 'strategy' handler is not defined. Here's tha patch to add strategy handler for net.ipv6.conf.*.forwarding. Thanks. Index: linux-2.6/net/ipv6/addrconf.c =================================================================== RCS file: /home/cvs/linux-2.5/net/ipv6/addrconf.c,v retrieving revision 1.48 diff -u -r1.48 addrconf.c --- linux-2.6/net/ipv6/addrconf.c 25 Jul 2003 23:58:59 -0000 1.48 +++ linux-2.6/net/ipv6/addrconf.c 8 Aug 2003 07:12:13 -0000 @@ -2593,6 +2593,48 @@ return ret; } +static int addrconf_sysctl_forward_strategy(ctl_table *table, + int *name, int nlen, + void *oldval, size_t *oldlenp, + void *newval, size_t newlen, + void **context) +{ + int *valp = table->data; + int new; + + if (!newval || !newlen) + return 0; + if (newlen != sizeof(int)) + return -EINVAL; + if (get_user(new, (int *)newval)) + return -EFAULT; + if (new == *valp) + return 0; + if (oldval && oldlenp) { + size_t len; + if (get_user(len, oldlenp)) + return -EFAULT; + if (len) { + if (len > table->maxlen) + len = table->maxlen; + if (copy_to_user(oldval, valp, len)) + return -EFAULT; + if (put_user(len, oldlenp)) + return -EFAULT; + } + } + + *valp = new; + if (valp != &ipv6_devconf.forwarding && + valp != &ipv6_devconf_dflt.forwarding) { + struct inet6_dev *idev = (struct inet6_dev *)table->extra1; + if (!idev) + return -ENODEV; + addrconf_forward_change(idev); + } + return 0; +} + static struct addrconf_sysctl_table { struct ctl_table_header *sysctl_header; @@ -2611,6 +2653,7 @@ .maxlen = sizeof(int), .mode = 0644, .proc_handler = &addrconf_sysctl_forward, + .strategy = &addrconf_sysctl_forward_strategy, }, { .ctl_name = NET_IPV6_HOP_LIMIT, -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From yoshfuji@linux-ipv6.org Fri Aug 8 02:51:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Aug 2003 02:51:43 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h789pVFl014572 for ; Fri, 8 Aug 2003 02:51:32 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h789pZ1M029766; Fri, 8 Aug 2003 18:51:35 +0900 Date: Fri, 08 Aug 2003 18:51:35 +0900 (JST) Message-Id: <20030808.185135.112441851.yoshfuji@linux-ipv6.org> To: jan.oravec@6com.sk, davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] IPV6: strategy hander for net.ipv6.conf.*.forwarding (is Re: problem setting net.ipvX.conf.all.forwarding via sysctl() system call) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20030808093704.GA18131@wsx.ksp.sk> References: <20030803154427.GA12926@wsx.ksp.sk> <20030808.175030.19527061.yoshfuji@linux-ipv6.org> <20030808093704.GA18131@wsx.ksp.sk> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4647 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <20030808093704.GA18131@wsx.ksp.sk> (at Fri, 8 Aug 2003 11:37:04 +0200), Jan Oravec says: > On Fri, Aug 08, 2003 at 05:50:30PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > > + *valp = new; > > + if (valp != &ipv6_devconf.forwarding && > > + valp != &ipv6_devconf_dflt.forwarding) { > > + struct inet6_dev *idev = (struct inet6_dev *)table->extra1; > > + if (!idev) > > + return -ENODEV; > > + addrconf_forward_change(idev); > > + } > > + return 0; > > +} > > Shouldn't we set ipv6_devconf_dflt.forwarding and call > addr_forward_change(NULL) in case that valp==&ipv6_devconf.forwarding? Oh, You're right. Here's the revised one: Index: linux-2.6/net/ipv6/addrconf.c =================================================================== RCS file: /home/cvs/linux-2.5/net/ipv6/addrconf.c,v retrieving revision 1.48 diff -u -r1.48 addrconf.c --- linux-2.6/net/ipv6/addrconf.c 25 Jul 2003 23:58:59 -0000 1.48 +++ linux-2.6/net/ipv6/addrconf.c 8 Aug 2003 08:21:56 -0000 @@ -2593,6 +2593,51 @@ return ret; } +static int addrconf_sysctl_forward_strategy(ctl_table *table, + int *name, int nlen, + void *oldval, size_t *oldlenp, + void *newval, size_t newlen, + void **context) +{ + int *valp = table->data; + int new; + + if (!newval || !newlen) + return 0; + if (newlen != sizeof(int)) + return -EINVAL; + if (get_user(new, (int *)newval)) + return -EFAULT; + if (new == *valp) + return 0; + if (oldval && oldlenp) { + size_t len; + if (get_user(len, oldlenp)) + return -EFAULT; + if (len) { + if (len > table->maxlen) + len = table->maxlen; + if (copy_to_user(oldval, valp, len)) + return -EFAULT; + if (put_user(len, oldlenp)) + return -EFAULT; + } + } + + *valp = new; + if (valp != &ipv6_devconf_dflt.forwarding) { + struct inet6_dev *idev; + if (valp != &ipv6_devconf.forwarding) { + idev = (struct inet6_dev *)table->extra1; + if (unlikely(idev == NULL)) + return -ENODEV; + } else + idev = NULL; + addrconf_forward_change(idev); + } + return 0; +} + static struct addrconf_sysctl_table { struct ctl_table_header *sysctl_header; @@ -2611,6 +2656,7 @@ .maxlen = sizeof(int), .mode = 0644, .proc_handler = &addrconf_sysctl_forward, + .strategy = &addrconf_sysctl_forward_strategy, }, { .ctl_name = NET_IPV6_HOP_LIMIT, -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From wsx@6com.sk Fri Aug 8 02:52:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Aug 2003 02:53:02 -0700 (PDT) Received: from mail.6com.sk (cement.ksp.edi.fmph.uniba.sk [158.195.16.151] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h789qgFl014863 for ; Fri, 8 Aug 2003 02:52:42 -0700 Received: by mail.6com.sk (Postfix, from userid 501) id 45EF328A8E; Fri, 8 Aug 2003 11:11:24 +0200 (CEST) Date: Fri, 8 Aug 2003 11:11:24 +0200 From: Jan Oravec To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: netdev@oss.sgi.com, davem@redhat.com Subject: Re: problem setting net.ipvX.conf.all.forwarding via sysctl() system call Message-ID: <20030808091124.GA17961@wsx.ksp.sk> Reply-To: Jan Oravec References: <20030803154427.GA12926@wsx.ksp.sk> <20030808.174504.14391608.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030808.174504.14391608.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.4.1i X-Operating-System: UNIX X-archive-position: 4648 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jan.oravec@6com.sk Precedence: bulk X-list: netdev Hello, this is a new patch > It seems correct, however, this patch cannot apply against > current tree. Pleaes resend the patch. > And please make sure to diff like this: > diff -u linux-2.6/net/ipv4/sysctl_net_ipv4.c.old linux-2.6/net/ipv4/sysctl_net_ipv4.c diff -u linux-2.6.0-test2/net/ipv4/sysctl_net_ipv4.c.old linux-2.6.0-test2/net/ipv4/sysctl_net_ipv4.c --- linux-2.6.0-test2/net/ipv4/sysctl_net_ipv4.c.old 2003-07-27 19:06:19.000000000 +0200 +++ linux-2.6.0-test2/net/ipv4/sysctl_net_ipv4.c 2003-08-08 10:56:31.000000000 +0200 @@ -109,8 +109,9 @@ } } + ipv4_devconf.forwarding = new; inet_forward_change(); - return 1; + return 0; } ctl_table ipv4_table[] = { Thanks, -- Jan Oravec XS26 coordinator 6COM s.r.o. 'Access to IPv6' http://www.6com.sk http://www.xs26.net From wsx@6com.sk Fri Aug 8 03:09:32 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Aug 2003 03:09:40 -0700 (PDT) Received: from mail.6com.sk (cement.ksp.edi.fmph.uniba.sk [158.195.16.151] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h78A9LFl016402 for ; Fri, 8 Aug 2003 03:09:22 -0700 Received: by mail.6com.sk (Postfix, from userid 501) id EE09528A98; Fri, 8 Aug 2003 11:37:04 +0200 (CEST) Date: Fri, 8 Aug 2003 11:37:04 +0200 From: Jan Oravec To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] IPV6: strategy hander for net.ipv6.conf.*.forwarding (is Re: problem setting net.ipvX.conf.all.forwarding via sysctl() system call) Message-ID: <20030808093704.GA18131@wsx.ksp.sk> Reply-To: Jan Oravec References: <20030803154427.GA12926@wsx.ksp.sk> <20030808.175030.19527061.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030808.175030.19527061.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.4.1i X-Operating-System: UNIX X-archive-position: 4649 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jan.oravec@6com.sk Precedence: bulk X-list: netdev On Fri, Aug 08, 2003 at 05:50:30PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > + *valp = new; > + if (valp != &ipv6_devconf.forwarding && > + valp != &ipv6_devconf_dflt.forwarding) { > + struct inet6_dev *idev = (struct inet6_dev *)table->extra1; > + if (!idev) > + return -ENODEV; > + addrconf_forward_change(idev); > + } > + return 0; > +} Shouldn't we set ipv6_devconf_dflt.forwarding and call addr_forward_change(NULL) in case that valp==&ipv6_devconf.forwarding? -- Jan Oravec XS26 coordinator 6COM s.r.o. 'Access to IPv6' http://www.6com.sk http://www.xs26.net From jchapman@katalix.com Fri Aug 8 03:27:42 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Aug 2003 03:27:50 -0700 (PDT) Received: from plesk.avahost.net ([216.40.206.200]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h78ARfFl017883 for ; Fri, 8 Aug 2003 03:27:42 -0700 Received: (qmail 6399 invoked by uid 10623); 8 Aug 2003 17:38:57 -0000 Received: from 212.56.89.216 ( [212.56.89.216]) as user jchapman@localhost by webmail.katalix.com with HTTP; Fri, 8 Aug 2003 12:38:57 -0500 Message-ID: <1060364337.3f33e0318bf82@webmail.katalix.com> Date: Fri, 8 Aug 2003 12:38:57 -0500 From: jchapman@katalix.com To: netdev@oss.sgi.com Subject: Re: How to improve small packet performance MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 212.56.89.216 X-archive-position: 4650 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jchapman@katalix.com Precedence: bulk X-list: netdev Try the latest e100 development driver from sf.net/projects/e1000. Make sure you compile it with NAPI enabled. - jc minnie wu wrote: > Hi, all! > I'm working on e100/eepro100, kernel version 2.4.20. I used NAPI, but > the 64 bit small packet dual throughout is only 28M/s. How to improve small > packet performance further? ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ From wsx@6com.sk Fri Aug 8 04:40:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Aug 2003 04:40:09 -0700 (PDT) Received: from mail.6com.sk (cement.ksp.edi.fmph.uniba.sk [158.195.16.151] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h78Be0Fl023512 for ; Fri, 8 Aug 2003 04:40:01 -0700 Received: by mail.6com.sk (Postfix, from userid 501) id 32E1020D1A; Fri, 8 Aug 2003 13:39:55 +0200 (CEST) Date: Fri, 8 Aug 2003 13:39:55 +0200 From: Jan Oravec To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] IPV6: strategy hander for net.ipv6.conf.*.forwarding (is Re: problem setting net.ipvX.conf.all.forwarding via sysctl() system call) Message-ID: <20030808113955.GA18307@wsx.ksp.sk> Reply-To: Jan Oravec References: <20030803154427.GA12926@wsx.ksp.sk> <20030808.175030.19527061.yoshfuji@linux-ipv6.org> <20030808093704.GA18131@wsx.ksp.sk> <20030808.185135.112441851.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030808.185135.112441851.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.4.1i X-Operating-System: UNIX X-archive-position: 4651 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jan.oravec@6com.sk Precedence: bulk X-list: netdev On Fri, Aug 08, 2003 at 06:51:35PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > Oh, You're right. Here's the revised one: Thanks, I tried it and it works. -- Jan Oravec XS26 coordinator 6COM s.r.o. 'Access to IPv6' http://www.6com.sk http://www.xs26.net From yoshfuji@linux-ipv6.org Fri Aug 8 06:37:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Aug 2003 06:37:40 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h78DbYFl007489 for ; Fri, 8 Aug 2003 06:37:35 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h78Dbg1M031881; Fri, 8 Aug 2003 22:37:43 +0900 Date: Fri, 08 Aug 2003 22:37:42 +0900 (JST) Message-Id: <20030808.223742.55652930.yoshfuji@linux-ipv6.org> To: davem@redhat.com CC: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: [PATCH] IPV6: typo in include/linux/ipv6.h From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4652 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Hello. Typo in definition in include/linux/ipv6.h. 2.4.x has similar bug, too. Thanks. Index: linux-2.6/include/linux/ipv6.h =================================================================== RCS file: /home/cvs/linux-2.5/include/linux/ipv6.h,v retrieving revision 1.11 diff -u -r1.11 ipv6.h --- linux-2.6/include/linux/ipv6.h 3 Aug 2003 18:34:10 -0000 1.11 +++ linux-2.6/include/linux/ipv6.h 8 Aug 2003 12:05:41 -0000 @@ -71,7 +71,7 @@ __u32 bitmap; /* strict/loose bit map */ struct in6_addr addr[0]; -#define rt0_type rt_hdr.type; +#define rt0_type rt_hdr.type }; struct ipv6_auth_hdr { -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From shmulik.hen@intel.com Fri Aug 8 07:45:10 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Aug 2003 07:45:16 -0700 (PDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h78Ej8Fl018008 for ; Fri, 8 Aug 2003 07:45:09 -0700 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h78Ecxw27752 for ; Fri, 8 Aug 2003 14:39:00 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h78E86T06961 for ; Fri, 8 Aug 2003 14:08:06 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.254.188]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003080807571209908 ; Fri, 08 Aug 2003 07:57:13 -0700 Content-Type: text/plain; charset="us-ascii" From: Shmulik Hen Reply-To: shmulik.hen@intel.com Organization: Intel corp. Subject: [SET 2][PATCH 2/8][bonding] Propagating master's settings to slaves Date: Fri, 8 Aug 2003 17:44:58 +0300 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit To: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Message-Id: <200308081744.58946.shmulik.hen@intel.com> X-archive-position: 4662 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev 2 - Change monitoring function use the new functionality. diff -Nuarp linux-2.4.22-rc1/drivers/net/bonding/bond_main.c linux-2.4.22-rc1-devel/drivers/net/bonding/bond_main.c --- linux-2.4.22-rc1/drivers/net/bonding/bond_main.c Fri Aug 8 14:03:16 2003 +++ linux-2.4.22-rc1-devel/drivers/net/bonding/bond_main.c Fri Aug 8 14:03:17 2003 @@ -2207,8 +2207,9 @@ out: static void bond_mii_monitor(struct net_device *master) { bonding_t *bond = (struct bonding *) master->priv; - slave_t *slave, *bestslave, *oldcurrent; + slave_t *slave, *oldcurrent; int slave_died = 0; + int do_failover = 0; read_lock(&bond->lock); @@ -2218,7 +2219,6 @@ static void bond_mii_monitor(struct net_ * program could monitor the link itself if needed. */ - bestslave = NULL; slave = (slave_t *)bond; read_lock(&bond->ptrlock); @@ -2226,8 +2226,6 @@ static void bond_mii_monitor(struct net_ read_unlock(&bond->ptrlock); while ((slave = slave->prev) != (slave_t *)bond) { - /* use updelay+1 to match an UP slave even when updelay is 0 */ - int mindelay = updelay + 1; struct net_device *dev = slave->dev; int link_state; u16 old_speed = slave->speed; @@ -2238,14 +2236,7 @@ static void bond_mii_monitor(struct net_ switch (slave->link) { case BOND_LINK_UP: /* the link was up */ if (link_state == BMSR_LSTATUS) { - /* link stays up, tell that this one - is immediately available */ - if (IS_UP(dev) && (mindelay > -2)) { - /* -2 is the best case : - this slave was already up */ - mindelay = -2; - bestslave = slave; - } + /* link stays up, nothing more to do */ break; } else { /* link going down */ @@ -2285,6 +2276,7 @@ static void bond_mii_monitor(struct net_ (bond_mode == BOND_MODE_8023AD)) { bond_set_slave_inactive_flags(slave); } + printk(KERN_INFO "%s: link status definitely down " "for interface %s, disabling it", @@ -2301,12 +2293,10 @@ static void bond_mii_monitor(struct net_ bond_alb_handle_link_change(bond, slave, BOND_LINK_DOWN); } - write_lock(&bond->ptrlock); - if (slave == bond->current_slave) { - /* find a new interface and be verbose */ - reselect_active_interface(bond); + if (slave == oldcurrent) { + do_failover = 1; } - write_unlock(&bond->ptrlock); + slave_died = 1; } else { slave->delay--; @@ -2321,13 +2311,6 @@ static void bond_mii_monitor(struct net_ master->name, (downdelay - slave->delay) * miimon, dev->name); - - if (IS_UP(dev) && (mindelay > -1)) { - /* -1 is a good case : this slave went - down only for a short time */ - mindelay = -1; - bestslave = slave; - } } break; case BOND_LINK_DOWN: /* the link was down */ @@ -2397,26 +2380,12 @@ static void bond_mii_monitor(struct net_ bond_alb_handle_link_change(bond, slave, BOND_LINK_UP); } - write_lock(&bond->ptrlock); - if ( (bond->primary_slave != NULL) - && (slave == bond->primary_slave) ) - reselect_active_interface(bond); - write_unlock(&bond->ptrlock); - } - else + if ((oldcurrent == NULL) || + (slave == bond->primary_slave)) { + do_failover = 1; + } + } else { slave->delay--; - - /* we'll also look for the mostly eligible slave */ - if (bond->primary_slave == NULL) { - if (IS_UP(dev) && (slave->delay < mindelay)) { - mindelay = slave->delay; - bestslave = slave; - } - } else if ( (IS_UP(bond->primary_slave->dev)) || - ( (!IS_UP(bond->primary_slave->dev)) && - (IS_UP(dev) && (slave->delay < mindelay)) ) ) { - mindelay = slave->delay; - bestslave = slave; } } break; @@ -2435,26 +2404,17 @@ static void bond_mii_monitor(struct net_ } /* end of while */ - /* - * if there's no active interface and we discovered that one - * of the slaves could be activated earlier, so we do it. - */ - read_lock(&bond->ptrlock); - oldcurrent = bond->current_slave; - read_unlock(&bond->ptrlock); + if (do_failover) { + write_lock(&bond->ptrlock); - /* no active interface at the moment or need to bring up the primary */ - if (oldcurrent == NULL) { /* no active interface at the moment */ - if (bestslave != NULL) { /* last chance to find one ? */ - write_lock(&bond->ptrlock); - change_active_interface(bond, bestslave); - write_unlock(&bond->ptrlock); - } else if (slave_died) { - /* print this message only once a slave has just died */ + reselect_active_interface(bond); + if (oldcurrent && !bond->current_slave) { printk(KERN_INFO "%s: now running without any active interface !\n", master->name); } + + write_unlock(&bond->ptrlock); } read_unlock(&bond->lock); @@ -2472,9 +2432,10 @@ static void bond_mii_monitor(struct net_ static void loadbalance_arp_monitor(struct net_device *master) { bonding_t *bond; - slave_t *slave; + slave_t *slave, *oldcurrent; int the_delta_in_ticks = arp_interval * HZ / 1000; int next_timer = jiffies + (arp_interval * HZ / 1000); + int do_failover = 0; bond = (struct bonding *) master->priv; if (master->priv == NULL) { @@ -2498,6 +2459,10 @@ static void loadbalance_arp_monitor(stru read_lock(&bond->lock); + read_lock(&bond->ptrlock); + oldcurrent = bond->current_slave; + read_unlock(&bond->ptrlock); + /* see if any of the previous devices are up now (i.e. they have * xmt and rcv traffic). the current_slave does not come into * the picture unless it is null. also, slave->jiffies is not needed @@ -2524,21 +2489,19 @@ static void loadbalance_arp_monitor(stru * current_slave being null after enslaving * is closed. */ - write_lock(&bond->ptrlock); - if (bond->current_slave == NULL) { + if (oldcurrent == NULL) { printk(KERN_INFO "%s: link status definitely up " "for interface %s, ", master->name, slave->dev->name); - reselect_active_interface(bond); + do_failover = 1; } else { printk(KERN_INFO "%s: interface %s is now up\n", master->name, slave->dev->name); } - write_unlock(&bond->ptrlock); } } else { /* slave->link == BOND_LINK_UP */ @@ -2561,11 +2524,9 @@ static void loadbalance_arp_monitor(stru master->name, slave->dev->name); - write_lock(&bond->ptrlock); - if (slave == bond->current_slave) { - reselect_active_interface(bond); + if (slave == oldcurrent) { + do_failover = 1; } - write_unlock(&bond->ptrlock); } } @@ -2579,6 +2540,19 @@ static void loadbalance_arp_monitor(stru if (IS_UP(slave->dev)) { arp_send_all(slave); } + } + + if (do_failover) { + write_lock(&bond->ptrlock); + + reselect_active_interface(bond); + if (oldcurrent && !bond->current_slave) { + printk(KERN_INFO + "%s: now running without any active interface !\n", + master->name); + } + + write_unlock(&bond->ptrlock); } read_unlock(&bond->lock); -- | Shmulik Hen Advanced Network Services | | Israel Design Center, Jerusalem | | LAN Access Division, Platform Networking | | Intel Communications Group, Intel corp. | From garzik@gtf.org Fri Aug 8 10:39:42 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Aug 2003 10:39:55 -0700 (PDT) Received: from havoc.gtf.org (host-64-213-145-173.atlantasolutions.com [64.213.145.173] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h78HdfFl026326 for ; Fri, 8 Aug 2003 10:39:42 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id 12F87667E; Fri, 8 Aug 2003 13:39:33 -0400 (EDT) Date: Fri, 8 Aug 2003 13:39:33 -0400 From: Jeff Garzik To: netdev@oss.sgi.com Subject: RFR: new SiS gige driver Message-ID: <20030808173932.GA4077@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: 4678 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 Every so often, new vendor drivers are submitted to me for inclusion in the Linux kernel. In an attempt to obtain greater pre-merge peer review, I'm going to start posting some of them here on netdev. This driver is actually a lot more clean than many that crop up. So far most of my nits are minor: * it needs copyright/license blurb at the top * should not wait for autoneg to complete in ->open, * worst-case delay in smdio_write is very long... try moving most phy interaction to process context, or examining if delays exist only to paper over PCI posting (for example) bugs * should use netif_carrier_xxx (required for bonding and linkwatch, these days) * remove #if 0'd code, commented-out code ("// ..."), and other dead code * since it's gige, it should definitely be using NAPI /* ========================================================================= SiS190.c: A SiS190 Gigabit Ethernet driver for Linux kernel 2.6.x. -------------------------------------------------------------------- History: Aug 7 2003 - created initially by K.M. Liu . ========================================================================= VERSION 1.0 <2003/8/7> Initial by K.M. Liu, test 100bps Full in 2.6.0 O.K. 1.1 <2003/8/8> Add mode detection. The bit4:0 of MII register 4 is called "selector field", and have to be 00001b to indicate support of IEEE std 802.3 during NWay process of exchanging Link Code Word (FLP). */ #include #include #include #include #include #include #include #include #define SiS190_VERSION "1.1" #define MODULENAME "SiS190" #define SiS190_DRIVER_NAME MODULENAME " Gigabit Ethernet driver " SiS190_VERSION #define PFX MODULENAME ": " #ifdef SiS190_DEBUG #define assert(expr) \ if(!(expr)) { \ printk( "Assertion failed! %s,%s,%s,line=%d\n", \ #expr,__FILE__,__FUNCTION__,__LINE__); \ } #else #define assert(expr) do {} while (0) #endif /* media options */ #define MAX_UNITS 8 /* Maximum events (Rx packets, etc.) to handle at each interrupt. */ static int max_interrupt_work = 20; /* Maximum number of multicast addresses to filter (vs. Rx-all-multicast). The chips use a 64 element hash table based on the Ethernet CRC. */ static int multicast_filter_limit = 32; /* MAC address length*/ #define MAC_ADDR_LEN 6 /* max supported gigabit ethernet frame size -- must be at least (dev->mtu+14+4).*/ #define MAX_ETH_FRAME_SIZE 1536 #define TX_FIFO_THRESH 256 /* In bytes */ #define RX_FIFO_THRESH 7 /* 7 means NO threshold, Rx buffer level before first PCI xfer. */ #define RX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */ #define TX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */ #define EarlyTxThld 0x3F /* 0x3F means NO early transmit */ #define RxPacketMaxSize 0x0800 /* Maximum size supported is 16K-1 */ #define InterFrameGap 0x03 /* 3 means InterFrameGap = the shortest one */ #define NUM_TX_DESC 64 /* Number of Tx descriptor registers */ #define NUM_RX_DESC 64 /* Number of Rx descriptor registers */ #define RX_BUF_SIZE 1536 /* Rx Buffer size */ #define SiS190_MIN_IO_SIZE 0x80 #define TX_TIMEOUT (6*HZ) /* enhanced PHY access register bit definitions */ #define EhnMIIread 0x0000 #define EhnMIIwrite 0x0020 #define EhnMIIdataShift 16 #define EhnMIIpmdShift 6 /* 7016 only */ #define EhnMIIregShift 11 #define EhnMIIreq 0x0010 #define EhnMIInotDone 0x0010 //------------------------------------------------------------------------- // Bit Mask definitions //------------------------------------------------------------------------- #define BIT_0 0x0001 #define BIT_1 0x0002 #define BIT_2 0x0004 #define BIT_3 0x0008 #define BIT_4 0x0010 #define BIT_5 0x0020 #define BIT_6 0x0040 #define BIT_7 0x0080 #define BIT_8 0x0100 #define BIT_9 0x0200 #define BIT_10 0x0400 #define BIT_11 0x0800 #define BIT_12 0x1000 #define BIT_13 0x2000 #define BIT_14 0x4000 #define BIT_15 0x8000 #define BIT_16 0x10000 #define BIT_17 0x20000 #define BIT_18 0x40000 #define BIT_19 0x80000 #define BIT_20 0x100000 #define BIT_21 0x200000 #define BIT_22 0x400000 #define BIT_23 0x800000 #define BIT_24 0x1000000 #define BIT_25 0x2000000 #define BIT_26 0x04000000 #define BIT_27 0x08000000 #define BIT_28 0x10000000 #define BIT_29 0x20000000 #define BIT_30 0x40000000 #define BIT_31 0x80000000 /* write/read MMIO register */ #define SiS_W8(reg, val8) writeb ((val8), ioaddr + (reg)) #define SiS_W16(reg, val16) writew ((val16), ioaddr + (reg)) #define SiS_W32(reg, val32) writel ((val32), ioaddr + (reg)) #define SiS_R8(reg) readb (ioaddr + (reg)) #define SiS_R16(reg) readw (ioaddr + (reg)) #define SiS_R32(reg) ((unsigned long) readl (ioaddr + (reg))) static struct { const char *name; } board_info[] __devinitdata = { { "SiS190 Gigabit Ethernet"},}; static struct pci_device_id sis190_pci_tbl[] __devinitdata = { {0x1039, 0x0190, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, {0,}, }; MODULE_DEVICE_TABLE(pci, sis190_pci_tbl); enum SiS190_registers { TxControl=0x0, TxDescStartAddr =0x4, TxNextDescAddr =0x0c, RxControl=0x10, RxDescStartAddr =0x14, RxNextDescAddr =0x1c, IntrStatus = 0x20, IntrMask = 0x24, IntrControl = 0x28, IntrTimer = 0x2c, PMControl = 0x30, ROMControl=0x38, ROMInterface=0x3c, StationControl=0x40, GMIIControl=0x44, TxMacControl=0x50, RxMacControl=0x60, RxMacAddr=0x62, RxHashTable=0x68, RxWakeOnLan=0x70, RxMPSControl=0x78, }; enum sis190_register_content { /*InterruptStatusBits */ SoftInt=0x40000000, Timeup=0x20000000, PauseFrame = 0x80000, MagicPacket=0x40000, WakeupFrame = 0x20000, LinkChange = 0x10000, RxQEmpty = 0x80, RxQInt = 0x40, TxQ1Empty = 0x20, TxQ1Int = 0x10, TxQ0Empty = 0x08, TxQ0Int = 0x04, RxHalt = 0x02, TxHalt=0x01, /*RxStatusDesc */ RxRES = 0x00200000, RxCRC = 0x00080000, RxRUNT = 0x00100000, RxRWT = 0x00400000, /*ChipCmdBits */ CmdReset = 0x10, CmdRxEnb = 0x08, CmdTxEnb = 0x01, RxBufEmpty = 0x01, /*Cfg9346Bits */ Cfg9346_Lock = 0x00, Cfg9346_Unlock = 0xC0, /*rx_mode_bits */ AcceptErr = 0x20, AcceptRunt = 0x10, AcceptBroadcast = 0x0800, AcceptMulticast = 0x0400, AcceptMyPhys = 0x0200, AcceptAllPhys = 0x0100, /*RxConfigBits */ RxCfgFIFOShift = 13, RxCfgDMAShift = 8, /*TxConfigBits */ TxInterFrameGapShift = 24, TxDMAShift = 8, /* DMA burst value (0-7) is shift this many bits */ /*_PHYstatus */ TBI_Enable = 0x80, TxFlowCtrl = 0x40, RxFlowCtrl = 0x20, _1000bpsF = 0x1c, _1000bpsH = 0x0c, _100bpsF = 0x18, _100bpsH = 0x08, _10bpsF = 0x14, _10bpsH = 0x04, LinkStatus = 0x02, FullDup = 0x01, /*GIGABIT_PHY_registers */ PHY_CTRL_REG = 0, PHY_STAT_REG = 1, PHY_AUTO_NEGO_REG = 4, PHY_1000_CTRL_REG = 9, /*GIGABIT_PHY_REG_BIT */ PHY_Restart_Auto_Nego = 0x0200, PHY_Enable_Auto_Nego = 0x1000, //PHY_STAT_REG = 1; PHY_Auto_Neco_Comp = 0x0020, //PHY_AUTO_NEGO_REG = 4; PHY_Cap_10_Half = 0x0020, PHY_Cap_10_Full = 0x0040, PHY_Cap_100_Half = 0x0080, PHY_Cap_100_Full = 0x0100, //PHY_1000_CTRL_REG = 9; PHY_Cap_1000_Full = 0x0200, PHY_Cap_Null = 0x0, /*_MediaType*/ _10_Half = 0x01, _10_Full = 0x02, _100_Half = 0x04, _100_Full = 0x08, _1000_Full = 0x10, /*_TBICSRBit*/ TBILinkOK = 0x02000000, }; const static struct { const char *name; u8 version; /* depend on docs */ u32 RxConfigMask; /* should clear the bits supported by this chip */ } sis_chip_info[] = { { "SiS-0190", 0x00, 0xff7e1880,},}; enum _DescStatusBit { OWNbit = 0x80000000, INTbit = 0x40000000, DEFbit = 0x200000, CRCbit = 0x20000, PADbit=0x10000, ENDbit=0x80000000, }; struct TxDesc { u32 PSize; u32 status; u32 buf_addr; u32 buf_Len; }; struct RxDesc { u32 PSize; u32 status; u32 buf_addr; u32 buf_Len; }; struct sis190_private { void *mmio_addr; /* memory map physical address */ struct pci_dev *pci_dev; /* Index of PCI device */ struct net_device_stats stats; /* statistics of net device */ spinlock_t lock; /* spin lock flag */ int chipset; unsigned long cur_rx; /* Index into the Rx descriptor buffer of next Rx pkt. */ unsigned long cur_tx; /* Index into the Tx descriptor buffer of next Rx pkt. */ unsigned long dirty_tx; unsigned char *TxDescArrays; /* Index of Tx Descriptor buffer */ unsigned char *RxDescArrays; /* Index of Rx Descriptor buffer */ struct TxDesc *TxDescArray; /* Index of 256-alignment Tx Descriptor buffer */ struct RxDesc *RxDescArray; /* Index of 256-alignment Rx Descriptor buffer */ unsigned char *RxBufferRings; /* Index of Rx Buffer */ unsigned char *RxBufferRing[NUM_RX_DESC]; /* Index of Rx Buffer array */ struct sk_buff *Tx_skbuff[NUM_TX_DESC]; /* Index of Transmit data buffer */ }; MODULE_AUTHOR("K.M. Liu999) printk(KERN_ERR PFX "Phy write Error!!!\n"); } int smdio_read(void *ioaddr, int RegAddr) { u32 l; u16 i; u32 pmd; pmd=1; l=0; l = EhnMIIread |EhnMIIreq | (((u32)RegAddr)<999) printk(KERN_ERR PFX "Phy Read Error!!!\n"); } l=SiS_R32(GMIIControl); return( (u16) ( l>>EhnMIIdataShift ) ); } int ReadEEprom(void *ioaddr, u32 RegAddr) { u16 data; u32 i; u32 ulValue; if(!(SiS_R32(ROMControl)&BIT_1)) { return 0; } ulValue = (BIT_7 | (0x2 << 8) | (RegAddr << 10)); SiS_W32(ROMInterface, ulValue); for(i=0 ; i < 200; i++) { if(!(SiS_R32(ROMInterface)& BIT_7)) break; udelay(1000); } data = (u16)((SiS_R32(ROMInterface) & 0xffff0000) >> 16); return data; } static int __devinit SiS190_init_board(struct pci_dev *pdev, struct net_device **dev_out, void **ioaddr_out) { void *ioaddr = NULL; struct net_device *dev; struct sis190_private *tp; u16 rc; unsigned long mmio_start, mmio_end, mmio_flags, mmio_len; // u32 tmp; assert(pdev != NULL); assert(ioaddr_out != NULL); *ioaddr_out = NULL; *dev_out = NULL; // dev zeroed in init_etherdev // printk("SiS190_init_board\n"); dev = alloc_etherdev(sizeof (*tp)); // dev = init_etherdev(NULL, sizeof (*tp)); if (dev == NULL) { printk(KERN_ERR PFX "unable to alloc new ethernet\n"); return -ENOMEM; } SET_MODULE_OWNER(dev); SET_NETDEV_DEV(dev, &pdev->dev); tp = dev->priv; // SET_MODULE_OWNER(dev); // tp = dev->priv; // enable device (incl. PCI PM wakeup and hotplug setup) rc = pci_enable_device(pdev); if (rc) goto err_out; mmio_start = pci_resource_start(pdev, 0); mmio_end = pci_resource_end(pdev, 0); mmio_flags = pci_resource_flags(pdev, 0); mmio_len = pci_resource_len(pdev, 0); // make sure PCI base addr 0 is MMIO if (!(mmio_flags & IORESOURCE_MEM)) { printk(KERN_ERR PFX "region #0 not an MMIO resource, aborting\n"); rc = -ENODEV; goto err_out; } // check for weird/broken PCI region reporting if (mmio_len < SiS190_MIN_IO_SIZE) { printk(KERN_ERR PFX "Invalid PCI region size(s), aborting\n"); rc = -ENODEV; goto err_out; } rc = pci_request_regions(pdev, dev->name); if (rc) goto err_out; // enable PCI bus-mastering pci_set_master(pdev); // ioremap MMIO region ioaddr = ioremap(mmio_start, mmio_len); if (ioaddr == NULL) { printk(KERN_ERR PFX "cannot remap MMIO, aborting\n"); rc = -EIO; goto err_out_free_res; } // Soft reset the chip. //_W8(ChipCmd, CmdReset); SiS_W32(IntrControl,0x8000); udelay(1000); SiS_W32(IntrControl,0x0); SiS_W32(TxControl,0x1a00); SiS_W32(RxControl,0x1a00); udelay(1000); //match: *ioaddr_out = ioaddr; *dev_out = dev; return 0; err_out_free_res: pci_release_regions(pdev); err_out: // err_out_disable: pci_disable_device(pdev); unregister_netdev(dev); kfree(dev); return rc; } static int __devinit SiS190_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) { struct net_device *dev = NULL; struct sis190_private *tp = NULL; void *ioaddr = NULL; static int board_idx = -1; static int printed_version = 0; int i,rc; u16 reg31; // int option = -1, Cap10_100 = 0, Cap1000 = 0; assert(pdev != NULL); assert(ent != NULL); board_idx++; // printk("SiS190_init_one! \n"); if (!printed_version) { printk(KERN_INFO SiS190_DRIVER_NAME " loaded\n"); printed_version = 1; } i = SiS190_init_board(pdev, &dev, &ioaddr); if (i < 0) { return i; } tp = dev->priv; assert(ioaddr != NULL); assert(dev != NULL); assert(tp != NULL); // Get MAC address // // Read node address from the EEPROM if(SiS_R32(ROMControl)&0x2){ for (i=0; i< 6; i += 2){ SiS_W16(RxMacAddr+i,ReadEEprom(ioaddr, 3 + (i/2))); } }else{ SiS_W32(RxMacAddr,0x11111100); //If 9346 does not exist SiS_W32(RxMacAddr+2,0x00111111); } for (i = 0; i < MAC_ADDR_LEN; i++) { dev->dev_addr[i] = SiS_R8(RxMacAddr+i); printk("SiS_R8(RxMacAddr+%x)= %x ",i,SiS_R8(RxMacAddr+i)); } dev->open = SiS190_open; dev->hard_start_xmit = SiS190_start_xmit; dev->get_stats = SiS190_get_stats; dev->stop = SiS190_close; dev->tx_timeout = SiS190_tx_timeout; dev->set_multicast_list = SiS190_set_rx_mode; dev->watchdog_timeo = TX_TIMEOUT; dev->irq = pdev->irq; dev->base_addr = (unsigned long) ioaddr; // dev->do_ioctl = mii_ioctl; tp = dev->priv; // private data // tp->pci_dev = pdev; tp->mmio_addr = ioaddr; printk(KERN_DEBUG "%s: Identified chip type is '%s'.\n", dev->name, sis_chip_info[tp->chipset].name); spin_lock_init(&tp->lock); rc = register_netdev(dev); if (rc) { iounmap(ioaddr); pci_release_regions(pdev); pci_disable_device(pdev); kfree(dev); return rc; } printk(KERN_DEBUG "%s: Identified chip type is '%s'.\n", dev->name, sis_chip_info[tp->chipset].name); pci_set_drvdata(pdev, dev); printk(KERN_INFO "%s: %s at 0x%lx, " "%2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x, " "IRQ %d\n", dev->name, board_info[ent->driver_data].name, dev->base_addr, dev->dev_addr[0], dev->dev_addr[1], dev->dev_addr[2], dev->dev_addr[3], dev->dev_addr[4], dev->dev_addr[5], dev->irq); int val = smdio_read(ioaddr, PHY_AUTO_NEGO_REG); printk(KERN_INFO "%s: Auto-negotiation Enabled.\n", dev->name); // enable 10/100 Full/Half Mode, leave PHY_AUTO_NEGO_REG bit4:0 unchanged smdio_write(ioaddr, PHY_AUTO_NEGO_REG, PHY_Cap_10_Half | PHY_Cap_10_Full | PHY_Cap_100_Half | PHY_Cap_100_Full | (val & 0x1F)); // enable 1000 Full Mode smdio_write(ioaddr, PHY_1000_CTRL_REG, PHY_Cap_1000_Full); // Enable auto-negotiation and restart auto-nigotiation smdio_write(ioaddr, PHY_CTRL_REG, PHY_Enable_Auto_Nego | PHY_Restart_Auto_Nego); udelay(100); // wait for auto-negotiation process for (i = 10000; i > 0; i--) { //check if auto-negotiation complete if (smdio_read(ioaddr, PHY_STAT_REG) & PHY_Auto_Neco_Comp) { udelay(100); reg31=smdio_read(ioaddr,31); reg31 &= 0x1c; //bit 4:2 switch(reg31){ case _1000bpsF: SiS_W16( 0x40, 0x1c01); printk("SiS190 Link on 1000 bps Full Duplex mode. \n"); break; case _1000bpsH: SiS_W16( 0x40, 0x0c01); printk("SiS190 Link on 1000 bps Half Duplex mode. \n"); break; case _100bpsF: SiS_W16( 0x40, 0x1801); printk("SiS190 Link on 100 bps Full Duplex mode. \n"); break; case _100bpsH: SiS_W16( 0x40, 0x0801); printk("SiS190 Link on 100 bps Half Duplex mode. \n"); break; case _10bpsF: SiS_W16( 0x40, 0x1401); printk("SiS190 Link on 10 bps Full Duplex mode. \n"); break; case _10bpsH: SiS_W16( 0x40, 0x0401); printk("SiS190 Link on 10 bps Half Duplex mode. \n"); break; default: printk(KERN_ERR PFX "Error! SiS190 Can not detect mode !!! \n"); break; } break; } else { udelay(100); } } // end for-loop to wait for auto-negotiation process return 0; } static void __devexit SiS190_remove_one(struct pci_dev *pdev) { struct net_device *dev = pci_get_drvdata(pdev); struct sis190_private *tp = (struct sis190_private *) (dev->priv); assert(dev != NULL); assert(tp != NULL); unregister_netdev(dev); iounmap(tp->mmio_addr); pci_release_regions(pdev); // poison memory before freeing memset(dev, 0xBC, sizeof (struct net_device) + sizeof (struct sis190_private)); kfree(dev); pci_set_drvdata(pdev, NULL); } static int SiS190_open(struct net_device *dev) { struct sis190_private *tp = dev->priv; int retval; u8 diff; u32 TxPhyAddr, RxPhyAddr; retval = request_irq(dev->irq, SiS190_interrupt, SA_SHIRQ, dev->name, dev); if (retval) { return retval; } tp->TxDescArrays = kmalloc(NUM_TX_DESC * sizeof (struct TxDesc) + 256, GFP_KERNEL); // Tx Desscriptor needs 256 bytes alignment; TxPhyAddr = virt_to_bus(tp->TxDescArrays); diff = 256 - (TxPhyAddr - ((TxPhyAddr >> 8) << 8)); TxPhyAddr += diff; tp->TxDescArray = (struct TxDesc *) (tp->TxDescArrays + diff); tp->RxDescArrays = kmalloc(NUM_RX_DESC * sizeof (struct RxDesc) + 256, GFP_KERNEL); // Rx Desscriptor needs 256 bytes alignment; RxPhyAddr = virt_to_bus(tp->RxDescArrays); diff = 256 - (RxPhyAddr - ((RxPhyAddr >> 8) << 8)); RxPhyAddr += diff; tp->RxDescArray = (struct RxDesc *) (tp->RxDescArrays + diff); if (tp->TxDescArrays == NULL || tp->RxDescArrays == NULL) { printk(KERN_INFO "Allocate RxDescArray or TxDescArray failed\n"); free_irq(dev->irq, dev); if (tp->TxDescArrays) kfree(tp->TxDescArrays); if (tp->RxDescArrays) kfree(tp->RxDescArrays); return -ENOMEM; } tp->RxBufferRings = kmalloc(RX_BUF_SIZE * NUM_RX_DESC, GFP_KERNEL); if (tp->RxBufferRings == NULL) { printk(KERN_INFO "Allocate RxBufferRing failed\n"); } SiS190_init_ring(dev); SiS190_hw_start(dev); return 0; } static void SiS190_hw_start(struct net_device *dev) { struct sis190_private *tp = dev->priv; void *ioaddr = tp->mmio_addr; /* Soft reset the chip. */ //_W8(ChipCmd, CmdReset); SiS_W32(IntrControl,0x8000); udelay(1000); SiS_W32(IntrControl,0x0); SiS_W32( 0x0, 0x01a00); SiS_W32( 0x4, virt_to_bus(tp->TxDescArray)); SiS_W32( 0x10, 0x1a00); SiS_W32( 0x14, virt_to_bus(tp->RxDescArray)); SiS_W32( 0x20, 0xffffffff); SiS_W32( 0x24, 0x0); SiS_W16( 0x40, 0x1901); //default is 100Mbps SiS_W32( 0x44, 0x0); SiS_W32( 0x50, 0x60); SiS_W16( 0x60, 0x02); SiS_W32( 0x68, 0x0); SiS_W32( 0x6c, 0x0); SiS_W32( 0x70, 0x0); SiS_W32( 0x74, 0x0); // Set Rx Config register tp->cur_rx = 0; udelay(10); SiS190_set_rx_mode(dev); /* Enable all known interrupts by setting the interrupt mask. */ SiS_W32(IntrMask, sis190_intr_mask); SiS_W32( 0x0, 0x1a01); SiS_W32( 0x10, 0x1a1d); netif_start_queue(dev); } static void SiS190_init_ring(struct net_device *dev) { struct sis190_private *tp = dev->priv; int i; tp->cur_rx = 0; tp->cur_tx = 0; tp->dirty_tx = 0; memset(tp->TxDescArray, 0x0, NUM_TX_DESC * sizeof (struct TxDesc)); memset(tp->RxDescArray, 0x0, NUM_RX_DESC * sizeof (struct RxDesc)); for (i = 0; i < NUM_TX_DESC; i++) { tp->Tx_skbuff[i] = NULL; } for (i = 0; i < NUM_RX_DESC; i++) { tp->RxDescArray[i].PSize = 0x0; if (i == (NUM_RX_DESC - 1)) tp->RxDescArray[i].buf_Len = BIT_31 + RX_BUF_SIZE; //bit 31 is End bit else tp->RxDescArray[i].buf_Len = RX_BUF_SIZE; tp->RxBufferRing[i] = &(tp->RxBufferRings[i * RX_BUF_SIZE]); tp->RxDescArray[i].buf_addr = virt_to_bus(tp->RxBufferRing[i]); tp->RxDescArray[i].status = OWNbit | INTbit; } } static void SiS190_tx_clear(struct sis190_private *tp) { int i; tp->cur_tx = 0; for (i = 0; i < NUM_TX_DESC; i++) { if (tp->Tx_skbuff[i] != NULL) { dev_kfree_skb(tp->Tx_skbuff[i]); tp->Tx_skbuff[i] = NULL; tp->stats.tx_dropped++; } } } static void SiS190_tx_timeout(struct net_device *dev) { struct sis190_private *tp = dev->priv; void *ioaddr = tp->mmio_addr; u8 tmp8; /* disable Tx, if not already */ tmp8 = SiS_R8(TxControl); if (tmp8 & CmdTxEnb) SiS_W8(TxControl, tmp8 & ~CmdTxEnb); /* Disable interrupts by clearing the interrupt mask. */ SiS_W32(IntrMask, 0x0000); /* Stop a shared interrupt from scavenging while we are. */ spin_lock_irq(&tp->lock); SiS190_tx_clear(tp); spin_unlock_irq(&tp->lock); /* ...and finally, reset everything */ SiS190_hw_start(dev); netif_wake_queue(dev); } static int SiS190_start_xmit(struct sk_buff *skb, struct net_device *dev) { struct sis190_private *tp = dev->priv; void *ioaddr = tp->mmio_addr; int entry = tp->cur_tx % NUM_TX_DESC; if (skb->len < ETH_ZLEN) { skb = skb_padto(skb, ETH_ZLEN); if (skb == NULL) return 0; } spin_lock_irq(&tp->lock); if ((tp->TxDescArray[entry].status & OWNbit) == 0) { tp->Tx_skbuff[entry] = skb; tp->TxDescArray[entry].buf_addr = virt_to_bus(skb->data); tp->TxDescArray[entry].PSize = ((skb->len > ETH_ZLEN) ? skb->len : ETH_ZLEN); if (entry != (NUM_TX_DESC - 1)){ tp->TxDescArray[entry].buf_Len = tp->TxDescArray[entry].PSize; }else{ tp->TxDescArray[entry].buf_Len = tp->TxDescArray[entry].PSize|ENDbit; } tp->TxDescArray[entry].status |= (OWNbit | INTbit | DEFbit |CRCbit |PADbit); //_W8(TxPoll, 0x40); //set polling bit SiS_W32(TxControl,0x1a11); //Start Send dev->trans_start = jiffies; tp->cur_tx++; } spin_unlock_irq(&tp->lock); if ((tp->cur_tx - NUM_TX_DESC) == tp->dirty_tx) { netif_stop_queue(dev); } return 0; } static void SiS190_tx_interrupt(struct net_device *dev, struct sis190_private *tp, void *ioaddr) { unsigned long dirty_tx, tx_left = 0; int entry = tp->cur_tx % NUM_TX_DESC; assert(dev != NULL); assert(tp != NULL); assert(ioaddr != NULL); dirty_tx = tp->dirty_tx; tx_left = tp->cur_tx - dirty_tx; while (tx_left > 0) { if ((tp->TxDescArray[entry].status & OWNbit) == 0) { dev_kfree_skb_irq(tp-> Tx_skbuff[dirty_tx % NUM_TX_DESC]); tp->Tx_skbuff[dirty_tx % NUM_TX_DESC] = NULL; tp->stats.tx_packets++; dirty_tx++; tx_left--; entry++; } } if (tp->dirty_tx != dirty_tx) { tp->dirty_tx = dirty_tx; if (netif_queue_stopped(dev)) netif_wake_queue(dev); } } static void SiS190_rx_interrupt(struct net_device *dev, struct sis190_private *tp, void *ioaddr) { int cur_rx; struct sk_buff *skb; int pkt_size = 0; assert(dev != NULL); assert(tp != NULL); assert(ioaddr != NULL); cur_rx = tp->cur_rx; while ((tp->RxDescArray[cur_rx].status & OWNbit) == 0) { if (tp->RxDescArray[cur_rx].PSize & 0x0080000) { printk(KERN_INFO "%s: Rx ERROR!!!\n", dev->name); tp->stats.rx_errors++; tp->stats.rx_length_errors++; }else if(!(tp->RxDescArray[cur_rx].PSize & 0x0010000)){ printk(KERN_INFO "%s: Rx ERROR!!!\n", dev->name); tp->stats.rx_errors++; tp->stats.rx_crc_errors++; } else { pkt_size = (int) (tp->RxDescArray[cur_rx]. PSize & 0x0000FFFF) - 4; skb = dev_alloc_skb(pkt_size + 2); if (skb != NULL) { skb->dev = dev; skb_reserve(skb, 2); // 16 byte align the IP fields. // eth_copy_and_sum(skb, tp->RxBufferRing[cur_rx], pkt_size, 0); skb_put(skb, pkt_size); skb->protocol = eth_type_trans(skb, dev); netif_rx(skb); tp->RxDescArray[cur_rx].PSize =0x0; if (cur_rx == (NUM_RX_DESC - 1)) tp->RxDescArray[cur_rx].buf_Len = ENDbit+RX_BUF_SIZE; else tp->RxDescArray[cur_rx].buf_Len = RX_BUF_SIZE; tp->RxDescArray[cur_rx].buf_addr = virt_to_bus(tp->RxBufferRing[cur_rx]); dev->last_rx = jiffies; tp->stats.rx_bytes += pkt_size; tp->stats.rx_packets++; tp->RxDescArray[cur_rx].status = OWNbit|INTbit; } else { printk(KERN_WARNING "%s: Memory squeeze, deferring packet.\n", dev->name); /* We should check that some rx space is free. If not, free one and mark stats->rx_dropped++. */ tp->stats.rx_dropped++; } } cur_rx = (cur_rx + 1) % NUM_RX_DESC; } tp->cur_rx = cur_rx; } /* The interrupt handler does all of the Rx thread work and cleans up after the Tx thread. */ static irqreturn_t SiS190_interrupt(int irq, void *dev_instance, struct pt_regs *regs) { struct net_device *dev = (struct net_device *) dev_instance; struct sis190_private *tp = dev->priv; int boguscnt = max_interrupt_work; void *ioaddr = tp->mmio_addr; unsigned long status = 0; int handled = 0; do { status = SiS_R32(IntrStatus); /* h/w no longer present (hotplug?) or major error, bail */ SiS_W32(IntrStatus,status); if ((status & (TxQ0Int | RxQInt)) == 0) break; // Rx interrupt if (status & (RxQInt)) { SiS190_rx_interrupt(dev, tp, ioaddr); } // Tx interrupt if (status & (TxQ0Int)) { spin_lock(&tp->lock); SiS190_tx_interrupt(dev, tp, ioaddr); spin_unlock(&tp->lock); } boguscnt--; } while (boguscnt > 0); if (boguscnt <= 0) { printk(KERN_WARNING "%s: Too much work at interrupt!\n", dev->name); /* Clear all interrupt sources. */ SiS_W32(IntrStatus, 0xffffffff); } return IRQ_RETVAL(handled); } static int SiS190_close(struct net_device *dev) { struct sis190_private *tp = dev->priv; void *ioaddr = tp->mmio_addr; int i; netif_stop_queue(dev); spin_lock_irq(&tp->lock); /* Stop the chip's Tx and Rx DMA processes. */ SiS_W32(TxControl,0x1a00); SiS_W32(RxControl,0x1a00); /* Disable interrupts by clearing the interrupt mask. */ SiS_W32(IntrMask, 0x0000); /* Update the error counts. */ //tp->stats.rx_missed_errors += _R32(RxMissed); //_W32(RxMissed, 0); spin_unlock_irq(&tp->lock); synchronize_irq(); free_irq(dev->irq, dev); SiS190_tx_clear(tp); kfree(tp->TxDescArrays); kfree(tp->RxDescArrays); tp->TxDescArrays = NULL; tp->RxDescArrays = NULL; tp->TxDescArray = NULL; tp->RxDescArray = NULL; kfree(tp->RxBufferRings); for (i = 0; i < NUM_RX_DESC; i++) { tp->RxBufferRing[i] = NULL; } return 0; } static void SiS190_set_rx_mode(struct net_device *dev) { struct sis190_private *tp = dev->priv; void *ioaddr = tp->mmio_addr; unsigned long flags; u32 mc_filter[2]; /* Multicast hash filter */ int i, rx_mode; u32 tmp = 0; if (dev->flags & IFF_PROMISC) { /* Unconditionally log net taps. */ printk(KERN_NOTICE "%s: Promiscuous mode enabled.\n", dev->name); rx_mode = AcceptBroadcast | AcceptMulticast | AcceptMyPhys | AcceptAllPhys; mc_filter[1] = mc_filter[0] = 0xffffffff; } else if ((dev->mc_count > multicast_filter_limit) || (dev->flags & IFF_ALLMULTI)) { /* Too many to filter perfectly -- accept all multicasts. */ rx_mode = AcceptBroadcast | AcceptMulticast | AcceptMyPhys; mc_filter[1] = mc_filter[0] = 0xffffffff; } else { struct dev_mc_list *mclist; rx_mode = AcceptBroadcast | AcceptMyPhys; mc_filter[1] = mc_filter[0] = 0; for (i = 0, mclist = dev->mc_list; mclist && i < dev->mc_count; i++, mclist = mclist->next) { int bit_nr = ether_crc(ETH_ALEN, mclist->dmi_addr) >> 26; mc_filter[bit_nr >> 5] |= 1 << (bit_nr & 31); rx_mode |= AcceptMulticast; } } spin_lock_irqsave(&tp->lock, flags); tmp = rx_mode | 0x2; SiS_W16(RxMacControl, tmp); SiS_W32(RxHashTable , mc_filter[0]); SiS_W32(RxHashTable + 4, mc_filter[1]); spin_unlock_irqrestore(&tp->lock, flags); } struct net_device_stats * SiS190_get_stats(struct net_device *dev) { struct sis190_private *tp = dev->priv; return &tp->stats; } static struct pci_driver sis190_pci_driver = { .name = MODULENAME, .id_table = sis190_pci_tbl, .probe = SiS190_init_one, .remove = SiS190_remove_one, .suspend = NULL, .resume = NULL, }; static int __init SiS190_init_module(void) { return pci_module_init(&sis190_pci_driver); } static void __exit SiS190_cleanup_module(void) { pci_unregister_driver(&sis190_pci_driver); } module_init(SiS190_init_module); module_exit(SiS190_cleanup_module); From shemminger@osdl.org Fri Aug 8 11:34:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Aug 2003 11:34:31 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h78IYMFl030031 for ; Fri, 8 Aug 2003 11:34:23 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h78IYAo00661; Fri, 8 Aug 2003 11:34:10 -0700 Date: Fri, 8 Aug 2003 11:34:04 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] tun driver use private linked list. Message-Id: <20030808113404.0e9e1e6d.shemminger@osdl.org> In-Reply-To: <20030807155901.49f1a424.davem@redhat.com> References: <200308051630.28552.bellucda@tiscali.it> <20030805090647.691daa7e.shemminger@osdl.org> <200308051910.55823.bellucda@tiscali.it> <20030807154524.4794ad45.shemminger@osdl.org> <20030807155901.49f1a424.davem@redhat.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4679 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Less grotty version, applies over earlier patch. - keep a private list. - fix debug format strings. - drop the name entry in the private data structure since it already has a pointer to netdev that has name. diff -Nru a/drivers/net/tun.c b/drivers/net/tun.c --- a/drivers/net/tun.c Fri Aug 8 11:26:07 2003 +++ b/drivers/net/tun.c Fri Aug 8 11:26:07 2003 @@ -51,6 +51,8 @@ /* Network device part of the driver */ +static LIST_HEAD(tun_dev_list); + /* Net device open. */ static int tun_net_open(struct net_device *dev) { @@ -70,7 +72,7 @@ { struct tun_struct *tun = (struct tun_struct *)dev->priv; - DBG(KERN_INFO "%s: tun_net_xmit %d\n", tun->name, skb->len); + DBG(KERN_INFO "%s: tun_net_xmit %d\n", tun->dev->name, skb->len); /* Drop packet if interface is not attached */ if (!tun->attached) @@ -120,7 +122,7 @@ { struct tun_struct *tun = (struct tun_struct *)dev->priv; - DBG(KERN_INFO "%s: tun_net_init\n", tun->name); + DBG(KERN_INFO "%s: tun_net_init\n", tun->dev->name); switch (tun->flags & TUN_TYPE_MASK) { case TUN_TUN_DEV: @@ -161,7 +163,7 @@ if (!tun) return -EBADFD; - DBG(KERN_INFO "%s: tun_chr_poll\n", tun->name); + DBG(KERN_INFO "%s: tun_chr_poll\n", tun->dev->name); poll_wait(file, &tun->read_wait, wait); @@ -226,7 +228,7 @@ if (!tun) return -EBADFD; - DBG(KERN_INFO "%s: tun_chr_write %d\n", tun->name, count); + DBG(KERN_INFO "%s: tun_chr_write %ld\n", tun->dev->name, count); for (i = 0, len = 0; i < count; i++) { if (verify_area(VERIFY_READ, iv[i].iov_base, iv[i].iov_len)) @@ -290,7 +292,7 @@ if (!tun) return -EBADFD; - DBG(KERN_INFO "%s: tun_chr_read\n", tun->name); + DBG(KERN_INFO "%s: tun_chr_read\n", tun->dev->name); for (i = 0, len = 0; i < count; i++) { if (verify_area(VERIFY_WRITE, iv[i].iov_base, iv[i].iov_len)) @@ -350,7 +352,7 @@ tun->owner = -1; dev->init = tun_net_init; - tun->name = dev->name; + SET_MODULE_OWNER(dev); dev->open = tun_net_open; dev->hard_start_xmit = tun_net_xmit; @@ -359,27 +361,40 @@ dev->destructor = (void (*)(struct net_device *))kfree; } +static struct tun_struct *tun_get_by_name(const char *name) +{ + struct tun_struct *tun; + + ASSERT_RTNL(); + list_for_each_entry(tun, &tun_dev_list, list) { + if (!strncmp(tun->dev->name, name, IFNAMSIZ)) + return tun; + } + + return NULL; +} + static int tun_set_iff(struct file *file, struct ifreq *ifr) { struct tun_struct *tun; - struct net_device *dev; int err; - dev = __dev_get_by_name(ifr->ifr_name); - if (dev) { - /* Device exist */ - tun = dev->priv; - - if (dev->init != tun_net_init || tun->attached) + tun = tun_get_by_name(ifr->ifr_name); + if (tun) { + if (tun->attached) return -EBUSY; /* Check permissions */ - if (tun->owner != -1) - if (current->euid != tun->owner && !capable(CAP_NET_ADMIN)) - return -EPERM; - } else { + if (tun->owner != -1 && + current->euid != tun->owner && !capable(CAP_NET_ADMIN)) + return -EPERM; + } + else if (__dev_get_by_name(ifr->ifr_name)) + return -EINVAL; + else { char *name; unsigned long flags = 0; + struct net_device *dev; err = -EINVAL; @@ -420,9 +435,10 @@ goto failed; } + list_add(&tun->list, &tun_dev_list); } - DBG(KERN_INFO "%s: tun_set_iff\n", tun->name); + DBG(KERN_INFO "%s: tun_set_iff\n", tun->dev->name); if (ifr->ifr_flags & IFF_NO_PI) tun->flags |= TUN_NO_PI; @@ -433,7 +449,7 @@ file->private_data = tun; tun->attached = 1; - strcpy(ifr->ifr_name, tun->name); + strcpy(ifr->ifr_name, tun->dev->name); return 0; failed: return err; @@ -466,7 +482,7 @@ if (!tun) return -EBADFD; - DBG(KERN_INFO "%s: tun_chr_ioctl cmd %d\n", tun->name, cmd); + DBG(KERN_INFO "%s: tun_chr_ioctl cmd %d\n", tun->dev->name, cmd); switch (cmd) { case TUNSETNOCSUM: @@ -477,7 +493,7 @@ tun->flags &= ~TUN_NOCHECKSUM; DBG(KERN_INFO "%s: checksum %s\n", - tun->name, arg ? "disabled" : "enabled"); + tun->dev->name, arg ? "disabled" : "enabled"); break; case TUNSETPERSIST: @@ -488,14 +504,14 @@ tun->flags &= ~TUN_PERSIST; DBG(KERN_INFO "%s: persist %s\n", - tun->name, arg ? "disabled" : "enabled"); + tun->dev->name, arg ? "disabled" : "enabled"); break; case TUNSETOWNER: /* Set owner of the device */ tun->owner = (uid_t) arg; - DBG(KERN_INFO "%s: owner set to %d\n", tun->owner); + DBG(KERN_INFO "%s: owner set to %d\n", tun->dev->name, tun->owner); break; #ifdef TUN_DEBUG @@ -519,7 +535,7 @@ if (!tun) return -EBADFD; - DBG(KERN_INFO "%s: tun_chr_fasync %d\n", tun->name, on); + DBG(KERN_INFO "%s: tun_chr_fasync %d\n", tun->dev->name, on); if ((ret = fasync_helper(fd, file, on, &tun->fasync)) < 0) return ret; @@ -549,7 +565,7 @@ if (!tun) return 0; - DBG(KERN_INFO "%s: tun_chr_close\n", tun->name); + DBG(KERN_INFO "%s: tun_chr_close\n", tun->dev->name); tun_chr_fasync(-1, file, 0); @@ -562,8 +578,10 @@ /* Drop read queue */ skb_queue_purge(&tun->readq); - if (!(tun->flags & TUN_PERSIST)) + if (!(tun->flags & TUN_PERSIST)) { + list_del(&tun->list); unregister_netdevice(tun->dev); + } rtnl_unlock(); @@ -605,15 +623,14 @@ void tun_cleanup(void) { - struct net_device *dev, *nxt; + struct tun_struct *tun, *nxt; misc_deregister(&tun_miscdev); rtnl_lock(); - for (dev = dev_base; dev; dev = nxt) { - nxt = dev->next; - if (dev->init == tun_net_init) - unregister_netdevice(dev); + list_for_each_entry_safe(tun, nxt, &tun_dev_list, list) { + DBG(KERN_INFO "%s cleaned up\n", tun->dev->name); + unregister_netdevice(tun->dev); } rtnl_unlock(); diff -Nru a/include/linux/if_tun.h b/include/linux/if_tun.h --- a/include/linux/if_tun.h Fri Aug 8 11:29:09 2003 +++ b/include/linux/if_tun.h Fri Aug 8 11:29:09 2003 @@ -32,7 +32,7 @@ #endif struct tun_struct { - char *name; + struct list_head list; unsigned long flags; int attached; uid_t owner; From shemminger@osdl.org Fri Aug 8 12:02:04 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Aug 2003 12:02:06 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h78J22Fl032216 for ; Fri, 8 Aug 2003 12:02:03 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h78J1uo06384; Fri, 8 Aug 2003 12:01:57 -0700 Date: Fri, 8 Aug 2003 12:01:50 -0700 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: Re: RFR: new SiS gige driver Message-Id: <20030808120150.45f091d8.shemminger@osdl.org> In-Reply-To: <20030808173932.GA4077@gtf.org> References: <20030808173932.GA4077@gtf.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4680 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Comments: - Run through lindent, indenting is non-standard. - struct board_info defined but only used in one debug message and it is just a string. - C99 initializers? - if code is commented out and outdated remove it (see init_board) - poisoning memory is useless and done already by allocator (see SIS190_remove_one) - assert checks for null pointers are overkill - ethtool? Overall, suffers a little from the "having more debug code makes my driver more reliable" fallacy. From shmulik.hen@intel.com Fri Aug 8 13:01:04 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Aug 2003 13:01:09 -0700 (PDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h78K13Fl004794 for ; Fri, 8 Aug 2003 13:01:04 -0700 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h78EhKc05732 for ; Fri, 8 Aug 2003 14:43:20 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h78E8VT07438 for ; Fri, 8 Aug 2003 14:08:31 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.254.188]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003080807573707052 ; Fri, 08 Aug 2003 07:57:38 -0700 Content-Type: text/plain; charset="us-ascii" From: Shmulik Hen Reply-To: shmulik.hen@intel.com Organization: Intel corp. Subject: [SET 2][PATCH 8/8][bonding] Propagating master's settings to slaves Date: Fri, 8 Aug 2003 17:45:23 +0300 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit To: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Message-Id: <200308081745.23436.shmulik.hen@intel.com> X-archive-position: 4681 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev 8 - Enhance netdev notification handling. Add comment block and bump version. diff -Nuarp linux-2.4.22-rc1/drivers/net/bonding/bond_main.c linux-2.4.22-rc1-devel/drivers/net/bonding/bond_main.c --- linux-2.4.22-rc1/drivers/net/bonding/bond_main.c Fri Aug 8 14:03:27 2003 +++ linux-2.4.22-rc1-devel/drivers/net/bonding/bond_main.c Fri Aug 8 14:03:28 2003 @@ -408,6 +408,18 @@ * and free it separately; use standard list operations instead * of pre-allocated array of bonds. * Version to 2.3.0. + * + * 2003/08/07 - Jay Vosburgh , + * Amir Noam and + * Shmulik Hen + * - Propagating master's settings: Distinguish between modes that + * use a primary slave from those that don't, and propagate settings + * accordingly; Consolidate change_active opeartions and add + * reselect_active and find_best opeartions; Decouple promiscuous + * handling from the multicast mode setting; Add support for changing + * HW address and MTU with proper unwind; Consolidate procfs code, + * add CHANGENAME handler; Enhance netdev notification handling. + * Version to 2.4.0. */ #include @@ -452,8 +464,8 @@ #include "bond_3ad.h" #include "bond_alb.h" -#define DRV_VERSION "2.3.0" -#define DRV_RELDATE "August 6, 2003" +#define DRV_VERSION "2.4.0" +#define DRV_RELDATE "August 7, 2003" #define DRV_NAME "bonding" #define DRV_DESCRIPTION "Ethernet Channel Bonding Driver" @@ -572,7 +584,6 @@ static struct net_device_stats *bond_get static void bond_mii_monitor(struct net_device *dev); static void loadbalance_arp_monitor(struct net_device *dev); static void activebackup_arp_monitor(struct net_device *dev); -static int bond_event(struct notifier_block *this, unsigned long event, void *ptr); static void bond_mc_list_destroy(struct bonding *bond); static void bond_mc_add(bonding_t *bond, void *addr, int alen); static void bond_mc_delete(bonding_t *bond, void *addr, int alen); @@ -3468,7 +3479,6 @@ static int bond_read_proc(char *buf, cha } #endif /* CONFIG_PROC_FS */ - static int bond_create_proc_info(struct bonding *bond) { #ifdef CONFIG_PROC_FS @@ -3633,21 +3643,134 @@ unwind: return error; } -static int bond_event(struct notifier_block *this, unsigned long event, - void *ptr) +/* + * Change device name + */ +static inline int bond_event_changename(struct bonding *bond) +{ + int error; + + bond_destroy_proc_info(bond); + error = bond_create_proc_info(bond); + if (error) { + return NOTIFY_BAD; + } + return NOTIFY_DONE; +} + +static int bond_master_netdev_event(unsigned long event, struct net_device *event_dev) +{ + struct bonding *bond, *event_bond = NULL; + + list_for_each_entry(bond, &bond_dev_list, bond_list) { + if (bond == event_dev->priv) { + event_bond = bond; + break; + } + } + + if (event_bond == NULL) { + return NOTIFY_DONE; + } + + switch (event) { + case NETDEV_CHANGENAME: + return bond_event_changename(event_bond); + case NETDEV_UNREGISTER: + /* + * TODO: remove a bond from the list? + */ + break; + default: + break; + } + + return NOTIFY_DONE; +} + +static int bond_slave_netdev_event(unsigned long event, struct net_device *event_dev) { - struct net_device *event_dev = (struct net_device *)ptr; struct net_device *master = event_dev->master; - if ((event == NETDEV_UNREGISTER) && (master != NULL)) { - bond_release(master, event_dev); + switch (event) { + case NETDEV_UNREGISTER: + if (master != NULL) { + bond_release(master, event_dev); + } + break; + case NETDEV_CHANGE: + /* + * TODO: is this what we get if somebody + * sets up a hierarchical bond, then rmmod's + * one of the slave bonding devices? + */ + break; + case NETDEV_DOWN: + /* + * ... Or is it this? + */ + break; + case NETDEV_CHANGEMTU: + /* + * TODO: Should slaves be allowed to + * independently alter their MTU? For + * an active-backup bond, slaves need + * not be the same type of device, so + * MTUs may vary. For other modes, + * slaves arguably should have the + * same MTUs. To do this, we'd need to + * take over the slave's change_mtu + * function for the duration of their + * servitude. + */ + break; + case NETDEV_CHANGENAME: + /* + * TODO: handle changing the primary's name + */ + break; + default: + break; } return NOTIFY_DONE; } +/* + * bond_netdev_event: handle netdev notifier chain events. + * + * This function receives events for the netdev chain. The caller (an + * ioctl handler calling notifier_call_chain) holds the necessary + * locks for us to safely manipulate the slave devices (RTNL lock, + * dev_probe_lock). + */ +static int bond_netdev_event(struct notifier_block *this, unsigned long event, void *ptr) +{ + struct net_device *event_dev = (struct net_device *)ptr; + unsigned short flags; + int res = NOTIFY_DONE; + + dprintk(KERN_INFO "bond_netdev_event n_b %p ev %lx ptr %p\n", + this, event, ptr); + + flags = event_dev->flags & (IFF_MASTER | IFF_SLAVE); + switch (flags) { + case IFF_MASTER: + res = bond_master_netdev_event(event, event_dev); + break; + case IFF_SLAVE: + res = bond_slave_netdev_event(event, event_dev); + break; + default: + /* A master that is also a slave ? */ + break; + } + + return res; +} + static struct notifier_block bond_netdev_notifier = { - notifier_call: bond_event, + notifier_call: bond_netdev_event, }; static void bond_deinit(struct net_device *dev) -- | Shmulik Hen Advanced Network Services | | Israel Design Center, Jerusalem | | LAN Access Division, Platform Networking | | Intel Communications Group, Intel corp. | From hadi@cyberus.ca Fri Aug 8 14:51:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Aug 2003 14:51:58 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h78LpmFl012028 for ; Fri, 8 Aug 2003 14:51:49 -0700 Received: from [216.209.86.2] (helo=[10.0.0.9] ident=jamal) by mail.cyberus.ca with esmtp (Exim 4.12) id 19lF9C-0005f9-00; Fri, 08 Aug 2003 17:51:42 -0400 Subject: Re: [RFC] High Performance Packet Classifiction for tc framework From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: nf@hipac.org, linux-net@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <20030807130502.4af9c815.davem@redhat.com> References: <200307141045.40999.nf@hipac.org> <1058328537.1797.24.camel@jzny.localdomain> <3F16A0E5.1080007@hipac.org> <1059934468.1103.41.camel@jzny.localdomain> <3F2E5CD6.4030500@hipac.org> <1060012260.1103.380.camel@jzny.localdomain> <3F302E04.1090503@hipac.org> <1060286331.1025.73.camel@jzny.localdomain> <20030807130502.4af9c815.davem@redhat.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1060379500.1723.214.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Aug 2003 17:51:40 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4682 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Thu, 2003-08-07 at 16:05, David S. Miller wrote: > On 07 Aug 2003 15:58:51 -0400 > jamal wrote: > If you input all the keys into the Jenkins hash, how does > it perform? Has anyone even tried that and compared it > to all of these fancy multi-level tree like hash things? AFAIK, noone has tried it. I will try out at some point. > I think Jenkins would work very well for exactly this kind > of application. And it's fully available to the entire kernel > via linux/jhash.h and already in use by other things such > as the routing cache and the netfilter conntrack code. A good reason for the multilevel stuff is to support arbitrary packet offsets i.e you dont know which bits in the packet you are interested in ahead of time. Its easy to use hashes when you know that you need to find example ip src/dst. Since its in the kernel I will look into it - but has to meet the arbitrary offset requirement. cheers, jamal From hadi@cyberus.ca Fri Aug 8 15:01:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Aug 2003 15:01:24 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h78M1HFl012776 for ; Fri, 8 Aug 2003 15:01:18 -0700 Received: from [216.209.86.2] (helo=[10.0.0.9] ident=jamal) by mail.cyberus.ca with esmtp (Exim 4.12) id 19lFIT-0006e9-00; Fri, 08 Aug 2003 18:01:17 -0400 Subject: Re: [SET 2][PATCH 2/8][bonding] Propagating master's settings to slaves From: jamal Reply-To: hadi@cyberus.ca To: shmulik.hen@intel.com Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: <200308081744.58946.shmulik.hen@intel.com> References: <200308081744.58946.shmulik.hen@intel.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1060380076.1717.233.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Aug 2003 18:01:16 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4683 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Shmulik, Some of this bonding stuff is pretty scary. Lotsa policies in the kernel and communication seems to be centred around /proc. Shouldnt policies on failover be really driven from user space? Also shouldnt communication be using something like netlink? cheers, jamal On Fri, 2003-08-08 at 10:44, Shmulik Hen wrote: > 2 - Change monitoring function use the new functionality. > From ahtraps@runbox.com Fri Aug 8 16:56:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Aug 2003 16:56:06 -0700 (PDT) Received: from aibo.runbox.com (cujo.runbox.com [193.71.199.138]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h78NtwFl019920 for ; Fri, 8 Aug 2003 16:56:00 -0700 Received: from [10.9.9.15] (helo=odie.runbox.com) by lufsen.runbox.com with esmtp (Exim 4.20) id 19lH5K-0001Hk-QD; Sat, 09 Aug 2003 01:55:50 +0200 Received: from mail by odie.runbox.com with local (Exim 4.20) id 19lH5A-0005yt-J9; Sat, 09 Aug 2003 01:55:40 +0200 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline MIME-Version: 1.0 From: Reply-To: ahtraps@runbox.com To: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: A question on inet_select_addr() Date: Fri, 08 Aug 2003 23:55:40 GMT X-Sender: 243652 X-Mailer: RMM Message-Id: X-Sender: unknown Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h78NtwFl019920 X-archive-position: 4684 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahtraps@runbox.com Precedence: bulk X-list: netdev Hello, I don't quite understand the comment, and the logic following it, in inet_select_addr() function. Specifically: 1. How is it guranteed that a loopback address is not chosen? (there is no check for 127.X.X.X addresses!) 2. Why is it important that the loopback interface be the first in the list. What would go wrong if the search starts from the second device in the list (i.e., skipping the loopback device). 3. And what does this test mean: (ifa->ifa_scope != RT_SCOPE_LINK && ifa->ifa_scope <= scope)? u32 inet_select_addr(const struct net_device *dev, u32 dst, int scope) { ... SNIP ... /* Not loopback addresses on loopback should be preferred in this case. It is importnat that lo is the first interface in dev_base list. */ read_lock(&dev_base_lock); read_lock(&inetdev_lock); for (dev=dev_base; dev; dev=dev->next) { if ((in_dev=__in_dev_get(dev)) == NULL) continue; read_lock(&in_dev->lock); for_primary_ifa(in_dev) { if (ifa->ifa_scope != RT_SCOPE_LINK && ifa->ifa_scope <= scope) { read_unlock(&in_dev->lock); read_unlock(&inetdev_lock); read_unlock(&dev_base_lock); return ifa->ifa_local; } } endfor_ifa(in_dev); read_unlock(&in_dev->lock); } read_unlock(&inetdev_lock); read_unlock(&dev_base_lock); return 0; } tx Andy --------------------------------------------------------------------------------------------------- Runbox Mail Manager (free trial version - this tag is removed upon subscription) Try your own premium email account for free at http://111.runbox.com 100MB storage, no ads, fast webmail, access on any device, retrieve and filter email. From davem@redhat.com Fri Aug 8 17:06:42 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Aug 2003 17:06:48 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7906fFl020917 for ; Fri, 8 Aug 2003 17:06:42 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id RAA32358; Fri, 8 Aug 2003 17:01:30 -0700 Date: Fri, 8 Aug 2003 17:01:30 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: nf@hipac.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [RFC] High Performance Packet Classifiction for tc framework Message-Id: <20030808170130.578ff441.davem@redhat.com> In-Reply-To: <1060379500.1723.214.camel@jzny.localdomain> References: <200307141045.40999.nf@hipac.org> <1058328537.1797.24.camel@jzny.localdomain> <3F16A0E5.1080007@hipac.org> <1059934468.1103.41.camel@jzny.localdomain> <3F2E5CD6.4030500@hipac.org> <1060012260.1103.380.camel@jzny.localdomain> <3F302E04.1090503@hipac.org> <1060286331.1025.73.camel@jzny.localdomain> <20030807130502.4af9c815.davem@redhat.com> <1060379500.1723.214.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4685 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On 08 Aug 2003 17:51:40 -0400 jamal wrote: > Its easy to use hashes when you know that you need to > find example ip src/dst. Jenkins is rather agnostic about the input bits, that's what makes it so powerful. It performs about as well for random input as it does for input which has various patterns. Wait, are you saying the input key size can change? Yes, that's an interesting problem. But for things where you always want some 96-bit key, Jenkins is probably best. From davem@redhat.com Fri Aug 8 23:44:52 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Aug 2003 23:44:57 -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 h796ipFl005112 for ; Fri, 8 Aug 2003 23:44:52 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id XAA00635; Fri, 8 Aug 2003 23:39:40 -0700 Date: Fri, 8 Aug 2003 23:39:40 -0700 From: "David S. Miller" To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: Re: RFR: new SiS gige driver Message-Id: <20030808233940.6ad767f5.davem@redhat.com> In-Reply-To: <20030808173932.GA4077@gtf.org> References: <20030808173932.GA4077@gtf.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4686 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 8 Aug 2003 13:39:33 -0400 Jeff Garzik wrote: > This driver is actually a lot more clean than many that crop up. So far > most of my nits are minor: egrep virt_to_bus sis190.c :-( I think this is more important to fix than any of the other things which have been listed. I really believe we're at the point where putting PCI device drivers into the tree still using virt_to_bus() and friends should simply not be allowed... From yoshfuji@linux-ipv6.org Sat Aug 9 00:29:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Aug 2003 00:29:53 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h797ThFl008075 for ; Sat, 9 Aug 2003 00:29:44 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h797Tq1M004639; Sat, 9 Aug 2003 16:29:53 +0900 Date: Sat, 09 Aug 2003 16:29:52 +0900 (JST) Message-Id: <20030809.162952.114376111.yoshfuji@linux-ipv6.org> To: davem@redhat.com CC: netdev@oss.sgi.com Subject: [PATCH] IPVS: linkage error without CONFIG_IP_VS_PROTO_TCP From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4687 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev This patch fixes linkage error occurs if CONFIG_IP_VS_PROTO_TCP is not set. Thanks. Index: linux26/net/ipv4/ipvs/ip_vs_core.c =================================================================== RCS file: /cvsroot/usagi/usagi/kernel/linux26/net/ipv4/ipvs/ip_vs_core.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 ip_vs_core.c --- linux26/net/ipv4/ipvs/ip_vs_core.c 15 Jul 2003 07:42:29 -0000 1.1.1.1 +++ linux26/net/ipv4/ipvs/ip_vs_core.c 9 Aug 2003 07:14:55 -0000 @@ -53,7 +53,9 @@ EXPORT_SYMBOL(ip_vs_conn_new); EXPORT_SYMBOL(ip_vs_conn_in_get); EXPORT_SYMBOL(ip_vs_conn_out_get); +#ifdef CONFIG_IP_VS_PROTO_TCP EXPORT_SYMBOL(ip_vs_tcp_conn_listen); +#endif EXPORT_SYMBOL(ip_vs_conn_put); #ifdef CONFIG_IP_VS_DEBUG EXPORT_SYMBOL(ip_vs_get_debug_level); -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From davem@redhat.com Sat Aug 9 01:11:32 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Aug 2003 01:11: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 h798BVFl009984 for ; Sat, 9 Aug 2003 01:11:31 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id BAA00751; Sat, 9 Aug 2003 01:06:06 -0700 Date: Sat, 9 Aug 2003 01:06:06 -0700 From: "David S. Miller" To: Jan Oravec Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: problem setting net.ipvX.conf.all.forwarding via sysctl() system call Message-Id: <20030809010606.6cfce75c.davem@redhat.com> In-Reply-To: <20030808091124.GA17961@wsx.ksp.sk> References: <20030803154427.GA12926@wsx.ksp.sk> <20030808.174504.14391608.yoshfuji@linux-ipv6.org> <20030808091124.GA17961@wsx.ksp.sk> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4688 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 8 Aug 2003 11:11:24 +0200 Jan Oravec wrote: > this is a new patch ... > + ipv4_devconf.forwarding = new; > inet_forward_change(); > - return 1; > + return 0; This is still wrong. First of all we have the table->data pointer in "valp" so let's use that to set the value. In this way we can use this function for other sysctl values if we ever desire to do that. Second, if we set the table->data value, we must return > 0. This tells the caller that we've done the sysctl value update. If we return zero, it would update the value a second time. Here is the fix I'm going to use. # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1136 -> 1.1137 # net/ipv4/sysctl_net_ipv4.c 1.11 -> 1.12 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 03/08/09 davem@nuts.ninka.net 1.1137 # [IPV4]: Fix setting net.ipv4.conf.all.forwarding via sysctl() system call. # -------------------------------------------- # diff -Nru a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c --- a/net/ipv4/sysctl_net_ipv4.c Sat Aug 9 01:02:17 2003 +++ b/net/ipv4/sysctl_net_ipv4.c Sat Aug 9 01:02:17 2003 @@ -109,6 +109,7 @@ } } + *valp = new; inet_forward_change(); return 1; } From davem@redhat.com Sat Aug 9 01:14:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Aug 2003 01:14:04 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h798DxFl010350 for ; Sat, 9 Aug 2003 01:14:00 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id BAA00766; Sat, 9 Aug 2003 01:08:45 -0700 Date: Sat, 9 Aug 2003 01:08:45 -0700 From: "David S. Miller" To: "YOSHIFUJI Hideaki / _$B5HF#1QL@" Cc: jan.oravec@6com.sk, netdev@oss.sgi.com Subject: Re: [PATCH] IPV6: strategy hander for net.ipv6.conf.*.forwarding (is Re: problem setting net.ipvX.conf.all.forwarding via sysctl() system call) Message-Id: <20030809010845.01ebcbe9.davem@redhat.com> In-Reply-To: <20030808.185135.112441851.yoshfuji@linux-ipv6.org> References: <20030803154427.GA12926@wsx.ksp.sk> <20030808.175030.19527061.yoshfuji@linux-ipv6.org> <20030808093704.GA18131@wsx.ksp.sk> <20030808.185135.112441851.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4689 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 08 Aug 2003 18:51:35 +0900 (JST) YOSHIFUJI Hideaki / _$B5HF#1QL@ wrote: > In article <20030808093704.GA18131@wsx.ksp.sk> (at Fri, 8 Aug 2003 11:37:04 +0200), Jan Oravec says: > > > On Fri, Aug 08, 2003 at 05:50:30PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > > > > + *valp = new; > > > + if (valp != &ipv6_devconf.forwarding && > > > + valp != &ipv6_devconf_dflt.forwarding) { > > > + struct inet6_dev *idev = (struct inet6_dev *)table->extra1; > > > + if (!idev) > > > + return -ENODEV; > > > + addrconf_forward_change(idev); > > > + } > > > + return 0; > > > +} > > > > Shouldn't we set ipv6_devconf_dflt.forwarding and call > > addr_forward_change(NULL) in case that valp==&ipv6_devconf.forwarding? > > Oh, You're right. Here's the revised one: As I mentioned for the ipv4 forwarding sysctl bug fix, if you will set table->data yourself you should return > 0 (for example "1") from your strategy handler. The patch looks fine otherwise. Please fix this, thank you. From davem@redhat.com Sat Aug 9 01:15:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Aug 2003 01:15: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 h798FdFl010757 for ; Sat, 9 Aug 2003 01:15:40 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id BAA00796; Sat, 9 Aug 2003 01:10:31 -0700 Date: Sat, 9 Aug 2003 01:10:31 -0700 From: "David S. Miller" To: "YOSHIFUJI Hideaki / _$B5HF#1QL@" Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPV6: typo in include/linux/ipv6.h Message-Id: <20030809011031.14b9f639.davem@redhat.com> In-Reply-To: <20030808.223742.55652930.yoshfuji@linux-ipv6.org> References: <20030808.223742.55652930.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4690 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 08 Aug 2003 22:37:42 +0900 (JST) YOSHIFUJI Hideaki / _$B5HF#1QL@ wrote: > Typo in definition in include/linux/ipv6.h. > 2.4.x has similar bug, too. Applied, thank you. From davem@redhat.com Sat Aug 9 01:23:10 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Aug 2003 01:23:17 -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 h798NAFl011425 for ; Sat, 9 Aug 2003 01:23:10 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id BAA00838; Sat, 9 Aug 2003 01:18:02 -0700 Date: Sat, 9 Aug 2003 01:18:01 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] tun driver use private linked list. Message-Id: <20030809011801.3258f7af.davem@redhat.com> In-Reply-To: <20030808113404.0e9e1e6d.shemminger@osdl.org> References: <200308051630.28552.bellucda@tiscali.it> <20030805090647.691daa7e.shemminger@osdl.org> <200308051910.55823.bellucda@tiscali.it> <20030807154524.4794ad45.shemminger@osdl.org> <20030807155901.49f1a424.davem@redhat.com> <20030808113404.0e9e1e6d.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4691 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 8 Aug 2003 11:34:04 -0700 Stephen Hemminger wrote: > Less grotty version, applies over earlier patch. > - keep a private list. > - fix debug format strings. > - drop the name entry in the private data structure since it already > has a pointer to netdev that has name. Applied, thanks for following up on this Stephen. From davem@redhat.com Sat Aug 9 02:39:21 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Aug 2003 02:39: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 h799dKFl017451 for ; Sat, 9 Aug 2003 02:39:20 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id CAA01103; Sat, 9 Aug 2003 02:34:05 -0700 Date: Sat, 9 Aug 2003 02:34:05 -0700 From: "David S. Miller" To: "YOSHIFUJI Hideaki / _$B5HF#1QL@" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] IPVS: linkage error without CONFIG_IP_VS_PROTO_TCP Message-Id: <20030809023405.3aa597dd.davem@redhat.com> In-Reply-To: <20030809.162952.114376111.yoshfuji@linux-ipv6.org> References: <20030809.162952.114376111.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4692 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sat, 09 Aug 2003 16:29:52 +0900 (JST) YOSHIFUJI Hideaki / _$B5HF#1QL@ wrote: > This patch fixes linkage error occurs if CONFIG_IP_VS_PROTO_TCP > is not set. Applied, thank you. From yoshfuji@linux-ipv6.org Sat Aug 9 03:21:59 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Aug 2003 03:22:06 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h79ALvFl022472 for ; Sat, 9 Aug 2003 03:21:58 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h79ALx1M005553; Sat, 9 Aug 2003 19:21:59 +0900 Date: Sat, 09 Aug 2003 19:21:58 +0900 (JST) Message-Id: <20030809.192158.47862071.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: jan.oravec@6com.sk, netdev@oss.sgi.com Subject: Re: [PATCH] IPV6: strategy hander for net.ipv6.conf.*.forwarding (is Re: problem setting net.ipvX.conf.all.forwarding via sysctl() system call) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20030809010845.01ebcbe9.davem@redhat.com> References: <20030808093704.GA18131@wsx.ksp.sk> <20030808.185135.112441851.yoshfuji@linux-ipv6.org> <20030809010845.01ebcbe9.davem@redhat.com> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4693 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <20030809010845.01ebcbe9.davem@redhat.com> (at Sat, 9 Aug 2003 01:08:45 -0700), "David S. Miller" says: > As I mentioned for the ipv4 forwarding sysctl bug fix, > if you will set table->data yourself you should return > > 0 (for example "1") from your strategy handler. : > Please fix this, thank you. Here it is. Index: linux-2.6/net/ipv6/addrconf.c =================================================================== RCS file: /home/cvs/linux-2.5/net/ipv6/addrconf.c,v retrieving revision 1.48 diff -u -r1.48 addrconf.c --- linux-2.6/net/ipv6/addrconf.c 25 Jul 2003 23:58:59 -0000 1.48 +++ linux-2.6/net/ipv6/addrconf.c 9 Aug 2003 08:51:42 -0000 @@ -2593,6 +2593,53 @@ return ret; } +static int addrconf_sysctl_forward_strategy(ctl_table *table, + int *name, int nlen, + void *oldval, size_t *oldlenp, + void *newval, size_t newlen, + void **context) +{ + int *valp = table->data; + int new; + + if (!newval || !newlen) + return 0; + if (newlen != sizeof(int)) + return -EINVAL; + if (get_user(new, (int *)newval)) + return -EFAULT; + if (new == *valp) + return 0; + if (oldval && oldlenp) { + size_t len; + if (get_user(len, oldlenp)) + return -EFAULT; + if (len) { + if (len > table->maxlen) + len = table->maxlen; + if (copy_to_user(oldval, valp, len)) + return -EFAULT; + if (put_user(len, oldlenp)) + return -EFAULT; + } + } + + if (valp != &ipv6_devconf_dflt.forwarding) { + struct inet6_dev *idev; + if (valp != &ipv6_devconf.forwarding) { + idev = (struct inet6_dev *)table->extra1; + if (unlikely(idev == NULL)) + return -ENODEV; + } else + idev = NULL; + *valp = new; + addrconf_forward_change(idev); + } else + *valp = new; + + return 1; +} + static struct addrconf_sysctl_table { struct ctl_table_header *sysctl_header; @@ -2611,6 +2658,7 @@ .maxlen = sizeof(int), .mode = 0644, .proc_handler = &addrconf_sysctl_forward, + .strategy = &addrconf_sysctl_forward_strategy, }, { .ctl_name = NET_IPV6_HOP_LIMIT, -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From shmulik.hen@intel.com Sat Aug 9 03:29:19 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Aug 2003 03:29:22 -0700 (PDT) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h79ATGFl023468 for ; Sat, 9 Aug 2003 03:29:18 -0700 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h79ANvM28038 for ; Sat, 9 Aug 2003 10:23:57 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h79AWD017421 for ; Sat, 9 Aug 2003 10:32:15 GMT Received: from hasmsx331.ger.corp.intel.com ([143.185.63.144]) by hasmsxvs01.iil.intel.com (NAVGW 2.5.2.11) with SMTP id M2003080913361709031 ; Sat, 09 Aug 2003 13:36:17 +0300 Received: from hasmsx403.ger.corp.intel.com ([143.185.63.109]) by hasmsx331.ger.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 9 Aug 2003 13:29:08 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [SET 2][PATCH 2/8][bonding] Propagating master's settings to slaves Date: Sat, 9 Aug 2003 13:29:08 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [SET 2][PATCH 2/8][bonding] Propagating master's settings toslaves Thread-Index: AcNd+KHqOJcY40/CSMqRlLdGamwFSwAZpZEA From: "Hen, Shmulik" To: Cc: , X-OriginalArrivalTime: 09 Aug 2003 10:29:08.0350 (UTC) FILETIME=[10D159E0:01C35E61] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h79ATGFl023468 X-archive-position: 4694 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev > -----Original Message----- > From: jamal [mailto:hadi@cyberus.ca] > Sent: Saturday, August 09, 2003 1:01 AM > To: Hen, Shmulik > Cc: bonding-devel@lists.sourceforge.net; netdev@oss.sgi.com > Subject: Re: [SET 2][PATCH 2/8][bonding] Propagating master's settings > to slaves > > Shmulik, > > Some of this bonding stuff is pretty scary. Lotsa policies in the > kernel and communication seems to be centred around /proc. > Shouldnt policies on failover be really driven from user space? > Also shouldnt communication be using something like netlink? > > cheers, > jamal > > On Fri, 2003-08-08 at 10:44, Shmulik Hen wrote: > > 2 - Change monitoring function use the new functionality. > > > Not sure I fully understood the concerns above, but I'll try to explain what the change was all about. By monitoring, I meant the 3 timer function running in bonding to monitor link changes and act once a link fail/recovery is detected. The old code used to do all the activity related to changing the current active slave separately in each timer function and it seemed redundant since it was basically the same thing repeated 3 times. Instead, we thought it would be best if we put that into 3 new functions - reselect_active, find_best_slave and change_active that does all the actual stuff of swapping an old current with the new one. The change we did in /proc was to reduce the amount of data extarcted each time the proc entry is polled. Instead of dumping all the data of all the bond devices that exist, each bond returns just data that is relevant to itself. In the lonf term, the drive is to move any *smart* code done in the config application into the driver itself and be left with the smallest, most compact application as possible. This is the trend we've seen in the VLAN config app, and the bridge module. All the "brain" is in the kernel module and very little should be done in the application. Shmulik. From shmulik.hen@intel.com Sat Aug 9 05:40:55 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Aug 2003 05:41:01 -0700 (PDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h79CesFl001100 for ; Sat, 9 Aug 2003 05:40:55 -0700 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h78EdBw27945 for ; Fri, 8 Aug 2003 14:39:11 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h78E8IT07196 for ; Fri, 8 Aug 2003 14:08:18 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.254.188]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003080807572403054 ; Fri, 08 Aug 2003 07:57:25 -0700 Content-Type: text/plain; charset="us-ascii" From: Shmulik Hen Reply-To: shmulik.hen@intel.com Organization: Intel corp. Subject: [SET 2][PATCH 5/8][bonding] Propagating master's settings to slaves Date: Fri, 8 Aug 2003 17:45:10 +0300 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit To: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Message-Id: <200308081745.10710.shmulik.hen@intel.com> X-archive-position: 4695 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev 5 - Add support for changing HW address and MTU with proper unwind. diff -Nuarp linux-2.4.22-rc1/drivers/net/bonding/bond_main.c linux-2.4.22-rc1-devel/drivers/net/bonding/bond_main.c --- linux-2.4.22-rc1/drivers/net/bonding/bond_main.c Fri Aug 8 14:03:22 2003 +++ linux-2.4.22-rc1-devel/drivers/net/bonding/bond_main.c Fri Aug 8 14:03:23 2003 @@ -592,6 +592,11 @@ static struct slave *find_best_interface /* #define BONDING_DEBUG 1 */ +#ifdef BONDING_DEBUG +#define dprintk(x...) printk(x...) +#else /* BONDING_DEBUG */ +#define dprintk(x...) do {} while (0) +#endif /* BONDING_DEBUG */ /* several macros */ @@ -680,19 +685,6 @@ update_slave_cnt(bonding_t *bond, int in BUG(); } -/* - * Set MAC. Differs from eth_mac_addr in that we allow changes while - * netif_running(). - */ -static int -bond_set_mac_address(struct net_device *dev, void *p) -{ - struct sockaddr *addr = p; - - memcpy(dev->dev_addr, addr->sa_data, dev->addr_len); - return 0; -} - /* * This function detaches the slave from the list . * WARNING: no check is made to verify if the slave effectively @@ -3037,10 +3029,6 @@ static int bond_ioctl(struct net_device case SIOCBONDRELEASE: ret = bond_release(master_dev, slave_dev); break; - case BOND_SETHWADDR_OLD: - case SIOCBONDSETHWADDR: - ret = bond_sethwaddr(master_dev, slave_dev); - break; case BOND_CHANGE_ACTIVE_OLD: case SIOCBONDCHANGEACTIVE: if (USES_PRIMARY(bond_mode)) { @@ -3480,6 +3468,132 @@ static int bond_read_proc(char *buf, cha } #endif /* CONFIG_PROC_FS */ + +/* + * Change HW address + * + * Note that many devices must be down to change the HW address, and + * downing the master releases all slaves. We can make bonds full of + * bonding devices to test this, however. + */ +static inline int +bond_set_mac_address(struct net_device *dev, void *addr) +{ + struct bonding *bond = dev->priv; + struct sockaddr *sa = addr, tmp_sa; + struct slave *slave; + int error; + + dprintk(KERN_INFO "bond_set_mac_address %p %s\n", dev, + dev->name); + + if (!is_valid_ether_addr(sa->sa_data)) { + return -EADDRNOTAVAIL; + } + + for (slave = bond->prev; slave != (struct slave *)bond; + slave = slave->prev) { + dprintk(KERN_INFO "bond_set_mac: slave %p %s\n", slave, + slave->dev->name); + if (slave->dev->set_mac_address == NULL) { + error = -EOPNOTSUPP; + dprintk(KERN_INFO "bond_set_mac EOPNOTSUPP %s\n", + slave->dev->name); + goto unwind; + } + + error = slave->dev->set_mac_address(slave->dev, addr); + if (error) { + /* TODO: consider downing the slave + * and retry ? + * User should expect communications + * breakage anyway until ARP finish + * updating, so... + */ + dprintk(KERN_INFO "bond_set_mac err %d %s\n", + error, slave->dev->name); + goto unwind; + } + } + + /* success */ + memcpy(dev->dev_addr, sa->sa_data, dev->addr_len); + return 0; + +unwind: + memcpy(tmp_sa.sa_data, dev->dev_addr, dev->addr_len); + tmp_sa.sa_family = dev->type; + + for (slave = slave->next; slave != bond->next; + slave = slave->next) { + int tmp_error; + + tmp_error = slave->dev->set_mac_address(slave->dev, &tmp_sa); + if (tmp_error) { + dprintk(KERN_INFO "bond_set_mac_address: " + "unwind err %d dev %s\n", + tmp_error, slave->dev->name); + } + } + + return error; +} + +/* + * Change the MTU of all of a master's slaves to match the master + */ +static inline int +bond_change_mtu(struct net_device *dev, int newmtu) +{ + bonding_t *bond = dev->priv; + slave_t *slave; + int error; + + dprintk(KERN_INFO "CM: b %p nm %d\n", bond, newmtu); + for (slave = bond->prev; slave != (slave_t *)bond; + slave = slave->prev) { + dprintk(KERN_INFO "CM: s %p s->p %p c_m %p\n", slave, + slave->prev, slave->dev->change_mtu); + if (slave->dev->change_mtu) { + error = slave->dev->change_mtu(slave->dev, newmtu); + } else { + slave->dev->mtu = newmtu; + error = 0; + } + + if (error) { + /* If we failed to set the slave's mtu to the new value + * we must abort the operation even in ACTIVE_BACKUP + * mode, because if we allow the backup slaves to have + * different mtu values than the active slave we'll + * need to change their mtu when doing a failover. That + * means changing their mtu from timer context, which + * is probably not a good idea. + */ + dprintk(KERN_INFO "bond_change_mtu err %d %s\n", + error, slave->dev->name); + goto unwind; + } + } + + dev->mtu = newmtu; + return 0; + + +unwind: + for (slave = slave->next; slave != bond->next; + slave = slave->next) { + + if (slave->dev->change_mtu) { + slave->dev->change_mtu(slave->dev, dev->mtu); + } else { + slave->dev->mtu = dev->mtu; + } + } + + return error; +} + static int bond_event(struct notifier_block *this, unsigned long event, void *ptr) { @@ -3572,6 +3686,7 @@ static int __init bond_init(struct net_d dev->stop = bond_close; dev->set_multicast_list = set_multicast_list; dev->do_ioctl = bond_ioctl; + dev->change_mtu = bond_change_mtu; dev->set_mac_address = bond_set_mac_address; dev->tx_queue_len = 0; dev->flags |= IFF_MASTER|IFF_MULTICAST; -- | Shmulik Hen Advanced Network Services | | Israel Design Center, Jerusalem | | LAN Access Division, Platform Networking | | Intel Communications Group, Intel corp. | From shmulik.hen@intel.com Sat Aug 9 05:40:56 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Aug 2003 05:41:01 -0700 (PDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h79CesFn001100 for ; Sat, 9 Aug 2003 05:40:56 -0700 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h78Ed7w27888 for ; Fri, 8 Aug 2003 14:39:08 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h78E8ET07131 for ; Fri, 8 Aug 2003 14:08:14 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.254.188]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003080807572021576 ; Fri, 08 Aug 2003 07:57:21 -0700 Content-Type: text/plain; charset="us-ascii" From: Shmulik Hen Reply-To: shmulik.hen@intel.com Organization: Intel corp. Subject: [SET 2][PATCH 4/8][bonding] Propagating master's settings to slaves Date: Fri, 8 Aug 2003 17:45:06 +0300 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit To: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Message-Id: <200308081745.06800.shmulik.hen@intel.com> X-archive-position: 4696 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev 4 - Decouple promiscuous handling from the multicast mode setting. diff -Nuarp linux-2.4.22-rc1/drivers/net/bonding/bond_main.c linux-2.4.22-rc1-devel/drivers/net/bonding/bond_main.c --- linux-2.4.22-rc1/drivers/net/bonding/bond_main.c Fri Aug 8 14:03:20 2003 +++ linux-2.4.22-rc1-devel/drivers/net/bonding/bond_main.c Fri Aug 8 14:03:21 2003 @@ -1167,23 +1167,22 @@ static inline int dmi_same(struct dev_mc } /* - * Push the promiscuity flag down to all slaves + * Push the promiscuity flag down to appropriate slaves */ static void bond_set_promiscuity(bonding_t *bond, int inc) { slave_t *slave; - switch (multicast_mode) { - case BOND_MULTICAST_ACTIVE : - /* write lock already acquired */ - if (bond->current_slave != NULL) + + if (USES_PRIMARY(bond_mode)) { + if (bond->current_slave) { dev_set_promiscuity(bond->current_slave->dev, inc); - break; - case BOND_MULTICAST_ALL : - for (slave = bond->prev; slave != (slave_t*)bond; slave = slave->prev) + } + + } else { + for (slave = bond->prev; slave != (slave_t*)bond; + slave = slave->prev) { dev_set_promiscuity(slave->dev, inc); - break; - case BOND_MULTICAST_DISABLED : - break; + } } } @@ -1229,20 +1228,23 @@ static void set_multicast_list(struct ne bonding_t *bond = master->priv; struct dev_mc_list *dmi; - if (multicast_mode == BOND_MULTICAST_DISABLED) - return; - /* - * Lock the private data for the master - */ write_lock_bh(&bond->lock); - /* set promiscuity flag to slaves */ + /* + * Do promisc before checking multicast_mode + */ if ( (master->flags & IFF_PROMISC) && !(bond->flags & IFF_PROMISC) ) bond_set_promiscuity(bond, 1); if ( !(master->flags & IFF_PROMISC) && (bond->flags & IFF_PROMISC) ) bond_set_promiscuity(bond, -1); + if (multicast_mode == BOND_MULTICAST_DISABLED) { + bond->flags = master->flags; + write_unlock_bh(&bond->lock); + return; + } + /* set allmulti flag to slaves */ if ( (master->flags & IFF_ALLMULTI) && !(bond->flags & IFF_ALLMULTI) ) bond_set_allmulti(bond, 1); @@ -1274,32 +1276,40 @@ static void set_multicast_list(struct ne /* * Update the mc list and multicast-related flags for the new and - * old active slaves (if any) according to the multicast mode + * old active slaves (if any) according to the multicast mode, and + * promiscuous flags unconditionally. */ static void bond_mc_update(bonding_t *bond, slave_t *new, slave_t *old) { struct dev_mc_list *dmi; - switch(multicast_mode) { - case BOND_MULTICAST_ACTIVE : + if (USES_PRIMARY(bond_mode)) { if (bond->device->flags & IFF_PROMISC) { - if (old != NULL && new != old) + if (old) dev_set_promiscuity(old->dev, -1); - dev_set_promiscuity(new->dev, 1); + if (new) + dev_set_promiscuity(new->dev, 1); } + } + + switch(multicast_mode) { + case BOND_MULTICAST_ACTIVE : if (bond->device->flags & IFF_ALLMULTI) { - if (old != NULL && new != old) + if (old) dev_set_allmulti(old->dev, -1); - dev_set_allmulti(new->dev, 1); + if (new) + dev_set_allmulti(new->dev, 1); } /* first remove all mc addresses from old slave if any, and _then_ add them to new active slave */ - if (old != NULL && new != old) { + if (old) { for (dmi = bond->device->mc_list; dmi != NULL; dmi = dmi->next) dev_mc_delete(old->dev, dmi->dmi_addr, dmi->dmi_addrlen, 0); } - for (dmi = bond->device->mc_list; dmi != NULL; dmi = dmi->next) - dev_mc_add(new->dev, dmi->dmi_addr, dmi->dmi_addrlen, 0); + if (new) { + for (dmi = bond->device->mc_list; dmi != NULL; dmi = dmi->next) + dev_mc_add(new->dev, dmi->dmi_addr, dmi->dmi_addrlen, 0); + } break; case BOND_MULTICAST_ALL : /* nothing to do: mc list is already up-to-date on all slaves */ @@ -1461,11 +1471,19 @@ static int bond_enslave(struct net_devic } } - if (multicast_mode == BOND_MULTICAST_ALL) { - /* set promiscuity level to new slave */ - if (master_dev->flags & IFF_PROMISC) + /* set promiscuity level to new slave */ + if (master_dev->flags & IFF_PROMISC) { + /* If the mode USES_PRIMARY, then the new slave gets the + * master's promisc (and mc) settings only if it becomes the + * current_slave, and that is taken care of later when calling + * bond_change_active() + */ + if (!USES_PRIMARY(bond_mode)) { dev_set_promiscuity(slave_dev, 1); + } + } + if (multicast_mode == BOND_MULTICAST_ALL) { /* set allmulti level to new slave */ if (master_dev->flags & IFF_ALLMULTI) dev_set_allmulti(slave_dev, 1); @@ -2040,16 +2058,22 @@ static int bond_release(struct net_devic return -EINVAL; } + /* unset promiscuity level from slave */ + if (master->flags & IFF_PROMISC) { + /* If the mode USES_PRIMARY, then we should only remove its + * promisc settings if it was the current_slave, but that was + * already taken care of above when we detached the slave + */ + if (!USES_PRIMARY(bond_mode)) { + dev_set_promiscuity(slave, -1); + } + } + /* undo settings and restore original values */ - if (multicast_mode == BOND_MULTICAST_ALL) { /* flush master's mc_list from slave */ bond_mc_list_flush (slave, master); - /* unset promiscuity level from slave */ - if (master->flags & IFF_PROMISC) - dev_set_promiscuity(slave, -1); - /* unset allmulti level from slave */ if (master->flags & IFF_ALLMULTI) dev_set_allmulti(slave, -1); @@ -2145,17 +2169,17 @@ static int bond_release_all(struct net_d */ write_unlock_bh(&bond->lock); - if (multicast_mode == BOND_MULTICAST_ALL - || (multicast_mode == BOND_MULTICAST_ACTIVE - && old_current == our_slave)) { + /* unset promiscuity level from slave */ + if (master->flags & IFF_PROMISC) { + if (!USES_PRIMARY(bond_mode)) { + dev_set_promiscuity(slave_dev, -1); + } + } + if (multicast_mode == BOND_MULTICAST_ALL) { /* flush master's mc_list from slave */ bond_mc_list_flush (slave_dev, master); - /* unset promiscuity level from slave */ - if (master->flags & IFF_PROMISC) - dev_set_promiscuity(slave_dev, -1); - /* unset allmulti level from slave */ if (master->flags & IFF_ALLMULTI) dev_set_allmulti(slave_dev, -1); @@ -3650,6 +3674,12 @@ static int __init bonding_init(void) mode == NULL ? "NULL" : mode); return -EINVAL; } + } + + if (USES_PRIMARY(bond_mode)) { + multicast_mode = BOND_MULTICAST_ACTIVE; + } else { + multicast_mode = BOND_MULTICAST_ALL; } if (multicast) { -- | Shmulik Hen Advanced Network Services | | Israel Design Center, Jerusalem | | LAN Access Division, Platform Networking | | Intel Communications Group, Intel corp. | From mailperson@alexandria.cc Sat Aug 9 06:44:43 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Aug 2003 06:44:52 -0700 (PDT) Received: from alexandria.cc (user-0ccetq0.cable.mindspring.com [24.199.119.64]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h79DifFl005480 for ; Sat, 9 Aug 2003 06:44:42 -0700 From: mailperson@alexandria.cc To: netdev@oss.sgi.com Date: 09 Aug 2003 09:44:34 -0400 Message-ID: <20030809094434.A6929C2F7F46598B@alexandria.cc> MIME-Version: 1.0 X-archive-position: 4697 Subject: (no subject) X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mailperson@alexandria.cc Precedence: bulk X-list: netdev From ak@suse.de Sat Aug 9 07:15:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Aug 2003 07:15:45 -0700 (PDT) Received: from Cantor.suse.de (mail.suse.de [213.95.15.193]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h79EFdFl007586 for ; Sat, 9 Aug 2003 07:15:40 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id D14C214B94; Sat, 9 Aug 2003 16:15:33 +0200 (MEST) Date: Sat, 9 Aug 2003 16:15:33 +0200 From: Andi Kleen To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: Re: RFR: new SiS gige driver Message-ID: <20030809141533.GB4539@wotan.suse.de> References: <20030808173932.GA4077@gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030808173932.GA4077@gtf.org> X-archive-position: 4698 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev > * since it's gige, it should definitely be using NAPI * it does not check its kmalloc returns. * and doesn't set a DMA mask. This means it is not DAC capable? * does not use pci_dma_* mappings like David noted. * no hardware checksum support? This looks quite poor for a Gigabit chipset. * same with sendpage - gigabit should have that. * missing NAPI and even with NAPI it should support interrupt mitigation - but the driver doesn't seem to do that. I suspect it's very easily DoSable in the current form. Even with NAPI interrupt mitigation would be needed, otherwise the start/stop of polling mode can be too expensive for moderate load. * netif_stop_queue in hard_start_xmit is not protected against the interrupt by the spinlock. That's racy, isn't it? -Andi From ak@suse.de Sat Aug 9 08:27:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Aug 2003 08:28:01 -0700 (PDT) Received: from Cantor.suse.de (mail.suse.de [213.95.15.193]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h79FRqFl011801 for ; Sat, 9 Aug 2003 08:27:53 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 9D0A114B7B; Sat, 9 Aug 2003 17:27:47 +0200 (MEST) Date: Sat, 9 Aug 2003 17:27:47 +0200 From: Andi Kleen To: Jeff Garzik Cc: Andi Kleen , netdev@oss.sgi.com Subject: Re: RFR: new SiS gige driver Message-ID: <20030809152747.GA1618@wotan.suse.de> References: <20030808173932.GA4077@gtf.org> <20030809141533.GB4539@wotan.suse.de> <3F350CC8.3090605@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F350CC8.3090605@pobox.com> X-archive-position: 4699 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev On Sat, Aug 09, 2003 at 11:01:28AM -0400, Jeff Garzik wrote: > Andi Kleen wrote: > >* netif_stop_queue in hard_start_xmit is not protected against the > >interrupt by the spinlock. That's racy, isn't it? > > Shouldn't be, if done right. If the interrupt runs a TX completion > cycle, it will run the code > if (work_done && netif_queue_stopped(dev)) > netif_wake_queue(dev) > > Since ->hard_start_xmit is guaranteed never to be called if the queue is > stopped, you also guaranteed that netif_wake_queue and ->hard_start_xmit > are mutually exclusive. The race is CPU0 CPU1 hard_start_xmit release lock TX finished interrupt my queue is full... clean some packets netif_wake_queue netif_stop_queue The netif_wake_queue is lost. It's only deadly when clean some packets clears the full TX ring, otherwise it will likely recover with the next TX finished interrupt but give suboptimal performance. Fix is to do the my queue is full -> netif_stop_queue inside the spinlock. -Andi From jgarzik@pobox.com Sat Aug 9 09:00:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Aug 2003 09:00:46 -0700 (PDT) Received: from www.linux.org.uk (IDENT:U+uCazPeXDTaOTgsXiae7FItTD8TYQfW@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h79G0dFl013827 for ; Sat, 9 Aug 2003 09:00:40 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19lVDv-0007Rh-Rp; Sat, 09 Aug 2003 16:01:39 +0100 Message-ID: <3F350CC8.3090605@pobox.com> Date: Sat, 09 Aug 2003 11:01:28 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: Andi Kleen CC: netdev@oss.sgi.com Subject: Re: RFR: new SiS gige driver References: <20030808173932.GA4077@gtf.org> <20030809141533.GB4539@wotan.suse.de> In-Reply-To: <20030809141533.GB4539@wotan.suse.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4700 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 Andi Kleen wrote: > * netif_stop_queue in hard_start_xmit is not protected against the interrupt by the > spinlock. That's racy, isn't it? Shouldn't be, if done right. If the interrupt runs a TX completion cycle, it will run the code if (work_done && netif_queue_stopped(dev)) netif_wake_queue(dev) Since ->hard_start_xmit is guaranteed never to be called if the queue is stopped, you also guaranteed that netif_wake_queue and ->hard_start_xmit are mutually exclusive. This of course assumes certain details about the driver implementation, which may be missing from that driver's TX completion handler :) Thanks for your, and everybody else's comments. They are being saved. Jeff From davem@redhat.com Sat Aug 9 14:49:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Aug 2003 14:49:51 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h79LniFl003121 for ; Sat, 9 Aug 2003 14:49:45 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id OAA02462; Sat, 9 Aug 2003 14:44:16 -0700 Date: Sat, 9 Aug 2003 14:44:16 -0700 From: "David S. Miller" To: "YOSHIFUJI Hideaki / _$B5HF#1QL@" Cc: jan.oravec@6com.sk, netdev@oss.sgi.com Subject: Re: [PATCH] IPV6: strategy hander for net.ipv6.conf.*.forwarding (is Re: problem setting net.ipvX.conf.all.forwarding via sysctl() system call) Message-Id: <20030809144416.181cbad1.davem@redhat.com> In-Reply-To: <20030809.192158.47862071.yoshfuji@linux-ipv6.org> References: <20030808093704.GA18131@wsx.ksp.sk> <20030808.185135.112441851.yoshfuji@linux-ipv6.org> <20030809010845.01ebcbe9.davem@redhat.com> <20030809.192158.47862071.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4701 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sat, 09 Aug 2003 19:21:58 +0900 (JST) YOSHIFUJI Hideaki / _$B5HF#1QL@ wrote: > In article <20030809010845.01ebcbe9.davem@redhat.com> (at Sat, 9 Aug 2003 01:08:45 -0700), "David S. Miller" says: > > > As I mentioned for the ipv4 forwarding sysctl bug fix, > > if you will set table->data yourself you should return > > > 0 (for example "1") from your strategy handler. > : > > Please fix this, thank you. > > Here it is. Patch applied, thank you. From kuznet@ms2.inr.ac.ru Sat Aug 9 20:04:21 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Aug 2003 20:04:26 -0700 (PDT) Received: from dub.inr.ac.ru (dub.inr.ac.ru [193.233.7.105]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7A34JFl024026 for ; Sat, 9 Aug 2003 20:04:20 -0700 Received: (from kuznet@localhost) by dub.inr.ac.ru (8.6.13/ANK) id HAA20709; Sun, 10 Aug 2003 07:03:48 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200308100303.HAA20709@dub.inr.ac.ru> Subject: Re: Fw: [PATCH] set NLM_F_MULTI in answer of RTM_GETADDR dump answer To: davem@redhat.com (David S. Miller) Date: Sun, 10 Aug 2003 07:03:48 +0400 (MSD) Cc: hadi@cyberus.ca, netdev@oss.sgi.com In-Reply-To: <20030809011153.46a99ef2.davem@redhat.com> from "David S. Miller" at Aug 09, 2003 01:11:53 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4702 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Hello! > After sending RTM_GETADDR dump request to netlink socket, received multipart > answer does not have NLM_F_MULTI set on each message. This patch fix that. OK. Actually, this flag was never used because of its redundancy it is not the only place where it is not set. Alexey From davem@redhat.com Sat Aug 9 20:53:19 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 09 Aug 2003 20:53:54 -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 h7A3rIFl027672 for ; Sat, 9 Aug 2003 20:53:19 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id UAA03046; Sat, 9 Aug 2003 20:47:28 -0700 Date: Sat, 9 Aug 2003 20:47:28 -0700 From: "David S. Miller" To: kuznet@ms2.inr.ac.ru Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: Fw: [PATCH] set NLM_F_MULTI in answer of RTM_GETADDR dump answer Message-Id: <20030809204728.03100f55.davem@redhat.com> In-Reply-To: <200308100303.HAA20709@dub.inr.ac.ru> References: <20030809011153.46a99ef2.davem@redhat.com> <200308100303.HAA20709@dub.inr.ac.ru> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4703 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sun, 10 Aug 2003 07:03:48 +0400 (MSD) kuznet@ms2.inr.ac.ru wrote: > > After sending RTM_GETADDR dump request to netlink socket, received multipart > > answer does not have NLM_F_MULTI set on each message. This patch fix that. > > OK. > > Actually, this flag was never used because of its redundancy > it is not the only place where it is not set. Ok, I applied the patch. Thanks for the review Alexey. From felix@allot.com Sun Aug 10 00:32:20 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Aug 2003 00:32:29 -0700 (PDT) Received: from mxout2.netvision.net.il (mxout2.netvision.net.il [194.90.9.21]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7A7WIFl009758 for ; Sun, 10 Aug 2003 00:32:20 -0700 Received: from exg.allot.com ([199.203.223.202]) by mxout2.netvision.net.il (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HJE00EHM7LN3Z@mxout2.netvision.net.il> for netdev@oss.sgi.com; Sun, 10 Aug 2003 10:32:12 +0300 (IDT) Received: from allot.com (199.203.223.201 [199.203.223.201]) by exg.allot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QNW75ASP; Sun, 10 Aug 2003 10:35:17 +0200 Date: Sun, 10 Aug 2003 10:32:43 +0300 From: Felix Radensky Subject: Re: Ethernet bridge performance To: hadi@cyberus.ca Cc: Robert Olsson , Ben Greear , netdev@oss.sgi.com Message-id: <3F35F51B.7080301@allot.com> Organization: Allot Communications Ltd. MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_UirtBd6b6YWS5joOM6NHtg)" X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 References: <3F3217E7.2080903@allot.com> <3F3284EA.5050406@candelatech.com> <3F328A0F.3040005@allot.com> <16178.41976.3643.584516@robur.slu.se> <1060284094.1024.36.camel@jzny.localdomain> X-archive-position: 4704 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: felix@allot.com Precedence: bulk X-list: netdev --Boundary_(ID_UirtBd6b6YWS5joOM6NHtg) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Hi, Jamal I guess you were not reading my first posting very carefully :) 2.4.22 has NAPI capable e1000 driver and I've compiled the driver with NAPI support. So running non-NAPI driver is not my problem. Felix. jamal wrote: >Actually seems his biggest problem is he is not running >the NAPI driver > >cheers, >jamal > >On Thu, 2003-08-07 at 15:09, Robert Olsson wrote: > > >>Felix Radensky writes: >> > Thanks for your help, Ben. What is skb-recycle patch >> > and where can I find it ? >> >> It's experimental and not updated for almost a year and current >> implementation does not add anything to SMP. Got some idea how >> to improve this... but try to keep to slab as long as possible >> it has been improved. >> >> Routing/bridging on SMP has affinty problem. If you are passing >> skb's say from eth0 to eth1 and they are bound on different CPU's >> you get cache boucing since the TX-interrupts come on another CPU. >> >> In a recent test with pktgen: >> 300 kpps with TX interrupts on same CPU as sender. >> 198 kpps with TX intr on different CPU as sender. >> >> Recycling tries to address this but current implementation fails >> as said. >> >> But you are probably hit by something else... Check were the drops >> happens qdisc?. NIC ring RX/TX size, Number of interrupts. ksoftird >> priority, link HW_FLOW control, checksumming, affinity etc. >> >> >> Cheers. >> --ro >> >> >> >> > > > --Boundary_(ID_UirtBd6b6YWS5joOM6NHtg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Jamal

I guess you were not reading my first posting
very carefully :)

2.4.22 has NAPI capable e1000 driver and I've
compiled the driver with NAPI support.

So running non-NAPI driver is not my problem.

Felix.

jamal wrote:
Actually seems his biggest problem is he is not running
the NAPI driver

cheers,
jamal

On Thu, 2003-08-07 at 15:09, Robert Olsson wrote:
  
Felix Radensky writes:
 > Thanks for your help, Ben. What is skb-recycle patch
 > and where can I find it ?
 
 It's experimental and not updated for almost a year and current 
 implementation does not add anything to SMP. Got some idea how
 to improve this... but try to keep to slab as long as possible 
 it has been improved.

 Routing/bridging on SMP has affinty problem. If you are passing
 skb's say from eth0 to eth1 and they are bound on different CPU's
 you get cache boucing since the TX-interrupts come on another CPU.

 In a recent test with pktgen:
 300 kpps with TX interrupts on same CPU as sender.
 198 kpps with TX intr on different CPU as sender.

 Recycling tries to address this but current implementation fails
 as said.

 But you are probably hit by something else... Check were the drops 
 happens qdisc?. NIC ring RX/TX size, Number of interrupts. ksoftird 
 priority, link HW_FLOW control, checksumming, affinity etc. 

 
 Cheers.
						--ro

--Boundary_(ID_UirtBd6b6YWS5joOM6NHtg)-- From felix@allot.com Sun Aug 10 02:25:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Aug 2003 02:25:09 -0700 (PDT) Received: from mxout4.netvision.net.il (mxout4.netvision.net.il [194.90.9.27]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7A9OwFl022363 for ; Sun, 10 Aug 2003 02:24:59 -0700 Received: from exg.allot.com ([199.203.223.202]) by mxout4.netvision.net.il (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HJE00BA2BNF0T@mxout4.netvision.net.il> for netdev@oss.sgi.com; Sun, 10 Aug 2003 11:59:40 +0300 (IDT) Received: from allot.com (199.203.223.201 [199.203.223.201]) by exg.allot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QNW75BBQ; Sun, 10 Aug 2003 12:02:45 +0200 Date: Sun, 10 Aug 2003 12:00:12 +0300 From: Felix Radensky Subject: Re: e100 "Ferguson" release To: Jeff Garzik Cc: "Feldman, Scott" , Ben Greear , netdev@oss.sgi.com Message-id: <3F36099C.7090002@allot.com> Organization: Allot Communications Ltd. MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_NRV+4kR+TEKMqsKNRaPtwQ)" X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 References: <20030805152418.GB6695@gtf.org> X-archive-position: 4705 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: felix@allot.com Precedence: bulk X-list: netdev --Boundary_(ID_NRV+4kR+TEKMqsKNRaPtwQ) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Hi, Jeff, Scott Are you planning to fix this before 2.4.22-final ? Thanks. Felix. Jeff Garzik wrote: >On Tue, Aug 05, 2003 at 08:19:25AM -0700, Feldman, Scott wrote: > > >>>I've also noticed that the number of hard_start_xmit failures >>>in e1000 has increased significantly in version 5.1.13-k1. In >>>version 5.0.43-k1 the number of failures was much smaller. >>> >>> >>Interesting. Felix, would you undo the change[1] below in 5.1.13-k1 and >>see what happens? With the change below, 5.1.13 would be more >>aggressive on Tx cleanup, so we'll be quicker waking the queue than >>before. >> >>-scott >> >> for(i = 0; i < E1000_MAX_INTR; i++) >>- if(!e1000_clean_rx_irq(adapter) && >>+ if(!e1000_clean_rx_irq(adapter) & >> !e1000_clean_tx_irq(adapter)) >> break; >> >>[1] Something still bothers me about this new form where we're mixing a >>bit-wise operator with logical operands. Should this bother me? >> >> > >It doesn't matter to the compiler if you make it explicit: > > unsigned int rx_work = e1000_clean_rx_irq(); > unsigned int tx_work = e1000_clean_tx_irq(); > if (!rx_work && !tx_work) > break; > > > > --Boundary_(ID_NRV+4kR+TEKMqsKNRaPtwQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Jeff, Scott

Are you planning to fix this before 2.4.22-final ?

Thanks.

Felix.

Jeff Garzik wrote:
On Tue, Aug 05, 2003 at 08:19:25AM -0700, Feldman, Scott wrote:
  
I've also noticed that the number of hard_start_xmit failures 
in e1000 has increased significantly in version 5.1.13-k1. In 
version 5.0.43-k1 the number of failures was much smaller.
      
Interesting.  Felix, would you undo the change[1] below in 5.1.13-k1 and
see what happens?  With the change below, 5.1.13 would be more
aggressive on Tx cleanup, so we'll be quicker waking the queue than
before. 

-scott

        for(i = 0; i < E1000_MAX_INTR; i++)
-               if(!e1000_clean_rx_irq(adapter) &&
+               if(!e1000_clean_rx_irq(adapter) &
                   !e1000_clean_tx_irq(adapter))
                        break;

[1] Something still bothers me about this new form where we're mixing a
bit-wise operator with logical operands.  Should this bother me?
    

It doesn't matter to the compiler if you make it explicit:

	unsigned int rx_work = e1000_clean_rx_irq();
	unsigned int tx_work = e1000_clean_tx_irq();
	if (!rx_work && !tx_work)
		break;

--Boundary_(ID_NRV+4kR+TEKMqsKNRaPtwQ)-- From arekm@risca.sse.pl Sun Aug 10 07:06:52 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Aug 2003 07:07:01 -0700 (PDT) Received: from mail.perfopol.pl (exim@perfo.perfopol.pl [213.25.186.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7AE6nFl018183 for ; Sun, 10 Aug 2003 07:06:52 -0700 Received: from amavis by mail.perfopol.pl with scanned-ok (Exim 3.36 #1) id 19lqqM-0001Xb-00 for netdev@oss.sgi.com; Sun, 10 Aug 2003 16:06:46 +0200 Received: from uucp by mail.perfopol.pl with local-rmail (Exim 3.36 #1) id 19lqqK-0001XT-00 for netdev@oss.sgi.com; Sun, 10 Aug 2003 16:06:44 +0200 Received: from arekm by risca.sse.pl with local (Exim 4.20) id 19lqDQ-0004CV-4t for netdev@oss.sgi.com; Sun, 10 Aug 2003 15:26:32 +0200 From: Arkadiusz Miskiewicz (by way of Arkadiusz Miskiewicz ) Organization: SelfOrganizing Subject: watchdog daemon causes kernel oops (2.4.18, 2.4.20, 2.4.21) Date: Sun, 10 Aug 2003 15:26:31 +0200 User-Agent: KMail/1.5.9 To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-2" Message-Id: <200308101526.31932.misiek@pld.ORG.PL> X-Virus-Scanned: by AMaViS Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7AE6nFl018183 X-archive-position: 4706 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arekm@pld-linux.org Precedence: bulk X-list: netdev Hi, I'm using watchdog daemon (ftp://ftp.debian.org/debian/pool/main/w/watchdog/watchdog_5.2.4.orig.tar.gz) . The problem is that kernels oops if watchdog is started and it uses softdog driver and then some networking operation like loading driver for network card and setting it up or doing something with nfs occurrs. If network driver is loaded before starting watchdog then everything is fine until for example rmmod network module and load it again+try to setup some ip. I've checked it on 2.4.18, 2.4.20, 2.4.21 - everywhere oops. I've also asked two other person to check this - for them it also oopses. Oppses from 2.4.21: Oops: 0002 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: d08f33a0 ebx: d08ea000 ecx: 00007123 edx: d0864020 esi: d08f02a0 edi: d08ea000 ebp: bffffe7e esp: cb77df80 ds: 0018 es: 0018 ss: 0018 Process rmmod (pid: 21701, stackpage=cb77d000) Stack: d08ea000 00000000 d08ede27 d08f02a0 c011a2b3 d08ea000 00000000 cf247000 bffffe7e c0119751 d08ea000 00000000 cb77c000 00000001 bfffecec bfffecec c010864b bffffe7e bffffd94 bfffecec 00000001 bfffecec bfffecec 00000081 Call Trace: [] [] [] [] [] Code: 89 50 04 89 02 c7 06 00 00 00 00 c7 46 04 00 00 00 00 8b 1d >>EIP; c0196687 <===== >> >>eax; d08f33a0 <[softdog].bss.end+cdd/793d> >>ebx; d08ea000 <[3c59x]__module_kernel_version+0/20> >>edx; d0864020 <[aic7xxx]aic7xxx_pci_driver+0/3f> >>esi; d08f02a0 <[3c59x]vortex_driver+0/3f> >>edi; d08ea000 <[3c59x]__module_kernel_version+0/20> >>esp; cb77df80 <___strtok+b4ad618/1053e698> Trace; d08ede27 <[3c59x]vortex_cleanup+13/25> Trace; d08f02a0 <[3c59x]vortex_driver+0/3f> Trace; c011a2b3 Trace; c0119751 Trace; c010864b <__up_wakeup+f87/1334> Code; c0196687 00000000 <_EIP>: Code; c0196687 <===== 0: 89 50 04 mov %edx,0x4(%eax) <===== Code; c019668a 3: 89 02 mov %eax,(%edx) Code; c019668c 5: c7 06 00 00 00 00 movl $0x0,(%esi) Code; c0196692 b: c7 46 04 00 00 00 00 movl $0x0,0x4(%esi) Code; c0196699 12: 8b 1d 00 00 00 00 mov 0x0,%ebx and second one Unable to handle kernel paging request at virtual address 2cd08f22 d08ed39f *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 00000802 ebx: 00000020 ecx: 00000020 edx: e40ce40e esi: ce6de400 edi: ce6de580 ebp: 0000e400 esp: ce5b5e90 ds: 0018 es: 0018 ss: 0018 Process ip (pid: 1071, stackpage=ce5b5000) Stack: 000001f0 ce6de580 00000020 00000020 01000000 ce6de478 000001f0 e40ce40e e406e40a 0000782d d08ed7da ce6de400 ce6de400 00000000 00001002 00000000 ce6de590 c01a8b19 ce6de400 ce6de400 00001003 c01a9bd5 ce6de400 ce5b5f48 Call Trace: [] [] [] [] [] [] [] [] [] Code: 66 a0 22 8f d0 2c 31 db 8a 49 28 88 4c 24 1b 8b b7 54 01 00 >>EIP; d08ed39f <[3c59x]vortex_down+47/bc> <===== >> >>esi; ce6de400 <___strtok+e40da98/1053e698> >>edi; ce6de580 <___strtok+e40dc18/1053e698> >>esp; ce5b5e90 <___strtok+e2e5528/1053e698> Trace; d08ed7da <[3c59x]netdev_ethtool_ioctl+3e/128> Trace; c01a8b19 Trace; c01a9bd5 Trace; c01dbd91 Trace; c01ddd57 Trace; c01a27f5 Trace; c0142e17 Trace; c010873c <__up_wakeup+1078/1334> Trace; c010864b <__up_wakeup+f87/1334> Code; d08ed39f <[3c59x]vortex_down+47/bc> 00000000 <_EIP>: Code; d08ed39f <[3c59x]vortex_down+47/bc> <===== 0: 66 data16 <===== Code; d08ed3a0 <[3c59x]vortex_down+48/bc> 1: a0 22 8f d0 2c mov 0x2cd08f22,%al Code; d08ed3a5 <[3c59x]vortex_down+4d/bc> 6: 31 db xor %ebx,%ebx Code; d08ed3a7 <[3c59x]vortex_down+4f/bc> 8: 8a 49 28 mov 0x28(%ecx),%cl Code; d08ed3aa <[3c59x]vortex_down+52/bc> b: 88 4c 24 1b mov %cl,0x1b(%esp,1) Code; d08ed3ae <[3c59x]vortex_down+56/bc> f: 8b b7 54 01 00 00 mov 0x154(%edi),%esi -- Arkadiusz Mi¶kiewicz CS at FoE, Wroclaw University of Technology arekm@sse.pl AM2-6BONE, 1024/3DB19BBD, arekm(at)ircnet, PLD/Linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Arkadiusz Mi¶kiewicz CS at FoE, Wroclaw University of Technology arekm@sse.pl AM2-6BONE, 1024/3DB19BBD, arekm(at)ircnet, PLD/Linux From greearb@candelatech.com Sun Aug 10 11:13:30 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Aug 2003 11:13:35 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-074.evrtwa1.dsl-verizon.net [4.33.45.74]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7AIDTFl027086 for ; Sun, 10 Aug 2003 11:13:29 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h7AIDFtf019363; Sun, 10 Aug 2003 11:13:15 -0700 Message-ID: <3F368B3A.3070009@candelatech.com> Date: Sun, 10 Aug 2003 11:13:14 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Felix Radensky CC: Robert Olsson , netdev@oss.sgi.com, "Feldman, Scott" Subject: Re: Ethernet bridge performance References: <3F3217E7.2080903@allot.com> <3F3284EA.5050406@candelatech.com> <3F328A0F.3040005@allot.com> <16178.41976.3643.584516@robur.slu.se> <3F3601F3.6000001@allot.com> In-Reply-To: <3F3601F3.6000001@allot.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4707 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Felix Radensky wrote: > I've mentioned in my first post that there are zero drops at driver level > (as shown by ifconfig). I'm also using IRQ affinity feature, binding > interrupts > of eth0 and eth1 to CPU0, so I guess NIC ring RX/TX size, link HW_FLOW > control > and affinity are not my problems. Maybe try un-binding the cpus, or binding them to different procs? > > Speaking of checksumming. This can be a problem indeed. ethtool -S shows > a lot > of rx_csum_offload errors. Scott, what could possibly be a problem ? The > NIC > is dual port 82546, driver is 5.1.13-k1. Why would a bridge be checksumming anything? > > I've failed to find a discussion about ksoftird priority. Can someone > please > provide a link. I've increased my performance by setting softirqd priority to -18, but since you seem to be dropping someplace other than the driver, I'm not sure that will help. > > Thanks a lot. > > Felix. > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From ak@suse.de Sun Aug 10 12:47:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Aug 2003 12:47:39 -0700 (PDT) Received: from Cantor.suse.de (mail.suse.de [213.95.15.193]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7AJlUFl000556 for ; Sun, 10 Aug 2003 12:47:31 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 9010F149EF; Sun, 10 Aug 2003 21:47:24 +0200 (MEST) Date: Sun, 10 Aug 2003 21:47:23 +0200 From: Andi Kleen To: Ben Greear Cc: Felix Radensky , Robert Olsson , netdev@oss.sgi.com, "Feldman, Scott" Subject: Re: Ethernet bridge performance Message-ID: <20030810194723.GA14822@wotan.suse.de> References: <3F3217E7.2080903@allot.com> <3F3284EA.5050406@candelatech.com> <3F328A0F.3040005@allot.com> <16178.41976.3643.584516@robur.slu.se> <3F3601F3.6000001@allot.com> <3F368B3A.3070009@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F368B3A.3070009@candelatech.com> X-archive-position: 4708 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev > >Speaking of checksumming. This can be a problem indeed. ethtool -S shows > >a lot > >of rx_csum_offload errors. Scott, what could possibly be a problem ? The > >NIC > >is dual port 82546, driver is 5.1.13-k1. > > Why would a bridge be checksumming anything? A NIC normally checksums every incoming packet when hardware checksumming is enabled. But of course the bridge doesn't use that information. -Andi From Robert.Olsson@data.slu.se Sun Aug 10 14:49:57 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Aug 2003 14:50:03 -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 h7ALntFl008644 for ; Sun, 10 Aug 2003 14:49:57 -0700 Received: (from robert@localhost) by robur.slu.se (8.9.3p2/8.9.3) id XAA19725; Sun, 10 Aug 2003 23:49:43 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16182.48631.720695.768876@robur.slu.se> Date: Sun, 10 Aug 2003 23:49:43 +0200 To: Felix Radensky Cc: Robert Olsson , Ben Greear , netdev@oss.sgi.com, "Feldman, Scott" Subject: Re: Ethernet bridge performance In-Reply-To: <3F3601F3.6000001@allot.com> References: <3F3217E7.2080903@allot.com> <3F3284EA.5050406@candelatech.com> <3F328A0F.3040005@allot.com> <16178.41976.3643.584516@robur.slu.se> <3F3601F3.6000001@allot.com> X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 4709 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 Felix Radensky writes: > Is slab good enough in 2.4 ? I was thinking that one of the goals > of skb-recycle patch was to avoid skb allocations and deallocations > which consume quite a lot of CPU time (as profile shows). Are you > saying that your patch is not hepling to reduce CPU load ? Try to understand why/where packets get dropped in your setup to start with. Bridging shouldn't be different from routing which I experiments with. Check /proc/interrupts, /proc/net/softnet_stat and check for drops at qdisc ( "tc -s qdisc" you might have to readd the qdisc just get the stats) Possible your TX-side cannot keep up with RX. Often the TX ring is not cleard aggressivly enough at high rates due intr. mitigation etc or possibly HW_FLOWCTRL from sink device. Disable it in your for testing. When you cure the cause in-kernel-drop you should have packets drops on the DMA-ring (in the driver) with NAPI drivers and no unnecssary skb allocation/CPU use or DMA's. > echo 1 > /proc/irq/48/smp_affinity > to avoid this kind of problem, or something else is required ? If you have both both incoming and outgoing on same CPU there will be no cache bouncing of course and a UP kernel would be faster if this all your job. Cheers. --ro From Robert.Olsson@data.slu.se Sun Aug 10 15:23:04 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Aug 2003 15:23:09 -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 h7AMN3Fl012194 for ; Sun, 10 Aug 2003 15:23:03 -0700 Received: (from robert@localhost) by robur.slu.se (8.9.3p2/8.9.3) id AAA19854; Mon, 11 Aug 2003 00:22:50 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16182.50618.69504.611254@robur.slu.se> Date: Mon, 11 Aug 2003 00:22:50 +0200 To: "Feldman, Scott" Cc: "Jeff Garzik" , "Samuel Flory" , Subject: RE: More 2.4.22pre10 ACPI breakage In-Reply-To: References: X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 4710 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 Feldman, Scott writes: > NAPI always-poll mode...that would be fun to play with... > Is this what you're thinking: 1) block any place the driver enables > interrupts so interrupts stay disabled, 2) ignore netif_rx_complete so > we stay in polling mode, 3) ignore return code from netdev->poll. > > For 1), the driver needs some way to know that we're in always-poll-mode > so enabling interrupts is a nop. > I will work but I doubt the usefulness of it as we spin aggressively even when there low or no load. This as NAPI tries to serve your dev->poll fastest possible given the fairness conditions are met. I could think of a variant... As dev->poll is callback we could possibly schedule (and delay) via a timer or something with in turn does the the schedule dev->poll for us. We have to return netif_rx_complete and have RX-buffers etc. > Just thinking out loud - haven't tried any of this. Same here... :-) Cheers. --ro From hadi@cyberus.ca Sun Aug 10 19:51:58 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Aug 2003 19:52:05 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7B2pvFl023976 for ; Sun, 10 Aug 2003 19:51:58 -0700 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.12) id 19m2mq-000JaO-00; Sun, 10 Aug 2003 22:51:56 -0400 Subject: RE: [SET 2][PATCH 2/8][bonding] Propagating master's settings to slaves From: jamal Reply-To: hadi@cyberus.ca To: "Hen, Shmulik" Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: jamalopolis Message-Id: <1060570284.1056.15.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 10 Aug 2003 22:51:25 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4711 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sat, 2003-08-09 at 06:29, Hen, Shmulik wrote: > > > > Not sure I fully understood the concerns above, but I'll try > to explain what the change was all about. > I think it wasnt the one specific change rather a few posted that i spent a minute or two staring at. And you confirm my suspicion below. [..] > > In the lonf term, the drive is to move any *smart* code done in > the config application into the driver itself and be left with > the smallest, most compact application as possible. This is the > trend we've seen in the VLAN config app, and the bridge module. > All the "brain" is in the kernel module and very little should be > done in the application. I am not very familiar with the bonding code although i think you guys have been doing very good work since you got involved. In any case the approach you state above is wrong. Actually Stephen Hemminger and I discussed this for bridging. Post 2.6 he is going to remove a lot of the bridge policy (or "brain" as you call it) out of the kernel. Netlink for kernel<->userspace not /proc. I think we should head towards that direction so we can have more sophisticated management. Thoughts? cheers, jamal From hadi@cyberus.ca Sun Aug 10 20:45:38 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 10 Aug 2003 20:45:47 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7B3jbFl024627 for ; Sun, 10 Aug 2003 20:45:38 -0700 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.12) id 19m2qu-000Jri-00; Sun, 10 Aug 2003 22:56:09 -0400 Subject: Re: Ethernet bridge performance From: jamal Reply-To: hadi@cyberus.ca To: Felix Radensky Cc: Robert Olsson , Ben Greear , netdev@oss.sgi.com In-Reply-To: <3F35F51B.7080301@allot.com> References: <3F3217E7.2080903@allot.com> <3F3284EA.5050406@candelatech.com> <3F328A0F.3040005@allot.com> <16178.41976.3643.584516@robur.slu.se> <1060284094.1024.36.camel@jzny.localdomain> <3F35F51B.7080301@allot.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1060570537.1050.17.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 10 Aug 2003 22:55:37 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4712 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Felix, Actually i based my comments on the profiles you posted ;-> Are you running any other nics? If not that profile does look strange. cheers, jamal On Sun, 2003-08-10 at 03:32, Felix Radensky wrote: > Hi, Jamal > > I guess you were not reading my first posting > very carefully :) > > 2.4.22 has NAPI capable e1000 driver and I've > compiled the driver with NAPI support. > > So running non-NAPI driver is not my problem. > > Felix. > > jamal wrote: > > Actually seems his biggest problem is he is not running > > the NAPI driver > > > > cheers, > > jamal > > > > On Thu, 2003-08-07 at 15:09, Robert Olsson wrote: > > > > > Felix Radensky writes: > > > > Thanks for your help, Ben. What is skb-recycle patch > > > > and where can I find it ? > > > > > > It's experimental and not updated for almost a year and current > > > implementation does not add anything to SMP. Got some idea how > > > to improve this... but try to keep to slab as long as possible > > > it has been improved. > > > > > > Routing/bridging on SMP has affinty problem. If you are passing > > > skb's say from eth0 to eth1 and they are bound on different CPU's > > > you get cache boucing since the TX-interrupts come on another CPU. > > > > > > In a recent test with pktgen: > > > 300 kpps with TX interrupts on same CPU as sender. > > > 198 kpps with TX intr on different CPU as sender. > > > > > > Recycling tries to address this but current implementation fails > > > as said. > > > > > > But you are probably hit by something else... Check were the drops > > > happens qdisc?. NIC ring RX/TX size, Number of interrupts. ksoftird > > > priority, link HW_FLOW control, checksumming, affinity etc. > > > > > > > > > Cheers. > > > --ro > > > > > > > > > > > > > > From Robert.Olsson@data.slu.se Mon Aug 11 00:52:56 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 00:53:05 -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 h7B7qsFl002302 for ; Mon, 11 Aug 2003 00:52:56 -0700 Received: (from robert@localhost) by robur.slu.se (8.9.3p2/8.9.3) id JAA21747; Mon, 11 Aug 2003 09:52:40 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16183.19272.107650.647577@robur.slu.se> Date: Mon, 11 Aug 2003 09:52:40 +0200 To: hadi@cyberus.ca Cc: Felix Radensky , Robert Olsson , Ben Greear , netdev@oss.sgi.com Subject: Re: Ethernet bridge performance In-Reply-To: <1060570537.1050.17.camel@jzny.localdomain> References: <3F3217E7.2080903@allot.com> <3F3284EA.5050406@candelatech.com> <3F328A0F.3040005@allot.com> <16178.41976.3643.584516@robur.slu.se> <1060284094.1024.36.camel@jzny.localdomain> <3F35F51B.7080301@allot.com> <1060570537.1050.17.camel@jzny.localdomain> X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 4713 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 jamal writes: > > Felix, > > Actually i based my comments on the profiles you posted ;-> > Are you running any other nics? If not that profile does look strange. Yes netif_rx the non-NAPI entrance to the upper layers is in the profiles. c019ad44 3404 5.3328 netif_rx Cheers. --ro From jgarzik@pobox.com Mon Aug 11 03:01:20 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 03:01:29 -0700 (PDT) Received: from www.linux.org.uk (IDENT:54dtAvtP/RiVqdP6WrDgwivooPn4OWk4@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7BA1IFl013548 for ; Mon, 11 Aug 2003 03:01:20 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19m19x-0007tc-PD; Mon, 11 Aug 2003 02:07:41 +0100 Message-ID: <3F36EC53.8040404@pobox.com> Date: Sun, 10 Aug 2003 21:07:31 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: Andi Kleen CC: netdev@oss.sgi.com Subject: Re: RFR: new SiS gige driver References: <20030808173932.GA4077@gtf.org> <20030809141533.GB4539@wotan.suse.de> <3F350CC8.3090605@pobox.com> <20030809152747.GA1618@wotan.suse.de> In-Reply-To: <20030809152747.GA1618@wotan.suse.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4714 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 Andi Kleen wrote: > The netif_wake_queue is lost. It's only deadly when clean some packets > clears the full TX ring, otherwise it will likely recover with the > next TX finished interrupt but give suboptimal performance. > > Fix is to do the my queue is full -> netif_stop_queue inside the spinlock. "a fix" not "the fix" :) You can also do what some drivers do, and move the netif_queue_stop above the queue-packet-to-hw section of driver's ->hard_start_xmit. Then when this uncommon race occurs, you are guaranteed another TX-complete interrupt, even if the queue is stopped prematurely. A lot of drivers netif_stop_queue after, not before, so this is indeed an issue that needs paying attention to. Jeff From shmulik.hen@intel.com Mon Aug 11 03:08:58 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 03:09:05 -0700 (PDT) Received: from caduceus.sc.intel.com (fmr04.intel.com [143.183.121.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7BA8vFl014346 for ; Mon, 11 Aug 2003 03:08:58 -0700 Received: from petasus.sc.intel.com (petasus.sc.intel.com [10.3.253.4]) by caduceus.sc.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 h7BA7Uk13727 for ; Mon, 11 Aug 2003 10:07:30 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.sc.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 h7BA7NT13657 for ; Mon, 11 Aug 2003 10:07:23 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.254.188]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003081103054101644 ; Mon, 11 Aug 2003 03:05:42 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Shmulik Hen Reply-To: shmulik.hen@intel.com Organization: Intel corp. To: hadi@cyberus.ca Subject: Re: [SET 2][PATCH 2/8][bonding] Propagating master's settings to slaves Date: Mon, 11 Aug 2003 13:08:48 +0300 User-Agent: KMail/1.4.3 References: <1060570284.1056.15.camel@jzny.localdomain> In-Reply-To: <1060570284.1056.15.camel@jzny.localdomain> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Message-Id: <200308111308.48263.shmulik.hen@intel.com> X-archive-position: 4715 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev On Monday 11 August 2003 05:51 am, you wrote: > On Sat, 2003-08-09 at 06:29, Hen, Shmulik wrote: > > Not sure I fully understood the concerns above, but I'll try > > to explain what the change was all about. > > I think it wasnt the one specific change rather a few posted that i > spent a minute or two staring at. And you confirm my suspicion > below. I probably didn't make myself clear - by "understood" I wanted to say I probably didn't get the *meaning* of the whole sentence , and not "I don't under stand why you are concerned". (English is not my native tongue :) ). > I am not very familiar with the bonding code although i think you > guys have been doing very good work since you got involved. > In any case the approach you state above is wrong. Actually Stephen > Hemminger and I discussed this for bridging. Post 2.6 he is going > to remove a lot of the bridge policy (or "brain" as you call it) > out of the kernel. Netlink for kernel<->userspace not /proc. I > think we should head towards that direction so we can have more > sophisticated management. I, on the other hand, am not familiar with the bridging code and I don't know what it actually does internally, I just noticed that regarding config operations, most of the code is done at the kernel level as response to ioctl commands. I'll try to clarify how that relates to bonding. The ifenslave utility has very little "brain" as it is, and all it knows how to do currently is enslave/release slave devices and change the current active slave. It also has some ability to extract status info from the bond and present it nicely for a user. The "brain" I was referring to in the bonding module itself has to do with timer functions monitoring link status or Tx/Rx activity of the slaves, and once a faulty slave is detected, switch to use another one instead according to the teaming mode. There are no large scale decision making nor major CPU consuming computations that are part of the continuous operation of the module that is basically handle Rx/Tx on slaves. The bonding module doesn't need to access any special info that is normally available to user space apps. What it does need is very short response time and accessibility to kernel internal resources like net devices info to make it a high availability intermediate driver. Trying to move that from the kernel module into the config application seems to be a very hard task to implement since we'll have to find a way to make the application constantly aware to the specifics like current topology, slave-to-bond affiliation, updated status of each slave, etc., etc. It would also mean that the driver will have to wait for the application to tell it what to do each time it needs a decision, and by that we'll surely suffer some performance hit and probably get low availability or temporary loss of communications. Going back to the first problem, discussions on the bonding development list pointed that it might be better if we moved the configuration-time decisions making to the driver, so the application wouldn't have to deal with situations like: 1) get the master's MTU settings, master's teaming mode, communication version, backwards compatibility issues, etc. 2) figure if need to set MTU to slave according to all that, 3) try to set that on the new slave being added, 4) if not successfull, decide if may enslave anyway or, 5) maybe undo all previous settings already done to the slave (needs a way to retrieve old values) 6) decide if should go on or fail any further operations 7) repeat the above for all other settings On the other hand, what we want to get to is something more like: 1) tell bonding to add slave X to bond Y, 2) watch for error returns, 3) print a nice message according to the type of the error. While the driver, already aware of all possible relevant data, makes all decisions, performs settings, handles compatibility issues, checks for failures at each stage, handles any undo steps, and return success/error values accordingly. > > Thoughts? Mostly explanations :) Is there anywhere I can see what you refereed to as discussions with Stephen Hemminger ? I would really like to know how and what could also be applied to bonding. Regards, Shmulik. From laurent.deniel@thalesatm.com Mon Aug 11 07:08:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 07:08:06 -0700 (PDT) Received: from gwsmtp.thomson-csf.com (gwsmtp.thomson-csf.com [195.101.39.226]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7BE7vFl002473 for ; Mon, 11 Aug 2003 07:07:59 -0700 Received: from thalescan.corp.thales (200.3.2.3) by gwsmtp.thomson-csf.com (NPlex 6.5.026) id 3F3761E40000A8E8 for netdev@oss.sgi.com; Mon, 11 Aug 2003 16:07:51 +0200 Received: from bgxplex.bgx.airsys.thomson-csf.com ([220.1.107.25]) by thalescan with InterScan Messaging Security Suite; Mon, 11 Aug 2003 16:07:45 +0200 Received: from bgxplex2.bgx.airsys.thomson-csf.com (1.38.9.152) by bgxplex.bgx.airsys.thomson-csf.com (NPlex 6.5.026) id 3F15565F0003ACC2; Mon, 11 Aug 2003 16:07:58 +0200 Received: from bgxplex2.bgx.airsys.thomson-csf.com (1.38.9.152) by bgxplex2.bgx.airsys.thomson-csf.com (NPlex 6.5.026) id 3F370B62000016DA; Mon, 11 Aug 2003 16:07:45 +0200 Received: from 200.64.130.8 by bgxplex2.bgx.airsys.thomson-csf.com (InterScan E-Mail VirusWall NT); Mon, 11 Aug 2003 16:07:45 +0200 Message-ID: <3F37A331.88EB0B1D@thalesatm.com> Date: Mon, 11 Aug 2003 16:07:45 +0200 From: Laurent DENIEL Organization: THALES ATM X-Mailer: Mozilla 4.75 [fr] (Windows NT 5.0; U) X-Accept-Language: fr,en-GB MIME-Version: 1.0 To: hadi@cyberus.ca CC: shmulik.hen@intel.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master's settings toslaves References: <1060570284.1056.15.camel@jzny.localdomain> <200308111308.48263.shmulik.hen@intel.com> <1060607079.1050.144.camel@jzny.localdomain> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by oss.sgi.com id h7BE7vFl002473 X-archive-position: 4716 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laurent.deniel@thalesatm.com Precedence: bulk X-list: netdev jamal a écrit : > > > Trying to move that from the kernel module into the config application > > seems to be a very hard task to implement since we'll have to find a > > way to make the application constantly aware to the specifics like > > current topology, slave-to-bond affiliation, updated status of each > > slave, etc., etc. It would also mean that the driver will have to > > wait for the application to tell it what to do each time it needs a > > decision, and by that we'll surely suffer some performance hit and > > probably get low availability or temporary loss of communications. > > > > Not at all. If you let some app control this i am sure whoever writes > the app has vested interest in getting fast failovers etc. > > > Basically what i described at the top. Move any "richness" to user > space. HP/Compaq/Digital used to have the same approach with their Netrain implementation, and from one release of Tru64 UNIX to another, they could no longer support resolution ala milli-seconds but only seconds due to the move of such "richness" to user space (among other things). I am not saying that doing so on Linux will result to the same, but a minimal failover policy shall remain in the kernel for performance reason ... (or a user space facility could exist to *configure* such policy but without direct interaction with user space when the kernel has to decide). Laurent From shmulik.hen@intel.com Mon Aug 11 07:20:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 07:20:58 -0700 (PDT) Received: from caduceus.sc.intel.com (fmr04.intel.com [143.183.121.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7BEKlFl003456 for ; Mon, 11 Aug 2003 07:20:48 -0700 Received: from petasus.sc.intel.com (petasus.sc.intel.com [10.3.253.4]) by caduceus.sc.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 h7BEJL807844 for ; Mon, 11 Aug 2003 14:19:21 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.sc.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 h7BEJEa14666 for ; Mon, 11 Aug 2003 14:19:14 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.254.188]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003081107173124813 ; Mon, 11 Aug 2003 07:17:32 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Shmulik Hen Reply-To: shmulik.hen@intel.com Organization: Intel corp. To: Laurent DENIEL , hadi@cyberus.ca Subject: Re: [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master's settings toslaves Date: Mon, 11 Aug 2003 17:20:38 +0300 User-Agent: KMail/1.4.3 Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com References: <1060607079.1050.144.camel@jzny.localdomain> <3F37A331.88EB0B1D@thalesatm.com> In-Reply-To: <3F37A331.88EB0B1D@thalesatm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200308111720.38472.shmulik.hen@intel.com> X-archive-position: 4717 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev On Monday 11 August 2003 05:07 pm, Laurent DENIEL wrote: > HP/Compaq/Digital used to have the same approach with their Netrain > implementation, and from one release of Tru64 UNIX to another, they > could no longer support resolution ala milli-seconds but only > seconds due to the move of such "richness" to user space (among > other things). I am not saying that doing so on Linux will result > to the same, but a minimal failover policy shall remain in the > kernel for performance reason ... (or a user space facility could > exist to *configure* such policy but without direct interaction > with user space when the kernel has to decide). > > Laurent That was my point. Thank you for putting it into better words. If high availbilty and fast failovers are what's needed, why move it out of kernel space and put it in an application ? How fast could it work compared to a kernel module ? Why need an extra piece of code running in user space (daemon?) to monitor a module when the module can do that itself ? If smarter behavior is needed (e.g. falling to eth4 instead of eth1 when eth0 fails), we can add some priority mechanism to the driver to do that when it decides to swap. Otherwise, we'll be devleoping applications from now on, not the Linux kernel :) Shmulik. From hadi@cyberus.ca Mon Aug 11 07:34:43 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 07:34:51 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7BEYgFl004672 for ; Mon, 11 Aug 2003 07:34:43 -0700 Received: from [216.209.86.2] (helo=[10.0.0.9] ident=jamal) by mail.cyberus.ca with esmtp (Exim 4.12) id 19mDkw-000JoR-00; Mon, 11 Aug 2003 10:34:42 -0400 Subject: Re: [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master's settings toslaves From: jamal Reply-To: hadi@cyberus.ca To: shmulik.hen@intel.com Cc: Laurent DENIEL , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: <200308111720.38472.shmulik.hen@intel.com> References: <1060607079.1050.144.camel@jzny.localdomain> <3F37A331.88EB0B1D@thalesatm.com> <200308111720.38472.shmulik.hen@intel.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1060612481.1034.15.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Aug 2003 10:34:41 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4718 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Mon, 2003-08-11 at 10:20, Shmulik Hen wrote: > On Monday 11 August 2003 05:07 pm, Laurent DENIEL wrote: > > HP/Compaq/Digital used to have the same approach with their Netrain > > implementation, and from one release of Tru64 UNIX to another, they > > could no longer support resolution ala milli-seconds but only > > seconds due to the move of such "richness" to user space (among > > other things). I am not saying that doing so on Linux will result > > to the same, but a minimal failover policy shall remain in the > > kernel for performance reason ... (or a user space facility could > > exist to *configure* such policy but without direct interaction > > with user space when the kernel has to decide). > > > > Laurent > > That was my point. Thank you for putting it into better words. > If high availbilty and fast failovers are what's needed, why move it > out of kernel space and put it in an application ? How fast could it > work compared to a kernel module ? Why need an extra piece of code > running in user space (daemon?) to monitor a module when the module > can do that itself ? > > If smarter behavior is needed (e.g. falling to eth4 instead of eth1 > when eth0 fails), we can add some priority mechanism to the driver to > do that when it decides to swap. Otherwise, we'll be devleoping > applications from now on, not the Linux kernel :) > So how many smart things are you going to add to the driver? ;-> Do you wanna add the qos policy changeover as well? What about route changes, firewalling etc. What about sliceing bread and adding butter? Where do you draw the line? BTW, I dont understand why it would slow down failover; sure it will a tiny bit because you have to cross user space to lookup the policy. Maybe this is the part that i havent made clear, heres an example: - User space gets notified link eth0 went down - User space looks up a policy config on what to do when eth0 goes down - user space executes commands which may include telling kernel to move activity to eth1. Note: I agree on a minimal failover policy staying in the kernel; very basic stuff like what bonding used to do (may still do, dont know). cheers, jamal From matthew.hare@amsjv.com Mon Aug 11 09:17:30 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 09:17:34 -0700 (PDT) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.138.254.62]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7BGHQFl011780 for ; Mon, 11 Aug 2003 09:17:30 -0700 Received: from ngbaux (ngbaux.msd.bae.co.uk [141.245.68.234]) by smtp2.bae.co.uk (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7BGHHr06783 for ; Mon, 11 Aug 2003 17:17:17 +0100 (BST) Received: from ngban8.ng.bae.co.uk ([141.245.68.229]) by ngbaux.net.bae.co.uk (PMDF V5.2-33 #44998) with ESMTP id <0HJG006ITQJOQD@ngbaux.net.bae.co.uk> for netdev@oss.sgi.com; Mon, 11 Aug 2003 17:16:38 +0100 (BST) Received: from dsnmtrs1.nm.ds.bae.co.uk (unverified) by ngban8.ng.bae.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Mon, 11 Aug 2003 17:17:02 +0100 Received: from nmtr01.nm.dsx.bae.co.uk (jupiter [172.30.192.21]) by dsnmtrs1.nm.ds.bae.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3G131QDH; Mon, 11 Aug 2003 17:17:03 +0100 Received: by nmtr01.nm.dsx.bae.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Aug 2003 17:23:51 +0100 Date: Mon, 11 Aug 2003 17:22:04 +0100 From: "Hare, Matthew" Subject: TCP/IP Window Size Problem/Query To: "'davem@redhat.com'" , "'ak@muc.de'" , "'kuznet@ms2.inr.ac.ru'" , "'netdev@oss.sgi.com'" Message-id: <3E28BEE03F7CD3118E540008C7F35FF602C7AFAB@NMEX01> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; charset="iso-8859-1" X-archive-position: 4719 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: matthew.hare@amsjv.com Precedence: bulk X-list: netdev Forgive this mass mailing out but I am getting desperate for help. My problem is with reported TCP window sizes. I have two systems running SuSE Linux. System 1 is running SuSE 7.1 with the 2.2.18 kernel. System 2 is running SuSE 7.3 with the 2.4.17 kernel. Both systems are PC based (Pentium III, 512MB RAM). When I open a TCP connection from System 1 I get a reported window size (I use Ethereal to check window sizes) of 32k. When I do the same with System 2 I get a reported window size of 5840bytes and the window size increases as the rate of data being sent via TCP increases. This is causing me problems, I need a fixed window size of 32k on System 2 so that it matches System 1. I have done a bit of testing to try and work out where this window size is set. I am by no means a Linux guru so I was working with little knowledge at the start. The application we use to open the TCP connections is our own code (C++) so I have hacked that and used some setsockopt() calls to set SO_SNDBUF. I tried setting this to 32k but this appears to have no effect on my reported window sizes. Does anyone know if setsockopt() can be used to change the size of the window I am seeing? Is SO_SNDBUF the same as the TCP window size that Ethereal is reporting? Is there a way to fix the TCP window size in the 2.4.17 kernel? I am familiar with recompiling the kernel but I've not found any kernel options that seem to do what I want. Can anyone help me or at least point me in the right direction? Thanks for your time. Mat Hare SAINTT Developer AMS UK ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From hadi@cyberus.ca Mon Aug 11 09:19:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 09:19:51 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7BGJiFl012240 for ; Mon, 11 Aug 2003 09:19:44 -0700 Received: from [216.209.86.2] (helo=[10.0.0.9] ident=jamal) by mail.cyberus.ca with esmtp (Exim 4.12) id 19mD1Q-000E4B-00; Mon, 11 Aug 2003 09:47:41 -0400 Subject: Re: [SET 2][PATCH 2/8][bonding] Propagating master's settings to slaves From: jamal Reply-To: hadi@cyberus.ca To: shmulik.hen@intel.com Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: <200308111308.48263.shmulik.hen@intel.com> References: <1060570284.1056.15.camel@jzny.localdomain> <200308111308.48263.shmulik.hen@intel.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1060607079.1050.144.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Aug 2003 09:47:39 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4720 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Mon, 2003-08-11 at 06:08, Shmulik Hen wrote: > On Monday 11 August 2003 05:51 am, you wrote: > > On Sat, 2003-08-09 at 06:29, Hen, Shmulik wrote: > > > Not sure I fully understood the concerns above, but I'll try > > > to explain what the change was all about. > > > > I think it wasnt the one specific change rather a few posted that i > > spent a minute or two staring at. And you confirm my suspicion > > below. > > I probably didn't make myself clear - by "understood" I wanted to say > I probably didn't get the *meaning* of the whole sentence , and not > "I don't under stand why you are concerned". > (English is not my native tongue :) ). > > > I am not very familiar with the bonding code although i think you > > guys have been doing very good work since you got involved. > > In any case the approach you state above is wrong. Actually Stephen > > Hemminger and I discussed this for bridging. Post 2.6 he is going > > to remove a lot of the bridge policy (or "brain" as you call it) > > out of the kernel. Netlink for kernel<->userspace not /proc. I > > think we should head towards that direction so we can have more > > sophisticated management. > > I, on the other hand, am not familiar with the bridging code and I > don't know what it actually does internally, I just noticed that > regarding config operations, most of the code is done at the kernel > level as response to ioctl commands. > Theres two main components to it: a control protocol and a forwarding path. The control protocol known as STP tells the forwarding path how to behave. Essentially, STP carries the policy implemented by the forwarding path. This is the same breakdown to say routing protocols like OSPF and regular forwarding path. At the moment STP sits in the kernel. STP is really the "brains". > I'll try to clarify how that relates to bonding. The ifenslave utility > has very little "brain" as it is, and all it knows how to do > currently is enslave/release slave devices and change the current > active slave. It also has some ability to extract status info from > the bond and present it nicely for a user. > > The "brain" I was referring to in the bonding module itself has to do > with timer functions monitoring link status or Tx/Rx activity of the > slaves, and once a faulty slave is detected, switch to use another > one instead according to the teaming mode. > There are no large scale > decision making nor major CPU consuming computations that are part of > the continuous operation of the module that is basically handle Rx/Tx > on slaves. > > The bonding module doesn't need to access any special info that is > normally available to user space apps. What it does need is very > short response time and accessibility to kernel internal resources > like net devices info to make it a high availability intermediate > driver. > > Trying to move that from the kernel module into the config application > seems to be a very hard task to implement since we'll have to find a > way to make the application constantly aware to the specifics like > current topology, slave-to-bond affiliation, updated status of each > slave, etc., etc. It would also mean that the driver will have to > wait for the application to tell it what to do each time it needs a > decision, and by that we'll surely suffer some performance hit and > probably get low availability or temporary loss of communications. > Not at all. If you let some app control this i am sure whoever writes the app has vested interest in getting fast failovers etc. > Going back to the first problem, discussions on the bonding > development list pointed that it might be better if we moved the > configuration-time decisions making to the driver, so the application > wouldn't have to deal with situations like: > 1) get the master's MTU settings, master's teaming mode, communication > version, backwards compatibility issues, etc. > 2) figure if need to set MTU to slave according to all that, > 3) try to set that on the new slave being added, > 4) if not successfull, decide if may enslave anyway or, > 5) maybe undo all previous settings already done to the slave > (needs a way to retrieve old values) > 6) decide if should go on or fail any further operations > 7) repeat the above for all other settings > > On the other hand, what we want to get to is something more like: > 1) tell bonding to add slave X to bond Y, > 2) watch for error returns, > 3) print a nice message according to the type of the error. > Dont you think that anything thats "rich" like you list above should stay out of the kernel? In any case, if you have a controlling app, you could do more interesting things; example add or delete routes, firewall rules, qos policies etc which all have very strong correlation with availability - these are examples btw, not an exhaustive list. If all you are satisfied with is link management alone, then by all means hardcoding behavior into the kernel is fine. I dont think it is sufficient. > While the driver, already aware of all possible relevant data, makes > all decisions, performs settings, handles compatibility issues, > checks for failures at each stage, handles any undo steps, and return > success/error values accordingly. > Driver - actually bonding - should have minimal failover policy built in for the lazy; example what i used to know about bonding - failover to the next link, maybe send a grat arp etc. If I want more than basic, then send me netlink events to user space and let me control how it goes. Maybe i dont want to go to the second link but rather the 4th link. > > > > Thoughts? > > Mostly explanations :) > > Is there anywhere I can see what you refereed to as discussions with > Stephen Hemminger ? I would really like to know how and what could > also be applied to bonding. > Basically what i described at the top. Move any "richness" to user space. cheers, jamal From shmulik.hen@intel.com Mon Aug 11 09:25:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 09:25:56 -0700 (PDT) Received: from hermes-pilot.fm.intel.com (fmr99.intel.com [192.55.52.32]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7BGPmFl012927 for ; Mon, 11 Aug 2003 09:25:49 -0700 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes-pilot.fm.intel.com (8.12.9/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h7BGKs14016460 for ; Mon, 11 Aug 2003 16:20:54 GMT Received: from fmsmsxv040-1.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108]) by petasus.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h7BGIEG10949 for ; Mon, 11 Aug 2003 16:18:14 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.254.188]) by fmsmsxv040-1.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003081109244309038 ; Mon, 11 Aug 2003 09:24:44 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Shmulik Hen Reply-To: shmulik.hen@intel.com Organization: Intel corp. To: hadi@cyberus.ca Subject: Re: [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master's settings toslaves Date: Mon, 11 Aug 2003 19:25:38 +0300 User-Agent: KMail/1.4.3 Cc: Laurent DENIEL , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com References: <200308111720.38472.shmulik.hen@intel.com> <1060612481.1034.15.camel@jzny.localdomain> In-Reply-To: <1060612481.1034.15.camel@jzny.localdomain> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200308111925.38278.shmulik.hen@intel.com> X-archive-position: 4721 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev On Monday 11 August 2003 05:34 pm, jamal wrote: > So how many smart things are you going to add to the driver? ;-> > Do you wanna add the qos policy changeover as well? What about > route changes, firewalling etc. What about sliceing bread and > adding butter? Where do you draw the line? > BTW, I dont understand why it would slow down failover; sure it > will a tiny bit because you have to cross user space to lookup the > policy. Maybe this is the part that i havent made clear, heres an > example: - User space gets notified link eth0 went down > - User space looks up a policy config on what to do when eth0 goes > down - user space executes commands which may include telling > kernel to move activity to eth1. > > Note: I agree on a minimal failover policy staying in the kernel; > very basic stuff like what bonding used to do (may still do, dont > know). > > cheers, > jamal Why have any kernel code other than device drivers in the first place ? Why not move all the TCP/IP stack out of kernel space and put it in an application ? Lets have the entire ARP mechanism in an appliaction and let it handle everything from routing tables management to arp negotiation while the kernel will only know how to create arp packets that it gets from that app and send them away ? It doesn't need to have the know how. Say we do thing s your way and use the notification mechanism, how long do you think it's going to take for the whole operation to finish taking into consideration how the kernel runs user space applications in comparison with kernel code? what happens when the system is heavily loaded ? What happens if the application dies for some reason ? Why should the bonding driver even care about routes or firewalling ? It's only meant to group several physical ethernet devices and group them under one logical device to handle teaming solutions. -- | Shmulik Hen Advanced Network Services | | Israel Design Center, Jerusalem | | LAN Access Division, Platform Networking | | Intel Communications Group, Intel corp. | From jgarzik@pobox.com Mon Aug 11 09:44:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 09:44:08 -0700 (PDT) Received: from www.linux.org.uk (IDENT:FMFX82S5sRmm6CLXA6TgyC8iPBP2Kvzd@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7BGi0Fl014519 for ; Mon, 11 Aug 2003 09:44:01 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19mFm2-0003Ki-By; Mon, 11 Aug 2003 17:43:58 +0100 Message-ID: <3F37C7C3.7070807@pobox.com> Date: Mon, 11 Aug 2003 12:43:47 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: shmulik.hen@intel.com, hadi@cyberus.ca CC: Laurent DENIEL , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master's settings toslaves References: <200308111720.38472.shmulik.hen@intel.com> <1060612481.1034.15.camel@jzny.localdomain> <200308111925.38278.shmulik.hen@intel.com> In-Reply-To: <200308111925.38278.shmulik.hen@intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4722 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev The answer is, like life, it's a balance. As a general rule, we do prefer to move all code possible out of the Linux kernel. We have even created "initramfs", which for 2.7, will be used as a vehicle to move code from the kernel to userspace, that previously had to be in the kernel only because it was a task that "had to be performed at boot time". However, one must consider (1) does moving code to userspace create any security holes? (2) does moving code to userspace dramatically increase the number of context switches? (3) does moving code to userspace violate some atomicity that being inside the kernel guarantees? In practice, #3 is the showstopper that occurs most often. This is why I push for a "bonding-utils" package from Jay.... because of the general rule above: put it into userspace, where possible. Jeff From davej@codemonkey.org.uk Mon Aug 11 09:49:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 09:49:35 -0700 (PDT) Received: from lacrosse.corp.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7BGnRFl016954 for ; Mon, 11 Aug 2003 09:49:28 -0700 Received: from tetrachloride (davej.cipe.redhat.com [10.0.1.164]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h7BGnQK22583 for ; Mon, 11 Aug 2003 12:49:26 -0400 Received: from davej by tetrachloride with local (Exim 3.36 #1 (Debian)) id 19mFqr-00068W-00 for ; Mon, 11 Aug 2003 17:48:57 +0100 To: netdev@oss.sgi.com From: davej@redhat.com Subject: [PATCH] Duplicate access_ok in sunrpc Message-Id: Date: Mon, 11 Aug 2003 17:48:57 +0100 X-archive-position: 4723 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davej@redhat.com Precedence: bulk X-list: netdev Already checked some lines above. diff -urpN --exclude-from=/home/davej/.exclude bk-linus/net/sunrpc/sysctl.c linux-2.5/net/sunrpc/sysctl.c --- bk-linus/net/sunrpc/sysctl.c 2003-06-30 14:01:04.000000000 +0100 +++ linux-2.5/net/sunrpc/sysctl.c 2003-06-30 16:04:03.000000000 +0100 @@ -102,7 +102,7 @@ proc_dodebug(ctl_table *table, int write len = sprintf(tmpbuf, "%d", *(unsigned int *) table->data); if (len > left) len = left; - copy_to_user(buffer, tmpbuf, len); + __copy_to_user(buffer, tmpbuf, len); if ((left -= len) > 0) { put_user('\n', (char *)buffer + len); left--; From davej@codemonkey.org.uk Mon Aug 11 09:49:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 09:49:35 -0700 (PDT) Received: from lacrosse.corp.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7BGnRFl016953 for ; Mon, 11 Aug 2003 09:49:28 -0700 Received: from tetrachloride (davej.cipe.redhat.com [10.0.1.164]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h7BGnQK22570 for ; Mon, 11 Aug 2003 12:49:26 -0400 Received: from davej by tetrachloride with local (Exim 3.36 #1 (Debian)) id 19mFqr-00068Q-00 for ; Mon, 11 Aug 2003 17:48:57 +0100 To: netdev@oss.sgi.com From: davej@redhat.com Subject: [PATCH] ipv4 reuses freed mem Message-Id: Date: Mon, 11 Aug 2003 17:48:57 +0100 X-archive-position: 4723 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davej@redhat.com Precedence: bulk X-list: netdev cat /proc/net/pnp will return garbage, as the fields it dumps are initdata. diff -urpN --exclude-from=/home/davej/.exclude bk-linus/net/ipv4/ipconfig.c linux-2.5/net/ipv4/ipconfig.c --- bk-linus/net/ipv4/ipconfig.c 2003-07-10 01:02:21.000000000 +0100 +++ linux-2.5/net/ipv4/ipconfig.c 2003-08-09 16:08:13.000000000 +0100 @@ -125,14 +125,14 @@ int ic_proto_enabled __initdata = 0 int ic_host_name_set __initdata = 0; /* Host name set by us? */ -u32 ic_myaddr __initdata = INADDR_NONE; /* My IP address */ -u32 ic_netmask __initdata = INADDR_NONE; /* Netmask for local subnet */ -u32 ic_gateway __initdata = INADDR_NONE; /* Gateway IP address */ +u32 ic_myaddr = INADDR_NONE; /* My IP address */ +u32 ic_netmask = INADDR_NONE; /* Netmask for local subnet */ +u32 ic_gateway = INADDR_NONE; /* Gateway IP address */ -u32 ic_servaddr __initdata = INADDR_NONE; /* Boot server IP address */ +u32 ic_servaddr = INADDR_NONE; /* Boot server IP address */ -u32 root_server_addr __initdata = INADDR_NONE; /* Address of NFS server */ -u8 root_server_path[256] __initdata = { 0, }; /* Path to mount as root */ +u32 root_server_addr = INADDR_NONE; /* Address of NFS server */ +u8 root_server_path[256] = { 0, }; /* Path to mount as root */ /* Persistent data: */ From davej@codemonkey.org.uk Mon Aug 11 09:49:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 09:49:35 -0700 (PDT) Received: from lacrosse.corp.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7BGnRFl016952 for ; Mon, 11 Aug 2003 09:49:28 -0700 Received: from tetrachloride (davej.cipe.redhat.com [10.0.1.164]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h7BGnQK22573 for ; Mon, 11 Aug 2003 12:49:26 -0400 Received: from davej by tetrachloride with local (Exim 3.36 #1 (Debian)) id 19mFqr-00068T-00 for ; Mon, 11 Aug 2003 17:48:57 +0100 To: netdev@oss.sgi.com From: davej@redhat.com Subject: [PATCH] Missing break in switch statement. Message-Id: Date: Mon, 11 Aug 2003 17:48:57 +0100 X-archive-position: 4724 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davej@redhat.com Precedence: bulk X-list: netdev Is this intentional? It should at least have a /* FALLTHROUGH */ or similar if so. Dave diff -urpN --exclude-from=/home/davej/.exclude bk-linus/net/ipv6/raw.c linux-2.5/net/ipv6/raw.c --- bk-linus/net/ipv6/raw.c 2003-07-11 13:57:41.000000000 +0100 +++ linux-2.5/net/ipv6/raw.c 2003-07-11 14:08:05.000000000 +0100 @@ -833,6 +833,7 @@ static int rawv6_getsockopt(struct sock val = -1; else val = opt->offset; + break; default: return -ENOPROTOOPT; From yoshfuji@hongo.wide.ad.jp Mon Aug 11 10:14:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 10:14:20 -0700 (PDT) Received: from linux6.nezu.wide.ad.jp (linux6.nezu.wide.ad.jp [203.178.142.218]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7BHEFFl022424 for ; Mon, 11 Aug 2003 10:14:17 -0700 Received: from localhost (localhost [127.0.0.1]) by linux6.nezu.wide.ad.jp (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7BHEEAn001729; Tue, 12 Aug 2003 02:14:14 +0900 Date: Tue, 12 Aug 2003 02:14:14 +0900 (JST) Message-Id: <20030812.021414.128414948.yoshfuji@hongo.wide.ad.jp> To: davem@redhat.com, davej@redhat.com Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] Missing break in switch statement. From: YOSHIFUJI Hideaki In-Reply-To: References: X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4725 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@hongo.wide.ad.jp Precedence: bulk X-list: netdev In article (at Mon, 11 Aug 2003 17:48:57 +0100), davej@redhat.com says: > Is this intentional? It should at least have a > /* FALLTHROUGH */ or similar if so. Of course not. > else > val = opt->offset; > + break; > > default: > return -ENOPROTOOPT; agreed. --yoshfuji From laurent.deniel@thalesatm.com Mon Aug 11 10:31:38 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 10:31:43 -0700 (PDT) Received: from gwsmtp.thomson-csf.com (gwsmtp.thomson-csf.com [195.101.39.226]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7BHVaFl023827 for ; Mon, 11 Aug 2003 10:31:38 -0700 Received: from thalescan.corp.thales (200.3.2.3) by gwsmtp.thomson-csf.com (NPlex 6.5.026) id 3F3761E40000FCA0 for netdev@oss.sgi.com; Mon, 11 Aug 2003 19:31:31 +0200 Received: from bgxplex.bgx.airsys.thomson-csf.com ([220.1.107.25]) by thalescan with InterScan Messaging Security Suite; Mon, 11 Aug 2003 19:31:26 +0200 Received: from bgxplex2.bgx.airsys.thomson-csf.com (1.38.9.152) by bgxplex.bgx.airsys.thomson-csf.com (NPlex 6.5.026) id 3F15565F0003B327; Mon, 11 Aug 2003 19:31:39 +0200 Received: from bgxplex2.bgx.airsys.thomson-csf.com (1.38.9.152) by bgxplex2.bgx.airsys.thomson-csf.com (NPlex 6.5.026) id 3F370B6200001C1F; Mon, 11 Aug 2003 19:31:26 +0200 Received: from 200.64.130.8 by bgxplex2.bgx.airsys.thomson-csf.com (InterScan E-Mail VirusWall NT); Mon, 11 Aug 2003 19:31:26 +0200 Message-ID: <3F37D2ED.B4B9223C@thalesatm.com> Date: Mon, 11 Aug 2003 19:31:25 +0200 From: Laurent DENIEL Organization: THALES ATM X-Mailer: Mozilla 4.75 [fr] (Windows NT 5.0; U) X-Accept-Language: fr,en-GB MIME-Version: 1.0 To: Jeff Garzik CC: shmulik.hen@intel.com, hadi@cyberus.ca, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master'ssettings toslaves References: <200308111720.38472.shmulik.hen@intel.com> <1060612481.1034.15.camel@jzny.localdomain> <200308111925.38278.shmulik.hen@intel.com> <3F37C7C3.7070807@pobox.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by oss.sgi.com id h7BHVaFl023827 X-archive-position: 4726 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laurent.deniel@thalesatm.com Precedence: bulk X-list: netdev Jeff Garzik a écrit : > > The answer is, like life, it's a balance. > > As a general rule, we do prefer to move all code possible out of the > Linux kernel. We have even created "initramfs", which for 2.7, will be > used as a vehicle to move code from the kernel to userspace, that > previously had to be in the kernel only because it was a task that "had > to be performed at boot time". > > However, one must consider > (1) does moving code to userspace create any security holes? > (2) does moving code to userspace dramatically increase the number of > context switches? > (3) does moving code to userspace violate some atomicity that being > inside the kernel guarantees? You forgot one important aspect : (4) does moving code to userspace break compatibility (or behavior) with user land applications (or systems) What can one do if say, kernel 2.[4|5] switches the NIC in 10 mseconds while kernel 2.7 with user land daemon switches in a few seconds ? nothing but stay with the previous version or fork the driver development ;-( But I agree that it is interesting to do some stuff at user land, and if the bonding had an option to disable the automatic failover policy, this could be implemented with trigger towards user land application that could use an ioctl call to switch to the appropriate NIC according to the user lan configuration ... But the fast and simple failover policy shall remain in kernel code. Laurent From jgarzik@pobox.com Mon Aug 11 10:43:43 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 10:43:54 -0700 (PDT) Received: from www.linux.org.uk (IDENT:0JIazgH4OLXAUw9cDLemfpgzTPTBra1l@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7BHhfFl024883 for ; Mon, 11 Aug 2003 10:43:42 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19mGhn-00047P-36; Mon, 11 Aug 2003 18:43:39 +0100 Message-ID: <3F37D5BF.8000702@pobox.com> Date: Mon, 11 Aug 2003 13:43:27 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: Laurent DENIEL CC: shmulik.hen@intel.com, hadi@cyberus.ca, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master'ssettings toslaves References: <200308111720.38472.shmulik.hen@intel.com> <1060612481.1034.15.camel@jzny.localdomain> <200308111925.38278.shmulik.hen@intel.com> <3F37C7C3.7070807@pobox.com> <3F37D2ED.B4B9223C@thalesatm.com> In-Reply-To: <3F37D2ED.B4B9223C@thalesatm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 4727 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 Laurent DENIEL wrote: > Jeff Garzik a écrit : > >>The answer is, like life, it's a balance. >> >>As a general rule, we do prefer to move all code possible out of the >>Linux kernel. We have even created "initramfs", which for 2.7, will be >>used as a vehicle to move code from the kernel to userspace, that >>previously had to be in the kernel only because it was a task that "had >>to be performed at boot time". >> >>However, one must consider >>(1) does moving code to userspace create any security holes? >>(2) does moving code to userspace dramatically increase the number of >>context switches? >>(3) does moving code to userspace violate some atomicity that being >>inside the kernel guarantees? > > > You forgot one important aspect : > > (4) does moving code to userspace break compatibility (or behavior) > with user land applications (or systems) I agree... assuming these userland interfaces are fairly standard and widely deployed. > What can one do if say, kernel 2.[4|5] switches the NIC in 10 mseconds > while kernel 2.7 with user land daemon switches in a few seconds ? > nothing but stay with the previous version or fork the driver development ;-( This is a silly example. If that happens in practice, then that is a bug in the configuration of the userland daemon, or a bug in the kernel<->userland ABI. > But I agree that it is interesting to do some stuff at user land, and if > the bonding had an option to disable the automatic failover policy, > this could be implemented with trigger towards user land application that > could use an ioctl call to switch to the appropriate NIC according to > the user lan configuration ... Remember, ioctls are bad. :) Unix design mistake. > But the fast and simple failover policy shall remain in kernel code. I would not make such absolute predictions, especially about policy :) Jeff From shemminger@osdl.org Mon Aug 11 11:48:55 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 11:49:04 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7BImsFl027380 for ; Mon, 11 Aug 2003 11:48:55 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7BImVo27603; Mon, 11 Aug 2003 11:48:31 -0700 Date: Mon, 11 Aug 2003 11:48:23 -0700 From: Stephen Hemminger To: chas williams , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [RFT][PATCH] cleanup net/atm/br2684.c Message-Id: <20030811114823.5b81474c.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4728 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev I fixed up some things in br2684 but don't have ATM hardware to test it well enough. The patch is against 2.6.0-test3 and module loads/unloads fine. Fixed: - Allocate network device with alloc_netdev and embed private data via dev->priv. This allows for future fix of rmmod race with sysfs. - Get rid of all the MOD_INC stuff. MOD_INC is not a spinlock or semaphore and don't use it like that! Have driver clean itself up properly on unload. - Add required owner field for /proc interface. Thought about converting to seq_file, but existing output format and ordering makes that hard. diff -Nru a/net/atm/br2684.c b/net/atm/br2684.c --- a/net/atm/br2684.c Mon Aug 11 11:42:19 2003 +++ b/net/atm/br2684.c Mon Aug 11 11:42:19 2003 @@ -81,7 +81,7 @@ }; struct br2684_dev { - struct net_device net_dev; + struct net_device *net_dev; struct list_head br2684_devs; int number; struct list_head brvccs; /* one device <=> one vcc (before xmas) */ @@ -137,8 +137,8 @@ case BR2684_FIND_BYIFNAME: list_for_each(lh, &br2684_devs) { brdev = list_entry_brdev(lh); - if (!strncmp(brdev->net_dev.name, s->spec.ifname, - sizeof brdev->net_dev.name)) + if (!strncmp(brdev->net_dev->name, s->spec.ifname, + IFNAMSIZ)) return brdev; } break; @@ -400,7 +400,6 @@ brvcc->atmvcc->user_back = NULL; /* what about vcc->recvq ??? */ brvcc->old_push(brvcc->atmvcc, NULL); /* pass on the bad news */ kfree(brvcc); - MOD_DEC_USE_COUNT; } /* when AAL5 PDU comes in: */ @@ -418,8 +417,8 @@ read_lock(&devs_lock); list_del(&brdev->br2684_devs); read_unlock(&devs_lock); - unregister_netdev(&brdev->net_dev); - kfree(brdev); + unregister_netdev(brdev->net_dev); + kfree(brdev->net_dev); } return; } @@ -464,7 +463,7 @@ #endif /* CONFIG_BR2684_FAST_TRANS */ #else skb_pull(skb, plen - ETH_HLEN); - skb->protocol = eth_type_trans(skb, &brdev->net_dev); + skb->protocol = eth_type_trans(skb, brdev->net_dev); #endif /* FASTER_VERSION */ #ifdef CONFIG_ATM_BR2684_IPFILTER if (packet_fails_filter(skb->protocol, brvcc, skb)) { @@ -473,11 +472,11 @@ return; } #endif /* CONFIG_ATM_BR2684_IPFILTER */ - skb->dev = &brdev->net_dev; + skb->dev = brdev->net_dev; ATM_SKB(skb)->vcc = atmvcc; /* needed ? */ DPRINTK("received packet's protocol: %x\n", ntohs(skb->protocol)); skb_debug(skb); - if (!(brdev->net_dev.flags & IFF_UP)) { /* sigh, interface is down */ + if (!(brdev->net_dev->flags & IFF_UP)) { /* sigh, interface is down */ brdev->stats.rx_dropped++; dev_kfree_skb(skb); return; @@ -500,9 +499,7 @@ struct br2684_dev *brdev; struct atm_backend_br2684 be; - MOD_INC_USE_COUNT; if (copy_from_user(&be, (void *) arg, sizeof be)) { - MOD_DEC_USE_COUNT; return -EFAULT; } write_lock_irq(&devs_lock); @@ -539,10 +536,10 @@ if (list_empty(&brdev->brvccs) && !brdev->mac_was_set) { unsigned char *esi = atmvcc->dev->esi; if (esi[0] | esi[1] | esi[2] | esi[3] | esi[4] | esi[5]) - memcpy(brdev->net_dev.dev_addr, esi, - brdev->net_dev.addr_len); + memcpy(brdev->net_dev->dev_addr, esi, + brdev->net_dev->addr_len); else - brdev->net_dev.dev_addr[2] = 1; + brdev->net_dev->dev_addr[2] = 1; } list_add(&brvcc->brvccs, &brdev->brvccs); write_unlock_irq(&devs_lock); @@ -563,77 +560,69 @@ return 0; error: write_unlock_irq(&devs_lock); - MOD_DEC_USE_COUNT; return err; } +static void br2684_setup(struct net_device *netdev) +{ + struct br2684_dev *brdev = netdev->priv; + + ether_setup(netdev); + brdev->net_dev = netdev; + +#ifdef FASTER_VERSION + my_eth_header = netdev->hard_header; + netdev->hard_header = br2684_header; + my_eth_header_cache = netdev->hard_header_cache; + netdev->hard_header_cache = br2684_header_cache; + netdev->hard_header_len = sizeof(llc_oui_pid_pad) + ETH_HLEN; /* 10 + 14 */ +#endif + my_eth_mac_addr = netdev->set_mac_address; + netdev->set_mac_address = br2684_mac_addr; + netdev->hard_start_xmit = br2684_start_xmit; + netdev->get_stats = br2684_get_stats; + + INIT_LIST_HEAD(&brdev->brvccs); +} + static int br2684_create(unsigned long arg) { int err; + struct net_device *netdev; struct br2684_dev *brdev; struct atm_newif_br2684 ni; DPRINTK("br2684_create\n"); - /* - * We track module use by vcc's NOT the devices they're on. We're - * protected here against module death by the kernel_lock, but if - * we need to sleep we should make sure that the module doesn't - * disappear under us. - */ - MOD_INC_USE_COUNT; + if (copy_from_user(&ni, (void *) arg, sizeof ni)) { - MOD_DEC_USE_COUNT; return -EFAULT; } if (ni.media != BR2684_MEDIA_ETHERNET || ni.mtu != 1500) { - MOD_DEC_USE_COUNT; return -EINVAL; } - if ((brdev = kmalloc(sizeof(struct br2684_dev), GFP_KERNEL)) == NULL) { - MOD_DEC_USE_COUNT; - return -ENOMEM; - } - memset(brdev, 0, sizeof(struct br2684_dev)); - INIT_LIST_HEAD(&brdev->brvccs); - write_lock_irq(&devs_lock); - brdev->number = list_empty(&br2684_devs) ? 1 : - list_entry_brdev(br2684_devs.prev)->number + 1; - list_add_tail(&brdev->br2684_devs, &br2684_devs); - write_unlock_irq(&devs_lock); + netdev = alloc_netdev(sizeof(struct br2684_dev), + ni.ifname[0] ? ni.ifname : "nas%d", + br2684_setup); + if (!netdev) + return -ENOMEM; - if (ni.ifname[0] != '\0') { - memcpy(brdev->net_dev.name, ni.ifname, - sizeof(brdev->net_dev.name)); - brdev->net_dev.name[sizeof(brdev->net_dev.name) - 1] = '\0'; - } else - sprintf(brdev->net_dev.name, "nas%d", brdev->number); - DPRINTK("registered netdev %s\n", brdev->net_dev.name); - ether_setup(&brdev->net_dev); - brdev->mac_was_set = 0; -#ifdef FASTER_VERSION - my_eth_header = brdev->net_dev.hard_header; - brdev->net_dev.hard_header = br2684_header; - my_eth_header_cache = brdev->net_dev.hard_header_cache; - brdev->net_dev.hard_header_cache = br2684_header_cache; - brdev->net_dev.hard_header_len = sizeof(llc_oui_pid_pad) + ETH_HLEN; /* 10 + 14 */ -#endif - my_eth_mac_addr = brdev->net_dev.set_mac_address; - brdev->net_dev.set_mac_address = br2684_mac_addr; - brdev->net_dev.hard_start_xmit = br2684_start_xmit; - brdev->net_dev.get_stats = br2684_get_stats; + brdev = netdev->priv; + DPRINTK("registered netdev %s\n", netdev->name); /* open, stop, do_ioctl ? */ - err = register_netdev(&brdev->net_dev); - MOD_DEC_USE_COUNT; + err = register_netdev(netdev); if (err < 0) { printk(KERN_ERR "br2684_create: register_netdev failed\n"); - write_lock_irq(&devs_lock); - list_del(&brdev->br2684_devs); - write_unlock_irq(&devs_lock); - kfree(brdev); + kfree(netdev); return err; } + + write_lock_irq(&devs_lock); + brdev->number = list_empty(&br2684_devs) ? 1 : + list_entry_brdev(br2684_devs.prev)->number + 1; + list_add_tail(&brdev->br2684_devs, &br2684_devs); + write_unlock_irq(&devs_lock); return 0; } @@ -649,9 +638,7 @@ case ATM_SETBACKEND: case ATM_NEWBACKENDIF: { atm_backend_t b; - MOD_INC_USE_COUNT; err = get_user(b, (atm_backend_t *) arg); - MOD_DEC_USE_COUNT; if (err) return -EFAULT; if (b != ATM_BACKEND_BR2684) @@ -669,9 +656,7 @@ return -ENOIOCTLCMD; if (!capable(CAP_NET_ADMIN)) return -EPERM; - MOD_INC_USE_COUNT; err = br2684_setfilt(atmvcc, arg); - MOD_DEC_USE_COUNT; return err; #endif /* CONFIG_ATM_BR2684_IPFILTER */ } @@ -688,14 +673,14 @@ brdev = list_entry_brdev(lhd); if (pos-- == 0) return sprintf(buf, "dev %.16s: num=%d, mac=%02X:%02X:" - "%02X:%02X:%02X:%02X (%s)\n", brdev->net_dev.name, + "%02X:%02X:%02X:%02X (%s)\n", brdev->net_dev->name, brdev->number, - brdev->net_dev.dev_addr[0], - brdev->net_dev.dev_addr[1], - brdev->net_dev.dev_addr[2], - brdev->net_dev.dev_addr[3], - brdev->net_dev.dev_addr[4], - brdev->net_dev.dev_addr[5], + brdev->net_dev->dev_addr[0], + brdev->net_dev->dev_addr[1], + brdev->net_dev->dev_addr[2], + brdev->net_dev->dev_addr[3], + brdev->net_dev->dev_addr[4], + brdev->net_dev->dev_addr[5], brdev->mac_was_set ? "set" : "auto"); list_for_each(lhc, &brdev->brvccs) { brvcc = list_entry_brvcc(lhc); @@ -766,15 +751,13 @@ } static struct file_operations br2684_proc_operations = { - read: br2684_proc_read, + .owner = THIS_MODULE, + .read = br2684_proc_read, }; extern struct proc_dir_entry *atm_proc_root; /* from proc.c */ -/* the following avoids some spurious warnings from the compiler */ -#define UNUSED __attribute__((unused)) - -static int __init UNUSED br2684_init(void) +static int __init br2684_init(void) { struct proc_dir_entry *p; if ((p = create_proc_entry("br2684", 0, atm_proc_root)) == NULL) @@ -784,16 +767,25 @@ return 0; } -static void __exit UNUSED br2684_exit(void) +static void __exit br2684_exit(void) { struct br2684_dev *brdev; + struct br2684_vcc *brvcc; + br2684_ioctl_set(NULL); + remove_proc_entry("br2684", atm_proc_root); + while (!list_empty(&br2684_devs)) { brdev = list_entry_brdev(br2684_devs.next); - unregister_netdev(&brdev->net_dev); + while (!list_empty(&brdev->brvccs)) { + brvcc = list_entry_brvcc(brdev->brvccs.next); + br2684_close_vcc(brvcc); + } + + unregister_netdev(brdev->net_dev); list_del(&brdev->br2684_devs); - kfree(brdev); + kfree(brdev->net_dev); } } From shemminger@osdl.org Mon Aug 11 11:53:55 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 11:53:59 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7BIrsFl028977 for ; Mon, 11 Aug 2003 11:53:55 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7BIrgo28732; Mon, 11 Aug 2003 11:53:42 -0700 Date: Mon, 11 Aug 2003 11:53:34 -0700 From: Stephen Hemminger To: Maxim Krasnyansky , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [RFT][PATCH] Convert bluetooth to dynamic net_device. Message-Id: <20030811115334.4bd4521a.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4729 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Convert Bluetooth networking to dynamic allocation of network devices. This will allow fixing races with rmmod and sysfs access. The patch is against 2.6.0-test3 and correctly loads/unloads but since I don't have bluetooth hardware can't test it more. Since the initialization code changed slightly, I would like to have someone do a basic sanity test before it is merged. diff -Nru a/net/bluetooth/bnep/bnep.h b/net/bluetooth/bnep/bnep.h --- a/net/bluetooth/bnep/bnep.h Mon Aug 11 11:42:08 2003 +++ b/net/bluetooth/bnep/bnep.h Mon Aug 11 11:42:08 2003 @@ -168,11 +168,11 @@ u64 mc_filter; struct socket *sock; - struct net_device dev; + struct net_device *dev; struct net_device_stats stats; }; -int bnep_net_init(struct net_device *dev); +void bnep_net_setup(struct net_device *dev); int bnep_sock_init(void); int bnep_sock_cleanup(void); diff -Nru a/net/bluetooth/bnep/core.c b/net/bluetooth/bnep/core.c --- a/net/bluetooth/bnep/core.c Mon Aug 11 11:42:08 2003 +++ b/net/bluetooth/bnep/core.c Mon Aug 11 11:42:08 2003 @@ -180,7 +180,7 @@ s->mc_filter = 0; /* Always send broadcast */ - set_bit(bnep_mc_hash(s->dev.broadcast), (ulong *) &s->mc_filter); + set_bit(bnep_mc_hash(s->dev->broadcast), (ulong *) &s->mc_filter); /* Add address ranges to the multicast hash */ for (; n > 0; n--) { @@ -293,7 +293,7 @@ static inline int bnep_rx_frame(struct bnep_session *s, struct sk_buff *skb) { - struct net_device *dev = &s->dev; + struct net_device *dev = s->dev; struct sk_buff *nskb; u8 type; @@ -451,7 +451,7 @@ static int bnep_session(void *arg) { struct bnep_session *s = arg; - struct net_device *dev = &s->dev; + struct net_device *dev = s->dev; struct sock *sk = s->sock->sk; struct sk_buff *skb; wait_queue_t wait; @@ -501,7 +501,7 @@ __bnep_unlink_session(s); up_write(&bnep_session_sem); - kfree(s); + kfree(dev); return 0; } @@ -517,10 +517,13 @@ baswap((void *) dst, &bt_sk(sock->sk)->dst); baswap((void *) src, &bt_sk(sock->sk)->src); - s = kmalloc(sizeof(struct bnep_session), GFP_KERNEL); - if (!s) - return -ENOMEM; - memset(s, 0, sizeof(struct bnep_session)); + /* session struct allocated as private part of net_device */ + dev = alloc_netdev(sizeof(struct bnep_session), + (*req->device) ? req->device : "bnep%d", + bnep_net_setup); + if (!dev) + return ENOMEM; + down_write(&bnep_session_sem); @@ -530,20 +533,15 @@ goto failed; } - dev = &s->dev; - - if (*req->device) - strcpy(dev->name, req->device); - else - strcpy(dev->name, "bnep%d"); + s = dev->priv; - memset(dev->broadcast, 0xff, ETH_ALEN); - /* This is rx header therefore addresses are swapped. * ie eh.h_dest is our local address. */ memcpy(s->eh.h_dest, &src, ETH_ALEN); memcpy(s->eh.h_source, &dst, ETH_ALEN); + memcpy(dev->dev_addr, s->eh.h_dest, ETH_ALEN); + s->dev = dev; s->sock = sock; s->role = req->role; s->state = BT_CONNECTED; @@ -569,8 +567,6 @@ s->proto_filter[2].end = htons(0x86DD); #endif - dev->init = bnep_net_init; - dev->priv = s; err = register_netdev(dev); if (err) { goto failed; @@ -592,7 +588,7 @@ failed: up_write(&bnep_session_sem); - kfree(s); + kfree(dev); return err; } @@ -624,7 +620,7 @@ static void __bnep_copy_ci(struct bnep_conninfo *ci, struct bnep_session *s) { memcpy(ci->dst, s->eh.h_source, ETH_ALEN); - strcpy(ci->device, s->dev.name); + strcpy(ci->device, s->dev->name); ci->flags = s->flags; ci->state = s->state; ci->role = s->role; diff -Nru a/net/bluetooth/bnep/netdev.c b/net/bluetooth/bnep/netdev.c --- a/net/bluetooth/bnep/netdev.c Mon Aug 11 11:42:08 2003 +++ b/net/bluetooth/bnep/netdev.c Mon Aug 11 11:42:08 2003 @@ -226,11 +226,10 @@ return 0; } -int bnep_net_init(struct net_device *dev) +void bnep_net_setup(struct net_device *dev) { - struct bnep_session *s = dev->priv; - memcpy(dev->dev_addr, s->eh.h_dest, ETH_ALEN); + memset(dev->broadcast, 0xff, ETH_ALEN); dev->addr_len = ETH_ALEN; ether_setup(dev); @@ -245,6 +244,4 @@ dev->watchdog_timeo = HZ * 2; dev->tx_timeout = bnep_net_timeout; - - return 0; } From mhuth@mvista.com Mon Aug 11 14:18:48 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 14:18:55 -0700 (PDT) Received: from zipcode.az.mvista.com (rav-az.mvista.com [65.200.49.157]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7BLIlFl004060 for ; Mon, 11 Aug 2003 14:18:47 -0700 Received: from mvista.com ([10.50.1.182]) by zipcode.az.mvista.com (8.9.3/8.9.3) with ESMTP id OAA09911; Mon, 11 Aug 2003 14:32:51 -0700 Message-ID: <3F380A28.10902@mvista.com> Date: Mon, 11 Aug 2003 14:27:04 -0700 From: Mark Huth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: shmulik.hen@intel.com, hadi@cyberus.ca, Laurent DENIEL , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master's settings toslaves References: <200308111720.38472.shmulik.hen@intel.com> <1060612481.1034.15.camel@jzny.localdomain> <200308111925.38278.shmulik.hen@intel.com> <3F37C7C3.7070807@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4730 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mhuth@mvista.com Precedence: bulk X-list: netdev Jeff Garzik wrote: > The answer is, like life, it's a balance. > > As a general rule, we do prefer to move all code possible out of the > Linux kernel. We have even created "initramfs", which for 2.7, will > be used as a vehicle to move code from the kernel to userspace, that > previously had to be in the kernel only because it was a task that > "had to be performed at boot time". > > However, one must consider > (1) does moving code to userspace create any security holes? > (2) does moving code to userspace dramatically increase the number of > context switches? > (3) does moving code to userspace violate some atomicity that being > inside the kernel guarantees? > > In practice, #3 is the showstopper that occurs most often. > > This is why I push for a "bonding-utils" package from Jay.... because > of the general rule above: put it into userspace, where possible. > > Jeff Yes, the answer is balance - the complicated, but non-time critical things should go into applications. However, we need to retain a basic ability to perform the failover according to pre-configured rules within the kernel. Many of our customers use bonding to provide a redundant network path through the wires and switches for what turn out to be heavily network dependant applications. In many cases, the systems do not have a local disk, and everything is obtained via say an NFS mount. When the MAC breaks, you may not be able to run userland! In HA systems at this level, guarding against the failure of a redundant hardware component, we find that it is very helpful for the kernel to be able to perform a variety of simple, pre-programmed operations without resort to userland - this keeps the interacting fault domains smaller. Sure, the decisons about how to configure the behaviors - that is the policies - belong in applications. But the response to an event which triggers the actions may well _need_ to be in the kernel. While the issue may not be so much one of speed - the applications may well respond in an adequate manner, depending on design and load - the issue of the amount of the system that must work for recovery is quite important when trying to push system availabilities into the mythical 5 9's plus region. For an application to run, the system has to be able to fork and exec, access the file system, allocate memory, etc. Sure, through careful configuration it is possible to reduce the transient resources required (run a pre-loaded/locked daemon, make sure the files are locally cached, etc) then the configuration and testing are complicated. It worked fine in the lab, because a resource we didn't realize was critical, never got pushed out of the dcache, for example. Mark Huth From fubar@us.ibm.com Mon Aug 11 14:43:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 14:43:38 -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 h7BLhMFl007388 for ; Mon, 11 Aug 2003 14:43:29 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h7BLgZRZ235174; Mon, 11 Aug 2003 17:42:35 -0400 Received: from death.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h7BLgWiY085824; Mon, 11 Aug 2003 15:42:34 -0600 Received: from us.ibm.com (fubar@localhost) by death.ibm.com (8.12.5/8.12.5/Submit) with ESMTP id h7BLftpS015012; Mon, 11 Aug 2003 14:41:56 -0700 Message-Id: <200308112141.h7BLftpS015012@death.ibm.com> X-Authentication-Warning: death.ibm.com: fubar owned process doing -bs To: Jeff Garzik cc: shmulik.hen@intel.com, hadi@cyberus.ca, Laurent DENIEL , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master's settings toslaves In-Reply-To: Message from Jeff Garzik of "Mon, 11 Aug 2003 12:43:47 EDT." <3F37C7C3.7070807@pobox.com> Date: Mon, 11 Aug 2003 14:41:54 -0700 From: Jay Vosburgh X-archive-position: 4731 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev >The answer is, like life, it's a balance. [...] >This is why I push for a "bonding-utils" package from Jay.... because of >the general rule above: put it into userspace, where possible. Hmm. My impression from our prior discussions was that your interest in moving ifenslave out of the kernel source and into its own package was more of a source code management concern rather than moving functionality from the kernel into user space (because ifenslave is in user space to begin with). Anyway, for most of the core bonding failover logic, I don't see how a user space daemon implementation can perform equivalently to a kernel-only implementation. I could be wrong (I haven't done any testing) but for the core "eth0 is dead, enable eth1" type stuff, it seems to me that in-kernel beats "user space yakking with kernel" for reliability and speed, particularly on heavily loaded systems. Now, that said, I can see a use for a user space monitoring / control program, for the "strategic" problems (as opposed to the "tactical" problems, like the previous paragraph). If we want to, e.g., monitor bandwidth usage and add or remove links from the aggregation, that is (a) not as time critical, and (b) somewhat fuzzier in definition. Such a user space program could also interface with various system management or HA thingies and report status for its activities as well as the activities that bonding performs independent of it. One thought I've had (which dovetails somewhat with an earlier comment from Laurent) is a tcpdump/bpf-style "policy engine" blob in the kernel, which is programmed from user space with enough brains to handle the "tactical" level problems (the "strategic" problems might be more than such a blob could handle, and if its easy enough to yak with user space for those problems, it may not be necessary). I haven't done much more than think about this, though; it may very well be overkill for the basic stuff. -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com From nf@hipac.org Mon Aug 11 15:41:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 15:42:03 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [62.67.200.156]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7BMfXFl018730 for ; Mon, 11 Aug 2003 15:41:35 -0700 Received: (qmail 1854 invoked from network); 11 Aug 2003 22:41:30 -0000 Received: from unknown (HELO portal.lan) (134300@[80.138.253.69]) (envelope-sender ) by smtprelay01.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 11 Aug 2003 22:41:30 -0000 Received: from hipac.org (tmobile.lan [192.168.0.6]) by portal.lan (Postfix) with ESMTP id B695A4AF78; Mon, 11 Aug 2003 23:02:01 +0200 (CEST) Message-ID: <3F381B3E.6080807@hipac.org> Date: Tue, 12 Aug 2003 00:39:58 +0200 From: Michael Bellion and Thomas Heinz User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.4) Gecko/20030714 Debian/1.4-2 X-Accept-Language: de, en MIME-Version: 1.0 To: hadi@cyberus.ca Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [RFC] High Performance Packet Classifiction for tc framework References: <200307141045.40999.nf@hipac.org> <1058328537.1797.24.camel@jzny.localdomain> <3F16A0E5.1080007@hipac.org> <1059934468.1103.41.camel@jzny.localdomain> <3F2E5CD6.4030500@hipac.org> <1060012260.1103.380.camel@jzny.localdomain> <3F302E04.1090503@hipac.org> <1060286331.1025.73.camel@jzny.localdomain> In-Reply-To: <1060286331.1025.73.camel@jzny.localdomain> X-Enigmail-Version: 0.76.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD08EFA7D1F7173B3DB5092FE" X-archive-position: 4732 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nf@hipac.org Precedence: bulk X-list: netdev This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD08EFA7D1F7173B3DB5092FE Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Jamal Sorry for the late reply. You wrote: > Unfortunately due to economical reasons i wont be able to make it. I > mentioned it to LaForge. It's a pity. Anyway, we should keep in touch to discuss the future directions of hipac, tc and stuff. We are going to post the new hipac design as soon as it is sufficiently elaborated. > It was very close ;-> The guy looked motivated i felt scared for a while > that he will be asking a lot of questions. Then i never heard about it > again ;-> I think he left town too. Too bad, you should have told the guy about all the fame and glory ;-) >>Yes, it does. Still the question is how to solve this >>generally. Consider the following example ruleset: >> >>1) src ip 10.0.0.0/30 dst ip 20.0.0.0/20 >>2) src ip 10.0.0.0/28 dst ip 20.0.0.0/22 >>3) src ip 10.0.0.0/26 dst ip 20.0.0.0/24 >>4) src ip 10.0.0.0/24 dst ip 20.0.0.0/26 >>5) src ip 10.0.0.0/22 dst ip 20.0.0.0/28 >>6) src ip 10.0.0.0/20 dst ip 20.0.0.0/30 > > It can be done by using the masks - but it would look really ugly. I > suppose just providing a good user interface is valuable. Well, let's discuss the problem in a more general way. First of all we should clearly agree on the goal. For simplicity we focus on the 1 dimensional case (e.g. src ip, see also next paragraph for a explanation of the term "dimension" in that context) and we allow only prefixes (no general masks). Problem: We are given an access list of n 1-dimensional prefix rules, i.e. (v_1/p_1, ..., v_n/p_n) where v_i is the value (e.g. src ip) and p_1 is the length of the prefix. [The target of the rules can be ignored since it is irrelevant for the considerations.] The priority of each rule is determined by its position in the tuple (-> smaller value means higher priority). Furthermore we assume: p_i >= p_j for all i <= j to avoid never matching rules. Now, we want to construct a hash with m = O(n) buckets where each bucket contains O(1) rules. Therefore we need to find a prefix length PREF and a hash function HASH where given a key k the number of the bucket is computed via: HASH(k & ~(~0 >> PREF)) Let's take a look at the elementary intervals (see our last e-mail) created by the ruleset. There are at most 2 * n + 1 elementary intervals and each interval can be described in the form of a prefix: eval/epref where eval is the value and epref the length of the prefix. From the description above we know that p_1 =: p_max is the maximal prefix length and p_n := p_min is the minimal prefix length of the ruleset. We can conclude that epref_min >= p_min and epref_max = p_max where epref_min is the minimal prefix length of all elementary intervals (epref_max analog). Now to the main question: How to choose PREF? Obviously, we would choose it such that epref_min <= PREF <= epref_max. Well, here we are in trouble because if you choose PREF < epref_max the number of elements per bucket is in the worst case: Sum[i := 1 to epref_max - PREF] min(2^(PREF + i), count(PREF + i)) where count(j) := number of rules with prefix length j So, we have to choose PREF very close to epref_max or even epref_max if we want to have O(1) rules per bucket. Unfortunately, if we're doing this we run into another problem. Assume PREF = epref_max. Since we allow O(n) buckets we can assign all rules with prefix length PREF to separate buckets -> no collisions. But what about the remaining rules with prefix lengths < PREF? Those prefixes are distributed over multiple buckets which breaks the O(1) requirement for buckets. The reason is as follows. We know that each of the remaining n - count(PREF) rules terminate in at least 1 elementary interval. The elementary interval of a rule with prefix length p contains at most 2^p keys. It is distributed over 2^(PREF - p) buckets (at most). Therefore we have at most: N := Sum[i := p_min to PREF - 1] count(i) * 2^(PREF - i) rules in all buckets, that is N / O(n) (> O(1)) rules per bucket. This estimation is rather rough but it clearly shows that choosing PREF near to epref_max breaks the O(1) requirement for buckets. This is a fundamental issue related to the use of hashes in this context. It shows that it is _impossible_ to create a hash which meets the requirement of O(1) rules per bucket in the setting described above regardless how clever you choose the hash function. What do you think about it? Do you agree? >>In theory you can do the following. Let's consider one >>dimension. The matches in one dimension form a set of >>elementary intervals which are overlapped by certain rules. >> >> [snipped] > > right. Why do you refer to this as one dimension? The term 'dimension' is related to the PCP (packet classification problem): Given a d-dimensional universe {i | 0 <= i < U}^d, a set of n rules {r_1, ..., r_n} where r_i = (cost, ([a_1, b_1], ..., [a_d, b_d])) with 0 <= a_i <= b_i < U and a packet (p_1, ..., p_d) where 0 <= p_i < U one has to find the least cost rule matching the packet. [The cost values must be unique per ruleset] Translated to real world packet classification a dimension is for example src ip, dst ip, proto, src port, dst port etc. >>BTW, this approach can be extended to 2 or more dimensions >>where the hash function for each hash has to meet the >>requirement. Of course this information is not very helpful >>since the problem of defining appropriate hash functions >>remains ;) > > Is that problem even solvable? Well, one could argue that the _problem_ is not precisely defined to answer this question since "easily (= fast) computable hash function" is rather spongy. Ignoring the "fast computable" requirement, the problem is solvable simply because the hash function is finite ... but again this does not help a bit ;-) So, do you agree that it is _impossible_ to express arbitrary access lists using the hash tree approach if each hash bucket is required to hold O(1) rules? [You already agreed that this requirement is needed for the tree of hashes to perform optimally.] > This is why i was wondering how fast your instertions and deletions are. > Seems to me you will have to sort the rules everytime. No, there is no sorting of rules involved. Each rule insert operation inserts the native matches of the rule into the (dim)tree. > Dont you think this "dynamic adjustment" is unnecessary. Essentially you > enforce a model where every rule is a different priority. Well, we consider the model beneficial for the user. First of all the requirement is also present in the classical PCP definition ;) and secondly it supports dynamic rulesets better because using static priorities you ran into the problem of redefining a lot of prios manually sooner or later. > The general idea is to recreate the tree if need be based on colisions. > I just hope some idiot reading this doesnt go and patent it(has happened > before). Well, this would be bad of course although it shouldn't be possible to reverse engineer the algorithm from your descrition ;) > I was wondering why not just optimize it for Linux. You are trying to > center the world around nf-hipac - I would just center it around > Linux ;-> LOL, this is _really_ funny :-)) In fact, we just try to be as general as possible without degrading performance. So far, everything integrates fine into Linux. Although the nf-hipac patch is rather large (530 KB), only 205 lines of code have to be added to existing kernel files. >>Well, in order to support iptables matches and targets we had >>to create an appropriate abstraction for them on the hipac >>layer. This abstraction can also be used for tc classifiers >>if the tcf_result is ignored, i.e. you just consider whether >>the filter matched or not. > > I am not sure i understood the part about ignoring tcf_result. If there would be no tcf_result then classifiers are simply matches, e.g. like iptables matches. They don't have an action associated with them. In iptables, from a technical viewpoint you could say that a target is basically the same as a match with an action attached to it. > You show only one classid per rule .. I think i can see what you meant > by ignoring tcf_result - essentially you want to have a series of filter > rules with different classification enngines, no? Hm, rather one rule with several classifiers and native matches. > But could you not have > the filters repeat the same classid for every filter? Each rule can only have one action or return "value" attached to it so if we want to use embedded classifiers (as matches) their classid (= action) must be ignored. The reason why we want to have several non-native matches in one rule is to allow the expression of a conjunction of these matches. This is not possible using several rules. > Also it seems you want to be able to have an action defined for > "nomatch" as well as "match" - is that correct? Some form of > reclassification when nomatch ? No, we don't want special actions defined for "match" or "nomatch". The action for a rule is already given by its classid. Regards, +-----------------------+----------------------+ | Michael Bellion | Thomas Heinz | | | | +-----------------------+----------------------+ | High Performance Packet Classification | | nf-hipac: http://www.hipac.org/ | +----------------------------------------------+ --------------enigD08EFA7D1F7173B3DB5092FE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQE/OBs/tXh2AYIMjggRAsjjAKCcZ7c2qKN3Boum8QSp6D6EQs602wCgiJwu 1xa1kcx7Mkq+OmVtgNsDNeI= =cVmV -----END PGP SIGNATURE----- --------------enigD08EFA7D1F7173B3DB5092FE-- From mitch@sfgoth.com Mon Aug 11 14:52:30 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 15:50:45 -0700 (PDT) Received: from gaz.sfgoth.com ([63.205.85.133]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7BLqTFl007749 for ; Mon, 11 Aug 2003 14:52:30 -0700 Received: from gaz.sfgoth.com (localhost.sfgoth.com [127.0.0.1]) by gaz.sfgoth.com (8.12.9/8.12.6) with ESMTP id h7BLwwL7001151; Mon, 11 Aug 2003 14:58:58 -0700 (PDT) (envelope-from mitch@gaz.sfgoth.com) Received: (from mitch@localhost) by gaz.sfgoth.com (8.12.9/8.12.6/Submit) id h7BLwvtb001150; Mon, 11 Aug 2003 14:58:57 -0700 (PDT) (envelope-from mitch) Date: Mon, 11 Aug 2003 14:58:57 -0700 From: Mitchell Blank Jr To: Stephen Hemminger Cc: chas williams , netdev@oss.sgi.com Subject: Re: [RFT][PATCH] cleanup net/atm/br2684.c Message-ID: <20030811215857.GA96728@gaz.sfgoth.com> References: <20030811114823.5b81474c.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030811114823.5b81474c.shemminger@osdl.org> User-Agent: Mutt/1.4.1i X-archive-position: 4733 X-Approved-By: ralf@linux-mips.org X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mitch@sfgoth.com Precedence: bulk X-list: netdev You might also want to send this patch to the linux-atm mailing list: linux-atm-general@lists.sourceforge.net Unfortunately you need to subscribe to post. http://lists.sourceforge.net/lists/listinfo/linux-atm-general Not sure how many ATM users are following 2.6 yet though. I might be able to give it a spin soon. > - unregister_netdev(&brdev->net_dev); > - kfree(brdev); > + unregister_netdev(brdev->net_dev); > + kfree(brdev->net_dev); Mmmm.. I see this snippet in your diff in multiplce places and it looks wrong. Where does the "brdev" structure get freed now? -Mitch From shemminger@osdl.org Mon Aug 11 15:31:08 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 15:51:32 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7BMV6Fl018382 for ; Mon, 11 Aug 2003 15:31:07 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7BMUko22954; Mon, 11 Aug 2003 15:30:46 -0700 Date: Mon, 11 Aug 2003 15:30:39 -0700 From: Stephen Hemminger To: Mitchell Blank Jr Cc: chas williams , netdev@oss.sgi.com Subject: Re: [RFT][PATCH] cleanup net/atm/br2684.c Message-Id: <20030811153039.6df304fb.shemminger@osdl.org> In-Reply-To: <20030811215857.GA96728@gaz.sfgoth.com> References: <20030811114823.5b81474c.shemminger@osdl.org> <20030811215857.GA96728@gaz.sfgoth.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4734 X-Approved-By: ralf@linux-mips.org X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Mon, 11 Aug 2003 14:58:57 -0700 Mitchell Blank Jr wrote: > You might also want to send this patch to the linux-atm mailing list: > linux-atm-general@lists.sourceforge.net > Unfortunately you need to subscribe to post. > http://lists.sourceforge.net/lists/listinfo/linux-atm-general > > Not sure how many ATM users are following 2.6 yet though. I might be > able to give it a spin soon. > > > - unregister_netdev(&brdev->net_dev); > > - kfree(brdev); > > + unregister_netdev(brdev->net_dev); > > + kfree(brdev->net_dev); > > Mmmm.. I see this snippet in your diff in multiplce places and it looks > wrong. Where does the "brdev" structure get freed now? > > -Mitch The brdev structure is contained inside the allocation of net_device, this is how all the ether and other devices do it. net_dev -->+-------------------+ | network_device | +-------------------+ |/// padding ///////| +-------------------+ priv -->| brdev | +-------------------+ From shmulik.hen@intel.com Mon Aug 11 16:15:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 16:15:40 -0700 (PDT) Received: from hermes.sc.intel.com (fmr03.intel.com [143.183.121.5]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7BNFUFl020537 for ; Mon, 11 Aug 2003 16:15:31 -0700 Received: from talaria.sc.intel.com (talaria.sc.intel.com [10.3.253.5]) by hermes.sc.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 h7BNApm12400 for ; Mon, 11 Aug 2003 23:10:52 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by talaria.sc.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 h7BN92g16312 for ; Mon, 11 Aug 2003 23:09:02 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.254.188]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003081116201932282 ; Mon, 11 Aug 2003 16:20:21 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Shmulik Hen Reply-To: shmulik.hen@intel.com Organization: Intel corp. To: Jay Vosburgh , Jeff Garzik Subject: Re: [SET 2][PATCH 2/8][bonding] Propagating master's settings to slaves Date: Tue, 12 Aug 2003 02:15:18 +0300 User-Agent: KMail/1.4.3 Cc: hadi@cyberus.ca, Laurent DENIEL , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com References: <200308112141.h7BLftpS015012@death.ibm.com> In-Reply-To: <200308112141.h7BLftpS015012@death.ibm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200308120215.18234.shmulik.hen@intel.com> X-archive-position: 4735 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev May I remind you all that the original discussion was only about stuff that has to do with configuration time. There was no mention of any run time code. ifenslave only does three simple things - add a slave, remove a slave and set the current active slave, that's all. The drive was to try and make ifenslave slimmer regarding those three operations only in the way that any setting of the slave will be done by the kernel module instead of the configuration application. There is no real "brain" there anyway. We had some experience with creating an configuration application that was incredibly smart and was always aware of what was going on in the driver and could make all possible decisions before even attempting to access the driver so it could fail the operation without "bothering" the driver. It's gigantic. It's extremely hard to install and configure. It's even harder to maintain. And all it was meant to do is configuration. Imagine what would happen if it was also supposed to handle run time issues. I am not aware of anything like moving kernel code into applications. Was that something that was discussed in OLS ? Where can I find some more info about this trend ? Shmulik. From shemminger@osdl.org Mon Aug 11 16:22:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 16:22:35 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7BNMUFl020983 for ; Mon, 11 Aug 2003 16:22:30 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7BNMDo03918; Mon, 11 Aug 2003 16:22:13 -0700 Date: Mon, 11 Aug 2003 16:22:05 -0700 From: Stephen Hemminger To: "David S. Miller" , Joerg Reuter Cc: linux-hams@vger.kernel.org, netdev@oss.sgi.com Subject: [PATCH] Update bpqether for 2.6 Message-Id: <20030811162205.78b2029f.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4736 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev This patch fixes several issues with drivers/net/hamradio/bpqether.c in 2.6.0-test3. 1. Fix encapsulation of net_device structure relative to private data (bpqdev) 2. Convert from single-linked list to the list macros. 3. Convert to using seq_file for the /proc interface 4. Fix up locking by switching to RCU and the rtnl semaphore supplied by the network layer. 5. Fix removal cases of ethernet device and bpqether device to work without deadlock. 6. Get rid of MOD_INC/MOD_DEC 7. Get rid of bogus check_devices method of cleanup, just cleanup correctly when device changes state. Tested with load/unload and ether load/unload on SMP. Don't have real BPQ hardware to interact with, but didn't change the data flow path. diff -Nru a/drivers/net/hamradio/bpqether.c b/drivers/net/hamradio/bpqether.c --- a/drivers/net/hamradio/bpqether.c Mon Aug 11 15:57:14 2003 +++ b/drivers/net/hamradio/bpqether.c Mon Aug 11 15:57:14 2003 @@ -75,6 +75,7 @@ #include #include #include +#include #include #include #include @@ -99,7 +100,7 @@ static int bpq_rcv(struct sk_buff *, struct net_device *, struct packet_type *); static int bpq_device_event(struct notifier_block *, unsigned long, void *); -static char *bpq_print_ethaddr(unsigned char *); +static const char *bpq_print_ethaddr(const unsigned char *); static struct packet_type bpq_packet_type = { .type = __constant_htons(ETH_P_BPQ), @@ -113,15 +114,16 @@ #define MAXBPQDEV 100 -static struct bpqdev { - struct bpqdev *next; - char ethname[14]; /* ether device name */ - struct net_device *ethdev; /* link to ethernet device */ - struct net_device axdev; /* bpq device (bpq#) */ +struct bpqdev { + struct list_head bpq_list; /* list of bpq devices chain */ + struct net_device *ethdev; /* link to ethernet device */ + struct net_device *axdev; /* bpq device (bpq#) */ struct net_device_stats stats; /* some statistics */ char dest_addr[6]; /* ether destination address */ char acpt_addr[6]; /* accept ether frames from this address only */ -} *bpq_devices; +}; + +static LIST_HEAD(bpq_devices); /* ------------------------------------------------------------------------ */ @@ -139,15 +141,16 @@ /* * Get the BPQ device for the ethernet device + * need to hold bqp_lock at least for read */ static inline struct net_device *bpq_get_ax25_dev(struct net_device *dev) { struct bpqdev *bpq; - for (bpq = bpq_devices; bpq != NULL; bpq = bpq->next) + list_for_each_entry(bpq, &bpq_devices, bpq_list) { if (bpq->ethdev == dev) - return &bpq->axdev; - + return bpq->axdev; + } return NULL; } @@ -159,50 +162,6 @@ ); } -static spinlock_t bpq_lock = SPIN_LOCK_UNLOCKED; - -/* - * Sanity check: remove all devices that ceased to exists and - * return '1' if the given BPQ device was affected. - */ -static int bpq_check_devices(struct net_device *dev) -{ - struct bpqdev *bpq, *bpq_prev, *bpq_next; - int result = 0; - unsigned long flags; - - spin_lock_irqsave(&bpq_lock, flags); - - bpq_prev = NULL; - - for (bpq = bpq_devices; bpq != NULL; bpq = bpq_next) { - bpq_next = bpq->next; - if (!dev_get(bpq->ethname)) { - if (bpq_prev) - bpq_prev->next = bpq->next; - else - bpq_devices = bpq->next; - - if (&bpq->axdev == dev) - result = 1; - - /* We should be locked, call - * unregister_netdevice directly - */ - - unregister_netdevice(&bpq->axdev); - kfree(bpq); - } - else - bpq_prev = bpq; - } - - spin_unlock_irqrestore(&bpq_lock, flags); - - return result; -} - - /* ------------------------------------------------------------------------ */ @@ -218,12 +177,11 @@ skb->sk = NULL; /* Initially we don't know who it's for */ + rcu_read_lock(); dev = bpq_get_ax25_dev(dev); - if (dev == NULL || !netif_running(dev)) { - kfree_skb(skb); - return 0; - } + if (dev == NULL || !netif_running(dev)) + goto drop; /* * if we want to accept frames from just one ethernet device @@ -234,8 +192,7 @@ if (!(bpq->acpt_addr[0] & 0x01) && memcmp(eth->h_source, bpq->acpt_addr, ETH_ALEN)) { printk(KERN_DEBUG "bpqether: wrong dest %s\n", bpq_print_ethaddr(eth->h_source)); - kfree_skb(skb); - return 0; + goto drop; } len = skb->data[0] + skb->data[1] * 256 - 5; @@ -256,8 +213,15 @@ netif_rx(skb); dev->last_rx = jiffies; + unlock: + + rcu_read_unlock(); return 0; + drop: + kfree_skb(skb); + goto unlock; + } /* @@ -275,7 +239,6 @@ * is down, the ethernet device may have gone. */ if (!netif_running(dev)) { - bpq_check_devices(dev); kfree_skb(skb); return -ENODEV; } @@ -400,11 +363,6 @@ */ static int bpq_open(struct net_device *dev) { - if (bpq_check_devices(dev)) - return -ENODEV; /* oops, it's gone */ - - MOD_INC_USE_COUNT; - netif_start_queue(dev); return 0; } @@ -412,15 +370,6 @@ static int bpq_close(struct net_device *dev) { netif_stop_queue(dev); - MOD_DEC_USE_COUNT; - return 0; -} - -/* - * currently unused - */ -static int bpq_dev_init(struct net_device *dev) -{ return 0; } @@ -431,7 +380,7 @@ /* * Proc filesystem */ -static char * bpq_print_ethaddr(unsigned char *e) +static const char * bpq_print_ethaddr(const unsigned char *e) { static char buf[18]; @@ -441,98 +390,92 @@ return buf; } -static int bpq_get_info(char *buffer, char **start, off_t offset, int length) +#define BPQ_PROC_START ((void *)1) + +static void *bpq_seq_start(struct seq_file *seq, loff_t *pos) { + int i = 1; struct bpqdev *bpqdev; - int len = 0; - off_t pos = 0; - off_t begin = 0; - unsigned long flags; - - spin_lock_irqsave(&bpq_lock, flags); - - len += sprintf(buffer, "dev ether destination accept from\n"); - - for (bpqdev = bpq_devices; bpqdev != NULL; bpqdev = bpqdev->next) { - len += sprintf(buffer + len, "%-5s %-10s %s ", - bpqdev->axdev.name, bpqdev->ethname, - bpq_print_ethaddr(bpqdev->dest_addr)); - - len += sprintf(buffer + len, "%s\n", - (bpqdev->acpt_addr[0] & 0x01) ? "*" : bpq_print_ethaddr(bpqdev->acpt_addr)); - pos = begin + len; + rcu_read_lock(); - if (pos < offset) { - len = 0; - begin = pos; - } - - if (pos > offset + length) - break; + if (*pos == 0) + return BPQ_PROC_START; + + list_for_each_entry(bpqdev, &bpq_devices, bpq_list) { + if (i == *pos) + return bpqdev; } + return NULL; +} - spin_unlock_irqrestore(&bpq_lock, flags); +static void *bpq_seq_next(struct seq_file *seq, void *v, loff_t *pos) +{ + struct list_head *p; - *start = buffer + (offset - begin); - len -= (offset - begin); + ++*pos; - if (len > length) len = length; + if (v == BPQ_PROC_START) + p = bpq_devices.next; + else + p = ((struct bpqdev *)v)->bpq_list.next; - return len; + return (p == &bpq_devices) ? NULL + : list_entry(p, struct bpqdev, bpq_list); } - -/* ------------------------------------------------------------------------ */ - - -/* - * Setup a new device. - */ -static int bpq_new_device(struct net_device *dev) +static void bpq_seq_stop(struct seq_file *seq, void *v) { - int k; - struct bpqdev *bpq, *bpq2; - unsigned long flags; + rcu_read_unlock(); +} - if ((bpq = kmalloc(sizeof(struct bpqdev), GFP_KERNEL)) == NULL) - return -ENOMEM; - memset(bpq, 0, sizeof(struct bpqdev)); +static int bpq_seq_show(struct seq_file *seq, void *v) +{ + if (v == BPQ_PROC_START) + seq_puts(seq, + "dev ether destination accept from\n"); + else { + const struct bpqdev *bpqdev = v; - bpq->ethdev = dev; + seq_printf(seq, "%-5s %-10s %s ", + bpqdev->axdev->name, bpqdev->ethdev->name, + bpq_print_ethaddr(bpqdev->dest_addr)); - bpq->ethname[sizeof(bpq->ethname)-1] = '\0'; - strncpy(bpq->ethname, dev->name, sizeof(bpq->ethname)-1); + seq_printf(seq, "%s\n", + (bpqdev->acpt_addr[0] & 0x01) ? "*" + : bpq_print_ethaddr(bpqdev->acpt_addr)); - memcpy(bpq->dest_addr, bcast_addr, sizeof(bpq_eth_addr)); - memcpy(bpq->acpt_addr, bcast_addr, sizeof(bpq_eth_addr)); - - dev = &bpq->axdev; + } + return 0; +} - for (k = 0; k < MAXBPQDEV; k++) { - struct net_device *odev; +static struct seq_operations bpq_seqops = { + .start = bpq_seq_start, + .next = bpq_seq_next, + .stop = bpq_seq_stop, + .show = bpq_seq_show, +}; - sprintf(dev->name, "bpq%d", k); +static int bpq_info_open(struct inode *inode, struct file *file) +{ + return seq_open(file, &bpq_seqops); +} - if ((odev = __dev_get_by_name(dev->name)) == NULL || bpq_check_devices(odev)) - break; - } +static struct file_operations bpq_info_fops = { + .owner = THIS_MODULE, + .open = bpq_info_open, + .read = seq_read, + .llseek = seq_lseek, + .release = seq_release, +}; - if (k == MAXBPQDEV) { - kfree(bpq); - return -ENODEV; - } - dev->priv = (void *)bpq; /* pointer back */ - dev->init = bpq_dev_init; +/* ------------------------------------------------------------------------ */ - /* We should be locked, call register_netdevice() directly. */ - if (register_netdevice(dev) != 0) { - kfree(bpq); - return -EIO; - } +static void bpq_setup(struct net_device *dev) +{ dev->hard_start_xmit = bpq_xmit; dev->open = bpq_open; @@ -540,6 +483,7 @@ dev->set_mac_address = bpq_set_mac_address; dev->get_stats = bpq_get_stats; dev->do_ioctl = bpq_ioctl; + dev->destructor = (void (*)(struct net_device *)) kfree; memcpy(dev->broadcast, ax25_bcast, AX25_ADDR_LEN); memcpy(dev->dev_addr, ax25_defaddr, AX25_ADDR_LEN); @@ -556,20 +500,59 @@ dev->mtu = AX25_DEF_PACLEN; dev->addr_len = AX25_ADDR_LEN; - spin_lock_irqsave(&bpq_lock, flags); +} - if (bpq_devices == NULL) { - bpq_devices = bpq; - } else { - for (bpq2 = bpq_devices; bpq2->next != NULL; bpq2 = bpq2->next); - bpq2->next = bpq; - } +/* + * Setup a new device. + */ +static int bpq_new_device(struct net_device *edev) +{ + int err; + struct net_device *ndev; + struct bpqdev *bpq; + + ndev = alloc_netdev(sizeof(struct bpqdev), "bpq%d", + bpq_setup); + if (!ndev) + return -ENOMEM; + + + bpq = ndev->priv; + dev_hold(edev); + bpq->ethdev = edev; + bpq->axdev = ndev; - spin_unlock_irqrestore(&bpq_lock, flags); + memcpy(bpq->dest_addr, bcast_addr, sizeof(bpq_eth_addr)); + memcpy(bpq->acpt_addr, bcast_addr, sizeof(bpq_eth_addr)); + + err = dev_alloc_name(ndev, ndev->name); + if (err < 0) + goto error; + + err = register_netdevice(ndev); + if (err) + goto error; + /* List protected by RTNL */ + list_add_rcu(&bpq->bpq_list, &bpq_devices); return 0; + + error: + dev_put(edev); + kfree(ndev); + return err; + } +static void bpq_free_device(struct net_device *ndev) +{ + struct bpqdev *bpq = ndev->priv; + + dev_put(bpq->ethdev); + list_del_rcu(&bpq->bpq_list); + + unregister_netdevice(ndev); +} /* * Handle device status changes. @@ -581,21 +564,23 @@ if (!dev_is_ethdev(dev)) return NOTIFY_DONE; - bpq_check_devices(NULL); - switch (event) { - case NETDEV_UP: /* new ethernet device -> new BPQ interface */ - if (bpq_get_ax25_dev(dev) == NULL) - bpq_new_device(dev); - break; - - case NETDEV_DOWN: /* ethernet device closed -> close BPQ interface */ - if ((dev = bpq_get_ax25_dev(dev)) != NULL) - dev_close(dev); - break; + case NETDEV_UP: /* new ethernet device -> new BPQ interface */ + if (bpq_get_ax25_dev(dev) == NULL) + bpq_new_device(dev); + break; - default: - break; + case NETDEV_DOWN: /* ethernet device closed -> close BPQ interface */ + if ((dev = bpq_get_ax25_dev(dev)) != NULL) + dev_close(dev); + break; + + case NETDEV_UNREGISTER: /* ethernet device removed -> free BPQ interface */ + if ((dev = bpq_get_ax25_dev(dev)) != NULL) + bpq_free_device(dev); + break; + default: + break; } return NOTIFY_DONE; @@ -618,7 +603,7 @@ printk(banner); - if (!proc_net_create("bpqether", 0, bpq_get_info)) { + if (!proc_net_fops_create("bpqether", S_IRUGO, &bpq_info_fops)) { printk(KERN_ERR "bpq: cannot create /proc/net/bpqether entry.\n"); unregister_netdevice_notifier(&bpq_dev_notifier); @@ -626,15 +611,15 @@ return -ENOENT; } - read_lock_bh(&dev_base_lock); + rtnl_lock(); for (dev = dev_base; dev != NULL; dev = dev->next) { - if (dev_is_ethdev(dev)) { - read_unlock_bh(&dev_base_lock); - bpq_new_device(dev); - read_lock_bh(&dev_base_lock); + if (dev_is_ethdev(dev) && bpq_new_device(dev)) { + printk(KERN_ERR + "bpq: cannot setup dev for '%s'\n", + dev->name); } } - read_unlock_bh(&dev_base_lock); + rtnl_unlock(); return 0; } @@ -648,8 +633,12 @@ proc_net_remove("bpqether"); - for (bpq = bpq_devices; bpq != NULL; bpq = bpq->next) - unregister_netdev(&bpq->axdev); + rtnl_lock(); + while (!list_empty(&bpq_devices)) { + bpq = list_entry(bpq_devices.next, struct bpqdev, bpq_list); + bpq_free_device(bpq->axdev); + } + rtnl_unlock(); } MODULE_AUTHOR("Joerg Reuter DL1BKE "); From fubar@us.ibm.com Mon Aug 11 16:30:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 16:30:18 -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 h7BNU8Fl021350 for ; Mon, 11 Aug 2003 16:30:15 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h7BNTMc8275514; Mon, 11 Aug 2003 19:29:22 -0400 Received: from death.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h7BNTFiY059368; Mon, 11 Aug 2003 17:29:17 -0600 Received: from us.ibm.com (fubar@localhost) by death.ibm.com (8.12.5/8.12.5/Submit) with ESMTP id h7BNSdYi015167; Mon, 11 Aug 2003 16:28:40 -0700 Message-Id: <200308112328.h7BNSdYi015167@death.ibm.com> X-Authentication-Warning: death.ibm.com: fubar owned process doing -bs To: shmulik.hen@intel.com cc: Jeff Garzik , hadi@cyberus.ca, Laurent DENIEL , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master's settings to slaves In-Reply-To: Message from Shmulik Hen of "Tue, 12 Aug 2003 02:15:18 +0300." <200308120215.18234.shmulik.hen@intel.com> Date: Mon, 11 Aug 2003 16:28:39 -0700 From: Jay Vosburgh X-archive-position: 4737 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev >The drive was to try and make ifenslave slimmer regarding those three >operations only in the way that any setting of the slave will be done >by the kernel module instead of the configuration application. There >is no real "brain" there anyway. Agreed. One reason for adding all of that propogation of settings from master to slave is so that ifenslave doesn't have to do it. The less mystic stuff that needs to be synchronized between the two, the better. -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com From hadi@cyberus.ca Mon Aug 11 19:32:21 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 19:32:32 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7C2WKFl028244 for ; Mon, 11 Aug 2003 19:32:21 -0700 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.12) id 19mOxK-000JhA-00; Mon, 11 Aug 2003 22:32:14 -0400 Subject: Re: [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master's settings toslaves From: jamal Reply-To: hadi@cyberus.ca To: shmulik.hen@intel.com Cc: Laurent DENIEL , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: <200308111925.38278.shmulik.hen@intel.com> References: <200308111720.38472.shmulik.hen@intel.com> <1060612481.1034.15.camel@jzny.localdomain> <200308111925.38278.shmulik.hen@intel.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1060655503.1028.47.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Aug 2003 22:31:43 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4738 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Mon, 2003-08-11 at 12:25, Shmulik Hen wrote: > Why have any kernel code other than device drivers in the first place > ? > Why not move all the TCP/IP stack out of kernel space and put it in an > application ? Lets have the entire ARP mechanism in an appliaction Of course ARP should be moved out. Infact you bring out a very good point;-> If ARP was out of the kernel a lot of the recent discussions on ARP in relation to HA would have been nonexistent. The only reason they are even being discussed its because so much of the policy exists in the kernel. [BTW, there are several ARP implementations on Linux which try to move it out of the kernel and leave some minimal functionality in the kernel]. > and let it handle everything from routing tables management to arp > negotiation while the kernel will only know how to create arp packets > that it gets from that app and send them away ? It doesn't need to > have the know how. Actually if you do this, then ARP packets need be generated in user space. > Say we do thing s your way and use the notification mechanism, how > long do you think it's going to take for the whole operation to > finish taking into consideration how the kernel runs user space > applications in comparison with kernel code? I dont have numbers. I would estimate less than a ms to go to user space, execute some simple policy config and come back. > what happens when the > system is heavily loaded ? What happens now ? > What happens if the application dies for > some reason ? What happens when the kernel oopses? ;-> > Why should the bonding driver even care about routes or firewalling ? I gave those as examples of policies that could be executed. There are many reasons why you would wanna do a route redirection should a specific link fail, most important being for path availability which is a layer above link availability. Again, this is just an example, i may wanna slice bread everytime a link goes down and add butter every time one comes up. Ridiculuos as that may sound, point is you cant predict what i wanna do with such events. > It's only meant to group several physical ethernet devices and group > them under one logical device to handle teaming solutions. yes, those are basic services. You need to allow for more interesting things. cheers, jamal From hadi@cyberus.ca Mon Aug 11 19:33:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 19:33:35 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7C2XVFl028438 for ; Mon, 11 Aug 2003 19:33:31 -0700 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.12) id 19mOyY-000JmU-00; Mon, 11 Aug 2003 22:33:30 -0400 Subject: Re: [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master'ssettings toslaves From: jamal Reply-To: hadi@cyberus.ca To: Laurent DENIEL Cc: Jeff Garzik , shmulik.hen@intel.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: <3F37D2ED.B4B9223C@thalesatm.com> References: <200308111720.38472.shmulik.hen@intel.com> <1060612481.1034.15.camel@jzny.localdomain> <200308111925.38278.shmulik.hen@intel.com> <3F37C7C3.7070807@pobox.com> <3F37D2ED.B4B9223C@thalesatm.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1060655579.1027.51.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Aug 2003 22:32:59 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4739 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Mon, 2003-08-11 at 13:31, Laurent DENIEL wrote: > But I agree that it is interesting to do some stuff at user land, and if > the bonding had an option to disable the automatic failover policy, > this could be implemented with trigger towards user land application that > could use an ioctl call to switch to the appropriate NIC according to You spoilt otherwise sane text by mentioning ioctl;-> > But the fast and simple failover policy shall remain in kernel code. nod from here. Simple failover policies should stay in the kernel. cheers, jamal From hadi@cyberus.ca Mon Aug 11 19:36:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 19:36:45 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7C2aeFl028916 for ; Mon, 11 Aug 2003 19:36:41 -0700 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.12) id 19mP1b-000K1C-00; Mon, 11 Aug 2003 22:36:39 -0400 Subject: Re: [SET 2][PATCH 2/8][bonding] Propagating master's settings to slaves From: jamal Reply-To: hadi@cyberus.ca To: shmulik.hen@intel.com Cc: Jay Vosburgh , Jeff Garzik , Laurent DENIEL , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: <200308120215.18234.shmulik.hen@intel.com> References: <200308112141.h7BLftpS015012@death.ibm.com> <200308120215.18234.shmulik.hen@intel.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1060655768.1029.57.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Aug 2003 22:36:08 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4740 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Shmulik, the only discussion as far as i know is the one that happened in this thread. I have not seen any discussion before. Folks, I really didnt mean to start such a long thread ;-> cheers, jamal On Mon, 2003-08-11 at 19:15, Shmulik Hen wrote: > May I remind you all that the original discussion was only about > stuff that has to do with configuration time. There was no mention of > any run time code. ifenslave only does three simple things - add a > slave, remove a slave and set the current active slave, that's all. > > The drive was to try and make ifenslave slimmer regarding those three > operations only in the way that any setting of the slave will be done > by the kernel module instead of the configuration application. There > is no real "brain" there anyway. > > We had some experience with creating an configuration application that > was incredibly smart and was always aware of what was going on in the > driver and could make all possible decisions before even attempting > to access the driver so it could fail the operation without > "bothering" the driver. It's gigantic. It's extremely hard to install > and configure. It's even harder to maintain. And all it was meant to > do is configuration. Imagine what would happen if it was also > supposed to handle run time issues. > > I am not aware of anything like moving kernel code into applications. > Was that something that was discussed in OLS ? Where can I find some > more info about this trend ? > > > Shmulik. > > From hadi@cyberus.ca Mon Aug 11 19:57:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 19:57:47 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7C2veFl029312 for ; Mon, 11 Aug 2003 19:57:41 -0700 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.12) id 19mPLw-000Lpj-00; Mon, 11 Aug 2003 22:57:40 -0400 Subject: Re: [RFC] High Performance Packet Classifiction for tc framework From: jamal Reply-To: hadi@cyberus.ca To: Michael Bellion and Thomas Heinz Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <3F381B3E.6080807@hipac.org> References: <200307141045.40999.nf@hipac.org> <1058328537.1797.24.camel@jzny.localdomain> <3F16A0E5.1080007@hipac.org> <1059934468.1103.41.camel@jzny.localdomain> <3F2E5CD6.4030500@hipac.org> <1060012260.1103.380.camel@jzny.localdomain> <3F302E04.1090503@hipac.org> <1060286331.1025.73.camel@jzny.localdomain> <3F381B3E.6080807@hipac.org> Content-Type: text/plain Organization: jamalopolis Message-Id: <1060657028.1028.79.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Aug 2003 22:57:08 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4741 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Hi, On Mon, 2003-08-11 at 18:39, Michael Bellion and Thomas Heinz wrote: > > It was very close ;-> The guy looked motivated i felt scared for a while > > that he will be asking a lot of questions. Then i never heard about it > > again ;-> I think he left town too. > > Too bad, you should have told the guy about all the fame > and glory ;-) > Some fires scare even brave firemen. This was a brave fireman until he saw the fire ;-> [..] > > This is a fundamental issue related to the use of hashes in this > context. It shows that it is _impossible_ to create a hash which > meets the requirement of O(1) rules per bucket in the setting > described above regardless how clever you choose the hash function. > > What do you think about it? Do you agree? > I have to go back and read the theory again to fully comprehend it but intutively you are right. I claim that if you knew your input well then you could construct a hash which will closely approach perfect hashing. So if i was to use the example you gave me earlier i could approximate a o(1) hash. u32 allows me to do so once i know how things will look like. Of course i have to do that mnaully with a pencil and paper. > > >>BTW, this approach can be extended to 2 or more dimensions > >>where the hash function for each hash has to meet the > >>requirement. Of course this information is not very helpful > >>since the problem of defining appropriate hash functions > >>remains ;) > > > > Is that problem even solvable? > > Well, one could argue that the _problem_ is not precisely > defined to answer this question since "easily (= fast) > computable hash function" is rather spongy. > > Ignoring the "fast computable" requirement, the problem > is solvable simply because the hash function is finite ... > but again this does not help a bit ;-) > > So, do you agree that it is _impossible_ to express arbitrary > access lists using the hash tree approach if each hash bucket > is required to hold O(1) rules? > [You already agreed that this requirement is needed for the > tree of hashes to perform optimally.] > yes. But note the caveat i put above on knowing the input and being able to manually use a pencil to map out the hash. Now automate the pencil and paper and let some cpu analyse the traffic patterns as well as adjust the hashes ... maybe a thesis for someone. > > This is why i was wondering how fast your instertions and deletions are. > > Seems to me you will have to sort the rules everytime. > > No, there is no sorting of rules involved. Each rule insert > operation inserts the native matches of the rule into the > (dim)tree. > I will have to cathup with you at some point - i think i understand what you mean. > > Dont you think this "dynamic adjustment" is unnecessary. Essentially you > > enforce a model where every rule is a different priority. > > Well, we consider the model beneficial for the user. > First of all the requirement is also present in the > classical PCP definition ;) and secondly it supports > dynamic rulesets better because using static priorities > you ran into the problem of redefining a lot of prios > manually sooner or later. > well, with the iptables scheme at least you need to know where to insert the rules; so theres some manual labor involved there as well ;-> Out of curiosity with such a model how do you define a default rule? In the prio model(and tc), you can have a default catchall rule in the lowest priority, this way should higher prios fail this will catchall. [..] > > > > I am not sure i understood the part about ignoring tcf_result. > > If there would be no tcf_result then classifiers are > simply matches, e.g. like iptables matches. They don't have > an action associated with them. In iptables, from a technical > viewpoint you could say that a target is basically the same > as a match with an action attached to it. > Ok, i see your point, so you are saying that a tcf_result is infact a hardcoded action which should probably be called "setclassid". Interesting thought. [..] > > But could you not have > > the filters repeat the same classid for every filter? > > Each rule can only have one action or return "value" > attached to it so if we want to use embedded classifiers > (as matches) their classid (= action) must be ignored. you want the "continue" action essentially. > The reason why we want to have several non-native > matches in one rule is to allow the expression of a > conjunction of these matches. This is not possible using > several rules. I think i finally see your point. Yes, this could be an improvement that could be made to tc. Infact you have motivated me to write a "setclassid" action which will override the classid defined otherwise. cheers, jamal From scott.feldman@intel.com Mon Aug 11 21:23:08 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 21:23:16 -0700 (PDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7C4N6Fl030512 for ; Mon, 11 Aug 2003 21:23:07 -0700 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h7C4Gu923940 for ; Tue, 12 Aug 2003 04:16:56 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h7C4Hxo26787 for ; Tue, 12 Aug 2003 04:17:59 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003081121351909128 ; Mon, 11 Aug 2003 21:35:19 -0700 Received: from orsmsx402.amr.corp.intel.com ([192.168.65.208]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 11 Aug 2003 21:23:00 -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: new SiS gige driver Date: Mon, 11 Aug 2003 21:22:59 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new SiS gige driver Thread-Index: AcNd1G7PeDuKEDq1SpaE+/kujooL8QCopoJA From: "Feldman, Scott" To: "Jeff Garzik" , X-OriginalArrivalTime: 12 Aug 2003 04:23:00.0686 (UTC) FILETIME=[6A4F16E0:01C36089] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7C4N6Fl030512 X-archive-position: 4742 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 Time to give something back: * sis190_pci_driver.remove should be __devexit_p() * suspend/resume important in today's world? * SiS190_get_stats is defined static but declared non-static. A little rearranging would eliminate the need for forward declarations, thus avoiding this issue. * // comments * Missing KERN_XXX on some printk's. * err_out does unregister_netdev() in _init_board before register_netdev(). * In _remove_one, no pci_disable_device(). * _open: cleanup on RxBufferRings failure is missing - no error return or cleanup. * _hw_start: pretty scary magic numbers. * Comment on sis190_private.curr_tx says "Rx". * Modulo operator on ring indexes is expensive on some archs. * _start_xmit: setting PSize can just use skb->len since already skb_padto. * MODULE_PARAM(media) isn't used. Then goes MAX_UNITS. * no big-endian support. * no NETIF_MSG_xxx or msg_enable suppport. * Add class net ethernet restiction to sis190_pci_tbl[]. * Use PCI_VENDOR_ID_SI for 0x1039 in sis190_pci_tbl[]. * Use ETH_ALEN for MAC_ADDR_LEN. * MAX_ETH_FRAME_SIZE isn't used. * TX_FIFO_THRESH and TX_DMA_BURST aren't used. * EarlyTxThld, RxPacketMaxSize, InterFrameGap aren't used. * not sure why there is a cast on SiS_R32(reg) using (unsigned long)? * [Ouch!] Is that a skb_copy_and_sum in the Rx path? That's going to hurt performance. Looks like RxDescArray[].buf_addr could point to a pci_map_single(skb). * Alternatively, in _rx_interurpt, why keep setting RxDescArray.buf_addr? Maybe h/w erases the previous value? * _interrupt: handled is never set to 1. * ____cacheline_aligned sis190_private. -scott From davem@redhat.com Mon Aug 11 22:32:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 22:32: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 h7C5WHFl031813 for ; Mon, 11 Aug 2003 22:32:18 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id WAA14097; Mon, 11 Aug 2003 22:26:34 -0700 Date: Mon, 11 Aug 2003 22:26:33 -0700 From: "David S. Miller" To: YOSHIFUJI Hideaki Cc: davej@redhat.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] Missing break in switch statement. Message-Id: <20030811222633.13f6759c.davem@redhat.com> In-Reply-To: <20030812.021414.128414948.yoshfuji@hongo.wide.ad.jp> References: <20030812.021414.128414948.yoshfuji@hongo.wide.ad.jp> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4743 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 12 Aug 2003 02:14:14 +0900 (JST) YOSHIFUJI Hideaki wrote: > In article (at Mon, 11 Aug 2003 17:48:57 +0100), davej@redhat.com says: > > > Is this intentional? It should at least have a > > /* FALLTHROUGH */ or similar if so. > > Of course not. Patch applied, thanks David. From davem@redhat.com Mon Aug 11 22:35:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 22:35:06 -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 h7C5Z2Fl032172 for ; Mon, 11 Aug 2003 22:35:03 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id WAA14123; Mon, 11 Aug 2003 22:29:25 -0700 Date: Mon, 11 Aug 2003 22:29:24 -0700 From: "David S. Miller" To: davej@redhat.com Cc: netdev@oss.sgi.com Subject: Re: [PATCH] ipv4 reuses freed mem Message-Id: <20030811222924.5ea129bd.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4744 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 11 Aug 2003 17:48:57 +0100 davej@redhat.com wrote: > cat /proc/net/pnp will return garbage, as the fields it > dumps are initdata. Applied, thanks David. From davem@redhat.com Mon Aug 11 22:36:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 22:36:17 -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 h7C5aEFl032498 for ; Mon, 11 Aug 2003 22:36:14 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id WAA14148; Mon, 11 Aug 2003 22:30:36 -0700 Date: Mon, 11 Aug 2003 22:30:36 -0700 From: "David S. Miller" To: davej@redhat.com Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Duplicate access_ok in sunrpc Message-Id: <20030811223036.0f12522a.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4745 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 11 Aug 2003 17:48:57 +0100 davej@redhat.com wrote: > Already checked some lines above. Applied, thanks David. From davem@redhat.com Mon Aug 11 22:46:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 22:46:41 -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 h7C5kXFl000438 for ; Mon, 11 Aug 2003 22:46:33 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id WAA14203; Mon, 11 Aug 2003 22:40:50 -0700 Date: Mon, 11 Aug 2003 22:40:50 -0700 From: "David S. Miller" To: Michael Bellion and Thomas Heinz Cc: hadi@cyberus.ca, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [RFC] High Performance Packet Classifiction for tc framework Message-Id: <20030811224050.59bc36fe.davem@redhat.com> In-Reply-To: <3F381B3E.6080807@hipac.org> References: <200307141045.40999.nf@hipac.org> <1058328537.1797.24.camel@jzny.localdomain> <3F16A0E5.1080007@hipac.org> <1059934468.1103.41.camel@jzny.localdomain> <3F2E5CD6.4030500@hipac.org> <1060012260.1103.380.camel@jzny.localdomain> <3F302E04.1090503@hipac.org> <1060286331.1025.73.camel@jzny.localdomain> <3F381B3E.6080807@hipac.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4746 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 12 Aug 2003 00:39:58 +0200 Michael Bellion and Thomas Heinz wrote: > This is a fundamental issue related to the use of hashes in this > context. It shows that it is _impossible_ to create a hash which > meets the requirement of O(1) rules per bucket in the setting > described above regardless how clever you choose the hash function. > > What do you think about it? Do you agree? The ipv4 FIB hash tables tackle exactly this problem. The resulting worse cast complexity is O(n_bits_in_prefix_mask). The problem you've described is exactly the same as trying to use hashing for routing tables. From davem@redhat.com Mon Aug 11 22:53:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 22:53:58 -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 h7C5rrFl000828 for ; Mon, 11 Aug 2003 22:53:53 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id WAA14253; Mon, 11 Aug 2003 22:48:06 -0700 Date: Mon, 11 Aug 2003 22:48:05 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: jreuter@yaina.de, linux-hams@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] Update bpqether for 2.6 Message-Id: <20030811224805.77439de5.davem@redhat.com> In-Reply-To: <20030811162205.78b2029f.shemminger@osdl.org> References: <20030811162205.78b2029f.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4747 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 11 Aug 2003 16:22:05 -0700 Stephen Hemminger wrote: > This patch fixes several issues with drivers/net/hamradio/bpqether.c in 2.6.0-test3. Applied, thanks. From davem@redhat.com Mon Aug 11 22:54:32 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 22:54:35 -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 h7C5sVFl001070 for ; Mon, 11 Aug 2003 22:54:31 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id WAA14263; Mon, 11 Aug 2003 22:48:51 -0700 Date: Mon, 11 Aug 2003 22:48:51 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: maxk@qualcomm.com, netdev@oss.sgi.com Subject: Re: [RFT][PATCH] Convert bluetooth to dynamic net_device. Message-Id: <20030811224851.18d41430.davem@redhat.com> In-Reply-To: <20030811115334.4bd4521a.shemminger@osdl.org> References: <20030811115334.4bd4521a.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4748 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 11 Aug 2003 11:53:34 -0700 Stephen Hemminger wrote: > Since the initialization code changed slightly, I would like to have > someone do a basic sanity test before it is merged. Ok, ping me when you believe this has occurred :-) From davem@redhat.com Mon Aug 11 22:55:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 22:55: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 h7C5tXFl001487 for ; Mon, 11 Aug 2003 22:55:34 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id WAA14273; Mon, 11 Aug 2003 22:49:45 -0700 Date: Mon, 11 Aug 2003 22:49:44 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: chas@cmf.nrl.navy.mil, netdev@oss.sgi.com Subject: Re: [RFT][PATCH] cleanup net/atm/br2684.c Message-Id: <20030811224944.5544caf3.davem@redhat.com> In-Reply-To: <20030811114823.5b81474c.shemminger@osdl.org> References: <20030811114823.5b81474c.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4749 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 11 Aug 2003 11:48:23 -0700 Stephen Hemminger wrote: > I fixed up some things in br2684 but don't have ATM hardware to test it well enough. > The patch is against 2.6.0-test3 and module loads/unloads fine. I'll wait until Chas either ACKs this or sends it to me under seperate cover. Thanks. From laurent.deniel@thalesatm.com Mon Aug 11 23:31:48 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 11 Aug 2003 23:31:54 -0700 (PDT) Received: from gwsmtp.thomson-csf.com (gwsmtp.thomson-csf.com [195.101.39.226]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7C6VkFl002511 for ; Mon, 11 Aug 2003 23:31:48 -0700 Received: from thalescan.corp.thales (200.3.2.3) by gwsmtp.thomson-csf.com (NPlex 6.5.026) id 3F3761E400015F0C for netdev@oss.sgi.com; Tue, 12 Aug 2003 08:31:40 +0200 Received: from bgxplex.bgx.airsys.thomson-csf.com ([220.1.107.25]) by thalescan with InterScan Messaging Security Suite; Tue, 12 Aug 2003 08:31:35 +0200 Received: from bgxplex2.bgx.airsys.thomson-csf.com (1.38.9.152) by bgxplex.bgx.airsys.thomson-csf.com (NPlex 6.5.026) id 3F15565F0003B87B; Tue, 12 Aug 2003 08:31:49 +0200 Received: from bgxplex2.bgx.airsys.thomson-csf.com (1.38.9.152) by bgxplex2.bgx.airsys.thomson-csf.com (NPlex 6.5.026) id 3F370B62000020EF; Tue, 12 Aug 2003 08:31:34 +0200 Received: from 200.64.130.8 by bgxplex2.bgx.airsys.thomson-csf.com (InterScan E-Mail VirusWall NT); Tue, 12 Aug 2003 08:31:34 +0200 Message-ID: <3F3889C7.1B4EC2BE@thalesatm.com> Date: Tue, 12 Aug 2003 08:31:35 +0200 From: Laurent DENIEL Organization: THALES ATM X-Mailer: Mozilla 4.75 [fr] (Windows NT 5.0; U) X-Accept-Language: fr,en-GB MIME-Version: 1.0 To: Jeff Garzik CC: shmulik.hen@intel.com, hadi@cyberus.ca, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master'ssettings toslaves References: <200308111720.38472.shmulik.hen@intel.com> <1060612481.1034.15.camel@jzny.localdomain> <200308111925.38278.shmulik.hen@intel.com> <3F37C7C3.7070807@pobox.com> <3F37D2ED.B4B9223C@thalesatm.com> <3F37D5BF.8000702@pobox.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by oss.sgi.com id h7C6VkFl002511 X-archive-position: 4750 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laurent.deniel@thalesatm.com Precedence: bulk X-list: netdev Jeff Garzik a écrit : > > > You forgot one important aspect : > > > > (4) does moving code to userspace break compatibility (or behavior) > > with user land applications (or systems) > > I agree... assuming these userland interfaces are fairly standard and > widely deployed. > > > What can one do if say, kernel 2.[4|5] switches the NIC in 10 mseconds > > while kernel 2.7 with user land daemon switches in a few seconds ? > > nothing but stay with the previous version or fork the driver development ;-( > > This is a silly example. If that happens in practice, then that is a > bug in the configuration of the userland daemon, or a bug in the > kernel<->userland ABI. Not a silly example but a real case that happened to me with another operating system and I'd hate if it happens also with Linux ... > > But I agree that it is interesting to do some stuff at user land, and if > > the bonding had an option to disable the automatic failover policy, > > this could be implemented with trigger towards user land application that > > could use an ioctl call to switch to the appropriate NIC according to > > the user lan configuration ... > > Remember, ioctls are bad. :) Unix design mistake. ioctl (which already exist) or something else, this is not the point here. > > what happens when the > > system is heavily loaded ? > > What happens now ? > > > What happens if the application dies for > > some reason ? > > What happens when the kernel oopses? ;-> Such silly responses make me think that it is no longer worth to argue ... Laurent From hadi@cyberus.ca Tue Aug 12 05:59:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 05:59:56 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CCxnFl015851 for ; Tue, 12 Aug 2003 05:59:49 -0700 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.12) id 19mYke-000BB1-00; Tue, 12 Aug 2003 08:59:49 -0400 Subject: Re: [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master'ssettings toslaves From: jamal Reply-To: hadi@cyberus.ca To: Laurent DENIEL Cc: Jeff Garzik , shmulik.hen@intel.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: <3F3889C7.1B4EC2BE@thalesatm.com> References: <200308111720.38472.shmulik.hen@intel.com> <1060612481.1034.15.camel@jzny.localdomain> <200308111925.38278.shmulik.hen@intel.com> <3F37C7C3.7070807@pobox.com> <3F37D2ED.B4B9223C@thalesatm.com> <3F37D5BF.8000702@pobox.com> <3F3889C7.1B4EC2BE@thalesatm.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1060693157.1027.87.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 12 Aug 2003 08:59:17 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4751 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Tue, 2003-08-12 at 02:31, Laurent DENIEL wrote: > > > What happens if the application dies for > > > some reason ? > > > > What happens when the kernel oopses? ;-> > > Such silly responses make me think that it is no longer worth to argue ... > You dont think asking "what if the application dies" is in the same calibre as "what happens when the kernel oopses"? cheers, jamal From davem@redhat.com Tue Aug 12 06:17:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 06:17: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 h7CDHaFl016372 for ; Tue, 12 Aug 2003 06:17:37 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id GAA15193; Tue, 12 Aug 2003 06:08:45 -0700 Date: Tue, 12 Aug 2003 06:08:45 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: laurent.deniel@thalesatm.com, jgarzik@pobox.com, shmulik.hen@intel.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master'ssettings toslaves Message-Id: <20030812060845.0e0ba2e8.davem@redhat.com> In-Reply-To: <1060693157.1027.87.camel@jzny.localdomain> References: <200308111720.38472.shmulik.hen@intel.com> <1060612481.1034.15.camel@jzny.localdomain> <200308111925.38278.shmulik.hen@intel.com> <3F37C7C3.7070807@pobox.com> <3F37D2ED.B4B9223C@thalesatm.com> <3F37D5BF.8000702@pobox.com> <3F3889C7.1B4EC2BE@thalesatm.com> <1060693157.1027.87.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4752 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On 12 Aug 2003 08:59:17 -0400 jamal wrote: > You dont think asking "what if the application dies" is in the same > calibre as "what happens when the kernel oopses"? Don't sweat it Jamal, some people just don't get it :-) Look, people, when userlevel routing daemon dies your system effectively stops to route. There is zero difference between that example and the ones we are discussing here. Policy belongs strictly at user space. One of the great things about what Jamal spends his time working on is finally a strict seperation of the control layer from everything else. And part of this is moving all of the control logic into userspace. Once that is accomplished, I can have my toilet flush every time a TCP packet is routed through my system and this won't crap up the kernel. If you don't see the value in that, perhaps you shouldn't be partaking in this discussion :-) From sasa@balabit.hu Tue Aug 12 06:20:56 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 06:21:00 -0700 (PDT) Received: from balabit.hu (catv-d5dea83f.bp11catv.broadband.hu [213.222.168.63]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CDKrFl016714 for ; Tue, 12 Aug 2003 06:20:55 -0700 Received: from mail (newmail.balabit [192.168.131.4]) by balabit.hu (Postfix) with ESMTP id 34576BB453 for ; Tue, 12 Aug 2003 15:20:52 +0200 (CEST) Received: by mail (Postfix, from userid 103) id 6ED0A18388; Tue, 12 Aug 2003 15:20:51 +0200 (CEST) Received: from mochrul.balabit (mochrul.balabit [192.168.131.42]) by mail (Postfix) with ESMTP id DE2141836D for ; Tue, 12 Aug 2003 15:20:50 +0200 (CEST) Received: from sasa by mochrul.balabit with local (Exim 3.35 #1 (Debian)) id 19mZ50-000751-00 for ; Tue, 12 Aug 2003 15:20:50 +0200 Date: Tue, 12 Aug 2003 15:20:50 +0200 From: SZALAY Attila To: netdev@oss.sgi.com Subject: Problem with __check_and_rekey Message-ID: <20030812132050.GA27178@mochrul.balabit> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.3.28i X-archive-position: 4753 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sasa@balabit.hu Precedence: bulk X-list: netdev Hi All! We have found a deadlock in kernel version 2.4.21. With sysreq we get this call trace: Trace; c01a9946 Trace; c0256cbc [...] Trace; c023e890 Trace; c022c88b Trace; c022c939 Trace; c022ca6f Trace; c011ee3d Trace; c010a2eb Trace; c01a88e7 Trace; c01a8b04 Trace; c01a8c6b Trace; c01a98c8 <__check_and_rekey+5c/88> Trace; c01a9946 Trace; c02559cd Trace; c026304d Trace; c0225de7 Trace; c0262482 First call of __check_and_rekey locks ip_lock. But when we harvest entropy, there is an interrupt triggered by an incoming packet. Because of the incoming SYN packet we try to generate another sequence number. Hovewer ip_lock is already locked... We created this patch to avoid the problem: --- tcp_ipv4.c~ Tue Jun 24 22:44:52 2003 +++ tcp_ipv4.c Tue Aug 12 14:21:33 2003 @@ -872,8 +872,10 @@ tp->write_seq = ip_randomisn(); else #endif + local_bh_disable(); tp->write_seq = secure_tcp_sequence_number(sk->saddr, sk->daddr, sk->sport, usin->sin_port); + local_bh_enable(); } #ifdef CONFIG_GRKERNSEC_RANDID -- Szalay Attila BalaBit IT Biztonságtechnikai Kft. tel:(36-1)-371-05-40 1116 Bp. Csurgoi ut 20/b fax:(36-1)-208-08-75 http://www.balabit.hu/ From yoshfuji@linux-ipv6.org Tue Aug 12 06:55:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 06:55:34 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CDtQFl017520 for ; Tue, 12 Aug 2003 06:55:27 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h7CDtR1M019592; Tue, 12 Aug 2003 22:55:28 +0900 Date: Tue, 12 Aug 2003 22:55:27 +0900 (JST) Message-Id: <20030812.225527.35784879.yoshfuji@linux-ipv6.org> To: sasa@balabit.hu Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: Problem with __check_and_rekey From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20030812132050.GA27178@mochrul.balabit> References: <20030812132050.GA27178@mochrul.balabit> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4754 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <20030812132050.GA27178@mochrul.balabit> (at Tue, 12 Aug 2003 15:20:50 +0200), SZALAY Attila says: > We created this patch to avoid the problem: > > --- tcp_ipv4.c~ Tue Jun 24 22:44:52 2003 > +++ tcp_ipv4.c Tue Aug 12 14:21:33 2003 > @@ -872,8 +872,10 @@ > tp->write_seq = ip_randomisn(); > else > #endif > + local_bh_disable(); > tp->write_seq = secure_tcp_sequence_number(sk->saddr, sk->daddr, > sk->sport, usin->sin_port); > + local_bh_enable(); > } > > #ifdef CONFIG_GRKERNSEC_RANDID > You must forgot braces. But anyway, I can't find these lines in linux-2.4.21 (or even in 2.6.x). Are you sure you're working on the vanilla kernel? -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From davem@redhat.com Tue Aug 12 06:59:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 06:59:41 -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 h7CDxXFl017893 for ; Tue, 12 Aug 2003 06:59:34 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id GAA15298; Tue, 12 Aug 2003 06:53:47 -0700 Date: Tue, 12 Aug 2003 06:53:46 -0700 From: "David S. Miller" To: "YOSHIFUJI Hideaki / _$B5HF#1QL@" Cc: sasa@balabit.hu, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: Problem with __check_and_rekey Message-Id: <20030812065347.331e9066.davem@redhat.com> In-Reply-To: <20030812.225527.35784879.yoshfuji@linux-ipv6.org> References: <20030812132050.GA27178@mochrul.balabit> <20030812.225527.35784879.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4755 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 12 Aug 2003 22:55:27 +0900 (JST) YOSHIFUJI Hideaki / _$B5HF#1QL@ wrote: > > + local_bh_disable(); > > tp->write_seq = secure_tcp_sequence_number(sk->saddr, sk->daddr, > > sk->sport, usin->sin_port); > > + local_bh_enable(); > > You must forgot braces. > But anyway, I can't find these lines in linux-2.4.21 (or even in 2.6.x). > Are you sure you're working on the vanilla kernel? It doesn't matter, a proper fix was put into drivers/char/random.c already. # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1019.3.9 -> 1.1019.3.10 # drivers/char/random.c 1.17 -> 1.18 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 03/07/28 olof@austin.ibm.com 1.1019.3.10 # [RANDOM]: Fix SMP deadlock in __check_and_rekey(). # -------------------------------------------- # diff -Nru a/drivers/char/random.c b/drivers/char/random.c --- a/drivers/char/random.c Tue Aug 12 06:56:52 2003 +++ b/drivers/char/random.c Tue Aug 12 06:56:52 2003 @@ -251,6 +251,8 @@ #include #include #include +#include +#include #include #include @@ -2069,7 +2071,7 @@ static struct keydata *__check_and_rekey(time_t time) { struct keydata *keyptr; - spin_lock(&ip_lock); + spin_lock_bh(&ip_lock); keyptr = &ip_keydata[ip_cnt&1]; if (!keyptr->rekey_time || (time - keyptr->rekey_time) > REKEY_INTERVAL) { keyptr = &ip_keydata[1^(ip_cnt&1)]; @@ -2079,7 +2081,7 @@ mb(); ip_cnt++; } - spin_unlock(&ip_lock); + spin_unlock_bh(&ip_lock); return keyptr; } From shmulik.hen@intel.com Tue Aug 12 07:03:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 07:03:34 -0700 (PDT) Received: from caduceus.sc.intel.com (fmr04.intel.com [143.183.121.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CE3PFl018337 for ; Tue, 12 Aug 2003 07:03:26 -0700 Received: from talaria.sc.intel.com (talaria.sc.intel.com [10.3.253.5]) by caduceus.sc.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 h7CE1wl15261 for ; Tue, 12 Aug 2003 14:01:58 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by talaria.sc.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 h7CDuxf24061 for ; Tue, 12 Aug 2003 13:56:59 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.254.188]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003081207081719250 ; Tue, 12 Aug 2003 07:08:19 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Shmulik Hen Reply-To: shmulik.hen@intel.com Organization: Intel corp. To: "David S. Miller" , Subject: Re: [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master'ssettings toslaves Date: Tue, 12 Aug 2003 17:03:15 +0300 User-Agent: KMail/1.4.3 Cc: , , , References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200308121703.15567.shmulik.hen@intel.com> X-archive-position: 4756 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev On Tuesday 12 August 2003 04:08 pm, David S. Miller wrote: > Policy belongs strictly at user space. Regarding bonding, what policies are we talking about ? run-time ? config time ? both ? other ? Our current aim is config time only. > One of the great things about what Jamal spends his time working > on is finally a strict seperation of the control layer from > everything else. And part of this is moving all of the control > logic into userspace. Once that is accomplished, I can have my > toilet flush every time a TCP packet is routed through my system > and this won't crap up the kernel. What scope are we talking about here ? 2.4 ? 2.6 ? 2.7 ? other ? Our current aim is 2.4 and 2.6. Taking into account the two statements I made above: Do you think that what we're doing right now might interfere with what Jamal is suggesting ? Wouldn't it be possible to do things the old way first and than convert everything to the new way ? Shouldn't all this be a part of a totally new project like "bonding2" -- | Shmulik Hen Advanced Network Services | | Israel Design Center, Jerusalem | | LAN Access Division, Platform Networking | | Intel Communications Group, Intel corp. | From sasa@balabit.hu Tue Aug 12 07:05:20 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 07:05:25 -0700 (PDT) Received: from balabit.hu (catv-d5dea83f.bp11catv.broadband.hu [213.222.168.63]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CE5IFl018687 for ; Tue, 12 Aug 2003 07:05:19 -0700 Received: from mail (newmail.balabit [192.168.131.4]) by balabit.hu (Postfix) with ESMTP id 5BC40BB456; Tue, 12 Aug 2003 16:05:18 +0200 (CEST) Received: by mail (Postfix, from userid 103) id 8F1BE18388; Tue, 12 Aug 2003 16:05:17 +0200 (CEST) Received: from mochrul.balabit (mochrul.balabit [192.168.131.42]) by mail (Postfix) with ESMTP id 16C651836D; Tue, 12 Aug 2003 16:05:17 +0200 (CEST) Received: from sasa by mochrul.balabit with local (Exim 3.35 #1 (Debian)) id 19mZm0-00075f-00; Tue, 12 Aug 2003 16:05:16 +0200 Date: Tue, 12 Aug 2003 16:05:16 +0200 From: SZALAY Attila To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: sasa@balabit.hu, netdev@oss.sgi.com Subject: Re: Problem with __check_and_rekey Message-ID: <20030812140516.GA27237@mochrul.balabit> References: <20030812132050.GA27178@mochrul.balabit> <20030812.225527.35784879.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20030812.225527.35784879.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.3.28i X-archive-position: 4757 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sasa@balabit.hu Precedence: bulk X-list: netdev Hi ALl! On 2003 Aug 12, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > In article <20030812132050.GA27178@mochrul.balabit> (at Tue, 12 Aug 2003 15:20:50 +0200), SZALAY Attila says: > > But anyway, I can't find these lines in linux-2.4.21 (or even in 2.6.x). > Are you sure you're working on the vanilla kernel? Sorry, no. The patch in vanilla kernel: --- tcp_ipv4.c~ Tue Aug 12 16:01:31 2003 +++ tcp_ipv4.c Tue Aug 12 16:03:35 2003 @@ -843,9 +843,12 @@ if (err) goto failure; - if (!tp->write_seq) + if (!tp->write_seq) { + local_bh_disable(); tp->write_seq = secure_tcp_sequence_number(sk->saddr, sk->daddr, sk->sport, usin->sin_port); + local_bh_enable(); + } sk->protinfo.af_inet.id = tp->write_seq^jiffies; -- Szalay Attila BalaBit IT Biztonságtechnikai Kft. tel:(36-1)-371-05-40 1116 Bp. Csurgoi ut 20/b fax:(36-1)-208-08-75 http://www.balabit.hu/ From yoshfuji@linux-ipv6.org Tue Aug 12 07:09:20 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 07:09:27 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CE9JFl019080 for ; Tue, 12 Aug 2003 07:09:20 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h7CE9T1M019686; Tue, 12 Aug 2003 23:09:29 +0900 Date: Tue, 12 Aug 2003 23:09:29 +0900 (JST) Message-Id: <20030812.230929.57895537.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: sasa@balabit.hu, netdev@oss.sgi.com Subject: Re: Problem with __check_and_rekey From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20030812065347.331e9066.davem@redhat.com> References: <20030812132050.GA27178@mochrul.balabit> <20030812.225527.35784879.yoshfuji@linux-ipv6.org> <20030812065347.331e9066.davem@redhat.com> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4758 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <20030812065347.331e9066.davem@redhat.com> (at Tue, 12 Aug 2003 06:53:46 -0700), "David S. Miller" says: > It doesn't matter, a proper fix was put into drivers/char/random.c > already. : > - spin_lock(&ip_lock); > + spin_lock_bh(&ip_lock); : > - spin_unlock(&ip_lock); > + spin_unlock_bh(&ip_lock); > return keyptr; Ah, exactly. Thanks for information. --yoshfuji From davem@redhat.com Tue Aug 12 07:09:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 07:09:30 -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 h7CE9PFl019086 for ; Tue, 12 Aug 2003 07:09:26 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id HAA15339; Tue, 12 Aug 2003 07:03:40 -0700 Date: Tue, 12 Aug 2003 07:03:40 -0700 From: "David S. Miller" To: SZALAY Attila Cc: yoshfuji@linux-ipv6.org, sasa@balabit.hu, netdev@oss.sgi.com Subject: Re: Problem with __check_and_rekey Message-Id: <20030812070340.01c320d6.davem@redhat.com> In-Reply-To: <20030812140516.GA27237@mochrul.balabit> References: <20030812132050.GA27178@mochrul.balabit> <20030812.225527.35784879.yoshfuji@linux-ipv6.org> <20030812140516.GA27237@mochrul.balabit> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4759 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 12 Aug 2003 16:05:16 +0200 SZALAY Attila wrote: > The patch in vanilla kernel: As I said in another email, your patch is unnecessary and the bug has been fixed in current kernels already. From davem@redhat.com Tue Aug 12 07:10:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 07:10:28 -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 h7CEANFl019815 for ; Tue, 12 Aug 2003 07:10:23 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id HAA15349; Tue, 12 Aug 2003 07:04:14 -0700 Date: Tue, 12 Aug 2003 07:04:14 -0700 From: "David S. Miller" To: shmulik.hen@intel.com Cc: hadi@cyberus.ca, laurent.deniel@thalesatm.com, jgarzik@pobox.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master'ssettings toslaves Message-Id: <20030812070414.1e8a5e63.davem@redhat.com> In-Reply-To: <200308121703.15567.shmulik.hen@intel.com> References: <200308121703.15567.shmulik.hen@intel.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4760 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 12 Aug 2003 17:03:15 +0300 Shmulik Hen wrote: > > One of the great things about what Jamal spends his time working > > on is finally a strict seperation of the control layer from > > everything else. And part of this is moving all of the control > > logic into userspace. Once that is accomplished, I can have my > > toilet flush every time a TCP packet is routed through my system > > and this won't crap up the kernel. > > What scope are we talking about here ? > 2.4 ? 2.6 ? 2.7 ? other ? > Our current aim is 2.4 and 2.6. Jamal's work is longer term, I'll let him answer your other questions. From laurent.deniel@thalesatm.com Tue Aug 12 07:11:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 07:11:07 -0700 (PDT) Received: from gwsmtp.thomson-csf.com (gwsmtp.thomson-csf.com [195.101.39.226]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CEB1Fl020656 for ; Tue, 12 Aug 2003 07:11:02 -0700 Received: from thalescan.corp.thales (200.3.2.3) by gwsmtp.thomson-csf.com (NPlex 6.5.026) id 3F3761E4000264C0 for netdev@oss.sgi.com; Tue, 12 Aug 2003 16:10:54 +0200 Received: from bgxplex.bgx.airsys.thomson-csf.com ([220.1.107.25]) by thalescan with InterScan Messaging Security Suite; Tue, 12 Aug 2003 16:10:49 +0200 Received: from bgxplex2.bgx.airsys.thomson-csf.com (1.38.9.152) by bgxplex.bgx.airsys.thomson-csf.com (NPlex 6.5.026) id 3F15565F0003D077; Tue, 12 Aug 2003 16:11:03 +0200 Received: from bgxplex2.bgx.airsys.thomson-csf.com (1.38.9.152) by bgxplex2.bgx.airsys.thomson-csf.com (NPlex 6.5.026) id 3F370B6200003230; Tue, 12 Aug 2003 16:10:49 +0200 Received: from 200.64.130.8 by bgxplex2.bgx.airsys.thomson-csf.com (InterScan E-Mail VirusWall NT); Tue, 12 Aug 2003 16:10:49 +0200 Message-ID: <3F38F569.C1EC7769@thalesatm.com> Date: Tue, 12 Aug 2003 16:10:49 +0200 From: Laurent DENIEL Organization: THALES ATM X-Mailer: Mozilla 4.75 [fr] (Windows NT 5.0; U) X-Accept-Language: fr,en-GB MIME-Version: 1.0 To: "David S. Miller" CC: hadi@cyberus.ca, jgarzik@pobox.com, shmulik.hen@intel.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master'ssettings toslaves References: <200308111720.38472.shmulik.hen@intel.com> <1060612481.1034.15.camel@jzny.localdomain> <200308111925.38278.shmulik.hen@intel.com> <3F37C7C3.7070807@pobox.com> <3F37D2ED.B4B9223C@thalesatm.com> <3F37D5BF.8000702@pobox.com> <3F3889C7.1B4EC2BE@thalesatm.com> <1060693157.1027.87.camel@jzny.localdomain> <20030812060845.0e0ba2e8.davem@redhat.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by oss.sgi.com id h7CEB1Fl020656 X-archive-position: 4761 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laurent.deniel@thalesatm.com Precedence: bulk X-list: netdev "David S. Miller" a écrit : > > On 12 Aug 2003 08:59:17 -0400 > jamal wrote: > > > You dont think asking "what if the application dies" is in the same > > calibre as "what happens when the kernel oopses"? > > Don't sweat it Jamal, some people just don't get it :-) > > Look, people, when userlevel routing daemon dies your system > effectively stops to route. That's why in really *safe* systems, we do not use routing daemon but only static routes ;-) And there is a BIG difference : When user level daemon dies, you have to be sure that some stuff exists to monitor and recover from that situation (either by restarting the faulty deamon (if it could recover in time which I doubt with the bonding case), or by switching to a new machine in a fault tolerant configuration). With kernel ooops, there is NOTHING to do in such in such a fault tolerant systems, since the machine is unusable (this is the same as a hardware failure). But people does not understand the constraints of really safe systems. > Policy belongs strictly at user space. > > One of the great things about what Jamal spends his time working > on is finally a strict seperation of the control layer from everything > else. And part of this is moving all of the control logic into userspace. > Once that is accomplished, I can have my toilet flush every time a TCP > packet is routed through my system and this won't crap up the kernel. > > If you don't see the value in that, perhaps you shouldn't be partaking > in this discussion :-) This is OK as long as your kernel and user space stuff remains suitable for highly fault tolerant systems and which does not require big montains of user stuff to do the same as a few line of code in the kernel. Remember the aim of bonding : NIC fault tolerance or load balancing. I am not against a user space configurable policy for more complex job but the initial aim of the bonding shall remain coded in the kernel (and is only usable in the above mentioned systems in that way). Laurent From hadi@cyberus.ca Tue Aug 12 07:29:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 07:29:22 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CETGFl024402 for ; Tue, 12 Aug 2003 07:29:17 -0700 Received: from [216.209.86.2] (helo=[10.0.0.9] ident=jamal) by mail.cyberus.ca with esmtp (Exim 4.12) id 19ma9C-000M04-00; Tue, 12 Aug 2003 10:29:14 -0400 Subject: Re: [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master'ssettings toslaves From: jamal Reply-To: hadi@cyberus.ca To: shmulik.hen@intel.com Cc: "David S. Miller" , laurent.deniel@thalesatm.com, jgarzik@pobox.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: <200308121703.15567.shmulik.hen@intel.com> References: <200308121703.15567.shmulik.hen@intel.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1060698553.1063.11.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 12 Aug 2003 10:29:14 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4762 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Tue, 2003-08-12 at 10:03, Shmulik Hen wrote: > > What scope are we talking about here ? > 2.4 ? 2.6 ? 2.7 ? other ? > Our current aim is 2.4 and 2.6. > You should start thinking 2.7. > Taking into account the two statements I made above: > Do you think that what we're doing right now might interfere with what > Jamal is suggesting ? > Wouldn't it be possible to do things the old way first and than > convert everything to the new way ? > Shouldn't all this be a part of a totally new project like "bonding2" yes, this would be next gen - 2.7 or above target. cheers, jamal From laurent.deniel@thalesatm.com Tue Aug 12 07:36:52 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 07:36:56 -0700 (PDT) Received: from gwsmtp.thomson-csf.com (gwsmtp.thomson-csf.com [195.101.39.226]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CEapFl024848 for ; Tue, 12 Aug 2003 07:36:52 -0700 Received: from thalescan.corp.thales (200.3.2.3) by gwsmtp.thomson-csf.com (NPlex 6.5.026) id 3F3761E40002731F for netdev@oss.sgi.com; Tue, 12 Aug 2003 16:36:45 +0200 Received: from bgxplex.bgx.airsys.thomson-csf.com ([220.1.107.25]) by thalescan with InterScan Messaging Security Suite; Tue, 12 Aug 2003 16:36:40 +0200 Received: from bgxplex2.bgx.airsys.thomson-csf.com (1.38.9.152) by bgxplex.bgx.airsys.thomson-csf.com (NPlex 6.5.026) id 3F15565F0003D18B; Tue, 12 Aug 2003 16:36:54 +0200 Received: from bgxplex2.bgx.airsys.thomson-csf.com (1.38.9.152) by bgxplex2.bgx.airsys.thomson-csf.com (NPlex 6.5.026) id 3F370B6200003310; Tue, 12 Aug 2003 16:36:40 +0200 Received: from 200.64.130.8 by bgxplex2.bgx.airsys.thomson-csf.com (InterScan E-Mail VirusWall NT); Tue, 12 Aug 2003 16:36:40 +0200 Message-ID: <3F38FB78.4536593A@thalesatm.com> Date: Tue, 12 Aug 2003 16:36:40 +0200 From: Laurent DENIEL Organization: THALES ATM X-Mailer: Mozilla 4.75 [fr] (Windows NT 5.0; U) X-Accept-Language: fr,en-GB MIME-Version: 1.0 To: hadi@cyberus.ca CC: "David S. Miller" , jgarzik@pobox.com, shmulik.hen@intel.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master'ssettings toslaves References: <200308111720.38472.shmulik.hen@intel.com> <1060612481.1034.15.camel@jzny.localdomain> <200308111925.38278.shmulik.hen@intel.com> <3F37C7C3.7070807@pobox.com> <3F37D2ED.B4B9223C@thalesatm.com> <3F37D5BF.8000702@pobox.com> <3F3889C7.1B4EC2BE@thalesatm.com> <1060693157.1027.87.camel@jzny.localdomain> <20030812060845.0e0ba2e8.davem@redhat.com> <3F38F569.C1EC7769@thalesatm.com> <1060698412.1063.7.camel@jzny.localdomain> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by oss.sgi.com id h7CEapFl024848 X-archive-position: 4763 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laurent.deniel@thalesatm.com Precedence: bulk X-list: netdev jamal a écrit : > > On Tue, 2003-08-12 at 10:10, Laurent DENIEL wrote: > > "David S. Miller" a écrit : > > > That's why in really *safe* systems, we do not use routing daemon > > but only static routes ;-) > > > > And there is a BIG difference : > > > > When user level daemon dies, you have to be sure that some stuff > > exists to monitor and recover from that situation (either by > > restarting the faulty deamon (if it could recover in time which > > I doubt with the bonding case), or by switching to a new machine > > in a fault tolerant configuration). With kernel ooops, there is > > NOTHING to do in such in such a fault tolerant systems, since the > > machine is unusable (this is the same as a hardware failure). > > > > But people does not understand the constraints of really safe > > systems. > > > > We have hardware watchdog timers to put the kernel into a known state by > rebooting. If you were not aware of all these RAS efforts on Linux > (projects like kexec for example) I suggest you start looking at them. I am aware of this great stuff but see below. > The kernel will oops and the app will die because of one thing: _A > software bug_. It doesnt matter what causes the death of the kernel or > app ( a misconfig for example causing a broadcast loop making the app > die is a bug). > If you want a safe system then you donot trust software neither do you > trust hardware - You must have workarounds incase they go beserk. Heck > the only entity you should trust is God and thats assuming you believe > in God. Hardware / software watchdogs are great but do not necessarily solve all problems especially where timing constraints are important. I prefer to rely on the timing of the bonding kernel code to switch NIC in milli seconds that to wait seconds or minutes that a user space daemon have the hand to handle the problem (and yes, I am aware of real time class scheduling and so on, but you say don't trust the software, and I agree so I prefer a direct kernel hang than nothing or something too late (software watchdog will not help in that case). Laurent From shmulik.hen@intel.com Tue Aug 12 07:51:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 07:51:39 -0700 (PDT) Received: from caduceus.sc.intel.com (fmr04.intel.com [143.183.121.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CEpXFl025378 for ; Tue, 12 Aug 2003 07:51:33 -0700 Received: from talaria.sc.intel.com (talaria.sc.intel.com [10.3.253.5]) by caduceus.sc.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 h7CEo6l17051 for ; Tue, 12 Aug 2003 14:50:06 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by talaria.sc.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 h7CEj6f26708 for ; Tue, 12 Aug 2003 14:45:06 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.254.188]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003081207562419069 ; Tue, 12 Aug 2003 07:56:26 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Shmulik Hen Reply-To: shmulik.hen@intel.com Organization: Intel corp. To: Subject: Re: [SET 2][PATCH 2/8][bonding] Propagating master'ssettings toslaves Date: Tue, 12 Aug 2003 17:51:22 +0300 User-Agent: KMail/1.4.3 Cc: "David S. Miller" , , , , References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200308121751.22724.shmulik.hen@intel.com> X-archive-position: 4764 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev On Tuesday 12 August 2003 05:29 pm, jamal wrote: [copied from another thread] > Some of this bonding stuff is pretty scary. > > You should start thinking 2.7. > I stand corrected. From your original replay above, I thought you meant we're doing this all wrong for the current implementation. > > Taking into account the two statements I made above: > > Do you think that what we're doing right now might interfere with > > what Jamal is suggesting ? > > Wouldn't it be possible to do things the old way first and than > > convert everything to the new way ? > > Shouldn't all this be a part of a totally new project like > > "bonding2" > > yes, this would be next gen - 2.7 or above target. I read your answer, yes, but for which question :) -- | Shmulik Hen Advanced Network Services | | Israel Design Center, Jerusalem | | LAN Access Division, Platform Networking | | Intel Communications Group, Intel corp. | From nf@hipac.org Tue Aug 12 07:58:06 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 07:58:14 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [62.67.200.157]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CEw4Fl025777 for ; Tue, 12 Aug 2003 07:58:05 -0700 Received: (qmail 31050 invoked from network); 12 Aug 2003 14:58:03 -0000 Received: from unknown (HELO portal.lan) (134300@[80.138.220.216]) (envelope-sender ) by smtprelay02.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 12 Aug 2003 14:58:03 -0000 Received: from hipac.org (tmobile.lan [192.168.0.6]) by portal.lan (Postfix) with ESMTP id EB17F4B493; Tue, 12 Aug 2003 15:18:35 +0200 (CEST) Message-ID: <3F390021.5040705@hipac.org> Date: Tue, 12 Aug 2003 16:56:33 +0200 From: Michael Bellion and Thomas Heinz User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.4) Gecko/20030714 Debian/1.4-2 X-Accept-Language: de, en MIME-Version: 1.0 To: "David S. Miller" Cc: hadi@cyberus.ca, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [RFC] High Performance Packet Classifiction for tc framework References: <200307141045.40999.nf@hipac.org> <1058328537.1797.24.camel@jzny.localdomain> <3F16A0E5.1080007@hipac.org> <1059934468.1103.41.camel@jzny.localdomain> <3F2E5CD6.4030500@hipac.org> <1060012260.1103.380.camel@jzny.localdomain> <3F302E04.1090503@hipac.org> <1060286331.1025.73.camel@jzny.localdomain> <3F381B3E.6080807@hipac.org> <20030811224050.59bc36fe.davem@redhat.com> In-Reply-To: <20030811224050.59bc36fe.davem@redhat.com> X-Enigmail-Version: 0.76.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig55A077B958DF8779F8D68BBA" X-archive-position: 4765 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nf@hipac.org Precedence: bulk X-list: netdev This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig55A077B958DF8779F8D68BBA Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi David You wrote: > The ipv4 FIB hash tables tackle exactly this problem. The resulting > worse cast complexity is O(n_bits_in_prefix_mask). > > The problem you've described is exactly the same as trying to use > hashing for routing tables. Yes, that's true for the 1-dimensional case. You refer to the following algorithm, don't you? min_prio := infinity match_rule := nil for all list_entries e: { // at most w+1 entries where w is the bit // width of the keys rule = lookup(hash(e), packet) // let's assume O(1) here if (prio(rule) < min_prio) { min_prio = prio(rule) match_rule = rule } } return match_rule This algorithm has running time O(w). [In fact it's O(number of different prefix lengths) which is O(w) in the worst case.] But what about the d-dimensional case? If you extend this approach to handle rules with d prefix based matches you end up in a running time of: O(w^d) (assuming w to be the max. bit width) This is definitely not desirable. Regards, +-----------------------+----------------------+ | Michael Bellion | Thomas Heinz | | | | +-----------------------+----------------------+ | High Performance Packet Classification | | nf-hipac: http://www.hipac.org/ | +----------------------------------------------+ --------------enig55A077B958DF8779F8D68BBA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQE/OQAhtXh2AYIMjggRAgg6AJ9jY3FJa4irGLO40byWJQIU6+/hmQCfd/xv p0o5BtK8fQlHpIQ5tUnu8Iw= =Ck7A -----END PGP SIGNATURE----- --------------enig55A077B958DF8779F8D68BBA-- From hadi@cyberus.ca Tue Aug 12 08:05:57 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 08:06:03 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CF5uFl026229 for ; Tue, 12 Aug 2003 08:05:57 -0700 Received: from [216.209.86.2] (helo=[10.0.0.9] ident=jamal) by mail.cyberus.ca with esmtp (Exim 4.12) id 19maih-0000Ho-00; Tue, 12 Aug 2003 11:05:55 -0400 Subject: Re: [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master'ssettings toslaves From: jamal Reply-To: hadi@cyberus.ca To: Laurent DENIEL Cc: "David S. Miller" , jgarzik@pobox.com, shmulik.hen@intel.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: <3F38FB78.4536593A@thalesatm.com> References: <200308111720.38472.shmulik.hen@intel.com> <1060612481.1034.15.camel@jzny.localdomain> <200308111925.38278.shmulik.hen@intel.com> <3F37C7C3.7070807@pobox.com> <3F37D2ED.B4B9223C@thalesatm.com> <3F37D5BF.8000702@pobox.com> <3F3889C7.1B4EC2BE@thalesatm.com> <1060693157.1027.87.camel@jzny.localdomain> <20030812060845.0e0ba2e8.davem@redhat.com> <3F38F569.C1EC7769@thalesatm.com> <1060698412.1063.7.camel@jzny.localdomain> <3F38FB78.4536593A@thalesatm.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1060700754.1065.34.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 12 Aug 2003 11:05:54 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4766 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Tue, 2003-08-12 at 10:36, Laurent DENIEL wrote: > Hardware / software watchdogs are great but do not necessarily > solve all problems especially where timing constraints are important. I think we are going on a tangent; i could ask you next why you think it is less likely to have bugs in the kernel than in user space. Please dont respond because we'll get into long circular debates. > I prefer to rely on the timing of the bonding kernel code to switch > NIC in milli seconds that to wait seconds or minutes that a user space > daemon have the hand to handle the problem (and yes, I am aware of > real time class scheduling and so on, but you say don't trust the > software, and I agree so I prefer a direct kernel hang than nothing > or something too late (software watchdog will not help in that case). I dont think we have any disagreements that minimalistic kernel policy should stay. I am not suggesting to move what the _original_ bonding driver did out of the kernel - so i dont think there are issues with "waiting for seconds". Are you basing this on experience? The key is this: We should start looking at bonding as an enabler for availabilty not as _the solution_. Bonding provides link availability for single hops; cheers, jamal From nf@hipac.org Tue Aug 12 08:15:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 08:15:41 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [62.67.200.156]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CFFXFl027942 for ; Tue, 12 Aug 2003 08:15:34 -0700 Received: (qmail 23624 invoked from network); 12 Aug 2003 14:57:54 -0000 Received: from unknown (HELO portal.lan) (134300@[80.138.220.216]) (envelope-sender ) by smtprelay01.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 12 Aug 2003 14:57:54 -0000 Received: from hipac.org (tmobile.lan [192.168.0.6]) by portal.lan (Postfix) with ESMTP id A2ADE4B493; Tue, 12 Aug 2003 15:18:25 +0200 (CEST) Message-ID: <3F390014.1080708@hipac.org> Date: Tue, 12 Aug 2003 16:56:20 +0200 From: Michael Bellion and Thomas Heinz Reply-To: nf@hipac.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.4) Gecko/20030714 Debian/1.4-2 X-Accept-Language: de, en MIME-Version: 1.0 To: hadi@cyberus.ca Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [RFC] High Performance Packet Classifiction for tc framework References: <200307141045.40999.nf@hipac.org> <1058328537.1797.24.camel@jzny.localdomain> <3F16A0E5.1080007@hipac.org> <1059934468.1103.41.camel@jzny.localdomain> <3F2E5CD6.4030500@hipac.org> <1060012260.1103.380.camel@jzny.localdomain> <3F302E04.1090503@hipac.org> <1060286331.1025.73.camel@jzny.localdomain> <3F381B3E.6080807@hipac.org> <1060657028.1028.79.camel@jzny.localdomain> In-Reply-To: <1060657028.1028.79.camel@jzny.localdomain> X-Enigmail-Version: 0.76.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF71BC491D1932543B4535ECA" X-archive-position: 4767 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nf@hipac.org Precedence: bulk X-list: netdev This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF71BC491D1932543B4535ECA Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Jamal You wrote: > Some fires scare even brave firemen. This was a brave fireman until he > saw the fire ;-> LOL :-) > I have to go back and read the theory again to fully comprehend it but > intutively you are right. I claim that if you knew your input well then > you could construct a hash which will closely approach perfect hashing. > So if i was to use the example you gave me earlier i could approximate a > o(1) hash. u32 allows me to do so once i know how things will look like. > Of course i have to do that mnaully with a pencil and paper. Apart from the fact that the "pencil and paper" approach is not feasible for complex examples where there are no strict regularities in the rule set, you simply cannot avoid the implications when choosing a certain prefix length for the hash (as described in the previous posting). So probably in most cases even "pencil and paper" won't help. > yes. But note the caveat i put above on knowing the input and being able > to manually use a pencil to map out the hash. Now automate the pencil > and paper and let some cpu analyse the traffic patterns as well as > adjust the hashes ... maybe a thesis for someone. Yes, maybe someone should dig further but as long as the assumptions stay the same you have to live with the consequences stated in our last posting. > well, with the iptables scheme at least you need to know where to insert > the rules; so theres some manual labor involved there as well ;-> > Out of curiosity with such a model how do you define a default rule? > In the prio model(and tc), you can have a default catchall rule in the > lowest priority, this way should higher prios fail this will catchall. In theory the default rule has priority "infinity". In an implementation you can simply choose the priority of the default rule 1 + max{prio(r) | for all rules r}. So it's increased by 1 for every insert operation. > Ok, i see your point, so you are saying that a tcf_result is infact a > hardcoded action which should probably be called "setclassid". > Interesting thought. Yes :-) >>Each rule can only have one action or return "value" >>attached to it so if we want to use embedded classifiers >>(as matches) their classid (= action) must be ignored. > > you want the "continue" action essentially. Sorry but we don't seem to get your point here. How is the "continue" action related to having multiple embedded classifiers in a rule which essentially provides 1 single action? > I think i finally see your point. Yes, this could be an improvement that > could be made to tc. Infact you have motivated me to write a > "setclassid" action which will override the classid defined otherwise. :-) Regards, +-----------------------+----------------------+ | Michael Bellion | Thomas Heinz | | | | +-----------------------+----------------------+ | High Performance Packet Classification | | nf-hipac: http://www.hipac.org/ | +----------------------------------------------+ --------------enigF71BC491D1932543B4535ECA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQE/OQAWtXh2AYIMjggRAtgjAJ40cItzNYeTc605D3teq+pn1QIa4ACgm1cU AMOaSmtZdxq6NKycGGEzR4I= =Crtj -----END PGP SIGNATURE----- --------------enigF71BC491D1932543B4535ECA-- From hadi@cyberus.ca Tue Aug 12 08:17:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 08:17:48 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CFHhFl028325 for ; Tue, 12 Aug 2003 08:17:43 -0700 Received: from [216.209.86.2] (helo=[10.0.0.9] ident=jamal) by mail.cyberus.ca with esmtp (Exim 4.12) id 19mau6-0001tN-00; Tue, 12 Aug 2003 11:17:42 -0400 Subject: Re: [SET 2][PATCH 2/8][bonding] Propagating master'ssettings toslaves From: jamal Reply-To: hadi@cyberus.ca To: shmulik.hen@intel.com Cc: "David S. Miller" , laurent.deniel@thalesatm.com, jgarzik@pobox.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: <200308121751.22724.shmulik.hen@intel.com> References: <200308121751.22724.shmulik.hen@intel.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1060701460.1063.44.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 12 Aug 2003 11:17:40 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4768 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Tue, 2003-08-12 at 10:51, Shmulik Hen wrote: > > > Taking into account the two statements I made above: > > > Do you think that what we're doing right now might interfere with > > > what Jamal is suggesting ? No it doesnt; you can continue on that trend - this is something to chew on. > > > Wouldn't it be possible to do things the old way first and than > > > convert everything to the new way ? yes. > > > Shouldn't all this be a part of a totally new project like > > > "bonding2" > > > > yes, this would be next gen - 2.7 or above target. > > I read your answer, yes, but for which question :) Typically around this time of the season - if you wanna call it that - a new stable release is on the table being eaten(2.6.x), people start talking at the table about what that next meal would constitute ;-> So you didnt like the vegetables or the amount of salt added? you make it known then. Of course you are not the cook - but in the Linux world its ok to criticize the cook hopefully they can make a better meal next time;-> Its also OK to criticize the food while it is being cooked. The beauty of it is the cook doesnt listen to your feedback or doesnt provide enough convincing why the food has so much salt, then you can convert yourself into a cook as well and provide alternatives ;-> I hope that is a good analogy and sorry I assumed you were synced in that 'twas that season. cheers, jamal From shmulik.hen@intel.com Tue Aug 12 08:37:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 08:37:36 -0700 (PDT) Received: from hermes.sc.intel.com (fmr03.intel.com [143.183.121.5]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CFbSFl029458 for ; Tue, 12 Aug 2003 08:37:29 -0700 Received: from petasus.sc.intel.com (petasus.sc.intel.com [10.3.253.4]) by hermes.sc.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 h7CFWoH03647 for ; Tue, 12 Aug 2003 15:32:50 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by petasus.sc.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 h7CFZsK14442 for ; Tue, 12 Aug 2003 15:35:54 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.254.188]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003081208421904213 ; Tue, 12 Aug 2003 08:42:21 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Shmulik Hen Reply-To: shmulik.hen@intel.com Organization: Intel corp. To: Subject: Re: [SET 2][PATCH 2/8][bonding] Propagating master'ssettingstoslaves Date: Tue, 12 Aug 2003 18:37:17 +0300 User-Agent: KMail/1.4.3 Cc: "David S. Miller" , , , , References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200308121837.17966.shmulik.hen@intel.com> X-archive-position: 4769 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev On Tuesday 12 August 2003 06:17 pm, jamal wrote: > I hope that is a good analogy and sorry I assumed you were synced > in that 'twas that season. > > > cheers, > jamal So it wasn't duck hunting season ? whew :-) We're kind of new to the business, so I guess we'll need to learn... Shmulik. From nf@hipac.org Tue Aug 12 08:40:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 08:40:58 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [62.67.200.156]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CFepFl030627 for ; Tue, 12 Aug 2003 08:40:52 -0700 Received: (qmail 32278 invoked from network); 12 Aug 2003 15:40:50 -0000 Received: from unknown (HELO portal.lan) (134300@[80.138.220.216]) (envelope-sender ) by smtprelay01.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 12 Aug 2003 15:40:50 -0000 Received: from hipac.org (tmobile.lan [192.168.0.6]) by portal.lan (Postfix) with ESMTP id 723454B493; Tue, 12 Aug 2003 16:01:17 +0200 (CEST) Message-ID: <3F390A23.3050409@hipac.org> Date: Tue, 12 Aug 2003 17:39:15 +0200 From: Michael Bellion and Thomas Heinz User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.4) Gecko/20030714 Debian/1.4-2 X-Accept-Language: de, en MIME-Version: 1.0 To: Jamie Lokier Cc: "David S. Miller" , hadi@cyberus.ca, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [RFC] High Performance Packet Classifiction for tc framework References: <200307141045.40999.nf@hipac.org> <1058328537.1797.24.camel@jzny.localdomain> <3F16A0E5.1080007@hipac.org> <1059934468.1103.41.camel@jzny.localdomain> <3F2E5CD6.4030500@hipac.org> <1060012260.1103.380.camel@jzny.localdomain> <3F302E04.1090503@hipac.org> <1060286331.1025.73.camel@jzny.localdomain> <3F381B3E.6080807@hipac.org> <20030811224050.59bc36fe.davem@redhat.com> <20030812142913.GB18802@mail.jlokier.co.uk> In-Reply-To: <20030812142913.GB18802@mail.jlokier.co.uk> X-Enigmail-Version: 0.76.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4CDC2936C056ECD43B226B35" X-archive-position: 4770 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nf@hipac.org Precedence: bulk X-list: netdev This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4CDC2936C056ECD43B226B35 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Jamie You wrote: > You can do it in O(log(n_bits_in_prefix_mask)). > > This is achieved using binary search on the prefix lengths which > appear in the table. (So if only a few prefix lengths are used, the > tree is small). > > [example snipped] That's true for the one dimensional PCP (with prefix rules) if the following condition holds: for all rules r1, r2: (prefix(r1) > prefix(r2)) && (r1 & prefix(r2) == r2 & prefix(r2)) => prio(r1) < prio(r2) [smallest prio wins] It's quite reasonable to assume that this condition holds for the one dimensional case since there would be never matching rules otherwise. > This generalises to multiple dimensions e.g. for doing multiple > prefixes on source+target + different combinations of other bits such > as protocol, TOS etc. - i.e. arbitrary bit-subset classifiers. The > basic principle and the algorithm are the same. Hm, how do you want to solve the d-dimensional PCP by doing binary search for each dimension? Remember that PCP is not related to longest prefix matching. Instead priorities are used. Maybe you should describe in little more detail what you mean by "This generalises to multiple dimensions ...". Regards, +-----------------------+----------------------+ | Michael Bellion | Thomas Heinz | | | | +-----------------------+----------------------+ | High Performance Packet Classification | | nf-hipac: http://www.hipac.org/ | +----------------------------------------------+ --------------enig4CDC2936C056ECD43B226B35 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQE/OQojtXh2AYIMjggRAkH8AJ40A+oT0az3er5KDD/QrouBl1SKiwCfTXf/ MXdcQGU7cSUwjNssBVvu4Lk= =JZK7 -----END PGP SIGNATURE----- --------------enig4CDC2936C056ECD43B226B35-- From hadi@cyberus.ca Tue Aug 12 08:41:48 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 08:41:53 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CFflFl030948 for ; Tue, 12 Aug 2003 08:41:48 -0700 Received: from [216.209.86.2] (helo=[10.0.0.9] ident=jamal) by mail.cyberus.ca with esmtp (Exim 4.12) id 19mbHP-0004nJ-00; Tue, 12 Aug 2003 11:41:47 -0400 Subject: Re: [RFC] High Performance Packet Classifiction for tc framework From: jamal Reply-To: hadi@cyberus.ca To: nf@hipac.org Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <3F390014.1080708@hipac.org> References: <200307141045.40999.nf@hipac.org> <1058328537.1797.24.camel@jzny.localdomain> <3F16A0E5.1080007@hipac.org> <1059934468.1103.41.camel@jzny.localdomain> <3F2E5CD6.4030500@hipac.org> <1060012260.1103.380.camel@jzny.localdomain> <3F302E04.1090503@hipac.org> <1060286331.1025.73.camel@jzny.localdomain> <3F381B3E.6080807@hipac.org> <1060657028.1028.79.camel@jzny.localdomain> <3F390014.1080708@hipac.org> Content-Type: text/plain Organization: jamalopolis Message-Id: <1060702906.1065.66.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 12 Aug 2003 11:41:46 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4771 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Tue, 2003-08-12 at 10:56, Michael Bellion and Thomas Heinz wrote: > Hi Jamal > > Apart from the fact that the "pencil and paper" approach is not > feasible for complex examples where there are no strict regularities > in the rule set, you simply cannot avoid the implications when > choosing a certain prefix length for the hash (as described in the > previous posting). So probably in most cases even "pencil and paper" > won't help. > If you give me _sufficient time_ it should work ;-> Note, i am not defining sufficient time ;-> Its a different approach,your approach - when you get it right- is the right way. > > yes. But note the caveat i put above on knowing the input and being able > > to manually use a pencil to map out the hash. Now automate the pencil > > and paper and let some cpu analyse the traffic patterns as well as > > adjust the hashes ... maybe a thesis for someone. > > Yes, maybe someone should dig further but as long as the > assumptions stay the same you have to live with the consequences > stated in our last posting. > If you have any students interested in a thesis let me know. > > well, with the iptables scheme at least you need to know where to insert > > the rules; so theres some manual labor involved there as well ;-> > > Out of curiosity with such a model how do you define a default rule? > > In the prio model(and tc), you can have a default catchall rule in the > > lowest priority, this way should higher prios fail this will catchall. > > In theory the default rule has priority "infinity". > In an implementation you can simply choose the priority of the default > rule 1 + max{prio(r) | for all rules r}. So it's increased by 1 for > every insert operation. > And the reason you do this is because you dont know how many rules will exist ahead of time. With static priorities you can set the default to the max value. > >>Each rule can only have one action or return "value" > >>attached to it so if we want to use embedded classifiers > >>(as matches) their classid (= action) must be ignored. > > > > you want the "continue" action essentially. > > Sorry but we don't seem to get your point here. > How is the "continue" action related to having multiple > embedded classifiers in a rule which essentially provides > 1 single action? > tc add continue continue accept - filter1-3 are derived from different classifiers. the accept at the end is doable if you use the tc extensions i am working on. on the setclassid stuff i will ping Alexey and Davem on it - it could be a 2.7 action item. For now, you will have to live with it. BTW, have you tried to leave out defining the classid definition?;-> policy gets accepted fine, i think its a bug but it could be a feature - dont have time to look at it right now. cheers, jamal From shmulik.hen@intel.com Tue Aug 12 09:05:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 09:05:37 -0700 (PDT) Received: from hermes.sc.intel.com (fmr03.intel.com [143.183.121.5]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CG5QFl032224 for ; Tue, 12 Aug 2003 09:05:27 -0700 Received: from petasus.sc.intel.com (petasus.sc.intel.com [10.3.253.4]) by hermes.sc.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 h7CG0mH24203 for ; Tue, 12 Aug 2003 16:00:48 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by petasus.sc.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 h7CG3rK09706 for ; Tue, 12 Aug 2003 16:03:53 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.254.188]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003081209102024176 ; Tue, 12 Aug 2003 09:10:21 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Shmulik Hen Reply-To: shmulik.hen@intel.com Organization: Intel corp. To: "Hare, Matthew" , netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: TCP/IP Window Size Problem/Query Date: Tue, 12 Aug 2003 19:05:18 +0300 User-Agent: KMail/1.4.3 References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200308121905.18313.shmulik.hen@intel.com> X-archive-position: 4772 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev On Monday 11 August 2003 07:22 pm, Hare, Matthew wrote: > I have two systems running SuSE Linux. System 1 is running SuSE 7.1 > with the 2.2.18 kernel. System 2 is running SuSE 7.3 with the > 2.4.17 kernel. Both systems are PC based (Pentium III, 512MB RAM). > > > When I open a TCP connection from System 1 I get a reported window > size (I use Ethereal to check window sizes) of 32k. When I do the > same with System 2 I get a reported window size of 5840bytes and > the window size increases as the rate of data being sent via TCP > increases. This is causing me problems, I need a fixed window size > of 32k on System 2 so that it matches System 1. > We've encountered similar behavior on a server running Red Hat 9 starting with the ~5k window size and publishing it is willing to increase it (forgot the exact name of the flags), problem is the clients are all w2k systems (for using Chariot as the performance analyzer), and they don't seem to be able to handle that kind of window size management, so we're always stuck with the original ~5k window size and the performance sucks. When using w2k on the same server, everything starts with 64k window, so the performance is great. Isn't there a way to ask the TCP/IP stack not to begin with small window size and then try to increase, but rather start with the largest windows size and then decrease ? Using jumbo frames and TSO doesn't seem to help a lot. -- | Shmulik Hen Advanced Network Services | | Israel Design Center, Jerusalem | | LAN Access Division, Platform Networking | | Intel Communications Group, Intel corp. | From chas@locutus.cmf.nrl.navy.mil Tue Aug 12 09:44:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 09:44:50 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CGieFl008586 for ; Tue, 12 Aug 2003 09:44:41 -0700 Received: from locutus.cmf.nrl.navy.mil (locutus.cmf.nrl.navy.mil [134.207.10.66]) by ginger.cmf.nrl.navy.mil (8.12.7/8.12.7) with ESMTP id h7CGiVsG001282; Tue, 12 Aug 2003 12:44:32 -0400 (EDT) Message-Id: <200308121644.h7CGiVsG001282@ginger.cmf.nrl.navy.mil> To: Stephen Hemminger cc: "David S. Miller" , netdev@oss.sgi.com Reply-To: chas3@users.sourceforge.net Subject: Re: [RFT][PATCH] cleanup net/atm/br2684.c In-reply-to: Your message of "Mon, 11 Aug 2003 11:48:23 PDT." <20030811114823.5b81474c.shemminger@osdl.org> Date: Tue, 12 Aug 2003 12:44:32 -0400 From: chas williams X-Spam-Score: () hits=-1.6 X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 4773 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev > - Get rid of all the MOD_INC stuff. MOD_INC is not a spinlock or semaph >ore > and don't use it like that! Have driver clean itself up properly on > unload. i actually have a patch for that already. pppoatm has the same problem. since both are now holding semaphores during ioctl most of the MOD_* stuff can go away. however, one pair needs to kept around in br2684 to keep the module from being removed while the user space process is keeping the vcc's in place. this will go away when everything is converted to netlink. >+ netdev = alloc_netdev(sizeof(struct br2684_dev), >+ ni.ifname[0] ? ni.ifname : "nas%d", >+ br2684_setup); >+ if (!netdev) >+ return -ENOMEM; >... >+ >+ write_lock_irq(&devs_lock); >+ brdev->number = list_empty(&br2684_devs) ? 1 : >+ list_entry_brdev(br2684_devs.prev)->number + 1; >+ list_add_tail(&brdev->br2684_devs, &br2684_devs); >+ write_unlock_irq(&devs_lock); > return 0; this is a little different than the old code. if the user didnt provide an ifname, then brdev->number is used to determine the name of the interface instead of letting the network stack choose the next available interface name. not sure if this really matters to anyone. From maxk@qualcomm.com Tue Aug 12 09:48:58 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 09:49:03 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CGmvFl008940 for ; Tue, 12 Aug 2003 09:48:58 -0700 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h7CGmruI029909; Tue, 12 Aug 2003 09:48:54 -0700 (PDT) Received: from MAXK.qualcomm.com (maxk.qualcomm.com [129.46.176.80]) by neophyte.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h7CGmpuh015120; Tue, 12 Aug 2003 09:48:51 -0700 (PDT) Message-Id: <5.1.0.14.2.20030812092213.08dc6ea0@unixmail.qualcomm.com> X-Sender: maxk@unixmail.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 12 Aug 2003 09:48:50 -0700 To: "David S. Miller" , Stephen Hemminger From: Max Krasnyansky Subject: Re: [PATCH] tun driver use private linked list. Cc: netdev@oss.sgi.com In-Reply-To: <20030809011801.3258f7af.davem@redhat.com> References: <20030808113404.0e9e1e6d.shemminger@osdl.org> <200308051630.28552.bellucda@tiscali.it> <20030805090647.691daa7e.shemminger@osdl.org> <200308051910.55823.bellucda@tiscali.it> <20030807154524.4794ad45.shemminger@osdl.org> <20030807155901.49f1a424.davem@redhat.com> <20030808113404.0e9e1e6d.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-archive-position: 4774 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: maxk@qualcomm.com Precedence: bulk X-list: netdev At 01:18 AM 8/9/2003, David S. Miller wrote: >On Fri, 8 Aug 2003 11:34:04 -0700 >Stephen Hemminger wrote: > >> Less grotty version, applies over earlier patch. >> - keep a private list. >> - fix debug format strings. >> - drop the name entry in the private data structure since it already >> has a pointer to netdev that has name. > >Applied, thanks for following up on this Stephen. Folks, Sorry for jumping in late. I didn't implement cleanup logic in module_exit() because TUN module is not supposed to be unloaded if it has network devices, _even if those devices are down_. TUN registers net device only when user application asks for it. fd = open("/dev/net/tun") -> ioctl(fd, CREATE_TUN_DEV) -> read(fd)/write(fd); Net device must not be destroyed while fd is open. So instead of cleaning up in tun_module_exit() we should fix misc driver to do refcounting for misc devices so that we could bump ref count for tun driver when application creates net device. Max From maxk@qualcomm.com Tue Aug 12 09:49:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 09:49:58 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CGnrFl009269 for ; Tue, 12 Aug 2003 09:49:54 -0700 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h7CGnoVp006887 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 12 Aug 2003 09:49:50 -0700 (PDT) Received: from MAXK.qualcomm.com (maxk.qualcomm.com [129.46.176.80]) by magus.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h7CGnlsh007493; Tue, 12 Aug 2003 09:49:48 -0700 (PDT) Message-Id: <5.1.0.14.2.20030812094908.08cca600@unixmail.qualcomm.com> X-Sender: maxk@unixmail.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 12 Aug 2003 09:49:47 -0700 To: "David S. Miller" , Stephen Hemminger From: Max Krasnyansky Subject: Re: [RFT][PATCH] Convert bluetooth to dynamic net_device. Cc: netdev@oss.sgi.com In-Reply-To: <20030811224851.18d41430.davem@redhat.com> References: <20030811115334.4bd4521a.shemminger@osdl.org> <20030811115334.4bd4521a.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-archive-position: 4775 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: maxk@qualcomm.com Precedence: bulk X-list: netdev At 10:48 PM 8/11/2003, David S. Miller wrote: >On Mon, 11 Aug 2003 11:53:34 -0700 >Stephen Hemminger wrote: > >> Since the initialization code changed slightly, I would like to have >> someone do a basic sanity test before it is merged. > >Ok, ping me when you believe this has occurred :-) I'll test this patch and let you guys know. So far it looks ok to me. Thanks Max From shemminger@osdl.org Tue Aug 12 10:03:23 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 10:03:28 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CH3MFl009868 for ; Tue, 12 Aug 2003 10:03:23 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7CH37o19212; Tue, 12 Aug 2003 10:03:07 -0700 Date: Tue, 12 Aug 2003 10:02:59 -0700 From: Stephen Hemminger To: Max Krasnyansky Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] tun driver use private linked list. Message-Id: <20030812100259.7d557bf3.shemminger@osdl.org> In-Reply-To: <5.1.0.14.2.20030812092213.08dc6ea0@unixmail.qualcomm.com> References: <20030808113404.0e9e1e6d.shemminger@osdl.org> <200308051630.28552.bellucda@tiscali.it> <20030805090647.691daa7e.shemminger@osdl.org> <200308051910.55823.bellucda@tiscali.it> <20030807154524.4794ad45.shemminger@osdl.org> <20030807155901.49f1a424.davem@redhat.com> <20030808113404.0e9e1e6d.shemminger@osdl.org> <5.1.0.14.2.20030812092213.08dc6ea0@unixmail.qualcomm.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4776 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Tue, 12 Aug 2003 09:48:50 -0700 Max Krasnyansky wrote: > At 01:18 AM 8/9/2003, David S. Miller wrote: > >On Fri, 8 Aug 2003 11:34:04 -0700 > >Stephen Hemminger wrote: > > > >> Less grotty version, applies over earlier patch. > >> - keep a private list. > >> - fix debug format strings. > >> - drop the name entry in the private data structure since it already > >> has a pointer to netdev that has name. > > > >Applied, thanks for following up on this Stephen. > > Folks, > > Sorry for jumping in late. > I didn't implement cleanup logic in module_exit() because TUN module is not supposed > to be unloaded if it has network devices, _even if those devices are down_. > TUN registers net device only when user application asks for it. > fd = open("/dev/net/tun") -> ioctl(fd, CREATE_TUN_DEV) -> read(fd)/write(fd); > Net device must not be destroyed while fd is open. > > So instead of cleaning up in tun_module_exit() we should fix misc driver to do refcounting > for misc devices so that we could bump ref count for tun driver when application creates > net device. Not necessary to change anything. If user process has /dev/net/tun open, then the owner field in the fops causes the module reference count to correctly increment. Verified this and it works. The issue is that it is possible to create TUN devices with TUN_PERSIST set and they have to be cleaned up upon. module_exit. The patch works as expected. From garzik@gtf.org Tue Aug 12 10:09:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 10:09:36 -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 h7CH9QFl010238 for ; Tue, 12 Aug 2003 10:09:27 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id 3AA9C663C; Tue, 12 Aug 2003 13:09:20 -0400 (EDT) Date: Tue, 12 Aug 2003 13:09:20 -0400 From: Jeff Garzik To: Matt Mackall Cc: Jon Burgess , linux kernel , netdev@oss.sgi.com Subject: Re: [PATCH][RFC] Netconsole debugging tool for 2.6 Message-ID: <20030812170920.GB24774@gtf.org> References: <3F38F5EC.2060003@jburgess.uklinux.net> <20030812163311.GL31810@waste.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030812163311.GL31810@waste.org> User-Agent: Mutt/1.3.28i X-archive-position: 4777 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev On Tue, Aug 12, 2003 at 11:33:11AM -0500, Matt Mackall wrote: > On Tue, Aug 12, 2003 at 03:13:00PM +0100, Jon Burgess wrote: > > Matt Mackall wrote: > > > I've decided to take a stab at resurrecting Ingo's netconsole patch. > > > > Is this different from the netdump patch which RedHat include in their > > kernel? > > > > The RH kernel patch is at > > http://www.kernelnewbies.org/kernels/rh9/SOURCES/linux-2.4.18-netdump.patch > > Ahh, so that's what's become of it. > > Theirs: > - does crashdumps > - does syslog without levels > - has hooks for receive > > Mine: > - works in 2.6 > - has non-appalling configuration > - works as a built-in and is available earlier in boot > - does syslog with levels (haven't posted this though) netconsole does syslog with levels, too. I agree netdump/netconsole have complete awful configuration. I was thinking netlink would be a good configurator. The kernel printk prefixes map into syslog quite nicely. In any case, there is my own active effort into cleaning up netdump to be less x86-specific, and get it ready for mainline. Maybe we can start discussing converging all these implementations on netdev@oss.sgi.com? (that's where the networking developers live) Jeff From oxymoron@waste.org Tue Aug 12 10:39:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 10:39:35 -0700 (PDT) Received: from waste.org (waste.org [209.173.204.2]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CHdQFl011031 for ; Tue, 12 Aug 2003 10:39:27 -0700 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7CHdIUQ017252; Tue, 12 Aug 2003 12:39:18 -0500 Received: (from oxymoron@localhost) by waste.org (8.12.3/8.12.3/Debian-6.4) id h7CHdHbL017250; Tue, 12 Aug 2003 12:39:17 -0500 Date: Tue, 12 Aug 2003 12:39:17 -0500 From: Matt Mackall To: Jeff Garzik Cc: Jon Burgess , linux kernel , netdev@oss.sgi.com Subject: Re: [PATCH][RFC] Netconsole debugging tool for 2.6 Message-ID: <20030812173917.GM31810@waste.org> References: <3F38F5EC.2060003@jburgess.uklinux.net> <20030812163311.GL31810@waste.org> <20030812170920.GB24774@gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030812170920.GB24774@gtf.org> User-Agent: Mutt/1.3.28i X-Virus-Scanned: by amavisd-new X-archive-position: 4778 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev On Tue, Aug 12, 2003 at 01:09:20PM -0400, Jeff Garzik wrote: > On Tue, Aug 12, 2003 at 11:33:11AM -0500, Matt Mackall wrote: > > On Tue, Aug 12, 2003 at 03:13:00PM +0100, Jon Burgess wrote: > > > Matt Mackall wrote: > > > > I've decided to take a stab at resurrecting Ingo's netconsole patch. > > > > > > Is this different from the netdump patch which RedHat include in their > > > kernel? > > > > > > The RH kernel patch is at > > > http://www.kernelnewbies.org/kernels/rh9/SOURCES/linux-2.4.18-netdump.patch > > > > Ahh, so that's what's become of it. > > > > Theirs: > > - does crashdumps > > - does syslog without levels > > - has hooks for receive > > > > Mine: > > - works in 2.6 > > - has non-appalling configuration > > - works as a built-in and is available earlier in boot > > - does syslog with levels (haven't posted this though) > > netconsole does syslog with levels, too. I agree netdump/netconsole > have complete awful configuration. I was thinking netlink would be a > good configurator. My personal goal is to have it configured in time to catch stuff in the boot process so I can avoid plugging into the serial console, which means everything on the command line. So I've got code to parse the following: netconsole=[src-port]@[src-ip]/[],[tgt-port]@/[tgt-macaddr] > The kernel printk prefixes map into syslog quite nicely. ..and are stripped by printk before the console code is called. The netdump patch logs everything at level 5: + send_syslog_skb(dev, syslog_line, syslog_chars, 5); My patch adds another entry to console struct for writing with levels. And adds hostname to messages. Still needs timestamp. > In any case, there is my own active effort into cleaning up netdump to > be less x86-specific, and get it ready for mainline. > > Maybe we can start discussing converging all these implementations on > netdev@oss.sgi.com? (that's where the networking developers live) Not sure that's the right place for it, simply because that's the one group of people it's not terribly useful for. Especially when I start talking about hooking it up to kgdb. And the network bits are pretty much there already. -- Matt Mackall : http://www.selenic.com : of or relating to the moon From pe1rxq@amsat.org Tue Aug 12 10:45:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 10:45:49 -0700 (PDT) Received: from amsfep12-int.chello.nl (amsfep12-int.chello.nl [213.46.243.18]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CHjgFl011395 for ; Tue, 12 Aug 2003 10:45:43 -0700 Received: from mail.chello.nl ([212.83.83.7]) by amsfep12-int.chello.nl (InterMail vM.5.01.05.17 201-253-122-126-117-20021021) with SMTP id <20030812174526.ZFAX1274.amsfep12-int.chello.nl@mail.chello.nl>; Tue, 12 Aug 2003 19:45:26 +0200 Date: Tue, 12 Aug 2003 19:46:53 +0200 From: Jeroen Vreeken To: linux-hams@vger.kernel.org Cc: ralf@linux-mips.org, davem@redhat.com, netdev@oss.sgi.com Subject: [PATCH] ax25 & netrom fixes for 2.6 Message-ID: <20030812194653.A28977@jeroen.pe1rxq.ampr.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="AWniW0JNca5xppdA" Content-Transfer-Encoding: 8bit X-Mailer: Balsa 1.1.0 Lines: 1155 X-archive-position: 4779 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pe1rxq@amsat.org Precedence: bulk X-list: netdev --AWniW0JNca5xppdA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hi, These are the same changes I send earlier in two parts against 2.6.0-test1. I remade the diff against 2.6.0-test3 as Stephen Hemminger's patch clashed with mine (My patch already had the fix....) Jeroen changes: -fix waitqueue oops on interrupted socket call -add refcounting like struct sock for ax25_cb -skb allocation uses dev->hard_header_len instead off predicted worst case. -ax25_cb list uses hlists like struct sock -lock sk in ax25_find_listener -ax25_destroy_timer set from 10*HZ to 2*HZ (Tihomir Heidelberg) -lock sock when calling ax25_destroy_socket() (Tihomir Heidelberg) -Set ax25->sk to NULL when destroying sk (Tihomir Heidelberg) -Empty write_queue in ax25_destroy_socket() (Tihomir Heidelberg) -ax25_destroy_timer() doesn't share its timer with the heartbeat timer -lock sock in ax25_destroy_timer() -return when destroying ax25 route (Ralf Baechle) -Add ax25_cb_put() calls to netrom -Initialize ax25_iface lists to NULL -unlock linkfail_lock in ax25_linkfail_release() -unlock listen_lock in ax25_listen_release() -unlock_listen_lock in ax25_listen_mine() -remove module_owner from nr_init() -Only release/register listener in nr_set_mac_address() if interface is up. -Call nr_destroy_socket() with socket locked -Free write queue in nr_destroy_socket() -Add missing sock_[unlock/release] calls in netrom code -nr_destroy_tmer set from 10*HZ to 2*HZ -Fixed net_device refcounting to nr_dev_first() and nr_dev_get() -Added nr_node & nr_neigh refcounting -Use hlists for nr_node_list and nr_neigh_list -Added nr_node locking -Prevent race between freeing dev.priv and freeing dev -Don't free dev.name on module exit -Fix error return value from ax25_connect() -Missing unlock in ax25_register_sysctl() -nr_route_frame() makes a private copy of skb's instead of using the one given, it also reserves head room using hard_header_len from the device the packet goes out removing the need for AX25_BPQ_HEADER_LEN -Make ax25_cb refcounting inlined or macro. -Additional locking in ax25 --AWniW0JNca5xppdA Content-Type: application/octet-stream; charset=ISO-8859-1 Content-Disposition: attachment; filename="linux-2.6.0-test3.rxq3.diff" Content-Transfer-Encoding: quoted-printable diff -ru linux-2.6.0-test3/net/ax25/af_ax25.c linux-2.6.0-test1.rxq3/net/ax= 25/af_ax25.c=0A--- linux-2.6.0-test3/net/ax25/af_ax25.c 2003-08-09 06:41:26= .000000000 +0200=0A+++ linux-2.6.0-test1.rxq3/net/ax25/af_ax25.c 2003-07-24= 20:56:37.000000000 +0200=0A@@ -51,54 +51,25 @@=0A =0A =0A =0A-ax25_cb *ax2= 5_list;=0A+HLIST_HEAD(ax25_list);=0A spinlock_t ax25_list_lock =3D SPIN_LOC= K_UNLOCKED;=0A =0A static struct proto_ops ax25_proto_ops;=0A =0A-/*=0A- * = Free an allocated ax25 control block. This is done to centralise=0A- * the = MOD count code.=0A- */=0A-void ax25_free_cb(ax25_cb *ax25)=0A-{=0A- if (ax2= 5->digipeat !=3D NULL) {=0A- kfree(ax25->digipeat);=0A- ax25->digipeat = =3D NULL;=0A- }=0A-=0A- kfree(ax25);=0A-}=0A-=0A static void ax25_free_sock= (struct sock *sk)=0A {=0A- ax25_free_cb(ax25_sk(sk));=0A+ ax25_cb_put(ax25_= sk(sk));=0A }=0A =0A /*=0A * Socket removal during an interrupt is now saf= e.=0A */=0A-static void ax25_remove_socket(ax25_cb *ax25)=0A+static void a= x25_cb_del(ax25_cb *ax25)=0A {=0A- ax25_cb *s;=0A-=0A spin_lock_bh(&ax25_l= ist_lock);=0A- if ((s =3D ax25_list) =3D=3D ax25) {=0A- ax25_list =3D s->n= ext;=0A- spin_unlock_bh(&ax25_list_lock);=0A- return;=0A- }=0A-=0A- while= (s !=3D NULL && s->next !=3D NULL) {=0A- if (s->next =3D=3D ax25) {=0A- = s->next =3D ax25->next;=0A- spin_unlock_bh(&ax25_list_lock);=0A- retur= n;=0A- }=0A-=0A- s =3D s->next;=0A- }=0A+ hlist_del_init(&ax25->ax25_node= );=0A spin_unlock_bh(&ax25_list_lock);=0A+ ax25_cb_put(ax25);=0A }=0A =0A = /*=0A@@ -108,12 +79,13 @@=0A {=0A ax25_dev *ax25_dev;=0A ax25_cb *s;=0A+ = struct hlist_node *node;=0A =0A if ((ax25_dev =3D ax25_dev_ax25dev(dev)) = =3D=3D NULL)=0A return;=0A =0A spin_lock_bh(&ax25_list_lock);=0A- for (s= =3D ax25_list; s !=3D NULL; s =3D s->next) {=0A+ ax25_for_each(s, node, &a= x25_list) {=0A if (s->ax25_dev =3D=3D ax25_dev) {=0A s->ax25_dev =3D N= ULL;=0A ax25_disconnect(s, ENETUNREACH);=0A@@ -153,11 +125,11 @@=0A /*= =0A * Add a socket to the bound sockets list.=0A */=0A-void ax25_insert_s= ocket(ax25_cb *ax25)=0A+void ax25_cb_add(ax25_cb *ax25)=0A {=0A spin_lock_= bh(&ax25_list_lock);=0A- ax25->next =3D ax25_list;=0A- ax25_list =3D ax25;= =0A+ ax25_cb_hold(ax25);=0A+ hlist_add_head(&ax25->ax25_node, &ax25_list);= =0A spin_unlock_bh(&ax25_list_lock);=0A }=0A =0A@@ -169,17 +141,18 @@=0A = struct net_device *dev, int type)=0A {=0A ax25_cb *s;=0A+ struct hlist_nod= e *node;=0A =0A spin_lock_bh(&ax25_list_lock);=0A- for (s =3D ax25_list; s= !=3D NULL; s =3D s->next) {=0A+ ax25_for_each(s, node, &ax25_list) {=0A = if ((s->iamdigi && !digi) || (!s->iamdigi && digi))=0A continue;=0A if= (s->sk && !ax25cmp(&s->source_addr, addr) &&=0A s->sk->sk_type =3D= =3D type && s->sk->sk_state =3D=3D TCP_LISTEN) {=0A /* If device is null= we match any device */=0A if (s->ax25_dev =3D=3D NULL || s->ax25_dev->d= ev =3D=3D dev) {=0A+ sock_hold(s->sk);=0A spin_unlock_bh(&ax25_list_= lock);=0A-=0A return s->sk;=0A }=0A }=0A@@ -197,9 +170,10 @@=0A {= =0A struct sock *sk =3D NULL;=0A ax25_cb *s;=0A+ struct hlist_node *node;= =0A =0A spin_lock_bh(&ax25_list_lock);=0A- for (s =3D ax25_list; s !=3D NU= LL; s =3D s->next) {=0A+ ax25_for_each(s, node, &ax25_list) {=0A if (s->s= k && !ax25cmp(&s->source_addr, my_addr) &&=0A !ax25cmp(&s->dest_addr,= dest_addr) &&=0A s->sk->sk_type =3D=3D type) {=0A@@ -223,9 +197,10 @= @=0A ax25_digi *digi, struct net_device *dev)=0A {=0A ax25_cb *s;=0A+ str= uct hlist_node *node;=0A =0A spin_lock_bh(&ax25_list_lock);=0A- for (s =3D= ax25_list; s !=3D NULL; s =3D s->next) {=0A+ ax25_for_each(s, node, &ax25_= list) {=0A if (s->sk && s->sk->sk_type !=3D SOCK_SEQPACKET)=0A continu= e;=0A if (s->ax25_dev =3D=3D NULL)=0A@@ -240,6 +215,7 @@=0A if (s->di= gipeat !=3D NULL && s->digipeat->ndigi !=3D 0)=0A continue;=0A }=0A= + ax25_cb_hold(s);=0A spin_unlock_bh(&ax25_list_lock);=0A =0A retur= n s;=0A@@ -257,9 +233,10 @@=0A {=0A struct sock *sk =3D NULL;=0A ax25_cb = *s;=0A+ struct hlist_node *node;=0A =0A spin_lock_bh(&ax25_list_lock);=0A-= for (s =3D ax25_list; s !=3D NULL; s =3D s->next) {=0A+ ax25_for_each(s, n= ode, &ax25_list) {=0A if (s->sk !=3D NULL && ax25cmp(&s->source_addr, add= r) =3D=3D 0 &&=0A s->sk->sk_type =3D=3D SOCK_RAW) {=0A sk =3D s->s= k;=0A@@ -267,6 +244,7 @@=0A break;=0A }=0A }=0A+=0A spin_unlock_bh(&= ax25_list_lock);=0A =0A return sk;=0A@@ -299,7 +277,16 @@=0A */=0A static= void ax25_destroy_timer(unsigned long data)=0A {=0A- ax25_destroy_socket((= ax25_cb *)data);=0A+ ax25_cb *ax25=3D(ax25_cb *)data;=0A+ struct sock *sk;= =0A+ =0A+ sk=3Dax25->sk;=0A+ =0A+ bh_lock_sock(sk);=0A+ sock_hold(sk);=0A+ = ax25_destroy_socket(ax25);=0A+ bh_unlock_sock(sk);=0A+ sock_put(sk);=0A }= =0A =0A /*=0A@@ -312,7 +299,7 @@=0A {=0A struct sk_buff *skb;=0A =0A- ax25= _remove_socket(ax25);=0A+ ax25_cb_del(ax25);=0A =0A ax25_stop_heartbeat(ax= 25);=0A ax25_stop_t1timer(ax25);=0A@@ -337,22 +324,27 @@=0A =0A kfree_s= kb(skb);=0A }=0A+ while ((skb =3D skb_dequeue(&ax25->sk->sk_write_queue)= ) !=3D NULL) {=0A+ kfree_skb(skb);=0A+ }=0A }=0A =0A if (ax25->sk !=3D= NULL) {=0A if (atomic_read(&ax25->sk->sk_wmem_alloc) ||=0A atomic_= read(&ax25->sk->sk_rmem_alloc)) {=0A /* Defer: outstanding buffers */=0A= - init_timer(&ax25->timer);=0A- ax25->timer.expires =3D jiffies + 10 *= HZ;=0A- ax25->timer.function =3D ax25_destroy_timer;=0A- ax25->timer.d= ata =3D (unsigned long)ax25;=0A- add_timer(&ax25->timer);=0A+ init_= timer(&ax25->dtimer);=0A+ ax25->dtimer.expires =3D jiffies + 2 * HZ;=0A+= ax25->dtimer.function =3D ax25_destroy_timer;=0A+ ax25->dtimer.data = =3D (unsigned long)ax25;=0A+ add_timer(&ax25->dtimer);=0A } else {=0A= - sock_put(ax25->sk);=0A+ struct sock *sk=3Dax25->sk;=0A+ ax25->sk=3D= NULL;=0A+ sock_put(sk);=0A }=0A } else {=0A- ax25_free_cb(ax25);=0A+ = ax25_cb_put(ax25);=0A }=0A }=0A =0A@@ -421,7 +413,7 @@=0A =0A case AX2= 5_N2:=0A if (ax25_ctl.arg < 1 || ax25_ctl.arg > 31)=0A- return -EIN= VAL;=0A+ return -EINVAL;=0A ax25->n2count =3D 0;=0A ax25->n2 =3D = ax25_ctl.arg;=0A break;=0A@@ -448,7 +440,7 @@=0A return -EINVAL;=0A= }=0A =0A- return 0;=0A+ return 0;=0A }=0A =0A /*=0A@@ -507,6 +499,7 @= @=0A return NULL;=0A =0A memset(ax25, 0x00, sizeof(*ax25));=0A+ atomic_s= et(&ax25->refcount, 1);=0A =0A skb_queue_head_init(&ax25->write_queue);=0A= skb_queue_head_init(&ax25->frag_queue);=0A@@ -655,6 +648,7 @@=0A (so= ck->state !=3D SS_UNCONNECTED ||=0A sk->sk_state =3D=3D TCP_LISTEN)) = {=0A res =3D -EADDRNOTAVAIL;=0A+ dev_put(dev);=0A break;=0A }=0A = =0A@@ -877,7 +871,7 @@=0A break;=0A default:=0A sk_free(sk);=0A- ax25= _free_cb(ax25);=0A+ ax25_cb_put(ax25);=0A return NULL;=0A }=0A =0A@@ -9= 37,6 +931,7 @@=0A if (sk =3D=3D NULL)=0A return 0;=0A =0A+ sock_hold(sk)= ;=0A lock_sock(sk);=0A ax25 =3D ax25_sk(sk);=0A =0A@@ -944,13 +939,15 @@= =0A switch (ax25->state) {=0A case AX25_STATE_0:=0A ax25_disconnect(= ax25, 0);=0A- goto drop;=0A+ ax25_destroy_socket(ax25);=0A+ break;=0A= =0A case AX25_STATE_1:=0A case AX25_STATE_2:=0A ax25_send_control(a= x25, AX25_DISC, AX25_POLLON, AX25_COMMAND);=0A ax25_disconnect(ax25, 0);= =0A- goto drop;=0A+ ax25_destroy_socket(ax25);=0A+ break;=0A =0A ca= se AX25_STATE_3:=0A case AX25_STATE_4:=0A@@ -993,16 +990,14 @@=0A sk->s= k_shutdown |=3D SEND_SHUTDOWN;=0A sk->sk_state_change(sk);=0A sock_set_= flag(sk, SOCK_DEAD);=0A- goto drop;=0A+ ax25_destroy_socket(ax25);=0A }= =0A =0A sock->sk =3D NULL;=0A sk->sk_socket =3D NULL; /* Not used, but = we should do this */=0A release_sock(sk);=0A- return 0;=0A- drop:=0A- rele= ase_sock(sk);=0A- ax25_destroy_socket(ax25);=0A+ sock_put(sk);=0A+=0A retu= rn 0;=0A }=0A =0A@@ -1077,7 +1072,7 @@=0A ax25_fillin_cb(ax25, ax25_dev);= =0A =0A done:=0A- ax25_insert_socket(ax25);=0A+ ax25_cb_add(ax25);=0A sk->= sk_zapped =3D 0;=0A =0A out:=0A@@ -1093,7 +1088,7 @@=0A int addr_len, int = flags)=0A {=0A struct sock *sk =3D sock->sk;=0A- ax25_cb *ax25 =3D ax25_sk= (sk);=0A+ ax25_cb *ax25 =3D ax25_sk(sk), *ax25t;=0A struct full_sockaddr_a= x25 *fsa =3D (struct full_sockaddr_ax25 *)uaddr;=0A ax25_digi *digi =3D NU= LL;=0A int ct =3D 0, err =3D 0;=0A@@ -1199,7 +1194,7 @@=0A goto out;=0A= =0A ax25_fillin_cb(ax25, ax25->ax25_dev);=0A- ax25_insert_socket(ax25);= =0A+ ax25_cb_add(ax25);=0A } else {=0A if (ax25->ax25_dev =3D=3D NULL) = {=0A err =3D -EHOSTUNREACH;=0A@@ -1208,11 +1203,12 @@=0A }=0A =0A if (= sk->sk_type =3D=3D SOCK_SEQPACKET &&=0A- ax25_find_cb(&ax25->source_add= r, &fsa->fsa_ax25.sax25_call, digi,=0A- ax25->ax25_dev->dev)) {=0A+ = (ax25t=3Dax25_find_cb(&ax25->source_addr, &fsa->fsa_ax25.sax25_call, di= gi,=0A+ ax25->ax25_dev->dev))) {=0A if (digi !=3D NULL)=0A kfre= e(digi);=0A err =3D -EADDRINUSE; /* Already such a connection */=0A+ ax= 25_cb_put(ax25t);=0A goto out;=0A }=0A =0A@@ -1273,6 +1269,8 @@=0A l= ock_sock(sk);=0A continue;=0A }=0A+ current->state =3D TASK_RUNNIN= G;=0A+ remove_wait_queue(sk->sk_sleep, &wait);=0A return -ERESTARTSYS;= =0A }=0A current->state =3D TASK_RUNNING;=0A@@ -1288,10 +1286,11 @@=0A = =0A sock->state =3D SS_CONNECTED;=0A =0A+ err=3D0;=0A out:=0A release_soc= k(sk);=0A =0A- return 0;=0A+ return err;=0A }=0A =0A =0A@@ -1331,15 +1330,1= 8 @@=0A if (skb)=0A break;=0A =0A- current->state =3D TASK_INTERRUPTI= BLE;=0A release_sock(sk);=0A+ current->state =3D TASK_INTERRUPTIBLE;=0A = if (flags & O_NONBLOCK)=0A return -EWOULDBLOCK;=0A if (!signal_pendi= ng(tsk)) {=0A schedule();=0A+ current->state =3D TASK_RUNNING;=0A l= ock_sock(sk);=0A continue;=0A }=0A+ current->state =3D TASK_RUNNING;= =0A+ remove_wait_queue(sk->sk_sleep, &wait);=0A return -ERESTARTSYS;=0A = }=0A current->state =3D TASK_RUNNING;=0A@@ -1519,7 +1521,7 @@=0A SOCK_DE= BUG(sk, "AX.25: sendto: building packet.\n");=0A =0A /* Assume the worst c= ase */=0A- size =3D len + 3 + ax25_addr_size(dp) + AX25_BPQ_HEADER_LEN;=0A+= size =3D len + ax25->ax25_dev->dev->hard_header_len;=0A =0A skb =3D sock_= alloc_send_skb(sk, size, msg->msg_flags&MSG_DONTWAIT, &err);=0A if (skb = =3D=3D NULL)=0A@@ -1780,7 +1782,7 @@=0A =0A /* old structure? */=0A if = (cmd =3D=3D SIOCAX25GETINFOOLD) {=0A- static int warned;=0A+ static int= warned =3D 0;=0A if (!warned) {=0A printk(KERN_INFO "%s uses old SI= OCAX25GETINFO\n",=0A current->comm);=0A@@ -1845,6 +1847,7 @@=0A int l= en =3D 0;=0A off_t pos =3D 0;=0A off_t begin =3D 0;=0A+ struct hlist_node= *node;=0A =0A spin_lock_bh(&ax25_list_lock);=0A =0A@@ -1853,7 +1856,7 @@= =0A * magic dev src_addr dest_addr,digi1,digi2,.. st vs vr va t1 t1 t2 t2= t3 t3 idle idle n2 n2 rtt window paclen Snd-Q Rcv-Q inode=0A */=0A =0A- = for (ax25 =3D ax25_list; ax25 !=3D NULL; ax25 =3D ax25->next) {=0A+ ax25_fo= r_each(ax25, node, &ax25_list) {=0A len +=3D sprintf(buffer+len, "%8.8lx = %s %s%s ",=0A (long) ax25,=0A ax25->ax25_dev =3D=3D NULL? "???" : a= x25->ax25_dev->dev->name,=0A@@ -1882,10 +1885,12 @@=0A ax25->paclen);=0A= =0A if (ax25->sk !=3D NULL) {=0A+ bh_lock_sock(ax25->sk);=0A len += =3D sprintf(buffer + len, " %d %d %ld\n",=0A atomic_read(&ax25->sk->sk_= wmem_alloc),=0A atomic_read(&ax25->sk->sk_rmem_alloc),=0A ax25->sk-= >sk_socket !=3D NULL ? SOCK_INODE(ax25->sk->sk_socket)->i_ino : 0L);=0A+ = bh_unlock_sock(ax25->sk);=0A } else {=0A len +=3D sprintf(buffer + len= , " * * *\n");=0A }=0Adiff -ru linux-2.6.0-test3/net/ax25/ax25_ds_in.c li= nux-2.6.0-test1.rxq3/net/ax25/ax25_ds_in.c=0A--- linux-2.6.0-test3/net/ax25= /ax25_ds_in.c 2003-08-09 06:38:45.000000000 +0200=0A+++ linux-2.6.0-test1.r= xq3/net/ax25/ax25_ds_in.c 2003-07-24 20:56:38.000000000 +0200=0A@@ -65,6 +6= 5,7 @@=0A ax25->state =3D AX25_STATE_3;=0A ax25->n2count =3D 0;=0A = if (ax25->sk !=3D NULL) {=0A+ bh_lock_sock(ax25->sk);=0A ax25->sk->sk_= state =3D TCP_ESTABLISHED;=0A /*=0A * For WAIT_SABM connections we w= ill produce an accept=0A@@ -72,6 +73,7 @@=0A */=0A if (!sock_flag(ax= 25->sk, SOCK_DEAD))=0A ax25->sk->sk_state_change(ax25->sk);=0A+ bh_un= lock_sock(ax25->sk);=0A }=0A ax25_dama_on(ax25);=0A =0Adiff -ru linux-2= .6.0-test3/net/ax25/ax25_ds_subr.c linux-2.6.0-test1.rxq3/net/ax25/ax25_ds_= subr.c=0A--- linux-2.6.0-test3/net/ax25/ax25_ds_subr.c 2003-08-09 06:41:32.= 000000000 +0200=0A+++ linux-2.6.0-test1.rxq3/net/ax25/ax25_ds_subr.c 2003-0= 7-24 20:56:38.000000000 +0200=0A@@ -40,6 +40,7 @@=0A void ax25_ds_enquiry_r= esponse(ax25_cb *ax25)=0A {=0A ax25_cb *ax25o;=0A+ struct hlist_node *node= ;=0A =0A /* Please note that neither DK4EG=B4s nor DG2FEF=B4s=0A * DAMA = spec mention the following behaviour as seen=0A@@ -80,7 +81,7 @@=0A ax25_d= s_set_timer(ax25->ax25_dev);=0A =0A spin_lock_bh(&ax25_list_lock);=0A- for= (ax25o =3D ax25_list; ax25o !=3D NULL; ax25o =3D ax25o->next) {=0A+ ax25_f= or_each(ax25o, node, &ax25_list) {=0A if (ax25o =3D=3D ax25)=0A contin= ue;=0A =0A@@ -160,9 +161,10 @@=0A {=0A ax25_cb *ax25;=0A int res =3D 0;= =0A+ struct hlist_node *node;=0A =0A spin_lock_bh(&ax25_list_lock);=0A- fo= r (ax25 =3D ax25_list; ax25 !=3D NULL ; ax25 =3D ax25->next)=0A+ ax25_for_e= ach(ax25, node, &ax25_list)=0A if (ax25->ax25_dev =3D=3D ax25_dev && (ax2= 5->condition & AX25_COND_DAMA_MODE) && ax25->state > AX25_STATE_1) {=0A = res =3D 1;=0A break;=0Adiff -ru linux-2.6.0-test3/net/ax25/ax25_ds_timer= .c linux-2.6.0-test1.rxq3/net/ax25/ax25_ds_timer.c=0A--- linux-2.6.0-test3/= net/ax25/ax25_ds_timer.c 2003-08-09 06:41:26.000000000 +0200=0A+++ linux-2.= 6.0-test1.rxq3/net/ax25/ax25_ds_timer.c 2003-07-24 20:56:37.000000000 +0200= =0A@@ -74,6 +74,7 @@=0A {=0A ax25_dev *ax25_dev =3D (struct ax25_dev *) ar= g;=0A ax25_cb *ax25;=0A+ struct hlist_node *node;=0A =0A if (ax25_dev =3D= =3D NULL || !ax25_dev->dama.slave)=0A return; /* Yikes! */=0A@@ -84,7 += 85,7 @@=0A }=0A =0A spin_lock_bh(&ax25_list_lock);=0A- for (ax25=3Dax25_l= ist; ax25 !=3D NULL; ax25 =3D ax25->next) {=0A+ ax25_for_each(ax25, node, &= ax25_list) {=0A if (ax25->ax25_dev !=3D ax25_dev || !(ax25->condition & A= X25_COND_DAMA_MODE))=0A continue;=0A =0A@@ -98,15 +99,26 @@=0A =0A void = ax25_ds_heartbeat_expiry(ax25_cb *ax25)=0A {=0A+ struct sock *sk=3Dax25->sk= ;=0A+=0A+ if (sk)=0A+ bh_lock_sock(sk);=0A+=0A switch (ax25->state) {=0A = =0A case AX25_STATE_0:=0A /* Magic here: If we listen() and a new link d= ies before it=0A is accepted() it isn't 'dead' so doesn't get removed.= */=0A- if (!ax25->sk || sock_flag(ax25->sk, SOCK_DESTROY) ||=0A- (ax= 25->sk->sk_state =3D=3D TCP_LISTEN &&=0A- sock_flag(ax25->sk, SOCK_DE= AD))) {=0A- ax25_destroy_socket(ax25);=0A+ if (!sk || sock_flag(sk, SOCK= _DESTROY) ||=0A+ (sk->sk_state =3D=3D TCP_LISTEN &&=0A+ sock_fla= g(sk, SOCK_DEAD))) {=0A+ if (sk) {=0A+ sock_hold(sk);=0A+ ax25_dest= roy_socket(ax25);=0A+ sock_put(sk);=0A+ bh_unlock_sock(sk);=0A+ } e= lse=0A+ ax25_destroy_socket(ax25);=0A return;=0A }=0A break;=0A@@= -115,9 +127,9 @@=0A /*=0A * Check the state of the receive buffer.=0A= */=0A- if (ax25->sk !=3D NULL) {=0A- if (atomic_read(&ax25->sk->sk_r= mem_alloc) <=0A- (ax25->sk->sk_rcvbuf / 2) &&=0A+ if (sk !=3D NULL) = {=0A+ if (atomic_read(&sk->sk_rmem_alloc) <=0A+ (sk->sk_rcvbuf / 2)= &&=0A (ax25->condition & AX25_COND_OWN_RX_BUSY)) {=0A ax25->con= dition &=3D ~AX25_COND_OWN_RX_BUSY;=0A ax25->condition &=3D ~AX25_COND_= ACK_PENDING;=0A@@ -127,6 +139,9 @@=0A break;=0A }=0A =0A+ if (sk)=0A+ b= h_unlock_sock(sk);=0A+=0A ax25_start_heartbeat(ax25);=0A }=0A =0A@@ -157,6= +172,7 @@=0A ax25_stop_t3timer(ax25);=0A =0A if (ax25->sk !=3D NULL) {= =0A+ bh_lock_sock(ax25->sk);=0A ax25->sk->sk_state =3D TCP_CLOSE;=0A= ax25->sk->sk_err =3D 0;=0A ax25->sk->sk_shutdown |=3D SEND_SHUTD= OWN;=0A@@ -164,6 +180,7 @@=0A ax25->sk->sk_state_change(ax25->sk);=0A = sock_set_flag(ax25->sk, SOCK_DEAD);=0A }=0A+ bh_lock_sock(ax25->sk);=0A= }=0A }=0A =0Adiff -ru linux-2.6.0-test3/net/ax25/ax25_iface.c linux-2.6.0= -test1.rxq3/net/ax25/ax25_iface.c=0A--- linux-2.6.0-test3/net/ax25/ax25_ifa= ce.c 2003-08-09 06:42:13.000000000 +0200=0A+++ linux-2.6.0-test1.rxq3/net/a= x25/ax25_iface.c 2003-07-24 20:56:37.000000000 +0200=0A@@ -33,20 +33,20 @@= =0A struct protocol_struct *next;=0A unsigned int pid;=0A int (*func)(st= ruct sk_buff *, ax25_cb *);=0A-} *protocol_list;=0A+} *protocol_list =3D NU= LL;=0A static rwlock_t protocol_list_lock =3D RW_LOCK_UNLOCKED;=0A =0A stat= ic struct linkfail_struct {=0A struct linkfail_struct *next;=0A void (*fu= nc)(ax25_cb *, int);=0A-} *linkfail_list;=0A+} *linkfail_list =3D NULL;=0A = static spinlock_t linkfail_lock =3D SPIN_LOCK_UNLOCKED;=0A =0A static struc= t listen_struct {=0A struct listen_struct *next;=0A ax25_address callsig= n;=0A struct net_device *dev;=0A-} *listen_list;=0A+} *listen_list =3D NUL= L;=0A static spinlock_t listen_lock =3D SPIN_LOCK_UNLOCKED;=0A =0A int ax25= _protocol_register(unsigned int pid,=0A@@ -129,8 +129,10 @@=0A =0A spin_lo= ck_bh(&linkfail_lock);=0A linkfail =3D linkfail_list;=0A- if (linkfail =3D= =3D NULL)=0A+ if (linkfail =3D=3D NULL) {=0A+ spin_unlock_bh(&linkfail_loc= k);=0A return;=0A+ }=0A =0A if (linkfail->func =3D=3D func) {=0A linkf= ail_list =3D linkfail->next;=0A@@ -180,8 +182,10 @@=0A =0A spin_lock_bh(&l= isten_lock);=0A listen =3D listen_list;=0A- if (listen =3D=3D NULL)=0A+ if= (listen =3D=3D NULL) {=0A+ spin_unlock_bh(&listen_lock);=0A return;=0A+= }=0A =0A if (ax25cmp(&listen->callsign, callsign) =3D=3D 0 && listen->dev= =3D=3D dev) {=0A listen_list =3D listen->next;=0A@@ -226,8 +230,10 @@=0A= =0A spin_lock_bh(&listen_lock);=0A for (listen =3D listen_list; listen != =3D NULL; listen =3D listen->next)=0A- if (ax25cmp(&listen->callsign, call= sign) =3D=3D 0 && (listen->dev =3D=3D dev || listen->dev =3D=3D NULL))=0A+ = if (ax25cmp(&listen->callsign, callsign) =3D=3D 0 && (listen->dev =3D=3D d= ev || listen->dev =3D=3D NULL)) {=0A+ spin_unlock_bh(&listen_lock);=0A = return 1;=0A+ }=0A spin_unlock_bh(&listen_lock);=0A =0A return 0;=0Adiff= -ru linux-2.6.0-test3/net/ax25/ax25_in.c linux-2.6.0-test1.rxq3/net/ax25/a= x25_in.c=0A--- linux-2.6.0-test3/net/ax25/ax25_in.c 2003-08-09 06:32:47.000= 000000 +0200=0A+++ linux-2.6.0-test1.rxq3/net/ax25/ax25_in.c 2003-07-24 20:= 56:36.000000000 +0200=0A@@ -147,6 +147,7 @@=0A }=0A =0A if (ax25->sk !=3D= NULL && ax25->ax25_dev->values[AX25_VALUES_CONMODE] =3D=3D 2) {=0A+ bh_lo= ck_sock(ax25->sk);=0A if ((!ax25->pidincl && ax25->sk->sk_protocol =3D=3D= pid) ||=0A ax25->pidincl) {=0A if (sock_queue_rcv_skb(ax25->sk, s= kb) =3D=3D 0)=0A@@ -154,6 +155,7 @@=0A else=0A ax25->condition |=3D = AX25_COND_OWN_RX_BUSY;=0A }=0A+ bh_unlock_sock(ax25->sk);=0A }=0A =0A = return queued;=0A@@ -329,6 +331,7 @@=0A if (ax25_process_rx_frame(ax25, s= kb, type, dama) =3D=3D 0)=0A kfree_skb(skb);=0A =0A+ ax25_cb_put(ax25);= =0A return 0;=0A }=0A =0A@@ -357,11 +360,14 @@=0A sk =3D ax25_find_lis= tener(next_digi, 1, dev, SOCK_SEQPACKET);=0A =0A if (sk !=3D NULL) {=0A+ = bh_lock_sock(sk);=0A if (sk->sk_ack_backlog =3D=3D sk->sk_max_ack_backlog= ||=0A (make =3D ax25_make_new(sk, ax25_dev)) =3D=3D NULL) {=0A if= (mine)=0A ax25_return_dm(dev, &src, &dest, &dp);=0A kfree_skb(skb);= =0A+ bh_unlock_sock(sk);=0A+ sock_put(sk);=0A =0A return 0;=0A }= =0A@@ -374,6 +380,8 @@=0A make->sk_pair =3D sk;=0A =0A sk->sk_ack_back= log++;=0A+ bh_unlock_sock(sk);=0A+ sock_put(sk);=0A } else {=0A if (!m= ine) {=0A kfree_skb(skb);=0A@@ -429,7 +437,7 @@=0A =0A ax25->state =3D = AX25_STATE_3;=0A =0A- ax25_insert_socket(ax25);=0A+ ax25_cb_add(ax25);=0A = =0A ax25_start_heartbeat(ax25);=0A ax25_start_t3timer(ax25);=0Adiff -ru l= inux-2.6.0-test3/net/ax25/ax25_ip.c linux-2.6.0-test1.rxq3/net/ax25/ax25_ip= .c=0A--- linux-2.6.0-test3/net/ax25/ax25_ip.c 2003-08-09 06:34:43.000000000= +0200=0A+++ linux-2.6.0-test1.rxq3/net/ax25/ax25_ip.c 2003-07-24 20:56:37.= 000000000 +0200=0A@@ -107,6 +107,7 @@=0A ax25_address *src, *dst;=0A ax25= _dev *ax25_dev;=0A ax25_route _route, *route =3D &_route;=0A+ ax25_cb *ax2= 5;=0A =0A dst =3D (ax25_address *)(bp + 1);=0A src =3D (ax25_address *)(b= p + 8);=0A@@ -167,9 +168,14 @@=0A skb_pull(ourskb, AX25_HEADER_LEN - 1);= /* Keep PID */=0A ourskb->nh.raw =3D ourskb->data;=0A =0A- ax25_send_= frame(ourskb, ax25_dev->values[AX25_VALUES_PACLEN], &src_c,=0A-&dst_c, rout= e->digipeat, dev);=0A-=0A+ ax25=3Dax25_send_frame(=0A+ ourskb, =0A+= ax25_dev->values[AX25_VALUES_PACLEN], =0A+ &src_c,=0A+ &= dst_c, route->digipeat, dev);=0A+ if (ax25) {=0A+ ax25_cb_put(ax25);= =0A+ }=0A goto put;=0A }=0A }=0Adiff -ru linux-2.6.0-test3/net/ax25= /ax25_out.c linux-2.6.0-test1.rxq3/net/ax25/ax25_out.c=0A--- linux-2.6.0-te= st3/net/ax25/ax25_out.c 2003-08-09 06:40:10.000000000 +0200=0A+++ linux-2.6= .0-test1.rxq3/net/ax25/ax25_out.c 2003-07-24 20:56:38.000000000 +0200=0A@@ = -71,7 +71,7 @@=0A =0A if (digi !=3D NULL) {=0A if ((ax25->digipeat =3D k= malloc(sizeof(ax25_digi), GFP_ATOMIC)) =3D=3D NULL) {=0A- ax25_free_cb(ax= 25);=0A+ ax25_cb_put(ax25);=0A return NULL;=0A }=0A memcpy(ax25->d= igipeat, digi, sizeof(ax25_digi));=0A@@ -93,7 +93,7 @@=0A #endif=0A }=0A = =0A- ax25_insert_socket(ax25);=0A+ ax25_cb_add(ax25);=0A =0A ax25->state = =3D AX25_STATE_1;=0A =0Adiff -ru linux-2.6.0-test3/net/ax25/ax25_route.c li= nux-2.6.0-test1.rxq3/net/ax25/ax25_route.c=0A--- linux-2.6.0-test3/net/ax25= /ax25_route.c 2003-08-09 06:38:41.000000000 +0200=0A+++ linux-2.6.0-test1.r= xq3/net/ax25/ax25_route.c 2003-07-24 20:56:38.000000000 +0200=0A@@ -162,6 += 162,7 @@=0A if (ax25_rt->digipeat !=3D NULL)=0A kfree(ax25_rt->digipea= t);=0A kfree(ax25_rt);=0A+ return;=0A }=0A =0A /*=0A@@ -434,8 +435,11 = @@=0A ax25_adjust_path(addr, ax25->digipeat);=0A }=0A =0A- if (ax25->sk = !=3D NULL)=0A+ if (ax25->sk !=3D NULL) {=0A+ bh_lock_sock(ax25->sk);=0A = ax25->sk->sk_zapped =3D 0;=0A+ bh_unlock_sock(ax25->sk);=0A+ }=0A =0A put:= =0A ax25_put_route(ax25_rt);=0Adiff -ru linux-2.6.0-test3/net/ax25/ax25_st= d_in.c linux-2.6.0-test1.rxq3/net/ax25/ax25_std_in.c=0A--- linux-2.6.0-test= 3/net/ax25/ax25_std_in.c 2003-08-09 06:39:26.000000000 +0200=0A+++ linux-2.= 6.0-test1.rxq3/net/ax25/ax25_std_in.c 2003-07-24 20:56:37.000000000 +0200= =0A@@ -73,10 +73,12 @@=0A ax25->state =3D AX25_STATE_3;=0A ax25->n2= count =3D 0;=0A if (ax25->sk !=3D NULL) {=0A+ bh_lock_sock(ax25->sk);= =0A ax25->sk->sk_state =3D TCP_ESTABLISHED;=0A /* For WAIT_SABM con= nections we will produce an accept ready socket here */=0A if (!sock_fl= ag(ax25->sk, SOCK_DEAD))=0A ax25->sk->sk_state_change(ax25->sk);=0A+ = bh_unlock_sock(ax25->sk);=0A }=0A }=0A break;=0Adiff -ru linux-2.6= .0-test3/net/ax25/ax25_std_timer.c linux-2.6.0-test1.rxq3/net/ax25/ax25_std= _timer.c=0A--- linux-2.6.0-test3/net/ax25/ax25_std_timer.c 2003-08-09 06:34= :03.000000000 +0200=0A+++ linux-2.6.0-test1.rxq3/net/ax25/ax25_std_timer.c = 2003-07-24 20:56:37.000000000 +0200=0A@@ -33,14 +33,25 @@=0A =0A void ax25_= std_heartbeat_expiry(ax25_cb *ax25)=0A {=0A+ struct sock *sk=3Dax25->sk;=0A= + =0A+ if (sk)=0A+ bh_lock_sock(sk);=0A+=0A switch (ax25->state) {=0A ca= se AX25_STATE_0:=0A /* Magic here: If we listen() and a new link dies bef= ore it=0A is accepted() it isn't 'dead' so doesn't get removed. */=0A-= if (!ax25->sk || sock_flag(ax25->sk, SOCK_DESTROY) ||=0A- (ax25->sk-= >sk_state =3D=3D TCP_LISTEN &&=0A- sock_flag(ax25->sk, SOCK_DEAD))) {= =0A- ax25_destroy_socket(ax25);=0A+ if (!sk || sock_flag(sk, SOCK_DESTRO= Y) ||=0A+ (sk->sk_state =3D=3D TCP_LISTEN &&=0A+ sock_flag(sk, S= OCK_DEAD))) {=0A+ if (sk) {=0A+ sock_hold(sk);=0A+ ax25_destroy_soc= ket(ax25);=0A+ bh_unlock_sock(sk);=0A+ sock_put(sk);=0A+ } else=0A+= ax25_destroy_socket(ax25);=0A return;=0A }=0A break;=0A@@ -50,9 = +61,9 @@=0A /*=0A * Check the state of the receive buffer.=0A */=0A= - if (ax25->sk !=3D NULL) {=0A- if (atomic_read(&ax25->sk->sk_rmem_alloc= ) <=0A- (ax25->sk->sk_rcvbuf / 2) &&=0A+ if (sk !=3D NULL) {=0A+ i= f (atomic_read(&sk->sk_rmem_alloc) <=0A+ (sk->sk_rcvbuf / 2) &&=0A = (ax25->condition & AX25_COND_OWN_RX_BUSY)) {=0A ax25->condition &= =3D ~AX25_COND_OWN_RX_BUSY;=0A ax25->condition &=3D ~AX25_COND_ACK_PEND= ING;=0A@@ -62,6 +73,9 @@=0A }=0A }=0A =0A+ if (sk)=0A+ bh_unlock_sock(s= k);=0A+=0A ax25_start_heartbeat(ax25);=0A }=0A =0A@@ -94,6 +108,7 @@=0A a= x25_stop_t3timer(ax25);=0A =0A if (ax25->sk !=3D NULL) {=0A+ bh_lock_sock= (ax25->sk);=0A ax25->sk->sk_state =3D TCP_CLOSE;=0A ax25->sk->sk_er= r =3D 0;=0A ax25->sk->sk_shutdown |=3D SEND_SHUTDOWN;=0A@@ -101,6 += 116,7 @@=0A ax25->sk->sk_state_change(ax25->sk);=0A sock_set_flag(ax2= 5->sk, SOCK_DEAD);=0A }=0A+ bh_unlock_sock(ax25->sk);=0A }=0A }=0A =0Ad= iff -ru linux-2.6.0-test3/net/ax25/ax25_subr.c linux-2.6.0-test1.rxq3/net/a= x25/ax25_subr.c=0A--- linux-2.6.0-test3/net/ax25/ax25_subr.c 2003-08-09 06:= 41:35.000000000 +0200=0A+++ linux-2.6.0-test1.rxq3/net/ax25/ax25_subr.c 200= 3-07-24 20:56:37.000000000 +0200=0A@@ -158,10 +158,10 @@=0A struct sk_buff= *skb;=0A unsigned char *dptr;=0A =0A- if ((skb =3D alloc_skb(AX25_BPQ_HE= ADER_LEN + ax25_addr_size(ax25->digipeat) + 2, GFP_ATOMIC)) =3D=3D NULL)=0A= + if ((skb =3D alloc_skb(ax25->ax25_dev->dev->hard_header_len + 2, GFP_ATOM= IC)) =3D=3D NULL)=0A return;=0A =0A- skb_reserve(skb, AX25_BPQ_HEADER_LEN= + ax25_addr_size(ax25->digipeat));=0A+ skb_reserve(skb, ax25->ax25_dev->de= v->hard_header_len);=0A =0A skb->nh.raw =3D skb->data;=0A =0A@@ -202,10 +2= 02,10 @@=0A if (dev =3D=3D NULL)=0A return;=0A =0A- if ((skb =3D alloc_s= kb(AX25_BPQ_HEADER_LEN + ax25_addr_size(digi) + 1, GFP_ATOMIC)) =3D=3D NULL= )=0A+ if ((skb =3D alloc_skb(dev->hard_header_len + 1, GFP_ATOMIC)) =3D=3D = NULL)=0A return; /* Next SABM will get DM'd */=0A =0A- skb_reserve(skb, A= X25_BPQ_HEADER_LEN + ax25_addr_size(digi));=0A+ skb_reserve(skb, dev->hard_= header_len);=0A skb->nh.raw =3D skb->data;=0A =0A ax25_digi_invert(digi, = &retdigi);=0A@@ -282,6 +282,7 @@=0A ax25_link_failed(ax25, reason);=0A =0A= if (ax25->sk !=3D NULL) {=0A+ bh_lock_sock(ax25->sk);=0A ax25->sk->sk_= state =3D TCP_CLOSE;=0A ax25->sk->sk_err =3D reason;=0A ax25-= >sk->sk_shutdown |=3D SEND_SHUTDOWN;=0A@@ -289,5 +290,6 @@=0A ax25->sk->= sk_state_change(ax25->sk);=0A sock_set_flag(ax25->sk, SOCK_DEAD);=0A }= =0A+ bh_unlock_sock(ax25->sk);=0A }=0A }=0Adiff -ru linux-2.6.0-test3/net= /ax25/ax25_timer.c linux-2.6.0-test1.rxq3/net/ax25/ax25_timer.c=0A--- linux= -2.6.0-test3/net/ax25/ax25_timer.c 2003-08-09 06:38:16.000000000 +0200=0A++= + linux-2.6.0-test1.rxq3/net/ax25/ax25_timer.c 2003-07-24 20:56:38.00000000= 0 +0200=0A@@ -141,13 +141,10 @@=0A {=0A int proto =3D AX25_PROTO_STD_SIMPL= EX;=0A ax25_cb *ax25 =3D (ax25_cb *)param;=0A- struct sock *sk =3D ax25->s= k;=0A =0A if (ax25->ax25_dev)=0A proto =3D ax25->ax25_dev->values[AX25_V= ALUES_PROTOCOL];=0A =0A- bh_lock_sock(sk);=0A-=0A switch (proto) {=0A cas= e AX25_PROTO_STD_SIMPLEX:=0A case AX25_PROTO_STD_DUPLEX:=0A@@ -163,15 +160= ,12 @@=0A break;=0A #endif=0A }=0A- bh_unlock_sock(sk);=0A }=0A =0A stat= ic void ax25_t1timer_expiry(unsigned long param)=0A {=0A ax25_cb *ax25 =3D= (ax25_cb *)param;=0A- struct sock *sk =3D ax25->sk;=0A =0A- bh_lock_sock(s= k);=0A switch (ax25->ax25_dev->values[AX25_VALUES_PROTOCOL]) {=0A case AX= 25_PROTO_STD_SIMPLEX:=0A case AX25_PROTO_STD_DUPLEX:=0A@@ -185,15 +179,12 = @@=0A break;=0A #endif=0A }=0A- bh_unlock_sock(sk);=0A }=0A =0A static v= oid ax25_t2timer_expiry(unsigned long param)=0A {=0A ax25_cb *ax25 =3D (ax= 25_cb *)param;=0A- struct sock *sk =3D ax25->sk;=0A =0A- bh_lock_sock(sk);= =0A switch (ax25->ax25_dev->values[AX25_VALUES_PROTOCOL]) {=0A case AX25_= PROTO_STD_SIMPLEX:=0A case AX25_PROTO_STD_DUPLEX:=0A@@ -207,15 +198,12 @@= =0A break;=0A #endif=0A }=0A- bh_unlock_sock(sk);=0A }=0A =0A static voi= d ax25_t3timer_expiry(unsigned long param)=0A {=0A ax25_cb *ax25 =3D (ax25= _cb *)param;=0A- struct sock *sk =3D ax25->sk;=0A =0A- bh_lock_sock(sk);=0A= switch (ax25->ax25_dev->values[AX25_VALUES_PROTOCOL]) {=0A case AX25_PRO= TO_STD_SIMPLEX:=0A case AX25_PROTO_STD_DUPLEX:=0A@@ -231,15 +219,12 @@=0A = break;=0A #endif=0A }=0A- bh_unlock_sock(sk);=0A }=0A =0A static void ax= 25_idletimer_expiry(unsigned long param)=0A {=0A ax25_cb *ax25 =3D (ax25_c= b *)param;=0A- struct sock *sk =3D ax25->sk;=0A =0A- bh_lock_sock(sk);=0A = switch (ax25->ax25_dev->values[AX25_VALUES_PROTOCOL]) {=0A case AX25_PROTO= _STD_SIMPLEX:=0A case AX25_PROTO_STD_DUPLEX:=0A@@ -255,5 +240,4 @@=0A br= eak;=0A #endif=0A }=0A- bh_unlock_sock(sk);=0A }=0Adiff -ru linux-2.6.0-te= st3/net/ax25/sysctl_net_ax25.c linux-2.6.0-test1.rxq3/net/ax25/sysctl_net_a= x25.c=0A--- linux-2.6.0-test3/net/ax25/sysctl_net_ax25.c 2003-08-09 06:41:2= 1.000000000 +0200=0A+++ linux-2.6.0-test1.rxq3/net/ax25/sysctl_net_ax25.c 2= 003-07-24 20:56:37.000000000 +0200=0A@@ -12,20 +12,20 @@=0A #include =0A #include =0A =0A-static int min_ipdefmode[1], = max_ipdefmode[] =3D {1};=0A-static int min_axdefmode[1], max_= axdefmode[] =3D {1};=0A-static int min_backoff[1], max_backoff[] =3D {2};= =0A-static int min_conmode[1], max_conmode[] =3D {2};=0A+static int min_ip= defmode[] =3D {0}, max_ipdefmode[] =3D {1};=0A+static int min_axdefmode[] = =3D {0}, max_axdefmode[] =3D {1};=0A+static int min_backoff[] =3D {0}, max= _backoff[] =3D {2};=0A+static int min_conmode[] =3D {0}, max_conmode[] =3D= {2};=0A static int min_window[] =3D {1}, max_window[] =3D {7};=0A static = int min_ewindow[] =3D {1}, max_ewindow[] =3D {63};=0A static int min_t1[] = =3D {1}, max_t1[] =3D {30 * HZ};=0A static int min_t2[] =3D {1}, max_t2[]= =3D {20 * HZ};=0A-static int min_t3[1], max_t3[] =3D {3600 * HZ};=0A-s= tatic int min_idle[1], max_idle[] =3D {65535 * HZ};=0A+static int min_t3= [] =3D {0}, max_t3[] =3D {3600 * HZ};=0A+static int min_idle[] =3D {0}, m= ax_idle[] =3D {65535 * HZ};=0A static int min_n2[] =3D {1}, max_n2[] =3D {= 31};=0A static int min_paclen[] =3D {1}, max_paclen[] =3D {512};=0A-static= int min_proto[1], max_proto[] =3D {3};=0A-static int min_ds_timeout[1], = max_ds_timeout[] =3D {65535 * HZ};=0A+static int min_proto[] =3D {0}, ma= x_proto[] =3D {3};=0A+static int min_ds_timeout[] =3D {0}, max_ds_timeout[]= =3D {65535 * HZ};=0A =0A static struct ctl_table_header *ax25_table_header= ;=0A =0A@@ -204,8 +204,10 @@=0A for (ax25_table_size =3D sizeof(ctl_table)= , ax25_dev =3D ax25_dev_list; ax25_dev !=3D NULL; ax25_dev =3D ax25_dev->ne= xt)=0A ax25_table_size +=3D sizeof(ctl_table);=0A =0A- if ((ax25_table = =3D kmalloc(ax25_table_size, GFP_ATOMIC)) =3D=3D NULL)=0A+ if ((ax25_table = =3D kmalloc(ax25_table_size, GFP_ATOMIC)) =3D=3D NULL) {=0A+ spin_unlock_b= h(&ax25_dev_lock);=0A return;=0A+ }=0A =0A memset(ax25_table, 0x00, ax25= _table_size);=0A =0Adiff -ru linux-2.6.0-test3/net/netrom/af_netrom.c linux= -2.6.0-test1.rxq3/net/netrom/af_netrom.c=0A--- linux-2.6.0-test3/net/netrom= /af_netrom.c 2003-08-09 06:36:46.000000000 +0200=0A+++ linux-2.6.0-test1.rx= q3/net/netrom/af_netrom.c 2003-07-24 20:56:55.000000000 +0200=0A@@ -147,8 += 147,10 @@=0A spin_lock_bh(&nr_list_lock);=0A sk_for_each(s, node, &nr_lis= t)=0A if (!ax25cmp(&nr_sk(s)->source_addr, addr) &&=0A- s->sk_state = =3D=3D TCP_LISTEN)=0A+ s->sk_state =3D=3D TCP_LISTEN) {=0A+ bh_l= ock_sock(s);=0A goto found;=0A+ }=0A s =3D NULL;=0A found:=0A spin_un= lock_bh(&nr_list_lock);=0A@@ -167,8 +169,10 @@=0A sk_for_each(s, node, &nr= _list) {=0A nr_cb *nr =3D nr_sk(s);=0A =0A- if (nr->my_index =3D=3D in= dex && nr->my_id =3D=3D id)=0A+ if (nr->my_index =3D=3D index && nr->my_id= =3D=3D id) {=0A+ bh_lock_sock(s);=0A goto found;=0A+ }=0A }=0A s = =3D NULL;=0A found:=0A@@ -190,8 +194,10 @@=0A nr_cb *nr =3D nr_sk(s);=0A = =0A if (nr->your_index =3D=3D index && nr->your_id =3D=3D id &&=0A- = !ax25cmp(&nr->dest_addr, dest))=0A+ !ax25cmp(&nr->dest_addr, dest)) = {=0A+ bh_lock_sock(s);=0A goto found;=0A+ }=0A }=0A s =3D NULL;= =0A found:=0A@@ -206,14 +212,17 @@=0A {=0A unsigned short id =3D circuit;= =0A unsigned char i, j;=0A+ struct sock *sk;=0A =0A for (;;) {=0A i =3D= id / 256;=0A j =3D id % 256;=0A =0A- if (i !=3D 0 && j !=3D 0)=0A- if= (nr_find_socket(i, j) =3D=3D NULL)=0A+ if (i !=3D 0 && j !=3D 0) {=0A+ = if ((sk=3Dnr_find_socket(i, j)) =3D=3D NULL)=0A break;=0A+ bh_unlock_= sock(sk);=0A+ }=0A =0A id++;=0A }=0A@@ -231,7 +240,12 @@=0A */=0A stat= ic void nr_destroy_timer(unsigned long data)=0A {=0A- nr_destroy_socket((st= ruct sock *)data);=0A+ struct sock *sk=3D(struct sock *)data;=0A+ bh_lock_s= ock(sk);=0A+ sock_hold(sk);=0A+ nr_destroy_socket(sk);=0A+ bh_unlock_sock(s= k);=0A+ sock_put(sk);=0A }=0A =0A /*=0A@@ -264,17 +278,20 @@=0A =0A kfree= _skb(skb);=0A }=0A+ while ((skb =3D skb_dequeue(&sk->sk_write_queue)) !=3D= NULL) {=0A+ kfree_skb(skb);=0A+ }=0A =0A if (atomic_read(&sk->sk_wmem_al= loc) ||=0A atomic_read(&sk->sk_rmem_alloc)) {=0A /* Defer: outstandi= ng buffers */=0A init_timer(&sk->sk_timer);=0A- sk->sk_timer.expires = =3D jiffies + 10 * HZ;=0A+ sk->sk_timer.expires =3D jiffies + 2 * HZ;=0A = sk->sk_timer.function =3D nr_destroy_timer;=0A sk->sk_timer.data = =3D (unsigned long)sk;=0A add_timer(&sk->sk_timer);=0A } else=0A- sk_fr= ee(sk);=0A+ sock_put(sk);=0A }=0A =0A /*=0A@@ -388,12 +405,15 @@=0A {=0A = struct sock *sk =3D sock->sk;=0A =0A+ lock_sock(sk);=0A if (sk->sk_state != =3D TCP_LISTEN) {=0A memset(&nr_sk(sk)->user_addr, 0, AX25_ADDR_LEN);=0A = sk->sk_max_ack_backlog =3D backlog;=0A sk->sk_state =3D TCP_L= ISTEN;=0A+ release_sock(sk);=0A return 0;=0A }=0A+ release_sock(sk);=0A= =0A return -EOPNOTSUPP;=0A }=0A@@ -495,6 +515,7 @@=0A =0A if (sk =3D=3D = NULL) return 0;=0A =0A+ lock_sock(sk);=0A nr =3D nr_sk(sk);=0A =0A switch= (nr->state) {=0A@@ -528,6 +549,7 @@=0A }=0A =0A sock->sk =3D NULL; =0A= + release_sock(sk);=0A =0A return 0;=0A }=0A@@ -540,21 +562,26 @@=0A stru= ct net_device *dev;=0A ax25_address *user, *source;=0A =0A- if (!sk->sk_za= pped)=0A+ lock_sock(sk);=0A+ if (!sk->sk_zapped) {=0A+ release_sock(sk);= =0A return -EINVAL;=0A-=0A- if (addr_len < sizeof(struct sockaddr_ax25) |= | addr_len > sizeof(struct=0A-full_sockaddr_ax25))=0A+ }=0A+ if (addr_len <= sizeof(struct sockaddr_ax25) || addr_len > sizeof(struct full_sockaddr_ax2= 5)) {=0A+ release_sock(sk);=0A return -EINVAL;=0A-=0A- if (addr_len < (a= ddr->fsa_ax25.sax25_ndigis * sizeof(ax25_address) + sizeof(struct sockaddr_= ax25)))=0A+ }=0A+ if (addr_len < (addr->fsa_ax25.sax25_ndigis * sizeof(ax25= _address) + sizeof(struct sockaddr_ax25))) {=0A+ release_sock(sk);=0A re= turn -EINVAL;=0A-=0A- if (addr->fsa_ax25.sax25_family !=3D AF_NETROM)=0A+ }= =0A+ if (addr->fsa_ax25.sax25_family !=3D AF_NETROM) {=0A+ release_sock(sk= );=0A return -EINVAL;=0A-=0A+ }=0A if ((dev =3D nr_dev_get(&addr->fsa_ax= 25.sax25_call)) =3D=3D NULL) {=0A SOCK_DEBUG(sk, "NET/ROM: bind failed: i= nvalid node callsign\n");=0A+ release_sock(sk);=0A return -EADDRNOTAVAIL= ;=0A }=0A =0A@@ -562,16 +589,22 @@=0A * Only the super user can set an a= rbitrary user callsign.=0A */=0A if (addr->fsa_ax25.sax25_ndigis =3D=3D = 1) {=0A- if (!capable(CAP_NET_BIND_SERVICE))=0A+ if (!capable(CAP_NET_BIN= D_SERVICE)) {=0A+ dev_put(dev);=0A+ release_sock(sk);=0A return -EAC= CES;=0A+ }=0A nr->user_addr =3D addr->fsa_digipeater[0];=0A nr->sour= ce_addr =3D addr->fsa_ax25.sax25_call;=0A } else {=0A source =3D &addr->= fsa_ax25.sax25_call;=0A =0A if ((user =3D ax25_findbyuid(current->euid)) = =3D=3D NULL) {=0A- if (ax25_uid_policy && !capable(CAP_NET_BIND_SERVICE))= =0A+ if (ax25_uid_policy && !capable(CAP_NET_BIND_SERVICE)) {=0A+ rele= ase_sock(sk);=0A+ dev_put(dev);=0A return -EPERM;=0A+ }=0A user= =3D source;=0A }=0A =0A@@ -583,6 +616,8 @@=0A nr_insert_socket(sk);=0A = =0A sk->sk_zapped =3D 0;=0A+ dev_put(dev);=0A+ release_sock(sk);=0A SOCK_= DEBUG(sk, "NET/ROM: socket is bound\n");=0A return 0;=0A }=0A@@ -596,39 +6= 31,50 @@=0A ax25_address *user, *source =3D NULL;=0A struct net_device *d= ev;=0A =0A+ lock_sock(sk);=0A if (sk->sk_state =3D=3D TCP_ESTABLISHED && s= ock->state =3D=3D SS_CONNECTING) {=0A sock->state =3D SS_CONNECTED;=0A+ = release_sock(sk);=0A return 0; /* Connect completed during a ERESTARTSYS = event */=0A }=0A =0A if (sk->sk_state =3D=3D TCP_CLOSE && sock->state =3D= =3D SS_CONNECTING) {=0A sock->state =3D SS_UNCONNECTED;=0A+ release_sock= (sk);=0A return -ECONNREFUSED;=0A }=0A =0A- if (sk->sk_state =3D=3D TCP_= ESTABLISHED)=0A+ if (sk->sk_state =3D=3D TCP_ESTABLISHED) {=0A+ release_so= ck(sk);=0A return -EISCONN; /* No reconnect on a seqpacket socket */=0A+ = }=0A =0A sk->sk_state =3D TCP_CLOSE; =0A sock->state =3D SS_UNCONNECTED= ;=0A =0A- if (addr_len !=3D sizeof(struct sockaddr_ax25) && addr_len !=3D s= izeof(struct full_sockaddr_ax25))=0A+ if (addr_len !=3D sizeof(struct socka= ddr_ax25) && addr_len !=3D sizeof(struct full_sockaddr_ax25)) {=0A+ releas= e_sock(sk);=0A return -EINVAL;=0A-=0A- if (addr->sax25_family !=3D AF_NET= ROM)=0A+ }=0A+ if (addr->sax25_family !=3D AF_NETROM) {=0A+ release_sock(s= k);=0A return -EINVAL;=0A-=0A+ }=0A if (sk->sk_zapped) { /* Must bind fi= rst - autobinding in this may or may not work */=0A sk->sk_zapped =3D 0;= =0A =0A- if ((dev =3D nr_dev_first()) =3D=3D NULL)=0A+ if ((dev =3D nr_de= v_first()) =3D=3D NULL) {=0A+ release_sock(sk);=0A return -ENETUNREACH= ;=0A-=0A+ }=0A source =3D (ax25_address *)dev->dev_addr;=0A =0A if ((u= ser =3D ax25_findbyuid(current->euid)) =3D=3D NULL) {=0A- if (ax25_uid_po= licy && !capable(CAP_NET_ADMIN))=0A+ if (ax25_uid_policy && !capable(CAP_= NET_ADMIN)) {=0A+ dev_put(dev);=0A+ release_sock(sk);=0A return -= EPERM;=0A+ }=0A user =3D source;=0A }=0A =0A@@ -636,12 +682,15 @@=0A= nr->source_addr =3D *source;=0A nr->device =3D dev;=0A =0A+ dev_= put(dev);=0A nr_insert_socket(sk); /* Finish the bind */=0A }=0A =0A n= r->dest_addr =3D addr->sax25_call;=0A =0A+ release_sock(sk);=0A circuit = =3D nr_find_next_circuit();=0A+ lock_sock(sk);=0A =0A nr->my_index =3D cir= cuit / 256;=0A nr->my_id =3D circuit % 256;=0A@@ -659,8 +708,10 @@=0A = nr_start_heartbeat(sk);=0A =0A /* Now the loop */=0A- if (sk->sk_state != =3D TCP_ESTABLISHED && (flags & O_NONBLOCK))=0A+ if (sk->sk_state !=3D TCP_= ESTABLISHED && (flags & O_NONBLOCK)) {=0A+ release_sock(sk);=0A return -= EINPROGRESS;=0A+ }=0A =0A /*=0A * A Connect Ack with Choke or timeout = or failed routing will go to=0A@@ -675,8 +726,10 @@=0A set_current_state= (TASK_INTERRUPTIBLE);=0A if (sk->sk_state !=3D TCP_SYN_SENT)=0A brea= k;=0A+ release_sock(sk);=0A if (!signal_pending(tsk)) {=0A schedul= e();=0A+ lock_sock(sk);=0A continue;=0A }=0A return -ERESTARTS= YS;=0A@@ -687,10 +740,12 @@=0A =0A if (sk->sk_state !=3D TCP_ESTABLISHED) = {=0A sock->state =3D SS_UNCONNECTED;=0A+ release_sock(sk);=0A return s= ock_error(sk); /* Always set at this point */=0A }=0A =0A sock->state =3D= SS_CONNECTED;=0A+ release_sock(sk);=0A =0A return 0;=0A }=0A@@ -753,6 +80= 8,7 @@=0A newsock->sk =3D newsk;=0A =0A out:=0A+ release_sock(sk);=0A ret= urn err;=0A }=0A =0A@@ -763,9 +819,12 @@=0A struct sock *sk =3D sock->sk;= =0A nr_cb *nr =3D nr_sk(sk);=0A =0A+ lock_sock(sk);=0A if (peer !=3D 0) {= =0A- if (sk->sk_state !=3D TCP_ESTABLISHED)=0A+ if (sk->sk_state !=3D TCP= _ESTABLISHED) {=0A+ release_sock(sk);=0A return -ENOTCONN;=0A+ }=0A = sax->fsa_ax25.sax25_family =3D AF_NETROM;=0A sax->fsa_ax25.sax25_ndigis = =3D 1;=0A sax->fsa_ax25.sax25_call =3D nr->user_addr;=0A@@ -777,6 +836,= 7 @@=0A sax->fsa_ax25.sax25_call =3D nr->source_addr;=0A *uaddr_len = =3D sizeof(struct sockaddr_ax25);=0A }=0A+ release_sock(sk);=0A =0A retur= n 0;=0A }=0A@@ -790,6 +850,7 @@=0A unsigned short circuit_index, circuit_i= d;=0A unsigned short peer_circuit_index, peer_circuit_id;=0A unsigned sho= rt frametype, flags, window, timeout;=0A+ int ret;=0A =0A skb->sk =3D NULL= ; /* Initially we don't know who it's for */=0A =0A@@ -847,7 +908,9 @@=0A = else=0A nr_sk(sk)->bpqext =3D 0;=0A =0A- return nr_process_rx_frame(s= k, skb);=0A+ ret =3D nr_process_rx_frame(sk, skb);=0A+ bh_unlock_sock(sk)= ;=0A+ return ret;=0A }=0A =0A /*=0A@@ -877,6 +940,8 @@=0A if (!sk || sk= ->sk_ack_backlog =3D=3D sk->sk_max_ack_backlog ||=0A (make =3D nr_make= _new(sk)) =3D=3D NULL) {=0A nr_transmit_refusal(skb, 0);=0A+ if (sk)=0A+= bh_unlock_sock(sk);=0A return 0;=0A }=0A =0A@@ -894,7 +959,9 @@=0A n= r_make->your_index =3D circuit_index;=0A nr_make->your_id =3D circuit= _id;=0A =0A+ bh_unlock_sock(sk);=0A circuit =3D nr_find_next_circuit();=0A= + bh_lock_sock(sk);=0A =0A nr_make->my_index =3D circuit / 256;=0A nr_= make->my_id =3D circuit % 256;=0A@@ -936,6 +1003,7 @@=0A if (!sock_f= lag(sk, SOCK_DEAD))=0A sk->sk_data_ready(sk, skb->len);=0A =0A+ bh_unlock= _sock(sk);=0A return 1;=0A }=0A =0A@@ -954,28 +1022,42 @@=0A if (msg->msg= _flags & ~(MSG_DONTWAIT|MSG_EOR))=0A return -EINVAL;=0A =0A- if (sk->sk_z= apped)=0A- return -EADDRNOTAVAIL;=0A+ lock_sock(sk);=0A+ if (sk->sk_zapped= ) {=0A+ err =3D -EADDRNOTAVAIL;=0A+ goto out;=0A+ }=0A =0A if (sk->sk_sh= utdown & SEND_SHUTDOWN) {=0A send_sig(SIGPIPE, current, 0);=0A- return -= EPIPE;=0A+ err =3D -EPIPE;=0A+ goto out;=0A }=0A =0A- if (nr->device =3D= =3D NULL)=0A- return -ENETUNREACH;=0A+ if (nr->device =3D=3D NULL) {=0A+ = err =3D -ENETUNREACH;=0A+ goto out;=0A+ }=0A =0A if (usax) {=0A- if (msg= ->msg_namelen < sizeof(sax))=0A- return -EINVAL;=0A+ if (msg->msg_namele= n < sizeof(sax)) {=0A+ err =3D -EINVAL;=0A+ goto out;=0A+ }=0A sax = =3D *usax;=0A- if (ax25cmp(&nr->dest_addr, &sax.sax25_call) !=3D 0)=0A- = return -EISCONN;=0A- if (sax.sax25_family !=3D AF_NETROM)=0A- return -EI= NVAL;=0A+ if (ax25cmp(&nr->dest_addr, &sax.sax25_call) !=3D 0) {=0A+ err= =3D -EISCONN;=0A+ goto out;=0A+ }=0A+ if (sax.sax25_family !=3D AF_NET= ROM) {=0A+ err =3D -EINVAL;=0A+ goto out;=0A+ }=0A } else {=0A- if (= sk->sk_state !=3D TCP_ESTABLISHED)=0A- return -ENOTCONN;=0A+ if (sk->sk_= state !=3D TCP_ESTABLISHED) {=0A+ err =3D -ENOTCONN;=0A+ goto out;=0A+ = }=0A sax.sax25_family =3D AF_NETROM;=0A sax.sax25_call =3D nr->dest_= addr;=0A }=0A@@ -984,10 +1066,10 @@=0A =0A /* Build a packet */=0A SOCK_= DEBUG(sk, "NET/ROM: sendto: building packet.\n");=0A- size =3D len + AX25_B= PQ_HEADER_LEN + AX25_MAX_HEADER_LEN + NR_NETWORK_LEN + NR_TRANSPORT_LEN;=0A= + size =3D len + NR_NETWORK_LEN + NR_TRANSPORT_LEN;=0A =0A if ((skb =3D so= ck_alloc_send_skb(sk, size, msg->msg_flags & MSG_DONTWAIT, &err)) =3D=3D NU= LL)=0A- return err;=0A+ goto out;=0A =0A skb_reserve(skb, size - len);= =0A =0A@@ -1022,12 +1104,16 @@=0A =0A if (sk->sk_state !=3D TCP_ESTABLISHE= D) {=0A kfree_skb(skb);=0A- return -ENOTCONN;=0A+ err =3D -ENOTCONN;=0A= + goto out;=0A }=0A =0A nr_output(sk, skb); /* Shove it onto the queue *= /=0A =0A- return len;=0A+ err =3D len;=0A+out:=0A+ release_sock(sk);=0A+ re= turn err;=0A }=0A =0A static int nr_recvmsg(struct kiocb *iocb, struct sock= et *sock,=0A@@ -1044,12 +1130,17 @@=0A * us! We do one quick check first = though=0A */=0A =0A- if (sk->sk_state !=3D TCP_ESTABLISHED)=0A+ lock_sock= (sk);=0A+ if (sk->sk_state !=3D TCP_ESTABLISHED) {=0A+ release_sock(sk);= =0A return -ENOTCONN;=0A+ }=0A =0A /* Now we can treat all alike */=0A- = if ((skb =3D skb_recv_datagram(sk, flags & ~MSG_DONTWAIT, flags & MSG_DONTW= AIT, &er)) =3D=3D NULL)=0A+ if ((skb =3D skb_recv_datagram(sk, flags & ~MSG= _DONTWAIT, flags & MSG_DONTWAIT, &er)) =3D=3D NULL) {=0A+ release_sock(sk)= ;=0A return er;=0A+ }=0A =0A skb->h.raw =3D skb->data;=0A copied = =3D skb->len;=0A@@ -1070,6 +1161,7 @@=0A =0A skb_free_datagram(sk, skb);= =0A =0A+ release_sock(sk);=0A return copied;=0A }=0A =0A@@ -1077,13 +1169,= 16 @@=0A static int nr_ioctl(struct socket *sock, unsigned int cmd, unsigne= d long arg)=0A {=0A struct sock *sk =3D sock->sk;=0A+ int ret;=0A =0A+ loc= k_sock(sk);=0A switch (cmd) {=0A case TIOCOUTQ: {=0A long amount;=0A = amount =3D sk->sk_sndbuf - atomic_read(&sk->sk_wmem_alloc);=0A if (amount= < 0)=0A amount =3D 0;=0A+ release_sock(sk);=0A return put_user(amoun= t, (int *)arg);=0A }=0A =0A@@ -1093,15 +1188,21 @@=0A /* These two are s= afe on a single CPU system as only user tasks fiddle here */=0A if ((skb = =3D skb_peek(&sk->sk_receive_queue)) !=3D NULL)=0A amount =3D skb->len;= =0A+ release_sock(sk);=0A return put_user(amount, (int *)arg);=0A }=0A = =0A case SIOCGSTAMP:=0A if (sk !=3D NULL) {=0A- if (!sk->sk_stamp.tv_s= ec)=0A+ if (!sk->sk_stamp.tv_sec) {=0A+ release_sock(sk);=0A retur= n -ENOENT;=0A- return copy_to_user((void *)arg, &sk->sk_stamp, sizeof(str= uct timeval)) ? -EFAULT : 0;=0A+ }=0A+ ret =3D copy_to_user((void *)arg= , &sk->sk_stamp, sizeof(struct timeval)) ? -EFAULT : 0;=0A+ release_sock(= sk);=0A+ return ret;=0A }=0A+ release_sock(sk);=0A return -EINVAL;= =0A =0A case SIOCGIFADDR:=0A@@ -1114,17 +1215,21 @@=0A case SIOCSIFNETMAS= K:=0A case SIOCGIFMETRIC:=0A case SIOCSIFMETRIC:=0A+ release_sock(sk);= =0A return -EINVAL;=0A =0A case SIOCADDRT:=0A case SIOCDELRT:=0A case = SIOCNRDECOBS:=0A+ release_sock(sk);=0A if (!capable(CAP_NET_ADMIN)) retu= rn -EPERM;=0A return nr_rt_ioctl(cmd, (void *)arg);=0A =0A default:=0A+ = release_sock(sk);=0A return dev_ioctl(cmd, (void *)arg);=0A }=0A+ relea= se_sock(sk);=0A =0A return 0;=0A }=0A@@ -1144,7 +1249,9 @@=0A len +=3D sp= rintf(buffer, "user_addr dest_node src_node dev my your st vs vr v= a t1 t2 t4 idle n2 wnd Snd-Q Rcv-Q inode\n");=0A =0A sk= _for_each(s, node, &nr_list) {=0A- nr_cb *nr =3D nr_sk(s);=0A+ nr_cb *nr;= =0A+ bh_lock_sock(s);=0A+ nr =3D nr_sk(s);=0A =0A if ((dev =3D nr->devi= ce) =3D=3D NULL)=0A devname =3D "???";=0A@@ -1187,7 +1294,7 @@=0A len= =3D 0;=0A begin =3D pos;=0A }=0A-=0A+ bh_unlock_sock(s);=0A if (= pos > offset + length)=0A break;=0A }=0A@@ -1256,6 +1363,7 @@=0A =0A f= or (i =3D 0; i < nr_ndevs; i++) {=0A sprintf(dev_nr[i].name, "nr%d", i);= =0A+ dev_nr[i].base_addr =3D i;=0A dev_nr[i].init =3D nr_init;=0A regi= ster_netdev(&dev_nr[i]);=0A }=0A@@ -1300,23 +1408,23 @@=0A =0A nr_rt_free= ();=0A =0A- ax25_protocol_release(AX25_P_NETROM);=0A+#ifdef CONFIG_SYSCTL= =0A+ nr_unregister_sysctl();=0A+#endif=0A+=0A ax25_linkfail_release(nr_lin= k_failed);=0A+ ax25_protocol_release(AX25_P_NETROM);=0A =0A unregister_net= device_notifier(&nr_dev_notifier);=0A =0A-#ifdef CONFIG_SYSCTL=0A- nr_unreg= ister_sysctl();=0A-#endif=0A sock_unregister(PF_NETROM);=0A =0A for (i = =3D 0; i < nr_ndevs; i++) {=0A if (dev_nr[i].priv !=3D NULL) {=0A+ unre= gister_netdev(&dev_nr[i]);=0A kfree(dev_nr[i].priv);=0A dev_nr[i].pri= v =3D NULL;=0A- unregister_netdev(&dev_nr[i]);=0A }=0A- kfree(dev_nr[i= ].name);=0A }=0A =0A kfree(dev_nr);=0Adiff -ru linux-2.6.0-test3/net/netr= om/nr_dev.c linux-2.6.0-test1.rxq3/net/netrom/nr_dev.c=0A--- linux-2.6.0-te= st3/net/netrom/nr_dev.c 2003-08-09 06:41:27.000000000 +0200=0A+++ linux-2.6= .0-test1.rxq3/net/netrom/nr_dev.c 2003-07-24 20:56:54.000000000 +0200=0A@@ = -159,11 +159,13 @@=0A {=0A struct sockaddr *sa =3D addr;=0A =0A- ax25_list= en_release((ax25_address *)dev->dev_addr, NULL);=0A+ if (dev->flags & IFF_U= P)=0A+ ax25_listen_release((ax25_address *)dev->dev_addr, NULL);=0A =0A m= emcpy(dev->dev_addr, sa->sa_data, dev->addr_len);=0A =0A- ax25_listen_regis= ter((ax25_address *)dev->dev_addr, NULL);=0A+ if (dev->flags & IFF_UP)=0A+ = ax25_listen_register((ax25_address *)dev->dev_addr, NULL);=0A =0A return = 0;=0A }=0A@@ -177,8 +179,8 @@=0A =0A static int nr_close(struct net_device = *dev)=0A {=0A- netif_stop_queue(dev);=0A ax25_listen_release((ax25_address= *)dev->dev_addr, NULL);=0A+ netif_stop_queue(dev);=0A return 0;=0A }=0A = =0A@@ -197,16 +199,16 @@=0A =0A int nr_init(struct net_device *dev)=0A {=0A= - SET_MODULE_OWNER(dev);=0A dev->mtu =3D NR_MAX_PACKET_SIZE;=0A dev->har= d_start_xmit =3D nr_xmit;=0A dev->open =3D nr_open;=0A dev->stop =3D nr= _close;=0A =0A dev->hard_header =3D nr_header;=0A- dev->hard_header_len = =3D AX25_BPQ_HEADER_LEN + AX25_MAX_HEADER_LEN + NR_NETWORK_LEN + NR_TRANSPO= RT_LEN;=0A+ dev->hard_header_len =3D NR_NETWORK_LEN + NR_TRANSPORT_LEN;=0A = dev->addr_len =3D AX25_ADDR_LEN;=0A dev->type =3D ARPHRD_NETROM;=0A+ de= v->tx_queue_len =3D 40;=0A dev->rebuild_header =3D nr_rebuild_header;=0A = dev->set_mac_address =3D nr_set_mac_address;=0A =0Adiff -ru linux-2.6.0-= test3/net/netrom/nr_in.c linux-2.6.0-test1.rxq3/net/netrom/nr_in.c=0A--- li= nux-2.6.0-test3/net/netrom/nr_in.c 2003-08-09 06:34:46.000000000 +0200=0A++= + linux-2.6.0-test1.rxq3/net/netrom/nr_in.c 2003-07-24 20:56:55.000000000 += 0200=0A@@ -74,6 +74,7 @@=0A static int nr_state1_machine(struct sock *sk, s= truct sk_buff *skb,=0A int frametype)=0A {=0A+ bh_lock_sock(sk);=0A switc= h (frametype) {=0A case NR_CONNACK: {=0A nr_cb *nr =3D nr_sk(sk);=0A@@ -= 102,6 +103,7 @@=0A default:=0A break;=0A }=0A+ bh_unlock_sock(sk);=0A = =0A return 0;=0A }=0A@@ -114,6 +116,7 @@=0A static int nr_state2_machine(s= truct sock *sk, struct sk_buff *skb,=0A int frametype)=0A {=0A+ bh_lock_so= ck(sk);=0A switch (frametype) {=0A case NR_CONNACK | NR_CHOKE_FLAG:=0A = nr_disconnect(sk, ECONNRESET);=0A@@ -129,6 +132,7 @@=0A default:=0A brea= k;=0A }=0A+ bh_unlock_sock(sk);=0A =0A return 0;=0A }=0A@@ -150,6 +154,7 = @@=0A nr =3D skb->data[18];=0A ns =3D skb->data[17];=0A =0A+ bh_lock_sock= (sk);=0A switch (frametype) {=0A case NR_CONNREQ:=0A nr_write_internal(= sk, NR_CONNACK);=0A@@ -260,6 +265,7 @@=0A default:=0A break;=0A }=0A+ b= h_unlock_sock(sk);=0A =0A return queued;=0A }=0Adiff -ru linux-2.6.0-test3= /net/netrom/nr_route.c linux-2.6.0-test1.rxq3/net/netrom/nr_route.c=0A--- l= inux-2.6.0-test3/net/netrom/nr_route.c 2003-08-09 06:42:17.000000000 +0200= =0A+++ linux-2.6.0-test1.rxq3/net/netrom/nr_route.c 2003-07-24 20:56:55.000= 000000 +0200=0A@@ -39,10 +39,45 @@=0A =0A static unsigned int nr_neigh_no = =3D 1;=0A =0A-static struct nr_node *nr_node_list;=0A-static spinlock_t nr= _node_lock;=0A-static struct nr_neigh *nr_neigh_list;=0A-static spinlock_t = nr_neigh_lock;=0A+HLIST_HEAD(nr_node_list);=0A+spinlock_t nr_node_list_lock= =3D SPIN_LOCK_UNLOCKED;=0A+HLIST_HEAD(nr_neigh_list);=0A+spinlock_t nr_nei= gh_list_lock =3D SPIN_LOCK_UNLOCKED;=0A+=0A+struct nr_node *nr_node_get(ax2= 5_address *callsign)=0A+{=0A+ struct nr_node *found =3D NULL;=0A+ struct nr= _node *nr_node;=0A+ struct hlist_node *node;=0A+=0A+ spin_lock_bh(&nr_node_= list_lock);=0A+ nr_node_for_each(nr_node, node, &nr_node_list)=0A+ if (ax2= 5cmp(callsign, &nr_node->callsign) =3D=3D 0) {=0A+ nr_node_hold(nr_node);= =0A+ found =3D nr_node;=0A+ break;=0A+ }=0A+ spin_unlock_bh(&nr_node_l= ist_lock);=0A+ return found;=0A+}=0A+=0A+struct nr_neigh *nr_neigh_get_dev(= ax25_address *callsign, struct net_device *dev)=0A+{=0A+ struct nr_neigh *f= ound =3D NULL;=0A+ struct nr_neigh *nr_neigh;=0A+ struct hlist_node *node;= =0A+=0A+ spin_lock_bh(&nr_neigh_list_lock);=0A+ nr_neigh_for_each(nr_neigh,= node, &nr_neigh_list)=0A+ if (ax25cmp(callsign, &nr_neigh->callsign) =3D= =3D 0 &&=0A+ nr_neigh->dev =3D=3D dev) {=0A+ nr_neigh_hold(nr_neigh)= ;=0A+ found =3D nr_neigh;=0A+ break;=0A+ }=0A+ spin_unlock_bh(&nr_neig= h_list_lock);=0A+ return found;=0A+}=0A =0A static void nr_remove_neigh(str= uct nr_neigh *);=0A =0A@@ -57,17 +92,16 @@=0A struct nr_neigh *nr_neigh;= =0A struct nr_route nr_route;=0A int i, found;=0A+ struct net_device *ode= v;=0A =0A- if (nr_dev_get(nr) !=3D NULL) /* Can't add routes to ourself */= =0A+ if ((odev=3Dnr_dev_get(nr)) !=3D NULL) { /* Can't add routes to oursel= f */=0A+ dev_put(odev);=0A return -EINVAL;=0A+ }=0A =0A- for (nr_node = =3D nr_node_list; nr_node !=3D NULL; nr_node =3D nr_node->next)=0A- if (ax= 25cmp(nr, &nr_node->callsign) =3D=3D 0)=0A- break;=0A+ nr_node =3D nr_nod= e_get(nr);=0A =0A- for (nr_neigh =3D nr_neigh_list; nr_neigh !=3D NULL; nr_= neigh =3D nr_neigh->next)=0A- if (ax25cmp(ax25, &nr_neigh->callsign) =3D= =3D 0 && nr_neigh->dev =3D=3D dev)=0A- break;=0A+ nr_neigh =3D nr_neigh_g= et_dev(ax25, dev);=0A =0A /*=0A * The L2 link to a neighbour has failed = in the past=0A@@ -76,24 +110,36 @@=0A * routes now (and not wait for a no= de broadcast).=0A */=0A if (nr_neigh !=3D NULL && nr_neigh->failed !=3D = 0 && quality =3D=3D 0) {=0A- struct nr_node *node;=0A+ struct nr_node *nr= _nodet;=0A+ struct hlist_node *node;=0A =0A- for (node =3D nr_node_list; = node !=3D NULL; node =3D node->next)=0A- for (i =3D 0; i < node->count; i= ++)=0A- if (node->routes[i].neighbour =3D=3D nr_neigh)=0A- if (i < n= ode->which)=0A- node->which =3D i;=0A+ spin_lock_bh(&nr_node_list_loc= k);=0A+ nr_node_for_each(nr_nodet, node, &nr_node_list) {=0A+ nr_node_lo= ck(nr_nodet);=0A+ for (i =3D 0; i < nr_nodet->count; i++)=0A+ if (nr_n= odet->routes[i].neighbour =3D=3D nr_neigh)=0A+ if (i < nr_nodet->which)= =0A+ nr_nodet->which =3D i;=0A+ nr_node_unlock(nr_nodet);=0A+ }=0A+= spin_unlock_bh(&nr_node_list_lock);=0A }=0A =0A if (nr_neigh !=3D NULL)= =0A nr_neigh->failed =3D 0;=0A =0A- if (quality =3D=3D 0 && nr_neigh !=3D= NULL && nr_node !=3D NULL)=0A+ if (quality =3D=3D 0 && nr_neigh !=3D NULL = && nr_node !=3D NULL) {=0A+ nr_neigh_put(nr_neigh);=0A+ nr_node_put(nr_no= de);=0A return 0;=0A+ }=0A =0A if (nr_neigh =3D=3D NULL) {=0A- if ((nr_= neigh =3D kmalloc(sizeof(*nr_neigh), GFP_ATOMIC)) =3D=3D NULL)=0A+ if ((nr= _neigh =3D kmalloc(sizeof(*nr_neigh), GFP_ATOMIC)) =3D=3D NULL) {=0A+ if = (nr_node)=0A+ nr_node_put(nr_node);=0A return -ENOMEM;=0A+ }=0A =0A = nr_neigh->callsign =3D *ax25;=0A nr_neigh->digipeat =3D NULL;=0A@@ -104= ,48 +150,58 @@=0A nr_neigh->count =3D 0;=0A nr_neigh->number =3D n= r_neigh_no++;=0A nr_neigh->failed =3D 0;=0A+ atomic_set(&nr_neigh->ref= count, 1);=0A =0A if (ax25_digi !=3D NULL && ax25_digi->ndigi > 0) {=0A = if ((nr_neigh->digipeat =3D kmalloc(sizeof(*ax25_digi), GFP_KERNEL)) =3D= =3D NULL) {=0A kfree(nr_neigh);=0A+ if (nr_node)=0A+ nr_node_put= (nr_node);=0A return -ENOMEM;=0A }=0A memcpy(nr_neigh->digipeat, = ax25_digi,=0A sizeof(*ax25_digi));=0A }=0A =0A- spin_lock_bh(&nr_ne= igh_lock);=0A- nr_neigh->next =3D nr_neigh_list;=0A- nr_neigh_list =3D n= r_neigh;=0A- spin_unlock_bh(&nr_neigh_lock);=0A+ spin_lock_bh(&nr_neigh_l= ist_lock);=0A+ hlist_add_head(&nr_neigh->neigh_node, &nr_neigh_list);=0A+ = nr_neigh_hold(nr_neigh);=0A+ spin_unlock_bh(&nr_neigh_list_lock);=0A }= =0A =0A if (quality !=3D 0 && ax25cmp(nr, ax25) =3D=3D 0 && !nr_neigh->loc= ked)=0A nr_neigh->quality =3D quality;=0A =0A if (nr_node =3D=3D NULL) {= =0A- if ((nr_node =3D kmalloc(sizeof(*nr_node), GFP_ATOMIC)) =3D=3D NULL)= =0A+ if ((nr_node =3D kmalloc(sizeof(*nr_node), GFP_ATOMIC)) =3D=3D NULL) = {=0A+ if (nr_neigh)=0A+ nr_neigh_put(nr_neigh);=0A return -ENOMEM;= =0A+ }=0A =0A nr_node->callsign =3D *nr;=0A strcpy(nr_node->mnemonic, = mnemonic);=0A =0A nr_node->which =3D 0;=0A nr_node->count =3D 1;=0A+ a= tomic_set(&nr_node->refcount, 1);=0A+ nr_node->node_lock =3D SPIN_LOCK_UNL= OCKED;=0A =0A nr_node->routes[0].quality =3D quality;=0A nr_node->rou= tes[0].obs_count =3D obs_count;=0A nr_node->routes[0].neighbour =3D nr_ne= igh;=0A =0A- spin_lock_bh(&nr_node_lock);=0A- nr_node->next =3D nr_node_l= ist;=0A- nr_node_list =3D nr_node;=0A- spin_unlock_bh(&nr_node_lock);=0A= -=0A+ nr_neigh_hold(nr_neigh);=0A nr_neigh->count++;=0A =0A+ spin_lock_= bh(&nr_node_list_lock);=0A+ hlist_add_head(&nr_node->node_node, &nr_node_l= ist);=0A+ /* refcount initialized at 1 */=0A+ spin_unlock_bh(&nr_node_lis= t_lock);=0A+=0A return 0;=0A }=0A+ nr_node_lock(nr_node);=0A =0A if (qu= ality !=3D 0)=0A strcpy(nr_node->mnemonic, mnemonic);=0A@@ -171,11 +227,1= 3 @@=0A =0A nr_node->which++;=0A nr_node->count++;=0A+ nr_neigh_hol= d(nr_neigh);=0A nr_neigh->count++;=0A } else {=0A /* It must be bet= ter than the worst */=0A if (quality > nr_node->routes[2].quality) {=0A = nr_node->routes[2].neighbour->count--;=0A+ nr_neigh_put(nr_node->rou= tes[2].neighbour);=0A =0A if (nr_node->routes[2].neighbour->count =3D= =3D 0 && !nr_node->routes[2].neighbour->locked)=0A nr_remove_neigh(nr_= node->routes[2].neighbour);=0A@@ -184,6 +242,7 @@=0A nr_node->routes[2]= .obs_count =3D obs_count;=0A nr_node->routes[2].neighbour =3D nr_neigh;= =0A =0A+ nr_neigh_hold(nr_neigh);=0A nr_neigh->count++;=0A }=0A = }=0A@@ -244,62 +303,42 @@=0A }=0A }=0A =0A+ nr_neigh_put(nr_neigh);=0A+= nr_node_unlock(nr_node);=0A+ nr_node_put(nr_node);=0A return 0;=0A }=0A = =0A-static void nr_remove_node(struct nr_node *nr_node)=0A+static inline vo= id __nr_remove_node(struct nr_node *nr_node)=0A {=0A- struct nr_node *s;=0A= -=0A- spin_lock_bh(&nr_node_lock);=0A- if ((s =3D nr_node_list) =3D=3D nr_n= ode) {=0A- nr_node_list =3D nr_node->next;=0A- spin_unlock_bh(&nr_node_lo= ck);=0A- kfree(nr_node);=0A- return;=0A- }=0A-=0A- while (s !=3D NULL && = s->next !=3D NULL) {=0A- if (s->next =3D=3D nr_node) {=0A- s->next =3D n= r_node->next;=0A- spin_unlock_bh(&nr_node_lock);=0A- kfree(nr_node);=0A= - return;=0A- }=0A+ hlist_del_init(&nr_node->node_node);=0A+ nr_node_put= (nr_node);=0A+}=0A =0A- s =3D s->next;=0A- }=0A+#define nr_remove_node_loc= ked(__node) \=0A+ __nr_remove_node(__node)=0A =0A- spin_unlock_bh(&nr_node_= lock);=0A+static void nr_remove_node(struct nr_node *nr_node)=0A+{=0A+ spin= _lock_bh(&nr_node_list_lock);=0A+ __nr_remove_node(nr_node);=0A+ spin_unloc= k_bh(&nr_node_list_lock);=0A }=0A =0A-static void nr_remove_neigh(struct nr= _neigh *nr_neigh)=0A+static inline void __nr_remove_neigh(struct nr_neigh *= nr_neigh)=0A {=0A- struct nr_neigh *s;=0A+ hlist_del_init(&nr_neigh->neigh_= node);=0A+ nr_neigh_put(nr_neigh);=0A+}=0A =0A- spin_lock_bh(&nr_neigh_lock= );=0A- if ((s =3D nr_neigh_list) =3D=3D nr_neigh) {=0A- nr_neigh_list =3D = nr_neigh->next;=0A- spin_unlock_bh(&nr_neigh_lock);=0A- if (nr_neigh->dig= ipeat !=3D NULL)=0A- kfree(nr_neigh->digipeat);=0A- kfree(nr_neigh);=0A-= return;=0A- }=0A+#define nr_remove_neigh_locked(__neigh) \=0A+ __nr_remov= e_neigh(__neigh)=0A =0A- while (s !=3D NULL && s->next !=3D NULL) {=0A- if= (s->next =3D=3D nr_neigh) {=0A- s->next =3D nr_neigh->next;=0A- spin_u= nlock_bh(&nr_neigh_lock);=0A- if (nr_neigh->digipeat !=3D NULL)=0A- kf= ree(nr_neigh->digipeat);=0A- kfree(nr_neigh);=0A- return;=0A- }=0A-=0A= - s =3D s->next;=0A- }=0A- spin_unlock_bh(&nr_neigh_lock);=0A+static void = nr_remove_neigh(struct nr_neigh *nr_neigh)=0A+{=0A+ spin_lock_bh(&nr_neigh_= list_lock);=0A+ __nr_remove_neigh(nr_neigh);=0A+ spin_unlock_bh(&nr_neigh_l= ist_lock);=0A }=0A =0A /*=0A@@ -312,26 +351,27 @@=0A struct nr_neigh *nr_n= eigh;=0A int i;=0A =0A- for (nr_node =3D nr_node_list; nr_node !=3D NULL; = nr_node =3D nr_node->next)=0A- if (ax25cmp(callsign, &nr_node->callsign) = =3D=3D 0)=0A- break;=0A+ nr_node =3D nr_node_get(callsign);=0A =0A if (n= r_node =3D=3D NULL)=0A return -EINVAL;=0A =0A- for (nr_neigh =3D nr_neigh= _list; nr_neigh !=3D NULL; nr_neigh =3D nr_neigh->next)=0A- if (ax25cmp(ne= ighbour, &nr_neigh->callsign) =3D=3D 0 && nr_neigh->dev =3D=3D dev)=0A- b= reak;=0A+ nr_neigh =3D nr_neigh_get_dev(neighbour, dev);=0A =0A- if (nr_nei= gh =3D=3D NULL)=0A+ if (nr_neigh =3D=3D NULL) {=0A+ nr_node_put(nr_node);= =0A return -EINVAL;=0A+ }=0A =0A+ nr_node_lock(nr_node);=0A for (i =3D 0= ; i < nr_node->count; i++) {=0A if (nr_node->routes[i].neighbour =3D=3D n= r_neigh) {=0A nr_neigh->count--;=0A+ nr_neigh_put(nr_neigh);=0A =0A = if (nr_neigh->count =3D=3D 0 && !nr_neigh->locked)=0A nr_remove_neigh(= nr_neigh);=0A+ nr_neigh_put(nr_neigh);=0A =0A nr_node->count--;=0A =0A= @@ -346,11 +386,16 @@=0A case 2:=0A break;=0A }=0A+ nr_node= _put(nr_node);=0A }=0A+ nr_node_unlock(nr_node);=0A =0A return 0;= =0A }=0A }=0A+ nr_neigh_put(nr_neigh);=0A+ nr_node_unlock(nr_node);=0A+ = nr_node_put(nr_node);=0A =0A return -EINVAL;=0A }=0A@@ -362,12 +407,12 @@= =0A {=0A struct nr_neigh *nr_neigh;=0A =0A- for (nr_neigh =3D nr_neigh_lis= t; nr_neigh !=3D NULL; nr_neigh =3D nr_neigh->next) {=0A- if (ax25cmp(call= sign, &nr_neigh->callsign) =3D=3D 0 && nr_neigh->dev =3D=3D dev) {=0A- nr= _neigh->quality =3D quality;=0A- nr_neigh->locked =3D 1;=0A- return 0;= =0A- }=0A+ nr_neigh =3D nr_neigh_get_dev(callsign, dev);=0A+ if (nr_neigh)= {=0A+ nr_neigh->quality =3D quality;=0A+ nr_neigh->locked =3D 1;=0A+ n= r_neigh_put(nr_neigh);=0A+ return 0;=0A }=0A =0A if ((nr_neigh =3D kmall= oc(sizeof(*nr_neigh), GFP_ATOMIC)) =3D=3D NULL)=0A@@ -382,6 +427,7 @@=0A n= r_neigh->count =3D 0;=0A nr_neigh->number =3D nr_neigh_no++;=0A nr_n= eigh->failed =3D 0;=0A+ atomic_set(&nr_neigh->refcount, 1);=0A =0A if (a= x25_digi !=3D NULL && ax25_digi->ndigi > 0) {=0A if ((nr_neigh->digipeat = =3D kmalloc(sizeof(*ax25_digi), GFP_KERNEL)) =3D=3D NULL) {=0A@@ -391,10 +4= 37,10 @@=0A memcpy(nr_neigh->digipeat, ax25_digi, sizeof(*ax25_digi));=0A= }=0A =0A- spin_lock_bh(&nr_neigh_lock);=0A- nr_neigh->next =3D nr_neigh_l= ist;=0A- nr_neigh_list =3D nr_neigh;=0A- spin_unlock_bh(&nr_neigh_lock);= =0A+ spin_lock_bh(&nr_neigh_list_lock);=0A+ hlist_add_head(&nr_neigh->neigh= _node, &nr_neigh_list);=0A+ /* refcount is initialized at 1 */=0A+ spin_unl= ock_bh(&nr_neigh_list_lock);=0A =0A return 0;=0A }=0A@@ -407,9 +453,7 @@= =0A {=0A struct nr_neigh *nr_neigh;=0A =0A- for (nr_neigh =3D nr_neigh_lis= t; nr_neigh !=3D NULL; nr_neigh =3D nr_neigh->next)=0A- if (ax25cmp(callsi= gn, &nr_neigh->callsign) =3D=3D 0 && nr_neigh->dev =3D=3D dev)=0A- break;= =0A+ nr_neigh =3D nr_neigh_get_dev(callsign, dev);=0A =0A if (nr_neigh =3D= =3D NULL) return -EINVAL;=0A =0A@@ -418,6 +462,7 @@=0A =0A if (nr_neigh->c= ount =3D=3D 0)=0A nr_remove_neigh(nr_neigh);=0A+ nr_neigh_put(nr_neigh);= =0A =0A return 0;=0A }=0A@@ -430,15 +475,13 @@=0A static int nr_dec_obs(vo= id)=0A {=0A struct nr_neigh *nr_neigh;=0A- struct nr_node *s, *nr_node;= =0A+ struct nr_node *s;=0A+ struct hlist_node *node, *nodet;=0A int i;=0A= =0A- nr_node =3D nr_node_list;=0A-=0A- while (nr_node !=3D NULL) {=0A- s = =3D nr_node;=0A- nr_node =3D nr_node->next;=0A-=0A+ spin_lock_bh(&nr= _node_list_lock);=0A+ nr_node_for_each_safe(s, node, nodet, &nr_node_list) = {=0A+ nr_node_lock(s);=0A for (i =3D 0; i < s->count; i++) {=0A switc= h (s->routes[i].obs_count) {=0A case 0: /* A locked entry */=0A@@ -448,= 6 +491,7 @@=0A nr_neigh =3D s->routes[i].neighbour;=0A =0A nr_neigh= ->count--;=0A+ nr_neigh_put(nr_neigh);=0A =0A if (nr_neigh->count = =3D=3D 0 && !nr_neigh->locked)=0A nr_remove_neigh(nr_neigh);=0A@@ -472= ,8 +516,10 @@=0A }=0A =0A if (s->count <=3D 0)=0A- nr_remove_node(s);= =0A+ nr_remove_node_locked(s);=0A+ nr_node_unlock(s);=0A }=0A+ spin_unl= ock_bh(&nr_node_list_lock);=0A =0A return 0;=0A }=0A@@ -483,21 +529,17 @@= =0A */=0A void nr_rt_device_down(struct net_device *dev)=0A {=0A- struct n= r_neigh *s, *nr_neigh =3D nr_neigh_list;=0A- struct nr_node *t, *nr_node;= =0A+ struct nr_neigh *s;=0A+ struct hlist_node *node, *nodet, *node2, *node= 2t;=0A+ struct nr_node *t;=0A int i;=0A =0A- while (nr_neigh !=3D NULL) {= =0A- s =3D nr_neigh;=0A- nr_neigh =3D nr_neigh->next;=0A-=0A+ spin= _lock_bh(&nr_neigh_list_lock);=0A+ nr_neigh_for_each_safe(s, node, nodet, &= nr_neigh_list) {=0A if (s->dev =3D=3D dev) {=0A- nr_node =3D nr_node_li= st;=0A-=0A- while (nr_node !=3D NULL) {=0A- t =3D nr_node;=0A- = nr_node =3D nr_node->next;=0A-=0A+ spin_lock_bh(&nr_node_list_lock);=0A= + nr_node_for_each_safe(t, node2, node2t, &nr_node_list) {=0A+ nr_node= _lock(t);=0A for (i =3D 0; i < t->count; i++) {=0A if (t->routes[i= ].neighbour =3D=3D s) {=0A t->count--;=0A@@ -514,12 +556,15 @@=0A = }=0A =0A if (t->count <=3D 0)=0A- nr_remove_node(t);=0A+ nr_re= move_node_locked(t);=0A+ nr_node_unlock(t);=0A }=0A+ spin_unlock_bh= (&nr_node_list_lock);=0A =0A- nr_remove_neigh(s);=0A+ nr_remove_neigh_l= ocked(s);=0A }=0A }=0A+ spin_unlock_bh(&nr_neigh_list_lock);=0A }=0A =0A= /*=0A@@ -553,6 +598,8 @@=0A if (first =3D=3D NULL || strncmp(dev->name,= first->name, 3) < 0)=0A first =3D dev;=0A }=0A+ if (first)=0A+ dev_h= old(first);=0A read_unlock(&dev_base_lock);=0A =0A return first;=0A@@ -60= 3,6 +650,7 @@=0A {=0A struct nr_route_struct nr_route;=0A struct net_devi= ce *dev;=0A+ int ret;=0A =0A switch (cmd) {=0A case SIOCADDRT:=0A@@ -610,= 23 +658,29 @@=0A return -EFAULT;=0A if ((dev =3D nr_ax25_dev_get(nr_ro= ute.device)) =3D=3D NULL)=0A return -EINVAL;=0A- if (nr_route.ndigis < = 0 || nr_route.ndigis > AX25_MAX_DIGIS)=0A+ if (nr_route.ndigis < 0 || nr_r= oute.ndigis > AX25_MAX_DIGIS) {=0A+ dev_put(dev);=0A return -EINVAL;= =0A+ }=0A switch (nr_route.type) {=0A case NETROM_NODE:=0A- return n= r_add_node(&nr_route.callsign,=0A+ ret =3D nr_add_node(&nr_route.callsign= ,=0A nr_route.mnemonic,=0A &nr_route.neighbour,=0A nr_call_to_d= igi(nr_route.ndigis, nr_route.digipeaters),=0A dev, nr_route.quality,= =0A nr_route.obs_count);=0A+ break;=0A case NETROM_NEIGH:=0A- ret= urn nr_add_neigh(&nr_route.callsign,=0A+ ret =3D nr_add_neigh(&nr_route.c= allsign,=0A nr_call_to_digi(nr_route.ndigis, nr_route.digipeaters),=0A = dev, nr_route.quality);=0A+ break;=0A default:=0A- return -EINVAL= ;=0A+ ret =3D -EINVAL;=0A }=0A+ dev_put(dev);=0A+ return ret;=0A =0A = case SIOCDELRT:=0A if (copy_from_user(&nr_route, arg, sizeof(struct nr_r= oute_struct)))=0A@@ -635,14 +689,18 @@=0A return -EINVAL;=0A switch (n= r_route.type) {=0A case NETROM_NODE:=0A- return nr_del_node(&nr_route.c= allsign,=0A+ ret =3D nr_del_node(&nr_route.callsign,=0A &nr_route.nei= ghbour, dev);=0A+ break;=0A case NETROM_NEIGH:=0A- return nr_del_neig= h(&nr_route.callsign,=0A+ ret =3D nr_del_neigh(&nr_route.callsign,=0A = dev, nr_route.quality);=0A+ break;=0A default:=0A- return -EINVAL;= =0A+ ret =3D -EINVAL;=0A }=0A+ dev_put(dev);=0A+ return ret;=0A =0A = case SIOCNRDECOBS:=0A return nr_dec_obs();=0A@@ -660,22 +718,36 @@=0A */= =0A void nr_link_failed(ax25_cb *ax25, int reason)=0A {=0A- struct nr_neigh= *nr_neigh;=0A- struct nr_node *nr_node;=0A-=0A- for (nr_neigh =3D nr_neig= h_list; nr_neigh !=3D NULL; nr_neigh =3D nr_neigh->next)=0A- if (nr_neigh-= >ax25 =3D=3D ax25)=0A+ struct nr_neigh *s, *nr_neigh =3D NULL;=0A+ struct h= list_node *node;=0A+ struct nr_node *nr_node =3D NULL;=0A+=0A+ spin_lock_b= h(&nr_neigh_list_lock);=0A+ nr_neigh_for_each(s, node, &nr_neigh_list)=0A+ = if (s->ax25 =3D=3D ax25) {=0A+ nr_neigh_hold(s);=0A+ nr_neigh =3D s;= =0A break;=0A+ }=0A+ spin_unlock_bh(&nr_neigh_list_lock);=0A =0A if (n= r_neigh =3D=3D NULL) return;=0A =0A nr_neigh->ax25 =3D NULL;=0A+ ax25_cb_p= ut(ax25);=0A =0A- if (++nr_neigh->failed < sysctl_netrom_link_fails_count) = return;=0A-=0A- for (nr_node =3D nr_node_list; nr_node !=3D NULL; nr_node = =3D nr_node->next)=0A+ if (++nr_neigh->failed < sysctl_netrom_link_fails_co= unt) {=0A+ nr_neigh_put(nr_neigh);=0A+ return;=0A+ }=0A+ spin_lock_bh(&nr= _node_list_lock);=0A+ nr_node_for_each(nr_node, node, &nr_node_list)=0A+ n= r_node_lock(nr_node);=0A if (nr_node->which < nr_node->count && nr_node->= routes[nr_node->which].neighbour =3D=3D nr_neigh)=0A nr_node->which++;= =0A+ nr_node_unlock(nr_node);=0A+ spin_unlock_bh(&nr_node_list_lock);=0A+ = nr_neigh_put(nr_neigh);=0A }=0A =0A /*=0A@@ -689,6 +761,9 @@=0A struct nr_= node *nr_node;=0A struct net_device *dev;=0A unsigned char *dptr;=0A+ ax= 25_cb *ax25s;=0A+ int ret;=0A+ struct sk_buff *skbn;=0A =0A =0A nr_src = =3D (ax25_address *)(skb->data + 0);=0A@@ -700,50 +775,84 @@=0A =0A if ((d= ev =3D nr_dev_get(nr_dest)) !=3D NULL) { /* Its for me */=0A if (ax25 =3D= =3D NULL) /* Its from me */=0A- return nr_loopback_queue(skb);=0A+ re= t =3D nr_loopback_queue(skb);=0A else=0A- return nr_rx_frame(skb, dev);= =0A+ ret =3D nr_rx_frame(skb, dev);=0A+ dev_put(dev);=0A+ return ret;= =0A }=0A =0A if (!sysctl_netrom_routing_control && ax25 !=3D NULL)=0A r= eturn 0;=0A =0A /* Its Time-To-Live has expired */=0A- if (--skb->data[14]= =3D=3D 0)=0A+ if (skb->data[14] =3D=3D 1) {=0A return 0;=0A+ }=0A =0A- f= or (nr_node =3D nr_node_list; nr_node !=3D NULL; nr_node =3D nr_node->next)= =0A- if (ax25cmp(nr_dest, &nr_node->callsign) =3D=3D 0)=0A- break;=0A+ n= r_node =3D nr_node_get(nr_dest);=0A+ if (nr_node =3D=3D NULL)=0A+ return 0= ;=0A+ nr_node_lock(nr_node);=0A =0A- if (nr_node =3D=3D NULL || nr_node->wh= ich >=3D nr_node->count)=0A+ if (nr_node->which >=3D nr_node->count) {=0A+ = nr_node_unlock(nr_node);=0A+ nr_node_put(nr_node);=0A return 0;=0A+ }= =0A =0A nr_neigh =3D nr_node->routes[nr_node->which].neighbour;=0A =0A- if= ((dev =3D nr_dev_first()) =3D=3D NULL)=0A+ if ((dev =3D nr_dev_first()) = =3D=3D NULL) {=0A+ nr_node_unlock(nr_node);=0A+ nr_node_put(nr_node);=0A+= return 0;=0A+ }=0A+=0A+ /* We are going to change the netrom headers so w= e should get our=0A+ own skb, we also did not know until now how much he= ader space=0A+ we had to reserve... - RXQ */=0A+ if ((skbn=3Dskb_copy_ex= pand(skb, dev->hard_header_len, 0, GFP_ATOMIC)) =3D=3D NULL) {=0A+ nr_node= _unlock(nr_node);=0A+ nr_node_put(nr_node);=0A+ dev_put(dev);=0A return= 0;=0A+ }=0A+ kfree_skb(skb);=0A+ skb=3Dskbn;=0A+ skb->data[14]--;=0A =0A = dptr =3D skb_push(skb, 1);=0A *dptr =3D AX25_P_NETROM;=0A =0A- nr_neigh->= ax25 =3D ax25_send_frame(skb, 256, (ax25_address *)dev->dev_addr, &nr_neigh= ->callsign, nr_neigh->digipeat, nr_neigh->dev);=0A+ ax25s =3D ax25_send_fra= me(skb, 256, (ax25_address *)dev->dev_addr, &nr_neigh->callsign, nr_neigh->= digipeat, nr_neigh->dev);=0A+ if (nr_neigh->ax25 && ax25s) {=0A+ /* We wer= e already holding this ax25_cb */=0A+ ax25_cb_put(ax25s);=0A+ }=0A+ nr_nei= gh->ax25 =3D ax25s;=0A =0A- return (nr_neigh->ax25 !=3D NULL);=0A+ dev_put(= dev);=0A+ ret =3D (nr_neigh->ax25 !=3D NULL);=0A+ nr_node_unlock(nr_node);= =0A+ nr_node_put(nr_node);=0A+ return ret;=0A }=0A =0A int nr_nodes_get_inf= o(char *buffer, char **start, off_t offset, int length)=0A {=0A struct nr_= node *nr_node;=0A+ struct hlist_node *node;=0A int len =3D 0;=0A off_= t pos =3D 0;=0A off_t begin =3D 0;=0A int i;=0A =0A- spin_lock_bh(&nr_n= ode_lock);=0A+ spin_lock_bh(&nr_node_list_lock);=0A len +=3D sprintf(buffe= r, "callsign mnemonic w n qual obs neigh qual obs neigh qual obs neigh\n")= ;=0A =0A- for (nr_node =3D nr_node_list; nr_node !=3D NULL; nr_node =3D nr_= node->next) {=0A+ nr_node_for_each(nr_node, node, &nr_node_list) {=0A+ nr_= node_lock(nr_node);=0A len +=3D sprintf(buffer + len, "%-9s %-7s %d %d",= =0A ax2asc(&nr_node->callsign),=0A (nr_node->mnemonic[0] =3D=3D '\0')= ? "*" : nr_node->mnemonic,=0A@@ -756,6 +865,7 @@=0A nr_node->routes[i]= .obs_count,=0A nr_node->routes[i].neighbour->number);=0A }=0A+ nr_no= de_unlock(nr_node);=0A =0A len +=3D sprintf(buffer + len, "\n");=0A =0A@@= -769,7 +879,7 @@=0A if (pos > offset + length)=0A break;=0A }=0A- sp= in_unlock_bh(&nr_node_lock);=0A+ spin_unlock_bh(&nr_node_list_lock);=0A =0A= *start =3D buffer + (offset - begin);=0A len -=3D (offset - begin);=0A= @@ -782,15 +892,16 @@=0A int nr_neigh_get_info(char *buffer, char **start, = off_t offset, int length)=0A {=0A struct nr_neigh *nr_neigh;=0A+ struct hl= ist_node *node;=0A int len =3D 0;=0A off_t pos =3D 0;=0A off_t beg= in =3D 0;=0A int i;=0A =0A- spin_lock_bh(&nr_neigh_lock);=0A+ spin_lock_bh= (&nr_neigh_list_lock);=0A len +=3D sprintf(buffer, "addr callsign dev q= ual lock count failed digipeaters\n");=0A =0A- for (nr_neigh =3D nr_neigh_l= ist; nr_neigh !=3D NULL; nr_neigh =3D nr_neigh->next) {=0A+ nr_neigh_for_ea= ch(nr_neigh, node, &nr_neigh_list) {=0A len +=3D sprintf(buffer + len, "%= 05d %-9s %-4s %3d %d %3d %3d",=0A nr_neigh->number,=0A ax2as= c(&nr_neigh->callsign),=0A@@ -818,7 +929,7 @@=0A break;=0A }=0A =0A- sp= in_unlock_bh(&nr_neigh_lock);=0A+ spin_unlock_bh(&nr_neigh_list_lock);=0A = =0A *start =3D buffer + (offset - begin);=0A len -=3D (offset - begin);= =0A@@ -833,20 +944,24 @@=0A */=0A void __exit nr_rt_free(void)=0A {=0A- st= ruct nr_neigh *s, *nr_neigh =3D nr_neigh_list;=0A- struct nr_node *t, *nr_= node =3D nr_node_list;=0A-=0A- while (nr_node !=3D NULL) {=0A- t = =3D nr_node;=0A- nr_node =3D nr_node->next;=0A-=0A- nr_remove_node(t);=0A= - }=0A-=0A- while (nr_neigh !=3D NULL) {=0A- s =3D nr_neigh;=0A- n= r_neigh =3D nr_neigh->next;=0A-=0A- nr_remove_neigh(s);=0A+ struct nr_neig= h *s =3D NULL;=0A+ struct nr_node *t =3D NULL;=0A+ struct hlist_node *node= , *nodet;=0A+=0A+ spin_lock_bh(&nr_neigh_list_lock);=0A+ spin_lock_bh(&nr_n= ode_list_lock);=0A+ nr_node_for_each_safe(t, node, nodet, &nr_node_list) {= =0A+ nr_node_lock(t);=0A+ nr_remove_node_locked(t);=0A+ nr_node_unlock(t= );=0A+ }=0A+ nr_neigh_for_each_safe(s, node, nodet, &nr_neigh_list) {=0A+ = while(s->count) {=0A+ s->count--;=0A+ nr_neigh_put(s);=0A+ }=0A+ nr_r= emove_neigh_locked(s);=0A }=0A+ spin_unlock_bh(&nr_node_list_lock);=0A+ sp= in_unlock_bh(&nr_neigh_list_lock);=0A }=0Adiff -ru linux-2.6.0-test3/net/ne= trom/nr_subr.c linux-2.6.0-test1.rxq3/net/netrom/nr_subr.c=0A--- linux-2.6.= 0-test3/net/netrom/nr_subr.c 2003-08-09 06:42:56.000000000 +0200=0A+++ linu= x-2.6.0-test1.rxq3/net/netrom/nr_subr.c 2003-07-24 20:56:54.000000000 +0200= =0A@@ -127,7 +127,7 @@=0A unsigned char *dptr;=0A int len, timeout;=0A = =0A- len =3D AX25_BPQ_HEADER_LEN + AX25_MAX_HEADER_LEN + NR_NETWORK_LEN + N= R_TRANSPORT_LEN;=0A+ len =3D NR_NETWORK_LEN + NR_TRANSPORT_LEN;=0A =0A swi= tch (frametype & 0x0F) {=0A case NR_CONNREQ:=0A@@ -151,7 +151,7 @@=0A /*= =0A * Space for AX.25 and NET/ROM network header=0A */=0A- skb_reserve(= skb, AX25_BPQ_HEADER_LEN + AX25_MAX_HEADER_LEN + NR_NETWORK_LEN);=0A+ skb_r= eserve(skb, NR_NETWORK_LEN);=0A =0A dptr =3D skb_put(skb, skb_tailroom(skb= ));=0A =0A@@ -219,12 +219,12 @@=0A unsigned char *dptr;=0A int len;=0A = =0A- len =3D AX25_BPQ_HEADER_LEN + AX25_MAX_HEADER_LEN + NR_NETWORK_LEN + N= R_TRANSPORT_LEN + 1;=0A+ len =3D NR_NETWORK_LEN + NR_TRANSPORT_LEN + 1;=0A = =0A if ((skbn =3D alloc_skb(len, GFP_ATOMIC)) =3D=3D NULL)=0A return;=0A= =0A- skb_reserve(skbn, AX25_BPQ_HEADER_LEN + AX25_MAX_HEADER_LEN);=0A+ skb= _reserve(skbn, 0);=0A =0A dptr =3D skb_put(skbn, NR_NETWORK_LEN + NR_TRANS= PORT_LEN);=0A =0Adiff -ru linux-2.6.0-test3/net/netrom/nr_timer.c linux-2.6= .0-test1.rxq3/net/netrom/nr_timer.c=0A--- linux-2.6.0-test3/net/netrom/nr_t= imer.c 2003-08-09 06:38:56.000000000 +0200=0A+++ linux-2.6.0-test1.rxq3/net= /netrom/nr_timer.c 2003-07-24 20:56:55.000000000 +0200=0A@@ -143,7 +143,10 = @@=0A is accepted() it isn't 'dead' so doesn't get removed. */=0A if= (sock_flag(sk, SOCK_DESTROY) ||=0A (sk->sk_state =3D=3D TCP_LISTEN &= & sock_flag(sk, SOCK_DEAD))) {=0A+ sock_hold(sk);=0A nr_destroy_socket= (sk);=0A+ bh_unlock_sock(sk);=0A+ sock_put(sk);=0A return;=0A }=0A= break;=0A@@ -227,6 +230,7 @@=0A case NR_STATE_1:=0A if (nr->n2count = =3D=3D nr->n2) {=0A nr_disconnect(sk, ETIMEDOUT);=0A+ bh_unlock_sock(s= k);=0A return;=0A } else {=0A nr->n2count++;=0A@@ -237,6 +241,7 @@= =0A case NR_STATE_2:=0A if (nr->n2count =3D=3D nr->n2) {=0A nr_discon= nect(sk, ETIMEDOUT);=0A+ bh_unlock_sock(sk);=0A return;=0A } else {= =0A nr->n2count++;=0A@@ -247,6 +252,7 @@=0A case NR_STATE_3:=0A if (n= r->n2count =3D=3D nr->n2) {=0A nr_disconnect(sk, ETIMEDOUT);=0A+ bh_un= lock_sock(sk);=0A return;=0A } else {=0A nr->n2count++;=0Adiff -ru = linux-2.6.0-test3/net/netrom/sysctl_net_netrom.c linux-2.6.0-test1.rxq3/net= /netrom/sysctl_net_netrom.c=0A--- linux-2.6.0-test3/net/netrom/sysctl_net_n= etrom.c 2003-08-09 06:33:21.000000000 +0200=0A+++ linux-2.6.0-test1.rxq3/ne= t/netrom/sysctl_net_netrom.c 2003-07-24 20:56:54.000000000 +0200=0A@@ -15,9= +15,9 @@=0A /*=0A * Values taken from NET/ROM documentation.=0A */=0A-st= atic int min_quality[1], max_quality[] =3D {255};=0A-static int min_o= bs[1], max_obs[] =3D {255};=0A-static int min_ttl[1], = max_ttl[] =3D {255};=0A+static int min_quality[] =3D {0}, max_qualit= y[] =3D {255};=0A+static int min_obs[] =3D {0}, max_obs[] =3D {255}= ;=0A+static int min_ttl[] =3D {0}, max_ttl[] =3D {255};=0A static i= nt min_t1[] =3D {5 * HZ};=0A static int max_t1[] =3D {600 * HZ};= =0A static int min_n2[] =3D {2}, max_n2[] =3D {127};=0A@@ -28,7 += 28,7 @@=0A static int min_window[] =3D {1}, max_window[] =3D {127};=0A st= atic int min_idle[] =3D {0 * HZ};=0A static int max_idle[] =3D {65535= * HZ};=0A-static int min_route[1], max_route[] =3D {1};=0A+static= int min_route[] =3D {0}, max_route[] =3D {1};=0A static int min_fails[= ] =3D {1}, max_fails[] =3D {10};=0A =0A static struct ctl_table_header = *nr_table_header;=0A--- linux-2.6.0-test3/include/net/ax25.h 2003-08-09 06:= 38:16.000000000 +0200=0A+++ linux-2.6.0-test1.rxq3/include/net/ax25.h 2003-= 07-24 21:01:59.000000000 +0200=0A@@ -10,6 +10,7 @@=0A #include =0A #include =0A #include =0A+#include <= linux/list.h>=0A #include =0A =0A #define AX25_T1CLAMPLO 1= =0A@@ -180,7 +181,7 @@=0A } ax25_dev;=0A =0A typedef struct ax25_cb {=0A- s= truct ax25_cb *next;=0A+ struct hlist_node ax25_node;=0A ax25_address so= urce_addr, dest_addr;=0A ax25_digi *digipeat;=0A ax25_dev *ax25_dev;=0A= @@ -197,17 +198,32 @@=0A struct sk_buff_head ack_queue;=0A struct sk_buff= _head frag_queue;=0A unsigned char window;=0A- struct timer_list timer;= =0A+ struct timer_list timer, dtimer;=0A struct sock *sk; /* Backlink to= socket */=0A+ atomic_t refcount;=0A } ax25_cb;=0A =0A #define ax25_sk(__s= k) ((ax25_cb *)(__sk)->sk_protinfo)=0A =0A+#define ax25_for_each(__ax25, no= de, list) \=0A+ hlist_for_each_entry(__ax25, node, list, ax25_node)=0A+=0A+= #define ax25_cb_hold(__ax25) \=0A+ atomic_inc(&((__ax25)->refcount))=0A+=0A= +static __inline__ void ax25_cb_put(ax25_cb *ax25)=0A+{=0A+ if (atomic_dec_= and_test(&ax25->refcount)) {=0A+ if (ax25->digipeat)=0A+ kfree(ax25->dig= ipeat);=0A+ kfree(ax25);=0A+ }=0A+}=0A+=0A /* af_ax25.c */=0A-extern ax25_= cb *ax25_list;=0A+extern struct hlist_head ax25_list;=0A extern spinlock_t = ax25_list_lock;=0A-extern void ax25_free_cb(ax25_cb *);=0A-extern void ax25= _insert_socket(ax25_cb *);=0A+extern void ax25_cb_add(ax25_cb *);=0A struct= sock *ax25_find_listener(ax25_address *, int, struct net_device *, int);= =0A struct sock *ax25_get_socket(ax25_address *, ax25_address *, int);=0A e= xtern ax25_cb *ax25_find_cb(ax25_address *, ax25_address *, ax25_digi *, st= ruct net_device *);=0A--- linux-2.6.0-test3/include/net/netrom.h 2003-08-09= 06:37:18.000000000 +0200=0A+++ linux-2.6.0-test1.rxq3/include/net/netrom.h= 2003-07-24 21:01:59.000000000 +0200=0A@@ -7,6 +7,7 @@=0A #ifndef _NETROM_H= =0A #define _NETROM_H =0A #include =0A+#include =0A =0A #define NR_NETWORK_LEN 15=0A #define NR_TRANSPORT_LEN 5=0A@@ = -77,16 +78,17 @@=0A #define nr_sk(__sk) ((nr_cb *)(__sk)->sk_protinfo)=0A = =0A struct nr_neigh {=0A- struct nr_neigh *next;=0A- ax25_address callsi= gn;=0A- ax25_digi *digipeat;=0A- ax25_cb *ax25;=0A- struct net_devic= e *dev;=0A- unsigned char quality;=0A- unsigned char locked;=0A- unsi= gned short count;=0A- unsigned int number;=0A- unsigned char failed;=0A= + struct hlist_node neigh_node;=0A+ ax25_address callsign;=0A+ ax25_digi = *digipeat;=0A+ ax25_cb *ax25;=0A+ struct net_device *dev;=0A+ unsigned ch= ar quality;=0A+ unsigned char locked;=0A+ unsigned short count;=0A+ unsi= gned int number;=0A+ unsigned char failed;=0A+ atomic_t refcount;=0A };= =0A =0A struct nr_route {=0A@@ -96,14 +98,74 @@=0A };=0A =0A struct nr_node= {=0A- struct nr_node *next;=0A- ax25_address callsign;=0A- char mnemo= nic[7];=0A- unsigned char which;=0A- unsigned char count;=0A- struct nr= _route routes[3];=0A+ struct hlist_node node_node;=0A+ ax25_address callsi= gn;=0A+ char mnemonic[7];=0A+ unsigned char which;=0A+ unsigned char co= unt;=0A+ struct nr_route routes[3];=0A+ atomic_t refcount;=0A+ spinlock_t= node_lock;=0A };=0A =0A+/************************************************= *********************=0A+ * nr_node & nr_neigh lists, refcounting and locki= ng=0A+ ********************************************************************= */=0A+=0A+extern struct hlist_head nr_node_list;=0A+extern struct hlist_hea= d nr_neigh_list;=0A+=0A+#define nr_node_hold(__nr_node) \=0A+ atomic_inc(&(= (__nr_node)->refcount))=0A+=0A+static __inline__ void nr_node_put(struct nr= _node *nr_node)=0A+{=0A+ if (atomic_dec_and_test(&nr_node->refcount)) {=0A+= kfree(nr_node);=0A+ }=0A+}=0A+=0A+#define nr_neigh_hold(__nr_neigh) \=0A+= atomic_inc(&((__nr_neigh)->refcount))=0A+=0A+static __inline__ void nr_nei= gh_put(struct nr_neigh *nr_neigh)=0A+{=0A+ if (atomic_dec_and_test(&nr_neig= h->refcount)) {=0A+ if (nr_neigh->digipeat !=3D NULL)=0A+ kfree(nr_neigh= ->digipeat);=0A+ kfree(nr_neigh);=0A+ }=0A+}=0A+=0A+/* nr_node_lock and nr= _node_unlock also hold/put the node's refcounter.=0A+ */=0A+static __inline= __ void nr_node_lock(struct nr_node *nr_node)=0A+{=0A+ nr_node_hold(nr_node= );=0A+ spin_lock_bh(&nr_node->node_lock);=0A+}=0A+=0A+static __inline__ voi= d nr_node_unlock(struct nr_node *nr_node)=0A+{=0A+ spin_unlock_bh(&nr_node-= >node_lock);=0A+ nr_node_put(nr_node);=0A+}=0A+=0A+#define nr_neigh_for_eac= h(__nr_neigh, node, list) \=0A+ hlist_for_each_entry(__nr_neigh, node, list= , neigh_node)=0A+=0A+#define nr_neigh_for_each_safe(__nr_neigh, node, node2= , list) \=0A+ hlist_for_each_entry_safe(__nr_neigh, node, node2, list, neig= h_node)=0A+=0A+#define nr_node_for_each(__nr_node, node, list) \=0A+ hlist_= for_each_entry(__nr_node, node, list, node_node)=0A+=0A+#define nr_node_for= _each_safe(__nr_node, node, node2, list) \=0A+ hlist_for_each_entry_safe(__= nr_node, node, node2, list, node_node)=0A+=0A+=0A+/************************= *********************************************/=0A+=0A /* af_netrom.c */=0A = extern int sysctl_netrom_default_path_quality;=0A extern int sysctl_netro= m_obsolescence_count_initialiser;=0A --AWniW0JNca5xppdA-- From rusty@samba.org Tue Aug 12 11:22:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 11:22:27 -0700 (PDT) Received: from lists.samba.org (dp.samba.org [66.70.73.150]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CIM6Fl012101 for ; Tue, 12 Aug 2003 11:22:07 -0700 Received: by lists.samba.org (Postfix, from userid 590) id 43BB22C06E; Tue, 12 Aug 2003 17:28:55 +0000 (GMT) From: Rusty Russell To: Andrew Morton Cc: netdev@oss.sgi.com Cc: laforge@gnumonks.org, temnota@kmv.ru, mingo@redhat.com Subject: Re: Fw: [Bugme-new] [Bug 1054] New: loading iptables modules kill raid5 kernel thread In-reply-to: Your message of "Thu, 07 Aug 2003 08:50:43 MST." <20030807085043.3b794387.akpm@osdl.org> Date: Tue, 12 Aug 2003 07:26:47 +1000 Message-Id: <20030812172855.43BB22C06E@lists.samba.org> X-archive-position: 4780 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rusty@rustcorp.com.au Precedence: bulk X-list: netdev In message <20030807085043.3b794387.akpm@osdl.org> you write: > > This is weird. It looks like something on the netfilter module > initialisation path has called smp_call_function(garbage_address). But I > cannot see where anything like that could happen. Hmm, this is 2.4. Is this a regression against previous kernels? I can't see anything to suspect here: we certainly don't use smp_call_function in the netfilter code. I wonder if loading a different module causes the same problems. BTW xor.h declares non-inline functions which I find disturbing. Hmm, maybe that tricky asm xor stuff blatts something which the smp_call_function wants to use...? Rusty. > Begin forwarded message: > > Date: Thu, 7 Aug 2003 07:49:13 -0700 > From: bugme-daemon@osdl.org > To: bugme-new@lists.osdl.org > Subject: [Bugme-new] [Bug 1054] New: loading iptables modules kill raid5 kern el thread > > > http://bugme.osdl.org/show_bug.cgi?id=1054 > > Summary: loading iptables modules kill raid5 kernel thread > Kernel Version: 2.4.22-pre10 > Status: NEW > Severity: normal > Owner: laforge@gnumonks.org > Submitter: temnota@kmv.ru > > > Distribution: RedHat 7.1 > Hardware Environment: HP NetServer 5/LS > > $ cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 5 > model : 2 > model name : Pentium 75 - 200 > stepping : 5 > fdiv_bug : no > hlt_bug : no > f00f_bug : yes > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 1 > wp : yes > flags : fpu vme de pse msr mce cx8 apic > bogomips : 53.04 > > processor : 1 > vendor_id : GenuineIntel > cpu family : 5 > model : 2 > model name : Pentium 75 - 200 > stepping : 5 > fdiv_bug : no > hlt_bug : no > f00f_bug : yes > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 1 > wp : yes > flags : fpu vme de pse msr mce cx8 apic > bogomips : 53.24 > > $ lspci -v > 00:00.0 Host bridge: Intel Corporation 82452KX/GX [Orion] (rev 02) > Flags: bus master, medium devsel, latency 6 > > 00:0d.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev > 01) Flags: bus master, medium devsel, latency 66, IRQ 10 > Memory at ffe7f000 (32-bit, prefetchable) [size=4K] > I/O ports at ef80 [size=32] > Memory at ff600000 (32-bit, non-prefetchable) [size=1M] > Expansion ROM at [disabled] [size=1M] > > 00:0e.0 Non-VGA unclassified device: Intel Corporation 82375EB (rev 05) > Flags: bus master, medium devsel, latency 248 > > 00:0f.0 Class ff00: Intel Corporation: Unknown device 0008 > Subsystem: Unknown device ec08:ffe7 > Flags: fast devsel > Memory at ffe7ec00 (32-bit, prefetchable) [size=1K] > Memory at 12000000 (32-bit, prefetchable) [size=1K] > Memory at 12000400 (32-bit, prefetchable) [size=1K] > Memory at 12000800 (32-bit, prefetchable) [size=1K] > Memory at 12000c00 (32-bit, prefetchable) [size=1K] > Memory at 12001000 (32-bit, prefetchable) [size=1K] > Expansion ROM at fffff800 [disabled] [size=2K] > > 01:00.0 Host bridge: Intel Corporation 82452KX/GX [Orion] (rev 02) > Flags: bus master, medium devsel, latency 6 > > 01:0c.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08) > Subsystem: Intel Corporation EtherExpress PRO/100+ Management Adapter > Flags: bus master, medium devsel, latency 66, IRQ 9 > Memory at ffcfe000 (32-bit, non-prefetchable) [size=4K] > I/O ports at f8c0 [size=64] > Memory at ffb00000 (32-bit, non-prefetchable) [size=1M] > Expansion ROM at [disabled] [size=1M] > Capabilities: [dc] Power Management version 2 > > 01:0d.0 SCSI storage controller: Adaptec AHA-294x / AIC-7870 (rev 03) > Flags: bus master, medium devsel, latency 64, IRQ 11 > I/O ports at fc00 [disabled] [size=256] > Memory at ffcff000 (32-bit, non-prefetchable) [size=4K] > Expansion ROM at [disabled] [size=64K] > > 01:0e.0 SCSI storage controller: Adaptec AHA-294x / AIC-7870 (rev 03) > Flags: bus master, medium devsel, latency 64, IRQ 9 > I/O ports at f400 [disabled] [size=256] > Memory at ffcfd000 (32-bit, non-prefetchable) [size=4K] > Expansion ROM at [disabled] [size=64K] > > $ cat /proc/modules > > ipt_TOS 1008 0 > ipt_tos 448 0 (unused) > iptable_mangle 2144 1 > ipt_TCPMSS 2336 3 > ipt_tcpmss 800 0 (unused) > ipt_LOG 3568 20 > ipt_MARK 720 0 (unused) > ipt_REDIRECT 768 0 (unused) > iptable_nat 23264 1 [ipt_REDIRECT] > ipt_REJECT 3136 0 (unused) > ipt_mac 656 12 > ipt_mark 464 0 (unused) > ipt_multiport 640 0 (unused) > iptable_filter 1712 1 > ipt_state 576 8 > ipt_limit 1216 171 > ip_conntrack_ftp 4512 0 (unused) > ip_conntrack 29664 3 [ipt_REDIRECT iptable_nat ipt_state ip_conntrack_ftp] > ip_tables 15008 18 [ipt_TOS ipt_tos iptable_mangle ipt_TCPMSS ipt_tcpmss ipt_LOG ipt_MARK ipt_REDIRECT iptable_nat ipt_REJECT ipt_mac ipt_mark ipt_multiport iptable_filter ipt_state ipt_limit] > > Software Environment: > Software Raid5 + iptables modules > > Problem Description: > When raid recovery discs (after unclean shutdown), loading iptables modules > kill radi5 kernel thread > > Unable to handle kernel NULL pointer dereference at virtual address > 00000212 > c102c04d > *pde = 00000000 > Oops: 0002 > CPU: 1 > EIP: 0010:[] Not tainted > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010082 > eax: d0355bb3 ebx: 00000001 ecx: c102c01c edx: 00000212 > esi: 00000019 edi: d1af3000 ebp: d1af4000 esp: d1d95dec > ds: 0018 es: 0018 ss: 0018 > Process raid5d (pid: 13, stackpage=d1d95000) > Stack: c0113b18 00000212 d1af3cc0 c010ca6a d1af3cc0 d1af5cc0 d1af4cc0 00000019 > d1af3000 d1af4000 0080e85d 00000018 00000018 fffffffb c01fb83a 00000010 > 00000282 00000003 d1af6c00 c01fbef7 00001000 d1af4000 d1af3000 d1af5000 > Call Trace: [] [] [] [] [] > [] [] [] [] [] [] > [] [] > Code: c0 02 c1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > >>EIP; c102c04d <_end+cae92d/124d9940> <===== > Trace; c0113b18 > Trace; c010ca6a > Trace; c01fb83a > Trace; c01fbef7 > Trace; c01f734e > Trace; c01b1261 > Trace; c01f82e6 > Trace; c01bb224 > Trace; c01f8ae1 > Trace; c01f8a10 > Trace; c0200515 > Trace; c0105883 > Trace; c0200370 > Code; c102c04d <_end+cae92d/124d9940> > 00000000 <_EIP>: > Code; c102c04d <_end+cae92d/124d9940> > 0: c0 02 c1 rolb $0xc1,(%edx) > > Unable to handle kernel NULL pointer dereference at virtual address 00000217 > c102c04d > *pde = 00000000 > Oops: 0002 > CPU: 0 > EIP: 0010:[] Not tainted > EFLAGS: 00010082 > eax: cb189bb3 ebx: 00000001 ecx: c102c01c edx: 00000217 > esi: 00000021 edi: d1c51000 ebp: d1c52000 esp: d1d95dec > ds: 0018 es: 0018 ss: 0018 > Process raid5d (pid: 13, stackpage=d1d95000) > Stack: c0113b18 00000217 d1c51bc0 c010ca6a d1c51bc0 d1c53be0 d1c52bc0 00000021 > d1c51000 d1c52000 807944a9 00000018 00000018 fffffffb c01fb85b 00000010 > 00000286 00000003 d1c54c00 c01fbef7 00001000 d1c52000 d1c51000 d1c53000 > Call Trace: [] [] [] [] [] > [] [] [] [] [] [] > [] [] > Code: c0 02 c1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > >>EIP; c102c04d <_end+cae92d/124d9940> <===== > Trace; c0113b18 > Trace; c010ca6a > Trace; c01fb85b > Trace; c01fbef7 > Trace; c01f734e > Trace; c01b1261 > Trace; c01f82e6 > Trace; c01bb224 > Trace; c01f8ae1 > Trace; c01f8a10 > Trace; c0200515 > Trace; c0105883 > Trace; c0200370 > Code; c102c04d <_end+cae92d/124d9940> > 00000000 <_EIP>: > Code; c102c04d <_end+cae92d/124d9940> > 0: c0 02 c1 rolb $0xc1,(%edx) > > Steps to reproduce: > > raidsetfaulty /dev/md0 /dev/sde1 > raidhotremove /dev/md0 /dev/sde1 > raidhotadd /dev/md0 /dev/sde1 > > and load iptables modules. OOPS > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. From temnota@kenga.kmv.ru Tue Aug 12 12:08:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 12:08:34 -0700 (PDT) Received: from kenga.kmv.ru (kenga.kmv.ru [217.13.212.5]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CJ8LFl012763 for ; Tue, 12 Aug 2003 12:08:24 -0700 Received: from kenga.kmv.ru (localhost [127.0.0.1]) by kenga.kmv.ru (8.12.9/8.12.7) with ESMTP id h7CJ83eL027520 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 12 Aug 2003 23:08:03 +0400 Received: (from temnota@localhost) by kenga.kmv.ru (8.12.9/8.12.6/Submit) id h7CJ7Aoj027450; Tue, 12 Aug 2003 23:07:10 +0400 Date: Tue, 12 Aug 2003 23:07:10 +0400 From: "Andrey J. Melnikoff (TEMHOTA)" To: Rusty Russell Cc: Andrew Morton , netdev@oss.sgi.com, laforge@gnumonks.org, mingo@redhat.com Subject: Re: Fw: [Bugme-new] [Bug 1054] New: loading iptables modules kill raid5 kernel thread Message-ID: <20030812190710.GQ14564@kmv.ru> References: <20030807085043.3b794387.akpm@osdl.org> <20030812172855.43BB22C06E@lists.samba.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030812172855.43BB22C06E@lists.samba.org> User-Agent: Mutt/1.4i X-AV-Scanned: Avp! X-Spam-Score: 10 total X-Data-Status: msg.XXFFIYkK@kenga.kmv.ru X-archive-position: 4781 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: temnota@kmv.ru Precedence: bulk X-list: netdev Hi Rusty Russell! On Tue, Aug 12, 2003 at 07:26:47AM +1000, Rusty Russell wrote next: > In message <20030807085043.3b794387.akpm@osdl.org> you write: > > > > This is weird. It looks like something on the netfilter module > > initialisation path has called smp_call_function(garbage_address). But I > > cannot see where anything like that could happen. > > Hmm, this is 2.4. Is this a regression against previous kernels? > > I can't see anything to suspect here: we certainly don't use > smp_call_function in the netfilter code. I wonder if loading a > different module causes the same problems. No, only iptables loaded as modules, all other in kernel. > BTW xor.h declares non-inline functions which I find disturbing. Hmm, > maybe that tricky asm xor stuff blatts something which the > smp_call_function wants to use...? Maybe. I see to many calls to flush_tlb_all_ipi when iptables start. See log (i'm add to smp_call_function_interrupt simple printk to see what function it call) # /etc/rc.d/rc.ipables start Arno's IPTABLES (ADSL) Firewall / NAT script v1.7.1BETA-1 --------------------------------------------------------------- Checking for root privileges...OK External (internet) interface (EXT_IF) : eth+ IPTABLES module / kernel check... Detected IPTABLES module... Loading additional IPTABLES modules: ip_tables: (C) 2000-2002 Netfilter core team SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 All IPTABLES modules loaded! --------------------------------------------------------------- Flushing rules in the filter table iptables -F SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 iptables -X SCFI call fn=c0113b20 in=00000000 wa=1 iptables -Z SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 iptables -F INPUT SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 iptables -F OUTPUT SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 iptables -F FORWARD SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 iptables -X CHECK SCFI call fn=c0113b20 in=00000000 wa=1 iptables -X VALID_CHECK SCFI call fn=c0113b20 in=00000000 wa=1 iptables -t mangle -F SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 iptables -t mangle -X SCFI call fn=c0113b20 in=00000000 wa=1 iptables -t mangle -Z SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 Setting default secure policies iptables -P INPUT DROP SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 iptables -P FORWARD DROP SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 iptables -P OUTPUT ACCEPT SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 iptables -t mangle -P OUTPUT ACCEPT SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 iptables -t mangle -P PREROUTING ACCEPT SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 iptables -N CHECK SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 iptables -N VALID_CHECK SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 iptables -N acct_in SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 iptables -N acct_out SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 iptables -N acct_forw SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 iptables -A INPUT -j acct_in SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 iptables -A OUTPUT -j acct_out SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 iptables -A FORWARD -j acct_forw SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 iptables -A FORWARD -i eth1 -j ACCEPT SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 iptables -A FORWARD -o eth1 -j ACCEPT SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 iptables -A INPUT -i eth1 -p udp --dport 67 -j ACCEPT SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 iptables -A INPUT -i eth1 -p udp --dport 53 -j ACCEPT SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 SCFI call fn=c0113b20 in=00000000 wa=1 Unable to handle kernel NULL pointer dereference at virtual address 000000aa c102c024 *pde = 00000000 Oops: 0002 CPU: 1 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010086 eax: 000000aa ebx: c02b2080 ecx: 00000000 edx: d141a000 esi: c102c01c edi: 00003c8a ebp: d1d93ddc esp: d1d93db8 ds: 0018 es: 0018 ss: 0018 Process raid5d (pid: 13, stackpage=d1d93000) Stack: c0113df7 c02b2080 c0270160 c0113b20 00000000 00000001 d1b0f500 00000057 d1b0f000 d1d93e20 c010ccea d1b0f500 d1b10500 d1b0e500 00000057 d1b0f000 d1d93e20 32203931 00000018 00000018 fffffffb c01fedc9 00000010 00000202 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40 00 01 >>EIP; c102c024 <===== >>ebx; c02b2080 Trace; c0113df7 Trace; c0113b20 Trace; c010ccea Trace; c01fedc9 Trace; c01ff462 Trace; c01fa55e Trace; c01fb731 Trace; c01fbf9f Trace; c01fbec0 Trace; c0203bcc Trace; c0105883 Trace; c0203a30 Trace; c0203a30 Code; c102c024 <===== 00000000 <_EIP>: <===== Code; c102c034 10: 00 40 00 add %al,0x0(%eax) Code; c102c037 13: 01 00 add %eax,(%eax) but system still alive, iptables process get stuck in "Running" state .... Call Trace: [] [] bash S 00000007 5100 644 643 681 (NOTLB) Call Trace: [] [] rc.iptables S BFFFB200 240 681 644 761 (NOTLB) Call Trace: [] [] iptables1 S BFFFF680 4284 761 681 762 (NOTLB) Call Trace: [] [] iptables R 00000041 0 762 761 (NOTLB) Call Trace: [ sys_socketcall+150] [ system_call+33] ... Strange..... Stack frame - with invalid order... -- Best regards, TEMHOTA-RIPN aka MJA13-RIPE System Administrator. mailto:temnota@kmv.ru From shemminger@osdl.org Tue Aug 12 12:48:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 12:48:41 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CJmZFl013367 for ; Tue, 12 Aug 2003 12:48:36 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7CJmSo25197; Tue, 12 Aug 2003 12:48:28 -0700 Date: Tue, 12 Aug 2003 12:48:20 -0700 From: Stephen Hemminger To: Jeroen Vreeken Cc: linux-hams@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] ax25 & netrom fixes for 2.6 Message-Id: <20030812124820.2ab57161.shemminger@osdl.org> In-Reply-To: <20030812194653.A28977@jeroen.pe1rxq.ampr.org> References: <20030812194653.A28977@jeroen.pe1rxq.ampr.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4782 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev You lost a critical fix to ax25; it oop's if I bring up any device then do "ifconfig -a" due to use after free. PLEASE do some debugging with some of the kernel debugging options enabled! Uninitialised timer! This is just a warning. Your computer is OK function=0x6b6b6b6b, data=0x6b6b6b6b Call Trace: [] check_timer_failed+0x73/0x75 [] del_timer+0x1d/0xe8 [] ax25_cb_del+0x96/0xdc [ax25] [] default_wake_function+0x0/0x2e [] ax25_destroy_socket+0x1f/0x335 [ax25] [] default_wake_function+0x0/0x2e [] ax25_release+0xc1/0x2c0 [ax25] [] sock_fasync+0x190/0x363 [] sock_release+0x79/0xb4 [] sock_close+0x36/0x4d [] __fput+0x103/0x115 [] filp_close+0x4b/0x74 [] sys_close+0x86/0xf8 [] sysenter_past_esp+0x52/0x71 Debug: sleeping function called from invalid context at include/linux/rwsem.h:43Call Trace: [] __might_sleep+0x5c/0x60 [] do_page_fault+0x78/0x4ab [] __wake_up_common+0x38/0x57 [] release_console_sem+0xfc/0x133 [] printk+0x1b6/0x25a [] do_page_fault+0x0/0x4ab [] error_code+0x2d/0x38 [] del_timer+0x2d/0xe8 [] ax25_cb_del+0x96/0xdc [ax25] [] default_wake_function+0x0/0x2e [] ax25_destroy_socket+0x1f/0x335 [ax25] [] default_wake_function+0x0/0x2e [] ax25_release+0xc1/0x2c0 [ax25] [] sock_fasync+0x190/0x363 [] sock_release+0x79/0xb4 [] sock_close+0x36/0x4d [] __fput+0x103/0x115 [] filp_close+0x4b/0x74 [] sys_close+0x86/0xf8 [] sysenter_past_esp+0x52/0x71 Unable to handle kernel paging request at virtual address 6b6b6b6f printing eip: c012b2a7 *pde = 00000000 Oops: 0000 [#1] CPU: 0 EIP: 0060:[] Not tainted EFLAGS: 00010002 EIP is at del_timer+0x2d/0xe8 eax: 00000000 ebx: 6b6b6b6b ecx: 00000001 edx: dead4ead esi: 00000202 edi: f723364c ebp: f4267ed0 esp: f4267eb4 ds: 007b es: 007b ss: 0068 Process ifconfig (pid: 1760, threadinfo=f4266000 task=f561a080) Stack: f723364c fa4f70d0 f723351c c011da1d f736fc84 f723351c f736fca4 f4267f00 fa4f7c21 f723364c f561a080 c011da1d 00100100 00000246 00000246 00000246 f736fc84 f723351c f736fca4 f4267f30 fa4f9346 f723351c 000003a7 f736fcb0 Call Trace: [] ax25_cb_del+0x96/0xdc [ax25] [] default_wake_function+0x0/0x2e [] ax25_destroy_socket+0x1f/0x335 [ax25] [] default_wake_function+0x0/0x2e [] ax25_release+0xc1/0x2c0 [ax25] [] sock_fasync+0x190/0x363 [] sock_release+0x79/0xb4 [] sock_close+0x36/0x4d [] __fput+0x103/0x115 [] filp_close+0x4b/0x74 [] sys_close+0x86/0xf8 [] sysenter_past_esp+0x52/0x71 Code: 81 7b 04 ad 4e ad de 0f 85 8d 00 00 00 f0 fe 0b 0f 88 3e 0d <3>Slab corruption: start=f723351c, expend=f723371b, problemat=f7233658 Last user: [](ax25_cb_del+0x96/0xdc [ax25]) Data: ************************************************************************* Next: 71 F0 2C .D0 70 4F FA 71 F0 2C .******************** slab error in check_poison_obj(): cache `size-512': object was modified after fgCall Trace: [] check_poison_obj+0x16c/0x1ac [] __kmalloc+0x172/0x1d1 [] alloc_skb+0x48/0xe1 [] alloc_skb+0x48/0xe1 [] sock_alloc_send_pskb+0xce/0x1f6 [] sock_alloc_send_skb+0x2e/0x32 [] unix_stream_sendmsg+0x194/0x46d [] sock_aio_write+0xbd/0xd9 [] do_sync_write+0x89/0xb4 [] schedule_timeout+0x72/0xbb [] sock_poll+0x29/0x30 [] sys_poll+0x228/0x27c [] vfs_write+0xe9/0x119 [] sys_write+0x3f/0x5d [] sysenter_past_esp+0x52/0x71 From shemminger@osdl.org Tue Aug 12 13:57:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 13:57:38 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CKvYFl014204 for ; Tue, 12 Aug 2003 13:57:35 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7CKv3o08302; Tue, 12 Aug 2003 13:57:03 -0700 Date: Tue, 12 Aug 2003 13:56:55 -0700 From: Stephen Hemminger To: Jeroen Vreeken Cc: linux-hams@vger.kernel.org, ralf@linux-mips.org, davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] ax25 & netrom fixes for 2.6 Message-Id: <20030812135655.7334887b.shemminger@osdl.org> In-Reply-To: <20030812194653.A28977@jeroen.pe1rxq.ampr.org> References: <20030812194653.A28977@jeroen.pe1rxq.ampr.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4783 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev It looks like af_x25 is advertising itself as a new style protocol, yet if I walk the receive path: ax25_kiss_rcv -> ax25_rcv -> ax25_addr_parse there is no place that checks that the address portion of the buffer isn't fragmented into a non_linear skb. From pe1rxq@amsat.org Tue Aug 12 13:57:52 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 13:57:57 -0700 (PDT) Received: from amsfep16-int.chello.nl (amsfep16-int.chello.nl [213.46.243.26]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CKvoFl014231 for ; Tue, 12 Aug 2003 13:57:51 -0700 Received: from mail.chello.nl ([212.83.83.7]) by amsfep16-int.chello.nl (InterMail vM.5.01.05.17 201-253-122-126-117-20021021) with SMTP id <20030812205744.NNKO10454.amsfep16-int.chello.nl@mail.chello.nl>; Tue, 12 Aug 2003 22:57:44 +0200 Date: Tue, 12 Aug 2003 22:59:12 +0200 From: Jeroen Vreeken To: Stephen Hemminger Cc: linux-hams@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] ax25 & netrom fixes for 2.6 Message-ID: <20030812225912.C28977@jeroen.pe1rxq.ampr.org> References: <20030812194653.A28977@jeroen.pe1rxq.ampr.org> <20030812124820.2ab57161.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <20030812124820.2ab57161.shemminger@osdl.org>; from shemminger@osdl.org on Tue, Aug 12, 2003 at 21:48:20 +0200 X-Mailer: Balsa 1.1.0 Lines: 14 X-archive-position: 4784 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pe1rxq@amsat.org Precedence: bulk X-list: netdev On 2003.08.12 21:48:20 +0200 Stephen Hemminger wrote: > You lost a critical fix to ax25; it oop's if I bring up any device > then do "ifconfig -a" due to use after free. > > PLEASE do some debugging with some of the kernel debugging options > enabled! Which fix exactly did I miss? the only thing I see in your patch is the change to use sock_put in ax25_destroy_sock() and that was in my original patch... btw, I do have debugging enabled... Jeroen From pe1rxq@amsat.org Tue Aug 12 14:08:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 14:08:36 -0700 (PDT) Received: from amsfep15-int.chello.nl (amsfep15-int.chello.nl [213.46.243.28]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CL8TFl015249 for ; Tue, 12 Aug 2003 14:08:30 -0700 Received: from mail.chello.nl ([212.83.83.7]) by amsfep15-int.chello.nl (InterMail vM.5.01.05.17 201-253-122-126-117-20021021) with SMTP id <20030812210823.BYXD23618.amsfep15-int.chello.nl@mail.chello.nl>; Tue, 12 Aug 2003 23:08:23 +0200 Date: Tue, 12 Aug 2003 23:09:51 +0200 From: Jeroen Vreeken To: Stephen Hemminger Cc: Jeroen Vreeken , linux-hams@vger.kernel.org, ralf@linux-mips.org, davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] ax25 & netrom fixes for 2.6 Message-ID: <20030812230951.E28977@jeroen.pe1rxq.ampr.org> References: <20030812194653.A28977@jeroen.pe1rxq.ampr.org> <20030812135655.7334887b.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <20030812135655.7334887b.shemminger@osdl.org>; from shemminger@osdl.org on Tue, Aug 12, 2003 at 22:56:55 +0200 X-Mailer: Balsa 1.1.0 Lines: 18 X-archive-position: 4785 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pe1rxq@amsat.org Precedence: bulk X-list: netdev On 2003.08.12 22:56:55 +0200 Stephen Hemminger wrote: > It looks like af_x25 is advertising itself as a new style protocol, yet > if > I walk the receive path: > ax25_kiss_rcv -> ax25_rcv -> ax25_addr_parse > there is no place that checks that the address portion of the buffer > isn't fragmented > into a non_linear skb. Since at the moment the only zero-copy path I can imagine is from packets over a bpq ethernet device wouldn't it be the easiest to just check at ax25_rcv() for non-linear packets and call skb_linearize() for them? That way we would be safe untill we can make sure that the whole of the ax25 stack is non-linear safe? Should I make a new patch with this included? (and possibly the ifconfig problem you mentioned?) Jeroen From hadi@cyberus.ca Tue Aug 12 15:30:56 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 15:31:07 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CMUtFl016159 for ; Tue, 12 Aug 2003 15:30:56 -0700 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.12) id 19mOz3-000Jp5-00; Mon, 11 Aug 2003 22:34:02 -0400 Subject: Re: [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master's settings toslaves From: jamal Reply-To: hadi@cyberus.ca To: Jay Vosburgh Cc: Jeff Garzik , shmulik.hen@intel.com, Laurent DENIEL , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: <200308112141.h7BLftpS015012@death.ibm.com> References: <200308112141.h7BLftpS015012@death.ibm.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1060655610.1029.53.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Aug 2003 22:33:31 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4786 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Mon, 2003-08-11 at 17:41, Jay Vosburgh wrote: > Anyway, for most of the core bonding failover logic, I don't > see how a user space daemon implementation can perform equivalently to > a kernel-only implementation. I could be wrong (I haven't done any > testing) but for the core "eth0 is dead, enable eth1" type stuff, it > seems to me that in-kernel beats "user space yakking with kernel" for > reliability and speed, particularly on heavily loaded systems. for "Eth0 dead migrate activity to eth1" thing - i claim thats basic. Leave it in the kernel. > Now, that said, I can see a use for a user space monitoring / > control program, for the "strategic" problems (as opposed to the > "tactical" problems, like the previous paragraph). If we want to, > e.g., monitor bandwidth usage and add or remove links from the > aggregation, that is (a) not as time critical, and (b) somewhat > fuzzier in definition. Such a user space program could also interface > with various system management or HA thingies and report status for > its activities as well as the activities that bonding performs > independent of it. Now thats an interesting app. Bandwidth on demand. Probabaly also bring down the number of links when they are not being used. Imagine if you had to push this to the kernel. > One thought I've had (which dovetails somewhat with an earlier > comment from Laurent) is a tcpdump/bpf-style "policy engine" blob in > the kernel, which is programmed from user space with enough brains to > handle the "tactical" level problems (the "strategic" problems might > be more than such a blob could handle, and if its easy enough to yak > with user space for those problems, it may not be necessary). I > haven't done much more than think about this, though; it may very well > be overkill for the basic stuff. It exists. It's called netlink. cheers, jamal From shemminger@osdl.org Tue Aug 12 15:33:38 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 15:33:42 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CMXbFl016439 for ; Tue, 12 Aug 2003 15:33:38 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7CMXKo31131; Tue, 12 Aug 2003 15:33:20 -0700 Date: Tue, 12 Aug 2003 15:33:12 -0700 From: Stephen Hemminger To: Stephen Hemminger Cc: "David S. Miller" , Joerg Reuter , linux-hams@vger.kernel.org, netdev@oss.sgi.com Subject: [PATCH] bpqether add rcu_read_lock Message-Id: <20030812153312.0e762cf3.shemminger@osdl.org> In-Reply-To: <20030811162205.78b2029f.shemminger@osdl.org> References: <20030811162205.78b2029f.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4787 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Fix one comment and add rcu_read_lock/rcu_read_unlock in the net_device_notifier. Preemption is almost certainly already disabled there, but be safe. diff -Nru a/drivers/net/hamradio/bpqether.c b/drivers/net/hamradio/bpqether.c --- a/drivers/net/hamradio/bpqether.c Tue Aug 12 11:37:28 2003 +++ b/drivers/net/hamradio/bpqether.c Tue Aug 12 11:37:28 2003 @@ -141,7 +141,6 @@ /* * Get the BPQ device for the ethernet device - * need to hold bqp_lock at least for read */ static inline struct net_device *bpq_get_ax25_dev(struct net_device *dev) { @@ -564,6 +563,8 @@ if (!dev_is_ethdev(dev)) return NOTIFY_DONE; + rcu_read_lock(); + switch (event) { case NETDEV_UP: /* new ethernet device -> new BPQ interface */ if (bpq_get_ax25_dev(dev) == NULL) @@ -582,6 +583,7 @@ default: break; } + rcu_read_unlock(); return NOTIFY_DONE; } From shemminger@osdl.org Tue Aug 12 15:39:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 15:39:30 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CMdQFl016889 for ; Tue, 12 Aug 2003 15:39:27 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7CMd9o32412; Tue, 12 Aug 2003 15:39:09 -0700 Date: Tue, 12 Aug 2003 15:39:01 -0700 From: Stephen Hemminger To: Jeroen Vreeken Cc: linux-hams@vger.kernel.org, ralf@linux-mips.org, davem@redhat.com, netdev@oss.sgi.com Subject: [PATCH] ax25 fix for premature free. Message-Id: <20030812153901.6e700dcb.shemminger@osdl.org> In-Reply-To: <20030812230951.E28977@jeroen.pe1rxq.ampr.org> References: <20030812194653.A28977@jeroen.pe1rxq.ampr.org> <20030812135655.7334887b.shemminger@osdl.org> <20030812230951.E28977@jeroen.pe1rxq.ampr.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4788 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev The problem is that you are freeing the ax25 control block too soon for the case of sockets that were never bound. If the socket is not bound, it never makes it into the node list and the refcount is 1. So when you decrement in ax25_cb_del by calling ax25_cb_put it gets freed. This fixes the problem, it assumes your earlier patch has been applied. diff -Nru a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c --- a/net/ax25/af_ax25.c Tue Aug 12 15:35:33 2003 +++ b/net/ax25/af_ax25.c Tue Aug 12 15:35:33 2003 @@ -66,10 +66,12 @@ */ static void ax25_cb_del(ax25_cb *ax25) { - spin_lock_bh(&ax25_list_lock); - hlist_del_init(&ax25->ax25_node); - spin_unlock_bh(&ax25_list_lock); - ax25_cb_put(ax25); + if (!hlist_unhashed(&ax25->ax25_node)) { + spin_lock_bh(&ax25_list_lock); + hlist_del(&ax25->ax25_node); + spin_unlock_bh(&ax25_list_lock); + ax25_cb_put(ax25); + } } /* From pe1rxq@amsat.org Tue Aug 12 16:01:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 16:01:52 -0700 (PDT) Received: from amsfep14-int.chello.nl (amsfep14-int.chello.nl [213.46.243.22]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CN1lFl017827 for ; Tue, 12 Aug 2003 16:01:48 -0700 Received: from mail.chello.nl ([212.83.83.7]) by amsfep14-int.chello.nl (InterMail vM.5.01.05.17 201-253-122-126-117-20021021) with SMTP id <20030812230132.HSWF15718.amsfep14-int.chello.nl@mail.chello.nl>; Wed, 13 Aug 2003 01:01:32 +0200 Date: Wed, 13 Aug 2003 01:03:01 +0200 From: Jeroen Vreeken To: Stephen Hemminger Cc: linux-hams@vger.kernel.org, ralf@linux-mips.org, davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] ax25 fix for premature free. Message-ID: <20030813010301.K28977@jeroen.pe1rxq.ampr.org> References: <20030812194653.A28977@jeroen.pe1rxq.ampr.org> <20030812135655.7334887b.shemminger@osdl.org> <20030812230951.E28977@jeroen.pe1rxq.ampr.org> <20030812153901.6e700dcb.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="+fexcqMh/evT6CrY" Content-Transfer-Encoding: 8bit In-Reply-To: <20030812153901.6e700dcb.shemminger@osdl.org>; from shemminger@osdl.org on Wed, Aug 13, 2003 at 00:39:01 +0200 X-Mailer: Balsa 1.1.0 Lines: 1159 X-archive-position: 4789 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pe1rxq@amsat.org Precedence: bulk X-list: netdev --+fexcqMh/evT6CrY Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit This is the same patch as earlier today with the bug Stephen mentioned in ax25_cb_del patched. It is made against 2.6.0-test3 Jeroen --+fexcqMh/evT6CrY Content-Type: application/octet-stream; charset=ISO-8859-1 Content-Disposition: attachment; filename="linux-2.6.0-test3.rxq4.diff" Content-Transfer-Encoding: quoted-printable Only in linux-2.6.0-test3.rxq/net/ax25: .af_ax25.o.cmd=0AOnly in linux-2.6.= 0-test3.rxq/net/ax25: .ax25.ko.cmd=0AOnly in linux-2.6.0-test3.rxq/net/ax25= : .ax25.mod.o.cmd=0AOnly in linux-2.6.0-test3.rxq/net/ax25: .ax25.o.cmd=0AO= nly in linux-2.6.0-test3.rxq/net/ax25: .ax25_addr.o.cmd=0AOnly in linux-2.6= .0-test3.rxq/net/ax25: .ax25_dev.o.cmd=0AOnly in linux-2.6.0-test3.rxq/net/= ax25: .ax25_iface.o.cmd=0AOnly in linux-2.6.0-test3.rxq/net/ax25: .ax25_in.= o.cmd=0AOnly in linux-2.6.0-test3.rxq/net/ax25: .ax25_ip.o.cmd=0AOnly in li= nux-2.6.0-test3.rxq/net/ax25: .ax25_out.o.cmd=0AOnly in linux-2.6.0-test3.r= xq/net/ax25: .ax25_route.o.cmd=0AOnly in linux-2.6.0-test3.rxq/net/ax25: .a= x25_std_in.o.cmd=0AOnly in linux-2.6.0-test3.rxq/net/ax25: .ax25_std_subr.o= .cmd=0AOnly in linux-2.6.0-test3.rxq/net/ax25: .ax25_std_timer.o.cmd=0AOnly= in linux-2.6.0-test3.rxq/net/ax25: .ax25_subr.o.cmd=0AOnly in linux-2.6.0-= test3.rxq/net/ax25: .ax25_timer.o.cmd=0AOnly in linux-2.6.0-test3.rxq/net/a= x25: .ax25_uid.o.cmd=0AOnly in linux-2.6.0-test3.rxq/net/ax25: .built-in.o.= cmd=0AOnly in linux-2.6.0-test3.rxq/net/ax25: .sysctl_net_ax25.o.cmd=0Adiff= -ru linux-2.6.0-test3/net/ax25/af_ax25.c linux-2.6.0-test3.rxq/net/ax25/af= _ax25.c=0A--- linux-2.6.0-test3/net/ax25/af_ax25.c 2003-08-09 06:41:26.0000= 00000 +0200=0A+++ linux-2.6.0-test3.rxq/net/ax25/af_ax25.c 2003-08-13 00:29= :48.000000000 +0200=0A@@ -51,54 +51,27 @@=0A =0A =0A =0A-ax25_cb *ax25_list= ;=0A+HLIST_HEAD(ax25_list);=0A spinlock_t ax25_list_lock =3D SPIN_LOCK_UNLO= CKED;=0A =0A static struct proto_ops ax25_proto_ops;=0A =0A-/*=0A- * Free a= n allocated ax25 control block. This is done to centralise=0A- * the MOD co= unt code.=0A- */=0A-void ax25_free_cb(ax25_cb *ax25)=0A-{=0A- if (ax25->dig= ipeat !=3D NULL) {=0A- kfree(ax25->digipeat);=0A- ax25->digipeat =3D NULL= ;=0A- }=0A-=0A- kfree(ax25);=0A-}=0A-=0A static void ax25_free_sock(struct = sock *sk)=0A {=0A- ax25_free_cb(ax25_sk(sk));=0A+ ax25_cb_put(ax25_sk(sk));= =0A }=0A =0A /*=0A * Socket removal during an interrupt is now safe.=0A *= /=0A-static void ax25_remove_socket(ax25_cb *ax25)=0A+static void ax25_cb_d= el(ax25_cb *ax25)=0A {=0A- ax25_cb *s;=0A-=0A- spin_lock_bh(&ax25_list_lock= );=0A- if ((s =3D ax25_list) =3D=3D ax25) {=0A- ax25_list =3D s->next;=0A+= if (!hlist_unhashed(&ax25->ax25_node)) {=0A+ spin_lock_bh(&ax25_list_lock= );=0A+ hlist_del_init(&ax25->ax25_node);=0A spin_unlock_bh(&ax25_list_lo= ck);=0A- return;=0A- }=0A-=0A- while (s !=3D NULL && s->next !=3D NULL) {= =0A- if (s->next =3D=3D ax25) {=0A- s->next =3D ax25->next;=0A- spin_u= nlock_bh(&ax25_list_lock);=0A- return;=0A- }=0A-=0A- s =3D s->next;=0A+= ax25_cb_put(ax25);=0A }=0A- spin_unlock_bh(&ax25_list_lock);=0A }=0A =0A= /*=0A@@ -108,12 +81,13 @@=0A {=0A ax25_dev *ax25_dev;=0A ax25_cb *s;=0A+= struct hlist_node *node;=0A =0A if ((ax25_dev =3D ax25_dev_ax25dev(dev)) = =3D=3D NULL)=0A return;=0A =0A spin_lock_bh(&ax25_list_lock);=0A- for (s= =3D ax25_list; s !=3D NULL; s =3D s->next) {=0A+ ax25_for_each(s, node, &a= x25_list) {=0A if (s->ax25_dev =3D=3D ax25_dev) {=0A s->ax25_dev =3D N= ULL;=0A ax25_disconnect(s, ENETUNREACH);=0A@@ -153,11 +127,11 @@=0A /*= =0A * Add a socket to the bound sockets list.=0A */=0A-void ax25_insert_s= ocket(ax25_cb *ax25)=0A+void ax25_cb_add(ax25_cb *ax25)=0A {=0A spin_lock_= bh(&ax25_list_lock);=0A- ax25->next =3D ax25_list;=0A- ax25_list =3D ax25;= =0A+ ax25_cb_hold(ax25);=0A+ hlist_add_head(&ax25->ax25_node, &ax25_list);= =0A spin_unlock_bh(&ax25_list_lock);=0A }=0A =0A@@ -169,17 +143,18 @@=0A = struct net_device *dev, int type)=0A {=0A ax25_cb *s;=0A+ struct hlist_nod= e *node;=0A =0A spin_lock_bh(&ax25_list_lock);=0A- for (s =3D ax25_list; s= !=3D NULL; s =3D s->next) {=0A+ ax25_for_each(s, node, &ax25_list) {=0A = if ((s->iamdigi && !digi) || (!s->iamdigi && digi))=0A continue;=0A if= (s->sk && !ax25cmp(&s->source_addr, addr) &&=0A s->sk->sk_type =3D= =3D type && s->sk->sk_state =3D=3D TCP_LISTEN) {=0A /* If device is null= we match any device */=0A if (s->ax25_dev =3D=3D NULL || s->ax25_dev->d= ev =3D=3D dev) {=0A+ sock_hold(s->sk);=0A spin_unlock_bh(&ax25_list_= lock);=0A-=0A return s->sk;=0A }=0A }=0A@@ -197,9 +172,10 @@=0A {= =0A struct sock *sk =3D NULL;=0A ax25_cb *s;=0A+ struct hlist_node *node;= =0A =0A spin_lock_bh(&ax25_list_lock);=0A- for (s =3D ax25_list; s !=3D NU= LL; s =3D s->next) {=0A+ ax25_for_each(s, node, &ax25_list) {=0A if (s->s= k && !ax25cmp(&s->source_addr, my_addr) &&=0A !ax25cmp(&s->dest_addr,= dest_addr) &&=0A s->sk->sk_type =3D=3D type) {=0A@@ -223,9 +199,10 @= @=0A ax25_digi *digi, struct net_device *dev)=0A {=0A ax25_cb *s;=0A+ str= uct hlist_node *node;=0A =0A spin_lock_bh(&ax25_list_lock);=0A- for (s =3D= ax25_list; s !=3D NULL; s =3D s->next) {=0A+ ax25_for_each(s, node, &ax25_= list) {=0A if (s->sk && s->sk->sk_type !=3D SOCK_SEQPACKET)=0A continu= e;=0A if (s->ax25_dev =3D=3D NULL)=0A@@ -240,6 +217,7 @@=0A if (s->di= gipeat !=3D NULL && s->digipeat->ndigi !=3D 0)=0A continue;=0A }=0A= + ax25_cb_hold(s);=0A spin_unlock_bh(&ax25_list_lock);=0A =0A retur= n s;=0A@@ -257,9 +235,10 @@=0A {=0A struct sock *sk =3D NULL;=0A ax25_cb = *s;=0A+ struct hlist_node *node;=0A =0A spin_lock_bh(&ax25_list_lock);=0A-= for (s =3D ax25_list; s !=3D NULL; s =3D s->next) {=0A+ ax25_for_each(s, n= ode, &ax25_list) {=0A if (s->sk !=3D NULL && ax25cmp(&s->source_addr, add= r) =3D=3D 0 &&=0A s->sk->sk_type =3D=3D SOCK_RAW) {=0A sk =3D s->s= k;=0A@@ -267,6 +246,7 @@=0A break;=0A }=0A }=0A+=0A spin_unlock_bh(&= ax25_list_lock);=0A =0A return sk;=0A@@ -299,7 +279,16 @@=0A */=0A static= void ax25_destroy_timer(unsigned long data)=0A {=0A- ax25_destroy_socket((= ax25_cb *)data);=0A+ ax25_cb *ax25=3D(ax25_cb *)data;=0A+ struct sock *sk;= =0A+ =0A+ sk=3Dax25->sk;=0A+ =0A+ bh_lock_sock(sk);=0A+ sock_hold(sk);=0A+ = ax25_destroy_socket(ax25);=0A+ bh_unlock_sock(sk);=0A+ sock_put(sk);=0A }= =0A =0A /*=0A@@ -312,7 +301,7 @@=0A {=0A struct sk_buff *skb;=0A =0A- ax25= _remove_socket(ax25);=0A+ ax25_cb_del(ax25);=0A =0A ax25_stop_heartbeat(ax= 25);=0A ax25_stop_t1timer(ax25);=0A@@ -337,22 +326,27 @@=0A =0A kfree_s= kb(skb);=0A }=0A+ while ((skb =3D skb_dequeue(&ax25->sk->sk_write_queue)= ) !=3D NULL) {=0A+ kfree_skb(skb);=0A+ }=0A }=0A =0A if (ax25->sk !=3D= NULL) {=0A if (atomic_read(&ax25->sk->sk_wmem_alloc) ||=0A atomic_= read(&ax25->sk->sk_rmem_alloc)) {=0A /* Defer: outstanding buffers */=0A= - init_timer(&ax25->timer);=0A- ax25->timer.expires =3D jiffies + 10 *= HZ;=0A- ax25->timer.function =3D ax25_destroy_timer;=0A- ax25->timer.d= ata =3D (unsigned long)ax25;=0A- add_timer(&ax25->timer);=0A+ init_= timer(&ax25->dtimer);=0A+ ax25->dtimer.expires =3D jiffies + 2 * HZ;=0A+= ax25->dtimer.function =3D ax25_destroy_timer;=0A+ ax25->dtimer.data = =3D (unsigned long)ax25;=0A+ add_timer(&ax25->dtimer);=0A } else {=0A= - sock_put(ax25->sk);=0A+ struct sock *sk=3Dax25->sk;=0A+ ax25->sk=3D= NULL;=0A+ sock_put(sk);=0A }=0A } else {=0A- ax25_free_cb(ax25);=0A+ = ax25_cb_put(ax25);=0A }=0A }=0A =0A@@ -421,7 +415,7 @@=0A =0A case AX2= 5_N2:=0A if (ax25_ctl.arg < 1 || ax25_ctl.arg > 31)=0A- return -EIN= VAL;=0A+ return -EINVAL;=0A ax25->n2count =3D 0;=0A ax25->n2 =3D = ax25_ctl.arg;=0A break;=0A@@ -448,7 +442,7 @@=0A return -EINVAL;=0A= }=0A =0A- return 0;=0A+ return 0;=0A }=0A =0A /*=0A@@ -507,6 +501,7 @= @=0A return NULL;=0A =0A memset(ax25, 0x00, sizeof(*ax25));=0A+ atomic_s= et(&ax25->refcount, 1);=0A =0A skb_queue_head_init(&ax25->write_queue);=0A= skb_queue_head_init(&ax25->frag_queue);=0A@@ -655,6 +650,7 @@=0A (so= ck->state !=3D SS_UNCONNECTED ||=0A sk->sk_state =3D=3D TCP_LISTEN)) = {=0A res =3D -EADDRNOTAVAIL;=0A+ dev_put(dev);=0A break;=0A }=0A = =0A@@ -877,7 +873,7 @@=0A break;=0A default:=0A sk_free(sk);=0A- ax25= _free_cb(ax25);=0A+ ax25_cb_put(ax25);=0A return NULL;=0A }=0A =0A@@ -9= 37,6 +933,7 @@=0A if (sk =3D=3D NULL)=0A return 0;=0A =0A+ sock_hold(sk)= ;=0A lock_sock(sk);=0A ax25 =3D ax25_sk(sk);=0A =0A@@ -944,13 +941,15 @@= =0A switch (ax25->state) {=0A case AX25_STATE_0:=0A ax25_disconnect(= ax25, 0);=0A- goto drop;=0A+ ax25_destroy_socket(ax25);=0A+ break;=0A= =0A case AX25_STATE_1:=0A case AX25_STATE_2:=0A ax25_send_control(a= x25, AX25_DISC, AX25_POLLON, AX25_COMMAND);=0A ax25_disconnect(ax25, 0);= =0A- goto drop;=0A+ ax25_destroy_socket(ax25);=0A+ break;=0A =0A ca= se AX25_STATE_3:=0A case AX25_STATE_4:=0A@@ -993,16 +992,14 @@=0A sk->s= k_shutdown |=3D SEND_SHUTDOWN;=0A sk->sk_state_change(sk);=0A sock_set_= flag(sk, SOCK_DEAD);=0A- goto drop;=0A+ ax25_destroy_socket(ax25);=0A }= =0A =0A sock->sk =3D NULL;=0A sk->sk_socket =3D NULL; /* Not used, but = we should do this */=0A release_sock(sk);=0A- return 0;=0A- drop:=0A- rele= ase_sock(sk);=0A- ax25_destroy_socket(ax25);=0A+ sock_put(sk);=0A+=0A retu= rn 0;=0A }=0A =0A@@ -1077,7 +1074,7 @@=0A ax25_fillin_cb(ax25, ax25_dev);= =0A =0A done:=0A- ax25_insert_socket(ax25);=0A+ ax25_cb_add(ax25);=0A sk->= sk_zapped =3D 0;=0A =0A out:=0A@@ -1093,7 +1090,7 @@=0A int addr_len, int = flags)=0A {=0A struct sock *sk =3D sock->sk;=0A- ax25_cb *ax25 =3D ax25_sk= (sk);=0A+ ax25_cb *ax25 =3D ax25_sk(sk), *ax25t;=0A struct full_sockaddr_a= x25 *fsa =3D (struct full_sockaddr_ax25 *)uaddr;=0A ax25_digi *digi =3D NU= LL;=0A int ct =3D 0, err =3D 0;=0A@@ -1199,7 +1196,7 @@=0A goto out;=0A= =0A ax25_fillin_cb(ax25, ax25->ax25_dev);=0A- ax25_insert_socket(ax25);= =0A+ ax25_cb_add(ax25);=0A } else {=0A if (ax25->ax25_dev =3D=3D NULL) = {=0A err =3D -EHOSTUNREACH;=0A@@ -1208,11 +1205,12 @@=0A }=0A =0A if (= sk->sk_type =3D=3D SOCK_SEQPACKET &&=0A- ax25_find_cb(&ax25->source_add= r, &fsa->fsa_ax25.sax25_call, digi,=0A- ax25->ax25_dev->dev)) {=0A+ = (ax25t=3Dax25_find_cb(&ax25->source_addr, &fsa->fsa_ax25.sax25_call, di= gi,=0A+ ax25->ax25_dev->dev))) {=0A if (digi !=3D NULL)=0A kfre= e(digi);=0A err =3D -EADDRINUSE; /* Already such a connection */=0A+ ax= 25_cb_put(ax25t);=0A goto out;=0A }=0A =0A@@ -1273,6 +1271,8 @@=0A l= ock_sock(sk);=0A continue;=0A }=0A+ current->state =3D TASK_RUNNIN= G;=0A+ remove_wait_queue(sk->sk_sleep, &wait);=0A return -ERESTARTSYS;= =0A }=0A current->state =3D TASK_RUNNING;=0A@@ -1288,10 +1288,11 @@=0A = =0A sock->state =3D SS_CONNECTED;=0A =0A+ err=3D0;=0A out:=0A release_soc= k(sk);=0A =0A- return 0;=0A+ return err;=0A }=0A =0A =0A@@ -1331,15 +1332,1= 8 @@=0A if (skb)=0A break;=0A =0A- current->state =3D TASK_INTERRUPTI= BLE;=0A release_sock(sk);=0A+ current->state =3D TASK_INTERRUPTIBLE;=0A = if (flags & O_NONBLOCK)=0A return -EWOULDBLOCK;=0A if (!signal_pendi= ng(tsk)) {=0A schedule();=0A+ current->state =3D TASK_RUNNING;=0A l= ock_sock(sk);=0A continue;=0A }=0A+ current->state =3D TASK_RUNNING;= =0A+ remove_wait_queue(sk->sk_sleep, &wait);=0A return -ERESTARTSYS;=0A = }=0A current->state =3D TASK_RUNNING;=0A@@ -1519,7 +1523,7 @@=0A SOCK_DE= BUG(sk, "AX.25: sendto: building packet.\n");=0A =0A /* Assume the worst c= ase */=0A- size =3D len + 3 + ax25_addr_size(dp) + AX25_BPQ_HEADER_LEN;=0A+= size =3D len + ax25->ax25_dev->dev->hard_header_len;=0A =0A skb =3D sock_= alloc_send_skb(sk, size, msg->msg_flags&MSG_DONTWAIT, &err);=0A if (skb = =3D=3D NULL)=0A@@ -1780,7 +1784,7 @@=0A =0A /* old structure? */=0A if = (cmd =3D=3D SIOCAX25GETINFOOLD) {=0A- static int warned;=0A+ static int= warned =3D 0;=0A if (!warned) {=0A printk(KERN_INFO "%s uses old SI= OCAX25GETINFO\n",=0A current->comm);=0A@@ -1845,6 +1849,7 @@=0A int l= en =3D 0;=0A off_t pos =3D 0;=0A off_t begin =3D 0;=0A+ struct hlist_node= *node;=0A =0A spin_lock_bh(&ax25_list_lock);=0A =0A@@ -1853,7 +1858,7 @@= =0A * magic dev src_addr dest_addr,digi1,digi2,.. st vs vr va t1 t1 t2 t2= t3 t3 idle idle n2 n2 rtt window paclen Snd-Q Rcv-Q inode=0A */=0A =0A- = for (ax25 =3D ax25_list; ax25 !=3D NULL; ax25 =3D ax25->next) {=0A+ ax25_fo= r_each(ax25, node, &ax25_list) {=0A len +=3D sprintf(buffer+len, "%8.8lx = %s %s%s ",=0A (long) ax25,=0A ax25->ax25_dev =3D=3D NULL? "???" : a= x25->ax25_dev->dev->name,=0A@@ -1882,10 +1887,12 @@=0A ax25->paclen);=0A= =0A if (ax25->sk !=3D NULL) {=0A+ bh_lock_sock(ax25->sk);=0A len += =3D sprintf(buffer + len, " %d %d %ld\n",=0A atomic_read(&ax25->sk->sk_= wmem_alloc),=0A atomic_read(&ax25->sk->sk_rmem_alloc),=0A ax25->sk-= >sk_socket !=3D NULL ? SOCK_INODE(ax25->sk->sk_socket)->i_ino : 0L);=0A+ = bh_unlock_sock(ax25->sk);=0A } else {=0A len +=3D sprintf(buffer + len= , " * * *\n");=0A }=0AOnly in linux-2.6.0-test3.rxq/net/ax25: af_ax25.o= =0AOnly in linux-2.6.0-test3.rxq/net/ax25: ax25.ko=0AOnly in linux-2.6.0-te= st3.rxq/net/ax25: ax25.mod.c=0AOnly in linux-2.6.0-test3.rxq/net/ax25: ax25= .mod.o=0AOnly in linux-2.6.0-test3.rxq/net/ax25: ax25.o=0AOnly in linux-2.6= .0-test3.rxq/net/ax25: ax25_addr.o=0AOnly in linux-2.6.0-test3.rxq/net/ax25= : ax25_dev.o=0Adiff -ru linux-2.6.0-test3/net/ax25/ax25_ds_in.c linux-2.6.0= -test3.rxq/net/ax25/ax25_ds_in.c=0A--- linux-2.6.0-test3/net/ax25/ax25_ds_i= n.c 2003-08-09 06:38:45.000000000 +0200=0A+++ linux-2.6.0-test3.rxq/net/ax2= 5/ax25_ds_in.c 2003-08-12 23:40:35.000000000 +0200=0A@@ -65,6 +65,7 @@=0A = ax25->state =3D AX25_STATE_3;=0A ax25->n2count =3D 0;=0A if (ax25->s= k !=3D NULL) {=0A+ bh_lock_sock(ax25->sk);=0A ax25->sk->sk_state =3D T= CP_ESTABLISHED;=0A /*=0A * For WAIT_SABM connections we will produce= an accept=0A@@ -72,6 +73,7 @@=0A */=0A if (!sock_flag(ax25->sk, SOC= K_DEAD))=0A ax25->sk->sk_state_change(ax25->sk);=0A+ bh_unlock_sock(a= x25->sk);=0A }=0A ax25_dama_on(ax25);=0A =0Adiff -ru linux-2.6.0-test3/= net/ax25/ax25_ds_subr.c linux-2.6.0-test3.rxq/net/ax25/ax25_ds_subr.c=0A---= linux-2.6.0-test3/net/ax25/ax25_ds_subr.c 2003-08-09 06:41:32.000000000 +0= 200=0A+++ linux-2.6.0-test3.rxq/net/ax25/ax25_ds_subr.c 2003-08-12 23:40:35= .000000000 +0200=0A@@ -40,6 +40,7 @@=0A void ax25_ds_enquiry_response(ax25_= cb *ax25)=0A {=0A ax25_cb *ax25o;=0A+ struct hlist_node *node;=0A =0A /* = Please note that neither DK4EG=B4s nor DG2FEF=B4s=0A * DAMA spec mention = the following behaviour as seen=0A@@ -80,7 +81,7 @@=0A ax25_ds_set_timer(a= x25->ax25_dev);=0A =0A spin_lock_bh(&ax25_list_lock);=0A- for (ax25o =3D a= x25_list; ax25o !=3D NULL; ax25o =3D ax25o->next) {=0A+ ax25_for_each(ax25o= , node, &ax25_list) {=0A if (ax25o =3D=3D ax25)=0A continue;=0A =0A@@ = -160,9 +161,10 @@=0A {=0A ax25_cb *ax25;=0A int res =3D 0;=0A+ struct hli= st_node *node;=0A =0A spin_lock_bh(&ax25_list_lock);=0A- for (ax25 =3D ax2= 5_list; ax25 !=3D NULL ; ax25 =3D ax25->next)=0A+ ax25_for_each(ax25, node,= &ax25_list)=0A if (ax25->ax25_dev =3D=3D ax25_dev && (ax25->condition & = AX25_COND_DAMA_MODE) && ax25->state > AX25_STATE_1) {=0A res =3D 1;=0A = break;=0Adiff -ru linux-2.6.0-test3/net/ax25/ax25_ds_timer.c linux-2.6.0-= test3.rxq/net/ax25/ax25_ds_timer.c=0A--- linux-2.6.0-test3/net/ax25/ax25_ds= _timer.c 2003-08-09 06:41:26.000000000 +0200=0A+++ linux-2.6.0-test3.rxq/ne= t/ax25/ax25_ds_timer.c 2003-08-12 23:40:35.000000000 +0200=0A@@ -74,6 +74,7= @@=0A {=0A ax25_dev *ax25_dev =3D (struct ax25_dev *) arg;=0A ax25_cb *a= x25;=0A+ struct hlist_node *node;=0A =0A if (ax25_dev =3D=3D NULL || !ax25= _dev->dama.slave)=0A return; /* Yikes! */=0A@@ -84,7 +85,7 @@=0A }=0A = =0A spin_lock_bh(&ax25_list_lock);=0A- for (ax25=3Dax25_list; ax25 !=3D NU= LL; ax25 =3D ax25->next) {=0A+ ax25_for_each(ax25, node, &ax25_list) {=0A = if (ax25->ax25_dev !=3D ax25_dev || !(ax25->condition & AX25_COND_DAMA_MOD= E))=0A continue;=0A =0A@@ -98,15 +99,26 @@=0A =0A void ax25_ds_heartbeat= _expiry(ax25_cb *ax25)=0A {=0A+ struct sock *sk=3Dax25->sk;=0A+=0A+ if (sk)= =0A+ bh_lock_sock(sk);=0A+=0A switch (ax25->state) {=0A =0A case AX25_ST= ATE_0:=0A /* Magic here: If we listen() and a new link dies before it=0A = is accepted() it isn't 'dead' so doesn't get removed. */=0A- if (!ax2= 5->sk || sock_flag(ax25->sk, SOCK_DESTROY) ||=0A- (ax25->sk->sk_state = =3D=3D TCP_LISTEN &&=0A- sock_flag(ax25->sk, SOCK_DEAD))) {=0A- ax2= 5_destroy_socket(ax25);=0A+ if (!sk || sock_flag(sk, SOCK_DESTROY) ||=0A+ = (sk->sk_state =3D=3D TCP_LISTEN &&=0A+ sock_flag(sk, SOCK_DEAD))= ) {=0A+ if (sk) {=0A+ sock_hold(sk);=0A+ ax25_destroy_socket(ax25);= =0A+ sock_put(sk);=0A+ bh_unlock_sock(sk);=0A+ } else=0A+ ax25_d= estroy_socket(ax25);=0A return;=0A }=0A break;=0A@@ -115,9 +127,9 @@= =0A /*=0A * Check the state of the receive buffer.=0A */=0A- if (a= x25->sk !=3D NULL) {=0A- if (atomic_read(&ax25->sk->sk_rmem_alloc) <=0A- = (ax25->sk->sk_rcvbuf / 2) &&=0A+ if (sk !=3D NULL) {=0A+ if (atomi= c_read(&sk->sk_rmem_alloc) <=0A+ (sk->sk_rcvbuf / 2) &&=0A (ax= 25->condition & AX25_COND_OWN_RX_BUSY)) {=0A ax25->condition &=3D ~AX25= _COND_OWN_RX_BUSY;=0A ax25->condition &=3D ~AX25_COND_ACK_PENDING;=0A@@= -127,6 +139,9 @@=0A break;=0A }=0A =0A+ if (sk)=0A+ bh_unlock_sock(sk)= ;=0A+=0A ax25_start_heartbeat(ax25);=0A }=0A =0A@@ -157,6 +172,7 @@=0A ax= 25_stop_t3timer(ax25);=0A =0A if (ax25->sk !=3D NULL) {=0A+ bh_lock_sock(= ax25->sk);=0A ax25->sk->sk_state =3D TCP_CLOSE;=0A ax25->sk->sk_err= =3D 0;=0A ax25->sk->sk_shutdown |=3D SEND_SHUTDOWN;=0A@@ -164,6 +1= 80,7 @@=0A ax25->sk->sk_state_change(ax25->sk);=0A sock_set_flag(ax25= ->sk, SOCK_DEAD);=0A }=0A+ bh_lock_sock(ax25->sk);=0A }=0A }=0A =0Adiff= -ru linux-2.6.0-test3/net/ax25/ax25_iface.c linux-2.6.0-test3.rxq/net/ax25= /ax25_iface.c=0A--- linux-2.6.0-test3/net/ax25/ax25_iface.c 2003-08-09 06:4= 2:13.000000000 +0200=0A+++ linux-2.6.0-test3.rxq/net/ax25/ax25_iface.c 2003= -08-12 23:40:35.000000000 +0200=0A@@ -33,20 +33,20 @@=0A struct protocol_s= truct *next;=0A unsigned int pid;=0A int (*func)(struct sk_buff *, ax25_c= b *);=0A-} *protocol_list;=0A+} *protocol_list =3D NULL;=0A static rwlock_t= protocol_list_lock =3D RW_LOCK_UNLOCKED;=0A =0A static struct linkfail_str= uct {=0A struct linkfail_struct *next;=0A void (*func)(ax25_cb *, int);= =0A-} *linkfail_list;=0A+} *linkfail_list =3D NULL;=0A static spinlock_t li= nkfail_lock =3D SPIN_LOCK_UNLOCKED;=0A =0A static struct listen_struct {=0A= struct listen_struct *next;=0A ax25_address callsign;=0A struct net_de= vice *dev;=0A-} *listen_list;=0A+} *listen_list =3D NULL;=0A static spinloc= k_t listen_lock =3D SPIN_LOCK_UNLOCKED;=0A =0A int ax25_protocol_register(u= nsigned int pid,=0A@@ -129,8 +129,10 @@=0A =0A spin_lock_bh(&linkfail_lock= );=0A linkfail =3D linkfail_list;=0A- if (linkfail =3D=3D NULL)=0A+ if (li= nkfail =3D=3D NULL) {=0A+ spin_unlock_bh(&linkfail_lock);=0A return;=0A+= }=0A =0A if (linkfail->func =3D=3D func) {=0A linkfail_list =3D linkfai= l->next;=0A@@ -180,8 +182,10 @@=0A =0A spin_lock_bh(&listen_lock);=0A lis= ten =3D listen_list;=0A- if (listen =3D=3D NULL)=0A+ if (listen =3D=3D NULL= ) {=0A+ spin_unlock_bh(&listen_lock);=0A return;=0A+ }=0A =0A if (ax25c= mp(&listen->callsign, callsign) =3D=3D 0 && listen->dev =3D=3D dev) {=0A = listen_list =3D listen->next;=0A@@ -226,8 +230,10 @@=0A =0A spin_lock_bh(&= listen_lock);=0A for (listen =3D listen_list; listen !=3D NULL; listen =3D= listen->next)=0A- if (ax25cmp(&listen->callsign, callsign) =3D=3D 0 && (l= isten->dev =3D=3D dev || listen->dev =3D=3D NULL))=0A+ if (ax25cmp(&listen= ->callsign, callsign) =3D=3D 0 && (listen->dev =3D=3D dev || listen->dev = =3D=3D NULL)) {=0A+ spin_unlock_bh(&listen_lock);=0A return 1;=0A+ }= =0A spin_unlock_bh(&listen_lock);=0A =0A return 0;=0AOnly in linux-2.6.0-= test3.rxq/net/ax25: ax25_iface.o=0Adiff -ru linux-2.6.0-test3/net/ax25/ax25= _in.c linux-2.6.0-test3.rxq/net/ax25/ax25_in.c=0A--- linux-2.6.0-test3/net/= ax25/ax25_in.c 2003-08-09 06:32:47.000000000 +0200=0A+++ linux-2.6.0-test3.= rxq/net/ax25/ax25_in.c 2003-08-12 23:40:35.000000000 +0200=0A@@ -147,6 +147= ,7 @@=0A }=0A =0A if (ax25->sk !=3D NULL && ax25->ax25_dev->values[AX25_V= ALUES_CONMODE] =3D=3D 2) {=0A+ bh_lock_sock(ax25->sk);=0A if ((!ax25->pi= dincl && ax25->sk->sk_protocol =3D=3D pid) ||=0A ax25->pidincl) {=0A = if (sock_queue_rcv_skb(ax25->sk, skb) =3D=3D 0)=0A@@ -154,6 +155,7 @@=0A= else=0A ax25->condition |=3D AX25_COND_OWN_RX_BUSY;=0A }=0A+ bh_= unlock_sock(ax25->sk);=0A }=0A =0A return queued;=0A@@ -329,6 +331,7 @@= =0A if (ax25_process_rx_frame(ax25, skb, type, dama) =3D=3D 0)=0A kfre= e_skb(skb);=0A =0A+ ax25_cb_put(ax25);=0A return 0;=0A }=0A =0A@@ -357,= 11 +360,14 @@=0A sk =3D ax25_find_listener(next_digi, 1, dev, SOCK_SEQPAC= KET);=0A =0A if (sk !=3D NULL) {=0A+ bh_lock_sock(sk);=0A if (sk->sk_ac= k_backlog =3D=3D sk->sk_max_ack_backlog ||=0A (make =3D ax25_make_new= (sk, ax25_dev)) =3D=3D NULL) {=0A if (mine)=0A ax25_return_dm(dev, &= src, &dest, &dp);=0A kfree_skb(skb);=0A+ bh_unlock_sock(sk);=0A+ soc= k_put(sk);=0A =0A return 0;=0A }=0A@@ -374,6 +380,8 @@=0A make->sk_p= air =3D sk;=0A =0A sk->sk_ack_backlog++;=0A+ bh_unlock_sock(sk);=0A+ s= ock_put(sk);=0A } else {=0A if (!mine) {=0A kfree_skb(skb);=0A@@ -429= ,7 +437,7 @@=0A =0A ax25->state =3D AX25_STATE_3;=0A =0A- ax25_insert_sock= et(ax25);=0A+ ax25_cb_add(ax25);=0A =0A ax25_start_heartbeat(ax25);=0A ax= 25_start_t3timer(ax25);=0AOnly in linux-2.6.0-test3.rxq/net/ax25: ax25_in.o= =0Adiff -ru linux-2.6.0-test3/net/ax25/ax25_ip.c linux-2.6.0-test3.rxq/net/= ax25/ax25_ip.c=0A--- linux-2.6.0-test3/net/ax25/ax25_ip.c 2003-08-09 06:34:= 43.000000000 +0200=0A+++ linux-2.6.0-test3.rxq/net/ax25/ax25_ip.c 2003-08-1= 2 23:40:35.000000000 +0200=0A@@ -107,6 +107,7 @@=0A ax25_address *src, *ds= t;=0A ax25_dev *ax25_dev;=0A ax25_route _route, *route =3D &_route;=0A+ a= x25_cb *ax25;=0A =0A dst =3D (ax25_address *)(bp + 1);=0A src =3D (ax25_a= ddress *)(bp + 8);=0A@@ -167,9 +168,14 @@=0A skb_pull(ourskb, AX25_HEADE= R_LEN - 1); /* Keep PID */=0A ourskb->nh.raw =3D ourskb->data;=0A =0A- = ax25_send_frame(ourskb, ax25_dev->values[AX25_VALUES_PACLEN], &src_c,=0A-&= dst_c, route->digipeat, dev);=0A-=0A+ ax25=3Dax25_send_frame(=0A+ o= urskb, =0A+ ax25_dev->values[AX25_VALUES_PACLEN], =0A+ &src_c,= =0A+ &dst_c, route->digipeat, dev);=0A+ if (ax25) {=0A+ ax25_cb_= put(ax25);=0A+ }=0A goto put;=0A }=0A }=0AOnly in linux-2.6.0-test3= .rxq/net/ax25: ax25_ip.o=0Adiff -ru linux-2.6.0-test3/net/ax25/ax25_out.c l= inux-2.6.0-test3.rxq/net/ax25/ax25_out.c=0A--- linux-2.6.0-test3/net/ax25/a= x25_out.c 2003-08-09 06:40:10.000000000 +0200=0A+++ linux-2.6.0-test3.rxq/n= et/ax25/ax25_out.c 2003-08-12 23:40:35.000000000 +0200=0A@@ -71,7 +71,7 @@= =0A =0A if (digi !=3D NULL) {=0A if ((ax25->digipeat =3D kmalloc(sizeof(= ax25_digi), GFP_ATOMIC)) =3D=3D NULL) {=0A- ax25_free_cb(ax25);=0A+ ax2= 5_cb_put(ax25);=0A return NULL;=0A }=0A memcpy(ax25->digipeat, digi,= sizeof(ax25_digi));=0A@@ -93,7 +93,7 @@=0A #endif=0A }=0A =0A- ax25_inser= t_socket(ax25);=0A+ ax25_cb_add(ax25);=0A =0A ax25->state =3D AX25_STATE_1= ;=0A =0AOnly in linux-2.6.0-test3.rxq/net/ax25: ax25_out.o=0Adiff -ru linux= -2.6.0-test3/net/ax25/ax25_route.c linux-2.6.0-test3.rxq/net/ax25/ax25_rout= e.c=0A--- linux-2.6.0-test3/net/ax25/ax25_route.c 2003-08-09 06:38:41.00000= 0000 +0200=0A+++ linux-2.6.0-test3.rxq/net/ax25/ax25_route.c 2003-08-12 23:= 40:35.000000000 +0200=0A@@ -162,6 +162,7 @@=0A if (ax25_rt->digipeat !=3D= NULL)=0A kfree(ax25_rt->digipeat);=0A kfree(ax25_rt);=0A+ return;=0A= }=0A =0A /*=0A@@ -434,8 +435,11 @@=0A ax25_adjust_path(addr, ax25->dig= ipeat);=0A }=0A =0A- if (ax25->sk !=3D NULL)=0A+ if (ax25->sk !=3D NULL) {= =0A+ bh_lock_sock(ax25->sk);=0A ax25->sk->sk_zapped =3D 0;=0A+ bh_unloc= k_sock(ax25->sk);=0A+ }=0A =0A put:=0A ax25_put_route(ax25_rt);=0AOnly in = linux-2.6.0-test3.rxq/net/ax25: ax25_route.o=0Adiff -ru linux-2.6.0-test3/n= et/ax25/ax25_std_in.c linux-2.6.0-test3.rxq/net/ax25/ax25_std_in.c=0A--- li= nux-2.6.0-test3/net/ax25/ax25_std_in.c 2003-08-09 06:39:26.000000000 +0200= =0A+++ linux-2.6.0-test3.rxq/net/ax25/ax25_std_in.c 2003-08-12 23:40:35.000= 000000 +0200=0A@@ -73,10 +73,12 @@=0A ax25->state =3D AX25_STATE_3;=0A= ax25->n2count =3D 0;=0A if (ax25->sk !=3D NULL) {=0A+ bh_lock_soc= k(ax25->sk);=0A ax25->sk->sk_state =3D TCP_ESTABLISHED;=0A /* For W= AIT_SABM connections we will produce an accept ready socket here */=0A = if (!sock_flag(ax25->sk, SOCK_DEAD))=0A ax25->sk->sk_state_change(ax25= ->sk);=0A+ bh_unlock_sock(ax25->sk);=0A }=0A }=0A break;=0AOnly i= n linux-2.6.0-test3.rxq/net/ax25: ax25_std_in.o=0AOnly in linux-2.6.0-test3= .rxq/net/ax25: ax25_std_subr.o=0Adiff -ru linux-2.6.0-test3/net/ax25/ax25_s= td_timer.c linux-2.6.0-test3.rxq/net/ax25/ax25_std_timer.c=0A--- linux-2.6.= 0-test3/net/ax25/ax25_std_timer.c 2003-08-09 06:34:03.000000000 +0200=0A+++= linux-2.6.0-test3.rxq/net/ax25/ax25_std_timer.c 2003-08-12 23:40:35.000000= 000 +0200=0A@@ -33,14 +33,25 @@=0A =0A void ax25_std_heartbeat_expiry(ax25_= cb *ax25)=0A {=0A+ struct sock *sk=3Dax25->sk;=0A+ =0A+ if (sk)=0A+ bh_loc= k_sock(sk);=0A+=0A switch (ax25->state) {=0A case AX25_STATE_0:=0A /* M= agic here: If we listen() and a new link dies before it=0A is accepted= () it isn't 'dead' so doesn't get removed. */=0A- if (!ax25->sk || sock_fl= ag(ax25->sk, SOCK_DESTROY) ||=0A- (ax25->sk->sk_state =3D=3D TCP_LISTE= N &&=0A- sock_flag(ax25->sk, SOCK_DEAD))) {=0A- ax25_destroy_socket= (ax25);=0A+ if (!sk || sock_flag(sk, SOCK_DESTROY) ||=0A+ (sk->sk_sta= te =3D=3D TCP_LISTEN &&=0A+ sock_flag(sk, SOCK_DEAD))) {=0A+ if (sk= ) {=0A+ sock_hold(sk);=0A+ ax25_destroy_socket(ax25);=0A+ bh_unloc= k_sock(sk);=0A+ sock_put(sk);=0A+ } else=0A+ ax25_destroy_socket(ax= 25);=0A return;=0A }=0A break;=0A@@ -50,9 +61,9 @@=0A /*=0A * C= heck the state of the receive buffer.=0A */=0A- if (ax25->sk !=3D NULL)= {=0A- if (atomic_read(&ax25->sk->sk_rmem_alloc) <=0A- (ax25->sk->s= k_rcvbuf / 2) &&=0A+ if (sk !=3D NULL) {=0A+ if (atomic_read(&sk->sk_rme= m_alloc) <=0A+ (sk->sk_rcvbuf / 2) &&=0A (ax25->condition & AX= 25_COND_OWN_RX_BUSY)) {=0A ax25->condition &=3D ~AX25_COND_OWN_RX_BUSY;= =0A ax25->condition &=3D ~AX25_COND_ACK_PENDING;=0A@@ -62,6 +73,9 @@=0A= }=0A }=0A =0A+ if (sk)=0A+ bh_unlock_sock(sk);=0A+=0A ax25_start_hear= tbeat(ax25);=0A }=0A =0A@@ -94,6 +108,7 @@=0A ax25_stop_t3timer(ax25);=0A = =0A if (ax25->sk !=3D NULL) {=0A+ bh_lock_sock(ax25->sk);=0A ax25->sk->= sk_state =3D TCP_CLOSE;=0A ax25->sk->sk_err =3D 0;=0A ax25->s= k->sk_shutdown |=3D SEND_SHUTDOWN;=0A@@ -101,6 +116,7 @@=0A ax25->sk->sk= _state_change(ax25->sk);=0A sock_set_flag(ax25->sk, SOCK_DEAD);=0A }= =0A+ bh_unlock_sock(ax25->sk);=0A }=0A }=0A =0AOnly in linux-2.6.0-test3.= rxq/net/ax25: ax25_std_timer.o=0Adiff -ru linux-2.6.0-test3/net/ax25/ax25_s= ubr.c linux-2.6.0-test3.rxq/net/ax25/ax25_subr.c=0A--- linux-2.6.0-test3/ne= t/ax25/ax25_subr.c 2003-08-09 06:41:35.000000000 +0200=0A+++ linux-2.6.0-te= st3.rxq/net/ax25/ax25_subr.c 2003-08-12 23:40:35.000000000 +0200=0A@@ -158,= 10 +158,10 @@=0A struct sk_buff *skb;=0A unsigned char *dptr;=0A =0A- if= ((skb =3D alloc_skb(AX25_BPQ_HEADER_LEN + ax25_addr_size(ax25->digipeat) += 2, GFP_ATOMIC)) =3D=3D NULL)=0A+ if ((skb =3D alloc_skb(ax25->ax25_dev->de= v->hard_header_len + 2, GFP_ATOMIC)) =3D=3D NULL)=0A return;=0A =0A- skb_= reserve(skb, AX25_BPQ_HEADER_LEN + ax25_addr_size(ax25->digipeat));=0A+ skb= _reserve(skb, ax25->ax25_dev->dev->hard_header_len);=0A =0A skb->nh.raw = =3D skb->data;=0A =0A@@ -202,10 +202,10 @@=0A if (dev =3D=3D NULL)=0A re= turn;=0A =0A- if ((skb =3D alloc_skb(AX25_BPQ_HEADER_LEN + ax25_addr_size(d= igi) + 1, GFP_ATOMIC)) =3D=3D NULL)=0A+ if ((skb =3D alloc_skb(dev->hard_he= ader_len + 1, GFP_ATOMIC)) =3D=3D NULL)=0A return; /* Next SABM will get = DM'd */=0A =0A- skb_reserve(skb, AX25_BPQ_HEADER_LEN + ax25_addr_size(digi)= );=0A+ skb_reserve(skb, dev->hard_header_len);=0A skb->nh.raw =3D skb->dat= a;=0A =0A ax25_digi_invert(digi, &retdigi);=0A@@ -282,6 +282,7 @@=0A ax25= _link_failed(ax25, reason);=0A =0A if (ax25->sk !=3D NULL) {=0A+ bh_lock_= sock(ax25->sk);=0A ax25->sk->sk_state =3D TCP_CLOSE;=0A ax25->sk->s= k_err =3D reason;=0A ax25->sk->sk_shutdown |=3D SEND_SHUTDOWN;=0A@@= -289,5 +290,6 @@=0A ax25->sk->sk_state_change(ax25->sk);=0A sock_set= _flag(ax25->sk, SOCK_DEAD);=0A }=0A+ bh_unlock_sock(ax25->sk);=0A }=0A = }=0AOnly in linux-2.6.0-test3.rxq/net/ax25: ax25_subr.o=0Adiff -ru linux-2.= 6.0-test3/net/ax25/ax25_timer.c linux-2.6.0-test3.rxq/net/ax25/ax25_timer.c= =0A--- linux-2.6.0-test3/net/ax25/ax25_timer.c 2003-08-09 06:38:16.00000000= 0 +0200=0A+++ linux-2.6.0-test3.rxq/net/ax25/ax25_timer.c 2003-08-12 23:40:= 35.000000000 +0200=0A@@ -141,13 +141,10 @@=0A {=0A int proto =3D AX25_PROT= O_STD_SIMPLEX;=0A ax25_cb *ax25 =3D (ax25_cb *)param;=0A- struct sock *sk = =3D ax25->sk;=0A =0A if (ax25->ax25_dev)=0A proto =3D ax25->ax25_dev->va= lues[AX25_VALUES_PROTOCOL];=0A =0A- bh_lock_sock(sk);=0A-=0A switch (proto= ) {=0A case AX25_PROTO_STD_SIMPLEX:=0A case AX25_PROTO_STD_DUPLEX:=0A@@ -= 163,15 +160,12 @@=0A break;=0A #endif=0A }=0A- bh_unlock_sock(sk);=0A }= =0A =0A static void ax25_t1timer_expiry(unsigned long param)=0A {=0A ax25_= cb *ax25 =3D (ax25_cb *)param;=0A- struct sock *sk =3D ax25->sk;=0A =0A- bh= _lock_sock(sk);=0A switch (ax25->ax25_dev->values[AX25_VALUES_PROTOCOL]) {= =0A case AX25_PROTO_STD_SIMPLEX:=0A case AX25_PROTO_STD_DUPLEX:=0A@@ -185= ,15 +179,12 @@=0A break;=0A #endif=0A }=0A- bh_unlock_sock(sk);=0A }=0A = =0A static void ax25_t2timer_expiry(unsigned long param)=0A {=0A ax25_cb *= ax25 =3D (ax25_cb *)param;=0A- struct sock *sk =3D ax25->sk;=0A =0A- bh_loc= k_sock(sk);=0A switch (ax25->ax25_dev->values[AX25_VALUES_PROTOCOL]) {=0A = case AX25_PROTO_STD_SIMPLEX:=0A case AX25_PROTO_STD_DUPLEX:=0A@@ -207,15 = +198,12 @@=0A break;=0A #endif=0A }=0A- bh_unlock_sock(sk);=0A }=0A =0A = static void ax25_t3timer_expiry(unsigned long param)=0A {=0A ax25_cb *ax25= =3D (ax25_cb *)param;=0A- struct sock *sk =3D ax25->sk;=0A =0A- bh_lock_so= ck(sk);=0A switch (ax25->ax25_dev->values[AX25_VALUES_PROTOCOL]) {=0A cas= e AX25_PROTO_STD_SIMPLEX:=0A case AX25_PROTO_STD_DUPLEX:=0A@@ -231,15 +219= ,12 @@=0A break;=0A #endif=0A }=0A- bh_unlock_sock(sk);=0A }=0A =0A stat= ic void ax25_idletimer_expiry(unsigned long param)=0A {=0A ax25_cb *ax25 = =3D (ax25_cb *)param;=0A- struct sock *sk =3D ax25->sk;=0A =0A- bh_lock_soc= k(sk);=0A switch (ax25->ax25_dev->values[AX25_VALUES_PROTOCOL]) {=0A case= AX25_PROTO_STD_SIMPLEX:=0A case AX25_PROTO_STD_DUPLEX:=0A@@ -255,5 +240,4= @@=0A break;=0A #endif=0A }=0A- bh_unlock_sock(sk);=0A }=0AOnly in linu= x-2.6.0-test3.rxq/net/ax25: ax25_timer.o=0AOnly in linux-2.6.0-test3.rxq/ne= t/ax25: ax25_uid.o=0AOnly in linux-2.6.0-test3.rxq/net/ax25: built-in.o=0Ad= iff -ru linux-2.6.0-test3/net/ax25/sysctl_net_ax25.c linux-2.6.0-test3.rxq/= net/ax25/sysctl_net_ax25.c=0A--- linux-2.6.0-test3/net/ax25/sysctl_net_ax25= .c 2003-08-09 06:41:21.000000000 +0200=0A+++ linux-2.6.0-test3.rxq/net/ax25= /sysctl_net_ax25.c 2003-08-12 23:40:35.000000000 +0200=0A@@ -12,20 +12,20 @= @=0A #include =0A #include =0A =0A-static int= min_ipdefmode[1], max_ipdefmode[] =3D {1};=0A-static int min_axdefmode= [1], max_axdefmode[] =3D {1};=0A-static int min_backoff[1], max= _backoff[] =3D {2};=0A-static int min_conmode[1], max_conmode[] =3D {2};= =0A+static int min_ipdefmode[] =3D {0}, max_ipdefmode[] =3D {1};=0A+static = int min_axdefmode[] =3D {0}, max_axdefmode[] =3D {1};=0A+static int min_bac= koff[] =3D {0}, max_backoff[] =3D {2};=0A+static int min_conmode[] =3D {0}= , max_conmode[] =3D {2};=0A static int min_window[] =3D {1}, max_window[]= =3D {7};=0A static int min_ewindow[] =3D {1}, max_ewindow[] =3D {63};=0A = static int min_t1[] =3D {1}, max_t1[] =3D {30 * HZ};=0A static int min_t2[= ] =3D {1}, max_t2[] =3D {20 * HZ};=0A-static int min_t3[1], max_t3[] = =3D {3600 * HZ};=0A-static int min_idle[1], max_idle[] =3D {65535 * HZ};= =0A+static int min_t3[] =3D {0}, max_t3[] =3D {3600 * HZ};=0A+static int m= in_idle[] =3D {0}, max_idle[] =3D {65535 * HZ};=0A static int min_n2[] =3D= {1}, max_n2[] =3D {31};=0A static int min_paclen[] =3D {1}, max_paclen[]= =3D {512};=0A-static int min_proto[1], max_proto[] =3D {3};=0A-static int= min_ds_timeout[1], max_ds_timeout[] =3D {65535 * HZ};=0A+static int min= _proto[] =3D {0}, max_proto[] =3D {3};=0A+static int min_ds_timeout[] =3D = {0}, max_ds_timeout[] =3D {65535 * HZ};=0A =0A static struct ctl_table_head= er *ax25_table_header;=0A =0A@@ -204,8 +204,10 @@=0A for (ax25_table_size = =3D sizeof(ctl_table), ax25_dev =3D ax25_dev_list; ax25_dev !=3D NULL; ax25= _dev =3D ax25_dev->next)=0A ax25_table_size +=3D sizeof(ctl_table);=0A = =0A- if ((ax25_table =3D kmalloc(ax25_table_size, GFP_ATOMIC)) =3D=3D NULL)= =0A+ if ((ax25_table =3D kmalloc(ax25_table_size, GFP_ATOMIC)) =3D=3D NULL)= {=0A+ spin_unlock_bh(&ax25_dev_lock);=0A return;=0A+ }=0A =0A memset(a= x25_table, 0x00, ax25_table_size);=0A =0AOnly in linux-2.6.0-test3.rxq/net/= ax25: sysctl_net_ax25.o=0AOnly in linux-2.6.0-test3.rxq/net/netrom: .af_net= rom.o.cmd=0AOnly in linux-2.6.0-test3.rxq/net/netrom: .built-in.o.cmd=0AOnl= y in linux-2.6.0-test3.rxq/net/netrom: .netrom.ko.cmd=0AOnly in linux-2.6.0= -test3.rxq/net/netrom: .netrom.mod.o.cmd=0AOnly in linux-2.6.0-test3.rxq/ne= t/netrom: .netrom.o.cmd=0AOnly in linux-2.6.0-test3.rxq/net/netrom: .nr_dev= .o.cmd=0AOnly in linux-2.6.0-test3.rxq/net/netrom: .nr_in.o.cmd=0AOnly in l= inux-2.6.0-test3.rxq/net/netrom: .nr_loopback.o.cmd=0AOnly in linux-2.6.0-t= est3.rxq/net/netrom: .nr_out.o.cmd=0AOnly in linux-2.6.0-test3.rxq/net/netr= om: .nr_route.o.cmd=0AOnly in linux-2.6.0-test3.rxq/net/netrom: .nr_subr.o.= cmd=0AOnly in linux-2.6.0-test3.rxq/net/netrom: .nr_timer.o.cmd=0AOnly in l= inux-2.6.0-test3.rxq/net/netrom: .sysctl_net_netrom.o.cmd=0Adiff -ru linux-= 2.6.0-test3/net/netrom/af_netrom.c linux-2.6.0-test3.rxq/net/netrom/af_netr= om.c=0A--- linux-2.6.0-test3/net/netrom/af_netrom.c 2003-08-09 06:36:46.000= 000000 +0200=0A+++ linux-2.6.0-test3.rxq/net/netrom/af_netrom.c 2003-08-12 = 23:40:35.000000000 +0200=0A@@ -147,8 +147,10 @@=0A spin_lock_bh(&nr_list_l= ock);=0A sk_for_each(s, node, &nr_list)=0A if (!ax25cmp(&nr_sk(s)->sourc= e_addr, addr) &&=0A- s->sk_state =3D=3D TCP_LISTEN)=0A+ s->sk_sta= te =3D=3D TCP_LISTEN) {=0A+ bh_lock_sock(s);=0A goto found;=0A+ }= =0A s =3D NULL;=0A found:=0A spin_unlock_bh(&nr_list_lock);=0A@@ -167,8 += 169,10 @@=0A sk_for_each(s, node, &nr_list) {=0A nr_cb *nr =3D nr_sk(s);= =0A =0A- if (nr->my_index =3D=3D index && nr->my_id =3D=3D id)=0A+ if (= nr->my_index =3D=3D index && nr->my_id =3D=3D id) {=0A+ bh_lock_sock(s);= =0A goto found;=0A+ }=0A }=0A s =3D NULL;=0A found:=0A@@ -190,8 +194,= 10 @@=0A nr_cb *nr =3D nr_sk(s);=0A =0A if (nr->your_index =3D=3D ind= ex && nr->your_id =3D=3D id &&=0A- !ax25cmp(&nr->dest_addr, dest))=0A+= !ax25cmp(&nr->dest_addr, dest)) {=0A+ bh_lock_sock(s);=0A go= to found;=0A+ }=0A }=0A s =3D NULL;=0A found:=0A@@ -206,14 +212,17 @@=0A= {=0A unsigned short id =3D circuit;=0A unsigned char i, j;=0A+ struct so= ck *sk;=0A =0A for (;;) {=0A i =3D id / 256;=0A j =3D id % 256;=0A =0A= - if (i !=3D 0 && j !=3D 0)=0A- if (nr_find_socket(i, j) =3D=3D NULL)=0A= + if (i !=3D 0 && j !=3D 0) {=0A+ if ((sk=3Dnr_find_socket(i, j)) =3D=3D= NULL)=0A break;=0A+ bh_unlock_sock(sk);=0A+ }=0A =0A id++;=0A }= =0A@@ -231,7 +240,12 @@=0A */=0A static void nr_destroy_timer(unsigned lon= g data)=0A {=0A- nr_destroy_socket((struct sock *)data);=0A+ struct sock *s= k=3D(struct sock *)data;=0A+ bh_lock_sock(sk);=0A+ sock_hold(sk);=0A+ nr_de= stroy_socket(sk);=0A+ bh_unlock_sock(sk);=0A+ sock_put(sk);=0A }=0A =0A /*= =0A@@ -264,17 +278,20 @@=0A =0A kfree_skb(skb);=0A }=0A+ while ((skb =3D= skb_dequeue(&sk->sk_write_queue)) !=3D NULL) {=0A+ kfree_skb(skb);=0A+ }= =0A =0A if (atomic_read(&sk->sk_wmem_alloc) ||=0A atomic_read(&sk->sk= _rmem_alloc)) {=0A /* Defer: outstanding buffers */=0A init_timer(&sk->= sk_timer);=0A- sk->sk_timer.expires =3D jiffies + 10 * HZ;=0A+ sk->sk_ti= mer.expires =3D jiffies + 2 * HZ;=0A sk->sk_timer.function =3D nr_destro= y_timer;=0A sk->sk_timer.data =3D (unsigned long)sk;=0A add_timer(&= sk->sk_timer);=0A } else=0A- sk_free(sk);=0A+ sock_put(sk);=0A }=0A =0A = /*=0A@@ -388,12 +405,15 @@=0A {=0A struct sock *sk =3D sock->sk;=0A =0A+ l= ock_sock(sk);=0A if (sk->sk_state !=3D TCP_LISTEN) {=0A memset(&nr_sk(sk= )->user_addr, 0, AX25_ADDR_LEN);=0A sk->sk_max_ack_backlog =3D backlog;= =0A sk->sk_state =3D TCP_LISTEN;=0A+ release_sock(sk);=0A re= turn 0;=0A }=0A+ release_sock(sk);=0A =0A return -EOPNOTSUPP;=0A }=0A@@ -= 495,6 +515,7 @@=0A =0A if (sk =3D=3D NULL) return 0;=0A =0A+ lock_sock(sk)= ;=0A nr =3D nr_sk(sk);=0A =0A switch (nr->state) {=0A@@ -528,6 +549,7 @@= =0A }=0A =0A sock->sk =3D NULL; =0A+ release_sock(sk);=0A =0A return 0= ;=0A }=0A@@ -540,21 +562,26 @@=0A struct net_device *dev;=0A ax25_address= *user, *source;=0A =0A- if (!sk->sk_zapped)=0A+ lock_sock(sk);=0A+ if (!sk= ->sk_zapped) {=0A+ release_sock(sk);=0A return -EINVAL;=0A-=0A- if (addr= _len < sizeof(struct sockaddr_ax25) || addr_len > sizeof(struct=0A-full_soc= kaddr_ax25))=0A+ }=0A+ if (addr_len < sizeof(struct sockaddr_ax25) || addr_= len > sizeof(struct full_sockaddr_ax25)) {=0A+ release_sock(sk);=0A retu= rn -EINVAL;=0A-=0A- if (addr_len < (addr->fsa_ax25.sax25_ndigis * sizeof(ax= 25_address) + sizeof(struct sockaddr_ax25)))=0A+ }=0A+ if (addr_len < (addr= ->fsa_ax25.sax25_ndigis * sizeof(ax25_address) + sizeof(struct sockaddr_ax2= 5))) {=0A+ release_sock(sk);=0A return -EINVAL;=0A-=0A- if (addr->fsa_ax= 25.sax25_family !=3D AF_NETROM)=0A+ }=0A+ if (addr->fsa_ax25.sax25_family != =3D AF_NETROM) {=0A+ release_sock(sk);=0A return -EINVAL;=0A-=0A+ }=0A = if ((dev =3D nr_dev_get(&addr->fsa_ax25.sax25_call)) =3D=3D NULL) {=0A SO= CK_DEBUG(sk, "NET/ROM: bind failed: invalid node callsign\n");=0A+ release= _sock(sk);=0A return -EADDRNOTAVAIL;=0A }=0A =0A@@ -562,16 +589,22 @@=0A= * Only the super user can set an arbitrary user callsign.=0A */=0A if= (addr->fsa_ax25.sax25_ndigis =3D=3D 1) {=0A- if (!capable(CAP_NET_BIND_SE= RVICE))=0A+ if (!capable(CAP_NET_BIND_SERVICE)) {=0A+ dev_put(dev);=0A+ = release_sock(sk);=0A return -EACCES;=0A+ }=0A nr->user_addr =3D a= ddr->fsa_digipeater[0];=0A nr->source_addr =3D addr->fsa_ax25.sax25_call;= =0A } else {=0A source =3D &addr->fsa_ax25.sax25_call;=0A =0A if ((use= r =3D ax25_findbyuid(current->euid)) =3D=3D NULL) {=0A- if (ax25_uid_poli= cy && !capable(CAP_NET_BIND_SERVICE))=0A+ if (ax25_uid_policy && !capable= (CAP_NET_BIND_SERVICE)) {=0A+ release_sock(sk);=0A+ dev_put(dev);=0A = return -EPERM;=0A+ }=0A user =3D source;=0A }=0A =0A@@ -583,6 +6= 16,8 @@=0A nr_insert_socket(sk);=0A =0A sk->sk_zapped =3D 0;=0A+ dev_put(= dev);=0A+ release_sock(sk);=0A SOCK_DEBUG(sk, "NET/ROM: socket is bound\n"= );=0A return 0;=0A }=0A@@ -596,39 +631,50 @@=0A ax25_address *user, *sour= ce =3D NULL;=0A struct net_device *dev;=0A =0A+ lock_sock(sk);=0A if (sk-= >sk_state =3D=3D TCP_ESTABLISHED && sock->state =3D=3D SS_CONNECTING) {=0A = sock->state =3D SS_CONNECTED;=0A+ release_sock(sk);=0A return 0; /* Co= nnect completed during a ERESTARTSYS event */=0A }=0A =0A if (sk->sk_stat= e =3D=3D TCP_CLOSE && sock->state =3D=3D SS_CONNECTING) {=0A sock->state = =3D SS_UNCONNECTED;=0A+ release_sock(sk);=0A return -ECONNREFUSED;=0A }= =0A =0A- if (sk->sk_state =3D=3D TCP_ESTABLISHED)=0A+ if (sk->sk_state =3D= =3D TCP_ESTABLISHED) {=0A+ release_sock(sk);=0A return -EISCONN; /* No r= econnect on a seqpacket socket */=0A+ }=0A =0A sk->sk_state =3D TCP_CLOS= E; =0A sock->state =3D SS_UNCONNECTED;=0A =0A- if (addr_len !=3D sizeof(st= ruct sockaddr_ax25) && addr_len !=3D sizeof(struct full_sockaddr_ax25))=0A+= if (addr_len !=3D sizeof(struct sockaddr_ax25) && addr_len !=3D sizeof(str= uct full_sockaddr_ax25)) {=0A+ release_sock(sk);=0A return -EINVAL;=0A-= =0A- if (addr->sax25_family !=3D AF_NETROM)=0A+ }=0A+ if (addr->sax25_famil= y !=3D AF_NETROM) {=0A+ release_sock(sk);=0A return -EINVAL;=0A-=0A+ }= =0A if (sk->sk_zapped) { /* Must bind first - autobinding in this may or m= ay not work */=0A sk->sk_zapped =3D 0;=0A =0A- if ((dev =3D nr_dev_first= ()) =3D=3D NULL)=0A+ if ((dev =3D nr_dev_first()) =3D=3D NULL) {=0A+ rel= ease_sock(sk);=0A return -ENETUNREACH;=0A-=0A+ }=0A source =3D (ax25_= address *)dev->dev_addr;=0A =0A if ((user =3D ax25_findbyuid(current->eui= d)) =3D=3D NULL) {=0A- if (ax25_uid_policy && !capable(CAP_NET_ADMIN))=0A= + if (ax25_uid_policy && !capable(CAP_NET_ADMIN)) {=0A+ dev_put(dev);= =0A+ release_sock(sk);=0A return -EPERM;=0A+ }=0A user =3D sour= ce;=0A }=0A =0A@@ -636,12 +682,15 @@=0A nr->source_addr =3D *source;=0A= nr->device =3D dev;=0A =0A+ dev_put(dev);=0A nr_insert_socket(sk= ); /* Finish the bind */=0A }=0A =0A nr->dest_addr =3D addr->sax25_call;= =0A =0A+ release_sock(sk);=0A circuit =3D nr_find_next_circuit();=0A+ lock= _sock(sk);=0A =0A nr->my_index =3D circuit / 256;=0A nr->my_id =3D cir= cuit % 256;=0A@@ -659,8 +708,10 @@=0A nr_start_heartbeat(sk);=0A =0A /* N= ow the loop */=0A- if (sk->sk_state !=3D TCP_ESTABLISHED && (flags & O_NONB= LOCK))=0A+ if (sk->sk_state !=3D TCP_ESTABLISHED && (flags & O_NONBLOCK)) {= =0A+ release_sock(sk);=0A return -EINPROGRESS;=0A+ }=0A =0A /*=0A *= A Connect Ack with Choke or timeout or failed routing will go to=0A@@ -675= ,8 +726,10 @@=0A set_current_state(TASK_INTERRUPTIBLE);=0A if (sk->sk= _state !=3D TCP_SYN_SENT)=0A break;=0A+ release_sock(sk);=0A if (!= signal_pending(tsk)) {=0A schedule();=0A+ lock_sock(sk);=0A cont= inue;=0A }=0A return -ERESTARTSYS;=0A@@ -687,10 +740,12 @@=0A =0A if= (sk->sk_state !=3D TCP_ESTABLISHED) {=0A sock->state =3D SS_UNCONNECTED;= =0A+ release_sock(sk);=0A return sock_error(sk); /* Always set at this p= oint */=0A }=0A =0A sock->state =3D SS_CONNECTED;=0A+ release_sock(sk);= =0A =0A return 0;=0A }=0A@@ -753,6 +808,7 @@=0A newsock->sk =3D newsk;=0A= =0A out:=0A+ release_sock(sk);=0A return err;=0A }=0A =0A@@ -763,9 +819,1= 2 @@=0A struct sock *sk =3D sock->sk;=0A nr_cb *nr =3D nr_sk(sk);=0A =0A+= lock_sock(sk);=0A if (peer !=3D 0) {=0A- if (sk->sk_state !=3D TCP_ESTAB= LISHED)=0A+ if (sk->sk_state !=3D TCP_ESTABLISHED) {=0A+ release_sock(sk= );=0A return -ENOTCONN;=0A+ }=0A sax->fsa_ax25.sax25_family =3D AF_NE= TROM;=0A sax->fsa_ax25.sax25_ndigis =3D 1;=0A sax->fsa_ax25.sax25_call = =3D nr->user_addr;=0A@@ -777,6 +836,7 @@=0A sax->fsa_ax25.sax25_call = =3D nr->source_addr;=0A *uaddr_len =3D sizeof(struct sockaddr_ax25);=0A = }=0A+ release_sock(sk);=0A =0A return 0;=0A }=0A@@ -790,6 +850,7 @@=0A un= signed short circuit_index, circuit_id;=0A unsigned short peer_circuit_ind= ex, peer_circuit_id;=0A unsigned short frametype, flags, window, timeout;= =0A+ int ret;=0A =0A skb->sk =3D NULL; /* Initially we don't know who it'= s for */=0A =0A@@ -847,7 +908,9 @@=0A else=0A nr_sk(sk)->bpqext =3D 0;= =0A =0A- return nr_process_rx_frame(sk, skb);=0A+ ret =3D nr_process_rx_f= rame(sk, skb);=0A+ bh_unlock_sock(sk);=0A+ return ret;=0A }=0A =0A /*= =0A@@ -877,6 +940,8 @@=0A if (!sk || sk->sk_ack_backlog =3D=3D sk->sk_max_= ack_backlog ||=0A (make =3D nr_make_new(sk)) =3D=3D NULL) {=0A nr_tr= ansmit_refusal(skb, 0);=0A+ if (sk)=0A+ bh_unlock_sock(sk);=0A return = 0;=0A }=0A =0A@@ -894,7 +959,9 @@=0A nr_make->your_index =3D circuit_ind= ex;=0A nr_make->your_id =3D circuit_id;=0A =0A+ bh_unlock_sock(sk);=0A= circuit =3D nr_find_next_circuit();=0A+ bh_lock_sock(sk);=0A =0A nr_make= ->my_index =3D circuit / 256;=0A nr_make->my_id =3D circuit % 256= ;=0A@@ -936,6 +1003,7 @@=0A if (!sock_flag(sk, SOCK_DEAD))=0A sk->sk_dat= a_ready(sk, skb->len);=0A =0A+ bh_unlock_sock(sk);=0A return 1;=0A }=0A = =0A@@ -954,28 +1022,42 @@=0A if (msg->msg_flags & ~(MSG_DONTWAIT|MSG_EOR))= =0A return -EINVAL;=0A =0A- if (sk->sk_zapped)=0A- return -EADDRNOTAVAIL= ;=0A+ lock_sock(sk);=0A+ if (sk->sk_zapped) {=0A+ err =3D -EADDRNOTAVAIL;= =0A+ goto out;=0A+ }=0A =0A if (sk->sk_shutdown & SEND_SHUTDOWN) {=0A s= end_sig(SIGPIPE, current, 0);=0A- return -EPIPE;=0A+ err =3D -EPIPE;=0A+ = goto out;=0A }=0A =0A- if (nr->device =3D=3D NULL)=0A- return -ENETUNREA= CH;=0A+ if (nr->device =3D=3D NULL) {=0A+ err =3D -ENETUNREACH;=0A+ goto = out;=0A+ }=0A =0A if (usax) {=0A- if (msg->msg_namelen < sizeof(sax))=0A-= return -EINVAL;=0A+ if (msg->msg_namelen < sizeof(sax)) {=0A+ err =3D= -EINVAL;=0A+ goto out;=0A+ }=0A sax =3D *usax;=0A- if (ax25cmp(&nr->= dest_addr, &sax.sax25_call) !=3D 0)=0A- return -EISCONN;=0A- if (sax.sax= 25_family !=3D AF_NETROM)=0A- return -EINVAL;=0A+ if (ax25cmp(&nr->dest_= addr, &sax.sax25_call) !=3D 0) {=0A+ err =3D -EISCONN;=0A+ goto out;=0A= + }=0A+ if (sax.sax25_family !=3D AF_NETROM) {=0A+ err =3D -EINVAL;=0A+= goto out;=0A+ }=0A } else {=0A- if (sk->sk_state !=3D TCP_ESTABLISHED= )=0A- return -ENOTCONN;=0A+ if (sk->sk_state !=3D TCP_ESTABLISHED) {=0A+= err =3D -ENOTCONN;=0A+ goto out;=0A+ }=0A sax.sax25_family =3D AF_N= ETROM;=0A sax.sax25_call =3D nr->dest_addr;=0A }=0A@@ -984,10 +1066,10= @@=0A =0A /* Build a packet */=0A SOCK_DEBUG(sk, "NET/ROM: sendto: build= ing packet.\n");=0A- size =3D len + AX25_BPQ_HEADER_LEN + AX25_MAX_HEADER_L= EN + NR_NETWORK_LEN + NR_TRANSPORT_LEN;=0A+ size =3D len + NR_NETWORK_LEN += NR_TRANSPORT_LEN;=0A =0A if ((skb =3D sock_alloc_send_skb(sk, size, msg->= msg_flags & MSG_DONTWAIT, &err)) =3D=3D NULL)=0A- return err;=0A+ goto ou= t;=0A =0A skb_reserve(skb, size - len);=0A =0A@@ -1022,12 +1104,16 @@=0A = =0A if (sk->sk_state !=3D TCP_ESTABLISHED) {=0A kfree_skb(skb);=0A- ret= urn -ENOTCONN;=0A+ err =3D -ENOTCONN;=0A+ goto out;=0A }=0A =0A nr_outp= ut(sk, skb); /* Shove it onto the queue */=0A =0A- return len;=0A+ err =3D = len;=0A+out:=0A+ release_sock(sk);=0A+ return err;=0A }=0A =0A static int n= r_recvmsg(struct kiocb *iocb, struct socket *sock,=0A@@ -1044,12 +1130,17 @= @=0A * us! We do one quick check first though=0A */=0A =0A- if (sk->sk_= state !=3D TCP_ESTABLISHED)=0A+ lock_sock(sk);=0A+ if (sk->sk_state !=3D TC= P_ESTABLISHED) {=0A+ release_sock(sk);=0A return -ENOTCONN;=0A+ }=0A =0A= /* Now we can treat all alike */=0A- if ((skb =3D skb_recv_datagram(sk, f= lags & ~MSG_DONTWAIT, flags & MSG_DONTWAIT, &er)) =3D=3D NULL)=0A+ if ((skb= =3D skb_recv_datagram(sk, flags & ~MSG_DONTWAIT, flags & MSG_DONTWAIT, &er= )) =3D=3D NULL) {=0A+ release_sock(sk);=0A return er;=0A+ }=0A =0A skb-= >h.raw =3D skb->data;=0A copied =3D skb->len;=0A@@ -1070,6 +1161,7 @@= =0A =0A skb_free_datagram(sk, skb);=0A =0A+ release_sock(sk);=0A return c= opied;=0A }=0A =0A@@ -1077,13 +1169,16 @@=0A static int nr_ioctl(struct soc= ket *sock, unsigned int cmd, unsigned long arg)=0A {=0A struct sock *sk = =3D sock->sk;=0A+ int ret;=0A =0A+ lock_sock(sk);=0A switch (cmd) {=0A ca= se TIOCOUTQ: {=0A long amount;=0A amount =3D sk->sk_sndbuf - atomic_rea= d(&sk->sk_wmem_alloc);=0A if (amount < 0)=0A amount =3D 0;=0A+ releas= e_sock(sk);=0A return put_user(amount, (int *)arg);=0A }=0A =0A@@ -1093,= 15 +1188,21 @@=0A /* These two are safe on a single CPU system as only us= er tasks fiddle here */=0A if ((skb =3D skb_peek(&sk->sk_receive_queue)) = !=3D NULL)=0A amount =3D skb->len;=0A+ release_sock(sk);=0A return pu= t_user(amount, (int *)arg);=0A }=0A =0A case SIOCGSTAMP:=0A if (sk !=3D= NULL) {=0A- if (!sk->sk_stamp.tv_sec)=0A+ if (!sk->sk_stamp.tv_sec) {= =0A+ release_sock(sk);=0A return -ENOENT;=0A- return copy_to_user(= (void *)arg, &sk->sk_stamp, sizeof(struct timeval)) ? -EFAULT : 0;=0A+ }= =0A+ ret =3D copy_to_user((void *)arg, &sk->sk_stamp, sizeof(struct timev= al)) ? -EFAULT : 0;=0A+ release_sock(sk);=0A+ return ret;=0A }=0A+ r= elease_sock(sk);=0A return -EINVAL;=0A =0A case SIOCGIFADDR:=0A@@ -1114,= 17 +1215,21 @@=0A case SIOCSIFNETMASK:=0A case SIOCGIFMETRIC:=0A case SI= OCSIFMETRIC:=0A+ release_sock(sk);=0A return -EINVAL;=0A =0A case SIOCA= DDRT:=0A case SIOCDELRT:=0A case SIOCNRDECOBS:=0A+ release_sock(sk);=0A = if (!capable(CAP_NET_ADMIN)) return -EPERM;=0A return nr_rt_ioctl(cmd, = (void *)arg);=0A =0A default:=0A+ release_sock(sk);=0A return dev_ioctl= (cmd, (void *)arg);=0A }=0A+ release_sock(sk);=0A =0A return 0;=0A }=0A@@= -1144,7 +1249,9 @@=0A len +=3D sprintf(buffer, "user_addr dest_node src_n= ode dev my your st vs vr va t1 t2 t4 idle n2 wn= d Snd-Q Rcv-Q inode\n");=0A =0A sk_for_each(s, node, &nr_list) {=0A- nr_c= b *nr =3D nr_sk(s);=0A+ nr_cb *nr;=0A+ bh_lock_sock(s);=0A+ nr =3D nr_sk= (s);=0A =0A if ((dev =3D nr->device) =3D=3D NULL)=0A devname =3D "???"= ;=0A@@ -1187,7 +1294,7 @@=0A len =3D 0;=0A begin =3D pos;=0A }=0A= -=0A+ bh_unlock_sock(s);=0A if (pos > offset + length)=0A break;=0A = }=0A@@ -1256,6 +1363,7 @@=0A =0A for (i =3D 0; i < nr_ndevs; i++) {=0A s= printf(dev_nr[i].name, "nr%d", i);=0A+ dev_nr[i].base_addr =3D i;=0A dev= _nr[i].init =3D nr_init;=0A register_netdev(&dev_nr[i]);=0A }=0A@@ -1300= ,23 +1408,23 @@=0A =0A nr_rt_free();=0A =0A- ax25_protocol_release(AX25_P_= NETROM);=0A+#ifdef CONFIG_SYSCTL=0A+ nr_unregister_sysctl();=0A+#endif=0A+= =0A ax25_linkfail_release(nr_link_failed);=0A+ ax25_protocol_release(AX25_= P_NETROM);=0A =0A unregister_netdevice_notifier(&nr_dev_notifier);=0A =0A-= #ifdef CONFIG_SYSCTL=0A- nr_unregister_sysctl();=0A-#endif=0A sock_unregis= ter(PF_NETROM);=0A =0A for (i =3D 0; i < nr_ndevs; i++) {=0A if (dev_nr[= i].priv !=3D NULL) {=0A+ unregister_netdev(&dev_nr[i]);=0A kfree(dev_n= r[i].priv);=0A dev_nr[i].priv =3D NULL;=0A- unregister_netdev(&dev_nr[= i]);=0A }=0A- kfree(dev_nr[i].name);=0A }=0A =0A kfree(dev_nr);=0AOnly= in linux-2.6.0-test3.rxq/net/netrom: af_netrom.o=0AOnly in linux-2.6.0-tes= t3.rxq/net/netrom: built-in.o=0AOnly in linux-2.6.0-test3.rxq/net/netrom: n= etrom.ko=0AOnly in linux-2.6.0-test3.rxq/net/netrom: netrom.mod.c=0AOnly in= linux-2.6.0-test3.rxq/net/netrom: netrom.mod.o=0AOnly in linux-2.6.0-test3= .rxq/net/netrom: netrom.o=0Adiff -ru linux-2.6.0-test3/net/netrom/nr_dev.c = linux-2.6.0-test3.rxq/net/netrom/nr_dev.c=0A--- linux-2.6.0-test3/net/netro= m/nr_dev.c 2003-08-09 06:41:27.000000000 +0200=0A+++ linux-2.6.0-test3.rxq/= net/netrom/nr_dev.c 2003-08-12 23:40:35.000000000 +0200=0A@@ -159,11 +159,1= 3 @@=0A {=0A struct sockaddr *sa =3D addr;=0A =0A- ax25_listen_release((ax= 25_address *)dev->dev_addr, NULL);=0A+ if (dev->flags & IFF_UP)=0A+ ax25_l= isten_release((ax25_address *)dev->dev_addr, NULL);=0A =0A memcpy(dev->dev= _addr, sa->sa_data, dev->addr_len);=0A =0A- ax25_listen_register((ax25_addr= ess *)dev->dev_addr, NULL);=0A+ if (dev->flags & IFF_UP)=0A+ ax25_listen_r= egister((ax25_address *)dev->dev_addr, NULL);=0A =0A return 0;=0A }=0A@@ -= 177,8 +179,8 @@=0A =0A static int nr_close(struct net_device *dev)=0A {=0A-= netif_stop_queue(dev);=0A ax25_listen_release((ax25_address *)dev->dev_ad= dr, NULL);=0A+ netif_stop_queue(dev);=0A return 0;=0A }=0A =0A@@ -197,16 += 199,16 @@=0A =0A int nr_init(struct net_device *dev)=0A {=0A- SET_MODULE_OW= NER(dev);=0A dev->mtu =3D NR_MAX_PACKET_SIZE;=0A dev->hard_start_xmit = =3D nr_xmit;=0A dev->open =3D nr_open;=0A dev->stop =3D nr_close;=0A = =0A dev->hard_header =3D nr_header;=0A- dev->hard_header_len =3D AX25_BPQ_= HEADER_LEN + AX25_MAX_HEADER_LEN + NR_NETWORK_LEN + NR_TRANSPORT_LEN;=0A+ d= ev->hard_header_len =3D NR_NETWORK_LEN + NR_TRANSPORT_LEN;=0A dev->addr_le= n =3D AX25_ADDR_LEN;=0A dev->type =3D ARPHRD_NETROM;=0A+ dev->tx_queue_l= en =3D 40;=0A dev->rebuild_header =3D nr_rebuild_header;=0A dev->set_mac_= address =3D nr_set_mac_address;=0A =0AOnly in linux-2.6.0-test3.rxq/net/= netrom: nr_dev.o=0Adiff -ru linux-2.6.0-test3/net/netrom/nr_in.c linux-2.6.= 0-test3.rxq/net/netrom/nr_in.c=0A--- linux-2.6.0-test3/net/netrom/nr_in.c 2= 003-08-09 06:34:46.000000000 +0200=0A+++ linux-2.6.0-test3.rxq/net/netrom/n= r_in.c 2003-08-12 23:40:35.000000000 +0200=0A@@ -74,6 +74,7 @@=0A static in= t nr_state1_machine(struct sock *sk, struct sk_buff *skb,=0A int frametype= )=0A {=0A+ bh_lock_sock(sk);=0A switch (frametype) {=0A case NR_CONNACK: = {=0A nr_cb *nr =3D nr_sk(sk);=0A@@ -102,6 +103,7 @@=0A default:=0A bre= ak;=0A }=0A+ bh_unlock_sock(sk);=0A =0A return 0;=0A }=0A@@ -114,6 +116,7= @@=0A static int nr_state2_machine(struct sock *sk, struct sk_buff *skb,= =0A int frametype)=0A {=0A+ bh_lock_sock(sk);=0A switch (frametype) {=0A = case NR_CONNACK | NR_CHOKE_FLAG:=0A nr_disconnect(sk, ECONNRESET);=0A@@ = -129,6 +132,7 @@=0A default:=0A break;=0A }=0A+ bh_unlock_sock(sk);=0A = =0A return 0;=0A }=0A@@ -150,6 +154,7 @@=0A nr =3D skb->data[18];=0A ns = =3D skb->data[17];=0A =0A+ bh_lock_sock(sk);=0A switch (frametype) {=0A c= ase NR_CONNREQ:=0A nr_write_internal(sk, NR_CONNACK);=0A@@ -260,6 +265,7 = @@=0A default:=0A break;=0A }=0A+ bh_unlock_sock(sk);=0A =0A return qu= eued;=0A }=0AOnly in linux-2.6.0-test3.rxq/net/netrom: nr_in.o=0AOnly in li= nux-2.6.0-test3.rxq/net/netrom: nr_loopback.o=0AOnly in linux-2.6.0-test3.r= xq/net/netrom: nr_out.o=0Adiff -ru linux-2.6.0-test3/net/netrom/nr_route.c = linux-2.6.0-test3.rxq/net/netrom/nr_route.c=0A--- linux-2.6.0-test3/net/net= rom/nr_route.c 2003-08-09 06:42:17.000000000 +0200=0A+++ linux-2.6.0-test3.= rxq/net/netrom/nr_route.c 2003-08-12 23:40:35.000000000 +0200=0A@@ -39,10 += 39,45 @@=0A =0A static unsigned int nr_neigh_no =3D 1;=0A =0A-static struct= nr_node *nr_node_list;=0A-static spinlock_t nr_node_lock;=0A-static struc= t nr_neigh *nr_neigh_list;=0A-static spinlock_t nr_neigh_lock;=0A+HLIST_HEA= D(nr_node_list);=0A+spinlock_t nr_node_list_lock =3D SPIN_LOCK_UNLOCKED;=0A= +HLIST_HEAD(nr_neigh_list);=0A+spinlock_t nr_neigh_list_lock =3D SPIN_LOCK_= UNLOCKED;=0A+=0A+struct nr_node *nr_node_get(ax25_address *callsign)=0A+{= =0A+ struct nr_node *found =3D NULL;=0A+ struct nr_node *nr_node;=0A+ struc= t hlist_node *node;=0A+=0A+ spin_lock_bh(&nr_node_list_lock);=0A+ nr_node_f= or_each(nr_node, node, &nr_node_list)=0A+ if (ax25cmp(callsign, &nr_node->= callsign) =3D=3D 0) {=0A+ nr_node_hold(nr_node);=0A+ found =3D nr_node;= =0A+ break;=0A+ }=0A+ spin_unlock_bh(&nr_node_list_lock);=0A+ return fou= nd;=0A+}=0A+=0A+struct nr_neigh *nr_neigh_get_dev(ax25_address *callsign, s= truct net_device *dev)=0A+{=0A+ struct nr_neigh *found =3D NULL;=0A+ struct= nr_neigh *nr_neigh;=0A+ struct hlist_node *node;=0A+=0A+ spin_lock_bh(&nr_= neigh_list_lock);=0A+ nr_neigh_for_each(nr_neigh, node, &nr_neigh_list)=0A+= if (ax25cmp(callsign, &nr_neigh->callsign) =3D=3D 0 &&=0A+ nr_neigh-= >dev =3D=3D dev) {=0A+ nr_neigh_hold(nr_neigh);=0A+ found =3D nr_neigh;= =0A+ break;=0A+ }=0A+ spin_unlock_bh(&nr_neigh_list_lock);=0A+ return fo= und;=0A+}=0A =0A static void nr_remove_neigh(struct nr_neigh *);=0A =0A@@ -= 57,17 +92,16 @@=0A struct nr_neigh *nr_neigh;=0A struct nr_route nr_route= ;=0A int i, found;=0A+ struct net_device *odev;=0A =0A- if (nr_dev_get(nr)= !=3D NULL) /* Can't add routes to ourself */=0A+ if ((odev=3Dnr_dev_get(nr= )) !=3D NULL) { /* Can't add routes to ourself */=0A+ dev_put(odev);=0A = return -EINVAL;=0A+ }=0A =0A- for (nr_node =3D nr_node_list; nr_node !=3D N= ULL; nr_node =3D nr_node->next)=0A- if (ax25cmp(nr, &nr_node->callsign) = =3D=3D 0)=0A- break;=0A+ nr_node =3D nr_node_get(nr);=0A =0A- for (nr_nei= gh =3D nr_neigh_list; nr_neigh !=3D NULL; nr_neigh =3D nr_neigh->next)=0A- = if (ax25cmp(ax25, &nr_neigh->callsign) =3D=3D 0 && nr_neigh->dev =3D=3D de= v)=0A- break;=0A+ nr_neigh =3D nr_neigh_get_dev(ax25, dev);=0A =0A /*=0A= * The L2 link to a neighbour has failed in the past=0A@@ -76,24 +110,36 = @@=0A * routes now (and not wait for a node broadcast).=0A */=0A if (n= r_neigh !=3D NULL && nr_neigh->failed !=3D 0 && quality =3D=3D 0) {=0A- st= ruct nr_node *node;=0A+ struct nr_node *nr_nodet;=0A+ struct hlist_node *= node;=0A =0A- for (node =3D nr_node_list; node !=3D NULL; node =3D node->n= ext)=0A- for (i =3D 0; i < node->count; i++)=0A- if (node->routes[i].n= eighbour =3D=3D nr_neigh)=0A- if (i < node->which)=0A- node->which= =3D i;=0A+ spin_lock_bh(&nr_node_list_lock);=0A+ nr_node_for_each(nr_nod= et, node, &nr_node_list) {=0A+ nr_node_lock(nr_nodet);=0A+ for (i =3D 0= ; i < nr_nodet->count; i++)=0A+ if (nr_nodet->routes[i].neighbour =3D=3D= nr_neigh)=0A+ if (i < nr_nodet->which)=0A+ nr_nodet->which =3D i;= =0A+ nr_node_unlock(nr_nodet);=0A+ }=0A+ spin_unlock_bh(&nr_node_list_l= ock);=0A }=0A =0A if (nr_neigh !=3D NULL)=0A nr_neigh->failed =3D 0;=0A= =0A- if (quality =3D=3D 0 && nr_neigh !=3D NULL && nr_node !=3D NULL)=0A+ = if (quality =3D=3D 0 && nr_neigh !=3D NULL && nr_node !=3D NULL) {=0A+ nr_= neigh_put(nr_neigh);=0A+ nr_node_put(nr_node);=0A return 0;=0A+ }=0A =0A= if (nr_neigh =3D=3D NULL) {=0A- if ((nr_neigh =3D kmalloc(sizeof(*nr_nei= gh), GFP_ATOMIC)) =3D=3D NULL)=0A+ if ((nr_neigh =3D kmalloc(sizeof(*nr_ne= igh), GFP_ATOMIC)) =3D=3D NULL) {=0A+ if (nr_node)=0A+ nr_node_put(nr_= node);=0A return -ENOMEM;=0A+ }=0A =0A nr_neigh->callsign =3D *ax25;= =0A nr_neigh->digipeat =3D NULL;=0A@@ -104,48 +150,58 @@=0A nr_neigh->c= ount =3D 0;=0A nr_neigh->number =3D nr_neigh_no++;=0A nr_neigh->fa= iled =3D 0;=0A+ atomic_set(&nr_neigh->refcount, 1);=0A =0A if (ax25_di= gi !=3D NULL && ax25_digi->ndigi > 0) {=0A if ((nr_neigh->digipeat =3D k= malloc(sizeof(*ax25_digi), GFP_KERNEL)) =3D=3D NULL) {=0A kfree(nr_neig= h);=0A+ if (nr_node)=0A+ nr_node_put(nr_node);=0A return -ENOMEM= ;=0A }=0A memcpy(nr_neigh->digipeat, ax25_digi,=0A sizeof(*ax25_= digi));=0A }=0A =0A- spin_lock_bh(&nr_neigh_lock);=0A- nr_neigh->next = =3D nr_neigh_list;=0A- nr_neigh_list =3D nr_neigh;=0A- spin_unlock_bh(&n= r_neigh_lock);=0A+ spin_lock_bh(&nr_neigh_list_lock);=0A+ hlist_add_head(= &nr_neigh->neigh_node, &nr_neigh_list);=0A+ nr_neigh_hold(nr_neigh);=0A+ = spin_unlock_bh(&nr_neigh_list_lock);=0A }=0A =0A if (quality !=3D 0 && ax= 25cmp(nr, ax25) =3D=3D 0 && !nr_neigh->locked)=0A nr_neigh->quality =3D q= uality;=0A =0A if (nr_node =3D=3D NULL) {=0A- if ((nr_node =3D kmalloc(si= zeof(*nr_node), GFP_ATOMIC)) =3D=3D NULL)=0A+ if ((nr_node =3D kmalloc(siz= eof(*nr_node), GFP_ATOMIC)) =3D=3D NULL) {=0A+ if (nr_neigh)=0A+ nr_ne= igh_put(nr_neigh);=0A return -ENOMEM;=0A+ }=0A =0A nr_node->callsign = =3D *nr;=0A strcpy(nr_node->mnemonic, mnemonic);=0A =0A nr_node->which = =3D 0;=0A nr_node->count =3D 1;=0A+ atomic_set(&nr_node->refcount, 1);= =0A+ nr_node->node_lock =3D SPIN_LOCK_UNLOCKED;=0A =0A nr_node->routes[0= ].quality =3D quality;=0A nr_node->routes[0].obs_count =3D obs_count;= =0A nr_node->routes[0].neighbour =3D nr_neigh;=0A =0A- spin_lock_bh(&nr_= node_lock);=0A- nr_node->next =3D nr_node_list;=0A- nr_node_list =3D nr_= node;=0A- spin_unlock_bh(&nr_node_lock);=0A-=0A+ nr_neigh_hold(nr_neigh);= =0A nr_neigh->count++;=0A =0A+ spin_lock_bh(&nr_node_list_lock);=0A+ hl= ist_add_head(&nr_node->node_node, &nr_node_list);=0A+ /* refcount initiali= zed at 1 */=0A+ spin_unlock_bh(&nr_node_list_lock);=0A+=0A return 0;=0A = }=0A+ nr_node_lock(nr_node);=0A =0A if (quality !=3D 0)=0A strcpy(nr_no= de->mnemonic, mnemonic);=0A@@ -171,11 +227,13 @@=0A =0A nr_node->which++= ;=0A nr_node->count++;=0A+ nr_neigh_hold(nr_neigh);=0A nr_neigh->co= unt++;=0A } else {=0A /* It must be better than the worst */=0A if = (quality > nr_node->routes[2].quality) {=0A nr_node->routes[2].neighbou= r->count--;=0A+ nr_neigh_put(nr_node->routes[2].neighbour);=0A =0A i= f (nr_node->routes[2].neighbour->count =3D=3D 0 && !nr_node->routes[2].neig= hbour->locked)=0A nr_remove_neigh(nr_node->routes[2].neighbour);=0A@@ = -184,6 +242,7 @@=0A nr_node->routes[2].obs_count =3D obs_count;=0A = nr_node->routes[2].neighbour =3D nr_neigh;=0A =0A+ nr_neigh_hold(nr_neig= h);=0A nr_neigh->count++;=0A }=0A }=0A@@ -244,62 +303,42 @@=0A }= =0A }=0A =0A+ nr_neigh_put(nr_neigh);=0A+ nr_node_unlock(nr_node);=0A+ nr_= node_put(nr_node);=0A return 0;=0A }=0A =0A-static void nr_remove_node(str= uct nr_node *nr_node)=0A+static inline void __nr_remove_node(struct nr_node= *nr_node)=0A {=0A- struct nr_node *s;=0A-=0A- spin_lock_bh(&nr_node_lock);= =0A- if ((s =3D nr_node_list) =3D=3D nr_node) {=0A- nr_node_list =3D nr_no= de->next;=0A- spin_unlock_bh(&nr_node_lock);=0A- kfree(nr_node);=0A- ret= urn;=0A- }=0A-=0A- while (s !=3D NULL && s->next !=3D NULL) {=0A- if (s->n= ext =3D=3D nr_node) {=0A- s->next =3D nr_node->next;=0A- spin_unlock_bh= (&nr_node_lock);=0A- kfree(nr_node);=0A- return;=0A- }=0A+ hlist_del_i= nit(&nr_node->node_node);=0A+ nr_node_put(nr_node);=0A+}=0A =0A- s =3D s->= next;=0A- }=0A+#define nr_remove_node_locked(__node) \=0A+ __nr_remove_node= (__node)=0A =0A- spin_unlock_bh(&nr_node_lock);=0A+static void nr_remove_no= de(struct nr_node *nr_node)=0A+{=0A+ spin_lock_bh(&nr_node_list_lock);=0A+ = __nr_remove_node(nr_node);=0A+ spin_unlock_bh(&nr_node_list_lock);=0A }=0A = =0A-static void nr_remove_neigh(struct nr_neigh *nr_neigh)=0A+static inline= void __nr_remove_neigh(struct nr_neigh *nr_neigh)=0A {=0A- struct nr_neigh= *s;=0A+ hlist_del_init(&nr_neigh->neigh_node);=0A+ nr_neigh_put(nr_neigh);= =0A+}=0A =0A- spin_lock_bh(&nr_neigh_lock);=0A- if ((s =3D nr_neigh_list) = =3D=3D nr_neigh) {=0A- nr_neigh_list =3D nr_neigh->next;=0A- spin_unlock_= bh(&nr_neigh_lock);=0A- if (nr_neigh->digipeat !=3D NULL)=0A- kfree(nr_n= eigh->digipeat);=0A- kfree(nr_neigh);=0A- return;=0A- }=0A+#define nr_rem= ove_neigh_locked(__neigh) \=0A+ __nr_remove_neigh(__neigh)=0A =0A- while (s= !=3D NULL && s->next !=3D NULL) {=0A- if (s->next =3D=3D nr_neigh) {=0A- = s->next =3D nr_neigh->next;=0A- spin_unlock_bh(&nr_neigh_lock);=0A- i= f (nr_neigh->digipeat !=3D NULL)=0A- kfree(nr_neigh->digipeat);=0A- kf= ree(nr_neigh);=0A- return;=0A- }=0A-=0A- s =3D s->next;=0A- }=0A- spin_= unlock_bh(&nr_neigh_lock);=0A+static void nr_remove_neigh(struct nr_neigh *= nr_neigh)=0A+{=0A+ spin_lock_bh(&nr_neigh_list_lock);=0A+ __nr_remove_neigh= (nr_neigh);=0A+ spin_unlock_bh(&nr_neigh_list_lock);=0A }=0A =0A /*=0A@@ -3= 12,26 +351,27 @@=0A struct nr_neigh *nr_neigh;=0A int i;=0A =0A- for (nr_= node =3D nr_node_list; nr_node !=3D NULL; nr_node =3D nr_node->next)=0A- i= f (ax25cmp(callsign, &nr_node->callsign) =3D=3D 0)=0A- break;=0A+ nr_node= =3D nr_node_get(callsign);=0A =0A if (nr_node =3D=3D NULL)=0A return -E= INVAL;=0A =0A- for (nr_neigh =3D nr_neigh_list; nr_neigh !=3D NULL; nr_neig= h =3D nr_neigh->next)=0A- if (ax25cmp(neighbour, &nr_neigh->callsign) =3D= =3D 0 && nr_neigh->dev =3D=3D dev)=0A- break;=0A+ nr_neigh =3D nr_neigh_g= et_dev(neighbour, dev);=0A =0A- if (nr_neigh =3D=3D NULL)=0A+ if (nr_neigh = =3D=3D NULL) {=0A+ nr_node_put(nr_node);=0A return -EINVAL;=0A+ }=0A =0A= + nr_node_lock(nr_node);=0A for (i =3D 0; i < nr_node->count; i++) {=0A = if (nr_node->routes[i].neighbour =3D=3D nr_neigh) {=0A nr_neigh->count--= ;=0A+ nr_neigh_put(nr_neigh);=0A =0A if (nr_neigh->count =3D=3D 0 && != nr_neigh->locked)=0A nr_remove_neigh(nr_neigh);=0A+ nr_neigh_put(nr_n= eigh);=0A =0A nr_node->count--;=0A =0A@@ -346,11 +386,16 @@=0A case = 2:=0A break;=0A }=0A+ nr_node_put(nr_node);=0A }=0A+ nr_no= de_unlock(nr_node);=0A =0A return 0;=0A }=0A }=0A+ nr_neigh_put(nr_ne= igh);=0A+ nr_node_unlock(nr_node);=0A+ nr_node_put(nr_node);=0A =0A return= -EINVAL;=0A }=0A@@ -362,12 +407,12 @@=0A {=0A struct nr_neigh *nr_neigh;= =0A =0A- for (nr_neigh =3D nr_neigh_list; nr_neigh !=3D NULL; nr_neigh =3D = nr_neigh->next) {=0A- if (ax25cmp(callsign, &nr_neigh->callsign) =3D=3D 0 = && nr_neigh->dev =3D=3D dev) {=0A- nr_neigh->quality =3D quality;=0A- n= r_neigh->locked =3D 1;=0A- return 0;=0A- }=0A+ nr_neigh =3D nr_neigh_ge= t_dev(callsign, dev);=0A+ if (nr_neigh) {=0A+ nr_neigh->quality =3D qualit= y;=0A+ nr_neigh->locked =3D 1;=0A+ nr_neigh_put(nr_neigh);=0A+ return 0= ;=0A }=0A =0A if ((nr_neigh =3D kmalloc(sizeof(*nr_neigh), GFP_ATOMIC)) = =3D=3D NULL)=0A@@ -382,6 +427,7 @@=0A nr_neigh->count =3D 0;=0A nr_nei= gh->number =3D nr_neigh_no++;=0A nr_neigh->failed =3D 0;=0A+ atomic_se= t(&nr_neigh->refcount, 1);=0A =0A if (ax25_digi !=3D NULL && ax25_digi->nd= igi > 0) {=0A if ((nr_neigh->digipeat =3D kmalloc(sizeof(*ax25_digi), GFP= _KERNEL)) =3D=3D NULL) {=0A@@ -391,10 +437,10 @@=0A memcpy(nr_neigh->digi= peat, ax25_digi, sizeof(*ax25_digi));=0A }=0A =0A- spin_lock_bh(&nr_neigh_= lock);=0A- nr_neigh->next =3D nr_neigh_list;=0A- nr_neigh_list =3D nr_neig= h;=0A- spin_unlock_bh(&nr_neigh_lock);=0A+ spin_lock_bh(&nr_neigh_list_lock= );=0A+ hlist_add_head(&nr_neigh->neigh_node, &nr_neigh_list);=0A+ /* refcou= nt is initialized at 1 */=0A+ spin_unlock_bh(&nr_neigh_list_lock);=0A =0A = return 0;=0A }=0A@@ -407,9 +453,7 @@=0A {=0A struct nr_neigh *nr_neigh;=0A= =0A- for (nr_neigh =3D nr_neigh_list; nr_neigh !=3D NULL; nr_neigh =3D nr_= neigh->next)=0A- if (ax25cmp(callsign, &nr_neigh->callsign) =3D=3D 0 && nr= _neigh->dev =3D=3D dev)=0A- break;=0A+ nr_neigh =3D nr_neigh_get_dev(call= sign, dev);=0A =0A if (nr_neigh =3D=3D NULL) return -EINVAL;=0A =0A@@ -418= ,6 +462,7 @@=0A =0A if (nr_neigh->count =3D=3D 0)=0A nr_remove_neigh(nr_= neigh);=0A+ nr_neigh_put(nr_neigh);=0A =0A return 0;=0A }=0A@@ -430,15 +47= 5,13 @@=0A static int nr_dec_obs(void)=0A {=0A struct nr_neigh *nr_neigh;= =0A- struct nr_node *s, *nr_node;=0A+ struct nr_node *s;=0A+ struct hlist= _node *node, *nodet;=0A int i;=0A =0A- nr_node =3D nr_node_list;=0A-=0A- w= hile (nr_node !=3D NULL) {=0A- s =3D nr_node;=0A- nr_node =3D nr_no= de->next;=0A-=0A+ spin_lock_bh(&nr_node_list_lock);=0A+ nr_node_for_each_sa= fe(s, node, nodet, &nr_node_list) {=0A+ nr_node_lock(s);=0A for (i =3D 0= ; i < s->count; i++) {=0A switch (s->routes[i].obs_count) {=0A case 0= : /* A locked entry */=0A@@ -448,6 +491,7 @@=0A nr_neigh =3D s->routes= [i].neighbour;=0A =0A nr_neigh->count--;=0A+ nr_neigh_put(nr_neigh);= =0A =0A if (nr_neigh->count =3D=3D 0 && !nr_neigh->locked)=0A nr_r= emove_neigh(nr_neigh);=0A@@ -472,8 +516,10 @@=0A }=0A =0A if (s->count = <=3D 0)=0A- nr_remove_node(s);=0A+ nr_remove_node_locked(s);=0A+ nr_no= de_unlock(s);=0A }=0A+ spin_unlock_bh(&nr_node_list_lock);=0A =0A return = 0;=0A }=0A@@ -483,21 +529,17 @@=0A */=0A void nr_rt_device_down(struct net= _device *dev)=0A {=0A- struct nr_neigh *s, *nr_neigh =3D nr_neigh_list;=0A-= struct nr_node *t, *nr_node;=0A+ struct nr_neigh *s;=0A+ struct hlist_nod= e *node, *nodet, *node2, *node2t;=0A+ struct nr_node *t;=0A int i;=0A =0A= - while (nr_neigh !=3D NULL) {=0A- s =3D nr_neigh;=0A- nr_neigh = =3D nr_neigh->next;=0A-=0A+ spin_lock_bh(&nr_neigh_list_lock);=0A+ nr_neigh= _for_each_safe(s, node, nodet, &nr_neigh_list) {=0A if (s->dev =3D=3D dev= ) {=0A- nr_node =3D nr_node_list;=0A-=0A- while (nr_node !=3D NULL) {= =0A- t =3D nr_node;=0A- nr_node =3D nr_node->next;=0A-=0A+ sp= in_lock_bh(&nr_node_list_lock);=0A+ nr_node_for_each_safe(t, node2, node2= t, &nr_node_list) {=0A+ nr_node_lock(t);=0A for (i =3D 0; i < t->cou= nt; i++) {=0A if (t->routes[i].neighbour =3D=3D s) {=0A t->count= --;=0A@@ -514,12 +556,15 @@=0A }=0A =0A if (t->count <=3D 0)=0A- = nr_remove_node(t);=0A+ nr_remove_node_locked(t);=0A+ nr_node_unloc= k(t);=0A }=0A+ spin_unlock_bh(&nr_node_list_lock);=0A =0A- nr_remove= _neigh(s);=0A+ nr_remove_neigh_locked(s);=0A }=0A }=0A+ spin_unlock_bh= (&nr_neigh_list_lock);=0A }=0A =0A /*=0A@@ -553,6 +598,8 @@=0A if (first= =3D=3D NULL || strncmp(dev->name, first->name, 3) < 0)=0A first =3D de= v;=0A }=0A+ if (first)=0A+ dev_hold(first);=0A read_unlock(&dev_base_loc= k);=0A =0A return first;=0A@@ -603,6 +650,7 @@=0A {=0A struct nr_route_st= ruct nr_route;=0A struct net_device *dev;=0A+ int ret;=0A =0A switch (cmd= ) {=0A case SIOCADDRT:=0A@@ -610,23 +658,29 @@=0A return -EFAULT;=0A = if ((dev =3D nr_ax25_dev_get(nr_route.device)) =3D=3D NULL)=0A return -E= INVAL;=0A- if (nr_route.ndigis < 0 || nr_route.ndigis > AX25_MAX_DIGIS)=0A= + if (nr_route.ndigis < 0 || nr_route.ndigis > AX25_MAX_DIGIS) {=0A+ dev= _put(dev);=0A return -EINVAL;=0A+ }=0A switch (nr_route.type) {=0A = case NETROM_NODE:=0A- return nr_add_node(&nr_route.callsign,=0A+ ret = =3D nr_add_node(&nr_route.callsign,=0A nr_route.mnemonic,=0A &nr_ro= ute.neighbour,=0A nr_call_to_digi(nr_route.ndigis, nr_route.digipeaters= ),=0A dev, nr_route.quality,=0A nr_route.obs_count);=0A+ break;= =0A case NETROM_NEIGH:=0A- return nr_add_neigh(&nr_route.callsign,=0A+ = ret =3D nr_add_neigh(&nr_route.callsign,=0A nr_call_to_digi(nr_route.= ndigis, nr_route.digipeaters),=0A dev, nr_route.quality);=0A+ break;= =0A default:=0A- return -EINVAL;=0A+ ret =3D -EINVAL;=0A }=0A+ dev= _put(dev);=0A+ return ret;=0A =0A case SIOCDELRT:=0A if (copy_from_user= (&nr_route, arg, sizeof(struct nr_route_struct)))=0A@@ -635,14 +689,18 @@= =0A return -EINVAL;=0A switch (nr_route.type) {=0A case NETROM_NODE:= =0A- return nr_del_node(&nr_route.callsign,=0A+ ret =3D nr_del_node(&nr= _route.callsign,=0A &nr_route.neighbour, dev);=0A+ break;=0A case N= ETROM_NEIGH:=0A- return nr_del_neigh(&nr_route.callsign,=0A+ ret =3D nr= _del_neigh(&nr_route.callsign,=0A dev, nr_route.quality);=0A+ break;= =0A default:=0A- return -EINVAL;=0A+ ret =3D -EINVAL;=0A }=0A+ dev= _put(dev);=0A+ return ret;=0A =0A case SIOCNRDECOBS:=0A return nr_dec_o= bs();=0A@@ -660,22 +718,36 @@=0A */=0A void nr_link_failed(ax25_cb *ax25, = int reason)=0A {=0A- struct nr_neigh *nr_neigh;=0A- struct nr_node *nr_nod= e;=0A-=0A- for (nr_neigh =3D nr_neigh_list; nr_neigh !=3D NULL; nr_neigh = =3D nr_neigh->next)=0A- if (nr_neigh->ax25 =3D=3D ax25)=0A+ struct nr_neig= h *s, *nr_neigh =3D NULL;=0A+ struct hlist_node *node;=0A+ struct nr_node = *nr_node =3D NULL;=0A+=0A+ spin_lock_bh(&nr_neigh_list_lock);=0A+ nr_neigh_= for_each(s, node, &nr_neigh_list)=0A+ if (s->ax25 =3D=3D ax25) {=0A+ nr_= neigh_hold(s);=0A+ nr_neigh =3D s;=0A break;=0A+ }=0A+ spin_unlock_bh= (&nr_neigh_list_lock);=0A =0A if (nr_neigh =3D=3D NULL) return;=0A =0A nr= _neigh->ax25 =3D NULL;=0A+ ax25_cb_put(ax25);=0A =0A- if (++nr_neigh->faile= d < sysctl_netrom_link_fails_count) return;=0A-=0A- for (nr_node =3D nr_nod= e_list; nr_node !=3D NULL; nr_node =3D nr_node->next)=0A+ if (++nr_neigh->f= ailed < sysctl_netrom_link_fails_count) {=0A+ nr_neigh_put(nr_neigh);=0A+ = return;=0A+ }=0A+ spin_lock_bh(&nr_node_list_lock);=0A+ nr_node_for_each(n= r_node, node, &nr_node_list)=0A+ nr_node_lock(nr_node);=0A if (nr_node->= which < nr_node->count && nr_node->routes[nr_node->which].neighbour =3D=3D = nr_neigh)=0A nr_node->which++;=0A+ nr_node_unlock(nr_node);=0A+ spin_un= lock_bh(&nr_node_list_lock);=0A+ nr_neigh_put(nr_neigh);=0A }=0A =0A /*=0A@= @ -689,6 +761,9 @@=0A struct nr_node *nr_node;=0A struct net_device *dev= ;=0A unsigned char *dptr;=0A+ ax25_cb *ax25s;=0A+ int ret;=0A+ struct sk_b= uff *skbn;=0A =0A =0A nr_src =3D (ax25_address *)(skb->data + 0);=0A@@ -7= 00,50 +775,84 @@=0A =0A if ((dev =3D nr_dev_get(nr_dest)) !=3D NULL) { /* = Its for me */=0A if (ax25 =3D=3D NULL) /* Its from me */=0A- return n= r_loopback_queue(skb);=0A+ ret =3D nr_loopback_queue(skb);=0A else=0A- = return nr_rx_frame(skb, dev);=0A+ ret =3D nr_rx_frame(skb, dev);=0A+ d= ev_put(dev);=0A+ return ret;=0A }=0A =0A if (!sysctl_netrom_routing_cont= rol && ax25 !=3D NULL)=0A return 0;=0A =0A /* Its Time-To-Live has expir= ed */=0A- if (--skb->data[14] =3D=3D 0)=0A+ if (skb->data[14] =3D=3D 1) {= =0A return 0;=0A+ }=0A =0A- for (nr_node =3D nr_node_list; nr_node !=3D N= ULL; nr_node =3D nr_node->next)=0A- if (ax25cmp(nr_dest, &nr_node->callsig= n) =3D=3D 0)=0A- break;=0A+ nr_node =3D nr_node_get(nr_dest);=0A+ if (nr_= node =3D=3D NULL)=0A+ return 0;=0A+ nr_node_lock(nr_node);=0A =0A- if (nr_= node =3D=3D NULL || nr_node->which >=3D nr_node->count)=0A+ if (nr_node->wh= ich >=3D nr_node->count) {=0A+ nr_node_unlock(nr_node);=0A+ nr_node_put(n= r_node);=0A return 0;=0A+ }=0A =0A nr_neigh =3D nr_node->routes[nr_node-= >which].neighbour;=0A =0A- if ((dev =3D nr_dev_first()) =3D=3D NULL)=0A+ if= ((dev =3D nr_dev_first()) =3D=3D NULL) {=0A+ nr_node_unlock(nr_node);=0A+= nr_node_put(nr_node);=0A+ return 0;=0A+ }=0A+=0A+ /* We are going to cha= nge the netrom headers so we should get our=0A+ own skb, we also did not= know until now how much header space=0A+ we had to reserve... - RXQ */= =0A+ if ((skbn=3Dskb_copy_expand(skb, dev->hard_header_len, 0, GFP_ATOMIC))= =3D=3D NULL) {=0A+ nr_node_unlock(nr_node);=0A+ nr_node_put(nr_node);=0A= + dev_put(dev);=0A return 0;=0A+ }=0A+ kfree_skb(skb);=0A+ skb=3Dskbn;= =0A+ skb->data[14]--;=0A =0A dptr =3D skb_push(skb, 1);=0A *dptr =3D AX2= 5_P_NETROM;=0A =0A- nr_neigh->ax25 =3D ax25_send_frame(skb, 256, (ax25_addr= ess *)dev->dev_addr, &nr_neigh->callsign, nr_neigh->digipeat, nr_neigh->dev= );=0A+ ax25s =3D ax25_send_frame(skb, 256, (ax25_address *)dev->dev_addr, &= nr_neigh->callsign, nr_neigh->digipeat, nr_neigh->dev);=0A+ if (nr_neigh->a= x25 && ax25s) {=0A+ /* We were already holding this ax25_cb */=0A+ ax25_c= b_put(ax25s);=0A+ }=0A+ nr_neigh->ax25 =3D ax25s;=0A =0A- return (nr_neigh-= >ax25 !=3D NULL);=0A+ dev_put(dev);=0A+ ret =3D (nr_neigh->ax25 !=3D NULL);= =0A+ nr_node_unlock(nr_node);=0A+ nr_node_put(nr_node);=0A+ return ret;=0A = }=0A =0A int nr_nodes_get_info(char *buffer, char **start, off_t offset, in= t length)=0A {=0A struct nr_node *nr_node;=0A+ struct hlist_node *node;=0A= int len =3D 0;=0A off_t pos =3D 0;=0A off_t begin =3D 0;=0A int = i;=0A =0A- spin_lock_bh(&nr_node_lock);=0A+ spin_lock_bh(&nr_node_list_lock= );=0A len +=3D sprintf(buffer, "callsign mnemonic w n qual obs neigh qual= obs neigh qual obs neigh\n");=0A =0A- for (nr_node =3D nr_node_list; nr_no= de !=3D NULL; nr_node =3D nr_node->next) {=0A+ nr_node_for_each(nr_node, no= de, &nr_node_list) {=0A+ nr_node_lock(nr_node);=0A len +=3D sprintf(buff= er + len, "%-9s %-7s %d %d",=0A ax2asc(&nr_node->callsign),=0A (nr_n= ode->mnemonic[0] =3D=3D '\0') ? "*" : nr_node->mnemonic,=0A@@ -756,6 +865,7= @@=0A nr_node->routes[i].obs_count,=0A nr_node->routes[i].neighbou= r->number);=0A }=0A+ nr_node_unlock(nr_node);=0A =0A len +=3D sprintf(= buffer + len, "\n");=0A =0A@@ -769,7 +879,7 @@=0A if (pos > offset + leng= th)=0A break;=0A }=0A- spin_unlock_bh(&nr_node_lock);=0A+ spin_unlock_b= h(&nr_node_list_lock);=0A =0A *start =3D buffer + (offset - begin);=0A le= n -=3D (offset - begin);=0A@@ -782,15 +892,16 @@=0A int nr_neigh_get_info= (char *buffer, char **start, off_t offset, int length)=0A {=0A struct nr_n= eigh *nr_neigh;=0A+ struct hlist_node *node;=0A int len =3D 0;=0A off= _t pos =3D 0;=0A off_t begin =3D 0;=0A int i;=0A =0A- spin_lock_bh(&nr_= neigh_lock);=0A+ spin_lock_bh(&nr_neigh_list_lock);=0A len +=3D sprintf(bu= ffer, "addr callsign dev qual lock count failed digipeaters\n");=0A =0A-= for (nr_neigh =3D nr_neigh_list; nr_neigh !=3D NULL; nr_neigh =3D nr_neigh= ->next) {=0A+ nr_neigh_for_each(nr_neigh, node, &nr_neigh_list) {=0A len = +=3D sprintf(buffer + len, "%05d %-9s %-4s %3d %d %3d %3d",=0A = nr_neigh->number,=0A ax2asc(&nr_neigh->callsign),=0A@@ -818,7 +929,7 @@= =0A break;=0A }=0A =0A- spin_unlock_bh(&nr_neigh_lock);=0A+ spin_unlock= _bh(&nr_neigh_list_lock);=0A =0A *start =3D buffer + (offset - begin);=0A = len -=3D (offset - begin);=0A@@ -833,20 +944,24 @@=0A */=0A void __exit= nr_rt_free(void)=0A {=0A- struct nr_neigh *s, *nr_neigh =3D nr_neigh_list;= =0A- struct nr_node *t, *nr_node =3D nr_node_list;=0A-=0A- while (nr_node= !=3D NULL) {=0A- t =3D nr_node;=0A- nr_node =3D nr_node->next;=0A-= =0A- nr_remove_node(t);=0A- }=0A-=0A- while (nr_neigh !=3D NULL) {=0A- s = =3D nr_neigh;=0A- nr_neigh =3D nr_neigh->next;=0A-=0A- nr_remove_n= eigh(s);=0A+ struct nr_neigh *s =3D NULL;=0A+ struct nr_node *t =3D NULL;= =0A+ struct hlist_node *node, *nodet;=0A+=0A+ spin_lock_bh(&nr_neigh_list_l= ock);=0A+ spin_lock_bh(&nr_node_list_lock);=0A+ nr_node_for_each_safe(t, no= de, nodet, &nr_node_list) {=0A+ nr_node_lock(t);=0A+ nr_remove_node_locke= d(t);=0A+ nr_node_unlock(t);=0A+ }=0A+ nr_neigh_for_each_safe(s, node, nod= et, &nr_neigh_list) {=0A+ while(s->count) {=0A+ s->count--;=0A+ nr_nei= gh_put(s);=0A+ }=0A+ nr_remove_neigh_locked(s);=0A }=0A+ spin_unlock_bh(= &nr_node_list_lock);=0A+ spin_unlock_bh(&nr_neigh_list_lock);=0A }=0AOnly i= n linux-2.6.0-test3.rxq/net/netrom: nr_route.o=0Adiff -ru linux-2.6.0-test3= /net/netrom/nr_subr.c linux-2.6.0-test3.rxq/net/netrom/nr_subr.c=0A--- linu= x-2.6.0-test3/net/netrom/nr_subr.c 2003-08-09 06:42:56.000000000 +0200=0A++= + linux-2.6.0-test3.rxq/net/netrom/nr_subr.c 2003-08-12 23:40:35.000000000 = +0200=0A@@ -127,7 +127,7 @@=0A unsigned char *dptr;=0A int len, timeout;= =0A =0A- len =3D AX25_BPQ_HEADER_LEN + AX25_MAX_HEADER_LEN + NR_NETWORK_LEN= + NR_TRANSPORT_LEN;=0A+ len =3D NR_NETWORK_LEN + NR_TRANSPORT_LEN;=0A =0A = switch (frametype & 0x0F) {=0A case NR_CONNREQ:=0A@@ -151,7 +151,7 @@=0A = /*=0A * Space for AX.25 and NET/ROM network header=0A */=0A- skb_reser= ve(skb, AX25_BPQ_HEADER_LEN + AX25_MAX_HEADER_LEN + NR_NETWORK_LEN);=0A+ sk= b_reserve(skb, NR_NETWORK_LEN);=0A =0A dptr =3D skb_put(skb, skb_tailroom(= skb));=0A =0A@@ -219,12 +219,12 @@=0A unsigned char *dptr;=0A int len;=0A= =0A- len =3D AX25_BPQ_HEADER_LEN + AX25_MAX_HEADER_LEN + NR_NETWORK_LEN + = NR_TRANSPORT_LEN + 1;=0A+ len =3D NR_NETWORK_LEN + NR_TRANSPORT_LEN + 1;=0A= =0A if ((skbn =3D alloc_skb(len, GFP_ATOMIC)) =3D=3D NULL)=0A return;= =0A =0A- skb_reserve(skbn, AX25_BPQ_HEADER_LEN + AX25_MAX_HEADER_LEN);=0A+ = skb_reserve(skbn, 0);=0A =0A dptr =3D skb_put(skbn, NR_NETWORK_LEN + NR_TR= ANSPORT_LEN);=0A =0AOnly in linux-2.6.0-test3.rxq/net/netrom: nr_subr.o=0Ad= iff -ru linux-2.6.0-test3/net/netrom/nr_timer.c linux-2.6.0-test3.rxq/net/n= etrom/nr_timer.c=0A--- linux-2.6.0-test3/net/netrom/nr_timer.c 2003-08-09 0= 6:38:56.000000000 +0200=0A+++ linux-2.6.0-test3.rxq/net/netrom/nr_timer.c 2= 003-08-12 23:40:35.000000000 +0200=0A@@ -143,7 +143,10 @@=0A is accept= ed() it isn't 'dead' so doesn't get removed. */=0A if (sock_flag(sk, SOCK= _DESTROY) ||=0A (sk->sk_state =3D=3D TCP_LISTEN && sock_flag(sk, SOCK= _DEAD))) {=0A+ sock_hold(sk);=0A nr_destroy_socket(sk);=0A+ bh_unloc= k_sock(sk);=0A+ sock_put(sk);=0A return;=0A }=0A break;=0A@@ -227,= 6 +230,7 @@=0A case NR_STATE_1:=0A if (nr->n2count =3D=3D nr->n2) {=0A = nr_disconnect(sk, ETIMEDOUT);=0A+ bh_unlock_sock(sk);=0A return;=0A = } else {=0A nr->n2count++;=0A@@ -237,6 +241,7 @@=0A case NR_STATE_2:= =0A if (nr->n2count =3D=3D nr->n2) {=0A nr_disconnect(sk, ETIMEDOUT);= =0A+ bh_unlock_sock(sk);=0A return;=0A } else {=0A nr->n2count++;= =0A@@ -247,6 +252,7 @@=0A case NR_STATE_3:=0A if (nr->n2count =3D=3D nr-= >n2) {=0A nr_disconnect(sk, ETIMEDOUT);=0A+ bh_unlock_sock(sk);=0A = return;=0A } else {=0A nr->n2count++;=0AOnly in linux-2.6.0-test3.rxq/= net/netrom: nr_timer.o=0Adiff -ru linux-2.6.0-test3/net/netrom/sysctl_net_n= etrom.c linux-2.6.0-test3.rxq/net/netrom/sysctl_net_netrom.c=0A--- linux-2.= 6.0-test3/net/netrom/sysctl_net_netrom.c 2003-08-09 06:33:21.000000000 +020= 0=0A+++ linux-2.6.0-test3.rxq/net/netrom/sysctl_net_netrom.c 2003-08-12 23:= 40:35.000000000 +0200=0A@@ -15,9 +15,9 @@=0A /*=0A * Values taken from NET= /ROM documentation.=0A */=0A-static int min_quality[1], max_quality[= ] =3D {255};=0A-static int min_obs[1], max_obs[] =3D {255};= =0A-static int min_ttl[1], max_ttl[] =3D {255};=0A+static int= min_quality[] =3D {0}, max_quality[] =3D {255};=0A+static int min_obs[] = =3D {0}, max_obs[] =3D {255};=0A+static int min_ttl[] =3D {0}, ma= x_ttl[] =3D {255};=0A static int min_t1[] =3D {5 * HZ};=0A static = int max_t1[] =3D {600 * HZ};=0A static int min_n2[] =3D {2}, max_= n2[] =3D {127};=0A@@ -28,7 +28,7 @@=0A static int min_window[] =3D {1= }, max_window[] =3D {127};=0A static int min_idle[] =3D {0 * HZ};=0A st= atic int max_idle[] =3D {65535 * HZ};=0A-static int min_route[1], = max_route[] =3D {1};=0A+static int min_route[] =3D {0}, max_route[] = =3D {1};=0A static int min_fails[] =3D {1}, max_fails[] =3D {10};=0A = =0A static struct ctl_table_header *nr_table_header;=0AOnly in linux-2.6.0-= test3.rxq/net/netrom: sysctl_net_netrom.o=0A--- linux-2.6.0-test3/include/n= et/ax25.h 2003-08-09 06:38:16.000000000 +0200=0A+++ linux-2.6.0-test3.rxq/i= nclude/net/ax25.h 2003-08-12 23:40:35.000000000 +0200=0A@@ -10,6 +10,7 @@= =0A #include =0A #include =0A #include =0A+#include =0A #include =0A =0A #d= efine AX25_T1CLAMPLO 1=0A@@ -180,7 +181,7 @@=0A } ax25_dev;=0A =0A typed= ef struct ax25_cb {=0A- struct ax25_cb *next;=0A+ struct hlist_node ax25_n= ode;=0A ax25_address source_addr, dest_addr;=0A ax25_digi *digipeat;=0A= ax25_dev *ax25_dev;=0A@@ -197,17 +198,32 @@=0A struct sk_buff_head ack_= queue;=0A struct sk_buff_head frag_queue;=0A unsigned char window;=0A- s= truct timer_list timer;=0A+ struct timer_list timer, dtimer;=0A struct soc= k *sk; /* Backlink to socket */=0A+ atomic_t refcount;=0A } ax25_cb;=0A = =0A #define ax25_sk(__sk) ((ax25_cb *)(__sk)->sk_protinfo)=0A =0A+#define a= x25_for_each(__ax25, node, list) \=0A+ hlist_for_each_entry(__ax25, node, l= ist, ax25_node)=0A+=0A+#define ax25_cb_hold(__ax25) \=0A+ atomic_inc(&((__a= x25)->refcount))=0A+=0A+static __inline__ void ax25_cb_put(ax25_cb *ax25)= =0A+{=0A+ if (atomic_dec_and_test(&ax25->refcount)) {=0A+ if (ax25->digipe= at)=0A+ kfree(ax25->digipeat);=0A+ kfree(ax25);=0A+ }=0A+}=0A+=0A /* af_= ax25.c */=0A-extern ax25_cb *ax25_list;=0A+extern struct hlist_head ax25_li= st;=0A extern spinlock_t ax25_list_lock;=0A-extern void ax25_free_cb(ax25_c= b *);=0A-extern void ax25_insert_socket(ax25_cb *);=0A+extern void ax25_cb_= add(ax25_cb *);=0A struct sock *ax25_find_listener(ax25_address *, int, str= uct net_device *, int);=0A struct sock *ax25_get_socket(ax25_address *, ax2= 5_address *, int);=0A extern ax25_cb *ax25_find_cb(ax25_address *, ax25_add= ress *, ax25_digi *, struct net_device *);=0A--- linux-2.6.0-test3/include/= net/netrom.h 2003-08-09 06:37:18.000000000 +0200=0A+++ linux-2.6.0-test3.rx= q/include/net/netrom.h 2003-08-12 23:40:35.000000000 +0200=0A@@ -7,6 +7,7 @= @=0A #ifndef _NETROM_H=0A #define _NETROM_H =0A #include = =0A+#include =0A =0A #define NR_NETWORK_LEN 15=0A #define N= R_TRANSPORT_LEN 5=0A@@ -77,16 +78,17 @@=0A #define nr_sk(__sk) ((nr_cb *)(= __sk)->sk_protinfo)=0A =0A struct nr_neigh {=0A- struct nr_neigh *next;=0A-= ax25_address callsign;=0A- ax25_digi *digipeat;=0A- ax25_cb *ax2= 5;=0A- struct net_device *dev;=0A- unsigned char quality;=0A- unsigned = char locked;=0A- unsigned short count;=0A- unsigned int number;=0A- u= nsigned char failed;=0A+ struct hlist_node neigh_node;=0A+ ax25_address ca= llsign;=0A+ ax25_digi *digipeat;=0A+ ax25_cb *ax25;=0A+ struct net_devic= e *dev;=0A+ unsigned char quality;=0A+ unsigned char locked;=0A+ unsigned= short count;=0A+ unsigned int number;=0A+ unsigned char failed;=0A+ ato= mic_t refcount;=0A };=0A =0A struct nr_route {=0A@@ -96,14 +98,74 @@=0A };= =0A =0A struct nr_node {=0A- struct nr_node *next;=0A- ax25_address cal= lsign;=0A- char mnemonic[7];=0A- unsigned char which;=0A- unsigned char = count;=0A- struct nr_route routes[3];=0A+ struct hlist_node node_node;=0A= + ax25_address callsign;=0A+ char mnemonic[7];=0A+ unsigned char which;= =0A+ unsigned char count;=0A+ struct nr_route routes[3];=0A+ atomic_t re= fcount;=0A+ spinlock_t node_lock;=0A };=0A =0A+/**************************= *******************************************=0A+ * nr_node & nr_neigh lists,= refcounting and locking=0A+ **********************************************= ***********************/=0A+=0A+extern struct hlist_head nr_node_list;=0A+e= xtern struct hlist_head nr_neigh_list;=0A+=0A+#define nr_node_hold(__nr_nod= e) \=0A+ atomic_inc(&((__nr_node)->refcount))=0A+=0A+static __inline__ void= nr_node_put(struct nr_node *nr_node)=0A+{=0A+ if (atomic_dec_and_test(&nr_= node->refcount)) {=0A+ kfree(nr_node);=0A+ }=0A+}=0A+=0A+#define nr_neigh_= hold(__nr_neigh) \=0A+ atomic_inc(&((__nr_neigh)->refcount))=0A+=0A+static = __inline__ void nr_neigh_put(struct nr_neigh *nr_neigh)=0A+{=0A+ if (atomic= _dec_and_test(&nr_neigh->refcount)) {=0A+ if (nr_neigh->digipeat !=3D NULL= )=0A+ kfree(nr_neigh->digipeat);=0A+ kfree(nr_neigh);=0A+ }=0A+}=0A+=0A+= /* nr_node_lock and nr_node_unlock also hold/put the node's refcounter.=0A+= */=0A+static __inline__ void nr_node_lock(struct nr_node *nr_node)=0A+{=0A= + nr_node_hold(nr_node);=0A+ spin_lock_bh(&nr_node->node_lock);=0A+}=0A+=0A= +static __inline__ void nr_node_unlock(struct nr_node *nr_node)=0A+{=0A+ sp= in_unlock_bh(&nr_node->node_lock);=0A+ nr_node_put(nr_node);=0A+}=0A+=0A+#d= efine nr_neigh_for_each(__nr_neigh, node, list) \=0A+ hlist_for_each_entry(= __nr_neigh, node, list, neigh_node)=0A+=0A+#define nr_neigh_for_each_safe(_= _nr_neigh, node, node2, list) \=0A+ hlist_for_each_entry_safe(__nr_neigh, n= ode, node2, list, neigh_node)=0A+=0A+#define nr_node_for_each(__nr_node, no= de, list) \=0A+ hlist_for_each_entry(__nr_node, node, list, node_node)=0A+= =0A+#define nr_node_for_each_safe(__nr_node, node, node2, list) \=0A+ hlist= _for_each_entry_safe(__nr_node, node, node2, list, node_node)=0A+=0A+=0A+/*= ********************************************************************/=0A+= =0A /* af_netrom.c */=0A extern int sysctl_netrom_default_path_quality;=0A= extern int sysctl_netrom_obsolescence_count_initialiser;=0A --+fexcqMh/evT6CrY-- From shemminger@osdl.org Tue Aug 12 16:50:05 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 16:50:09 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7CNo4Fl018927 for ; Tue, 12 Aug 2003 16:50:05 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7CNnmo16370; Tue, 12 Aug 2003 16:49:48 -0700 Date: Tue, 12 Aug 2003 16:49:40 -0700 From: Stephen Hemminger To: Jeroen Vreeken Cc: linux-hams@vger.kernel.org, ralf@linux-mips.org, davem@redhat.com, netdev@oss.sgi.com Subject: [PATCH] ax25 use dev_hold/dev_put as required for net_devices. Message-Id: <20030812164940.4b8ebcf9.shemminger@osdl.org> In-Reply-To: <20030813010301.K28977@jeroen.pe1rxq.ampr.org> References: <20030812194653.A28977@jeroen.pe1rxq.ampr.org> <20030812135655.7334887b.shemminger@osdl.org> <20030812230951.E28977@jeroen.pe1rxq.ampr.org> <20030812153901.6e700dcb.shemminger@osdl.org> <20030813010301.K28977@jeroen.pe1rxq.ampr.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4790 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Ax25 holds a reference to the net device below, in the ax25_dev structure; therefore it needs to use dev_hold/dev_put. This is against 2.6.0-test3 with your earlier patch diff -Nru a/net/ax25/ax25_dev.c b/net/ax25/ax25_dev.c --- a/net/ax25/ax25_dev.c Tue Aug 12 16:45:51 2003 +++ b/net/ax25/ax25_dev.c Tue Aug 12 16:45:51 2003 @@ -67,6 +67,7 @@ dev->ax25_ptr = ax25_dev; ax25_dev->dev = dev; + dev_hold(dev); ax25_dev->forward = NULL; ax25_dev->values[AX25_VALUES_IPDEFMODE] = AX25_DEF_IPDEFMODE; @@ -121,6 +122,7 @@ if ((s = ax25_dev_list) == ax25_dev) { ax25_dev_list = s->next; spin_unlock_bh(&ax25_dev_lock); + dev_put(dev); kfree(ax25_dev); ax25_register_sysctl(); return; @@ -131,6 +133,7 @@ s->next = ax25_dev->next; spin_unlock_bh(&ax25_dev_lock); kfree(ax25_dev); + dev_put(dev); ax25_register_sysctl(); return; } From shemminger@osdl.org Tue Aug 12 17:08:08 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 17:08:13 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7D087Fl019427 for ; Tue, 12 Aug 2003 17:08:08 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7D07no20038; Tue, 12 Aug 2003 17:07:51 -0700 Date: Tue, 12 Aug 2003 17:07:41 -0700 From: Stephen Hemminger To: Henner Eisen , "David S. Miller" Cc: linux-x25@vger.kernel.org, netdev@oss.sgi.com Subject: [PATCH] make lapbether work on 2.6.0-test3 Message-Id: <20030812170741.40608f59.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4791 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Lapbether needed work to get it up on 2.6.0-test3; the network device semantic changes caused several locking issues. Since lapb devices are created and removed in response to changes in underlying devices, the locking assumption changes caused the breakage. Changes: - unneeded include (no proc here) - redundant fields in local device structure + convert to dynamic network device allocation - refcounts on local data are redundant, it is really part of network_device - excessive __inline__ + correctly manage references to underlying network device + cascade unregister + use RCU and RTNL to avoid deadlock + account for bytes as well as packets Tested by exercising up/down/unregister state transitions on SMP. No change to underlying protocol was made. --- linux-2.5/drivers/net/wan/lapbether.c 2003-06-05 10:04:38.000000000 -0700 +++ linux-2.5-net/drivers/net/wan/lapbether.c 2003-08-12 16:56:37.452112904 -0700 @@ -37,7 +37,6 @@ #include #include #include -#include #include #include #include @@ -52,50 +51,27 @@ static char bcast_addr[6] = { 0xFF, 0xFF struct lapbethdev { struct list_head node; - char ethname[14]; /* ether device name */ struct net_device *ethdev; /* link to ethernet device */ - struct net_device axdev; /* lapbeth device (lapb#) */ + struct net_device *axdev; /* lapbeth device (lapb#) */ struct net_device_stats stats; /* some statistics */ - atomic_t refcnt; }; static struct list_head lapbeth_devices = LIST_HEAD_INIT(lapbeth_devices); -static rwlock_t lapbeth_devices_lock = RW_LOCK_UNLOCKED; -static __inline__ void lapbeth_hold(struct lapbethdev *lapbeth) -{ - atomic_inc(&lapbeth->refcnt); -} - -static __inline__ void lapbeth_put(struct lapbethdev *lapbeth) -{ - if (atomic_dec_and_test(&lapbeth->refcnt)) - kfree(lapbeth); -} /* ------------------------------------------------------------------------ */ /* * Get the LAPB device for the ethernet device */ -static __inline__ struct lapbethdev *lapbeth_get_x25_dev(struct net_device *dev) +static struct lapbethdev *lapbeth_get_x25_dev(struct net_device *dev) { - struct list_head *entry; - struct lapbethdev *lapbeth, *use = NULL; - - read_lock(&lapbeth_devices_lock); + struct lapbethdev *lapbeth; - list_for_each(entry, &lapbeth_devices) { - lapbeth = list_entry(entry, struct lapbethdev, node); - if (lapbeth->ethdev == dev) { - use = lapbeth; - break; - } + list_for_each_entry_rcu(lapbeth, &lapbeth_devices, node) { + if (lapbeth->ethdev == dev) + return lapbeth; } - if (use) - lapbeth_hold(use); - - read_unlock(&lapbeth_devices_lock); - return use; + return NULL; } static __inline__ int dev_is_ethdev(struct net_device *dev) @@ -103,36 +79,6 @@ static __inline__ int dev_is_ethdev(stru return dev->type == ARPHRD_ETHER && strncmp(dev->name, "dummy", 5); } -/* - * Sanity check: remove all devices that ceased to exists and - * return '1' if the given LAPB device was affected. - */ -static int lapbeth_check_devices(struct net_device *dev) -{ - struct lapbethdev *lapbeth; - struct list_head *entry, *tmp; - int result = 0; - - write_lock(&lapbeth_devices_lock); - - list_for_each_safe(entry, tmp, &lapbeth_devices) { - lapbeth = list_entry(entry, struct lapbethdev, node); - - if (!dev_get(lapbeth->ethname)) { - if (&lapbeth->axdev == dev) - result = 1; - - unregister_netdev(&lapbeth->axdev); - dev_put(lapbeth->ethdev); - list_del(&lapbeth->node); - lapbeth_put(lapbeth); - } - } - write_unlock(&lapbeth_devices_lock); - - return result; -} - /* ------------------------------------------------------------------------ */ /* @@ -145,29 +91,28 @@ static int lapbeth_rcv(struct sk_buff *s skb->sk = NULL; /* Initially we don't know who it's for */ + rcu_read_lock(); lapbeth = lapbeth_get_x25_dev(dev); - if (!lapbeth) goto drop; - if (!netif_running(&lapbeth->axdev)) - goto put_drop; + if (!netif_running(lapbeth->axdev)) + goto drop; lapbeth->stats.rx_packets++; len = skb->data[0] + skb->data[1] * 256; + lapbeth->stats.rx_bytes += len; skb_pull(skb, 2); /* Remove the length bytes */ skb_trim(skb, len); /* Set the length of the data */ if ((err = lapb_data_received(lapbeth, skb)) != LAPB_OK) { printk(KERN_DEBUG "lapbether: lapb_data_received err - %d\n", err); - goto put_drop; + goto drop; } - lapbeth_put(lapbeth); out: + rcu_read_unlock(); return 0; -put_drop: - lapbeth_put(lapbeth); drop: kfree_skb(skb); goto out; @@ -181,7 +126,7 @@ static int lapbeth_data_indication(void ptr = skb_push(skb, 1); *ptr = 0x00; - skb->dev = &lapbeth->axdev; + skb->dev = lapbeth->axdev; skb->protocol = htons(ETH_P_X25); skb->mac.raw = skb->data; skb->pkt_type = PACKET_HOST; @@ -203,7 +148,6 @@ static int lapbeth_xmit(struct sk_buff * * is down, the ethernet device may have gone. */ if (!netif_running(dev)) { - lapbeth_check_devices(dev); goto drop; } @@ -257,6 +201,7 @@ static void lapbeth_data_transmit(void * *ptr++ = size / 256; lapbeth->stats.tx_packets++; + lapbeth->stats.tx_bytes += size; skb->dev = dev = lapbeth->ethdev; @@ -279,7 +224,7 @@ static void lapbeth_connected(void *toke ptr = skb_put(skb, 1); *ptr = 0x01; - skb->dev = &lapbeth->axdev; + skb->dev = lapbeth->axdev; skb->protocol = htons(ETH_P_X25); skb->mac.raw = skb->data; skb->pkt_type = PACKET_HOST; @@ -302,7 +247,7 @@ static void lapbeth_disconnected(void *t ptr = skb_put(skb, 1); *ptr = 0x02; - skb->dev = &lapbeth->axdev; + skb->dev = lapbeth->axdev; skb->protocol = htons(ETH_P_X25); skb->mac.raw = skb->data; skb->pkt_type = PACKET_HOST; @@ -330,27 +275,26 @@ static int lapbeth_set_mac_address(struc return 0; } + +static struct lapb_register_struct lapbeth_callbacks = { + .connect_confirmation = lapbeth_connected, + .connect_indication = lapbeth_connected, + .disconnect_confirmation = lapbeth_disconnected, + .disconnect_indication = lapbeth_disconnected, + .data_indication = lapbeth_data_indication, + .data_transmit = lapbeth_data_transmit, + +}; + /* * open/close a device */ static int lapbeth_open(struct net_device *dev) { - struct lapb_register_struct lapbeth_callbacks; struct lapbethdev *lapbeth; int err; - if (lapbeth_check_devices(dev)) - return -ENODEV; /* oops, it's gone */ - lapbeth = (struct lapbethdev *)dev->priv; - - lapbeth_callbacks.connect_confirmation = lapbeth_connected; - lapbeth_callbacks.connect_indication = lapbeth_connected; - lapbeth_callbacks.disconnect_confirmation = lapbeth_disconnected; - lapbeth_callbacks.disconnect_indication = lapbeth_disconnected; - lapbeth_callbacks.data_indication = lapbeth_data_indication; - lapbeth_callbacks.data_transmit = lapbeth_data_transmit; - if ((err = lapb_register(lapbeth, &lapbeth_callbacks)) != LAPB_OK) { printk(KERN_ERR "lapbeth: lapb_register error - %d\n", err); return -ENODEV; @@ -375,65 +319,52 @@ static int lapbeth_close(struct net_devi /* ------------------------------------------------------------------------ */ +static void lapbeth_setup(struct net_device *dev) +{ + dev->hard_start_xmit = lapbeth_xmit; + dev->open = lapbeth_open; + dev->stop = lapbeth_close; + dev->destructor = (void (*)(struct net_device *))kfree; + dev->set_mac_address = lapbeth_set_mac_address; + dev->get_stats = lapbeth_get_stats; + dev->type = ARPHRD_X25; + dev->hard_header_len = 3; + dev->mtu = 1000; + dev->addr_len = 0; + SET_MODULE_OWNER(dev); +} + /* * Setup a new device. */ static int lapbeth_new_device(struct net_device *dev) { - unsigned char buf[14]; + struct net_device *ndev; struct lapbethdev *lapbeth; - int k, rc = -ENOMEM; + int rc = -ENOMEM; - if ((lapbeth = kmalloc(sizeof(struct lapbethdev), GFP_ATOMIC)) == NULL) + ASSERT_RTNL(); + + ndev = alloc_netdev(sizeof(*lapbeth), "lapb%d", + lapbeth_setup); + if (!ndev) goto out; - memset(lapbeth, 0, sizeof(struct lapbethdev)); + lapbeth = ndev->priv; + lapbeth->axdev = ndev; dev_hold(dev); lapbeth->ethdev = dev; - strncpy(lapbeth->ethname, dev->name, sizeof(lapbeth->ethname) - 1); - lapbeth->ethname[sizeof(lapbeth->ethname) - 1] = '\0'; - atomic_set(&lapbeth->refcnt, 1); - - dev = &lapbeth->axdev; - SET_MODULE_OWNER(dev); - - for (k = 0; k < MAXLAPBDEV; k++) { - struct net_device *odev; - - sprintf(buf, "lapb%d", k); - - if ((odev = __dev_get_by_name(buf)) == NULL || - lapbeth_check_devices(odev)) - break; - } - - rc = -ENODEV; - if (k == MAXLAPBDEV) + rc = dev_alloc_name(ndev, ndev->name); + if (rc < 0) goto fail; - dev->priv = (void *)lapbeth; /* pointer back */ - strcpy(dev->name, buf); - rc = -EIO; - if (register_netdev(dev)) + if (register_netdevice(ndev)) goto fail; - dev->hard_start_xmit = lapbeth_xmit; - dev->open = lapbeth_open; - dev->stop = lapbeth_close; - dev->set_mac_address = lapbeth_set_mac_address; - dev->get_stats = lapbeth_get_stats; - dev->type = ARPHRD_X25; - dev->hard_header_len = 3; - dev->mtu = 1000; - dev->addr_len = 0; - - write_lock(&lapbeth_devices_lock); - list_add(&lapbeth->node, &lapbeth_devices); - lapbeth_hold(lapbeth); - write_unlock(&lapbeth_devices_lock); + list_add_rcu(&lapbeth->node, &lapbeth_devices); rc = 0; out: return rc; @@ -444,6 +375,16 @@ fail: } /* + * Free a lapb network device. + */ +static void lapbeth_free_device(struct lapbethdev *lapbeth) +{ + dev_put(lapbeth->ethdev); + list_del_rcu(&lapbeth->node); + unregister_netdevice(lapbeth->axdev); +} + +/* * Handle device status changes. */ static int lapbeth_device_event(struct notifier_block *this, @@ -455,30 +396,27 @@ static int lapbeth_device_event(struct n if (!dev_is_ethdev(dev)) return NOTIFY_DONE; - lapbeth_check_devices(NULL); - + rcu_read_lock(); switch (event) { case NETDEV_UP: - /* - * New ethernet device -> new LAPB interface - */ - lapbeth = lapbeth_get_x25_dev(dev); - - if (lapbeth) - lapbeth_put(lapbeth); - else + /* New ethernet device -> new LAPB interface */ + if (lapbeth_get_x25_dev(dev) == NULL) lapbeth_new_device(dev); break; - case NETDEV_GOING_DOWN: - case NETDEV_DOWN: /* ethernet device closed -> close LAPB interface */ + case NETDEV_DOWN: + /* ethernet device closed -> close LAPB interface */ lapbeth = lapbeth_get_x25_dev(dev); - - if (lapbeth) { - dev_close(lapbeth->ethdev); - lapbeth_put(lapbeth); - } + if (lapbeth) + dev_close(lapbeth->axdev); + break; + case NETDEV_UNREGISTER: + /* ethernet device disappears -> remove LAPB interface */ + lapbeth = lapbeth_get_x25_dev(dev); + if (lapbeth) + lapbeth_free_device(lapbeth); break; } + rcu_read_unlock(); return NOTIFY_DONE; } @@ -506,15 +444,13 @@ static int __init lapbeth_init_driver(vo printk(banner); - read_lock_bh(&dev_base_lock); + rtnl_lock(); for (dev = dev_base; dev; dev = dev->next) { if (dev_is_ethdev(dev)) { - read_unlock_bh(&dev_base_lock); lapbeth_new_device(dev); - read_lock_bh(&dev_base_lock); } } - read_unlock_bh(&dev_base_lock); + rtnl_unlock(); return 0; } @@ -528,16 +464,13 @@ static void __exit lapbeth_cleanup_drive dev_remove_pack(&lapbeth_packet_type); unregister_netdevice_notifier(&lapbeth_dev_notifier); - write_lock(&lapbeth_devices_lock); - + rtnl_lock(); list_for_each_safe(entry, tmp, &lapbeth_devices) { lapbeth = list_entry(entry, struct lapbethdev, node); - unregister_netdev(&lapbeth->axdev); - list_del(&lapbeth->node); - lapbeth_put(lapbeth); - } - write_unlock(&lapbeth_devices_lock); + unregister_netdevice(lapbeth->axdev); + } + rtnl_unlock(); } module_exit(lapbeth_cleanup_driver); From shemminger@osdl.org Tue Aug 12 17:19:51 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 17:19:54 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7D0JnFl019822 for ; Tue, 12 Aug 2003 17:19:50 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7D0JYo23602; Tue, 12 Aug 2003 17:19:34 -0700 Date: Tue, 12 Aug 2003 17:19:26 -0700 From: Stephen Hemminger To: Jeroen Vreeken Cc: linux-hams@vger.kernel.org, ralf@linux-mips.org, davem@redhat.com, netdev@oss.sgi.com Subject: [PATCH] ax25 setsockopt(SO_BINDTODEVICE) bug fix Message-Id: <20030812171926.628186dc.shemminger@osdl.org> In-Reply-To: <20030813010301.K28977@jeroen.pe1rxq.ampr.org> References: <20030812194653.A28977@jeroen.pe1rxq.ampr.org> <20030812135655.7334887b.shemminger@osdl.org> <20030812230951.E28977@jeroen.pe1rxq.ampr.org> <20030812153901.6e700dcb.shemminger@osdl.org> <20030813010301.K28977@jeroen.pe1rxq.ampr.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4792 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Fix the error path (and indentation) in the SO_BINDTODEVICE setsockopt. As it was, a reference to the device was left hanging, and it would not check to see if the device was really an AX25 device. Found this with a simple test program on 2.6.0-test3 with your rqx4 patch. --- ax25/net/ax25/af_ax25.c 2003-08-12 17:08:42.025816088 -0700 +++ linux-2.5-net/net/ax25/af_ax25.c 2003-08-12 16:47:07.802057749 -0700 if (optlen > IFNAMSIZ) optlen=IFNAMSIZ; if (copy_from_user(devname, optval, optlen)) { - res = -EFAULT; + res = -EFAULT; break; } @@ -650,12 +650,14 @@ static int ax25_setsockopt(struct socket (sock->state != SS_UNCONNECTED || sk->sk_state == TCP_LISTEN)) { res = -EADDRNOTAVAIL; - dev_put(dev); - break; } - ax25->ax25_dev = ax25_dev_ax25dev(dev); - ax25_fillin_cb(ax25, ax25->ax25_dev); + else if ((ax25->ax25_dev = ax25_dev_ax25dev(dev)) == NULL) + res = -EINVAL; + else + ax25_fillin_cb(ax25, ax25->ax25_dev); + + dev_put(dev); break; default: From shemminger@osdl.org Tue Aug 12 17:22:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 17:22:22 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7D0MHFl020165 for ; Tue, 12 Aug 2003 17:22:18 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7D0Lxo24033; Tue, 12 Aug 2003 17:21:59 -0700 Date: Tue, 12 Aug 2003 17:21:51 -0700 From: Stephen Hemminger To: Jeroen Vreeken Cc: linux-hams@vger.kernel.org, ralf@linux-mips.org, davem@redhat.com, netdev@oss.sgi.com Subject: [PATCH] Convert ax25 to seq_file Message-Id: <20030812172151.7de0c950.shemminger@osdl.org> In-Reply-To: <20030813010301.K28977@jeroen.pe1rxq.ampr.org> References: <20030812194653.A28977@jeroen.pe1rxq.ampr.org> <20030812135655.7334887b.shemminger@osdl.org> <20030812230951.E28977@jeroen.pe1rxq.ampr.org> <20030812153901.6e700dcb.shemminger@osdl.org> <20030813010301.K28977@jeroen.pe1rxq.ampr.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4793 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Convert AX25 /proc interface over to using the seq_file library. This is avoids bugs, and also because there is an fops structure, correctly assigns the owner field so module refcounting works right. This is against 2.6.0-test3 with your rqx4 patch and my earlier bug fixes. diff -Nru a/include/net/ax25.h b/include/net/ax25.h --- a/include/net/ax25.h Tue Aug 12 17:16:52 2003 +++ b/include/net/ax25.h Tue Aug 12 17:16:52 2003 @@ -314,7 +314,7 @@ /* ax25_route.c */ extern void ax25_rt_device_down(struct net_device *); extern int ax25_rt_ioctl(unsigned int, void *); -extern int ax25_rt_get_info(char *, char **, off_t, int); +extern struct file_operations ax25_route_fops; extern int ax25_rt_autobind(ax25_cb *, ax25_address *); extern ax25_route *ax25_rt_find_route(ax25_route *, ax25_address *, struct net_device *); @@ -373,7 +373,7 @@ extern int ax25_uid_policy; extern ax25_address *ax25_findbyuid(uid_t); extern int ax25_uid_ioctl(int, struct sockaddr_ax25 *); -extern int ax25_uid_get_info(char *, char **, off_t, int); +extern struct file_operations ax25_uid_fops; extern void ax25_uid_free(void); /* sysctl_net_ax25.c */ diff -Nru a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c --- a/net/ax25/af_ax25.c Tue Aug 12 17:16:52 2003 +++ b/net/ax25/af_ax25.c Tue Aug 12 17:16:52 2003 @@ -1844,81 +1844,107 @@ return res; } -static int ax25_get_info(char *buffer, char **start, off_t offset, int length) +#ifdef CONFIG_PROC_FS + +static void *ax25_info_start(struct seq_file *seq, loff_t *pos) { - ax25_cb *ax25; - int k; - int len = 0; - off_t pos = 0; - off_t begin = 0; + struct ax25_cb *ax25; struct hlist_node *node; + int i = 0; spin_lock_bh(&ax25_list_lock); + ax25_for_each(ax25, node, &ax25_list) { + if (i == *pos) + return ax25; + ++i; + } + return NULL; +} + +static void *ax25_info_next(struct seq_file *seq, void *v, loff_t *pos) +{ + ++*pos; + + return hlist_entry( ((struct ax25_cb *)v)->ax25_node.next, + struct ax25_cb, ax25_node); +} + +static void ax25_info_stop(struct seq_file *seq, void *v) +{ + spin_unlock_bh(&ax25_list_lock); +} + +static int ax25_info_show(struct seq_file *seq, void *v) +{ + ax25_cb *ax25 = v; + int k; + /* * New format: * magic dev src_addr dest_addr,digi1,digi2,.. st vs vr va t1 t1 t2 t2 t3 t3 idle idle n2 n2 rtt window paclen Snd-Q Rcv-Q inode */ - ax25_for_each(ax25, node, &ax25_list) { - len += sprintf(buffer+len, "%8.8lx %s %s%s ", - (long) ax25, - ax25->ax25_dev == NULL? "???" : ax25->ax25_dev->dev->name, - ax2asc(&ax25->source_addr), - ax25->iamdigi? "*":""); - - len += sprintf(buffer+len, "%s", ax2asc(&ax25->dest_addr)); - - for (k=0; (ax25->digipeat != NULL) && (k < ax25->digipeat->ndigi); k++) { - len += sprintf(buffer+len, ",%s%s", - ax2asc(&ax25->digipeat->calls[k]), - ax25->digipeat->repeated[k]? "*":""); - } - - len += sprintf(buffer+len, " %d %d %d %d %lu %lu %lu %lu %lu %lu %lu %lu %d %d %lu %d %d", - ax25->state, - ax25->vs, ax25->vr, ax25->va, - ax25_display_timer(&ax25->t1timer) / HZ, ax25->t1 / HZ, - ax25_display_timer(&ax25->t2timer) / HZ, ax25->t2 / HZ, - ax25_display_timer(&ax25->t3timer) / HZ, ax25->t3 / HZ, - ax25_display_timer(&ax25->idletimer) / (60 * HZ), - ax25->idle / (60 * HZ), - ax25->n2count, ax25->n2, - ax25->rtt / HZ, - ax25->window, - ax25->paclen); - - if (ax25->sk != NULL) { - bh_lock_sock(ax25->sk); - len += sprintf(buffer + len, " %d %d %ld\n", - atomic_read(&ax25->sk->sk_wmem_alloc), - atomic_read(&ax25->sk->sk_rmem_alloc), - ax25->sk->sk_socket != NULL ? SOCK_INODE(ax25->sk->sk_socket)->i_ino : 0L); - bh_unlock_sock(ax25->sk); - } else { - len += sprintf(buffer + len, " * * *\n"); - } - - pos = begin + len; - - if (pos < offset) { - len = 0; - begin = pos; - } + seq_printf(seq, "%8.8lx %s %s%s ", + (long) ax25, + ax25->ax25_dev == NULL? "???" : ax25->ax25_dev->dev->name, + ax2asc(&ax25->source_addr), + ax25->iamdigi? "*":""); + seq_printf(seq, "%s", ax2asc(&ax25->dest_addr)); + + for (k=0; (ax25->digipeat != NULL) && (k < ax25->digipeat->ndigi); k++) { + seq_printf(seq, ",%s%s", + ax2asc(&ax25->digipeat->calls[k]), + ax25->digipeat->repeated[k]? "*":""); + } - if (pos > offset + length) - break; + seq_printf(seq, " %d %d %d %d %lu %lu %lu %lu %lu %lu %lu %lu %d %d %lu %d %d", + ax25->state, + ax25->vs, ax25->vr, ax25->va, + ax25_display_timer(&ax25->t1timer) / HZ, ax25->t1 / HZ, + ax25_display_timer(&ax25->t2timer) / HZ, ax25->t2 / HZ, + ax25_display_timer(&ax25->t3timer) / HZ, ax25->t3 / HZ, + ax25_display_timer(&ax25->idletimer) / (60 * HZ), + ax25->idle / (60 * HZ), + ax25->n2count, ax25->n2, + ax25->rtt / HZ, + ax25->window, + ax25->paclen); + + if (ax25->sk != NULL) { + bh_lock_sock(ax25->sk); + seq_printf(seq," %d %d %ld\n", + atomic_read(&ax25->sk->sk_wmem_alloc), + atomic_read(&ax25->sk->sk_rmem_alloc), + ax25->sk->sk_socket != NULL ? SOCK_INODE(ax25->sk->sk_socket)->i_ino : 0L); + bh_unlock_sock(ax25->sk); + } else { + seq_puts(seq, " * * *\n"); } + return 0; +} - spin_unlock_bh(&ax25_list_lock); +static struct seq_operations ax25_info_seqops = { + .start = ax25_info_start, + .next = ax25_info_next, + .stop = ax25_info_stop, + .show = ax25_info_show, +}; - *start = buffer + (offset - begin); - len -= (offset - begin); +static int ax25_info_open(struct inode *inode, struct file *file) +{ + return seq_open(file, &ax25_info_seqops); +} - if (len > length) len = length; +struct file_operations ax25_info_fops = { + .owner = THIS_MODULE, + .open = ax25_info_open, + .read = seq_read, + .llseek = seq_lseek, + .release = seq_release, +}; - return(len); -} +#endif static struct net_proto_family ax25_family_ops = { .family = PF_AX25, @@ -1988,9 +2014,9 @@ register_netdevice_notifier(&ax25_dev_notifier); ax25_register_sysctl(); - proc_net_create("ax25_route", 0, ax25_rt_get_info); - proc_net_create("ax25", 0, ax25_get_info); - proc_net_create("ax25_calls", 0, ax25_uid_get_info); + proc_net_fops_create("ax25_route", S_IRUGO, &ax25_route_fops); + proc_net_fops_create("ax25", S_IRUGO, &ax25_info_fops); + proc_net_fops_create("ax25_calls", S_IRUGO, &ax25_uid_fops); printk(banner); return 0; diff -Nru a/net/ax25/ax25_route.c b/net/ax25/ax25_route.c --- a/net/ax25/ax25_route.c Tue Aug 12 17:16:52 2003 +++ b/net/ax25/ax25_route.c Tue Aug 12 17:16:52 2003 @@ -34,6 +34,7 @@ #include #include #include +#include static ax25_route *ax25_route_list; static rwlock_t ax25_route_lock = RW_LOCK_UNLOCKED; @@ -278,66 +279,100 @@ } } -int ax25_rt_get_info(char *buffer, char **start, off_t offset, int length) -{ - ax25_route *ax25_rt; - int len = 0; - off_t pos = 0; - off_t begin = 0; - char *callsign; - int i; +#ifdef CONFIG_PROC_FS - read_lock(&ax25_route_lock); +#define AX25_PROC_START ((void *)1) - len += sprintf(buffer, "callsign dev mode digipeaters\n"); +static void *ax25_rt_seq_start(struct seq_file *seq, loff_t *pos) +{ + struct ax25_route *ax25_rt; + int i = 1; + + read_lock(&ax25_route_lock); + if (*pos == 0) + return AX25_PROC_START; for (ax25_rt = ax25_route_list; ax25_rt != NULL; ax25_rt = ax25_rt->next) { + if (i == *pos) + return ax25_rt; + ++i; + } + + return NULL; +} + +static void *ax25_rt_seq_next(struct seq_file *seq, void *v, loff_t *pos) +{ + ++*pos; + return (v == AX25_PROC_START) ? ax25_route_list : + ((struct ax25_route *) v)->next; +} + +static void ax25_rt_seq_stop(struct seq_file *seq, void *v) +{ + read_unlock(&ax25_route_lock); +} + +static int ax25_rt_seq_show(struct seq_file *seq, void *v) +{ + if (v == AX25_PROC_START) + seq_puts(seq, "callsign dev mode digipeaters\n"); + else { + struct ax25_route *ax25_rt = v; + const char *callsign; + int i; + if (ax25cmp(&ax25_rt->callsign, &null_ax25_address) == 0) callsign = "default"; else callsign = ax2asc(&ax25_rt->callsign); - len += sprintf(buffer + len, "%-9s %-4s", + + seq_printf(seq, "%-9s %-4s", callsign, ax25_rt->dev ? ax25_rt->dev->name : "???"); switch (ax25_rt->ip_mode) { case 'V': - len += sprintf(buffer + len, " vc"); + seq_puts(seq, " vc"); break; case 'D': - len += sprintf(buffer + len, " dg"); + seq_puts(seq, " dg"); break; default: - len += sprintf(buffer + len, " *"); + seq_puts(seq, " *"); break; } if (ax25_rt->digipeat != NULL) for (i = 0; i < ax25_rt->digipeat->ndigi; i++) - len += sprintf(buffer + len, " %s", ax2asc(&ax25_rt->digipeat->calls[i])); - - len += sprintf(buffer + len, "\n"); + seq_printf(seq, " %s", ax2asc(&ax25_rt->digipeat->calls[i])); - pos = begin + len; - - if (pos < offset) { - len = 0; - begin = pos; - } - - if (pos > offset + length) - break; + seq_puts(seq, "\n"); } - read_unlock(&ax25_route_lock); - - *start = buffer + (offset - begin); - len -= (offset - begin); + return 0; +} - if (len > length) - len = length; +static struct seq_operations ax25_rt_seqops = { + .start = ax25_rt_seq_start, + .next = ax25_rt_seq_next, + .stop = ax25_rt_seq_stop, + .show = ax25_rt_seq_show, +}; - return len; +static int ax25_rt_info_open(struct inode *inode, struct file *file) +{ + return seq_open(file, &ax25_rt_seqops); } + +struct file_operations ax25_route_fops = { + .owner = THIS_MODULE, + .open = ax25_rt_info_open, + .read = seq_read, + .llseek = seq_lseek, + .release = seq_release, +}; + +#endif /* * Find AX.25 route diff -Nru a/net/ax25/ax25_uid.c b/net/ax25/ax25_uid.c --- a/net/ax25/ax25_uid.c Tue Aug 12 17:16:52 2003 +++ b/net/ax25/ax25_uid.c Tue Aug 12 17:16:52 2003 @@ -30,6 +30,7 @@ #include #include #include +#include #include #include #include @@ -141,39 +142,73 @@ return -EINVAL; /*NOTREACHED */ } -int ax25_uid_get_info(char *buffer, char **start, off_t offset, int length) +#ifdef CONFIG_PROC_FS + +#define AX25_PROC_START ((void *)1) + +static void *ax25_uid_seq_start(struct seq_file *seq, loff_t *pos) { - ax25_uid_assoc *pt; - int len = 0; - off_t pos = 0; - off_t begin = 0; + struct ax25_uid_assoc *pt; + int i = 1; read_lock(&ax25_uid_lock); - len += sprintf(buffer, "Policy: %d\n", ax25_uid_policy); + if (*pos == 0) + return AX25_PROC_START; for (pt = ax25_uid_list; pt != NULL; pt = pt->next) { - len += sprintf(buffer + len, "%6d %s\n", pt->uid, ax2asc(&pt->call)); - - pos = begin + len; + if (i == *pos) + return pt; + ++i; + } + return NULL; +} - if (pos < offset) { - len = 0; - begin = pos; - } +static void *ax25_uid_seq_next(struct seq_file *seq, void *v, loff_t *pos) +{ + ++*pos; + return (v == AX25_PROC_START) ? ax25_uid_list : + ((struct ax25_uid_assoc *) v)->next; +} - if (pos > offset + length) - break; - } +static void ax25_uid_seq_stop(struct seq_file *seq, void *v) +{ read_unlock(&ax25_uid_lock); +} + +static int ax25_uid_seq_show(struct seq_file *seq, void *v) +{ + if (v == AX25_PROC_START) + seq_printf(seq, "Policy: %d\n", ax25_uid_policy); + else { + struct ax25_uid_assoc *pt = v; + - *start = buffer + (offset - begin); - len -= offset - begin; + seq_printf(seq, "%6d %s\n", pt->uid, ax2asc(&pt->call)); + } + return 0; +} - if (len > length) - len = length; +static struct seq_operations ax25_uid_seqops = { + .start = ax25_uid_seq_start, + .next = ax25_uid_seq_next, + .stop = ax25_uid_seq_stop, + .show = ax25_uid_seq_show, +}; - return len; +static int ax25_uid_info_open(struct inode *inode, struct file *file) +{ + return seq_open(file, &ax25_uid_seqops); } + +struct file_operations ax25_uid_fops = { + .owner = THIS_MODULE, + .open = ax25_uid_info_open, + .read = seq_read, + .llseek = seq_lseek, + .release = seq_release, +}; + +#endif /* * Free all memory associated with UID/Callsign structures. From mitch@sfgoth.com Tue Aug 12 18:02:43 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 18:02:47 -0700 (PDT) Received: from gaz.sfgoth.com ([63.205.85.133]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7D12hFl020826 for ; Tue, 12 Aug 2003 18:02:43 -0700 Received: from gaz.sfgoth.com (localhost.sfgoth.com [127.0.0.1]) by gaz.sfgoth.com (8.12.9/8.12.6) with ESMTP id h7D19IL7041928; Tue, 12 Aug 2003 18:09:18 -0700 (PDT) (envelope-from mitch@gaz.sfgoth.com) Received: (from mitch@localhost) by gaz.sfgoth.com (8.12.9/8.12.6/Submit) id h7D19Hdl041927; Tue, 12 Aug 2003 18:09:17 -0700 (PDT) (envelope-from mitch) Date: Tue, 12 Aug 2003 18:09:17 -0700 From: Mitchell Blank Jr To: Stephen Hemminger Cc: chas williams , netdev@oss.sgi.com Subject: Re: [RFT][PATCH] cleanup net/atm/br2684.c Message-ID: <20030813010917.GC36444@gaz.sfgoth.com> References: <20030811114823.5b81474c.shemminger@osdl.org> <20030811215857.GA96728@gaz.sfgoth.com> <20030811153039.6df304fb.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030811153039.6df304fb.shemminger@osdl.org> User-Agent: Mutt/1.4.1i X-archive-position: 4794 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mitch@sfgoth.com Precedence: bulk X-list: netdev Stephen Hemminger wrote: > > Mmmm.. I see this snippet in your diff in multiplce places and it looks > > wrong. Where does the "brdev" structure get freed now? > > > The brdev structure is contained inside the allocation of net_device, > this is how all the ether and other devices do it. OK, sorry... that should have been obvious. The reason I was confused is that almost always the net_dev is referenced as brdev->net_dev which makes look like brdev merely has a reference to net_dev. I think it would be cleaner to change the code to pass around "net_dev" instead of "brdev" references (and just get the brdev via net_dev->priv as needed) and just get rid of the brdev->net_dev pointer entirely. Are you interested in doing that? Otherwise I could take a crack at it when I get the chance (I've done some surgery on this file before) -Mitch From minniewkitty@yahoo.com.cn Tue Aug 12 18:38:01 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 12 Aug 2003 18:38:05 -0700 (PDT) Received: from web15204.mail.bjs.yahoo.com (web15204.mail.bjs.yahoo.com [202.3.77.134]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7D1bwFl021356 for ; Tue, 12 Aug 2003 18:38:00 -0700 Message-ID: <20030813013752.37510.qmail@web15204.mail.bjs.yahoo.com> Received: from [218.90.189.254] by web15204.mail.bjs.yahoo.com via HTTP; Wed, 13 Aug 2003 09:37:52 CST Date: Wed, 13 Aug 2003 09:37:52 +0800 (CST) From: =?gb2312?q?minnie=20wu?= Subject: How to improve small packet performance? To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1847026593-1060738672=:36840" Content-Transfer-Encoding: 8bit X-archive-position: 4795 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: minniewkitty@yahoo.com.cn Precedence: bulk X-list: netdev --0-1847026593-1060738672=:36840 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Hi, all! I tried e100-napi, but it's performance is still worse than eepro100-napi. It seems that napi cannot meet my needs. Any ideas? jchapman wrote: >Try the latest e100 development driver from sf.net/projects/e1000. Make >sure you compile it with NAPI enabled. >- jc minnie wu wrote: > Hi, all! > I'm working on e100/eepro100, kernel version 2.4.20. I used NAPI, >but the 64 byte small packet dual throughout is only 28M/s. How to >improve small packet performance further? --------------------------------- Do You Yahoo!? ÊîÆÚ´óƬÆë¾ÛÑÅ»¢Í¨ ÍøÂçÉãÏñÍ·+ÑÅ»¢Í¨µ÷ƵÊÕÒô»úµÈÄãÀ´Äà --0-1847026593-1060738672=:36840 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 8bit
Hi, all!
     I tried e100-napi, but it's performance is still worse than eepro100-napi. It seems that napi cannot meet my needs. Any ideas?
 
jchapman wrote:
 
>Try the latest e100 development driver from sf.net/projects/e1000. Make >sure you compile it with NAPI enabled.

>- jc

minnie wu wrote:

> Hi, all!
>      I'm working on e100/eepro100, kernel version 2.4.20. I used NAPI, >but  the 64 byte small packet dual throughout is only 28M/s. How to >improve small  packet performance further?

   
   


Do You Yahoo!?
ÊîÆÚ´óƬÆë¾ÛÑÅ»¢Í¨ ÍøÂçÉãÏñÍ·+ÑÅ»¢Í¨µ÷ƵÊÕÒô»úµÈÄãÀ´Äà --0-1847026593-1060738672=:36840-- From jamie@shareable.org Wed Aug 13 03:13:51 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 03:14:00 -0700 (PDT) Received: from mail.jlokier.co.uk (mail.jlokier.co.uk [81.29.64.88]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DADnFl032026 for ; Wed, 13 Aug 2003 03:13:50 -0700 Received: from mail.jlokier.co.uk (localhost [127.0.0.1]) by mail.jlokier.co.uk (8.12.8/8.12.8) with ESMTP id h7CETHqK019152; Tue, 12 Aug 2003 15:29:17 +0100 Received: (from jamie@localhost) by mail.jlokier.co.uk (8.12.8/8.12.8/Submit) id h7CETDn0019143; Tue, 12 Aug 2003 15:29:13 +0100 Date: Tue, 12 Aug 2003 15:29:13 +0100 From: Jamie Lokier To: "David S. Miller" Cc: Michael Bellion and Thomas Heinz , hadi@cyberus.ca, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [RFC] High Performance Packet Classifiction for tc framework Message-ID: <20030812142913.GB18802@mail.jlokier.co.uk> References: <200307141045.40999.nf@hipac.org> <1058328537.1797.24.camel@jzny.localdomain> <3F16A0E5.1080007@hipac.org> <1059934468.1103.41.camel@jzny.localdomain> <3F2E5CD6.4030500@hipac.org> <1060012260.1103.380.camel@jzny.localdomain> <3F302E04.1090503@hipac.org> <1060286331.1025.73.camel@jzny.localdomain> <3F381B3E.6080807@hipac.org> <20030811224050.59bc36fe.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030811224050.59bc36fe.davem@redhat.com> User-Agent: Mutt/1.4.1i X-archive-position: 4796 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jamie@shareable.org Precedence: bulk X-list: netdev David S. Miller wrote: > On Tue, 12 Aug 2003 00:39:58 +0200 > Michael Bellion and Thomas Heinz wrote: > > > This is a fundamental issue related to the use of hashes in this > > context. It shows that it is _impossible_ to create a hash which > > meets the requirement of O(1) rules per bucket in the setting > > described above regardless how clever you choose the hash function. > > > > What do you think about it? Do you agree? > > The ipv4 FIB hash tables tackle exactly this problem. The resulting > worse cast complexity is O(n_bits_in_prefix_mask). > > The problem you've described is exactly the same as trying to use > hashing for routing tables. You can do it in O(log(n_bits_in_prefix_mask)). This is achieved using binary search on the prefix lengths which appear in the table. (So if only a few prefix lengths are used, the tree is small). Illustrated by an example. The example assumes 32 bits total and every prefix length appears in the table. Each node in the search tree has one or more of these fields: - TABLE: Sparse (hash) or dense (direct) mapping of some subset of input bits to subtree nodes. - SHORTER: Subtree node, for matching shorter prefixes than the one which lead to the current node. - BEST: Best matching result given the prefix that lead to this node. This is either an exact match for that prefix, or the best shorter-prefix match for it. (On the root node, this will be the default value). In the worst case of N bits in the prefix, and every prefix length is actually used, there would by N tree nodes, however the depth of the search tree is ceil(log2(N)). This is the lookup algorithm: - Start with the root tree node. Note that this isn't the shortest prefix matcher. It will match the "middle" prefix length, given your set of lengths. E.g. on a 32-bit address, with rules of all prefix lenghts, the root tree node would match 16 bits. LOOP: - If NODE->TABLE exists, lookup the appropriate subset of input bits in it. For sparse tables, this involves a hash lookup. If a match is found, select that as the new tree node and goto LOOP. - Otherwise there is no table or no match in the table. - If NODE->SHORTER exists, select that as the new tree node and goto LOOP. - Otherwise, return NODE->BEST. This generalises to multiple dimensions e.g. for doing multiple prefixes on source+target + different combinations of other bits such as protocol, TOS etc. - i.e. arbitrary bit-subset classifiers. The basic principle and the algorithm are the same. In some cases it is worth reducing the tree size a little, e.g. if prefix lengths P and P+1 appear, you may as well just hash on P+1 bits and insert all the P prefix matches into the P+1 table, instead of having a P table. The cost is up to twice the number of entries in the P+1 table (depending on how dense your set of P+1 rules is), but this may be better than the cost of a extra hash lookup. Naturally, there are other optimisations too. -- Jamie From davem@redhat.com Wed Aug 13 03:17:05 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 03:17:09 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DAH4Fl032348 for ; Wed, 13 Aug 2003 03:17:04 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id DAA16880; Wed, 13 Aug 2003 03:10:38 -0700 Date: Wed, 13 Aug 2003 03:10:38 -0700 From: "David S. Miller" To: Jeroen Vreeken Cc: shemminger@osdl.org, pe1rxq@amsat.org, linux-hams@vger.kernel.org, ralf@linux-mips.org, netdev@oss.sgi.com Subject: Re: [PATCH] ax25 & netrom fixes for 2.6 Message-Id: <20030813031038.2c2afc6d.davem@redhat.com> In-Reply-To: <20030812230951.E28977@jeroen.pe1rxq.ampr.org> References: <20030812194653.A28977@jeroen.pe1rxq.ampr.org> <20030812135655.7334887b.shemminger@osdl.org> <20030812230951.E28977@jeroen.pe1rxq.ampr.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4797 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 12 Aug 2003 23:09:51 +0200 Jeroen Vreeken wrote: > Since at the moment the only zero-copy path I can imagine is from packets > over a bpq ethernet device wouldn't it be the easiest to just check at > ax25_rcv() for non-linear packets and call skb_linearize() for them? skb_linearize() is a deprecated interface, no new pieces of code should use it. If you want to mark the protocol as a new one you must do the non-linear handling properly just like every other protocol. Please, if you're going to be working in this area, fix this up properly and don't paper around the problems Stephen is showing to you. From davem@redhat.com Wed Aug 13 03:18:23 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 03:18:26 -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 h7DAINFl032664 for ; Wed, 13 Aug 2003 03:18:23 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id DAA16896; Wed, 13 Aug 2003 03:12:00 -0700 Date: Wed, 13 Aug 2003 03:11:59 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: pe1rxq@amsat.org, linux-hams@vger.kernel.org, ralf@linux-mips.org, netdev@oss.sgi.com Subject: Re: [PATCH] Convert ax25 to seq_file Message-Id: <20030813031159.6c6c9629.davem@redhat.com> In-Reply-To: <20030812172151.7de0c950.shemminger@osdl.org> References: <20030812194653.A28977@jeroen.pe1rxq.ampr.org> <20030812135655.7334887b.shemminger@osdl.org> <20030812230951.E28977@jeroen.pe1rxq.ampr.org> <20030812153901.6e700dcb.shemminger@osdl.org> <20030813010301.K28977@jeroen.pe1rxq.ampr.org> <20030812172151.7de0c950.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4798 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 12 Aug 2003 17:21:51 -0700 Stephen Hemminger wrote: > This is against 2.6.0-test3 with your rqx4 patch and my earlier > bug fixes. I have a bazillion different ax.25 patches in my inbox now, some should be applied and others not, and this is hard to determine with all the activity. Can someone send me a coherent set of patches to apply once all the issues have been worked out? Thanks. From davem@redhat.com Wed Aug 13 03:43:32 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 03:43:38 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DAhVFl000724 for ; Wed, 13 Aug 2003 03:43:31 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id DAA17066; Wed, 13 Aug 2003 03:37:38 -0700 Date: Wed, 13 Aug 2003 03:37:38 -0700 From: "David S. Miller" To: Steffen Klassert Cc: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] fix a kfree(skb) in net/bridge/br_stp_bpdu.c Message-Id: <20030813033738.28bc419d.davem@redhat.com> In-Reply-To: <20030812123126.GD24073@gareth.mathematik.tu-chemnitz.de> References: <20030812123126.GD24073@gareth.mathematik.tu-chemnitz.de> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4799 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 12 Aug 2003 14:31:26 +0200 Steffen Klassert wrote: > This patch against 2.6.0-test3 fix an occurence of kfree(skb) > in net/bridge/br_stp_bpdu.c Patch applied, thanks. From davem@redhat.com Wed Aug 13 04:02:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 04:02: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 h7DB2aFl001776 for ; Wed, 13 Aug 2003 04:02:37 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id DAA17209; Wed, 13 Aug 2003 03:56:39 -0700 Date: Wed, 13 Aug 2003 03:56:38 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: shemminger@osdl.org, jreuter@yaina.de, linux-hams@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] bpqether add rcu_read_lock Message-Id: <20030813035638.3486f244.davem@redhat.com> In-Reply-To: <20030812153312.0e762cf3.shemminger@osdl.org> References: <20030811162205.78b2029f.shemminger@osdl.org> <20030812153312.0e762cf3.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4800 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 12 Aug 2003 15:33:12 -0700 Stephen Hemminger wrote: > Fix one comment and add rcu_read_lock/rcu_read_unlock in the net_device_notifier. > Preemption is almost certainly already disabled there, but be safe. Patch applied, thanks Stephen. From davem@redhat.com Wed Aug 13 04:03:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 04:04:00 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DB3rFl002057 for ; Wed, 13 Aug 2003 04:03:53 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id DAA17239; Wed, 13 Aug 2003 03:57:59 -0700 Date: Wed, 13 Aug 2003 03:57:59 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: eis@baty.hanse.de, linux-x25@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] make lapbether work on 2.6.0-test3 Message-Id: <20030813035759.66dc9bf6.davem@redhat.com> In-Reply-To: <20030812170741.40608f59.shemminger@osdl.org> References: <20030812170741.40608f59.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4801 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 12 Aug 2003 17:07:41 -0700 Stephen Hemminger wrote: > Lapbether needed work to get it up on 2.6.0-test3; Applied, thanks Stephen. From davem@redhat.com Wed Aug 13 08:48:51 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 08:48: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 h7DFmoFl009138 for ; Wed, 13 Aug 2003 08:48:51 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id IAA18328; Wed, 13 Aug 2003 08:42:52 -0700 Date: Wed, 13 Aug 2003 08:42:52 -0700 From: "David S. Miller" To: Jeroen Vreeken Cc: shemminger@osdl.org, linux-hams@vger.kernel.org, ralf@linux-mips.org, netdev@oss.sgi.com Subject: Re: [PATCH] Convert ax25 to seq_file Message-Id: <20030813084252.7b667fb8.davem@redhat.com> In-Reply-To: <20030813173446.A2604@jeroen.pe1rxq.ampr.org> References: <20030812194653.A28977@jeroen.pe1rxq.ampr.org> <20030812135655.7334887b.shemminger@osdl.org> <20030812230951.E28977@jeroen.pe1rxq.ampr.org> <20030812153901.6e700dcb.shemminger@osdl.org> <20030813010301.K28977@jeroen.pe1rxq.ampr.org> <20030812172151.7de0c950.shemminger@osdl.org> <20030813031159.6c6c9629.davem@redhat.com> <20030813173446.A2604@jeroen.pe1rxq.ampr.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4802 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 13 Aug 2003 17:34:46 +0200 Jeroen Vreeken wrote: > This is my last patch (rxq4) plus Stephen's last three (dev locking, > setsockopt, seq_file) Please don't combine the patches, I want the each individual patch with the author and his comments for that change. If you combine all the work, this information gets lost. Also, please use something more intelligent to generate these diffs, so that I don't have to sift through all of the lines like "Only in ...". Thanks. > p.s. Which protocol is a good example of non-linear skb usage? Most still > seem to use skb_linearize() and the skb documentation is somewhat outdated. What are you talking about? There are only a handful of skb_linearize() users in the current 2.6.x sources, and those will be eradicated soon. IPV4 is probably the best example. From shemminger@osdl.org Wed Aug 13 09:40:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 09:40:33 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DGe7Fl010285 for ; Wed, 13 Aug 2003 09:40:27 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7DGdHo24843; Wed, 13 Aug 2003 09:39:19 -0700 Date: Wed, 13 Aug 2003 09:39:09 -0700 From: Stephen Hemminger To: Jean-Paul Roubelat , "David S. Miller" , Jeff Garzik Cc: linux-hams@vger.kernel.org, netdev@oss.sgi.com Subject: [PATCH] (1/2) Convert YAM driver to dynamic net_device Message-Id: <20030813093909.22de1915.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4803 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Convert hamradio/yam.c to dynamic allocation of net_device instead of allocating an array of structures containing net_device's. This applies to 2.6.0-test3. Since this driver will come up with out any actual hardware was able to test load/unload on SMP. To bad my license is way out of date ;-) diff -Nru a/drivers/net/hamradio/yam.c b/drivers/net/hamradio/yam.c --- a/drivers/net/hamradio/yam.c Wed Aug 13 09:31:17 2003 +++ b/drivers/net/hamradio/yam.c Wed Aug 13 09:31:17 2003 @@ -120,7 +120,7 @@ int irq; int dupmode; - struct net_device dev; + struct net_device *dev; /* Stats section */ @@ -161,7 +161,7 @@ struct yam_mcs *next; }; -static struct yam_port yam_ports[NR_PORTS]; +static struct net_device *yam_devs[NR_PORTS]; static struct yam_mcs *yam_data; @@ -628,8 +628,8 @@ int i; for (i = 0; i < NR_PORTS; i++) { - struct net_device *dev = &yam_ports[i].dev; - if (netif_running(dev)) + struct net_device *dev = yam_devs[i]; + if (dev && netif_running(dev)) yam_arbitrate(dev); } yam_timer.expires = jiffies + HZ / 100; @@ -724,8 +724,8 @@ int handled = 0; for (i = 0; i < NR_PORTS; i++) { - yp = &yam_ports[i]; - dev = &yp->dev; + dev = yam_devs[i]; + yp = dev->priv; if (!netif_running(dev)) continue; @@ -882,8 +882,10 @@ /* Reset overruns for all ports - FPGA programming makes overruns */ for (i = 0; i < NR_PORTS; i++) { - inb(LSR(yam_ports[i].dev.base_addr)); - yam_ports[i].stats.rx_fifo_errors = 0; + struct net_device *dev = yam_devs[i]; + struct yam_port *yp = dev->priv; + inb(LSR(dev->base_addr)); + yp->stats.rx_fifo_errors = 0; } printk(KERN_INFO "%s at iobase 0x%lx irq %u uart %s\n", dev->name, dev->base_addr, dev->irq, @@ -1070,14 +1072,26 @@ /* --------------------------------------------------------------------- */ -static int yam_probe(struct net_device *dev) +static void yam_setup(struct net_device *dev) { - struct yam_port *yp; - - if (!dev) - return -ENXIO; + struct yam_port *yp = dev->priv; - yp = (struct yam_port *) dev->priv; + yp->magic = YAM_MAGIC; + yp->bitrate = DEFAULT_BITRATE; + yp->baudrate = DEFAULT_BITRATE * 2; + yp->iobase = 0; + yp->irq = 0; + yp->dupmode = 0; + yp->holdd = DEFAULT_HOLDD; + yp->txd = DEFAULT_TXD; + yp->txtail = DEFAULT_TXTAIL; + yp->slot = DEFAULT_SLOT; + yp->pers = DEFAULT_PERS; + yp->dev = dev; + + dev->base_addr = yp->iobase; + dev->irq = yp->irq; + SET_MODULE_OWNER(dev); dev->open = yam_open; dev->stop = yam_close; @@ -1104,50 +1118,35 @@ memcpy(dev->broadcast, ax25_bcast, 7); memcpy(dev->dev_addr, ax25_test, 7); - /* New style flags */ - dev->flags = 0; - - return 0; } -/* --------------------------------------------------------------------- */ - static int __init yam_init_driver(void) { struct net_device *dev; - int i; + int i, err; + char name[IFNAMSIZ]; printk(yam_drvinfo); for (i = 0; i < NR_PORTS; i++) { - sprintf(yam_ports[i].dev.name, "yam%d", i); - yam_ports[i].magic = YAM_MAGIC; - yam_ports[i].bitrate = DEFAULT_BITRATE; - yam_ports[i].baudrate = DEFAULT_BITRATE * 2; - yam_ports[i].iobase = 0; - yam_ports[i].irq = 0; - yam_ports[i].dupmode = 0; - yam_ports[i].holdd = DEFAULT_HOLDD; - yam_ports[i].txd = DEFAULT_TXD; - yam_ports[i].txtail = DEFAULT_TXTAIL; - yam_ports[i].slot = DEFAULT_SLOT; - yam_ports[i].pers = DEFAULT_PERS; - - dev = &yam_ports[i].dev; - - dev->priv = &yam_ports[i]; - dev->base_addr = yam_ports[i].iobase; - dev->irq = yam_ports[i].irq; - dev->init = yam_probe; - dev->if_port = 0; - - if (register_netdev(dev)) { + sprintf(name, "yam%d", i); + + dev = alloc_netdev(sizeof(struct yam_port), name, + yam_setup); + if (!dev) { + printk(KERN_ERR "yam: cannot allocate net device %s\n", + dev->name); + err = -ENOMEM; + goto error; + } + + err = register_netdev(dev); + if (err) { printk(KERN_WARNING "yam: cannot register net device %s\n", dev->name); - dev->priv = NULL; - return -ENXIO; + goto error; } + yam_devs[i] = dev; - SET_MODULE_OWNER(dev); } yam_timer.function = yam_dotimer; @@ -1156,6 +1155,12 @@ proc_net_create("yam", 0, yam_net_get_info); return 0; + error: + while (--i >= 0) { + unregister_netdev(yam_devs[i]); + kfree(yam_devs[i]); + } + return err; } /* --------------------------------------------------------------------- */ @@ -1167,12 +1172,11 @@ del_timer(&yam_timer); for (i = 0; i < NR_PORTS; i++) { - struct net_device *dev = &yam_ports[i].dev; - if (!dev->priv) - continue; - if (netif_running(dev)) - yam_close(dev); - unregister_netdev(dev); + struct net_device *dev = yam_devs[i]; + if (dev) { + unregister_netdev(dev); + kfree(dev); + } } while (yam_data) { From shemminger@osdl.org Wed Aug 13 09:40:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 09:40:33 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DGe4Fl010279 for ; Wed, 13 Aug 2003 09:40:25 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7DGdYo24865; Wed, 13 Aug 2003 09:39:34 -0700 Date: Wed, 13 Aug 2003 09:39:26 -0700 From: Stephen Hemminger To: Jean-Paul Roubelat , "David S. Miller" , Jeff Garzik , linux-hams@vger.kernel.org, netdev@oss.sgi.com Subject: [PATCH] (2/2) Convert yam driver to seq_file Message-Id: <20030813093926.7b267dd6.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4803 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Convert the yam driver to use the new seq_file interface to /proc. This resolves potential issues with module owner and buffer sizes by using the common library. This applies to 2.6.0-test3. Since this driver will come up with out any actual hardware was able to test load/unload on SMP. diff -Nru a/drivers/net/hamradio/yam.c b/drivers/net/hamradio/yam.c --- a/drivers/net/hamradio/yam.c Wed Aug 13 09:31:31 2003 +++ b/drivers/net/hamradio/yam.c Wed Aug 13 09:31:31 2003 @@ -72,6 +72,7 @@ #include #include +#include #include #include @@ -765,56 +766,73 @@ return IRQ_RETVAL(handled); } -static int yam_net_get_info(char *buffer, char **start, off_t offset, int length) +#ifdef CONFIG_PROC_FS + +static void *yam_seq_start(struct seq_file *seq, loff_t *pos) { - int len = 0; - int i; - off_t pos = 0; - off_t begin = 0; + return (*pos < NR_PORTS) ? yam_devs[*pos] : NULL; +} +static void *yam_seq_next(struct seq_file *seq, void *v, loff_t *pos) +{ + ++*pos; + return (*pos < NR_PORTS) ? yam_devs[*pos] : NULL; +} - for (i = 0; i < NR_PORTS; i++) { - if (yam_ports[i].iobase == 0 || yam_ports[i].irq == 0) - continue; - len += sprintf(buffer + len, "Device yam%d\n", i); - len += sprintf(buffer + len, " Up %d\n", netif_running(&yam_ports[i].dev)); - len += sprintf(buffer + len, " Speed %u\n", yam_ports[i].bitrate); - len += sprintf(buffer + len, " IoBase 0x%x\n", yam_ports[i].iobase); - len += sprintf(buffer + len, " BaudRate %u\n", yam_ports[i].baudrate); - len += sprintf(buffer + len, " IRQ %u\n", yam_ports[i].irq); - len += sprintf(buffer + len, " TxState %u\n", yam_ports[i].tx_state); - len += sprintf(buffer + len, " Duplex %u\n", yam_ports[i].dupmode); - len += sprintf(buffer + len, " HoldDly %u\n", yam_ports[i].holdd); - len += sprintf(buffer + len, " TxDelay %u\n", yam_ports[i].txd); - len += sprintf(buffer + len, " TxTail %u\n", yam_ports[i].txtail); - len += sprintf(buffer + len, " SlotTime %u\n", yam_ports[i].slot); - len += sprintf(buffer + len, " Persist %u\n", yam_ports[i].pers); - len += sprintf(buffer + len, " TxFrames %lu\n", yam_ports[i].stats.tx_packets); - len += sprintf(buffer + len, " RxFrames %lu\n", yam_ports[i].stats.rx_packets); - len += sprintf(buffer + len, " TxInt %u\n", yam_ports[i].nb_mdint); - len += sprintf(buffer + len, " RxInt %u\n", yam_ports[i].nb_rxint); - len += sprintf(buffer + len, " RxOver %lu\n", yam_ports[i].stats.rx_fifo_errors); - len += sprintf(buffer + len, "\n"); - - pos = begin + len; - - if (pos < offset) { - len = 0; - begin = pos; - } - if (pos > offset + length) - break; - } +static void yam_seq_stop(struct seq_file *seq, void *v) +{ +} - *start = buffer + (offset - begin); - len -= (offset - begin); +static int yam_seq_show(struct seq_file *seq, void *v) +{ + const struct net_device *dev = v; + const struct yam_port *yp = dev->priv; + + seq_printf(seq, "Device %s\n", dev->name); + seq_printf(seq, " Up %d\n", netif_running(dev)); + seq_printf(seq, " Speed %u\n", yp->bitrate); + seq_printf(seq, " IoBase 0x%x\n", yp->iobase); + seq_printf(seq, " BaudRate %u\n", yp->baudrate); + seq_printf(seq, " IRQ %u\n", yp->irq); + seq_printf(seq, " TxState %u\n", yp->tx_state); + seq_printf(seq, " Duplex %u\n", yp->dupmode); + seq_printf(seq, " HoldDly %u\n", yp->holdd); + seq_printf(seq, " TxDelay %u\n", yp->txd); + seq_printf(seq, " TxTail %u\n", yp->txtail); + seq_printf(seq, " SlotTime %u\n", yp->slot); + seq_printf(seq, " Persist %u\n", yp->pers); + seq_printf(seq, " TxFrames %lu\n", yp->stats.tx_packets); + seq_printf(seq, " RxFrames %lu\n", yp->stats.rx_packets); + seq_printf(seq, " TxInt %u\n", yp->nb_mdint); + seq_printf(seq, " RxInt %u\n", yp->nb_rxint); + seq_printf(seq, " RxOver %lu\n", yp->stats.rx_fifo_errors); + seq_printf(seq, "\n"); - if (len > length) - len = length; +} + +static struct seq_operations yam_seqops = { + .start = yam_seq_start, + .next = yam_seq_next, + .stop = yam_seq_stop, + .show = yam_seq_show, +}; - return len; +static int yam_info_open(struct inode *inode, struct file *file) +{ + return seq_open(file, &yam_seqops); } +static struct file_operations yam_info_fops = { + .owner = THIS_MODULE, + .open = yam_info_open, + .read = seq_read, + .llseek = seq_lseek, + .release = seq_release, +}; + +#endif + + /* --------------------------------------------------------------------- */ static struct net_device_stats *yam_get_stats(struct net_device *dev) @@ -1153,7 +1171,7 @@ yam_timer.expires = jiffies + HZ / 100; add_timer(&yam_timer); - proc_net_create("yam", 0, yam_net_get_info); + proc_net_fops_create("yam", S_IRUGO, &yam_info_fops); return 0; error: while (--i >= 0) { From pe1rxq@amsat.org Wed Aug 13 09:49:05 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 09:49:14 -0700 (PDT) Received: from amsfep12-int.chello.nl (amsfep12-int.chello.nl [213.46.243.18]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DGn2Fl011042 for ; Wed, 13 Aug 2003 09:49:03 -0700 Received: from mail.chello.nl ([212.83.83.7]) by amsfep12-int.chello.nl (InterMail vM.5.01.05.17 201-253-122-126-117-20021021) with SMTP id <20030813153313.VVJH1274.amsfep12-int.chello.nl@mail.chello.nl>; Wed, 13 Aug 2003 17:33:13 +0200 Date: Wed, 13 Aug 2003 17:34:46 +0200 From: Jeroen Vreeken To: "David S . Miller" Cc: Stephen Hemminger , linux-hams@vger.kernel.org, ralf@linux-mips.org, netdev@oss.sgi.com Subject: Re: [PATCH] Convert ax25 to seq_file Message-ID: <20030813173446.A2604@jeroen.pe1rxq.ampr.org> References: <20030812194653.A28977@jeroen.pe1rxq.ampr.org> <20030812135655.7334887b.shemminger@osdl.org> <20030812230951.E28977@jeroen.pe1rxq.ampr.org> <20030812153901.6e700dcb.shemminger@osdl.org> <20030813010301.K28977@jeroen.pe1rxq.ampr.org> <20030812172151.7de0c950.shemminger@osdl.org> <20030813031159.6c6c9629.davem@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="AWniW0JNca5xppdA" Content-Transfer-Encoding: 8bit In-Reply-To: <20030813031159.6c6c9629.davem@redhat.com>; from davem@redhat.com on Wed, Aug 13, 2003 at 12:11:59 +0200 X-Mailer: Balsa 1.1.0 Lines: 1364 X-archive-position: 4804 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pe1rxq@amsat.org Precedence: bulk X-list: netdev --AWniW0JNca5xppdA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit On 2003.08.13 12:11:59 +0200 David S. Miller wrote: > I have a bazillion different ax.25 patches in my inbox now, > some should be applied and others not, and this is hard to > determine with all the activity. > > Can someone send me a coherent set of patches to apply once > all the issues have been worked out? This is my last patch (rxq4) plus Stephen's last three (dev locking, setsockopt, seq_file) Jeroen p.s. Which protocol is a good example of non-linear skb usage? Most still seem to use skb_linearize() and the skb documentation is somewhat outdated. --AWniW0JNca5xppdA Content-Type: application/octet-stream; charset=ISO-8859-1 Content-Disposition: attachment; filename="linux-2.6.0-test3.ax25.diff" Content-Transfer-Encoding: quoted-printable Only in linux-2.6.0-test3.rxq/net/ax25: .af_ax25.o.cmd=0AOnly in linux-2.6.= 0-test3.rxq/net/ax25: .ax25.ko.cmd=0AOnly in linux-2.6.0-test3.rxq/net/ax25= : .ax25.mod.o.cmd=0AOnly in linux-2.6.0-test3.rxq/net/ax25: .ax25.o.cmd=0AO= nly in linux-2.6.0-test3.rxq/net/ax25: .ax25_addr.o.cmd=0AOnly in linux-2.6= .0-test3.rxq/net/ax25: .ax25_dev.o.cmd=0AOnly in linux-2.6.0-test3.rxq/net/= ax25: .ax25_iface.o.cmd=0AOnly in linux-2.6.0-test3.rxq/net/ax25: .ax25_in.= o.cmd=0AOnly in linux-2.6.0-test3.rxq/net/ax25: .ax25_ip.o.cmd=0AOnly in li= nux-2.6.0-test3.rxq/net/ax25: .ax25_out.o.cmd=0AOnly in linux-2.6.0-test3.r= xq/net/ax25: .ax25_route.o.cmd=0AOnly in linux-2.6.0-test3.rxq/net/ax25: .a= x25_std_in.o.cmd=0AOnly in linux-2.6.0-test3.rxq/net/ax25: .ax25_std_subr.o= .cmd=0AOnly in linux-2.6.0-test3.rxq/net/ax25: .ax25_std_timer.o.cmd=0AOnly= in linux-2.6.0-test3.rxq/net/ax25: .ax25_subr.o.cmd=0AOnly in linux-2.6.0-= test3.rxq/net/ax25: .ax25_timer.o.cmd=0AOnly in linux-2.6.0-test3.rxq/net/a= x25: .ax25_uid.o.cmd=0AOnly in linux-2.6.0-test3.rxq/net/ax25: .built-in.o.= cmd=0AOnly in linux-2.6.0-test3.rxq/net/ax25: .sysctl_net_ax25.o.cmd=0Adiff= -ru linux-2.6.0-test3/net/ax25/af_ax25.c linux-2.6.0-test3.rxq/net/ax25/af= _ax25.c=0A--- linux-2.6.0-test3/net/ax25/af_ax25.c 2003-08-09 06:41:26.0000= 00000 +0200=0A+++ linux-2.6.0-test3.rxq/net/ax25/af_ax25.c 2003-08-13 00:29= :48.000000000 +0200=0A@@ -51,54 +51,27 @@=0A =0A =0A =0A-ax25_cb *ax25_list= ;=0A+HLIST_HEAD(ax25_list);=0A spinlock_t ax25_list_lock =3D SPIN_LOCK_UNLO= CKED;=0A =0A static struct proto_ops ax25_proto_ops;=0A =0A-/*=0A- * Free a= n allocated ax25 control block. This is done to centralise=0A- * the MOD co= unt code.=0A- */=0A-void ax25_free_cb(ax25_cb *ax25)=0A-{=0A- if (ax25->dig= ipeat !=3D NULL) {=0A- kfree(ax25->digipeat);=0A- ax25->digipeat =3D NULL= ;=0A- }=0A-=0A- kfree(ax25);=0A-}=0A-=0A static void ax25_free_sock(struct = sock *sk)=0A {=0A- ax25_free_cb(ax25_sk(sk));=0A+ ax25_cb_put(ax25_sk(sk));= =0A }=0A =0A /*=0A * Socket removal during an interrupt is now safe.=0A *= /=0A-static void ax25_remove_socket(ax25_cb *ax25)=0A+static void ax25_cb_d= el(ax25_cb *ax25)=0A {=0A- ax25_cb *s;=0A-=0A- spin_lock_bh(&ax25_list_lock= );=0A- if ((s =3D ax25_list) =3D=3D ax25) {=0A- ax25_list =3D s->next;=0A+= if (!hlist_unhashed(&ax25->ax25_node)) {=0A+ spin_lock_bh(&ax25_list_lock= );=0A+ hlist_del_init(&ax25->ax25_node);=0A spin_unlock_bh(&ax25_list_lo= ck);=0A- return;=0A- }=0A-=0A- while (s !=3D NULL && s->next !=3D NULL) {= =0A- if (s->next =3D=3D ax25) {=0A- s->next =3D ax25->next;=0A- spin_u= nlock_bh(&ax25_list_lock);=0A- return;=0A- }=0A-=0A- s =3D s->next;=0A+= ax25_cb_put(ax25);=0A }=0A- spin_unlock_bh(&ax25_list_lock);=0A }=0A =0A= /*=0A@@ -108,12 +81,13 @@=0A {=0A ax25_dev *ax25_dev;=0A ax25_cb *s;=0A+= struct hlist_node *node;=0A =0A if ((ax25_dev =3D ax25_dev_ax25dev(dev)) = =3D=3D NULL)=0A return;=0A =0A spin_lock_bh(&ax25_list_lock);=0A- for (s= =3D ax25_list; s !=3D NULL; s =3D s->next) {=0A+ ax25_for_each(s, node, &a= x25_list) {=0A if (s->ax25_dev =3D=3D ax25_dev) {=0A s->ax25_dev =3D N= ULL;=0A ax25_disconnect(s, ENETUNREACH);=0A@@ -153,11 +127,11 @@=0A /*= =0A * Add a socket to the bound sockets list.=0A */=0A-void ax25_insert_s= ocket(ax25_cb *ax25)=0A+void ax25_cb_add(ax25_cb *ax25)=0A {=0A spin_lock_= bh(&ax25_list_lock);=0A- ax25->next =3D ax25_list;=0A- ax25_list =3D ax25;= =0A+ ax25_cb_hold(ax25);=0A+ hlist_add_head(&ax25->ax25_node, &ax25_list);= =0A spin_unlock_bh(&ax25_list_lock);=0A }=0A =0A@@ -169,17 +143,18 @@=0A = struct net_device *dev, int type)=0A {=0A ax25_cb *s;=0A+ struct hlist_nod= e *node;=0A =0A spin_lock_bh(&ax25_list_lock);=0A- for (s =3D ax25_list; s= !=3D NULL; s =3D s->next) {=0A+ ax25_for_each(s, node, &ax25_list) {=0A = if ((s->iamdigi && !digi) || (!s->iamdigi && digi))=0A continue;=0A if= (s->sk && !ax25cmp(&s->source_addr, addr) &&=0A s->sk->sk_type =3D= =3D type && s->sk->sk_state =3D=3D TCP_LISTEN) {=0A /* If device is null= we match any device */=0A if (s->ax25_dev =3D=3D NULL || s->ax25_dev->d= ev =3D=3D dev) {=0A+ sock_hold(s->sk);=0A spin_unlock_bh(&ax25_list_= lock);=0A-=0A return s->sk;=0A }=0A }=0A@@ -197,9 +172,10 @@=0A {= =0A struct sock *sk =3D NULL;=0A ax25_cb *s;=0A+ struct hlist_node *node;= =0A =0A spin_lock_bh(&ax25_list_lock);=0A- for (s =3D ax25_list; s !=3D NU= LL; s =3D s->next) {=0A+ ax25_for_each(s, node, &ax25_list) {=0A if (s->s= k && !ax25cmp(&s->source_addr, my_addr) &&=0A !ax25cmp(&s->dest_addr,= dest_addr) &&=0A s->sk->sk_type =3D=3D type) {=0A@@ -223,9 +199,10 @= @=0A ax25_digi *digi, struct net_device *dev)=0A {=0A ax25_cb *s;=0A+ str= uct hlist_node *node;=0A =0A spin_lock_bh(&ax25_list_lock);=0A- for (s =3D= ax25_list; s !=3D NULL; s =3D s->next) {=0A+ ax25_for_each(s, node, &ax25_= list) {=0A if (s->sk && s->sk->sk_type !=3D SOCK_SEQPACKET)=0A continu= e;=0A if (s->ax25_dev =3D=3D NULL)=0A@@ -240,6 +217,7 @@=0A if (s->di= gipeat !=3D NULL && s->digipeat->ndigi !=3D 0)=0A continue;=0A }=0A= + ax25_cb_hold(s);=0A spin_unlock_bh(&ax25_list_lock);=0A =0A retur= n s;=0A@@ -257,9 +235,10 @@=0A {=0A struct sock *sk =3D NULL;=0A ax25_cb = *s;=0A+ struct hlist_node *node;=0A =0A spin_lock_bh(&ax25_list_lock);=0A-= for (s =3D ax25_list; s !=3D NULL; s =3D s->next) {=0A+ ax25_for_each(s, n= ode, &ax25_list) {=0A if (s->sk !=3D NULL && ax25cmp(&s->source_addr, add= r) =3D=3D 0 &&=0A s->sk->sk_type =3D=3D SOCK_RAW) {=0A sk =3D s->s= k;=0A@@ -267,6 +246,7 @@=0A break;=0A }=0A }=0A+=0A spin_unlock_bh(&= ax25_list_lock);=0A =0A return sk;=0A@@ -299,7 +279,16 @@=0A */=0A static= void ax25_destroy_timer(unsigned long data)=0A {=0A- ax25_destroy_socket((= ax25_cb *)data);=0A+ ax25_cb *ax25=3D(ax25_cb *)data;=0A+ struct sock *sk;= =0A+ =0A+ sk=3Dax25->sk;=0A+ =0A+ bh_lock_sock(sk);=0A+ sock_hold(sk);=0A+ = ax25_destroy_socket(ax25);=0A+ bh_unlock_sock(sk);=0A+ sock_put(sk);=0A }= =0A =0A /*=0A@@ -312,7 +301,7 @@=0A {=0A struct sk_buff *skb;=0A =0A- ax25= _remove_socket(ax25);=0A+ ax25_cb_del(ax25);=0A =0A ax25_stop_heartbeat(ax= 25);=0A ax25_stop_t1timer(ax25);=0A@@ -337,22 +326,27 @@=0A =0A kfree_s= kb(skb);=0A }=0A+ while ((skb =3D skb_dequeue(&ax25->sk->sk_write_queue)= ) !=3D NULL) {=0A+ kfree_skb(skb);=0A+ }=0A }=0A =0A if (ax25->sk !=3D= NULL) {=0A if (atomic_read(&ax25->sk->sk_wmem_alloc) ||=0A atomic_= read(&ax25->sk->sk_rmem_alloc)) {=0A /* Defer: outstanding buffers */=0A= - init_timer(&ax25->timer);=0A- ax25->timer.expires =3D jiffies + 10 *= HZ;=0A- ax25->timer.function =3D ax25_destroy_timer;=0A- ax25->timer.d= ata =3D (unsigned long)ax25;=0A- add_timer(&ax25->timer);=0A+ init_= timer(&ax25->dtimer);=0A+ ax25->dtimer.expires =3D jiffies + 2 * HZ;=0A+= ax25->dtimer.function =3D ax25_destroy_timer;=0A+ ax25->dtimer.data = =3D (unsigned long)ax25;=0A+ add_timer(&ax25->dtimer);=0A } else {=0A= - sock_put(ax25->sk);=0A+ struct sock *sk=3Dax25->sk;=0A+ ax25->sk=3D= NULL;=0A+ sock_put(sk);=0A }=0A } else {=0A- ax25_free_cb(ax25);=0A+ = ax25_cb_put(ax25);=0A }=0A }=0A =0A@@ -421,7 +415,7 @@=0A =0A case AX2= 5_N2:=0A if (ax25_ctl.arg < 1 || ax25_ctl.arg > 31)=0A- return -EIN= VAL;=0A+ return -EINVAL;=0A ax25->n2count =3D 0;=0A ax25->n2 =3D = ax25_ctl.arg;=0A break;=0A@@ -448,7 +442,7 @@=0A return -EINVAL;=0A= }=0A =0A- return 0;=0A+ return 0;=0A }=0A =0A /*=0A@@ -507,6 +501,7 @= @=0A return NULL;=0A =0A memset(ax25, 0x00, sizeof(*ax25));=0A+ atomic_s= et(&ax25->refcount, 1);=0A =0A skb_queue_head_init(&ax25->write_queue);=0A= skb_queue_head_init(&ax25->frag_queue);=0A@@ -655,6 +650,7 @@=0A (so= ck->state !=3D SS_UNCONNECTED ||=0A sk->sk_state =3D=3D TCP_LISTEN)) = {=0A res =3D -EADDRNOTAVAIL;=0A+ dev_put(dev);=0A break;=0A }=0A = =0A@@ -877,7 +873,7 @@=0A break;=0A default:=0A sk_free(sk);=0A- ax25= _free_cb(ax25);=0A+ ax25_cb_put(ax25);=0A return NULL;=0A }=0A =0A@@ -9= 37,6 +933,7 @@=0A if (sk =3D=3D NULL)=0A return 0;=0A =0A+ sock_hold(sk)= ;=0A lock_sock(sk);=0A ax25 =3D ax25_sk(sk);=0A =0A@@ -944,13 +941,15 @@= =0A switch (ax25->state) {=0A case AX25_STATE_0:=0A ax25_disconnect(= ax25, 0);=0A- goto drop;=0A+ ax25_destroy_socket(ax25);=0A+ break;=0A= =0A case AX25_STATE_1:=0A case AX25_STATE_2:=0A ax25_send_control(a= x25, AX25_DISC, AX25_POLLON, AX25_COMMAND);=0A ax25_disconnect(ax25, 0);= =0A- goto drop;=0A+ ax25_destroy_socket(ax25);=0A+ break;=0A =0A ca= se AX25_STATE_3:=0A case AX25_STATE_4:=0A@@ -993,16 +992,14 @@=0A sk->s= k_shutdown |=3D SEND_SHUTDOWN;=0A sk->sk_state_change(sk);=0A sock_set_= flag(sk, SOCK_DEAD);=0A- goto drop;=0A+ ax25_destroy_socket(ax25);=0A }= =0A =0A sock->sk =3D NULL;=0A sk->sk_socket =3D NULL; /* Not used, but = we should do this */=0A release_sock(sk);=0A- return 0;=0A- drop:=0A- rele= ase_sock(sk);=0A- ax25_destroy_socket(ax25);=0A+ sock_put(sk);=0A+=0A retu= rn 0;=0A }=0A =0A@@ -1077,7 +1074,7 @@=0A ax25_fillin_cb(ax25, ax25_dev);= =0A =0A done:=0A- ax25_insert_socket(ax25);=0A+ ax25_cb_add(ax25);=0A sk->= sk_zapped =3D 0;=0A =0A out:=0A@@ -1093,7 +1090,7 @@=0A int addr_len, int = flags)=0A {=0A struct sock *sk =3D sock->sk;=0A- ax25_cb *ax25 =3D ax25_sk= (sk);=0A+ ax25_cb *ax25 =3D ax25_sk(sk), *ax25t;=0A struct full_sockaddr_a= x25 *fsa =3D (struct full_sockaddr_ax25 *)uaddr;=0A ax25_digi *digi =3D NU= LL;=0A int ct =3D 0, err =3D 0;=0A@@ -1199,7 +1196,7 @@=0A goto out;=0A= =0A ax25_fillin_cb(ax25, ax25->ax25_dev);=0A- ax25_insert_socket(ax25);= =0A+ ax25_cb_add(ax25);=0A } else {=0A if (ax25->ax25_dev =3D=3D NULL) = {=0A err =3D -EHOSTUNREACH;=0A@@ -1208,11 +1205,12 @@=0A }=0A =0A if (= sk->sk_type =3D=3D SOCK_SEQPACKET &&=0A- ax25_find_cb(&ax25->source_add= r, &fsa->fsa_ax25.sax25_call, digi,=0A- ax25->ax25_dev->dev)) {=0A+ = (ax25t=3Dax25_find_cb(&ax25->source_addr, &fsa->fsa_ax25.sax25_call, di= gi,=0A+ ax25->ax25_dev->dev))) {=0A if (digi !=3D NULL)=0A kfre= e(digi);=0A err =3D -EADDRINUSE; /* Already such a connection */=0A+ ax= 25_cb_put(ax25t);=0A goto out;=0A }=0A =0A@@ -1273,6 +1271,8 @@=0A l= ock_sock(sk);=0A continue;=0A }=0A+ current->state =3D TASK_RUNNIN= G;=0A+ remove_wait_queue(sk->sk_sleep, &wait);=0A return -ERESTARTSYS;= =0A }=0A current->state =3D TASK_RUNNING;=0A@@ -1288,10 +1288,11 @@=0A = =0A sock->state =3D SS_CONNECTED;=0A =0A+ err=3D0;=0A out:=0A release_soc= k(sk);=0A =0A- return 0;=0A+ return err;=0A }=0A =0A =0A@@ -1331,15 +1332,1= 8 @@=0A if (skb)=0A break;=0A =0A- current->state =3D TASK_INTERRUPTI= BLE;=0A release_sock(sk);=0A+ current->state =3D TASK_INTERRUPTIBLE;=0A = if (flags & O_NONBLOCK)=0A return -EWOULDBLOCK;=0A if (!signal_pendi= ng(tsk)) {=0A schedule();=0A+ current->state =3D TASK_RUNNING;=0A l= ock_sock(sk);=0A continue;=0A }=0A+ current->state =3D TASK_RUNNING;= =0A+ remove_wait_queue(sk->sk_sleep, &wait);=0A return -ERESTARTSYS;=0A = }=0A current->state =3D TASK_RUNNING;=0A@@ -1519,7 +1523,7 @@=0A SOCK_DE= BUG(sk, "AX.25: sendto: building packet.\n");=0A =0A /* Assume the worst c= ase */=0A- size =3D len + 3 + ax25_addr_size(dp) + AX25_BPQ_HEADER_LEN;=0A+= size =3D len + ax25->ax25_dev->dev->hard_header_len;=0A =0A skb =3D sock_= alloc_send_skb(sk, size, msg->msg_flags&MSG_DONTWAIT, &err);=0A if (skb = =3D=3D NULL)=0A@@ -1780,7 +1784,7 @@=0A =0A /* old structure? */=0A if = (cmd =3D=3D SIOCAX25GETINFOOLD) {=0A- static int warned;=0A+ static int= warned =3D 0;=0A if (!warned) {=0A printk(KERN_INFO "%s uses old SI= OCAX25GETINFO\n",=0A current->comm);=0A@@ -1845,6 +1849,7 @@=0A int l= en =3D 0;=0A off_t pos =3D 0;=0A off_t begin =3D 0;=0A+ struct hlist_node= *node;=0A =0A spin_lock_bh(&ax25_list_lock);=0A =0A@@ -1853,7 +1858,7 @@= =0A * magic dev src_addr dest_addr,digi1,digi2,.. st vs vr va t1 t1 t2 t2= t3 t3 idle idle n2 n2 rtt window paclen Snd-Q Rcv-Q inode=0A */=0A =0A- = for (ax25 =3D ax25_list; ax25 !=3D NULL; ax25 =3D ax25->next) {=0A+ ax25_fo= r_each(ax25, node, &ax25_list) {=0A len +=3D sprintf(buffer+len, "%8.8lx = %s %s%s ",=0A (long) ax25,=0A ax25->ax25_dev =3D=3D NULL? "???" : a= x25->ax25_dev->dev->name,=0A@@ -1882,10 +1887,12 @@=0A ax25->paclen);=0A= =0A if (ax25->sk !=3D NULL) {=0A+ bh_lock_sock(ax25->sk);=0A len += =3D sprintf(buffer + len, " %d %d %ld\n",=0A atomic_read(&ax25->sk->sk_= wmem_alloc),=0A atomic_read(&ax25->sk->sk_rmem_alloc),=0A ax25->sk-= >sk_socket !=3D NULL ? SOCK_INODE(ax25->sk->sk_socket)->i_ino : 0L);=0A+ = bh_unlock_sock(ax25->sk);=0A } else {=0A len +=3D sprintf(buffer + len= , " * * *\n");=0A }=0AOnly in linux-2.6.0-test3.rxq/net/ax25: af_ax25.o= =0AOnly in linux-2.6.0-test3.rxq/net/ax25: ax25.ko=0AOnly in linux-2.6.0-te= st3.rxq/net/ax25: ax25.mod.c=0AOnly in linux-2.6.0-test3.rxq/net/ax25: ax25= .mod.o=0AOnly in linux-2.6.0-test3.rxq/net/ax25: ax25.o=0AOnly in linux-2.6= .0-test3.rxq/net/ax25: ax25_addr.o=0AOnly in linux-2.6.0-test3.rxq/net/ax25= : ax25_dev.o=0Adiff -ru linux-2.6.0-test3/net/ax25/ax25_ds_in.c linux-2.6.0= -test3.rxq/net/ax25/ax25_ds_in.c=0A--- linux-2.6.0-test3/net/ax25/ax25_ds_i= n.c 2003-08-09 06:38:45.000000000 +0200=0A+++ linux-2.6.0-test3.rxq/net/ax2= 5/ax25_ds_in.c 2003-08-12 23:40:35.000000000 +0200=0A@@ -65,6 +65,7 @@=0A = ax25->state =3D AX25_STATE_3;=0A ax25->n2count =3D 0;=0A if (ax25->s= k !=3D NULL) {=0A+ bh_lock_sock(ax25->sk);=0A ax25->sk->sk_state =3D T= CP_ESTABLISHED;=0A /*=0A * For WAIT_SABM connections we will produce= an accept=0A@@ -72,6 +73,7 @@=0A */=0A if (!sock_flag(ax25->sk, SOC= K_DEAD))=0A ax25->sk->sk_state_change(ax25->sk);=0A+ bh_unlock_sock(a= x25->sk);=0A }=0A ax25_dama_on(ax25);=0A =0Adiff -ru linux-2.6.0-test3/= net/ax25/ax25_ds_subr.c linux-2.6.0-test3.rxq/net/ax25/ax25_ds_subr.c=0A---= linux-2.6.0-test3/net/ax25/ax25_ds_subr.c 2003-08-09 06:41:32.000000000 +0= 200=0A+++ linux-2.6.0-test3.rxq/net/ax25/ax25_ds_subr.c 2003-08-12 23:40:35= .000000000 +0200=0A@@ -40,6 +40,7 @@=0A void ax25_ds_enquiry_response(ax25_= cb *ax25)=0A {=0A ax25_cb *ax25o;=0A+ struct hlist_node *node;=0A =0A /* = Please note that neither DK4EG=B4s nor DG2FEF=B4s=0A * DAMA spec mention = the following behaviour as seen=0A@@ -80,7 +81,7 @@=0A ax25_ds_set_timer(a= x25->ax25_dev);=0A =0A spin_lock_bh(&ax25_list_lock);=0A- for (ax25o =3D a= x25_list; ax25o !=3D NULL; ax25o =3D ax25o->next) {=0A+ ax25_for_each(ax25o= , node, &ax25_list) {=0A if (ax25o =3D=3D ax25)=0A continue;=0A =0A@@ = -160,9 +161,10 @@=0A {=0A ax25_cb *ax25;=0A int res =3D 0;=0A+ struct hli= st_node *node;=0A =0A spin_lock_bh(&ax25_list_lock);=0A- for (ax25 =3D ax2= 5_list; ax25 !=3D NULL ; ax25 =3D ax25->next)=0A+ ax25_for_each(ax25, node,= &ax25_list)=0A if (ax25->ax25_dev =3D=3D ax25_dev && (ax25->condition & = AX25_COND_DAMA_MODE) && ax25->state > AX25_STATE_1) {=0A res =3D 1;=0A = break;=0Adiff -ru linux-2.6.0-test3/net/ax25/ax25_ds_timer.c linux-2.6.0-= test3.rxq/net/ax25/ax25_ds_timer.c=0A--- linux-2.6.0-test3/net/ax25/ax25_ds= _timer.c 2003-08-09 06:41:26.000000000 +0200=0A+++ linux-2.6.0-test3.rxq/ne= t/ax25/ax25_ds_timer.c 2003-08-12 23:40:35.000000000 +0200=0A@@ -74,6 +74,7= @@=0A {=0A ax25_dev *ax25_dev =3D (struct ax25_dev *) arg;=0A ax25_cb *a= x25;=0A+ struct hlist_node *node;=0A =0A if (ax25_dev =3D=3D NULL || !ax25= _dev->dama.slave)=0A return; /* Yikes! */=0A@@ -84,7 +85,7 @@=0A }=0A = =0A spin_lock_bh(&ax25_list_lock);=0A- for (ax25=3Dax25_list; ax25 !=3D NU= LL; ax25 =3D ax25->next) {=0A+ ax25_for_each(ax25, node, &ax25_list) {=0A = if (ax25->ax25_dev !=3D ax25_dev || !(ax25->condition & AX25_COND_DAMA_MOD= E))=0A continue;=0A =0A@@ -98,15 +99,26 @@=0A =0A void ax25_ds_heartbeat= _expiry(ax25_cb *ax25)=0A {=0A+ struct sock *sk=3Dax25->sk;=0A+=0A+ if (sk)= =0A+ bh_lock_sock(sk);=0A+=0A switch (ax25->state) {=0A =0A case AX25_ST= ATE_0:=0A /* Magic here: If we listen() and a new link dies before it=0A = is accepted() it isn't 'dead' so doesn't get removed. */=0A- if (!ax2= 5->sk || sock_flag(ax25->sk, SOCK_DESTROY) ||=0A- (ax25->sk->sk_state = =3D=3D TCP_LISTEN &&=0A- sock_flag(ax25->sk, SOCK_DEAD))) {=0A- ax2= 5_destroy_socket(ax25);=0A+ if (!sk || sock_flag(sk, SOCK_DESTROY) ||=0A+ = (sk->sk_state =3D=3D TCP_LISTEN &&=0A+ sock_flag(sk, SOCK_DEAD))= ) {=0A+ if (sk) {=0A+ sock_hold(sk);=0A+ ax25_destroy_socket(ax25);= =0A+ sock_put(sk);=0A+ bh_unlock_sock(sk);=0A+ } else=0A+ ax25_d= estroy_socket(ax25);=0A return;=0A }=0A break;=0A@@ -115,9 +127,9 @@= =0A /*=0A * Check the state of the receive buffer.=0A */=0A- if (a= x25->sk !=3D NULL) {=0A- if (atomic_read(&ax25->sk->sk_rmem_alloc) <=0A- = (ax25->sk->sk_rcvbuf / 2) &&=0A+ if (sk !=3D NULL) {=0A+ if (atomi= c_read(&sk->sk_rmem_alloc) <=0A+ (sk->sk_rcvbuf / 2) &&=0A (ax= 25->condition & AX25_COND_OWN_RX_BUSY)) {=0A ax25->condition &=3D ~AX25= _COND_OWN_RX_BUSY;=0A ax25->condition &=3D ~AX25_COND_ACK_PENDING;=0A@@= -127,6 +139,9 @@=0A break;=0A }=0A =0A+ if (sk)=0A+ bh_unlock_sock(sk)= ;=0A+=0A ax25_start_heartbeat(ax25);=0A }=0A =0A@@ -157,6 +172,7 @@=0A ax= 25_stop_t3timer(ax25);=0A =0A if (ax25->sk !=3D NULL) {=0A+ bh_lock_sock(= ax25->sk);=0A ax25->sk->sk_state =3D TCP_CLOSE;=0A ax25->sk->sk_err= =3D 0;=0A ax25->sk->sk_shutdown |=3D SEND_SHUTDOWN;=0A@@ -164,6 +1= 80,7 @@=0A ax25->sk->sk_state_change(ax25->sk);=0A sock_set_flag(ax25= ->sk, SOCK_DEAD);=0A }=0A+ bh_lock_sock(ax25->sk);=0A }=0A }=0A =0Adiff= -ru linux-2.6.0-test3/net/ax25/ax25_iface.c linux-2.6.0-test3.rxq/net/ax25= /ax25_iface.c=0A--- linux-2.6.0-test3/net/ax25/ax25_iface.c 2003-08-09 06:4= 2:13.000000000 +0200=0A+++ linux-2.6.0-test3.rxq/net/ax25/ax25_iface.c 2003= -08-12 23:40:35.000000000 +0200=0A@@ -33,20 +33,20 @@=0A struct protocol_s= truct *next;=0A unsigned int pid;=0A int (*func)(struct sk_buff *, ax25_c= b *);=0A-} *protocol_list;=0A+} *protocol_list =3D NULL;=0A static rwlock_t= protocol_list_lock =3D RW_LOCK_UNLOCKED;=0A =0A static struct linkfail_str= uct {=0A struct linkfail_struct *next;=0A void (*func)(ax25_cb *, int);= =0A-} *linkfail_list;=0A+} *linkfail_list =3D NULL;=0A static spinlock_t li= nkfail_lock =3D SPIN_LOCK_UNLOCKED;=0A =0A static struct listen_struct {=0A= struct listen_struct *next;=0A ax25_address callsign;=0A struct net_de= vice *dev;=0A-} *listen_list;=0A+} *listen_list =3D NULL;=0A static spinloc= k_t listen_lock =3D SPIN_LOCK_UNLOCKED;=0A =0A int ax25_protocol_register(u= nsigned int pid,=0A@@ -129,8 +129,10 @@=0A =0A spin_lock_bh(&linkfail_lock= );=0A linkfail =3D linkfail_list;=0A- if (linkfail =3D=3D NULL)=0A+ if (li= nkfail =3D=3D NULL) {=0A+ spin_unlock_bh(&linkfail_lock);=0A return;=0A+= }=0A =0A if (linkfail->func =3D=3D func) {=0A linkfail_list =3D linkfai= l->next;=0A@@ -180,8 +182,10 @@=0A =0A spin_lock_bh(&listen_lock);=0A lis= ten =3D listen_list;=0A- if (listen =3D=3D NULL)=0A+ if (listen =3D=3D NULL= ) {=0A+ spin_unlock_bh(&listen_lock);=0A return;=0A+ }=0A =0A if (ax25c= mp(&listen->callsign, callsign) =3D=3D 0 && listen->dev =3D=3D dev) {=0A = listen_list =3D listen->next;=0A@@ -226,8 +230,10 @@=0A =0A spin_lock_bh(&= listen_lock);=0A for (listen =3D listen_list; listen !=3D NULL; listen =3D= listen->next)=0A- if (ax25cmp(&listen->callsign, callsign) =3D=3D 0 && (l= isten->dev =3D=3D dev || listen->dev =3D=3D NULL))=0A+ if (ax25cmp(&listen= ->callsign, callsign) =3D=3D 0 && (listen->dev =3D=3D dev || listen->dev = =3D=3D NULL)) {=0A+ spin_unlock_bh(&listen_lock);=0A return 1;=0A+ }= =0A spin_unlock_bh(&listen_lock);=0A =0A return 0;=0AOnly in linux-2.6.0-= test3.rxq/net/ax25: ax25_iface.o=0Adiff -ru linux-2.6.0-test3/net/ax25/ax25= _in.c linux-2.6.0-test3.rxq/net/ax25/ax25_in.c=0A--- linux-2.6.0-test3/net/= ax25/ax25_in.c 2003-08-09 06:32:47.000000000 +0200=0A+++ linux-2.6.0-test3.= rxq/net/ax25/ax25_in.c 2003-08-12 23:40:35.000000000 +0200=0A@@ -147,6 +147= ,7 @@=0A }=0A =0A if (ax25->sk !=3D NULL && ax25->ax25_dev->values[AX25_V= ALUES_CONMODE] =3D=3D 2) {=0A+ bh_lock_sock(ax25->sk);=0A if ((!ax25->pi= dincl && ax25->sk->sk_protocol =3D=3D pid) ||=0A ax25->pidincl) {=0A = if (sock_queue_rcv_skb(ax25->sk, skb) =3D=3D 0)=0A@@ -154,6 +155,7 @@=0A= else=0A ax25->condition |=3D AX25_COND_OWN_RX_BUSY;=0A }=0A+ bh_= unlock_sock(ax25->sk);=0A }=0A =0A return queued;=0A@@ -329,6 +331,7 @@= =0A if (ax25_process_rx_frame(ax25, skb, type, dama) =3D=3D 0)=0A kfre= e_skb(skb);=0A =0A+ ax25_cb_put(ax25);=0A return 0;=0A }=0A =0A@@ -357,= 11 +360,14 @@=0A sk =3D ax25_find_listener(next_digi, 1, dev, SOCK_SEQPAC= KET);=0A =0A if (sk !=3D NULL) {=0A+ bh_lock_sock(sk);=0A if (sk->sk_ac= k_backlog =3D=3D sk->sk_max_ack_backlog ||=0A (make =3D ax25_make_new= (sk, ax25_dev)) =3D=3D NULL) {=0A if (mine)=0A ax25_return_dm(dev, &= src, &dest, &dp);=0A kfree_skb(skb);=0A+ bh_unlock_sock(sk);=0A+ soc= k_put(sk);=0A =0A return 0;=0A }=0A@@ -374,6 +380,8 @@=0A make->sk_p= air =3D sk;=0A =0A sk->sk_ack_backlog++;=0A+ bh_unlock_sock(sk);=0A+ s= ock_put(sk);=0A } else {=0A if (!mine) {=0A kfree_skb(skb);=0A@@ -429= ,7 +437,7 @@=0A =0A ax25->state =3D AX25_STATE_3;=0A =0A- ax25_insert_sock= et(ax25);=0A+ ax25_cb_add(ax25);=0A =0A ax25_start_heartbeat(ax25);=0A ax= 25_start_t3timer(ax25);=0AOnly in linux-2.6.0-test3.rxq/net/ax25: ax25_in.o= =0Adiff -ru linux-2.6.0-test3/net/ax25/ax25_ip.c linux-2.6.0-test3.rxq/net/= ax25/ax25_ip.c=0A--- linux-2.6.0-test3/net/ax25/ax25_ip.c 2003-08-09 06:34:= 43.000000000 +0200=0A+++ linux-2.6.0-test3.rxq/net/ax25/ax25_ip.c 2003-08-1= 2 23:40:35.000000000 +0200=0A@@ -107,6 +107,7 @@=0A ax25_address *src, *ds= t;=0A ax25_dev *ax25_dev;=0A ax25_route _route, *route =3D &_route;=0A+ a= x25_cb *ax25;=0A =0A dst =3D (ax25_address *)(bp + 1);=0A src =3D (ax25_a= ddress *)(bp + 8);=0A@@ -167,9 +168,14 @@=0A skb_pull(ourskb, AX25_HEADE= R_LEN - 1); /* Keep PID */=0A ourskb->nh.raw =3D ourskb->data;=0A =0A- = ax25_send_frame(ourskb, ax25_dev->values[AX25_VALUES_PACLEN], &src_c,=0A-&= dst_c, route->digipeat, dev);=0A-=0A+ ax25=3Dax25_send_frame(=0A+ o= urskb, =0A+ ax25_dev->values[AX25_VALUES_PACLEN], =0A+ &src_c,= =0A+ &dst_c, route->digipeat, dev);=0A+ if (ax25) {=0A+ ax25_cb_= put(ax25);=0A+ }=0A goto put;=0A }=0A }=0AOnly in linux-2.6.0-test3= .rxq/net/ax25: ax25_ip.o=0Adiff -ru linux-2.6.0-test3/net/ax25/ax25_out.c l= inux-2.6.0-test3.rxq/net/ax25/ax25_out.c=0A--- linux-2.6.0-test3/net/ax25/a= x25_out.c 2003-08-09 06:40:10.000000000 +0200=0A+++ linux-2.6.0-test3.rxq/n= et/ax25/ax25_out.c 2003-08-12 23:40:35.000000000 +0200=0A@@ -71,7 +71,7 @@= =0A =0A if (digi !=3D NULL) {=0A if ((ax25->digipeat =3D kmalloc(sizeof(= ax25_digi), GFP_ATOMIC)) =3D=3D NULL) {=0A- ax25_free_cb(ax25);=0A+ ax2= 5_cb_put(ax25);=0A return NULL;=0A }=0A memcpy(ax25->digipeat, digi,= sizeof(ax25_digi));=0A@@ -93,7 +93,7 @@=0A #endif=0A }=0A =0A- ax25_inser= t_socket(ax25);=0A+ ax25_cb_add(ax25);=0A =0A ax25->state =3D AX25_STATE_1= ;=0A =0AOnly in linux-2.6.0-test3.rxq/net/ax25: ax25_out.o=0Adiff -ru linux= -2.6.0-test3/net/ax25/ax25_route.c linux-2.6.0-test3.rxq/net/ax25/ax25_rout= e.c=0A--- linux-2.6.0-test3/net/ax25/ax25_route.c 2003-08-09 06:38:41.00000= 0000 +0200=0A+++ linux-2.6.0-test3.rxq/net/ax25/ax25_route.c 2003-08-12 23:= 40:35.000000000 +0200=0A@@ -162,6 +162,7 @@=0A if (ax25_rt->digipeat !=3D= NULL)=0A kfree(ax25_rt->digipeat);=0A kfree(ax25_rt);=0A+ return;=0A= }=0A =0A /*=0A@@ -434,8 +435,11 @@=0A ax25_adjust_path(addr, ax25->dig= ipeat);=0A }=0A =0A- if (ax25->sk !=3D NULL)=0A+ if (ax25->sk !=3D NULL) {= =0A+ bh_lock_sock(ax25->sk);=0A ax25->sk->sk_zapped =3D 0;=0A+ bh_unloc= k_sock(ax25->sk);=0A+ }=0A =0A put:=0A ax25_put_route(ax25_rt);=0AOnly in = linux-2.6.0-test3.rxq/net/ax25: ax25_route.o=0Adiff -ru linux-2.6.0-test3/n= et/ax25/ax25_std_in.c linux-2.6.0-test3.rxq/net/ax25/ax25_std_in.c=0A--- li= nux-2.6.0-test3/net/ax25/ax25_std_in.c 2003-08-09 06:39:26.000000000 +0200= =0A+++ linux-2.6.0-test3.rxq/net/ax25/ax25_std_in.c 2003-08-12 23:40:35.000= 000000 +0200=0A@@ -73,10 +73,12 @@=0A ax25->state =3D AX25_STATE_3;=0A= ax25->n2count =3D 0;=0A if (ax25->sk !=3D NULL) {=0A+ bh_lock_soc= k(ax25->sk);=0A ax25->sk->sk_state =3D TCP_ESTABLISHED;=0A /* For W= AIT_SABM connections we will produce an accept ready socket here */=0A = if (!sock_flag(ax25->sk, SOCK_DEAD))=0A ax25->sk->sk_state_change(ax25= ->sk);=0A+ bh_unlock_sock(ax25->sk);=0A }=0A }=0A break;=0AOnly i= n linux-2.6.0-test3.rxq/net/ax25: ax25_std_in.o=0AOnly in linux-2.6.0-test3= .rxq/net/ax25: ax25_std_subr.o=0Adiff -ru linux-2.6.0-test3/net/ax25/ax25_s= td_timer.c linux-2.6.0-test3.rxq/net/ax25/ax25_std_timer.c=0A--- linux-2.6.= 0-test3/net/ax25/ax25_std_timer.c 2003-08-09 06:34:03.000000000 +0200=0A+++= linux-2.6.0-test3.rxq/net/ax25/ax25_std_timer.c 2003-08-12 23:40:35.000000= 000 +0200=0A@@ -33,14 +33,25 @@=0A =0A void ax25_std_heartbeat_expiry(ax25_= cb *ax25)=0A {=0A+ struct sock *sk=3Dax25->sk;=0A+ =0A+ if (sk)=0A+ bh_loc= k_sock(sk);=0A+=0A switch (ax25->state) {=0A case AX25_STATE_0:=0A /* M= agic here: If we listen() and a new link dies before it=0A is accepted= () it isn't 'dead' so doesn't get removed. */=0A- if (!ax25->sk || sock_fl= ag(ax25->sk, SOCK_DESTROY) ||=0A- (ax25->sk->sk_state =3D=3D TCP_LISTE= N &&=0A- sock_flag(ax25->sk, SOCK_DEAD))) {=0A- ax25_destroy_socket= (ax25);=0A+ if (!sk || sock_flag(sk, SOCK_DESTROY) ||=0A+ (sk->sk_sta= te =3D=3D TCP_LISTEN &&=0A+ sock_flag(sk, SOCK_DEAD))) {=0A+ if (sk= ) {=0A+ sock_hold(sk);=0A+ ax25_destroy_socket(ax25);=0A+ bh_unloc= k_sock(sk);=0A+ sock_put(sk);=0A+ } else=0A+ ax25_destroy_socket(ax= 25);=0A return;=0A }=0A break;=0A@@ -50,9 +61,9 @@=0A /*=0A * C= heck the state of the receive buffer.=0A */=0A- if (ax25->sk !=3D NULL)= {=0A- if (atomic_read(&ax25->sk->sk_rmem_alloc) <=0A- (ax25->sk->s= k_rcvbuf / 2) &&=0A+ if (sk !=3D NULL) {=0A+ if (atomic_read(&sk->sk_rme= m_alloc) <=0A+ (sk->sk_rcvbuf / 2) &&=0A (ax25->condition & AX= 25_COND_OWN_RX_BUSY)) {=0A ax25->condition &=3D ~AX25_COND_OWN_RX_BUSY;= =0A ax25->condition &=3D ~AX25_COND_ACK_PENDING;=0A@@ -62,6 +73,9 @@=0A= }=0A }=0A =0A+ if (sk)=0A+ bh_unlock_sock(sk);=0A+=0A ax25_start_hear= tbeat(ax25);=0A }=0A =0A@@ -94,6 +108,7 @@=0A ax25_stop_t3timer(ax25);=0A = =0A if (ax25->sk !=3D NULL) {=0A+ bh_lock_sock(ax25->sk);=0A ax25->sk->= sk_state =3D TCP_CLOSE;=0A ax25->sk->sk_err =3D 0;=0A ax25->s= k->sk_shutdown |=3D SEND_SHUTDOWN;=0A@@ -101,6 +116,7 @@=0A ax25->sk->sk= _state_change(ax25->sk);=0A sock_set_flag(ax25->sk, SOCK_DEAD);=0A }= =0A+ bh_unlock_sock(ax25->sk);=0A }=0A }=0A =0AOnly in linux-2.6.0-test3.= rxq/net/ax25: ax25_std_timer.o=0Adiff -ru linux-2.6.0-test3/net/ax25/ax25_s= ubr.c linux-2.6.0-test3.rxq/net/ax25/ax25_subr.c=0A--- linux-2.6.0-test3/ne= t/ax25/ax25_subr.c 2003-08-09 06:41:35.000000000 +0200=0A+++ linux-2.6.0-te= st3.rxq/net/ax25/ax25_subr.c 2003-08-12 23:40:35.000000000 +0200=0A@@ -158,= 10 +158,10 @@=0A struct sk_buff *skb;=0A unsigned char *dptr;=0A =0A- if= ((skb =3D alloc_skb(AX25_BPQ_HEADER_LEN + ax25_addr_size(ax25->digipeat) += 2, GFP_ATOMIC)) =3D=3D NULL)=0A+ if ((skb =3D alloc_skb(ax25->ax25_dev->de= v->hard_header_len + 2, GFP_ATOMIC)) =3D=3D NULL)=0A return;=0A =0A- skb_= reserve(skb, AX25_BPQ_HEADER_LEN + ax25_addr_size(ax25->digipeat));=0A+ skb= _reserve(skb, ax25->ax25_dev->dev->hard_header_len);=0A =0A skb->nh.raw = =3D skb->data;=0A =0A@@ -202,10 +202,10 @@=0A if (dev =3D=3D NULL)=0A re= turn;=0A =0A- if ((skb =3D alloc_skb(AX25_BPQ_HEADER_LEN + ax25_addr_size(d= igi) + 1, GFP_ATOMIC)) =3D=3D NULL)=0A+ if ((skb =3D alloc_skb(dev->hard_he= ader_len + 1, GFP_ATOMIC)) =3D=3D NULL)=0A return; /* Next SABM will get = DM'd */=0A =0A- skb_reserve(skb, AX25_BPQ_HEADER_LEN + ax25_addr_size(digi)= );=0A+ skb_reserve(skb, dev->hard_header_len);=0A skb->nh.raw =3D skb->dat= a;=0A =0A ax25_digi_invert(digi, &retdigi);=0A@@ -282,6 +282,7 @@=0A ax25= _link_failed(ax25, reason);=0A =0A if (ax25->sk !=3D NULL) {=0A+ bh_lock_= sock(ax25->sk);=0A ax25->sk->sk_state =3D TCP_CLOSE;=0A ax25->sk->s= k_err =3D reason;=0A ax25->sk->sk_shutdown |=3D SEND_SHUTDOWN;=0A@@= -289,5 +290,6 @@=0A ax25->sk->sk_state_change(ax25->sk);=0A sock_set= _flag(ax25->sk, SOCK_DEAD);=0A }=0A+ bh_unlock_sock(ax25->sk);=0A }=0A = }=0AOnly in linux-2.6.0-test3.rxq/net/ax25: ax25_subr.o=0Adiff -ru linux-2.= 6.0-test3/net/ax25/ax25_timer.c linux-2.6.0-test3.rxq/net/ax25/ax25_timer.c= =0A--- linux-2.6.0-test3/net/ax25/ax25_timer.c 2003-08-09 06:38:16.00000000= 0 +0200=0A+++ linux-2.6.0-test3.rxq/net/ax25/ax25_timer.c 2003-08-12 23:40:= 35.000000000 +0200=0A@@ -141,13 +141,10 @@=0A {=0A int proto =3D AX25_PROT= O_STD_SIMPLEX;=0A ax25_cb *ax25 =3D (ax25_cb *)param;=0A- struct sock *sk = =3D ax25->sk;=0A =0A if (ax25->ax25_dev)=0A proto =3D ax25->ax25_dev->va= lues[AX25_VALUES_PROTOCOL];=0A =0A- bh_lock_sock(sk);=0A-=0A switch (proto= ) {=0A case AX25_PROTO_STD_SIMPLEX:=0A case AX25_PROTO_STD_DUPLEX:=0A@@ -= 163,15 +160,12 @@=0A break;=0A #endif=0A }=0A- bh_unlock_sock(sk);=0A }= =0A =0A static void ax25_t1timer_expiry(unsigned long param)=0A {=0A ax25_= cb *ax25 =3D (ax25_cb *)param;=0A- struct sock *sk =3D ax25->sk;=0A =0A- bh= _lock_sock(sk);=0A switch (ax25->ax25_dev->values[AX25_VALUES_PROTOCOL]) {= =0A case AX25_PROTO_STD_SIMPLEX:=0A case AX25_PROTO_STD_DUPLEX:=0A@@ -185= ,15 +179,12 @@=0A break;=0A #endif=0A }=0A- bh_unlock_sock(sk);=0A }=0A = =0A static void ax25_t2timer_expiry(unsigned long param)=0A {=0A ax25_cb *= ax25 =3D (ax25_cb *)param;=0A- struct sock *sk =3D ax25->sk;=0A =0A- bh_loc= k_sock(sk);=0A switch (ax25->ax25_dev->values[AX25_VALUES_PROTOCOL]) {=0A = case AX25_PROTO_STD_SIMPLEX:=0A case AX25_PROTO_STD_DUPLEX:=0A@@ -207,15 = +198,12 @@=0A break;=0A #endif=0A }=0A- bh_unlock_sock(sk);=0A }=0A =0A = static void ax25_t3timer_expiry(unsigned long param)=0A {=0A ax25_cb *ax25= =3D (ax25_cb *)param;=0A- struct sock *sk =3D ax25->sk;=0A =0A- bh_lock_so= ck(sk);=0A switch (ax25->ax25_dev->values[AX25_VALUES_PROTOCOL]) {=0A cas= e AX25_PROTO_STD_SIMPLEX:=0A case AX25_PROTO_STD_DUPLEX:=0A@@ -231,15 +219= ,12 @@=0A break;=0A #endif=0A }=0A- bh_unlock_sock(sk);=0A }=0A =0A stat= ic void ax25_idletimer_expiry(unsigned long param)=0A {=0A ax25_cb *ax25 = =3D (ax25_cb *)param;=0A- struct sock *sk =3D ax25->sk;=0A =0A- bh_lock_soc= k(sk);=0A switch (ax25->ax25_dev->values[AX25_VALUES_PROTOCOL]) {=0A case= AX25_PROTO_STD_SIMPLEX:=0A case AX25_PROTO_STD_DUPLEX:=0A@@ -255,5 +240,4= @@=0A break;=0A #endif=0A }=0A- bh_unlock_sock(sk);=0A }=0AOnly in linu= x-2.6.0-test3.rxq/net/ax25: ax25_timer.o=0AOnly in linux-2.6.0-test3.rxq/ne= t/ax25: ax25_uid.o=0AOnly in linux-2.6.0-test3.rxq/net/ax25: built-in.o=0Ad= iff -ru linux-2.6.0-test3/net/ax25/sysctl_net_ax25.c linux-2.6.0-test3.rxq/= net/ax25/sysctl_net_ax25.c=0A--- linux-2.6.0-test3/net/ax25/sysctl_net_ax25= .c 2003-08-09 06:41:21.000000000 +0200=0A+++ linux-2.6.0-test3.rxq/net/ax25= /sysctl_net_ax25.c 2003-08-12 23:40:35.000000000 +0200=0A@@ -12,20 +12,20 @= @=0A #include =0A #include =0A =0A-static int= min_ipdefmode[1], max_ipdefmode[] =3D {1};=0A-static int min_axdefmode= [1], max_axdefmode[] =3D {1};=0A-static int min_backoff[1], max= _backoff[] =3D {2};=0A-static int min_conmode[1], max_conmode[] =3D {2};= =0A+static int min_ipdefmode[] =3D {0}, max_ipdefmode[] =3D {1};=0A+static = int min_axdefmode[] =3D {0}, max_axdefmode[] =3D {1};=0A+static int min_bac= koff[] =3D {0}, max_backoff[] =3D {2};=0A+static int min_conmode[] =3D {0}= , max_conmode[] =3D {2};=0A static int min_window[] =3D {1}, max_window[]= =3D {7};=0A static int min_ewindow[] =3D {1}, max_ewindow[] =3D {63};=0A = static int min_t1[] =3D {1}, max_t1[] =3D {30 * HZ};=0A static int min_t2[= ] =3D {1}, max_t2[] =3D {20 * HZ};=0A-static int min_t3[1], max_t3[] = =3D {3600 * HZ};=0A-static int min_idle[1], max_idle[] =3D {65535 * HZ};= =0A+static int min_t3[] =3D {0}, max_t3[] =3D {3600 * HZ};=0A+static int m= in_idle[] =3D {0}, max_idle[] =3D {65535 * HZ};=0A static int min_n2[] =3D= {1}, max_n2[] =3D {31};=0A static int min_paclen[] =3D {1}, max_paclen[]= =3D {512};=0A-static int min_proto[1], max_proto[] =3D {3};=0A-static int= min_ds_timeout[1], max_ds_timeout[] =3D {65535 * HZ};=0A+static int min= _proto[] =3D {0}, max_proto[] =3D {3};=0A+static int min_ds_timeout[] =3D = {0}, max_ds_timeout[] =3D {65535 * HZ};=0A =0A static struct ctl_table_head= er *ax25_table_header;=0A =0A@@ -204,8 +204,10 @@=0A for (ax25_table_size = =3D sizeof(ctl_table), ax25_dev =3D ax25_dev_list; ax25_dev !=3D NULL; ax25= _dev =3D ax25_dev->next)=0A ax25_table_size +=3D sizeof(ctl_table);=0A = =0A- if ((ax25_table =3D kmalloc(ax25_table_size, GFP_ATOMIC)) =3D=3D NULL)= =0A+ if ((ax25_table =3D kmalloc(ax25_table_size, GFP_ATOMIC)) =3D=3D NULL)= {=0A+ spin_unlock_bh(&ax25_dev_lock);=0A return;=0A+ }=0A =0A memset(a= x25_table, 0x00, ax25_table_size);=0A =0AOnly in linux-2.6.0-test3.rxq/net/= ax25: sysctl_net_ax25.o=0AOnly in linux-2.6.0-test3.rxq/net/netrom: .af_net= rom.o.cmd=0AOnly in linux-2.6.0-test3.rxq/net/netrom: .built-in.o.cmd=0AOnl= y in linux-2.6.0-test3.rxq/net/netrom: .netrom.ko.cmd=0AOnly in linux-2.6.0= -test3.rxq/net/netrom: .netrom.mod.o.cmd=0AOnly in linux-2.6.0-test3.rxq/ne= t/netrom: .netrom.o.cmd=0AOnly in linux-2.6.0-test3.rxq/net/netrom: .nr_dev= .o.cmd=0AOnly in linux-2.6.0-test3.rxq/net/netrom: .nr_in.o.cmd=0AOnly in l= inux-2.6.0-test3.rxq/net/netrom: .nr_loopback.o.cmd=0AOnly in linux-2.6.0-t= est3.rxq/net/netrom: .nr_out.o.cmd=0AOnly in linux-2.6.0-test3.rxq/net/netr= om: .nr_route.o.cmd=0AOnly in linux-2.6.0-test3.rxq/net/netrom: .nr_subr.o.= cmd=0AOnly in linux-2.6.0-test3.rxq/net/netrom: .nr_timer.o.cmd=0AOnly in l= inux-2.6.0-test3.rxq/net/netrom: .sysctl_net_netrom.o.cmd=0Adiff -ru linux-= 2.6.0-test3/net/netrom/af_netrom.c linux-2.6.0-test3.rxq/net/netrom/af_netr= om.c=0A--- linux-2.6.0-test3/net/netrom/af_netrom.c 2003-08-09 06:36:46.000= 000000 +0200=0A+++ linux-2.6.0-test3.rxq/net/netrom/af_netrom.c 2003-08-12 = 23:40:35.000000000 +0200=0A@@ -147,8 +147,10 @@=0A spin_lock_bh(&nr_list_l= ock);=0A sk_for_each(s, node, &nr_list)=0A if (!ax25cmp(&nr_sk(s)->sourc= e_addr, addr) &&=0A- s->sk_state =3D=3D TCP_LISTEN)=0A+ s->sk_sta= te =3D=3D TCP_LISTEN) {=0A+ bh_lock_sock(s);=0A goto found;=0A+ }= =0A s =3D NULL;=0A found:=0A spin_unlock_bh(&nr_list_lock);=0A@@ -167,8 += 169,10 @@=0A sk_for_each(s, node, &nr_list) {=0A nr_cb *nr =3D nr_sk(s);= =0A =0A- if (nr->my_index =3D=3D index && nr->my_id =3D=3D id)=0A+ if (= nr->my_index =3D=3D index && nr->my_id =3D=3D id) {=0A+ bh_lock_sock(s);= =0A goto found;=0A+ }=0A }=0A s =3D NULL;=0A found:=0A@@ -190,8 +194,= 10 @@=0A nr_cb *nr =3D nr_sk(s);=0A =0A if (nr->your_index =3D=3D ind= ex && nr->your_id =3D=3D id &&=0A- !ax25cmp(&nr->dest_addr, dest))=0A+= !ax25cmp(&nr->dest_addr, dest)) {=0A+ bh_lock_sock(s);=0A go= to found;=0A+ }=0A }=0A s =3D NULL;=0A found:=0A@@ -206,14 +212,17 @@=0A= {=0A unsigned short id =3D circuit;=0A unsigned char i, j;=0A+ struct so= ck *sk;=0A =0A for (;;) {=0A i =3D id / 256;=0A j =3D id % 256;=0A =0A= - if (i !=3D 0 && j !=3D 0)=0A- if (nr_find_socket(i, j) =3D=3D NULL)=0A= + if (i !=3D 0 && j !=3D 0) {=0A+ if ((sk=3Dnr_find_socket(i, j)) =3D=3D= NULL)=0A break;=0A+ bh_unlock_sock(sk);=0A+ }=0A =0A id++;=0A }= =0A@@ -231,7 +240,12 @@=0A */=0A static void nr_destroy_timer(unsigned lon= g data)=0A {=0A- nr_destroy_socket((struct sock *)data);=0A+ struct sock *s= k=3D(struct sock *)data;=0A+ bh_lock_sock(sk);=0A+ sock_hold(sk);=0A+ nr_de= stroy_socket(sk);=0A+ bh_unlock_sock(sk);=0A+ sock_put(sk);=0A }=0A =0A /*= =0A@@ -264,17 +278,20 @@=0A =0A kfree_skb(skb);=0A }=0A+ while ((skb =3D= skb_dequeue(&sk->sk_write_queue)) !=3D NULL) {=0A+ kfree_skb(skb);=0A+ }= =0A =0A if (atomic_read(&sk->sk_wmem_alloc) ||=0A atomic_read(&sk->sk= _rmem_alloc)) {=0A /* Defer: outstanding buffers */=0A init_timer(&sk->= sk_timer);=0A- sk->sk_timer.expires =3D jiffies + 10 * HZ;=0A+ sk->sk_ti= mer.expires =3D jiffies + 2 * HZ;=0A sk->sk_timer.function =3D nr_destro= y_timer;=0A sk->sk_timer.data =3D (unsigned long)sk;=0A add_timer(&= sk->sk_timer);=0A } else=0A- sk_free(sk);=0A+ sock_put(sk);=0A }=0A =0A = /*=0A@@ -388,12 +405,15 @@=0A {=0A struct sock *sk =3D sock->sk;=0A =0A+ l= ock_sock(sk);=0A if (sk->sk_state !=3D TCP_LISTEN) {=0A memset(&nr_sk(sk= )->user_addr, 0, AX25_ADDR_LEN);=0A sk->sk_max_ack_backlog =3D backlog;= =0A sk->sk_state =3D TCP_LISTEN;=0A+ release_sock(sk);=0A re= turn 0;=0A }=0A+ release_sock(sk);=0A =0A return -EOPNOTSUPP;=0A }=0A@@ -= 495,6 +515,7 @@=0A =0A if (sk =3D=3D NULL) return 0;=0A =0A+ lock_sock(sk)= ;=0A nr =3D nr_sk(sk);=0A =0A switch (nr->state) {=0A@@ -528,6 +549,7 @@= =0A }=0A =0A sock->sk =3D NULL; =0A+ release_sock(sk);=0A =0A return 0= ;=0A }=0A@@ -540,21 +562,26 @@=0A struct net_device *dev;=0A ax25_address= *user, *source;=0A =0A- if (!sk->sk_zapped)=0A+ lock_sock(sk);=0A+ if (!sk= ->sk_zapped) {=0A+ release_sock(sk);=0A return -EINVAL;=0A-=0A- if (addr= _len < sizeof(struct sockaddr_ax25) || addr_len > sizeof(struct=0A-full_soc= kaddr_ax25))=0A+ }=0A+ if (addr_len < sizeof(struct sockaddr_ax25) || addr_= len > sizeof(struct full_sockaddr_ax25)) {=0A+ release_sock(sk);=0A retu= rn -EINVAL;=0A-=0A- if (addr_len < (addr->fsa_ax25.sax25_ndigis * sizeof(ax= 25_address) + sizeof(struct sockaddr_ax25)))=0A+ }=0A+ if (addr_len < (addr= ->fsa_ax25.sax25_ndigis * sizeof(ax25_address) + sizeof(struct sockaddr_ax2= 5))) {=0A+ release_sock(sk);=0A return -EINVAL;=0A-=0A- if (addr->fsa_ax= 25.sax25_family !=3D AF_NETROM)=0A+ }=0A+ if (addr->fsa_ax25.sax25_family != =3D AF_NETROM) {=0A+ release_sock(sk);=0A return -EINVAL;=0A-=0A+ }=0A = if ((dev =3D nr_dev_get(&addr->fsa_ax25.sax25_call)) =3D=3D NULL) {=0A SO= CK_DEBUG(sk, "NET/ROM: bind failed: invalid node callsign\n");=0A+ release= _sock(sk);=0A return -EADDRNOTAVAIL;=0A }=0A =0A@@ -562,16 +589,22 @@=0A= * Only the super user can set an arbitrary user callsign.=0A */=0A if= (addr->fsa_ax25.sax25_ndigis =3D=3D 1) {=0A- if (!capable(CAP_NET_BIND_SE= RVICE))=0A+ if (!capable(CAP_NET_BIND_SERVICE)) {=0A+ dev_put(dev);=0A+ = release_sock(sk);=0A return -EACCES;=0A+ }=0A nr->user_addr =3D a= ddr->fsa_digipeater[0];=0A nr->source_addr =3D addr->fsa_ax25.sax25_call;= =0A } else {=0A source =3D &addr->fsa_ax25.sax25_call;=0A =0A if ((use= r =3D ax25_findbyuid(current->euid)) =3D=3D NULL) {=0A- if (ax25_uid_poli= cy && !capable(CAP_NET_BIND_SERVICE))=0A+ if (ax25_uid_policy && !capable= (CAP_NET_BIND_SERVICE)) {=0A+ release_sock(sk);=0A+ dev_put(dev);=0A = return -EPERM;=0A+ }=0A user =3D source;=0A }=0A =0A@@ -583,6 +6= 16,8 @@=0A nr_insert_socket(sk);=0A =0A sk->sk_zapped =3D 0;=0A+ dev_put(= dev);=0A+ release_sock(sk);=0A SOCK_DEBUG(sk, "NET/ROM: socket is bound\n"= );=0A return 0;=0A }=0A@@ -596,39 +631,50 @@=0A ax25_address *user, *sour= ce =3D NULL;=0A struct net_device *dev;=0A =0A+ lock_sock(sk);=0A if (sk-= >sk_state =3D=3D TCP_ESTABLISHED && sock->state =3D=3D SS_CONNECTING) {=0A = sock->state =3D SS_CONNECTED;=0A+ release_sock(sk);=0A return 0; /* Co= nnect completed during a ERESTARTSYS event */=0A }=0A =0A if (sk->sk_stat= e =3D=3D TCP_CLOSE && sock->state =3D=3D SS_CONNECTING) {=0A sock->state = =3D SS_UNCONNECTED;=0A+ release_sock(sk);=0A return -ECONNREFUSED;=0A }= =0A =0A- if (sk->sk_state =3D=3D TCP_ESTABLISHED)=0A+ if (sk->sk_state =3D= =3D TCP_ESTABLISHED) {=0A+ release_sock(sk);=0A return -EISCONN; /* No r= econnect on a seqpacket socket */=0A+ }=0A =0A sk->sk_state =3D TCP_CLOS= E; =0A sock->state =3D SS_UNCONNECTED;=0A =0A- if (addr_len !=3D sizeof(st= ruct sockaddr_ax25) && addr_len !=3D sizeof(struct full_sockaddr_ax25))=0A+= if (addr_len !=3D sizeof(struct sockaddr_ax25) && addr_len !=3D sizeof(str= uct full_sockaddr_ax25)) {=0A+ release_sock(sk);=0A return -EINVAL;=0A-= =0A- if (addr->sax25_family !=3D AF_NETROM)=0A+ }=0A+ if (addr->sax25_famil= y !=3D AF_NETROM) {=0A+ release_sock(sk);=0A return -EINVAL;=0A-=0A+ }= =0A if (sk->sk_zapped) { /* Must bind first - autobinding in this may or m= ay not work */=0A sk->sk_zapped =3D 0;=0A =0A- if ((dev =3D nr_dev_first= ()) =3D=3D NULL)=0A+ if ((dev =3D nr_dev_first()) =3D=3D NULL) {=0A+ rel= ease_sock(sk);=0A return -ENETUNREACH;=0A-=0A+ }=0A source =3D (ax25_= address *)dev->dev_addr;=0A =0A if ((user =3D ax25_findbyuid(current->eui= d)) =3D=3D NULL) {=0A- if (ax25_uid_policy && !capable(CAP_NET_ADMIN))=0A= + if (ax25_uid_policy && !capable(CAP_NET_ADMIN)) {=0A+ dev_put(dev);= =0A+ release_sock(sk);=0A return -EPERM;=0A+ }=0A user =3D sour= ce;=0A }=0A =0A@@ -636,12 +682,15 @@=0A nr->source_addr =3D *source;=0A= nr->device =3D dev;=0A =0A+ dev_put(dev);=0A nr_insert_socket(sk= ); /* Finish the bind */=0A }=0A =0A nr->dest_addr =3D addr->sax25_call;= =0A =0A+ release_sock(sk);=0A circuit =3D nr_find_next_circuit();=0A+ lock= _sock(sk);=0A =0A nr->my_index =3D circuit / 256;=0A nr->my_id =3D cir= cuit % 256;=0A@@ -659,8 +708,10 @@=0A nr_start_heartbeat(sk);=0A =0A /* N= ow the loop */=0A- if (sk->sk_state !=3D TCP_ESTABLISHED && (flags & O_NONB= LOCK))=0A+ if (sk->sk_state !=3D TCP_ESTABLISHED && (flags & O_NONBLOCK)) {= =0A+ release_sock(sk);=0A return -EINPROGRESS;=0A+ }=0A =0A /*=0A *= A Connect Ack with Choke or timeout or failed routing will go to=0A@@ -675= ,8 +726,10 @@=0A set_current_state(TASK_INTERRUPTIBLE);=0A if (sk->sk= _state !=3D TCP_SYN_SENT)=0A break;=0A+ release_sock(sk);=0A if (!= signal_pending(tsk)) {=0A schedule();=0A+ lock_sock(sk);=0A cont= inue;=0A }=0A return -ERESTARTSYS;=0A@@ -687,10 +740,12 @@=0A =0A if= (sk->sk_state !=3D TCP_ESTABLISHED) {=0A sock->state =3D SS_UNCONNECTED;= =0A+ release_sock(sk);=0A return sock_error(sk); /* Always set at this p= oint */=0A }=0A =0A sock->state =3D SS_CONNECTED;=0A+ release_sock(sk);= =0A =0A return 0;=0A }=0A@@ -753,6 +808,7 @@=0A newsock->sk =3D newsk;=0A= =0A out:=0A+ release_sock(sk);=0A return err;=0A }=0A =0A@@ -763,9 +819,1= 2 @@=0A struct sock *sk =3D sock->sk;=0A nr_cb *nr =3D nr_sk(sk);=0A =0A+= lock_sock(sk);=0A if (peer !=3D 0) {=0A- if (sk->sk_state !=3D TCP_ESTAB= LISHED)=0A+ if (sk->sk_state !=3D TCP_ESTABLISHED) {=0A+ release_sock(sk= );=0A return -ENOTCONN;=0A+ }=0A sax->fsa_ax25.sax25_family =3D AF_NE= TROM;=0A sax->fsa_ax25.sax25_ndigis =3D 1;=0A sax->fsa_ax25.sax25_call = =3D nr->user_addr;=0A@@ -777,6 +836,7 @@=0A sax->fsa_ax25.sax25_call = =3D nr->source_addr;=0A *uaddr_len =3D sizeof(struct sockaddr_ax25);=0A = }=0A+ release_sock(sk);=0A =0A return 0;=0A }=0A@@ -790,6 +850,7 @@=0A un= signed short circuit_index, circuit_id;=0A unsigned short peer_circuit_ind= ex, peer_circuit_id;=0A unsigned short frametype, flags, window, timeout;= =0A+ int ret;=0A =0A skb->sk =3D NULL; /* Initially we don't know who it'= s for */=0A =0A@@ -847,7 +908,9 @@=0A else=0A nr_sk(sk)->bpqext =3D 0;= =0A =0A- return nr_process_rx_frame(sk, skb);=0A+ ret =3D nr_process_rx_f= rame(sk, skb);=0A+ bh_unlock_sock(sk);=0A+ return ret;=0A }=0A =0A /*= =0A@@ -877,6 +940,8 @@=0A if (!sk || sk->sk_ack_backlog =3D=3D sk->sk_max_= ack_backlog ||=0A (make =3D nr_make_new(sk)) =3D=3D NULL) {=0A nr_tr= ansmit_refusal(skb, 0);=0A+ if (sk)=0A+ bh_unlock_sock(sk);=0A return = 0;=0A }=0A =0A@@ -894,7 +959,9 @@=0A nr_make->your_index =3D circuit_ind= ex;=0A nr_make->your_id =3D circuit_id;=0A =0A+ bh_unlock_sock(sk);=0A= circuit =3D nr_find_next_circuit();=0A+ bh_lock_sock(sk);=0A =0A nr_make= ->my_index =3D circuit / 256;=0A nr_make->my_id =3D circuit % 256= ;=0A@@ -936,6 +1003,7 @@=0A if (!sock_flag(sk, SOCK_DEAD))=0A sk->sk_dat= a_ready(sk, skb->len);=0A =0A+ bh_unlock_sock(sk);=0A return 1;=0A }=0A = =0A@@ -954,28 +1022,42 @@=0A if (msg->msg_flags & ~(MSG_DONTWAIT|MSG_EOR))= =0A return -EINVAL;=0A =0A- if (sk->sk_zapped)=0A- return -EADDRNOTAVAIL= ;=0A+ lock_sock(sk);=0A+ if (sk->sk_zapped) {=0A+ err =3D -EADDRNOTAVAIL;= =0A+ goto out;=0A+ }=0A =0A if (sk->sk_shutdown & SEND_SHUTDOWN) {=0A s= end_sig(SIGPIPE, current, 0);=0A- return -EPIPE;=0A+ err =3D -EPIPE;=0A+ = goto out;=0A }=0A =0A- if (nr->device =3D=3D NULL)=0A- return -ENETUNREA= CH;=0A+ if (nr->device =3D=3D NULL) {=0A+ err =3D -ENETUNREACH;=0A+ goto = out;=0A+ }=0A =0A if (usax) {=0A- if (msg->msg_namelen < sizeof(sax))=0A-= return -EINVAL;=0A+ if (msg->msg_namelen < sizeof(sax)) {=0A+ err =3D= -EINVAL;=0A+ goto out;=0A+ }=0A sax =3D *usax;=0A- if (ax25cmp(&nr->= dest_addr, &sax.sax25_call) !=3D 0)=0A- return -EISCONN;=0A- if (sax.sax= 25_family !=3D AF_NETROM)=0A- return -EINVAL;=0A+ if (ax25cmp(&nr->dest_= addr, &sax.sax25_call) !=3D 0) {=0A+ err =3D -EISCONN;=0A+ goto out;=0A= + }=0A+ if (sax.sax25_family !=3D AF_NETROM) {=0A+ err =3D -EINVAL;=0A+= goto out;=0A+ }=0A } else {=0A- if (sk->sk_state !=3D TCP_ESTABLISHED= )=0A- return -ENOTCONN;=0A+ if (sk->sk_state !=3D TCP_ESTABLISHED) {=0A+= err =3D -ENOTCONN;=0A+ goto out;=0A+ }=0A sax.sax25_family =3D AF_N= ETROM;=0A sax.sax25_call =3D nr->dest_addr;=0A }=0A@@ -984,10 +1066,10= @@=0A =0A /* Build a packet */=0A SOCK_DEBUG(sk, "NET/ROM: sendto: build= ing packet.\n");=0A- size =3D len + AX25_BPQ_HEADER_LEN + AX25_MAX_HEADER_L= EN + NR_NETWORK_LEN + NR_TRANSPORT_LEN;=0A+ size =3D len + NR_NETWORK_LEN += NR_TRANSPORT_LEN;=0A =0A if ((skb =3D sock_alloc_send_skb(sk, size, msg->= msg_flags & MSG_DONTWAIT, &err)) =3D=3D NULL)=0A- return err;=0A+ goto ou= t;=0A =0A skb_reserve(skb, size - len);=0A =0A@@ -1022,12 +1104,16 @@=0A = =0A if (sk->sk_state !=3D TCP_ESTABLISHED) {=0A kfree_skb(skb);=0A- ret= urn -ENOTCONN;=0A+ err =3D -ENOTCONN;=0A+ goto out;=0A }=0A =0A nr_outp= ut(sk, skb); /* Shove it onto the queue */=0A =0A- return len;=0A+ err =3D = len;=0A+out:=0A+ release_sock(sk);=0A+ return err;=0A }=0A =0A static int n= r_recvmsg(struct kiocb *iocb, struct socket *sock,=0A@@ -1044,12 +1130,17 @= @=0A * us! We do one quick check first though=0A */=0A =0A- if (sk->sk_= state !=3D TCP_ESTABLISHED)=0A+ lock_sock(sk);=0A+ if (sk->sk_state !=3D TC= P_ESTABLISHED) {=0A+ release_sock(sk);=0A return -ENOTCONN;=0A+ }=0A =0A= /* Now we can treat all alike */=0A- if ((skb =3D skb_recv_datagram(sk, f= lags & ~MSG_DONTWAIT, flags & MSG_DONTWAIT, &er)) =3D=3D NULL)=0A+ if ((skb= =3D skb_recv_datagram(sk, flags & ~MSG_DONTWAIT, flags & MSG_DONTWAIT, &er= )) =3D=3D NULL) {=0A+ release_sock(sk);=0A return er;=0A+ }=0A =0A skb-= >h.raw =3D skb->data;=0A copied =3D skb->len;=0A@@ -1070,6 +1161,7 @@= =0A =0A skb_free_datagram(sk, skb);=0A =0A+ release_sock(sk);=0A return c= opied;=0A }=0A =0A@@ -1077,13 +1169,16 @@=0A static int nr_ioctl(struct soc= ket *sock, unsigned int cmd, unsigned long arg)=0A {=0A struct sock *sk = =3D sock->sk;=0A+ int ret;=0A =0A+ lock_sock(sk);=0A switch (cmd) {=0A ca= se TIOCOUTQ: {=0A long amount;=0A amount =3D sk->sk_sndbuf - atomic_rea= d(&sk->sk_wmem_alloc);=0A if (amount < 0)=0A amount =3D 0;=0A+ releas= e_sock(sk);=0A return put_user(amount, (int *)arg);=0A }=0A =0A@@ -1093,= 15 +1188,21 @@=0A /* These two are safe on a single CPU system as only us= er tasks fiddle here */=0A if ((skb =3D skb_peek(&sk->sk_receive_queue)) = !=3D NULL)=0A amount =3D skb->len;=0A+ release_sock(sk);=0A return pu= t_user(amount, (int *)arg);=0A }=0A =0A case SIOCGSTAMP:=0A if (sk !=3D= NULL) {=0A- if (!sk->sk_stamp.tv_sec)=0A+ if (!sk->sk_stamp.tv_sec) {= =0A+ release_sock(sk);=0A return -ENOENT;=0A- return copy_to_user(= (void *)arg, &sk->sk_stamp, sizeof(struct timeval)) ? -EFAULT : 0;=0A+ }= =0A+ ret =3D copy_to_user((void *)arg, &sk->sk_stamp, sizeof(struct timev= al)) ? -EFAULT : 0;=0A+ release_sock(sk);=0A+ return ret;=0A }=0A+ r= elease_sock(sk);=0A return -EINVAL;=0A =0A case SIOCGIFADDR:=0A@@ -1114,= 17 +1215,21 @@=0A case SIOCSIFNETMASK:=0A case SIOCGIFMETRIC:=0A case SI= OCSIFMETRIC:=0A+ release_sock(sk);=0A return -EINVAL;=0A =0A case SIOCA= DDRT:=0A case SIOCDELRT:=0A case SIOCNRDECOBS:=0A+ release_sock(sk);=0A = if (!capable(CAP_NET_ADMIN)) return -EPERM;=0A return nr_rt_ioctl(cmd, = (void *)arg);=0A =0A default:=0A+ release_sock(sk);=0A return dev_ioctl= (cmd, (void *)arg);=0A }=0A+ release_sock(sk);=0A =0A return 0;=0A }=0A@@= -1144,7 +1249,9 @@=0A len +=3D sprintf(buffer, "user_addr dest_node src_n= ode dev my your st vs vr va t1 t2 t4 idle n2 wn= d Snd-Q Rcv-Q inode\n");=0A =0A sk_for_each(s, node, &nr_list) {=0A- nr_c= b *nr =3D nr_sk(s);=0A+ nr_cb *nr;=0A+ bh_lock_sock(s);=0A+ nr =3D nr_sk= (s);=0A =0A if ((dev =3D nr->device) =3D=3D NULL)=0A devname =3D "???"= ;=0A@@ -1187,7 +1294,7 @@=0A len =3D 0;=0A begin =3D pos;=0A }=0A= -=0A+ bh_unlock_sock(s);=0A if (pos > offset + length)=0A break;=0A = }=0A@@ -1256,6 +1363,7 @@=0A =0A for (i =3D 0; i < nr_ndevs; i++) {=0A s= printf(dev_nr[i].name, "nr%d", i);=0A+ dev_nr[i].base_addr =3D i;=0A dev= _nr[i].init =3D nr_init;=0A register_netdev(&dev_nr[i]);=0A }=0A@@ -1300= ,23 +1408,23 @@=0A =0A nr_rt_free();=0A =0A- ax25_protocol_release(AX25_P_= NETROM);=0A+#ifdef CONFIG_SYSCTL=0A+ nr_unregister_sysctl();=0A+#endif=0A+= =0A ax25_linkfail_release(nr_link_failed);=0A+ ax25_protocol_release(AX25_= P_NETROM);=0A =0A unregister_netdevice_notifier(&nr_dev_notifier);=0A =0A-= #ifdef CONFIG_SYSCTL=0A- nr_unregister_sysctl();=0A-#endif=0A sock_unregis= ter(PF_NETROM);=0A =0A for (i =3D 0; i < nr_ndevs; i++) {=0A if (dev_nr[= i].priv !=3D NULL) {=0A+ unregister_netdev(&dev_nr[i]);=0A kfree(dev_n= r[i].priv);=0A dev_nr[i].priv =3D NULL;=0A- unregister_netdev(&dev_nr[= i]);=0A }=0A- kfree(dev_nr[i].name);=0A }=0A =0A kfree(dev_nr);=0AOnly= in linux-2.6.0-test3.rxq/net/netrom: af_netrom.o=0AOnly in linux-2.6.0-tes= t3.rxq/net/netrom: built-in.o=0AOnly in linux-2.6.0-test3.rxq/net/netrom: n= etrom.ko=0AOnly in linux-2.6.0-test3.rxq/net/netrom: netrom.mod.c=0AOnly in= linux-2.6.0-test3.rxq/net/netrom: netrom.mod.o=0AOnly in linux-2.6.0-test3= .rxq/net/netrom: netrom.o=0Adiff -ru linux-2.6.0-test3/net/netrom/nr_dev.c = linux-2.6.0-test3.rxq/net/netrom/nr_dev.c=0A--- linux-2.6.0-test3/net/netro= m/nr_dev.c 2003-08-09 06:41:27.000000000 +0200=0A+++ linux-2.6.0-test3.rxq/= net/netrom/nr_dev.c 2003-08-12 23:40:35.000000000 +0200=0A@@ -159,11 +159,1= 3 @@=0A {=0A struct sockaddr *sa =3D addr;=0A =0A- ax25_listen_release((ax= 25_address *)dev->dev_addr, NULL);=0A+ if (dev->flags & IFF_UP)=0A+ ax25_l= isten_release((ax25_address *)dev->dev_addr, NULL);=0A =0A memcpy(dev->dev= _addr, sa->sa_data, dev->addr_len);=0A =0A- ax25_listen_register((ax25_addr= ess *)dev->dev_addr, NULL);=0A+ if (dev->flags & IFF_UP)=0A+ ax25_listen_r= egister((ax25_address *)dev->dev_addr, NULL);=0A =0A return 0;=0A }=0A@@ -= 177,8 +179,8 @@=0A =0A static int nr_close(struct net_device *dev)=0A {=0A-= netif_stop_queue(dev);=0A ax25_listen_release((ax25_address *)dev->dev_ad= dr, NULL);=0A+ netif_stop_queue(dev);=0A return 0;=0A }=0A =0A@@ -197,16 += 199,16 @@=0A =0A int nr_init(struct net_device *dev)=0A {=0A- SET_MODULE_OW= NER(dev);=0A dev->mtu =3D NR_MAX_PACKET_SIZE;=0A dev->hard_start_xmit = =3D nr_xmit;=0A dev->open =3D nr_open;=0A dev->stop =3D nr_close;=0A = =0A dev->hard_header =3D nr_header;=0A- dev->hard_header_len =3D AX25_BPQ_= HEADER_LEN + AX25_MAX_HEADER_LEN + NR_NETWORK_LEN + NR_TRANSPORT_LEN;=0A+ d= ev->hard_header_len =3D NR_NETWORK_LEN + NR_TRANSPORT_LEN;=0A dev->addr_le= n =3D AX25_ADDR_LEN;=0A dev->type =3D ARPHRD_NETROM;=0A+ dev->tx_queue_l= en =3D 40;=0A dev->rebuild_header =3D nr_rebuild_header;=0A dev->set_mac_= address =3D nr_set_mac_address;=0A =0AOnly in linux-2.6.0-test3.rxq/net/= netrom: nr_dev.o=0Adiff -ru linux-2.6.0-test3/net/netrom/nr_in.c linux-2.6.= 0-test3.rxq/net/netrom/nr_in.c=0A--- linux-2.6.0-test3/net/netrom/nr_in.c 2= 003-08-09 06:34:46.000000000 +0200=0A+++ linux-2.6.0-test3.rxq/net/netrom/n= r_in.c 2003-08-12 23:40:35.000000000 +0200=0A@@ -74,6 +74,7 @@=0A static in= t nr_state1_machine(struct sock *sk, struct sk_buff *skb,=0A int frametype= )=0A {=0A+ bh_lock_sock(sk);=0A switch (frametype) {=0A case NR_CONNACK: = {=0A nr_cb *nr =3D nr_sk(sk);=0A@@ -102,6 +103,7 @@=0A default:=0A bre= ak;=0A }=0A+ bh_unlock_sock(sk);=0A =0A return 0;=0A }=0A@@ -114,6 +116,7= @@=0A static int nr_state2_machine(struct sock *sk, struct sk_buff *skb,= =0A int frametype)=0A {=0A+ bh_lock_sock(sk);=0A switch (frametype) {=0A = case NR_CONNACK | NR_CHOKE_FLAG:=0A nr_disconnect(sk, ECONNRESET);=0A@@ = -129,6 +132,7 @@=0A default:=0A break;=0A }=0A+ bh_unlock_sock(sk);=0A = =0A return 0;=0A }=0A@@ -150,6 +154,7 @@=0A nr =3D skb->data[18];=0A ns = =3D skb->data[17];=0A =0A+ bh_lock_sock(sk);=0A switch (frametype) {=0A c= ase NR_CONNREQ:=0A nr_write_internal(sk, NR_CONNACK);=0A@@ -260,6 +265,7 = @@=0A default:=0A break;=0A }=0A+ bh_unlock_sock(sk);=0A =0A return qu= eued;=0A }=0AOnly in linux-2.6.0-test3.rxq/net/netrom: nr_in.o=0AOnly in li= nux-2.6.0-test3.rxq/net/netrom: nr_loopback.o=0AOnly in linux-2.6.0-test3.r= xq/net/netrom: nr_out.o=0Adiff -ru linux-2.6.0-test3/net/netrom/nr_route.c = linux-2.6.0-test3.rxq/net/netrom/nr_route.c=0A--- linux-2.6.0-test3/net/net= rom/nr_route.c 2003-08-09 06:42:17.000000000 +0200=0A+++ linux-2.6.0-test3.= rxq/net/netrom/nr_route.c 2003-08-12 23:40:35.000000000 +0200=0A@@ -39,10 += 39,45 @@=0A =0A static unsigned int nr_neigh_no =3D 1;=0A =0A-static struct= nr_node *nr_node_list;=0A-static spinlock_t nr_node_lock;=0A-static struc= t nr_neigh *nr_neigh_list;=0A-static spinlock_t nr_neigh_lock;=0A+HLIST_HEA= D(nr_node_list);=0A+spinlock_t nr_node_list_lock =3D SPIN_LOCK_UNLOCKED;=0A= +HLIST_HEAD(nr_neigh_list);=0A+spinlock_t nr_neigh_list_lock =3D SPIN_LOCK_= UNLOCKED;=0A+=0A+struct nr_node *nr_node_get(ax25_address *callsign)=0A+{= =0A+ struct nr_node *found =3D NULL;=0A+ struct nr_node *nr_node;=0A+ struc= t hlist_node *node;=0A+=0A+ spin_lock_bh(&nr_node_list_lock);=0A+ nr_node_f= or_each(nr_node, node, &nr_node_list)=0A+ if (ax25cmp(callsign, &nr_node->= callsign) =3D=3D 0) {=0A+ nr_node_hold(nr_node);=0A+ found =3D nr_node;= =0A+ break;=0A+ }=0A+ spin_unlock_bh(&nr_node_list_lock);=0A+ return fou= nd;=0A+}=0A+=0A+struct nr_neigh *nr_neigh_get_dev(ax25_address *callsign, s= truct net_device *dev)=0A+{=0A+ struct nr_neigh *found =3D NULL;=0A+ struct= nr_neigh *nr_neigh;=0A+ struct hlist_node *node;=0A+=0A+ spin_lock_bh(&nr_= neigh_list_lock);=0A+ nr_neigh_for_each(nr_neigh, node, &nr_neigh_list)=0A+= if (ax25cmp(callsign, &nr_neigh->callsign) =3D=3D 0 &&=0A+ nr_neigh-= >dev =3D=3D dev) {=0A+ nr_neigh_hold(nr_neigh);=0A+ found =3D nr_neigh;= =0A+ break;=0A+ }=0A+ spin_unlock_bh(&nr_neigh_list_lock);=0A+ return fo= und;=0A+}=0A =0A static void nr_remove_neigh(struct nr_neigh *);=0A =0A@@ -= 57,17 +92,16 @@=0A struct nr_neigh *nr_neigh;=0A struct nr_route nr_route= ;=0A int i, found;=0A+ struct net_device *odev;=0A =0A- if (nr_dev_get(nr)= !=3D NULL) /* Can't add routes to ourself */=0A+ if ((odev=3Dnr_dev_get(nr= )) !=3D NULL) { /* Can't add routes to ourself */=0A+ dev_put(odev);=0A = return -EINVAL;=0A+ }=0A =0A- for (nr_node =3D nr_node_list; nr_node !=3D N= ULL; nr_node =3D nr_node->next)=0A- if (ax25cmp(nr, &nr_node->callsign) = =3D=3D 0)=0A- break;=0A+ nr_node =3D nr_node_get(nr);=0A =0A- for (nr_nei= gh =3D nr_neigh_list; nr_neigh !=3D NULL; nr_neigh =3D nr_neigh->next)=0A- = if (ax25cmp(ax25, &nr_neigh->callsign) =3D=3D 0 && nr_neigh->dev =3D=3D de= v)=0A- break;=0A+ nr_neigh =3D nr_neigh_get_dev(ax25, dev);=0A =0A /*=0A= * The L2 link to a neighbour has failed in the past=0A@@ -76,24 +110,36 = @@=0A * routes now (and not wait for a node broadcast).=0A */=0A if (n= r_neigh !=3D NULL && nr_neigh->failed !=3D 0 && quality =3D=3D 0) {=0A- st= ruct nr_node *node;=0A+ struct nr_node *nr_nodet;=0A+ struct hlist_node *= node;=0A =0A- for (node =3D nr_node_list; node !=3D NULL; node =3D node->n= ext)=0A- for (i =3D 0; i < node->count; i++)=0A- if (node->routes[i].n= eighbour =3D=3D nr_neigh)=0A- if (i < node->which)=0A- node->which= =3D i;=0A+ spin_lock_bh(&nr_node_list_lock);=0A+ nr_node_for_each(nr_nod= et, node, &nr_node_list) {=0A+ nr_node_lock(nr_nodet);=0A+ for (i =3D 0= ; i < nr_nodet->count; i++)=0A+ if (nr_nodet->routes[i].neighbour =3D=3D= nr_neigh)=0A+ if (i < nr_nodet->which)=0A+ nr_nodet->which =3D i;= =0A+ nr_node_unlock(nr_nodet);=0A+ }=0A+ spin_unlock_bh(&nr_node_list_l= ock);=0A }=0A =0A if (nr_neigh !=3D NULL)=0A nr_neigh->failed =3D 0;=0A= =0A- if (quality =3D=3D 0 && nr_neigh !=3D NULL && nr_node !=3D NULL)=0A+ = if (quality =3D=3D 0 && nr_neigh !=3D NULL && nr_node !=3D NULL) {=0A+ nr_= neigh_put(nr_neigh);=0A+ nr_node_put(nr_node);=0A return 0;=0A+ }=0A =0A= if (nr_neigh =3D=3D NULL) {=0A- if ((nr_neigh =3D kmalloc(sizeof(*nr_nei= gh), GFP_ATOMIC)) =3D=3D NULL)=0A+ if ((nr_neigh =3D kmalloc(sizeof(*nr_ne= igh), GFP_ATOMIC)) =3D=3D NULL) {=0A+ if (nr_node)=0A+ nr_node_put(nr_= node);=0A return -ENOMEM;=0A+ }=0A =0A nr_neigh->callsign =3D *ax25;= =0A nr_neigh->digipeat =3D NULL;=0A@@ -104,48 +150,58 @@=0A nr_neigh->c= ount =3D 0;=0A nr_neigh->number =3D nr_neigh_no++;=0A nr_neigh->fa= iled =3D 0;=0A+ atomic_set(&nr_neigh->refcount, 1);=0A =0A if (ax25_di= gi !=3D NULL && ax25_digi->ndigi > 0) {=0A if ((nr_neigh->digipeat =3D k= malloc(sizeof(*ax25_digi), GFP_KERNEL)) =3D=3D NULL) {=0A kfree(nr_neig= h);=0A+ if (nr_node)=0A+ nr_node_put(nr_node);=0A return -ENOMEM= ;=0A }=0A memcpy(nr_neigh->digipeat, ax25_digi,=0A sizeof(*ax25_= digi));=0A }=0A =0A- spin_lock_bh(&nr_neigh_lock);=0A- nr_neigh->next = =3D nr_neigh_list;=0A- nr_neigh_list =3D nr_neigh;=0A- spin_unlock_bh(&n= r_neigh_lock);=0A+ spin_lock_bh(&nr_neigh_list_lock);=0A+ hlist_add_head(= &nr_neigh->neigh_node, &nr_neigh_list);=0A+ nr_neigh_hold(nr_neigh);=0A+ = spin_unlock_bh(&nr_neigh_list_lock);=0A }=0A =0A if (quality !=3D 0 && ax= 25cmp(nr, ax25) =3D=3D 0 && !nr_neigh->locked)=0A nr_neigh->quality =3D q= uality;=0A =0A if (nr_node =3D=3D NULL) {=0A- if ((nr_node =3D kmalloc(si= zeof(*nr_node), GFP_ATOMIC)) =3D=3D NULL)=0A+ if ((nr_node =3D kmalloc(siz= eof(*nr_node), GFP_ATOMIC)) =3D=3D NULL) {=0A+ if (nr_neigh)=0A+ nr_ne= igh_put(nr_neigh);=0A return -ENOMEM;=0A+ }=0A =0A nr_node->callsign = =3D *nr;=0A strcpy(nr_node->mnemonic, mnemonic);=0A =0A nr_node->which = =3D 0;=0A nr_node->count =3D 1;=0A+ atomic_set(&nr_node->refcount, 1);= =0A+ nr_node->node_lock =3D SPIN_LOCK_UNLOCKED;=0A =0A nr_node->routes[0= ].quality =3D quality;=0A nr_node->routes[0].obs_count =3D obs_count;= =0A nr_node->routes[0].neighbour =3D nr_neigh;=0A =0A- spin_lock_bh(&nr_= node_lock);=0A- nr_node->next =3D nr_node_list;=0A- nr_node_list =3D nr_= node;=0A- spin_unlock_bh(&nr_node_lock);=0A-=0A+ nr_neigh_hold(nr_neigh);= =0A nr_neigh->count++;=0A =0A+ spin_lock_bh(&nr_node_list_lock);=0A+ hl= ist_add_head(&nr_node->node_node, &nr_node_list);=0A+ /* refcount initiali= zed at 1 */=0A+ spin_unlock_bh(&nr_node_list_lock);=0A+=0A return 0;=0A = }=0A+ nr_node_lock(nr_node);=0A =0A if (quality !=3D 0)=0A strcpy(nr_no= de->mnemonic, mnemonic);=0A@@ -171,11 +227,13 @@=0A =0A nr_node->which++= ;=0A nr_node->count++;=0A+ nr_neigh_hold(nr_neigh);=0A nr_neigh->co= unt++;=0A } else {=0A /* It must be better than the worst */=0A if = (quality > nr_node->routes[2].quality) {=0A nr_node->routes[2].neighbou= r->count--;=0A+ nr_neigh_put(nr_node->routes[2].neighbour);=0A =0A i= f (nr_node->routes[2].neighbour->count =3D=3D 0 && !nr_node->routes[2].neig= hbour->locked)=0A nr_remove_neigh(nr_node->routes[2].neighbour);=0A@@ = -184,6 +242,7 @@=0A nr_node->routes[2].obs_count =3D obs_count;=0A = nr_node->routes[2].neighbour =3D nr_neigh;=0A =0A+ nr_neigh_hold(nr_neig= h);=0A nr_neigh->count++;=0A }=0A }=0A@@ -244,62 +303,42 @@=0A }= =0A }=0A =0A+ nr_neigh_put(nr_neigh);=0A+ nr_node_unlock(nr_node);=0A+ nr_= node_put(nr_node);=0A return 0;=0A }=0A =0A-static void nr_remove_node(str= uct nr_node *nr_node)=0A+static inline void __nr_remove_node(struct nr_node= *nr_node)=0A {=0A- struct nr_node *s;=0A-=0A- spin_lock_bh(&nr_node_lock);= =0A- if ((s =3D nr_node_list) =3D=3D nr_node) {=0A- nr_node_list =3D nr_no= de->next;=0A- spin_unlock_bh(&nr_node_lock);=0A- kfree(nr_node);=0A- ret= urn;=0A- }=0A-=0A- while (s !=3D NULL && s->next !=3D NULL) {=0A- if (s->n= ext =3D=3D nr_node) {=0A- s->next =3D nr_node->next;=0A- spin_unlock_bh= (&nr_node_lock);=0A- kfree(nr_node);=0A- return;=0A- }=0A+ hlist_del_i= nit(&nr_node->node_node);=0A+ nr_node_put(nr_node);=0A+}=0A =0A- s =3D s->= next;=0A- }=0A+#define nr_remove_node_locked(__node) \=0A+ __nr_remove_node= (__node)=0A =0A- spin_unlock_bh(&nr_node_lock);=0A+static void nr_remove_no= de(struct nr_node *nr_node)=0A+{=0A+ spin_lock_bh(&nr_node_list_lock);=0A+ = __nr_remove_node(nr_node);=0A+ spin_unlock_bh(&nr_node_list_lock);=0A }=0A = =0A-static void nr_remove_neigh(struct nr_neigh *nr_neigh)=0A+static inline= void __nr_remove_neigh(struct nr_neigh *nr_neigh)=0A {=0A- struct nr_neigh= *s;=0A+ hlist_del_init(&nr_neigh->neigh_node);=0A+ nr_neigh_put(nr_neigh);= =0A+}=0A =0A- spin_lock_bh(&nr_neigh_lock);=0A- if ((s =3D nr_neigh_list) = =3D=3D nr_neigh) {=0A- nr_neigh_list =3D nr_neigh->next;=0A- spin_unlock_= bh(&nr_neigh_lock);=0A- if (nr_neigh->digipeat !=3D NULL)=0A- kfree(nr_n= eigh->digipeat);=0A- kfree(nr_neigh);=0A- return;=0A- }=0A+#define nr_rem= ove_neigh_locked(__neigh) \=0A+ __nr_remove_neigh(__neigh)=0A =0A- while (s= !=3D NULL && s->next !=3D NULL) {=0A- if (s->next =3D=3D nr_neigh) {=0A- = s->next =3D nr_neigh->next;=0A- spin_unlock_bh(&nr_neigh_lock);=0A- i= f (nr_neigh->digipeat !=3D NULL)=0A- kfree(nr_neigh->digipeat);=0A- kf= ree(nr_neigh);=0A- return;=0A- }=0A-=0A- s =3D s->next;=0A- }=0A- spin_= unlock_bh(&nr_neigh_lock);=0A+static void nr_remove_neigh(struct nr_neigh *= nr_neigh)=0A+{=0A+ spin_lock_bh(&nr_neigh_list_lock);=0A+ __nr_remove_neigh= (nr_neigh);=0A+ spin_unlock_bh(&nr_neigh_list_lock);=0A }=0A =0A /*=0A@@ -3= 12,26 +351,27 @@=0A struct nr_neigh *nr_neigh;=0A int i;=0A =0A- for (nr_= node =3D nr_node_list; nr_node !=3D NULL; nr_node =3D nr_node->next)=0A- i= f (ax25cmp(callsign, &nr_node->callsign) =3D=3D 0)=0A- break;=0A+ nr_node= =3D nr_node_get(callsign);=0A =0A if (nr_node =3D=3D NULL)=0A return -E= INVAL;=0A =0A- for (nr_neigh =3D nr_neigh_list; nr_neigh !=3D NULL; nr_neig= h =3D nr_neigh->next)=0A- if (ax25cmp(neighbour, &nr_neigh->callsign) =3D= =3D 0 && nr_neigh->dev =3D=3D dev)=0A- break;=0A+ nr_neigh =3D nr_neigh_g= et_dev(neighbour, dev);=0A =0A- if (nr_neigh =3D=3D NULL)=0A+ if (nr_neigh = =3D=3D NULL) {=0A+ nr_node_put(nr_node);=0A return -EINVAL;=0A+ }=0A =0A= + nr_node_lock(nr_node);=0A for (i =3D 0; i < nr_node->count; i++) {=0A = if (nr_node->routes[i].neighbour =3D=3D nr_neigh) {=0A nr_neigh->count--= ;=0A+ nr_neigh_put(nr_neigh);=0A =0A if (nr_neigh->count =3D=3D 0 && != nr_neigh->locked)=0A nr_remove_neigh(nr_neigh);=0A+ nr_neigh_put(nr_n= eigh);=0A =0A nr_node->count--;=0A =0A@@ -346,11 +386,16 @@=0A case = 2:=0A break;=0A }=0A+ nr_node_put(nr_node);=0A }=0A+ nr_no= de_unlock(nr_node);=0A =0A return 0;=0A }=0A }=0A+ nr_neigh_put(nr_ne= igh);=0A+ nr_node_unlock(nr_node);=0A+ nr_node_put(nr_node);=0A =0A return= -EINVAL;=0A }=0A@@ -362,12 +407,12 @@=0A {=0A struct nr_neigh *nr_neigh;= =0A =0A- for (nr_neigh =3D nr_neigh_list; nr_neigh !=3D NULL; nr_neigh =3D = nr_neigh->next) {=0A- if (ax25cmp(callsign, &nr_neigh->callsign) =3D=3D 0 = && nr_neigh->dev =3D=3D dev) {=0A- nr_neigh->quality =3D quality;=0A- n= r_neigh->locked =3D 1;=0A- return 0;=0A- }=0A+ nr_neigh =3D nr_neigh_ge= t_dev(callsign, dev);=0A+ if (nr_neigh) {=0A+ nr_neigh->quality =3D qualit= y;=0A+ nr_neigh->locked =3D 1;=0A+ nr_neigh_put(nr_neigh);=0A+ return 0= ;=0A }=0A =0A if ((nr_neigh =3D kmalloc(sizeof(*nr_neigh), GFP_ATOMIC)) = =3D=3D NULL)=0A@@ -382,6 +427,7 @@=0A nr_neigh->count =3D 0;=0A nr_nei= gh->number =3D nr_neigh_no++;=0A nr_neigh->failed =3D 0;=0A+ atomic_se= t(&nr_neigh->refcount, 1);=0A =0A if (ax25_digi !=3D NULL && ax25_digi->nd= igi > 0) {=0A if ((nr_neigh->digipeat =3D kmalloc(sizeof(*ax25_digi), GFP= _KERNEL)) =3D=3D NULL) {=0A@@ -391,10 +437,10 @@=0A memcpy(nr_neigh->digi= peat, ax25_digi, sizeof(*ax25_digi));=0A }=0A =0A- spin_lock_bh(&nr_neigh_= lock);=0A- nr_neigh->next =3D nr_neigh_list;=0A- nr_neigh_list =3D nr_neig= h;=0A- spin_unlock_bh(&nr_neigh_lock);=0A+ spin_lock_bh(&nr_neigh_list_lock= );=0A+ hlist_add_head(&nr_neigh->neigh_node, &nr_neigh_list);=0A+ /* refcou= nt is initialized at 1 */=0A+ spin_unlock_bh(&nr_neigh_list_lock);=0A =0A = return 0;=0A }=0A@@ -407,9 +453,7 @@=0A {=0A struct nr_neigh *nr_neigh;=0A= =0A- for (nr_neigh =3D nr_neigh_list; nr_neigh !=3D NULL; nr_neigh =3D nr_= neigh->next)=0A- if (ax25cmp(callsign, &nr_neigh->callsign) =3D=3D 0 && nr= _neigh->dev =3D=3D dev)=0A- break;=0A+ nr_neigh =3D nr_neigh_get_dev(call= sign, dev);=0A =0A if (nr_neigh =3D=3D NULL) return -EINVAL;=0A =0A@@ -418= ,6 +462,7 @@=0A =0A if (nr_neigh->count =3D=3D 0)=0A nr_remove_neigh(nr_= neigh);=0A+ nr_neigh_put(nr_neigh);=0A =0A return 0;=0A }=0A@@ -430,15 +47= 5,13 @@=0A static int nr_dec_obs(void)=0A {=0A struct nr_neigh *nr_neigh;= =0A- struct nr_node *s, *nr_node;=0A+ struct nr_node *s;=0A+ struct hlist= _node *node, *nodet;=0A int i;=0A =0A- nr_node =3D nr_node_list;=0A-=0A- w= hile (nr_node !=3D NULL) {=0A- s =3D nr_node;=0A- nr_node =3D nr_no= de->next;=0A-=0A+ spin_lock_bh(&nr_node_list_lock);=0A+ nr_node_for_each_sa= fe(s, node, nodet, &nr_node_list) {=0A+ nr_node_lock(s);=0A for (i =3D 0= ; i < s->count; i++) {=0A switch (s->routes[i].obs_count) {=0A case 0= : /* A locked entry */=0A@@ -448,6 +491,7 @@=0A nr_neigh =3D s->routes= [i].neighbour;=0A =0A nr_neigh->count--;=0A+ nr_neigh_put(nr_neigh);= =0A =0A if (nr_neigh->count =3D=3D 0 && !nr_neigh->locked)=0A nr_r= emove_neigh(nr_neigh);=0A@@ -472,8 +516,10 @@=0A }=0A =0A if (s->count = <=3D 0)=0A- nr_remove_node(s);=0A+ nr_remove_node_locked(s);=0A+ nr_no= de_unlock(s);=0A }=0A+ spin_unlock_bh(&nr_node_list_lock);=0A =0A return = 0;=0A }=0A@@ -483,21 +529,17 @@=0A */=0A void nr_rt_device_down(struct net= _device *dev)=0A {=0A- struct nr_neigh *s, *nr_neigh =3D nr_neigh_list;=0A-= struct nr_node *t, *nr_node;=0A+ struct nr_neigh *s;=0A+ struct hlist_nod= e *node, *nodet, *node2, *node2t;=0A+ struct nr_node *t;=0A int i;=0A =0A= - while (nr_neigh !=3D NULL) {=0A- s =3D nr_neigh;=0A- nr_neigh = =3D nr_neigh->next;=0A-=0A+ spin_lock_bh(&nr_neigh_list_lock);=0A+ nr_neigh= _for_each_safe(s, node, nodet, &nr_neigh_list) {=0A if (s->dev =3D=3D dev= ) {=0A- nr_node =3D nr_node_list;=0A-=0A- while (nr_node !=3D NULL) {= =0A- t =3D nr_node;=0A- nr_node =3D nr_node->next;=0A-=0A+ sp= in_lock_bh(&nr_node_list_lock);=0A+ nr_node_for_each_safe(t, node2, node2= t, &nr_node_list) {=0A+ nr_node_lock(t);=0A for (i =3D 0; i < t->cou= nt; i++) {=0A if (t->routes[i].neighbour =3D=3D s) {=0A t->count= --;=0A@@ -514,12 +556,15 @@=0A }=0A =0A if (t->count <=3D 0)=0A- = nr_remove_node(t);=0A+ nr_remove_node_locked(t);=0A+ nr_node_unloc= k(t);=0A }=0A+ spin_unlock_bh(&nr_node_list_lock);=0A =0A- nr_remove= _neigh(s);=0A+ nr_remove_neigh_locked(s);=0A }=0A }=0A+ spin_unlock_bh= (&nr_neigh_list_lock);=0A }=0A =0A /*=0A@@ -553,6 +598,8 @@=0A if (first= =3D=3D NULL || strncmp(dev->name, first->name, 3) < 0)=0A first =3D de= v;=0A }=0A+ if (first)=0A+ dev_hold(first);=0A read_unlock(&dev_base_loc= k);=0A =0A return first;=0A@@ -603,6 +650,7 @@=0A {=0A struct nr_route_st= ruct nr_route;=0A struct net_device *dev;=0A+ int ret;=0A =0A switch (cmd= ) {=0A case SIOCADDRT:=0A@@ -610,23 +658,29 @@=0A return -EFAULT;=0A = if ((dev =3D nr_ax25_dev_get(nr_route.device)) =3D=3D NULL)=0A return -E= INVAL;=0A- if (nr_route.ndigis < 0 || nr_route.ndigis > AX25_MAX_DIGIS)=0A= + if (nr_route.ndigis < 0 || nr_route.ndigis > AX25_MAX_DIGIS) {=0A+ dev= _put(dev);=0A return -EINVAL;=0A+ }=0A switch (nr_route.type) {=0A = case NETROM_NODE:=0A- return nr_add_node(&nr_route.callsign,=0A+ ret = =3D nr_add_node(&nr_route.callsign,=0A nr_route.mnemonic,=0A &nr_ro= ute.neighbour,=0A nr_call_to_digi(nr_route.ndigis, nr_route.digipeaters= ),=0A dev, nr_route.quality,=0A nr_route.obs_count);=0A+ break;= =0A case NETROM_NEIGH:=0A- return nr_add_neigh(&nr_route.callsign,=0A+ = ret =3D nr_add_neigh(&nr_route.callsign,=0A nr_call_to_digi(nr_route.= ndigis, nr_route.digipeaters),=0A dev, nr_route.quality);=0A+ break;= =0A default:=0A- return -EINVAL;=0A+ ret =3D -EINVAL;=0A }=0A+ dev= _put(dev);=0A+ return ret;=0A =0A case SIOCDELRT:=0A if (copy_from_user= (&nr_route, arg, sizeof(struct nr_route_struct)))=0A@@ -635,14 +689,18 @@= =0A return -EINVAL;=0A switch (nr_route.type) {=0A case NETROM_NODE:= =0A- return nr_del_node(&nr_route.callsign,=0A+ ret =3D nr_del_node(&nr= _route.callsign,=0A &nr_route.neighbour, dev);=0A+ break;=0A case N= ETROM_NEIGH:=0A- return nr_del_neigh(&nr_route.callsign,=0A+ ret =3D nr= _del_neigh(&nr_route.callsign,=0A dev, nr_route.quality);=0A+ break;= =0A default:=0A- return -EINVAL;=0A+ ret =3D -EINVAL;=0A }=0A+ dev= _put(dev);=0A+ return ret;=0A =0A case SIOCNRDECOBS:=0A return nr_dec_o= bs();=0A@@ -660,22 +718,36 @@=0A */=0A void nr_link_failed(ax25_cb *ax25, = int reason)=0A {=0A- struct nr_neigh *nr_neigh;=0A- struct nr_node *nr_nod= e;=0A-=0A- for (nr_neigh =3D nr_neigh_list; nr_neigh !=3D NULL; nr_neigh = =3D nr_neigh->next)=0A- if (nr_neigh->ax25 =3D=3D ax25)=0A+ struct nr_neig= h *s, *nr_neigh =3D NULL;=0A+ struct hlist_node *node;=0A+ struct nr_node = *nr_node =3D NULL;=0A+=0A+ spin_lock_bh(&nr_neigh_list_lock);=0A+ nr_neigh_= for_each(s, node, &nr_neigh_list)=0A+ if (s->ax25 =3D=3D ax25) {=0A+ nr_= neigh_hold(s);=0A+ nr_neigh =3D s;=0A break;=0A+ }=0A+ spin_unlock_bh= (&nr_neigh_list_lock);=0A =0A if (nr_neigh =3D=3D NULL) return;=0A =0A nr= _neigh->ax25 =3D NULL;=0A+ ax25_cb_put(ax25);=0A =0A- if (++nr_neigh->faile= d < sysctl_netrom_link_fails_count) return;=0A-=0A- for (nr_node =3D nr_nod= e_list; nr_node !=3D NULL; nr_node =3D nr_node->next)=0A+ if (++nr_neigh->f= ailed < sysctl_netrom_link_fails_count) {=0A+ nr_neigh_put(nr_neigh);=0A+ = return;=0A+ }=0A+ spin_lock_bh(&nr_node_list_lock);=0A+ nr_node_for_each(n= r_node, node, &nr_node_list)=0A+ nr_node_lock(nr_node);=0A if (nr_node->= which < nr_node->count && nr_node->routes[nr_node->which].neighbour =3D=3D = nr_neigh)=0A nr_node->which++;=0A+ nr_node_unlock(nr_node);=0A+ spin_un= lock_bh(&nr_node_list_lock);=0A+ nr_neigh_put(nr_neigh);=0A }=0A =0A /*=0A@= @ -689,6 +761,9 @@=0A struct nr_node *nr_node;=0A struct net_device *dev= ;=0A unsigned char *dptr;=0A+ ax25_cb *ax25s;=0A+ int ret;=0A+ struct sk_b= uff *skbn;=0A =0A =0A nr_src =3D (ax25_address *)(skb->data + 0);=0A@@ -7= 00,50 +775,84 @@=0A =0A if ((dev =3D nr_dev_get(nr_dest)) !=3D NULL) { /* = Its for me */=0A if (ax25 =3D=3D NULL) /* Its from me */=0A- return n= r_loopback_queue(skb);=0A+ ret =3D nr_loopback_queue(skb);=0A else=0A- = return nr_rx_frame(skb, dev);=0A+ ret =3D nr_rx_frame(skb, dev);=0A+ d= ev_put(dev);=0A+ return ret;=0A }=0A =0A if (!sysctl_netrom_routing_cont= rol && ax25 !=3D NULL)=0A return 0;=0A =0A /* Its Time-To-Live has expir= ed */=0A- if (--skb->data[14] =3D=3D 0)=0A+ if (skb->data[14] =3D=3D 1) {= =0A return 0;=0A+ }=0A =0A- for (nr_node =3D nr_node_list; nr_node !=3D N= ULL; nr_node =3D nr_node->next)=0A- if (ax25cmp(nr_dest, &nr_node->callsig= n) =3D=3D 0)=0A- break;=0A+ nr_node =3D nr_node_get(nr_dest);=0A+ if (nr_= node =3D=3D NULL)=0A+ return 0;=0A+ nr_node_lock(nr_node);=0A =0A- if (nr_= node =3D=3D NULL || nr_node->which >=3D nr_node->count)=0A+ if (nr_node->wh= ich >=3D nr_node->count) {=0A+ nr_node_unlock(nr_node);=0A+ nr_node_put(n= r_node);=0A return 0;=0A+ }=0A =0A nr_neigh =3D nr_node->routes[nr_node-= >which].neighbour;=0A =0A- if ((dev =3D nr_dev_first()) =3D=3D NULL)=0A+ if= ((dev =3D nr_dev_first()) =3D=3D NULL) {=0A+ nr_node_unlock(nr_node);=0A+= nr_node_put(nr_node);=0A+ return 0;=0A+ }=0A+=0A+ /* We are going to cha= nge the netrom headers so we should get our=0A+ own skb, we also did not= know until now how much header space=0A+ we had to reserve... - RXQ */= =0A+ if ((skbn=3Dskb_copy_expand(skb, dev->hard_header_len, 0, GFP_ATOMIC))= =3D=3D NULL) {=0A+ nr_node_unlock(nr_node);=0A+ nr_node_put(nr_node);=0A= + dev_put(dev);=0A return 0;=0A+ }=0A+ kfree_skb(skb);=0A+ skb=3Dskbn;= =0A+ skb->data[14]--;=0A =0A dptr =3D skb_push(skb, 1);=0A *dptr =3D AX2= 5_P_NETROM;=0A =0A- nr_neigh->ax25 =3D ax25_send_frame(skb, 256, (ax25_addr= ess *)dev->dev_addr, &nr_neigh->callsign, nr_neigh->digipeat, nr_neigh->dev= );=0A+ ax25s =3D ax25_send_frame(skb, 256, (ax25_address *)dev->dev_addr, &= nr_neigh->callsign, nr_neigh->digipeat, nr_neigh->dev);=0A+ if (nr_neigh->a= x25 && ax25s) {=0A+ /* We were already holding this ax25_cb */=0A+ ax25_c= b_put(ax25s);=0A+ }=0A+ nr_neigh->ax25 =3D ax25s;=0A =0A- return (nr_neigh-= >ax25 !=3D NULL);=0A+ dev_put(dev);=0A+ ret =3D (nr_neigh->ax25 !=3D NULL);= =0A+ nr_node_unlock(nr_node);=0A+ nr_node_put(nr_node);=0A+ return ret;=0A = }=0A =0A int nr_nodes_get_info(char *buffer, char **start, off_t offset, in= t length)=0A {=0A struct nr_node *nr_node;=0A+ struct hlist_node *node;=0A= int len =3D 0;=0A off_t pos =3D 0;=0A off_t begin =3D 0;=0A int = i;=0A =0A- spin_lock_bh(&nr_node_lock);=0A+ spin_lock_bh(&nr_node_list_lock= );=0A len +=3D sprintf(buffer, "callsign mnemonic w n qual obs neigh qual= obs neigh qual obs neigh\n");=0A =0A- for (nr_node =3D nr_node_list; nr_no= de !=3D NULL; nr_node =3D nr_node->next) {=0A+ nr_node_for_each(nr_node, no= de, &nr_node_list) {=0A+ nr_node_lock(nr_node);=0A len +=3D sprintf(buff= er + len, "%-9s %-7s %d %d",=0A ax2asc(&nr_node->callsign),=0A (nr_n= ode->mnemonic[0] =3D=3D '\0') ? "*" : nr_node->mnemonic,=0A@@ -756,6 +865,7= @@=0A nr_node->routes[i].obs_count,=0A nr_node->routes[i].neighbou= r->number);=0A }=0A+ nr_node_unlock(nr_node);=0A =0A len +=3D sprintf(= buffer + len, "\n");=0A =0A@@ -769,7 +879,7 @@=0A if (pos > offset + leng= th)=0A break;=0A }=0A- spin_unlock_bh(&nr_node_lock);=0A+ spin_unlock_b= h(&nr_node_list_lock);=0A =0A *start =3D buffer + (offset - begin);=0A le= n -=3D (offset - begin);=0A@@ -782,15 +892,16 @@=0A int nr_neigh_get_info= (char *buffer, char **start, off_t offset, int length)=0A {=0A struct nr_n= eigh *nr_neigh;=0A+ struct hlist_node *node;=0A int len =3D 0;=0A off= _t pos =3D 0;=0A off_t begin =3D 0;=0A int i;=0A =0A- spin_lock_bh(&nr_= neigh_lock);=0A+ spin_lock_bh(&nr_neigh_list_lock);=0A len +=3D sprintf(bu= ffer, "addr callsign dev qual lock count failed digipeaters\n");=0A =0A-= for (nr_neigh =3D nr_neigh_list; nr_neigh !=3D NULL; nr_neigh =3D nr_neigh= ->next) {=0A+ nr_neigh_for_each(nr_neigh, node, &nr_neigh_list) {=0A len = +=3D sprintf(buffer + len, "%05d %-9s %-4s %3d %d %3d %3d",=0A = nr_neigh->number,=0A ax2asc(&nr_neigh->callsign),=0A@@ -818,7 +929,7 @@= =0A break;=0A }=0A =0A- spin_unlock_bh(&nr_neigh_lock);=0A+ spin_unlock= _bh(&nr_neigh_list_lock);=0A =0A *start =3D buffer + (offset - begin);=0A = len -=3D (offset - begin);=0A@@ -833,20 +944,24 @@=0A */=0A void __exit= nr_rt_free(void)=0A {=0A- struct nr_neigh *s, *nr_neigh =3D nr_neigh_list;= =0A- struct nr_node *t, *nr_node =3D nr_node_list;=0A-=0A- while (nr_node= !=3D NULL) {=0A- t =3D nr_node;=0A- nr_node =3D nr_node->next;=0A-= =0A- nr_remove_node(t);=0A- }=0A-=0A- while (nr_neigh !=3D NULL) {=0A- s = =3D nr_neigh;=0A- nr_neigh =3D nr_neigh->next;=0A-=0A- nr_remove_n= eigh(s);=0A+ struct nr_neigh *s =3D NULL;=0A+ struct nr_node *t =3D NULL;= =0A+ struct hlist_node *node, *nodet;=0A+=0A+ spin_lock_bh(&nr_neigh_list_l= ock);=0A+ spin_lock_bh(&nr_node_list_lock);=0A+ nr_node_for_each_safe(t, no= de, nodet, &nr_node_list) {=0A+ nr_node_lock(t);=0A+ nr_remove_node_locke= d(t);=0A+ nr_node_unlock(t);=0A+ }=0A+ nr_neigh_for_each_safe(s, node, nod= et, &nr_neigh_list) {=0A+ while(s->count) {=0A+ s->count--;=0A+ nr_nei= gh_put(s);=0A+ }=0A+ nr_remove_neigh_locked(s);=0A }=0A+ spin_unlock_bh(= &nr_node_list_lock);=0A+ spin_unlock_bh(&nr_neigh_list_lock);=0A }=0AOnly i= n linux-2.6.0-test3.rxq/net/netrom: nr_route.o=0Adiff -ru linux-2.6.0-test3= /net/netrom/nr_subr.c linux-2.6.0-test3.rxq/net/netrom/nr_subr.c=0A--- linu= x-2.6.0-test3/net/netrom/nr_subr.c 2003-08-09 06:42:56.000000000 +0200=0A++= + linux-2.6.0-test3.rxq/net/netrom/nr_subr.c 2003-08-12 23:40:35.000000000 = +0200=0A@@ -127,7 +127,7 @@=0A unsigned char *dptr;=0A int len, timeout;= =0A =0A- len =3D AX25_BPQ_HEADER_LEN + AX25_MAX_HEADER_LEN + NR_NETWORK_LEN= + NR_TRANSPORT_LEN;=0A+ len =3D NR_NETWORK_LEN + NR_TRANSPORT_LEN;=0A =0A = switch (frametype & 0x0F) {=0A case NR_CONNREQ:=0A@@ -151,7 +151,7 @@=0A = /*=0A * Space for AX.25 and NET/ROM network header=0A */=0A- skb_reser= ve(skb, AX25_BPQ_HEADER_LEN + AX25_MAX_HEADER_LEN + NR_NETWORK_LEN);=0A+ sk= b_reserve(skb, NR_NETWORK_LEN);=0A =0A dptr =3D skb_put(skb, skb_tailroom(= skb));=0A =0A@@ -219,12 +219,12 @@=0A unsigned char *dptr;=0A int len;=0A= =0A- len =3D AX25_BPQ_HEADER_LEN + AX25_MAX_HEADER_LEN + NR_NETWORK_LEN + = NR_TRANSPORT_LEN + 1;=0A+ len =3D NR_NETWORK_LEN + NR_TRANSPORT_LEN + 1;=0A= =0A if ((skbn =3D alloc_skb(len, GFP_ATOMIC)) =3D=3D NULL)=0A return;= =0A =0A- skb_reserve(skbn, AX25_BPQ_HEADER_LEN + AX25_MAX_HEADER_LEN);=0A+ = skb_reserve(skbn, 0);=0A =0A dptr =3D skb_put(skbn, NR_NETWORK_LEN + NR_TR= ANSPORT_LEN);=0A =0AOnly in linux-2.6.0-test3.rxq/net/netrom: nr_subr.o=0Ad= iff -ru linux-2.6.0-test3/net/netrom/nr_timer.c linux-2.6.0-test3.rxq/net/n= etrom/nr_timer.c=0A--- linux-2.6.0-test3/net/netrom/nr_timer.c 2003-08-09 0= 6:38:56.000000000 +0200=0A+++ linux-2.6.0-test3.rxq/net/netrom/nr_timer.c 2= 003-08-12 23:40:35.000000000 +0200=0A@@ -143,7 +143,10 @@=0A is accept= ed() it isn't 'dead' so doesn't get removed. */=0A if (sock_flag(sk, SOCK= _DESTROY) ||=0A (sk->sk_state =3D=3D TCP_LISTEN && sock_flag(sk, SOCK= _DEAD))) {=0A+ sock_hold(sk);=0A nr_destroy_socket(sk);=0A+ bh_unloc= k_sock(sk);=0A+ sock_put(sk);=0A return;=0A }=0A break;=0A@@ -227,= 6 +230,7 @@=0A case NR_STATE_1:=0A if (nr->n2count =3D=3D nr->n2) {=0A = nr_disconnect(sk, ETIMEDOUT);=0A+ bh_unlock_sock(sk);=0A return;=0A = } else {=0A nr->n2count++;=0A@@ -237,6 +241,7 @@=0A case NR_STATE_2:= =0A if (nr->n2count =3D=3D nr->n2) {=0A nr_disconnect(sk, ETIMEDOUT);= =0A+ bh_unlock_sock(sk);=0A return;=0A } else {=0A nr->n2count++;= =0A@@ -247,6 +252,7 @@=0A case NR_STATE_3:=0A if (nr->n2count =3D=3D nr-= >n2) {=0A nr_disconnect(sk, ETIMEDOUT);=0A+ bh_unlock_sock(sk);=0A = return;=0A } else {=0A nr->n2count++;=0AOnly in linux-2.6.0-test3.rxq/= net/netrom: nr_timer.o=0Adiff -ru linux-2.6.0-test3/net/netrom/sysctl_net_n= etrom.c linux-2.6.0-test3.rxq/net/netrom/sysctl_net_netrom.c=0A--- linux-2.= 6.0-test3/net/netrom/sysctl_net_netrom.c 2003-08-09 06:33:21.000000000 +020= 0=0A+++ linux-2.6.0-test3.rxq/net/netrom/sysctl_net_netrom.c 2003-08-12 23:= 40:35.000000000 +0200=0A@@ -15,9 +15,9 @@=0A /*=0A * Values taken from NET= /ROM documentation.=0A */=0A-static int min_quality[1], max_quality[= ] =3D {255};=0A-static int min_obs[1], max_obs[] =3D {255};= =0A-static int min_ttl[1], max_ttl[] =3D {255};=0A+static int= min_quality[] =3D {0}, max_quality[] =3D {255};=0A+static int min_obs[] = =3D {0}, max_obs[] =3D {255};=0A+static int min_ttl[] =3D {0}, ma= x_ttl[] =3D {255};=0A static int min_t1[] =3D {5 * HZ};=0A static = int max_t1[] =3D {600 * HZ};=0A static int min_n2[] =3D {2}, max_= n2[] =3D {127};=0A@@ -28,7 +28,7 @@=0A static int min_window[] =3D {1= }, max_window[] =3D {127};=0A static int min_idle[] =3D {0 * HZ};=0A st= atic int max_idle[] =3D {65535 * HZ};=0A-static int min_route[1], = max_route[] =3D {1};=0A+static int min_route[] =3D {0}, max_route[] = =3D {1};=0A static int min_fails[] =3D {1}, max_fails[] =3D {10};=0A = =0A static struct ctl_table_header *nr_table_header;=0AOnly in linux-2.6.0-= test3.rxq/net/netrom: sysctl_net_netrom.o=0A--- linux-2.6.0-test3/include/n= et/ax25.h 2003-08-09 06:38:16.000000000 +0200=0A+++ linux-2.6.0-test3.rxq/i= nclude/net/ax25.h 2003-08-12 23:40:35.000000000 +0200=0A@@ -10,6 +10,7 @@= =0A #include =0A #include =0A #include =0A+#include =0A #include =0A =0A #d= efine AX25_T1CLAMPLO 1=0A@@ -180,7 +181,7 @@=0A } ax25_dev;=0A =0A typed= ef struct ax25_cb {=0A- struct ax25_cb *next;=0A+ struct hlist_node ax25_n= ode;=0A ax25_address source_addr, dest_addr;=0A ax25_digi *digipeat;=0A= ax25_dev *ax25_dev;=0A@@ -197,17 +198,32 @@=0A struct sk_buff_head ack_= queue;=0A struct sk_buff_head frag_queue;=0A unsigned char window;=0A- s= truct timer_list timer;=0A+ struct timer_list timer, dtimer;=0A struct soc= k *sk; /* Backlink to socket */=0A+ atomic_t refcount;=0A } ax25_cb;=0A = =0A #define ax25_sk(__sk) ((ax25_cb *)(__sk)->sk_protinfo)=0A =0A+#define a= x25_for_each(__ax25, node, list) \=0A+ hlist_for_each_entry(__ax25, node, l= ist, ax25_node)=0A+=0A+#define ax25_cb_hold(__ax25) \=0A+ atomic_inc(&((__a= x25)->refcount))=0A+=0A+static __inline__ void ax25_cb_put(ax25_cb *ax25)= =0A+{=0A+ if (atomic_dec_and_test(&ax25->refcount)) {=0A+ if (ax25->digipe= at)=0A+ kfree(ax25->digipeat);=0A+ kfree(ax25);=0A+ }=0A+}=0A+=0A /* af_= ax25.c */=0A-extern ax25_cb *ax25_list;=0A+extern struct hlist_head ax25_li= st;=0A extern spinlock_t ax25_list_lock;=0A-extern void ax25_free_cb(ax25_c= b *);=0A-extern void ax25_insert_socket(ax25_cb *);=0A+extern void ax25_cb_= add(ax25_cb *);=0A struct sock *ax25_find_listener(ax25_address *, int, str= uct net_device *, int);=0A struct sock *ax25_get_socket(ax25_address *, ax2= 5_address *, int);=0A extern ax25_cb *ax25_find_cb(ax25_address *, ax25_add= ress *, ax25_digi *, struct net_device *);=0A--- linux-2.6.0-test3/include/= net/netrom.h 2003-08-09 06:37:18.000000000 +0200=0A+++ linux-2.6.0-test3.rx= q/include/net/netrom.h 2003-08-12 23:40:35.000000000 +0200=0A@@ -7,6 +7,7 @= @=0A #ifndef _NETROM_H=0A #define _NETROM_H =0A #include = =0A+#include =0A =0A #define NR_NETWORK_LEN 15=0A #define N= R_TRANSPORT_LEN 5=0A@@ -77,16 +78,17 @@=0A #define nr_sk(__sk) ((nr_cb *)(= __sk)->sk_protinfo)=0A =0A struct nr_neigh {=0A- struct nr_neigh *next;=0A-= ax25_address callsign;=0A- ax25_digi *digipeat;=0A- ax25_cb *ax2= 5;=0A- struct net_device *dev;=0A- unsigned char quality;=0A- unsigned = char locked;=0A- unsigned short count;=0A- unsigned int number;=0A- u= nsigned char failed;=0A+ struct hlist_node neigh_node;=0A+ ax25_address ca= llsign;=0A+ ax25_digi *digipeat;=0A+ ax25_cb *ax25;=0A+ struct net_devic= e *dev;=0A+ unsigned char quality;=0A+ unsigned char locked;=0A+ unsigned= short count;=0A+ unsigned int number;=0A+ unsigned char failed;=0A+ ato= mic_t refcount;=0A };=0A =0A struct nr_route {=0A@@ -96,14 +98,74 @@=0A };= =0A =0A struct nr_node {=0A- struct nr_node *next;=0A- ax25_address cal= lsign;=0A- char mnemonic[7];=0A- unsigned char which;=0A- unsigned char = count;=0A- struct nr_route routes[3];=0A+ struct hlist_node node_node;=0A= + ax25_address callsign;=0A+ char mnemonic[7];=0A+ unsigned char which;= =0A+ unsigned char count;=0A+ struct nr_route routes[3];=0A+ atomic_t re= fcount;=0A+ spinlock_t node_lock;=0A };=0A =0A+/**************************= *******************************************=0A+ * nr_node & nr_neigh lists,= refcounting and locking=0A+ **********************************************= ***********************/=0A+=0A+extern struct hlist_head nr_node_list;=0A+e= xtern struct hlist_head nr_neigh_list;=0A+=0A+#define nr_node_hold(__nr_nod= e) \=0A+ atomic_inc(&((__nr_node)->refcount))=0A+=0A+static __inline__ void= nr_node_put(struct nr_node *nr_node)=0A+{=0A+ if (atomic_dec_and_test(&nr_= node->refcount)) {=0A+ kfree(nr_node);=0A+ }=0A+}=0A+=0A+#define nr_neigh_= hold(__nr_neigh) \=0A+ atomic_inc(&((__nr_neigh)->refcount))=0A+=0A+static = __inline__ void nr_neigh_put(struct nr_neigh *nr_neigh)=0A+{=0A+ if (atomic= _dec_and_test(&nr_neigh->refcount)) {=0A+ if (nr_neigh->digipeat !=3D NULL= )=0A+ kfree(nr_neigh->digipeat);=0A+ kfree(nr_neigh);=0A+ }=0A+}=0A+=0A+= /* nr_node_lock and nr_node_unlock also hold/put the node's refcounter.=0A+= */=0A+static __inline__ void nr_node_lock(struct nr_node *nr_node)=0A+{=0A= + nr_node_hold(nr_node);=0A+ spin_lock_bh(&nr_node->node_lock);=0A+}=0A+=0A= +static __inline__ void nr_node_unlock(struct nr_node *nr_node)=0A+{=0A+ sp= in_unlock_bh(&nr_node->node_lock);=0A+ nr_node_put(nr_node);=0A+}=0A+=0A+#d= efine nr_neigh_for_each(__nr_neigh, node, list) \=0A+ hlist_for_each_entry(= __nr_neigh, node, list, neigh_node)=0A+=0A+#define nr_neigh_for_each_safe(_= _nr_neigh, node, node2, list) \=0A+ hlist_for_each_entry_safe(__nr_neigh, n= ode, node2, list, neigh_node)=0A+=0A+#define nr_node_for_each(__nr_node, no= de, list) \=0A+ hlist_for_each_entry(__nr_node, node, list, node_node)=0A+= =0A+#define nr_node_for_each_safe(__nr_node, node, node2, list) \=0A+ hlist= _for_each_entry_safe(__nr_node, node, node2, list, node_node)=0A+=0A+=0A+/*= ********************************************************************/=0A+= =0A /* af_netrom.c */=0A extern int sysctl_netrom_default_path_quality;=0A= extern int sysctl_netrom_obsolescence_count_initialiser;=0Adiff -Nru a/ne= t/ax25/ax25_dev.c b/net/ax25/ax25_dev.c=0A--- a/net/ax25/ax25_dev.c Tue Aug= 12 16:45:51 2003=0A+++ b/net/ax25/ax25_dev.c Tue Aug 12 16:45:51 2003=0A@@= -67,6 +67,7 @@=0A =0A dev->ax25_ptr =3D ax25_dev;=0A ax25_dev->dev = =3D dev;=0A+ dev_hold(dev);=0A ax25_dev->forward =3D NULL;=0A =0A ax25= _dev->values[AX25_VALUES_IPDEFMODE] =3D AX25_DEF_IPDEFMODE;=0A@@ -121,6 +12= 2,7 @@=0A if ((s =3D ax25_dev_list) =3D=3D ax25_dev) {=0A ax25_dev_list = =3D s->next;=0A spin_unlock_bh(&ax25_dev_lock);=0A+ dev_put(dev);=0A k= free(ax25_dev);=0A ax25_register_sysctl();=0A return;=0A@@ -131,6 +133,= 7 @@=0A s->next =3D ax25_dev->next;=0A spin_unlock_bh(&ax25_dev_lock)= ;=0A kfree(ax25_dev);=0A+ dev_put(dev);=0A ax25_register_sysctl();= =0A return;=0A }=0A--- ax25/net/ax25/af_ax25.c 2003-08-12 17:08:42.025= 816088 -0700=0A+++ linux-2.5-net/net/ax25/af_ax25.c 2003-08-12 16:47:07.802= 057749=0A-0700=0A if (optlen > IFNAMSIZ)=0A optlen=3DIFNAMSIZ;=0A if= (copy_from_user(devname, optval, optlen)) {=0A- res =3D -EFAULT;=0A+ re= s =3D -EFAULT;=0A break;=0A }=0A =0A@@ -650,12 +650,14 @@ static int a= x25_setsockopt(struct socket=0A (sock->state !=3D SS_UNCONNECTED ||=0A= sk->sk_state =3D=3D TCP_LISTEN)) {=0A res =3D -EADDRNOTAVAIL;=0A-= dev_put(dev);=0A- break;=0A }=0A =0A- ax25->ax25_dev =3D ax25_dev_a= x25dev(dev);=0A- ax25_fillin_cb(ax25, ax25->ax25_dev);=0A+ else if ((ax25= ->ax25_dev =3D ax25_dev_ax25dev(dev)) =3D=3D NULL)=0A+ res =3D -EINVAL;= =0A+ else =0A+ ax25_fillin_cb(ax25, ax25->ax25_dev);=0A+=0A+ dev_put(de= v);=0A break;=0A =0A default:=0Adiff -Nru a/include/net/ax25.h b/include= /net/ax25.h=0A--- a/include/net/ax25.h Tue Aug 12 17:16:52 2003=0A+++ b/inc= lude/net/ax25.h Tue Aug 12 17:16:52 2003=0A@@ -314,7 +314,7 @@=0A /* ax25_r= oute.c */=0A extern void ax25_rt_device_down(struct net_device *);=0A exter= n int ax25_rt_ioctl(unsigned int, void *);=0A-extern int ax25_rt_get_info= (char *, char **, off_t, int);=0A+extern struct file_operations ax25_route_= fops;=0A extern int ax25_rt_autobind(ax25_cb *, ax25_address *);=0A extern= ax25_route *ax25_rt_find_route(ax25_route *, ax25_address *,=0A struct ne= t_device *);=0A@@ -373,7 +373,7 @@=0A extern int ax25_uid_policy;=0A exter= n ax25_address *ax25_findbyuid(uid_t);=0A extern int ax25_uid_ioctl(int, s= truct sockaddr_ax25 *);=0A-extern int ax25_uid_get_info(char *, char **, o= ff_t, int);=0A+extern struct file_operations ax25_uid_fops;=0A extern void = ax25_uid_free(void);=0A =0A /* sysctl_net_ax25.c */=0Adiff -Nru a/net/ax25/= af_ax25.c b/net/ax25/af_ax25.c=0A--- a/net/ax25/af_ax25.c Tue Aug 12 17:16:= 52 2003=0A+++ b/net/ax25/af_ax25.c Tue Aug 12 17:16:52 2003=0A@@ -1844,81 += 1844,107 @@=0A return res;=0A }=0A =0A-static int ax25_get_info(char *buff= er, char **start, off_t offset, int=0Alength)=0A+#ifdef CONFIG_PROC_FS=0A+= =0A+static void *ax25_info_start(struct seq_file *seq, loff_t *pos)=0A {=0A= - ax25_cb *ax25;=0A- int k;=0A- int len =3D 0;=0A- off_t pos =3D 0;=0A- off= _t begin =3D 0;=0A+ struct ax25_cb *ax25;=0A struct hlist_node *node;=0A+ = int i =3D 0;=0A =0A spin_lock_bh(&ax25_list_lock);=0A+ ax25_for_each(ax25,= node, &ax25_list) {=0A+ if (i =3D=3D *pos)=0A+ return ax25;=0A+ ++i;= =0A+ }=0A+ return NULL;=0A+}=0A+=0A+static void *ax25_info_next(struct seq_= file *seq, void *v, loff_t *pos)=0A+{=0A+ ++*pos;=0A+=0A+ return hlist_entr= y( ((struct ax25_cb *)v)->ax25_node.next,=0A+ struct ax25_cb, ax25_no= de);=0A+}=0A+ =0A+static void ax25_info_stop(struct seq_file *seq, void *v)= =0A+{=0A+ spin_unlock_bh(&ax25_list_lock);=0A+}=0A+=0A+static int ax25_info= _show(struct seq_file *seq, void *v)=0A+{=0A+ ax25_cb *ax25 =3D v;=0A+ int = k;=0A+=0A =0A /*=0A * New format:=0A * magic dev src_addr dest_addr,di= gi1,digi2,.. st vs vr va t1 t1=0At2 t2 t3 t3 idle idle n2 n2 rtt window pac= len Snd-Q Rcv-Q inode=0A */=0A =0A- ax25_for_each(ax25, node, &ax25_list)= {=0A- len +=3D sprintf(buffer+len, "%8.8lx %s %s%s ",=0A- (long) ax25,= =0A- ax25->ax25_dev =3D=3D NULL? "???" : ax25->ax25_dev->dev->name,=0A- = ax2asc(&ax25->source_addr),=0A- ax25->iamdigi? "*":"");=0A-=0A- len = +=3D sprintf(buffer+len, "%s", ax2asc(&ax25->dest_addr));=0A-=0A- for (k= =3D0; (ax25->digipeat !=3D NULL) && (k <=0Aax25->digipeat->ndigi); k++) {= =0A- len +=3D sprintf(buffer+len, ",%s%s",=0A- ax2asc(&ax25->digipeat= ->calls[k]),=0A- ax25->digipeat->repeated[k]? "*":"");=0A- }=0A-=0A- = len +=3D sprintf(buffer+len, " %d %d %d %d %lu %lu %lu %lu=0A%lu %lu %lu %l= u %d %d %lu %d %d",=0A- ax25->state,=0A- ax25->vs, ax25->vr, ax25->va,= =0A- ax25_display_timer(&ax25->t1timer) / HZ, ax25->t1=0A/ HZ,=0A- ax25= _display_timer(&ax25->t2timer) / HZ, ax25->t2=0A/ HZ,=0A- ax25_display_ti= mer(&ax25->t3timer) / HZ, ax25->t3=0A/ HZ,=0A- ax25_display_timer(&ax25->= idletimer) / (60 * HZ),=0A- ax25->idle / (60 * HZ),=0A- ax25->n2count, = ax25->n2,=0A- ax25->rtt / HZ,=0A- ax25->window,=0A- ax25->paclen);=0A= -=0A- if (ax25->sk !=3D NULL) {=0A- bh_lock_sock(ax25->sk);=0A- len += =3D sprintf(buffer + len, " %d %d %ld\n",=0A- atomic_read(&ax25->sk->sk_= wmem_alloc),=0A- atomic_read(&ax25->sk->sk_rmem_alloc),=0A- ax25->sk-= >sk_socket !=3D NULL ? SOCK_INODE(ax25->sk->sk_socket)->i_ino=0A: 0L);=0A- = bh_unlock_sock(ax25->sk);=0A- } else {=0A- len +=3D sprintf(buffer + l= en, " * * *\n");=0A- }=0A-=0A- pos =3D begin + len;=0A-=0A- if (pos < of= fset) {=0A- len =3D 0;=0A- begin =3D pos;=0A- }=0A+ seq_printf(seq, = "%8.8lx %s %s%s ",=0A+ (long) ax25,=0A+ ax25->ax25_dev =3D=3D NULL?= "???" :=0Aax25->ax25_dev->dev->name,=0A+ ax2asc(&ax25->source_addr),= =0A+ ax25->iamdigi? "*":"");=0A+ seq_printf(seq, "%s", ax2asc(&ax25->de= st_addr));=0A+=0A+ for (k=3D0; (ax25->digipeat !=3D NULL) && (k < ax25->dig= ipeat->ndigi);=0Ak++) {=0A+ seq_printf(seq, ",%s%s",=0A+ ax2asc(&ax25= ->digipeat->calls[k]),=0A+ ax25->digipeat->repeated[k]? "*":"");=0A+ }= =0A =0A- if (pos > offset + length)=0A- break;=0A+ seq_printf(seq, " %d = %d %d %d %lu %lu %lu %lu %lu %lu %lu %lu %d=0A%d %lu %d %d",=0A+ ax25->= state,=0A+ ax25->vs, ax25->vr, ax25->va,=0A+ ax25_display_timer(&ax= 25->t1timer) / HZ, ax25->t1 / HZ,=0A+ ax25_display_timer(&ax25->t2timer= ) / HZ, ax25->t2 / HZ,=0A+ ax25_display_timer(&ax25->t3timer) / HZ, ax2= 5->t3 / HZ,=0A+ ax25_display_timer(&ax25->idletimer) / (60 * HZ),=0A+ = ax25->idle / (60 * HZ),=0A+ ax25->n2count, ax25->n2,=0A+ ax25->r= tt / HZ,=0A+ ax25->window,=0A+ ax25->paclen);=0A+=0A+ if (ax25->sk = !=3D NULL) {=0A+ bh_lock_sock(ax25->sk);=0A+ seq_printf(seq," %d %d %ld\n= ",=0A+ atomic_read(&ax25->sk->sk_wmem_alloc),=0A+ atomic_read(&ax= 25->sk->sk_rmem_alloc),=0A+ ax25->sk->sk_socket !=3D NULL ? SOCK_INODE= (ax25->sk->sk_socket)->i_ino=0A: 0L);=0A+ bh_unlock_sock(ax25->sk);=0A+ } = else {=0A+ seq_puts(seq, " * * *\n");=0A }=0A+ return 0;=0A+}=0A =0A- spi= n_unlock_bh(&ax25_list_lock);=0A+static struct seq_operations ax25_info_seq= ops =3D {=0A+ .start =3D ax25_info_start,=0A+ .next =3D ax25_info_next,=0A+= .stop =3D ax25_info_stop,=0A+ .show =3D ax25_info_show,=0A+};=0A =0A- *sta= rt =3D buffer + (offset - begin);=0A- len -=3D (offset - begin);=0A+stati= c int ax25_info_open(struct inode *inode, struct file *file)=0A+{=0A+ retur= n seq_open(file, &ax25_info_seqops);=0A+}=0A =0A- if (len > length) len =3D= length;=0A+struct file_operations ax25_info_fops =3D {=0A+ .owner =3D THIS= _MODULE,=0A+ .open =3D ax25_info_open,=0A+ .read =3D seq_read,=0A+ .llseek = =3D seq_lseek,=0A+ .release =3D seq_release,=0A+};=0A =0A- return(len);=0A-= }=0A+#endif=0A =0A static struct net_proto_family ax25_family_ops =3D {=0A = .family =3D PF_AX25,=0A@@ -1988,9 +2014,9 @@=0A register_netdevice_notifi= er(&ax25_dev_notifier);=0A ax25_register_sysctl();=0A =0A- proc_net_create= ("ax25_route", 0, ax25_rt_get_info);=0A- proc_net_create("ax25", 0, ax25_ge= t_info);=0A- proc_net_create("ax25_calls", 0, ax25_uid_get_info);=0A+ proc_= net_fops_create("ax25_route", S_IRUGO, &ax25_route_fops);=0A+ proc_net_fops= _create("ax25", S_IRUGO, &ax25_info_fops);=0A+ proc_net_fops_create("ax25_c= alls", S_IRUGO, &ax25_uid_fops);=0A =0A printk(banner);=0A return 0;=0Adi= ff -Nru a/net/ax25/ax25_route.c b/net/ax25/ax25_route.c=0A--- a/net/ax25/ax= 25_route.c Tue Aug 12 17:16:52 2003=0A+++ b/net/ax25/ax25_route.c Tue Aug 1= 2 17:16:52 2003=0A@@ -34,6 +34,7 @@=0A #include =0A #include =0A #include =0A+#include = =0A =0A static ax25_route *ax25_route_list;=0A static rwlock_t ax25_route_l= ock =3D RW_LOCK_UNLOCKED;=0A@@ -278,66 +279,100 @@=0A }=0A }=0A =0A-int ax= 25_rt_get_info(char *buffer, char **start, off_t offset, int length)=0A-{= =0A- ax25_route *ax25_rt;=0A- int len =3D 0;=0A- off_t pos =3D 0;=0A-= off_t begin =3D 0;=0A- char *callsign;=0A- int i;=0A+#ifdef CONFIG_PROC_FS= =0A =0A- read_lock(&ax25_route_lock);=0A+#define AX25_PROC_START ((void *)1= )=0A =0A- len +=3D sprintf(buffer, "callsign dev mode digipeaters\n");=0A= +static void *ax25_rt_seq_start(struct seq_file *seq, loff_t *pos)=0A+{=0A+= struct ax25_route *ax25_rt;=0A+ int i =3D 1;=0A+ =0A+ read_lock(&ax25_rou= te_lock);=0A+ if (*pos =3D=3D 0)=0A+ return AX25_PROC_START;=0A =0A for (= ax25_rt =3D ax25_route_list; ax25_rt !=3D NULL; ax25_rt =3D=0Aax25_rt->next= ) {=0A+ if (i =3D=3D *pos)=0A+ return ax25_rt;=0A+ ++i;=0A+ }=0A+=0A+ r= eturn NULL;=0A+}=0A+=0A+static void *ax25_rt_seq_next(struct seq_file *seq,= void *v, loff_t *pos)=0A+{=0A+ ++*pos;=0A+ return (v =3D=3D AX25_PROC_STAR= T) ? ax25_route_list : =0A+ ((struct ax25_route *) v)->next;=0A+}=0A+=0A+s= tatic void ax25_rt_seq_stop(struct seq_file *seq, void *v)=0A+{=0A+ read_un= lock(&ax25_route_lock);=0A+}=0A+=0A+static int ax25_rt_seq_show(struct seq_= file *seq, void *v)=0A+{=0A+ if (v =3D=3D AX25_PROC_START)=0A+ seq_puts(se= q, "callsign dev mode digipeaters\n");=0A+ else {=0A+ struct ax25_route = *ax25_rt =3D v;=0A+ const char *callsign;=0A+ int i;=0A+=0A if (ax25cmp= (&ax25_rt->callsign, &null_ax25_address) =3D=3D 0)=0A callsign =3D "defa= ult";=0A else=0A callsign =3D ax2asc(&ax25_rt->callsign);=0A- len += =3D sprintf(buffer + len, "%-9s %-4s",=0A+=0A+ seq_printf(seq, "%-9s %-4s"= ,=0A callsign,=0A ax25_rt->dev ? ax25_rt->dev->name : "???");=0A =0A = switch (ax25_rt->ip_mode) {=0A case 'V':=0A- len +=3D sprintf(buffer = + len, " vc");=0A+ seq_puts(seq, " vc");=0A break;=0A case 'D':= =0A- len +=3D sprintf(buffer + len, " dg");=0A+ seq_puts(seq, " dg"= );=0A break;=0A default:=0A- len +=3D sprintf(buffer + len, " *")= ;=0A+ seq_puts(seq, " *");=0A break;=0A }=0A =0A if (ax25_rt->d= igipeat !=3D NULL)=0A for (i =3D 0; i < ax25_rt->digipeat->ndigi; i++)= =0A- len +=3D sprintf(buffer + len, " %s",=0Aax2asc(&ax25_rt->digipeat->= calls[i]));=0A-=0A- len +=3D sprintf(buffer + len, "\n");=0A+ seq_print= f(seq, " %s", ax2asc(&ax25_rt->digipeat->calls[i]));=0A =0A- pos =3D begin= + len;=0A-=0A- if (pos < offset) {=0A- len =3D 0;=0A- begin =3D pos= ;=0A- }=0A-=0A- if (pos > offset + length)=0A- break;=0A+ seq_puts(seq= , "\n");=0A }=0A- read_unlock(&ax25_route_lock);=0A-=0A- *start =3D buffer= + (offset - begin);=0A- len -=3D (offset - begin);=0A+ return 0;=0A+}=0A= =0A- if (len > length)=0A- len =3D length;=0A+static struct seq_operation= s ax25_rt_seqops =3D {=0A+ .start =3D ax25_rt_seq_start,=0A+ .next =3D ax25= _rt_seq_next,=0A+ .stop =3D ax25_rt_seq_stop,=0A+ .show =3D ax25_rt_seq_sho= w,=0A+};=0A =0A- return len;=0A+static int ax25_rt_info_open(struct inode *= inode, struct file *file)=0A+{=0A+ return seq_open(file, &ax25_rt_seqops);= =0A }=0A+=0A+struct file_operations ax25_route_fops =3D {=0A+ .owner =3D TH= IS_MODULE,=0A+ .open =3D ax25_rt_info_open,=0A+ .read =3D seq_read,=0A+ .ll= seek =3D seq_lseek,=0A+ .release =3D seq_release,=0A+};=0A+=0A+#endif=0A = =0A /*=0A * Find AX.25 route=0Adiff -Nru a/net/ax25/ax25_uid.c b/net/ax25/= ax25_uid.c=0A--- a/net/ax25/ax25_uid.c Tue Aug 12 17:16:52 2003=0A+++ b/net= /ax25/ax25_uid.c Tue Aug 12 17:16:52 2003=0A@@ -30,6 +30,7 @@=0A #include <= linux/interrupt.h>=0A #include =0A #include =0A+#include =0A #include =0A #include = =0A #include =0A@@ -141,39 +142,73 @@=0A= return -EINVAL; /*NOTREACHED */=0A }=0A =0A-int ax25_uid_get_info(char *b= uffer, char **start, off_t offset, int=0Alength)=0A+#ifdef CONFIG_PROC_FS= =0A+=0A+#define AX25_PROC_START ((void *)1)=0A+=0A+static void *ax25_uid_se= q_start(struct seq_file *seq, loff_t *pos)=0A {=0A- ax25_uid_assoc *pt;=0A-= int len =3D 0;=0A- off_t pos =3D 0;=0A- off_t begin =3D 0;=0A+ struc= t ax25_uid_assoc *pt;=0A+ int i =3D 1;=0A =0A read_lock(&ax25_uid_lock);= =0A- len +=3D sprintf(buffer, "Policy: %d\n", ax25_uid_policy);=0A+ if (*po= s =3D=3D 0)=0A+ return AX25_PROC_START;=0A =0A for (pt =3D ax25_uid_list;= pt !=3D NULL; pt =3D pt->next) {=0A- len +=3D sprintf(buffer + len, "%6d = %s\n", pt->uid,=0Aax2asc(&pt->call));=0A-=0A- pos =3D begin + len;=0A+ if= (i =3D=3D *pos)=0A+ return pt;=0A+ ++i;=0A+ }=0A+ return NULL;=0A+}=0A = =0A- if (pos < offset) {=0A- len =3D 0;=0A- begin =3D pos;=0A- }=0A+s= tatic void *ax25_uid_seq_next(struct seq_file *seq, void *v, loff_t *pos)= =0A+{=0A+ ++*pos;=0A+ return (v =3D=3D AX25_PROC_START) ? ax25_uid_list : = =0A+ ((struct ax25_uid_assoc *) v)->next;=0A+}=0A =0A- if (pos > offset += length)=0A- break;=0A- }=0A+static void ax25_uid_seq_stop(struct seq_fil= e *seq, void *v)=0A+{=0A read_unlock(&ax25_uid_lock);=0A+}=0A+=0A+static i= nt ax25_uid_seq_show(struct seq_file *seq, void *v)=0A+{=0A+ if (v =3D=3D A= X25_PROC_START)=0A+ seq_printf(seq, "Policy: %d\n", ax25_uid_policy);=0A+ = else {=0A+ struct ax25_uid_assoc *pt =3D v;=0A+ =0A =0A- *start =3D buffe= r + (offset - begin);=0A- len -=3D offset - begin;=0A+ seq_printf(seq, "= %6d %s\n", pt->uid, ax2asc(&pt->call));=0A+ }=0A+ return 0;=0A+}=0A =0A- if= (len > length)=0A- len =3D length;=0A+static struct seq_operations ax25_u= id_seqops =3D {=0A+ .start =3D ax25_uid_seq_start,=0A+ .next =3D ax25_uid_s= eq_next,=0A+ .stop =3D ax25_uid_seq_stop,=0A+ .show =3D ax25_uid_seq_show,= =0A+};=0A =0A- return len;=0A+static int ax25_uid_info_open(struct inode *i= node, struct file *file)=0A+{=0A+ return seq_open(file, &ax25_uid_seqops);= =0A }=0A+=0A+struct file_operations ax25_uid_fops =3D {=0A+ .owner =3D THIS= _MODULE,=0A+ .open =3D ax25_uid_info_open,=0A+ .read =3D seq_read,=0A+ .lls= eek =3D seq_lseek,=0A+ .release =3D seq_release,=0A+};=0A+=0A+#endif=0A =0A= /*=0A * Free all memory associated with UID/Callsign structures.=0A --AWniW0JNca5xppdA-- From ralph@istop.com Wed Aug 13 11:05:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 11:05:51 -0700 (PDT) Received: from smtp.istop.com (dci.doncaster.on.ca [66.11.168.194]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DI5PFl012243 for ; Wed, 13 Aug 2003 11:05:25 -0700 Received: from ns.istop.com (ns.istop.com [66.11.168.199]) by smtp.istop.com (Postfix) with ESMTP id 45BE93692B; Wed, 13 Aug 2003 13:28:29 -0400 (EDT) Date: Wed, 13 Aug 2003 13:28:28 -0400 (EDT) From: Ralph Doncaster Reply-To: ralph+d@istop.com To: Jamie Lokier Cc: "netdev@oss.sgi.com" Subject: Re: [RFC] High Performance Packet Classifiction for tc framework In-Reply-To: <20030812142913.GB18802@mail.jlokier.co.uk> Message-ID: References: <200307141045.40999.nf@hipac.org> <1058328537.1797.24.camel@jzny.localdomain> <3F16A0E5.1080007@hipac.org> <1059934468.1103.41.camel@jzny.localdomain> <3F2E5CD6.4030500@hipac.org> <1060012260.1103.380.camel@jzny.localdomain> <3F302E04.1090503@hipac.org> <1060286331.1025.73.camel@jzny.localdomain> <3F381B3E.6080807@hipac.org> <20030811224050.59bc36fe.davem@redhat.com> <20030812142913.GB18802@mail.jlokier.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4805 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ralph@istop.com Precedence: bulk X-list: netdev On Tue, 12 Aug 2003, Jamie Lokier wrote: > David S. Miller wrote: > > On Tue, 12 Aug 2003 00:39:58 +0200 > > The ipv4 FIB hash tables tackle exactly this problem. The resulting > > worse cast complexity is O(n_bits_in_prefix_mask). > > > > The problem you've described is exactly the same as trying to use > > hashing for routing tables. > > You can do it in O(log(n_bits_in_prefix_mask)). > > This is achieved using binary search on the prefix lengths which > appear in the table. (So if only a few prefix lengths are used, the > tree is small). > > Illustrated by an example. The example assumes 32 bits total and > every prefix length appears in the table. Each node in the search > tree has one or more of these fields: > > - TABLE: Sparse (hash) or dense (direct) mapping of some > subset of input bits to subtree nodes. > - SHORTER: Subtree node, for matching shorter prefixes than the > one which lead to the current node. > - BEST: Best matching result given the prefix that lead to this node. > This is either an exact match for that prefix, or the best > shorter-prefix match for it. > (On the root node, this will be the default value). > > In the worst case of N bits in the prefix, and every prefix length is > actually used, there would by N tree nodes, however the depth of the > search tree is ceil(log2(N)). > > This is the lookup algorithm: > > - Start with the root tree node. > Note that this isn't the shortest prefix matcher. > It will match the "middle" prefix length, given your set of lengths. > E.g. on a 32-bit address, with rules of all prefix lenghts, the root > tree node would match 16 bits. > LOOP: > - If NODE->TABLE exists, lookup the appropriate subset of input bits in it. > For sparse tables, this involves a hash lookup. > If a match is found, select that as the new tree node and goto LOOP. > - Otherwise there is no table or no match in the table. > - If NODE->SHORTER exists, select that as the new tree node and goto LOOP. > - Otherwise, return NODE->BEST. > > This generalises to multiple dimensions e.g. for doing multiple > prefixes on source+target + different combinations of other bits such > as protocol, TOS etc. - i.e. arbitrary bit-subset classifiers. The > basic principle and the algorithm are the same. > > In some cases it is worth reducing the tree size a little, e.g. if > prefix lengths P and P+1 appear, you may as well just hash on P+1 bits > and insert all the P prefix matches into the P+1 table, instead of > having a P table. The cost is up to twice the number of entries in > the P+1 table (depending on how dense your set of P+1 rules is), but > this may be better than the cost of a extra hash lookup. Naturally, > there are other optimisations too. Most of this doesn't make sense to me. The part about merging prefix-length tables is OK (i.e. 10.10.0.0/16 and 10.10.1.0/17 becomes 10.10.0.0/17 and 10.10.1.0/17). However if you have 32 tables (one for each prefix length) I can't see any possible way of avoiding a search in each table for the worst case. So if my packet is destined to 217.109.118.70 you need to start looking for a match for a /32 route, and if not found continue checking each prefix size until you've reached /0. -Ralph From greearb@candelatech.com Wed Aug 13 11:48:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 11:48:41 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-074.evrtwa1.dsl-verizon.net [4.33.45.74]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DImWFl013033 for ; Wed, 13 Aug 2003 11:48:32 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h79IAjtf025474; Sat, 9 Aug 2003 11:10:46 -0700 Message-ID: <3F353925.3030106@candelatech.com> Date: Sat, 09 Aug 2003 11:10:45 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030718 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: Andi Kleen , netdev@oss.sgi.com Subject: Re: RFR: new SiS gige driver References: <20030808173932.GA4077@gtf.org> <20030809141533.GB4539@wotan.suse.de> <3F350CC8.3090605@pobox.com> In-Reply-To: <3F350CC8.3090605@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4806 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Jeff Garzik wrote: > Andi Kleen wrote: > >> * netif_stop_queue in hard_start_xmit is not protected against the >> interrupt by the spinlock. That's racy, isn't it? > > > Shouldn't be, if done right. If the interrupt runs a TX completion > cycle, it will run the code > if (work_done && netif_queue_stopped(dev)) > netif_wake_queue(dev) > > Since ->hard_start_xmit is guaranteed never to be called if the queue is > stopped, you also guaranteed that netif_wake_queue and ->hard_start_xmit > are mutually exclusive. Is this really guaranteed? What if the queue is stopped between the check to see if it's stopped and the call to hard_start_xmit? Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From jamie@shareable.org Wed Aug 13 12:18:13 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 12:18:49 -0700 (PDT) Received: from mail.jlokier.co.uk (mail.jlokier.co.uk [81.29.64.88]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DJI8Fl013676 for ; Wed, 13 Aug 2003 12:18:12 -0700 Received: from mail.jlokier.co.uk (localhost [127.0.0.1]) by mail.jlokier.co.uk (8.12.8/8.12.8) with ESMTP id h7DJHvOI005495; Wed, 13 Aug 2003 20:17:57 +0100 Received: (from jamie@localhost) by mail.jlokier.co.uk (8.12.8/8.12.8/Submit) id h7DJHv15005493; Wed, 13 Aug 2003 20:17:57 +0100 Date: Wed, 13 Aug 2003 20:17:57 +0100 From: Jamie Lokier To: ralph+d@istop.com Cc: "netdev@oss.sgi.com" Subject: Re: [RFC] High Performance Packet Classifiction for tc framework Message-ID: <20030813191757.GE4405@mail.jlokier.co.uk> References: <3F16A0E5.1080007@hipac.org> <1059934468.1103.41.camel@jzny.localdomain> <3F2E5CD6.4030500@hipac.org> <1060012260.1103.380.camel@jzny.localdomain> <3F302E04.1090503@hipac.org> <1060286331.1025.73.camel@jzny.localdomain> <3F381B3E.6080807@hipac.org> <20030811224050.59bc36fe.davem@redhat.com> <20030812142913.GB18802@mail.jlokier.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-archive-position: 4807 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jamie@shareable.org Precedence: bulk X-list: netdev Ralph Doncaster wrote: > However if you have 32 tables (one for each prefix length) I can't see any > possible way of avoiding a search in each table for the worst case. So if > my packet is destined to 217.109.118.70 you need to start looking for a > match for a /32 route, and if not found continue checking each prefix size > until you've reached /0. You would start by search for a 217.109.0.0/16 entry. That's the root in the search tree. That would match, and the matching tree node would tell you to search a specific table for 217.109.118.0/24. (Actually, just 0.0.118.0/0.0.255.0, because this node can assume the first 16 bits). That would match, and the matching tree node tells you to search a specific table for 217.109.118.64/28 (0.0.0.64/0.0.0.240). That would match, and the matching tree node tells you to search a specific table for 217.109.118.68/32 (0.0.0.6/0.0.0.15). That would match, and is your result. Without the optimisation you said you understand, there would be a few more steps, narrowing to /30, /31 then /32, but for such small hashes, not only is it faster, it also uses less memory to just use a single 4-bit table lookup than to have a tree of tiny hash tables. -- Jamie From jgarzik@pobox.com Wed Aug 13 13:03:59 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 13:04:08 -0700 (PDT) Received: from www.linux.org.uk (IDENT:3GtbNcGa1Vct6NirkZC1gBLtkIlqPsEU@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DK3vFl014415 for ; Wed, 13 Aug 2003 13:03:58 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19n0jS-0004qd-QP; Wed, 13 Aug 2003 19:52:26 +0100 Message-ID: <3F3A88DF.80205@pobox.com> Date: Wed, 13 Aug 2003 14:52:15 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: Ben Greear CC: Andi Kleen , netdev@oss.sgi.com Subject: Re: RFR: new SiS gige driver References: <20030808173932.GA4077@gtf.org> <20030809141533.GB4539@wotan.suse.de> <3F350CC8.3090605@pobox.com> <3F353925.3030106@candelatech.com> In-Reply-To: <3F353925.3030106@candelatech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4808 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 Ben Greear wrote: > Jeff Garzik wrote: > >> Andi Kleen wrote: >> >>> * netif_stop_queue in hard_start_xmit is not protected against the >>> interrupt by the spinlock. That's racy, isn't it? >> >> >> >> Shouldn't be, if done right. If the interrupt runs a TX completion >> cycle, it will run the code >> if (work_done && netif_queue_stopped(dev)) >> netif_wake_queue(dev) >> > >> Since ->hard_start_xmit is guaranteed never to be called if the queue >> is stopped, you also guaranteed that netif_wake_queue and >> ->hard_start_xmit are mutually exclusive. > > > Is this really guaranteed? What if the queue is stopped between the check > to see if it's stopped and the call to hard_start_xmit? Actually, a slight correction (something I forgot): the atomicity is provided by the bitops already so the netif_queue_stopped check isn't needed. Jeff From shemminger@osdl.org Wed Aug 13 13:25:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 13:25:28 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DKPOFl015347 for ; Wed, 13 Aug 2003 13:25:25 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7DKPAo17482; Wed, 13 Aug 2003 13:25:10 -0700 Date: Wed, 13 Aug 2003 13:25:01 -0700 From: Stephen Hemminger To: Alan Cox , Jeff Garzik , Nenad Corbic Cc: netdev@oss.sgi.com Subject: [PATCH] Make z8530.c build on 2.6 Message-Id: <20030813132501.01eb1ecf.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4809 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Either we need to mark this driver (and the parts that use them) as BROKEN, or at least get it building again. With this it builds, but of course, I don't have the real hardware. diff -Nru a/drivers/net/wan/z85230.c b/drivers/net/wan/z85230.c --- a/drivers/net/wan/z85230.c Wed Aug 13 13:17:33 2003 +++ b/drivers/net/wan/z85230.c Wed Aug 13 13:17:33 2003 @@ -890,12 +890,12 @@ if(c->mtu > PAGE_SIZE/2) return -EMSGSIZE; - c->rx_buf[0]=(void *)get_free_page(GFP_KERNEL|GFP_DMA); + c->rx_buf[0]=(void *)get_zeroed_page(GFP_KERNEL|GFP_DMA); if(c->rx_buf[0]==NULL) return -ENOBUFS; c->rx_buf[1]=c->rx_buf[0]+PAGE_SIZE/2; - c->tx_dma_buf[0]=(void *)get_free_page(GFP_KERNEL|GFP_DMA); + c->tx_dma_buf[0]=(void *)get_zeroed_page(GFP_KERNEL|GFP_DMA); if(c->tx_dma_buf[0]==NULL) { free_page((unsigned long)c->rx_buf[0]); @@ -1080,7 +1080,7 @@ if(c->mtu > PAGE_SIZE/2) return -EMSGSIZE; - c->tx_dma_buf[0]=(void *)get_free_page(GFP_KERNEL|GFP_DMA); + c->tx_dma_buf[0]=(void *)get_zeroed_page(GFP_KERNEL|GFP_DMA); if(c->tx_dma_buf[0]==NULL) return -ENOBUFS; From pekkas@netcore.fi Wed Aug 13 13:31:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 13:31:04 -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 h7DKUtFl015792 for ; Wed, 13 Aug 2003 13:30:59 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7DKUnf15335 for ; Wed, 13 Aug 2003 23:30:49 +0300 Date: Wed, 13 Aug 2003 23:30:49 +0300 (EEST) From: Pekka Savola To: netdev@oss.sgi.com Subject: netfilter6: REJECT target? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4810 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev Hi, Is there some reason the IPv6 Netfilter REJECT target hasn't been merged during the last 2 years it has existed in Netfilter's patch-o-matic. (it hasn't been pushed for merging, sure, ...) Just wondering why we are keeping Netfilter6 crippled like this. Unless we can properly use it to reject packets with ICMPv6/TCP-RST, it's pretty close to useless :-( -- 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 Wed Aug 13 13:40:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 13:40: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 h7DKebFl016190 for ; Wed, 13 Aug 2003 13:40:40 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id NAA19040; Wed, 13 Aug 2003 13:34:40 -0700 Date: Wed, 13 Aug 2003 13:34:40 -0700 From: "David S. Miller" To: Pekka Savola Cc: netdev@oss.sgi.com Subject: Re: netfilter6: REJECT target? Message-Id: <20030813133440.23ad50d7.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4811 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 13 Aug 2003 23:30:49 +0300 (EEST) Pekka Savola wrote: > Is there some reason the IPv6 Netfilter REJECT target hasn't been merged > during the last 2 years it has existed in Netfilter's patch-o-matic. It might be more profitable to ask the netfilter lists than here. From jchapman@katalix.com Wed Aug 13 14:10:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 14:10:22 -0700 (PDT) Received: from plesk.avahost.net ([216.40.206.200]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DLAHFl018192 for ; Wed, 13 Aug 2003 14:10:17 -0700 Received: (qmail 15244 invoked by uid 10623); 14 Aug 2003 04:23:43 -0000 Received: from 212.56.89.216 ( [212.56.89.216]) as user jchapman@localhost by webmail.katalix.com with HTTP; Wed, 13 Aug 2003 23:23:43 -0500 Message-ID: <1060835023.3f3b0ecfc97b4@webmail.katalix.com> Date: Wed, 13 Aug 2003 23:23:43 -0500 From: jchapman@katalix.com To: minniewkitty@yahoo.com.cn Cc: netdev@oss.sgi.com Subject: Re: How to improve small packet performance MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 212.56.89.216 X-archive-position: 4812 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jchapman@katalix.com Precedence: bulk X-list: netdev I downloaded the eepro100 NAPI patch and tried it in my test setup (a 1GHz P-III configured as a 2-port bridge, 2.4.20-8 RH9 kernel). I see e100-napi perform much better than eepro100, which is what I was expecting. e100-v3.0.0dev12-napi 93k packets/sec eepro100-napi-020619 49k packets/sec When doing a bidirectional test, the eepro100 driver locks up completely, although it seems to survive with 128 byte packets (where the event rate is less). What's your test setup? How are you generating your test traffic? Do your NIC cards share the same irq? -jc minnie wu wrote: > Hi, all! > I tried e100-napi, but it's performance is still worse than > eepro100-napi. It seems that napi cannot meet my needs. Any ideas? > > jchapman@katalix.com wrote: > > > Try the latest e100 development driver from sf.net/projects/e1000. > > Make >sure you compile it with NAPI enabled. > > minnie wu wrote: > > > Hi, all! > > I'm working on e100/eepro100, kernel version 2.4.20. I > > used NAPI, but the 64 byte small packet dual throughout > > is only 28M/s. How to improve small packet performance further? > ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ From ralph@istop.com Wed Aug 13 14:39:59 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 14:40:26 -0700 (PDT) Received: from smtp.istop.com (dci.doncaster.on.ca [66.11.168.194]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DLdmFl021764 for ; Wed, 13 Aug 2003 14:39:48 -0700 Received: from ns.istop.com (ns.istop.com [66.11.168.199]) by smtp.istop.com (Postfix) with ESMTP id BAC8B36948; Wed, 13 Aug 2003 17:10:56 -0400 (EDT) Date: Wed, 13 Aug 2003 17:10:56 -0400 (EDT) From: Ralph Doncaster Reply-To: ralph+d@istop.com To: Jamie Lokier Cc: "netdev@oss.sgi.com" Subject: Re: [RFC] High Performance Packet Classifiction for tc framework In-Reply-To: <20030813191757.GE4405@mail.jlokier.co.uk> Message-ID: References: <3F16A0E5.1080007@hipac.org> <1059934468.1103.41.camel@jzny.localdomain> <3F2E5CD6.4030500@hipac.org> <1060012260.1103.380.camel@jzny.localdomain> <3F302E04.1090503@hipac.org> <1060286331.1025.73.camel@jzny.localdomain> <3F381B3E.6080807@hipac.org> <20030811224050.59bc36fe.davem@redhat.com> <20030812142913.GB18802@mail.jlokier.co.uk> <20030813191757.GE4405@mail.jlokier.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4813 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ralph@istop.com Precedence: bulk X-list: netdev On Wed, 13 Aug 2003, Jamie Lokier wrote: > You would start by search for a 217.109.0.0/16 entry. That's > the root in the search tree. > > That would match, and the matching tree node would tell you to search > a specific table for 217.109.118.0/24. (Actually, just > 0.0.118.0/0.0.255.0, because this node can assume the first 16 bits). So you have to put an entry in the /16 table for every /16 that you have a more specific route for, right? Then what if I have 3 different routes; one for 217.109.0.0/16, another for 217.109.118.0/24 and one for 217.109.118.68/32? -Ralph From alan@lxorguk.ukuu.org.uk Wed Aug 13 15:24:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 15:24:20 -0700 (PDT) Received: from dhcp23.swansea.linux.org.uk (crosslink-village-512-1.bc.nu [81.2.110.254] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DMOCFl023434 for ; Wed, 13 Aug 2003 15:24:14 -0700 Received: from dhcp23.swansea.linux.org.uk (localhost.localdomain [127.0.0.1]) by dhcp23.swansea.linux.org.uk (8.12.9/8.12.9) with ESMTP id h7DMNlJ2011273; Wed, 13 Aug 2003 23:23:47 +0100 Received: (from alan@localhost) by dhcp23.swansea.linux.org.uk (8.12.9/8.12.9/Submit) id h7DMNjr9011271; Wed, 13 Aug 2003 23:23:45 +0100 X-Authentication-Warning: dhcp23.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: [PATCH] Make z8530.c build on 2.6 From: Alan Cox To: Stephen Hemminger Cc: Jeff Garzik , Nenad Corbic , netdev@oss.sgi.com In-Reply-To: <20030813132501.01eb1ecf.shemminger@osdl.org> References: <20030813132501.01eb1ecf.shemminger@osdl.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1060813424.9130.61.camel@dhcp23.swansea.linux.org.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 (1.4.3-3) Date: 13 Aug 2003 23:23:45 +0100 X-archive-position: 4814 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: netdev On Mer, 2003-08-13 at 21:25, Stephen Hemminger wrote: > Either we need to mark this driver (and the parts that use them) as BROKEN, > or at least get it building again. It works fine. > - c->rx_buf[0]=(void *)get_free_page(GFP_KERNEL|GFP_DMA); > + c->rx_buf[0]=(void *)get_zeroed_page(GFP_KERNEL|GFP_DMA); and doesn't need zeroed pages, I've just got no idea what 2.6 decided to call the give me a free page function, fix that and it'll work fine. (BTW its not one of the sangoma drivers but something I wrote originally so Nenad isnt the guy to cc) From jgarzik@pobox.com Wed Aug 13 15:28:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 15:28:30 -0700 (PDT) Received: from www.linux.org.uk (IDENT:+JnuE3jVvY8dYfiWwiK+roz5cyedVM4h@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DMSOFl023781 for ; Wed, 13 Aug 2003 15:28:25 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19n46P-0007i9-F6; Wed, 13 Aug 2003 23:28:21 +0100 Message-ID: <3F3ABB7A.5080204@pobox.com> Date: Wed, 13 Aug 2003 18:28:10 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: Alan Cox CC: Stephen Hemminger , Nenad Corbic , netdev@oss.sgi.com Subject: Re: [PATCH] Make z8530.c build on 2.6 References: <20030813132501.01eb1ecf.shemminger@osdl.org> <1060813424.9130.61.camel@dhcp23.swansea.linux.org.uk> In-Reply-To: <1060813424.9130.61.camel@dhcp23.swansea.linux.org.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4815 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Alan Cox wrote: > and doesn't need zeroed pages, I've just got no idea what 2.6 decided > to call the give me a free page function, fix that and it'll work fine. Look at 2.4 ;-) include/linux/mm.h:#define get_free_page get_zeroed_page From shemminger@osdl.org Wed Aug 13 15:35:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 15:35:52 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DMZmFl024165 for ; Wed, 13 Aug 2003 15:35:49 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7DMZZo18675; Wed, 13 Aug 2003 15:35:35 -0700 Date: Wed, 13 Aug 2003 15:35:26 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: Jeroen Vreeken , netdev@oss.sgi.com, linux-hams@vger.kernel.org, ralf@linux-mips.org, netdev@oss.sgi.com Subject: [PATCH] (0/11) Netrom patches Message-Id: <20030813153526.2e74e008.shemminger@osdl.org> In-Reply-To: <20030813084252.7b667fb8.davem@redhat.com> References: <20030812194653.A28977@jeroen.pe1rxq.ampr.org> <20030812135655.7334887b.shemminger@osdl.org> <20030812230951.E28977@jeroen.pe1rxq.ampr.org> <20030812153901.6e700dcb.shemminger@osdl.org> <20030813010301.K28977@jeroen.pe1rxq.ampr.org> <20030812172151.7de0c950.shemminger@osdl.org> <20030813031159.6c6c9629.davem@redhat.com> <20030813173446.A2604@jeroen.pe1rxq.ampr.org> <20030813084252.7b667fb8.davem@redhat.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4816 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev The following set of patches breaks out Jeroen's work (1-7) and adds several updates from me. 1 - sysctl initializers 2 - destroy timeout 3 - write queue cleanup on close 4 - socket header length reservation 5 - lock socket's when using 6 - device management fixes 7 - route table use hlist After these it closely matches the version of NETROM in the rxq3 patch set. 8 - make things static 9 - dynamic net device allocation 10 - convert to seq_file 11 - bug fix for using socket after close From shemminger@osdl.org Wed Aug 13 15:39:38 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 15:39:41 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DMdbFl024522 for ; Wed, 13 Aug 2003 15:39:37 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7DMdMo19157; Wed, 13 Aug 2003 15:39:22 -0700 Date: Wed, 13 Aug 2003 15:39:14 -0700 From: Stephen Hemminger To: "David S. Miller" , Jeroen Vreeken Cc: netdev@oss.sgi.com, linux-hams@vger.kernel.org Subject: [PATCH] (1/11) netrom - fix sysctl initializers Message-Id: <20030813153914.608101f7.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4817 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev From: Jeroen Vreeken Change initializers for syctl values. diff -Nru a/net/netrom/sysctl_net_netrom.c b/net/netrom/sysctl_net_netrom.c --- a/net/netrom/sysctl_net_netrom.c Wed Aug 13 11:58:15 2003 +++ b/net/netrom/sysctl_net_netrom.c Wed Aug 13 11:58:15 2003 @@ -15,9 +15,9 @@ /* * Values taken from NET/ROM documentation. */ -static int min_quality[1], max_quality[] = {255}; -static int min_obs[1], max_obs[] = {255}; -static int min_ttl[1], max_ttl[] = {255}; +static int min_quality[] = {0}, max_quality[] = {255}; +static int min_obs[] = {0}, max_obs[] = {255}; +static int min_ttl[] = {0}, max_ttl[] = {255}; static int min_t1[] = {5 * HZ}; static int max_t1[] = {600 * HZ}; static int min_n2[] = {2}, max_n2[] = {127}; @@ -28,7 +28,7 @@ static int min_window[] = {1}, max_window[] = {127}; static int min_idle[] = {0 * HZ}; static int max_idle[] = {65535 * HZ}; -static int min_route[1], max_route[] = {1}; +static int min_route[] = {0}, max_route[] = {1}; static int min_fails[] = {1}, max_fails[] = {10}; static struct ctl_table_header *nr_table_header; From shemminger@osdl.org Wed Aug 13 15:39:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 15:39:44 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DMdfFl024523 for ; Wed, 13 Aug 2003 15:39:41 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7DMdTo19165; Wed, 13 Aug 2003 15:39:29 -0700 Date: Wed, 13 Aug 2003 15:39:20 -0700 From: Stephen Hemminger To: "David S. Miller" , Jeroen Vreeken Cc: netdev@oss.sgi.com, linux-hams@vger.kernel.org Subject: [PATCH] (2/11) netrom - shorten destroy timeout Message-Id: <20030813153920.68d52970.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4818 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev From: Jeroen Vreeken Expire sockets faster on close diff -Nru a/net/netrom/af_netrom.c b/net/netrom/af_netrom.c --- a/net/netrom/af_netrom.c Wed Aug 13 11:58:31 2003 +++ b/net/netrom/af_netrom.c Wed Aug 13 11:58:31 2003 @@ -269,7 +269,7 @@ atomic_read(&sk->sk_rmem_alloc)) { /* Defer: outstanding buffers */ init_timer(&sk->sk_timer); - sk->sk_timer.expires = jiffies + 10 * HZ; + sk->sk_timer.expires = jiffies + 2 * HZ; sk->sk_timer.function = nr_destroy_timer; sk->sk_timer.data = (unsigned long)sk; add_timer(&sk->sk_timer); From shemminger@osdl.org Wed Aug 13 15:39:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 15:39:53 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DMdnFl024569 for ; Wed, 13 Aug 2003 15:39:50 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7DMdco19206; Wed, 13 Aug 2003 15:39:38 -0700 Date: Wed, 13 Aug 2003 15:39:29 -0700 From: Stephen Hemminger To: "David S. Miller" , Jeroen Vreeken Cc: netdev@oss.sgi.com, linux-hams@vger.kernel.org Subject: [PATCH] (3/11) netrom - drop buffers in write queue on close Message-Id: <20030813153929.3fe71b60.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4819 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev From: Jeroen Vreeken Free buffers in write queue on socket destroy diff -Nru a/net/netrom/af_netrom.c b/net/netrom/af_netrom.c --- a/net/netrom/af_netrom.c Wed Aug 13 11:58:59 2003 +++ b/net/netrom/af_netrom.c Wed Aug 13 11:58:59 2003 @@ -264,6 +264,9 @@ kfree_skb(skb); } + while ((skb = skb_dequeue(&sk->sk_write_queue)) != NULL) { + kfree_skb(skb); + } if (atomic_read(&sk->sk_wmem_alloc) || atomic_read(&sk->sk_rmem_alloc)) { From shemminger@osdl.org Wed Aug 13 15:41:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 15:41:44 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DMfeFl025526 for ; Wed, 13 Aug 2003 15:41:41 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7DMfSo19874; Wed, 13 Aug 2003 15:41:28 -0700 Date: Wed, 13 Aug 2003 15:41:20 -0700 From: Stephen Hemminger To: "David S. Miller" , Jeroen Vreeken , netdev@oss.sgi.com, linux-hams@vger.kernel.org Subject: [PATCH] (6/11) netrom - ax25 interface changes Message-Id: <20030813154120.0b2ef7e8.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4820 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev From: Jeroen Vreeken Better control over the AX25 devices diff -Nru a/net/netrom/af_netrom.c b/net/netrom/af_netrom.c --- a/net/netrom/af_netrom.c Wed Aug 13 13:19:42 2003 +++ b/net/netrom/af_netrom.c Wed Aug 13 13:19:42 2003 @@ -1363,6 +1363,7 @@ for (i = 0; i < nr_ndevs; i++) { sprintf(dev_nr[i].name, "nr%d", i); + dev_nr[i].base_addr = i; dev_nr[i].init = nr_init; register_netdev(&dev_nr[i]); } @@ -1407,23 +1408,23 @@ nr_rt_free(); - ax25_protocol_release(AX25_P_NETROM); +#ifdef CONFIG_SYSCTL + nr_unregister_sysctl(); +#endif + ax25_linkfail_release(nr_link_failed); + ax25_protocol_release(AX25_P_NETROM); unregister_netdevice_notifier(&nr_dev_notifier); -#ifdef CONFIG_SYSCTL - nr_unregister_sysctl(); -#endif sock_unregister(PF_NETROM); for (i = 0; i < nr_ndevs; i++) { if (dev_nr[i].priv != NULL) { + unregister_netdev(&dev_nr[i]); kfree(dev_nr[i].priv); dev_nr[i].priv = NULL; - unregister_netdev(&dev_nr[i]); } - kfree(dev_nr[i].name); } kfree(dev_nr); diff -Nru a/net/netrom/nr_dev.c b/net/netrom/nr_dev.c --- a/net/netrom/nr_dev.c Wed Aug 13 13:19:42 2003 +++ b/net/netrom/nr_dev.c Wed Aug 13 13:19:42 2003 @@ -159,11 +159,13 @@ { struct sockaddr *sa = addr; - ax25_listen_release((ax25_address *)dev->dev_addr, NULL); + if (dev->flags & IFF_UP) + ax25_listen_release((ax25_address *)dev->dev_addr, NULL); memcpy(dev->dev_addr, sa->sa_data, dev->addr_len); - ax25_listen_register((ax25_address *)dev->dev_addr, NULL); + if (dev->flags & IFF_UP) + ax25_listen_register((ax25_address *)dev->dev_addr, NULL); return 0; } @@ -177,8 +179,8 @@ static int nr_close(struct net_device *dev) { - netif_stop_queue(dev); ax25_listen_release((ax25_address *)dev->dev_addr, NULL); + netif_stop_queue(dev); return 0; } @@ -207,6 +208,7 @@ dev->hard_header_len = NR_NETWORK_LEN + NR_TRANSPORT_LEN; dev->addr_len = AX25_ADDR_LEN; dev->type = ARPHRD_NETROM; + dev->tx_queue_len = 40; dev->rebuild_header = nr_rebuild_header; dev->set_mac_address = nr_set_mac_address; From shemminger@osdl.org Wed Aug 13 15:42:21 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 15:42:23 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DMgJFl025710 for ; Wed, 13 Aug 2003 15:42:20 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7DMg7o20012; Wed, 13 Aug 2003 15:42:07 -0700 Date: Wed, 13 Aug 2003 15:41:59 -0700 From: Stephen Hemminger To: "David S. Miller" , Jeroen Vreeken Cc: netdev@oss.sgi.com, linux-hams@vger.kernel.org Subject: [PATCH] (4/11) netrom - reserve room for AX25 header in skb Message-Id: <20030813154159.3775dd90.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4821 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev From: Jeroen Vreeken Reserve space in socket header for AX25 header. diff -Nru a/net/netrom/nr_dev.c b/net/netrom/nr_dev.c --- a/net/netrom/nr_dev.c Wed Aug 13 12:22:13 2003 +++ b/net/netrom/nr_dev.c Wed Aug 13 12:22:13 2003 @@ -204,7 +204,7 @@ dev->stop = nr_close; dev->hard_header = nr_header; - dev->hard_header_len = AX25_BPQ_HEADER_LEN + AX25_MAX_HEADER_LEN + NR_NETWORK_LEN + NR_TRANSPORT_LEN; + dev->hard_header_len = NR_NETWORK_LEN + NR_TRANSPORT_LEN; dev->addr_len = AX25_ADDR_LEN; dev->type = ARPHRD_NETROM; dev->rebuild_header = nr_rebuild_header; diff -Nru a/net/netrom/nr_subr.c b/net/netrom/nr_subr.c --- a/net/netrom/nr_subr.c Wed Aug 13 12:22:13 2003 +++ b/net/netrom/nr_subr.c Wed Aug 13 12:22:13 2003 @@ -127,7 +127,7 @@ unsigned char *dptr; int len, timeout; - len = AX25_BPQ_HEADER_LEN + AX25_MAX_HEADER_LEN + NR_NETWORK_LEN + NR_TRANSPORT_LEN; + len = NR_NETWORK_LEN + NR_TRANSPORT_LEN; switch (frametype & 0x0F) { case NR_CONNREQ: @@ -151,7 +151,7 @@ /* * Space for AX.25 and NET/ROM network header */ - skb_reserve(skb, AX25_BPQ_HEADER_LEN + AX25_MAX_HEADER_LEN + NR_NETWORK_LEN); + skb_reserve(skb, NR_NETWORK_LEN); dptr = skb_put(skb, skb_tailroom(skb)); @@ -219,12 +219,12 @@ unsigned char *dptr; int len; - len = AX25_BPQ_HEADER_LEN + AX25_MAX_HEADER_LEN + NR_NETWORK_LEN + NR_TRANSPORT_LEN + 1; + len = NR_NETWORK_LEN + NR_TRANSPORT_LEN + 1; if ((skbn = alloc_skb(len, GFP_ATOMIC)) == NULL) return; - skb_reserve(skbn, AX25_BPQ_HEADER_LEN + AX25_MAX_HEADER_LEN); + skb_reserve(skbn, 0); dptr = skb_put(skbn, NR_NETWORK_LEN + NR_TRANSPORT_LEN); From shemminger@osdl.org Wed Aug 13 15:45:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 15:45:42 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DMjdFl026533 for ; Wed, 13 Aug 2003 15:45:39 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7DMjQo20781; Wed, 13 Aug 2003 15:45:26 -0700 Date: Wed, 13 Aug 2003 15:45:17 -0700 From: Stephen Hemminger To: "David S. Miller" , Jeroen Vreeken Cc: linux-hams@vger.kernel.org, netdev@oss.sgi.com Subject: [PATCH] (8/11) netrom - make lists and locks static Message-Id: <20030813154517.6c82f112.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4822 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Make lists and locks static since they are only used in one file. diff -Nru a/net/netrom/af_netrom.c b/net/netrom/af_netrom.c --- a/net/netrom/af_netrom.c Wed Aug 13 13:31:48 2003 +++ b/net/netrom/af_netrom.c Wed Aug 13 13:31:48 2003 @@ -57,8 +57,8 @@ static unsigned short circuit = 0x101; -HLIST_HEAD(nr_list); -static spinlock_t nr_list_lock; +static HLIST_HEAD(nr_list); +static spinlock_t nr_list_lock = SPIN_LOCK_UNLOCKED; static struct proto_ops nr_proto_ops; diff -Nru a/net/netrom/nr_route.c b/net/netrom/nr_route.c --- a/net/netrom/nr_route.c Wed Aug 13 13:31:48 2003 +++ b/net/netrom/nr_route.c Wed Aug 13 13:31:48 2003 @@ -39,10 +39,10 @@ static unsigned int nr_neigh_no = 1; -HLIST_HEAD(nr_node_list); -spinlock_t nr_node_list_lock = SPIN_LOCK_UNLOCKED; -HLIST_HEAD(nr_neigh_list); -spinlock_t nr_neigh_list_lock = SPIN_LOCK_UNLOCKED; +static HLIST_HEAD(nr_node_list); +static spinlock_t nr_node_list_lock = SPIN_LOCK_UNLOCKED; +static HLIST_HEAD(nr_neigh_list); +static spinlock_t nr_neigh_list_lock = SPIN_LOCK_UNLOCKED; struct nr_node *nr_node_get(ax25_address *callsign) { From shemminger@osdl.org Wed Aug 13 15:47:01 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 15:47:04 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DMl1Fl026949 for ; Wed, 13 Aug 2003 15:47:01 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7DMkio21080; Wed, 13 Aug 2003 15:46:44 -0700 Date: Wed, 13 Aug 2003 15:46:35 -0700 From: Stephen Hemminger To: "David S. Miller" , Jeroen Vreeken Cc: linux-hams@vger.kernel.org, netdev@oss.sgi.com Subject: [PATCH] (10/11) netrom - convert /proc interface to seq_file Message-Id: <20030813154635.376df59b.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4823 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Convert netrom /proc interface to seq_file. diff -Nru a/include/net/netrom.h b/include/net/netrom.h --- a/include/net/netrom.h Wed Aug 13 13:54:19 2003 +++ b/include/net/netrom.h Wed Aug 13 13:54:19 2003 @@ -209,8 +209,8 @@ extern int nr_rt_ioctl(unsigned int, void *); extern void nr_link_failed(ax25_cb *, int); extern int nr_route_frame(struct sk_buff *, ax25_cb *); -extern int nr_nodes_get_info(char *, char **, off_t, int); -extern int nr_neigh_get_info(char *, char **, off_t, int); +extern struct file_operations nr_nodes_fops; +extern struct file_operations nr_neigh_fops; extern void nr_rt_free(void); /* nr_subr.c */ diff -Nru a/net/netrom/af_netrom.c b/net/netrom/af_netrom.c --- a/net/netrom/af_netrom.c Wed Aug 13 13:54:19 2003 +++ b/net/netrom/af_netrom.c Wed Aug 13 13:54:19 2003 @@ -36,6 +36,7 @@ #include #include #include +#include #include #include #include @@ -1234,22 +1235,54 @@ return 0; } -static int nr_get_info(char *buffer, char **start, off_t offset, int length) +#ifdef CONFIG_PROC_FS + +/* Marker for header entry */ +#define NETROM_PROC_START ((void *)1) +static void *nr_info_start(struct seq_file *seq, loff_t *pos) { struct sock *s; struct hlist_node *node; + int i = 1; + + spin_lock_bh(&nr_list_lock); + if (*pos == 0) + return NETROM_PROC_START; + + sk_for_each(s, node, &nr_list) { + if (i == *pos) + return s; + ++i; + } + return NULL; +} + +static void *nr_info_next(struct seq_file *seq, void *v, loff_t *pos) +{ + ++*pos; + + return (v == NETROM_PROC_START) ? sk_head(&nr_list) + : sk_next((struct sock *)v); +} + +static void nr_info_stop(struct seq_file *seq, void *v) +{ + spin_unlock_bh(&nr_list_lock); +} + +static int nr_info_show(struct seq_file *seq, void *v) +{ + struct sock *s = v; struct net_device *dev; + nr_cb *nr; const char *devname; - int len = 0; - off_t pos = 0; - off_t begin = 0; - spin_lock_bh(&nr_list_lock); + if (v == NETROM_PROC_START) + seq_puts(seq, +"user_addr dest_node src_node dev my your st vs vr va t1 t2 t4 idle n2 wnd Snd-Q Rcv-Q inode\n"); - len += sprintf(buffer, "user_addr dest_node src_node dev my your st vs vr va t1 t2 t4 idle n2 wnd Snd-Q Rcv-Q inode\n"); + else { - sk_for_each(s, node, &nr_list) { - nr_cb *nr; bh_lock_sock(s); nr = nr_sk(s); @@ -1258,11 +1291,10 @@ else devname = dev->name; - len += sprintf(buffer + len, "%-9s ", - ax2asc(&nr->user_addr)); - len += sprintf(buffer + len, "%-9s ", - ax2asc(&nr->dest_addr)); - len += sprintf(buffer + len, "%-9s %-3s %02X/%02X %02X/%02X %2d %3d %3d %3d %3lu/%03lu %2lu/%02lu %3lu/%03lu %3lu/%03lu %2d/%02d %3d %5d %5d %ld\n", + seq_printf(seq, "%-9s ", ax2asc(&nr->user_addr)); + seq_printf(seq, "%-9s ", ax2asc(&nr->dest_addr)); + seq_printf(seq, +"%-9s %-3s %02X/%02X %02X/%02X %2d %3d %3d %3d %3lu/%03lu %2lu/%02lu %3lu/%03lu %3lu/%03lu %2d/%02d %3d %5d %5d %ld\n", ax2asc(&nr->source_addr), devname, nr->my_index, @@ -1288,27 +1320,31 @@ atomic_read(&s->sk_rmem_alloc), s->sk_socket ? SOCK_INODE(s->sk_socket)->i_ino : 0L); - pos = begin + len; - - if (pos < offset) { - len = 0; - begin = pos; - } bh_unlock_sock(s); - if (pos > offset + length) - break; } + return 0; +} - spin_unlock_bh(&nr_list_lock); - - *start = buffer + (offset - begin); - len -= (offset - begin); - - if (len > length) - len = length; - - return len; +static struct seq_operations nr_info_seqops = { + .start = nr_info_start, + .next = nr_info_next, + .stop = nr_info_stop, + .show = nr_info_show, +}; + +static int nr_info_open(struct inode *inode, struct file *file) +{ + return seq_open(file, &nr_info_seqops); } + +static struct file_operations nr_info_fops = { + .owner = THIS_MODULE, + .open = nr_info_open, + .read = seq_read, + .llseek = seq_lseek, + .release = seq_release, +}; +#endif /* CONFIG_PROC_FS */ static struct net_proto_family nr_family_ops = { .family = PF_NETROM, @@ -1399,10 +1435,11 @@ nr_loopback_init(); - proc_net_create("nr", 0, nr_get_info); - proc_net_create("nr_neigh", 0, nr_neigh_get_info); - proc_net_create("nr_nodes", 0, nr_nodes_get_info); + proc_net_fops_create("nr", S_IRUGO, &nr_info_fops); + proc_net_fops_create("nr_neigh", S_IRUGO, &nr_neigh_fops); + proc_net_fops_create("nr_nodes", S_IRUGO, &nr_nodes_fops); return 0; + fail: while (--i >= 0) unregister_netdev(dev_nr[i]); diff -Nru a/net/netrom/nr_route.c b/net/netrom/nr_route.c --- a/net/netrom/nr_route.c Wed Aug 13 13:54:19 2003 +++ b/net/netrom/nr_route.c Wed Aug 13 13:54:19 2003 @@ -36,6 +36,7 @@ #include #include #include +#include static unsigned int nr_neigh_no = 1; @@ -839,70 +840,138 @@ return ret; } -int nr_nodes_get_info(char *buffer, char **start, off_t offset, int length) +#ifdef CONFIG_PROC_FS +#define NETROM_PROC_START ((void *) 1) + +static void *nr_node_start(struct seq_file *seq, loff_t *pos) { struct nr_node *nr_node; struct hlist_node *node; - int len = 0; - off_t pos = 0; - off_t begin = 0; - int i; - - spin_lock_bh(&nr_node_list_lock); - len += sprintf(buffer, "callsign mnemonic w n qual obs neigh qual obs neigh qual obs neigh\n"); + int i = 1; + + spin_lock_bh(&nr_node_list_lock); + if (*pos == 0) + return NETROM_PROC_START; nr_node_for_each(nr_node, node, &nr_node_list) { + if (i == *pos) + return nr_node; + ++i; + } + + return NULL; +} + +static void *nr_node_next(struct seq_file *seq, void *v, loff_t *pos) +{ + struct hlist_node *node; + ++*pos; + + node = (v == NETROM_PROC_START) + ? nr_node_list.first + : ((struct nr_node *)v)->node_node.next; + + return hlist_entry(node, struct nr_node, node_node); +} + +static void nr_node_stop(struct seq_file *seq, void *v) +{ + spin_unlock_bh(&nr_node_list_lock); +} + +static int nr_node_show(struct seq_file *seq, void *v) +{ + int i; + + if (v == NETROM_PROC_START) + seq_puts(seq, + "callsign mnemonic w n qual obs neigh qual obs neigh qual obs neigh\n"); + else { + struct nr_node *nr_node = v; nr_node_lock(nr_node); - len += sprintf(buffer + len, "%-9s %-7s %d %d", + seq_printf(seq, "%-9s %-7s %d %d", ax2asc(&nr_node->callsign), (nr_node->mnemonic[0] == '\0') ? "*" : nr_node->mnemonic, nr_node->which + 1, nr_node->count); for (i = 0; i < nr_node->count; i++) { - len += sprintf(buffer + len, " %3d %d %05d", + seq_printf(seq, " %3d %d %05d", nr_node->routes[i].quality, nr_node->routes[i].obs_count, nr_node->routes[i].neighbour->number); } nr_node_unlock(nr_node); - len += sprintf(buffer + len, "\n"); + seq_puts(seq, "\n"); + } + return 0; +} - pos = begin + len; +static struct seq_operations nr_node_seqops = { + .start = nr_node_start, + .next = nr_node_next, + .stop = nr_node_stop, + .show = nr_node_show, +}; + +static int nr_node_info_open(struct inode *inode, struct file *file) +{ + return seq_open(file, &nr_node_seqops); +} + +struct file_operations nr_nodes_fops = { + .owner = THIS_MODULE, + .open = nr_node_info_open, + .read = seq_read, + .llseek = seq_lseek, + .release = seq_release, +}; - if (pos < offset) { - len = 0; - begin = pos; - } +static void *nr_neigh_start(struct seq_file *seq, loff_t *pos) +{ + struct nr_neigh *nr_neigh; + struct hlist_node *node; + int i = 1; - if (pos > offset + length) - break; + spin_lock_bh(&nr_neigh_list_lock); + if (*pos == 0) + return NETROM_PROC_START; + + nr_neigh_for_each(nr_neigh, node, &nr_neigh_list) { + if (i == *pos) + return nr_neigh; } - spin_unlock_bh(&nr_node_list_lock); + return NULL; +} - *start = buffer + (offset - begin); - len -= (offset - begin); +static void *nr_neigh_next(struct seq_file *seq, void *v, loff_t *pos) +{ + struct hlist_node *node; + ++*pos; + + node = (v == NETROM_PROC_START) + ? nr_neigh_list.first + : ((struct nr_neigh *)v)->neigh_node.next; - if (len > length) len = length; + return hlist_entry(node, struct nr_neigh, neigh_node); +} - return len; +static void nr_neigh_stop(struct seq_file *seq, void *v) +{ + spin_unlock_bh(&nr_neigh_list_lock); } -int nr_neigh_get_info(char *buffer, char **start, off_t offset, int length) +static int nr_neigh_show(struct seq_file *seq, void *v) { - struct nr_neigh *nr_neigh; - struct hlist_node *node; - int len = 0; - off_t pos = 0; - off_t begin = 0; int i; - spin_lock_bh(&nr_neigh_list_lock); - len += sprintf(buffer, "addr callsign dev qual lock count failed digipeaters\n"); + if (v == NETROM_PROC_START) + seq_puts(seq, "addr callsign dev qual lock count failed digipeaters\n"); + else { + struct nr_neigh *nr_neigh = v; - nr_neigh_for_each(nr_neigh, node, &nr_neigh_list) { - len += sprintf(buffer + len, "%05d %-9s %-4s %3d %d %3d %3d", + seq_printf(seq, "%05d %-9s %-4s %3d %d %3d %3d", nr_neigh->number, ax2asc(&nr_neigh->callsign), nr_neigh->dev ? nr_neigh->dev->name : "???", @@ -913,31 +982,36 @@ if (nr_neigh->digipeat != NULL) { for (i = 0; i < nr_neigh->digipeat->ndigi; i++) - len += sprintf(buffer + len, " %s", ax2asc(&nr_neigh->digipeat->calls[i])); + seq_printf(seq, " %s", + ax2asc(&nr_neigh->digipeat->calls[i])); } - len += sprintf(buffer + len, "\n"); - - pos = begin + len; - - if (pos < offset) { - len = 0; - begin = pos; - } - - if (pos > offset + length) - break; + seq_puts(seq, "\n"); } + return 0; +} - spin_unlock_bh(&nr_neigh_list_lock); - - *start = buffer + (offset - begin); - len -= (offset - begin); - - if (len > length) len = length; +static struct seq_operations nr_neigh_seqops = { + .start = nr_neigh_start, + .next = nr_neigh_next, + .stop = nr_neigh_stop, + .show = nr_neigh_show, +}; + +static int nr_neigh_info_open(struct inode *inode, struct file *file) +{ + return seq_open(file, &nr_neigh_seqops); +} + +struct file_operations nr_neigh_fops = { + .owner = THIS_MODULE, + .open = nr_neigh_info_open, + .read = seq_read, + .llseek = seq_lseek, + .release = seq_release, +}; - return len; -} +#endif /* * Free all memory associated with the nodes and routes lists. From shemminger@osdl.org Wed Aug 13 15:47:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 15:47:33 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DMlUFl027094 for ; Wed, 13 Aug 2003 15:47:30 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7DMlHo21942; Wed, 13 Aug 2003 15:47:17 -0700 Date: Wed, 13 Aug 2003 15:47:09 -0700 From: Stephen Hemminger To: "David S. Miller" , Jeroen Vreeken Cc: linux-hams@vger.kernel.org, netdev@oss.sgi.com Subject: [PATCH] (9/11) netrom - convert to alloc_netdev Message-Id: <20030813154709.66812756.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4824 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Convert net_device's from array of structures to an array of pointers, so they can be freed individually on module exit. The net_device_stats are stored at dev->priv diff -Nru a/include/net/netrom.h b/include/net/netrom.h --- a/include/net/netrom.h Wed Aug 13 14:22:03 2003 +++ b/include/net/netrom.h Wed Aug 13 14:22:03 2003 @@ -183,7 +183,7 @@ /* nr_dev.c */ extern int nr_rx_ip(struct sk_buff *, struct net_device *); -extern int nr_init(struct net_device *); +extern void nr_setup(struct net_device *); /* nr_in.c */ extern int nr_process_rx_frame(struct sock *, struct sk_buff *); diff -Nru a/net/netrom/af_netrom.c b/net/netrom/af_netrom.c --- a/net/netrom/af_netrom.c Wed Aug 13 14:22:03 2003 +++ b/net/netrom/af_netrom.c Wed Aug 13 14:22:03 2003 @@ -1341,7 +1341,7 @@ .notifier_call = nr_device_event, }; -static struct net_device *dev_nr; +static struct net_device **dev_nr; static char banner[] __initdata = KERN_INFO "G4KLX NET/ROM for Linux. Version 0.7 for AX25.037 Linux 2.4\n"; @@ -1354,21 +1354,39 @@ return -1; } - if ((dev_nr = kmalloc(nr_ndevs * sizeof(struct net_device), GFP_KERNEL)) == NULL) { - printk(KERN_ERR "NET/ROM: nr_proto_init - unable to allocate device structure\n"); + dev_nr = kmalloc(nr_ndevs * sizeof(struct net_device *), GFP_KERNEL); + if (dev_nr == NULL) { + printk(KERN_ERR "NET/ROM: nr_proto_init - unable to allocate device array\n"); return -1; } - memset(dev_nr, 0x00, nr_ndevs * sizeof(struct net_device)); + memset(dev_nr, 0x00, nr_ndevs * sizeof(struct net_device *)); for (i = 0; i < nr_ndevs; i++) { - sprintf(dev_nr[i].name, "nr%d", i); - dev_nr[i].base_addr = i; - dev_nr[i].init = nr_init; - register_netdev(&dev_nr[i]); + char name[IFNAMSIZ]; + struct net_device *dev; + + sprintf(name, "nr%d", i); + dev = alloc_netdev(sizeof(struct net_device_stats), name, + nr_setup); + if (!dev) { + printk(KERN_ERR "NET/ROM: nr_proto_init - unable to allocate device structure\n"); + goto fail; + } + + dev->base_addr = i; + if (register_netdev(dev)) { + printk(KERN_ERR "NET/ROM: nr_proto_init - unable to register network device\n"); + goto fail; + } + dev_nr[i] = dev; } - sock_register(&nr_family_ops); + if (sock_register(&nr_family_ops)) { + printk(KERN_ERR "NET/ROM: nr_proto_init - unable to register socket family\n"); + goto fail; + } + register_netdevice_notifier(&nr_dev_notifier); printk(banner); @@ -1385,6 +1403,11 @@ proc_net_create("nr_neigh", 0, nr_neigh_get_info); proc_net_create("nr_nodes", 0, nr_nodes_get_info); return 0; + fail: + while (--i >= 0) + unregister_netdev(dev_nr[i]); + kfree(dev_nr); + return -1; } module_init(nr_proto_init); @@ -1420,11 +1443,9 @@ sock_unregister(PF_NETROM); for (i = 0; i < nr_ndevs; i++) { - if (dev_nr[i].priv != NULL) { - unregister_netdev(&dev_nr[i]); - kfree(dev_nr[i].priv); - dev_nr[i].priv = NULL; - } + struct net_device *dev = dev_nr[i]; + if (dev) + unregister_netdev(dev); } kfree(dev_nr); diff -Nru a/net/netrom/nr_dev.c b/net/netrom/nr_dev.c --- a/net/netrom/nr_dev.c Wed Aug 13 14:22:03 2003 +++ b/net/netrom/nr_dev.c Wed Aug 13 14:22:03 2003 @@ -197,12 +197,13 @@ return (struct net_device_stats *)dev->priv; } -int nr_init(struct net_device *dev) +void nr_setup(struct net_device *dev) { SET_MODULE_OWNER(dev); dev->mtu = NR_MAX_PACKET_SIZE; dev->hard_start_xmit = nr_xmit; dev->open = nr_open; dev->stop = nr_close; + dev->destructor = (void (*)(struct net_device *))kfree; dev->hard_header = nr_header; @@ -215,12 +216,5 @@ /* New-style flags. */ dev->flags = 0; - if ((dev->priv = kmalloc(sizeof(struct net_device_stats), GFP_KERNEL)) == NULL) - return -ENOMEM; - - memset(dev->priv, 0, sizeof(struct net_device_stats)); - - dev->get_stats = nr_get_stats; - - return 0; -}; + dev->get_stats = nr_get_stats; +} From shemminger@osdl.org Wed Aug 13 15:49:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 15:49:20 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DMnFFl027604 for ; Wed, 13 Aug 2003 15:49:16 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7DMn1o22198; Wed, 13 Aug 2003 15:49:01 -0700 Date: Wed, 13 Aug 2003 15:48:52 -0700 From: Stephen Hemminger To: "David S. Miller" , Jeroen Vreeken Cc: linux-hams@vger.kernel.org, netdev@oss.sgi.com Subject: [PATCH] (11/11) netrom - fix use after free in close Message-Id: <20030813154852.45704d29.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4825 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev netrom would oops if one did: modprobe netrom ifconfig -a because the code in destroy was freeing the socket then release_sock was called. diff -Nru a/net/netrom/af_netrom.c b/net/netrom/af_netrom.c --- a/net/netrom/af_netrom.c Wed Aug 13 15:33:26 2003 +++ b/net/netrom/af_netrom.c Wed Aug 13 15:33:26 2003 @@ -516,6 +516,7 @@ if (sk == NULL) return 0; + sock_hold(sk); lock_sock(sk); nr = nr_sk(sk); @@ -551,6 +552,7 @@ sock->sk = NULL; release_sock(sk); + sock_put(sk); return 0; } From shemminger@osdl.org Wed Aug 13 16:03:23 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 16:03:28 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DN3MFl028112 for ; Wed, 13 Aug 2003 16:03:23 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7DN39o25510; Wed, 13 Aug 2003 16:03:09 -0700 Date: Wed, 13 Aug 2003 16:03:00 -0700 From: Stephen Hemminger To: "David S. Miller" , Jeroen Vreeken Cc: linux-hams@vger.kernel.org, netdev@oss.sgi.com Subject: [PATCH] (5/11) netrom - lock sockets during usage Message-Id: <20030813160300.64d3fb54.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4826 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev From: Jeroen Vreeken Lock sockets while doing protocol processing. diff -Nru a/net/netrom/af_netrom.c b/net/netrom/af_netrom.c --- a/net/netrom/af_netrom.c Wed Aug 13 12:22:36 2003 +++ b/net/netrom/af_netrom.c Wed Aug 13 12:22:36 2003 @@ -147,8 +147,10 @@ spin_lock_bh(&nr_list_lock); sk_for_each(s, node, &nr_list) if (!ax25cmp(&nr_sk(s)->source_addr, addr) && - s->sk_state == TCP_LISTEN) + s->sk_state == TCP_LISTEN) { + bh_lock_sock(s); goto found; + } s = NULL; found: spin_unlock_bh(&nr_list_lock); @@ -167,8 +169,10 @@ sk_for_each(s, node, &nr_list) { nr_cb *nr = nr_sk(s); - if (nr->my_index == index && nr->my_id == id) + if (nr->my_index == index && nr->my_id == id) { + bh_lock_sock(s); goto found; + } } s = NULL; found: @@ -190,8 +194,10 @@ nr_cb *nr = nr_sk(s); if (nr->your_index == index && nr->your_id == id && - !ax25cmp(&nr->dest_addr, dest)) + !ax25cmp(&nr->dest_addr, dest)) { + bh_lock_sock(s); goto found; + } } s = NULL; found: @@ -206,14 +212,17 @@ { unsigned short id = circuit; unsigned char i, j; + struct sock *sk; for (;;) { i = id / 256; j = id % 256; - if (i != 0 && j != 0) - if (nr_find_socket(i, j) == NULL) + if (i != 0 && j != 0) { + if ((sk=nr_find_socket(i, j)) == NULL) break; + bh_unlock_sock(sk); + } id++; } @@ -231,7 +240,12 @@ */ static void nr_destroy_timer(unsigned long data) { - nr_destroy_socket((struct sock *)data); + struct sock *sk=(struct sock *)data; + bh_lock_sock(sk); + sock_hold(sk); + nr_destroy_socket(sk); + bh_unlock_sock(sk); + sock_put(sk); } /* @@ -277,7 +291,7 @@ sk->sk_timer.data = (unsigned long)sk; add_timer(&sk->sk_timer); } else - sk_free(sk); + sock_put(sk); } /* @@ -391,12 +405,15 @@ { struct sock *sk = sock->sk; + lock_sock(sk); if (sk->sk_state != TCP_LISTEN) { memset(&nr_sk(sk)->user_addr, 0, AX25_ADDR_LEN); sk->sk_max_ack_backlog = backlog; sk->sk_state = TCP_LISTEN; + release_sock(sk); return 0; } + release_sock(sk); return -EOPNOTSUPP; } @@ -498,6 +515,7 @@ if (sk == NULL) return 0; + lock_sock(sk); nr = nr_sk(sk); switch (nr->state) { @@ -531,6 +549,7 @@ } sock->sk = NULL; + release_sock(sk); return 0; } @@ -543,21 +562,26 @@ struct net_device *dev; ax25_address *user, *source; - if (!sk->sk_zapped) + lock_sock(sk); + if (!sk->sk_zapped) { + release_sock(sk); return -EINVAL; - - if (addr_len < sizeof(struct sockaddr_ax25) || addr_len > sizeof(struct -full_sockaddr_ax25)) + } + if (addr_len < sizeof(struct sockaddr_ax25) || addr_len > sizeof(struct full_sockaddr_ax25)) { + release_sock(sk); return -EINVAL; - - if (addr_len < (addr->fsa_ax25.sax25_ndigis * sizeof(ax25_address) + sizeof(struct sockaddr_ax25))) + } + if (addr_len < (addr->fsa_ax25.sax25_ndigis * sizeof(ax25_address) + sizeof(struct sockaddr_ax25))) { + release_sock(sk); return -EINVAL; - - if (addr->fsa_ax25.sax25_family != AF_NETROM) + } + if (addr->fsa_ax25.sax25_family != AF_NETROM) { + release_sock(sk); return -EINVAL; - + } if ((dev = nr_dev_get(&addr->fsa_ax25.sax25_call)) == NULL) { SOCK_DEBUG(sk, "NET/ROM: bind failed: invalid node callsign\n"); + release_sock(sk); return -EADDRNOTAVAIL; } @@ -565,16 +589,22 @@ * Only the super user can set an arbitrary user callsign. */ if (addr->fsa_ax25.sax25_ndigis == 1) { - if (!capable(CAP_NET_BIND_SERVICE)) + if (!capable(CAP_NET_BIND_SERVICE)) { + dev_put(dev); + release_sock(sk); return -EACCES; + } nr->user_addr = addr->fsa_digipeater[0]; nr->source_addr = addr->fsa_ax25.sax25_call; } else { source = &addr->fsa_ax25.sax25_call; if ((user = ax25_findbyuid(current->euid)) == NULL) { - if (ax25_uid_policy && !capable(CAP_NET_BIND_SERVICE)) + if (ax25_uid_policy && !capable(CAP_NET_BIND_SERVICE)) { + release_sock(sk); + dev_put(dev); return -EPERM; + } user = source; } @@ -586,6 +616,8 @@ nr_insert_socket(sk); sk->sk_zapped = 0; + dev_put(dev); + release_sock(sk); SOCK_DEBUG(sk, "NET/ROM: socket is bound\n"); return 0; } @@ -599,39 +631,50 @@ ax25_address *user, *source = NULL; struct net_device *dev; + lock_sock(sk); if (sk->sk_state == TCP_ESTABLISHED && sock->state == SS_CONNECTING) { sock->state = SS_CONNECTED; + release_sock(sk); return 0; /* Connect completed during a ERESTARTSYS event */ } if (sk->sk_state == TCP_CLOSE && sock->state == SS_CONNECTING) { sock->state = SS_UNCONNECTED; + release_sock(sk); return -ECONNREFUSED; } - if (sk->sk_state == TCP_ESTABLISHED) + if (sk->sk_state == TCP_ESTABLISHED) { + release_sock(sk); return -EISCONN; /* No reconnect on a seqpacket socket */ + } sk->sk_state = TCP_CLOSE; sock->state = SS_UNCONNECTED; - if (addr_len != sizeof(struct sockaddr_ax25) && addr_len != sizeof(struct full_sockaddr_ax25)) + if (addr_len != sizeof(struct sockaddr_ax25) && addr_len != sizeof(struct full_sockaddr_ax25)) { + release_sock(sk); return -EINVAL; - - if (addr->sax25_family != AF_NETROM) + } + if (addr->sax25_family != AF_NETROM) { + release_sock(sk); return -EINVAL; - + } if (sk->sk_zapped) { /* Must bind first - autobinding in this may or may not work */ sk->sk_zapped = 0; - if ((dev = nr_dev_first()) == NULL) + if ((dev = nr_dev_first()) == NULL) { + release_sock(sk); return -ENETUNREACH; - + } source = (ax25_address *)dev->dev_addr; if ((user = ax25_findbyuid(current->euid)) == NULL) { - if (ax25_uid_policy && !capable(CAP_NET_ADMIN)) + if (ax25_uid_policy && !capable(CAP_NET_ADMIN)) { + dev_put(dev); + release_sock(sk); return -EPERM; + } user = source; } @@ -639,12 +682,15 @@ nr->source_addr = *source; nr->device = dev; + dev_put(dev); nr_insert_socket(sk); /* Finish the bind */ } nr->dest_addr = addr->sax25_call; + release_sock(sk); circuit = nr_find_next_circuit(); + lock_sock(sk); nr->my_index = circuit / 256; nr->my_id = circuit % 256; @@ -662,8 +708,10 @@ nr_start_heartbeat(sk); /* Now the loop */ - if (sk->sk_state != TCP_ESTABLISHED && (flags & O_NONBLOCK)) + if (sk->sk_state != TCP_ESTABLISHED && (flags & O_NONBLOCK)) { + release_sock(sk); return -EINPROGRESS; + } /* * A Connect Ack with Choke or timeout or failed routing will go to @@ -678,8 +726,10 @@ set_current_state(TASK_INTERRUPTIBLE); if (sk->sk_state != TCP_SYN_SENT) break; + release_sock(sk); if (!signal_pending(tsk)) { schedule(); + lock_sock(sk); continue; } return -ERESTARTSYS; @@ -690,10 +740,12 @@ if (sk->sk_state != TCP_ESTABLISHED) { sock->state = SS_UNCONNECTED; + release_sock(sk); return sock_error(sk); /* Always set at this point */ } sock->state = SS_CONNECTED; + release_sock(sk); return 0; } @@ -756,6 +808,7 @@ newsock->sk = newsk; out: + release_sock(sk); return err; } @@ -766,9 +819,12 @@ struct sock *sk = sock->sk; nr_cb *nr = nr_sk(sk); + lock_sock(sk); if (peer != 0) { - if (sk->sk_state != TCP_ESTABLISHED) + if (sk->sk_state != TCP_ESTABLISHED) { + release_sock(sk); return -ENOTCONN; + } sax->fsa_ax25.sax25_family = AF_NETROM; sax->fsa_ax25.sax25_ndigis = 1; sax->fsa_ax25.sax25_call = nr->user_addr; @@ -780,6 +836,7 @@ sax->fsa_ax25.sax25_call = nr->source_addr; *uaddr_len = sizeof(struct sockaddr_ax25); } + release_sock(sk); return 0; } @@ -793,6 +850,7 @@ unsigned short circuit_index, circuit_id; unsigned short peer_circuit_index, peer_circuit_id; unsigned short frametype, flags, window, timeout; + int ret; skb->sk = NULL; /* Initially we don't know who it's for */ @@ -850,7 +908,9 @@ else nr_sk(sk)->bpqext = 0; - return nr_process_rx_frame(sk, skb); + ret = nr_process_rx_frame(sk, skb); + bh_unlock_sock(sk); + return ret; } /* @@ -880,6 +940,8 @@ if (!sk || sk->sk_ack_backlog == sk->sk_max_ack_backlog || (make = nr_make_new(sk)) == NULL) { nr_transmit_refusal(skb, 0); + if (sk) + bh_unlock_sock(sk); return 0; } @@ -897,7 +959,9 @@ nr_make->your_index = circuit_index; nr_make->your_id = circuit_id; + bh_unlock_sock(sk); circuit = nr_find_next_circuit(); + bh_lock_sock(sk); nr_make->my_index = circuit / 256; nr_make->my_id = circuit % 256; @@ -939,6 +1003,7 @@ if (!sock_flag(sk, SOCK_DEAD)) sk->sk_data_ready(sk, skb->len); + bh_unlock_sock(sk); return 1; } @@ -957,28 +1022,42 @@ if (msg->msg_flags & ~(MSG_DONTWAIT|MSG_EOR)) return -EINVAL; - if (sk->sk_zapped) - return -EADDRNOTAVAIL; + lock_sock(sk); + if (sk->sk_zapped) { + err = -EADDRNOTAVAIL; + goto out; + } if (sk->sk_shutdown & SEND_SHUTDOWN) { send_sig(SIGPIPE, current, 0); - return -EPIPE; + err = -EPIPE; + goto out; } - if (nr->device == NULL) - return -ENETUNREACH; + if (nr->device == NULL) { + err = -ENETUNREACH; + goto out; + } if (usax) { - if (msg->msg_namelen < sizeof(sax)) - return -EINVAL; + if (msg->msg_namelen < sizeof(sax)) { + err = -EINVAL; + goto out; + } sax = *usax; - if (ax25cmp(&nr->dest_addr, &sax.sax25_call) != 0) - return -EISCONN; - if (sax.sax25_family != AF_NETROM) - return -EINVAL; + if (ax25cmp(&nr->dest_addr, &sax.sax25_call) != 0) { + err = -EISCONN; + goto out; + } + if (sax.sax25_family != AF_NETROM) { + err = -EINVAL; + goto out; + } } else { - if (sk->sk_state != TCP_ESTABLISHED) - return -ENOTCONN; + if (sk->sk_state != TCP_ESTABLISHED) { + err = -ENOTCONN; + goto out; + } sax.sax25_family = AF_NETROM; sax.sax25_call = nr->dest_addr; } @@ -987,10 +1066,10 @@ /* Build a packet */ SOCK_DEBUG(sk, "NET/ROM: sendto: building packet.\n"); - size = len + AX25_BPQ_HEADER_LEN + AX25_MAX_HEADER_LEN + NR_NETWORK_LEN + NR_TRANSPORT_LEN; + size = len + NR_NETWORK_LEN + NR_TRANSPORT_LEN; if ((skb = sock_alloc_send_skb(sk, size, msg->msg_flags & MSG_DONTWAIT, &err)) == NULL) - return err; + goto out; skb_reserve(skb, size - len); @@ -1025,12 +1104,16 @@ if (sk->sk_state != TCP_ESTABLISHED) { kfree_skb(skb); - return -ENOTCONN; + err = -ENOTCONN; + goto out; } nr_output(sk, skb); /* Shove it onto the queue */ - return len; + err = len; +out: + release_sock(sk); + return err; } static int nr_recvmsg(struct kiocb *iocb, struct socket *sock, @@ -1047,12 +1130,17 @@ * us! We do one quick check first though */ - if (sk->sk_state != TCP_ESTABLISHED) + lock_sock(sk); + if (sk->sk_state != TCP_ESTABLISHED) { + release_sock(sk); return -ENOTCONN; + } /* Now we can treat all alike */ - if ((skb = skb_recv_datagram(sk, flags & ~MSG_DONTWAIT, flags & MSG_DONTWAIT, &er)) == NULL) + if ((skb = skb_recv_datagram(sk, flags & ~MSG_DONTWAIT, flags & MSG_DONTWAIT, &er)) == NULL) { + release_sock(sk); return er; + } skb->h.raw = skb->data; copied = skb->len; @@ -1073,6 +1161,7 @@ skb_free_datagram(sk, skb); + release_sock(sk); return copied; } @@ -1080,13 +1169,16 @@ static int nr_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg) { struct sock *sk = sock->sk; + int ret; + lock_sock(sk); switch (cmd) { case TIOCOUTQ: { long amount; amount = sk->sk_sndbuf - atomic_read(&sk->sk_wmem_alloc); if (amount < 0) amount = 0; + release_sock(sk); return put_user(amount, (int *)arg); } @@ -1096,15 +1188,21 @@ /* These two are safe on a single CPU system as only user tasks fiddle here */ if ((skb = skb_peek(&sk->sk_receive_queue)) != NULL) amount = skb->len; + release_sock(sk); return put_user(amount, (int *)arg); } case SIOCGSTAMP: if (sk != NULL) { - if (!sk->sk_stamp.tv_sec) + if (!sk->sk_stamp.tv_sec) { + release_sock(sk); return -ENOENT; - return copy_to_user((void *)arg, &sk->sk_stamp, sizeof(struct timeval)) ? -EFAULT : 0; + } + ret = copy_to_user((void *)arg, &sk->sk_stamp, sizeof(struct timeval)) ? -EFAULT : 0; + release_sock(sk); + return ret; } + release_sock(sk); return -EINVAL; case SIOCGIFADDR: @@ -1117,17 +1215,21 @@ case SIOCSIFNETMASK: case SIOCGIFMETRIC: case SIOCSIFMETRIC: + release_sock(sk); return -EINVAL; case SIOCADDRT: case SIOCDELRT: case SIOCNRDECOBS: + release_sock(sk); if (!capable(CAP_NET_ADMIN)) return -EPERM; return nr_rt_ioctl(cmd, (void *)arg); default: + release_sock(sk); return dev_ioctl(cmd, (void *)arg); } + release_sock(sk); return 0; } @@ -1147,7 +1249,9 @@ len += sprintf(buffer, "user_addr dest_node src_node dev my your st vs vr va t1 t2 t4 idle n2 wnd Snd-Q Rcv-Q inode\n"); sk_for_each(s, node, &nr_list) { - nr_cb *nr = nr_sk(s); + nr_cb *nr; + bh_lock_sock(s); + nr = nr_sk(s); if ((dev = nr->device) == NULL) devname = "???"; @@ -1190,7 +1294,7 @@ len = 0; begin = pos; } - + bh_unlock_sock(s); if (pos > offset + length) break; } diff -Nru a/net/netrom/nr_in.c b/net/netrom/nr_in.c --- a/net/netrom/nr_in.c Wed Aug 13 12:22:36 2003 +++ b/net/netrom/nr_in.c Wed Aug 13 12:22:36 2003 @@ -74,6 +74,7 @@ static int nr_state1_machine(struct sock *sk, struct sk_buff *skb, int frametype) { + bh_lock_sock(sk); switch (frametype) { case NR_CONNACK: { nr_cb *nr = nr_sk(sk); @@ -102,6 +103,7 @@ default: break; } + bh_unlock_sock(sk); return 0; } @@ -114,6 +116,7 @@ static int nr_state2_machine(struct sock *sk, struct sk_buff *skb, int frametype) { + bh_lock_sock(sk); switch (frametype) { case NR_CONNACK | NR_CHOKE_FLAG: nr_disconnect(sk, ECONNRESET); @@ -129,6 +132,7 @@ default: break; } + bh_unlock_sock(sk); return 0; } @@ -150,6 +154,7 @@ nr = skb->data[18]; ns = skb->data[17]; + bh_lock_sock(sk); switch (frametype) { case NR_CONNREQ: nr_write_internal(sk, NR_CONNACK); @@ -260,6 +265,7 @@ default: break; } + bh_unlock_sock(sk); return queued; } diff -Nru a/net/netrom/nr_timer.c b/net/netrom/nr_timer.c --- a/net/netrom/nr_timer.c Wed Aug 13 12:22:36 2003 +++ b/net/netrom/nr_timer.c Wed Aug 13 12:22:36 2003 @@ -143,7 +143,10 @@ is accepted() it isn't 'dead' so doesn't get removed. */ if (sock_flag(sk, SOCK_DESTROY) || (sk->sk_state == TCP_LISTEN && sock_flag(sk, SOCK_DEAD))) { + sock_hold(sk); nr_destroy_socket(sk); + bh_unlock_sock(sk); + sock_put(sk); return; } break; @@ -227,6 +230,7 @@ case NR_STATE_1: if (nr->n2count == nr->n2) { nr_disconnect(sk, ETIMEDOUT); + bh_unlock_sock(sk); return; } else { nr->n2count++; @@ -237,6 +241,7 @@ case NR_STATE_2: if (nr->n2count == nr->n2) { nr_disconnect(sk, ETIMEDOUT); + bh_unlock_sock(sk); return; } else { nr->n2count++; @@ -247,6 +252,7 @@ case NR_STATE_3: if (nr->n2count == nr->n2) { nr_disconnect(sk, ETIMEDOUT); + bh_unlock_sock(sk); return; } else { nr->n2count++; From shemminger@osdl.org Wed Aug 13 16:06:11 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 16:06:16 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DN6AFl028491 for ; Wed, 13 Aug 2003 16:06:10 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7DMgho20214; Wed, 13 Aug 2003 15:42:43 -0700 Date: Wed, 13 Aug 2003 15:42:34 -0700 From: Stephen Hemminger To: "David S. Miller" , Jeroen Vreeken Cc: netdev@oss.sgi.com, linux-hams@vger.kernel.org Subject: [PATCH] (7/11) netrom - convert route/node tables to hlist Message-Id: <20030813154234.68497928.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4827 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev From: Jeroen Vreeken Use hlist for the routing table information. Note: there is a call to ax25_cb_put commented out, that can be added back when ax25 refcount patches go in. diff -Nru a/include/net/netrom.h b/include/net/netrom.h --- a/include/net/netrom.h Wed Aug 13 13:20:27 2003 +++ b/include/net/netrom.h Wed Aug 13 13:20:27 2003 @@ -7,6 +7,7 @@ #ifndef _NETROM_H #define _NETROM_H #include +#include #define NR_NETWORK_LEN 15 #define NR_TRANSPORT_LEN 5 @@ -77,16 +78,17 @@ #define nr_sk(__sk) ((nr_cb *)(__sk)->sk_protinfo) struct nr_neigh { - struct nr_neigh *next; - ax25_address callsign; - ax25_digi *digipeat; - ax25_cb *ax25; - struct net_device *dev; - unsigned char quality; - unsigned char locked; - unsigned short count; - unsigned int number; - unsigned char failed; + struct hlist_node neigh_node; + ax25_address callsign; + ax25_digi *digipeat; + ax25_cb *ax25; + struct net_device *dev; + unsigned char quality; + unsigned char locked; + unsigned short count; + unsigned int number; + unsigned char failed; + atomic_t refcount; }; struct nr_route { @@ -96,13 +98,73 @@ }; struct nr_node { - struct nr_node *next; - ax25_address callsign; - char mnemonic[7]; - unsigned char which; - unsigned char count; - struct nr_route routes[3]; + struct hlist_node node_node; + ax25_address callsign; + char mnemonic[7]; + unsigned char which; + unsigned char count; + struct nr_route routes[3]; + atomic_t refcount; + spinlock_t node_lock; }; + +/********************************************************************* + * nr_node & nr_neigh lists, refcounting and locking + *********************************************************************/ + +extern struct hlist_head nr_node_list; +extern struct hlist_head nr_neigh_list; + +#define nr_node_hold(__nr_node) \ + atomic_inc(&((__nr_node)->refcount)) + +static __inline__ void nr_node_put(struct nr_node *nr_node) +{ + if (atomic_dec_and_test(&nr_node->refcount)) { + kfree(nr_node); + } +} + +#define nr_neigh_hold(__nr_neigh) \ + atomic_inc(&((__nr_neigh)->refcount)) + +static __inline__ void nr_neigh_put(struct nr_neigh *nr_neigh) +{ + if (atomic_dec_and_test(&nr_neigh->refcount)) { + if (nr_neigh->digipeat != NULL) + kfree(nr_neigh->digipeat); + kfree(nr_neigh); + } +} + +/* nr_node_lock and nr_node_unlock also hold/put the node's refcounter. + */ +static __inline__ void nr_node_lock(struct nr_node *nr_node) +{ + nr_node_hold(nr_node); + spin_lock_bh(&nr_node->node_lock); +} + +static __inline__ void nr_node_unlock(struct nr_node *nr_node) +{ + spin_unlock_bh(&nr_node->node_lock); + nr_node_put(nr_node); +} + +#define nr_neigh_for_each(__nr_neigh, node, list) \ + hlist_for_each_entry(__nr_neigh, node, list, neigh_node) + +#define nr_neigh_for_each_safe(__nr_neigh, node, node2, list) \ + hlist_for_each_entry_safe(__nr_neigh, node, node2, list, neigh_node) + +#define nr_node_for_each(__nr_node, node, list) \ + hlist_for_each_entry(__nr_node, node, list, node_node) + +#define nr_node_for_each_safe(__nr_node, node, node2, list) \ + hlist_for_each_entry_safe(__nr_node, node, node2, list, node_node) + + +/*********************************************************************/ /* af_netrom.c */ extern int sysctl_netrom_default_path_quality; diff -Nru a/net/netrom/nr_route.c b/net/netrom/nr_route.c --- a/net/netrom/nr_route.c Wed Aug 13 13:20:27 2003 +++ b/net/netrom/nr_route.c Wed Aug 13 13:20:27 2003 @@ -39,10 +39,45 @@ static unsigned int nr_neigh_no = 1; -static struct nr_node *nr_node_list; -static spinlock_t nr_node_lock; -static struct nr_neigh *nr_neigh_list; -static spinlock_t nr_neigh_lock; +HLIST_HEAD(nr_node_list); +spinlock_t nr_node_list_lock = SPIN_LOCK_UNLOCKED; +HLIST_HEAD(nr_neigh_list); +spinlock_t nr_neigh_list_lock = SPIN_LOCK_UNLOCKED; + +struct nr_node *nr_node_get(ax25_address *callsign) +{ + struct nr_node *found = NULL; + struct nr_node *nr_node; + struct hlist_node *node; + + spin_lock_bh(&nr_node_list_lock); + nr_node_for_each(nr_node, node, &nr_node_list) + if (ax25cmp(callsign, &nr_node->callsign) == 0) { + nr_node_hold(nr_node); + found = nr_node; + break; + } + spin_unlock_bh(&nr_node_list_lock); + return found; +} + +struct nr_neigh *nr_neigh_get_dev(ax25_address *callsign, struct net_device *dev) +{ + struct nr_neigh *found = NULL; + struct nr_neigh *nr_neigh; + struct hlist_node *node; + + spin_lock_bh(&nr_neigh_list_lock); + nr_neigh_for_each(nr_neigh, node, &nr_neigh_list) + if (ax25cmp(callsign, &nr_neigh->callsign) == 0 && + nr_neigh->dev == dev) { + nr_neigh_hold(nr_neigh); + found = nr_neigh; + break; + } + spin_unlock_bh(&nr_neigh_list_lock); + return found; +} static void nr_remove_neigh(struct nr_neigh *); @@ -57,17 +92,16 @@ struct nr_neigh *nr_neigh; struct nr_route nr_route; int i, found; + struct net_device *odev; - if (nr_dev_get(nr) != NULL) /* Can't add routes to ourself */ + if ((odev=nr_dev_get(nr)) != NULL) { /* Can't add routes to ourself */ + dev_put(odev); return -EINVAL; + } - for (nr_node = nr_node_list; nr_node != NULL; nr_node = nr_node->next) - if (ax25cmp(nr, &nr_node->callsign) == 0) - break; + nr_node = nr_node_get(nr); - for (nr_neigh = nr_neigh_list; nr_neigh != NULL; nr_neigh = nr_neigh->next) - if (ax25cmp(ax25, &nr_neigh->callsign) == 0 && nr_neigh->dev == dev) - break; + nr_neigh = nr_neigh_get_dev(ax25, dev); /* * The L2 link to a neighbour has failed in the past @@ -76,24 +110,36 @@ * routes now (and not wait for a node broadcast). */ if (nr_neigh != NULL && nr_neigh->failed != 0 && quality == 0) { - struct nr_node *node; + struct nr_node *nr_nodet; + struct hlist_node *node; - for (node = nr_node_list; node != NULL; node = node->next) - for (i = 0; i < node->count; i++) - if (node->routes[i].neighbour == nr_neigh) - if (i < node->which) - node->which = i; + spin_lock_bh(&nr_node_list_lock); + nr_node_for_each(nr_nodet, node, &nr_node_list) { + nr_node_lock(nr_nodet); + for (i = 0; i < nr_nodet->count; i++) + if (nr_nodet->routes[i].neighbour == nr_neigh) + if (i < nr_nodet->which) + nr_nodet->which = i; + nr_node_unlock(nr_nodet); + } + spin_unlock_bh(&nr_node_list_lock); } if (nr_neigh != NULL) nr_neigh->failed = 0; - if (quality == 0 && nr_neigh != NULL && nr_node != NULL) + if (quality == 0 && nr_neigh != NULL && nr_node != NULL) { + nr_neigh_put(nr_neigh); + nr_node_put(nr_node); return 0; + } if (nr_neigh == NULL) { - if ((nr_neigh = kmalloc(sizeof(*nr_neigh), GFP_ATOMIC)) == NULL) + if ((nr_neigh = kmalloc(sizeof(*nr_neigh), GFP_ATOMIC)) == NULL) { + if (nr_node) + nr_node_put(nr_node); return -ENOMEM; + } nr_neigh->callsign = *ax25; nr_neigh->digipeat = NULL; @@ -104,48 +150,58 @@ nr_neigh->count = 0; nr_neigh->number = nr_neigh_no++; nr_neigh->failed = 0; + atomic_set(&nr_neigh->refcount, 1); if (ax25_digi != NULL && ax25_digi->ndigi > 0) { if ((nr_neigh->digipeat = kmalloc(sizeof(*ax25_digi), GFP_KERNEL)) == NULL) { kfree(nr_neigh); + if (nr_node) + nr_node_put(nr_node); return -ENOMEM; } memcpy(nr_neigh->digipeat, ax25_digi, sizeof(*ax25_digi)); } - spin_lock_bh(&nr_neigh_lock); - nr_neigh->next = nr_neigh_list; - nr_neigh_list = nr_neigh; - spin_unlock_bh(&nr_neigh_lock); + spin_lock_bh(&nr_neigh_list_lock); + hlist_add_head(&nr_neigh->neigh_node, &nr_neigh_list); + nr_neigh_hold(nr_neigh); + spin_unlock_bh(&nr_neigh_list_lock); } if (quality != 0 && ax25cmp(nr, ax25) == 0 && !nr_neigh->locked) nr_neigh->quality = quality; if (nr_node == NULL) { - if ((nr_node = kmalloc(sizeof(*nr_node), GFP_ATOMIC)) == NULL) + if ((nr_node = kmalloc(sizeof(*nr_node), GFP_ATOMIC)) == NULL) { + if (nr_neigh) + nr_neigh_put(nr_neigh); return -ENOMEM; + } nr_node->callsign = *nr; strcpy(nr_node->mnemonic, mnemonic); nr_node->which = 0; nr_node->count = 1; + atomic_set(&nr_node->refcount, 1); + nr_node->node_lock = SPIN_LOCK_UNLOCKED; nr_node->routes[0].quality = quality; nr_node->routes[0].obs_count = obs_count; nr_node->routes[0].neighbour = nr_neigh; - spin_lock_bh(&nr_node_lock); - nr_node->next = nr_node_list; - nr_node_list = nr_node; - spin_unlock_bh(&nr_node_lock); - + nr_neigh_hold(nr_neigh); nr_neigh->count++; + spin_lock_bh(&nr_node_list_lock); + hlist_add_head(&nr_node->node_node, &nr_node_list); + /* refcount initialized at 1 */ + spin_unlock_bh(&nr_node_list_lock); + return 0; } + nr_node_lock(nr_node); if (quality != 0) strcpy(nr_node->mnemonic, mnemonic); @@ -171,11 +227,13 @@ nr_node->which++; nr_node->count++; + nr_neigh_hold(nr_neigh); nr_neigh->count++; } else { /* It must be better than the worst */ if (quality > nr_node->routes[2].quality) { nr_node->routes[2].neighbour->count--; + nr_neigh_put(nr_node->routes[2].neighbour); if (nr_node->routes[2].neighbour->count == 0 && !nr_node->routes[2].neighbour->locked) nr_remove_neigh(nr_node->routes[2].neighbour); @@ -184,6 +242,7 @@ nr_node->routes[2].obs_count = obs_count; nr_node->routes[2].neighbour = nr_neigh; + nr_neigh_hold(nr_neigh); nr_neigh->count++; } } @@ -244,62 +303,42 @@ } } + nr_neigh_put(nr_neigh); + nr_node_unlock(nr_node); + nr_node_put(nr_node); return 0; } -static void nr_remove_node(struct nr_node *nr_node) +static inline void __nr_remove_node(struct nr_node *nr_node) { - struct nr_node *s; - - spin_lock_bh(&nr_node_lock); - if ((s = nr_node_list) == nr_node) { - nr_node_list = nr_node->next; - spin_unlock_bh(&nr_node_lock); - kfree(nr_node); - return; - } - - while (s != NULL && s->next != NULL) { - if (s->next == nr_node) { - s->next = nr_node->next; - spin_unlock_bh(&nr_node_lock); - kfree(nr_node); - return; - } + hlist_del_init(&nr_node->node_node); + nr_node_put(nr_node); +} - s = s->next; - } +#define nr_remove_node_locked(__node) \ + __nr_remove_node(__node) - spin_unlock_bh(&nr_node_lock); +static void nr_remove_node(struct nr_node *nr_node) +{ + spin_lock_bh(&nr_node_list_lock); + __nr_remove_node(nr_node); + spin_unlock_bh(&nr_node_list_lock); } -static void nr_remove_neigh(struct nr_neigh *nr_neigh) +static inline void __nr_remove_neigh(struct nr_neigh *nr_neigh) { - struct nr_neigh *s; + hlist_del_init(&nr_neigh->neigh_node); + nr_neigh_put(nr_neigh); +} - spin_lock_bh(&nr_neigh_lock); - if ((s = nr_neigh_list) == nr_neigh) { - nr_neigh_list = nr_neigh->next; - spin_unlock_bh(&nr_neigh_lock); - if (nr_neigh->digipeat != NULL) - kfree(nr_neigh->digipeat); - kfree(nr_neigh); - return; - } +#define nr_remove_neigh_locked(__neigh) \ + __nr_remove_neigh(__neigh) - while (s != NULL && s->next != NULL) { - if (s->next == nr_neigh) { - s->next = nr_neigh->next; - spin_unlock_bh(&nr_neigh_lock); - if (nr_neigh->digipeat != NULL) - kfree(nr_neigh->digipeat); - kfree(nr_neigh); - return; - } - - s = s->next; - } - spin_unlock_bh(&nr_neigh_lock); +static void nr_remove_neigh(struct nr_neigh *nr_neigh) +{ + spin_lock_bh(&nr_neigh_list_lock); + __nr_remove_neigh(nr_neigh); + spin_unlock_bh(&nr_neigh_list_lock); } /* @@ -312,26 +351,27 @@ struct nr_neigh *nr_neigh; int i; - for (nr_node = nr_node_list; nr_node != NULL; nr_node = nr_node->next) - if (ax25cmp(callsign, &nr_node->callsign) == 0) - break; + nr_node = nr_node_get(callsign); if (nr_node == NULL) return -EINVAL; - for (nr_neigh = nr_neigh_list; nr_neigh != NULL; nr_neigh = nr_neigh->next) - if (ax25cmp(neighbour, &nr_neigh->callsign) == 0 && nr_neigh->dev == dev) - break; + nr_neigh = nr_neigh_get_dev(neighbour, dev); - if (nr_neigh == NULL) + if (nr_neigh == NULL) { + nr_node_put(nr_node); return -EINVAL; + } + nr_node_lock(nr_node); for (i = 0; i < nr_node->count; i++) { if (nr_node->routes[i].neighbour == nr_neigh) { nr_neigh->count--; + nr_neigh_put(nr_neigh); if (nr_neigh->count == 0 && !nr_neigh->locked) nr_remove_neigh(nr_neigh); + nr_neigh_put(nr_neigh); nr_node->count--; @@ -346,11 +386,16 @@ case 2: break; } + nr_node_put(nr_node); } + nr_node_unlock(nr_node); return 0; } } + nr_neigh_put(nr_neigh); + nr_node_unlock(nr_node); + nr_node_put(nr_node); return -EINVAL; } @@ -362,12 +407,12 @@ { struct nr_neigh *nr_neigh; - for (nr_neigh = nr_neigh_list; nr_neigh != NULL; nr_neigh = nr_neigh->next) { - if (ax25cmp(callsign, &nr_neigh->callsign) == 0 && nr_neigh->dev == dev) { - nr_neigh->quality = quality; - nr_neigh->locked = 1; - return 0; - } + nr_neigh = nr_neigh_get_dev(callsign, dev); + if (nr_neigh) { + nr_neigh->quality = quality; + nr_neigh->locked = 1; + nr_neigh_put(nr_neigh); + return 0; } if ((nr_neigh = kmalloc(sizeof(*nr_neigh), GFP_ATOMIC)) == NULL) @@ -382,6 +427,7 @@ nr_neigh->count = 0; nr_neigh->number = nr_neigh_no++; nr_neigh->failed = 0; + atomic_set(&nr_neigh->refcount, 1); if (ax25_digi != NULL && ax25_digi->ndigi > 0) { if ((nr_neigh->digipeat = kmalloc(sizeof(*ax25_digi), GFP_KERNEL)) == NULL) { @@ -391,10 +437,10 @@ memcpy(nr_neigh->digipeat, ax25_digi, sizeof(*ax25_digi)); } - spin_lock_bh(&nr_neigh_lock); - nr_neigh->next = nr_neigh_list; - nr_neigh_list = nr_neigh; - spin_unlock_bh(&nr_neigh_lock); + spin_lock_bh(&nr_neigh_list_lock); + hlist_add_head(&nr_neigh->neigh_node, &nr_neigh_list); + /* refcount is initialized at 1 */ + spin_unlock_bh(&nr_neigh_list_lock); return 0; } @@ -407,9 +453,7 @@ { struct nr_neigh *nr_neigh; - for (nr_neigh = nr_neigh_list; nr_neigh != NULL; nr_neigh = nr_neigh->next) - if (ax25cmp(callsign, &nr_neigh->callsign) == 0 && nr_neigh->dev == dev) - break; + nr_neigh = nr_neigh_get_dev(callsign, dev); if (nr_neigh == NULL) return -EINVAL; @@ -418,6 +462,7 @@ if (nr_neigh->count == 0) nr_remove_neigh(nr_neigh); + nr_neigh_put(nr_neigh); return 0; } @@ -430,15 +475,13 @@ static int nr_dec_obs(void) { struct nr_neigh *nr_neigh; - struct nr_node *s, *nr_node; + struct nr_node *s; + struct hlist_node *node, *nodet; int i; - nr_node = nr_node_list; - - while (nr_node != NULL) { - s = nr_node; - nr_node = nr_node->next; - + spin_lock_bh(&nr_node_list_lock); + nr_node_for_each_safe(s, node, nodet, &nr_node_list) { + nr_node_lock(s); for (i = 0; i < s->count; i++) { switch (s->routes[i].obs_count) { case 0: /* A locked entry */ @@ -448,6 +491,7 @@ nr_neigh = s->routes[i].neighbour; nr_neigh->count--; + nr_neigh_put(nr_neigh); if (nr_neigh->count == 0 && !nr_neigh->locked) nr_remove_neigh(nr_neigh); @@ -472,8 +516,10 @@ } if (s->count <= 0) - nr_remove_node(s); + nr_remove_node_locked(s); + nr_node_unlock(s); } + spin_unlock_bh(&nr_node_list_lock); return 0; } @@ -483,21 +529,17 @@ */ void nr_rt_device_down(struct net_device *dev) { - struct nr_neigh *s, *nr_neigh = nr_neigh_list; - struct nr_node *t, *nr_node; + struct nr_neigh *s; + struct hlist_node *node, *nodet, *node2, *node2t; + struct nr_node *t; int i; - while (nr_neigh != NULL) { - s = nr_neigh; - nr_neigh = nr_neigh->next; - + spin_lock_bh(&nr_neigh_list_lock); + nr_neigh_for_each_safe(s, node, nodet, &nr_neigh_list) { if (s->dev == dev) { - nr_node = nr_node_list; - - while (nr_node != NULL) { - t = nr_node; - nr_node = nr_node->next; - + spin_lock_bh(&nr_node_list_lock); + nr_node_for_each_safe(t, node2, node2t, &nr_node_list) { + nr_node_lock(t); for (i = 0; i < t->count; i++) { if (t->routes[i].neighbour == s) { t->count--; @@ -514,12 +556,15 @@ } if (t->count <= 0) - nr_remove_node(t); + nr_remove_node_locked(t); + nr_node_unlock(t); } + spin_unlock_bh(&nr_node_list_lock); - nr_remove_neigh(s); + nr_remove_neigh_locked(s); } } + spin_unlock_bh(&nr_neigh_list_lock); } /* @@ -553,6 +598,8 @@ if (first == NULL || strncmp(dev->name, first->name, 3) < 0) first = dev; } + if (first) + dev_hold(first); read_unlock(&dev_base_lock); return first; @@ -603,6 +650,7 @@ { struct nr_route_struct nr_route; struct net_device *dev; + int ret; switch (cmd) { case SIOCADDRT: @@ -610,23 +658,29 @@ return -EFAULT; if ((dev = nr_ax25_dev_get(nr_route.device)) == NULL) return -EINVAL; - if (nr_route.ndigis < 0 || nr_route.ndigis > AX25_MAX_DIGIS) + if (nr_route.ndigis < 0 || nr_route.ndigis > AX25_MAX_DIGIS) { + dev_put(dev); return -EINVAL; + } switch (nr_route.type) { case NETROM_NODE: - return nr_add_node(&nr_route.callsign, + ret = nr_add_node(&nr_route.callsign, nr_route.mnemonic, &nr_route.neighbour, nr_call_to_digi(nr_route.ndigis, nr_route.digipeaters), dev, nr_route.quality, nr_route.obs_count); + break; case NETROM_NEIGH: - return nr_add_neigh(&nr_route.callsign, + ret = nr_add_neigh(&nr_route.callsign, nr_call_to_digi(nr_route.ndigis, nr_route.digipeaters), dev, nr_route.quality); + break; default: - return -EINVAL; + ret = -EINVAL; } + dev_put(dev); + return ret; case SIOCDELRT: if (copy_from_user(&nr_route, arg, sizeof(struct nr_route_struct))) @@ -635,14 +689,18 @@ return -EINVAL; switch (nr_route.type) { case NETROM_NODE: - return nr_del_node(&nr_route.callsign, + ret = nr_del_node(&nr_route.callsign, &nr_route.neighbour, dev); + break; case NETROM_NEIGH: - return nr_del_neigh(&nr_route.callsign, + ret = nr_del_neigh(&nr_route.callsign, dev, nr_route.quality); + break; default: - return -EINVAL; + ret = -EINVAL; } + dev_put(dev); + return ret; case SIOCNRDECOBS: return nr_dec_obs(); @@ -660,22 +718,36 @@ */ void nr_link_failed(ax25_cb *ax25, int reason) { - struct nr_neigh *nr_neigh; - struct nr_node *nr_node; - - for (nr_neigh = nr_neigh_list; nr_neigh != NULL; nr_neigh = nr_neigh->next) - if (nr_neigh->ax25 == ax25) + struct nr_neigh *s, *nr_neigh = NULL; + struct hlist_node *node; + struct nr_node *nr_node = NULL; + + spin_lock_bh(&nr_neigh_list_lock); + nr_neigh_for_each(s, node, &nr_neigh_list) + if (s->ax25 == ax25) { + nr_neigh_hold(s); + nr_neigh = s; break; + } + spin_unlock_bh(&nr_neigh_list_lock); if (nr_neigh == NULL) return; nr_neigh->ax25 = NULL; + // ax25_cb_put(ax25); - if (++nr_neigh->failed < sysctl_netrom_link_fails_count) return; - - for (nr_node = nr_node_list; nr_node != NULL; nr_node = nr_node->next) + if (++nr_neigh->failed < sysctl_netrom_link_fails_count) { + nr_neigh_put(nr_neigh); + return; + } + spin_lock_bh(&nr_node_list_lock); + nr_node_for_each(nr_node, node, &nr_node_list) + nr_node_lock(nr_node); if (nr_node->which < nr_node->count && nr_node->routes[nr_node->which].neighbour == nr_neigh) nr_node->which++; + nr_node_unlock(nr_node); + spin_unlock_bh(&nr_node_list_lock); + nr_neigh_put(nr_neigh); } /* @@ -689,6 +761,9 @@ struct nr_node *nr_node; struct net_device *dev; unsigned char *dptr; + ax25_cb *ax25s; + int ret; + struct sk_buff *skbn; nr_src = (ax25_address *)(skb->data + 0); @@ -700,50 +775,84 @@ if ((dev = nr_dev_get(nr_dest)) != NULL) { /* Its for me */ if (ax25 == NULL) /* Its from me */ - return nr_loopback_queue(skb); + ret = nr_loopback_queue(skb); else - return nr_rx_frame(skb, dev); + ret = nr_rx_frame(skb, dev); + dev_put(dev); + return ret; } if (!sysctl_netrom_routing_control && ax25 != NULL) return 0; /* Its Time-To-Live has expired */ - if (--skb->data[14] == 0) + if (skb->data[14] == 1) { return 0; + } - for (nr_node = nr_node_list; nr_node != NULL; nr_node = nr_node->next) - if (ax25cmp(nr_dest, &nr_node->callsign) == 0) - break; + nr_node = nr_node_get(nr_dest); + if (nr_node == NULL) + return 0; + nr_node_lock(nr_node); - if (nr_node == NULL || nr_node->which >= nr_node->count) + if (nr_node->which >= nr_node->count) { + nr_node_unlock(nr_node); + nr_node_put(nr_node); return 0; + } nr_neigh = nr_node->routes[nr_node->which].neighbour; - if ((dev = nr_dev_first()) == NULL) + if ((dev = nr_dev_first()) == NULL) { + nr_node_unlock(nr_node); + nr_node_put(nr_node); + return 0; + } + + /* We are going to change the netrom headers so we should get our + own skb, we also did not know until now how much header space + we had to reserve... - RXQ */ + if ((skbn=skb_copy_expand(skb, dev->hard_header_len, 0, GFP_ATOMIC)) == NULL) { + nr_node_unlock(nr_node); + nr_node_put(nr_node); + dev_put(dev); return 0; + } + kfree_skb(skb); + skb=skbn; + skb->data[14]--; dptr = skb_push(skb, 1); *dptr = AX25_P_NETROM; - nr_neigh->ax25 = ax25_send_frame(skb, 256, (ax25_address *)dev->dev_addr, &nr_neigh->callsign, nr_neigh->digipeat, nr_neigh->dev); + ax25s = ax25_send_frame(skb, 256, (ax25_address *)dev->dev_addr, &nr_neigh->callsign, nr_neigh->digipeat, nr_neigh->dev); + if (nr_neigh->ax25 && ax25s) { + /* We were already holding this ax25_cb */ + // ax25_cb_put(ax25s); + } + nr_neigh->ax25 = ax25s; - return (nr_neigh->ax25 != NULL); + dev_put(dev); + ret = (nr_neigh->ax25 != NULL); + nr_node_unlock(nr_node); + nr_node_put(nr_node); + return ret; } int nr_nodes_get_info(char *buffer, char **start, off_t offset, int length) { struct nr_node *nr_node; + struct hlist_node *node; int len = 0; off_t pos = 0; off_t begin = 0; int i; - spin_lock_bh(&nr_node_lock); + spin_lock_bh(&nr_node_list_lock); len += sprintf(buffer, "callsign mnemonic w n qual obs neigh qual obs neigh qual obs neigh\n"); - for (nr_node = nr_node_list; nr_node != NULL; nr_node = nr_node->next) { + nr_node_for_each(nr_node, node, &nr_node_list) { + nr_node_lock(nr_node); len += sprintf(buffer + len, "%-9s %-7s %d %d", ax2asc(&nr_node->callsign), (nr_node->mnemonic[0] == '\0') ? "*" : nr_node->mnemonic, @@ -756,6 +865,7 @@ nr_node->routes[i].obs_count, nr_node->routes[i].neighbour->number); } + nr_node_unlock(nr_node); len += sprintf(buffer + len, "\n"); @@ -769,7 +879,7 @@ if (pos > offset + length) break; } - spin_unlock_bh(&nr_node_lock); + spin_unlock_bh(&nr_node_list_lock); *start = buffer + (offset - begin); len -= (offset - begin); @@ -782,15 +892,16 @@ int nr_neigh_get_info(char *buffer, char **start, off_t offset, int length) { struct nr_neigh *nr_neigh; + struct hlist_node *node; int len = 0; off_t pos = 0; off_t begin = 0; int i; - spin_lock_bh(&nr_neigh_lock); + spin_lock_bh(&nr_neigh_list_lock); len += sprintf(buffer, "addr callsign dev qual lock count failed digipeaters\n"); - for (nr_neigh = nr_neigh_list; nr_neigh != NULL; nr_neigh = nr_neigh->next) { + nr_neigh_for_each(nr_neigh, node, &nr_neigh_list) { len += sprintf(buffer + len, "%05d %-9s %-4s %3d %d %3d %3d", nr_neigh->number, ax2asc(&nr_neigh->callsign), @@ -818,7 +929,7 @@ break; } - spin_unlock_bh(&nr_neigh_lock); + spin_unlock_bh(&nr_neigh_list_lock); *start = buffer + (offset - begin); len -= (offset - begin); @@ -833,20 +944,24 @@ */ void __exit nr_rt_free(void) { - struct nr_neigh *s, *nr_neigh = nr_neigh_list; - struct nr_node *t, *nr_node = nr_node_list; - - while (nr_node != NULL) { - t = nr_node; - nr_node = nr_node->next; - - nr_remove_node(t); - } - - while (nr_neigh != NULL) { - s = nr_neigh; - nr_neigh = nr_neigh->next; - - nr_remove_neigh(s); + struct nr_neigh *s = NULL; + struct nr_node *t = NULL; + struct hlist_node *node, *nodet; + + spin_lock_bh(&nr_neigh_list_lock); + spin_lock_bh(&nr_node_list_lock); + nr_node_for_each_safe(t, node, nodet, &nr_node_list) { + nr_node_lock(t); + nr_remove_node_locked(t); + nr_node_unlock(t); + } + nr_neigh_for_each_safe(s, node, nodet, &nr_neigh_list) { + while(s->count) { + s->count--; + nr_neigh_put(s); + } + nr_remove_neigh_locked(s); } + spin_unlock_bh(&nr_node_list_lock); + spin_unlock_bh(&nr_neigh_list_lock); } From jamie@shareable.org Wed Aug 13 16:22:12 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 16:22:18 -0700 (PDT) Received: from mail.jlokier.co.uk (mail.jlokier.co.uk [81.29.64.88]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7DNMAFl028932 for ; Wed, 13 Aug 2003 16:22:12 -0700 Received: from mail.jlokier.co.uk (localhost [127.0.0.1]) by mail.jlokier.co.uk (8.12.8/8.12.8) with ESMTP id h7DNLxOI006741; Thu, 14 Aug 2003 00:21:59 +0100 Received: (from jamie@localhost) by mail.jlokier.co.uk (8.12.8/8.12.8/Submit) id h7DNLxrg006739; Thu, 14 Aug 2003 00:21:59 +0100 Date: Thu, 14 Aug 2003 00:21:58 +0100 From: Jamie Lokier To: ralph+d@istop.com Cc: "netdev@oss.sgi.com" Subject: Re: [RFC] High Performance Packet Classifiction for tc framework Message-ID: <20030813232158.GA6181@mail.jlokier.co.uk> References: <3F2E5CD6.4030500@hipac.org> <1060012260.1103.380.camel@jzny.localdomain> <3F302E04.1090503@hipac.org> <1060286331.1025.73.camel@jzny.localdomain> <3F381B3E.6080807@hipac.org> <20030811224050.59bc36fe.davem@redhat.com> <20030812142913.GB18802@mail.jlokier.co.uk> <20030813191757.GE4405@mail.jlokier.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-archive-position: 4828 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jamie@shareable.org Precedence: bulk X-list: netdev Ralph Doncaster wrote: > So you have to put an entry in the /16 table for every /16 that you have a > more specific route for, right? > Then what if I have 3 different routes; one for 217.109.0.0/16, another > for 217.109.118.0/24 and one for 217.109.118.68/32? Then you would have one entry in the /16 table, matching 217.109.0.0/16, whose BEST value is the first route and whose LARGER points to another table. The second table would have one entry matching 217.109.118.0/24, whose BEST value is the second route, and whose LARGER points to another table. The third table would have one entry matching 217.109.118.68/32, whose BEST value is the third route, and which has no LARGER. That's three hash tables, each containing just one entry. -- Jamie From shemminger@osdl.org Wed Aug 13 17:47:48 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 17:47:55 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7E0llFl030151 for ; Wed, 13 Aug 2003 17:47:48 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7E0l7o14635; Wed, 13 Aug 2003 17:47:10 -0700 Date: Wed, 13 Aug 2003 17:46:58 -0700 From: Stephen Hemminger To: Mike Phillips , "David S. Miller" Cc: linux-tr@linuxtr.net, netdev@oss.sgi.com Subject: [PATCH] ibmtr - get rid of MOD_INC/DEC Message-Id: <20030813174658.2c5125af.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4829 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev With the new module system MOD_INC/MOD_DEC are no longer necessary. Also changed to new module init/exit macros for function setup. The module exit code can sleep, so calling schedule_timeout is better than spinning. Don't have real hardware, so I tested it by short circuiting the probe(). diff -Nru a/drivers/net/tokenring/ibmtr.c b/drivers/net/tokenring/ibmtr.c --- a/drivers/net/tokenring/ibmtr.c Wed Aug 13 17:44:49 2003 +++ b/drivers/net/tokenring/ibmtr.c Wed Aug 13 17:44:49 2003 @@ -876,7 +876,6 @@ if (i==0) break; if (ti->open_status == OPEN && ti->sap_status==OPEN) { netif_start_queue(dev); - MOD_INC_USE_COUNT; DPRINTK("Adapter is up and running\n"); return 0; } @@ -1041,7 +1040,6 @@ netif_stop_queue(dev); DPRINTK("Adapter is closed.\n"); - MOD_DEC_USE_COUNT; return 0; } @@ -1918,7 +1916,7 @@ MODULE_PARM(irq, "1-" __MODULE_STRING(IBMTR_MAX_ADAPTERS) "i"); MODULE_PARM(mem, "1-" __MODULE_STRING(IBMTR_MAX_ADAPTERS) "i"); -int init_module(void) +static int __init ibmtr_init(void) { int i; int count=0; @@ -1948,21 +1946,24 @@ if (count) return 0; printk("ibmtr: register_netdev() returned non-zero.\n"); return -EIO; -} /*init_module */ +} +module_init(ibmtr_init); -void cleanup_module(void) +static void __exit ibmtr_cleanup(void) { - int i,j; + int i; for (i = 0; i < IBMTR_MAX_ADAPTERS; i++){ if (!dev_ibmtr[i]) continue; if (dev_ibmtr[i]->base_addr) { outb(0,dev_ibmtr[i]->base_addr+ADAPTRESET); - for(j=jiffies+TR_RST_TIME; - time_before_eq(jiffies,j);) ; + + schedule_timeout(TR_RST_TIME); /* wait 50ms */ + outb(0,dev_ibmtr[i]->base_addr+ADAPTRESETREL); } + unregister_netdev(dev_ibmtr[i]); free_irq(dev_ibmtr[i]->irq, dev_ibmtr[i]); release_region(dev_ibmtr[i]->base_addr, IBMTR_IO_EXTENT); @@ -1978,4 +1979,5 @@ dev_ibmtr[i] = NULL; } } -#endif /* MODULE */ +module_exit(ibmtr_cleanup); +#endif From minniewkitty@yahoo.com.cn Wed Aug 13 19:31:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 13 Aug 2003 19:31:43 -0700 (PDT) Received: from web15212.mail.bjs.yahoo.com (web15212.mail.bjs.yahoo.com [202.3.77.142]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7E2VWFl031204 for ; Wed, 13 Aug 2003 19:31:34 -0700 Message-ID: <20030814023121.80893.qmail@web15212.mail.bjs.yahoo.com> Received: from [218.90.189.254] by web15212.mail.bjs.yahoo.com via HTTP; Thu, 14 Aug 2003 10:31:21 CST Date: Thu, 14 Aug 2003 10:31:21 +0800 (CST) From: =?gb2312?q?minnie=20wu?= Subject: Re: How to improve small packet performance To: jchapman@katalix.com Cc: netdev@oss.sgi.com In-Reply-To: <1060835023.3f3b0ecfc97b4@webmail.katalix.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-907308067-1060828281=:80393" Content-Transfer-Encoding: 8bit X-archive-position: 4830 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: minniewkitty@yahoo.com.cn Precedence: bulk X-list: netdev --0-907308067-1060828281=:80393 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Here is the experimental setup I used: A traffic generator[Smartbits] is sending from one of its ports to the PC on eth0. Linux routes the packet out eth1 back to the Smartbits. /proc/sys/net/ipv4/ip_forward set to 1. The PC is a PIII 863MHz with 256M of RAM. And the NIC cards do not share the same irq. The unidirectional test: e100-v3.0.0dev12-napi 47k packets/sec eepro100-napi-020619 89k packets/sec minnie jchapman@katalix.com wrote:I downloaded the eepro100 NAPI patch and tried it in my test setup (a 1GHz P-III configured as a 2-port bridge, 2.4.20-8 RH9 kernel). I see e100-napi perform much better than eepro100, which is what I was expecting e100-v3.0.0dev12-napi 93k packets/sec eepro100-napi-020619 49k packets/sec When doing a bidirectional test, the eepro100 driver locks up completely, although it seems to survive with 128 byte packets (where the event rate is less). What's your test setup? How are you generating your test traffic? Do your NIC cards share the same irq? -jc --------------------------------- Do You Yahoo!? ÊîÆÚ´óƬÆë¾ÛÑÅ»¢Í¨ ÍøÂçÉãÏñÍ·+ÑÅ»¢Í¨µ÷ƵÊÕÒô»úµÈÄãÀ´Äà --0-907308067-1060828281=:80393 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 8bit
   Here is the experimental setup I used:
   A traffic generator[Smartbits] is sending from one of its ports to the PC on eth0. Linux routes the packet out eth1 back to the Smartbits. /proc/sys/net/ipv4/ip_forward set to 1.
  The PC is a PIII 863MHz with 256M of RAM. And the NIC cards do not share the same irq.
  The unidirectional test:
   e100-v3.0.0dev12-napi    47k packets/sec
   eepro100-napi-020619     89k packets/sec
  
  minnie
jchapman@katalix.com wrote:
I downloaded the eepro100 NAPI patch and tried it in my test setup (a
1GHz P-III configured as a 2-port bridge, 2.4.20-8 RH9 kernel). I see
e100-napi perform much better than eepro100, which is what I was
expecting

e100-v3.0.0dev12-napi 93k packets/sec
eepro100-napi-020619 49k packets/sec

When doing a bidirectional test, the eepro100 driver locks up
completely, although it seems to survive with 128 byte packets (where
the event rate is less).

What's your test setup? How are you generating your test traffic? Do
your NIC cards share the same irq?

-jc


Do You Yahoo!?
ÊîÆÚ´óƬÆë¾ÛÑÅ»¢Í¨ ÍøÂçÉãÏñÍ·+ÑÅ»¢Í¨µ÷ƵÊÕÒô»úµÈÄãÀ´Äà --0-907308067-1060828281=:80393-- From kyle@imladris.debian.net Thu Aug 14 09:47:39 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Aug 2003 09:47:46 -0700 (PDT) Received: from imladris.debian.net (CPE0030ab0b413b-CM023469906297.cpe.net.cable.rogers.com [24.157.3.237]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7EGlbFl023785 for ; Thu, 14 Aug 2003 09:47:38 -0700 Received: by imladris.debian.net (Postfix, from userid 1000) id 54D68E7DC; Thu, 14 Aug 2003 12:48:19 -0400 (EDT) Date: Thu, 14 Aug 2003 12:48:19 -0400 From: Kyle McMartin To: jmorris@intercode.com.au Cc: netdev@oss.sgi.com, davem@redhat.com Subject: [PATCH] IPsec: add support for Twofish and Serpent Message-ID: <20030814164819.GA18948@imladris.debian.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline User-Agent: Mutt/1.5.4i X-archive-position: 4831 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kyle@debian.org Precedence: bulk X-list: netdev --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This patch adds support for the use of twofish and serpent as ESP algorithms. The ESP index numbers given are in accordance with RFC2407, draft-ietf-ipsec-ciph-aes-cbc-00 (before Rijndael was selected), and KAME which assigns 253 to twofishcbc. Support for using twofish was requested on linux-kernel, and since I noticed serpent was missing too, included that as well. Regards, -- Kyle McMartin 1024D/191FCD8A - 331A 9468 C04D 3A76 5C56 BA68 7EB7 92DF 191F CD8A 2048R/F515317D - 68 A9 0D 28 1B DF 8D 42 0F CC AF 98 A8 D5 A4 04 --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pfkeyv2.diff" --- linux-2.6.0-test3-mm2/include/linux/pfkeyv2.h.old 2003-08-14 10:11:32.000000000 -0400 +++ linux-2.6.0-test3-mm2/include/linux/pfkeyv2.h 2003-08-14 11:30:46.000000000 -0400 @@ -284,7 +284,10 @@ #define SADB_X_EALG_BLOWFISHCBC 7 #define SADB_EALG_NULL 11 #define SADB_X_EALG_AESCBC 12 -#define SADB_EALG_MAX 12 +#define SADB_EALG_MAX 253 /* last EALG */ +/* private allocations should use 249-255 (RFC2407) */ +#define SADB_X_EALG_SERPENTCBC 252 /* draft-ietf-ipsec-ciph-aes-cbc-00 */ +#define SADB_X_EALG_TWOFISHCBC 253 /* draft-ietf-ipsec-ciph-aes-cbc-00 */ /* Compression algorithms */ #define SADB_X_CALG_NONE 0 --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xfrm_algo.diff" --- linux-2.6.0-test3-mm2/net/xfrm/xfrm_algo.c.old 2003-08-14 10:15:04.000000000 -0400 +++ linux-2.6.0-test3-mm2/net/xfrm/xfrm_algo.c 2003-08-14 11:06:20.000000000 -0400 @@ -217,6 +217,40 @@ .sadb_alg_maxbits = 256 } }, +{ + .name = "serpent", + + .uinfo = { + .encr = { + .blockbits = 128, + .defkeybits = 128, + } + }, + + .desc = { + .sadb_alg_id = SADB_X_EALG_SERPENTCBC, + .sadb_alg_ivlen = 8, + .sadb_alg_minbits = 128, + .sadb_alg_maxbits = 256, + } +}, +{ + .name = "twofish", + + .uinfo = { + .encr = { + .blockbits = 128, + .defkeybits = 128, + } + }, + + .desc = { + .sadb_alg_id = SADB_X_EALG_TWOFISHCBC, + .sadb_alg_ivlen = 8, + .sadb_alg_minbits = 128, + .sadb_alg_maxbits = 256 + } +}, }; static struct xfrm_algo_desc calg_list[] = { --LQksG6bCIzRHxTLp-- From acme@conectiva.com.br Thu Aug 14 10:17:19 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Aug 2003 10:17:26 -0700 (PDT) Received: from perninha.conectiva.com.br (perninha.conectiva.com.br [200.250.58.156]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7EHHHFl029441 for ; Thu, 14 Aug 2003 10:17:18 -0700 Received: from brinquendo.conectiva.com.br (dhcp074.conectiva [10.0.4.74]) by perninha.conectiva.com.br (Postfix) with ESMTP id D240047346; Thu, 14 Aug 2003 14:17:13 -0300 (BRT) Received: by brinquendo.conectiva.com.br (Postfix, from userid 500) id 7A0D31966D; Thu, 14 Aug 2003 17:23:13 +0000 (UTC) Date: Thu, 14 Aug 2003 14:23:13 -0300 From: Arnaldo Carvalho de Melo To: Stephen Hemminger Cc: "David S. Miller" , Jeroen Vreeken , netdev@oss.sgi.com, linux-hams@vger.kernel.org Subject: Re: [PATCH] (2/11) netrom - shorten destroy timeout Message-ID: <20030814172312.GC1785@conectiva.com.br> References: <20030813153920.68d52970.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030813153920.68d52970.shemminger@osdl.org> X-Url: http://advogato.org/person/acme Organization: Conectiva S.A. User-Agent: Mutt/1.5.4i X-archive-position: 4832 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Em Wed, Aug 13, 2003 at 03:39:20PM -0700, Stephen Hemminger escreveu: > > From: Jeroen Vreeken > > Expire sockets faster on close > > diff -Nru a/net/netrom/af_netrom.c b/net/netrom/af_netrom.c > --- a/net/netrom/af_netrom.c Wed Aug 13 11:58:31 2003 > +++ b/net/netrom/af_netrom.c Wed Aug 13 11:58:31 2003 > @@ -269,7 +269,7 @@ > atomic_read(&sk->sk_rmem_alloc)) { > /* Defer: outstanding buffers */ > init_timer(&sk->sk_timer); > - sk->sk_timer.expires = jiffies + 10 * HZ; > + sk->sk_timer.expires = jiffies + 2 * HZ; has this to be a magic fixed number? sysctl? From acme@conectiva.com.br Thu Aug 14 10:19:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Aug 2003 10:19:48 -0700 (PDT) Received: from perninha.conectiva.com.br (perninha.conectiva.com.br [200.250.58.156]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7EHJgFl029772 for ; Thu, 14 Aug 2003 10:19:44 -0700 Received: from brinquendo.conectiva.com.br (dhcp074.conectiva [10.0.4.74]) by perninha.conectiva.com.br (Postfix) with ESMTP id 4E75D473A2; Thu, 14 Aug 2003 14:19:40 -0300 (BRT) Received: by brinquendo.conectiva.com.br (Postfix, from userid 500) id DA6971966D; Thu, 14 Aug 2003 17:25:39 +0000 (UTC) Date: Thu, 14 Aug 2003 14:25:39 -0300 From: Arnaldo Carvalho de Melo To: Stephen Hemminger Cc: "David S. Miller" , Jeroen Vreeken , linux-hams@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] (10/11) netrom - convert /proc interface to seq_file Message-ID: <20030814172539.GD1785@conectiva.com.br> References: <20030813154635.376df59b.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030813154635.376df59b.shemminger@osdl.org> X-Url: http://advogato.org/person/acme Organization: Conectiva S.A. User-Agent: Mutt/1.5.4i X-archive-position: 4833 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Em Wed, Aug 13, 2003 at 03:46:35PM -0700, Stephen Hemminger escreveu: > Convert netrom /proc interface to seq_file. > > diff -Nru a/include/net/netrom.h b/include/net/netrom.h > --- a/include/net/netrom.h Wed Aug 13 13:54:19 2003 > +++ b/include/net/netrom.h Wed Aug 13 13:54:19 2003 > + seq_printf(seq, "%-9s ", ax2asc(&nr->user_addr)); > + seq_printf(seq, "%-9s ", ax2asc(&nr->dest_addr)); > + seq_printf(seq, > +"%-9s %-3s %02X/%02X %02X/%02X %2d %3d %3d %3d %3lu/%03lu %2lu/%02lu %3lu/%03lu %3lu/%03lu %2d/%02d %3d %5d %5d %ld\n", why not just one seq_printf call? From acme@conectiva.com.br Thu Aug 14 10:58:20 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Aug 2003 10:58:24 -0700 (PDT) Received: from perninha.conectiva.com.br (perninha.conectiva.com.br [200.250.58.156]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7EHw7Fl001379 for ; Thu, 14 Aug 2003 10:58:09 -0700 Received: from brinquendo.conectiva.com.br (dhcp074.conectiva [10.0.4.74]) by perninha.conectiva.com.br (Postfix) with ESMTP id A8AFF4739A; Thu, 14 Aug 2003 14:16:27 -0300 (BRT) Received: by brinquendo.conectiva.com.br (Postfix, from userid 500) id 683C21966D; Thu, 14 Aug 2003 17:22:24 +0000 (UTC) Date: Thu, 14 Aug 2003 14:22:24 -0300 From: Arnaldo Carvalho de Melo To: Stephen Hemminger Cc: "David S. Miller" , Jeroen Vreeken , netdev@oss.sgi.com, linux-hams@vger.kernel.org Subject: Re: [PATCH] (3/11) netrom - drop buffers in write queue on close Message-ID: <20030814172223.GB1785@conectiva.com.br> References: <20030813153929.3fe71b60.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030813153929.3fe71b60.shemminger@osdl.org> X-Url: http://advogato.org/person/acme Organization: Conectiva S.A. User-Agent: Mutt/1.5.4i X-archive-position: 4834 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Em Wed, Aug 13, 2003 at 03:39:29PM -0700, Stephen Hemminger escreveu: > From: Jeroen Vreeken > > Free buffers in write queue on socket destroy > > diff -Nru a/net/netrom/af_netrom.c b/net/netrom/af_netrom.c > --- a/net/netrom/af_netrom.c Wed Aug 13 11:58:59 2003 > +++ b/net/netrom/af_netrom.c Wed Aug 13 11:58:59 2003 > @@ -264,6 +264,9 @@ > + while ((skb = skb_dequeue(&sk->sk_write_queue)) != NULL) { > + kfree_skb(skb); > + } Hey, use skb_queue_purge - Arnaldo From pp@evil.netppl.fi Thu Aug 14 11:09:12 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Aug 2003 11:09:15 -0700 (PDT) Received: from evil.netppl.fi (evil.netppl.fi [195.242.209.201]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7EI99Fl001808 for ; Thu, 14 Aug 2003 11:09:11 -0700 Received: (from pp@localhost) by evil.netppl.fi (8.11.6/8.11.6) id h7EI8vO05919; Thu, 14 Aug 2003 21:08:57 +0300 Date: Thu, 14 Aug 2003 21:08:57 +0300 From: Pekka Pietikainen To: Kyle McMartin Cc: jmorris@intercode.com.au, netdev@oss.sgi.com, davem@redhat.com Subject: Re: [PATCH] IPsec: add support for Twofish and Serpent Message-ID: <20030814180857.GA4205@netppl.fi> References: <20030814164819.GA18948@imladris.debian.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20030814164819.GA18948@imladris.debian.net> User-Agent: Mutt/1.4i X-archive-position: 4835 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pp@netppl.fi Precedence: bulk X-list: netdev On Thu, Aug 14, 2003 at 12:48:19PM -0400, Kyle McMartin wrote: > > This patch adds support for the use of twofish and serpent as > ESP algorithms. The ESP index numbers given are in accordance > with RFC2407, draft-ietf-ipsec-ciph-aes-cbc-00 (before Rijndael > was selected), and KAME which assigns 253 to twofishcbc. > Support for using twofish was requested on linux-kernel, and > since I noticed serpent was missing too, included that as well. Hi Nothing against twofish or serpent per se, but I have this feeling that supporting every possible crypto algoritm known to man is not necessarily wise (see eg. Practical Cryptography for the rationale). There's absolutely no need to add complexity unless there are some technical arguments for doing so, say compatibility with legacy implementations which justifies bothering with DES/3DES/MD5 although they're inferior to AES and SHA1 in just about every aspect. -- Pekka Pietikainen From shemminger@osdl.org Thu Aug 14 11:30:56 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Aug 2003 11:31:05 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7EIUsFl002203 for ; Thu, 14 Aug 2003 11:30:56 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7EIUZo05083; Thu, 14 Aug 2003 11:30:35 -0700 Date: Thu, 14 Aug 2003 11:30:25 -0700 From: Stephen Hemminger To: Arnaldo Carvalho de Melo Cc: "David S. Miller" , Jeroen Vreeken , linux-hams@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] (10/11) netrom - convert /proc interface to seq_file Message-Id: <20030814113025.2b40be14.shemminger@osdl.org> In-Reply-To: <20030814172539.GD1785@conectiva.com.br> References: <20030813154635.376df59b.shemminger@osdl.org> <20030814172539.GD1785@conectiva.com.br> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4836 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Thu, 14 Aug 2003 14:25:39 -0300 Arnaldo Carvalho de Melo wrote: > Em Wed, Aug 13, 2003 at 03:46:35PM -0700, Stephen Hemminger escreveu: > > Convert netrom /proc interface to seq_file. > > > > diff -Nru a/include/net/netrom.h b/include/net/netrom.h > > --- a/include/net/netrom.h Wed Aug 13 13:54:19 2003 > > +++ b/include/net/netrom.h Wed Aug 13 13:54:19 2003 > > + seq_printf(seq, "%-9s ", ax2asc(&nr->user_addr)); > > + seq_printf(seq, "%-9s ", ax2asc(&nr->dest_addr)); > > + seq_printf(seq, > > +"%-9s %-3s %02X/%02X %02X/%02X %2d %3d %3d %3d %3lu/%03lu %2lu/%02lu %3lu/%03lu %3lu/%03lu %2d/%02d %3d %5d %5d %ld\n", > > why not just one seq_printf call? ax2asc() returns a pointer to static buffer. From mhuth@mvista.com Thu Aug 14 11:54:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Aug 2003 11:54:48 -0700 (PDT) Received: from zipcode.az.mvista.com (rav-az.mvista.com [65.200.49.157]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7EIsdFl005849 for ; Thu, 14 Aug 2003 11:54:40 -0700 Received: from mvista.com ([10.50.1.182]) by zipcode.az.mvista.com (8.9.3/8.9.3) with ESMTP id MAA13752; Thu, 14 Aug 2003 12:09:17 -0700 Message-ID: <3F3BDCF3.5050708@mvista.com> Date: Thu, 14 Aug 2003 12:03:15 -0700 From: Mark Huth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Fix to have sysfs track rename of network devices Content-Type: multipart/mixed; boundary="------------070309000706020401080306" X-archive-position: 4837 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mhuth@mvista.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------070309000706020401080306 Content-Type: multipart/alternative; boundary="------------090404000602010207080904" --------------090404000602010207080904 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Description: When an Ethernet interface is renamed in the kernel via the ioctl SIOCSIFNAME, the sysfs directories /sys/class/net/ethX are not changed to the new name. This patch ensures sysfs is updated to the new name specified by the rename ioctl. Thanks, Mark Huth --------------090404000602010207080904 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
Description:

When an Ethernet interface is renamed in the kernel via the ioctl SIOCSIFNAME, the sysfs directories /sys/class/net/ethX are not changed to the new name.  This patch ensures sysfs is updated to the new name  specified by the rename ioctl.

Thanks,
Mark Huth
--------------090404000602010207080904-- --------------070309000706020401080306 Content-Type: application/octet-stream; name="2.6.0-test3-fixifrename.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="2.6.0-test3-fixifrename.patch" ZGlmZiAtdU5yIGxpbnV4LTIuNi4wLXRlc3QzL25ldC9jb3JlL2Rldi5jIGxpbnV4LTIuNi4w LXRlc3QzLWZpeGlmcmVuYW1lL25ldC9jb3JlL2Rldi5jDQotLS0gbGludXgtMi42LjAtdGVz dDMvbmV0L2NvcmUvZGV2LmMJMjAwMy0wOC0wOCAyMTozNjo1MC4wMDAwMDAwMDAgLTA3MDAN CisrKyBsaW51eC0yLjYuMC10ZXN0My1maXhpZnJlbmFtZS9uZXQvY29yZS9kZXYuYwkyMDAz LTA4LTEzIDE2OjExOjAzLjAwMDAwMDAwMCAtMDcwMA0KQEAgLTIzNDUsOSArMjM0NSwxMSBA QA0KIAkJCQlyZXR1cm4gLUVCVVNZOw0KIAkJCWlmIChfX2Rldl9nZXRfYnlfbmFtZShpZnIt Pmlmcl9uZXduYW1lKSkNCiAJCQkJcmV0dXJuIC1FRVhJU1Q7DQorCQkJbmV0ZGV2X3VucmVn aXN0ZXJfc3lzZnMoZGV2KTsNCiAJCQltZW1jcHkoZGV2LT5uYW1lLCBpZnItPmlmcl9uZXdu YW1lLCBJRk5BTVNJWik7DQogCQkJZGV2LT5uYW1lW0lGTkFNU0laIC0gMV0gPSAwOw0KIAkJ CXN0cmxjcHkoZGV2LT5jbGFzc19kZXYuY2xhc3NfaWQsIGRldi0+bmFtZSwgQlVTX0lEX1NJ WkUpOw0KKwkJCW5ldGRldl9yZWdpc3Rlcl9zeXNmcyhkZXYpOw0KIAkJCW5vdGlmaWVyX2Nh bGxfY2hhaW4oJm5ldGRldl9jaGFpbiwNCiAJCQkJCSAgICBORVRERVZfQ0hBTkdFTkFNRSwg ZGV2KTsNCiAJCQlyZXR1cm4gMDsNCg== --------------070309000706020401080306-- From pekkas@netcore.fi Thu Aug 14 13:25:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Aug 2003 13:25:41 -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 h7EKPTFl007202 for ; Thu, 14 Aug 2003 13:25:30 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7EKPCg29661; Thu, 14 Aug 2003 23:25:12 +0300 Date: Thu, 14 Aug 2003 23:25:11 +0300 (EEST) From: Pekka Savola To: Pekka Pietikainen cc: Kyle McMartin , , , Subject: Re: [PATCH] IPsec: add support for Twofish and Serpent In-Reply-To: <20030814180857.GA4205@netppl.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4838 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 Thu, 14 Aug 2003, Pekka Pietikainen wrote: > On Thu, Aug 14, 2003 at 12:48:19PM -0400, Kyle McMartin wrote: > > > > This patch adds support for the use of twofish and serpent as > > ESP algorithms. The ESP index numbers given are in accordance > > with RFC2407, draft-ietf-ipsec-ciph-aes-cbc-00 (before Rijndael > > was selected), and KAME which assigns 253 to twofishcbc. > > > Support for using twofish was requested on linux-kernel, and > > since I noticed serpent was missing too, included that as well. > Hi > > Nothing against twofish or serpent per se, but I have this feeling that > supporting every possible crypto algoritm known to man > is not necessarily wise (see eg. Practical Cryptography for the rationale). > > There's absolutely no need to add complexity unless there are some technical > arguments for doing so, say compatibility with legacy implementations > which justifies bothering with DES/3DES/MD5 although they're inferior to > AES and SHA1 in just about every aspect. Very much agree. Also, I could be missing something, but I think it takes much more to add an encryption algorithm than what the patch does?!?! -- 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 buytenh@gnu.org Thu Aug 14 14:04:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Aug 2003 14:04:46 -0700 (PDT) Received: from fencepost.gnu.org (fencepost.gnu.org [199.232.76.164]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7EL4WFl007864 for ; Thu, 14 Aug 2003 14:04:33 -0700 Received: from buytenh by fencepost.gnu.org with local (Exim 4.20) id 19nHtU-0006jP-92 for netdev@oss.sgi.com; Thu, 14 Aug 2003 09:11:56 -0400 Date: Thu, 14 Aug 2003 09:11:56 -0400 To: netdev@oss.sgi.com Subject: [PATCH,RFC] explicit connection confirmation Message-ID: <20030814131156.GA21892@gnu.org> References: <20021107093207.GA30666@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021107093207.GA30666@gnu.org> User-Agent: Mutt/1.3.28i From: Lennert Buytenhek X-archive-position: 4839 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@gnu.org Precedence: bulk X-list: netdev Hi, Below is the original email I sent to netdev about nine months ago announcing selective connection acceptance support for TCP sockets. I have forward-ported the 2.4.18 patch to 2.6.0-test2, included below. No functional changes have been made. Could someone have a look at it? cheers, Lennert On Thu, Nov 07, 2002 at 04:32:08AM -0500, buytenh wrote: > (please CC on replies, I am not on this list) > > Hi, > > This patch gives userland the ability to decide whether to react > with an incoming TCP SYN with a SYN-ACK or a RST. It was hacked > up after Linux Kongress 2001 and has been sitting on my patch > pile since april this year or something. > > The basic idea is this: > - Put the listening TCP socket in TCP_CONFIRM_CONNECT mode. > - Sockets returned from accept() on this socket after this will be > sockets in the SYN_RECV state instead of the ESTABLISHED state > (unless syncookies had to be used). By writing to the socket, > you cause a SYN-ACK to be sent, and by immediately closing the > socket you cause a RST to be sent. > > There are two issues left, AFAICS: > - SYN_RECV sockets currently don't time out for some reason > - it deadlocks instantly on SMP > > It's against 2.4.18. Could someone have a look at it please? I > unfortunately haven't had any time at all lately, so I would be > really happy if someone else could take this over. (Well, I can > dream, can't I?) > > > cheers, > Lennert > --- linux-2.6.0-test2/include/linux/tcp.h.orig 2003-08-14 14:19:20.886285797 +0200 +++ linux-2.6.0-test2/include/linux/tcp.h 2003-08-14 13:44:42.000000000 +0200 @@ -127,6 +127,7 @@ #define TCP_WINDOW_CLAMP 10 /* Bound advertised window */ #define TCP_INFO 11 /* Information about this connection. */ #define TCP_QUICKACK 12 /* Block/reenable quick acks */ +#define TCP_CONFIRM_CONNECT 13 /* Let user control connection acceptance */ #define TCPI_OPT_TIMESTAMPS 1 #define TCPI_OPT_SACK 2 @@ -257,6 +258,7 @@ __u8 reordering; /* Packet reordering metric. */ __u8 queue_shrunk; /* Write queue has been shrunk recently.*/ __u8 defer_accept; /* User waits for some data after accept() */ + __u8 confirm_connect;/* User wants control over conn. acceptance */ /* RTT measurement */ __u8 backoff; /* backoff */ @@ -364,6 +366,11 @@ struct open_request *accept_queue; struct open_request *accept_queue_tail; + /* Our corresponding open_request if this socket is unconfirmed + * (i.e. if we haven't sent SYN-ACK or RST yet) + */ + struct open_request *unconfirmed_openreq; + int write_pending; /* A write to socket waits to start. */ unsigned int keepalive_time; /* time before keep alive takes place */ --- linux-2.6.0-test2/include/net/tcp.h.orig 2003-08-14 14:19:20.888285455 +0200 +++ linux-2.6.0-test2/include/net/tcp.h 2003-08-14 13:42:42.000000000 +0200 @@ -591,7 +591,8 @@ sack_ok : 1, wscale_ok : 1, ecn_ok : 1, - acked : 1; + acked : 1, + unconfirmed : 1; /* The following two fields can be easily recomputed I think -AK */ __u32 window_clamp; /* window clamp at creation time */ __u32 rcv_wnd; /* rcv_wnd offered first time */ @@ -619,6 +620,17 @@ tcp_openreq_fastfree(req); } +static inline int tcp_is_unconfirmed(struct tcp_opt *tp) +{ + struct open_request *req; + + req = tp->unconfirmed_openreq; + if (req != NULL && req->unconfirmed) + return 1; + + return 0; +} + #if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) #define TCP_INET_FAMILY(fam) ((fam) == AF_INET) #else @@ -1762,6 +1774,7 @@ req->acked = 0; req->ecn_ok = 0; req->rmt_port = skb->h.th->source; + req->unconfirmed = 0; } #define TCP_MEM_QUANTUM ((int)PAGE_SIZE) --- linux-2.6.0-test2/net/ipv4/af_inet.c.orig 2003-08-14 14:19:20.890285113 +0200 +++ linux-2.6.0-test2/net/ipv4/af_inet.c 2003-08-14 13:47:14.000000000 +0200 @@ -685,8 +685,8 @@ lock_sock(sk2); - BUG_TRAP((1 << sk2->sk_state) & - (TCPF_ESTABLISHED | TCPF_CLOSE_WAIT | TCPF_CLOSE)); + BUG_TRAP((1 << sk2->sk_state) & (TCPF_SYN_RECV | TCPF_ESTABLISHED | + TCPF_CLOSE_WAIT | TCPF_CLOSE)); sock_graft(sk2, newsock); --- linux-2.6.0-test2/net/ipv4/tcp.c.orig 2003-08-14 14:19:20.891284941 +0200 +++ linux-2.6.0-test2/net/ipv4/tcp.c 2003-08-14 14:16:08.697201584 +0200 @@ -206,6 +206,7 @@ * lingertime == 0 (RFC 793 ABORT Call) * Hirokazu Takahashi : Use copy_from_user() instead of * csum_and_copy_from_user() if possible. + * Lennert Buytenhek : Explicit connection confirmation * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License @@ -374,6 +375,15 @@ return tcp_sk(sk)->accept_queue ? (POLLIN | POLLRDNORM) : 0; } +static void tcp_confirm(struct sock *sk) +{ + struct tcp_opt *tp = tcp_sk(sk); + struct open_request *req = tp->unconfirmed_openreq; + + req->unconfirmed = 0; + req->class->rtx_syn_ack(sk, req, NULL); +} + /* * Wait for a TCP event. * @@ -662,6 +672,9 @@ struct task_struct *tsk = current; DEFINE_WAIT(wait); + if (tcp_is_unconfirmed(tp)) + tcp_confirm(sk); + while ((1 << sk->sk_state) & ~(TCPF_ESTABLISHED | TCPF_CLOSE_WAIT)) { if (sk->sk_err) return sock_error(sk); @@ -1939,7 +1952,7 @@ void tcp_close(struct sock *sk, long timeout) { struct sk_buff *skb; - int data_was_unread = 0; + int should_send_rst = 0; lock_sock(sk); sk->sk_shutdown = SHUTDOWN_MASK; @@ -1960,12 +1973,19 @@ while ((skb = __skb_dequeue(&sk->sk_receive_queue)) != NULL) { u32 len = TCP_SKB_CB(skb)->end_seq - TCP_SKB_CB(skb)->seq - skb->h.th->fin; - data_was_unread += len; + should_send_rst += len; __kfree_skb(skb); } tcp_mem_reclaim(sk); + if (tcp_sk(sk)->unconfirmed_openreq != NULL) { + if (tcp_is_unconfirmed(tcp_sk(sk))) + should_send_rst = 1; + tcp_openreq_free(tcp_sk(sk)->unconfirmed_openreq); + tcp_sk(sk)->unconfirmed_openreq = NULL; + } + /* As outlined in draft-ietf-tcpimpl-prob-03.txt, section * 3.10, we send a RST here because data was lost. To * witness the awful effects of the old behavior of always @@ -1975,7 +1995,7 @@ * the FTP client, wheee... Note: timeout is always zero * in such a case. */ - if (data_was_unread) { + if (should_send_rst) { /* Unread data was tossed, zap the connection. */ NET_INC_STATS_USER(TCPAbortOnClose); tcp_set_state(sk, TCP_CLOSE); @@ -2145,6 +2165,11 @@ if (!(sk->sk_userlocks & SOCK_BINDADDR_LOCK)) inet_reset_saddr(sk); + if (tp->unconfirmed_openreq) { + tcp_openreq_free(tp->unconfirmed_openreq); + tp->unconfirmed_openreq = NULL; + } + sk->sk_shutdown = 0; sock_reset_flag(sk, SOCK_DONE); tp->srtt = 0; @@ -2258,8 +2283,10 @@ newsk = req->sk; tcp_acceptq_removed(sk); - tcp_openreq_fastfree(req); - BUG_TRAP(newsk->sk_state != TCP_SYN_RECV); + if (tcp_sk(newsk)->unconfirmed_openreq == NULL) + tcp_openreq_fastfree(req); + BUG_TRAP(tcp_sk(newsk)->unconfirmed_openreq || + newsk->sk_state != TCP_SYN_RECV); release_sock(sk); return newsk; @@ -2428,6 +2455,10 @@ } break; + case TCP_CONFIRM_CONNECT: + tp->confirm_connect = !!val; + break; + default: err = -ENOPROTOOPT; break; @@ -2553,6 +2584,9 @@ case TCP_QUICKACK: val = !tp->ack.pingpong; break; + case TCP_CONFIRM_CONNECT: + val = tp->confirm_connect || tcp_is_unconfirmed(tp); + break; default: return -ENOPROTOOPT; }; --- linux-2.6.0-test2/net/ipv4/tcp_input.c.orig 2003-08-14 14:19:20.894284428 +0200 +++ linux-2.6.0-test2/net/ipv4/tcp_input.c 2003-08-14 13:42:42.000000000 +0200 @@ -3938,6 +3938,11 @@ switch(sk->sk_state) { case TCP_SYN_RECV: if (acceptable) { + if (tp->unconfirmed_openreq != NULL) { + tcp_openreq_free(tp->unconfirmed_openreq); + tp->unconfirmed_openreq = NULL; + } + tp->copied_seq = tp->rcv_nxt; mb(); tcp_set_state(sk, TCP_ESTABLISHED); --- linux-2.6.0-test2/net/ipv4/tcp_ipv4.c.orig 2003-08-14 14:19:20.895284256 +0200 +++ linux-2.6.0-test2/net/ipv4/tcp_ipv4.c 2003-08-14 14:34:31.383363445 +0200 @@ -1403,12 +1403,14 @@ int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb) { + struct tcp_opt *master_tp = tcp_sk(sk); struct tcp_opt tp; struct open_request *req; __u32 saddr = skb->nh.iph->saddr; __u32 daddr = skb->nh.iph->daddr; __u32 isn = TCP_SKB_CB(skb)->when; struct dst_entry *dst = NULL; + int dont_confirm = 0; #ifdef CONFIG_SYN_COOKIES int want_cookie = 0; #else @@ -1445,6 +1447,9 @@ if (!req) goto drop; + if (!want_cookie && master_tp->confirm_connect) + dont_confirm = 1; + tcp_clear_options(&tp); tp.mss_clamp = 536; tp.user_mss = tcp_sk(sk)->user_mss; @@ -1533,11 +1538,31 @@ } req->snt_isn = isn; - if (tcp_v4_send_synack(sk, req, dst)) + if (!dont_confirm && tcp_v4_send_synack(sk, req, dst)) goto drop_and_free; if (want_cookie) { tcp_openreq_free(req); + } else if (dont_confirm) { + struct sock *child; + __u8 rcv_wscale; + + req->window_clamp = dst ? dst_metric(dst, RTAX_WINDOW) : 0; + tcp_select_initial_window(tcp_full_space(sk), req->mss, + &req->rcv_wnd, &req->window_clamp, + 0, &rcv_wscale); + req->rcv_wscale = rcv_wscale; + + child = tcp_v4_syn_recv_sock(sk, skb, req, NULL); + if (child != NULL) { + req->unconfirmed = 1; + tcp_sk(child)->unconfirmed_openreq = req; + tcp_acceptq_queue(sk, req, child); + sk->sk_data_ready(sk, 0); + sock_put(child); + } else { + tcp_openreq_free(req); + } } else { tcp_v4_synq_add(sk, req); } --- linux-2.6.0-test2/net/ipv4/tcp_minisocks.c.orig 2003-08-14 14:19:20.897283914 +0200 +++ linux-2.6.0-test2/net/ipv4/tcp_minisocks.c 2003-08-14 13:42:42.000000000 +0200 @@ -732,6 +732,7 @@ tcp_init_wl(newtp, req->snt_isn, req->rcv_isn); newtp->retransmits = 0; + newtp->confirm_connect = 0; newtp->backoff = 0; newtp->srtt = 0; newtp->mdev = TCP_TIMEOUT_INIT; @@ -884,7 +885,8 @@ * Enforce "SYN-ACK" according to figure 8, figure 6 * of RFC793, fixed by RFC1122. */ - req->class->rtx_syn_ack(sk, req, NULL); + if (!req->unconfirmed) + req->class->rtx_syn_ack(sk, req, NULL); return NULL; } @@ -955,7 +957,7 @@ if (paws_reject || !tcp_in_window(TCP_SKB_CB(skb)->seq, TCP_SKB_CB(skb)->end_seq, req->rcv_isn+1, req->rcv_isn+1+req->rcv_wnd)) { /* Out of window: send ACK and drop. */ - if (!(flg & TCP_FLAG_RST)) + if (!req->unconfirmed && !(flg & TCP_FLAG_RST)) req->class->send_ack(skb, req); if (paws_reject) NET_INC_STATS_BH(PAWSEstabRejected); @@ -991,6 +993,12 @@ return NULL; } + /* @@@ If we are in SYN_RECV and haven't confirmed/rejected + * the connection yet, this ACK is acking a never-sent packet. + */ + if (tcp_is_unconfirmed(tp)) + return NULL; + /* OK, ACK is valid, create big socket and * feed this segment to it. It will repeat all * the tests. THIS SEGMENT MUST MOVE SOCKET TO --- linux-2.6.0-test2/net/ipv4/tcp_timer.c.orig 2003-08-14 14:19:20.899283572 +0200 +++ linux-2.6.0-test2/net/ipv4/tcp_timer.c 2003-08-14 13:42:42.000000000 +0200 @@ -519,7 +519,8 @@ if (time_after_eq(now, req->expires)) { if ((req->retrans < thresh || (req->acked && req->retrans < max_retries)) - && !req->class->rtx_syn_ack(sk, req, NULL)) { + && (req->unconfirmed || + !req->class->rtx_syn_ack(sk, req, NULL))) { unsigned long timeo; if (req->retrans++ == 0) From davem@redhat.com Thu Aug 14 19:19:19 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Aug 2003 19:19: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 h7F2JIFl013421 for ; Thu, 14 Aug 2003 19:19:19 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id TAA22025; Thu, 14 Aug 2003 19:12:59 -0700 Date: Thu, 14 Aug 2003 19:12:59 -0700 From: "David S. Miller" To: Pekka Savola Cc: pp@netppl.fi, kyle@debian.org, jmorris@intercode.com.au, netdev@oss.sgi.com Subject: Re: [PATCH] IPsec: add support for Twofish and Serpent Message-Id: <20030814191259.435945cf.davem@redhat.com> In-Reply-To: References: <20030814180857.GA4205@netppl.fi> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4840 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Thu, 14 Aug 2003 23:25:11 +0300 (EEST) Pekka Savola wrote: > Very much agree. I totally disagree, choice is everything. That's why we allow NULL crypto algorithms. Not doing so turns this into a political thing, which I decidedly do not want our IPSEC implementation to be all about. And therefore I will add the patch. > Also, I could be missing something, but I think it takes much more to add > an encryption algorithm than what the patch does?!?! If you use the netlink based IPSEC implementation, any crypto algorithm is supported fully the moment it is added to crypto/. When using pfkeyv2 sockets, yes you have to assign a number and then the APP has to be aware of it. This just shows how bogus it is to use fixed numbers instead of strings to select crypto algorithms. From davem@redhat.com Thu Aug 14 21:04:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Aug 2003 21:04:36 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7F44TFl015661 for ; Thu, 14 Aug 2003 21:04:29 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id UAA22237; Thu, 14 Aug 2003 20:57:47 -0700 Date: Thu, 14 Aug 2003 20:57:47 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: mikep@linuxtr.net, linux-tr@linuxtr.net, netdev@oss.sgi.com Subject: Re: [PATCH] ibmtr - get rid of MOD_INC/DEC Message-Id: <20030814205747.5fcd83d0.davem@redhat.com> In-Reply-To: <20030813174658.2c5125af.shemminger@osdl.org> References: <20030813174658.2c5125af.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4841 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 13 Aug 2003 17:46:58 -0700 Stephen Hemminger wrote: > With the new module system MOD_INC/MOD_DEC are no longer necessary. > Also changed to new module init/exit macros for function setup. > > The module exit code can sleep, so calling schedule_timeout is better > than spinning. Can't we lose the MODULE ifdefs too? From davem@redhat.com Thu Aug 14 21:20:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Aug 2003 21:20:33 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7F4KQFl016140 for ; Thu, 14 Aug 2003 21:20:27 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id VAA22464; Thu, 14 Aug 2003 21:13:47 -0700 Date: Thu, 14 Aug 2003 21:13:47 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: pe1rxq@amsat.org, netdev@oss.sgi.com, linux-hams@vger.kernel.org, ralf@linux-mips.org Subject: Re: [PATCH] (0/11) Netrom patches Message-Id: <20030814211347.0259a2fc.davem@redhat.com> In-Reply-To: <20030813153526.2e74e008.shemminger@osdl.org> References: <20030812194653.A28977@jeroen.pe1rxq.ampr.org> <20030812135655.7334887b.shemminger@osdl.org> <20030812230951.E28977@jeroen.pe1rxq.ampr.org> <20030812153901.6e700dcb.shemminger@osdl.org> <20030813010301.K28977@jeroen.pe1rxq.ampr.org> <20030812172151.7de0c950.shemminger@osdl.org> <20030813031159.6c6c9629.davem@redhat.com> <20030813173446.A2604@jeroen.pe1rxq.ampr.org> <20030813084252.7b667fb8.davem@redhat.com> <20030813153526.2e74e008.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4842 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 13 Aug 2003 15:35:26 -0700 Stephen Hemminger wrote: > The following set of patches breaks out Jeroen's work (1-7) and adds > several updates from me. I've applied all of these NETROM patches, thanks. From davem@redhat.com Thu Aug 14 21:32:57 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Aug 2003 21:33: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 h7F4WuFl016513 for ; Thu, 14 Aug 2003 21:32:57 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id VAA22523; Thu, 14 Aug 2003 21:22:56 -0700 Date: Thu, 14 Aug 2003 21:22:55 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: jpr@f6fbb.org, jgarzik@pobox.com, linux-hams@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] (2/2) Convert yam driver to seq_file Message-Id: <20030814212255.22f27fb2.davem@redhat.com> In-Reply-To: <20030813093926.7b267dd6.shemminger@osdl.org> References: <20030813093926.7b267dd6.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4843 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 13 Aug 2003 09:39:26 -0700 Stephen Hemminger wrote: > Convert the yam driver to use the new seq_file interface to /proc. > This resolves potential issues with module owner and buffer sizes > by using the common library. I've applied both of your YAM driver patches, thanks Stephen. From davem@redhat.com Thu Aug 14 22:40:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 14 Aug 2003 22:40: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 h7F5eOFl017279 for ; Thu, 14 Aug 2003 22:40:25 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id WAA22795; Thu, 14 Aug 2003 22:34:09 -0700 Date: Thu, 14 Aug 2003 22:34:09 -0700 From: "David S. Miller" To: Mark Huth Cc: netdev@oss.sgi.com Subject: Re: Fix to have sysfs track rename of network devices Message-Id: <20030814223409.10c157e5.davem@redhat.com> In-Reply-To: <3F3BDCF3.5050708@mvista.com> References: <3F3BDCF3.5050708@mvista.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4844 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 Please don't use HTML encoded emails on this list. It makes you look like a bozo. :-) From da-x@gmx.net Fri Aug 15 04:15:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Aug 2003 04:15:35 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FBFQFl026422 for ; Fri, 15 Aug 2003 04:15:26 -0700 Received: (qmail 3936 invoked by uid 65534); 15 Aug 2003 11:15:19 -0000 Received: from DSL212-235-122-158.bb.netvision.net.il (HELO callisto.yi.org) (212.235.122.158) by mail.gmx.net (mp013) with SMTP; 15 Aug 2003 13:15:19 +0200 Date: Fri, 15 Aug 2003 14:15:14 +0300 From: Dan Aloni To: Linux Net-Dev Cc: "David S. Miller" , Mark Huth Subject: [PATCH] network device renaming sysfs fix Message-ID: <20030815111514.GA5228@callisto.yi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-archive-position: 4845 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: da-x@gmx.net Precedence: bulk X-list: netdev (repost, now will hopefully reach the mailing list) I believe this is a better approach for fixing the sysfs renaming discrepancy. Later I'll also look into fixing the same issue with sysctl. --- linux/net/core/dev.c 2003-08-15 12:47:50.000000000 +0300 +++ linux/net/core/dev.c 2003-08-15 12:47:59.000000000 +0300 @@ -2347,10 +2347,14 @@ return -EEXIST; memcpy(dev->name, ifr->ifr_newname, IFNAMSIZ); dev->name[IFNAMSIZ - 1] = 0; - strlcpy(dev->class_dev.class_id, dev->name, BUS_ID_SIZE); + + err = class_device_rename(&dev->class_dev, dev->name); + if (err) + printk(KERN_DEBUG "SIOCSIFNAME: error renaming class_device (%d)\n", err); + notifier_call_chain(&netdev_chain, NETDEV_CHANGENAME, dev); - return 0; + return err; /* * Unknown or private ioctl -- Dan Aloni da-x@gmx.net From shmulik.hen@intel.com Fri Aug 15 04:36:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Aug 2003 04:36:47 -0700 (PDT) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FBaZFl026823 for ; Fri, 15 Aug 2003 04:36:36 -0700 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h7FBVDQ09700 for ; Fri, 15 Aug 2003 11:31:13 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h7FBdYM12148 for ; Fri, 15 Aug 2003 11:39:35 GMT Received: from hasmsx331.ger.corp.intel.com ([143.185.63.144]) by hasmsxvs01.iil.intel.com (NAVGW 2.5.2.11) with SMTP id M2003081514434221458 ; Fri, 15 Aug 2003 14:43:42 +0300 Received: from hasmsx403.ger.corp.intel.com ([143.185.63.109]) by hasmsx331.ger.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 15 Aug 2003 14:36:27 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [PATCH] network device renaming sysfs fix Date: Fri, 15 Aug 2003 14:36:27 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] network device renaming sysfs fix Thread-Index: AcNjHsZpLGByVkWkRR2NxHCnJ0TLDgAAixbQ From: "Hen, Shmulik" To: "Dan Aloni" , "Linux Net-Dev" Cc: "David S. Miller" , "Mark Huth" X-OriginalArrivalTime: 15 Aug 2003 11:36:27.0853 (UTC) FILETIME=[770717D0:01C36321] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7FBaZFl026823 X-archive-position: 4846 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev > -----Original Message----- > From: Dan Aloni [mailto:da-x@gmx.net] > Sent: Friday, August 15, 2003 2:15 PM > To: Linux Net-Dev > Cc: David S. Miller; Mark Huth > Subject: [PATCH] network device renaming sysfs fix > > > (repost, now will hopefully reach the mailing list) > > I believe this is a better approach for fixing the sysfs renaming > discrepancy. Later I'll also look into fixing the same issue > with sysctl. > > > -- > Dan Aloni > da-x@gmx.net > > In general, it a similar thing applicable for proc fs too ? We just had to fix something like that in bonding, and it sounds odd each driver should handle this on it's own. -- | Shmulik Hen Advanced Network Services | | Israel Design Center, Jerusalem | | LAN Access Division, Platform Networking | | Intel Communications Group, Intel corp. | From da-x@gmx.net Fri Aug 15 04:45:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Aug 2003 04:45:27 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FBjGFl027197 for ; Fri, 15 Aug 2003 04:45:16 -0700 Received: (qmail 5269 invoked by uid 65534); 15 Aug 2003 11:45:09 -0000 Received: from DSL212-235-122-158.bb.netvision.net.il (HELO callisto.yi.org) (212.235.122.158) by mail.gmx.net (mp023) with SMTP; 15 Aug 2003 13:45:09 +0200 Date: Fri, 15 Aug 2003 14:45:07 +0300 From: Dan Aloni To: "Hen, Shmulik" Cc: Linux Net-Dev , "David S. Miller" , Mark Huth Subject: Re: [PATCH] network device renaming sysfs fix Message-ID: <20030815114507.GA5929@callisto.yi.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-archive-position: 4847 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: da-x@gmx.net Precedence: bulk X-list: netdev On Fri, Aug 15, 2003 at 02:36:27PM +0300, Hen, Shmulik wrote: > > -----Original Message----- > > From: Dan Aloni [mailto:da-x@gmx.net] > > Sent: Friday, August 15, 2003 2:15 PM > > To: Linux Net-Dev > > Cc: David S. Miller; Mark Huth > > Subject: [PATCH] network device renaming sysfs fix > > > > > > (repost, now will hopefully reach the mailing list) > > > > I believe this is a better approach for fixing the sysfs renaming > > discrepancy. Later I'll also look into fixing the same issue > > with sysctl. > > > > > > -- > > Dan Aloni > > da-x@gmx.net > > > > > > In general, it a similar thing applicable for proc fs too ? > We just had to fix something like that in bonding, and > it sounds odd each driver should handle this on it's own. It is more complicated. procfs's interface to sysctl is optional - thus sysctl's interfaces hide procfs from you. Fixing this require changes in sysctl itself, and most probably also in the networking code, because network devices' sysctls are not exposed in the net/dev/core.c level. -- Dan Aloni da-x@gmx.net From jamie@shareable.org Fri Aug 15 07:29:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Aug 2003 07:29:13 -0700 (PDT) Received: from mail.jlokier.co.uk (mail.jlokier.co.uk [81.29.64.88]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FET1Fl029986 for ; Fri, 15 Aug 2003 07:29:02 -0700 Received: from mail.jlokier.co.uk (localhost [127.0.0.1]) by mail.jlokier.co.uk (8.12.8/8.12.8) with ESMTP id h7FESEOI016696; Fri, 15 Aug 2003 15:28:14 +0100 Received: (from jamie@localhost) by mail.jlokier.co.uk (8.12.8/8.12.8/Submit) id h7FESDwK016694; Fri, 15 Aug 2003 15:28:13 +0100 Date: Fri, 15 Aug 2003 15:28:13 +0100 From: Jamie Lokier To: Michael Bellion and Thomas Heinz Cc: "David S. Miller" , hadi@cyberus.ca, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [RFC] High Performance Packet Classifiction for tc framework Message-ID: <20030815142813.GB16560@mail.jlokier.co.uk> References: <3F16A0E5.1080007@hipac.org> <1059934468.1103.41.camel@jzny.localdomain> <3F2E5CD6.4030500@hipac.org> <1060012260.1103.380.camel@jzny.localdomain> <3F302E04.1090503@hipac.org> <1060286331.1025.73.camel@jzny.localdomain> <3F381B3E.6080807@hipac.org> <20030811224050.59bc36fe.davem@redhat.com> <20030812142913.GB18802@mail.jlokier.co.uk> <3F390A23.3050409@hipac.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F390A23.3050409@hipac.org> User-Agent: Mutt/1.4.1i X-archive-position: 4848 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jamie@shareable.org Precedence: bulk X-list: netdev Michael Bellion and Thomas Heinz wrote: > >This generalises to multiple dimensions e.g. for doing multiple > >prefixes on source+target + different combinations of other bits such > >as protocol, TOS etc. - i.e. arbitrary bit-subset classifiers. The > >basic principle and the algorithm are the same. > > Hm, how do you want to solve the d-dimensional PCP by > doing binary search for each dimension? Remember that > PCP is not related to longest prefix matching. Instead > priorities are used. I don't know what you mean by "PCP", so can't answer the question. > Maybe you should describe in little more detail what you mean > by "This generalises to multiple dimensions ...". I mean that the lookup algorithm works for multi-dimensional searches. Creating the search tree can be a little more involved, and I am not sure how much (if any) node duplication is needed when some kinds of rule priorities are used. It may help to say that you don't have to do binary search for each dimension separately, although that is a possible strategy for prefix matching. You can build a tree where each node represents a point (a,b,c...) in prefix-length space, and whose children are other points in that space, if you choose to see the general problem as matching multiple prefixes. At one extreme, a general bit matcher (i.e. no non-power-of-2 numerical ranges) can be treated as a multi-dimensional prefix match where each prefix is length 0 or 1. You see that, if the input rule set is _equivalent_ to a longest-prefix single-dimensional rule set, the optimal multi-dimensional search tree is trivally found and it does not do binary search on each dimension separately. -- Jamie From shemminger@osdl.org Fri Aug 15 09:37:43 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Aug 2003 09:37:51 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FGbgFl031520 for ; Fri, 15 Aug 2003 09:37:43 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7FGbYo18664; Fri, 15 Aug 2003 09:37:34 -0700 Date: Fri, 15 Aug 2003 09:37:24 -0700 From: Stephen Hemminger To: Dan Aloni , "David S. Miller" Cc: Linux Net-Dev , Mark Huth Subject: Re: [PATCH] network device renaming sysfs fix Message-Id: <20030815093724.519779e6.shemminger@osdl.org> In-Reply-To: <20030815111514.GA5228@callisto.yi.org> References: <20030815111514.GA5228@callisto.yi.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4849 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Fri, 15 Aug 2003 14:15:14 +0300 Dan Aloni wrote: > (repost, now will hopefully reach the mailing list) > > I believe this is a better approach for fixing the sysfs renaming > discrepancy. Later I'll also look into fixing the same issue > with sysctl. > Yes, this is a better fix because it won't break when unregister and free are split into seperate steps (coming soon). But, do we really need the debug message? Why return an error if you already committed the change? If you get an error, then don't rename the network device. The class_dev kobject name is 20 chars and IFNAMSIZ is 16, so the solution needs to truncate if new_name is not null terminated (all 16 chars long). This seems like the best approach: diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c Fri Aug 15 09:34:11 2003 +++ b/net/core/dev.c Fri Aug 15 09:34:11 2003 @@ -2343,14 +2343,18 @@ case SIOCSIFNAME: if (dev->flags & IFF_UP) return -EBUSY; + ifr->ifr_newname[IFNAMSIZ-1] = '\0'; if (__dev_get_by_name(ifr->ifr_newname)) return -EEXIST; - memcpy(dev->name, ifr->ifr_newname, IFNAMSIZ); - dev->name[IFNAMSIZ - 1] = 0; - strlcpy(dev->class_dev.class_id, dev->name, BUS_ID_SIZE); - notifier_call_chain(&netdev_chain, - NETDEV_CHANGENAME, dev); - return 0; + err = class_device_rename(&dev->class_dev, + ifr->ifr_newname); + if (!err) { + strlcpy(dev->name, ifr->ifr_newname, IFNAMSIZ); + + notifier_call_chain(&netdev_chain, + NETDEV_CHANGENAME, dev); + } + return err; /* * Unknown or private ioctl From da-x@gmx.net Fri Aug 15 09:51:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Aug 2003 09:51:04 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FGoxFl031923 for ; Fri, 15 Aug 2003 09:51:00 -0700 Received: (qmail 21274 invoked by uid 65534); 15 Aug 2003 16:50:52 -0000 Received: from DSL212-235-122-158.bb.netvision.net.il (HELO callisto.yi.org) (212.235.122.158) by mail.gmx.net (mp023) with SMTP; 15 Aug 2003 18:50:52 +0200 Date: Fri, 15 Aug 2003 19:50:48 +0300 From: Dan Aloni To: Stephen Hemminger Cc: "David S. Miller" , Linux Net-Dev , Mark Huth Subject: Re: [PATCH] network device renaming sysfs fix Message-ID: <20030815165048.GA11014@callisto.yi.org> References: <20030815111514.GA5228@callisto.yi.org> <20030815093724.519779e6.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030815093724.519779e6.shemminger@osdl.org> User-Agent: Mutt/1.5.4i X-archive-position: 4850 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: da-x@gmx.net Precedence: bulk X-list: netdev On Fri, Aug 15, 2003 at 09:37:24AM -0700, Stephen Hemminger wrote: > Yes, this is a better fix because it won't break when unregister and free are split > into seperate steps (coming soon). > > But, do we really need the debug message? > Why return an error if you already committed the change? If you get an error, > then don't rename the network device. > > The class_dev kobject name is 20 chars and IFNAMSIZ is 16, so the solution > needs to truncate if new_name is not null terminated (all 16 chars long). > > This seems like the best approach: Agreed. > diff -Nru a/net/core/dev.c b/net/core/dev.c > --- a/net/core/dev.c Fri Aug 15 09:34:11 2003 > +++ b/net/core/dev.c Fri Aug 15 09:34:11 2003 [patch] -- Dan Aloni da-x@gmx.net From pb@bieringer.de Fri Aug 15 10:05:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Aug 2003 10:05:34 -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 h7FH5LFl032468 for ; Fri, 15 Aug 2003 10:05:23 -0700 Received: by smtp2.aerasec.de (Postfix, from userid 995) id 6607B137E6; Fri, 15 Aug 2003 19:05:13 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by smtp2.aerasec.de (Postfix) with SMTP id 94B91137E8 for ; Fri, 15 Aug 2003 19:05:12 +0200 (CEST) X-AV-Checked: Fri Aug 15 19:05:12 2003 smtp2.aerasec.de Received: from [192.168.1.2] (p50805F17.dip.t-dialin.net [80.128.95.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 422D5137E6 for ; Fri, 15 Aug 2003 19:05:11 +0200 (CEST) Date: Fri, 15 Aug 2003 19:05:05 +0200 From: Peter Bieringer To: netdev@oss.sgi.com Subject: Re: netfilter6: REJECT target? Message-ID: <96590000.1060967105@worker.muc.bieringer.de> In-Reply-To: <20030813133440.23ad50d7.davem@redhat.com> References: <20030813133440.23ad50d7.davem@redhat.com> 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: 4851 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 --On Wednesday, August 13, 2003 01:34:40 PM -0700 "David S. Miller" wrote: > On Wed, 13 Aug 2003 23:30:49 +0300 (EEST) > Pekka Savola wrote: > >> Is there some reason the IPv6 Netfilter REJECT target hasn't been merged >> during the last 2 years it has existed in Netfilter's patch-o-matic. > > It might be more profitable to ask the netfilter lists > than here. >From some private correspondence some month ago my result is that I think the netfilter6 team needs some more man-power. Currently I know only about Harald Welte, Andras Kis-Szabo has left the team afair. There are also some inconsistency in logging between IPv4 and IPv6 code...but looks like this is all low-prio ;-) 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 kyle@imladris.debian.net Fri Aug 15 10:33:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Aug 2003 10:33:06 -0700 (PDT) Received: from imladris.debian.net (CPE0030ab0b413b-CM023469906297.cpe.net.cable.rogers.com [24.157.3.237]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FHWwFl000506 for ; Fri, 15 Aug 2003 10:33:00 -0700 Received: by imladris.debian.net (Postfix, from userid 1000) id 9F62EE7DF; Fri, 15 Aug 2003 13:34:01 -0400 (EDT) Date: Fri, 15 Aug 2003 13:34:01 -0400 From: Kyle McMartin To: Pekka Savola Cc: netdev@oss.sgi.com Subject: Re: [PATCH] IPsec: add support for Twofish and Serpent Message-ID: <20030815173401.GA3119@imladris.debian.net> References: <20030814180857.GA4205@netppl.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-archive-position: 4852 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kyle@debian.org Precedence: bulk X-list: netdev On Thu, Aug 14, 2003 at 11:25:11PM +0300, Pekka Savola wrote: > Very much agree. > > Also, I could be missing something, but I think it takes much more to add > an encryption algorithm than what the patch does?!?! > The algorithms were already part of the CryptoAPI. All the patch did was simply make them accessible to IPsec, by adding numerical IDs for ESP. Regards, -- Kyle McMartin 1024D/191FCD8A - 331A 9468 C04D 3A76 5C56 BA68 7EB7 92DF 191F CD8A 2048R/F515317D - 68 A9 0D 28 1B DF 8D 42 0F CC AF 98 A8 D5 A4 04 From kyle@imladris.debian.net Fri Aug 15 10:37:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Aug 2003 10:37:33 -0700 (PDT) Received: from imladris.debian.net (CPE0030ab0b413b-CM023469906297.cpe.net.cable.rogers.com [24.157.3.237]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FHbSFl000866 for ; Fri, 15 Aug 2003 10:37:29 -0700 Received: by imladris.debian.net (Postfix, from userid 1000) id A5FE1E7DF; Fri, 15 Aug 2003 13:38:31 -0400 (EDT) Date: Fri, 15 Aug 2003 13:38:31 -0400 From: Kyle McMartin To: Pekka Pietikainen Cc: netdev@oss.sgi.com Subject: Re: [PATCH] IPsec: add support for Twofish and Serpent Message-ID: <20030815173831.GB3119@imladris.debian.net> References: <20030814164819.GA18948@imladris.debian.net> <20030814180857.GA4205@netppl.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030814180857.GA4205@netppl.fi> User-Agent: Mutt/1.5.4i X-archive-position: 4853 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kyle@debian.org Precedence: bulk X-list: netdev On Thu, Aug 14, 2003 at 09:08:57PM +0300, Pekka Pietikainen wrote: > There's absolutely no need to add complexity unless there are some technical > arguments for doing so, say compatibility with legacy implementations > which justifies bothering with DES/3DES/MD5 although they're inferior to > AES and SHA1 in just about every aspect. > There are simple technical arguments for doing so, SERPENT and Twofish are both either as secure, or more secure than rijndael, as it stood with the amount of cryptanalysis the three received as part of the AES selection process. (Serpent, as it stood, was more secure, since it had more rounds, and more proven sboxes). Adding more *secure* algorithms does no harm. Regards, -- Kyle McMartin 1024D/191FCD8A - 331A 9468 C04D 3A76 5C56 BA68 7EB7 92DF 191F CD8A 2048R/F515317D - 68 A9 0D 28 1B DF 8D 42 0F CC AF 98 A8 D5 A4 04 From kyle@imladris.debian.net Fri Aug 15 10:41:42 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Aug 2003 10:41:46 -0700 (PDT) Received: from imladris.debian.net (CPE0030ab0b413b-CM023469906297.cpe.net.cable.rogers.com [24.157.3.237]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FHfeFl001245 for ; Fri, 15 Aug 2003 10:41:41 -0700 Received: by imladris.debian.net (Postfix, from userid 1000) id 14E81E7DF; Fri, 15 Aug 2003 13:42:44 -0400 (EDT) Date: Fri, 15 Aug 2003 13:42:43 -0400 From: Kyle McMartin To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] IPsec: add support for Twofish and Serpent Message-ID: <20030815174243.GC3119@imladris.debian.net> References: <20030814180857.GA4205@netppl.fi> <20030814191259.435945cf.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030814191259.435945cf.davem@redhat.com> User-Agent: Mutt/1.5.4i X-archive-position: 4854 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kyle@debian.org Precedence: bulk X-list: netdev On Thu, Aug 14, 2003 at 07:12:59PM -0700, David S. Miller wrote: > I totally disagree, choice is everything. > > That's why we allow NULL crypto algorithms. Not doing > so turns this into a political thing, which I decidedly > do not want our IPSEC implementation to be all about. > > And therefore I will add the patch. > Thank you, David. I completely agree with allowing users to choose which algorithms they wish to deploy. > When using pfkeyv2 sockets, yes you have to assign a number and then > the APP has to be aware of it. This just shows how bogus it is to use > fixed numbers instead of strings to select crypto algorithms. > Again, I agree. Especially given the limitations of using the private ESP id space, since there is no new RFC delegating additions yet. Regards, -- Kyle McMartin 1024D/191FCD8A - 331A 9468 C04D 3A76 5C56 BA68 7EB7 92DF 191F CD8A 2048R/F515317D - 68 A9 0D 28 1B DF 8D 42 0F CC AF 98 A8 D5 A4 04 From mhuth@mvista.com Fri Aug 15 11:01:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Aug 2003 11:01:04 -0700 (PDT) Received: from zipcode.az.mvista.com (rav-az.mvista.com [65.200.49.157]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FI0xFl001688 for ; Fri, 15 Aug 2003 11:01:00 -0700 Received: from mvista.com ([10.50.1.182]) by zipcode.az.mvista.com (8.9.3/8.9.3) with ESMTP id LAA14836; Fri, 15 Aug 2003 11:15:35 -0700 Message-ID: <3F3D21DE.50906@mvista.com> Date: Fri, 15 Aug 2003 11:09:34 -0700 From: Mark Huth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Aloni CC: Linux Net-Dev , "David S. Miller" Subject: Re: [PATCH] network device renaming sysfs fix References: <20030815111514.GA5228@callisto.yi.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4855 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mhuth@mvista.com Precedence: bulk X-list: netdev Agreed. We had not yet found the class_device_rename. Hopefully, this is no longer in HTML format. By all means, help not to look like a bozo :-) - a tall order, I realize. Mark Huth Dan Aloni wrote: >(repost, now will hopefully reach the mailing list) > >I believe this is a better approach for fixing the sysfs renaming >discrepancy. Later I'll also look into fixing the same issue >with sysctl. > >--- linux/net/core/dev.c 2003-08-15 12:47:50.000000000 +0300 >+++ linux/net/core/dev.c 2003-08-15 12:47:59.000000000 +0300 >@@ -2347,10 +2347,14 @@ > return -EEXIST; > memcpy(dev->name, ifr->ifr_newname, IFNAMSIZ); > dev->name[IFNAMSIZ - 1] = 0; >- strlcpy(dev->class_dev.class_id, dev->name, BUS_ID_SIZE); >+ >+ err = class_device_rename(&dev->class_dev, dev->name); >+ if (err) >+ printk(KERN_DEBUG "SIOCSIFNAME: error renaming class_device (%d)\n", err); >+ > notifier_call_chain(&netdev_chain, > NETDEV_CHANGENAME, dev); >- return 0; >+ return err; > > /* > * Unknown or private ioctl > > > > > From shemminger@osdl.org Fri Aug 15 11:01:30 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Aug 2003 11:01:33 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FI1TFl001737 for ; Fri, 15 Aug 2003 11:01:30 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7FI1Go09924; Fri, 15 Aug 2003 11:01:16 -0700 Date: Fri, 15 Aug 2003 11:01:07 -0700 From: Stephen Hemminger To: "David S. Miller" , Hideaki YOSHIFUJI Cc: netdev@oss.sgi.com Subject: [PATCH] set owner on /proc/net/rt6_stats Message-Id: <20030815110107.3ea9b4dc.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4856 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Fix up initialization of IPV6 /proc/net/rt6_stats entries so owner field is set. Use proc_net_fops_create helper instead of proc_net_create and fops assignment. diff -Nru a/net/ipv6/route.c b/net/ipv6/route.c --- a/net/ipv6/route.c Fri Aug 15 10:57:55 2003 +++ b/net/ipv6/route.c Fri Aug 15 10:57:55 2003 @@ -1983,10 +1983,11 @@ NULL, NULL); fib6_init(); #ifdef CONFIG_PROC_FS - proc_net_create("ipv6_route", 0, rt6_proc_info); - p = create_proc_entry("rt6_stats", S_IRUGO, proc_net); + p = proc_net_create("ipv6_route", 0, rt6_proc_info); if (p) - p->proc_fops = &rt6_stats_seq_fops; + p->owner = THIS_MODULE; + + proc_net_fops_create("rt6_stats", S_IRUGO, &rt6_stats_seq_fops); #endif #ifdef CONFIG_XFRM xfrm6_init(); From yoshfuji@linux-ipv6.org Fri Aug 15 13:33:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Aug 2003 13:33:25 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FKXGFl006117 for ; Fri, 15 Aug 2003 13:33:17 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h7FKXW1M008781; Sat, 16 Aug 2003 05:33:32 +0900 Date: Sat, 16 Aug 2003 05:33:32 +0900 (JST) Message-Id: <20030816.053332.108341697.yoshfuji@linux-ipv6.org> To: davem@redhat.com CC: netdev@oss.sgi.com Subject: [PATCH] SCTP: typo in Kconfig From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4857 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Hello. This patch fixes typo in net/sctp/Kconfig. Thanks in advance. Index: linux-2.6/net/sctp/Kconfig =================================================================== RCS file: /home/cvs/linux-2.5/net/sctp/Kconfig,v retrieving revision 1.6 diff -u -r1.6 Kconfig --- linux-2.6/net/sctp/Kconfig 10 May 2003 12:19:24 -0000 1.6 +++ linux-2.6/net/sctp/Kconfig 15 Aug 2003 19:01:23 -0000 @@ -43,7 +43,7 @@ bool "SCTP: Use old checksum (Adler-32)" depends on IP_SCTP help - RCF2960 currently specifies the Adler-32 checksum algorithm for SCTP. + RFC2960 currently specifies the Adler-32 checksum algorithm for SCTP. This has been deprecated and replaced by an algorithm now referred to as crc32c. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From acme@conectiva.com.br Fri Aug 15 14:06:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Aug 2003 14:06:22 -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 h7FL6FFl006765 for ; Fri, 15 Aug 2003 14:06:16 -0700 Received: from [200.181.170.104] (helo=brinquendo.conectiva.com.br) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 19nls9-00088l-00; Fri, 15 Aug 2003 18:12:34 -0300 Received: by brinquendo.conectiva.com.br (Postfix, from userid 500) id B49C61966D; Fri, 15 Aug 2003 21:12:18 +0000 (UTC) Date: Fri, 15 Aug 2003 18:12:17 -0300 From: Arnaldo Carvalho de Melo To: Stephen Hemminger Cc: "David S. Miller" , Jeroen Vreeken , linux-hams@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] (10/11) netrom - convert /proc interface to seq_file Message-ID: <20030815211217.GL1564@conectiva.com.br> References: <20030813154635.376df59b.shemminger@osdl.org> <20030814172539.GD1785@conectiva.com.br> <20030814113025.2b40be14.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030814113025.2b40be14.shemminger@osdl.org> X-Url: http://advogato.org/person/acme Organization: Conectiva S.A. User-Agent: Mutt/1.5.4i X-archive-position: 4858 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 Thu, Aug 14, 2003 at 11:30:25AM -0700, Stephen Hemminger escreveu: > On Thu, 14 Aug 2003 14:25:39 -0300 > Arnaldo Carvalho de Melo wrote: > > why not just one seq_printf call? > > ax2asc() returns a pointer to static buffer. argh :-\ Even if only for correctness shouldn't it receive a buffer, like snprintf, etc? - Arnaldo From shemminger@osdl.org Fri Aug 15 14:08:04 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Aug 2003 14:08:07 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FL83Fl007117 for ; Fri, 15 Aug 2003 14:08:04 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7FL7oo19859; Fri, 15 Aug 2003 14:07:50 -0700 Date: Fri, 15 Aug 2003 14:07:40 -0700 From: Stephen Hemminger To: YOSHIFUJI Hideaki , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] fix build problem with IPV6 Message-Id: <20030815140740.388a79c4.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4859 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev IPV6 won't build in current 2.6.0-test3 tree unless CONFIG_XFRM is defined because of reference to xfrm6_fini. The linux way to fix this would be to make the functions stub's in the include file, but that isn't how IPV6 does it now for other xfrm functions. diff -Nru a/net/ipv6/route.c b/net/ipv6/route.c --- a/net/ipv6/route.c Fri Aug 15 14:04:05 2003 +++ b/net/ipv6/route.c Fri Aug 15 14:04:05 2003 @@ -2000,7 +2000,9 @@ proc_net_remove("ipv6_route"); proc_net_remove("rt6_stats"); #endif +#ifdef CONFIG_XFRM xfrm6_fini(); +#endif rt6_ifdown(NULL); fib6_gc_cleanup(); kmem_cache_destroy(ip6_dst_ops.kmem_cachep); From acme@conectiva.com.br Fri Aug 15 14:13:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Aug 2003 14:13:43 -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 h7FLDZFl007486 for ; Fri, 15 Aug 2003 14:13:36 -0700 Received: from [200.181.170.104] (helo=brinquendo.conectiva.com.br) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 19nlzI-00089B-00; Fri, 15 Aug 2003 18:19:57 -0300 Received: by brinquendo.conectiva.com.br (Postfix, from userid 500) id B07151966D; Fri, 15 Aug 2003 21:19:39 +0000 (UTC) Date: Fri, 15 Aug 2003 18:19:38 -0300 From: Arnaldo Carvalho de Melo To: Stephen Hemminger Cc: YOSHIFUJI Hideaki , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] fix build problem with IPV6 Message-ID: <20030815211938.GM1564@conectiva.com.br> References: <20030815140740.388a79c4.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030815140740.388a79c4.shemminger@osdl.org> X-Url: http://advogato.org/person/acme Organization: Conectiva S.A. User-Agent: Mutt/1.5.4i X-archive-position: 4860 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Em Fri, Aug 15, 2003 at 02:07:40PM -0700, Stephen Hemminger escreveu: > IPV6 won't build in current 2.6.0-test3 tree unless CONFIG_XFRM is defined > because of reference to xfrm6_fini. > > The linux way to fix this would be to make the functions > stub's in the include file, but that isn't how IPV6 does it now > for other xfrm functions. > > diff -Nru a/net/ipv6/route.c b/net/ipv6/route.c > --- a/net/ipv6/route.c Fri Aug 15 14:04:05 2003 > +++ b/net/ipv6/route.c Fri Aug 15 14:04:05 2003 > @@ -2000,7 +2000,9 @@ > proc_net_remove("ipv6_route"); > proc_net_remove("rt6_stats"); > #endif > +#ifdef CONFIG_XFRM > xfrm6_fini(); > +#endif > rt6_ifdown(NULL); > fib6_gc_cleanup(); > kmem_cache_destroy(ip6_dst_ops.kmem_cachep); Stephen, Couldn't this be ifdefed at the header that has the xfrm6_fini prototype? #ifndef CONFIG_XFRM void xfrm6_fini(void) {} #endif Or something like that. - Arnaldo From romieu@fr.zoreil.com Fri Aug 15 14:50:09 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Aug 2003 14:50:13 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FLo4Fl008892 for ; Fri, 15 Aug 2003 14:50:07 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id h7FLli0m032094; Fri, 15 Aug 2003 23:47:44 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id h7FLlghJ032093; Fri, 15 Aug 2003 23:47:43 +0200 Date: Fri, 15 Aug 2003 23:47:42 +0200 From: Francois Romieu To: Arnaldo Carvalho de Melo Cc: Stephen Hemminger , "David S. Miller" , Jeroen Vreeken , linux-hams@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] (10/11) netrom - convert /proc interface to seq_file Message-ID: <20030815234742.A31946@electric-eye.fr.zoreil.com> References: <20030813154635.376df59b.shemminger@osdl.org> <20030814172539.GD1785@conectiva.com.br> <20030814113025.2b40be14.shemminger@osdl.org> <20030815211217.GL1564@conectiva.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030815211217.GL1564@conectiva.com.br>; from acme@conectiva.com.br on Fri, Aug 15, 2003 at 06:12:17PM -0300 X-archive-position: 4861 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Arnaldo Carvalho de Melo : [ax2asc and the static buffer from hell] > argh :-\ Even if only for correctness shouldn't it receive a buffer, like > snprintf, etc? Then its name would be "ax2asc2". -- Ueimor From shemminger@osdl.org Fri Aug 15 15:28:52 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Aug 2003 15:28:58 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FMSpFl009502 for ; Fri, 15 Aug 2003 15:28:52 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7FMSco04917; Fri, 15 Aug 2003 15:28:38 -0700 Date: Fri, 15 Aug 2003 15:28:28 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (1/4) net-sysfs misc fixes. Message-Id: <20030815152828.626862d5.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4862 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev This is a some minor net-sysfs code cleanup; prior to some real changes. - define format strings once rather than N times - add GNU license that I forgot in original code - move read_lock out from format_address to show_address so device is alive test is inside of lock. diff -Nru a/net/core/net-sysfs.c b/net/core/net-sysfs.c --- a/net/core/net-sysfs.c Fri Aug 15 15:23:00 2003 +++ b/net/core/net-sysfs.c Fri Aug 15 15:23:00 2003 @@ -3,6 +3,10 @@ * * Copyright (c) 2003 Stephen Hemminger * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. */ #include @@ -15,6 +19,10 @@ #define to_class_dev(obj) container_of(obj,struct class_device,kobj) #define to_net_dev(class) container_of(class, struct net_device, class_dev) +static const char *fmt_hex = "%#x\n"; +static const char *fmt_dec = "%d\n"; +static const char *fmt_ulong = "%lu\n"; + static inline int dev_isalive(const struct net_device *dev) { return dev->reg_state == NETREG_REGISTERED; @@ -79,11 +87,11 @@ NETDEVICE_SHOW(field, format_string) \ static CLASS_DEVICE_ATTR(field, S_IRUGO, show_##field, NULL) \ -NETDEVICE_ATTR(addr_len, "%d\n"); -NETDEVICE_ATTR(iflink, "%d\n"); -NETDEVICE_ATTR(ifindex, "%d\n"); -NETDEVICE_ATTR(features, "%#x\n"); -NETDEVICE_ATTR(type, "%d\n"); +NETDEVICE_ATTR(addr_len, fmt_dec); +NETDEVICE_ATTR(iflink, fmt_dec); +NETDEVICE_ATTR(ifindex, fmt_dec); +NETDEVICE_ATTR(features, fmt_hex); +NETDEVICE_ATTR(type, fmt_dec); /* use same locking rules as GIFHWADDR ioctl's */ static ssize_t format_addr(char *buf, const unsigned char *addr, int len) @@ -91,20 +99,22 @@ int i; char *cp = buf; - read_lock(&dev_base_lock); for (i = 0; i < len; i++) cp += sprintf(cp, "%02x%c", addr[i], i == (len - 1) ? '\n' : ':'); - read_unlock(&dev_base_lock); return cp - buf; } static ssize_t show_address(struct class_device *dev, char *buf) { struct net_device *net = to_net_dev(dev); + ssize_t ret = -EINVAL; + + read_lock(&dev_base_lock); if (dev_isalive(net)) - return format_addr(buf, net->dev_addr, net->addr_len); - return -EINVAL; + ret = format_addr(buf, net->dev_addr, net->addr_len); + read_unlock(&dev_base_lock); + return ret; } static ssize_t show_broadcast(struct class_device *dev, char *buf) @@ -119,7 +129,7 @@ static CLASS_DEVICE_ATTR(broadcast, S_IRUGO, show_broadcast, NULL); /* read-write attributes */ -NETDEVICE_SHOW(mtu, "%d\n"); +NETDEVICE_SHOW(mtu, fmt_dec); static int change_mtu(struct net_device *net, unsigned long new_mtu) { @@ -133,7 +143,7 @@ static CLASS_DEVICE_ATTR(mtu, S_IRUGO | S_IWUSR, show_mtu, store_mtu); -NETDEVICE_SHOW(flags, "%#x\n"); +NETDEVICE_SHOW(flags, fmt_hex); static int change_flags(struct net_device *net, unsigned long new_flags) { @@ -147,7 +157,7 @@ static CLASS_DEVICE_ATTR(flags, S_IRUGO | S_IWUSR, show_flags, store_flags); -NETDEVICE_SHOW(tx_queue_len, "%lu\n"); +NETDEVICE_SHOW(tx_queue_len, fmt_ulong); static int change_tx_queue_len(struct net_device *net, unsigned long new_len) { @@ -186,7 +196,7 @@ static ssize_t net_device_stat_show(unsigned long var, char *buf) { - return sprintf(buf, "%lu\n", var); + return sprintf(buf, fmt_ulong, var); } /* generate a read-only statistics attribute */ From shemminger@osdl.org Fri Aug 15 15:33:05 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Aug 2003 15:33:08 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FMX5Fl009850 for ; Fri, 15 Aug 2003 15:33:05 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7FMWro06184; Fri, 15 Aug 2003 15:32:53 -0700 Date: Fri, 15 Aug 2003 15:32:43 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (2/4) net-sysfs - use attribute group instead of kobject for statistics Message-Id: <20030815153243.3b8de683.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4863 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Net statistics were in a kobject only because there was no better way to create a directory. Latest 2.6.0-test3 bk tree, has merged in Pat's change to provide "attribute groups". This patch converts netdevice's from a statistic's kobject to attribute group. This is cleaner and fixes some shutdown unload issues as well. Ps. it gets rid of of the "object has no release" warning as well. diff -Nru a/include/linux/netdevice.h b/include/linux/netdevice.h --- a/include/linux/netdevice.h Fri Aug 15 15:23:44 2003 +++ b/include/linux/netdevice.h Fri Aug 15 15:23:44 2003 @@ -463,9 +463,6 @@ /* class/net/name entry */ struct class_device class_dev; - - /* statistics sub-directory */ - struct kobject stats_kobj; }; #define SET_MODULE_OWNER(dev) do { } while (0) diff -Nru a/net/core/net-sysfs.c b/net/core/net-sysfs.c --- a/net/core/net-sysfs.c Fri Aug 15 15:23:44 2003 +++ b/net/core/net-sysfs.c Fri Aug 15 15:23:44 2003 @@ -188,107 +188,94 @@ NULL }; -struct netstat_fs_entry { - struct attribute attr; - ssize_t (*show)(const struct net_device_stats *, char *); - ssize_t (*store)(struct net_device_stats *, const char *, size_t); -}; - -static ssize_t net_device_stat_show(unsigned long var, char *buf) +/* Show a given an attribute in the statistics group */ +static ssize_t netstat_show(const struct class_device *cd, char *buf, + unsigned long offset) { - return sprintf(buf, fmt_ulong, var); + struct net_device *dev = to_net_dev(cd); + struct net_device_stats *stats; + ssize_t ret = -EINVAL; + + if (offset > sizeof(struct net_device_stats) || + offset % sizeof(unsigned long) != 0) + WARN_ON(1); + + read_lock(&dev_base_lock); + if (dev_isalive(dev) && dev->get_stats && + (stats = (*dev->get_stats)(dev))) + ret = sprintf(buf, fmt_ulong, + *(unsigned long *)(((u8 *) stats) + offset)); + + read_unlock(&dev_base_lock); + return ret; } /* generate a read-only statistics attribute */ -#define NETDEVICE_STAT(_NAME) \ -static ssize_t show_stat_##_NAME(const struct net_device_stats *stats, \ - char *buf) \ +#define NETSTAT_ENTRY(name) \ +static ssize_t show_##name(struct class_device *cd, char *buf) \ { \ - return net_device_stat_show(stats->_NAME, buf); \ + return netstat_show(cd, buf, \ + offsetof(struct net_device_stats, name)); \ } \ -static struct netstat_fs_entry net_stat_##_NAME = { \ - .attr = {.name = __stringify(_NAME), .mode = S_IRUGO }, \ - .show = show_stat_##_NAME, \ -} +static CLASS_DEVICE_ATTR(name, S_IRUGO, show_##name, NULL) -NETDEVICE_STAT(rx_packets); -NETDEVICE_STAT(tx_packets); -NETDEVICE_STAT(rx_bytes); -NETDEVICE_STAT(tx_bytes); -NETDEVICE_STAT(rx_errors); -NETDEVICE_STAT(tx_errors); -NETDEVICE_STAT(rx_dropped); -NETDEVICE_STAT(tx_dropped); -NETDEVICE_STAT(multicast); -NETDEVICE_STAT(collisions); -NETDEVICE_STAT(rx_length_errors); -NETDEVICE_STAT(rx_over_errors); -NETDEVICE_STAT(rx_crc_errors); -NETDEVICE_STAT(rx_frame_errors); -NETDEVICE_STAT(rx_fifo_errors); -NETDEVICE_STAT(rx_missed_errors); -NETDEVICE_STAT(tx_aborted_errors); -NETDEVICE_STAT(tx_carrier_errors); -NETDEVICE_STAT(tx_fifo_errors); -NETDEVICE_STAT(tx_heartbeat_errors); -NETDEVICE_STAT(tx_window_errors); -NETDEVICE_STAT(rx_compressed); -NETDEVICE_STAT(tx_compressed); - -static struct attribute *default_attrs[] = { - &net_stat_rx_packets.attr, - &net_stat_tx_packets.attr, - &net_stat_rx_bytes.attr, - &net_stat_tx_bytes.attr, - &net_stat_rx_errors.attr, - &net_stat_tx_errors.attr, - &net_stat_rx_dropped.attr, - &net_stat_tx_dropped.attr, - &net_stat_multicast.attr, - &net_stat_collisions.attr, - &net_stat_rx_length_errors.attr, - &net_stat_rx_over_errors.attr, - &net_stat_rx_crc_errors.attr, - &net_stat_rx_frame_errors.attr, - &net_stat_rx_fifo_errors.attr, - &net_stat_rx_missed_errors.attr, - &net_stat_tx_aborted_errors.attr, - &net_stat_tx_carrier_errors.attr, - &net_stat_tx_fifo_errors.attr, - &net_stat_tx_heartbeat_errors.attr, - &net_stat_tx_window_errors.attr, - &net_stat_rx_compressed.attr, - &net_stat_tx_compressed.attr, +NETSTAT_ENTRY(rx_packets); +NETSTAT_ENTRY(tx_packets); +NETSTAT_ENTRY(rx_bytes); +NETSTAT_ENTRY(tx_bytes); +NETSTAT_ENTRY(rx_errors); +NETSTAT_ENTRY(tx_errors); +NETSTAT_ENTRY(rx_dropped); +NETSTAT_ENTRY(tx_dropped); +NETSTAT_ENTRY(multicast); +NETSTAT_ENTRY(collisions); +NETSTAT_ENTRY(rx_length_errors); +NETSTAT_ENTRY(rx_over_errors); +NETSTAT_ENTRY(rx_crc_errors); +NETSTAT_ENTRY(rx_frame_errors); +NETSTAT_ENTRY(rx_fifo_errors); +NETSTAT_ENTRY(rx_missed_errors); +NETSTAT_ENTRY(tx_aborted_errors); +NETSTAT_ENTRY(tx_carrier_errors); +NETSTAT_ENTRY(tx_fifo_errors); +NETSTAT_ENTRY(tx_heartbeat_errors); +NETSTAT_ENTRY(tx_window_errors); +NETSTAT_ENTRY(rx_compressed); +NETSTAT_ENTRY(tx_compressed); + +static struct attribute *netstat_attrs[] = { + &class_device_attr_rx_packets.attr, + &class_device_attr_tx_packets.attr, + &class_device_attr_rx_bytes.attr, + &class_device_attr_tx_bytes.attr, + &class_device_attr_rx_errors.attr, + &class_device_attr_tx_errors.attr, + &class_device_attr_rx_dropped.attr, + &class_device_attr_tx_dropped.attr, + &class_device_attr_multicast.attr, + &class_device_attr_collisions.attr, + &class_device_attr_rx_length_errors.attr, + &class_device_attr_rx_over_errors.attr, + &class_device_attr_rx_crc_errors.attr, + &class_device_attr_rx_frame_errors.attr, + &class_device_attr_rx_fifo_errors.attr, + &class_device_attr_rx_missed_errors.attr, + &class_device_attr_tx_aborted_errors.attr, + &class_device_attr_tx_carrier_errors.attr, + &class_device_attr_tx_fifo_errors.attr, + &class_device_attr_tx_heartbeat_errors.attr, + &class_device_attr_tx_window_errors.attr, + &class_device_attr_rx_compressed.attr, + &class_device_attr_tx_compressed.attr, NULL }; -static ssize_t -netstat_attr_show(struct kobject *kobj, struct attribute *attr, char *buf) -{ - struct netstat_fs_entry *entry - = container_of(attr, struct netstat_fs_entry, attr); - struct net_device *dev - = to_net_dev(to_class_dev(kobj->parent)); - struct net_device_stats *stats; - ssize_t ret = -EINVAL; - - read_lock(&dev_base_lock); - if (dev_isalive(dev) && entry->show && dev->get_stats && - (stats = (*dev->get_stats)(dev))) - ret = entry->show(stats, buf); - read_unlock(&dev_base_lock); - return ret; -} - -static struct sysfs_ops netstat_sysfs_ops = { - .show = netstat_attr_show, +static struct attribute_group netstat_group = { + .name = "statistics", + .attrs = netstat_attrs, }; -static struct kobj_type netstat_ktype = { - .sysfs_ops = &netstat_sysfs_ops, - .default_attrs = default_attrs, -}; #ifdef CONFIG_HOTPLUG static int netdev_hotplug(struct class_device *cd, char **envp, @@ -339,32 +326,23 @@ goto out_unreg; } - net->stats_kobj.parent = NULL; - if (net->get_stats) { - struct kobject *k = &net->stats_kobj; - - k->parent = &class_dev->kobj; - strlcpy(k->name, "statistics", KOBJ_NAME_LEN); - k->ktype = &netstat_ktype; - if((ret = kobject_register(k))) - goto out_unreg; - } + if (net->get_stats && + (ret = sysfs_create_group(&class_dev->kobj, &netstat_group))) + goto out_unreg; + + return 0; -out: - return ret; out_unreg: printk(KERN_WARNING "%s: sysfs attribute registration failed %d\n", net->name, ret); class_device_unregister(class_dev); - goto out; +out: + return ret; } void netdev_unregister_sysfs(struct net_device *net) { - if (net->stats_kobj.parent) - kobject_unregister(&net->stats_kobj); - class_device_unregister(&net->class_dev); } From shemminger@osdl.org Fri Aug 15 15:36:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Aug 2003 15:36:37 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FMaYFl010191 for ; Fri, 15 Aug 2003 15:36:34 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7FMaNo06710; Fri, 15 Aug 2003 15:36:23 -0700 Date: Fri, 15 Aug 2003 15:36:13 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (3/4) move code inline if short and used once. Message-Id: <20030815153613.295aba61.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4864 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Now that unregister_sysfs got smaller, just eliminate it and call class_device_unregister directly. netdev_finish_unregister is called one place, therefore it is easier to understand if we just put those few lines into wait_allrefs state machine. diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c Fri Aug 15 15:24:32 2003 +++ b/net/core/dev.c Fri Aug 15 15:24:32 2003 @@ -187,7 +187,6 @@ extern int netdev_sysfs_init(void); extern int netdev_register_sysfs(struct net_device *); -extern void netdev_unregister_sysfs(struct net_device *); /******************************************************************************* @@ -2706,38 +2705,17 @@ goto out; } -/** - * netdev_finish_unregister - complete unregistration - * @dev: device +/* + * netdev_wait_allrefs - wait until all references are gone. * - * Destroy and free a dead device. A value of zero is returned on - * success. + * This is called when unregistering network devices. + * + * Any protocol or device that holds a reference should register + * for netdevice notification, and cleanup and put back the + * reference if they receive an UNREGISTER event. + * We can get stuck here if buggy protocols don't correctly + * call dev_put. */ -static int netdev_finish_unregister(struct net_device *dev) -{ - BUG_TRAP(!dev->ip_ptr); - BUG_TRAP(!dev->ip6_ptr); - BUG_TRAP(!dev->dn_ptr); - - if (dev->reg_state != NETREG_UNREGISTERED) { - printk(KERN_ERR "Freeing alive device %p, %s\n", - dev, dev->name); - return 0; - } -#ifdef NET_REFCNT_DEBUG - printk(KERN_DEBUG "netdev_finish_unregister: %s%s.\n", dev->name, - (dev->destructor != NULL)?"":", old style"); -#endif - - /* It must be the very last action, after this 'dev' may point - * to freed up memory. - */ - if (dev->destructor) - dev->destructor(dev); - - return 0; -} - static void netdev_wait_allrefs(struct net_device *dev) { unsigned long rebroadcast_time, warning_time; @@ -2833,13 +2811,23 @@ break; case NETREG_UNREGISTERING: - netdev_unregister_sysfs(dev); + class_device_unregister(&dev->class_dev); dev->reg_state = NETREG_UNREGISTERED; netdev_wait_allrefs(dev); + + /* paranoia */ BUG_ON(atomic_read(&dev->refcnt)); - - netdev_finish_unregister(dev); + BUG_TRAP(!dev->ip_ptr); + BUG_TRAP(!dev->ip6_ptr); + BUG_TRAP(!dev->dn_ptr); + + + /* It must be the very last action, + * after this 'dev' may point to freed up memory. + */ + if (dev->destructor) + dev->destructor(dev); break; default: diff -Nru a/net/core/net-sysfs.c b/net/core/net-sysfs.c --- a/net/core/net-sysfs.c Fri Aug 15 15:24:32 2003 +++ b/net/core/net-sysfs.c Fri Aug 15 15:24:32 2003 @@ -341,11 +341,6 @@ return ret; } -void netdev_unregister_sysfs(struct net_device *net) -{ - class_device_unregister(&net->class_dev); -} - int netdev_sysfs_init(void) { return class_register(&net_class); From shemminger@osdl.org Fri Aug 15 15:38:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Aug 2003 15:38:32 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FMcOFl010486 for ; Fri, 15 Aug 2003 15:38:25 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7FMcDo07233; Fri, 15 Aug 2003 15:38:13 -0700 Date: Fri, 15 Aug 2003 15:38:04 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (4/4) add wireless statistics to sysfs Message-Id: <20030815153804.58e7edc0.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4865 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Add wireless statistics to /net/class/ethXX/wireless. diff -Nru a/net/core/net-sysfs.c b/net/core/net-sysfs.c --- a/net/core/net-sysfs.c Fri Aug 15 15:25:00 2003 +++ b/net/core/net-sysfs.c Fri Aug 15 15:25:00 2003 @@ -15,6 +15,7 @@ #include #include #include +#include #define to_class_dev(obj) container_of(obj,struct class_device,kobj) #define to_net_dev(class) container_of(class, struct net_device, class_dev) @@ -276,6 +277,67 @@ .attrs = netstat_attrs, }; +#ifdef WIRELESS_EXT +/* helper function that does all the locking etc for wireless stats */ +static ssize_t wireless_show(struct class_device *cd, char *buf, + ssize_t (*format)(const struct iw_statistics *, + char *)) +{ + struct net_device *dev = to_net_dev(cd); + const struct iw_statistics *iw; + ssize_t ret = -EINVAL; + + read_lock(&dev_base_lock); + if (dev_isalive(dev) && dev->get_wireless_stats + && (iw = dev->get_wireless_stats(dev)) != NULL) + ret = (*format)(iw, buf); + read_unlock(&dev_base_lock); + + return ret; +} + +/* show function template for wireless fields */ +#define WIRELESS_SHOW(name, field, format_string) \ +static ssize_t format_iw_##name(const struct iw_statistics *iw, char *buf) \ +{ \ + return sprintf(buf, format_string, iw->field); \ +} \ +static ssize_t show_iw_##name(struct class_device *cd, char *buf) \ +{ \ + return wireless_show(cd, buf, format_iw_##name); \ +} \ +static CLASS_DEVICE_ATTR(name, S_IRUGO, show_iw_##name, NULL) + +WIRELESS_SHOW(status, status, fmt_hex); +WIRELESS_SHOW(link, qual.qual, fmt_dec); +WIRELESS_SHOW(level, qual.level, fmt_dec); +WIRELESS_SHOW(noise, qual.noise, fmt_dec); +WIRELESS_SHOW(nwid, discard.nwid, fmt_dec); +WIRELESS_SHOW(crypt, discard.code, fmt_dec); +WIRELESS_SHOW(fragment, discard.fragment, fmt_dec); +WIRELESS_SHOW(misc, discard.misc, fmt_dec); +WIRELESS_SHOW(retries, discard.retries, fmt_dec); +WIRELESS_SHOW(beacon, miss.beacon, fmt_dec); + +static struct attribute *wireless_attrs[] = { + &class_device_attr_status.attr, + &class_device_attr_link.attr, + &class_device_attr_level.attr, + &class_device_attr_noise.attr, + &class_device_attr_nwid.attr, + &class_device_attr_crypt.attr, + &class_device_attr_fragment.attr, + &class_device_attr_retries.attr, + &class_device_attr_misc.attr, + &class_device_attr_beacon.attr, + NULL +}; + +static struct attribute_group wireless_group = { + .name = "wireless", + .attrs = wireless_attrs, +}; +#endif #ifdef CONFIG_HOTPLUG static int netdev_hotplug(struct class_device *cd, char **envp, @@ -331,6 +393,11 @@ (ret = sysfs_create_group(&class_dev->kobj, &netstat_group))) goto out_unreg; +#ifdef WIRELESS_EXT + if (net->get_wireless_stats && + (ret = sysfs_create_group(&class_dev->kobj, &wireless_group))) + goto out_unreg; +#endif return 0; out_unreg: From shemminger@osdl.org Fri Aug 15 15:46:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Aug 2003 15:46:39 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FMkZFl010896 for ; Fri, 15 Aug 2003 15:46:36 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7FMkIo08592; Fri, 15 Aug 2003 15:46:18 -0700 Date: Fri, 15 Aug 2003 15:46:08 -0700 From: Stephen Hemminger To: Jean Tourrilhes Cc: irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] (1/5) get rid of useless hashbin in irtty Message-Id: <20030815154608.56cf0551.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4866 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Working on converting IRDA to new netdevice semantics, this is the first of some of the small things I found. The irtty hashbin is created, maintained and never used. Motivation for removing is that the hashbin locking has problems with the locking assumptions in on network device removal. diff -Nru a/drivers/net/irda/irtty.c b/drivers/net/irda/irtty.c --- a/drivers/net/irda/irtty.c Fri Aug 15 11:46:11 2003 +++ b/drivers/net/irda/irtty.c Fri Aug 15 11:46:11 2003 @@ -39,7 +39,6 @@ #include #include -static hashbin_t *irtty = NULL; static struct tty_ldisc irda_ldisc; static int qos_mtt_bits = 0x03; /* 5 ms or more */ @@ -75,14 +74,6 @@ { int status; - /* Probably no need to lock here because all operations done in - * open()/close() which are already safe - Jean II */ - irtty = hashbin_new( HB_NOLOCK); - if ( irtty == NULL) { - printk( KERN_WARNING "IrDA: Can't allocate irtty hashbin!\n"); - return -ENOMEM; - } - /* Fill in our line protocol discipline, and register it */ memset(&irda_ldisc, 0, sizeof( irda_ldisc)); @@ -124,12 +115,6 @@ __FUNCTION__, ret); } - /* - * The TTY should care of deallocating the instances by using the - * callback to irtty_close(), therefore we do give any deallocation - * function to hashbin_destroy(). - */ - hashbin_delete(irtty, NULL); } /* @@ -172,8 +157,6 @@ /* Give self a name */ strcpy(name, tty->name); - hashbin_insert(irtty, (irda_queue_t *) self, (int) self, NULL); - if (tty->driver->flush_buffer) tty->driver->flush_buffer(tty); @@ -285,8 +268,6 @@ if (self->netdev) unregister_netdev(self->netdev); - self = hashbin_remove(irtty, (int) self, NULL); - /* Protect access to self->task and self->?x_buff - Jean II */ spin_lock_irqsave(&self->lock, flags); diff -Nru a/include/net/irda/irtty.h b/include/net/irda/irtty.h --- a/include/net/irda/irtty.h Fri Aug 15 11:46:11 2003 +++ b/include/net/irda/irtty.h Fri Aug 15 11:46:11 2003 @@ -31,7 +31,6 @@ #include #include -#include #include /* Used by ioctl */ @@ -45,7 +44,6 @@ #define IRTTY_IOC_MAXNR 2 struct irtty_cb { - irda_queue_t q; /* Must be first */ magic_t magic; struct net_device *netdev; /* Yes! we are some kind of netdevice */ From shemminger@osdl.org Fri Aug 15 15:51:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Aug 2003 15:51:30 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FMpQFl011335 for ; Fri, 15 Aug 2003 15:51:26 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7FMp8o09711; Fri, 15 Aug 2003 15:51:08 -0700 Date: Fri, 15 Aug 2003 15:50:59 -0700 From: Stephen Hemminger To: Jean Tourrilhes Cc: irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] (2/5) Fix irtty line disc and module semantics Message-Id: <20030815155059.44039644.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4867 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev The irda tty line discipline does not handle the new module paradigm well. This patch fixes that: - initialize line discipline as data, not with code - set module owner - make prototype for irtty_ioctl match expected arguments from tty discipline - get rid of explicit MOD_INC/MOD_DEC Patch against 2.6.0-test3 latest Include removal of driver_name which is a global defined but never used! diff -Nru a/drivers/net/irda/irtty.c b/drivers/net/irda/irtty.c --- a/drivers/net/irda/irtty.c Fri Aug 15 11:45:06 2003 +++ b/drivers/net/irda/irtty.c Fri Aug 15 11:45:06 2003 @@ -39,8 +39,6 @@ #include #include -static struct tty_ldisc irda_ldisc; - static int qos_mtt_bits = 0x03; /* 5 ms or more */ /* Network device fuction prototypes */ @@ -54,7 +52,8 @@ /* Line discipline function prototypes */ static int irtty_open(struct tty_struct *tty); static void irtty_close(struct tty_struct *tty); -static int irtty_ioctl(struct tty_struct *, void *, int, void *); +static int irtty_ioctl(struct tty_struct *, struct file *, + unsigned int, unsigned long); static int irtty_receive_room(struct tty_struct *tty); static void irtty_write_wakeup(struct tty_struct *tty); static void irtty_receive_buf(struct tty_struct *, const unsigned char *, @@ -68,29 +67,22 @@ static int irtty_set_mode(struct net_device *dev, int mode); static int irtty_change_speed(struct irda_task *task); -char *driver_name = "irtty"; +static struct tty_ldisc irda_ldisc = { + .owner = THIS_MODULE, + .magic = TTY_LDISC_MAGIC, + .name = "irda", + .open = irtty_open, + .close = irtty_close, + .ioctl = irtty_ioctl, + .receive_buf = irtty_receive_buf, + .receive_room = irtty_receive_room, + .write_wakeup = irtty_write_wakeup, +}; int __init irtty_init(void) { int status; - /* Fill in our line protocol discipline, and register it */ - memset(&irda_ldisc, 0, sizeof( irda_ldisc)); - - irda_ldisc.magic = TTY_LDISC_MAGIC; - irda_ldisc.name = "irda"; - irda_ldisc.flags = 0; - irda_ldisc.open = irtty_open; - irda_ldisc.close = irtty_close; - irda_ldisc.read = NULL; - irda_ldisc.write = NULL; - irda_ldisc.ioctl = (int (*)(struct tty_struct *, struct file *, - unsigned int, unsigned long)) irtty_ioctl; - irda_ldisc.poll = NULL; - irda_ldisc.receive_buf = irtty_receive_buf; - irda_ldisc.receive_room = irtty_receive_room; - irda_ldisc.write_wakeup = irtty_write_wakeup; - if ((status = tty_register_ldisc(N_IRDA, &irda_ldisc)) != 0) { ERROR("IrDA: can't register line discipline (err = %d)\n", status); @@ -234,8 +226,6 @@ MESSAGE("IrDA: Registered device %s\n", dev->name); - MOD_INC_USE_COUNT; - return 0; } @@ -286,8 +276,6 @@ spin_unlock_irqrestore(&self->lock, flags); kfree(self); - - MOD_DEC_USE_COUNT; } /* @@ -468,7 +456,8 @@ * The Swiss army knife of system calls :-) * */ -static int irtty_ioctl(struct tty_struct *tty, void *file, int cmd, void *arg) +static int irtty_ioctl(struct tty_struct *tty, struct file *file, + unsigned int cmd, unsigned long arg) { dongle_t *dongle; struct irtty_info info; @@ -492,8 +481,7 @@ case TCGETS: case TCGETA: /* Unsure about locking here, to check - Jean II */ - return n_tty_ioctl(tty, (struct file *) file, cmd, - (unsigned long) arg); + return n_tty_ioctl(tty, (struct file *) file, cmd, arg); break; case IRTTY_IOCTDONGLE: /* Initialize dongle */ @@ -524,7 +512,7 @@ memset(&info, 0, sizeof(struct irtty_info)); strncpy(info.name, self->netdev->name, 5); - if (copy_to_user(arg, &info, sizeof(struct irtty_info))) + if (copy_to_user((void *) arg, &info, sizeof(struct irtty_info))) return -EFAULT; break; default: @@ -941,8 +929,6 @@ */ self->irlap = irlap_open(dev, &self->qos, hwname); - MOD_INC_USE_COUNT; - return 0; } @@ -963,8 +949,6 @@ if (self->irlap) irlap_close(self->irlap); self->irlap = NULL; - - MOD_DEC_USE_COUNT; return 0; } From shemminger@osdl.org Fri Aug 15 15:53:21 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Aug 2003 15:53:24 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FMrLFl011673 for ; Fri, 15 Aug 2003 15:53:21 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7FMr4o09892; Fri, 15 Aug 2003 15:53:04 -0700 Date: Fri, 15 Aug 2003 15:52:54 -0700 From: Stephen Hemminger To: Jean Tourrilhes Cc: irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] (3/5) irda_device_setup should match ether_setup Message-Id: <20030815155254.5580d60a.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4868 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev irda_device_setup signature should match ether_setup so it can be used with alloc_netdev. No caller was checking the return value anyway. diff -Nru a/include/net/irda/irda_device.h b/include/net/irda/irda_device.h --- a/include/net/irda/irda_device.h Fri Aug 15 13:07:28 2003 +++ b/include/net/irda/irda_device.h Fri Aug 15 13:07:28 2003 @@ -222,7 +222,7 @@ int irda_device_set_raw_mode(struct net_device* self, int status); int irda_device_set_dtr_rts(struct net_device *dev, int dtr, int rts); int irda_device_change_speed(struct net_device *dev, __u32 speed); -int irda_device_setup(struct net_device *dev); +void irda_device_setup(struct net_device *dev); /* Dongle interface */ void irda_device_unregister_dongle(struct dongle_reg *dongle); diff -Nru a/net/irda/irda_device.c b/net/irda/irda_device.c --- a/net/irda/irda_device.c Fri Aug 15 13:07:28 2003 +++ b/net/irda/irda_device.c Fri Aug 15 13:07:28 2003 @@ -383,10 +383,8 @@ * This function should be used by low level device drivers in a similar way * as ether_setup() is used by normal network device drivers */ -int irda_device_setup(struct net_device *dev) +void irda_device_setup(struct net_device *dev) { - ASSERT(dev != NULL, return -1;); - dev->hard_header_len = 0; dev->addr_len = 0; @@ -399,7 +397,6 @@ dev->mtu = 2048; dev->flags = IFF_NOARP; - return 0; } /* From shemminger@osdl.org Fri Aug 15 15:56:23 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Aug 2003 15:56:25 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FMuMFl012018 for ; Fri, 15 Aug 2003 15:56:22 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7FMu3o10430; Fri, 15 Aug 2003 15:56:03 -0700 Date: Fri, 15 Aug 2003 15:55:53 -0700 From: Stephen Hemminger To: Jean Tourrilhes Cc: irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] (4/5) irlap_open should take const string Message-Id: <20030815155553.2f1b8735.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4869 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev irlap_open should take a constant string because it copies its argument. Therefore, irtty_net_open doesn't have to make a copy! diff -Nru a/drivers/net/irda/irtty.c b/drivers/net/irda/irtty.c --- a/drivers/net/irda/irtty.c Fri Aug 15 13:16:43 2003 +++ b/drivers/net/irda/irtty.c Fri Aug 15 13:16:43 2003 @@ -907,7 +907,6 @@ { struct irtty_cb *self = (struct irtty_cb *) dev->priv; struct tty_struct *tty = self->tty; - char hwname[16]; ASSERT(self != NULL, return -1;); ASSERT(self->magic == IRTTY_MAGIC, return -1;); @@ -920,14 +919,11 @@ /* Make sure we can receive more data */ irtty_stop_receiver(self, FALSE); - /* Give self a hardware name */ - sprintf(hwname, "%s", tty->name); - /* * Open new IrLAP layer instance, now that everything should be * initialized properly */ - self->irlap = irlap_open(dev, &self->qos, hwname); + self->irlap = irlap_open(dev, &self->qos, tty->name); return 0; } diff -Nru a/include/net/irda/irda_device.h b/include/net/irda/irda_device.h --- a/include/net/irda/irda_device.h Fri Aug 15 13:16:43 2003 +++ b/include/net/irda/irda_device.h Fri Aug 15 13:16:43 2003 @@ -209,7 +209,7 @@ * We declare them here to avoid the driver pulling a whole bunch stack * headers they don't really need - Jean II */ struct irlap_cb *irlap_open(struct net_device *dev, struct qos_info *qos, - char * hw_name); + const char *hw_name); void irlap_close(struct irlap_cb *self); /* Interface to be uses by IrLAP */ diff -Nru a/include/net/irda/irlap.h b/include/net/irda/irlap.h --- a/include/net/irda/irlap.h Fri Aug 15 13:16:43 2003 +++ b/include/net/irda/irlap.h Fri Aug 15 13:16:43 2003 @@ -217,7 +217,7 @@ void irlap_cleanup(void); struct irlap_cb *irlap_open(struct net_device *dev, struct qos_info *qos, - char * hw_name); + const char *hw_name); void irlap_close(struct irlap_cb *self); void irlap_connect_request(struct irlap_cb *self, __u32 daddr, diff -Nru a/net/irda/irlap.c b/net/irda/irlap.c --- a/net/irda/irlap.c Fri Aug 15 13:16:43 2003 +++ b/net/irda/irlap.c Fri Aug 15 13:16:43 2003 @@ -110,7 +110,7 @@ * */ struct irlap_cb *irlap_open(struct net_device *dev, struct qos_info *qos, - char * hw_name) + const char *hw_name) { struct irlap_cb *self; From shemminger@osdl.org Fri Aug 15 15:58:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Aug 2003 15:58:02 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FMvxFl012352 for ; Fri, 15 Aug 2003 15:58:00 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7FMvdo10801; Fri, 15 Aug 2003 15:57:39 -0700 Date: Fri, 15 Aug 2003 15:57:29 -0700 From: Stephen Hemminger To: Jean Tourrilhes Cc: irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] (5/5) irlap hashbin can be private Message-Id: <20030815155729.06632ade.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4870 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev irlap hashbin is only used in one file, so make it private not global. diff -Nru a/include/net/irda/irlap.h b/include/net/irda/irlap.h --- a/include/net/irda/irlap.h Fri Aug 15 13:52:21 2003 +++ b/include/net/irda/irlap.h Fri Aug 15 13:52:21 2003 @@ -208,8 +208,6 @@ int next_bofs; /* Negotiated extra BOFs after next frame */ }; -extern hashbin_t *irlap; - /* * Function prototypes */ diff -Nru a/net/irda/irlap.c b/net/irda/irlap.c --- a/net/irda/irlap.c Fri Aug 15 13:52:21 2003 +++ b/net/irda/irlap.c Fri Aug 15 13:52:21 2003 @@ -48,7 +48,7 @@ #include #include -hashbin_t *irlap = NULL; +static hashbin_t *irlap = NULL; int sysctl_slot_timeout = SLOT_TIMEOUT * 1000 / HZ; /* This is the delay of missed pf period before generating an event From jt@bougret.hpl.hp.com Fri Aug 15 16:05:55 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 15 Aug 2003 16:06:02 -0700 (PDT) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7FN5sFl012806 for ; Fri, 15 Aug 2003 16:05:55 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel13.hp.com (Postfix) with ESMTP id 551761C018AD; Fri, 15 Aug 2003 16:05:54 -0700 (PDT) Received: from bougret.hpl.hp.com (mail@bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_26305)/8.9.3 HPLabs Timeshare Server) with ESMTP id QAA10857; Fri, 15 Aug 2003 16:05:46 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 19nndi-0008IG-00; Fri, 15 Aug 2003 16:05:46 -0700 Date: Fri, 15 Aug 2003 16:05:46 -0700 To: Stephen Hemminger Cc: irda-users@lists.sourceforge.net, netdev@oss.sgi.com, Martin Diehl Subject: Re: [PATCH] (1/5) get rid of useless hashbin in irtty Message-ID: <20030815230546.GA31831@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20030815154608.56cf0551.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030815154608.56cf0551.shemminger@osdl.org> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 4871 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev On Fri, Aug 15, 2003 at 03:46:08PM -0700, Stephen Hemminger wrote: > > Working on converting IRDA to new netdevice semantics, I hope you realised that this is most likely 2.7.X material. There is not enough IrDA testing happening in 2.6.X to make sure that this could work properly in the short time we have before 2.6.0. It usually take 3 months to get feedback on the 2.4.X changes. Driver still have not caught up with the core changes in 2.6.X, so I don't feel like introducing more core changes that would destabilise everything. I don't want to discourage you, because I know that this needs to happen. Also, you may want to contact Martin Diehl, which is taking care of irtty-sir and dongle drivers, so might have a more accurate perpective on the problem and help on that. I'm not saying "No", I just want some way to reduce the risk level. Having Martin involved is one good way. > this is the first > of some of the small things I found. > > The irtty hashbin is created, maintained and never used. irtty is broken in 2.6.X, and the only thing that should happen to it is complete removal. > Motivation for removing is that the hashbin locking has problems with > the locking assumptions in on network device removal. Please explain that, if there is a bug in hashbin, it need fixing. I personally took care of making sure that hashbin locking is sensible, so I have to assume that there is something wrong with network device removal. Also note that the hashbin was created with NO_LOCK, so hashbin locking can't be a problem ;-) Have fun... Jean From davem@redhat.com Sat Aug 16 05:28:30 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 16 Aug 2003 05:28:39 -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 h7GCSTFl023258 for ; Sat, 16 Aug 2003 05:28:30 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id FAA25896; Sat, 16 Aug 2003 05:20:48 -0700 Date: Sat, 16 Aug 2003 05:20:48 -0700 From: "David S. Miller" To: jt@hpl.hp.com Cc: jt@bougret.hpl.hp.com, shemminger@osdl.org, irda-users@lists.sourceforge.net, netdev@oss.sgi.com, lists@mdiehl.de Subject: Re: [PATCH] (1/5) get rid of useless hashbin in irtty Message-Id: <20030816052048.5858d68a.davem@redhat.com> In-Reply-To: <20030815230546.GA31831@bougret.hpl.hp.com> References: <20030815154608.56cf0551.shemminger@osdl.org> <20030815230546.GA31831@bougret.hpl.hp.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4872 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 15 Aug 2003 16:05:46 -0700 Jean Tourrilhes wrote: > On Fri, Aug 15, 2003 at 03:46:08PM -0700, Stephen Hemminger wrote: > > > > Working on converting IRDA to new netdevice semantics, > > I hope you realised that this is most likely 2.7.X > material. Without moving to the new netdevice semantics, you're drivers will be broken. This isn't a happy cleanup change, it is necessary. From davem@redhat.com Sat Aug 16 07:44:42 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 16 Aug 2003 07:44:48 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7GEigFl025272 for ; Sat, 16 Aug 2003 07:44:42 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id HAA26224; Sat, 16 Aug 2003 07:38:05 -0700 Date: Sat, 16 Aug 2003 07:38:04 -0700 From: "David S. Miller" To: Jeff Garzik Cc: shemminger@osdl.org, mikep@linuxtr.net, linux-tr@linuxtr.net, netdev@oss.sgi.com Subject: Re: [PATCH] ibmtr - get rid of MOD_INC/DEC Message-Id: <20030816073804.2464c5e2.davem@redhat.com> In-Reply-To: <3F3CE05D.5080306@pobox.com> References: <20030813174658.2c5125af.shemminger@osdl.org> <20030814205747.5fcd83d0.davem@redhat.com> <3F3CE05D.5080306@pobox.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4873 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 15 Aug 2003 09:30:05 -0400 Jeff Garzik wrote: > David S. Miller wrote: > > Can't we lose the MODULE ifdefs too? > > Doubtful for ibmtr, which requires some of them for ibmtr_cs (which > #includes it). Indeed. Patch applied, thanks Stephen. From davem@redhat.com Sat Aug 16 07:46:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 16 Aug 2003 07:46: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 h7GEkeFl025601 for ; Sat, 16 Aug 2003 07:46:40 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id HAA26264; Sat, 16 Aug 2003 07:40:15 -0700 Date: Sat, 16 Aug 2003 07:40:14 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: da-x@gmx.net, netdev@oss.sgi.com, mhuth@mvista.com Subject: Re: [PATCH] network device renaming sysfs fix Message-Id: <20030816074014.46b228f5.davem@redhat.com> In-Reply-To: <20030815093724.519779e6.shemminger@osdl.org> References: <20030815111514.GA5228@callisto.yi.org> <20030815093724.519779e6.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4874 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 15 Aug 2003 09:37:24 -0700 Stephen Hemminger wrote: > The class_dev kobject name is 20 chars and IFNAMSIZ is 16, so the solution > needs to truncate if new_name is not null terminated (all 16 chars long). > > This seems like the best approach: Patch applied, thanks everyone. Can't the device name also change via netlink messages? If so, do we handle that case properly? From davem@redhat.com Sat Aug 16 07:54:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 16 Aug 2003 07:54:43 -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 h7GEsYFl026027 for ; Sat, 16 Aug 2003 07:54:35 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id HAA26328; Sat, 16 Aug 2003 07:48:09 -0700 Date: Sat, 16 Aug 2003 07:48:09 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [PATCH] set owner on /proc/net/rt6_stats Message-Id: <20030816074809.629c20da.davem@redhat.com> In-Reply-To: <20030815110107.3ea9b4dc.shemminger@osdl.org> References: <20030815110107.3ea9b4dc.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4875 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 15 Aug 2003 11:01:07 -0700 Stephen Hemminger wrote: > Fix up initialization of IPV6 /proc/net/rt6_stats entries so owner field is set. > Use proc_net_fops_create helper instead of proc_net_create and fops assignment. Patch applied, thanks Stephen. From davem@redhat.com Sat Aug 16 07:55:39 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 16 Aug 2003 07:55: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 h7GEtdFl026350 for ; Sat, 16 Aug 2003 07:55:39 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id HAA26354; Sat, 16 Aug 2003 07:49:15 -0700 Date: Sat, 16 Aug 2003 07:49:14 -0700 From: "David S. Miller" To: "YOSHIFUJI Hideaki / _$B5HF#1QL@" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] SCTP: typo in Kconfig Message-Id: <20030816074914.4b86734f.davem@redhat.com> In-Reply-To: <20030816.053332.108341697.yoshfuji@linux-ipv6.org> References: <20030816.053332.108341697.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4876 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sat, 16 Aug 2003 05:33:32 +0900 (JST) YOSHIFUJI Hideaki / _$B5HF#1QL@ wrote: > This patch fixes typo in net/sctp/Kconfig. Patch applied, thank you. From davem@redhat.com Sat Aug 16 07:57:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 16 Aug 2003 07:57:20 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7GEvCFl026675 for ; Sat, 16 Aug 2003 07:57:13 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id HAA26392; Sat, 16 Aug 2003 07:50:46 -0700 Date: Sat, 16 Aug 2003 07:50:46 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [PATCH] fix build problem with IPV6 Message-Id: <20030816075046.752e58cc.davem@redhat.com> In-Reply-To: <20030815140740.388a79c4.shemminger@osdl.org> References: <20030815140740.388a79c4.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4877 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 15 Aug 2003 14:07:40 -0700 Stephen Hemminger wrote: > IPV6 won't build in current 2.6.0-test3 tree unless CONFIG_XFRM is defined > because of reference to xfrm6_fini. Applied, thanks Stephen. > The linux way to fix this would be to make the functions > stub's in the include file, but that isn't how IPV6 does it now > for other xfrm functions. If someone wants to clean house in this area, I'll happily take patches doing that. :) From davem@redhat.com Sat Aug 16 08:04:58 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 16 Aug 2003 08:05:00 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7GF4vFl027100 for ; Sat, 16 Aug 2003 08:04:57 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id HAA26468; Sat, 16 Aug 2003 07:58:34 -0700 Date: Sat, 16 Aug 2003 07:58:34 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] (4/4) add wireless statistics to sysfs Message-Id: <20030816075834.39f66e4b.davem@redhat.com> In-Reply-To: <20030815153804.58e7edc0.shemminger@osdl.org> References: <20030815153804.58e7edc0.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4878 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 All four patches applied. In particular I'm very happy with the attribute groups and subsequent cleanups. Thanks Stephen. From davem@redhat.com Sat Aug 16 08:16:32 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 16 Aug 2003 08:16:38 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7GFGWFl032024 for ; Sat, 16 Aug 2003 08:16:32 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id IAA26591; Sat, 16 Aug 2003 08:09:56 -0700 Date: Sat, 16 Aug 2003 08:09:55 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: jt@hpl.hp.com, irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] (5/5) irlap hashbin can be private Message-Id: <20030816080955.5c02c045.davem@redhat.com> In-Reply-To: <20030815155729.06632ade.shemminger@osdl.org> References: <20030815155729.06632ade.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4879 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 All 5 patches applied, thanks a lot Stephen. From szukw000@students.uni-mainz.de Sat Aug 16 17:11:09 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 16 Aug 2003 17:11:13 -0700 (PDT) Received: from mailgate2.zdv.Uni-Mainz.DE (mailgate2.zdv.Uni-Mainz.DE [134.93.8.57]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7H0B7Fl007588 for ; Sat, 16 Aug 2003 17:11:09 -0700 Received: from mail.students.Uni-Mainz.DE (mailserver1.zdv.Uni-Mainz.DE [134.93.8.30]) by mailgate2.zdv.Uni-Mainz.DE (8.12.9/8.12.8) with ESMTP id h7H0B5Na015203 for ; Sun, 17 Aug 2003 02:11:05 +0200 (MEST) Received: from keun.at.localdomain (dialin74.zdv.Uni-Mainz.DE [134.93.174.74]) by mail.students.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id CAA11149 for ; Sun, 17 Aug 2003 02:11:04 +0200 (MEST) Received: by keun.at.localdomain (Postfix, from userid 0) id 6E6227C73E; Sun, 17 Aug 2003 02:09:25 +0000 (UTC) Date: Sun, 17 Aug 2003 02:09:25 GMT From: "w.szukalski" Subject: linux-2.4.21 and IPv6 To: Message-ID: <20030817020925.A875@keun> Mime-Version: 1.0 X-Mailer: mMosaic-3.8.17-pre5 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7H0B7Fl007588 X-archive-position: 4880 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: szukw000@students.uni-mainz.de Precedence: bulk X-list: netdev I have written a small program to test IPv6 multicasting with linux-2.4.21. A LAN connects three linux boxes. I have found, that IPv6 sometimes fails. With IPv6 group 'ff02::1': struct sockaddr_in6 read6, write6; struct ipv6_mreq mreq6; inet_pton(AF_INET6, group, &mreq6.ipv6mr_multiaddr); read6.sin6_family = AF_INET6; read6.sin6_port = htons(readport); read6.sin6_flowinfo = 0; read6.sin6_scope_id = 0; // ALTERNATIVE 1: memset(&read6.sin6_addr, 0, sizeof(struct in6_addr)); // ALTERNATIVE 2: inet_pton(AF_INET6, host, &read6.sin6_addr); // ALTERNATIVE 3: read6.sin6_addr = mreq6.ipv6mr_multiaddr; bind(reader, (struct sockaddr *)&read6, sizeof(read6) ); bind() fails for alternative 3 with 'Invalid argument'. connect(writer, (struct sockaddr*)&write6, sizeof(struct sockaddr_in6)); connect() always fails with 'Invalid argument'. With IPv4 group '224.0.0.1': struct sockaddr_in read4, write4; struct ip_mreq mreq4; inet_pton(AF_INET, group, &mreq4.imr_multiaddr); read4.sin_family = AF_INET; read4.sin_port = htons(readport); // ALTERNATIVE 1: read4.sin_addr.s_addr = 0; // ALTERNATIVE 2: inet_pton(AF_INET, host, &read4.sin_addr); // ALTERNATIVE 3: read4.sin_addr = mreq4.imr_multiaddr; bind(reader, (struct sockaddr *)&read4, sizeof(read4) ); bind() never fails. connect(writer, (struct sockaddr*)&write4, sizeof(struct sockaddr_in)); connect() never fails. Why does IPv6 sometimes fail? winfried From jt@bougret.hpl.hp.com Sat Aug 16 17:14:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 16 Aug 2003 17:14:32 -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 h7H0ERFl007923 for ; Sat, 16 Aug 2003 17:14:28 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel12.hp.com (Postfix) with ESMTP id 5C94A1C020FE; Sat, 16 Aug 2003 17:14:23 -0700 (PDT) Received: from bougret.hpl.hp.com (mail@bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_26305)/8.9.3 HPLabs Timeshare Server) with ESMTP id RAA15982; Sat, 16 Aug 2003 17:14:06 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 19oBBN-0000VE-00; Sat, 16 Aug 2003 17:14:05 -0700 Date: Sat, 16 Aug 2003 17:14:05 -0700 To: "David S. Miller" Cc: shemminger@osdl.org, irda-users@lists.sourceforge.net, netdev@oss.sgi.com, lists@mdiehl.de Subject: Re: [PATCH] (1/5) get rid of useless hashbin in irtty Message-ID: <20030817001405.GA1916@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20030815154608.56cf0551.shemminger@osdl.org> <20030815230546.GA31831@bougret.hpl.hp.com> <20030816052048.5858d68a.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030816052048.5858d68a.davem@redhat.com> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 4881 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev On Sat, Aug 16, 2003 at 05:20:48AM -0700, David S. Miller wrote: > On Fri, 15 Aug 2003 16:05:46 -0700 > Jean Tourrilhes wrote: > > > On Fri, Aug 15, 2003 at 03:46:08PM -0700, Stephen Hemminger wrote: > > > > > > Working on converting IRDA to new netdevice semantics, > > > > I hope you realised that this is most likely 2.7.X > > material. > > Without moving to the new netdevice semantics, you're > drivers will be broken. > > This isn't a happy cleanup change, it is necessary. Curently driver do work properly (including SMP). Does it mean that you plan to have big changes before 2.6.0 is released ? Regards, Jean From mitch@sfgoth.com Sat Aug 16 17:51:12 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 16 Aug 2003 17:51:17 -0700 (PDT) Received: from gaz.sfgoth.com ([63.205.85.133]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7H0pBFl008469 for ; Sat, 16 Aug 2003 17:51:12 -0700 Received: from gaz.sfgoth.com (localhost.sfgoth.com [127.0.0.1]) by gaz.sfgoth.com (8.12.9/8.12.6) with ESMTP id h7H0v6kV085892; Sat, 16 Aug 2003 17:57:06 -0700 (PDT) (envelope-from mitch@gaz.sfgoth.com) Received: (from mitch@localhost) by gaz.sfgoth.com (8.12.9/8.12.6/Submit) id h7H0v6Be085891; Sat, 16 Aug 2003 17:57:06 -0700 (PDT) (envelope-from mitch) Date: Sat, 16 Aug 2003 17:57:06 -0700 From: Mitchell Blank Jr To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] small loopback.c cleanups Message-ID: <20030817005706.GE80721@gaz.sfgoth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 4882 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mitch@sfgoth.com Precedence: bulk X-list: netdev Few trivial cleanups/improvements to drivers/net/loopback.c Seems to work fine for me, although I don't know how to stress all of the code paths. Patch is versus 2.6.0-test3 (should apply to current BK fine) -Mitch --- linux-2.6.0-test3-VIRGIN/drivers/net/loopback.c 2003-07-13 20:30:48.000000000 -0700 +++ linux-2.6.0-test3mnb1/drivers/net/loopback.c 2003-08-16 08:37:29.000000000 -0700 @@ -128,17 +128,13 @@ * instead are lobbed from tx queue to rx queue */ - if(atomic_read(&skb->users) != 1) - { + if (skb_shared(skb)) { struct sk_buff *skb2=skb; skb=skb_clone(skb, GFP_ATOMIC); /* Clone the buffer */ - if(skb==NULL) { - kfree_skb(skb2); + kfree_skb(skb2); + if (unlikely(skb==NULL)) return 0; - } - kfree_skb(skb2); - } - else + } else skb_orphan(skb); skb->protocol=eth_type_trans(skb,dev); @@ -148,12 +144,8 @@ #endif if (skb_shinfo(skb)->tso_size) { - struct iphdr *iph = skb->nh.iph; - - if (skb->protocol != htons(ETH_P_IP)) - BUG(); - if (iph->protocol != IPPROTO_TCP) - BUG(); + BUG_ON(skb->protocol != htons(ETH_P_IP)); + BUG_ON(skb->nh.iph->protocol != IPPROTO_TCP); emulate_large_send_offload(skb); return 0; From davem@redhat.com Sat Aug 16 18:06:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 16 Aug 2003 18:06: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 h7H16WFl008896 for ; Sat, 16 Aug 2003 18:06:33 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id RAA27612; Sat, 16 Aug 2003 17:58:51 -0700 Date: Sat, 16 Aug 2003 17:58:51 -0700 From: "David S. Miller" To: jt@hpl.hp.com Cc: jt@bougret.hpl.hp.com, shemminger@osdl.org, irda-users@lists.sourceforge.net, netdev@oss.sgi.com, lists@mdiehl.de Subject: Re: [PATCH] (1/5) get rid of useless hashbin in irtty Message-Id: <20030816175851.58a2c179.davem@redhat.com> In-Reply-To: <20030817001405.GA1916@bougret.hpl.hp.com> References: <20030815154608.56cf0551.shemminger@osdl.org> <20030815230546.GA31831@bougret.hpl.hp.com> <20030816052048.5858d68a.davem@redhat.com> <20030817001405.GA1916@bougret.hpl.hp.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4883 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sat, 16 Aug 2003 17:14:05 -0700 Jean Tourrilhes wrote: > Curently driver do work properly (including SMP). Users can hold onto procfs files after the driver modules are unloaded. For example: rmmod eth0 ; Sat, 16 Aug 2003 18:11:34 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel13.hp.com (Postfix) with ESMTP id A38771C013C8; Sat, 16 Aug 2003 18:11:33 -0700 (PDT) Received: from bougret.hpl.hp.com (mail@bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_26305)/8.9.3 HPLabs Timeshare Server) with ESMTP id SAA17986; Sat, 16 Aug 2003 18:11:31 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 19oC4x-0000Yk-00; Sat, 16 Aug 2003 18:11:31 -0700 Date: Sat, 16 Aug 2003 18:11:31 -0700 To: "David S. Miller" Cc: shemminger@osdl.org, irda-users@lists.sourceforge.net, netdev@oss.sgi.com, lists@mdiehl.de Subject: Re: [PATCH] (1/5) get rid of useless hashbin in irtty Message-ID: <20030817011131.GA2120@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20030815154608.56cf0551.shemminger@osdl.org> <20030815230546.GA31831@bougret.hpl.hp.com> <20030816052048.5858d68a.davem@redhat.com> <20030817001405.GA1916@bougret.hpl.hp.com> <20030816175851.58a2c179.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030816175851.58a2c179.davem@redhat.com> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 4884 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev On Sat, Aug 16, 2003 at 05:58:51PM -0700, David S. Miller wrote: > On Sat, 16 Aug 2003 17:14:05 -0700 > Jean Tourrilhes wrote: > > > Curently driver do work properly (including SMP). > > Users can hold onto procfs files after the driver > modules are unloaded. For example: > > rmmod eth0 > If IRDA creates any procfs files for devices that are > registered, you have this problem too. > > This is not fixable without first making sure every net driver in the > entire tree abides by a few rules, and that is what Stephen is doing. No problem, it's just that with the total lack of testing of IrDA in 2.6.0, I'm a bit nervous, as always. Would it be possible for Stephen to use some real IrDA hardware so that he can double check what he is doing ? Have fun... Jean From davem@redhat.com Sat Aug 16 18:17:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 16 Aug 2003 18:17:35 -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 h7H1HVFl009597 for ; Sat, 16 Aug 2003 18:17:31 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id SAA27642; Sat, 16 Aug 2003 18:09:47 -0700 Date: Sat, 16 Aug 2003 18:09:46 -0700 From: "David S. Miller" To: jt@hpl.hp.com Cc: jt@bougret.hpl.hp.com, shemminger@osdl.org, irda-users@lists.sourceforge.net, netdev@oss.sgi.com, lists@mdiehl.de Subject: Re: [PATCH] (1/5) get rid of useless hashbin in irtty Message-Id: <20030816180946.228b5909.davem@redhat.com> In-Reply-To: <20030817011131.GA2120@bougret.hpl.hp.com> References: <20030815154608.56cf0551.shemminger@osdl.org> <20030815230546.GA31831@bougret.hpl.hp.com> <20030816052048.5858d68a.davem@redhat.com> <20030817001405.GA1916@bougret.hpl.hp.com> <20030816175851.58a2c179.davem@redhat.com> <20030817011131.GA2120@bougret.hpl.hp.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4885 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sat, 16 Aug 2003 18:11:31 -0700 Jean Tourrilhes wrote: > Would it be possible for Stephen to use some real IrDA hardware so > that he can double check what he is doing ? And alternatively, what? We let known bugs sit in the tree because of IRDA? We've had to edit and hack on lots of obscure ISA ethernet drivers to do this so far that probably nobody has tried to use in years and very few people have access to. Not just trivial changes, we've had to rewrite some of their probe routines in some cases. The work simply must be done. If we add bugs, the first person who tries to use it will find out and report the problem. From jt@bougret.hpl.hp.com Sat Aug 16 18:35:08 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 16 Aug 2003 18:35:11 -0700 (PDT) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7H1YwFl009999 for ; Sat, 16 Aug 2003 18:34:58 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel10.hp.com (Postfix) with ESMTP id 23D6A1C01CB7; Sat, 16 Aug 2003 18:01:19 -0700 (PDT) Received: from bougret.hpl.hp.com (mail@bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_26305)/8.9.3 HPLabs Timeshare Server) with ESMTP id SAA17495; Sat, 16 Aug 2003 18:00:02 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 19oBtq-0000Xa-00; Sat, 16 Aug 2003 18:00:02 -0700 Date: Sat, 16 Aug 2003 18:00:02 -0700 To: "David S. Miller" Cc: Stephen Hemminger , irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] (5/5) irlap hashbin can be private Message-ID: <20030817010002.GC1981@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20030815155729.06632ade.shemminger@osdl.org> <20030816080955.5c02c045.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030816080955.5c02c045.davem@redhat.com> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 4886 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev On Sat, Aug 16, 2003 at 08:09:55AM -0700, David S. Miller wrote: > > All 5 patches applied, thanks a lot Stephen. Thanks for the quick turn around ! By the way, if anybody care about that, I tested the patches with real hardware (except irtty), and it was fine. Have fun... Jean From jt@bougret.hpl.hp.com Sat Aug 16 18:36:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 16 Aug 2003 18:36:29 -0700 (PDT) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7H1aOFl010324 for ; Sat, 16 Aug 2003 18:36:24 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel10.hp.com (Postfix) with ESMTP id 9BEE31C00DB0; Sat, 16 Aug 2003 18:36:24 -0700 (PDT) Received: from bougret.hpl.hp.com (mail@bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_26305)/8.9.3 HPLabs Timeshare Server) with ESMTP id SAA18775; Sat, 16 Aug 2003 18:36:24 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 19oCT2-0000Zw-00; Sat, 16 Aug 2003 18:36:24 -0700 Date: Sat, 16 Aug 2003 18:36:24 -0700 To: "David S. Miller" Cc: shemminger@osdl.org, irda-users@lists.sourceforge.net, netdev@oss.sgi.com, lists@mdiehl.de Subject: Re: [PATCH] (1/5) get rid of useless hashbin in irtty Message-ID: <20030817013624.GB2173@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20030815154608.56cf0551.shemminger@osdl.org> <20030815230546.GA31831@bougret.hpl.hp.com> <20030816052048.5858d68a.davem@redhat.com> <20030817001405.GA1916@bougret.hpl.hp.com> <20030816175851.58a2c179.davem@redhat.com> <20030817011131.GA2120@bougret.hpl.hp.com> <20030816180946.228b5909.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030816180946.228b5909.davem@redhat.com> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 4887 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev On Sat, Aug 16, 2003 at 06:09:46PM -0700, David S. Miller wrote: > On Sat, 16 Aug 2003 18:11:31 -0700 > Jean Tourrilhes wrote: > > > Would it be possible for Stephen to use some real IrDA hardware so > > that he can double check what he is doing ? > > And alternatively, what? We let known bugs sit in the tree > because of IRDA? Wow ! I did not mean to argue and stop the work, if you understood that, I'm sorry for the misunderstanding. I'm just trying to understand the reason for it, how best to proceed, and that's why I took the time to give Stephen some constructive suggestions (as well as my worries). I'm just doing my job, and I don't think I'm unnegociable. > We've had to edit and hack on lots of obscure ISA ethernet drivers to > do this so far that probably nobody has tried to use in years and very > few people have access to. Not just trivial changes, we've had to > rewrite some of their probe routines in some cases. It's fairly easy to get hold of some IrDA hardware, and in the worse case you can use a serial crossover cable to test it. It's not like I'm asking the impossible. > The work simply must be done. After your explanation, I didn't argue with that. But let's do quality work, not a quick job. > If we add bugs, the first person who tries to use it will find out > and report the problem. If the bug report come in one year, nobody will remember the context of the work. It's better to get it right the first time, and that's what I'm trying to acheive. Have fun... Jean From davem@redhat.com Sat Aug 16 22:49:10 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 16 Aug 2003 22:49: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 h7H5n9Fl015856 for ; Sat, 16 Aug 2003 22:49:10 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id WAA27901; Sat, 16 Aug 2003 22:42:40 -0700 Date: Sat, 16 Aug 2003 22:42:40 -0700 From: "David S. Miller" To: Mitchell Blank Jr Cc: netdev@oss.sgi.com Subject: Re: [PATCH] small loopback.c cleanups Message-Id: <20030816224240.2b52956a.davem@redhat.com> In-Reply-To: <20030817005706.GE80721@gaz.sfgoth.com> References: <20030817005706.GE80721@gaz.sfgoth.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4888 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sat, 16 Aug 2003 17:57:06 -0700 Mitchell Blank Jr wrote: > Few trivial cleanups/improvements to drivers/net/loopback.c Seems to work > fine for me, although I don't know how to stress all of the code paths. > > Patch is versus 2.6.0-test3 (should apply to current BK fine) Patch applied, thank you. From da-x@gmx.net Sun Aug 17 00:13:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 00:13:34 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7H7DGFl016712 for ; Sun, 17 Aug 2003 00:13:17 -0700 Received: (qmail 16452 invoked by uid 65534); 17 Aug 2003 07:13:09 -0000 Received: from DSL212-235-93-224.bb.netvision.net.il (HELO callisto.yi.org) (212.235.93.224) by mail.gmx.net (mp022) with SMTP; 17 Aug 2003 09:13:09 +0200 Date: Sun, 17 Aug 2003 10:13:07 +0300 From: Dan Aloni To: "David S. Miller" Cc: Stephen Hemminger , netdev@oss.sgi.com, mhuth@mvista.com Subject: Re: [PATCH] network device renaming sysfs fix Message-ID: <20030817071307.GA11408@callisto.yi.org> References: <20030815111514.GA5228@callisto.yi.org> <20030815093724.519779e6.shemminger@osdl.org> <20030816074014.46b228f5.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030816074014.46b228f5.davem@redhat.com> User-Agent: Mutt/1.5.4i X-archive-position: 4889 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: da-x@gmx.net Precedence: bulk X-list: netdev On Sat, Aug 16, 2003 at 07:40:14AM -0700, David S. Miller wrote: > On Fri, 15 Aug 2003 09:37:24 -0700 > Stephen Hemminger wrote: > > > The class_dev kobject name is 20 chars and IFNAMSIZ is 16, so the solution > > needs to truncate if new_name is not null terminated (all 16 chars long). > > > > This seems like the best approach: > > Patch applied, thanks everyone. > > Can't the device name also change via netlink messages? > If so, do we handle that case properly? No it can't, AFAIK. You might be confusing between netlink and notifier calls (which allow ipv4 to update the names of aliases when the device name changes). BTW, it is possible to add notifier handling for fixing device naming discrepancies regarding family-level sysctl registration. I think this is how the sysctl issue should be fixed. -- Dan Aloni da-x@gmx.net From pb@bieringer.de Sun Aug 17 05:04:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 05:04:05 -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 h7HC3tFl004112 for ; Sun, 17 Aug 2003 05:03:58 -0700 Received: by smtp2.aerasec.de (Postfix, from userid 995) id A31E1137E6; Sun, 17 Aug 2003 14:03:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by smtp2.aerasec.de (Postfix) with SMTP id B8CA7137E8 for ; Sun, 17 Aug 2003 14:03:45 +0200 (CEST) X-AV-Checked: Sun Aug 17 14:03:45 2003 smtp2.aerasec.de Received: from [192.168.1.2] (pD950F55C.dip.t-dialin.net [217.80.245.92]) (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 E5816137E6 for ; Sun, 17 Aug 2003 14:03:43 +0200 (CEST) Date: Sun, 17 Aug 2003 14:03:38 +0200 From: Peter Bieringer To: Maillist netdev Subject: Hardcoding instead of using MAX_UNITS in 3c590.c driver Message-ID: <45450000.1061121818@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: 4890 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, during looking for some "how-would-this-be-done" code, I wonder that driver 3c590.c doesn't always use MAX_UNITS. In difference, ne2.c does. Perhaps fix below would helps. Possible, that such inconsistency also exists in other drivers, too: # diff -u 3c59x.c.orig 3c59x.c --- 3c59x.c.orig Sun Aug 17 13:57:29 2003 +++ 3c59x.c Sun Aug 17 13:58:45 2003 @@ -269,12 +269,13 @@ DRV_VERSION " " DRV_RELDATE); MODULE_LICENSE("GPL"); +#define MAX_UNITS 8 MODULE_PARM(debug, "i"); -MODULE_PARM(options, "1-" __MODULE_STRING(8) "i"); -MODULE_PARM(full_duplex, "1-" __MODULE_STRING(8) "i"); -MODULE_PARM(hw_checksums, "1-" __MODULE_STRING(8) "i"); -MODULE_PARM(flow_ctrl, "1-" __MODULE_STRING(8) "i"); -MODULE_PARM(enable_wol, "1-" __MODULE_STRING(8) "i"); +MODULE_PARM(options, "1-" __MODULE_STRING(MAX_UNITS) "i"); +MODULE_PARM(full_duplex, "1-" __MODULE_STRING(MAX_UNITS) "i"); +MODULE_PARM(hw_checksums, "1-" __MODULE_STRING(MAX_UNITS) "i"); +MODULE_PARM(flow_ctrl, "1-" __MODULE_STRING(MAX_UNITS) "i"); +MODULE_PARM(enable_wol, "1-" __MODULE_STRING(MAX_UNITS) "i"); MODULE_PARM(rx_copybreak, "i"); MODULE_PARM(max_interrupt_work, "i"); MODULE_PARM(compaq_ioaddr, "i"); @@ -847,7 +848,6 @@ /* This driver uses 'options' to pass the media type, full-duplex flag, etc. */ /* Option count limit only -- unlimited interfaces are supported. */ -#define MAX_UNITS 8 static int options[MAX_UNITS] = { -1, -1, -1, -1, -1, -1, -1, -1,}; static int full_duplex[MAX_UNITS] = {-1, -1, -1, -1, -1, -1, -1, -1}; static int hw_checksums[MAX_UNITS] = {-1, -1, -1, -1, -1, -1, -1, -1}; BTW: - static int options[MAX_UNITS] = { -1, -1, -1, -1, -1, -1, -1, -1,}; + static int options[MAX_UNITS] = { -1, -1, -1, -1, -1, -1, -1, -1}; 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 carlosev@newipnet.com Sun Aug 17 06:13:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 06:13:38 -0700 (PDT) Received: from smtp.newipnet.com (5.Red-80-32-157.pooles.rima-tde.net [80.32.157.5]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7HDDNFl004793 for ; Sun, 17 Aug 2003 06:13:25 -0700 Received: by smtp.newipnet.com (ESMTP Server, from userid 511) id 05A002082A; Sun, 17 Aug 2003 15:13:19 +0200 (CEST) Received: from madre (madre.newipnet.com [192.168.128.4]) by smtp.newipnet.com (ESMTP Server) with ESMTP id 92F7F207E5; Sun, 17 Aug 2003 15:13:10 +0200 (CEST) Message-ID: <200308171509570955.003E4FEC@192.168.128.16> In-Reply-To: <20030728213933.F81299@coredump.scriptkiddie.org> References: <20030728213933.F81299@coredump.scriptkiddie.org> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Sun, 17 Aug 2003 15:09:57 +0200 From: "Carlos Velasco" To: "Lamont Granquist" , "Bill Davidsen" Cc: "David S. Miller" , bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Content-Type: text/plain; charset="us-ascii" X-archive-position: 4891 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: carlosev@newipnet.com Precedence: bulk X-list: netdev I have received reply from Cisco: *********** BEGIN FORWARDED MESSAGE *********** On 06/08/2003 at 11:40 Oscar Madrid wrote: > >My name is Oscar Madrid and I'm Luis Isselin's escalation engineer. I've >decided to answer to this case straight as this is a question of whether >or not Cisco is following a standard. > >I can only think of one scenario where an arp request would come in from >192.168.140.x to a router interface that has 192.168.128.1. That one >scenario is a misconfiguration. >ARP is designed to find the next hop on a LAN. If the host has an IP >address of 192.168.140.140 and wants to get to 192.168.128.1, it will have >to have a default gateway configured. >This default gateway would have to be on the same logical local network. > >Now, lets say that the host has an IP address of 192.168.140.140/17 which >will include both 192.168.128.x and 192.168.140.x. This would still be a >misconfig as the router is not on the same subnet. (meaning the router >does not have the same /17 mask. The host can see the router, but the >router cannot see the host). > >You could, in theory, say that we're not following "similar algorithm" in >the RFC as we check the source, but this is more for a sanity check as if >it was a perfect world and everything is configured properly and there >were no such things as bad implementations of TCP/IP stacks, then we >wouldn't need to check. > >If the router for some reason was responding to the ARP broadcast, how >would anyone know where the packet came from since the network is not >being advertised as connected to this router? Meaning, how would a return >packet make it back to the host? The router doesn't "see" the host in his >logical network therefore it cannot communicate with it. > >I believe that reason we do the sanity check is because of basic IP >routing. If the source is not from an IP address on the interface we >received it on, we cannot reply to that IP address. It is simple as that. >As I stated, ARP is designed to be used on a LAN. This means that all >stations that send/receive ARP packets are on the same subnet. This is >the reason we do the check. > >Please also note another portion of the RFC 0826 in question: > >[The purpose of this RFC is to present a method of Converting >Protocol Addresses (e.g., IP addresses) to Local Network >Addresses (e.g., Ethernet addresses). This is a issue of general >concern in the ARPA Internet community at this time. The >method proposed here is presented for your consideration and >comment. This is not the specification of a Internet Standard.] > >When it is talking about Local Network Addresses, that means IP addresses >on the same network. This is why we can perform the checks we perform in >our IOS. > >The point of the check would be to verify that the hosts are configured >correctly. There is no case where a properly configured host should ever >send a ARP request for an IP address on a different subnet. > >The best example I can point out is this: >Ethernet is a Broadcast network which uses ARP to find HW addresses of >other IP addresses on the same broadcast network. If the IP address is >not on the same network, then the host/router/client needs to find the >gateway which is on the local network. > >Basic and proper implementations of the TCP/IP stack should never ARP out >for a device that it is not located on the same logical network the host >is, the reason for this being they cannot communicate directly unless a >gateway is involved. The only ARP request a host should send in this case >is for its gateway that should also be a "local" device to the host (same >network). > >I hope this clears up the reson why Cisco's ARP implementation has this >safeguard you have found along with several others, HOWEVER, please refer >to RFC 1027, (http://www.ietf.org/rfc/rfc1027.txt) and under section 2.4, >it contains the following paragraph: > >[If the IP networks of the source and target hosts of an ARP request >are different, an ARP subnet gateway implementation should not >reply. This is to prevent the ARP subnet gateway from being used to >reach foreign IP networks and thus possibly bypass security checks >provided by IP gateways. ] > >I would also ask you if you would be so kind to send me the link to the >netdev list of linux kernel you are making mention to so I can escalate it >and respond to the linux community if higher up is deemed up necesary. > >Best Regards, > > > >Oscar Madrid >Customer Support Engineer >Routing Protocols Team >Cisco Systems >omadrid@cisco.com > > >Open a TAC case on the web for faster response! www.cisco.com/tac/caseopen >Visit the TAC Web Site for quick access to technical support! >www.cisco.com/tac >Use the new TAC Advanced Search to find information fast! >www.cisco.com/tac/advancedsearch > > *********** END FORWARDED MESSAGE *********** From carlosev@newipnet.com Sun Aug 17 06:21:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 06:21:38 -0700 (PDT) Received: from smtp.newipnet.com (5.Red-80-32-157.pooles.rima-tde.net [80.32.157.5]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7HDLWFl005641 for ; Sun, 17 Aug 2003 06:21:33 -0700 Received: by smtp.newipnet.com (ESMTP Server, from userid 511) id B0C7A2082A; Sun, 17 Aug 2003 15:21:30 +0200 (CEST) Received: from madre (madre.newipnet.com [192.168.128.4]) by smtp.newipnet.com (ESMTP Server) with ESMTP id EF0BC207E5; Sun, 17 Aug 2003 15:21:21 +0200 (CEST) Message-ID: <200308171516090038.0043F977@192.168.128.16> In-Reply-To: <200308171509570955.003E4FEC@192.168.128.16> References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Sun, 17 Aug 2003 15:16:09 +0200 From: "Carlos Velasco" To: "Carlos Velasco" , "Lamont Granquist" , "Bill Davidsen" Cc: "David S. Miller" , bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Content-Type: text/plain; charset="us-ascii" X-archive-position: 4892 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: carlosev@newipnet.com Precedence: bulk X-list: netdev So, According to RFC 1027: http://www.ietf.org/rfc/rfc1027.txt === 2.4 Sanity checks If the IP networks of the source and target hosts of an ARP request are different, an ARP subnet gateway implementation should not reply. This is to prevent the ARP subnet gateway from being used to reach foreign IP networks and thus possibly bypass security checks provided by IP gateways. === According to RFC 985: http://www.ietf.org/rfc/rfc0985.txt?number=985 === A.3. ARP datagram An ARP reply is discarded if the destination IP address does not match the local host address. An ARP request is discarded if the source IP address is not in the same subnet. It is desirable that this test be overridden by a configuration parameter, in order to support the infrequent cases where more than one subnet may coexist on the same cable (see RFC-925 for examples). An ARP reply is generated only if the destination protocol IP address is reachable from the local host (as determined by the routing algorithm) and the next hop is not via the same interface. If the local host functions as a gateway, this may result in ARP replies for destinations not in the same subnet. === Linux is doing the things _WRONG_ and on its own way without any switch to change its behaviour. Regards, Carlos Velasco From szukw000@students.uni-mainz.de Sun Aug 17 06:29:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 06:29:20 -0700 (PDT) Received: from mailgate2.zdv.Uni-Mainz.DE (mailgate2.zdv.Uni-Mainz.DE [134.93.8.57]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7HDTFFl006103 for ; Sun, 17 Aug 2003 06:29:17 -0700 Received: from mail.students.Uni-Mainz.DE (mailserver1.zdv.Uni-Mainz.DE [134.93.8.30]) by mailgate2.zdv.Uni-Mainz.DE (8.12.9/8.12.8) with ESMTP id h7HDTENa027396 for ; Sun, 17 Aug 2003 15:29:14 +0200 (MEST) Received: from keun.at.localdomain (dialin119.zdv.Uni-Mainz.DE [134.93.174.119]) by mail.students.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id PAA02983 for ; Sun, 17 Aug 2003 15:29:13 +0200 (MEST) Received: by keun.at.localdomain (Postfix, from userid 0) id ECA9B7C73C; Sun, 17 Aug 2003 15:27:25 +0000 (UTC) Date: Sun, 17 Aug 2003 15:27:25 GMT From: "w.szukalski" Subject: linux-2.4.21 and IPv6: problem solved To: Message-ID: <20030817152725.A2212@keun> Mime-Version: 1.0 X-Mailer: mMosaic-3.8.17-pre5 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7HDTFFl006103 X-archive-position: 4893 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: szukw000@students.uni-mainz.de Precedence: bulk X-list: netdev First I regret: I did not mention the socket creation: reader = socket(AF_INET6, SOCK_DGRAM, PF_UNSPEC); writer = socket(AF_INET6, SOCK_DGRAM, PF_UNSPEC); In the meantime I inserted some 'printk(KERN_DEBUG "")' into the kernel code. Test program without connect(): linux/net/ipv6/af_inet6.c, inet6_bind(): /* Binding to link-local address requires an interface */ if (sk->bound_dev_if == 0) { release_sock(sk); printk(KERN_DEBUG "%s:%d:link-local address without IF:EINVAL\n", __FILE__,__LINE__); return -EINVAL; } After setting for 'ff02::1': read6.sin6_scope_id = 2; the reader succeeded. Test program with connect(): linux/net/ipv6/udp.c, udpv6_connect(): /* Connect to link-local address requires an interface */ if (sk->bound_dev_if == 0) { printk(KERN_DEBUG "%s:%d:sk->bound_dev_if == 0:EINVAL\n", __FILE__,__LINE__); return -EINVAL; } After setting for 'ff02::1': write6.sin6_scope_id = 2; the writer succeeded. winfried From alan@lxorguk.ukuu.org.uk Sun Aug 17 06:40:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 06:40:49 -0700 (PDT) Received: from dhcp23.swansea.linux.org.uk (pc1-cwma1-5-cust4.swan.cable.ntl.com [80.5.120.4]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7HDegFl006563 for ; Sun, 17 Aug 2003 06:40:43 -0700 Received: from dhcp23.swansea.linux.org.uk (localhost.localdomain [127.0.0.1]) by dhcp23.swansea.linux.org.uk (8.12.9/8.12.9) with ESMTP id h7HDc8ra022095; Sun, 17 Aug 2003 14:38:08 +0100 Received: (from alan@localhost) by dhcp23.swansea.linux.org.uk (8.12.9/8.12.9/Submit) id h7HDc6Oa022093; Sun, 17 Aug 2003 14:38:06 +0100 X-Authentication-Warning: dhcp23.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices From: Alan Cox To: Carlos Velasco Cc: Lamont Granquist , Bill Davidsen , "David S. Miller" , bloemsaa@xs4all.nl, Marcelo Tosatti , netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, Linux Kernel Mailing List In-Reply-To: <200308171509570955.003E4FEC@192.168.128.16> References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1061127485.21878.32.camel@dhcp23.swansea.linux.org.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 (1.4.3-3) Date: 17 Aug 2003 14:38:06 +0100 X-archive-position: 4894 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: netdev On Sul, 2003-08-17 at 14:09, Carlos Velasco wrote:> > >I can only think of one scenario where an arp request would come in > from > >192.168.140.x to a router interface that has 192.168.128.1. That one > >scenario is a misconfiguration. Two virtual networks sharing the same lan is a perfectly valid one. There since the router doesn't know how to reach 140.x it wouldnt reply, if it also *is* 140.1 for example then it can reply if it wishes but I see nothing in 826 requiring it does. In normal situations the routing tables will indicate preferred routes and gateways. > >I believe that reason we do the sanity check is because of basic IP > >routing. If the source is not from an IP address on the interface we > >received it on, we cannot reply to that IP address. It is simple as > that. Thats not true at the IP level for basic situations like asymmetric routing. > >As I stated, ARP is designed to be used on a LAN. This means that all > >stations that send/receive ARP packets are on the same subnet. This > is > >the reason we do the check. Actual ARP is used on everything from 300 baud radio networks up > >correctly. There is no case where a properly configured host should > ever > >send a ARP request for an IP address on a different subnet. See above, multiple virtual networks. > >not on the same network, then the host/router/client needs to find the > >gateway which is on the local network See "both are my address" case above > >Basic and proper implementations of the TCP/IP stack should never ARP > out > >for a device that it is not located on the same logical network the > host > >is, the reason for this being they cannot communicate directly unless See above, multiple lans co-existing. > >I hope this clears up the reson why Cisco's ARP implementation has > this > >safeguard you have found along with several others, HOWEVER, please > refer > >to RFC 1027, (http://www.ietf.org/rfc/rfc1027.txt) and under section > 2.4, > >it contains the following paragraph: RFC1027 covers proxy ARP only From alan@lxorguk.ukuu.org.uk Sun Aug 17 06:44:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 06:44:31 -0700 (PDT) Received: from dhcp23.swansea.linux.org.uk (pc1-cwma1-5-cust4.swan.cable.ntl.com [80.5.120.4]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7HDiQFl006953 for ; Sun, 17 Aug 2003 06:44:27 -0700 Received: from dhcp23.swansea.linux.org.uk (localhost.localdomain [127.0.0.1]) by dhcp23.swansea.linux.org.uk (8.12.9/8.12.9) with ESMTP id h7HDfwra022105; Sun, 17 Aug 2003 14:41:58 +0100 Received: (from alan@localhost) by dhcp23.swansea.linux.org.uk (8.12.9/8.12.9/Submit) id h7HDfu2C022103; Sun, 17 Aug 2003 14:41:56 +0100 X-Authentication-Warning: dhcp23.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices From: Alan Cox To: Carlos Velasco Cc: Lamont Granquist , Bill Davidsen , "David S. Miller" , bloemsaa@xs4all.nl, Marcelo Tosatti , netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, Linux Kernel Mailing List In-Reply-To: <200308171516090038.0043F977@192.168.128.16> References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> <200308171516090038.0043F977@192.168.128.16> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 (1.4.3-3) Date: 17 Aug 2003 14:41:56 +0100 X-archive-position: 4895 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: netdev On Sul, 2003-08-17 at 14:16, Carlos Velasco wrote: > So, > > According to RFC 1027: > http://www.ietf.org/rfc/rfc1027.txt Proxy ARP only. > A.3. ARP datagram > > An ARP reply is discarded if the destination IP address does not > match the local host address. Linux counts all the IP addresses it has as being local host address. And Linux btw has arpfilter which can do far more than just imitate your favourite network religion of the week From bloemsaa@xs4all.nl Sun Aug 17 07:01:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 07:01:33 -0700 (PDT) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7HE1TFl007663 for ; Sun, 17 Aug 2003 07:01:30 -0700 Received: from llewella (vialle.xs4all.nl [213.84.6.25]) by smtpzilla2.xs4all.nl (8.12.9/8.12.9) with SMTP id h7HDxkZ9053472; Sun, 17 Aug 2003 16:00:12 +0200 (CEST) Message-ID: <00fa01c364c7$e2c6ba50$c801a8c0@llewella> From: "Bas Bloemsaat" To: "Alan Cox" , "Carlos Velasco" Cc: "Lamont Granquist" , "Bill Davidsen" , "David S. Miller" , "Marcelo Tosatti" , , , , , "Linux Kernel Mailing List" References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Date: Sun, 17 Aug 2003 15:59:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 4896 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bloemsaa@xs4all.nl Precedence: bulk X-list: netdev > Proxy ARP only. > > > A.3. ARP datagram > > > > An ARP reply is discarded if the destination IP address does not > > match the local host address. > > Linux counts all the IP addresses it has as being local host address. > > And Linux btw has arpfilter which can do far more than just imitate your > favourite network religion of the week > I think the whole mess comes from the ambigious use of the word host in RFC 826, and several possible interpretations. It can mean both ethernet host (i.e. a NIC) or internet host (i.e. the whole server). This isn't clear from the RFC. In fact, the meanings are mixed. It's not a good RFC. The linux way is a perfectly legal, if somewhat awkward, way to interpret the RFC. Me too, I'd like a device respond only to ARP requests that are meant for an IP bound to it, but please, let's not turn this into a holy war. Regards, Bas From carlosev@newipnet.com Sun Aug 17 07:17:13 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 07:17:20 -0700 (PDT) Received: from smtp.newipnet.com (5.Red-80-32-157.pooles.rima-tde.net [80.32.157.5]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7HEHAFl008309 for ; Sun, 17 Aug 2003 07:17:11 -0700 Received: by smtp.newipnet.com (ESMTP Server, from userid 511) id 091A6207E5; Sun, 17 Aug 2003 16:17:07 +0200 (CEST) Received: from madre (madre.newipnet.com [192.168.128.4]) by smtp.newipnet.com (ESMTP Server) with ESMTP id 412412082A; Sun, 17 Aug 2003 16:16:59 +0200 (CEST) Message-ID: <200308171555280781.0067FB36@192.168.128.16> In-Reply-To: <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Sun, 17 Aug 2003 15:55:28 +0200 From: "Carlos Velasco" To: "Alan Cox" Cc: "Lamont Granquist" , "Bill Davidsen" , "David S. Miller" , bloemsaa@xs4all.nl, "Marcelo Tosatti" , netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, "Linux Kernel Mailing List" Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Content-Type: text/plain; charset="us-ascii" X-archive-position: 4897 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: carlosev@newipnet.com Precedence: bulk X-list: netdev On 17/08/2003 at 14:41 Alan Cox wrote: >On Sul, 2003-08-17 at 14:16, Carlos Velasco wrote: >> So, >> >> According to RFC 1027: >> http://www.ietf.org/rfc/rfc1027.txt > >Proxy ARP only. So, if you have a router performing Proxy ARP... you don't need to reply to the "bad" Linux ARP Request, right? >> A.3. ARP datagram >> >> An ARP reply is discarded if the destination IP address does not >> match the local host address. > >Linux counts all the IP addresses it has as being local host address. You should pay more attention, the real thing is on the second phrase: "An ARP request is discarded if the source IP address is not in the same subnet." >And Linux btw has arpfilter which can do far more than just imitate your >favourite network religion of the week And you can just use other OS and solve the problem without messing with firewalling and mangling techniques. Maybe the "favourite network religion" should be called as "RedHat favourite network religion"? Or maybe it should be called... "Linux approaching Microsoft", as both don't listen to real users. Linux versus all other OSes and systems (Cisco, Foundry, ...) It's clear this is not MY religious war... maybe others war.... I don't live from Linux. Regards, Carlos Velasco From yoshfuji@linux-ipv6.org Sun Aug 17 07:34:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 07:34:27 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7HEYJFl008939 for ; Sun, 17 Aug 2003 07:34:21 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h7HEYc1M019291; Sun, 17 Aug 2003 23:34:39 +0900 Date: Sun, 17 Aug 2003 23:34:38 +0900 (JST) Message-Id: <20030817.233438.07191138.yoshfuji@linux-ipv6.org> To: szukw000@students.uni-mainz.de Cc: netdev@oss.sgi.com Subject: Re: linux-2.4.21 and IPv6 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20030817020925.A875@keun> References: <20030817020925.A875@keun> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4898 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <20030817020925.A875@keun> (at Sun, 17 Aug 2003 02:09:25 GMT), "w.szukalski" says: > read6.sin6_scope_id = 0; : > // ALTERNATIVE 2: > inet_pton(AF_INET6, host, &read6.sin6_addr); > > // ALTERNATIVE 3: > read6.sin6_addr = mreq6.ipv6mr_multiaddr; What is host? > bind(reader, (struct sockaddr *)&read6, sizeof(read6) ); > > bind() fails for alternative 3 with 'Invalid argument'. bind(2) should fail with ALT.2 for some "host." Anyway, the reason seems that you forgot to set scope-id for link-local scope addresses. --yoshfuji From yoshfuji@linux-ipv6.org Sun Aug 17 07:38:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 07:38:46 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7HEcIFl009345 for ; Sun, 17 Aug 2003 07:38:21 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h7HEcb1M019311; Sun, 17 Aug 2003 23:38:37 +0900 Date: Sun, 17 Aug 2003 23:38:37 +0900 (JST) Message-Id: <20030817.233837.101383706.yoshfuji@linux-ipv6.org> To: szukw000@students.uni-mainz.de Cc: netdev@oss.sgi.com Subject: Re: linux-2.4.21 and IPv6: problem solved From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20030817152725.A2212@keun> References: <20030817152725.A2212@keun> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4899 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <20030817152725.A2212@keun> (at Sun, 17 Aug 2003 15:27:25 GMT), "w.szukalski" says: > First I regret: I did not mention the socket creation: > > reader = socket(AF_INET6, SOCK_DGRAM, PF_UNSPEC); > writer = socket(AF_INET6, SOCK_DGRAM, PF_UNSPEC); ~~~~~~~~~This is not good. use 0, or IPPROTO_UDP (for UDP). --yoshfuji From alan@lxorguk.ukuu.org.uk Sun Aug 17 08:30:48 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 08:30:54 -0700 (PDT) Received: from dhcp23.swansea.linux.org.uk (pc1-cwma1-5-cust4.swan.cable.ntl.com [80.5.120.4]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7HFUkFl010731 for ; Sun, 17 Aug 2003 08:30:47 -0700 Received: from dhcp23.swansea.linux.org.uk (localhost.localdomain [127.0.0.1]) by dhcp23.swansea.linux.org.uk (8.12.9/8.12.9) with ESMTP id h7HFSHra023145; Sun, 17 Aug 2003 16:28:17 +0100 Received: (from alan@localhost) by dhcp23.swansea.linux.org.uk (8.12.9/8.12.9/Submit) id h7HFSCcM023143; Sun, 17 Aug 2003 16:28:12 +0100 X-Authentication-Warning: dhcp23.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices From: Alan Cox To: Carlos Velasco Cc: Lamont Granquist , Bill Davidsen , "David S. Miller" , bloemsaa@xs4all.nl, Marcelo Tosatti , netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, Linux Kernel Mailing List In-Reply-To: <200308171555280781.0067FB36@192.168.128.16> References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 (1.4.3-3) Date: 17 Aug 2003 16:28:12 +0100 X-archive-position: 4900 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: netdev On Sul, 2003-08-17 at 14:55, Carlos Velasco wrote: > >> According to RFC 1027: > >> http://www.ietf.org/rfc/rfc1027.txt > > > >Proxy ARP only. > > So, if you have a router performing Proxy ARP... you don't need to > reply to the "bad" Linux ARP Request, right? Linux doesn't issue "bad" requests. Linux will reply when it is asked for an address that it owns, as per RFC826, unless you chose to change the behaviour with things like arpfilter. From bloemsaa@xs4all.nl Sun Aug 17 08:58:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 08:58:40 -0700 (PDT) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7HFwZFl011247 for ; Sun, 17 Aug 2003 08:58:36 -0700 Received: from llewella (vialle.xs4all.nl [213.84.6.25]) by smtpzilla2.xs4all.nl (8.12.9/8.12.9) with SMTP id h7HFvJ3n074745; Sun, 17 Aug 2003 17:57:26 +0200 (CEST) Message-ID: <011a01c364d8$44be1f90$c801a8c0@llewella> From: "Bas Bloemsaat" To: "Alan Cox" , "Carlos Velasco" Cc: "Lamont Granquist" , "Bill Davidsen" , "David S. Miller" , "Marcelo Tosatti" , , , , , "Linux Kernel Mailing List" References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Date: Sun, 17 Aug 2003 17:57:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 4901 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bloemsaa@xs4all.nl Precedence: bulk X-list: netdev What wonders me about the behaviour is that it is not consistent. When I have the following situation: a box with twon nics, one 192.168.1.1, ethernet adr aa , the other 192.168.1.2 ethernet adr bb When I do an ARP request for 192.168.1.2, both respond. aa as wel as bb But if I do another request for 192.168.1.2, and I direct it to the aa NIC, it does not respond. Unless I turn on packet_forwarding (i.e. routing). Remember, ARP is not routable, or shouldn't be, yet it is treated as such. Regards, Bas From carlosev@newipnet.com Sun Aug 17 09:01:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 09:01:48 -0700 (PDT) Received: from smtp.newipnet.com (5.Red-80-32-157.pooles.rima-tde.net [80.32.157.5]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7HG1eFl011609 for ; Sun, 17 Aug 2003 09:01:43 -0700 Received: by smtp.newipnet.com (ESMTP Server, from userid 511) id 074872082A; Sun, 17 Aug 2003 18:01:37 +0200 (CEST) Received: from madre (madre.newipnet.com [192.168.128.4]) by smtp.newipnet.com (ESMTP Server) with ESMTP id 4C884207E5; Sun, 17 Aug 2003 18:01:29 +0200 (CEST) Message-ID: <200308171759540391.00AA8CAB@192.168.128.16> In-Reply-To: <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Sun, 17 Aug 2003 17:59:54 +0200 From: "Carlos Velasco" To: "Alan Cox" Cc: "Lamont Granquist" , "Bill Davidsen" , "David S. Miller" , bloemsaa@xs4all.nl, "Marcelo Tosatti" , netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, "Linux Kernel Mailing List" Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Content-Type: text/plain; charset="us-ascii" X-archive-position: 4902 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: carlosev@newipnet.com Precedence: bulk X-list: netdev On 17/08/2003 at 16:28 Alan Cox wrote: >Linux doesn't issue "bad" requests. Linux will reply when it is >asked for an address that it owns, as per RFC826, unless you chose >to change the behaviour with things like arpfilter. We are not talking about ARP Replies, we are talking about ARP Requests. You can see the Richard post here, same issue I reported several weeks ago: http://marc.theaimsgroup.com/?l=linux-net&m=106094924813337&w=2 == On eth0, we see: 11:23:55.650514 0:4:75:ca:c4:ef Broadcast arp 42: arp who-has 10.10.10.1 tell 212.xxx.yyy.9 == Linux is sending an ARP Request to a LAN where the source IP address of the packet has not any sense in that IP network. And, at least, 2 RFCs are stating that other devices should not reply to this packet. Currently know Cisco, Foundry; possibly others, and possibly others coming as ARP storms are not desired. Regards, Carlos Velasco From alan@lxorguk.ukuu.org.uk Sun Aug 17 09:28:59 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 09:29:07 -0700 (PDT) Received: from dhcp23.swansea.linux.org.uk (pc1-cwma1-5-cust4.swan.cable.ntl.com [80.5.120.4]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7HGSwFl012086 for ; Sun, 17 Aug 2003 09:28:59 -0700 Received: from dhcp23.swansea.linux.org.uk (localhost.localdomain [127.0.0.1]) by dhcp23.swansea.linux.org.uk (8.12.9/8.12.9) with ESMTP id h7HGQNra023274; Sun, 17 Aug 2003 17:26:23 +0100 Received: (from alan@localhost) by dhcp23.swansea.linux.org.uk (8.12.9/8.12.9/Submit) id h7HGQJfX023272; Sun, 17 Aug 2003 17:26:19 +0100 X-Authentication-Warning: dhcp23.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices From: Alan Cox To: Carlos Velasco Cc: Lamont Granquist , Bill Davidsen , "David S. Miller" , bloemsaa@xs4all.nl, Marcelo Tosatti , netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, Linux Kernel Mailing List In-Reply-To: <200308171759540391.00AA8CAB@192.168.128.16> References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 (1.4.3-3) Date: 17 Aug 2003 17:26:19 +0100 X-archive-position: 4903 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: netdev On Sul, 2003-08-17 at 16:59, Carlos Velasco wrote: > We are not talking about ARP Replies, we are talking about ARP > Requests. > You can see the Richard post here, same issue I reported several weeks > ago: > http://marc.theaimsgroup.com/?l=linux-net&m=106094924813337&w=2 You put the foundary devices IP on one of your interfaces ? In which case your network is misconfigured - go fix it. Two systems are not permitted to have the same IP address. Linux supports asymettric routing just fine. From carlosev@newipnet.com Sun Aug 17 09:38:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 09:38:45 -0700 (PDT) Received: from smtp.newipnet.com (5.Red-80-32-157.pooles.rima-tde.net [80.32.157.5]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7HGcbFl012442 for ; Sun, 17 Aug 2003 09:38:39 -0700 Received: by smtp.newipnet.com (ESMTP Server, from userid 511) id 51E01207E5; Sun, 17 Aug 2003 18:38:35 +0200 (CEST) Received: from madre (madre.newipnet.com [192.168.128.4]) by smtp.newipnet.com (ESMTP Server) with ESMTP id EBE6F2082A; Sun, 17 Aug 2003 18:38:24 +0200 (CEST) Message-ID: <200308171827130739.00C3905F@192.168.128.16> In-Reply-To: <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Sun, 17 Aug 2003 18:27:13 +0200 From: "Carlos Velasco" To: "Alan Cox" Cc: "Lamont Granquist" , "Bill Davidsen" , "David S. Miller" , bloemsaa@xs4all.nl, "Marcelo Tosatti" , netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, "Linux Kernel Mailing List" Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Content-Type: text/plain; charset="us-ascii" X-archive-position: 4904 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: carlosev@newipnet.com Precedence: bulk X-list: netdev On 17/08/2003 at 17:26 Alan Cox wrote: >> http://marc.theaimsgroup.com/?l=linux-net&m=106094924813337&w=2 > >You put the foundary devices IP on one of your interfaces ? In which case >your network is misconfigured - go fix it. Two systems are not permitted >to have the same IP address. Linux supports asymettric routing just fine. Really, I don't know if you don't uderstand or you don't want to understand... There is _NOT_ any problem of duplicated IPs or so. It's a Load Balancing scenary, similar to linuxvirtualserver and ARP problem that rise _ONLY_ when using Linux as real server: http://www.linuxvirtualserver.org/docs/arp.html If you send a packet through dev eth0 to dev lo IP address or other interface, when Linux try to map the MAC address with the IP address of the default gateway (or the gateway to reach the packet Source IP address), it uses the lo IP address (or other dev) in the ARP Request. Regards, Carlos Velasco From dhollis@davehollis.com Sun Aug 17 09:53:23 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 09:53:27 -0700 (PDT) Received: from bender.davehollis.com (user-0cal2fl.cable.mindspring.com [24.170.137.245]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7HGrJFl012823 for ; Sun, 17 Aug 2003 09:53:22 -0700 Received: from davehollis.com (dhollis-lnx.davehollis.com [192.168.1.170]) (authenticated bits=0) by bender.davehollis.com (8.12.8/8.12.8) with ESMTP id h7HGovxQ003158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Aug 2003 12:50:59 -0400 Message-ID: <3F3FB275.3090601@davehollis.com> Date: Sun, 17 Aug 2003 12:51:01 -0400 From: David T Hollis User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carlos Velasco CC: Alan Cox , Lamont Granquist , Bill Davidsen , "David S. Miller" , bloemsaa@xs4all.nl, Marcelo Tosatti , netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, Linux Kernel Mailing List Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> In-Reply-To: <200308171759540391.00AA8CAB@192.168.128.16> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-archive-position: 4905 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dhollis@davehollis.com Precedence: bulk X-list: netdev Carlos Velasco wrote: >On 17/08/2003 at 16:28 Alan Cox wrote: > > > >>Linux doesn't issue "bad" requests. Linux will reply when it is >>asked for an address that it owns, as per RFC826, unless you chose >>to change the behaviour with things like arpfilter. >> >> > >We are not talking about ARP Replies, we are talking about ARP >Requests. >You can see the Richard post here, same issue I reported several weeks >ago: >http://marc.theaimsgroup.com/?l=linux-net&m=106094924813337&w=2 > >== > On eth0, we see: > >11:23:55.650514 0:4:75:ca:c4:ef Broadcast arp 42: arp who-has >10.10.10.1 >tell 212.xxx.yyy.9 >== > >Linux is sending an ARP Request to a LAN where the source IP address of >the packet has not any sense in that IP network. >And, at least, 2 RFCs are stating that other devices should not reply >to this packet. Currently know Cisco, Foundry; possibly others, and >possibly others coming as ARP storms are not desired. > >Regards, >Carlos Velasco > > >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ > > Check out: http://www.linuxvirtualserver.org/docs/arp.html. I understand the problem you're talking about. It's not a 'bug', it's a feature! You need to use the hidden interface approach to have the back end system not broadcast it's MAC for the virtual IP. From carlosev@newipnet.com Sun Aug 17 10:03:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 10:03:44 -0700 (PDT) Received: from smtp.newipnet.com (5.Red-80-32-157.pooles.rima-tde.net [80.32.157.5]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7HH3cFl013206 for ; Sun, 17 Aug 2003 10:03:39 -0700 Received: by smtp.newipnet.com (ESMTP Server, from userid 511) id AF46C2082A; Sun, 17 Aug 2003 19:03:36 +0200 (CEST) Received: from madre (madre.newipnet.com [192.168.128.4]) by smtp.newipnet.com (ESMTP Server) with ESMTP id DF27E207E5; Sun, 17 Aug 2003 19:03:26 +0200 (CEST) Message-ID: <200308171845560303.00D4B163@192.168.128.16> In-Reply-To: <3F3FB275.3090601@davehollis.com> References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> <3F3FB275.3090601@davehollis.com> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Sun, 17 Aug 2003 18:45:56 +0200 From: "Carlos Velasco" To: "David T Hollis" Cc: "Alan Cox" , "Lamont Granquist" , "Bill Davidsen" , "David S. Miller" , bloemsaa@xs4all.nl, "Marcelo Tosatti" , netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, "Linux Kernel Mailing List" Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Content-Type: text/plain; charset="ISO-8859-1" X-archive-position: 4906 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: carlosev@newipnet.com Precedence: bulk X-list: netdev On 17/08/2003 at 12:51 David T Hollis wrote: >Check out: http://www.linuxvirtualserver.org/docs/arp.html. I >understand the problem you're talking about. It's not a 'bug', it's a >feature! You need to use the hidden interface approach to have the back >end system not broadcast it's MAC for the virtual IP. I know it... but.. 1. hidden patch is not in the main linuk kernel stream.... why? 2. that "feature" makes linux to send non-RFC ARP Requests 3. what's the meaning of that "feature"? It seems to do more problems that it solves. Regards, Carlos Velasco From arjanv@redhat.com Sun Aug 17 10:18:42 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 10:18:46 -0700 (PDT) Received: from laptop.fenrus.com (nat-pool-bos.redhat.com [66.187.230.200]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7HHIfFl013638 for ; Sun, 17 Aug 2003 10:18:42 -0700 Received: from laptop.fenrus.com (laptop.fenrus.com [127.0.0.1]) by laptop.fenrus.com (8.12.9/8.12.9) with ESMTP id h7HHDPPI031762; Sun, 17 Aug 2003 13:13:26 -0400 Received: (from arjan@localhost) by laptop.fenrus.com (8.12.9/8.12.9/Submit) id h7HHDPtD031760; Sun, 17 Aug 2003 13:13:25 -0400 X-Authentication-Warning: laptop.fenrus.com: arjan set sender to arjanv@redhat.com using -f Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices From: Arjan van de Ven Reply-To: arjanv@redhat.com To: Carlos Velasco Cc: David T Hollis , Alan Cox , Lamont Granquist , Bill Davidsen , "David S. Miller" , bloemsaa@xs4all.nl, Marcelo Tosatti , netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, Linux Kernel Mailing List In-Reply-To: <200308171845560303.00D4B163@192.168.128.16> References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> <3F3FB275.3090601@davehollis.com> <200308171845560303.00D4B163@192.168.128.16> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-pvy2wwBMrUDO3qFcJjuW" Organization: Red Hat, Inc. Message-Id: <1061140404.29559.0.camel@laptop.fenrus.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 (1.4.4-2) Date: Sun, 17 Aug 2003 13:13:24 -0400 X-archive-position: 4907 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arjanv@redhat.com Precedence: bulk X-list: netdev --=-pvy2wwBMrUDO3qFcJjuW Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > 1. hidden patch is not in the main linuk kernel stream.... why? because arpfilter is a more generic way of doing things like this, and that IS in the main linux kernel --=-pvy2wwBMrUDO3qFcJjuW Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/P7e0xULwo51rQBIRAnUUAJkByJSuyHz4tv/7BD5akZlnh7Yl6wCfVinj ER4FDcOJEPHlaPhF5XFOSlo= =iRkb -----END PGP SIGNATURE----- --=-pvy2wwBMrUDO3qFcJjuW-- From alan@lxorguk.ukuu.org.uk Sun Aug 17 10:26:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 10:26:50 -0700 (PDT) Received: from dhcp23.swansea.linux.org.uk (pc1-cwma1-5-cust4.swan.cable.ntl.com [80.5.120.4]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7HHQiFl013991 for ; Sun, 17 Aug 2003 10:26:46 -0700 Received: from dhcp23.swansea.linux.org.uk (localhost.localdomain [127.0.0.1]) by dhcp23.swansea.linux.org.uk (8.12.9/8.12.9) with ESMTP id h7HHOBra023369; Sun, 17 Aug 2003 18:24:11 +0100 Received: (from alan@localhost) by dhcp23.swansea.linux.org.uk (8.12.9/8.12.9/Submit) id h7HHO6E0023367; Sun, 17 Aug 2003 18:24:06 +0100 X-Authentication-Warning: dhcp23.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices From: Alan Cox To: Carlos Velasco Cc: Lamont Granquist , Bill Davidsen , "David S. Miller" , bloemsaa@xs4all.nl, Marcelo Tosatti , netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, Linux Kernel Mailing List In-Reply-To: <200308171827130739.00C3905F@192.168.128.16> References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> <200308171827130739.00C3905F@192.168.128.16> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1061141045.21885.74.camel@dhcp23.swansea.linux.org.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 (1.4.3-3) Date: 17 Aug 2003 18:24:06 +0100 X-archive-position: 4908 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: netdev On Sul, 2003-08-17 at 17:27, Carlos Velasco wrote: > Really, I don't know if you don't uderstand or you don't want to > understand... > > There is _NOT_ any problem of duplicated IPs or so. > It's a Load Balancing scenary, similar to linuxvirtualserver and ARP > problem that rise _ONLY_ when using Linux as real server: > http://www.linuxvirtualserver.org/docs/arp.html Which says | In the LVS/TUN and LVS/DR clusters, the Virtual IP (VIP) addresses are | shared by both the load balancer and real servers, because they all | configure the VIP address on one of their interfaces. Which is not legal IP, and is why you are having problems. > If you send a packet through dev eth0 to dev lo IP address or other > interface, when Linux try to map the MAC address with the IP address of > the default gateway (or the gateway to reach the packet Source IP > address), it uses the lo IP address (or other dev) in the ARP Request. So stick the address on eth0 not on lo since its not a loopback but an eth0 address, then use arpfilter so you don't arp for the invalid magic shared IP address, or NAT it, or it may work to do ip route add nexthop-addr src my-virtual-addr dev eth0 scope local onlink ip route add default src my-virtual-addr via nexthop-addr dev eth0 scope global if you have no other routes getting in the way, especially old style ifconfig ones From jgarzik@pobox.com Sun Aug 17 10:46:06 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 10:46:09 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7HHk5Fl014377 for ; Sun, 17 Aug 2003 10:46:06 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19oRbP-0006PO-Td; Sun, 17 Aug 2003 18:46:04 +0100 Message-ID: <3F3FBF50.8070207@pobox.com> Date: Sun, 17 Aug 2003 13:45:52 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: Maillist netdev CC: "David S. Miller" Subject: double-check me? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4909 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 Maybe you guys can spot something I'm missing here. alloc_netdev is supposed to guarantee that dev->priv is aligned by 32 bytes: struct net_device *alloc_netdev(int sizeof_priv, const char *mask, void (*setup)(struct net_device *)) { struct net_device *dev; int alloc_size; /* ensure 32-byte alignment of the private area */ alloc_size = sizeof (*dev) + sizeof_priv + 31; dev = (struct net_device *) kmalloc (alloc_size, GFP_KERNEL); if (dev == NULL) { printk(KERN_ERR "alloc_dev: Unable to allocate device memory.\n" ); return NULL; } memset(dev, 0, alloc_size); if (sizeof_priv) dev->priv = (void *) (((long)(dev + 1) + 31) & ~31); Now... shouldn't that last line of code be "dev + 1 + sizeof(*dev)" ? It seems to work 2.[456] for a long time, so I am doubting myself... surely it would have caused memory corruption or something by now if I have really found a bug. Jeff From garzik@gtf.org Sun Aug 17 11:31:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 11:31:52 -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 h7HIVjFl015011 for ; Sun, 17 Aug 2003 11:31:46 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id 51C10660B; Sun, 17 Aug 2003 14:31:37 -0400 (EDT) Date: Sun, 17 Aug 2003 14:31:37 -0400 From: Jeff Garzik To: torvalds@osdl.org Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [bk patches] net driver updates Message-ID: <20030817183137.GA18521@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: 4910 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Linus, please do a bk pull bk://kernel.bkbits.net/jgarzik/net-drivers-2.6 Patch is also available at ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.0-test3-bk5-netdrvr1.patch.bz2 This will update the following files: drivers/net/Kconfig | 11 drivers/net/Makefile | 1 drivers/net/Makefile.lib | 1 drivers/net/arcnet/com20020-pci.c | 6 drivers/net/arcnet/com20020.c | 31 drivers/net/arcnet/com90io.c | 17 drivers/net/hydra.c | 24 drivers/net/sis190.c | 2094 +++++++++++++++++++++++++++++--------- drivers/net/tokenring/3c359.c | 2 drivers/net/tokenring/olympic.c | 3 drivers/net/tulip/tulip_core.c | 1 drivers/net/wan/z85230.c | 6 drivers/net/wireless/airo.c | 12 drivers/net/wireless/atmel_cs.c | 1 14 files changed, 1715 insertions(+), 495 deletions(-) through these ChangeSets: (03/08/17 1.1217) [netdrvr sis190] allocate RX/TX descriptors using PCI DMA API The RX buffers themselves still need to be converted. The three places that need fixing are marked with #warning. (03/08/17 1.1216) [netdrvr tulip] add pci id for 3com 3CSOHO100B-TX (03/08/17 1.1215) [netdrvr sis190] manually clean up formatting a bit more Also, two trivial code changes: * add unlikely() to assert() definition * fix MODULE_AUTHOR email address brackets (03/08/17 1.1214) [netdrvr sis190] Lindent sis190. zero code changes. (03/08/17 1.1213) [netdrvr] add sis190 gigabit ethernet driver (note: needs work) (03/08/17 1.1212) [PATCH] Make z8530.c build on 2.6 Either we need to mark this driver (and the parts that use them) as BROKEN, or at least get it building again. With this it builds, but of course, I don't have the real hardware. (03/08/17 1.1211) [netdrvr hydra] janitor cleanups (03/08/17 1.1210) [wireless airo] Fix PCI unregister code (03/08/17 1.1209) [wireless airo] Turns on spy code in wireless extensions v16 (03/08/17 1.1208) [arcnet com90io] replace check_region with temporary request_region, in probe phase. (03/08/17 1.1207) [arcnet com20020] misc fixes * com20020_close expects two arguments (and actually uses the second argument), but the arcnet layer only passes one arg. Fun ensues. * Remove __devinit markers, this is a library module. * Move request_region up in com20020_found, to make the call occur before the first I/O access in the function. (03/08/17 1.1206) [arcnet com20020] check_region removal, ->name removal breakage fix (03/08/17 1.1205) [netdrvr] clean up driver object name removal breakage Affected drivers: atmel_cs, olympic, 3c359 From garzik@gtf.org Sun Aug 17 11:38:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 11:38:59 -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 h7HIcrFl015359 for ; Sun, 17 Aug 2003 11:38:54 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id 7726F660B; Sun, 17 Aug 2003 14:38:48 -0400 (EDT) Date: Sun, 17 Aug 2003 14:38:48 -0400 From: Jeff Garzik To: torvalds@osdl.org Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [bk patches] add ethtool_ops to net drivers Message-ID: <20030817183848.GA18728@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: 4911 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Linus, In order to maintain backwards compatibility and minimize impact, netdev_ops mentioned at KS was scaled back to ethtool_ops. This allows driver-at-a-time replacement often-duplicated ioctl handling code with a Linux-style foo_ops set of function pointers. Also, I've been waiting on this patch to begin attacking the stack usage problems that often occur in ethtool ioctl handlers. Since gcc sums instead of unions disjoint stack scopes (gcc bug #9997), huge functions that handle a bunch of ioctls wind up eating way more stack space than the programmer (rightfully) intended. ethtool_ops not only makes a driver smaller, but it also neatly eliminates the stack usage problem. I much prefer this scaled back approach, which doesn't break anything, and DaveM is ok with it as well. Please apply. BitKeeper repo: bk pull http://gkernel.bkbits.net/ethtool-2.6 Patch is also available from ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.0-test3-bk5-ethtool1.patch.bz2 This will update the following files: drivers/net/tg3.c | 664 +++++++++++++++++++-------------------------- include/linux/ethtool.h | 99 ++++++ include/linux/netdevice.h | 9 net/core/Makefile | 4 net/core/dev.c | 16 - net/core/ethtool.c | 672 ++++++++++++++++++++++++++++++++++++++++++++++ 6 files changed, 1076 insertions(+), 388 deletions(-) through these ChangeSets: (03/08/07 1.1119.10.3) [netdrvr] add SET_ETHTOOL_OPS back-compat hook (03/08/07 1.1119.10.2) [netdrvr tg3] convert to using ethtool_ops (03/08/07 1.1119.10.1) [netdrvr] add ethtool_ops to struct net_device, and associated infrastructure Contributed by Matthew Wilcox. From insecure@mail.od.ua Sun Aug 17 12:46:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 12:46:35 -0700 (PDT) Received: from 127.0.0.1 (168.imtp.Ilyichevsk.Odessa.UA [195.66.192.168] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7HJkMFl015989 for ; Sun, 17 Aug 2003 12:46:26 -0700 Received: (qmail 17025 invoked by uid 0); 17 Aug 2003 19:46:13 -0000 Received: from unknown (HELO quasar) (1.1.1.1) by 0 with SMTP; 17 Aug 2003 19:46:13 -0000 Content-Type: text/plain; charset="koi8-r" From: insecure Reply-To: insecure@mail.od.ua To: arjanv@redhat.com, Carlos Velasco Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Date: Sun, 17 Aug 2003 22:46:12 +0300 X-Mailer: KMail [version 1.4] Cc: David T Hollis , Alan Cox , Lamont Granquist , Bill Davidsen , "David S. Miller" , bloemsaa@xs4all.nl, Marcelo Tosatti , netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, Linux Kernel Mailing List References: <200308171845560303.00D4B163@192.168.128.16> <1061140404.29559.0.camel@laptop.fenrus.com> In-Reply-To: <1061140404.29559.0.camel@laptop.fenrus.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200308172246.12835.insecure@mail.od.ua> X-archive-position: 4912 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: insecure@mail.od.ua Precedence: bulk X-list: netdev On Sunday 17 August 2003 20:13, Arjan van de Ven wrote: > > 1. hidden patch is not in the main linuk kernel stream.... why? > > because arpfilter is a more generic way of doing things like this, and > that IS in the main linux kernel I am interested in that but last time I googled for it, neither userspace utils nor any documentation turned up. I only see some kernel parts of it. -- vda From khc@pm.waw.pl Sun Aug 17 14:27:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 14:27:43 -0700 (PDT) Received: from hq.pm.waw.pl (hq.pm.waw.pl [195.116.170.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7HLRZFl017090 for ; Sun, 17 Aug 2003 14:27:37 -0700 Received: by hq.pm.waw.pl (Postfix, from userid 10) id A3B52322F; Sun, 17 Aug 2003 23:27:32 +0200 (CEST) Received: by defiant.pm.waw.pl (Postfix, from userid 500) id 457AC3C7BB; Sun, 17 Aug 2003 22:58:31 +0200 (CEST) To: Jeff Garzik Cc: Maillist netdev , "David S. Miller" Subject: Re: double-check me? References: <3F3FBF50.8070207@pobox.com> From: Krzysztof Halasa Date: 17 Aug 2003 22:58:31 +0200 In-Reply-To: <3F3FBF50.8070207@pobox.com> Message-ID: Lines: 32 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4913 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: khc@pm.waw.pl Precedence: bulk X-list: netdev Jeff Garzik writes: > Maybe you guys can spot something I'm missing here. alloc_netdev is > supposed to guarantee that dev->priv is aligned by 32 bytes: > > struct net_device *dev; > > if (sizeof_priv) > dev->priv = (void *) (((long)(dev + 1) + 31) & ~31); > > > Now... shouldn't that last line of code be "dev + 1 + sizeof(*dev)" ? > > It seems to work 2.[456] for a long time, so I am doubting > myself... surely it would have caused memory corruption or something > by now if I have really found a bug. Looks ok... not very readable, though. dev + 1 = ((u8*)dev) + sizeof(dev) = pointer to end of net_device struct. (X + 31) & ~31 makes sure X is 32-bytes aligned (0-31 bytes are added). Hope the alloc_size has enough space for this. 31 should be better 0x1F I think. I also like sizeof(struct net_device) more than sizeof(*dev). Why do you want "+ 1" if you add sizeof(*dev)? -- Krzysztof Halasa Network Administrator From jgarzik@pobox.com Sun Aug 17 15:31:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 15:31:26 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7HMVFFl017856 for ; Sun, 17 Aug 2003 15:31:17 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19oW3N-0008QY-HM; Sun, 17 Aug 2003 23:31:13 +0100 Message-ID: <3F400226.1080006@pobox.com> Date: Sun, 17 Aug 2003 18:31:02 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: Krzysztof Halasa CC: Maillist netdev , "David S. Miller" Subject: Re: double-check me? References: <3F3FBF50.8070207@pobox.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4914 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 Krzysztof Halasa wrote: > Jeff Garzik writes: > > >>Maybe you guys can spot something I'm missing here. alloc_netdev is >>supposed to guarantee that dev->priv is aligned by 32 bytes: >> >> struct net_device *dev; >> >> if (sizeof_priv) >> dev->priv = (void *) (((long)(dev + 1) + 31) & ~31); >> >> >>Now... shouldn't that last line of code be "dev + 1 + sizeof(*dev)" ? >> >>It seems to work 2.[456] for a long time, so I am doubting >>myself... surely it would have caused memory corruption or something >>by now if I have really found a bug. > > > Looks ok... not very readable, though. > > dev + 1 = ((u8*)dev) + sizeof(dev) = pointer to end of net_device struct. C pointer arithmatic. Ok, duh, thanks :) Jeff, too used to void pointer arith From willy@w.ods.org Sun Aug 17 15:55:47 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 15:55:54 -0700 (PDT) Received: from www.home.local (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7HMthFl018251 for ; Sun, 17 Aug 2003 15:55:46 -0700 Received: from alpha.home.local (alpha [10.0.1.2]) by www.home.local (8.12.1/8.12.1) with ESMTP id h7HMmxpn032538; Mon, 18 Aug 2003 00:48:59 +0200 Received: (from willy@localhost) by alpha.home.local (8.12.4/8.12.1) id h7HMmnjw009780; Mon, 18 Aug 2003 00:48:49 +0200 Date: Mon, 18 Aug 2003 00:48:49 +0200 From: Willy Tarreau To: Alan Cox Cc: Carlos Velasco , Lamont Granquist , Bill Davidsen , "David S. Miller" , bloemsaa@xs4all.nl, Marcelo Tosatti , netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, Linux Kernel Mailing List Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-ID: <20030817224849.GB734@alpha.home.local> References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> <200308171827130739.00C3905F@192.168.128.16> <1061141045.21885.74.camel@dhcp23.swansea.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1061141045.21885.74.camel@dhcp23.swansea.linux.org.uk> User-Agent: Mutt/1.4i X-archive-position: 4915 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@w.ods.org Precedence: bulk X-list: netdev Hi Alan ! On Sun, Aug 17, 2003 at 06:24:06PM +0100, Alan Cox wrote: > So stick the address on eth0 not on lo since its not a loopback but an eth0 > address, then use arpfilter so you don't arp for the invalid magic shared IP > address, or NAT it, or it may work to do > > ip route add nexthop-addr src my-virtual-addr dev eth0 scope local onlink > ip route add default src my-virtual-addr via nexthop-addr dev eth0 scope global I have a case where this doesn't work, and which required me to apply Julian's arp_prefsrc patch, because I couldn't resolve it with iproute alone. This is a fairly simple and certainly common scenario : box A : client router box B +------------+ +---------+ +--------+ ---+ eth0 eth1 +-----+ gateway +------+ server + +------------+ +---------+ +--------+ 10.1 11.1 11.2 12.2 12.3 <-- IP : 10.1 for 10.0.0.1, etc. Network 11 is an interconnect network, it is not known from box B, but B knows how to reach network 10 through the router (12.0.0.2), which also knows how to reach 10 through 11.0.0.1 of course. If I want to be able to reach box B from A (eg for debugging purposes), I need it to join B from its 10.1 address, through gateway 11.2. I do the following on Box A: ip route add 11.0.0.2 src 11.0.0.1 dev eth1 onlink ip route add 12.0.0.3 via 11.0.0.2 src 10.0.0.1 dev eth1 To me, it means that when talking to 12.0.0.3, I bind to source 10.0.0.1, and route through 11.0.0.2, which I obtain the MAC address by asking with a source of 11.0.0.1. But it doesn't work this way : 11.0.0.2 receives ARP requests from 10.0.0.1 and obviously refuses them. But now if I simply ping 11.0.0.2, this one won't work either because box A will still try to request its MAC address with 10.0.0.1 as its source ! So I manually delete the incomplete ARP entry, and ping 11.0.0.2 again. This time, the valid address (11.0.0.1) is used, and I can reach 12.0.0.3 from 10.0.0.1 as long as the ARP entry stays valid. Perhaps this is a standard arp_filter case, but I didn't find how to resolve it, except by using Julian's arp_prefsrc patch which does a lookup of a valid source address to send the ARP request. Now, each time I have these sort of setup and I don't have a patched kernel, I prepare a background ping to feed the ARP cache correctly. And frankly, I don't understand what feature it brings to deliberately use a wrong address as the source for ARP requests. I have searched a long time, but still didn't find any advantage to this behaviour. Reading the code, I don't think it was deliberate, but only a forgotten case. To me, the first route entry above is explicit enough : use 11.0.0.1 as a source when trying to reach 11.0.0.2, so I don't see why ARP requests don't respect this. If you want to reproduce the setup above, you only need ONE host and tcpdump. Simply put the two addresses on the same NIC, add the routes and watch the ARP requests go out with the wrong source. Here is Julian's patch if you want to take a look at it. It seems fairly logical to me, and I don't see what it could break. But again, if you have a way to do something equivalent with iproute or any other standard method, I'd be glad to try. Cheers, Willy --- v2.4.12/linux/net/ipv4/arp.c Tue Sep 25 02:38:23 2001 +++ linux/net/ipv4/arp.c Mon Oct 22 22:58:49 2001 @@ -316,16 +316,19 @@ static void arp_solicit(struct neighbour *neigh, struct sk_buff *skb) { + struct rtable *rt; u32 saddr; u8 *dst_ha = NULL; struct net_device *dev = neigh->dev; u32 target = *(u32*)neigh->primary_key; int probes = atomic_read(&neigh->probes); - if (skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL) - saddr = skb->nh.iph->saddr; - else - saddr = inet_select_addr(dev, target, RT_SCOPE_LINK); + if (ip_route_output(&rt, target, 0, 0, dev->ifindex) < 0) + return; + saddr = rt->rt_src; + ip_rt_put(rt); + if (!saddr) + return; if ((probes -= neigh->parms->ucast_probes) < 0) { if (!(neigh->nud_state&NUD_VALID)) From kuznet@ms2.inr.ac.ru Sun Aug 17 16:30:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 16:30:29 -0700 (PDT) Received: from dub.inr.ac.ru (dub.inr.ac.ru [193.233.7.105]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7HNUOFl018761 for ; Sun, 17 Aug 2003 16:30:25 -0700 Received: (from kuznet@localhost) by dub.inr.ac.ru (8.6.13/ANK) id DAA14889; Mon, 18 Aug 2003 03:29:50 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200308172329.DAA14889@dub.inr.ac.ru> Subject: Re: [PATCH][IPV6] fixed authentication error with TCP To: davem@redhat.com (David S. Miller) Date: Mon, 18 Aug 2003 03:29:50 +0400 (MSD) Cc: kazunori@miyazawa.org, netdev@oss.sgi.com, usagi@linux-ipv6.org, latten@austin.ibm.com In-Reply-To: <20030807220539.4555db2d.davem@redhat.com> from "David S. Miller" at Aug 07, 2003 10:05:39 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4916 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Hello! > But I see a small area for improvement. Look at the place inside > of ip6_dst_lookup() where we do source address selection. If this > fails, we mark error to dst->error. ..... > It seems to me that it is only OK for dst->error to be set on routes > that may not be used validly for anything. > > Alexey, do I understand this stuff correctly? I think you do. And this is rather severe bug than area for improvement. It definitely corrupts routing table. Well, I think switching from function returning error code to a function returning dst is not a very good idea. This never was convenient. In the case of error, IPv6 used to return to caller a dummy reject route, which is always -ENETRUNREACH. So, to do this we have to hold a route for each errno. Returning int was just better. Alexey From acme@conectiva.com.br Sun Aug 17 20:02:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 20:02:38 -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 h7I32VFl021189 for ; Sun, 17 Aug 2003 20:02:32 -0700 Received: from [200.181.168.254] (helo=brinquendo.conectiva.com.br) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 19oaO1-00077B-00; Mon, 18 Aug 2003 00:08:49 -0300 Received: by brinquendo.conectiva.com.br (Postfix, from userid 500) id 1295B1966D; Mon, 18 Aug 2003 03:09:00 +0000 (UTC) Date: Mon, 18 Aug 2003 00:08:59 -0300 From: Arnaldo Carvalho de Melo To: "David S. Miller" , chas@cmf.nrl.navy.mil Cc: Linux Networking Development Mailing List Subject: [PATCH] atm/eni: use skb_queue_walk, not open coded equivalent Message-ID: <20030818030859.GB2853@conectiva.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Url: http://advogato.org/person/acme Organization: Conectiva S.A. User-Agent: Mutt/1.5.4i X-archive-position: 4917 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 Hi Chas, David, Pleae consider pulling from: bk://kernel.bkbits.net/acme/sk_buff-2.6 There is just this trivial outstanding changeset there. - Arnaldo You can import this changeset into BK by piping this whole message to: '| bk receive [path to repository]' or apply the patch as usual. =================================================================== ChangeSet@1.1210, 2003-08-17 23:12:31-03:00, acme@conectiva.com.br o atm/eni: use skb_queue_walk, not open coded equivalent eni.c | 3 +-- 1 files changed, 1 insertion(+), 2 deletions(-) diff -Nru a/drivers/atm/eni.c b/drivers/atm/eni.c --- a/drivers/atm/eni.c Sun Aug 17 23:22:24 2003 +++ b/drivers/atm/eni.c Sun Aug 17 23:22:24 2003 @@ -2019,8 +2019,7 @@ * segmentation buffer descriptors of this VCC. */ tasklet_disable(&eni_dev->task); - for (skb = eni_dev->tx_queue.next; skb != - (struct sk_buff *) &eni_dev->tx_queue; skb = skb->next) { + skb_queue_walk(&eni_dev->tx_queue, skb) { unsigned long dsc; if (ATM_SKB(skb)->vcc != vcc) continue; =================================================================== This BitKeeper patch contains the following changesets: 1.1210 ## Wrapped with gzip_uu ## M'XL( & X0#\ \U476O;,!1]MG[%A<+86&WK2OZ&E&SMV$8'"QE]&B/(LA(' MQU9KR^G&_.,KIZ-IUXZPLH=)0K)UQ=&YYQYT!!>=:C-'R%J1(_B@.Y,Y4C=* MFO56>%+77M[:P%QK&_!+72L_K_RN6N3]0<>,IX2&9[ MD8G[EXT0*B@Y.9!6T:['6ON_B'KR7GH!Q<2F%X?I$&"T9#3'-)=YFJKX:2F? M1AL+E5#DE"4#9R&+=^YY=/2PBY[)E:Q:M9I6K1;E"/-U_/WV)ZHQ1V9G9 ./ M>8*WGDKO.@H]M\Y:B?]9W#;Z]VP#ID]KL(S;'9FN3-@Y*-=.2!Q M'K)Z^<("+PJU=4_,]]O]XY'X*_BY?V]DJ635]?5$Y&D4; Sun, 17 Aug 2003 20:37:14 -0700 Received: from vana.vc.cvut.cz (smmsp@localhost [127.0.0.1]) by vana.vc.cvut.cz (8.12.9/8.12.9/Debian-5) with ESMTP id h7I3bBXb031174; Mon, 18 Aug 2003 05:37:11 +0200 Received: (from root@localhost) by vana.vc.cvut.cz (8.12.9/8.12.9/Debian-5) id h7I3bBFt031172; Mon, 18 Aug 2003 05:37:11 +0200 Date: Mon, 18 Aug 2003 05:37:11 +0200 From: Petr Vandrovec To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: dev_add_pack and hardware checksumming Message-ID: <20030818033711.GA21360@vana.vc.cvut.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-archive-position: 4918 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vandrove@vc.cvut.cz Precedence: bulk X-list: netdev Hi Dave, VMware uses dev_add_pack() for capturing ethernet traffic generated by the host and forwarding it to the guest. Unfortunately skb at the packet filter input is still in CHECKSUM_HW state, while skb->csum is relative to the skb->h.raw and dev_queue_xmit_nit overwrites skb->h.raw with skb->nh.raw. Due to this I have to peek at packet body to detect protocol & its header length, reinitialize skb->h.raw with this knowledge and then finally do skb_checksum_help(). For me it would be best if dev_queue_xmit_nit could just leave skb->h.raw alone, usable for skb_checksum_help(), but I assume that it is not possible due to backward compatibility? Other choice is doing checksumming in dev_queue_xmit_nit itself, before passing skb down to the registered packet handlers. BTW, it looks to me like that an uninitialized value is leaked in UDP's checksum field to the packets tcpdump on the host can capture... Thanks, Petr Vandrovec vandrove@vc.cvut.cz From davem@redhat.com Sun Aug 17 22:19:39 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 22:19:48 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7I5JcFl022482 for ; Sun, 17 Aug 2003 22:19:38 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id WAA03338; Sun, 17 Aug 2003 22:11:55 -0700 Date: Sun, 17 Aug 2003 22:11:55 -0700 From: "David S. Miller" To: insecure@mail.od.ua Cc: arjanv@redhat.com, carlosev@newipnet.com, dhollis@davehollis.com, alan@lxorguk.ukuu.org.uk, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030817221155.2013e6a9.davem@redhat.com> In-Reply-To: <200308172246.12835.insecure@mail.od.ua> References: <200308171845560303.00D4B163@192.168.128.16> <1061140404.29559.0.camel@laptop.fenrus.com> <200308172246.12835.insecure@mail.od.ua> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4919 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sun, 17 Aug 2003 22:46:12 +0300 insecure wrote: > On Sunday 17 August 2003 20:13, Arjan van de Ven wrote: > > > 1. hidden patch is not in the main linuk kernel stream.... why? > > > > because arpfilter is a more generic way of doing things like this, and > > that IS in the main linux kernel > > I am interested in that but last time I googled for it, > neither userspace utils nor any documentation turned up. > I only see some kernel parts of it. The bridging netfilter (ie. "ebtables") maintainer has tools available up on his site. http://ebtables.sourceforge.net/ From davem@redhat.com Sun Aug 17 22:25:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 22:25:41 -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 h7I5PZFl022842 for ; Sun, 17 Aug 2003 22:25:36 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id WAA03383; Sun, 17 Aug 2003 22:18:05 -0700 Date: Sun, 17 Aug 2003 22:18:04 -0700 From: "David S. Miller" To: Martin Diehl Cc: jt@hpl.hp.com, shemminger@osdl.org, irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] (1/5) get rid of useless hashbin in irtty Message-Id: <20030817221804.27e2f07d.davem@redhat.com> In-Reply-To: References: <20030816175851.58a2c179.davem@redhat.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4920 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sun, 17 Aug 2003 19:42:40 +0200 (CEST) Martin Diehl wrote: > try_module_get(netdev->owner) netdev->owner does not exist any more and we don't use module refcounts to manage unload of network devices, it simply is not needed. From davem@redhat.com Sun Aug 17 22:30:08 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 22:30:13 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7I5U8Fl023208 for ; Sun, 17 Aug 2003 22:30:08 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id WAA03426; Sun, 17 Aug 2003 22:22:58 -0700 Date: Sun, 17 Aug 2003 22:22:58 -0700 From: "David S. Miller" To: Willy Tarreau Cc: alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030817222258.257694b9.davem@redhat.com> In-Reply-To: <20030817224849.GB734@alpha.home.local> References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> <200308171827130739.00C3905F@192.168.128.16> <1061141045.21885.74.camel@dhcp23.swansea.linux.org.uk> <20030817224849.GB734@alpha.home.local> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4921 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 00:48:49 +0200 Willy Tarreau wrote: > I have a case where this doesn't work And that's exactly what arpfilter is for. There are zero performance implications from using arpfilter too, if that is something people are worried about. Only ARP packets will go into the netfilter code, all other packet types will bypass netfilter entirely. From davem@redhat.com Sun Aug 17 22:36:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 22:36:39 -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 h7I5aZFl023555 for ; Sun, 17 Aug 2003 22:36:35 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id WAA03450; Sun, 17 Aug 2003 22:29:43 -0700 Date: Sun, 17 Aug 2003 22:29:43 -0700 From: "David S. Miller" To: "Carlos Velasco" Cc: alan@lxorguk.ukuu.org.uk, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030817222943.2fdf9765.davem@redhat.com> In-Reply-To: <200308171555280781.0067FB36@192.168.128.16> References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4922 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sun, 17 Aug 2003 15:55:28 +0200 "Carlos Velasco" wrote: > And you can just use other OS and solve the problem Nobody hacking on Linux feels threatened by this. And if anything, it's the last thing that would make us change Linux to behave one way or another. That would be a stupid reason to make a change to the kernel, just because someone is shitting their pants on some mailing list endlessly about it. So please, go ahead, go use another OS if that suits your needs better, it certainly has no bearing on how we'll make Linux's ARP behave. But the one thing you can't do is accuse us of not providing the facility you need. Your only valid complaint is that the facility doesn't get configured in the way that you would like it to, and frankly my answer to that is "tough". From davem@redhat.com Sun Aug 17 22:38:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 22:38: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 h7I5cLFl023885 for ; Sun, 17 Aug 2003 22:38:21 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id WAA03469; Sun, 17 Aug 2003 22:31:18 -0700 Date: Sun, 17 Aug 2003 22:31:18 -0700 From: "David S. Miller" To: Willy Tarreau Cc: alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030817223118.3cbc497c.davem@redhat.com> In-Reply-To: <20030817224849.GB734@alpha.home.local> References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> <200308171827130739.00C3905F@192.168.128.16> <1061141045.21885.74.camel@dhcp23.swansea.linux.org.uk> <20030817224849.GB734@alpha.home.local> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4923 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 00:48:49 +0200 Willy Tarreau wrote: > On Sun, Aug 17, 2003 at 06:24:06PM +0100, Alan Cox wrote: > > > So stick the address on eth0 not on lo since its not a loopback but an eth0 > > address, then use arpfilter so you don't arp for the invalid magic shared IP > > address, or NAT it, or it may work to do > > > > ip route add nexthop-addr src my-virtual-addr dev eth0 scope local onlink > > ip route add default src my-virtual-addr via nexthop-addr dev eth0 scope global > > I have a case where this doesn't work Replying again... Alan does mention in the paragraph you've quoted to use arpfilter, which works for every case imaginable. The facilities to solve these problems are there, people simply don't want to use them. From davem@redhat.com Sun Aug 17 22:45:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 22:45: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 h7I5jXFl024236 for ; Sun, 17 Aug 2003 22:45:33 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id WAA03510; Sun, 17 Aug 2003 22:38:52 -0700 Date: Sun, 17 Aug 2003 22:38:51 -0700 From: "David S. Miller" To: Petr Vandrovec Cc: netdev@oss.sgi.com Subject: Re: dev_add_pack and hardware checksumming Message-Id: <20030817223851.5185bdee.davem@redhat.com> In-Reply-To: <20030818033711.GA21360@vana.vc.cvut.cz> References: <20030818033711.GA21360@vana.vc.cvut.cz> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4924 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 05:37:11 +0200 Petr Vandrovec wrote: > For me it would be best if dev_queue_xmit_nit could just leave > skb->h.raw alone, The AF_PACKET layer depends upon skb->h.raw being set a certain way. Have a look at the dev_add_pack() registered hooks that net/packet/af_packet.c uses. > Other choice is doing checksumming in dev_queue_xmit_nit itself, > before passing skb down to the registered packet handlers. This is not an option either. We're specifically not going to undo checksum offloading just because tcpdump or some other kind of tap is installed. From val@nmt.edu Sun Aug 17 23:16:38 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 23:16:42 -0700 (PDT) Received: from mailhost.nmt.edu (mailhost.nmt.edu [129.138.4.52]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7I6GbFl025188 for ; Sun, 17 Aug 2003 23:16:38 -0700 Received: from speare5-1-14.nmt.edu (speare5-1-14.nmt.edu [129.138.2.192]) by mailhost.nmt.edu (8.12.9/8.12.10.Beta2) with ESMTP id h7I6FvvL011748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Aug 2003 00:16:02 -0600 Received: from speare5-1-14.nmt.edu (localhost.localdomain [127.0.0.1]) by speare5-1-14.nmt.edu (8.12.8/8.12.8) with ESMTP id h7I6FvMf001272; Mon, 18 Aug 2003 00:15:57 -0600 Received: (from val@localhost) by speare5-1-14.nmt.edu (8.12.8/8.12.8/Submit) id h7I6FBCV001270; Mon, 18 Aug 2003 00:15:11 -0600 Date: Mon, 18 Aug 2003 00:15:11 -0600 From: Val Henson To: Jeff Garzik Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [bk patches] add ethtool_ops to net drivers Message-ID: <20030818061511.GA1255@speare5-1-14> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Favorite-Color: Polka dot X-archive-position: 4925 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: val@nmt.edu Precedence: bulk X-list: netdev I needed the following patch to compile netsyms.c - just a missing include. Thanks, -VAL # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1214 -> 1.1215 # net/netsyms.c 1.93 -> 1.94 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 03/08/17 val@host4.sbcglobal.net 1.1215 # Add missing include for ethtool ops # -------------------------------------------- # diff -Nru a/net/netsyms.c b/net/netsyms.c --- a/net/netsyms.c Sun Aug 17 20:26:07 2003 +++ b/net/netsyms.c Sun Aug 17 20:26:07 2003 @@ -626,6 +626,7 @@ EXPORT_SYMBOL(linkwatch_fire_event); /* ethtool.c */ +#include EXPORT_SYMBOL(ethtool_op_get_link); EXPORT_SYMBOL(ethtool_op_get_tx_csum); EXPORT_SYMBOL(ethtool_op_get_sg); From davem@redhat.com Sun Aug 17 23:21:38 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 23:21: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 h7I6LbFl025584 for ; Sun, 17 Aug 2003 23:21:38 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id XAA03633; Sun, 17 Aug 2003 23:14:54 -0700 Date: Sun, 17 Aug 2003 23:14:53 -0700 From: "David S. Miller" To: Val Henson Cc: jgarzik@pobox.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [bk patches] add ethtool_ops to net drivers Message-Id: <20030817231453.6a31c98a.davem@redhat.com> In-Reply-To: <20030818061511.GA1255@speare5-1-14> References: <20030818061511.GA1255@speare5-1-14> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4926 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 00:15:11 -0600 Val Henson wrote: > I needed the following patch to compile netsyms.c - just a missing > include. It's already in Linus's tree. From davem@redhat.com Sun Aug 17 23:41:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 17 Aug 2003 23:41: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 h7I6fNFl026034 for ; Sun, 17 Aug 2003 23:41:24 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id XAA03703; Sun, 17 Aug 2003 23:34:37 -0700 Date: Sun, 17 Aug 2003 23:34:36 -0700 From: "David S. Miller" To: Arnaldo Carvalho de Melo Cc: chas@cmf.nrl.navy.mil, netdev@oss.sgi.com Subject: Re: [PATCH] atm/eni: use skb_queue_walk, not open coded equivalent Message-Id: <20030817233436.7588bb1b.davem@redhat.com> In-Reply-To: <20030818030859.GB2853@conectiva.com.br> References: <20030818030859.GB2853@conectiva.com.br> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4927 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 00:08:59 -0300 Arnaldo Carvalho de Melo wrote: > Hi Chas, David, > > Pleae consider pulling from: > > bk://kernel.bkbits.net/acme/sk_buff-2.6 > > There is just this trivial outstanding changeset there. Pulled, thanks Arnaldo. From willy@w.ods.org Mon Aug 18 00:03:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 00:03:58 -0700 (PDT) Received: from www.home.local (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7I73oFl026517 for ; Mon, 18 Aug 2003 00:03:52 -0700 Received: from alpha.home.local (alpha [10.0.1.2]) by www.home.local (8.12.1/8.12.1) with ESMTP id h7I6vApn032573; Mon, 18 Aug 2003 08:57:10 +0200 Received: (from willy@localhost) by alpha.home.local (8.12.4/8.12.1) id h7I6uqpG015271; Mon, 18 Aug 2003 08:56:52 +0200 Date: Mon, 18 Aug 2003 08:56:52 +0200 From: Willy Tarreau To: "David S. Miller" Cc: Willy Tarreau , alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-ID: <20030818065652.GA15098@alpha.home.local> References: <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> <200308171827130739.00C3905F@192.168.128.16> <1061141045.21885.74.camel@dhcp23.swansea.linux.org.uk> <20030817224849.GB734@alpha.home.local> <20030817222258.257694b9.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030817222258.257694b9.davem@redhat.com> User-Agent: Mutt/1.4i X-archive-position: 4928 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@w.ods.org Precedence: bulk X-list: netdev Hello David, On Sun, Aug 17, 2003 at 10:22:58PM -0700, David S. Miller wrote: > On Mon, 18 Aug 2003 00:48:49 +0200 > Willy Tarreau wrote: > > > I have a case where this doesn't work > > And that's exactly what arpfilter is for. That's indeed what I was supposing so. > There are zero performance implications from using > arpfilter too, if that is something people are worried > about. I'm not worried about performance, which I can easily imagine is not affected for such rare events as ARP requests. I'm more worried about how to set it up. I have already searched in Documentation/networking, on google, etc... but didn't find any useful information about how to set up an arpfilter configuration. I'd agree to test it, but don't know where to start from. I even don't know if it's related to 'ip arp'. I guess that's what stops most people from using it. Others may even not be aware that this feature exists at all. Other than that, I don't know if the resulting configuration will still be straightforward or look completely tricky. Again, I don't know what we can break by applying the arp_prefsrc patch, which will do the Right Thing most of the time. And when it won't, the current code would also have required arpfilter anyway. But I'm willing to try arpfilter if you show me where to start from. Cheers, Willy From davem@redhat.com Mon Aug 18 00:09:01 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 00:09: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 h7I790Fl026913 for ; Mon, 18 Aug 2003 00:09:01 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id AAA03791; Mon, 18 Aug 2003 00:01:39 -0700 Date: Mon, 18 Aug 2003 00:01:39 -0700 From: "David S. Miller" To: Willy Tarreau Cc: willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030818000139.6964cd04.davem@redhat.com> In-Reply-To: <20030818065652.GA15098@alpha.home.local> References: <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> <200308171827130739.00C3905F@192.168.128.16> <1061141045.21885.74.camel@dhcp23.swansea.linux.org.uk> <20030817224849.GB734@alpha.home.local> <20030817222258.257694b9.davem@redhat.com> <20030818065652.GA15098@alpha.home.local> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4929 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 08:56:52 +0200 Willy Tarreau wrote: > But I'm willing to try arpfilter if you show me where to start from. There are tools at: http://ebtables.sourceforge.net/ From willy@w.ods.org Mon Aug 18 00:36:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 00:36:31 -0700 (PDT) Received: from www.home.local (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7I7aKFl027357 for ; Mon, 18 Aug 2003 00:36:21 -0700 Received: from alpha.home.local (alpha [10.0.1.2]) by www.home.local (8.12.1/8.12.1) with ESMTP id h7I7Tdpn032578; Mon, 18 Aug 2003 09:29:39 +0200 Received: (from willy@localhost) by alpha.home.local (8.12.4/8.12.1) id h7I7TMHs015619; Mon, 18 Aug 2003 09:29:22 +0200 Date: Mon, 18 Aug 2003 09:29:22 +0200 From: Willy Tarreau To: "David S. Miller" Cc: Willy Tarreau , alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-ID: <20030818072922.GB15098@alpha.home.local> References: <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> <200308171827130739.00C3905F@192.168.128.16> <1061141045.21885.74.camel@dhcp23.swansea.linux.org.uk> <20030817224849.GB734@alpha.home.local> <20030817222258.257694b9.davem@redhat.com> <20030818065652.GA15098@alpha.home.local> <20030818000139.6964cd04.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030818000139.6964cd04.davem@redhat.com> User-Agent: Mutt/1.4i X-archive-position: 4930 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@w.ods.org Precedence: bulk X-list: netdev On Mon, Aug 18, 2003 at 12:01:39AM -0700, David S. Miller wrote: > On Mon, 18 Aug 2003 08:56:52 +0200 > Willy Tarreau wrote: > > > But I'm willing to try arpfilter if you show me where to start from. > > There are tools at: > > http://ebtables.sourceforge.net/ Thanks, I've downloaded them and will take a look at them. By the time, I did some random tests with 'ip arp', and found a simple way to solve the problem I reported initially. This can be of interest to others BTW : Trivial example below : My host wants to use address 10.0.0.1 to talk to the world, but through the gateway 11.0.0.2 reachable from 11.0.0.1 : ip address add 10.0.0.1/24 dev eth0 ip address add 11.0.0.1/24 dev eth0 ip route add default via 11.0.0.2 src 10.0.0.1 => same as before till this ip arp append table output to 11.0.0.0/24 oif eth0 src 11.0.0.1 => now it will use 11.0.0.1 to find its gateway (11.0.0.2) So as a general rule of thumb, I would recommend people to systematically call "ip arp append table output to [network] oif [NIC] src [local_ip]" after an "ip address add [local_ip] dev [NIC]". And yes, I agree that these are standard tools, but I maintain that the default behaviour should be cleaner. I also found that I can filter incoming requests easily with "table input" : ip arp append table input deny ip arp add table input allow from 11.0.0.0/24 to 11.0.0.0/24 iif eth0 ip arp add table input allow from 10.0.0.0/24 to 10.0.0.0/24 iif eth0 I don't understand how the forward table is used, BTW, but I'll search a bit more. If I finally understand how all this works, I may propose a simple how-to to put under Documentation/networking/arp.txt so solve most common problems. Cheers, Willy From willy@w.ods.org Mon Aug 18 00:50:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 00:50:54 -0700 (PDT) Received: from www.home.local (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7I7omFl027726 for ; Mon, 18 Aug 2003 00:50:49 -0700 Received: from alpha.home.local (alpha [10.0.1.2]) by www.home.local (8.12.1/8.12.1) with ESMTP id h7I7iEpn032582; Mon, 18 Aug 2003 09:44:14 +0200 Received: (from willy@localhost) by alpha.home.local (8.12.4/8.12.1) id h7I7hwNE015786; Mon, 18 Aug 2003 09:43:58 +0200 Date: Mon, 18 Aug 2003 09:43:58 +0200 From: Willy Tarreau To: "David S. Miller" Cc: Willy Tarreau , alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-ID: <20030818074358.GA15633@alpha.home.local> References: <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> <200308171827130739.00C3905F@192.168.128.16> <1061141045.21885.74.camel@dhcp23.swansea.linux.org.uk> <20030817224849.GB734@alpha.home.local> <20030817222258.257694b9.davem@redhat.com> <20030818065652.GA15098@alpha.home.local> <20030818000139.6964cd04.davem@redhat.com> <20030818072922.GB15098@alpha.home.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030818072922.GB15098@alpha.home.local> User-Agent: Mutt/1.4i X-archive-position: 4931 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@w.ods.org Precedence: bulk X-list: netdev Hmmm replying to myself ! > So as a general rule of thumb, I would recommend people to systematically call > "ip arp append table output to [network] oif [NIC] src [local_ip]" after an > "ip address add [local_ip] dev [NIC]". And yes, I agree that these are > standard tools, but I maintain that the default behaviour should be cleaner. In fact, not standard. 'ip arp' was brought by Julian Anastasov's iproute2-iparp-3 patch on top of iproute2. But it seems to do wonderful things. Cheers, Willy From davem@redhat.com Mon Aug 18 00:53:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 00:53:45 -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 h7I7reFl028043 for ; Mon, 18 Aug 2003 00:53:41 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id AAA03933; Mon, 18 Aug 2003 00:45:22 -0700 Date: Mon, 18 Aug 2003 00:45:22 -0700 From: "David S. Miller" To: Ville Nuorvala Cc: kuznet@ms2.inr.ac.ru, kazunori@miyazawa.org, netdev@oss.sgi.com, usagi@linux-ipv6.org, latten@austin.ibm.com Subject: Re: [PATCH][IPV6] fixed authentication error with TCP Message-Id: <20030818004522.458a97b9.davem@redhat.com> In-Reply-To: References: <200308172329.DAA14889@dub.inr.ac.ru> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4932 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 10:45:41 +0300 (EEST) Ville Nuorvala wrote: > The attached patch reverts to the old ip6_dst_lookup() interface and and > makes tcp_ipv6.c use that instead. > > As an added bonus neither tcp_v6_connect() nor udpv6_connect() needs to do > source address selection anymore, since ip6_dst_lookup() already does this > for them. Thanks a lot for doing this work, I'll review and apply your patch. I was about to code this up myself :) From vnuorval@tcs.hut.fi Mon Aug 18 01:13:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 01:13:22 -0700 (PDT) Received: from mail.tcs.hut.fi (mail.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7I8DEFl028517 for ; Mon, 18 Aug 2003 01:13:15 -0700 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by mail.tcs.hut.fi (Postfix) with ESMTP id 1F9188001BD; Mon, 18 Aug 2003 11:13:14 +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 h7I8DE5L018687; Mon, 18 Aug 2003 11:13:14 +0300 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-5) with ESMTP id h7I8DD82018683; Mon, 18 Aug 2003 11:13:13 +0300 Date: Mon, 18 Aug 2003 11:13:13 +0300 (EEST) From: Ville Nuorvala To: davem@redhat.com, Cc: netdev@oss.sgi.com Subject: [PATCH] IPv6: fix dst leakage caused by rt6_cow() In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: X-archive-position: 4933 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Hi, since rt6_cow() calls dst_hold() it looks like we're leaking refcounts in three places in route.c. The patch below should fix this. --- linux-2.5.OLD/net/ipv6/route.c 2003-08-18 10:04:24.000000000 +0300 +++ linux-2.5/net/ipv6/route.c 2003-08-15 16:20:19.000000000 +0300 @@ -432,6 +432,7 @@ /* Race condition! In the gap, when rt6_lock was released someone could insert this route. Relookup. */ + dst_release(&rt->u.dst); goto relookup; } dst_hold(&rt->u.dst); @@ -486,6 +487,7 @@ /* Race condition! In the gap, when rt6_lock was released someone could insert this route. Relookup. */ + dst_release(&rt->u.dst); goto relookup; } dst_hold(&rt->u.dst); @@ -1094,8 +1096,8 @@ */ dst_set_expires(&nrt->u.dst, ip6_rt_mtu_expires); nrt->rt6i_flags |= RTF_DYNAMIC|RTF_EXPIRES; - dst_release(&nrt->u.dst); } + dst_release(&nrt->u.dst); } else { nrt = ip6_rt_copy(rt); if (nrt == NULL) Thanks, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From vnuorval@tcs.hut.fi Mon Aug 18 01:26:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 01:27:02 -0700 (PDT) Received: from mail.tcs.hut.fi (mail.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7I8QcFl028891 for ; Mon, 18 Aug 2003 01:26:39 -0700 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by mail.tcs.hut.fi (Postfix) with ESMTP id 5642E80019B; Mon, 18 Aug 2003 10:45:45 +0300 (EEST) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-5) with ESMTP id h7I7jj5L018616; Mon, 18 Aug 2003 10:45:45 +0300 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-5) with ESMTP id h7I7jfKv018612; Mon, 18 Aug 2003 10:45:41 +0300 Date: Mon, 18 Aug 2003 10:45:41 +0300 (EEST) From: Ville Nuorvala To: kuznet@ms2.inr.ac.ru, "David S. Miller" , Cc: netdev@oss.sgi.com, , Subject: Re: [PATCH][IPV6] fixed authentication error with TCP In-Reply-To: <200308172329.DAA14889@dub.inr.ac.ru> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-377318441-404174682-1061192741=:18400" X-archive-position: 4934 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---377318441-404174682-1061192741=:18400 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 18 Aug 2003 kuznet@ms2.inr.ac.ru wrote: > Hello! > > > But I see a small area for improvement. Look at the place inside > > of ip6_dst_lookup() where we do source address selection. If this > > fails, we mark error to dst->error. > ..... > > It seems to me that it is only OK for dst->error to be set on routes > > that may not be used validly for anything. > > > > Alexey, do I understand this stuff correctly? > > I think you do. And this is rather severe bug than area for improvement. > It definitely corrupts routing table. Besides this, the patch also introduced dst_entry leaks in at least icmp.c, raw.c and udp.c. > > Well, I think switching from function returning error code to a function > returning dst is not a very good idea. This never was convenient. > In the case of error, IPv6 used to return to caller a dummy reject route, > which is always -ENETRUNREACH. So, to do this we have to hold a route > for each errno. Returning int was just better. The attached patch reverts to the old ip6_dst_lookup() interface and and makes tcp_ipv6.c use that instead. As an added bonus neither tcp_v6_connect() nor udpv6_connect() needs to do source address selection anymore, since ip6_dst_lookup() already does this for them. > > Alexey I've tested the patch a bit and everything seems to work normally, so its probably safe to apply it :) Thanks, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 ---377318441-404174682-1061192741=:18400 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="ip6_dst_lookup.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="ip6_dst_lookup.patch" ZGlmZiAtTnVyIC0tZXhjbHVkZT1SQ1MgLS1leGNsdWRlPUNWUyAtLWV4Y2x1 ZGU9U0NDUyAtLWV4Y2x1ZGU9Qml0S2VlcGVyIC0tZXhjbHVkZT1DaGFuZ2VT ZXQgbGludXgtMi41Lk9MRC9pbmNsdWRlL25ldC9pcHY2LmggbGludXgtMi41 L2luY2x1ZGUvbmV0L2lwdjYuaA0KLS0tIGxpbnV4LTIuNS5PTEQvaW5jbHVk ZS9uZXQvaXB2Ni5oCU1vbiBBdWcgMTggMTA6MDQ6MDcgMjAwMw0KKysrIGxp bnV4LTIuNS9pbmNsdWRlL25ldC9pcHY2LmgJRnJpIEF1ZyAxNSAxMzoyOTow MCAyMDAzDQpAQCAtMzUzLDcgKzM1Myw5IEBADQogDQogZXh0ZXJuIHZvaWQJ CQlpcDZfZmx1c2hfcGVuZGluZ19mcmFtZXMoc3RydWN0IHNvY2sgKnNrKTsN CiANCi1leHRlcm4gc3RydWN0IGRzdF9lbnRyeSAqCWlwNl9kc3RfbG9va3Vw KHN0cnVjdCBzb2NrICpzaywgc3RydWN0IGZsb3dpICpmbCk7DQorZXh0ZXJu IGludAkJCWlwNl9kc3RfbG9va3VwKHN0cnVjdCBzb2NrICpzaywNCisJCQkJ CSAgICAgICBzdHJ1Y3QgZHN0X2VudHJ5ICoqZHN0LA0KKwkJCQkJICAgICAg IHN0cnVjdCBmbG93aSAqZmwpOw0KIA0KIC8qDQogICoJc2tiIHByb2Nlc3Np bmcgZnVuY3Rpb25zDQpkaWZmIC1OdXIgLS1leGNsdWRlPVJDUyAtLWV4Y2x1 ZGU9Q1ZTIC0tZXhjbHVkZT1TQ0NTIC0tZXhjbHVkZT1CaXRLZWVwZXIgLS1l eGNsdWRlPUNoYW5nZVNldCBsaW51eC0yLjUuT0xEL25ldC9pcHY2L2ljbXAu YyBsaW51eC0yLjUvbmV0L2lwdjYvaWNtcC5jDQotLS0gbGludXgtMi41Lk9M RC9uZXQvaXB2Ni9pY21wLmMJTW9uIEF1ZyAxOCAxMDowNDoyMyAyMDAzDQor KysgbGludXgtMi41L25ldC9pcHY2L2ljbXAuYwlGcmkgQXVnIDE1IDEzOjI5 OjAzIDIwMDMNCkBAIC0zNTUsOCArMzU1LDggQEANCiAJaWYgKCFmbC5vaWYg JiYgaXB2Nl9hZGRyX2lzX211bHRpY2FzdCgmZmwuZmw2X2RzdCkpDQogCQlm bC5vaWYgPSBucC0+bWNhc3Rfb2lmOw0KIA0KLQlkc3QgPSBpcDZfZHN0X2xv b2t1cChzaywgJmZsKTsNCi0JaWYgKGRzdC0+ZXJyb3IpIGdvdG8gb3V0Ow0K KwllcnIgPSBpcDZfZHN0X2xvb2t1cChzaywgJmRzdCwgJmZsKTsNCisJaWYg KGVycikgZ290byBvdXQ7DQogDQogCWlmIChobGltaXQgPCAwKSB7DQogCQlp ZiAoaXB2Nl9hZGRyX2lzX211bHRpY2FzdCgmZmwuZmw2X2RzdCkpDQpAQCAt NDM0LDkgKzQzNCw5IEBADQogCWlmICghZmwub2lmICYmIGlwdjZfYWRkcl9p c19tdWx0aWNhc3QoJmZsLmZsNl9kc3QpKQ0KIAkJZmwub2lmID0gbnAtPm1j YXN0X29pZjsNCiANCi0JZHN0ID0gaXA2X2RzdF9sb29rdXAoc2ssICZmbCk7 DQorCWVyciA9IGlwNl9kc3RfbG9va3VwKHNrLCAmZHN0LCAmZmwpOw0KIA0K LQlpZiAoZHN0LT5lcnJvcikgZ290byBvdXQ7DQorCWlmIChlcnIpIGdvdG8g b3V0Ow0KIA0KIAlpZiAoaGxpbWl0IDwgMCkgew0KIAkJaWYgKGlwdjZfYWRk cl9pc19tdWx0aWNhc3QoJmZsLmZsNl9kc3QpKQ0KZGlmZiAtTnVyIC0tZXhj bHVkZT1SQ1MgLS1leGNsdWRlPUNWUyAtLWV4Y2x1ZGU9U0NDUyAtLWV4Y2x1 ZGU9Qml0S2VlcGVyIC0tZXhjbHVkZT1DaGFuZ2VTZXQgbGludXgtMi41Lk9M RC9uZXQvaXB2Ni9pcDZfb3V0cHV0LmMgbGludXgtMi41L25ldC9pcHY2L2lw Nl9vdXRwdXQuYw0KLS0tIGxpbnV4LTIuNS5PTEQvbmV0L2lwdjYvaXA2X291 dHB1dC5jCU1vbiBBdWcgMTggMTA6MDQ6MjMgMjAwMw0KKysrIGxpbnV4LTIu NS9uZXQvaXB2Ni9pcDZfb3V0cHV0LmMJRnJpIEF1ZyAxNSAxMzo1MToxMSAy MDAzDQpAQCAtMTEzNiwxNyArMTEzNiwxNiBAQA0KIAlyZXR1cm4gZXJyOw0K IH0NCiANCi1zdHJ1Y3QgZHN0X2VudHJ5ICppcDZfZHN0X2xvb2t1cChzdHJ1 Y3Qgc29jayAqc2ssIHN0cnVjdCBmbG93aSAqZmwpDQoraW50IGlwNl9kc3Rf bG9va3VwKHN0cnVjdCBzb2NrICpzaywgc3RydWN0IGRzdF9lbnRyeSAqKmRz dCwgc3RydWN0IGZsb3dpICpmbCkNCiB7DQotCXN0cnVjdCBkc3RfZW50cnkg KmRzdCA9IE5VTEw7DQogCWludCBlcnIgPSAwOw0KIA0KIAlpZiAoc2spIHsN CiAJCXN0cnVjdCBpcHY2X3BpbmZvICpucCA9IGluZXQ2X3NrKHNrKTsNCiAJ DQotCQlkc3QgPSBfX3NrX2RzdF9jaGVjayhzaywgbnAtPmRzdF9jb29raWUp Ow0KLQkJaWYgKGRzdCkgew0KLQkJCXN0cnVjdCBydDZfaW5mbyAqcnQgPSAo c3RydWN0IHJ0Nl9pbmZvKilkc3Q7DQorCQkqZHN0ID0gX19za19kc3RfY2hl Y2soc2ssIG5wLT5kc3RfY29va2llKTsNCisJCWlmICgqZHN0KSB7DQorCQkJ c3RydWN0IHJ0Nl9pbmZvICpydCA9IChzdHJ1Y3QgcnQ2X2luZm8qKSpkc3Q7 DQogCQ0KIAkJCQkvKiBZZXMsIGNoZWNraW5nIHJvdXRlIHZhbGlkaXR5IGlu IG5vdCBjb25uZWN0ZWQNCiAJCQkJICAgY2FzZSBpcyBub3QgdmVyeSBzaW1w bGUuIFRha2UgaW50byBhY2NvdW50LA0KQEAgLTExNzAsMzkgKzExNjksMzgg QEANCiAJCQkgICAgICBpcHY2X2FkZHJfY21wKCZmbC0+Zmw2X2RzdCwgJnJ0 LT5ydDZpX2RzdC5hZGRyKSkNCiAJCQkgICAgICYmIChucC0+ZGFkZHJfY2Fj aGUgPT0gTlVMTCB8fA0KIAkJCQkgaXB2Nl9hZGRyX2NtcCgmZmwtPmZsNl9k c3QsIG5wLT5kYWRkcl9jYWNoZSkpKQ0KLQkJCSAgICB8fCAoZmwtPm9pZiAm JiBmbC0+b2lmICE9IGRzdC0+ZGV2LT5pZmluZGV4KSkgew0KLQkJCQlkc3Qg PSBOVUxMOw0KKwkJCSAgICB8fCAoZmwtPm9pZiAmJiBmbC0+b2lmICE9ICgq ZHN0KS0+ZGV2LT5pZmluZGV4KSkgew0KKwkJCQkqZHN0ID0gTlVMTDsNCiAJ CQl9IGVsc2UNCi0JCQkJZHN0X2hvbGQoZHN0KTsNCisJCQkJZHN0X2hvbGQo KmRzdCk7DQogCQl9DQogCX0NCiANCi0JaWYgKGRzdCA9PSBOVUxMKQ0KLQkJ ZHN0ID0gaXA2X3JvdXRlX291dHB1dChzaywgZmwpOw0KLQ0KLQlpZiAoZHN0 LT5lcnJvcikNCi0JCXJldHVybiBkc3Q7DQorCWlmICgqZHN0ID09IE5VTEwp DQorCQkqZHN0ID0gaXA2X3JvdXRlX291dHB1dChzaywgZmwpOw0KIA0KKwlp ZiAoKGVyciA9ICgqZHN0KS0+ZXJyb3IpKSB7DQorCQlkc3RfcmVsZWFzZSgq ZHN0KTsNCisJCXJldHVybiBlcnI7DQorCX0NCiAJaWYgKGlwdjZfYWRkcl9h bnkoJmZsLT5mbDZfc3JjKSkgew0KLQkJZXJyID0gaXB2Nl9nZXRfc2FkZHIo ZHN0LCAmZmwtPmZsNl9kc3QsICZmbC0+Zmw2X3NyYyk7DQorCQllcnIgPSBp cHY2X2dldF9zYWRkcigqZHN0LCAmZmwtPmZsNl9kc3QsICZmbC0+Zmw2X3Ny Yyk7DQogDQogCQlpZiAoZXJyKSB7DQogI2lmIElQNl9ERUJVRyA+PSAyDQot CQkJcHJpbnRrKEtFUk5fREVCVUcgImlwNl9idWlsZF94bWl0OiAiDQorCQkJ cHJpbnRrKEtFUk5fREVCVUcgImlwNl9kc3RfbG9va3VwOiAiDQogCQkJICAg ICAgICJubyBhdmFpbGFibGUgc291cmNlIGFkZHJlc3NcbiIpOw0KICNlbmRp Zg0KLQkJCWRzdC0+ZXJyb3IgPSBlcnI7DQotCQkJcmV0dXJuIGRzdDsNCisJ CQlkc3RfcmVsZWFzZSgqZHN0KTsNCisJCQlyZXR1cm4gZXJyOw0KIAkJfQ0K IAl9DQotDQotICAgICAgICBpZiAoZHN0KSB7DQotCQlpZiAoKGVyciA9IHhm cm1fbG9va3VwKCZkc3QsIGZsLCBzaywgMCkpIDwgMCkgew0KLQkJCWRzdC0+ ZXJyb3IgPSAtRU5FVFVOUkVBQ0g7DQotCQl9DQorCWlmICgoZXJyID0geGZy bV9sb29rdXAoZHN0LCBmbCwgc2ssIDApKSA8IDApIHsNCisJCWRzdF9yZWxl YXNlKCpkc3QpOw0KKwkJcmV0dXJuIC1FTkVUVU5SRUFDSDsNCiAgICAgICAg IH0NCiANCi0JcmV0dXJuIGRzdDsNCisJcmV0dXJuIDA7DQogfQ0KIA0KIGlu dCBpcDZfYXBwZW5kX2RhdGEoc3RydWN0IHNvY2sgKnNrLCBpbnQgZ2V0ZnJh Zyh2b2lkICpmcm9tLCBjaGFyICp0bywgaW50IG9mZnNldCwgaW50IGxlbiwg aW50IG9kZCwgc3RydWN0IHNrX2J1ZmYgKnNrYiksDQpkaWZmIC1OdXIgLS1l eGNsdWRlPVJDUyAtLWV4Y2x1ZGU9Q1ZTIC0tZXhjbHVkZT1TQ0NTIC0tZXhj bHVkZT1CaXRLZWVwZXIgLS1leGNsdWRlPUNoYW5nZVNldCBsaW51eC0yLjUu T0xEL25ldC9pcHY2L3Jhdy5jIGxpbnV4LTIuNS9uZXQvaXB2Ni9yYXcuYw0K LS0tIGxpbnV4LTIuNS5PTEQvbmV0L2lwdjYvcmF3LmMJTW9uIEF1ZyAxOCAx MDowNDoyNCAyMDAzDQorKysgbGludXgtMi41L25ldC9pcHY2L3Jhdy5jCUZy aSBBdWcgMTUgMTM6MzM6MTQgMjAwMw0KQEAgLTY1OCw4ICs2NTgsOCBAQA0K IAlpZiAoIWZsLm9pZiAmJiBpcHY2X2FkZHJfaXNfbXVsdGljYXN0KCZmbC5m bDZfZHN0KSkNCiAJCWZsLm9pZiA9IG5wLT5tY2FzdF9vaWY7DQogDQotCWRz dCA9IGlwNl9kc3RfbG9va3VwKHNrLCAmZmwpOw0KLQlpZiAoKGVyciA9IGRz dC0+ZXJyb3IpKQ0KKwllcnIgPSBpcDZfZHN0X2xvb2t1cChzaywgJmRzdCwg JmZsKTsNCisJaWYgKGVycikNCiAJCWdvdG8gb3V0Ow0KIA0KIAlpZiAoaGxp bWl0IDwgMCkgew0KZGlmZiAtTnVyIC0tZXhjbHVkZT1SQ1MgLS1leGNsdWRl PUNWUyAtLWV4Y2x1ZGU9U0NDUyAtLWV4Y2x1ZGU9Qml0S2VlcGVyIC0tZXhj bHVkZT1DaGFuZ2VTZXQgbGludXgtMi41Lk9MRC9uZXQvaXB2Ni90Y3BfaXB2 Ni5jIGxpbnV4LTIuNS9uZXQvaXB2Ni90Y3BfaXB2Ni5jDQotLS0gbGludXgt Mi41Lk9MRC9uZXQvaXB2Ni90Y3BfaXB2Ni5jCU1vbiBBdWcgMTggMTA6MDQ6 MjQgMjAwMw0KKysrIGxpbnV4LTIuNS9uZXQvaXB2Ni90Y3BfaXB2Ni5jCUZy aSBBdWcgMTUgMTc6MjQ6MDYgMjAwMw0KQEAgLTY2MywxOSArNjYzLDEyIEBA DQogCQlpcHY2X2FkZHJfY29weSgmZmwuZmw2X2RzdCwgcnQwLT5hZGRyKTsN CiAJfQ0KIA0KLQlkc3QgPSBpcDZfZHN0X2xvb2t1cChzaywgJmZsKTsNCisJ ZXJyID0gaXA2X2RzdF9sb29rdXAoc2ssICZkc3QsICZmbCk7DQogDQotCWlm ICgoZXJyID0gZHN0LT5lcnJvcikgIT0gMCkgew0KLQkJZHN0X3JlbGVhc2Uo ZHN0KTsNCisJaWYgKGVycikNCiAJCWdvdG8gZmFpbHVyZTsNCi0JfQ0KIA0K IAlpZiAoc2FkZHIgPT0gTlVMTCkgew0KLQkJZXJyID0gaXB2Nl9nZXRfc2Fk ZHIoZHN0LCAmbnAtPmRhZGRyLCAmZmwuZmw2X3NyYyk7DQotCQlpZiAoZXJy KSB7DQotCQkJZHN0X3JlbGVhc2UoZHN0KTsNCi0JCQlnb3RvIGZhaWx1cmU7 DQotCQl9DQogCQlzYWRkciA9ICZmbC5mbDZfc3JjOw0KIAkJaXB2Nl9hZGRy X2NvcHkoJm5wLT5yY3Zfc2FkZHIsIHNhZGRyKTsNCiAJfQ0KQEAgLTc5MCwx MyArNzgzLDE0IEBADQogCQkJZmwuZmxfaXBfZHBvcnQgPSBpbmV0LT5kcG9y dDsNCiAJCQlmbC5mbF9pcF9zcG9ydCA9IGluZXQtPnNwb3J0Ow0KIA0KLQkJ CWRzdCA9IGlwNl9kc3RfbG9va3VwKHNrLCAmZmwpOw0KKwkJCWlmICgoZXJy ID0gaXA2X2RzdF9sb29rdXAoc2ssICZkc3QsICZmbCkpKSB7DQorCQkJCXNr LT5za19lcnJfc29mdCA9IC1lcnI7DQorCQkJCWdvdG8gb3V0Ow0KKwkJCX0N CiAJCX0gZWxzZQ0KIAkJCWRzdF9ob2xkKGRzdCk7DQogDQotCQlpZiAoZHN0 LT5lcnJvcikgew0KLQkJCXNrLT5za19lcnJfc29mdCA9IC1kc3QtPmVycm9y Ow0KLQkJfSBlbHNlIGlmICh0cC0+cG10dV9jb29raWUgPiBkc3RfcG10dShk c3QpKSB7DQorCQlpZiAodHAtPnBtdHVfY29va2llID4gZHN0X3BtdHUoZHN0 KSkgew0KIAkJCXRjcF9zeW5jX21zcyhzaywgZHN0X3BtdHUoZHN0KSk7DQog CQkJdGNwX3NpbXBsZV9yZXRyYW5zbWl0KHNrKTsNCiAJCX0gLyogZWxzZSBs ZXQgdGhlIHVzdWFsIHJldHJhbnNtaXQgdGltZXIgaGFuZGxlIGl0ICovDQpA QCAtODkxLDggKzg4NSw4IEBADQogCQkJaXB2Nl9hZGRyX2NvcHkoJmZsLmZs Nl9kc3QsIHJ0MC0+YWRkcik7DQogCQl9DQogDQotCQlkc3QgPSBpcDZfZHN0 X2xvb2t1cChzaywgJmZsKTsNCi0JCWlmIChkc3QtPmVycm9yKQ0KKwkJZXJy ID0gaXA2X2RzdF9sb29rdXAoc2ssICZkc3QsICZmbCk7DQorCQlpZiAoZXJy KQ0KIAkJCWdvdG8gZG9uZTsNCiAJfQ0KIA0KQEAgLTEwMjAsOSArMTAxNCw3 IEBADQogCWZsLmZsX2lwX3Nwb3J0ID0gdDEtPnNvdXJjZTsNCiANCiAJLyog c2sgPSBOVUxMLCBidXQgaXQgaXMgc2FmZSBmb3Igbm93LiBSU1Qgc29ja2V0 IHJlcXVpcmVkLiAqLw0KLQlidWZmLT5kc3QgPSBpcDZfZHN0X2xvb2t1cChO VUxMLCAmZmwpOw0KLQ0KLQlpZiAoYnVmZi0+ZHN0LT5lcnJvciA9PSAwKSB7 DQorCWlmICghaXA2X2RzdF9sb29rdXAoTlVMTCwgJmJ1ZmYtPmRzdCwgJmZs KSkgew0KIAkJaXA2X3htaXQoTlVMTCwgYnVmZiwgJmZsLCBOVUxMLCAwKTsN CiAJCVRDUF9JTkNfU1RBVFNfQkgoVGNwT3V0U2Vncyk7DQogCQlUQ1BfSU5D X1NUQVRTX0JIKFRjcE91dFJzdHMpOw0KQEAgLTEwODMsOSArMTA3NSw3IEBA DQogCWZsLmZsX2lwX2Rwb3J0ID0gdDEtPmRlc3Q7DQogCWZsLmZsX2lwX3Nw b3J0ID0gdDEtPnNvdXJjZTsNCiANCi0JYnVmZi0+ZHN0ID0gaXA2X2RzdF9s b29rdXAoTlVMTCwgJmZsKTsNCi0NCi0JaWYgKGJ1ZmYtPmRzdC0+ZXJyb3Ig PT0gMCkgew0KKwlpZiAoIWlwNl9kc3RfbG9va3VwKE5VTEwsICZidWZmLT5k c3QsICZmbCkpIHsNCiAJCWlwNl94bWl0KE5VTEwsIGJ1ZmYsICZmbCwgTlVM TCwgMCk7DQogCQlUQ1BfSU5DX1NUQVRTX0JIKFRjcE91dFNlZ3MpOw0KIAkJ cmV0dXJuOw0KQEAgLTEzMzEsMTEgKzEzMjEsOSBAQA0KIAkJZmwuZmxfaXBf ZHBvcnQgPSByZXEtPnJtdF9wb3J0Ow0KIAkJZmwuZmxfaXBfc3BvcnQgPSBp bmV0X3NrKHNrKS0+c3BvcnQ7DQogDQotCQlkc3QgPSBpcDZfZHN0X2xvb2t1 cChzaywgJmZsKTsNCi0JfQ0KLQ0KLQlpZiAoZHN0LT5lcnJvcikNCi0JCWdv dG8gb3V0Ow0KKwkJaWYgKGlwNl9kc3RfbG9va3VwKHNrLCAmZHN0LCAmZmwp KQ0KKwkJCWdvdG8gb3V0Ow0KKwl9IA0KIA0KIAluZXdzayA9IHRjcF9jcmVh dGVfb3BlbnJlcV9jaGlsZChzaywgcmVxLCBza2IpOw0KIAlpZiAobmV3c2sg PT0gTlVMTCkNCkBAIC0xNzMwLDExICsxNzE4LDkgQEANCiAJCQlpcHY2X2Fk ZHJfY29weSgmZmwuZmw2X2RzdCwgcnQwLT5hZGRyKTsNCiAJCX0NCiANCi0J CWRzdCA9IGlwNl9kc3RfbG9va3VwKHNrLCAmZmwpOw0KKwkJZXJyID0gaXA2 X2RzdF9sb29rdXAoc2ssICZkc3QsICZmbCk7DQogDQotCQlpZiAoZHN0LT5l cnJvcikgew0KLQkJCWVyciA9IGRzdC0+ZXJyb3I7DQotCQkJZHN0X3JlbGVh c2UoZHN0KTsNCisJCWlmIChlcnIpIHsNCiAJCQlzay0+c2tfcm91dGVfY2Fw cyA9IDA7DQogCQkJcmV0dXJuIGVycjsNCiAJCX0NCkBAIC0xNzczLDEyICsx NzU5LDExIEBADQogCWRzdCA9IF9fc2tfZHN0X2NoZWNrKHNrLCBucC0+ZHN0 X2Nvb2tpZSk7DQogDQogCWlmIChkc3QgPT0gTlVMTCkgew0KLQkJZHN0ID0g aXA2X2RzdF9sb29rdXAoc2ssICZmbCk7DQorCQlpbnQgZXJyID0gaXA2X2Rz dF9sb29rdXAoc2ssICZkc3QsICZmbCk7DQogDQotCQlpZiAoZHN0LT5lcnJv cikgew0KLQkJCXNrLT5za19lcnJfc29mdCA9IC1kc3QtPmVycm9yOw0KLQkJ CWRzdF9yZWxlYXNlKGRzdCk7DQotCQkJcmV0dXJuIC1zay0+c2tfZXJyX3Nv ZnQ7DQorCQlpZiAoZXJyKSB7DQorCQkJc2stPnNrX2Vycl9zb2Z0ID0gLWVy cjsNCisJCQlyZXR1cm4gZXJyOw0KIAkJfQ0KIA0KIAkJaXA2X2RzdF9zdG9y ZShzaywgZHN0LCBOVUxMKTsNCmRpZmYgLU51ciAtLWV4Y2x1ZGU9UkNTIC0t ZXhjbHVkZT1DVlMgLS1leGNsdWRlPVNDQ1MgLS1leGNsdWRlPUJpdEtlZXBl ciAtLWV4Y2x1ZGU9Q2hhbmdlU2V0IGxpbnV4LTIuNS5PTEQvbmV0L2lwdjYv dWRwLmMgbGludXgtMi41L25ldC9pcHY2L3VkcC5jDQotLS0gbGludXgtMi41 Lk9MRC9uZXQvaXB2Ni91ZHAuYwlNb24gQXVnIDE4IDEwOjA0OjI0IDIwMDMN CisrKyBsaW51eC0yLjUvbmV0L2lwdjYvdWRwLmMJRnJpIEF1ZyAxNSAxMzoz NDoyOCAyMDAzDQpAQCAtMzMwLDIxICszMzAsMTEgQEANCiAJCWlwdjZfYWRk cl9jb3B5KCZmbC5mbDZfZHN0LCBydDAtPmFkZHIpOw0KIAl9DQogDQotCWRz dCA9IGlwNl9yb3V0ZV9vdXRwdXQoc2ssICZmbCk7DQotDQotCWlmICgoZXJy ID0gZHN0LT5lcnJvcikgIT0gMCkgew0KLQkJZHN0X3JlbGVhc2UoZHN0KTsN CisJZXJyID0gaXA2X2RzdF9sb29rdXAoc2ssICZkc3QsICZmbCk7DQorCWlm IChlcnIpDQogCQlnb3RvIG91dDsNCi0JfQ0KLQ0KLQkvKiBnZXQgdGhlIHNv dXJjZSBhZGRyZXNzIHVzZWQgaW4gdGhlIGFwcHJvcHJpYXRlIGRldmljZSAq Lw0KIA0KLQllcnIgPSBpcHY2X2dldF9zYWRkcihkc3QsIGRhZGRyLCAmZmwu Zmw2X3NyYyk7DQotDQotCWlmIChlcnIpIHsNCi0JCWRzdF9yZWxlYXNlKGRz dCk7DQotCQlnb3RvIG91dDsNCi0JfQ0KKwkvKiBzb3VyY2UgYWRkcmVzcyBs b29rdXAgZG9uZSBpbiBpcDZfZHN0X2xvb2t1cCAqLw0KIA0KIAlpZiAoaXB2 Nl9hZGRyX2FueSgmbnAtPnNhZGRyKSkNCiAJCWlwdjZfYWRkcl9jb3B5KCZu cC0+c2FkZHIsICZmbC5mbDZfc3JjKTsNCkBAIC05MzAsOCArOTIwLDggQEAN CiAJaWYgKCFmbC5vaWYgJiYgaXB2Nl9hZGRyX2lzX211bHRpY2FzdCgmZmwu Zmw2X2RzdCkpDQogCQlmbC5vaWYgPSBucC0+bWNhc3Rfb2lmOw0KIA0KLQlk c3QgPSBpcDZfZHN0X2xvb2t1cChzaywgJmZsKTsNCi0JaWYgKChlcnIgPSBk c3QtPmVycm9yKSkNCisJZXJyID0gaXA2X2RzdF9sb29rdXAoc2ssICZkc3Qs ICZmbCk7DQorCWlmIChlcnIpDQogCQlnb3RvIG91dDsNCiANCiAJaWYgKGhs aW1pdCA8IDApIHsNCg== ---377318441-404174682-1061192741=:18400-- From tv@tv.debian.net Mon Aug 18 02:13:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 02:13:38 -0700 (PDT) Received: from yin.wanderer.org (yin.wanderer.org [195.218.87.139]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7I9DNFl030083 for ; Mon, 18 Aug 2003 02:13:27 -0700 Received: by yin.wanderer.org (Postfix, from userid 1000) id 81899ACD5; Mon, 18 Aug 2003 12:13:20 +0300 (EEST) Date: Mon, 18 Aug 2003 12:13:12 +0300 X-OfflineIMAP-673465541-72656d6f74652d74764074762e64656269616e2e6e6574-494e424f582e6f7574626f78: 1061198001-0349853104509 From: Tommi Virtanen To: netdev@oss.sgi.com Subject: [PATCH] Change MAC without bringing interface down Message-ID: <20030818091312.GA4889@lapdog> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-archive-position: 4935 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tv@debian.org Precedence: bulk X-list: netdev Hi. There are cases when you want to change your MAC address, such as in Linux-HA when the other box fails, and your hot standby activates itself. Some NICs, such as e100, e1000 and uml ;) allow you to do that without bringing the interface down. Which is nice, because it allows the link to stay up, and not make switches scratch their head for up to a minute. The problem is, if you do that, the old MAC address is stored in the hh_cache entries, and used in future traffic also. Here's a patch that 1. makes eth_header_cache_update also update the source MAC in hh_cache. 2. adds a NETDEV_CHANGEADDR notifier in net/core/neighbour.c that walks through all the neighbour entries and updates the hh_cache's for all the neighbour entries related to given device. 3. adds neighbour_init() to allow registration of said notifier. Please comment. ===== include/net/neighbour.h 1.1 vs edited ===== --- 1.1/include/net/neighbour.h Tue Feb 5 19:39:48 2002 +++ edited/include/net/neighbour.h Mon Aug 18 11:17:25 2003 @@ -275,6 +275,8 @@ return neigh_create(tbl, pkey, dev); } +extern void neighbour_init(void); + #endif #endif ===== net/core/dev.c 1.36 vs edited ===== --- 1.36/net/core/dev.c Fri May 23 20:59:51 2003 +++ edited/net/core/dev.c Mon Aug 18 11:54:30 2003 @@ -93,6 +93,7 @@ #include #include #include +#include #include #include #include @@ -2849,6 +2850,7 @@ open_softirq(NET_RX_SOFTIRQ, net_rx_action, NULL); dst_init(); + neighbour_init(); dev_mcast_init(); #ifdef CONFIG_NET_SCHED ===== net/core/neighbour.c 1.9 vs edited ===== --- 1.9/net/core/neighbour.c Thu Jun 12 09:24:41 2003 +++ edited/net/core/neighbour.c Mon Aug 18 11:53:50 2003 @@ -1558,3 +1558,46 @@ } #endif /* CONFIG_SYSCTL */ + +static int neighbour_dev_event(struct notifier_block *this, unsigned long event, void *ptr) +{ + struct net_device *dev = ptr; + + switch (event) { + struct neigh_table *tbl; + case NETDEV_CHANGEADDR: + read_lock(&neigh_tbl_lock); + for (tbl = neigh_tables; tbl; tbl=tbl->next) { + int i; + + for (i=0; i<=NEIGH_HASHMASK; i++) { + struct neighbour *n, **np; + + np = &tbl->hash_buckets[i]; + write_lock(&tbl->lock); + + while ((n = *np) != NULL) { + if (n->dev == dev) { + neigh_update_hhs(n); + } + np = &n->next; + } + write_unlock(&tbl->lock); + } + } + read_unlock(&neigh_tbl_lock); + break; + } + return NOTIFY_DONE; +} + +struct notifier_block neighbour_dev_notifier = { + neighbour_dev_event, + NULL, + 0 +}; + +void __init neighbour_init(void) +{ + register_netdevice_notifier(&neighbour_dev_notifier); +} ===== net/ethernet/eth.c 1.3 vs edited ===== --- 1.3/net/ethernet/eth.c Fri Jun 20 00:22:53 2003 +++ edited/net/ethernet/eth.c Mon Aug 18 11:55:36 2003 @@ -238,6 +238,11 @@ void eth_header_cache_update(struct hh_cache *hh, struct net_device *dev, unsigned char * haddr) { - memcpy(((u8*)hh->hh_data) + HH_DATA_OFF(sizeof(struct ethhdr)), - haddr, dev->addr_len); + struct ethhdr *eth; + + eth = (struct ethhdr*) + (((u8*)hh->hh_data) + (HH_DATA_OFF(sizeof(*eth)))); + + memcpy(eth->h_source, dev->dev_addr, dev->addr_len); + memcpy(eth->h_dest, haddr, dev->addr_len); } -- :(){ :|:&};: From davem@redhat.com Mon Aug 18 02:28:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 02:28:34 -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 h7I9STFl032013 for ; Mon, 18 Aug 2003 02:28:30 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id CAA04074; Mon, 18 Aug 2003 02:21:32 -0700 Date: Mon, 18 Aug 2003 02:21:31 -0700 From: "David S. Miller" To: Martin Diehl Cc: jt@hpl.hp.com, shemminger@osdl.org, irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] (1/5) get rid of useless hashbin in irtty Message-Id: <20030818022131.311583f6.davem@redhat.com> In-Reply-To: References: <20030817221804.27e2f07d.davem@redhat.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4936 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 10:48:28 +0200 (CEST) Martin Diehl wrote: > So the question arises what to do if > some stack (say irda ;-) *wants* to lock the driver providing the netdev > while registered? You can't, you have to interlock with netdevice removal and also capture NETDEV_GOING_DOWN events to properly handle when netdevices disappear. From kazunori@miyazawa.org Mon Aug 18 02:32:19 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 02:32:28 -0700 (PDT) Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7I9WHFl032339 for ; Mon, 18 Aug 2003 02:32:19 -0700 Received: from monza.miyazawa.org ([::ffff:203.178.141.107]) (AUTH: LOGIN kazunori, ) by miyazawa.org with esmtp; Mon, 18 Aug 2003 18:23:36 +0900 Date: Mon, 18 Aug 2003 18:32:45 +0900 From: Kazunori Miyazawa To: Ville Nuorvala Cc: kuznet@ms2.inr.ac.ru, davem@redhat.com, netdev@oss.sgi.com, usagi@linux-ipv6.org, latten@austin.ibm.com Subject: Re: [PATCH][IPV6] fixed authentication error with TCP Message-Id: <20030818183245.4fa3508e.kazunori@miyazawa.org> In-Reply-To: References: <200308172329.DAA14889@dub.inr.ac.ru> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4937 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kazunori@miyazawa.org Precedence: bulk X-list: netdev I don't stick to chenge the interface. I think his/her patch is better than mine. I checked and it seems to work well. Please apply his/her patch. On Mon, 18 Aug 2003 10:45:41 +0300 (EEST) Ville Nuorvala wrote: > On Mon, 18 Aug 2003 kuznet@ms2.inr.ac.ru wrote: > > > Hello! > > > > > But I see a small area for improvement. Look at the place inside > > > of ip6_dst_lookup() where we do source address selection. If this > > > fails, we mark error to dst->error. > > ..... > > > It seems to me that it is only OK for dst->error to be set on routes > > > that may not be used validly for anything. > > > > > > Alexey, do I understand this stuff correctly? > > > > I think you do. And this is rather severe bug than area for improvement. > > It definitely corrupts routing table. > > Besides this, the patch also introduced dst_entry leaks in at least > icmp.c, raw.c and udp.c. > > > > Well, I think switching from function returning error code to a function > > returning dst is not a very good idea. This never was convenient. > > In the case of error, IPv6 used to return to caller a dummy reject route, > > which is always -ENETRUNREACH. So, to do this we have to hold a route > > for each errno. Returning int was just better. > > The attached patch reverts to the old ip6_dst_lookup() interface and and > makes tcp_ipv6.c use that instead. > > As an added bonus neither tcp_v6_connect() nor udpv6_connect() needs to do > source address selection anymore, since ip6_dst_lookup() already does this > for them. > > > > > Alexey > > I've tested the patch a bit and everything seems to work normally, so its > probably safe to apply it :) > > Thanks, > Ville > -- > Ville Nuorvala > Research Assistant, Institute of Digital Communications, > Helsinki University of Technology > email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 > --Kazunori Miyazawa From davem@redhat.com Mon Aug 18 02:56:56 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 02:57:01 -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 h7I9uuFl001814 for ; Mon, 18 Aug 2003 02:56:56 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id CAA04147; Mon, 18 Aug 2003 02:48:37 -0700 Date: Mon, 18 Aug 2003 02:48:37 -0700 From: "David S. Miller" To: Ville Nuorvala Cc: kuznet@ms2.inr.ac.ru, kazunori@miyazawa.org, netdev@oss.sgi.com, usagi@linux-ipv6.org, latten@austin.ibm.com Subject: Re: [PATCH][IPV6] fixed authentication error with TCP Message-Id: <20030818024837.6815f0c2.davem@redhat.com> In-Reply-To: References: <200308172329.DAA14889@dub.inr.ac.ru> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4938 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 10:45:41 +0300 (EEST) Ville Nuorvala wrote: > The attached patch reverts to the old ip6_dst_lookup() interface and and > makes tcp_ipv6.c use that instead. > > As an added bonus neither tcp_v6_connect() nor udpv6_connect() needs to do > source address selection anymore, since ip6_dst_lookup() already does this > for them. While verifying this patch, I discovered some new dst leaks. For example: 1) In icmpv6_send(), who releases the DST? 2) Similarly, for icmpv6_echo_reply()? In these two cases, ip6_append_data() grabs one reference each time it attaches 'rt' to the np->cort.rt, but we still have the singular reference in those two icmpv6_*() routines referenced above and they leak. 3) ip6_push_pending_frames(), it gets a new reference to np->cork.rt to attach the 'dst' to skb->dst on output. Then it sets np->cork.rt to NULL, 1 reference is lost as a result. 4) Similarly in ip6_flush_pending_frames(). I don't want to check any more places, because every place where I look in ipv6 I find a new DST leak :( From davem@redhat.com Mon Aug 18 03:20:07 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 03:20:15 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IAK6Fl002333 for ; Mon, 18 Aug 2003 03:20:07 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id DAA04190; Mon, 18 Aug 2003 03:11:48 -0700 Date: Mon, 18 Aug 2003 03:11:48 -0700 From: "David S. Miller" To: Ville Nuorvala Cc: kuznet@ms2.inr.ac.ru, kazunori@miyazawa.org, netdev@oss.sgi.com, usagi@linux-ipv6.org, latten@austin.ibm.com Subject: Re: [PATCH][IPV6] fixed authentication error with TCP Message-Id: <20030818031148.5c9ab656.davem@redhat.com> In-Reply-To: References: <200308172329.DAA14889@dub.inr.ac.ru> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4939 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 10:45:41 +0300 (EEST) Ville Nuorvala wrote: > The attached patch reverts to the old ip6_dst_lookup() interface and and > makes tcp_ipv6.c use that instead. I applied your patch with a small change, I made it so that *dst is set to NULL in every case that ip6_dst_lookup() returned an error. In particular, there were some error paths still in tcp_ipv6.c that would dst_release() in the error path which only works if dst is set to NULL in ip6_dst_lookup() error cases. From davem@redhat.com Mon Aug 18 03:45:19 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 03:45:28 -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 h7IAjIFl002783 for ; Mon, 18 Aug 2003 03:45:19 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id DAA04266; Mon, 18 Aug 2003 03:36:08 -0700 Date: Mon, 18 Aug 2003 03:36:08 -0700 From: "David S. Miller" To: "David S. Miller" Cc: vnuorval@tcs.hut.fi, kuznet@ms2.inr.ac.ru, kazunori@miyazawa.org, netdev@oss.sgi.com, usagi@linux-ipv6.org, latten@austin.ibm.com Subject: Re: [PATCH][IPV6] fixed authentication error with TCP Message-Id: <20030818033608.35c86539.davem@redhat.com> In-Reply-To: <20030818024837.6815f0c2.davem@redhat.com> References: <200308172329.DAA14889@dub.inr.ac.ru> <20030818024837.6815f0c2.davem@redhat.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4940 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 02:48:37 -0700 "David S. Miller" wrote: > While verifying this patch, I discovered some new dst leaks. This patch fixes them up. # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1209 -> 1.1210 # net/ipv6/ip6_output.c 1.42 -> 1.43 # net/ipv6/icmp.c 1.39 -> 1.40 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 03/08/18 davem@nuts.ninka.net 1.1210 # [IPV6]: Fix some dst cache leaks. # 1) icmpv6_send() and icmpv6_echo_reply() never release dst. # 2) ip6_{push,flush}_pending_frames() leak np->cork.rt. # -------------------------------------------- # diff -Nru a/net/ipv6/icmp.c b/net/ipv6/icmp.c --- a/net/ipv6/icmp.c Mon Aug 18 03:39:55 2003 +++ b/net/ipv6/icmp.c Mon Aug 18 03:39:55 2003 @@ -356,7 +356,8 @@ fl.oif = np->mcast_oif; err = ip6_dst_lookup(sk, &dst, &fl); - if (err) goto out; + if (err) + goto out; if (hlimit < 0) { if (ipv6_addr_is_multicast(&fl.fl6_dst)) @@ -375,7 +376,7 @@ if (net_ratelimit()) printk(KERN_DEBUG "icmp: len problem\n"); __skb_push(skb, plen); - goto out; + goto out_dst_release; } idev = in6_dev_get(skb->dev); @@ -396,6 +397,8 @@ out_put: if (likely(idev != NULL)) in6_dev_put(idev); +out_dst_release: + dst_release(dst); out: icmpv6_xmit_unlock(); } @@ -435,8 +438,8 @@ fl.oif = np->mcast_oif; err = ip6_dst_lookup(sk, &dst, &fl); - - if (err) goto out; + if (err) + goto out; if (hlimit < 0) { if (ipv6_addr_is_multicast(&fl.fl6_dst)) @@ -465,6 +468,7 @@ out_put: if (likely(idev != NULL)) in6_dev_put(idev); + dst_release(dst); out: icmpv6_xmit_unlock(); } diff -Nru a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c --- a/net/ipv6/ip6_output.c Mon Aug 18 03:39:55 2003 +++ b/net/ipv6/ip6_output.c Mon Aug 18 03:39:55 2003 @@ -1484,6 +1484,7 @@ np->cork.opt = NULL; } if (np->cork.rt) { + dst_release(&np->cork.rt->u.dst); np->cork.rt = NULL; } if (np->cork.fl) { @@ -1510,6 +1511,7 @@ np->cork.opt = NULL; } if (np->cork.rt) { + dst_release(&np->cork.rt->u.dst); np->cork.rt = NULL; } if (np->cork.fl) { From davem@redhat.com Mon Aug 18 03:52:51 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 03:52:55 -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 h7IAqoFl003133 for ; Mon, 18 Aug 2003 03:52:50 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id DAA04315; Mon, 18 Aug 2003 03:45:05 -0700 Date: Mon, 18 Aug 2003 03:45:05 -0700 From: "David S. Miller" To: Ville Nuorvala Cc: usagi-core@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [PATCH] IPv6: fix dst leakage caused by rt6_cow() Message-Id: <20030818034505.08182f5b.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4941 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 11:13:13 +0300 (EEST) Ville Nuorvala wrote: > since rt6_cow() calls dst_hold() it looks like we're leaking refcounts in > three places in route.c. The patch below should fix this. You are absolutely correct. Patch applied, thanks. From jgarzik@pobox.com Mon Aug 18 04:21:20 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 04:21:45 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IBLIFl004187 for ; Mon, 18 Aug 2003 04:21:20 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19neem-0006f0-EJ; Fri, 15 Aug 2003 14:30:16 +0100 Message-ID: <3F3CE05D.5080306@pobox.com> Date: Fri, 15 Aug 2003 09:30:05 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: Stephen Hemminger , mikep@linuxtr.net, linux-tr@linuxtr.net, netdev@oss.sgi.com Subject: Re: [PATCH] ibmtr - get rid of MOD_INC/DEC References: <20030813174658.2c5125af.shemminger@osdl.org> <20030814205747.5fcd83d0.davem@redhat.com> In-Reply-To: <20030814205747.5fcd83d0.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4942 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev David S. Miller wrote: > On Wed, 13 Aug 2003 17:46:58 -0700 > Stephen Hemminger wrote: > > >>With the new module system MOD_INC/MOD_DEC are no longer necessary. >>Also changed to new module init/exit macros for function setup. >> >>The module exit code can sleep, so calling schedule_timeout is better >>than spinning. > > > Can't we lose the MODULE ifdefs too? Doubtful for ibmtr, which requires some of them for ibmtr_cs (which #includes it). Jeff From davem@redhat.com Mon Aug 18 04:25:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 04:25:58 -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 h7IBPrFl004535 for ; Mon, 18 Aug 2003 04:25:53 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id EAA04624; Mon, 18 Aug 2003 04:19:11 -0700 Date: Mon, 18 Aug 2003 04:19:11 -0700 From: "David S. Miller" To: Tommi Virtanen Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Change MAC without bringing interface down Message-Id: <20030818041911.358c3437.davem@redhat.com> In-Reply-To: <20030818091312.GA4889@lapdog> References: <20030818091312.GA4889@lapdog> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4943 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 12:13:12 +0300 Tommi Virtanen wrote: > Here's a patch that > > 1. makes eth_header_cache_update also update the source MAC in > hh_cache. > > 2. adds a NETDEV_CHANGEADDR notifier in net/core/neighbour.c > that walks through all the neighbour entries and updates > the hh_cache's for all the neighbour entries related to > given device. > > 3. adds neighbour_init() to allow registration of said notifier. I would suggest to fix this by instead flushing the hh entries (just like neigh_destroy() does). This way, we don't have to fix up every single header cache implementation, that's painful :( From skraw@ithnet.com Mon Aug 18 04:40:04 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 04:40:13 -0700 (PDT) Received: from heather-ng.ithnet.com (mail3.ithnet.com [217.64.64.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IBe0Fl004900 for ; Mon, 18 Aug 2003 04:40:04 -0700 Received: (qmail 32443 invoked by uid 0); 18 Aug 2003 11:39:58 -0000 Received: from skraw@ithnet.com by heather-ng (Processed in 0.568477 secs); 18 Aug 2003 11:39:58 -0000 X-Virus-Status: No Received: from unknown (HELO ithnet.com) (217.64.64.14) by heather-ng.ithnet.com with SMTP; 18 Aug 2003 11:39:57 -0000 X-Sender-Authentication: SMTPafterPOP by from 217.64.64.14 Date: Mon, 18 Aug 2003 13:39:57 +0200 From: Stephan von Krawczynski To: "David S. Miller" Cc: willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030818133957.3d3d51d2.skraw@ithnet.com> In-Reply-To: <20030817223118.3cbc497c.davem@redhat.com> References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> <200308171827130739.00C3905F@192.168.128.16> <1061141045.21885.74.camel@dhcp23.swansea.linux.org.uk> <20030817224849.GB734@alpha.home.local> <20030817223118.3cbc497c.davem@redhat.com> Organization: ith Kommunikationstechnik GmbH X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4944 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: skraw@ithnet.com Precedence: bulk X-list: netdev On Sun, 17 Aug 2003 22:31:18 -0700 "David S. Miller" wrote: > On Mon, 18 Aug 2003 00:48:49 +0200 > Willy Tarreau wrote: > > > On Sun, Aug 17, 2003 at 06:24:06PM +0100, Alan Cox wrote: > > > > > So stick the address on eth0 not on lo since its not a loopback but an > > > eth0 address, then use arpfilter so you don't arp for the invalid magic > > > shared IP address, or NAT it, or it may work to do > > > > > > ip route add nexthop-addr src my-virtual-addr dev eth0 scope > > > local onlink ip route add default src my-virtual-addr via > > > nexthop-addr dev eth0 scope global > > > > I have a case where this doesn't work > > Replying again... Alan does mention in the paragraph you've quoted > to use arpfilter, which works for every case imaginable. > > The facilities to solve these problems are there, people simply > don't want to use them. It would be probably a good thing if anybody ever found a _positive_ scenario where your view of the arp-world has _advantages_ compared to what the vast majority of people I ever talked to sees as _expected_ behaviour... (Please don't argue that my "vast majority" is not necessarily _the_ vast majority, because that is true for merely every human being on this planet and beyond) I mean everybody is willing to follow you if you could say: "look at these type of wide-spread operations and notice the positive (config shortening or whatever) influence of the current default behaviour." Can you please give us a striking example of a widespread application where current behaviour is a requirement or at least a very positive thing? Regards, Stephan From vnuorval@tcs.hut.fi Mon Aug 18 04:50:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 04:50:58 -0700 (PDT) Received: from mail.tcs.hut.fi (mail.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IBoqFl005388 for ; Mon, 18 Aug 2003 04:50:53 -0700 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by mail.tcs.hut.fi (Postfix) with ESMTP id D10A5800195; Mon, 18 Aug 2003 14:50:51 +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 h7IBop5L019294; Mon, 18 Aug 2003 14:50:51 +0300 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-5) with ESMTP id h7IBopo9019290; Mon, 18 Aug 2003 14:50:51 +0300 Date: Mon, 18 Aug 2003 14:50:51 +0300 (EEST) From: Ville Nuorvala To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [PATCH] IPv6: Fix tunnel encapsulation limit in ip6_tunnel.c Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4945 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Hi, I reread RFC 2473 and noticed the tunnel encapsulation limit handling was off by one. This patch fixes the bug. Please apply! Thanks, Ville --- linux-2.5.OLD/net/ipv6/ip6_tunnel.c 2003-08-18 10:04:23.000000000 +0300 +++ linux-2.5/net/ipv6/ip6_tunnel.c 2003-08-15 18:45:36.000000000 +0300 @@ -423,7 +423,7 @@ if (teli && teli == info - 2) { tel = (struct ipv6_tlv_tnl_enc_lim *) &skb->data[teli]; - if (tel->encap_limit <= 1) { + if (tel->encap_limit == 0) { if (net_ratelimit()) printk(KERN_WARNING "%s: Too small encapsulation " @@ -669,7 +669,7 @@ struct ipv6hdr *ipv6h = skb->nh.ipv6h; struct ipv6_txoptions *orig_opt = NULL; struct ipv6_txoptions *opt = NULL; - __u8 encap_limit = 0; + int encap_limit = -1; __u16 offset; struct flowi fl; struct ip6_flowlabel *fl_lbl = NULL; @@ -692,7 +692,7 @@ if ((offset = parse_tlv_tnl_enc_lim(skb, skb->nh.raw)) > 0) { struct ipv6_tlv_tnl_enc_lim *tel; tel = (struct ipv6_tlv_tnl_enc_lim *) &skb->nh.raw[offset]; - if (tel->encap_limit <= 1) { + if (tel->encap_limit == 0) { icmpv6_send(skb, ICMPV6_PARAMPROB, ICMPV6_HDR_FIELD, offset + 2, skb->dev); goto tx_err; @@ -715,7 +715,7 @@ if (fl_lbl) orig_opt = fl_lbl->opt; } - if (encap_limit > 0) { + if (encap_limit >= 0) { if (!(opt = merge_options(sk, encap_limit, orig_opt))) { goto tx_err_free_fl_lbl; } -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From davem@redhat.com Mon Aug 18 04:51:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 04:51:35 -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 h7IBpTFl005576 for ; Mon, 18 Aug 2003 04:51:29 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id EAA04750; Mon, 18 Aug 2003 04:44:19 -0700 Date: Mon, 18 Aug 2003 04:44:19 -0700 From: "David S. Miller" To: Stephan von Krawczynski Cc: willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030818044419.0bc24d14.davem@redhat.com> In-Reply-To: <20030818133957.3d3d51d2.skraw@ithnet.com> References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> <200308171827130739.00C3905F@192.168.128.16> <1061141045.21885.74.camel@dhcp23.swansea.linux.org.uk> <20030817224849.GB734@alpha.home.local> <20030817223118.3cbc497c.davem@redhat.com> <20030818133957.3d3d51d2.skraw@ithnet.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4946 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 13:39:57 +0200 Stephan von Krawczynski wrote: > Can you please give us a striking example of a widespread application where > current behaviour is a requirement or at least a very positive thing? [ I've been waiting what seems like centuries for someone to even consider talking about source address selection, alas I have to bring it up myself :( ] I'll responsd by asking questions of you. Do you know how source address selection works when the user tries to connect to a remote location yet doesn't specify a specific source address to use? Once you understand source address selection, the next thing you need to do is: 1) consider how you might want to make that configurable by the user 2) what the default behavior should be 3) what kind of ARP behavior is necessary in order for these various configurations to work From davem@redhat.com Mon Aug 18 04:55:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 04:55:57 -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 h7IBtrFl006044 for ; Mon, 18 Aug 2003 04:55:54 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id EAA04804; Mon, 18 Aug 2003 04:48:10 -0700 Date: Mon, 18 Aug 2003 04:48:10 -0700 From: "David S. Miller" To: Ville Nuorvala Cc: netdev@oss.sgi.com Subject: Re: [PATCH] IPv6: Fix tunnel encapsulation limit in ip6_tunnel.c Message-Id: <20030818044810.01a28c38.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4947 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 14:50:51 +0300 (EEST) Ville Nuorvala wrote: > I reread RFC 2473 and noticed the tunnel encapsulation limit handling was > off by one. This patch fixes the bug. Please apply! Applied, thanks Ville. From bloemsaa@xs4all.nl Mon Aug 18 05:08:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 05:08:58 -0700 (PDT) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IC8mFl006610 for ; Mon, 18 Aug 2003 05:08:49 -0700 Received: from llewella (vialle.xs4all.nl [213.84.6.25]) by smtpzilla5.xs4all.nl (8.12.9/8.12.9) with SMTP id h7IC81qg029435; Mon, 18 Aug 2003 14:08:26 +0200 (CEST) Message-ID: <012b01c36581$6fd1c1b0$c801a8c0@llewella> From: "Bas Bloemsaat" To: "David S. Miller" Cc: , , , , , , , , , , References: <20030728213933.F81299@coredump.scriptkiddie.org><200308171509570955.003E4FEC@192.168.128.16><200308171516090038.0043F977@192.168.128.16><1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk><200308171555280781.0067FB36@192.168.128.16><1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk><200308171759540391.00AA8CAB@192.168.128.16><1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk><200308171827130739.00C3905F@192.168.128.16><1061141045.21885.74.camel@dhcp23.swansea.linux.org.uk><20030817224849.GB734@alpha.home.local><20030817223118.3cbc497c.davem@redhat.com> <20030818133957.3d3d51d2.skraw@ithnet.com> Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Date: Mon, 18 Aug 2003 14:08:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 4948 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bloemsaa@xs4all.nl Precedence: bulk X-list: netdev > > Replying again... Alan does mention in the paragraph you've quoted > > to use arpfilter, which works for every case imaginable. No it doesn't. When I have two nics on DHCP on the same ethernet segment, it cannot be made to work. I don't know the ip addresses beforehand. And if if I would get them with scripting and crafted some rules on the fly, there's no way I can be sure I'll get the same IP's on a renew, so I'd have to check often. Regards, Bas From davem@redhat.com Mon Aug 18 05:11:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 05:11:05 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7ICAxFl006940 for ; Mon, 18 Aug 2003 05:11:00 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id FAA04968; Mon, 18 Aug 2003 05:03:57 -0700 Date: Mon, 18 Aug 2003 05:03:57 -0700 From: "David S. Miller" To: "Bas Bloemsaat" Cc: willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030818050357.1a5b8d6e.davem@redhat.com> In-Reply-To: <012b01c36581$6fd1c1b0$c801a8c0@llewella> References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> <200308171827130739.00C3905F@192.168.128.16> <1061141045.21885.74.camel@dhcp23.swansea.linux.org.uk> <20030817224849.GB734@alpha.home.local> <20030817223118.3cbc497c.davem@redhat.com> <20030818133957.3d3d51d2.skraw@ithnet.com> <012b01c36581$6fd1c1b0$c801a8c0@llewella> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4949 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 14:08:05 +0200 "Bas Bloemsaat" wrote: > > > Replying again... Alan does mention in the paragraph you've quoted > > > to use arpfilter, which works for every case imaginable. > > No it doesn't. When I have two nics on DHCP on the same ethernet segment, it > cannot be made to work. I don't know the ip addresses beforehand. And if if > I would get them with scripting and crafted some rules on the fly, there's > no way I can be sure I'll get the same IP's on a renew, so I'd have to check > often. You don't understand how 'arpfilter' works. It's a netfilter module that allows you to block ARP packets going in and out of the system using any criteria you want. It can block on device, on src MAC address, on destination MAC address, whatever you want. From hadi@cyberus.ca Mon Aug 18 05:14:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 05:14:25 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7ICEGFl007270 for ; Mon, 18 Aug 2003 05:14:17 -0700 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.12) id 19oiuY-0008tN-00; Mon, 18 Aug 2003 08:14:58 -0400 Subject: Re: [PATCH] Change MAC without bringing interface down From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: Tommi Virtanen , netdev@oss.sgi.com In-Reply-To: <20030818041911.358c3437.davem@redhat.com> References: <20030818091312.GA4889@lapdog> <20030818041911.358c3437.davem@redhat.com> Content-Type: multipart/mixed; boundary="=-06lLkphgphFnvyYz4iyU" Organization: jamalopolis Message-Id: <1061208824.16010.2119.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 18 Aug 2003 08:13:44 -0400 X-archive-position: 4950 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev --=-06lLkphgphFnvyYz4iyU Content-Type: text/plain Content-Transfer-Encoding: 7bit Editing the header may be the better approach if you have a few hundred hhs already inserted (this was the issue i was faced with when VRRP was failing over when i was playing with it). I tried to flush the cache but it took longer to recover it. The patch posted may not be the better way to do this. It should be per neighbour table owner - at the moment only ARP and ndisc really care about this. Heres an old patch i have circa 2.4.2 that i have been sitting on planning to convert it to latest kernels; the ndisc portion is missing; If this is found agreeable Tommi you can clean it up and bring it to par with latest kernel cheers, jamal On Mon, 2003-08-18 at 07:19, David S. Miller wrote: > On Mon, 18 Aug 2003 12:13:12 +0300 > Tommi Virtanen wrote: > > > Here's a patch that > > > > 1. makes eth_header_cache_update also update the source MAC in > > hh_cache. > > > > 2. adds a NETDEV_CHANGEADDR notifier in net/core/neighbour.c > > that walks through all the neighbour entries and updates > > the hh_cache's for all the neighbour entries related to > > given device. > > > > 3. adds neighbour_init() to allow registration of said notifier. > > I would suggest to fix this by instead flushing the hh > entries (just like neigh_destroy() does). > > This way, we don't have to fix up every single header cache > implementation, that's painful :( > > --=-06lLkphgphFnvyYz4iyU Content-Disposition: attachment; filename=neighp Content-Type: text/plain; name=neighp; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- 242/include/net/neighbour.h 2003-07-20 19:42:33.000000000 -0400 +++ 242/include/net/patchedneighbour.h 2003-07-20 19:42:38.000000000 -0400 @@ -180,6 +180,7 @@ extern void neigh_destroy(struct neighbour *neigh); extern int __neigh_event_send(struct neighbour *neigh, struct sk_buff *skb); extern int neigh_update(struct neighbour *neigh, const u8 *lladdr, u8 new, int override, int arp); +extern int neigh_changeaddr(struct neigh_table *tbl, struct net_device *dev); extern int neigh_ifdown(struct neigh_table *tbl, struct net_device *dev); extern int neigh_resolve_output(struct sk_buff *skb); extern int neigh_connected_output(struct sk_buff *skb); --- 242/net/core/neighbour.c 2003-07-20 19:38:19.000000000 -0400 +++ 242/net/core/patchedneighbour.c 2003-08-18 07:15:35.000000000 -0400 @@ -50,6 +50,7 @@ static void neigh_app_notify(struct neighbour *n); #endif static int pneigh_ifdown(struct neigh_table *tbl, struct net_device *dev); +int neigh_changeaddr(struct neigh_table *tbl, struct net_device *dev); static int neigh_glbl_allocs; static struct neigh_table *neigh_tables; @@ -410,6 +411,52 @@ return -ENOENT; } +void update_neigh_hh(struct neighbour *neigh) +{ + + struct hh_cache *hh; + + int (*update)(struct neighbour *neigh, struct hh_cache *hh) = + neigh->dev->hard_header_cache; + + if (update) { + for (hh=neigh->hh; hh; hh=hh->hh_next) { + write_lock_bh(&hh->hh_lock); + update(neigh, hh); + write_unlock_bh(&hh->hh_lock); + } + } + else { + printk("device neigh %p does not have a update method!\n",neigh); + } +} + +int neigh_changeaddr(struct neigh_table *tbl, struct net_device *dev) +{ + int i; + + write_lock_bh(&tbl->lock); + + for (i=0; i<=NEIGH_HASHMASK; i++) { + struct neighbour *n, **np; + + np = &tbl->hash_buckets[i]; + while ((n = *np) != NULL) { + if (dev && n->dev != dev) { + np = &n->next; + continue; + } + *np = n->next; + write_lock_bh(&n->lock); + update_neigh_hh(n); + write_unlock_bh(&n->lock); + } + } + + write_unlock_bh(&tbl->lock); + return 0; +} + static int pneigh_ifdown(struct neigh_table *tbl, struct net_device *dev) { struct pneigh_entry *n, **np; @@ -432,6 +479,7 @@ } + /* * neighbour must already be out of the table; * @@ -488,8 +536,9 @@ neigh->output = neigh->ops->output; - for (hh = neigh->hh; hh; hh = hh->hh_next) + for (hh = neigh->hh; hh; hh = hh->hh_next) { hh->hh_output = neigh->ops->output; + } } /* Neighbour state is OK; @@ -507,8 +556,10 @@ neigh->output = neigh->ops->connected_output; - for (hh = neigh->hh; hh; hh = hh->hh_next) + for (hh = neigh->hh; hh; hh = hh->hh_next) { hh->hh_output = neigh->ops->hh_output; + } + } /* @@ -924,6 +975,7 @@ atomic_inc(&hh->hh_refcnt); dst->hh = hh; } + } /* This function can be used in contexts, where only old dev_queue_xmit @@ -961,6 +1013,7 @@ int err; struct net_device *dev = neigh->dev; if (dev->hard_header_cache && dst->hh == NULL) { + write_lock_bh(&neigh->lock); if (dst->hh == NULL) neigh_hh_init(neigh, dst, dst->ops->protocol); --- 242/net/ipv4/arp.c 2003-07-20 19:37:52.000000000 -0400 +++ 242/net/ipv4/patchedarp.c 2003-08-18 07:19:08.000000000 -0400 @@ -1,6 +1,6 @@ /* linux/net/inet/arp.c * - * Version: $Id: arp.c,v 1.90 2000/10/04 09:20:56 anton Exp $ + * Version: $Id: arp.c,v 1.1 2003/07/04 14:04:46 root Exp root $ * * Copyright (C) 1994 by Florian La Roche * @@ -123,6 +123,7 @@ static void arp_error_report(struct neighbour *neigh, struct sk_buff *skb); static void parp_redo(struct sk_buff *skb); +static int arp_n_event(struct notifier_block *this, unsigned long event, void *ptr); static struct neigh_ops arp_generic_ops = { AF_INET, @@ -1140,6 +1141,30 @@ } #endif + +struct notifier_block arp_netdev_notifier = { + arp_n_event, + NULL, + 0 +}; + +static int arp_n_event(struct notifier_block *this, unsigned long event, void *ptr) +{ + struct net_device *dev = (struct net_device *)(ptr) ; + + switch (event) { + default: + break; + case NETDEV_CHANGEADDR: + neigh_changeaddr(&arp_tbl, dev); + break; + } + + return NOTIFY_DONE; + +} + + /* Note, that it is not on notifier chain. It is necessary, that this routine was called after route cache will be flushed. @@ -1174,6 +1199,7 @@ #ifdef CONFIG_SYSCTL neigh_sysctl_register(NULL, &arp_tbl.parms, NET_IPV4, NET_IPV4_NEIGH, "ipv4"); #endif + register_netdevice_notifier(&arp_netdev_notifier); } --=-06lLkphgphFnvyYz4iyU-- From davem@redhat.com Mon Aug 18 05:20:12 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 05:20:15 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7ICKBFl007616 for ; Mon, 18 Aug 2003 05:20:11 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id FAA05064; Mon, 18 Aug 2003 05:12:27 -0700 Date: Mon, 18 Aug 2003 05:12:27 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: tv@debian.org, netdev@oss.sgi.com Subject: Re: [PATCH] Change MAC without bringing interface down Message-Id: <20030818051227.4f35f2f3.davem@redhat.com> In-Reply-To: <1061208824.16010.2119.camel@jzny.localdomain> References: <20030818091312.GA4889@lapdog> <20030818041911.358c3437.davem@redhat.com> <1061208824.16010.2119.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4951 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On 18 Aug 2003 08:13:44 -0400 jamal wrote: > Editing the header may be the better approach if you have a few hundred > hhs already inserted (this was the issue i was faced with when VRRP was > failing over when i was playing with it). I tried to flush the cache but > it took longer to recover it. There is another reason I want the cache flushed. Those hh cache entries are what ARP resolved to when we had the previous MAC address, not the one we have now. The ARPs may come back differently with the new MAC address. I _REALLY REALLY_ don't want to have to change the ->update() implementations. Although one thing I would consider is a new ->update_src() operation and if this were NULL we flush the entries instead. From skraw@ithnet.com Mon Aug 18 05:34:05 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 05:34:09 -0700 (PDT) Received: from heather-ng.ithnet.com (mail3.ithnet.com [217.64.64.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7ICY3Fl008415 for ; Mon, 18 Aug 2003 05:34:04 -0700 Received: (qmail 7654 invoked by uid 0); 18 Aug 2003 12:34:02 -0000 Received: from skraw@ithnet.com by heather-ng (Processed in 0.59603 secs); 18 Aug 2003 12:34:02 -0000 X-Virus-Status: No Received: from unknown (HELO ithnet.com) (217.64.64.14) by heather-ng.ithnet.com with SMTP; 18 Aug 2003 12:34:01 -0000 X-Sender-Authentication: SMTPafterPOP by from 217.64.64.14 Date: Mon, 18 Aug 2003 14:34:01 +0200 From: Stephan von Krawczynski To: "David S. Miller" Cc: willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030818143401.1352d158.skraw@ithnet.com> In-Reply-To: <20030818044419.0bc24d14.davem@redhat.com> References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> <200308171827130739.00C3905F@192.168.128.16> <1061141045.21885.74.camel@dhcp23.swansea.linux.org.uk> <20030817224849.GB734@alpha.home.local> <20030817223118.3cbc497c.davem@redhat.com> <20030818133957.3d3d51d2.skraw@ithnet.com> <20030818044419.0bc24d14.davem@redhat.com> Organization: ith Kommunikationstechnik GmbH X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4952 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: skraw@ithnet.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 04:44:19 -0700 "David S. Miller" wrote: > On Mon, 18 Aug 2003 13:39:57 +0200 > Stephan von Krawczynski wrote: > > > Can you please give us a striking example of a widespread application where > > current behaviour is a requirement or at least a very positive thing? > > [ I've been waiting what seems like centuries for someone > to even consider talking about source address selection, > alas I have to bring it up myself :( ] > > I'll responsd by asking questions of you. David, this is the wrong way round. Others'/my question was not about the implementation and technical considerations leading to it (bottom up), but pure and simple (and top down): what is the _positive_ outcome of this implementation compared to others? We are always talking of setups that seem to be more complicated because of the current situation. So one would expect that there are advantages that make up the discussed disadvantages. And since I obviously don't have the knowledge to see them, I'd like to learn and therefore ask: what are the advantages on the _users_ side? Regards, Stephan From davem@redhat.com Mon Aug 18 05:37:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 05:37:17 -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 h7ICbDFl008748 for ; Mon, 18 Aug 2003 05:37:14 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id FAA05217; Mon, 18 Aug 2003 05:30:08 -0700 Date: Mon, 18 Aug 2003 05:30:07 -0700 From: "David S. Miller" To: Stephan von Krawczynski Cc: willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030818053007.7852ca77.davem@redhat.com> In-Reply-To: <20030818143401.1352d158.skraw@ithnet.com> References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> <200308171827130739.00C3905F@192.168.128.16> <1061141045.21885.74.camel@dhcp23.swansea.linux.org.uk> <20030817224849.GB734@alpha.home.local> <20030817223118.3cbc497c.davem@redhat.com> <20030818133957.3d3d51d2.skraw@ithnet.com> <20030818044419.0bc24d14.davem@redhat.com> <20030818143401.1352d158.skraw@ithnet.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4953 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 14:34:01 +0200 Stephan von Krawczynski wrote: > what is the _positive_ outcome of this > implementation compared to others? If you're not willing to think I can't help you resolve the questions you have. If you don't understand source address selection, than it's not possible for me to have an intellegent conversation about this topic. So you need to make this crucial first step. From willy@w.ods.org Mon Aug 18 05:52:52 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 05:53:04 -0700 (PDT) Received: from www.home.local (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7ICqoFl009194 for ; Mon, 18 Aug 2003 05:52:51 -0700 Received: from alpha.home.local (alpha [10.0.1.2]) by www.home.local (8.12.1/8.12.1) with ESMTP id h7ICqQpn032606; Mon, 18 Aug 2003 14:52:26 +0200 Received: (from willy@localhost) by alpha.home.local (8.12.4/8.12.1) id h7ICpwxx019061; Mon, 18 Aug 2003 14:51:58 +0200 Date: Mon, 18 Aug 2003 14:51:58 +0200 From: Willy Tarreau To: "David S. Miller" Cc: Stephan von Krawczynski , willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-ID: <20030818125158.GA18699@alpha.home.local> References: <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> <200308171827130739.00C3905F@192.168.128.16> <1061141045.21885.74.camel@dhcp23.swansea.linux.org.uk> <20030817224849.GB734@alpha.home.local> <20030817223118.3cbc497c.davem@redhat.com> <20030818133957.3d3d51d2.skraw@ithnet.com> <20030818044419.0bc24d14.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030818044419.0bc24d14.davem@redhat.com> User-Agent: Mutt/1.4i X-archive-position: 4954 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@w.ods.org Precedence: bulk X-list: netdev On Mon, Aug 18, 2003 at 04:44:19AM -0700, David S. Miller wrote: > On Mon, 18 Aug 2003 13:39:57 +0200 > Stephan von Krawczynski wrote: > > > Can you please give us a striking example of a widespread application where > > current behaviour is a requirement or at least a very positive thing? > > [ I've been waiting what seems like centuries for someone > to even consider talking about source address selection, > alas I have to bring it up myself :( ] You're not fair, David, that was *exactly* my concern when I jumped into the thread : the SELECTED SOURCE address for ARP requests is wrong by default as soon as you manually set the IP source address. (but perhaps you didn't have time to read my long mail). > Do you know how source address selection works when the user tries to > connect to a remote location yet doesn't specify a specific source > address to use? In my case, although I don't know the internals, I think I have a clear enough idea of it (but I may be wrong) : the IP source address used when connecting to a remote host should be either the one manually specified on the most appropriate route, or one local address which can reach the remote host or a gateway indicated by the most appropriate route. The ARP source is the IP source address if this address is a local one, or one of those assigned to the NIC from which either the host or the gateway should be reached. > 1) consider how you might want to make that configurable > by the user ip route ... src ... is really fine to me for the IP part, and I would have expected it to act on ARP too ;-) > 2) what the default behavior should be I think we should apply the exact same source selection as IP to ARP. That is, if we need to reach host X or gateway X on the LAN, we should do a route lookup and use a valid source (or the manually set one) associated to the most appropriate route. That is what Julian Anastasov's patch does, and it does it fairly well IMHO. > 3) what kind of ARP behavior is necessary in order for > these various configurations to work The one detailed above by default, then use arptables (or ip arp) for all tricky configurations. BTW, I've tried arptables-0.0.1. Except that I had to patch it to make it usable on 2.4.22-rc2 (because the FORWARD chain doesn't exist on 2.4), it allows me to do the same as what 'ip arp' did for me on a patched kernel (although I prefer the iproute interface, just a matter of taste). Using my previous example, I now do the following which works : ip address add 10.0.0.1/24 dev eth0 ip address add 11.0.0.1/24 dev eth0 ip route add default via 11.0.0.2 src 10.0.0.1 arptables -A OUTPUT -d 11.0.0.0/24 -o eth0 -j mangle --mangle-ip-s 11.0.0.1 I'll send a fix to the arptable's maintainer so that it works again on 2.4. Cheers, Willy From skraw@ithnet.com Mon Aug 18 05:53:20 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 05:53:25 -0700 (PDT) Received: from heather-ng.ithnet.com (mail3.ithnet.com [217.64.64.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7ICrIFl009256 for ; Mon, 18 Aug 2003 05:53:19 -0700 Received: (qmail 9868 invoked by uid 0); 18 Aug 2003 12:53:17 -0000 Received: from skraw@ithnet.com by heather-ng (Processed in 0.633011 secs); 18 Aug 2003 12:53:17 -0000 X-Virus-Status: No Received: from unknown (HELO ithnet.com) (217.64.64.14) by heather-ng.ithnet.com with SMTP; 18 Aug 2003 12:53:16 -0000 X-Sender-Authentication: SMTPafterPOP by from 217.64.64.14 Date: Mon, 18 Aug 2003 14:53:16 +0200 From: Stephan von Krawczynski To: "David S. Miller" Cc: willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030818145316.3a81f70c.skraw@ithnet.com> In-Reply-To: <20030818053007.7852ca77.davem@redhat.com> References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> <200308171827130739.00C3905F@192.168.128.16> <1061141045.21885.74.camel@dhcp23.swansea.linux.org.uk> <20030817224849.GB734@alpha.home.local> <20030817223118.3cbc497c.davem@redhat.com> <20030818133957.3d3d51d2.skraw@ithnet.com> <20030818044419.0bc24d14.davem@redhat.com> <20030818143401.1352d158.skraw@ithnet.com> <20030818053007.7852ca77.davem@redhat.com> Organization: ith Kommunikationstechnik GmbH X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4955 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: skraw@ithnet.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 05:30:07 -0700 "David S. Miller" wrote: > On Mon, 18 Aug 2003 14:34:01 +0200 > Stephan von Krawczynski wrote: > > > what is the _positive_ outcome of this > > implementation compared to others? > > If you're not willing to think I can't help you resolve > the questions you have. > > If you don't understand source address selection, than it's > not possible for me to have an intellegent conversation about > this topic. > > So you need to make this crucial first step. Sorry, David. Your argument would only be valid, if there weren't other implementations that behave differently. But in fact there are, and there are patches for linux that do just the same. _And_ you did not explain so far why these implementations should not be RFC-conform or else illegal. So there is no validity in your claim one has to understand why the designer did what he did to follow the discussion. In fact it is rather up to the designer to explain to the users why he did it in another way other designers did, i.e. what is _better_ about _this_ way compared to others. Because if there is nothing better then the implementation is legal but contestable, because all scenarios discussed so far have more complex solutions then with other implementations. Don't get me wrong, this is no technical argument. It is purely darwinism, "legal and easy" is superior to "legal and complex" (as long as there are no other benefits). Regards, Stephan From davem@redhat.com Mon Aug 18 06:00:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 06:00:46 -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 h7ID0YFl009889 for ; Mon, 18 Aug 2003 06:00:35 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id FAA05351; Mon, 18 Aug 2003 05:53:29 -0700 Date: Mon, 18 Aug 2003 05:53:29 -0700 From: "David S. Miller" To: Willy Tarreau Cc: skraw@ithnet.com, willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030818055329.44db9262.davem@redhat.com> In-Reply-To: <20030818125158.GA18699@alpha.home.local> References: <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> <200308171827130739.00C3905F@192.168.128.16> <1061141045.21885.74.camel@dhcp23.swansea.linux.org.uk> <20030817224849.GB734@alpha.home.local> <20030817223118.3cbc497c.davem@redhat.com> <20030818133957.3d3d51d2.skraw@ithnet.com> <20030818044419.0bc24d14.davem@redhat.com> <20030818125158.GA18699@alpha.home.local> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4956 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 14:51:58 +0200 Willy Tarreau wrote: > > 1) consider how you might want to make that configurable > > by the user > > ip route ... src ... is really fine to me for the IP part, and I would have > expected it to act on ARP too ;-) More precisely, "preferred source". > > 2) what the default behavior should be > > I think we should apply the exact same source selection as IP to ARP. This is what setting the "arp_filter" sysctl on a device does if you've setup the preferred source on your routes correctly. If we would use that IP address to speak to the destination in the ARP, we respond, else we do not. I've quoted the 'arp_filter' entry in Documentation/sysctl/ip-sysctl.txt please give it a read. From davem@redhat.com Mon Aug 18 06:03:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 06:03: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 h7ID32Fl010233 for ; Mon, 18 Aug 2003 06:03:02 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id FAA05384; Mon, 18 Aug 2003 05:55:55 -0700 Date: Mon, 18 Aug 2003 05:55:55 -0700 From: "David S. Miller" To: Stephan von Krawczynski Cc: willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030818055555.248f2a01.davem@redhat.com> In-Reply-To: <20030818145316.3a81f70c.skraw@ithnet.com> References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> <200308171827130739.00C3905F@192.168.128.16> <1061141045.21885.74.camel@dhcp23.swansea.linux.org.uk> <20030817224849.GB734@alpha.home.local> <20030817223118.3cbc497c.davem@redhat.com> <20030818133957.3d3d51d2.skraw@ithnet.com> <20030818044419.0bc24d14.davem@redhat.com> <20030818143401.1352d158.skraw@ithnet.com> <20030818053007.7852ca77.davem@redhat.com> <20030818145316.3a81f70c.skraw@ithnet.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4957 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 14:53:16 +0200 Stephan von Krawczynski wrote: > _And_ you did not explain so far why these implementations should > not be RFC-conform or else illegal. Both responding and not responding on all interfaces for ARPs is RFC conformant. This means both Linux and other systems are within the rules. Under Linux, by default, IP addresses are owned by the system not by interfaces. This increases the likelyhood of successful communication on a subnet. For scenerios where this doesn't work, we have ways to make the kernel behave the way you want it to. There is no discussion about changing the default, because that might break things for some people. So this discussion is pretty useless. From hadi@cyberus.ca Mon Aug 18 06:04:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 06:04:31 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7ID4QFl010550 for ; Mon, 18 Aug 2003 06:04:26 -0700 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.12) id 19ojh7-000Bnc-00; Mon, 18 Aug 2003 09:05:09 -0400 Subject: Re: [PATCH] Change MAC without bringing interface down From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: tv@debian.org, netdev@oss.sgi.com In-Reply-To: <20030818051227.4f35f2f3.davem@redhat.com> References: <20030818091312.GA4889@lapdog> <20030818041911.358c3437.davem@redhat.com> <1061208824.16010.2119.camel@jzny.localdomain> <20030818051227.4f35f2f3.davem@redhat.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1061211833.16010.2202.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 18 Aug 2003 09:03:54 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4958 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev This is fine by me. I 'll let Tommi take the lead on it unless he is too busy. cheers, jamal On Mon, 2003-08-18 at 08:12, David S. Miller wrote: > On 18 Aug 2003 08:13:44 -0400 > jamal wrote: > > > Editing the header may be the better approach if you have a few hundred > > hhs already inserted (this was the issue i was faced with when VRRP was > > failing over when i was playing with it). I tried to flush the cache but > > it took longer to recover it. > > There is another reason I want the cache flushed. > > Those hh cache entries are what ARP resolved to when we > had the previous MAC address, not the one we have now. > > The ARPs may come back differently with the new MAC > address. > > I _REALLY REALLY_ don't want to have to change the > ->update() implementations. Although one thing I > would consider is a new ->update_src() operation > and if this were NULL we flush the entries instead. > > From skraw@ithnet.com Mon Aug 18 06:17:59 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 06:18:08 -0700 (PDT) Received: from heather-ng.ithnet.com (mail3.ithnet.com [217.64.64.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IDHvFl010958 for ; Mon, 18 Aug 2003 06:17:58 -0700 Received: (qmail 13508 invoked by uid 0); 18 Aug 2003 13:17:56 -0000 Received: from skraw@ithnet.com by heather-ng (Processed in 0.492152 secs); 18 Aug 2003 13:17:56 -0000 X-Virus-Status: No Received: from unknown (HELO ithnet.com) (217.64.64.14) by heather-ng.ithnet.com with SMTP; 18 Aug 2003 13:17:55 -0000 X-Sender-Authentication: SMTPafterPOP by from 217.64.64.14 Date: Mon, 18 Aug 2003 15:17:55 +0200 From: Stephan von Krawczynski To: "David S. Miller" Cc: willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030818151755.47096672.skraw@ithnet.com> In-Reply-To: <20030818055555.248f2a01.davem@redhat.com> References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> <200308171827130739.00C3905F@192.168.128.16> <1061141045.21885.74.camel@dhcp23.swansea.linux.org.uk> <20030817224849.GB734@alpha.home.local> <20030817223118.3cbc497c.davem@redhat.com> <20030818133957.3d3d51d2.skraw@ithnet.com> <20030818044419.0bc24d14.davem@redhat.com> <20030818143401.1352d158.skraw@ithnet.com> <20030818053007.7852ca77.davem@redhat.com> <20030818145316.3a81f70c.skraw@ithnet.com> <20030818055555.248f2a01.davem@redhat.com> Organization: ith Kommunikationstechnik GmbH X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4959 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: skraw@ithnet.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 05:55:55 -0700 "David S. Miller" wrote: > On Mon, 18 Aug 2003 14:53:16 +0200 > Stephan von Krawczynski wrote: > > > _And_ you did not explain so far why these implementations should > > not be RFC-conform or else illegal. > > Both responding and not responding on all interfaces for ARPs > is RFC conformant. This means both Linux and other systems > are within the rules. > > Under Linux, by default, IP addresses are owned by the system > not by interfaces. This increases the likelyhood of successful > communication on a subnet. In other words: it is more tolerant against broken setups. > For scenerios where this doesn't work, we have ways to make the > kernel behave the way you want it to. For sure. > There is no discussion about changing the default, because that > might break things for some people. So this discussion is pretty > useless. Ah yes. Maybe we are getting to the real point of the discussion. If I remember that right kernels 2.0 and 2.2 behave differently, so you are talking about setups for 2.4 kernels. I am very interested to hear what a valid setup looks like that is broken by the default behaviour of _other_ RFC-conformant implementations. That is exactly what you are telling us here. If you cannot describe such a setup, then you basically say you don't want to follow the mainstream because you want to keep broken setups going. I have heard things like that before from some well-known big company... Can't you simply state the true reason why you are playing shepherd for a dead cow? Regards, Stephan From davem@redhat.com Mon Aug 18 06:21:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 06:21:53 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IDLnFl011298 for ; Mon, 18 Aug 2003 06:21:50 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id GAA05520; Mon, 18 Aug 2003 06:14:21 -0700 Date: Mon, 18 Aug 2003 06:14:20 -0700 From: "David S. Miller" To: Stephan von Krawczynski Cc: willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030818061420.6255f3d9.davem@redhat.com> In-Reply-To: <20030818151755.47096672.skraw@ithnet.com> References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> <200308171827130739.00C3905F@192.168.128.16> <1061141045.21885.74.camel@dhcp23.swansea.linux.org.uk> <20030817224849.GB734@alpha.home.local> <20030817223118.3cbc497c.davem@redhat.com> <20030818133957.3d3d51d2.skraw@ithnet.com> <20030818044419.0bc24d14.davem@redhat.com> <20030818143401.1352d158.skraw@ithnet.com> <20030818053007.7852ca77.davem@redhat.com> <20030818145316.3a81f70c.skraw@ithnet.com> <20030818055555.248f2a01.davem@redhat.com> <20030818151755.47096672.skraw@ithnet.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4960 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 15:17:55 +0200 Stephan von Krawczynski wrote: > If I remember that right kernels 2.0 and 2.2 behave differently, so > you are talking about setups for 2.4 kernels. All kernel versions have had the ARP behavior we have now. Both 2.0 and 2.2 answer on all interfaces for ARP requests by default just like 2.4 does. This is why Alan is able to add constructive criticism to this discussion, this behavior goes back even to when he was maintaining the networking :) From davem@redhat.com Mon Aug 18 06:28:12 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 06:28:15 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IDSBFl011634 for ; Mon, 18 Aug 2003 06:28:12 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id GAA05624; Mon, 18 Aug 2003 06:21:02 -0700 Date: Mon, 18 Aug 2003 06:21:02 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: skraw@ithnet.com, willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030818062102.170c56e3.davem@redhat.com> In-Reply-To: <1061213027.16017.2220.camel@jzny.localdomain> References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> <200308171827130739.00C3905F@192.168.128.16> <1061141045.21885.74.camel@dhcp23.swansea.linux.org.uk> <20030817224849.GB734@alpha.home.local> <20030817223118.3cbc497c.davem@redhat.com> <20030818133957.3d3d51d2.skraw@ithnet.com> <20030818044419.0bc24d14.davem@redhat.com> <20030818143401.1352d158.skraw@ithnet.com> <20030818053007.7852ca77.davem@redhat.com> <20030818145316.3a81f70c.skraw@ithnet.com> <20030818055555.248f2a01.davem@redhat.com> <1061213027.16017.2220.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4961 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On 18 Aug 2003 09:23:48 -0400 jamal wrote: > Ok, heres a neat little feature requst: someone create arp rewrite rules > with ARPtable so we can have do MAC address aliasing. What you ask for is in 2.6.x already, I'm more than happy to put a backport it to 2.4.x too as it is a netfilter module that stands by itself. From skraw@ithnet.com Mon Aug 18 06:40:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 06:40:32 -0700 (PDT) Received: from heather-ng.ithnet.com (mail3.ithnet.com [217.64.64.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IDeQFl011992 for ; Mon, 18 Aug 2003 06:40:27 -0700 Received: (qmail 16621 invoked by uid 0); 18 Aug 2003 13:40:24 -0000 Received: from skraw@ithnet.com by heather-ng (Processed in 0.357751 secs); 18 Aug 2003 13:40:24 -0000 X-Virus-Status: No Received: from unknown (HELO ithnet.com) (217.64.64.14) by heather-ng.ithnet.com with SMTP; 18 Aug 2003 13:40:24 -0000 X-Sender-Authentication: SMTPafterPOP by from 217.64.64.14 Date: Mon, 18 Aug 2003 15:40:24 +0200 From: Stephan von Krawczynski To: "David S. Miller" Cc: hadi@cyberus.ca, willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030818154024.4c607783.skraw@ithnet.com> In-Reply-To: <20030818062102.170c56e3.davem@redhat.com> References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> <200308171827130739.00C3905F@192.168.128.16> <1061141045.21885.74.camel@dhcp23.swansea.linux.org.uk> <20030817224849.GB734@alpha.home.local> <20030817223118.3cbc497c.davem@redhat.com> <20030818133957.3d3d51d2.skraw@ithnet.com> <20030818044419.0bc24d14.davem@redhat.com> <20030818143401.1352d158.skraw@ithnet.com> <20030818053007.7852ca77.davem@redhat.com> <20030818145316.3a81f70c.skraw@ithnet.com> <20030818055555.248f2a01.davem@redhat.com> <1061213027.16017.2220.camel@jzny.localdomain> <20030818062102.170c56e3.davem@redhat.com> Organization: ith Kommunikationstechnik GmbH X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4962 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: skraw@ithnet.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 06:21:02 -0700 "David S. Miller" wrote: > On 18 Aug 2003 09:23:48 -0400 > jamal wrote: > > > Ok, heres a neat little feature requst: someone create arp rewrite rules > > with ARPtable so we can have do MAC address aliasing. > > What you ask for is in 2.6.x already, I'm more than happy to put a > backport it to 2.4.x too as it is a netfilter module that stands by > itself. Is netfilter completely SMP safe currently? Regards, Stephan From dominik.kubla@sciobyte.com Mon Aug 18 06:40:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 06:40:46 -0700 (PDT) Received: from server1.intern.kubla.de (dsl-213-023-213-112.arcor-ip.net [213.23.213.112]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IDeaFl011997 for ; Mon, 18 Aug 2003 06:40:40 -0700 Received: from duron.intern.kubla.de (duron.intern.kubla.de [192.168.2.7]) by server1.intern.kubla.de (Postfix) with ESMTP id 6F81F5B; Mon, 18 Aug 2003 15:40:24 +0200 (CEST) From: Dominik Kubla To: Stephan von Krawczynski , "David S. Miller" Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Date: Mon, 18 Aug 2003 15:40:23 +0200 User-Agent: KMail/1.5.3 Cc: willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org References: <20030728213933.F81299@coredump.scriptkiddie.org> <20030818044419.0bc24d14.davem@redhat.com> <20030818143401.1352d158.skraw@ithnet.com> In-Reply-To: <20030818143401.1352d158.skraw@ithnet.com> Organization: ScioByte Information Technologies MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200308181540.23709.dominik.kubla@sciobyte.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7IDeaFl011997 X-archive-position: 4963 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dominik.kubla@sciobyte.com Precedence: bulk X-list: netdev Am Montag, 18. August 2003 14:34 schrieb Stephan von Krawczynski: > David, this is the wrong way round. Others'/my question was not about the > implementation and technical considerations leading to it (bottom up), but > pure and simple (and top down): what is the _positive_ outcome of this > implementation compared to others? We are always talking of setups that > seem to be more complicated because of the current situation. So one would > expect that there are advantages that make up the discussed disadvantages. > And since I obviously don't have the knowledge to see them, I'd like to > learn and therefore ask: what are the advantages on the _users_ side? Very simple: no need for any IPMP crap on Linux. It just works. And that puts "answered" on all questions that were ever raised regarding that issue. Regards, Dominik -- ScioByte GmbH | ScioByte Information Technologies AG Fritz-Erler-Strasse 6 | Innere Güterstrasse 4 55129 Mainz (Germany) | 6304 Zug (Switzerland) Phone: +49 700 724 629 83 | Phone: +41 41 710 30 18 Fax: +49 700 724 629 84 | GnuPG: 1024D/717F16BB A384 F5F1 F566 5716 5485 27EF 3B00 C007 717F 16BB From skraw@ithnet.com Mon Aug 18 07:23:13 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 07:23:20 -0700 (PDT) Received: from heather-ng.ithnet.com (mail3.ithnet.com [217.64.64.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IENCFl012987 for ; Mon, 18 Aug 2003 07:23:13 -0700 Received: (qmail 22252 invoked by uid 0); 18 Aug 2003 14:23:10 -0000 Received: from skraw@ithnet.com by heather-ng (Processed in 0.415565 secs); 18 Aug 2003 14:23:10 -0000 X-Virus-Status: No Received: from unknown (HELO ithnet.com) (217.64.64.14) by heather-ng.ithnet.com with SMTP; 18 Aug 2003 14:23:10 -0000 X-Sender-Authentication: SMTPafterPOP by from 217.64.64.14 Date: Mon, 18 Aug 2003 16:23:10 +0200 From: Stephan von Krawczynski To: "David S. Miller" Cc: willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030818162310.4106c8c6.skraw@ithnet.com> In-Reply-To: <20030818061420.6255f3d9.davem@redhat.com> References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> <200308171827130739.00C3905F@192.168.128.16> <1061141045.21885.74.camel@dhcp23.swansea.linux.org.uk> <20030817224849.GB734@alpha.home.local> <20030817223118.3cbc497c.davem@redhat.com> <20030818133957.3d3d51d2.skraw@ithnet.com> <20030818044419.0bc24d14.davem@redhat.com> <20030818143401.1352d158.skraw@ithnet.com> <20030818053007.7852ca77.davem@redhat.com> <20030818145316.3a81f70c.skraw@ithnet.com> <20030818055555.248f2a01.davem@redhat.com> <20030818151755.47096672.skraw@ithnet.com> <20030818061420.6255f3d9.davem@redhat.com> Organization: ith Kommunikationstechnik GmbH X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4964 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: skraw@ithnet.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 06:14:20 -0700 "David S. Miller" wrote: > On Mon, 18 Aug 2003 15:17:55 +0200 > Stephan von Krawczynski wrote: > > > If I remember that right kernels 2.0 and 2.2 behave differently, so > > you are talking about setups for 2.4 kernels. > > All kernel versions have had the ARP behavior we have now. They have not. I just tried. I have two boxes with 2 interfaces each and a third for testing. Testbox 1 has 2.2 kernel, testbox 2 has 2.4 kernel. The three are connected via same switch on primary if. I ping the second if ip of testbox 2, then arp -vn and see the second ip with a mac entry of testbox 2 primary if. I ping the second if ip of testbox 1, then arp -vn and see _no_ entry for this second ip, it is in fact routed (which I would state as the expected behaviour as the second ip is from another subnet). > Both 2.0 and 2.2 answer on all interfaces for ARP requests > by default just like 2.4 does. Try it. Proven wrong. See above. Regards, Stephan From tv@tv.debian.net Mon Aug 18 07:25:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 07:25:19 -0700 (PDT) Received: from yin.wanderer.org (yin.wanderer.org [195.218.87.139]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IEPDFl013241 for ; Mon, 18 Aug 2003 07:25:14 -0700 Received: by yin.wanderer.org (Postfix, from userid 1000) id 60B3EACE3; Mon, 18 Aug 2003 17:25:10 +0300 (EEST) Date: Mon, 18 Aug 2003 17:24:55 +0300 X-OfflineIMAP-630340391-72656d6f74652d74764074762e64656269616e2e6e6574-494e424f582e6f7574626f78: 1061216711-000669428722801 From: Tommi Virtanen To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Change MAC without bringing interface down Message-ID: <20030818142455.GA1793@lapdog> References: <20030818091312.GA4889@lapdog> <20030818041911.358c3437.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030818041911.358c3437.davem@redhat.com> User-Agent: Mutt/1.5.4i X-archive-position: 4965 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tv@debian.org Precedence: bulk X-list: netdev On Mon, Aug 18, 2003 at 04:19:11AM -0700, David S. Miller wrote: > On Mon, 18 Aug 2003 12:13:12 +0300 > > 1. makes eth_header_cache_update also update the source MAC in > > hh_cache. > > > > 2. adds a NETDEV_CHANGEADDR notifier in net/core/neighbour.c > > that walks through all the neighbour entries and updates > > the hh_cache's for all the neighbour entries related to > > given device. > I would suggest to fix this by instead flushing the hh > entries (just like neigh_destroy() does). This may be a dumb question, but how do I do that? If I set them to neigh_blackhole, like neigh_destroy() does, e.g. already running gets -ENETDOWN. That's now true and it's not nice. I'm having trouble seeing how to "disable" the neighbour entry, so it won't be used again. If I use neigh_suspect() in an attempt to mark the entry as "expired", I see traffic using the "old" MAC as source after a while. Apparently, it gets confirmed and then the old MAC is used again. > This way, we don't have to fix up every single header cache > implementation, that's painful :( I agree with that, though I am only interested in ethernet ;) -- :(){ :|:&};: From davem@redhat.com Mon Aug 18 07:26:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 07:26:40 -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 h7IEQaFl013624 for ; Mon, 18 Aug 2003 07:26:37 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id HAA05838; Mon, 18 Aug 2003 07:19:28 -0700 Date: Mon, 18 Aug 2003 07:19:28 -0700 From: "David S. Miller" To: Stephan von Krawczynski Cc: willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030818071928.163a4957.davem@redhat.com> In-Reply-To: <20030818162310.4106c8c6.skraw@ithnet.com> References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> <200308171827130739.00C3905F@192.168.128.16> <1061141045.21885.74.camel@dhcp23.swansea.linux.org.uk> <20030817224849.GB734@alpha.home.local> <20030817223118.3cbc497c.davem@redhat.com> <20030818133957.3d3d51d2.skraw@ithnet.com> <20030818044419.0bc24d14.davem@redhat.com> <20030818143401.1352d158.skraw@ithnet.com> <20030818053007.7852ca77.davem@redhat.com> <20030818145316.3a81f70c.skraw@ithnet.com> <20030818055555.248f2a01.davem@redhat.com> <20030818151755.47096672.skraw@ithnet.com> <20030818061420.6255f3d9.davem@redhat.com> <20030818162310.4106c8c6.skraw@ithnet.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4966 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 16:23:10 +0200 Stephan von Krawczynski wrote: > > Both 2.0 and 2.2 answer on all interfaces for ARP requests > > by default just like 2.4 does. > > Try it. Proven wrong. See above. Ok then. It still doesn't change the essence of this conversation. Changing things would break a lot of people's setups. See the other posting from someone about IPMP (IP multipathing). From davem@redhat.com Mon Aug 18 07:27:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 07:27: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 h7IERSFl013887 for ; Mon, 18 Aug 2003 07:27:28 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id HAA05865; Mon, 18 Aug 2003 07:20:44 -0700 Date: Mon, 18 Aug 2003 07:20:44 -0700 From: "David S. Miller" To: Tommi Virtanen Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Change MAC without bringing interface down Message-Id: <20030818072044.5a41ced5.davem@redhat.com> In-Reply-To: <20030818142455.GA1793@lapdog> References: <20030818091312.GA4889@lapdog> <20030818041911.358c3437.davem@redhat.com> <20030818142455.GA1793@lapdog> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4967 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 17:24:55 +0300 Tommi Virtanen wrote: > > I would suggest to fix this by instead flushing the hh > > entries (just like neigh_destroy() does). > > This may be a dumb question, but how do I do that? > > If I set them to neigh_blackhole, like neigh_destroy() does, > e.g. already running gets -ENETDOWN. That's now true and it's > not nice. I'm having trouble seeing how to "disable" the > neighbour entry, so it won't be used again. You have to also remove them from the list, like neigh_destroy() does, are you doing that as well? From willy@w.ods.org Mon Aug 18 07:29:19 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 07:29:23 -0700 (PDT) Received: from www.home.local (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IETHFl014290 for ; Mon, 18 Aug 2003 07:29:18 -0700 Received: from alpha.home.local (alpha [10.0.1.2]) by www.home.local (8.12.1/8.12.1) with ESMTP id h7IETBpn032615; Mon, 18 Aug 2003 16:29:11 +0200 Received: (from willy@localhost) by alpha.home.local (8.12.4/8.12.1) id h7IESlTr020135; Mon, 18 Aug 2003 16:28:47 +0200 Date: Mon, 18 Aug 2003 16:28:47 +0200 From: Willy Tarreau To: "David S. Miller" Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-ID: <20030818142847.GA19910@alpha.home.local> References: <200308171759540391.00AA8CAB@192.168.128.16> <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> <200308171827130739.00C3905F@192.168.128.16> <1061141045.21885.74.camel@dhcp23.swansea.linux.org.uk> <20030817224849.GB734@alpha.home.local> <20030817223118.3cbc497c.davem@redhat.com> <20030818133957.3d3d51d2.skraw@ithnet.com> <20030818044419.0bc24d14.davem@redhat.com> <20030818125158.GA18699@alpha.home.local> <20030818055329.44db9262.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030818055329.44db9262.davem@redhat.com> User-Agent: Mutt/1.4i X-archive-position: 4968 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@w.ods.org Precedence: bulk X-list: netdev [Cc: list stripped down to MLs only] > > > 2) what the default behavior should be > > > > I think we should apply the exact same source selection as IP to ARP. > > This is what setting the "arp_filter" sysctl on a device does > if you've setup the preferred source on your routes correctly. > If we would use that IP address to speak to the destination in > the ARP, we respond, else we do not. > > I've quoted the 'arp_filter' entry in Documentation/sysctl/ip-sysctl.txt > please give it a read. I've read it, but it's not about the same problem. It solves some problems related to *INCOMING REQUESTS*, that some people are complaining about. My problem was with source address for *OUTGOING REQUESTS*, and the arp_filter sysctl has nothing to do with it since it. Arptables helps fixing this problem. I fully respect your desire not to break existing behaviour, because even if I'm fairly certain that *nobody* uses the current "feature" I'm facing, it's possible that a definitive fix would break the workarounds they have set up for this problem. But if you agree to review it, I'm willing to write a simple patch which provides a sysctl to enable automatic valid source for *OUTGOING REQUESTS*. Basically, echoing 1 to /proc/sys/net/ipv4/ethXXX/arp_auto_src would select a valid source address for outgoing ARP requests. I can even do it both for 2.4 and 2.6 (just need a bit more time). All other strange setups will have to be left to arptables. Now if you think that the behaviour I'm proposing is broken, please explain me why. I'm not closed, I just want to understand, and since the beginning, I've only heard about ARP replies but not requests. Cheers, Willy From davem@redhat.com Mon Aug 18 07:35:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 07:35:27 -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 h7IEZNFl014674 for ; Mon, 18 Aug 2003 07:35:24 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id HAA05915; Mon, 18 Aug 2003 07:28:33 -0700 Date: Mon, 18 Aug 2003 07:28:33 -0700 From: "David S. Miller" To: Willy Tarreau Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030818072833.1ea7a81b.davem@redhat.com> In-Reply-To: <20030818142847.GA19910@alpha.home.local> References: <200308171759540391.00AA8CAB@192.168.128.16> <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> <200308171827130739.00C3905F@192.168.128.16> <1061141045.21885.74.camel@dhcp23.swansea.linux.org.uk> <20030817224849.GB734@alpha.home.local> <20030817223118.3cbc497c.davem@redhat.com> <20030818133957.3d3d51d2.skraw@ithnet.com> <20030818044419.0bc24d14.davem@redhat.com> <20030818125158.GA18699@alpha.home.local> <20030818055329.44db9262.davem@redhat.com> <20030818142847.GA19910@alpha.home.local> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4969 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 16:28:47 +0200 Willy Tarreau wrote: > Now if you think that the behaviour I'm proposing is broken, please explain me > why. If the user overrides the source address (which is the case I believe you're talking about, there are so many cases it's hard for me to keep track) then HE KNOWS WHAT HE IS DOING even if using that source address to talk to a particular remote address makes no sense. From linux-netdev@gmane.org Mon Aug 18 07:38:55 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 07:38:57 -0700 (PDT) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IEcrFl015020 for ; Mon, 18 Aug 2003 07:38:55 -0700 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19olAq-0006XX-00 for ; Mon, 18 Aug 2003 16:39:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: netdev@oss.sgi.com Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19olAp-0006XN-00 for ; Mon, 18 Aug 2003 16:39:55 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19ol9m-00011b-00 for ; Mon, 18 Aug 2003 16:38:50 +0200 From: Jason Lunz Subject: Re: double-check me? Date: Mon, 18 Aug 2003 14:38:50 +0000 (UTC) Organization: PBR Streetgang Lines: 8 Message-ID: References: <3F3FBF50.8070207@pobox.com> <3F400226.1080006@pobox.com> X-Complaints-To: usenet@sea.gmane.org User-Agent: slrn/0.9.7.4 (Linux) X-archive-position: 4970 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lunz@falooley.org Precedence: bulk X-list: netdev jgarzik@pobox.com said: > C pointer arithmatic. Ok, duh, thanks :) > Jeff, too used to void pointer arith Don't get _too_ used to it. arithmetic on (void *) is a gcc extension. it's undefined in ansi C. Jason From garzik@gtf.org Mon Aug 18 07:41:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 07:41:29 -0700 (PDT) Received: from havoc.gtf.org ([63.247.75.124]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IEfPFl015353 for ; Mon, 18 Aug 2003 07:41:26 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id A71366643; Mon, 18 Aug 2003 10:41:19 -0400 (EDT) Date: Mon, 18 Aug 2003 10:41:19 -0400 From: Jeff Garzik To: Jason Lunz Cc: netdev@oss.sgi.com Subject: Re: double-check me? Message-ID: <20030818144119.GA24693@gtf.org> References: <3F3FBF50.8070207@pobox.com> <3F400226.1080006@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-archive-position: 4971 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev On Mon, Aug 18, 2003 at 02:38:50PM +0000, Jason Lunz wrote: > jgarzik@pobox.com said: > > C pointer arithmatic. Ok, duh, thanks :) > > Jeff, too used to void pointer arith > > Don't get _too_ used to it. arithmetic on (void *) is a gcc extension. > it's undefined in ansi C. Yes, I know. It's used extensively in the kernel, however. Jeff From hadi@cyberus.ca Mon Aug 18 08:10:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 08:10:56 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IFAnFl017218 for ; Mon, 18 Aug 2003 08:10:49 -0700 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.12) id 19olei-000LiF-00; Mon, 18 Aug 2003 11:10:48 -0400 Subject: Re: [PATCH] Change MAC without bringing interface down From: jamal Reply-To: hadi@cyberus.ca To: Tommi Virtanen Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20030818142455.GA1793@lapdog> References: <20030818091312.GA4889@lapdog> <20030818041911.358c3437.davem@redhat.com> <20030818142455.GA1793@lapdog> Content-Type: text/plain Organization: jamalopolis Message-Id: <1061219448.1031.20.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 18 Aug 2003 11:10:48 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4972 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev If you are going that approach then please if you have time do some measurement on editing vs flushing with X number of cache entries. go with X being a max of 200. cheers, jamal On Mon, 2003-08-18 at 10:24, Tommi Virtanen wrote: > > > This way, we don't have to fix up every single header cache > > implementation, that's painful :( > > I agree with that, though I am only interested in ethernet ;) From skraw@ithnet.com Mon Aug 18 08:46:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 08:46:36 -0700 (PDT) Received: from heather-ng.ithnet.com (mail3.ithnet.com [217.64.64.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IFkTFl018367 for ; Mon, 18 Aug 2003 08:46:30 -0700 Received: (qmail 31384 invoked by uid 0); 18 Aug 2003 15:46:27 -0000 Received: from skraw@ithnet.com by heather-ng (Processed in 0.434563 secs); 18 Aug 2003 15:46:27 -0000 X-Virus-Status: No Received: from unknown (HELO ithnet.com) (217.64.64.14) by heather-ng.ithnet.com with SMTP; 18 Aug 2003 15:46:26 -0000 X-Sender-Authentication: SMTPafterPOP by from 217.64.64.14 Date: Mon, 18 Aug 2003 17:46:26 +0200 From: Stephan von Krawczynski To: "David S. Miller" Cc: willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030818174626.4dd57655.skraw@ithnet.com> In-Reply-To: <20030818071928.163a4957.davem@redhat.com> References: <20030728213933.F81299@coredump.scriptkiddie.org> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> <200308171827130739.00C3905F@192.168.128.16> <1061141045.21885.74.camel@dhcp23.swansea.linux.org.uk> <20030817224849.GB734@alpha.home.local> <20030817223118.3cbc497c.davem@redhat.com> <20030818133957.3d3d51d2.skraw@ithnet.com> <20030818044419.0bc24d14.davem@redhat.com> <20030818143401.1352d158.skraw@ithnet.com> <20030818053007.7852ca77.davem@redhat.com> <20030818145316.3a81f70c.skraw@ithnet.com> <20030818055555.248f2a01.davem@redhat.com> <20030818151755.47096672.skraw@ithnet.com> <20030818061420.6255f3d9.davem@redhat.com> <20030818162310.4106c8c6.skraw@ithnet.com> <20030818071928.163a4957.davem@redhat.com> Organization: ith Kommunikationstechnik GmbH X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4973 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: skraw@ithnet.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 07:19:28 -0700 "David S. Miller" wrote: > On Mon, 18 Aug 2003 16:23:10 +0200 > Stephan von Krawczynski wrote: > > > > Both 2.0 and 2.2 answer on all interfaces for ARP requests > > > by default just like 2.4 does. > > > > Try it. Proven wrong. See above. > > Ok then. > > It still doesn't change the essence of this conversation. Changing > things would break a lot of people's setups. Please explain _one_. I mean you must have something special in your mind, or not? > See the other posting from someone about IPMP (IP multipathing). Perhaps it would have been a good idea to explain some details about what he thinks would break if default behaviour was changed. At least for me it is non-obvious. He could have stated "42", too... Regards, Stephan From tv@tv.debian.net Mon Aug 18 09:04:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 09:04:40 -0700 (PDT) Received: from yin.wanderer.org (yin.wanderer.org [195.218.87.139]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IG4XFl018862 for ; Mon, 18 Aug 2003 09:04:35 -0700 Received: by yin.wanderer.org (Postfix, from userid 1000) id E3548ACE4; Mon, 18 Aug 2003 19:04:30 +0300 (EEST) Date: Mon, 18 Aug 2003 19:04:22 +0300 X-OfflineIMAP-69992918-72656d6f74652d74764074762e64656269616e2e6e6574-494e424f582e6f7574626f78: 1061222672-0110636175383 From: Tommi Virtanen To: "David S. Miller" Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: [PATCH] Change MAC without bringing interface down Message-ID: <20030818160422.GB1793@lapdog> References: <20030818091312.GA4889@lapdog> <20030818041911.358c3437.davem@redhat.com> <1061208824.16010.2119.camel@jzny.localdomain> <20030818051227.4f35f2f3.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030818051227.4f35f2f3.davem@redhat.com> User-Agent: Mutt/1.5.4i X-archive-position: 4975 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tv@debian.org Precedence: bulk X-list: netdev On Mon, Aug 18, 2003 at 05:12:27AM -0700, David S. Miller wrote: > There is another reason I want the cache flushed. Alright, here's an implementation that does that. Please comment. A single flood ping from uml->host survives MAC changes perfectly without dropping a single packet. (Can't test realworld performance right now.) Note I had to flush the route cache also, that was tricking me previously. Clearing neigh_table isn't enough, as the hh is reached from dst_entries also. ===== include/net/neighbour.h 1.1 vs edited ===== --- 1.1/include/net/neighbour.h Tue Feb 5 19:39:48 2002 +++ edited/include/net/neighbour.h Mon Aug 18 18:52:30 2003 @@ -180,6 +180,7 @@ extern void neigh_destroy(struct neighbour *neigh); extern int __neigh_event_send(struct neighbour *neigh, struct sk_buff *skb); extern int neigh_update(struct neighbour *neigh, const u8 *lladdr, u8 new, int override, int arp); +extern void neigh_changeaddr(struct neigh_table *tbl, struct net_device *dev); extern int neigh_ifdown(struct neigh_table *tbl, struct net_device *dev); extern int neigh_resolve_output(struct sk_buff *skb); extern int neigh_connected_output(struct sk_buff *skb); ===== net/core/neighbour.c 1.9 vs edited ===== --- 1.9/net/core/neighbour.c Thu Jun 12 09:24:41 2003 +++ edited/net/core/neighbour.c Mon Aug 18 18:52:41 2003 @@ -50,6 +50,7 @@ static void neigh_app_notify(struct neighbour *n); #endif static int pneigh_ifdown(struct neigh_table *tbl, struct net_device *dev); +void neigh_changeaddr(struct neigh_table *tbl, struct net_device *dev); static int neigh_glbl_allocs; static struct neigh_table *neigh_tables; @@ -167,6 +168,33 @@ dev_put(skb->dev); kfree_skb(skb); } +} + +void neigh_changeaddr(struct neigh_table *tbl, struct net_device *dev) +{ + int i; + + write_lock_bh(&tbl->lock); + + for (i=0; i<=NEIGH_HASHMASK; i++) { + struct neighbour *n, **np; + + np = &tbl->hash_buckets[i]; + while ((n = *np) != NULL) { + if (dev && n->dev != dev) { + np = &n->next; + continue; + } + *np = n->next; + write_lock_bh(&n->lock); + n->dead = 1; + neigh_del_timer(n); + write_unlock_bh(&n->lock); + neigh_release(n); + } + } + + write_unlock_bh(&tbl->lock); } int neigh_ifdown(struct neigh_table *tbl, struct net_device *dev) ===== net/ipv4/arp.c 1.11 vs edited ===== --- 1.11/net/ipv4/arp.c Fri Jun 27 09:03:01 2003 +++ edited/net/ipv4/arp.c Mon Aug 18 18:51:10 2003 @@ -1212,6 +1212,28 @@ } #endif +static int arp_netdev_event(struct notifier_block *this, unsigned long event, void *ptr) +{ + struct net_device *dev = ptr; + + switch (event) { + case NETDEV_CHANGEADDR: + neigh_changeaddr(&arp_tbl, dev); + rt_cache_flush(0); + break; + default: + break; + } + + return NOTIFY_DONE; +} + +struct notifier_block arp_netdev_notifier = { + arp_netdev_event, + NULL, + 0 +}; + /* Note, that it is not on notifier chain. It is necessary, that this routine was called after route cache will be flushed. @@ -1243,6 +1265,7 @@ #ifdef CONFIG_SYSCTL neigh_sysctl_register(NULL, &arp_tbl.parms, NET_IPV4, NET_IPV4_NEIGH, "ipv4"); #endif + register_netdevice_notifier(&arp_netdev_notifier); } ===== net/ipv6/ndisc.c 1.22 vs edited ===== --- 1.22/net/ipv6/ndisc.c Tue Jun 24 02:21:28 2003 +++ edited/net/ipv6/ndisc.c Mon Aug 18 18:51:40 2003 @@ -1336,6 +1336,28 @@ return 0; } +static int ndisc_netdev_event(struct notifier_block *this, unsigned long event, void *ptr) +{ + struct net_device *dev = ptr; + + switch (event) { + case NETDEV_CHANGEADDR: + neigh_changeaddr(&nd_tbl, dev); + rt_cache_flush(0); + break; + default: + break; + } + + return NOTIFY_DONE; +} + +struct notifier_block ndisc_netdev_notifier = { + ndisc_netdev_event, + NULL, + 0 +}; + int __init ndisc_init(struct net_proto_family *ops) { struct sock *sk; @@ -1377,6 +1399,7 @@ neigh_sysctl_register(NULL, &nd_tbl.parms, NET_IPV6, NET_IPV6_NEIGH, "ipv6"); #endif + register_netdevice_notifier(&ndisc_netdev_notifier); return 0; } -- :(){ :|:&};: From shemminger@osdl.org Mon Aug 18 09:04:23 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 09:04:27 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IG4LFl018847 for ; Mon, 18 Aug 2003 09:04:22 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7IG3Oo14062; Mon, 18 Aug 2003 09:03:24 -0700 Date: Mon, 18 Aug 2003 09:03:13 -0700 From: Stephen Hemminger To: jt@hpl.hp.com Cc: jt@bougret.hpl.hp.com, "David S. Miller" , irda-users@lists.sourceforge.net, netdev@oss.sgi.com, lists@mdiehl.de Subject: Re: [PATCH] (1/5) get rid of useless hashbin in irtty Message-Id: <20030818090313.7f153d7a.shemminger@osdl.org> In-Reply-To: <20030817011131.GA2120@bougret.hpl.hp.com> References: <20030815154608.56cf0551.shemminger@osdl.org> <20030815230546.GA31831@bougret.hpl.hp.com> <20030816052048.5858d68a.davem@redhat.com> <20030817001405.GA1916@bougret.hpl.hp.com> <20030816175851.58a2c179.davem@redhat.com> <20030817011131.GA2120@bougret.hpl.hp.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4974 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Sat, 16 Aug 2003 18:11:31 -0700 Jean Tourrilhes wrote: > On Sat, Aug 16, 2003 at 05:58:51PM -0700, David S. Miller wrote: > > On Sat, 16 Aug 2003 17:14:05 -0700 > > Jean Tourrilhes wrote: > > > > > Curently driver do work properly (including SMP). > > > > Users can hold onto procfs files after the driver > > modules are unloaded. For example: > > > > rmmod eth0 > > > If IRDA creates any procfs files for devices that are > > registered, you have this problem too. > > > > This is not fixable without first making sure every net driver in the > > entire tree abides by a few rules, and that is what Stephen is doing. > > No problem, it's just that with the total lack of testing of > IrDA in 2.6.0, I'm a bit nervous, as always. Would it be possible for > Stephen to use some real IrDA hardware so that he can double check > what he is doing ? > Have fun... I have some, but haven't used it so far. For the load/unload testing, it is possible to setup irtty (and irlan) without real hardware. So far, haven't had to change the hardware drivers. From davem@redhat.com Mon Aug 18 09:13:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 09:13:46 -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 h7IGDeFl019674 for ; Mon, 18 Aug 2003 09:13:41 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id JAA06298; Mon, 18 Aug 2003 09:06:54 -0700 Date: Mon, 18 Aug 2003 09:06:54 -0700 From: "David S. Miller" To: Tommi Virtanen Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: [PATCH] Change MAC without bringing interface down Message-Id: <20030818090654.7f44a16e.davem@redhat.com> In-Reply-To: <20030818160422.GB1793@lapdog> References: <20030818091312.GA4889@lapdog> <20030818041911.358c3437.davem@redhat.com> <1061208824.16010.2119.camel@jzny.localdomain> <20030818051227.4f35f2f3.davem@redhat.com> <20030818160422.GB1793@lapdog> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4976 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 19:04:22 +0300 Tommi Virtanen wrote: > ===== net/ipv6/ndisc.c 1.22 vs edited ===== > --- 1.22/net/ipv6/ndisc.c Tue Jun 24 02:21:28 2003 > +++ edited/net/ipv6/ndisc.c Mon Aug 18 18:51:40 2003 ... > + case NETDEV_CHANGEADDR: > + neigh_changeaddr(&nd_tbl, dev); > + rt_cache_flush(0); Don't flush the ipv4 routing cache from ipv6 please :-) From master@tentacle.sectorb.msk.ru Mon Aug 18 09:27:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 09:27:49 -0700 (PDT) Received: from tentacle.sectorb.msk.ru (postfix@tentacle.s2s.msu.ru [193.232.119.109]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IGRSFl020095 for ; Mon, 18 Aug 2003 09:27:29 -0700 Received: by tentacle.sectorb.msk.ru (Postfix, from userid 10001) id 719C76EEE; Mon, 18 Aug 2003 19:49:46 +0400 (MSD) Date: Mon, 18 Aug 2003 19:49:46 +0400 From: "Vladimir B. Savkin" To: Carlos Velasco Cc: Alan Cox , "David S. Miller" , Marcelo Tosatti , netdev@oss.sgi.com, linux-net@vger.kernel.org, Linux Kernel Mailing List Subject: SRC IP selection in ARP request (Was: bugfix: ARP respond on all devices) Message-ID: <20030818154945.GA32191@tentacle.sectorb.msk.ru> References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> <200308171827130739.00C3905F@192.168.128.16> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <200308171827130739.00C3905F@192.168.128.16> User-Agent: Mutt/1.3.28i X-Organization: Moscow State Univ., Dept. of Mechanics and Mathematics X-Operating-System: Linux 2.4.22-rc2 X-archive-position: 4977 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: master@sectorb.msk.ru Precedence: bulk X-list: netdev On Sun, Aug 17, 2003 at 06:27:13PM +0200, Carlos Velasco wrote: > If you send a packet through dev eth0 to dev lo IP address or other ^^ Did you mean "from"? > interface, when Linux try to map the MAC address with the IP address of > the default gateway (or the gateway to reach the packet Source IP > address), it uses the lo IP address (or other dev) in the ARP Request. I think I saw this problem, but in another situation: Suppose we are the server and have TCP connection established, using src address 10.0.0.1 (because the client have chosen this address to connect to). But the route to the client leads via gateway 10.1.0.1, reachable through dev eth0. We have address 10.1.0.2/24 assigned to eth0. All is fine until ARP table entry for 10.1.0.1 is expired and we start to send ARP requests. We choose 10.0.0.1 for src ip in the requests, because that's what upper layer uses, and gateway doesn't respond because it's Cisco or BSD. I didn't test arpfilter (I think it wasn't there when I met this problem), but it can be solved with the following simple patch (implemented as a new per-interface sysctl). I just tested it, works for me. echo 1 > /proc/sys/net/ipv4/conf/all/arp_select_clean_src diff -ur _orig_linux/include/linux/inetdevice.h linux/include/linux/inetdevice.h --- _orig_linux/include/linux/inetdevice.h Mon Aug 11 13:24:51 2003 +++ linux/include/linux/inetdevice.h Mon Aug 18 18:21:30 2003 @@ -18,6 +18,7 @@ int mc_forwarding; int tag; int arp_filter; + int arp_select_clean_src; int medium_id; void *sysctl; }; @@ -68,6 +69,7 @@ (ipv4_devconf.accept_redirects || (in_dev)->cnf.accept_redirects))) #define IN_DEV_ARPFILTER(in_dev) (ipv4_devconf.arp_filter || (in_dev)->cnf.arp_filter) +#define IN_DEV_ARP_CLEAN_SRC(in_dev) (ipv4_devconf.arp_select_clean_src || (in_dev)->cnf.arp_select_clean_src) struct in_ifaddr { diff -ur _orig_linux/include/linux/sysctl.h linux/include/linux/sysctl.h --- _orig_linux/include/linux/sysctl.h Mon Aug 11 13:28:18 2003 +++ linux/include/linux/sysctl.h Mon Aug 18 18:52:01 2003 @@ -349,6 +349,7 @@ NET_IPV4_CONF_TAG=12, NET_IPV4_CONF_ARPFILTER=13, NET_IPV4_CONF_MEDIUM_ID=14, + NET_IPV4_CONF_ARPSRC=15, }; /* /proc/sys/net/ipv6 */ diff -ur _orig_linux/net/ipv4/arp.c linux/net/ipv4/arp.c --- _orig_linux/net/ipv4/arp.c Mon Aug 11 13:24:52 2003 +++ linux/net/ipv4/arp.c Mon Aug 18 18:36:44 2003 @@ -322,8 +322,20 @@ struct net_device *dev = neigh->dev; u32 target = *(u32*)neigh->primary_key; int probes = atomic_read(&neigh->probes); + int inherit_src; + struct in_device *in_dev; - if (skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL) + read_lock(&inetdev_lock); + in_dev = __in_dev_get(dev); + if (in_dev != NULL) { + inherit_src = !IN_DEV_ARP_CLEAN_SRC(in_dev); + } else { + inherit_src = 1; + } + read_unlock(&inetdev_lock); + + if ( inherit_src && + skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL) saddr = skb->nh.iph->saddr; else saddr = inet_select_addr(dev, target, RT_SCOPE_LINK); diff -ur _orig_linux/net/ipv4/devinet.c linux/net/ipv4/devinet.c --- _orig_linux/net/ipv4/devinet.c Fri Jun 13 18:51:39 2003 +++ linux/net/ipv4/devinet.c Mon Aug 18 18:54:07 2003 @@ -1056,7 +1056,7 @@ static struct devinet_sysctl_table { struct ctl_table_header *sysctl_header; - ctl_table devinet_vars[15]; + ctl_table devinet_vars[16]; ctl_table devinet_dev[2]; ctl_table devinet_conf_dir[2]; ctl_table devinet_proto_dir[2]; @@ -1104,6 +1104,9 @@ &proc_dointvec}, {NET_IPV4_CONF_ARPFILTER, "arp_filter", &ipv4_devconf.arp_filter, sizeof(int), 0644, NULL, + &proc_dointvec}, + {NET_IPV4_CONF_ARPSRC, "arp_select_clean_src", + &ipv4_devconf.arp_select_clean_src, sizeof(int), 0644, NULL, &proc_dointvec}, {0}}, :wq With best regards, Vladimir Savkin. From jt@bougret.hpl.hp.com Mon Aug 18 09:50:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 09:50:30 -0700 (PDT) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IGoPFl020602 for ; Mon, 18 Aug 2003 09:50:25 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel13.hp.com (Postfix) with ESMTP id 9FF2A1C00C4D; Mon, 18 Aug 2003 09:50:24 -0700 (PDT) Received: from bougret.hpl.hp.com (mail@bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_26305)/8.9.3 HPLabs Timeshare Server) with ESMTP id JAA12292; Mon, 18 Aug 2003 09:50:24 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 19onD6-0001Z6-00; Mon, 18 Aug 2003 09:50:24 -0700 Date: Mon, 18 Aug 2003 09:50:24 -0700 To: Stephen Hemminger Cc: "David S. Miller" , irda-users@lists.sourceforge.net, netdev@oss.sgi.com, lists@mdiehl.de Subject: Re: [PATCH] (1/5) get rid of useless hashbin in irtty Message-ID: <20030818165024.GB5992@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20030815154608.56cf0551.shemminger@osdl.org> <20030815230546.GA31831@bougret.hpl.hp.com> <20030816052048.5858d68a.davem@redhat.com> <20030817001405.GA1916@bougret.hpl.hp.com> <20030816175851.58a2c179.davem@redhat.com> <20030817011131.GA2120@bougret.hpl.hp.com> <20030818090313.7f153d7a.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030818090313.7f153d7a.shemminger@osdl.org> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 4978 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev On Mon, Aug 18, 2003 at 09:03:13AM -0700, Stephen Hemminger wrote: > On Sat, 16 Aug 2003 18:11:31 -0700 > Jean Tourrilhes wrote: > > > On Sat, Aug 16, 2003 at 05:58:51PM -0700, David S. Miller wrote: > > > On Sat, 16 Aug 2003 17:14:05 -0700 > > > Jean Tourrilhes wrote: > > > > > > > Curently driver do work properly (including SMP). > > > > > > Users can hold onto procfs files after the driver > > > modules are unloaded. For example: > > > > > > rmmod eth0 > > > > > If IRDA creates any procfs files for devices that are > > > registered, you have this problem too. > > > > > > This is not fixable without first making sure every net driver in the > > > entire tree abides by a few rules, and that is what Stephen is doing. > > > > No problem, it's just that with the total lack of testing of > > IrDA in 2.6.0, I'm a bit nervous, as always. Would it be possible for > > Stephen to use some real IrDA hardware so that he can double check > > what he is doing ? > > Have fun... > > I have some, but haven't used it so far. > For the load/unload testing, it is possible to setup irtty (and irlan) > without real hardware. So far, haven't had to change the hardware drivers. You can use irtty-sir with a cross-over serial cable between two PCs. IrLAN is a bit flaky and no longer maintained, I would recommend to try IrNET or RfCOMM. Thanks ! Jean From linux-netdev@gmane.org Mon Aug 18 09:52:04 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 09:52:06 -0700 (PDT) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IGpxFl020802 for ; Mon, 18 Aug 2003 09:52:02 -0700 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19oVBR-0005em-00 for ; Sun, 17 Aug 2003 23:35:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: netdev@oss.sgi.com Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19oVBQ-0005ee-00 for ; Sun, 17 Aug 2003 23:35:28 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19oVAM-0004YV-00 for ; Sun, 17 Aug 2003 23:34:22 +0200 From: Jason Lunz Subject: Re: double-check me? Date: Sun, 17 Aug 2003 21:34:22 +0000 (UTC) Organization: PBR Streetgang Lines: 17 Message-ID: References: <3F3FBF50.8070207@pobox.com> X-Complaints-To: usenet@sea.gmane.org User-Agent: slrn/0.9.7.4 (Linux) X-archive-position: 4979 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lunz@falooley.org Precedence: bulk X-list: netdev jgarzik@pobox.com said: > if (sizeof_priv) > dev->priv = (void *) (((long)(dev + 1) + 31) & ~31); > > > Now... shouldn't that last line of code be "dev + 1 + sizeof(*dev)" ? are you missing that the "dev + 1" pointer arithmetic is already adding sizeof(*dev) to dev, rather than just 1 byte? "(dev + 1)" is a pointer to the private area after the actual struct net_device, and "((long)(dev + 1) + 31)" adds 31 bytes of padding. The final "& ~31" chops off any excess padding from the 31 that was added and actually aligns the pointer. Seems right to me, but I'm not used to playing alignment tricks. Jason From garzik@gtf.org Mon Aug 18 09:53:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 09:53:31 -0700 (PDT) Received: from havoc.gtf.org ([63.247.75.124]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IGrRFl021237 for ; Mon, 18 Aug 2003 09:53:28 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id D747D6645; Mon, 18 Aug 2003 12:53:21 -0400 (EDT) Date: Mon, 18 Aug 2003 12:53:21 -0400 From: Jeff Garzik To: jt@hpl.hp.com Cc: Stephen Hemminger , "David S. Miller" , irda-users@lists.sourceforge.net, netdev@oss.sgi.com, lists@mdiehl.de Subject: Re: [PATCH] (1/5) get rid of useless hashbin in irtty Message-ID: <20030818165321.GH24693@gtf.org> References: <20030815154608.56cf0551.shemminger@osdl.org> <20030815230546.GA31831@bougret.hpl.hp.com> <20030816052048.5858d68a.davem@redhat.com> <20030817001405.GA1916@bougret.hpl.hp.com> <20030816175851.58a2c179.davem@redhat.com> <20030817011131.GA2120@bougret.hpl.hp.com> <20030818090313.7f153d7a.shemminger@osdl.org> <20030818165024.GB5992@bougret.hpl.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030818165024.GB5992@bougret.hpl.hp.com> User-Agent: Mutt/1.3.28i X-archive-position: 4980 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev On Mon, Aug 18, 2003 at 09:50:24AM -0700, Jean Tourrilhes wrote: > You can use irtty-sir with a cross-over serial cable between > two PCs. IrLAN is a bit flaky and no longer maintained, I would > recommend to try IrNET or RfCOMM. Can we remove IrLAN in 2.6, then? :) Jeff From jt@bougret.hpl.hp.com Mon Aug 18 10:08:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 10:08:57 -0700 (PDT) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IH8qFl021705 for ; Mon, 18 Aug 2003 10:08:52 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel13.hp.com (Postfix) with ESMTP id 60D8F1C01F06; Mon, 18 Aug 2003 10:08:52 -0700 (PDT) Received: from bougret.hpl.hp.com (mail@bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_26305)/8.9.3 HPLabs Timeshare Server) with ESMTP id KAA13506; Mon, 18 Aug 2003 10:08:51 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 19onUw-0001av-00; Mon, 18 Aug 2003 10:08:50 -0700 Date: Mon, 18 Aug 2003 10:08:50 -0700 To: Jeff Garzik Cc: Stephen Hemminger , "David S. Miller" , irda-users@lists.sourceforge.net, netdev@oss.sgi.com, lists@mdiehl.de Subject: Re: [PATCH] (1/5) get rid of useless hashbin in irtty Message-ID: <20030818170850.GE5992@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20030815154608.56cf0551.shemminger@osdl.org> <20030815230546.GA31831@bougret.hpl.hp.com> <20030816052048.5858d68a.davem@redhat.com> <20030817001405.GA1916@bougret.hpl.hp.com> <20030816175851.58a2c179.davem@redhat.com> <20030817011131.GA2120@bougret.hpl.hp.com> <20030818090313.7f153d7a.shemminger@osdl.org> <20030818165024.GB5992@bougret.hpl.hp.com> <20030818165321.GH24693@gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030818165321.GH24693@gtf.org> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 4981 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev On Mon, Aug 18, 2003 at 12:53:21PM -0400, Jeff Garzik wrote: > On Mon, Aug 18, 2003 at 09:50:24AM -0700, Jean Tourrilhes wrote: > > You can use irtty-sir with a cross-over serial cable between > > two PCs. IrLAN is a bit flaky and no longer maintained, I would > > recommend to try IrNET or RfCOMM. > > Can we remove IrLAN in 2.6, then? :) > > Jeff The problem is that we don't have another implementation of IrLAN. There are a few devices that talk IrLAN (NetBeamIr, Win95), and for those there is no alternative and IrLAN works good enough with them (I test it every few months). No need to remove it if it still works... If you really are in cleanup mood, you can kill : o irtty (broken - replaced by irtty-sir + sir-dev) o toshoboe (no spinlock - replaced by donauboe) o smc-ircc (flaky - replaced by smsc-ircc2) o ep7211_ir (obsolete hardware, unmaintained) Happy ? Have fun... Jean From tv@tv.debian.net Mon Aug 18 10:12:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 10:12:07 -0700 (PDT) Received: from yin.wanderer.org (yin.wanderer.org [195.218.87.139]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IHC1Fl022057 for ; Mon, 18 Aug 2003 10:12:02 -0700 Received: by yin.wanderer.org (Postfix, from userid 1000) id 13F0CACE3; Mon, 18 Aug 2003 20:11:57 +0300 (EEST) Date: Mon, 18 Aug 2003 20:11:44 +0300 X-OfflineIMAP-152919476-72656d6f74652d74764074762e64656269616e2e6e6574-494e424f582e6f7574626f78: 1061226719-0837599468151 From: Tommi Virtanen To: "David S. Miller" Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: [PATCH] Change MAC without bringing interface down Message-ID: <20030818171144.GC1793@lapdog> References: <20030818091312.GA4889@lapdog> <20030818041911.358c3437.davem@redhat.com> <1061208824.16010.2119.camel@jzny.localdomain> <20030818051227.4f35f2f3.davem@redhat.com> <20030818160422.GB1793@lapdog> <20030818090654.7f44a16e.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030818090654.7f44a16e.davem@redhat.com> User-Agent: Mutt/1.5.4i X-archive-position: 4982 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tv@debian.org Precedence: bulk X-list: netdev On Mon, Aug 18, 2003 at 09:06:54AM -0700, David S. Miller wrote: > > ===== net/ipv6/ndisc.c 1.22 vs edited ===== > > --- 1.22/net/ipv6/ndisc.c Tue Jun 24 02:21:28 2003 > > +++ edited/net/ipv6/ndisc.c Mon Aug 18 18:51:40 2003 > ... > > + case NETDEV_CHANGEADDR: > > + neigh_changeaddr(&nd_tbl, dev); > > + rt_cache_flush(0); > > Don't flush the ipv4 routing cache from ipv6 please :-) Good point. I don't have an IPv6 test setup, so that side is.. umm.. improvised ;) Here's the updated patch; I feel this is suitable for inclusion, performance can always be improved; remember, the current situation is either 10s..1min of no traffic passing because you had to bring down the interface, or cache lifetime of existing flows using the old MAC. This is a whole lot better. ===== include/net/neighbour.h 1.1 vs edited ===== --- 1.1/include/net/neighbour.h Tue Feb 5 19:39:48 2002 +++ edited/include/net/neighbour.h Mon Aug 18 18:52:30 2003 @@ -180,6 +180,7 @@ extern void neigh_destroy(struct neighbour *neigh); extern int __neigh_event_send(struct neighbour *neigh, struct sk_buff *skb); extern int neigh_update(struct neighbour *neigh, const u8 *lladdr, u8 new, int override, int arp); +extern void neigh_changeaddr(struct neigh_table *tbl, struct net_device *dev); extern int neigh_ifdown(struct neigh_table *tbl, struct net_device *dev); extern int neigh_resolve_output(struct sk_buff *skb); extern int neigh_connected_output(struct sk_buff *skb); ===== net/core/neighbour.c 1.9 vs edited ===== --- 1.9/net/core/neighbour.c Thu Jun 12 09:24:41 2003 +++ edited/net/core/neighbour.c Mon Aug 18 18:52:41 2003 @@ -50,6 +50,7 @@ static void neigh_app_notify(struct neighbour *n); #endif static int pneigh_ifdown(struct neigh_table *tbl, struct net_device *dev); +void neigh_changeaddr(struct neigh_table *tbl, struct net_device *dev); static int neigh_glbl_allocs; static struct neigh_table *neigh_tables; @@ -167,6 +168,33 @@ dev_put(skb->dev); kfree_skb(skb); } +} + +void neigh_changeaddr(struct neigh_table *tbl, struct net_device *dev) +{ + int i; + + write_lock_bh(&tbl->lock); + + for (i=0; i<=NEIGH_HASHMASK; i++) { + struct neighbour *n, **np; + + np = &tbl->hash_buckets[i]; + while ((n = *np) != NULL) { + if (dev && n->dev != dev) { + np = &n->next; + continue; + } + *np = n->next; + write_lock_bh(&n->lock); + n->dead = 1; + neigh_del_timer(n); + write_unlock_bh(&n->lock); + neigh_release(n); + } + } + + write_unlock_bh(&tbl->lock); } int neigh_ifdown(struct neigh_table *tbl, struct net_device *dev) ===== net/ipv4/arp.c 1.11 vs edited ===== --- 1.11/net/ipv4/arp.c Fri Jun 27 09:03:01 2003 +++ edited/net/ipv4/arp.c Mon Aug 18 18:51:10 2003 @@ -1212,6 +1212,28 @@ } #endif +static int arp_netdev_event(struct notifier_block *this, unsigned long event, void *ptr) +{ + struct net_device *dev = ptr; + + switch (event) { + case NETDEV_CHANGEADDR: + neigh_changeaddr(&arp_tbl, dev); + rt_cache_flush(0); + break; + default: + break; + } + + return NOTIFY_DONE; +} + +struct notifier_block arp_netdev_notifier = { + arp_netdev_event, + NULL, + 0 +}; + /* Note, that it is not on notifier chain. It is necessary, that this routine was called after route cache will be flushed. @@ -1243,6 +1265,7 @@ #ifdef CONFIG_SYSCTL neigh_sysctl_register(NULL, &arp_tbl.parms, NET_IPV4, NET_IPV4_NEIGH, "ipv4"); #endif + register_netdevice_notifier(&arp_netdev_notifier); } ===== net/ipv6/ndisc.c 1.22 vs edited ===== --- 1.22/net/ipv6/ndisc.c Tue Jun 24 02:21:28 2003 +++ edited/net/ipv6/ndisc.c Mon Aug 18 20:06:11 2003 @@ -1336,6 +1336,28 @@ return 0; } +static int ndisc_netdev_event(struct notifier_block *this, unsigned long event, void *ptr) +{ + struct net_device *dev = ptr; + + switch (event) { + case NETDEV_CHANGEADDR: + neigh_changeaddr(&nd_tbl, dev); + fib6_run_gc(0); + break; + default: + break; + } + + return NOTIFY_DONE; +} + +struct notifier_block ndisc_netdev_notifier = { + ndisc_netdev_event, + NULL, + 0 +}; + int __init ndisc_init(struct net_proto_family *ops) { struct sock *sk; @@ -1377,6 +1399,7 @@ neigh_sysctl_register(NULL, &nd_tbl.parms, NET_IPV6, NET_IPV6_NEIGH, "ipv6"); #endif + register_netdevice_notifier(&ndisc_netdev_notifier); return 0; } -- :(){ :|:&};: From shemminger@osdl.org Mon Aug 18 11:20:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 11:20:18 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IIKFFl023096 for ; Mon, 18 Aug 2003 11:20:15 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7IIJso18426; Mon, 18 Aug 2003 11:19:54 -0700 Date: Mon, 18 Aug 2003 11:19:42 -0700 From: Stephen Hemminger To: Jean Tourrilhes Cc: netdev@oss.sgi.com, irda-users@lists.sourceforge.net Subject: [PATCH] set owner field on /proc/net/irda sub entries Message-Id: <20030818111942.6060b450.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4984 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev common net/irda code in 2.6.0-test3 creates directory and sub entries, but forgets to set owner field on sub entries. diff -Nru a/net/irda/irproc.c b/net/irda/irproc.c --- a/net/irda/irproc.c Mon Aug 18 11:08:23 2003 +++ b/net/irda/irproc.c Mon Aug 18 11:08:23 2003 @@ -62,14 +62,18 @@ void __init irda_proc_register(void) { int i; + struct proc_dir_entry *d; proc_irda = proc_mkdir("net/irda", NULL); if (proc_irda == NULL) return; proc_irda->owner = THIS_MODULE; - for (i=0; iowner = THIS_MODULE; + } } /* From shemminger@osdl.org Mon Aug 18 11:18:32 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 11:18:36 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IIIUFl022964 for ; Mon, 18 Aug 2003 11:18:31 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7IIHvo17610; Mon, 18 Aug 2003 11:17:57 -0700 Date: Mon, 18 Aug 2003 11:17:46 -0700 From: Stephen Hemminger To: Jean Tourrilhes Cc: irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] ircomm - set owner get rid of MOD_INC/MOD_DEC Message-Id: <20030818111746.34b9e52b.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4983 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Ircomm in 2.6.0-test3 can just set the owner field in the tty structure like other drivers, and not mess with MOD_INC/MOD_DEC. diff -Nru a/net/irda/ircomm/ircomm_tty.c b/net/irda/ircomm/ircomm_tty.c --- a/net/irda/ircomm/ircomm_tty.c Mon Aug 18 11:07:15 2003 +++ b/net/irda/ircomm/ircomm_tty.c Mon Aug 18 11:07:15 2003 @@ -117,6 +117,7 @@ return -ENOMEM; } + driver->owner = THIS_MODULE; driver->driver_name = "ircomm"; driver->name = "ircomm"; driver->devfs_name = "ircomm"; @@ -363,10 +364,8 @@ IRDA_DEBUG(2, "%s()\n", __FUNCTION__ ); - MOD_INC_USE_COUNT; line = tty->index; if ((line < 0) || (line >= IRCOMM_TTY_PORTS)) { - MOD_DEC_USE_COUNT; return -ENODEV; } @@ -377,7 +376,6 @@ self = kmalloc(sizeof(struct ircomm_tty_cb), GFP_KERNEL); if (self == NULL) { ERROR("%s(), kmalloc failed!\n", __FUNCTION__); - MOD_DEC_USE_COUNT; return -ENOMEM; } memset(self, 0, sizeof(struct ircomm_tty_cb)); @@ -503,7 +501,6 @@ spin_lock_irqsave(&self->spinlock, flags); if (tty_hung_up_p(filp)) { - MOD_DEC_USE_COUNT; spin_unlock_irqrestore(&self->spinlock, flags); IRDA_DEBUG(0, "%s(), returning 1\n", __FUNCTION__ ); @@ -530,7 +527,6 @@ self->open_count = 0; } if (self->open_count) { - MOD_DEC_USE_COUNT; spin_unlock_irqrestore(&self->spinlock, flags); IRDA_DEBUG(0, "%s(), open count > 0\n", __FUNCTION__ ); @@ -572,8 +568,6 @@ self->flags &= ~(ASYNC_NORMAL_ACTIVE|ASYNC_CLOSING); wake_up_interruptible(&self->close_wait); - - MOD_DEC_USE_COUNT; } /* From shemminger@osdl.org Mon Aug 18 11:22:59 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 11:23:02 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IIMxFl023618 for ; Mon, 18 Aug 2003 11:22:59 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7IIMRo18870; Mon, 18 Aug 2003 11:22:27 -0700 Date: Mon, 18 Aug 2003 11:22:15 -0700 From: Stephen Hemminger To: Jean Tourrilhes Cc: irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] remove unused function prototype Message-Id: <20030818112215.312fb201.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4985 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Unused function prototype defined but never used on 2.6.0-test3 diff -Nru a/net/irda/irda_device.c b/net/irda/irda_device.c --- a/net/irda/irda_device.c Mon Aug 18 11:12:00 2003 +++ b/net/irda/irda_device.c Mon Aug 18 11:12:00 2003 @@ -83,12 +83,6 @@ static void irda_task_timer_expired(void *data); -#ifdef CONFIG_PROC_FS -int irda_device_proc_read(char *buf, char **start, off_t offset, int len, - int unused); - -#endif /* CONFIG_PROC_FS */ - int __init irda_device_init( void) { dongles = hashbin_new(HB_LOCK); From vandrove@vc.cvut.cz Mon Aug 18 11:27:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 11:27:35 -0700 (PDT) Received: from vana.vc.cvut.cz (root@vana.vc.cvut.cz [147.32.240.58]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IIRTFl023954 for ; Mon, 18 Aug 2003 11:27:30 -0700 Received: from vana.vc.cvut.cz (smmsp@localhost [127.0.0.1]) by vana.vc.cvut.cz (8.12.9/8.12.9/Debian-5) with ESMTP id h7IIRSXb003257; Mon, 18 Aug 2003 20:27:28 +0200 Received: (from root@localhost) by vana.vc.cvut.cz (8.12.9/8.12.9/Debian-5) id h7IIRR8h003255; Mon, 18 Aug 2003 20:27:27 +0200 Date: Mon, 18 Aug 2003 20:27:27 +0200 From: Petr Vandrovec To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: dev_add_pack and hardware checksumming Message-ID: <20030818182727.GD999@vana.vc.cvut.cz> References: <20030818033711.GA21360@vana.vc.cvut.cz> <20030817223851.5185bdee.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030817223851.5185bdee.davem@redhat.com> User-Agent: Mutt/1.5.4i X-archive-position: 4986 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vandrove@vc.cvut.cz Precedence: bulk X-list: netdev On Sun, Aug 17, 2003 at 10:38:51PM -0700, David S. Miller wrote: > On Mon, 18 Aug 2003 05:37:11 +0200 > Petr Vandrovec wrote: > > > For me it would be best if dev_queue_xmit_nit could just leave > > skb->h.raw alone, > > The AF_PACKET layer depends upon skb->h.raw being set a certain > way. Have a look at the dev_add_pack() registered hooks that > net/packet/af_packet.c uses. Well, I do not see skb->h.raw used in any way in AF_PACKET hooks... Probably I missed some deeply nested generic function which accesses it... > > Other choice is doing checksumming in dev_queue_xmit_nit itself, > > before passing skb down to the registered packet handlers. > > This is not an option either. We're specifically not going to > undo checksum offloading just because tcpdump or some other > kind of tap is installed. And what's left, then? I can happilly offload checksum to some other place down in the chain, but for doing that I must know where I should put checksum, and currently this information is unavailable to the packet hook. Best regards, Petr Vandrovec From shemminger@osdl.org Mon Aug 18 11:44:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 11:44:25 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IIiGFl024511 for ; Mon, 18 Aug 2003 11:44:16 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7IIdmo21804; Mon, 18 Aug 2003 11:39:48 -0700 Date: Mon, 18 Aug 2003 11:39:36 -0700 From: Stephen Hemminger To: Jean Tourrilhes , "David S. Miller" Cc: irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] (1/4) remove hashbin from irlan Message-Id: <20030818113936.205b5632.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4987 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev The locking in hashbin_delete is a problem since unregister_netdevice can't be called with locks held in 2.6.0-test3. Replace it with simpler list macros. Insertion/deletion protected with RTNL semaphore, and read uses RCU. Don't have client hardware to test, but load/unload works on SMP. diff -Nru a/include/net/irda/irlan_common.h b/include/net/irda/irlan_common.h --- a/include/net/irda/irlan_common.h Mon Aug 18 11:09:06 2003 +++ b/include/net/irda/irlan_common.h Mon Aug 18 11:09:06 2003 @@ -33,7 +33,6 @@ #include #include -#include #include #define IRLAN_MTU 1518 @@ -161,9 +160,8 @@ * IrLAN control block */ struct irlan_cb { - irda_queue_t q; /* Must be first */ - int magic; + struct list_head dev_list; struct net_device dev; /* Ethernet device structure*/ struct net_device_stats stats; @@ -204,6 +202,7 @@ int irlan_run_ctrl_tx_queue(struct irlan_cb *self); +struct irlan_cb *irlan_get_any(void); void irlan_get_provider_info(struct irlan_cb *self); void irlan_get_unicast_addr(struct irlan_cb *self); void irlan_get_media_char(struct irlan_cb *self); @@ -221,8 +220,6 @@ int irlan_extract_param(__u8 *buf, char *name, char *value, __u16 *len); void print_ret_code(__u8 code); - -extern hashbin_t *irlan; #endif diff -Nru a/net/irda/irlan/irlan_client.c b/net/irda/irlan/irlan_client.c --- a/net/irda/irlan/irlan_client.c Mon Aug 18 11:09:06 2003 +++ b/net/irda/irlan/irlan_client.c Mon Aug 18 11:09:06 2003 @@ -154,7 +154,6 @@ IRDA_DEBUG(1, "%s()\n", __FUNCTION__ ); - ASSERT(irlan != NULL, return;); ASSERT(discovery != NULL, return;); /* @@ -170,7 +169,8 @@ daddr = discovery->daddr; /* Find instance */ - self = (struct irlan_cb *) hashbin_get_first(irlan); + rcu_read_lock(); + self = irlan_get_any(); if (self) { ASSERT(self->magic == IRLAN_MAGIC, return;); @@ -179,6 +179,7 @@ irlan_client_wakeup(self, saddr, daddr); } + rcu_read_unlock(); } /* diff -Nru a/net/irda/irlan/irlan_common.c b/net/irda/irlan/irlan_common.c --- a/net/irda/irlan/irlan_common.c Mon Aug 18 11:09:06 2003 +++ b/net/irda/irlan/irlan_common.c Mon Aug 18 11:09:06 2003 @@ -33,6 +33,7 @@ #include #include #include +#include #include #include @@ -63,7 +64,8 @@ /* * Master structure */ -hashbin_t *irlan = NULL; +static LIST_HEAD(irlans); + static void *ckey; static void *skey; @@ -124,12 +126,6 @@ __u16 hints; IRDA_DEBUG(0, "%s()\n", __FUNCTION__ ); - /* Allocate master structure */ - irlan = hashbin_new(HB_LOCK); /* protect from /proc */ - if (irlan == NULL) { - printk(KERN_WARNING "IrLAN: Can't allocate hashbin!\n"); - return -ENOMEM; - } #ifdef CONFIG_PROC_FS create_proc_info_entry("irlan", 0, proc_irda, irlan_proc_read); #endif /* CONFIG_PROC_FS */ @@ -158,6 +154,8 @@ void __exit irlan_cleanup(void) { + struct irlan_cb *self, *next; + IRDA_DEBUG(4, "%s()\n", __FUNCTION__ ); irlmp_unregister_client(ckey); @@ -166,10 +164,13 @@ #ifdef CONFIG_PROC_FS remove_proc_entry("irlan", proc_irda); #endif /* CONFIG_PROC_FS */ - /* - * Delete hashbin and close all irlan client instances in it - */ - hashbin_delete(irlan, (FREE_FUNC) __irlan_close); + + /* Cleanup any leftover network devices */ + rtnl_lock(); + list_for_each_entry_safe(self, next, &irlans, dev_list) { + __irlan_close(self); + } + rtnl_unlock(); } /* @@ -210,7 +211,6 @@ struct irlan_cb *self; IRDA_DEBUG(2, "%s()\n", __FUNCTION__ ); - ASSERT(irlan != NULL, return NULL;); /* * Initialize the irlan structure. @@ -243,7 +243,7 @@ init_timer(&self->client.kick_timer); init_waitqueue_head(&self->open_wait); - hashbin_insert(irlan, (irda_queue_t *) self, daddr, NULL); + list_add_rcu(&self->dev_list, &irlans); skb_queue_head_init(&self->client.txq); @@ -258,8 +258,7 @@ * Function __irlan_close (self) * * This function closes and deallocates the IrLAN client instances. Be - * aware that other functions which calles client_close() must call - * hashbin_remove() first!!! + * aware that other functions which calles client_close() */ static void __irlan_close(struct irlan_cb *self) { @@ -267,6 +266,7 @@ IRDA_DEBUG(2, "%s()\n", __FUNCTION__ ); + ASSERT_RTNL(); ASSERT(self != NULL, return;); ASSERT(self->magic == IRLAN_MAGIC, return;); @@ -283,12 +283,23 @@ while ((skb = skb_dequeue(&self->client.txq))) dev_kfree_skb(skb); - unregister_netdev(&self->dev); + unregister_netdevice(&self->dev); self->magic = 0; kfree(self); } +/* Find any instance of irlan, used for client discovery wakeup */ +struct irlan_cb *irlan_get_any(void) +{ + struct irlan_cb *self; + + list_for_each_entry_rcu(self, &irlans, dev_list) { + return self; + } + return NULL; +} + /* * Function irlan_connect_indication (instance, sap, qos, max_sdu_size, skb) * @@ -1086,18 +1097,16 @@ */ static int irlan_proc_read(char *buf, char **start, off_t offset, int len) { - struct irlan_cb *self; - unsigned long flags; - ASSERT(irlan != NULL, return 0;); + struct irlan_cb *self; len = 0; - spin_lock_irqsave(&irlan->hb_spinlock, flags); + rcu_read_lock(); len += sprintf(buf+len, "IrLAN instances:\n"); - self = (struct irlan_cb *) hashbin_get_first(irlan); - while (self != NULL) { + list_for_each_entry_rcu(self, &irlans, dev_list) { + ASSERT(self->magic == IRLAN_MAGIC, break;); len += sprintf(buf+len, "ifname: %s,\n", @@ -1126,10 +1135,8 @@ netif_queue_stopped(&self->dev) ? "TRUE" : "FALSE"); len += sprintf(buf+len, "\n"); - - self = (struct irlan_cb *) hashbin_get_next(irlan); } - spin_unlock_irqrestore(&irlan->hb_spinlock, flags); + rcu_read_unlock(); return len; } From shemminger@osdl.org Mon Aug 18 11:53:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 11:53:44 -0700 (PDT) Received: from mail.osdl.org ([65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IIrdFl024917 for ; Mon, 18 Aug 2003 11:53:39 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7IIngo22814; Mon, 18 Aug 2003 11:49:42 -0700 Date: Mon, 18 Aug 2003 11:49:30 -0700 From: Stephen Hemminger To: Jean Tourrilhes , "David S. Miller" Cc: irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] (2/4) convert irlan to use alloc_netdev Message-Id: <20030818114930.4ca873cf.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4988 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev This patch to 2.6.0-test3 converts irlan to use alloc_netdev. Setup auto free via destructor. diff -Nru a/include/net/irda/irlan_common.h b/include/net/irda/irlan_common.h --- a/include/net/irda/irlan_common.h Mon Aug 18 11:09:33 2003 +++ b/include/net/irda/irlan_common.h Mon Aug 18 11:09:33 2003 @@ -162,7 +162,7 @@ struct irlan_cb { int magic; struct list_head dev_list; - struct net_device dev; /* Ethernet device structure*/ + struct net_device *dev; /* Ethernet device structure*/ struct net_device_stats stats; __u32 saddr; /* Source device address */ diff -Nru a/include/net/irda/irlan_eth.h b/include/net/irda/irlan_eth.h --- a/include/net/irda/irlan_eth.h Mon Aug 18 11:09:33 2003 +++ b/include/net/irda/irlan_eth.h Mon Aug 18 11:09:33 2003 @@ -25,7 +25,7 @@ #ifndef IRLAN_ETH_H #define IRLAN_ETH_H -int irlan_eth_init(struct net_device *dev); +void irlan_eth_setup(struct net_device *dev); int irlan_eth_open(struct net_device *dev); int irlan_eth_close(struct net_device *dev); int irlan_eth_receive(void *instance, void *sap, struct sk_buff *skb); diff -Nru a/net/irda/irlan/irlan_client.c b/net/irda/irlan/irlan_client.c --- a/net/irda/irlan/irlan_client.c Mon Aug 18 11:09:33 2003 +++ b/net/irda/irlan/irlan_client.c Mon Aug 18 11:09:33 2003 @@ -512,7 +512,7 @@ bytes[0], bytes[1], bytes[2], bytes[3], bytes[4], bytes[5]); for (i = 0; i < 6; i++) - self->dev.dev_addr[i] = bytes[i]; + self->dev->dev_addr[i] = bytes[i]; } } diff -Nru a/net/irda/irlan/irlan_common.c b/net/irda/irlan/irlan_common.c --- a/net/irda/irlan/irlan_common.c Mon Aug 18 11:09:33 2003 +++ b/net/irda/irlan/irlan_common.c Mon Aug 18 11:09:33 2003 @@ -174,33 +174,6 @@ } /* - * Function irlan_register_netdev (self) - * - * Registers the network device to be used. We should don't register until - * we have been binded to a particular provider or client. - */ -int irlan_register_netdev(struct irlan_cb *self) -{ - int i=0; - - IRDA_DEBUG(0, "%s()\n", __FUNCTION__ ); - - /* Check if we should call the device eth or irlan */ - if (!eth) { - /* Get the first free irlan name */ - do { - sprintf(self->dev.name, "%s%d", "irlan", i++); - } while (dev_get(self->dev.name)); - } - - if (register_netdev(&self->dev) != 0) { - IRDA_DEBUG(2, "%s(), register_netdev() failed!\n", __FUNCTION__ ); - return -1; - } - return 0; -} - -/* * Function irlan_open (void) * * Open new instance of a client/provider, we should only register the @@ -208,30 +181,25 @@ */ struct irlan_cb *irlan_open(__u32 saddr, __u32 daddr) { + struct net_device *dev; struct irlan_cb *self; IRDA_DEBUG(2, "%s()\n", __FUNCTION__ ); - /* - * Initialize the irlan structure. - */ - self = kmalloc(sizeof(struct irlan_cb), GFP_ATOMIC); - if (self == NULL) + /* Create network device with irlan */ + dev = alloc_netdev(sizeof(*self), + eth ? "eth%d" : "irlan%d", + irlan_eth_setup); + if (!dev) return NULL; - - memset(self, 0, sizeof(struct irlan_cb)); + + self = dev->priv; + self->dev = dev; /* * Initialize local device structure */ self->magic = IRLAN_MAGIC; - - sprintf(self->dev.name, "%s", "unknown"); - - self->dev.priv = (void *) self; - self->dev.next = NULL; - self->dev.init = irlan_eth_init; - self->saddr = saddr; self->daddr = daddr; @@ -242,15 +210,22 @@ init_timer(&self->watchdog_timer); init_timer(&self->client.kick_timer); init_waitqueue_head(&self->open_wait); - - list_add_rcu(&self->dev_list, &irlans); skb_queue_head_init(&self->client.txq); irlan_next_client_state(self, IRLAN_IDLE); irlan_next_provider_state(self, IRLAN_IDLE); - irlan_register_netdev(self); + if (register_netdev(dev)) { + IRDA_DEBUG(2, "%s(), register_netdev() failed!\n", + __FUNCTION__ ); + self = NULL; + kfree(dev); + } else { + rtnl_lock(); + list_add_rcu(&self->dev_list, &irlans); + rtnl_unlock(); + } return self; } @@ -258,7 +233,8 @@ * Function __irlan_close (self) * * This function closes and deallocates the IrLAN client instances. Be - * aware that other functions which calles client_close() + * aware that other functions which calls client_close() must + * remove self from irlans list first. */ static void __irlan_close(struct irlan_cb *self) { @@ -283,10 +259,8 @@ while ((skb = skb_dequeue(&self->client.txq))) dev_kfree_skb(skb); - unregister_netdevice(&self->dev); - - self->magic = 0; - kfree(self); + /* Unregister and free self via destructor */ + unregister_netdevice(self->dev); } /* Find any instance of irlan, used for client discovery wakeup */ @@ -348,7 +322,7 @@ irlan_open_unicast_addr(self); } /* Ready to transfer Ethernet frames (at last) */ - netif_start_queue(&self->dev); /* Clear reason */ + netif_start_queue(self->dev); /* Clear reason */ } void irlan_connect_confirm(void *instance, void *sap, struct qos_info *qos, @@ -382,7 +356,7 @@ irlan_set_multicast_filter(self, TRUE); /* Ready to transfer Ethernet frames */ - netif_start_queue(&self->dev); + netif_start_queue(self->dev); self->disconnect_reason = 0; /* Clear reason */ #ifdef CONFIG_IRLAN_SEND_GRATUITOUS_ARP irlan_eth_send_gratuitous_arp(&self->dev); @@ -1110,7 +1084,7 @@ ASSERT(self->magic == IRLAN_MAGIC, break;); len += sprintf(buf+len, "ifname: %s,\n", - self->dev.name); + self->dev->name); len += sprintf(buf+len, "client state: %s, ", irlan_state[ self->client.state]); len += sprintf(buf+len, "provider state: %s,\n", @@ -1132,7 +1106,7 @@ buf+len); len += sprintf(buf+len, "tx busy: %s\n", - netif_queue_stopped(&self->dev) ? "TRUE" : "FALSE"); + netif_queue_stopped(self->dev) ? "TRUE" : "FALSE"); len += sprintf(buf+len, "\n"); } diff -Nru a/net/irda/irlan/irlan_eth.c b/net/irda/irlan/irlan_eth.c --- a/net/irda/irlan/irlan_eth.c Mon Aug 18 11:09:33 2003 +++ b/net/irda/irlan/irlan_eth.c Mon Aug 18 11:09:33 2003 @@ -47,14 +47,12 @@ * The network device initialization function. * */ -int irlan_eth_init(struct net_device *dev) +void irlan_eth_setup(struct net_device *dev) { struct irlan_cb *self; IRDA_DEBUG(2, "%s()\n", __FUNCTION__ ); - ASSERT(dev != NULL, return -1;); - self = (struct irlan_cb *) dev->priv; dev->open = irlan_eth_open; @@ -62,6 +60,8 @@ dev->hard_start_xmit = irlan_eth_xmit; dev->get_stats = irlan_eth_get_stats; dev->set_multicast_list = irlan_eth_set_multicast_list; + dev->destructor = (void (*)(struct net_device *)) kfree; + SET_MODULE_OWNER(dev); ether_setup(dev); @@ -85,8 +85,6 @@ get_random_bytes(dev->dev_addr+4, 1); get_random_bytes(dev->dev_addr+5, 1); } - - return 0; } /* @@ -237,7 +235,7 @@ * might have been previously set by the low level IrDA network * device driver */ - skb->dev = &self->dev; + skb->dev = self->dev; skb->protocol=eth_type_trans(skb, skb->dev); /* Remove eth header */ self->stats.rx_packets++; @@ -264,7 +262,7 @@ ASSERT(self != NULL, return;); ASSERT(self->magic == IRLAN_MAGIC, return;); - dev = &self->dev; + dev = self->dev; ASSERT(dev != NULL, return;); From jt@bougret.hpl.hp.com Mon Aug 18 12:00:51 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 12:00:58 -0700 (PDT) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IJ0pFl025346 for ; Mon, 18 Aug 2003 12:00:51 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel13.hp.com (Postfix) with ESMTP id BB1291C021A5; Mon, 18 Aug 2003 12:00:50 -0700 (PDT) Received: from bougret.hpl.hp.com (mail@bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_26305)/8.9.3 HPLabs Timeshare Server) with ESMTP id MAA18026; Mon, 18 Aug 2003 12:00:47 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 19opFH-0001iL-00; Mon, 18 Aug 2003 12:00:47 -0700 Date: Mon, 18 Aug 2003 12:00:46 -0700 To: Stephen Hemminger Cc: "David S. Miller" , irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] (1/4) remove hashbin from irlan Message-ID: <20030818190046.GA6577@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20030818113936.205b5632.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030818113936.205b5632.shemminger@osdl.org> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 4989 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev On Mon, Aug 18, 2003 at 11:39:36AM -0700, Stephen Hemminger wrote: > The locking in hashbin_delete is a problem since unregister_netdevice > can't be called with locks held in 2.6.0-test3. > > Replace it with simpler list macros. > Insertion/deletion protected with RTNL semaphore, and read > uses RCU. > > Don't have client hardware to test, but load/unload works on SMP. Why don't you try the much simpler version : ---------------------------------------------- --- irlan_common.h1.c Mon Aug 18 11:57:39 2003 +++ irlan_common.c Mon Aug 18 11:58:25 2003 @@ -125,7 +125,7 @@ int __init irlan_init(void) IRDA_DEBUG(0, "%s()\n", __FUNCTION__ ); /* Allocate master structure */ - irlan = hashbin_new(HB_LOCK); /* protect from /proc */ + irlan = hashbin_new(HB_NOLOCK); /* network layer will protect us */ if (irlan == NULL) { printk(KERN_WARNING "IrLAN: Can't allocate hashbin!\n"); return -ENOMEM; ---------------------------------------------- We would still need the RCU, but the overall patch would be much simpler and safer IMHO. But it's up to you ;-) Have fun... Jean From davem@redhat.com Mon Aug 18 12:02:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 12:02:49 -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 h7IJ2kFl025680 for ; Mon, 18 Aug 2003 12:02:46 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id LAA06920; Mon, 18 Aug 2003 11:53:33 -0700 Date: Mon, 18 Aug 2003 11:53:33 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: jt@bougret.hpl.hp.com, irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] (2/4) convert irlan to use alloc_netdev Message-Id: <20030818115333.35fe5f6d.davem@redhat.com> In-Reply-To: <20030818114930.4ca873cf.shemminger@osdl.org> References: <20030818114930.4ca873cf.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4990 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 Jean, I'd like to merge Stephen's work as I review it unless you have some hard reason why I shouldn't. From shemminger@osdl.org Mon Aug 18 12:25:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 12:25:37 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IJPTFl026584 for ; Mon, 18 Aug 2003 12:25:32 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7IJOoo00603; Mon, 18 Aug 2003 12:24:50 -0700 Date: Mon, 18 Aug 2003 12:24:38 -0700 From: Stephen Hemminger To: Jean Tourrilhes , "David S. Miller" Cc: irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] (3/4) remove duplicate of irlan_state Message-Id: <20030818122438.66cb8d81.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4991 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Remove duplicate string definition. Same table already defined and exported in irlan_event.c diff -Nru a/net/irda/irlan/irlan_common.c b/net/irda/irlan/irlan_common.c --- a/net/irda/irlan/irlan_common.c Mon Aug 18 11:09:50 2003 +++ b/net/irda/irlan/irlan_common.c Mon Aug 18 11:09:50 2003 @@ -74,20 +74,6 @@ static int access = ACCESS_PEER; /* PEER, DIRECT or HOSTED */ #ifdef CONFIG_PROC_FS -static char *irlan_state[] = { - "IRLAN_IDLE", - "IRLAN_QUERY", - "IRLAN_CONN", - "IRLAN_INFO", - "IRLAN_MEDIA", - "IRLAN_OPEN", - "IRLAN_WAIT", - "IRLAN_ARB", - "IRLAN_DATA", - "IRLAN_CLOSE", - "IRLAN_SYNC" -}; - static char *irlan_access[] = { "UNKNOWN", "DIRECT", From shemminger@osdl.org Mon Aug 18 12:27:52 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 12:27:56 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IJRpFl026961 for ; Mon, 18 Aug 2003 12:27:52 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7IJRDo01291; Mon, 18 Aug 2003 12:27:13 -0700 Date: Mon, 18 Aug 2003 12:27:02 -0700 From: Stephen Hemminger To: Jean Tourrilhes , "David S. Miller" Cc: irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] (4/4) convert irlan to seq_file interface Message-Id: <20030818122702.67e9162d.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4992 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Convert irlan /proc interface to safer seq_file library. diff -Nru a/include/net/irda/irlan_filter.h b/include/net/irda/irlan_filter.h --- a/include/net/irda/irlan_filter.h Mon Aug 18 11:11:02 2003 +++ b/include/net/irda/irlan_filter.h Mon Aug 18 11:11:02 2003 @@ -28,6 +28,6 @@ void irlan_check_command_param(struct irlan_cb *self, char *param, char *value); void handle_filter_request(struct irlan_cb *self, struct sk_buff *skb); -int irlan_print_filter(int filter_type, char *buf); +int irlan_print_filter(struct seq_file *seq, int filter_type); #endif /* IRLAN_FILTER_H */ diff -Nru a/net/irda/irlan/irlan_common.c b/net/irda/irlan/irlan_common.c --- a/net/irda/irlan/irlan_common.c Mon Aug 18 11:11:02 2003 +++ b/net/irda/irlan/irlan_common.c Mon Aug 18 11:11:02 2003 @@ -31,6 +31,7 @@ #include #include #include +#include #include #include #include @@ -86,6 +87,20 @@ "802.3", "802.5" }; + +extern struct proc_dir_entry *proc_irda; + +static int irlan_seq_open(struct inode *inode, struct file *file); + +static struct file_operations irlan_fops = { + .owner = THIS_MODULE, + .open = irlan_seq_open, + .read = seq_read, + .llseek = seq_lseek, + .release = seq_release, +}; + +extern struct proc_dir_entry *proc_irda; #endif /* CONFIG_PROC_FS */ static void __irlan_close(struct irlan_cb *self); @@ -94,12 +109,6 @@ __u8 *value_array, __u16 value_len); void irlan_close_tsaps(struct irlan_cb *self); -#ifdef CONFIG_PROC_FS -static int irlan_proc_read(char *buf, char **start, off_t offset, int len); - -extern struct proc_dir_entry *proc_irda; -#endif /* CONFIG_PROC_FS */ - /* * Function irlan_init (void) * @@ -112,8 +121,17 @@ __u16 hints; IRDA_DEBUG(0, "%s()\n", __FUNCTION__ ); + #ifdef CONFIG_PROC_FS - create_proc_info_entry("irlan", 0, proc_irda, irlan_proc_read); + { struct proc_dir_entry *proc; + proc = create_proc_entry("irlan", 0, proc_irda); + if (!proc) { + printk(KERN_ERR "irlan_init: can't create /proc entry!\n"); + return -ENODEV; + } + + proc->proc_fops = &irlan_fops; + } #endif /* CONFIG_PROC_FS */ IRDA_DEBUG(4, "%s()\n", __FUNCTION__ ); @@ -1050,55 +1068,104 @@ } #ifdef CONFIG_PROC_FS +#define IRLAN_PROC_START_TOKEN ((void *)1) + /* - * Function irlan_client_proc_read (buf, start, offset, len, unused) - * - * Give some info to the /proc file system + * Start of reading /proc entries. + * Return entry at pos, + * or start_token to indicate print header line + * or NULL if end of file */ -static int irlan_proc_read(char *buf, char **start, off_t offset, int len) +static void *irlan_seq_start(struct seq_file *seq, loff_t *pos) { + int i = 1; struct irlan_cb *self; - - len = 0; - + rcu_read_lock(); + if (*pos == 0) + return IRLAN_PROC_START_TOKEN; + + list_for_each_entry(self, &irlans, dev_list) { + if (*pos == i) + return self; + ++i; + } + return NULL; +} + +/* Return entry after v, and increment pos */ +static void *irlan_seq_next(struct seq_file *seq, void *v, loff_t *pos) +{ + struct list_head *nxt; + + ++*pos; + if (v == IRLAN_PROC_START_TOKEN) + nxt = irlans.next; + else + nxt = ((struct irlan_cb *)v)->dev_list.next; + + return (nxt == &irlans) ? NULL + : list_entry(nxt, struct irlan_cb, dev_list); +} + +/* End of reading /proc file */ +static void irlan_seq_stop(struct seq_file *seq, void *v) +{ + rcu_read_unlock(); +} - len += sprintf(buf+len, "IrLAN instances:\n"); - - list_for_each_entry_rcu(self, &irlans, dev_list) { - ASSERT(self->magic == IRLAN_MAGIC, break;); +/* + * Show one entry in /proc file. + */ +static int irlan_seq_show(struct seq_file *seq, void *v) +{ + if (v == IRLAN_PROC_START_TOKEN) + seq_puts(seq, "IrLAN instances:\n"); + else { + struct irlan_cb *self = v; - len += sprintf(buf+len, "ifname: %s,\n", + ASSERT(self != NULL, return -1;); + ASSERT(self->magic == IRLAN_MAGIC, return -1;); + + seq_printf(seq,"ifname: %s,\n", self->dev->name); - len += sprintf(buf+len, "client state: %s, ", + seq_printf(seq,"client state: %s, ", irlan_state[ self->client.state]); - len += sprintf(buf+len, "provider state: %s,\n", + seq_printf(seq,"provider state: %s,\n", irlan_state[ self->provider.state]); - len += sprintf(buf+len, "saddr: %#08x, ", + seq_printf(seq,"saddr: %#08x, ", self->saddr); - len += sprintf(buf+len, "daddr: %#08x\n", + seq_printf(seq,"daddr: %#08x\n", self->daddr); - len += sprintf(buf+len, "version: %d.%d,\n", + seq_printf(seq,"version: %d.%d,\n", self->version[1], self->version[0]); - len += sprintf(buf+len, "access type: %s\n", + seq_printf(seq,"access type: %s\n", irlan_access[self->client.access_type]); - len += sprintf(buf+len, "media: %s\n", + seq_printf(seq,"media: %s\n", irlan_media[self->media]); - len += sprintf(buf+len, "local filter:\n"); - len += sprintf(buf+len, "remote filter: "); - len += irlan_print_filter(self->client.filter_type, - buf+len); - - len += sprintf(buf+len, "tx busy: %s\n", + seq_printf(seq,"local filter:\n"); + seq_printf(seq,"remote filter: "); + irlan_print_filter(seq, self->client.filter_type); + seq_printf(seq,"tx busy: %s\n", netif_queue_stopped(self->dev) ? "TRUE" : "FALSE"); - len += sprintf(buf+len, "\n"); - } - rcu_read_unlock(); + seq_putc(seq,'\n'); + } + return 0; +} - return len; +static struct seq_operations irlan_seq_ops = { + .start = irlan_seq_start, + .next = irlan_seq_next, + .stop = irlan_seq_stop, + .show = irlan_seq_show, +}; + +static int irlan_seq_open(struct inode *inode, struct file *file) +{ + return seq_open(file, &irlan_seq_ops); } #endif diff -Nru a/net/irda/irlan/irlan_filter.c b/net/irda/irlan/irlan_filter.c --- a/net/irda/irlan/irlan_filter.c Mon Aug 18 11:11:02 2003 +++ b/net/irda/irlan/irlan_filter.c Mon Aug 18 11:11:02 2003 @@ -24,6 +24,7 @@ #include #include +#include #include @@ -216,26 +217,24 @@ * Print status of filter. Used by /proc file system * */ -int irlan_print_filter(int filter_type, char *buf) +#ifdef CONFIG_PROC_FS +void irlan_print_filter(struct seq_file *seq, int filter_type) { - int len = 0; - if (filter_type & IRLAN_DIRECTED) - len += sprintf(buf+len, "%s", "DIRECTED "); + seq_printf(seq, "%s", "DIRECTED "); if (filter_type & IRLAN_FUNCTIONAL) - len += sprintf(buf+len, "%s", "FUNCTIONAL "); + seq_printf(seq, "%s", "FUNCTIONAL "); if (filter_type & IRLAN_GROUP) - len += sprintf(buf+len, "%s", "GROUP "); + seq_printf(seq, "%s", "GROUP "); if (filter_type & IRLAN_MAC_FRAME) - len += sprintf(buf+len, "%s", "MAC_FRAME "); + seq_printf(seq, "%s", "MAC_FRAME "); if (filter_type & IRLAN_MULTICAST) - len += sprintf(buf+len, "%s", "MULTICAST "); + seq_printf(seq, "%s", "MULTICAST "); if (filter_type & IRLAN_BROADCAST) - len += sprintf(buf+len, "%s", "BROADCAST "); + seq_printf(seq, "%s", "BROADCAST "); if (filter_type & IRLAN_IPX_SOCKET) - len += sprintf(buf+len, "%s", "IPX_SOCKET"); - - len += sprintf(buf+len, "\n"); + seq_printf(seq, "%s", "IPX_SOCKET"); - return len; + seq_putc(seq, '\n'); } +#endif From shemminger@osdl.org Mon Aug 18 12:32:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 12:32:39 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IJWWFl027300 for ; Mon, 18 Aug 2003 12:32:33 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7IJVro03174; Mon, 18 Aug 2003 12:31:53 -0700 Date: Mon, 18 Aug 2003 12:31:42 -0700 From: Stephen Hemminger To: Jean Tourrilhes , "David S. Miller" Cc: irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] convert ircomm to seq_file interface Message-Id: <20030818123142.6369fbff.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4993 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Convert ircomm /proc interface to seq_file. Note: don't need spin_lock_irq because list is not ever locked from inside interrupt context. Last IRDA patch for today ;-) diff -Nru a/net/irda/ircomm/ircomm_core.c b/net/irda/ircomm/ircomm_core.c --- a/net/irda/ircomm/ircomm_core.c Mon Aug 18 12:30:42 2003 +++ b/net/irda/ircomm/ircomm_core.c Mon Aug 18 12:30:42 2003 @@ -33,6 +33,7 @@ #include #include #include +#include #include #include @@ -53,7 +54,15 @@ struct sk_buff *skb, int clen); #ifdef CONFIG_PROC_FS -static int ircomm_proc_read(char *buf, char **start, off_t offset, int len); +static int ircomm_seq_open(struct inode *inode, struct file *file); + +static struct file_operations ircomm_fops = { + .owner = THIS_MODULE, + .open = ircomm_seq_open, + .read = seq_read, + .llseek = seq_lseek, + .release = seq_release, +}; extern struct proc_dir_entry *proc_irda; #endif /* CONFIG_PROC_FS */ @@ -69,7 +78,15 @@ } #ifdef CONFIG_PROC_FS - create_proc_info_entry("ircomm", 0, proc_irda, ircomm_proc_read); + { struct proc_dir_entry *proc; + proc = create_proc_entry("ircomm", 0, proc_irda); + if (!proc) { + printk(KERN_ERR "ircomm_init: can't create /proc entry!\n"); + return -ENODEV; + } + + proc->proc_fops = &ircomm_fops; + } #endif /* CONFIG_PROC_FS */ MESSAGE("IrCOMM protocol (Dag Brattli)\n"); @@ -497,49 +514,80 @@ #ifdef CONFIG_PROC_FS /* - * Function ircomm_proc_read (buf, start, offset, len, unused) - * - * - * + * Start of reading /proc entries. + * Return entry at pos, or NULL if end of file */ -int ircomm_proc_read(char *buf, char **start, off_t offset, int len) -{ +static void *ircomm_seq_start(struct seq_file *seq, loff_t *pos) +{ + int i = 0; struct ircomm_cb *self; - unsigned long flags; - - len = 0; - spin_lock_irqsave(&ircomm->hb_spinlock, flags); + spin_lock(&ircomm->hb_spinlock); + for (self = (struct ircomm_cb *) hashbin_get_first(ircomm); + self != NULL; + self = (struct ircomm_cb *) hashbin_get_next(ircomm)) { + if (*pos == i) + return self; + ++i; + } + return NULL; +} - self = (struct ircomm_cb *) hashbin_get_first(ircomm); - while (self != NULL) { - ASSERT(self->magic == IRCOMM_MAGIC, break;); - - if(self->line < 0x10) - len += sprintf(buf+len, "ircomm%d", self->line); - else - len += sprintf(buf+len, "irlpt%d", self->line - 0x10); - len += sprintf(buf+len, " state: %s, ", - ircomm_state[ self->state]); - len += sprintf(buf+len, - "slsap_sel: %#02x, dlsap_sel: %#02x, mode:", - self->slsap_sel, self->dlsap_sel); - if(self->service_type & IRCOMM_3_WIRE_RAW) - len += sprintf(buf+len, " 3-wire-raw"); - if(self->service_type & IRCOMM_3_WIRE) - len += sprintf(buf+len, " 3-wire"); - if(self->service_type & IRCOMM_9_WIRE) - len += sprintf(buf+len, " 9-wire"); - if(self->service_type & IRCOMM_CENTRONICS) - len += sprintf(buf+len, " Centronics"); - len += sprintf(buf+len, "\n"); - - self = (struct ircomm_cb *) hashbin_get_next(ircomm); - } - spin_unlock_irqrestore(&ircomm->hb_spinlock, flags); +/* Return entry after v, and increment pos */ +static void *ircomm_seq_next(struct seq_file *seq, void *v, loff_t *pos) +{ + ++*pos; + return hashbin_get_next(ircomm); +} - return len; +/* End of reading /proc file */ +static void ircomm_seq_stop(struct seq_file *seq, void *v) +{ + spin_unlock(&ircomm->hb_spinlock); } + + +/* + * Show one entry in /proc file. + */ +static int ircomm_seq_show(struct seq_file *seq, void *v) +{ + const struct ircomm_cb *self = v; + + if(self->line < 0x10) + seq_printf(seq, "ircomm%d", self->line); + else + seq_printf(seq, "irlpt%d", self->line - 0x10); + seq_printf(seq, " state: %s, ", ircomm_state[self->state]); + seq_printf(seq, "slsap_sel: %#02x, dlsap_sel: %#02x, mode:", + self->slsap_sel, self->dlsap_sel); + + if(self->service_type & IRCOMM_3_WIRE_RAW) + seq_puts(seq, " 3-wire-raw"); + if(self->service_type & IRCOMM_3_WIRE) + seq_puts(seq, " 3-wire"); + if(self->service_type & IRCOMM_9_WIRE) + seq_puts(seq, " 9-wire"); + if(self->service_type & IRCOMM_CENTRONICS) + seq_puts(seq, " Centronics"); + seq_putc(seq, '\n'); + + + return 0; +} + +static struct seq_operations ircomm_seq_ops = { + .start = ircomm_seq_start, + .next = ircomm_seq_next, + .stop = ircomm_seq_stop, + .show = ircomm_seq_show, +}; + +static int ircomm_seq_open(struct inode *inode, struct file *file) +{ + return seq_open(file, &ircomm_seq_ops); +} + #endif /* CONFIG_PROC_FS */ MODULE_AUTHOR("Dag Brattli "); From shemminger@osdl.org Mon Aug 18 12:35:12 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 12:35:18 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IJZBFl027624 for ; Mon, 18 Aug 2003 12:35:12 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7IJYXo04198; Mon, 18 Aug 2003 12:34:33 -0700 Date: Mon, 18 Aug 2003 12:34:21 -0700 From: Stephen Hemminger To: jt@hpl.hp.com Cc: jt@bougret.hpl.hp.com, "David S. Miller" , irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] (1/4) remove hashbin from irlan Message-Id: <20030818123421.64ee3ff2.shemminger@osdl.org> In-Reply-To: <20030818190046.GA6577@bougret.hpl.hp.com> References: <20030818113936.205b5632.shemminger@osdl.org> <20030818190046.GA6577@bougret.hpl.hp.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4994 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 12:00:46 -0700 Jean Tourrilhes wrote: > On Mon, Aug 18, 2003 at 11:39:36AM -0700, Stephen Hemminger wrote: > > The locking in hashbin_delete is a problem since unregister_netdevice > > can't be called with locks held in 2.6.0-test3. > > > > Replace it with simpler list macros. > > Insertion/deletion protected with RTNL semaphore, and read > > uses RCU. > > > > Don't have client hardware to test, but load/unload works on SMP. > > Why don't you try the much simpler version : > ---------------------------------------------- > --- irlan_common.h1.c Mon Aug 18 11:57:39 2003 > +++ irlan_common.c Mon Aug 18 11:58:25 2003 > @@ -125,7 +125,7 @@ int __init irlan_init(void) > > IRDA_DEBUG(0, "%s()\n", __FUNCTION__ ); > /* Allocate master structure */ > - irlan = hashbin_new(HB_LOCK); /* protect from /proc */ > + irlan = hashbin_new(HB_NOLOCK); /* network layer will protect us */ > if (irlan == NULL) { > printk(KERN_WARNING "IrLAN: Can't allocate hashbin!\n"); > return -ENOMEM; > ---------------------------------------------- > We would still need the RCU, but the overall patch would be > much simpler and safer IMHO. But it's up to you ;-) > > Have fun... > > Jean It really is a personal choice; there is no "right and wrong", but I felt more secure using the same locking and list model as other network drivers. You probably feel more secure using the hashbin stuff that the rest of the IRDA stack does. Also, RCU is well tested and if something comes up, it would get fixed in list.h. I wouldn't trust hashbin's with RCU without explicit testing and review by Paul or Dipankar. From jt@bougret.hpl.hp.com Mon Aug 18 13:28:47 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 13:28:53 -0700 (PDT) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IKSbFl030714 for ; Mon, 18 Aug 2003 13:28:37 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel11.hp.com (Postfix) with ESMTP id D353D1C02FCB; Mon, 18 Aug 2003 12:58:36 -0700 (PDT) Received: from bougret.hpl.hp.com (mail@bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_26305)/8.9.3 HPLabs Timeshare Server) with ESMTP id MAA20587; Mon, 18 Aug 2003 12:58:36 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 19oq9E-0001lz-00; Mon, 18 Aug 2003 12:58:36 -0700 Date: Mon, 18 Aug 2003 12:58:36 -0700 To: "David S. Miller" Cc: Stephen Hemminger , irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] (2/4) convert irlan to use alloc_netdev Message-ID: <20030818195836.GB6577@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20030818114930.4ca873cf.shemminger@osdl.org> <20030818115333.35fe5f6d.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030818115333.35fe5f6d.davem@redhat.com> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 4995 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev On Mon, Aug 18, 2003 at 11:53:33AM -0700, David S. Miller wrote: > > Jean, I'd like to merge Stephen's work as I review > it unless you have some hard reason why I shouldn't. Well, I already told you that I don't maintain IrLAN, so you are free to do as you wish with IrLAN. It's up to Stephen to see if he likes my suggestion or not. By the way, that's why I try to read Stephen patches as fast as they come, even though I've got a pile of other work to do. Thanks... Jean From jt@bougret.hpl.hp.com Mon Aug 18 14:02:06 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 14:02:14 -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 h7IL1tFl031356 for ; Mon, 18 Aug 2003 14:01:56 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel12.hp.com (Postfix) with ESMTP id CC9CD1C04690; Mon, 18 Aug 2003 13:09:27 -0700 (PDT) Received: from bougret.hpl.hp.com (mail@bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_26305)/8.9.3 HPLabs Timeshare Server) with ESMTP id NAA20992; Mon, 18 Aug 2003 13:09:23 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 19oqJf-0001mU-00; Mon, 18 Aug 2003 13:09:23 -0700 Date: Mon, 18 Aug 2003 13:09:23 -0700 To: Stephen Hemminger Cc: "David S. Miller" , irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] convert ircomm to seq_file interface Message-ID: <20030818200923.GC6577@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20030818123142.6369fbff.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030818123142.6369fbff.shemminger@osdl.org> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 4996 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev On Mon, Aug 18, 2003 at 12:31:42PM -0700, Stephen Hemminger wrote: > Convert ircomm /proc interface to seq_file. > > Note: don't need spin_lock_irq because list is not ever locked > from inside interrupt context. I don't agree with this change. If you look in ircomm_lmp.c ; ircomm_lmp_flow_control(), you will see that the hashbin is accessed from BH context. So, at minimum it should be a spin_lock_bh(). Currently, all the IrDA stack uses spin_lock_irqsave(), where is fact a only spin_lock_bh() is needed. But, this is something that I kept for 2.7.X, because I would rather make sure previous locking changes are safe, before going to the next step. So, for consistency with the rest of the IrDA stack and the code in hashbin, I would keep the spin_lock_irqsave(). What do you think ? On the other hand, the conversion to seq_file is badly needed, because the current /proc code was known to be very buggy. Thanks for doing that. Have fun... Jean From bellucda@tiscali.it Mon Aug 18 14:26:20 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 14:26:24 -0700 (PDT) Received: from mail-6.tiscali.it (mail-6.tiscali.it [195.130.225.152]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7ILQIFl031943 for ; Mon, 18 Aug 2003 14:26:19 -0700 Received: from localhost.localdomain (217.133.211.27) by mail-6.tiscali.it (6.7.019) id 3F3102320049F998; Mon, 18 Aug 2003 23:26:12 +0200 Content-Type: text/plain; charset="us-ascii" From: Daniele Bellucci Reply-To: bellucda@tiscali.it To: netdev@oss.sgi.com Subject: [PATCH] make pktgen depends on procfs [2.6.0-test3] Date: Mon, 18 Aug 2003 23:26:10 +0200 User-Agent: KMail/1.4.3 Cc: davem@redhat.com MIME-Version: 1.0 Message-Id: <200308182326.10798.bellucda@tiscali.it> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7ILQIFl031943 X-archive-position: 4997 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bellucda@tiscali.it Precedence: bulk X-list: netdev IMHO pktgen should depends on proc fs to avoid the following compilation error: net/core/pktgen.c: In function `create_proc_dir': net/core/pktgen.c:1296: `proc_net' undeclared (first use in this function) net/core/pktgen.c:1296: (Each undeclared identifier is reported only once net/core/pktgen.c:1296: for each function it appears in.) make[2]: *** [net/core/pktgen.o] Error 1 make[1]: *** [net/core] Error 2 make: *** [net] Error 2 diff -urN 1.0/net/Kconfig 1.1/net/Kconfig --- 1.0/net/Kconfig 2003-08-18 23:25:02.000000000 +0200 +++ 1.1/net/Kconfig 2003-08-18 23:25:13.000000000 +0200 @@ -661,6 +661,7 @@ config NET_PKTGEN tristate "Packet Generator (USE WITH CAUTION)" + depends on CONFIG_PROC_FS ---help--- This module will inject preconfigured packets, at a configurable rate, out of a given interface. It is used for network interface -- Daniele. From romieu@fr.zoreil.com Mon Aug 18 14:30:52 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 14:30:57 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7ILUlFl032307 for ; Mon, 18 Aug 2003 14:30:51 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id h7ILPsxA008138; Mon, 18 Aug 2003 23:25:55 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id h7ILPsn9008137; Mon, 18 Aug 2003 23:25:54 +0200 Date: Mon, 18 Aug 2003 23:25:54 +0200 From: Francois Romieu To: Stephen Hemminger Cc: Jean Tourrilhes , "David S. Miller" , irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] (4/4) convert irlan to seq_file interface Message-ID: <20030818232554.A7779@electric-eye.fr.zoreil.com> References: <20030818122702.67e9162d.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030818122702.67e9162d.shemminger@osdl.org>; from shemminger@osdl.org on Mon, Aug 18, 2003 at 12:27:02PM -0700 X-archive-position: 4998 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Stephen Hemminger : > Convert irlan /proc interface to safer seq_file library. [...] > diff -Nru a/net/irda/irlan/irlan_filter.c b/net/irda/irlan/irlan_filter.c > --- a/net/irda/irlan/irlan_filter.c Mon Aug 18 11:11:02 2003 > +++ b/net/irda/irlan/irlan_filter.c Mon Aug 18 11:11:02 2003 [...] > @@ -216,26 +217,24 @@ > * Print status of filter. Used by /proc file system > * > */ > -int irlan_print_filter(int filter_type, char *buf) > +#ifdef CONFIG_PROC_FS > +void irlan_print_filter(struct seq_file *seq, int filter_type) > { > - int len = 0; > - > if (filter_type & IRLAN_DIRECTED) > - len += sprintf(buf+len, "%s", "DIRECTED "); > + seq_printf(seq, "%s", "DIRECTED "); > if (filter_type & IRLAN_FUNCTIONAL) > - len += sprintf(buf+len, "%s", "FUNCTIONAL "); > + seq_printf(seq, "%s", "FUNCTIONAL "); > if (filter_type & IRLAN_GROUP) > - len += sprintf(buf+len, "%s", "GROUP "); > + seq_printf(seq, "%s", "GROUP "); > if (filter_type & IRLAN_MAC_FRAME) > - len += sprintf(buf+len, "%s", "MAC_FRAME "); > + seq_printf(seq, "%s", "MAC_FRAME "); > if (filter_type & IRLAN_MULTICAST) > - len += sprintf(buf+len, "%s", "MULTICAST "); > + seq_printf(seq, "%s", "MULTICAST "); > if (filter_type & IRLAN_BROADCAST) > - len += sprintf(buf+len, "%s", "BROADCAST "); > + seq_printf(seq, "%s", "BROADCAST "); > if (filter_type & IRLAN_IPX_SOCKET) > - len += sprintf(buf+len, "%s", "IPX_SOCKET"); > - > - len += sprintf(buf+len, "\n"); > + seq_printf(seq, "%s", "IPX_SOCKET"); > > - return len; > + seq_putc(seq, '\n'); > } > +#endif (Ugly) variable naming apart, what about: void irlan_print_filter(struct seq_file *seq, int filter_type) { static struct { int mask; char *str; } filter_mask2str[] = { { IRLAN_DIRECTED, "DIRECTED" }, { IRLAN_FUNCTIONAL, "FUNCTIONAL" }, { IRLAN_GROUP, "GROUP" }, { IRLAN_MAC_FRAME, "MAC_FRAME" }, { IRLAN_MULTICAST, "MULTICAST" }, { IRLAN_BROADCAST, "BROADCAST" }, { IRLAN_IPX_SOCKET, "IPX_SOCKET" }, { 0, NULL } }, *p; for (p = filter_mask2str; p->str; p++) { if (filter_type & p->mask) seq_printf(seq, "%s ", p->str); } seq_putc(seq, '\n'); } -- Ueimor From davidsen@tmr.com Mon Aug 18 14:42:42 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 14:42:51 -0700 (PDT) Received: from gatekeeper.tmr.com (tmr-02.dsl.thebiz.net [216.238.38.204]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7ILgeFl032740 for ; Mon, 18 Aug 2003 14:42:41 -0700 Received: from localhost (davidsen@localhost) by gatekeeper.tmr.com (8.9.0/8.9.0) with SMTP id RAA02300; Mon, 18 Aug 2003 17:32:49 -0400 Date: Mon, 18 Aug 2003 17:32:49 -0400 (EDT) From: Bill Davidsen To: "David S. Miller" cc: Willy Tarreau , alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices In-Reply-To: <20030817223118.3cbc497c.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4999 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davidsen@tmr.com Precedence: bulk X-list: netdev On Sun, 17 Aug 2003, David S. Miller wrote: > On Mon, 18 Aug 2003 00:48:49 +0200 > Willy Tarreau wrote: > > > On Sun, Aug 17, 2003 at 06:24:06PM +0100, Alan Cox wrote: > > > > > So stick the address on eth0 not on lo since its not a loopback but an eth0 > > > address, then use arpfilter so you don't arp for the invalid magic shared IP > > > address, or NAT it, or it may work to do > > > > > > ip route add nexthop-addr src my-virtual-addr dev eth0 scope local onlink > > > ip route add default src my-virtual-addr via nexthop-addr dev eth0 scope global > > > > I have a case where this doesn't work > > Replying again... Alan does mention in the paragraph you've quoted > to use arpfilter, which works for every case imaginable. Okay, I'll show my ignorance and ask... the Documentation for arp_filter says source routing must be used. Is there some flag I'm missing, or a way to avoid having a rule per address, or is the 8 bit rule number larger in 2.6, or ??? Or is having a lot of IPs on one machine not an imaginable case? -- bill davidsen CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. From jt@bougret.hpl.hp.com Mon Aug 18 14:52:12 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 14:52:17 -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 h7ILq2Fl001112 for ; Mon, 18 Aug 2003 14:52:02 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel12.hp.com (Postfix) with ESMTP id D4B3F1C036AB; Mon, 18 Aug 2003 11:41:02 -0700 (PDT) Received: from bougret.hpl.hp.com (mail@bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_26305)/8.9.3 HPLabs Timeshare Server) with ESMTP id LAA17327; Mon, 18 Aug 2003 11:40:59 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 19oow7-0001gl-00; Mon, 18 Aug 2003 11:40:59 -0700 Date: Mon, 18 Aug 2003 11:40:59 -0700 To: Stephen Hemminger Cc: irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] ircomm - set owner get rid of MOD_INC/MOD_DEC Message-ID: <20030818184059.GA6457@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20030818111746.34b9e52b.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030818111746.34b9e52b.shemminger@osdl.org> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 5000 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev On Mon, Aug 18, 2003 at 11:17:46AM -0700, Stephen Hemminger wrote: > Ircomm in 2.6.0-test3 can just set the owner field in the tty structure > like other drivers, and not mess with MOD_INC/MOD_DEC. You missed a couple of comments. I sent the more complete version of the exact same patch a few weeks ago to Jeff Garzik, you may want to check with Jeff what the status on this. Of course, I would prefer the "more complete" version to go in. By the way, because of Jeff's turnaround, we are going to have this problem a lot. All my pending IrDA patches are listed on my web page, you may want to check it : http://www.hpl.hp.com/personal/Jean_Tourrilhes/IrDA/IrDA.html Thanks for the good work ! Jean P.S. : Did you manage to set-up the crossover serial cable ? From davidsen@tmr.com Mon Aug 18 15:03:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 15:03:30 -0700 (PDT) Received: from gatekeeper.tmr.com (tmr-02.dsl.thebiz.net [216.238.38.204]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IM3OFl001596 for ; Mon, 18 Aug 2003 15:03:25 -0700 Received: from localhost (davidsen@localhost) by gatekeeper.tmr.com (8.9.0/8.9.0) with SMTP id RAA02370; Mon, 18 Aug 2003 17:54:37 -0400 Date: Mon, 18 Aug 2003 17:54:37 -0400 (EDT) From: Bill Davidsen To: "David S. Miller" cc: Stephan von Krawczynski , willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices In-Reply-To: <20030818053007.7852ca77.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5001 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davidsen@tmr.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003, David S. Miller wrote: > On Mon, 18 Aug 2003 14:34:01 +0200 > Stephan von Krawczynski wrote: > > > what is the _positive_ outcome of this > > implementation compared to others? > > If you're not willing to think I can't help you resolve > the questions you have. Trying to think of something you have never seen is like trying to think of a new color. I can not think of a case where the current default behaviour is better (you can define that as your will, in terms of either functionality or convenience). > > If you don't understand source address selection, than it's > not possible for me to have an intellegent conversation about > this topic. > > So you need to make this crucial first step. > Good buzz words, your mailer dropped the URL of the document with the examples... Complaining that people don't understand without providing a pointer to some help for that lack is not helping them (or reducing the call for changes). If you want people to stop asking for patches help them do what they need to do. -- bill davidsen CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. From shemminger@osdl.org Mon Aug 18 15:06:09 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 15:06:13 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IM66Fl001782 for ; Mon, 18 Aug 2003 15:06:09 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7IM5Qo08718; Mon, 18 Aug 2003 15:05:26 -0700 Date: Mon, 18 Aug 2003 15:05:14 -0700 From: Stephen Hemminger To: Francois Romieu Cc: Jean Tourrilhes , "David S. Miller" , irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] (4/4) convert irlan to seq_file interface Message-Id: <20030818150514.310f6f5d.shemminger@osdl.org> In-Reply-To: <20030818232554.A7779@electric-eye.fr.zoreil.com> References: <20030818122702.67e9162d.shemminger@osdl.org> <20030818232554.A7779@electric-eye.fr.zoreil.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5002 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev I did a one step at a time conversion. > void irlan_print_filter(struct seq_file *seq, int filter_type) > { > static struct { > int mask; > char *str; > } filter_mask2str[] = { > { IRLAN_DIRECTED, "DIRECTED" }, > { IRLAN_FUNCTIONAL, "FUNCTIONAL" }, > { IRLAN_GROUP, "GROUP" }, > { IRLAN_MAC_FRAME, "MAC_FRAME" }, > { IRLAN_MULTICAST, "MULTICAST" }, > { IRLAN_BROADCAST, "BROADCAST" }, > { IRLAN_IPX_SOCKET, "IPX_SOCKET" }, > { 0, NULL } > }, *p; > > for (p = filter_mask2str; p->str; p++) { > if (filter_type & p->mask) > seq_printf(seq, "%s ", p->str); > } > seq_putc(seq, '\n'); > } If you are going to do that (and it looks good). Make the str a const and use C99 initializers? From romieu@fr.zoreil.com Mon Aug 18 15:30:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 15:30:39 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IMUXFl003021 for ; Mon, 18 Aug 2003 15:30:35 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id h7IMQcxA008989; Tue, 19 Aug 2003 00:26:38 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id h7IMQbk9008988; Tue, 19 Aug 2003 00:26:37 +0200 Date: Tue, 19 Aug 2003 00:26:37 +0200 From: Francois Romieu To: Stephen Hemminger Cc: Jean Tourrilhes , "David S. Miller" , irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] (4/4) convert irlan to seq_file interface Message-ID: <20030819002637.B7779@electric-eye.fr.zoreil.com> References: <20030818122702.67e9162d.shemminger@osdl.org> <20030818232554.A7779@electric-eye.fr.zoreil.com> <20030818150514.310f6f5d.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030818150514.310f6f5d.shemminger@osdl.org>; from shemminger@osdl.org on Mon, Aug 18, 2003 at 03:05:14PM -0700 X-archive-position: 5003 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Stephen Hemminger : [...] > If you are going to do that (and it looks good). Make the str a const > and use C99 initializers? I'll add a #define MASK2STR(m,s) { .mask = m, .str = s } and push it as an incremental patch once the bk-commit mail is here (tomorrow evening then). -- Ueimor From jt@bougret.hpl.hp.com Mon Aug 18 15:58:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 15:58:38 -0700 (PDT) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IMwOFl003828 for ; Mon, 18 Aug 2003 15:58:24 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel10.hp.com (Postfix) with ESMTP id 4496C1C032C1; Mon, 18 Aug 2003 15:34:29 -0700 (PDT) Received: from bougret.hpl.hp.com (mail@bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_26305)/8.9.3 HPLabs Timeshare Server) with ESMTP id PAA27033; Mon, 18 Aug 2003 15:34:28 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 19osa4-0001qw-00; Mon, 18 Aug 2003 15:34:28 -0700 Date: Mon, 18 Aug 2003 15:34:28 -0700 To: Jeff Garzik Cc: Stephen Hemminger , irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] ircomm - set owner get rid of MOD_INC/MOD_DEC Message-ID: <20030818223428.GB6962@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20030818111746.34b9e52b.shemminger@osdl.org> <20030818184059.GA6457@bougret.hpl.hp.com> <3F414E3F.9090908@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F414E3F.9090908@pobox.com> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 5004 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev On Mon, Aug 18, 2003 at 06:07:59PM -0400, Jeff Garzik wrote: > > Yes, I have "ircomm module fix" and "NSC '39x fixes" queued, and going > to Linus today with some more net driver stuff. > > Jeff By the way, I don't want you to take it the wrong way, I prefer a reliable person than a quick one. It's just hard to synchronise everything. Have fun... Jean From davem@redhat.com Mon Aug 18 15:59:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 15:59:48 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7IMxiFl004072 for ; Mon, 18 Aug 2003 15:59:45 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id PAA07625; Mon, 18 Aug 2003 15:51:41 -0700 Date: Mon, 18 Aug 2003 15:51:41 -0700 From: "David S. Miller" To: jt@hpl.hp.com Cc: jt@bougret.hpl.hp.com, shemminger@osdl.org, irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] ircomm - set owner get rid of MOD_INC/MOD_DEC Message-Id: <20030818155141.1648db4c.davem@redhat.com> In-Reply-To: <20030818184059.GA6457@bougret.hpl.hp.com> References: <20030818111746.34b9e52b.shemminger@osdl.org> <20030818184059.GA6457@bougret.hpl.hp.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5005 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 11:40:59 -0700 Jean Tourrilhes wrote: > By the way, because of Jeff's turnaround, Jeff's turnaround time isn't so hot lately, just use me for all the IRDA stuff until we can rely upon him again. I live in my email box and can push things into Linus's tree in 24 hours or less. From jgarzik@pobox.com Mon Aug 18 16:17:01 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 16:17:06 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7INGxFl005281 for ; Mon, 18 Aug 2003 16:17:00 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19osAc-0004GA-CM; Mon, 18 Aug 2003 23:08:10 +0100 Message-ID: <3F414E3F.9090908@pobox.com> Date: Mon, 18 Aug 2003 18:07:59 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: jt@hpl.hp.com CC: Stephen Hemminger , irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] ircomm - set owner get rid of MOD_INC/MOD_DEC References: <20030818111746.34b9e52b.shemminger@osdl.org> <20030818184059.GA6457@bougret.hpl.hp.com> In-Reply-To: <20030818184059.GA6457@bougret.hpl.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5006 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 Jean Tourrilhes wrote: > On Mon, Aug 18, 2003 at 11:17:46AM -0700, Stephen Hemminger wrote: > >>Ircomm in 2.6.0-test3 can just set the owner field in the tty structure >>like other drivers, and not mess with MOD_INC/MOD_DEC. > > > You missed a couple of comments. I sent the more complete > version of the exact same patch a few weeks ago to Jeff Garzik, you > may want to check with Jeff what the status on this. > Of course, I would prefer the "more complete" version to go > in. > > By the way, because of Jeff's turnaround, we are going to have > this problem a lot. All my pending IrDA patches are listed on my web > page, you may want to check it : Yes, I have "ircomm module fix" and "NSC '39x fixes" queued, and going to Linus today with some more net driver stuff. Jeff From jgarzik@pobox.com Mon Aug 18 17:08:13 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 17:08:19 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7J08BFl006991 for ; Mon, 18 Aug 2003 17:08:12 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19ou2j-0005NH-Dx; Tue, 19 Aug 2003 01:08:09 +0100 Message-ID: <3F416A5E.2060302@pobox.com> Date: Mon, 18 Aug 2003 20:07:58 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: jt@hpl.hp.com CC: Stephen Hemminger , "David S. Miller" , irda-users@lists.sourceforge.net, netdev@oss.sgi.com, lists@mdiehl.de Subject: Re: [PATCH] (1/5) get rid of useless hashbin in irtty References: <20030815154608.56cf0551.shemminger@osdl.org> <20030815230546.GA31831@bougret.hpl.hp.com> <20030816052048.5858d68a.davem@redhat.com> <20030817001405.GA1916@bougret.hpl.hp.com> <20030816175851.58a2c179.davem@redhat.com> <20030817011131.GA2120@bougret.hpl.hp.com> <20030818090313.7f153d7a.shemminger@osdl.org> <20030818165024.GB5992@bougret.hpl.hp.com> <20030818165321.GH24693@gtf.org> <20030818170850.GE5992@bougret.hpl.hp.com> In-Reply-To: <20030818170850.GE5992@bougret.hpl.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5007 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 Jean Tourrilhes wrote: > On Mon, Aug 18, 2003 at 12:53:21PM -0400, Jeff Garzik wrote: > >>On Mon, Aug 18, 2003 at 09:50:24AM -0700, Jean Tourrilhes wrote: >> >>> You can use irtty-sir with a cross-over serial cable between >>>two PCs. IrLAN is a bit flaky and no longer maintained, I would >>>recommend to try IrNET or RfCOMM. >> >>Can we remove IrLAN in 2.6, then? :) >> >> Jeff > > > The problem is that we don't have another implementation of > IrLAN. There are a few devices that talk IrLAN (NetBeamIr, Win95), and > for those there is no alternative and IrLAN works good enough with > them (I test it every few months). No need to remove it if it still > works... No argument. IrLAN definitely sounds like it should stay. > If you really are in cleanup mood, you can kill : > o irtty (broken - replaced by irtty-sir + sir-dev) > o toshoboe (no spinlock - replaced by donauboe) > o smc-ircc (flaky - replaced by smsc-ircc2) > o ep7211_ir (obsolete hardware, unmaintained) > Happy ? hehe :) Given this list, I would be ok with removing the first three, if you and others are ok with it. If something's been replaced, I don't have any problem removing it. If something doesn't have a replacement, like IrLAN or ep7211_ir, Linux generally leans towards not removing that code (retrocomputing!), so I was perhaps a bit hasty in suggesting that. But that's why we have discussion ;-) Jeff From acme@conectiva.com.br Mon Aug 18 17:40:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 17:41:00 -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 h7J0epFl007543 for ; Mon, 18 Aug 2003 17:40:52 -0700 Received: from [200.181.168.254] (helo=brinquendo.conectiva.com.br) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 19oues-0002kT-00; Mon, 18 Aug 2003 21:47:34 -0300 Received: by brinquendo.conectiva.com.br (Postfix, from userid 500) id 0E91B1966D; Mon, 18 Aug 2003 18:51:54 +0000 (UTC) Date: Mon, 18 Aug 2003 15:51:53 -0300 From: Arnaldo Carvalho de Melo To: Tommi Virtanen Cc: "David S. Miller" , hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: [PATCH] Change MAC without bringing interface down Message-ID: <20030818185153.GA1559@conectiva.com.br> References: <20030818091312.GA4889@lapdog> <20030818041911.358c3437.davem@redhat.com> <1061208824.16010.2119.camel@jzny.localdomain> <20030818051227.4f35f2f3.davem@redhat.com> <20030818160422.GB1793@lapdog> <20030818090654.7f44a16e.davem@redhat.com> <20030818171144.GC1793@lapdog> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030818171144.GC1793@lapdog> X-Url: http://advogato.org/person/acme Organization: Conectiva S.A. User-Agent: Mutt/1.5.4i X-archive-position: 5008 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, Aug 18, 2003 at 08:11:44PM +0300, Tommi Virtanen escreveu: > +void neigh_changeaddr(struct neigh_table *tbl, struct net_device *dev) > +{ > + int i; > + > + write_lock_bh(&tbl->lock); > + > + for (i=0; i<=NEIGH_HASHMASK; i++) { spaces before and after operators, please > +struct notifier_block arp_netdev_notifier = { > + arp_netdev_event, > + NULL, > + 0 > +}; c99 style please, that is: struct notifier_block arp_netdev_notifier = { .notifier_call = arp_netdev_event, } > +struct notifier_block ndisc_netdev_notifier = { > + ndisc_netdev_event, > + NULL, > + 0 > +}; ditto Thanks, - Arnaldo From greearb@candelatech.com Mon Aug 18 20:21:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 20:21:50 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-084.evrtwa1.dsl-verizon.net [4.33.45.84]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7J3LhFl009258 for ; Mon, 18 Aug 2003 20:21:44 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h7J3L0tf006239; Mon, 18 Aug 2003 20:21:00 -0700 Message-ID: <3F41979C.3070408@candelatech.com> Date: Mon, 18 Aug 2003 20:21:00 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Davidsen CC: "David S. Miller" , Willy Tarreau , alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5009 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Bill Davidsen wrote: > Okay, I'll show my ignorance and ask... the Documentation for arp_filter > says source routing must be used. Is there some flag I'm missing, or a way > to avoid having a rule per address, or is the 8 bit rule number larger in > 2.6, or ??? Or is having a lot of IPs on one machine not an imaginable > case? Last response I got was that one would have to hack the netlink api to get a bigger index because the design (and rfc, unfortunately) describe the field as only 8 bits. I never did hear a response to my comment that this was inadequate in this age of vlans... -- Ben Greear Candela Technologies Inc http://www.candelatech.com From garzik@gtf.org Mon Aug 18 21:27:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 21:27:45 -0700 (PDT) Received: from havoc.gtf.org ([63.247.75.124]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7J4RZFl012303 for ; Mon, 18 Aug 2003 21:27:36 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id 841F66653; Tue, 19 Aug 2003 00:27:29 -0400 (EDT) Date: Tue, 19 Aug 2003 00:27:29 -0400 From: Jeff Garzik To: torvalds@osdl.org Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [bk patches] 2.6 net driver updates Message-ID: <20030819042729.GA1360@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: 5010 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Linus, please do a bk pull bk://kernel.bkbits.net/jgarzik/net-drivers-2.6 Patch is also available from ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.0-test3-bk6-netdrvr1.patch.bz2 This will update the following files: Documentation/networking/8139too.txt | 1 drivers/net/8139cp.c | 4 drivers/net/8139too.c | 10 drivers/net/Kconfig | 2 drivers/net/eexpress.c | 2 drivers/net/tulip/Kconfig | 8 drivers/net/wireless/Kconfig | 2 drivers/net/wireless/airo.c | 522 +++++++++++++++++++---------------- drivers/net/wireless/atmel.c | 21 - drivers/net/wireless/atmel_cs.c | 1 10 files changed, 313 insertions(+), 260 deletions(-) through these ChangeSets: (03/08/19 1.1240) [netdrvr eexpress] fix buglet in skb_padto conversion (03/08/19 1.1239) [netdrvr de2104x] fix Kconfig help text to reflect reality (03/08/19 1.1238) [wireless atmel] minor updates 1) Add another card to the PCMCIA card database. 2) Fix a bug in wireless extensions. 3) Remove extra code for compilation without the firmware loader 4) force-enable CRC32 and FW_LOADER in Kconfig. (03/08/19 1.1237) [netdrvr 8139too] add adapter to supported list, in docs (03/08/19 1.1236) [netdrvr] fix seeq8005 entry help text in Kconfig (03/08/18 1.1235) [netdrvr 8139too] fix resume behavior (03/08/18 1.1234) [netdrvr 8139cp] fix h/w vlan offload It wants big endian vlan tags. IEEE, or just weird? (03/08/18 1.1233) [wireless airo] Replaces task queues by simpler kernel_thread From garzik@gtf.org Mon Aug 18 21:29:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 21:29:42 -0700 (PDT) Received: from havoc.gtf.org ([63.247.75.124]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7J4TaFl012513 for ; Mon, 18 Aug 2003 21:29:37 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id EBD5D6646; Tue, 19 Aug 2003 00:29:17 -0400 (EDT) Date: Tue, 19 Aug 2003 00:29:17 -0400 From: Jeff Garzik To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [bk patches] 2.4 net driver updates Message-ID: <20030819042917.GA1402@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: 5011 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 (pending for Marcelo, for 2.4.23-pre1) BK users: bk pull bk://kernel.bkbits.net/jgarzik/net-drivers-2.4 or bk pull http://gkernel.bkbits.net/net-drivers-2.4 Patch: ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.4/2.4.22-rc2-netdrvr1.patch.bz2 This will update the following files: drivers/net/8139cp.c | 4 drivers/net/8139too.c | 10 drivers/net/bonding/bond_main.c | 17 - drivers/net/bonding/bonding.h | 2 drivers/net/net_init.c | 3 drivers/net/tulip/tulip_core.c | 1 drivers/net/wireless/airo.c | 568 ++++++++++++++++++++++------------------ include/linux/netdevice.h | 2 8 files changed, 342 insertions(+), 265 deletions(-) through these ChangeSets: (03/08/18 1.1064.1.13) [netdrvr 8139too] fix resume behavior, by correctly saving/restoring pci state. (03/08/18 1.1064.1.12) [netdrvr 8139cp] fix h/w vlan offload It wants big endian vlan tags. IEEE, or just weird? (03/08/18 1.1064.1.11) [wireless airo] Replaces task queues by simpler kernel_thread (03/08/18 1.1064.1.10) [wireless airo] Fixes unregistering of PCI cards (03/08/17 1.1064.1.9) [netdrvr tulip] add pci id for 3com 3CSOHO100B-TX (03/08/07 1.1064.1.8) [netdrvr bonding] embed stats struct inside bonding private struct Simplification: Don't allocate the stats struct via kmalloc, embed it inside it's parent bonding_t. (03/08/07 1.1064.1.7) [net] export alloc_netdev (03/08/07 1.1064.1.6) [PATCH] Fix adhoc config (03/08/07 1.1064.1.5) [PATCH] Safer unload code (03/08/07 1.1064.1.4) [PATCH] MIC support with newer firmware (03/08/07 1.1064.1.3) [PATCH] Missing lines for Wireless Extensions 16 (03/08/07 1.1064.1.2) [netdrvr airo] MAC type changed to unsigned (03/08/07 1.1064.1.1) [netdrvr airo] Missing defines (only for documentation) From tv@tv.debian.net Mon Aug 18 22:50:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 18 Aug 2003 22:50:52 -0700 (PDT) Received: from yin.wanderer.org (yin.wanderer.org [195.218.87.139]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7J5ohFl013592 for ; Mon, 18 Aug 2003 22:50:44 -0700 Received: by yin.wanderer.org (Postfix, from userid 1000) id A13BDACD6; Tue, 19 Aug 2003 08:50:40 +0300 (EEST) Date: Tue, 19 Aug 2003 08:50:34 +0300 X-OfflineIMAP-x360116747-72656d6f74652d74764074762e64656269616e2e6e6574-494e424f582e6f7574626f78: 1061272243-0801852367051 From: Tommi Virtanen To: Arnaldo Carvalho de Melo Cc: "David S. Miller" , hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: [PATCH] Change MAC without bringing interface down Message-ID: <20030819055034.GA809@lapdog> References: <20030818171144.GC1793@lapdog> <20030818185153.GA1559@conectiva.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030818185153.GA1559@conectiva.com.br> User-Agent: Mutt/1.5.4i X-archive-position: 5012 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tv@debian.org Precedence: bulk X-list: netdev On Mon, Aug 18, 2003 at 03:51:53PM -0300, Arnaldo Carvalho de Melo wrote: > > + for (i=0; i<=NEIGH_HASHMASK; i++) { > spaces before and after operators, please > > +struct notifier_block arp_netdev_notifier = { > > + arp_netdev_event, > > + NULL, > > + 0 > > +}; > c99 style please, that is: > > +struct notifier_block ndisc_netdev_notifier = { > > + ndisc_netdev_event, > > + NULL, > > + 0 > > +}; > ditto Here's an updated patch with those nits picked. Those were all cut-and-pasted from elsewhere, so if you want perfection, there's lots of those to fix. ===== include/net/neighbour.h 1.1 vs edited ===== --- 1.1/include/net/neighbour.h Tue Feb 5 19:39:48 2002 +++ edited/include/net/neighbour.h Mon Aug 18 18:52:30 2003 @@ -180,6 +180,7 @@ extern void neigh_destroy(struct neighbour *neigh); extern int __neigh_event_send(struct neighbour *neigh, struct sk_buff *skb); extern int neigh_update(struct neighbour *neigh, const u8 *lladdr, u8 new, int override, int arp); +extern void neigh_changeaddr(struct neigh_table *tbl, struct net_device *dev); extern int neigh_ifdown(struct neigh_table *tbl, struct net_device *dev); extern int neigh_resolve_output(struct sk_buff *skb); extern int neigh_connected_output(struct sk_buff *skb); ===== net/core/neighbour.c 1.9 vs edited ===== --- 1.9/net/core/neighbour.c Thu Jun 12 09:24:41 2003 +++ edited/net/core/neighbour.c Tue Aug 19 08:45:14 2003 @@ -50,6 +50,7 @@ static void neigh_app_notify(struct neighbour *n); #endif static int pneigh_ifdown(struct neigh_table *tbl, struct net_device *dev); +void neigh_changeaddr(struct neigh_table *tbl, struct net_device *dev); static int neigh_glbl_allocs; static struct neigh_table *neigh_tables; @@ -167,6 +168,33 @@ dev_put(skb->dev); kfree_skb(skb); } +} + +void neigh_changeaddr(struct neigh_table *tbl, struct net_device *dev) +{ + int i; + + write_lock_bh(&tbl->lock); + + for (i=0; i <= NEIGH_HASHMASK; i++) { + struct neighbour *n, **np; + + np = &tbl->hash_buckets[i]; + while ((n = *np) != NULL) { + if (dev && n->dev != dev) { + np = &n->next; + continue; + } + *np = n->next; + write_lock_bh(&n->lock); + n->dead = 1; + neigh_del_timer(n); + write_unlock_bh(&n->lock); + neigh_release(n); + } + } + + write_unlock_bh(&tbl->lock); } int neigh_ifdown(struct neigh_table *tbl, struct net_device *dev) ===== net/ipv4/arp.c 1.11 vs edited ===== --- 1.11/net/ipv4/arp.c Fri Jun 27 09:03:01 2003 +++ edited/net/ipv4/arp.c Tue Aug 19 08:45:36 2003 @@ -1212,6 +1212,26 @@ } #endif +static int arp_netdev_event(struct notifier_block *this, unsigned long event, void *ptr) +{ + struct net_device *dev = ptr; + + switch (event) { + case NETDEV_CHANGEADDR: + neigh_changeaddr(&arp_tbl, dev); + rt_cache_flush(0); + break; + default: + break; + } + + return NOTIFY_DONE; +} + +struct notifier_block arp_netdev_notifier = { + .notifier_call = arp_netdev_event, +}; + /* Note, that it is not on notifier chain. It is necessary, that this routine was called after route cache will be flushed. @@ -1243,6 +1263,7 @@ #ifdef CONFIG_SYSCTL neigh_sysctl_register(NULL, &arp_tbl.parms, NET_IPV4, NET_IPV4_NEIGH, "ipv4"); #endif + register_netdevice_notifier(&arp_netdev_notifier); } ===== net/ipv6/ndisc.c 1.22 vs edited ===== --- 1.22/net/ipv6/ndisc.c Tue Jun 24 02:21:28 2003 +++ edited/net/ipv6/ndisc.c Tue Aug 19 08:45:53 2003 @@ -1336,6 +1336,26 @@ return 0; } +static int ndisc_netdev_event(struct notifier_block *this, unsigned long event, void *ptr) +{ + struct net_device *dev = ptr; + + switch (event) { + case NETDEV_CHANGEADDR: + neigh_changeaddr(&nd_tbl, dev); + fib6_run_gc(0); + break; + default: + break; + } + + return NOTIFY_DONE; +} + +struct notifier_block ndisc_netdev_notifier = { + .notifier_call = ndisc_netdev_event, +}; + int __init ndisc_init(struct net_proto_family *ops) { struct sock *sk; @@ -1377,6 +1397,7 @@ neigh_sysctl_register(NULL, &nd_tbl.parms, NET_IPV6, NET_IPV6_NEIGH, "ipv6"); #endif + register_netdevice_notifier(&ndisc_netdev_notifier); return 0; } -- :(){ :|:&};: From bloemsaa@xs4all.nl Tue Aug 19 01:19:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 01:19:54 -0700 (PDT) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7J8JlFl016459 for ; Tue, 19 Aug 2003 01:19:48 -0700 Received: from llewella (vialle.xs4all.nl [213.84.6.25]) by smtpzilla1.xs4all.nl (8.12.9/8.12.9) with SMTP id h7J8J2lJ017634; Tue, 19 Aug 2003 10:19:22 +0200 (CEST) Message-ID: <05f501c3662a$9ba72d30$c801a8c0@llewella> From: "Bas Bloemsaat" To: "Bill Davidsen" , "David S. Miller" Cc: "Willy Tarreau" , , , , , , , , , References: Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Date: Tue, 19 Aug 2003 09:58:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 5013 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bloemsaa@xs4all.nl Precedence: bulk X-list: netdev > > Okay, I'll show my ignorance and ask... the Documentation for arp_filter > says source routing must be used. Is there some flag I'm missing, or a way > to avoid having a rule per address, or is the 8 bit rule number larger in > 2.6, or ??? Or is having a lot of IPs on one machine not an imaginable > case? I'll include a conversation I had with David, yesterday. Maybe it clear things up: Someone: Replying again... Alan does mention in the paragraph you've quoted Someone: to use arpfilter, which works for every case imaginable. Me: No it doesn't. When I have two nics on DHCP on the same ethernet segment, it M: cannot be made to work. I don't know the ip addresses beforehand. And if if M: I would get them with scripting and crafted some rules on the fly, there's M: no way I can be sure I'll get the same IP's on a renew, so I'd have to check M: often. David: You don't understand how 'arpfilter' works. D: It's a netfilter module that allows you to block ARP packets D: going in and out of the system using any criteria you want. D: It can block on device, on src MAC address, on destination D: MAC address, whatever you want. Me: Maybe you could explain to me how to filter out all ARP M: responses to an IP not bound to that mac address, of letting through all the M: ARP responses for an IP bound to that mac, without specifying the IP address M: (because that can change, sometimes quite often). I really do not see it. D: You wouldn't use 'arpfiler' for that. D: You would use the 'arp_filter' sysctl on your devices and D: proper setting of the preferred source in the routes on D: your machine. M: For that I'd still need the IP address. Don't I? And I don't have that until M: later, and it is prone to change. M: So I have a feeling you are sending me in circles. D: You need to change routes when the IP address changes, so all I'm D: asking you to do is setup your routes correctly at those points D: in time. M: Which is on dhcp renew. Which calls for a rewrite of dhcpclient, or a daemon M: that monitors it. D: Sure, if software is setting routes manually and it isn't D: doing so the way you want it to it'll need changes. In other words: it keeps being done the way it is now, never mind people having problems with it. Never mind the changing it doesn't break anything. Never mind I cannot come up with a scenario that actually benefits from the current situation over the new situation. IP Multipathing does not qualify. The current way actually violates IP multipathing: Multipathing calls for two seperate, fixed internal IP's which are seperated from each other. Multipathing requires you to restore the IP address to it's preferred interface if it comes up again. In multipathing, all IP's have preferred interfaces, not one left by chance. Remember that multipathing doesn't need to be symmetric. It may very way have a fat pipe on one end, and a smaller backup pipe. All of this is not satisfied with the current, broken, linux arp. So we're still short of an example that benefits from the current situation Regards, Bas From alan@lxorguk.ukuu.org.uk Tue Aug 19 05:36:43 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 05:36:53 -0700 (PDT) Received: from dhcp23.swansea.linux.org.uk (pc1-cwma1-5-cust4.swan.cable.ntl.com [80.5.120.4]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JCafFl023947 for ; Tue, 19 Aug 2003 05:36:42 -0700 Received: from dhcp23.swansea.linux.org.uk (localhost.localdomain [127.0.0.1]) by dhcp23.swansea.linux.org.uk (8.12.9/8.12.9) with ESMTP id h7JCZvra030589; Tue, 19 Aug 2003 13:35:57 +0100 Received: (from alan@localhost) by dhcp23.swansea.linux.org.uk (8.12.9/8.12.9/Submit) id h7JCZjIa030587; Tue, 19 Aug 2003 13:35:45 +0100 X-Authentication-Warning: dhcp23.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: RE: [2.4 PATCH] bugfix: ARP respond on all devices From: Alan Cox To: Richard Underwood Cc: "'David S. Miller'" , Stephan von Krawczynski , willy@w.ods.org, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, Marcelo Tosatti , netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, Linux Kernel Mailing List In-Reply-To: <353568DCBAE06148B70767C1B1A93E625EAB57@post.pc.aspectgroup.co.uk> References: <353568DCBAE06148B70767C1B1A93E625EAB57@post.pc.aspectgroup.co.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1061296544.30566.8.camel@dhcp23.swansea.linux.org.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 (1.4.3-3) Date: 19 Aug 2003 13:35:45 +0100 X-archive-position: 5014 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: netdev On Maw, 2003-08-19 at 13:02, Richard Underwood wrote: > ARP is local to a broadcast net. The ARP standard explicitly > prohibits responding to an ARP request on a different interface. Correct, but we don't do that > If you broadcast a request asking for a reply on an entirely > different subnet, you're asking for trouble. You REDUCE the likelyhood of a > successful ARP reply, not increase it. You increase it and you shortcut on shared lans. Thats really a seperate issue to the question of which source is used. If you loopback someone elses address on your own lo device I'm not suprised weird shit happens, put the alias on eth0 where it belongs. > All you can possibly achieve by sending REQUESTS from the wrong IP > number is assist screwed up networks where you've got multiple subnets on > the same copper and cause a shed-load of security issues. Not in general. If you are using ARP your lan is hardly "secure". For most situations the trust across multiple aggregated lans is the same, if it isnt people use vlan (which rarely helps 8)) From bloemsaa@xs4all.nl Tue Aug 19 06:12:30 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 06:12:33 -0700 (PDT) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JDCSFl025767 for ; Tue, 19 Aug 2003 06:12:29 -0700 Received: from llewella (vialle.xs4all.nl [213.84.6.25]) by smtpzilla1.xs4all.nl (8.12.9/8.12.9) with SMTP id h7JDBxQq031572; Tue, 19 Aug 2003 15:12:10 +0200 (CEST) Message-ID: <070c01c36653$7f3c1ab0$c801a8c0@llewella> From: "Bas Bloemsaat" To: "Richard Underwood" , "'David S. Miller'" , "Stephan von Krawczynski" Cc: , , , , , , , , , , References: <353568DCBAE06148B70767C1B1A93E625EAB57@post.pc.aspectgroup.co.uk> Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Date: Tue, 19 Aug 2003 15:11:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 5015 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bloemsaa@xs4all.nl Precedence: bulk X-list: netdev > The RFC I quoted (985) says the ARP packets generated by Linux > should be dropped. Sure, the RFC isn't a standard, but there ARE plenty of > implementations that obey it for perfectly valid security reasons. Same goes for 1180. It it doesn't define a standard either, but makes perfectly clear that any interface has it's own ARP, not one ARP for the entire system. Regards, Bas From vnuorval@tcs.hut.fi Tue Aug 19 06:20:09 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 06:20:14 -0700 (PDT) Received: from mail.tcs.hut.fi (mail.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JDJwFl026121 for ; Tue, 19 Aug 2003 06:19:59 -0700 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by mail.tcs.hut.fi (Postfix) with ESMTP id EC4138001D0; Tue, 19 Aug 2003 15:47:04 +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 h7JCl45L026178; Tue, 19 Aug 2003 15:47:04 +0300 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-5) with ESMTP id h7JCl3dx026174; Tue, 19 Aug 2003 15:47:03 +0300 Date: Tue, 19 Aug 2003 15:47:03 +0300 (EEST) From: Ville Nuorvala To: shemminger@osdl.org Cc: greg@kroah.com, Subject: dev/core/net_sysfs.c: missing release() function in net_class Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5016 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Hi, lately I've been getting a nasty looking warning from class_dev_release() in drivers/base/class.c when I unregister my ip6_tunnel devices. The warning (added by Greg Kroah-Hartman in cset 1.1152.2.7) is apparently triggered because net_class doesn't have .release set. Would an empty dummy function be enough for net_class or should the release function actually do something? Thanks, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From Robert.Olsson@data.slu.se Tue Aug 19 06:55:42 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 06:55:46 -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 h7JDteFl027192 for ; Tue, 19 Aug 2003 06:55:42 -0700 Received: (from robert@localhost) by robur.slu.se (8.9.3p2/8.9.3) id PAA30875; Tue, 19 Aug 2003 15:54:34 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16194.11289.761163.104079@robur.slu.se> Date: Tue, 19 Aug 2003 15:54:33 +0200 To: bellucda@tiscali.it Cc: netdev@oss.sgi.com, davem@redhat.com Subject: [PATCH] make pktgen depends on procfs [2.6.0-test3] In-Reply-To: <200308182326.10798.bellucda@tiscali.it> References: <200308182326.10798.bellucda@tiscali.it> X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 5017 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 Daniele Bellucci writes: > IMHO pktgen should depends on proc fs to avoid the following compilation error: > Hello! It should be changed to: diff -urN 1.0/net/Kconfig 1.1/net/Kconfig --- 1.0/net/Kconfig 2003-08-18 23:25:02.000000000 +0200 +++ 1.1/net/Kconfig 2003-08-18 23:25:13.000000000 +0200 @@ -661,6 +661,7 @@ config NET_PKTGEN tristate "Packet Generator (USE WITH CAUTION)" + depends on PROC_FS ---help--- This module will inject preconfigured packets, at a configurable rate, out of a given interface. It is used for network interface > + depends on CONFIG_PROC_FS Cheers. --ro From bellucda@tiscali.it Tue Aug 19 06:58:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 06:58:38 -0700 (PDT) Received: from mail-1.tiscali.it (mail-1.tiscali.it [195.130.225.147]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JDwXFl027512 for ; Tue, 19 Aug 2003 06:58:34 -0700 Received: from localhost.localdomain (217.133.208.84) by mail-1.tiscali.it (6.7.019) id 3F335F02003D2762; Tue, 19 Aug 2003 15:58:21 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Daniele Bellucci Reply-To: bellucda@tiscali.it To: Robert Olsson Subject: Re: [PATCH] make pktgen depends on procfs [2.6.0-test3] Date: Tue, 19 Aug 2003 15:58:22 +0200 User-Agent: KMail/1.4.3 Cc: netdev@oss.sgi.com, davem@redhat.com References: <200308182326.10798.bellucda@tiscali.it> <16194.11289.761163.104079@robur.slu.se> In-Reply-To: <16194.11289.761163.104079@robur.slu.se> MIME-Version: 1.0 Message-Id: <200308191558.22513.bellucda@tiscali.it> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7JDwXFl027512 X-archive-position: 5018 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bellucda@tiscali.it Precedence: bulk X-list: netdev > Hello! > It should be changed to: > > diff -urN 1.0/net/Kconfig 1.1/net/Kconfig > --- 1.0/net/Kconfig 2003-08-18 23:25:02.000000000 +0200 > +++ 1.1/net/Kconfig 2003-08-18 23:25:13.000000000 +0200 > @@ -661,6 +661,7 @@ > > config NET_PKTGEN > tristate "Packet Generator (USE WITH CAUTION)" > + depends on PROC_FS > ---help--- > This module will inject preconfigured packets, at a configurable > rate, out of a given interface. It is used for network interface > > > + depends on CONFIG_PROC_FS > > Cheers. > --ro Argh !%$@#! i've post the wrong version ;( -- Daniele. From willy@w.ods.org Tue Aug 19 07:55:42 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 07:55:51 -0700 (PDT) Received: from www.home.local (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JEteFl028509 for ; Tue, 19 Aug 2003 07:55:41 -0700 Received: from alpha.home.local (alpha [10.0.1.2]) by www.home.local (8.12.1/8.12.1) with ESMTP id h7JEt5pn032738; Tue, 19 Aug 2003 16:55:05 +0200 Received: (from willy@localhost) by alpha.home.local (8.12.4/8.12.1) id h7JEs3NB003955; Tue, 19 Aug 2003 16:54:03 +0200 Date: Tue, 19 Aug 2003 16:54:03 +0200 From: Willy Tarreau To: Richard Underwood Cc: "'Alan Cox'" , "'David S. Miller'" , Stephan von Krawczynski , willy@w.ods.org, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, Marcelo Tosatti , netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, Linux Kernel Mailing List Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-ID: <20030819145403.GA3407@alpha.home.local> References: <353568DCBAE06148B70767C1B1A93E625EAB58@post.pc.aspectgroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <353568DCBAE06148B70767C1B1A93E625EAB58@post.pc.aspectgroup.co.uk> User-Agent: Mutt/1.4i X-archive-position: 5019 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@w.ods.org Precedence: bulk X-list: netdev Hello, On Tue, Aug 19, 2003 at 03:34:43PM +0100, Richard Underwood wrote: > As an example, I have a router/firewall for the office that has two > interface cards, both with perfectly valid internal addresses - these > addresses aren't used anywhere else on the network. > > Two of the interfaces are: 172.20.240.2/24 and 172.24.0.1/16. My > default gateway is 172.20.240.1 and there aren't any other non-interface > routes. If I do: > > # arp -d 172.24.0.80 > # ping -I 172.20.240.2 172.24.0.80 > > I see: > > 16:18:40.856328 arp who-has 172.24.0.80 tell 172.20.240.2 > 16:18:40.856431 arp reply 172.24.0.80 is-at 0:50:da:44:f:37 > > Now, since 172.24.0.80 is a Linux box, it's happily adding > 172.20.240.2 into its ARP table and reply to it, hence the reply. > > But if I was to do this in the other direction (arp -d 172.20.240.1; > ping -I 172.24.0.1 172.20.240.1) then I'd lose connectivity over my default > route because 172.20.240.1 won't accept ARP packets from IP numbers not on > the connected subnet. The ARP entry will block any further ARP > requests from valid IP numbers. This is exactly the case I calmly discussed privately with David then Alexey. Both explained me that in fact, the remote host shouldn't be filtering the ARP requests based on the source IP they provide, but agreed that it seems to be a general trend today. Alexey proposed a slight change which can at least solve this very common case by preventing the system from using the local address as a source IP if it is not on the interface through which the request is sent. Obviously it will not solve all very special cases, which people can work around with arptables, but it will solve this common one. Cheers, Willy From skraw@ithnet.com Tue Aug 19 08:07:56 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 08:08:02 -0700 (PDT) Received: from heather-ng.ithnet.com (mail3.ithnet.com [217.64.64.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JF7rFl029101 for ; Tue, 19 Aug 2003 08:07:55 -0700 Received: (qmail 23273 invoked by uid 0); 19 Aug 2003 15:07:52 -0000 Received: from skraw@ithnet.com by heather-ng (Processed in 0.263495 secs); 19 Aug 2003 15:07:52 -0000 X-Virus-Status: No Received: from unknown (HELO ithnet.com) (217.64.64.14) by heather-ng.ithnet.com with SMTP; 19 Aug 2003 15:07:51 -0000 X-Sender-Authentication: SMTPafterPOP by from 217.64.64.14 Date: Tue, 19 Aug 2003 17:07:51 +0200 From: Stephan von Krawczynski To: Willy Tarreau Cc: richard@aspectgroup.co.uk, alan@lxorguk.ukuu.org.uk, davem@redhat.com, willy@w.ods.org, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030819170751.2b92ba2e.skraw@ithnet.com> In-Reply-To: <20030819145403.GA3407@alpha.home.local> References: <353568DCBAE06148B70767C1B1A93E625EAB58@post.pc.aspectgroup.co.uk> <20030819145403.GA3407@alpha.home.local> Organization: ith Kommunikationstechnik GmbH X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5020 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: skraw@ithnet.com Precedence: bulk X-list: netdev On Tue, 19 Aug 2003 16:54:03 +0200 Willy Tarreau wrote: > This is exactly the case I calmly discussed privately with David then Alexey. > Both explained me that in fact, the remote host shouldn't be filtering the > ARP requests based on the source IP they provide, Hm, what rule is broken by the remote host, then? I mean "remote host shouln't" reads like "according to RFC-XYZ he should not". IFF of course the remote host is not broken, then our idea must be broken. Else world would have kind of a definition gap in this layer of networking, and I hardly believe that. Regards, Stephan From davem@redhat.com Tue Aug 19 08:32:59 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 08:33:05 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JFWwFl029700 for ; Tue, 19 Aug 2003 08:32:59 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id IAA09697; Tue, 19 Aug 2003 08:22:27 -0700 Date: Tue, 19 Aug 2003 08:22:27 -0700 From: "David S. Miller" To: Ben Greear Cc: davidsen@tmr.com, willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030819082227.5ef3b7ed.davem@redhat.com> In-Reply-To: <3F41979C.3070408@candelatech.com> References: <3F41979C.3070408@candelatech.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5021 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 18 Aug 2003 20:21:00 -0700 Ben Greear wrote: > I never did hear a response to my comment that this > was inadequate in this age of vlans... Just define a rtnetlink attribute to extend the ID number, that's all. It's not hard work and it eliminates the 8-bit limit. From emann@mrv.com Tue Aug 19 08:35:23 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 08:35:28 -0700 (PDT) Received: from apollo.nbase.co.il (apollo.nbase.co.il [194.90.137.2]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JFZ0Fl030051 for ; Tue, 19 Aug 2003 08:35:22 -0700 Received: from mrv.com ([194.90.139.36]) by apollo.nbase.co.il (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-44418U200L2S100) with ESMTP id AAA1177 for ; Tue, 19 Aug 2003 18:38:38 +0200 Message-ID: <3F424405.6020002@mrv.com> Date: Tue, 19 Aug 2003 18:36:37 +0300 From: Eran Mann User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: [patch 2.4] kernel oops on VLAN removal Content-Type: multipart/mixed; boundary="------------050402020401080606060404" X-archive-position: 5022 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: emann@mrv.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------050402020401080606060404 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The attached patch against 2.4.21 (applies cleanly to 2.4.22-rc2) fixes an oops in the VLAN code. The current code attempts to add a proc entry for each vlan device, however there is no check whether this attempt succeeded. When a device is unregistered it tries to remove the proc entry, if none was added the oops follows... ksymoops 2.4.4 on i686 2.4.21. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.21/ (default) -m /boot/System.map-2.4.21 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. cpu: 0, clocks: 1329900, slice: 664950 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html Unable to handle kernel NULL pointer dereference at virtual address 00000004 d4e62cfc *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00210202 eax: 00000000 ebx: c1bfb400 ecx: cc9e5000 edx: 00000002 esi: c20c0004 edi: 00000ffa ebp: 00003fe8 esp: c19f1eb4 ds: 0018 es: 0018 ss: 0018 Process vconfig (pid: 5398, stackpage=c19f1000) Stack: c8c92e74 cc9e5000 d4e622a6 c1bfb400 00000000 c20c0000 00000010 00200286 00000003 00000000 c1bfb400 ffffffea c19f1f60 ffffffe7 d4e623ba cc9e5000 00000ffa c12c7354 000001f0 3e60e0c4 c0288d44 c19f1f28 c02745c4 c12ca200 Call Trace: [] [] [] [] [] [] [] [] Code: 8b 48 04 51 e8 eb b6 2e eb 8b 43 68 c7 40 74 00 00 00 00 31 >>EIP; d4e62cfc <[8021q]vlan_proc_rem_dev+5c/80> <===== Trace; d4e622a6 <[8021q]unregister_vlan_dev+86/160> Trace; d4e623ba <[8021q]unregister_vlan_device+3a/a0> Trace; c02745c4 Trace; d4e62aea <[8021q]vlan_ioctl_handler+13a/170> Trace; c0259520 Trace; c02202ee Trace; c013fec7 Trace; c0108913 Code; d4e62cfc <[8021q]vlan_proc_rem_dev+5c/80> 00000000 <_EIP>: Code; d4e62cfc <[8021q]vlan_proc_rem_dev+5c/80> <===== 0: 8b 48 04 mov 0x4(%eax),%ecx <===== Code; d4e62cff <[8021q]vlan_proc_rem_dev+5f/80> 3: 51 push %ecx Code; d4e62d00 <[8021q]vlan_proc_rem_dev+60/80> 4: e8 eb b6 2e eb call eb2eb6f4 <_EIP+0xeb2eb6f4> c014e3f0 Code; d4e62d05 <[8021q]vlan_proc_rem_dev+65/80> 9: 8b 43 68 mov 0x68(%ebx),%eax Code; d4e62d08 <[8021q]vlan_proc_rem_dev+68/80> c: c7 40 74 00 00 00 00 movl $0x0,0x74(%eax) Code; d4e62d0f <[8021q]vlan_proc_rem_dev+6f/80> 13: 31 00 xor %eax,(%eax) 1 warning issued. Results may not be reliable. -- Eran Mann MRV International Tel: 972-4-9936297 Fax: 972-4-9890430 www.mrv.com --------------050402020401080606060404 Content-Type: text/plain; name="linux-2.4.21-vlan-proc.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="linux-2.4.21-vlan-proc.diff" diff -ruN linux-2.4.21/net/8021q/vlan.c linux-2.4.21.fixed/net/8021q/vlan.c --- linux-2.4.21/net/8021q/vlan.c Fri Jun 13 17:51:39 2003 +++ linux-2.4.21.fixed/net/8021q/vlan.c Tue Aug 19 17:38:22 2003 @@ -533,7 +533,9 @@ grp->vlan_devices[VLAN_ID] = new_dev; - vlan_proc_add_dev(new_dev); /* create it's proc entry */ + if (vlan_proc_add_dev(new_dev)<0)/* create it's proc entry */ + printk(KERN_WARNING "VLAN: failed to add proc entry for %s\n", + new_dev->name); if (real_dev->features & NETIF_F_HW_VLAN_FILTER) real_dev->vlan_rx_add_vid(real_dev, VLAN_ID); diff -ruN linux-2.4.21/net/8021q/vlanproc.c linux-2.4.21.fixed/net/8021q/vlanproc.c --- linux-2.4.21/net/8021q/vlanproc.c Fri Jun 13 17:51:39 2003 +++ linux-2.4.21.fixed/net/8021q/vlanproc.c Tue Aug 19 17:38:22 2003 @@ -204,8 +204,10 @@ #endif /** NOTE: This will consume the memory pointed to by dent, it seems. */ - remove_proc_entry(VLAN_DEV_INFO(vlandev)->dent->name, proc_vlan_dir); - VLAN_DEV_INFO(vlandev)->dent = NULL; + if (VLAN_DEV_INFO(vlandev)->dent) { + remove_proc_entry(VLAN_DEV_INFO(vlandev)->dent->name, proc_vlan_dir); + VLAN_DEV_INFO(vlandev)->dent = NULL; + } return 0; } --------------050402020401080606060404-- From acme@conectiva.com.br Tue Aug 19 08:36:08 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 08:36:22 -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 h7JFZkFl030171 for ; Tue, 19 Aug 2003 08:36:07 -0700 Received: from [200.181.168.254] (helo=brinquendo.conectiva.com.br) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 19p8cx-0003ir-00; Tue, 19 Aug 2003 12:42:32 -0300 Received: by brinquendo.conectiva.com.br (Postfix, from userid 500) id B65711966D; Tue, 19 Aug 2003 15:42:53 +0000 (UTC) Date: Tue, 19 Aug 2003 12:42:53 -0300 From: Arnaldo Carvalho de Melo To: Tommi Virtanen Cc: "David S. Miller" , hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: [PATCH] Change MAC without bringing interface down Message-ID: <20030819154252.GA935@conectiva.com.br> References: <20030818171144.GC1793@lapdog> <20030818185153.GA1559@conectiva.com.br> <20030819055034.GA809@lapdog> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030819055034.GA809@lapdog> X-Url: http://advogato.org/person/acme Organization: Conectiva S.A. User-Agent: Mutt/1.5.4i X-archive-position: 5023 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 Tue, Aug 19, 2003 at 08:50:34AM +0300, Tommi Virtanen escreveu: > Here's an updated patch with those nits picked. Those were > all cut-and-pasted from elsewhere, so if you want perfection, > there's lots of those to fix. Thank you. And yes, I wish there was a consistent style, and have been fixing these kinds of nits for years :-) - Arnaldo From davem@redhat.com Tue Aug 19 08:44:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 08:44: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 h7JFisFl031194 for ; Tue, 19 Aug 2003 08:44:54 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id IAA09801; Tue, 19 Aug 2003 08:36:22 -0700 Date: Tue, 19 Aug 2003 08:36:21 -0700 From: "David S. Miller" To: Ville Nuorvala Cc: shemminger@osdl.org, greg@kroah.com, netdev@oss.sgi.com Subject: Re: dev/core/net_sysfs.c: missing release() function in net_class Message-Id: <20030819083621.2ae4abc8.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5024 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 19 Aug 2003 15:47:03 +0300 (EEST) Ville Nuorvala wrote: > lately I've been getting a nasty looking warning from class_dev_release() > in drivers/base/class.c when I unregister my ip6_tunnel devices. This is fixed in current sources after recent changes done by Stephen Hemminger. From davem@redhat.com Tue Aug 19 08:45:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 08:45: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 h7JFj0Fl031207 for ; Tue, 19 Aug 2003 08:45:02 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id IAA09793; Tue, 19 Aug 2003 08:34:39 -0700 Date: Tue, 19 Aug 2003 08:34:38 -0700 From: "David S. Miller" To: "Bas Bloemsaat" Cc: richard@aspectgroup.co.uk, skraw@ithnet.com, willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030819083438.26c985b9.davem@redhat.com> In-Reply-To: <070c01c36653$7f3c1ab0$c801a8c0@llewella> References: <353568DCBAE06148B70767C1B1A93E625EAB57@post.pc.aspectgroup.co.uk> <070c01c36653$7f3c1ab0$c801a8c0@llewella> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5025 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 19 Aug 2003 15:11:59 +0200 "Bas Bloemsaat" wrote: > It it doesn't define a standard either, but makes > perfectly clear that any interface has it's own ARP, > not one ARP for the entire system. This is absolutely not true. There are two valid ways the RFCs allow systems to handle IP addresses. 1) IP addresses are owned by "the host" 2) IP addresses are owned by "the interface" Linux does #1, many systems do #2, both are correct. We provide ways for you to obtain the behavior or #2 so there is nothing to complain about. From davidsen@tmr.com Tue Aug 19 09:02:58 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 09:03:05 -0700 (PDT) Received: from gatekeeper.tmr.com (tmr-02.dsl.thebiz.net [216.238.38.204]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JG2sFl032003 for ; Tue, 19 Aug 2003 09:02:57 -0700 Received: from localhost (davidsen@localhost) by gatekeeper.tmr.com (8.9.0/8.9.0) with SMTP id LAA07199; Tue, 19 Aug 2003 11:53:29 -0400 Date: Tue, 19 Aug 2003 11:53:29 -0400 (EDT) From: Bill Davidsen To: Willy Tarreau cc: Richard Underwood , "'Alan Cox'" , "'David S. Miller'" , Stephan von Krawczynski , carlosev@newipnet.com, lamont@scriptkiddie.org, bloemsaa@xs4all.nl, Marcelo Tosatti , netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, Linux Kernel Mailing List Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices In-Reply-To: <20030819145403.GA3407@alpha.home.local> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5026 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davidsen@tmr.com Precedence: bulk X-list: netdev On Tue, 19 Aug 2003, Willy Tarreau wrote: > Hello, > > On Tue, Aug 19, 2003 at 03:34:43PM +0100, Richard Underwood wrote: > > Now, since 172.24.0.80 is a Linux box, it's happily adding > > 172.20.240.2 into its ARP table and reply to it, hence the reply. > > > > But if I was to do this in the other direction (arp -d 172.20.240.1; > > ping -I 172.24.0.1 172.20.240.1) then I'd lose connectivity over my default > > route because 172.20.240.1 won't accept ARP packets from IP numbers not on > > the connected subnet. The ARP entry will block any further ARP > > requests from valid IP numbers. > > This is exactly the case I calmly discussed privately with David then Alexey. > Both explained me that in fact, the remote host shouldn't be filtering the ARP > requests based on the source IP they provide, but agreed that it seems to be a > general trend today. Alexey proposed a slight change which can at least solve > this very common case by preventing the system from using the local address as > a source IP if it is not on the interface through which the request is sent. > > Obviously it will not solve all very special cases, which people can work > around with arptables, but it will solve this common one. I wonder if a change to add a flag preventing *any* packet from being sent on a NIC which doesn't have the proper source address would be politically acceptable. I did that type of patch for 2.4.16 to prevent killing routers by having the MAC change for an IP. It will hurt performance on at least some routers, and the patch eliminated the problem. I later changed to using source routing, since the number of IPs was modest and didn't change, but I am still fighting the issue in a test environment, where the number of IPs is high and I can't just grab a range in some cases. -- bill davidsen CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. From davem@redhat.com Tue Aug 19 09:04:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 09:04:45 -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 h7JG4fFl032279 for ; Tue, 19 Aug 2003 09:04:41 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id IAA09994; Tue, 19 Aug 2003 08:57:18 -0700 Date: Tue, 19 Aug 2003 08:57:17 -0700 From: "David S. Miller" To: Stephan von Krawczynski Cc: willy@w.ods.org, richard@aspectgroup.co.uk, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030819085717.56046afd.davem@redhat.com> In-Reply-To: <20030819170751.2b92ba2e.skraw@ithnet.com> References: <353568DCBAE06148B70767C1B1A93E625EAB58@post.pc.aspectgroup.co.uk> <20030819145403.GA3407@alpha.home.local> <20030819170751.2b92ba2e.skraw@ithnet.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5027 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 19 Aug 2003 17:07:51 +0200 Stephan von Krawczynski wrote: > Hm, what rule is broken by the remote host, then? It means that systems (like Linux) that make IP addresses owned by the host instead of specific interfaces cannot correctly interoperate with such remote systems. It is also the case that a host cannot possibly be aware of all subnets present on a given LAN, therefore is should be liberal in it's replies to ARP requests. Finally, it violates the most basic rule of IP networking: "Be liberal in what you accept, and conservative in what you send" -Jon Postel In general, when a host posses the information necessary to allow other hosts to communicate, it should provide that information whenever possible. From skraw@ithnet.com Tue Aug 19 09:19:38 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 09:19:44 -0700 (PDT) Received: from heather-ng.ithnet.com (mail3.ithnet.com [217.64.64.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JGJHFl000751 for ; Tue, 19 Aug 2003 09:19:38 -0700 Received: (qmail 32159 invoked by uid 0); 19 Aug 2003 16:19:16 -0000 Received: from skraw@ithnet.com by heather-ng (Processed in 0.358082 secs); 19 Aug 2003 16:19:16 -0000 X-Virus-Status: No Received: from unknown (HELO ithnet.com) (217.64.64.14) by heather-ng.ithnet.com with SMTP; 19 Aug 2003 16:19:15 -0000 X-Sender-Authentication: SMTPafterPOP by from 217.64.64.14 Date: Tue, 19 Aug 2003 18:19:16 +0200 From: Stephan von Krawczynski To: "Bas Bloemsaat" Cc: richard@aspectgroup.co.uk, davem@redhat.com, willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030819181916.4e636495.skraw@ithnet.com> In-Reply-To: <070c01c36653$7f3c1ab0$c801a8c0@llewella> References: <353568DCBAE06148B70767C1B1A93E625EAB57@post.pc.aspectgroup.co.uk> <070c01c36653$7f3c1ab0$c801a8c0@llewella> Organization: ith Kommunikationstechnik GmbH X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5028 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: skraw@ithnet.com Precedence: bulk X-list: netdev On Tue, 19 Aug 2003 15:11:59 +0200 "Bas Bloemsaat" wrote: > > The RFC I quoted (985) says the ARP packets generated by Linux > > should be dropped. Sure, the RFC isn't a standard, but there ARE plenty of > > implementations that obey it for perfectly valid security reasons. > Same goes for 1180. It it doesn't define a standard either, but makes > perfectly clear that any interface has it's own ARP, not one ARP for the > entire system. Does "has its own ARP" mean "has its own ARP-table"? I just want to understand you correctly. Regards, Stephan From davem@redhat.com Tue Aug 19 09:21:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 09:21:38 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JGLXFl001113 for ; Tue, 19 Aug 2003 09:21:33 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id JAA10122; Tue, 19 Aug 2003 09:14:15 -0700 Date: Tue, 19 Aug 2003 09:14:14 -0700 From: "David S. Miller" To: Bill Davidsen Cc: willy@w.ods.org, richard@aspectgroup.co.uk, alan@lxorguk.ukuu.org.uk, skraw@ithnet.com, carlosev@newipnet.com, lamont@scriptkiddie.org, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030819091414.512d80c4.davem@redhat.com> In-Reply-To: References: <20030819145403.GA3407@alpha.home.local> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5029 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 19 Aug 2003 11:53:29 -0400 (EDT) Bill Davidsen wrote: > I wonder if a change to add a flag preventing *any* packet from being sent > on a NIC which doesn't have the proper source address would be politically > acceptable. This would disable things like MSG_DONTROUTE and many valid uses of RAW sockets. From skraw@ithnet.com Tue Aug 19 09:52:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 09:52:29 -0700 (PDT) Received: from heather-ng.ithnet.com (mail3.ithnet.com [217.64.64.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JGqLFl001692 for ; Tue, 19 Aug 2003 09:52:22 -0700 Received: (qmail 2773 invoked by uid 0); 19 Aug 2003 16:52:20 -0000 Received: from skraw@ithnet.com by heather-ng (Processed in 0.533612 secs); 19 Aug 2003 16:52:20 -0000 X-Virus-Status: No Received: from unknown (HELO ithnet.com) (217.64.64.14) by heather-ng.ithnet.com with SMTP; 19 Aug 2003 16:52:19 -0000 X-Sender-Authentication: SMTPafterPOP by from 217.64.64.14 Date: Tue, 19 Aug 2003 18:52:19 +0200 From: Stephan von Krawczynski To: "David S. Miller" Cc: willy@w.ods.org, richard@aspectgroup.co.uk, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030819185219.116fd259.skraw@ithnet.com> In-Reply-To: <20030819085717.56046afd.davem@redhat.com> References: <353568DCBAE06148B70767C1B1A93E625EAB58@post.pc.aspectgroup.co.uk> <20030819145403.GA3407@alpha.home.local> <20030819170751.2b92ba2e.skraw@ithnet.com> <20030819085717.56046afd.davem@redhat.com> Organization: ith Kommunikationstechnik GmbH X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5030 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: skraw@ithnet.com Precedence: bulk X-list: netdev On Tue, 19 Aug 2003 08:57:17 -0700 "David S. Miller" wrote: > On Tue, 19 Aug 2003 17:07:51 +0200 > Stephan von Krawczynski wrote: > > > Hm, what rule is broken by the remote host, then? > > It means that systems (like Linux) that make IP addresses owned by the > host instead of specific interfaces cannot correctly interoperate with > such remote systems. > > It is also the case that a host cannot possibly be aware of all > subnets present on a given LAN, therefore is should be liberal in it's > replies to ARP requests. > > Finally, it violates the most basic rule of IP networking: > > "Be liberal in what you accept, and conservative in what you send" > -Jon Postel If I understood what Richard said in this thread Jon just shot you down. The conservative way to _request_ arp would definitely be to request it from the "correct" subnet, because as a sender you ought to give credit to knowing that "bad" boxes out there won't answer if you do otherwise. There can be no doubt what "conservative" means here. Additionally, the remote box is not really bad behaving: A.3. ARP datagram An ARP reply is discarded if the destination IP address does not match the local host address. An ARP request is discarded if the source IP address is not in the same subnet. It is desirable that this test be overridden by a configuration parameter, in order to support the infrequent cases where more than one subnet may coexist on the same cable (see RFC-925 for examples). This means the remote box is completely ok if not answering to a request with source ip from another subnet. So from what I read here requesting arp should really only happen with a source ip from the same subnet. Regards, Stephan From richard@aspectgroup.co.uk Tue Aug 19 09:54:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 09:54:52 -0700 (PDT) Received: from letters.pc.aspectgroup.co.uk (granite.aspectgroup.co.uk [212.187.249.254]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JGsRFl002029 for ; Tue, 19 Aug 2003 09:54:48 -0700 Received: by letters.pc.aspectgroup.co.uk with Internet Mail Service (5.5.2656.59) id ; Tue, 19 Aug 2003 17:54:26 +0100 Message-ID: <353568DCBAE06148B70767C1B1A93E625EAB5B@post.pc.aspectgroup.co.uk> From: Richard Underwood To: "'David S. Miller'" , Stephan von Krawczynski Cc: willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: RE: [2.4 PATCH] bugfix: ARP respond on all devices Date: Tue, 19 Aug 2003 17:54:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-archive-position: 5031 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: richard@aspectgroup.co.uk Precedence: bulk X-list: netdev David S. Miller wrote: > > It means that systems (like Linux) that make IP addresses owned by the > host instead of specific interfaces cannot correctly interoperate with > such remote systems. > This makes sense for replies, but not for requests. When a HOST sends out an ARP request, it's NOT associated with a single connection, it's associated with the host. Why should it pick a "random" IP number to send as the source address? The way the network code is currently, you're reducing your connectivity to chance. There should be a defined process for making a connection to another host. As it stands, this process is simply not predictable. If you insist that an ARP request IS directly associated with a connection, then you are required to have one ARP cache per source IP address. It'd be predictable again ... but I don't think anyone wants to go there. > It is also the case that a host cannot possibly be aware of all > subnets present on a given LAN, therefore is should be liberal in it's > replies to ARP requests. > Well, actually, I know exactly which IP subnets are on which LAN segments - they're defined by the IP address and subnet of the interface. I think you'll find that this a pretty basic feature of most hosts. > Finally, it violates the most basic rule of IP networking: > > "Be liberal in what you accept, and conservative in what you send" > -Jon Postel > I'm sorry, but Linux simply isn't being conservative in what it sends. It's being bloody awkward. Look at it this way - when a host sends out an ARP request, it WANTS a reply, it's not doing it for fun. If it uses the IP number of the interface it's sending the ARP request on, it will ALWAYS get a reply (assuming there's one to get.) If it uses the IP number of another interface, it MAY get a reply, but it MAY NOT. Are there any cases when this is reversed? I don't think so! Linux is being intentionally difficult, and as far as I can tell, for no good reason. > In general, when a host posses the information necessary to allow > other hosts to communicate, it should provide that information > whenever possible. > No, it should follow the rules for letting traffic pass through it. Just because a host can see two networks, doesn't mean it should route between them - it possesses information, but there have to be rules to determine how this information is used. Compare it to IP: If a firewall sees a packet come in on an interface it shouldn't, it'll probably drop it - it's called anti-spoofing. Should the firewall forward the packet on just because it can? So at the lower layer, a router sees an ARP packet with what looks like a "spoofed" source address. Should it trust it implicitly and place it in its cache, or should it drop it? No one yet has given one single example of a network that relies on Linux's current behaviour. I've given two examples of networks that break because of it. I would kindly suggest that the default should be changed. Thanks, Richard From richard@aspectgroup.co.uk Tue Aug 19 09:55:10 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 09:55:13 -0700 (PDT) Received: from letters.pc.aspectgroup.co.uk (granite.aspectgroup.co.uk [212.187.249.254]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JGsnFl002050 for ; Tue, 19 Aug 2003 09:55:10 -0700 Received: by letters.pc.aspectgroup.co.uk with Internet Mail Service (5.5.2656.59) id ; Tue, 19 Aug 2003 13:02:22 +0100 Message-ID: <353568DCBAE06148B70767C1B1A93E625EAB57@post.pc.aspectgroup.co.uk> From: Richard Underwood To: "'David S. Miller'" , Stephan von Krawczynski Cc: willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: RE: [2.4 PATCH] bugfix: ARP respond on all devices Date: Tue, 19 Aug 2003 13:02:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-archive-position: 5032 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: richard@aspectgroup.co.uk Precedence: bulk X-list: netdev David S. Miller wrote: > > > _And_ you did not explain so far why these implementations should > > not be RFC-conform or else illegal. > > Both responding and not responding on all interfaces for ARPs > is RFC conformant. This means both Linux and other systems > are within the rules. > Firstly, can I point out that you have consistently talked about REPLIES when everyone else has been talking about REQUESTS. I suspect that this may be confusing more people than you realise. The RFC I quoted (985) says the ARP packets generated by Linux should be dropped. Sure, the RFC isn't a standard, but there ARE plenty of implementations that obey it for perfectly valid security reasons. > Under Linux, by default, IP addresses are owned by the system > not by interfaces. This increases the likelyhood of successful > communication on a subnet. > This is crap. ARP is local to a broadcast net. The ARP standard explicitly prohibits responding to an ARP request on a different interface. If you broadcast a request asking for a reply on an entirely different subnet, you're asking for trouble. You REDUCE the likelyhood of a successful ARP reply, not increase it. All you can possibly achieve by sending REQUESTS from the wrong IP number is assist screwed up networks where you've got multiple subnets on the same copper and cause a shed-load of security issues. > For scenerios where this doesn't work, we have ways to make the > kernel behave the way you want it to. > There are many ways of "fixing" it. I've chosen a static ARP entry for my next-hop. I really don't care. The issue is that the Linux ARP code is, apparently by design, flawed. > There is no discussion about changing the default, because that > might break things for some people. So this discussion is pretty > useless. Can you give one good example where this is the case? What makes all this worse is that once an ARP request has been queued using the wrong IP number, further connections that would otherwise have generated a valid ARP request will be blocked as Linux won't queue a second request - despite it coming from a different IP number. This means that connectivity is non-deterministic, and while everything may work for 99.9% of the time, when an ARP entry gets deleted and the next ARP request comes from the wrong IP number you lose connectivity. I wonder how many unsolved random network problems there have been due to this. "Just reboot it, it'll work again." Great! If you insist on leaving the code as it is, at the very least allow multiple incomplete ARP requests, one per source IP. Thanks, Richard From davem@redhat.com Tue Aug 19 09:58:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 09:58:43 -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 h7JGwZFl002727 for ; Tue, 19 Aug 2003 09:58:39 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id JAA10403; Tue, 19 Aug 2003 09:51:05 -0700 Date: Tue, 19 Aug 2003 09:51:05 -0700 From: "David S. Miller" To: Richard Underwood Cc: skraw@ithnet.com, willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030819095105.2cb9acc1.davem@redhat.com> In-Reply-To: <353568DCBAE06148B70767C1B1A93E625EAB5B@post.pc.aspectgroup.co.uk> References: <353568DCBAE06148B70767C1B1A93E625EAB5B@post.pc.aspectgroup.co.uk> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5033 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 19 Aug 2003 17:54:26 +0100 Richard Underwood wrote: > When a HOST sends out an ARP request, it's NOT associated with a > single connection, it's associated with the host. Why should it pick a > "random" IP number to send as the source address? It's not "random", it is using the IP address it intends to use as the source in packets it will output once the ARP completes. In fact, if you look at the code in arp_solicit(), the source address is coming directly from the packet we are trying to output. From davem@redhat.com Tue Aug 19 10:00:43 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 10:00:47 -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 h7JH0eFl003109 for ; Tue, 19 Aug 2003 10:00:43 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id JAA10431; Tue, 19 Aug 2003 09:53:02 -0700 Date: Tue, 19 Aug 2003 09:53:02 -0700 From: "David S. Miller" To: Stephan von Krawczynski Cc: willy@w.ods.org, richard@aspectgroup.co.uk, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030819095302.7213ddd5.davem@redhat.com> In-Reply-To: <20030819185219.116fd259.skraw@ithnet.com> References: <353568DCBAE06148B70767C1B1A93E625EAB58@post.pc.aspectgroup.co.uk> <20030819145403.GA3407@alpha.home.local> <20030819170751.2b92ba2e.skraw@ithnet.com> <20030819085717.56046afd.davem@redhat.com> <20030819185219.116fd259.skraw@ithnet.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5034 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 19 Aug 2003 18:52:19 +0200 Stephan von Krawczynski wrote: > On Tue, 19 Aug 2003 08:57:17 -0700 > "David S. Miller" wrote: > > > "Be liberal in what you accept, and conservative in what you send" > > -Jon Postel > > If I understood what Richard said in this thread Jon just shot you > down. The conservative way to _request_ arp would definitely be to > request it from the "correct" subnet, because as a sender you ought > to give credit to knowing that "bad" boxes out there won't answer if > you do otherwise. In the ARP request we are using the source address in the packet we are building for output. If ARP doesn't work using that source address, we can only assume IP communication is not possible either. It is the box not responding to this ARP which is preventing communication not the box creating the ARP request. From davem@redhat.com Tue Aug 19 10:02:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 10:02:39 -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 h7JH2UFl003439 for ; Tue, 19 Aug 2003 10:02:36 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id JAA10454; Tue, 19 Aug 2003 09:54:54 -0700 Date: Tue, 19 Aug 2003 09:54:54 -0700 From: "David S. Miller" To: "Bas Bloemsaat" Cc: richard@aspectgroup.co.uk, skraw@ithnet.com, willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030819095454.4935d48f.davem@redhat.com> In-Reply-To: <070c01c36653$7f3c1ab0$c801a8c0@llewella> References: <353568DCBAE06148B70767C1B1A93E625EAB57@post.pc.aspectgroup.co.uk> <070c01c36653$7f3c1ab0$c801a8c0@llewella> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5035 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 19 Aug 2003 15:11:59 +0200 "Bas Bloemsaat" wrote: > > The RFC I quoted (985) says the ARP packets generated by Linux > > should be dropped. Sure, the RFC isn't a standard, but there ARE plenty of > > implementations that obey it for perfectly valid security reasons. > > Same goes for 1180. It it doesn't define a standard either, but makes > perfectly clear that any interface has it's own ARP, not one ARP for the > entire system. Which is all irrelevant because the IPv4 RFCs say that host based and interface based address ownership are both valid system models. Any document saying that they must be per-interface is therefore invalid. From davem@redhat.com Tue Aug 19 10:04:07 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 10:04:09 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JH3kFl003760 for ; Tue, 19 Aug 2003 10:04:06 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id JAA10488; Tue, 19 Aug 2003 09:56:12 -0700 Date: Tue, 19 Aug 2003 09:56:11 -0700 From: "David S. Miller" To: Richard Underwood Cc: skraw@ithnet.com, willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030819095611.0fb8f9a3.davem@redhat.com> In-Reply-To: <353568DCBAE06148B70767C1B1A93E625EAB57@post.pc.aspectgroup.co.uk> References: <353568DCBAE06148B70767C1B1A93E625EAB57@post.pc.aspectgroup.co.uk> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5036 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 19 Aug 2003 13:02:20 +0100 Richard Underwood wrote: > David S. Miller wrote: > > Under Linux, by default, IP addresses are owned by the system > > not by interfaces. This increases the likelyhood of successful > > communication on a subnet. > > > This is crap. Nope, the RFCs allow this. So this is where we must agree to disagree. Because host ownership of IP addresses is the basis for all of the arguments and it completely justifies Linux's ARP behavior on both sides. From skraw@ithnet.com Tue Aug 19 10:10:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 10:10:19 -0700 (PDT) Received: from heather-ng.ithnet.com (mail3.ithnet.com [217.64.64.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JHACFl004175 for ; Tue, 19 Aug 2003 10:10:13 -0700 Received: (qmail 4202 invoked by uid 0); 19 Aug 2003 17:10:11 -0000 Received: from skraw@ithnet.com by heather-ng (Processed in 0.449173 secs); 19 Aug 2003 17:10:11 -0000 X-Virus-Status: No Received: from unknown (HELO ithnet.com) (217.64.64.14) by heather-ng.ithnet.com with SMTP; 19 Aug 2003 17:10:10 -0000 X-Sender-Authentication: SMTPafterPOP by from 217.64.64.14 Date: Tue, 19 Aug 2003 19:10:10 +0200 From: Stephan von Krawczynski To: "David S. Miller" Cc: richard@aspectgroup.co.uk, willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030819191010.43d83b79.skraw@ithnet.com> In-Reply-To: <20030819095105.2cb9acc1.davem@redhat.com> References: <353568DCBAE06148B70767C1B1A93E625EAB5B@post.pc.aspectgroup.co.uk> <20030819095105.2cb9acc1.davem@redhat.com> Organization: ith Kommunikationstechnik GmbH X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5037 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: skraw@ithnet.com Precedence: bulk X-list: netdev On Tue, 19 Aug 2003 09:51:05 -0700 "David S. Miller" wrote: > On Tue, 19 Aug 2003 17:54:26 +0100 > Richard Underwood wrote: > > > When a HOST sends out an ARP request, it's NOT associated with a > > single connection, it's associated with the host. Why should it pick a > > "random" IP number to send as the source address? > > It's not "random", it is using the IP address it intends > to use as the source in packets it will output once the > ARP completes. > > In fact, if you look at the code in arp_solicit(), the source address > is coming directly from the packet we are trying to output. Well, then you have a problem, at least with RFC-985 as quoted in my other email. If your host has two interfaces on two different pyhsical nets and host A from net A shall be contacted by a service bound to your interface on net B you will obviously send an arp request with a source ip from wrong subnet. I did not read the code, I take your code explanation as true, of course. It is very likely you will not receive a valid answer in this case: An ARP request is discarded if the source IP address is not in the same subnet. Regards, Stephan From skraw@ithnet.com Tue Aug 19 10:12:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 10:12:54 -0700 (PDT) Received: from heather-ng.ithnet.com (mail3.ithnet.com [217.64.64.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JHCmFl004499 for ; Tue, 19 Aug 2003 10:12:49 -0700 Received: (qmail 4376 invoked by uid 0); 19 Aug 2003 17:12:47 -0000 Received: from skraw@ithnet.com by heather-ng (Processed in 0.41133 secs); 19 Aug 2003 17:12:47 -0000 X-Virus-Status: No Received: from unknown (HELO ithnet.com) (217.64.64.14) by heather-ng.ithnet.com with SMTP; 19 Aug 2003 17:12:46 -0000 X-Sender-Authentication: SMTPafterPOP by from 217.64.64.14 Date: Tue, 19 Aug 2003 19:12:46 +0200 From: Stephan von Krawczynski To: "David S. Miller" Cc: willy@w.ods.org, richard@aspectgroup.co.uk, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030819191246.027061dd.skraw@ithnet.com> In-Reply-To: <20030819095302.7213ddd5.davem@redhat.com> References: <353568DCBAE06148B70767C1B1A93E625EAB58@post.pc.aspectgroup.co.uk> <20030819145403.GA3407@alpha.home.local> <20030819170751.2b92ba2e.skraw@ithnet.com> <20030819085717.56046afd.davem@redhat.com> <20030819185219.116fd259.skraw@ithnet.com> <20030819095302.7213ddd5.davem@redhat.com> Organization: ith Kommunikationstechnik GmbH X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5038 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: skraw@ithnet.com Precedence: bulk X-list: netdev On Tue, 19 Aug 2003 09:53:02 -0700 "David S. Miller" wrote: > On Tue, 19 Aug 2003 18:52:19 +0200 > Stephan von Krawczynski wrote: > > > On Tue, 19 Aug 2003 08:57:17 -0700 > > "David S. Miller" wrote: > > > > > "Be liberal in what you accept, and conservative in what you send" > > > -Jon Postel > > > > If I understood what Richard said in this thread Jon just shot you > > down. The conservative way to _request_ arp would definitely be to > > request it from the "correct" subnet, because as a sender you ought > > to give credit to knowing that "bad" boxes out there won't answer if > > you do otherwise. > > In the ARP request we are using the source address in the packet we > are building for output. > > If ARP doesn't work using that source address, we can only assume IP > communication is not possible either. > > It is the box not responding to this ARP which is preventing > communication not the box creating the ARP request. Please read my example from other email. Very simple to prove you wrong here. Regards, Stephan From davem@redhat.com Tue Aug 19 10:14:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 10:14:54 -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 h7JHEoFl004829 for ; Tue, 19 Aug 2003 10:14:50 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id KAA10582; Tue, 19 Aug 2003 10:07:13 -0700 Date: Tue, 19 Aug 2003 10:07:12 -0700 From: "David S. Miller" To: Stephan von Krawczynski Cc: richard@aspectgroup.co.uk, willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030819100712.2470d18d.davem@redhat.com> In-Reply-To: <20030819191010.43d83b79.skraw@ithnet.com> References: <353568DCBAE06148B70767C1B1A93E625EAB5B@post.pc.aspectgroup.co.uk> <20030819095105.2cb9acc1.davem@redhat.com> <20030819191010.43d83b79.skraw@ithnet.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5039 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 19 Aug 2003 19:10:10 +0200 Stephan von Krawczynski wrote: > Well, then you have a problem, at least with RFC-985 as quoted in my other > email. RFC-985 does not take into consideration a system model where IP addresses are owned by the host not specific interfaces which is a valid system model that the RFC standards allow. > > An ARP request is discarded if the source IP address is not in the same subnet. > This RFC is broken in an environment consistent of systems using the host address ownership model. It also doesn't consider cases where the host receiving the ARP request is not aware of all subnets present on a LAN. Ignoring such ARPs is therefore broken and prevents valid communications from occuring. Some systems implement this check to provide "pseudo security", but it isn't even that. From skraw@ithnet.com Tue Aug 19 10:15:13 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 10:15:16 -0700 (PDT) Received: from heather-ng.ithnet.com (mail3.ithnet.com [217.64.64.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JHFCFl004947 for ; Tue, 19 Aug 2003 10:15:13 -0700 Received: (qmail 4563 invoked by uid 0); 19 Aug 2003 17:15:11 -0000 Received: from skraw@ithnet.com by heather-ng (Processed in 0.17504 secs); 19 Aug 2003 17:15:11 -0000 X-Virus-Status: No Received: from unknown (HELO ithnet.com) (217.64.64.14) by heather-ng.ithnet.com with SMTP; 19 Aug 2003 17:15:11 -0000 X-Sender-Authentication: SMTPafterPOP by from 217.64.64.14 Date: Tue, 19 Aug 2003 19:15:10 +0200 From: Stephan von Krawczynski To: "David S. Miller" Cc: bloemsaa@xs4all.nl, richard@aspectgroup.co.uk, willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030819191510.427063fb.skraw@ithnet.com> In-Reply-To: <20030819095454.4935d48f.davem@redhat.com> References: <353568DCBAE06148B70767C1B1A93E625EAB57@post.pc.aspectgroup.co.uk> <070c01c36653$7f3c1ab0$c801a8c0@llewella> <20030819095454.4935d48f.davem@redhat.com> Organization: ith Kommunikationstechnik GmbH X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5040 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: skraw@ithnet.com Precedence: bulk X-list: netdev On Tue, 19 Aug 2003 09:54:54 -0700 "David S. Miller" wrote: > Which is all irrelevant because the IPv4 RFCs say that host > based and interface based address ownership are both valid > system models. Can you (for completeness) name (the number) or quote the RFC you are talking about. Regards, Stephan From davem@redhat.com Tue Aug 19 10:16:57 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 10:17:00 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JHGtFl005681 for ; Tue, 19 Aug 2003 10:16:56 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id KAA10616; Tue, 19 Aug 2003 10:09:30 -0700 Date: Tue, 19 Aug 2003 10:09:29 -0700 From: "David S. Miller" To: Stephan von Krawczynski Cc: willy@w.ods.org, richard@aspectgroup.co.uk, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030819100929.0bfefbb4.davem@redhat.com> In-Reply-To: <20030819191246.027061dd.skraw@ithnet.com> References: <353568DCBAE06148B70767C1B1A93E625EAB58@post.pc.aspectgroup.co.uk> <20030819145403.GA3407@alpha.home.local> <20030819170751.2b92ba2e.skraw@ithnet.com> <20030819085717.56046afd.davem@redhat.com> <20030819185219.116fd259.skraw@ithnet.com> <20030819095302.7213ddd5.davem@redhat.com> <20030819191246.027061dd.skraw@ithnet.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5041 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 19 Aug 2003 19:12:46 +0200 Stephan von Krawczynski wrote: > On Tue, 19 Aug 2003 09:53:02 -0700 > "David S. Miller" wrote: > > > In the ARP request we are using the source address in the packet we > > are building for output. > > > > If ARP doesn't work using that source address, we can only assume IP > > communication is not possible either. > > > > It is the box not responding to this ARP which is preventing > > communication not the box creating the ARP request. > > Please read my example from other email. Very simple to prove you wrong here. Not really, the RFC you keep quoting is broken in several regards: 1) It is non-functional in environments containing systems using the host ownership model for IP addresses which the RFC standards fully allow. 2) It does not consider the cases where a host is not completely aware of all subnets present on a given link. This is actually quite common. Dropping such ARP requests can only be done when the the host is aware of all subnets that exist, which is cannot be possibly true. From davidsen@tmr.com Tue Aug 19 10:27:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 10:27:20 -0700 (PDT) Received: from gatekeeper.tmr.com (tmr-02.dsl.thebiz.net [216.238.38.204]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JHQxFl006120 for ; Tue, 19 Aug 2003 10:27:17 -0700 Received: from localhost (davidsen@localhost) by gatekeeper.tmr.com (8.9.0/8.9.0) with SMTP id NAA07735; Tue, 19 Aug 2003 13:17:44 -0400 Date: Tue, 19 Aug 2003 13:17:44 -0400 (EDT) From: Bill Davidsen To: "David S. Miller" cc: willy@w.ods.org, richard@aspectgroup.co.uk, alan@lxorguk.ukuu.org.uk, skraw@ithnet.com, carlosev@newipnet.com, lamont@scriptkiddie.org, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices In-Reply-To: <20030819091414.512d80c4.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5042 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davidsen@tmr.com Precedence: bulk X-list: netdev On Tue, 19 Aug 2003, David S. Miller wrote: > On Tue, 19 Aug 2003 11:53:29 -0400 (EDT) > Bill Davidsen wrote: > > > I wonder if a change to add a flag preventing *any* packet from being sent > > on a NIC which doesn't have the proper source address would be politically > > acceptable. > > This would disable things like MSG_DONTROUTE and many valid > uses of RAW sockets. > Probably would, but since it's a flag people could use it or not. I did that via a patch and it didn't show any problems in a tcp/udp environment. I would assume that source routing would produce the same problem in some cases, would it not? And I bet that using rp_filter can break some things as well, so there is precedent for having capabilities which could impact some valid procedures. I appreciate your point (which I totally overlooked), but I don't see that we have avoided other capabilities which could cause problems if misconfigured. It is clearly the responsibility of the admin to do configuration, and this seems (based on my actual experience) to work in an environment where arp/tcp/udp are being used. Unless you have additional issues, I would suggest that there are good reasons to add this capability. - no more dangerous than source routing and much easier to use - saves much discussion and time - much better to have one change done properly than lots of half-assed patches I understand your objections to the hidden patch, I think the approach I suggest could be done at the proper level and would provide a standard way to solve a common problem. If this can be reasonably done I would think you would support it just to be able to say "use default_source_routing" when the hidden patch visits the next time ;-) -- bill davidsen CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. From davem@redhat.com Tue Aug 19 10:43:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 10:43: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 h7JHhqFl007153 for ; Tue, 19 Aug 2003 10:43:53 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id KAA10867; Tue, 19 Aug 2003 10:36:13 -0700 Date: Tue, 19 Aug 2003 10:36:13 -0700 From: "David S. Miller" To: Lars Marowsky-Bree Cc: bloemsaa@xs4all.nl, richard@aspectgroup.co.uk, skraw@ithnet.com, willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030819103613.4485e549.davem@redhat.com> In-Reply-To: <20030819173920.GA3301@marowsky-bree.de> References: <353568DCBAE06148B70767C1B1A93E625EAB57@post.pc.aspectgroup.co.uk> <070c01c36653$7f3c1ab0$c801a8c0@llewella> <20030819083438.26c985b9.davem@redhat.com> <20030819173920.GA3301@marowsky-bree.de> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5043 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 19 Aug 2003 19:39:20 +0200 Lars Marowsky-Bree wrote: > On 2003-08-19T08:34:38, > "David S. Miller" said: > > > There are two valid ways the RFCs allow systems to handle > > IP addresses. > > > > 1) IP addresses are owned by "the host" > > 2) IP addresses are owned by "the interface" > > > > Linux does #1, many systems do #2, both are correct. > > Yes, both are "correct" in the sense that the RFC allows this > interpretation. The _sensible_ interpretation for practical networking > however is #2, and the only persons who seem to believe differently are > those in charge of the Linux network code... And, as Alan said, we provide a way for one to obtain your networking religion of week. Changing the default is not an option, that would undoubtedly break things. From davem@redhat.com Tue Aug 19 11:00:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 11:00:38 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JI0ZFl007661 for ; Tue, 19 Aug 2003 11:00:35 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id KAA11006; Tue, 19 Aug 2003 10:53:07 -0700 Date: Tue, 19 Aug 2003 10:53:07 -0700 From: "David S. Miller" To: Richard Underwood Cc: skraw@ithnet.com, willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030819105307.0b0a6491.davem@redhat.com> In-Reply-To: <353568DCBAE06148B70767C1B1A93E625EAB5C@post.pc.aspectgroup.co.uk> References: <353568DCBAE06148B70767C1B1A93E625EAB5C@post.pc.aspectgroup.co.uk> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5044 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 19 Aug 2003 18:56:18 +0100 Richard Underwood wrote: > Which nicely sums up the bug, really. Ok, then how would you propose to be able to send packets out an interface _before_ we have addresses assigned to it? Linux allows that, and in fact it's a useful feature. Consider MSG_DONTROUTE as well. BTW, this ARP source address algorithm we use comes from ipv6, it would be instructive to go and see why they do things the way they do. From lmb@suse.de Tue Aug 19 11:20:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 11:20:41 -0700 (PDT) Received: from mx.in-addr.de (postfix@gate.in-addr.de [212.8.193.158]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JIKNFl010516 for ; Tue, 19 Aug 2003 11:20:26 -0700 Received: by mx.in-addr.de (mx.in-addr.de, from userid 10) id 7D43D158D; Tue, 19 Aug 2003 19:40:39 +0200 (CEST) Received: by hermes.in-addr.de (Postfix, from userid 500) id D54F9B8D; Tue, 19 Aug 2003 19:39:20 +0200 (CEST) Date: Tue, 19 Aug 2003 19:39:20 +0200 From: Lars Marowsky-Bree To: "David S. Miller" , Bas Bloemsaat Cc: richard@aspectgroup.co.uk, skraw@ithnet.com, willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-ID: <20030819173920.GA3301@marowsky-bree.de> References: <353568DCBAE06148B70767C1B1A93E625EAB57@post.pc.aspectgroup.co.uk> <070c01c36653$7f3c1ab0$c801a8c0@llewella> <20030819083438.26c985b9.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20030819083438.26c985b9.davem@redhat.com> User-Agent: Mutt/1.4i X-Ctuhulu: HASTUR X-archive-position: 5045 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lmb@suse.de Precedence: bulk X-list: netdev On 2003-08-19T08:34:38, "David S. Miller" said: > There are two valid ways the RFCs allow systems to handle > IP addresses. > > 1) IP addresses are owned by "the host" > 2) IP addresses are owned by "the interface" > > Linux does #1, many systems do #2, both are correct. Yes, both are "correct" in the sense that the RFC allows this interpretation. The _sensible_ interpretation for practical networking however is #2, and the only persons who seem to believe differently are those in charge of the Linux network code... Sincerely, Lars Marowsky-Brée -- High Availability & Clustering ever tried. ever failed. no matter. SuSE Labs try again. fail again. fail better. Research & Development, SuSE Linux AG -- Samuel Beckett From davem@redhat.com Tue Aug 19 11:21:51 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 11:21: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 h7JILbFl010688 for ; Tue, 19 Aug 2003 11:21:51 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id LAA11197; Tue, 19 Aug 2003 11:13:59 -0700 Date: Tue, 19 Aug 2003 11:13:58 -0700 From: "David S. Miller" To: Richard Underwood Cc: skraw@ithnet.com, willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030819111358.35ef1059.davem@redhat.com> In-Reply-To: <353568DCBAE06148B70767C1B1A93E625EAB5E@post.pc.aspectgroup.co.uk> References: <353568DCBAE06148B70767C1B1A93E625EAB5E@post.pc.aspectgroup.co.uk> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5046 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 19 Aug 2003 19:16:18 +0100 Richard Underwood wrote: > David S. Miller wrote: > > Ok, then how would you propose to be able to send > > packets out an interface _before_ we have addresses > > assigned to it? > > > IP packets you mean? You don't? ;) It would depend on why you're > doing it naturally. Mostly, I'd have thought that if a host doesn't have an > IP number it doesn't get to use ARP. Of course it gets to use ARP, nothing prevents this. If I know that IP X has my configuration information, I have every right to send X a packet from zero-net to ask for that information before I have any IP addresses attached to the interface. This is nothing wrong nor strange about this and we've supported it for years. Also, when one specifies a specific device in an output address and we cannot find the IP part of the address in the routing tables, we still procure a valid route for the requester. Besides normal IP addresses, multicast tools use these facilities. From davem@redhat.com Tue Aug 19 11:28:47 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 11:28:51 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JISRFl011332 for ; Tue, 19 Aug 2003 11:28:47 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id LAA11280; Tue, 19 Aug 2003 11:21:03 -0700 Date: Tue, 19 Aug 2003 11:21:03 -0700 From: "David S. Miller" To: Richard Underwood Cc: skraw@ithnet.com, willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030819112103.373fce27.davem@redhat.com> In-Reply-To: <353568DCBAE06148B70767C1B1A93E625EAB5D@post.pc.aspectgroup.co.uk> References: <353568DCBAE06148B70767C1B1A93E625EAB5D@post.pc.aspectgroup.co.uk> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5047 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 19 Aug 2003 19:05:13 +0100 Richard Underwood wrote: > The ARP request represents all FUTURE > packets being sent out that interface, not just the one single packet that > happened to kick of this ARP request. That's RIGHT! And by your own argument the source address in the ARP request IS IRRELEVANT and is to be ignored! Ok, I've lost 3 days of talking about ARP non-stop, I think I'll take a break from these threads for a while, it's getting to be a bit much. From dang@fprintf.net Tue Aug 19 11:30:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 11:30:54 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JIUTFl011687 for ; Tue, 19 Aug 2003 11:30:50 -0700 Received: (qmail 12006 invoked from network); 19 Aug 2003 18:30:27 -0000 Received: from bgp01080308bgs.wanarb01.mi.comcast.net (HELO apollo.fprintf.net) (68.40.145.213) by relay.pair.com with SMTP; 19 Aug 2003 18:30:27 -0000 X-pair-Authenticated: 68.40.145.213 Received: by apollo.fprintf.net (sSMTP sendmail emulation); Tue, 19 Aug 2003 14:30:27 -0400 Subject: RE: [2.4 PATCH] bugfix: ARP respond on all devices From: Daniel Gryniewicz To: Alan Cox Cc: Richard Underwood , "'David S. Miller'" , Stephan von Krawczynski , willy@w.ods.org, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, Marcelo Tosatti , netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, Linux Kernel Mailing List In-Reply-To: <1061296544.30566.8.camel@dhcp23.swansea.linux.org.uk> References: <353568DCBAE06148B70767C1B1A93E625EAB57@post.pc.aspectgroup.co.uk> <1061296544.30566.8.camel@dhcp23.swansea.linux.org.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1061317825.3744.7.camel@athena.fprintf.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 19 Aug 2003 14:30:26 -0400 X-archive-position: 5048 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dang@fprintf.net Precedence: bulk X-list: netdev On Tue, 2003-08-19 at 08:35, Alan Cox wrote: > You increase it and you shortcut on shared lans. Thats really a seperate > issue to the question of which source is used. If you loopback someone > elses address on your own lo device I'm not suprised weird shit happens, > put the alias on eth0 where it belongs. Only if you are on a shared lan. If you are not on a shared lan, then it will *ONLY* work if linux is on the other end. No other system will work. And, you don't need an alias on loopback. Merely changing the default route will result in this. Change default route from gw 1.1.1.1 on eth0 to gw 2.2.2.2 on eth1 (making sure that 2.2.2.2 doesn't have an arp entry), and linux will say, on eth1: whohas 2.2.2.2 tell 1.1.1.2 where 1.1.1.2 is the address on eth0. No one will respond to this, so all communication from beyond a directly connected network will now fail. -- Daniel Gryniewicz From bloemsaa@xs4all.nl Tue Aug 19 11:31:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 11:31:51 -0700 (PDT) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JIVRFl011804 for ; Tue, 19 Aug 2003 11:31:48 -0700 Received: from llewella (vialle.xs4all.nl [213.84.6.25]) by smtpzilla1.xs4all.nl (8.12.9/8.12.9) with SMTP id h7JIUjoB076703; Tue, 19 Aug 2003 20:31:00 +0200 (CEST) Message-ID: <089d01c36680$09c04b30$c801a8c0@llewella> From: "Bas Bloemsaat" To: "David S. Miller" , "Richard Underwood" Cc: , , , , , , , , , , , References: <353568DCBAE06148B70767C1B1A93E625EAB5E@post.pc.aspectgroup.co.uk> <20030819111358.35ef1059.davem@redhat.com> Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Date: Tue, 19 Aug 2003 20:30:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 5049 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bloemsaa@xs4all.nl Precedence: bulk X-list: netdev > > > Ok, then how would you propose to be able to send > > > packets out an interface _before_ we have addresses > > > assigned to it? > > > > > IP packets you mean? You don't? ;) It would depend on why you're > > doing it naturally. Mostly, I'd have thought that if a host doesn't have an > > IP number it doesn't get to use ARP. > > Of course it gets to use ARP, nothing prevents this. Huh? RFC 826 states that the requesting arp packet sends the protocol address of itself. So no address is no arp. Allowing it to is a violation of that rfc Regards, Bas From davem@redhat.com Tue Aug 19 11:37:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 11: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 h7JIagFl012362 for ; Tue, 19 Aug 2003 11:37:03 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id LAA11363; Tue, 19 Aug 2003 11:29:12 -0700 Date: Tue, 19 Aug 2003 11:29:12 -0700 From: "David S. Miller" To: Daniel Gryniewicz Cc: alan@lxorguk.ukuu.org.uk, richard@aspectgroup.co.uk, skraw@ithnet.com, willy@w.ods.org, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030819112912.359eaea6.davem@redhat.com> In-Reply-To: <1061317825.3744.7.camel@athena.fprintf.net> References: <353568DCBAE06148B70767C1B1A93E625EAB57@post.pc.aspectgroup.co.uk> <1061296544.30566.8.camel@dhcp23.swansea.linux.org.uk> <1061317825.3744.7.camel@athena.fprintf.net> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5050 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On 19 Aug 2003 14:30:26 -0400 Daniel Gryniewicz wrote: > If you are not on a shared lan, then it will *ONLY* work if linux is > on the other end. No other system will work. And these other systems are broken. (actually, older Cisco equipment correctly responds to the ARP regardless of source IP) Just because some Cisco engineer says that it is correct doesn't make it is. Consider the situation logically. When you're replying to an ARP, _HOW_ do you know what IP addresses are assigned to _MY_ outgoing interfaces and _HOW_ do you know what subnets _EXIST_ on the LAN? The answer to both is, you'd don't know these things _EVEN_ if you are a router/gateway. Therefore there is no valid reason not to respond to an ARP using one source address as opposed to another. From richard@aspectgroup.co.uk Tue Aug 19 12:01:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 12:01:19 -0700 (PDT) Received: from letters.pc.aspectgroup.co.uk (granite.aspectgroup.co.uk [212.187.249.254]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JJ0rFl015304 for ; Tue, 19 Aug 2003 12:01:14 -0700 Received: by letters.pc.aspectgroup.co.uk with Internet Mail Service (5.5.2656.59) id ; Tue, 19 Aug 2003 20:00:52 +0100 Message-ID: <353568DCBAE06148B70767C1B1A93E625EAB5F@post.pc.aspectgroup.co.uk> From: Richard Underwood To: "'David S. Miller'" Cc: skraw@ithnet.com, willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: RE: [2.4 PATCH] bugfix: ARP respond on all devices Date: Tue, 19 Aug 2003 20:00:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-archive-position: 5051 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: richard@aspectgroup.co.uk Precedence: bulk X-list: netdev David S. Miller wrote: > > IP packets you mean? You don't? ;) It would depend on why you're > > doing it naturally. Mostly, I'd have thought that if a host > doesn't have an > > IP number it doesn't get to use ARP. > > Of course it gets to use ARP, nothing prevents this. > > If I know that IP X has my configuration information, I > have every right to send X a packet from zero-net to > ask for that information before I have any IP addresses > attached to the interface. > Ick! And how is IP X going to get the information back? Broadcast it, too? Here was me thinking that protocols like BOOTP and DHCP were appropriate for this. If you are going to send from 0.0.0.0, then I assume there's something in the ARP standard to say "don't cache this ARP request" - I must have missed it. If so, that's a special case - no need to spoil things elsewhere, though. > Also, when one specifies a specific device in an output > address and we cannot find the IP part of the address > in the routing tables, we still procure a valid route for > the requester. > Well, what do you do currently? If the packet you're routeing came from another host, there's no way in hell you can use their IP address in an ARP request ... is there? I certainly hope you don't go that far!!! If it's a locally generated packet, then the next hop must be on the same subnet as the address it's coming from - there's your IP number. > Besides normal IP addresses, multicast tools use these > facilities. > Multicast uses ARP? That's news to me! Richard From alan@lxorguk.ukuu.org.uk Tue Aug 19 12:05:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 12:05:42 -0700 (PDT) Received: from dhcp23.swansea.linux.org.uk (pc1-cwma1-5-cust4.swan.cable.ntl.com [80.5.120.4]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JJ5FFl015668 for ; Tue, 19 Aug 2003 12:05:36 -0700 Received: from dhcp23.swansea.linux.org.uk (localhost.localdomain [127.0.0.1]) by dhcp23.swansea.linux.org.uk (8.12.9/8.12.9) with ESMTP id h7JJ4Vra031100; Tue, 19 Aug 2003 20:04:31 +0100 Received: (from alan@localhost) by dhcp23.swansea.linux.org.uk (8.12.9/8.12.9/Submit) id h7JJ4QWa031098; Tue, 19 Aug 2003 20:04:26 +0100 X-Authentication-Warning: dhcp23.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices From: Alan Cox To: Stephan von Krawczynski Cc: "David S. Miller" , willy@w.ods.org, richard@aspectgroup.co.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, Marcelo Tosatti , netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, Linux Kernel Mailing List In-Reply-To: <20030819185219.116fd259.skraw@ithnet.com> References: <353568DCBAE06148B70767C1B1A93E625EAB58@post.pc.aspectgroup.co.uk> <20030819145403.GA3407@alpha.home.local> <20030819170751.2b92ba2e.skraw@ithnet.com> <20030819085717.56046afd.davem@redhat.com> <20030819185219.116fd259.skraw@ithnet.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1061319864.30565.52.camel@dhcp23.swansea.linux.org.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 (1.4.3-3) Date: 19 Aug 2003 20:04:25 +0100 X-archive-position: 5052 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: netdev On Maw, 2003-08-19 at 17:52, Stephan von Krawczynski wrote: > Effectively Obsolete. > An ARP reply is discarded if the destination IP address does not > match the local host address. An ARP request is discarded if the The local host address. Singular. Back from the days where addresses lived by box From davem@redhat.com Tue Aug 19 12:06:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 12:06:33 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JJ68Fl015797 for ; Tue, 19 Aug 2003 12:06:29 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id LAA11581; Tue, 19 Aug 2003 11:58:46 -0700 Date: Tue, 19 Aug 2003 11:58:45 -0700 From: "David S. Miller" To: Richard Underwood Cc: skraw@ithnet.com, willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030819115845.4e968506.davem@redhat.com> In-Reply-To: <353568DCBAE06148B70767C1B1A93E625EAB5F@post.pc.aspectgroup.co.uk> References: <353568DCBAE06148B70767C1B1A93E625EAB5F@post.pc.aspectgroup.co.uk> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5053 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 19 Aug 2003 20:00:44 +0100 Richard Underwood wrote: > David S. Miller wrote: > > If I know that IP X has my configuration information, I > > have every right to send X a packet from zero-net to > > ask for that information before I have any IP addresses > > attached to the interface. > > > Ick! And how is IP X going to get the information back? It knows the MAC address of the intended receiver, there is no problem here. > If you are going to send from 0.0.0.0, then I assume there's > something in the ARP standard to say "don't cache this ARP request" - I must > have missed it. If so, that's a special case - no need to spoil things > elsewhere, though. What is the caching problem? The ARP response is valid, and we have no reason to believe otherwise. > Well, what do you do currently? If the packet you're routeing came > from another host, there's no way in hell you can use their IP address in an > ARP request ... is there? I certainly hope you don't go that far!!! We're not talking about routing scenerios, we're talking strictly about packets being originated by an application on the local host. > > Besides normal IP addresses, multicast tools use these > > facilities. > > > Multicast uses ARP? That's news to me! It uses routes that only have been determined only using the desired device index. There is no "interface address" to match up to when we're trying to send to a multicast address. From alan@lxorguk.ukuu.org.uk Tue Aug 19 12:09:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 12:09:06 -0700 (PDT) Received: from dhcp23.swansea.linux.org.uk (pc1-cwma1-5-cust4.swan.cable.ntl.com [80.5.120.4]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JJ90Fl017631 for ; Tue, 19 Aug 2003 12:09:01 -0700 Received: from dhcp23.swansea.linux.org.uk (localhost.localdomain [127.0.0.1]) by dhcp23.swansea.linux.org.uk (8.12.9/8.12.9) with ESMTP id h7JJ8Mra031108; Tue, 19 Aug 2003 20:08:22 +0100 Received: (from alan@localhost) by dhcp23.swansea.linux.org.uk (8.12.9/8.12.9/Submit) id h7JJ8Kjf031106; Tue, 19 Aug 2003 20:08:20 +0100 X-Authentication-Warning: dhcp23.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: RE: [2.4 PATCH] bugfix: ARP respond on all devices From: Alan Cox To: Richard Underwood Cc: "'David S. Miller'" , Stephan von Krawczynski , willy@w.ods.org, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, Marcelo Tosatti , netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, Linux Kernel Mailing List In-Reply-To: <353568DCBAE06148B70767C1B1A93E625EAB58@post.pc.aspectgroup.co.uk> References: <353568DCBAE06148B70767C1B1A93E625EAB58@post.pc.aspectgroup.co.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1061320099.30567.55.camel@dhcp23.swansea.linux.org.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 (1.4.3-3) Date: 19 Aug 2003 20:08:20 +0100 X-archive-position: 5054 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: netdev On Maw, 2003-08-19 at 15:34, Richard Underwood wrote: > # arp -d 172.24.0.80 > # ping -I 172.20.240.2 172.24.0.80 > > I see: > > 16:18:40.856328 arp who-has 172.24.0.80 tell 172.20.240.2 > 16:18:40.856431 arp reply 172.24.0.80 is-at 0:50:da:44:f:37 Fine > But if I was to do this in the other direction (arp -d 172.20.240.1; > ping -I 172.24.0.1 172.20.240.1) then I'd lose connectivity over my default > route because 172.20.240.1 won't accept ARP packets from IP numbers not on > the connected subnet. The ARP entry will block any further ARP > requests from valid IP numbers. One thing I agree with you about is that an ARP resolution for an address via one path should not block a resolution for it by another path since to begin with the two paths may be to different routers one of which is down. From davem@redhat.com Tue Aug 19 12:09:05 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 12:09:09 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JJ8oFl017628 for ; Tue, 19 Aug 2003 12:09:04 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id MAA11620; Tue, 19 Aug 2003 12:01:31 -0700 Date: Tue, 19 Aug 2003 12:01:31 -0700 From: "David S. Miller" To: Alan Cox Cc: skraw@ithnet.com, willy@w.ods.org, richard@aspectgroup.co.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030819120131.1999b1ec.davem@redhat.com> In-Reply-To: <1061319864.30565.52.camel@dhcp23.swansea.linux.org.uk> References: <353568DCBAE06148B70767C1B1A93E625EAB58@post.pc.aspectgroup.co.uk> <20030819145403.GA3407@alpha.home.local> <20030819170751.2b92ba2e.skraw@ithnet.com> <20030819085717.56046afd.davem@redhat.com> <20030819185219.116fd259.skraw@ithnet.com> <1061319864.30565.52.camel@dhcp23.swansea.linux.org.uk> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5055 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On 19 Aug 2003 20:04:25 +0100 Alan Cox wrote: > On Maw, 2003-08-19 at 17:52, Stephan von Krawczynski wrote: > > > > Effectively Obsolete. Indeed, would people stop quoting from RFC 985 and RFC 826. From dang@fprintf.net Tue Aug 19 12:12:47 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 12:12:51 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JJCkFl018305 for ; Tue, 19 Aug 2003 12:12:46 -0700 Received: (qmail 33962 invoked from network); 19 Aug 2003 19:12:45 -0000 Received: from bgp01080308bgs.wanarb01.mi.comcast.net (HELO apollo.fprintf.net) (68.40.145.213) by relay.pair.com with SMTP; 19 Aug 2003 19:12:45 -0000 X-pair-Authenticated: 68.40.145.213 Received: by apollo.fprintf.net (sSMTP sendmail emulation); Tue, 19 Aug 2003 15:12:44 -0400 Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices From: Daniel Gryniewicz To: "David S. Miller" Cc: alan@lxorguk.ukuu.org.uk, richard@aspectgroup.co.uk, skraw@ithnet.com, willy@w.ods.org, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org In-Reply-To: <20030819112912.359eaea6.davem@redhat.com> References: <353568DCBAE06148B70767C1B1A93E625EAB57@post.pc.aspectgroup.co.uk> <1061296544.30566.8.camel@dhcp23.swansea.linux.org.uk> <1061317825.3744.7.camel@athena.fprintf.net> <20030819112912.359eaea6.davem@redhat.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1061320363.3744.14.camel@athena.fprintf.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 19 Aug 2003 15:12:43 -0400 X-archive-position: 5056 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dang@fprintf.net Precedence: bulk X-list: netdev I realize that, but is that a reason to keep linux from working with these? (And it's not just cisco, all the *BSDs (and therefore anything that took the BSD stack such as MS) work this way too.) As nearly as I can tell, there's no way to make linux work with these, and the situation I gave is one where linux could easily get it right, and isn't. Saying "They're broken. Tough." is not really helpful. At least can we get a "work with broken other systems in certain circumstances" switch somewhere? (Funny you should mention Cisco, as we write routing software and must interoperate with Cisco. What Cisco says *does* go in the routing community, if you wish your product to be used. Currently, when our customers come to us, we have to say "Either don't use Linux or run 2.2 with the arp fix patch.") Daniel On Tue, 2003-08-19 at 14:29, David S. Miller wrote: > On 19 Aug 2003 14:30:26 -0400 > Daniel Gryniewicz wrote: > > > If you are not on a shared lan, then it will *ONLY* work if linux is > > on the other end. No other system will work. > > And these other systems are broken. (actually, older Cisco equipment > correctly responds to the ARP regardless of source IP) > > Just because some Cisco engineer says that it is correct doesn't > make it is. > > Consider the situation logically. When you're replying to an > ARP, _HOW_ do you know what IP addresses are assigned to _MY_ > outgoing interfaces and _HOW_ do you know what subnets _EXIST_ > on the LAN? > > The answer to both is, you'd don't know these things _EVEN_ if > you are a router/gateway. > > Therefore there is no valid reason not to respond to an ARP using one > source address as opposed to another. -- Daniel Gryniewicz From davem@redhat.com Tue Aug 19 12:17:30 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 12:17:35 -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 h7JJHUFl018666 for ; Tue, 19 Aug 2003 12:17:30 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id MAA11705; Tue, 19 Aug 2003 12:10:04 -0700 Date: Tue, 19 Aug 2003 12:10:03 -0700 From: "David S. Miller" To: Daniel Gryniewicz Cc: alan@lxorguk.ukuu.org.uk, richard@aspectgroup.co.uk, skraw@ithnet.com, willy@w.ods.org, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030819121003.7b5031c7.davem@redhat.com> In-Reply-To: <1061320363.3744.14.camel@athena.fprintf.net> References: <353568DCBAE06148B70767C1B1A93E625EAB57@post.pc.aspectgroup.co.uk> <1061296544.30566.8.camel@dhcp23.swansea.linux.org.uk> <1061317825.3744.7.camel@athena.fprintf.net> <20030819112912.359eaea6.davem@redhat.com> <1061320363.3744.14.camel@athena.fprintf.net> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5057 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On 19 Aug 2003 15:12:43 -0400 Daniel Gryniewicz wrote: > (And it's not just cisco, all the *BSDs (and therefore anything > that took the BSD stack such as MS) work this way too.) Not true. Microsoft systems do respond properly to these ARPs. From hadi@cyberus.ca Tue Aug 19 12:17:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 12:17:55 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JJHkFl018766 for ; Tue, 19 Aug 2003 12:17:50 -0700 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.12) id 19pByn-000OxG-00; Tue, 19 Aug 2003 15:17:17 -0400 Subject: Discussion fucking closed WAS(Re: [2.4 PATCH] bugfix: ARP respond on all devices From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: Daniel Gryniewicz , alan@lxorguk.ukuu.org.uk, richard@aspectgroup.co.uk, skraw@ithnet.com, willy@w.ods.org, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org In-Reply-To: <20030819112912.359eaea6.davem@redhat.com> References: <353568DCBAE06148B70767C1B1A93E625EAB57@post.pc.aspectgroup.co.uk> <1061296544.30566.8.camel@dhcp23.swansea.linux.org.uk> <1061317825.3744.7.camel@athena.fprintf.net> <20030819112912.359eaea6.davem@redhat.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1061320636.1029.16.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Aug 2003 15:17:16 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 5058 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1815 Lines: 48 Ok, go ahead and call my mama - tell her i used a bad word on a mailing list. Folks, this is a actually a republic model: in other words its a democracy upto a certain level then there maybe a veto. You have been provided a facility to go and do what funky thing that pleases you. Use ARPTABLEs; if you dont like it maintain your own patches - you have that freedom; dont enforce your freedom on someone actually doing the maintanace work - they have more important things to worry about. You can quote all the RFCs you want - it wont change anything soon. I got tired of following same cyclic arguements. What Linux is doing is conformant. What other people following CISCO are doing is also conformant. RFCs are written in an ambigous language called english. People actually (lately anyways) sneak in ambiguity to make their implementation look correct. So please stop quoting stoopid RFCs. cheers, jamal On Tue, 2003-08-19 at 14:29, David S. Miller wrote: > On 19 Aug 2003 14:30:26 -0400 > Daniel Gryniewicz wrote: > > > If you are not on a shared lan, then it will *ONLY* work if linux is > > on the other end. No other system will work. > > And these other systems are broken. (actually, older Cisco equipment > correctly responds to the ARP regardless of source IP) > > Just because some Cisco engineer says that it is correct doesn't > make it is. > > Consider the situation logically. When you're replying to an > ARP, _HOW_ do you know what IP addresses are assigned to _MY_ > outgoing interfaces and _HOW_ do you know what subnets _EXIST_ > on the LAN? > > The answer to both is, you'd don't know these things _EVEN_ if > you are a router/gateway. > > Therefore there is no valid reason not to respond to an ARP using one > source address as opposed to another. > > From bloemsaa@xs4all.nl Tue Aug 19 12:20:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 12:20:27 -0700 (PDT) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JJKMFl019356 for ; Tue, 19 Aug 2003 12:20:24 -0700 Received: from llewella (vialle.xs4all.nl [213.84.6.25]) by smtpzilla3.xs4all.nl (8.12.9/8.12.9) with SMTP id h7JJJhMR091568; Tue, 19 Aug 2003 21:19:47 +0200 (CEST) Message-ID: <091f01c36686$dade2bf0$c801a8c0@llewella> From: "Bas Bloemsaat" To: "David S. Miller" , "Alan Cox" Cc: , , , , , , , , , , , References: <353568DCBAE06148B70767C1B1A93E625EAB58@post.pc.aspectgroup.co.uk><20030819145403.GA3407@alpha.home.local><20030819170751.2b92ba2e.skraw@ithnet.com><20030819085717.56046afd.davem@redhat.com><20030819185219.116fd259.skraw@ithnet.com><1061319864.30565.52.camel@dhcp23.swansea.linux.org.uk> <20030819120131.1999b1ec.davem@redhat.com> Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Date: Tue, 19 Aug 2003 21:19:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 5059 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bloemsaa@xs4all.nl Precedence: bulk X-list: netdev Content-Length: 158 Lines: 7 > Indeed, would people stop quoting from RFC 985 and > RFC 826. RFC 826 is referenced from 1009 as describing ARP. So in effect it does define a standard. From davem@redhat.com Tue Aug 19 12:23:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 12:23: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 h7JJNqFl019715 for ; Tue, 19 Aug 2003 12:23:53 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id MAA11775; Tue, 19 Aug 2003 12:16:03 -0700 Date: Tue, 19 Aug 2003 12:16:03 -0700 From: "David S. Miller" To: "Bas Bloemsaat" Cc: alan@lxorguk.ukuu.org.uk, skraw@ithnet.com, willy@w.ods.org, richard@aspectgroup.co.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030819121603.1cc70937.davem@redhat.com> In-Reply-To: <091f01c36686$dade2bf0$c801a8c0@llewella> References: <353568DCBAE06148B70767C1B1A93E625EAB58@post.pc.aspectgroup.co.uk> <20030819145403.GA3407@alpha.home.local> <20030819170751.2b92ba2e.skraw@ithnet.com> <20030819085717.56046afd.davem@redhat.com> <20030819185219.116fd259.skraw@ithnet.com> <1061319864.30565.52.camel@dhcp23.swansea.linux.org.uk> <20030819120131.1999b1ec.davem@redhat.com> <091f01c36686$dade2bf0$c801a8c0@llewella> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5060 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 Content-Length: 649 Lines: 18 On Tue, 19 Aug 2003 21:19:44 +0200 "Bas Bloemsaat" wrote: > > Indeed, would people stop quoting from RFC 985 and > > RFC 826. > > RFC 826 is referenced from 1009 as describing ARP. So in effect it does > define a standard. The RFC 826 document clearly says, at the top, "This is not an Internet Standard" It does not define a standard. And given that it really isn't surprising it has errors in it as we've clearly shown in these threads. The authors of said document didn't scuritinize it to the level it would need to be in order to truly be a standards document people must follow to have a conformant implementation. From davem@redhat.com Tue Aug 19 12:38:56 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 12:38: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 h7JJctFl020103 for ; Tue, 19 Aug 2003 12:38:55 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id MAA11905; Tue, 19 Aug 2003 12:31:50 -0700 Date: Tue, 19 Aug 2003 12:31:50 -0700 From: "David S. Miller" To: Tommi Virtanen Cc: acme@conectiva.com.br, hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: [PATCH] Change MAC without bringing interface down Message-Id: <20030819123150.3d283130.davem@redhat.com> In-Reply-To: <20030819055034.GA809@lapdog> References: <20030818171144.GC1793@lapdog> <20030818185153.GA1559@conectiva.com.br> <20030819055034.GA809@lapdog> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5061 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 Content-Length: 285 Lines: 10 On Tue, 19 Aug 2003 08:50:34 +0300 Tommi Virtanen wrote: > Here's an updated patch with those nits picked. Those were > all cut-and-pasted from elsewhere, so if you want perfection, > there's lots of those to fix. This patch is fine, I will apply it. Thank you. From shemminger@osdl.org Tue Aug 19 12:47:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 12:47:44 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JJlYFl020472 for ; Tue, 19 Aug 2003 12:47:35 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7JJl5o25244; Tue, 19 Aug 2003 12:47:05 -0700 Date: Tue, 19 Aug 2003 12:37:56 -0700 From: Stephen Hemminger To: "David S. Miller" , Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] (3/9) freenetdev - drivers/net/* changes Message-Id: <20030819123756.25aec239.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7JJlYFl020472 X-archive-position: 5063 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 39501 Lines: 1315 Simple one line substitution of kfree with free_netdev for the bulk of the network drivers. diff -Nru a/drivers/net/3c509.c b/drivers/net/3c509.c --- a/drivers/net/3c509.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/3c509.c Tue Aug 19 12:33:10 2003 @@ -355,7 +355,7 @@ unregister_netdev (dev); release_region(dev->base_addr, EL3_IO_EXTENT); - kfree (dev); + free_netdev (dev); } static int __init el3_probe(int card_idx) diff -Nru a/drivers/net/3c515.c b/drivers/net/3c515.c --- a/drivers/net/3c515.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/3c515.c Tue Aug 19 12:33:10 2003 @@ -1676,7 +1676,7 @@ outw(TotalReset, root_corkscrew_dev->base_addr + EL3_CMD); release_region(root_corkscrew_dev->base_addr, CORKSCREW_TOTAL_SIZE); - kfree(root_corkscrew_dev); + free_netdev(root_corkscrew_dev); root_corkscrew_dev = next_dev; } } diff -Nru a/drivers/net/3c59x.c b/drivers/net/3c59x.c --- a/drivers/net/3c59x.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/3c59x.c Tue Aug 19 12:33:10 2003 @@ -1012,7 +1012,7 @@ outw (TotalReset|0x14, ioaddr + EL3_CMD); release_region (ioaddr, VORTEX_TOTAL_SIZE); - kfree (dev); + free_netdev (dev); return 0; } #endif @@ -3057,7 +3057,7 @@ vp->rx_ring_dma); if (vp->must_free_region) release_region(dev->base_addr, vp->io_size); - kfree(dev); + free_netdev(dev); } @@ -3111,7 +3111,7 @@ outw (TotalReset, ioaddr + EL3_CMD); release_region (ioaddr, VORTEX_TOTAL_SIZE); - kfree (compaq_net_device); + free_netdev (compaq_net_device); } } diff -Nru a/drivers/net/8139cp.c b/drivers/net/8139cp.c --- a/drivers/net/8139cp.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/8139cp.c Tue Aug 19 12:33:10 2003 @@ -1969,7 +1969,7 @@ pci_release_regions(pdev); pci_disable_device(pdev); pci_set_drvdata(pdev, NULL); - kfree(dev); + free_netdev(dev); } #ifdef CONFIG_PM diff -Nru a/drivers/net/8139too.c b/drivers/net/8139too.c --- a/drivers/net/8139too.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/8139too.c Tue Aug 19 12:33:10 2003 @@ -723,7 +723,7 @@ sizeof (struct rtl8139_private)); #endif /* RTL8139_NDEBUG */ - kfree (dev); + free_netdev(dev); pci_set_drvdata (pdev, NULL); } diff -Nru a/drivers/net/a2065.c b/drivers/net/a2065.c --- a/drivers/net/a2065.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/a2065.c Tue Aug 19 12:33:10 2003 @@ -820,7 +820,7 @@ release_mem_region(ZTWO_PADDR(dev->base_addr), sizeof(struct lance_regs)); release_mem_region(ZTWO_PADDR(dev->mem_start), A2065_RAM_SIZE); - kfree(dev); + free_netdev(dev); root_a2065_dev = next; } #endif diff -Nru a/drivers/net/acenic.c b/drivers/net/acenic.c --- a/drivers/net/acenic.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/acenic.c Tue Aug 19 12:33:10 2003 @@ -955,7 +955,7 @@ } ace_init_cleanup(root_dev); - kfree(root_dev); + free_netdev(root_dev); root_dev = next; } } diff -Nru a/drivers/net/amd8111e.c b/drivers/net/amd8111e.c --- a/drivers/net/amd8111e.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/amd8111e.c Tue Aug 19 12:33:10 2003 @@ -1711,7 +1711,7 @@ if (dev) { unregister_netdev(dev); iounmap((void *) ((struct amd8111e_priv *)(dev->priv))->mmio); - kfree(dev); + free_netdev(dev); pci_release_regions(pdev); pci_disable_device(pdev); pci_set_drvdata(pdev, NULL); diff -Nru a/drivers/net/arcnet/arc-rimi.c b/drivers/net/arcnet/arc-rimi.c --- a/drivers/net/arcnet/arc-rimi.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/arcnet/arc-rimi.c Tue Aug 19 12:33:10 2003 @@ -345,7 +345,7 @@ iounmap(lp->mem_start); release_mem_region(dev->mem_start, dev->mem_end - dev->mem_start + 1); kfree(dev->priv); - kfree(dev); + free_netdev(dev); } #else diff -Nru a/drivers/net/arcnet/com20020.c b/drivers/net/arcnet/com20020.c --- a/drivers/net/arcnet/com20020.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/arcnet/com20020.c Tue Aug 19 12:33:10 2003 @@ -344,7 +344,7 @@ free_irq(dev->irq, dev); release_region(dev->base_addr, ARCNET_TOTAL_SIZE); kfree(dev->priv); - kfree(dev); + free_netdev(dev); } #ifdef MODULE diff -Nru a/drivers/net/arcnet/com90io.c b/drivers/net/arcnet/com90io.c --- a/drivers/net/arcnet/com90io.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/arcnet/com90io.c Tue Aug 19 12:33:10 2003 @@ -411,7 +411,7 @@ free_irq(dev->irq, dev); release_region(dev->base_addr, ARCNET_TOTAL_SIZE); kfree(dev->priv); - kfree(dev); + free_netdev(dev); } #else diff -Nru a/drivers/net/arcnet/com90xx.c b/drivers/net/arcnet/com90xx.c --- a/drivers/net/arcnet/com90xx.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/arcnet/com90xx.c Tue Aug 19 12:33:10 2003 @@ -639,7 +639,7 @@ release_region(dev->base_addr, ARCNET_TOTAL_SIZE); release_mem_region(dev->mem_start, dev->mem_end - dev->mem_start + 1); kfree(dev->priv); - kfree(dev); + free_netdev(dev); } } diff -Nru a/drivers/net/ariadne.c b/drivers/net/ariadne.c --- a/drivers/net/ariadne.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/ariadne.c Tue Aug 19 12:33:10 2003 @@ -852,7 +852,7 @@ unregister_netdev(dev); release_mem_region(ZTWO_PADDR(dev->base_addr), sizeof(struct Am79C960)); release_mem_region(ZTWO_PADDR(dev->mem_start), ARIADNE_RAM_SIZE); - kfree(dev); + free_netdev(dev); root_ariadne_dev = next; } #endif diff -Nru a/drivers/net/arm/ether00.c b/drivers/net/arm/ether00.c --- a/drivers/net/arm/ether00.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/arm/ether00.c Tue Aug 19 12:33:10 2003 @@ -983,7 +983,7 @@ unregister_netdev(dev_list[i]); iounmap((void*)dev_list[i]->base_addr); release_mem_region(dev_list[i]->base_addr, MAC_REG_SIZE); - kfree(dev_list[i]); + free_netdev(dev_list[i]); dev_list[i]=0; } } diff -Nru a/drivers/net/arm/ether1.c b/drivers/net/arm/ether1.c --- a/drivers/net/arm/ether1.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/arm/ether1.c Tue Aug 19 12:33:10 2003 @@ -1082,7 +1082,7 @@ release_region(dev->base_addr, 16); release_region(dev->base_addr + 0x800, 4096); - kfree(dev); + free_netdev(dev); } static const struct ecard_id ether1_ids[] = { diff -Nru a/drivers/net/arm/ether3.c b/drivers/net/arm/ether3.c --- a/drivers/net/arm/ether3.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/arm/ether3.c Tue Aug 19 12:33:10 2003 @@ -921,7 +921,7 @@ unregister_netdev(dev); release_region(dev->base_addr, 128); - kfree(dev); + free_netdev(dev); } static const struct ecard_id ether3_ids[] = { diff -Nru a/drivers/net/arm/etherh.c b/drivers/net/arm/etherh.c --- a/drivers/net/arm/etherh.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/arm/etherh.c Tue Aug 19 12:33:10 2003 @@ -721,7 +721,7 @@ if (ec->cid.product == PROD_ANT_ETHERM) size <<= 3; release_region(dev->base_addr, size); - kfree(dev); + free_netdev(dev); ec->ops = NULL; kfree(ec->irq_data); diff -Nru a/drivers/net/atp.c b/drivers/net/atp.c --- a/drivers/net/atp.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/atp.c Tue Aug 19 12:33:10 2003 @@ -943,7 +943,7 @@ next_dev = ((struct net_local *)root_atp_dev->priv)->next_module; unregister_netdev(root_atp_dev); /* No need to release_region(), since we never snarf it. */ - kfree(root_atp_dev); + free_netdev(root_atp_dev); root_atp_dev = next_dev; } } diff -Nru a/drivers/net/au1000_eth.c b/drivers/net/au1000_eth.c --- a/drivers/net/au1000_eth.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/au1000_eth.c Tue Aug 19 12:33:10 2003 @@ -811,7 +811,7 @@ MAX_BUF_SIZE * (NUM_TX_BUFFS+NUM_RX_BUFFS)); printk(KERN_ERR "%s: au1000_probe1 failed. Returns %d\n", dev->name, retval); - kfree(dev); + free_netdev(dev); return retval; } diff -Nru a/drivers/net/b44.c b/drivers/net/b44.c --- a/drivers/net/b44.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/b44.c Tue Aug 19 12:33:10 2003 @@ -1852,7 +1852,7 @@ if (dev) { unregister_netdev(dev); iounmap((void *) ((struct b44 *)(dev->priv))->regs); - kfree(dev); + free_netdev(dev); pci_release_regions(pdev); pci_disable_device(pdev); pci_set_drvdata(pdev, NULL); diff -Nru a/drivers/net/bmac.c b/drivers/net/bmac.c --- a/drivers/net/bmac.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/bmac.c Tue Aug 19 12:33:10 2003 @@ -1720,7 +1720,7 @@ free_irq(bp->tx_dma_intr, dev); free_irq(bp->rx_dma_intr, dev); - kfree(dev); + free_netdev(dev); } while (bmac_devs != NULL); } diff -Nru a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/bonding/bond_main.c Tue Aug 19 12:33:10 2003 @@ -3892,7 +3892,7 @@ remove_proc_entry(dev->name, proc_net); #endif unregister_netdev(dev); - kfree(dev); + free_netdev(dev); } } diff -Nru a/drivers/net/declance.c b/drivers/net/declance.c --- a/drivers/net/declance.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/declance.c Tue Aug 19 12:33:10 2003 @@ -1244,7 +1244,7 @@ err_out: unregister_netdev(dev); - kfree(dev); + free_netdev(dev); return ret; } @@ -1295,7 +1295,7 @@ #endif root_lance_dev = lp->next; unregister_netdev(dev); - kfree(dev); + free_netdev(dev); } } diff -Nru a/drivers/net/defxx.c b/drivers/net/defxx.c --- a/drivers/net/defxx.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/defxx.c Tue Aug 19 12:33:10 2003 @@ -3376,7 +3376,7 @@ if (bp->kmalloced) pci_free_consistent(pdev, alloc_size, bp->kmalloced, bp->kmalloced_dma); - kfree(dev); + free_netdev(dev); } static void __devexit dfx_remove_one (struct pci_dev *pdev) diff -Nru a/drivers/net/dgrs.c b/drivers/net/dgrs.c --- a/drivers/net/dgrs.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/dgrs.c Tue Aug 19 12:33:10 2003 @@ -1337,7 +1337,7 @@ dgrs_root_dev = ((DGRS_PRIV *)d->priv)->next_dev; unregister_netdev(d); - kfree(d); + free_netdev(d); } return ret; } @@ -1529,7 +1529,7 @@ if (dgrs_root_dev->irq) free_irq(dgrs_root_dev->irq, dgrs_root_dev); - kfree(dgrs_root_dev); + free_netdev(dgrs_root_dev); dgrs_root_dev = next_dev; } } diff -Nru a/drivers/net/dl2k.c b/drivers/net/dl2k.c --- a/drivers/net/dl2k.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/dl2k.c Tue Aug 19 12:33:10 2003 @@ -1844,7 +1844,7 @@ #ifdef MEM_MAPPING iounmap ((char *) (dev->base_addr)); #endif - kfree (dev); + free_netdev (dev); pci_release_regions (pdev); pci_disable_device (pdev); } diff -Nru a/drivers/net/dummy.c b/drivers/net/dummy.c --- a/drivers/net/dummy.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/dummy.c Tue Aug 19 12:33:10 2003 @@ -107,7 +107,7 @@ static void __exit dummy_cleanup_module(void) { unregister_netdev(dev_dummy); - kfree(dev_dummy); + free_netdev(dev_dummy); dev_dummy = NULL; } diff -Nru a/drivers/net/e100/e100_main.c b/drivers/net/e100/e100_main.c --- a/drivers/net/e100/e100_main.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/e100/e100_main.c Tue Aug 19 12:33:10 2003 @@ -730,7 +730,7 @@ e100_dealloc_space(bdp); pci_set_drvdata(bdp->pdev, NULL); - kfree(dev); + free_netdev(dev); } static void __devexit diff -Nru a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c --- a/drivers/net/e1000/e1000_main.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/e1000/e1000_main.c Tue Aug 19 12:33:10 2003 @@ -531,7 +531,7 @@ iounmap(adapter->hw.hw_addr); pci_release_regions(pdev); - kfree(netdev); + free_netdev(netdev); } /** diff -Nru a/drivers/net/eepro100.c b/drivers/net/eepro100.c --- a/drivers/net/eepro100.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/eepro100.c Tue Aug 19 12:33:10 2003 @@ -2378,7 +2378,7 @@ + sizeof(struct speedo_stats), sp->tx_ring, sp->tx_ring_dma); pci_disable_device(pdev); - kfree(dev); + free_netdev(dev); } static struct pci_device_id eepro100_pci_tbl[] = { diff -Nru a/drivers/net/epic100.c b/drivers/net/epic100.c --- a/drivers/net/epic100.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/epic100.c Tue Aug 19 12:33:10 2003 @@ -1482,7 +1482,7 @@ iounmap((void*) dev->base_addr); #endif pci_release_regions(pdev); - kfree(dev); + free_netdev(dev); pci_set_drvdata(pdev, NULL); /* pci_power_off(pdev, -1); */ } diff -Nru a/drivers/net/eql.c b/drivers/net/eql.c --- a/drivers/net/eql.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/eql.c Tue Aug 19 12:33:10 2003 @@ -607,7 +607,7 @@ static void __exit eql_cleanup_module(void) { unregister_netdev(dev_eql); - kfree(dev_eql); + free_netdev(dev_eql); } module_init(eql_init_module); diff -Nru a/drivers/net/ewrk3.c b/drivers/net/ewrk3.c --- a/drivers/net/ewrk3.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/ewrk3.c Tue Aug 19 12:33:10 2003 @@ -2097,7 +2097,7 @@ ewrk3_devs[i]->irq = 0; release_region(ewrk3_devs[i]->base_addr, EWRK3_TOTAL_SIZE); - kfree(ewrk3_devs[i]); + free_netdev(ewrk3_devs[i]); ewrk3_devs[i] = NULL; } } diff -Nru a/drivers/net/fc/iph5526.c b/drivers/net/fc/iph5526.c --- a/drivers/net/fc/iph5526.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/fc/iph5526.c Tue Aug 19 12:33:10 2003 @@ -4527,7 +4527,7 @@ clean_up_memory(fc[i]); if (dev->priv) kfree(priv); - kfree(dev); + free_netdev(dev); dev = NULL; i++; } diff -Nru a/drivers/net/fealnx.c b/drivers/net/fealnx.c --- a/drivers/net/fealnx.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/fealnx.c Tue Aug 19 12:33:10 2003 @@ -712,7 +712,7 @@ #ifndef USE_IO_OPS iounmap((void *)dev->base_addr); #endif - kfree(dev); + free_netdev(dev); pci_release_regions(pdev); pci_set_drvdata(pdev, NULL); } else diff -Nru a/drivers/net/gt96100eth.c b/drivers/net/gt96100eth.c --- a/drivers/net/gt96100eth.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/gt96100eth.c Tue Aug 19 12:33:10 2003 @@ -826,7 +826,7 @@ free_region: release_region(gtif->iobase, GT96100_ETH_IO_SIZE); unregister_netdev(dev); - kfree (dev); + free_netdev (dev); err("%s failed. Returns %d\n", __FUNCTION__, retval); return retval; } @@ -1575,7 +1575,7 @@ (struct gt96100_private *)gtif->dev->priv; release_region(gtif->iobase, gp->io_size); unregister_netdev(gtif->dev); - kfree (gtif->dev); + free_netdev (gtif->dev); } } } diff -Nru a/drivers/net/hamachi.c b/drivers/net/hamachi.c --- a/drivers/net/hamachi.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/hamachi.c Tue Aug 19 12:33:10 2003 @@ -1976,7 +1976,7 @@ hmp->tx_ring_dma); unregister_netdev(dev); iounmap((char *)dev->base_addr); - kfree(dev); + free_netdev(dev); pci_release_regions(pdev); pci_set_drvdata(pdev, NULL); } diff -Nru a/drivers/net/hamradio/scc.c b/drivers/net/hamradio/scc.c --- a/drivers/net/hamradio/scc.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/hamradio/scc.c Tue Aug 19 12:33:10 2003 @@ -2121,7 +2121,7 @@ if (Nchips == 0) { unregister_netdev(SCC_Info[0].dev); - kfree(SCC_Info[0].dev); + free_netdev(SCC_Info[0].dev); } /* Guard against chip prattle */ @@ -2153,7 +2153,7 @@ if (scc->dev) { unregister_netdev(scc->dev); - kfree(scc->dev); + free_netdev(scc->dev); } } diff -Nru a/drivers/net/hamradio/yam.c b/drivers/net/hamradio/yam.c --- a/drivers/net/hamradio/yam.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/hamradio/yam.c Tue Aug 19 12:33:10 2003 @@ -1176,7 +1176,7 @@ error: while (--i >= 0) { unregister_netdev(yam_devs[i]); - kfree(yam_devs[i]); + free_netdev(yam_devs[i]); } return err; } diff -Nru a/drivers/net/hp100.c b/drivers/net/hp100.c --- a/drivers/net/hp100.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/hp100.c Tue Aug 19 12:33:10 2003 @@ -2965,7 +2965,7 @@ iounmap(p->mem_ptr_virt); kfree(d->priv); d->priv = NULL; - kfree(d); + free_netdev(d); hp100_devlist[i] = NULL; } diff -Nru a/drivers/net/hplance.c b/drivers/net/hplance.c --- a/drivers/net/hplance.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/hplance.c Tue Aug 19 12:33:10 2003 @@ -239,7 +239,7 @@ lp = root_hplance_dev->next_module; dio_unconfig_board(lp->scode); unregister_netdev(root_lance_dev->dev); - kfree(root_lance_dev->dev); + free_netdev(root_lance_dev->dev); root_lance_dev = lp; } } diff -Nru a/drivers/net/hydra.c b/drivers/net/hydra.c --- a/drivers/net/hydra.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/hydra.c Tue Aug 19 12:33:10 2003 @@ -226,7 +226,7 @@ unregister_netdev(dev); free_irq(IRQ_AMIGA_PORTS, dev); release_mem_region(ZTWO_PADDR(dev->base_addr)-HYDRA_NIC_BASE, 0x10000); - kfree(dev); + free_netdev(dev); root_hydra_dev = next; } } diff -Nru a/drivers/net/ioc3-eth.c b/drivers/net/ioc3-eth.c --- a/drivers/net/ioc3-eth.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/ioc3-eth.c Tue Aug 19 12:33:10 2003 @@ -1525,7 +1525,7 @@ unregister_netdev(dev); iounmap(ioc3); pci_release_regions(pdev); - kfree(dev); + free_netdev(dev); } static struct pci_device_id ioc3_pci_tbl[] = { diff -Nru a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c --- a/drivers/net/ixgb/ixgb_main.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/ixgb/ixgb_main.c Tue Aug 19 12:33:10 2003 @@ -478,7 +478,7 @@ iounmap((void *) adapter->hw.hw_addr); pci_release_regions(pdev); - kfree(netdev); + free_netdev(netdev); } /** diff -Nru a/drivers/net/lp486e.c b/drivers/net/lp486e.c --- a/drivers/net/lp486e.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/lp486e.c Tue Aug 19 12:33:10 2003 @@ -1336,7 +1336,7 @@ static void __exit lp486e_cleanup_module(void) { unregister_netdev(dev_lp486e); release_region(dev_lp486e->base_addr, LP486E_TOTAL_SIZE); - kfree(dev_lp486e); + free_netdev(dev_lp486e); } module_init(lp486e_init_module); diff -Nru a/drivers/net/mace.c b/drivers/net/mace.c --- a/drivers/net/mace.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/mace.c Tue Aug 19 12:33:10 2003 @@ -254,7 +254,7 @@ release_OF_resource(mp->of_node, 1); release_OF_resource(mp->of_node, 2); } - kfree(dev); + free_netdev(dev); } static void dbdma_reset(volatile struct dbdma_regs *dma) diff -Nru a/drivers/net/mvme147.c b/drivers/net/mvme147.c --- a/drivers/net/mvme147.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/mvme147.c Tue Aug 19 12:33:10 2003 @@ -199,7 +199,7 @@ lp = root_m147lance_dev->next_module; unregister_netdev(root_lance_dev->dev); free_pages(lp->ram, 3); - kfree(root_lance_dev->dev); + free_netdev(root_lance_dev->dev); root_lance_dev = lp; } } diff -Nru a/drivers/net/myri_sbus.c b/drivers/net/myri_sbus.c --- a/drivers/net/myri_sbus.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/myri_sbus.c Tue Aug 19 12:33:10 2003 @@ -1151,7 +1151,7 @@ unregister_netdev(root_myri_dev->dev); /* this will also free the co-allocated 'root_myri_dev' */ - kfree(root_myri_dev->dev); + free_netdev(root_myri_dev->dev); root_myri_dev = next; } #endif /* MODULE */ diff -Nru a/drivers/net/natsemi.c b/drivers/net/natsemi.c --- a/drivers/net/natsemi.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/natsemi.c Tue Aug 19 12:33:10 2003 @@ -2552,7 +2552,7 @@ unregister_netdev (dev); pci_release_regions (pdev); iounmap ((char *) dev->base_addr); - kfree (dev); + free_netdev (dev); pci_set_drvdata(pdev, NULL); } diff -Nru a/drivers/net/ne2k-pci.c b/drivers/net/ne2k-pci.c --- a/drivers/net/ne2k-pci.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/ne2k-pci.c Tue Aug 19 12:33:10 2003 @@ -636,7 +636,7 @@ unregister_netdev(dev); release_region(dev->base_addr, NE_IO_EXTENT); kfree(dev->priv); - kfree(dev); + free_netdev(dev); pci_set_drvdata(pdev, NULL); } diff -Nru a/drivers/net/ns83820.c b/drivers/net/ns83820.c --- a/drivers/net/ns83820.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/ns83820.c Tue Aug 19 12:33:10 2003 @@ -438,7 +438,7 @@ struct ns83820 { - struct net_device net_dev; + struct net_device net_dev; /* must be first */ struct net_device_stats stats; u8 *base; @@ -2057,7 +2057,7 @@ pci_free_consistent(dev->pci_dev, 4 * DESC_SIZE * NR_RX_DESC, dev->rx_info.descs, dev->rx_info.phy_descs); pci_disable_device(dev->pci_dev); - kfree(dev); + free_netdev(&dev->net_dev); pci_set_drvdata(pci_dev, NULL); } diff -Nru a/drivers/net/oaknet.c b/drivers/net/oaknet.c --- a/drivers/net/oaknet.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/oaknet.c Tue Aug 19 12:33:10 2003 @@ -687,7 +687,7 @@ release_region(ioaddr, OAKNET_IO_SIZE); iounmap(ioaddr); unregister_netdev(oaknet_dev); - kfree(priv); + free_netdev(priv); } /* Convert to loop once driver supports multiple devices. */ diff -Nru a/drivers/net/pci-skeleton.c b/drivers/net/pci-skeleton.c --- a/drivers/net/pci-skeleton.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/pci-skeleton.c Tue Aug 19 12:33:10 2003 @@ -871,7 +871,7 @@ sizeof (struct netdrv_private)); #endif /* NETDRV_NDEBUG */ - kfree (dev); + free_netdev (dev); pci_set_drvdata (pdev, NULL); diff -Nru a/drivers/net/pcnet32.c b/drivers/net/pcnet32.c --- a/drivers/net/pcnet32.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/pcnet32.c Tue Aug 19 12:33:10 2003 @@ -1762,7 +1762,7 @@ if (lp->pci_dev) pci_unregister_driver(&pcnet32_driver); pci_free_consistent(lp->pci_dev, sizeof(*lp), lp, lp->dma_addr); - kfree(pcnet32_dev); + free_netdev(pcnet32_dev); pcnet32_dev = next_dev; } } diff -Nru a/drivers/net/plip.c b/drivers/net/plip.c --- a/drivers/net/plip.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/plip.c Tue Aug 19 12:33:10 2003 @@ -1346,7 +1346,7 @@ if (nl->port_owner) parport_release(nl->pardev); parport_unregister_device(nl->pardev); - kfree(dev); + free_netdev(dev); dev_plip[i] = NULL; } } diff -Nru a/drivers/net/r8169.c b/drivers/net/r8169.c --- a/drivers/net/r8169.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/r8169.c Tue Aug 19 12:33:10 2003 @@ -646,7 +646,7 @@ sizeof (struct net_device) + sizeof (struct rtl8169_private)); pci_disable_device(pdev); - kfree(dev); + free_netdev(dev); pci_set_drvdata(pdev, NULL); } diff -Nru a/drivers/net/rcpci45.c b/drivers/net/rcpci45.c --- a/drivers/net/rcpci45.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/rcpci45.c Tue Aug 19 12:33:10 2003 @@ -146,7 +146,7 @@ pDpa->msgbuf_dma); if (pDpa->pPab) kfree (pDpa->pPab); - kfree (dev); + free_netdev (dev); pci_set_drvdata (pdev, NULL); } diff -Nru a/drivers/net/rrunner.c b/drivers/net/rrunner.c --- a/drivers/net/rrunner.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/rrunner.c Tue Aug 19 12:33:10 2003 @@ -253,7 +253,7 @@ rr->tx_ring_dma); unregister_netdev(dev); iounmap(rr->regs); - kfree(dev); + free_netdev(dev); pci_release_regions(pdev); pci_disable_device(pdev); pci_set_drvdata(pdev, NULL); diff -Nru a/drivers/net/sb1000.c b/drivers/net/sb1000.c --- a/drivers/net/sb1000.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/sb1000.c Tue Aug 19 12:33:10 2003 @@ -235,7 +235,7 @@ unregister_netdev(dev); release_region(dev->base_addr, 16); release_region(dev->mem_start, 16); - kfree(dev); + free_netdev(dev); } static struct pnp_driver sb1000_driver = { diff -Nru a/drivers/net/sb1250-mac.c b/drivers/net/sb1250-mac.c --- a/drivers/net/sb1250-mac.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/sb1250-mac.c Tue Aug 19 12:33:10 2003 @@ -2929,7 +2929,7 @@ port = A_MAC_CHANNEL_BASE(idx); SBMAC_WRITECSR(KSEG1ADDR(port+R_MAC_ETHERNET_ADDR), sbmac_orig_hwaddr[idx] ); - kfree(dev); + free_netdev(dev); dev_sbmac[idx] = NULL; } } diff -Nru a/drivers/net/sgiseeq.c b/drivers/net/sgiseeq.c --- a/drivers/net/sgiseeq.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/sgiseeq.c Tue Aug 19 12:33:10 2003 @@ -704,7 +704,7 @@ free_irq(dev->irq, dev); free_page((unsigned long) sp); unregister_netdev(dev); - kfree(dev); + free_netdev(dev); dev = next; } } diff -Nru a/drivers/net/sis190.c b/drivers/net/sis190.c --- a/drivers/net/sis190.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/sis190.c Tue Aug 19 12:33:10 2003 @@ -706,7 +706,7 @@ memset(dev, 0xBC, sizeof (struct net_device) + sizeof (struct sis190_private)); - kfree(dev); + free_netdev(dev); pci_set_drvdata(pdev, NULL); } diff -Nru a/drivers/net/sis900.c b/drivers/net/sis900.c --- a/drivers/net/sis900.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/sis900.c Tue Aug 19 12:33:10 2003 @@ -2190,7 +2190,7 @@ pci_free_consistent(pci_dev, TX_TOTAL_SIZE, sis_priv->tx_ring, sis_priv->tx_ring_dma); unregister_netdev(net_dev); - kfree(net_dev); + free_netdev(net_dev); pci_release_regions(pci_dev); pci_set_drvdata(pci_dev, NULL); } diff -Nru a/drivers/net/sk98lin/skge.c b/drivers/net/sk98lin/skge.c --- a/drivers/net/sk98lin/skge.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/sk98lin/skge.c Tue Aug 19 12:33:10 2003 @@ -1082,7 +1082,7 @@ * invalid IO ... :-( */ unregister_netdev(SkGeRootDev); - kfree(SkGeRootDev); + free_netdev(SkGeRootDev); kfree(pAC); SkGeRootDev = next; } diff -Nru a/drivers/net/sk_g16.c b/drivers/net/sk_g16.c --- a/drivers/net/sk_g16.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/sk_g16.c Tue Aug 19 12:33:10 2003 @@ -652,7 +652,7 @@ SK_dev->priv = NULL; } unregister_netdev(SK_dev); - kfree(SK_dev); + free_netdev(SK_dev); SK_dev = NULL; } if (SK_ioaddr) { diff -Nru a/drivers/net/skfp/skfddi.c b/drivers/net/skfp/skfddi.c --- a/drivers/net/skfp/skfddi.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/skfp/skfddi.c Tue Aug 19 12:33:10 2003 @@ -2582,7 +2582,7 @@ } unregister_netdev(p); printk("%s: unloaded\n", p->name); - kfree(p); /* Free the device structure */ + free_netdev(p); /* Free the device structure */ return next; } // unlink_modules diff -Nru a/drivers/net/starfire.c b/drivers/net/starfire.c --- a/drivers/net/starfire.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/starfire.c Tue Aug 19 12:33:10 2003 @@ -2196,7 +2196,7 @@ pci_release_regions(pdev); pci_set_drvdata(pdev, NULL); - kfree(dev); /* Will also free np!! */ + free_netdev(dev); /* Will also free np!! */ } diff -Nru a/drivers/net/sunbmac.c b/drivers/net/sunbmac.c --- a/drivers/net/sunbmac.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/sunbmac.c Tue Aug 19 12:33:10 2003 @@ -1275,7 +1275,7 @@ bp->bblock_dvma); unregister_netdev(bp->dev); - kfree(bp->dev); + free_netdev(bp->dev); root_bigmac_dev = bp_nxt; } } diff -Nru a/drivers/net/sundance.c b/drivers/net/sundance.c --- a/drivers/net/sundance.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/sundance.c Tue Aug 19 12:33:10 2003 @@ -1790,7 +1790,7 @@ #ifndef USE_IO_OPS iounmap((char *)(dev->base_addr)); #endif - kfree(dev); + free_netdev(dev); pci_set_drvdata(pdev, NULL); } } diff -Nru a/drivers/net/sungem.c b/drivers/net/sungem.c --- a/drivers/net/sungem.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/sungem.c Tue Aug 19 12:33:10 2003 @@ -2879,7 +2879,7 @@ gp->gblock_dvma); iounmap((void *) gp->regs); pci_release_regions(pdev); - kfree(dev); + free_netdev(dev); pci_set_drvdata(pdev, NULL); } diff -Nru a/drivers/net/sunhme.c b/drivers/net/sunhme.c --- a/drivers/net/sunhme.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/sunhme.c Tue Aug 19 12:33:10 2003 @@ -3348,7 +3348,7 @@ pci_release_regions(hp->happy_dev); } #endif - kfree(dev); + free_netdev(dev); root_happy_dev = next; } diff -Nru a/drivers/net/sunlance.c b/drivers/net/sunlance.c --- a/drivers/net/sunlance.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/sunlance.c Tue Aug 19 12:33:10 2003 @@ -1582,7 +1582,7 @@ unregister_netdev(root_lance_dev->dev); lance_free_hwresources(root_lance_dev); - kfree(root_lance_dev->dev); + free_netdev(root_lance_dev->dev); root_lance_dev = lp; } } diff -Nru a/drivers/net/sunqe.c b/drivers/net/sunqe.c --- a/drivers/net/sunqe.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/sunqe.c Tue Aug 19 12:33:10 2003 @@ -998,7 +998,7 @@ sizeof(struct sunqe_buffers), root_qec_dev->qes[i]->buffers, root_qec_dev->qes[i]->buffers_dvma); - kfree(root_qec_dev->qes[i]->dev); + free_netdev(root_qec_dev->qes[i]->dev); } free_irq(root_qec_dev->qec_sdev->irqs[0], (void *)root_qec_dev); sbus_iounmap(root_qec_dev->gregs, GLOB_REG_SIZE); diff -Nru a/drivers/net/tc35815.c b/drivers/net/tc35815.c --- a/drivers/net/tc35815.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/tc35815.c Tue Aug 19 12:33:10 2003 @@ -1769,7 +1769,7 @@ next_dev = ((struct tc35815_local *)dev->priv)->next_module; iounmap((void *)(dev->base_addr)); unregister_netdev(dev); - kfree(dev); + free_netdev(dev); root_tc35815_dev = next_dev; } } diff -Nru a/drivers/net/tg3.c b/drivers/net/tg3.c --- a/drivers/net/tg3.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/tg3.c Tue Aug 19 12:33:10 2003 @@ -6882,7 +6882,7 @@ if (dev) { unregister_netdev(dev); iounmap((void *) ((struct tg3 *)(dev->priv))->regs); - kfree(dev); + free_netdev(dev); pci_release_regions(pdev); pci_disable_device(pdev); pci_set_drvdata(pdev, NULL); diff -Nru a/drivers/net/tlan.c b/drivers/net/tlan.c --- a/drivers/net/tlan.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/tlan.c Tue Aug 19 12:33:10 2003 @@ -447,7 +447,7 @@ pci_release_regions(pdev); - kfree( dev ); + free_netdev( dev ); pci_set_drvdata( pdev, NULL ); } diff -Nru a/drivers/net/tulip/de2104x.c b/drivers/net/tulip/de2104x.c --- a/drivers/net/tulip/de2104x.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/tulip/de2104x.c Tue Aug 19 12:33:10 2003 @@ -2152,7 +2152,7 @@ pci_release_regions(pdev); pci_disable_device(pdev); pci_set_drvdata(pdev, NULL); - kfree(dev); + free_netdev(dev); } #ifdef CONFIG_PM diff -Nru a/drivers/net/tulip/de4x5.c b/drivers/net/tulip/de4x5.c --- a/drivers/net/tulip/de4x5.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/tulip/de4x5.c Tue Aug 19 12:33:10 2003 @@ -5837,7 +5837,7 @@ kfree(lp->cache.priv); /* Free the private area */ } unregister_netdev(p); - kfree(p); /* Free the device structure */ + free_netdev(p); /* Free the device structure */ return next; } diff -Nru a/drivers/net/tulip/dmfe.c b/drivers/net/tulip/dmfe.c --- a/drivers/net/tulip/dmfe.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/tulip/dmfe.c Tue Aug 19 12:33:10 2003 @@ -478,7 +478,7 @@ db->buf_pool_ptr, db->buf_pool_dma_ptr); unregister_netdev(dev); pci_release_regions(pdev); - kfree(dev); /* free board information */ + free_netdev(dev); /* free board information */ pci_set_drvdata(pdev, NULL); } diff -Nru a/drivers/net/tulip/tulip_core.c b/drivers/net/tulip/tulip_core.c --- a/drivers/net/tulip/tulip_core.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/tulip/tulip_core.c Tue Aug 19 12:33:10 2003 @@ -1780,7 +1780,7 @@ #ifndef USE_IO_OPS iounmap((void *)dev->base_addr); #endif - kfree (dev); + free_netdev (dev); pci_release_regions (pdev); pci_set_drvdata (pdev, NULL); diff -Nru a/drivers/net/tulip/winbond-840.c b/drivers/net/tulip/winbond-840.c --- a/drivers/net/tulip/winbond-840.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/tulip/winbond-840.c Tue Aug 19 12:33:10 2003 @@ -1623,7 +1623,7 @@ #ifndef USE_IO_OPS iounmap((char *)(dev->base_addr)); #endif - kfree(dev); + free_netdev(dev); } pci_set_drvdata(pdev, NULL); diff -Nru a/drivers/net/tulip/xircom_cb.c b/drivers/net/tulip/xircom_cb.c --- a/drivers/net/tulip/xircom_cb.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/tulip/xircom_cb.c Tue Aug 19 12:33:10 2003 @@ -338,7 +338,7 @@ } release_region(dev->base_addr, 128); unregister_netdev(dev); - kfree(dev); + free_netdev(dev); leave("xircom_remove"); } diff -Nru a/drivers/net/tulip/xircom_tulip_cb.c b/drivers/net/tulip/xircom_tulip_cb.c --- a/drivers/net/tulip/xircom_tulip_cb.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/tulip/xircom_tulip_cb.c Tue Aug 19 12:33:10 2003 @@ -1702,7 +1702,7 @@ printk(KERN_INFO "xircom_remove_one(%s)\n", dev->name); unregister_netdev(dev); pci_release_regions(pdev); - kfree(dev); + free_netdev(dev); pci_set_drvdata(pdev, NULL); } diff -Nru a/drivers/net/typhoon.c b/drivers/net/typhoon.c --- a/drivers/net/typhoon.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/typhoon.c Tue Aug 19 12:33:10 2003 @@ -2476,7 +2476,7 @@ pci_release_regions(pdev); pci_disable_device(pdev); pci_set_drvdata(pdev, NULL); - kfree(dev); + free_netdev(dev); } static struct pci_driver typhoon_driver = { diff -Nru a/drivers/net/via-rhine.c b/drivers/net/via-rhine.c --- a/drivers/net/via-rhine.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/via-rhine.c Tue Aug 19 12:33:10 2003 @@ -1893,7 +1893,7 @@ iounmap((char *)(dev->base_addr)); #endif - kfree(dev); + free_netdev(dev); pci_disable_device(pdev); pci_set_drvdata(pdev, NULL); } diff -Nru a/drivers/net/wan/comx.c b/drivers/net/wan/comx.c --- a/drivers/net/wan/comx.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/wan/comx.c Tue Aug 19 12:33:10 2003 @@ -908,7 +908,7 @@ if (dev->priv) { kfree(dev->priv); } - kfree(dev); + free_netdev(dev); remove_proc_entry(FILENAME_DEBUG, entry); remove_proc_entry(FILENAME_LINEUPDELAY, entry); diff -Nru a/drivers/net/wan/dlci.c b/drivers/net/wan/dlci.c --- a/drivers/net/wan/dlci.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/wan/dlci.c Tue Aug 19 12:33:10 2003 @@ -509,7 +509,7 @@ open_dev[i] = NULL; kfree(master->priv); - kfree(master); + free_netdev(master); MOD_DEC_USE_COUNT; diff -Nru a/drivers/net/wan/lmc/lmc_main.c b/drivers/net/wan/lmc/lmc_main.c --- a/drivers/net/wan/lmc/lmc_main.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/wan/lmc/lmc_main.c Tue Aug 19 12:33:10 2003 @@ -1913,7 +1913,7 @@ kfree (dev->priv); dev->priv = NULL; - kfree ((struct ppp_device *) dev); + free_netdev (dev); dev = NULL; } diff -Nru a/drivers/net/wan/sbni.c b/drivers/net/wan/sbni.c --- a/drivers/net/wan/sbni.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/wan/sbni.c Tue Aug 19 12:33:10 2003 @@ -1507,7 +1507,7 @@ unregister_netdev( dev ); release_region( dev->base_addr, SBNI_IO_EXTENT ); kfree( dev->priv ); - kfree( dev ); + free_netdev( dev ); } } diff -Nru a/drivers/net/wan/x25_asy.c b/drivers/net/wan/x25_asy.c --- a/drivers/net/wan/x25_asy.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/wan/x25_asy.c Tue Aug 19 12:33:10 2003 @@ -840,7 +840,7 @@ * unregistered while close proc. */ unregister_netdev(dev); - kfree(dev); + free_netdev(dev); } } diff -Nru a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c --- a/drivers/net/wireless/airo.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/wireless/airo.c Tue Aug 19 12:33:10 2003 @@ -1608,7 +1608,7 @@ unregister_netdev( dev ); if (ai->wifidev) { unregister_netdev(ai->wifidev); - kfree(ai->wifidev); + free_netdev(ai->wifidev); ai->wifidev = 0; } ai->registered = 0; @@ -1625,7 +1625,7 @@ release_region( dev->base_addr, 64 ); } del_airo_dev( dev ); - kfree( dev ); + free_netdev( dev ); } EXPORT_SYMBOL(stop_airo_card); diff -Nru a/drivers/net/wireless/airport.c b/drivers/net/wireless/airport.c --- a/drivers/net/wireless/airport.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/wireless/airport.c Tue Aug 19 12:33:10 2003 @@ -284,7 +284,7 @@ current->state = TASK_UNINTERRUPTIBLE; schedule_timeout(HZ); - kfree(dev); + free_netdev(dev); } /* airport_detach */ static char version[] __initdata = "airport.c 0.13e (Benjamin Herrenschmidt )"; diff -Nru a/drivers/net/wireless/arlan.c b/drivers/net/wireless/arlan.c --- a/drivers/net/wireless/arlan.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/wireless/arlan.c Tue Aug 19 12:33:10 2003 @@ -2061,7 +2061,7 @@ unregister_netdev(arlan_device[i]); ap = arlan_device[i]->priv; if (ap->init_etherdev_alloc) { - kfree(arlan_device[i]); + free_netdev(arlan_device[i]); arlan_device[i] = NULL; } else { kfree(ap); diff -Nru a/drivers/net/wireless/atmel.c b/drivers/net/wireless/atmel.c --- a/drivers/net/wireless/atmel.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/wireless/atmel.c Tue Aug 19 12:33:10 2003 @@ -1468,7 +1468,7 @@ /* PCMCIA frees this stuff, so only for PCI */ release_region(dev->base_addr, 64); } - kfree(dev); + free_netdev(dev); } EXPORT_SYMBOL(stop_atmel_card); diff -Nru a/drivers/net/wireless/netwave_cs.c b/drivers/net/wireless/netwave_cs.c --- a/drivers/net/wireless/netwave_cs.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/wireless/netwave_cs.c Tue Aug 19 12:33:10 2003 @@ -574,9 +574,9 @@ /* Unlink device structure, free pieces */ *linkp = link->next; - if (link->dev) + if (link->dev) unregister_netdev(dev); - kfree(dev); + free_netdev(dev); } /* netwave_detach */ diff -Nru a/drivers/net/wireless/orinoco_cs.c b/drivers/net/wireless/orinoco_cs.c --- a/drivers/net/wireless/orinoco_cs.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/wireless/orinoco_cs.c Tue Aug 19 12:33:10 2003 @@ -286,7 +286,7 @@ dev); unregister_netdev(dev); } - kfree(dev); + free_netdev(dev); } /* orinoco_cs_detach */ /* diff -Nru a/drivers/net/wireless/orinoco_pci.c b/drivers/net/wireless/orinoco_pci.c --- a/drivers/net/wireless/orinoco_pci.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/wireless/orinoco_pci.c Tue Aug 19 12:33:10 2003 @@ -289,7 +289,7 @@ iounmap((unsigned char *) priv->hw.iobase); pci_set_drvdata(pdev, NULL); - kfree(dev); + free_netdev(dev); pci_disable_device(pdev); } diff -Nru a/drivers/net/wireless/orinoco_plx.c b/drivers/net/wireless/orinoco_plx.c --- a/drivers/net/wireless/orinoco_plx.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/wireless/orinoco_plx.c Tue Aug 19 12:33:10 2003 @@ -291,7 +291,7 @@ pci_set_drvdata(pdev, NULL); - kfree(dev); + free_netdev(dev); release_region(pci_resource_start(pdev, 3), pci_resource_len(pdev, 3)); diff -Nru a/drivers/net/wireless/orinoco_tmd.c b/drivers/net/wireless/orinoco_tmd.c --- a/drivers/net/wireless/orinoco_tmd.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/wireless/orinoco_tmd.c Tue Aug 19 12:33:10 2003 @@ -182,7 +182,7 @@ pci_set_drvdata(pdev, NULL); - kfree(dev); + free_netdev(dev); release_region(pci_resource_start(pdev, 2), pci_resource_len(pdev, 2)); diff -Nru a/drivers/net/wireless/wavelan.c b/drivers/net/wireless/wavelan.c --- a/drivers/net/wireless/wavelan.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/wireless/wavelan.c Tue Aug 19 12:33:10 2003 @@ -4410,7 +4410,7 @@ /* Free pieces. */ kfree(dev->priv); - kfree(dev); + free_netdev(dev); } #ifdef DEBUG_MODULE_TRACE diff -Nru a/drivers/net/yellowfin.c b/drivers/net/yellowfin.c --- a/drivers/net/yellowfin.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/yellowfin.c Tue Aug 19 12:33:10 2003 @@ -1486,7 +1486,7 @@ iounmap ((void *) dev->base_addr); #endif - kfree (dev); + free_netdev (dev); pci_set_drvdata(pdev, NULL); } diff -Nru a/drivers/net/znet.c b/drivers/net/znet.c --- a/drivers/net/znet.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/znet.c Tue Aug 19 12:33:10 2003 @@ -941,7 +941,7 @@ kfree (znet->rx_start); kfree (znet->tx_start); unregister_netdev (znet_dev); - kfree (znet_dev); + free_netdev (znet_dev); } #endif } diff -Nru a/drivers/net/zorro8390.c b/drivers/net/zorro8390.c --- a/drivers/net/zorro8390.c Tue Aug 19 12:33:10 2003 +++ b/drivers/net/zorro8390.c Tue Aug 19 12:33:10 2003 @@ -413,7 +413,7 @@ unregister_netdev(dev); free_irq(IRQ_AMIGA_PORTS, dev); release_mem_region(ZTWO_PADDR(dev->base_addr), NE_IO_EXTENT*2); - kfree(dev); + free_netdev(dev); root_zorro8390_dev = next; } #endif From shemminger@osdl.org Tue Aug 19 12:47:38 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 12:47:42 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JJlcFl020473 for ; Tue, 19 Aug 2003 12:47:38 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7JJl6o25381; Tue, 19 Aug 2003 12:47:06 -0700 Date: Tue, 19 Aug 2003 12:21:43 -0700 From: Stephen Hemminger To: "David S. Miller" , Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] (7/9) freenetdev - net/* drivers Message-Id: <20030819122143.3d6d5cf9.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5062 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 2107 Lines: 75 Replace kfree with free_netdev in cleanup routines of protocols and network pseudo drivers. diff -Nru a/net/wanrouter/wanmain.c b/net/wanrouter/wanmain.c --- a/net/wanrouter/wanmain.c Tue Aug 19 09:04:32 2003 +++ b/net/wanrouter/wanmain.c Tue Aug 19 09:04:32 2003 @@ -908,7 +908,7 @@ unregister_netdev(dev); - kfree(dev); + free_netdev(dev); return 0; } diff -Nru a/net/sched/sch_teql.c b/net/sched/sch_teql.c --- a/net/sched/sch_teql.c Tue Aug 19 09:04:31 2003 +++ b/net/sched/sch_teql.c Tue Aug 19 09:04:31 2003 @@ -498,7 +498,7 @@ unregister_qdisc(&master->qops); unregister_netdev(master->dev); - kfree(master->dev); + free_netdev(master->dev); } spin_unlock(&master_dev_lock); } diff -Nru a/net/rose/af_rose.c b/net/rose/af_rose.c --- a/net/rose/af_rose.c Tue Aug 19 09:04:31 2003 +++ b/net/rose/af_rose.c Tue Aug 19 09:04:31 2003 @@ -1580,7 +1580,7 @@ if (dev) { unregister_netdev(dev); - kfree(dev); + free_netdev(dev); } } diff -Nru a/net/atm/br2684.c b/net/atm/br2684.c --- a/net/atm/br2684.c Tue Aug 19 09:04:31 2003 +++ b/net/atm/br2684.c Tue Aug 19 09:04:31 2003 @@ -793,7 +793,7 @@ brdev = list_entry_brdev(br2684_devs.next); unregister_netdev(&brdev->net_dev); list_del(&brdev->br2684_devs); - kfree(brdev); + free_netdev(brdev); } } diff -Nru a/net/atm/clip.c b/net/atm/clip.c --- a/net/atm/clip.c Tue Aug 19 09:04:32 2003 +++ b/net/atm/clip.c Tue Aug 19 09:04:32 2003 @@ -786,7 +786,7 @@ while (dev) { next = PRIV(dev)->next; unregister_netdev(dev); - kfree(dev); + free_netdev(dev); dev = next; } if (start_timer == 0) del_timer(&idle_timer); diff -Nru a/net/atm/lec.c b/net/atm/lec.c --- a/net/atm/lec.c Tue Aug 19 09:04:31 2003 +++ b/net/atm/lec.c Tue Aug 19 09:04:31 2003 @@ -864,7 +864,7 @@ if (dev_lec[i] != NULL) { priv = (struct lec_priv *)dev_lec[i]->priv; unregister_netdev(dev_lec[i]); - kfree(dev_lec[i]); + free_netdev(dev_lec[i]); dev_lec[i] = NULL; } } From shemminger@osdl.org Tue Aug 19 12:47:56 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 12:47:59 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JJltFl021669 for ; Tue, 19 Aug 2003 12:47:55 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7JJl6o25305; Tue, 19 Aug 2003 12:47:06 -0700 Date: Tue, 19 Aug 2003 12:18:23 -0700 From: Stephen Hemminger To: "David S. Miller" , Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] (5/9) freenetdev - pcmcia drivers Message-Id: <20030819121823.2667a2aa.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5064 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 4533 Lines: 162 Replace kfree with free_netdev diff -Nru a/drivers/net/pcmcia/3c574_cs.c b/drivers/net/pcmcia/3c574_cs.c --- a/drivers/net/pcmcia/3c574_cs.c Tue Aug 19 09:04:31 2003 +++ b/drivers/net/pcmcia/3c574_cs.c Tue Aug 19 09:04:31 2003 @@ -384,9 +384,11 @@ /* Unlink device structure, free bits */ *linkp = link->next; - if (link->dev) + if (link->dev) { unregister_netdev(dev); - kfree(dev); + free_netdev(dev); + } else + kfree(dev); } /* tc574_detach */ diff -Nru a/drivers/net/pcmcia/3c589_cs.c b/drivers/net/pcmcia/3c589_cs.c --- a/drivers/net/pcmcia/3c589_cs.c Tue Aug 19 09:04:32 2003 +++ b/drivers/net/pcmcia/3c589_cs.c Tue Aug 19 09:04:32 2003 @@ -308,9 +308,11 @@ /* Unlink device structure, free bits */ *linkp = link->next; - if (link->dev) + if (link->dev) { unregister_netdev(dev); - kfree(dev); + free_netdev(dev); + } else + kfree(dev); } /* tc589_detach */ diff -Nru a/drivers/net/pcmcia/axnet_cs.c b/drivers/net/pcmcia/axnet_cs.c --- a/drivers/net/pcmcia/axnet_cs.c Tue Aug 19 09:04:31 2003 +++ b/drivers/net/pcmcia/axnet_cs.c Tue Aug 19 09:04:31 2003 @@ -267,9 +267,11 @@ /* Unlink device structure, free bits */ *linkp = link->next; - if (link->dev) + if (link->dev) { unregister_netdev(&info->dev); - kfree(info); + free_netdev(&info->dev); + } else + kfree(info); } /* axnet_detach */ diff -Nru a/drivers/net/pcmcia/com20020_cs.c b/drivers/net/pcmcia/com20020_cs.c --- a/drivers/net/pcmcia/com20020_cs.c Tue Aug 19 09:04:31 2003 +++ b/drivers/net/pcmcia/com20020_cs.c Tue Aug 19 09:04:31 2003 @@ -329,7 +329,7 @@ DEBUG(1,"kfree...\n"); kfree(dev->priv); - kfree(dev); + free_netdev(dev); } DEBUG(1,"kfree2...\n"); kfree(info); diff -Nru a/drivers/net/pcmcia/fmvj18x_cs.c b/drivers/net/pcmcia/fmvj18x_cs.c --- a/drivers/net/pcmcia/fmvj18x_cs.c Tue Aug 19 09:04:32 2003 +++ b/drivers/net/pcmcia/fmvj18x_cs.c Tue Aug 19 09:04:32 2003 @@ -365,9 +365,11 @@ /* Unlink device structure, free pieces */ *linkp = link->next; - if (link->dev) + if (link->dev) { unregister_netdev(dev); - kfree(dev); + free_netdev(dev); + } else + kfree(dev); } /* fmvj18x_detach */ diff -Nru a/drivers/net/pcmcia/ibmtr_cs.c b/drivers/net/pcmcia/ibmtr_cs.c --- a/drivers/net/pcmcia/ibmtr_cs.c Tue Aug 19 09:04:31 2003 +++ b/drivers/net/pcmcia/ibmtr_cs.c Tue Aug 19 09:04:31 2003 @@ -306,7 +306,7 @@ /* Unlink device structure, free bits */ *linkp = link->next; unregister_netdev(dev); - kfree(dev); + free_netdev(dev); } /* ibmtr_detach */ /*====================================================================== diff -Nru a/drivers/net/pcmcia/nmclan_cs.c b/drivers/net/pcmcia/nmclan_cs.c --- a/drivers/net/pcmcia/nmclan_cs.c Tue Aug 19 09:04:31 2003 +++ b/drivers/net/pcmcia/nmclan_cs.c Tue Aug 19 09:04:31 2003 @@ -579,9 +579,11 @@ /* Unlink device structure, free bits */ *linkp = link->next; - if (link->dev) + if (link->dev) { unregister_netdev(dev); - kfree(dev); + free_netdev(dev); + } else + kfree(dev); } /* nmclan_detach */ diff -Nru a/drivers/net/pcmcia/pcnet_cs.c b/drivers/net/pcmcia/pcnet_cs.c --- a/drivers/net/pcmcia/pcnet_cs.c Tue Aug 19 09:04:32 2003 +++ b/drivers/net/pcmcia/pcnet_cs.c Tue Aug 19 09:04:32 2003 @@ -367,9 +367,11 @@ /* Unlink device structure, free bits */ *linkp = link->next; - if (link->dev) + if (link->dev) { unregister_netdev(&info->dev); - kfree(info); + free_netdev(&info->dev); + } else + kfree(info); } /* pcnet_detach */ diff -Nru a/drivers/net/pcmcia/smc91c92_cs.c b/drivers/net/pcmcia/smc91c92_cs.c --- a/drivers/net/pcmcia/smc91c92_cs.c Tue Aug 19 09:04:32 2003 +++ b/drivers/net/pcmcia/smc91c92_cs.c Tue Aug 19 09:04:32 2003 @@ -443,9 +443,11 @@ /* Unlink device structure, free bits */ *linkp = link->next; - if (link->dev) + if (link->dev) { unregister_netdev(dev); - kfree(dev); + free_netdev(dev); + } else + kfree(dev); } /* smc91c92_detach */ diff -Nru a/drivers/net/pcmcia/xirc2ps_cs.c b/drivers/net/pcmcia/xirc2ps_cs.c --- a/drivers/net/pcmcia/xirc2ps_cs.c Tue Aug 19 09:04:31 2003 +++ b/drivers/net/pcmcia/xirc2ps_cs.c Tue Aug 19 09:04:31 2003 @@ -699,9 +699,11 @@ /* Unlink device structure, free it */ *linkp = link->next; - if (link->dev) + if (link->dev) { unregister_netdev(dev); - kfree(dev); + free_netdev(dev); + } else + kfree(dev); } /* xirc2ps_detach */ From shemminger@osdl.org Tue Aug 19 12:48:01 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 12:48:04 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JJm0Fl021742 for ; Tue, 19 Aug 2003 12:48:00 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7JJl5o25253; Tue, 19 Aug 2003 12:47:05 -0700 Date: Tue, 19 Aug 2003 12:18:06 -0700 From: Stephen Hemminger To: "David S. Miller" , Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] (1/9) free_netdev - free network device on last class_device usage Message-Id: <20030819121806.1e06a4b9.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5065 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 4316 Lines: 123 This patch adds the free_netdev function and associated changes so that net_device structures are not freed until last reference to the network device class is released. diff -urNp -X dontdiff linux-2.5/include/linux/netdevice.h net-dev-2.5/include/linux/netdevice.h --- linux-2.5/include/linux/netdevice.h 2003-08-18 09:20:55.749112711 -0700 +++ net-dev-2.5/include/linux/netdevice.h 2003-08-18 09:43:45.159545904 -0700 @@ -384,6 +384,7 @@ struct net_device NETREG_REGISTERED, /* completed register todo */ NETREG_UNREGISTERING, /* called unregister_netdevice */ NETREG_UNREGISTERED, /* completed unregister todo */ + NETREG_RELEASED, /* called free_netdev */ } reg_state; /* Net device features */ @@ -516,6 +517,7 @@ extern int dev_close(struct net_device extern int dev_queue_xmit(struct sk_buff *skb); extern int register_netdevice(struct net_device *dev); extern int unregister_netdevice(struct net_device *dev); +extern void free_netdev(struct net_device *dev); extern void synchronize_net(void); extern int register_netdevice_notifier(struct notifier_block *nb); extern int unregister_netdevice_notifier(struct notifier_block *nb); diff -urNp -X dontdiff linux-2.5/net/core/dev.c net-dev-2.5/net/core/dev.c --- linux-2.5/net/core/dev.c 2003-08-18 09:20:55.831097541 -0700 +++ net-dev-2.5/net/core/dev.c 2003-08-18 09:43:45.991391795 -0700 @@ -2643,7 +2643,7 @@ int register_netdevice(struct net_device ASSERT_RTNL(); /* When net_device's are persistent, this will be fatal. */ - WARN_ON(dev->reg_state != NETREG_UNINITIALIZED); + BUG_ON(dev->reg_state != NETREG_UNINITIALIZED); spin_lock_init(&dev->queue_lock); spin_lock_init(&dev->xmit_lock); @@ -2788,6 +2788,8 @@ static void netdev_wait_allrefs(struct n * unregister_netdevice(y2); * ... * rtnl_unlock(); + * free_netdev(y1); + * free_netdev(y2); * * We are invoked by rtnl_unlock() after it drops the semaphore. * This allows us to deal with problems: @@ -2827,7 +2829,7 @@ void netdev_run_todo(void) break; case NETREG_UNREGISTERING: - class_device_unregister(&dev->class_dev); + class_device_del(&dev->class_dev); dev->reg_state = NETREG_UNREGISTERED; netdev_wait_allrefs(dev); @@ -2856,6 +2858,29 @@ void netdev_run_todo(void) up(&net_todo_run_mutex); } +/** + * free_netdev - free network device + * @dev: device + * + * This function does the last stage of destroying an allocated device + * interface. The reference to the device object is released. + * If this is the last reference then it will be freed. + */ +void free_netdev(struct net_device *dev) +{ + /* Compatiablity with error handling in drivers */ + if (dev->reg_state == NETREG_UNINITIALIZED) { + kfree(dev); + return; + } + + BUG_ON(dev->reg_state != NETREG_UNREGISTERED); + dev->reg_state = NETREG_RELEASED; + + /* will free via class release */ + class_device_put(&dev->class_dev); +} + /* Synchronize with packet receive processing. */ void synchronize_net(void) { diff -urNp -X dontdiff linux-2.5/net/core/net-sysfs.c net-dev-2.5/net/core/net-sysfs.c --- linux-2.5/net/core/net-sysfs.c 2003-08-18 09:20:55.833097171 -0700 +++ net-dev-2.5/net/core/net-sysfs.c 2003-08-18 09:43:45.996390869 -0700 @@ -361,8 +361,23 @@ static int netdev_hotplug(struct class_d } #endif +/* + * netdev_release -- destroy and free a dead device. + * Called when last reference to class_device kobject is gone. + */ +static void netdev_release(struct class_device *cd) +{ + struct net_device *dev + = container_of(cd, struct net_device, class_dev); + + BUG_ON(dev->reg_state != NETREG_RELEASED); + + kfree(dev); +} + static struct class net_class = { .name = "net", + .release = netdev_release, #ifdef CONFIG_HOTPLUG .hotplug = netdev_hotplug, #endif diff -urNp -X dontdiff linux-2.5/net/netsyms.c net-dev-2.5/net/netsyms.c --- linux-2.5/net/netsyms.c 2003-08-18 09:20:55.822099206 -0700 +++ net-dev-2.5/net/netsyms.c 2003-08-18 09:43:45.943400686 -0700 @@ -480,6 +480,7 @@ EXPORT_SYMBOL(call_netdevice_notifiers); EXPORT_SYMBOL(loopback_dev); EXPORT_SYMBOL(register_netdevice); EXPORT_SYMBOL(unregister_netdevice); +EXPORT_SYMBOL(free_netdev); EXPORT_SYMBOL(synchronize_net); EXPORT_SYMBOL(netdev_state_change); EXPORT_SYMBOL(netdev_boot_setup_check); From shemminger@osdl.org Tue Aug 19 12:48:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 12:48:20 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JJmHFl021955 for ; Tue, 19 Aug 2003 12:48:17 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7JJl6o25265; Tue, 19 Aug 2003 12:47:06 -0700 Date: Tue, 19 Aug 2003 12:18:12 -0700 From: Stephen Hemminger To: "David S. Miller" , Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] (2/9) freenetdev - update documentation Message-Id: <20030819121812.2a27f0a7.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5066 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1093 Lines: 22 diff -Nru a/Documentation/networking/netdevices.txt b/Documentation/networking/netdevices.txt --- a/Documentation/networking/netdevices.txt Tue Aug 5 09:41:12 2003 +++ b/Documentation/networking/netdevices.txt Tue Aug 5 09:41:12 2003 @@ -7,6 +7,18 @@ The following is a random collection of documentation regarding network devices. +struct net_device allocation rules +================================== +Network device structures need to persist even after module is unloaded and +must be allocated with kmalloc. If device has registered successfully, +it will be freed on last use by free_netdev. This is required to handle the +pathologic case cleanly (example: rmmod mydriver priv) then it is up to the module exit handler to free that. struct net_device synchronization rules From shemminger@osdl.org Tue Aug 19 12:48:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 12:48:21 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JJmHFl021961 for ; Tue, 19 Aug 2003 12:48:17 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7JJl6o25281; Tue, 19 Aug 2003 12:47:06 -0700 Date: Tue, 19 Aug 2003 12:18:19 -0700 From: Stephen Hemminger To: "David S. Miller" , Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] (4/9) freenetdev - tokenring changes Message-Id: <20030819121819.202ddcdb.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5067 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 4133 Lines: 122 s/kfree/free_netdev/ as appropriate for tokenring drivers. diff -Nru a/drivers/net/tokenring/3c359.c b/drivers/net/tokenring/3c359.c --- a/drivers/net/tokenring/3c359.c Tue Aug 19 09:04:32 2003 +++ b/drivers/net/tokenring/3c359.c Tue Aug 19 09:04:32 2003 @@ -1787,7 +1787,7 @@ iounmap(xl_priv->xl_mmio) ; pci_release_regions(pdev) ; pci_set_drvdata(pdev,NULL) ; - kfree(dev); + free_netdev(dev); return ; } diff -Nru a/drivers/net/tokenring/abyss.c b/drivers/net/tokenring/abyss.c --- a/drivers/net/tokenring/abyss.c Tue Aug 19 09:04:31 2003 +++ b/drivers/net/tokenring/abyss.c Tue Aug 19 09:04:31 2003 @@ -443,7 +443,7 @@ release_region(dev->base_addr-0x10, ABYSS_IO_EXTENT); free_irq(dev->irq, dev); tmsdev_term(dev); - kfree(dev); + free_netdev(dev); pci_set_drvdata(pdev, NULL); } diff -Nru a/drivers/net/tokenring/ibmtr.c b/drivers/net/tokenring/ibmtr.c --- a/drivers/net/tokenring/ibmtr.c Tue Aug 19 09:04:31 2003 +++ b/drivers/net/tokenring/ibmtr.c Tue Aug 19 09:04:31 2003 @@ -1975,7 +1975,7 @@ iounmap((u32 *)ti->sram_virt); } #endif - kfree(dev_ibmtr[i]); + free_netdev(dev_ibmtr[i]); dev_ibmtr[i] = NULL; } } diff -Nru a/drivers/net/tokenring/lanstreamer.c b/drivers/net/tokenring/lanstreamer.c --- a/drivers/net/tokenring/lanstreamer.c Tue Aug 19 09:04:32 2003 +++ b/drivers/net/tokenring/lanstreamer.c Tue Aug 19 09:04:32 2003 @@ -433,7 +433,7 @@ /* shouldn't we do iounmap here? */ release_region(pci_resource_start(pdev, 0), pci_resource_len(pdev,0)); release_mem_region(pci_resource_start(pdev, 1), pci_resource_len(pdev,1)); - kfree(dev); + free_netdev(dev); pci_set_drvdata(pdev, NULL); } diff -Nru a/drivers/net/tokenring/madgemc.c b/drivers/net/tokenring/madgemc.c --- a/drivers/net/tokenring/madgemc.c Tue Aug 19 09:04:32 2003 +++ b/drivers/net/tokenring/madgemc.c Tue Aug 19 09:04:32 2003 @@ -774,7 +774,7 @@ release_region(dev->base_addr-MADGEMC_SIF_OFFSET, MADGEMC_IO_EXTENT); free_irq(dev->irq, dev); tmsdev_term(dev); - kfree(dev); + free_netdev(dev); this_card = madgemc_card_list; madgemc_card_list = this_card->next; kfree(this_card); diff -Nru a/drivers/net/tokenring/olympic.c b/drivers/net/tokenring/olympic.c --- a/drivers/net/tokenring/olympic.c Tue Aug 19 09:04:32 2003 +++ b/drivers/net/tokenring/olympic.c Tue Aug 19 09:04:32 2003 @@ -1779,7 +1779,7 @@ iounmap(olympic_priv->olympic_lap) ; pci_release_regions(pdev) ; pci_set_drvdata(pdev,NULL) ; - kfree(dev) ; + free_netdev(dev) ; } static struct pci_driver olympic_driver = { diff -Nru a/drivers/net/tokenring/proteon.c b/drivers/net/tokenring/proteon.c --- a/drivers/net/tokenring/proteon.c Tue Aug 19 09:04:32 2003 +++ b/drivers/net/tokenring/proteon.c Tue Aug 19 09:04:32 2003 @@ -436,7 +436,7 @@ free_irq(dev->irq, dev); free_dma(dev->dma); tmsdev_term(dev); - kfree(dev); + free_netdev(dev); this_card = proteon_card_list; proteon_card_list = this_card->next; kfree(this_card); diff -Nru a/drivers/net/tokenring/skisa.c b/drivers/net/tokenring/skisa.c --- a/drivers/net/tokenring/skisa.c Tue Aug 19 09:04:31 2003 +++ b/drivers/net/tokenring/skisa.c Tue Aug 19 09:04:31 2003 @@ -449,7 +449,7 @@ free_irq(dev->irq, dev); free_dma(dev->dma); tmsdev_term(dev); - kfree(dev); + free_netdev(dev); this_card = sk_isa_card_list; sk_isa_card_list = this_card->next; kfree(this_card); diff -Nru a/drivers/net/tokenring/smctr.c b/drivers/net/tokenring/smctr.c --- a/drivers/net/tokenring/smctr.c Tue Aug 19 09:04:31 2003 +++ b/drivers/net/tokenring/smctr.c Tue Aug 19 09:04:31 2003 @@ -5730,7 +5730,7 @@ if (dev) { unregister_netdev(dev); cleanup_card(dev); - kfree(dev); + free_netdev(dev); } } } diff -Nru a/drivers/net/tokenring/tmspci.c b/drivers/net/tokenring/tmspci.c --- a/drivers/net/tokenring/tmspci.c Tue Aug 19 09:04:32 2003 +++ b/drivers/net/tokenring/tmspci.c Tue Aug 19 09:04:32 2003 @@ -229,7 +229,7 @@ release_region(dev->base_addr, TMS_PCI_IO_EXTENT); free_irq(dev->irq, dev); tmsdev_term(dev); - kfree(dev); + free_netdev(dev); pci_set_drvdata(pdev, NULL); } From davem@redhat.com Tue Aug 19 12:48:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 12:48: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 h7JJmqFl022752 for ; Tue, 19 Aug 2003 12:48:52 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id MAA12071; Tue, 19 Aug 2003 12:41:54 -0700 Date: Tue, 19 Aug 2003 12:41:54 -0700 From: "David S. Miller" To: Eran Mann Cc: netdev@oss.sgi.com Subject: Re: [patch 2.4] kernel oops on VLAN removal Message-Id: <20030819124154.75ec0383.davem@redhat.com> In-Reply-To: <3F424405.6020002@mrv.com> References: <3F424405.6020002@mrv.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5068 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 Content-Length: 395 Lines: 11 On Tue, 19 Aug 2003 18:36:37 +0300 Eran Mann wrote: > The current code attempts to add a proc entry for each vlan device, > however there is no check whether this attempt succeeded. When a device > is unregistered it tries to remove the proc entry, if none was added > the oops follows... Patch applied to my 2.4.x tree, scheduled for 2.4.23-preX Can someone check out 2.6.x? From shemminger@osdl.org Tue Aug 19 12:52:48 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 12:52:57 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JJqlFl023823 for ; Tue, 19 Aug 2003 12:52:47 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7JJl7o25399; Tue, 19 Aug 2003 12:47:07 -0700 Date: Tue, 19 Aug 2003 12:23:19 -0700 From: Stephen Hemminger To: "David S. Miller" , Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] (8/9) freenetdev - destructors Message-Id: <20030819122319.20cad225.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5069 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 7850 Lines: 230 Drivers that use kfree in destructor are easily converted to use free_netdev. diff -Nru a/drivers/net/hamradio/bpqether.c b/drivers/net/hamradio/bpqether.c --- a/drivers/net/hamradio/bpqether.c Tue Aug 19 11:54:46 2003 +++ b/drivers/net/hamradio/bpqether.c Tue Aug 19 11:54:46 2003 @@ -482,7 +482,7 @@ dev->set_mac_address = bpq_set_mac_address; dev->get_stats = bpq_get_stats; dev->do_ioctl = bpq_ioctl; - dev->destructor = (void (*)(struct net_device *)) kfree; + dev->destructor = free_netdev; memcpy(dev->broadcast, ax25_bcast, AX25_ADDR_LEN); memcpy(dev->dev_addr, ax25_defaddr, AX25_ADDR_LEN); diff -Nru a/drivers/net/ppp_generic.c b/drivers/net/ppp_generic.c --- a/drivers/net/ppp_generic.c Tue Aug 19 11:54:46 2003 +++ b/drivers/net/ppp_generic.c Tue Aug 19 11:54:46 2003 @@ -2256,11 +2256,6 @@ * and for initialization. */ -static void ppp_device_destructor(struct net_device *dev) -{ - kfree(dev); -} - /* * Create a new ppp interface unit. Fails if it can't allocate memory * or if there is already a unit with the requested number. @@ -2309,7 +2304,7 @@ dev->init = ppp_net_init; sprintf(dev->name, "ppp%d", unit); dev->priv = ppp; - dev->destructor = ppp_device_destructor; + dev->destructor = free_netdev; rtnl_lock(); ret = register_netdevice(dev); diff -Nru a/drivers/net/shaper.c b/drivers/net/shaper.c --- a/drivers/net/shaper.c Tue Aug 19 11:54:46 2003 +++ b/drivers/net/shaper.c Tue Aug 19 11:54:46 2003 @@ -642,7 +642,7 @@ dev->open = shaper_open; dev->stop = shaper_close; - dev->destructor = (void (*)(struct net_device *))kfree; + dev->destructor = free_netdev; dev->hard_start_xmit = shaper_start_xmit; dev->get_stats = shaper_get_stats; dev->set_multicast_list = NULL; diff -Nru a/drivers/net/slip.c b/drivers/net/slip.c --- a/drivers/net/slip.c Tue Aug 19 11:54:46 2003 +++ b/drivers/net/slip.c Tue Aug 19 11:54:46 2003 @@ -640,7 +640,7 @@ dev->init = sl_init; dev->uninit = sl_uninit; dev->open = sl_open; - dev->destructor = (void (*)(struct net_device *))kfree; + dev->destructor = free_netdev; dev->stop = sl_close; dev->get_stats = sl_get_stats; dev->change_mtu = sl_change_mtu; diff -Nru a/drivers/net/tun.c b/drivers/net/tun.c --- a/drivers/net/tun.c Tue Aug 19 11:54:46 2003 +++ b/drivers/net/tun.c Tue Aug 19 11:54:46 2003 @@ -358,7 +358,7 @@ dev->hard_start_xmit = tun_net_xmit; dev->stop = tun_net_close; dev->get_stats = tun_net_stats; - dev->destructor = (void (*)(struct net_device *))kfree; + dev->destructor = free_netdev; } static struct tun_struct *tun_get_by_name(const char *name) diff -Nru a/drivers/net/wan/hdlc_fr.c b/drivers/net/wan/hdlc_fr.c --- a/drivers/net/wan/hdlc_fr.c Tue Aug 19 11:54:46 2003 +++ b/drivers/net/wan/hdlc_fr.c Tue Aug 19 11:54:46 2003 @@ -1055,7 +1055,7 @@ return -EIO; } - dev->destructor = (void (*)(struct net_device *)) kfree; + dev->destructor = free_netdev; *get_dev_p(pvc, type) = dev; if (!used) { hdlc->state.fr.dce_changed = 1; diff -Nru a/drivers/net/wan/lapbether.c b/drivers/net/wan/lapbether.c --- a/drivers/net/wan/lapbether.c Tue Aug 19 11:54:46 2003 +++ b/drivers/net/wan/lapbether.c Tue Aug 19 11:54:46 2003 @@ -324,7 +324,7 @@ dev->hard_start_xmit = lapbeth_xmit; dev->open = lapbeth_open; dev->stop = lapbeth_close; - dev->destructor = (void (*)(struct net_device *))kfree; + dev->destructor = free_netdev; dev->set_mac_address = lapbeth_set_mac_address; dev->get_stats = lapbeth_get_stats; dev->type = ARPHRD_X25; diff -Nru a/net/8021q/vlan.c b/net/8021q/vlan.c --- a/net/8021q/vlan.c Tue Aug 19 11:54:46 2003 +++ b/net/8021q/vlan.c Tue Aug 19 11:54:46 2003 @@ -358,7 +358,7 @@ new_dev->stop = vlan_dev_stop; new_dev->set_mac_address = vlan_dev_set_mac_address; new_dev->set_multicast_list = vlan_dev_set_multicast_list; - new_dev->destructor = (void (*)(struct net_device *)) kfree; + new_dev->destructor = free_netdev; } /* Attach a VLAN device to a mac address (ie Ethernet Card). diff -Nru a/net/bridge/br_device.c b/net/bridge/br_device.c --- a/net/bridge/br_device.c Tue Aug 19 11:54:46 2003 +++ b/net/bridge/br_device.c Tue Aug 19 11:54:46 2003 @@ -110,22 +110,6 @@ return -1; } -/* convert later to direct kfree */ -static void br_dev_free(struct net_device *dev) -{ - struct net_bridge *br = dev->priv; - - WARN_ON(!list_empty(&br->port_list)); - WARN_ON(!list_empty(&br->age_list)); - - BUG_ON(timer_pending(&br->hello_timer)); - BUG_ON(timer_pending(&br->tcn_timer)); - BUG_ON(timer_pending(&br->topology_change_timer)); - BUG_ON(timer_pending(&br->gc_timer)); - - kfree(dev); -} - void br_dev_setup(struct net_device *dev) { memset(dev->dev_addr, 0, ETH_ALEN); @@ -137,7 +121,7 @@ dev->hard_start_xmit = br_dev_xmit; dev->open = br_dev_open; dev->set_multicast_list = br_dev_set_multicast_list; - dev->destructor = br_dev_free; + dev->destructor = free_netdev; SET_MODULE_OWNER(dev); dev->stop = br_dev_stop; dev->accept_fastpath = br_dev_accept_fastpath; diff -Nru a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c --- a/net/ipv4/ip_gre.c Tue Aug 19 11:54:46 2003 +++ b/net/ipv4/ip_gre.c Tue Aug 19 11:54:46 2003 @@ -1128,7 +1128,7 @@ { SET_MODULE_OWNER(dev); dev->uninit = ipgre_tunnel_uninit; - dev->destructor = (void (*)(struct net_device *))kfree; + dev->destructor = free_netdev; dev->hard_start_xmit = ipgre_tunnel_xmit; dev->get_stats = ipgre_tunnel_get_stats; dev->do_ioctl = ipgre_tunnel_ioctl; diff -Nru a/net/ipv4/ipip.c b/net/ipv4/ipip.c --- a/net/ipv4/ipip.c Tue Aug 19 11:54:46 2003 +++ b/net/ipv4/ipip.c Tue Aug 19 11:54:46 2003 @@ -246,7 +246,7 @@ nt = dev->priv; SET_MODULE_OWNER(dev); dev->init = ipip_tunnel_init; - dev->destructor = (void (*)(struct net_device *))kfree; + dev->destructor = free_netdev; nt->parms = *parms; if (register_netdevice(dev) < 0) { diff -Nru a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c --- a/net/ipv4/ipmr.c Tue Aug 19 11:54:46 2003 +++ b/net/ipv4/ipmr.c Tue Aug 19 11:54:46 2003 @@ -193,7 +193,7 @@ dev->flags = IFF_NOARP; dev->hard_start_xmit = reg_vif_xmit; dev->get_stats = reg_vif_get_stats; - dev->destructor = (void (*)(struct net_device *)) kfree; + dev->destructor = free_netdev; } static struct net_device *ipmr_reg_vif(void) diff -Nru a/net/ipv6/sit.c b/net/ipv6/sit.c --- a/net/ipv6/sit.c Tue Aug 19 11:54:46 2003 +++ b/net/ipv6/sit.c Tue Aug 19 11:54:46 2003 @@ -722,7 +722,7 @@ { SET_MODULE_OWNER(dev); dev->uninit = ipip6_tunnel_uninit; - dev->destructor = (void (*)(struct net_device *))kfree; + dev->destructor = free_netdev; dev->hard_start_xmit = ipip6_tunnel_xmit; dev->get_stats = ipip6_tunnel_get_stats; dev->do_ioctl = ipip6_tunnel_ioctl; diff -Nru a/net/irda/irda_device.c b/net/irda/irda_device.c --- a/net/irda/irda_device.c Tue Aug 19 11:54:46 2003 +++ b/net/irda/irda_device.c Tue Aug 19 11:54:46 2003 @@ -372,11 +372,6 @@ irda_task_kick(task); } -static void irda_device_destructor(struct net_device *dev) -{ - kfree(dev); -} - /* * Function irda_device_setup (dev) * @@ -388,7 +383,7 @@ dev->hard_header_len = 0; dev->addr_len = 0; - dev->destructor = irda_device_destructor; + dev->destructor = free_netdev; dev->type = ARPHRD_IRDA; dev->tx_queue_len = 8; /* Window size + 1 s-frame */ diff -Nru a/net/netrom/nr_dev.c b/net/netrom/nr_dev.c --- a/net/netrom/nr_dev.c Tue Aug 19 11:54:46 2003 +++ b/net/netrom/nr_dev.c Tue Aug 19 11:54:46 2003 @@ -204,7 +204,7 @@ dev->hard_start_xmit = nr_xmit; dev->open = nr_open; dev->stop = nr_close; - dev->destructor = (void (*)(struct net_device *))kfree; + dev->destructor = free_netdev; dev->hard_header = nr_header; dev->hard_header_len = NR_NETWORK_LEN + NR_TRANSPORT_LEN; From shemminger@osdl.org Tue Aug 19 12:53:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 12:53:08 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JJr2Fl023831 for ; Tue, 19 Aug 2003 12:53:03 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7JJl6o25309; Tue, 19 Aug 2003 12:47:06 -0700 Date: Tue, 19 Aug 2003 12:20:11 -0700 From: Stephen Hemminger To: "David S. Miller" , Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] (6/9) freenetdev - misc drivers Message-Id: <20030819122011.40906f04.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5070 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 3312 Lines: 111 s/kfree/free_netdev/ in cleanup routines of a bunch of different network drivers. diff -Nru a/arch/um/drivers/net_kern.c b/arch/um/drivers/net_kern.c --- a/arch/um/drivers/net_kern.c Tue Aug 19 09:04:31 2003 +++ b/arch/um/drivers/net_kern.c Tue Aug 19 09:04:31 2003 @@ -609,7 +609,7 @@ unregister_netdev(dev); list_del(&device->list); - kfree(device); + free_netdev(device); return(0); } diff -Nru a/drivers/ieee1394/eth1394.c b/drivers/ieee1394/eth1394.c --- a/drivers/ieee1394/eth1394.c Tue Aug 19 09:04:31 2003 +++ b/drivers/ieee1394/eth1394.c Tue Aug 19 09:04:31 2003 @@ -502,7 +502,7 @@ if (hi->dev) { unregister_netdev (hi->dev); - kfree(hi->dev); + free_netdev(hi->dev); } } diff -Nru a/drivers/isdn/hysdn/hysdn_net.c b/drivers/isdn/hysdn/hysdn_net.c --- a/drivers/isdn/hysdn/hysdn_net.c Tue Aug 19 09:04:31 2003 +++ b/drivers/isdn/hysdn/hysdn_net.c Tue Aug 19 09:04:31 2003 @@ -334,7 +334,7 @@ flush_tx_buffers((struct net_local *) dev); /* empty buffers */ unregister_netdev(dev); /* release the device */ - kfree(dev); /* release the memory allocated */ + free_netdev(dev); /* release the memory allocated */ if (card->debug_flags & LOG_NET_INIT) hysdn_addlog(card, "network device deleted"); diff -Nru a/drivers/s390/net/ctcmain.c b/drivers/s390/net/ctcmain.c --- a/drivers/s390/net/ctcmain.c Tue Aug 19 09:04:31 2003 +++ b/drivers/s390/net/ctcmain.c Tue Aug 19 09:04:31 2003 @@ -2708,7 +2708,7 @@ } #ifdef MODULE if (free_dev) - kfree(dev); + free_netdev(dev); #endif } diff -Nru a/drivers/s390/net/netiucv.c b/drivers/s390/net/netiucv.c --- a/drivers/s390/net/netiucv.c Tue Aug 19 09:04:31 2003 +++ b/drivers/s390/net/netiucv.c Tue Aug 19 09:04:31 2003 @@ -1654,7 +1654,7 @@ kfree_fsm(privptr->fsm); kfree(privptr); } - kfree(dev); + free_netdev(dev); } static ssize_t diff -Nru a/drivers/usb/net/catc.c b/drivers/usb/net/catc.c --- a/drivers/usb/net/catc.c Tue Aug 19 09:04:31 2003 +++ b/drivers/usb/net/catc.c Tue Aug 19 09:04:31 2003 @@ -961,7 +961,7 @@ usb_free_urb(catc->tx_urb); usb_free_urb(catc->rx_urb); usb_free_urb(catc->irq_urb); - kfree(catc->netdev); + free_netdev(catc->netdev); kfree(catc); } } diff -Nru a/drivers/usb/net/kaweth.c b/drivers/usb/net/kaweth.c --- a/drivers/usb/net/kaweth.c Tue Aug 19 09:04:32 2003 +++ b/drivers/usb/net/kaweth.c Tue Aug 19 09:04:32 2003 @@ -1189,7 +1189,7 @@ kaweth_dbg("Unregistering net device"); unregister_netdev(kaweth->net); - kfree(kaweth->net); + free_netdev(kaweth->net); } usb_free_urb(kaweth->rx_urb); diff -Nru a/drivers/usb/net/pegasus.c b/drivers/usb/net/pegasus.c --- a/drivers/usb/net/pegasus.c Tue Aug 19 09:04:32 2003 +++ b/drivers/usb/net/pegasus.c Tue Aug 19 09:04:32 2003 @@ -1310,7 +1310,7 @@ free_skb_pool(pegasus); if (pegasus->rx_skb) dev_kfree_skb(pegasus->rx_skb); - kfree(pegasus->net); + free_netdev(pegasus->net); kfree(pegasus); } diff -Nru a/drivers/usb/net/rtl8150.c b/drivers/usb/net/rtl8150.c --- a/drivers/usb/net/rtl8150.c Tue Aug 19 09:04:31 2003 +++ b/drivers/usb/net/rtl8150.c Tue Aug 19 09:04:31 2003 @@ -870,7 +870,7 @@ free_skb_pool(dev); if (dev->rx_skb) dev_kfree_skb(dev->rx_skb); - kfree(dev->netdev); + free_netdev(dev->netdev); kfree(dev->intr_buff); kfree(dev); } From shemminger@osdl.org Tue Aug 19 12:53:05 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 12:53:09 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JJr4Fl023848 for ; Tue, 19 Aug 2003 12:53:05 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7JJl5o25240; Tue, 19 Aug 2003 12:47:05 -0700 Date: Tue, 19 Aug 2003 12:36:54 -0700 From: Stephen Hemminger To: "David S. Miller" , Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] (9/9) freenetdev - fix leaky drivers Message-Id: <20030819123654.54919e58.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5071 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1929 Lines: 53 When doing the audit for this change, it was obvious that several drivers allocate but never free the net_device. This fixes these drivers. This patch is riskier than the earlier ones, because it isn't just a simple substitution and maybe there is a reason they never free. diff -Nru a/drivers/message/fusion/mptlan.c b/drivers/message/fusion/mptlan.c --- a/drivers/message/fusion/mptlan.c Tue Aug 19 09:05:35 2003 +++ b/drivers/message/fusion/mptlan.c Tue Aug 19 09:05:35 2003 @@ -1534,7 +1534,7 @@ printk (KERN_INFO ": %s/%s: Fusion MPT LAN device unregistered\n", IOC_AND_NETDEV_NAMES_s_s(dev)); unregister_netdev(dev); - //mpt_landev[i] = (struct net_device *) 0xdeadbeef; /* Debug */ + free_netdev(dev); mpt_landev[i] = NULL; } diff -Nru a/drivers/net/lasi_82596.c b/drivers/net/lasi_82596.c --- a/drivers/net/lasi_82596.c Tue Aug 19 09:05:35 2003 +++ b/drivers/net/lasi_82596.c Tue Aug 19 09:05:35 2003 @@ -1596,7 +1596,7 @@ lp = (struct i596_private *) netdevice->priv; dma_free_noncoherent(lp->dev, sizeof(struct i596_private), (void *)netdevice->mem_start, lp->dma_addr); - netdevice->priv = NULL; + free_netdev(netdevice); } unregister_parisc_driver(&lan_driver); diff -Nru a/drivers/net/wan/cosa.c b/drivers/net/wan/cosa.c --- a/drivers/net/wan/cosa.c Tue Aug 19 09:05:35 2003 +++ b/drivers/net/wan/cosa.c Tue Aug 19 09:05:35 2003 @@ -632,6 +632,7 @@ { sppp_detach(chan->pppdev.dev); unregister_netdev(chan->pppdev.dev); + free_netdev(chan->ppp.dev); } static int cosa_sppp_open(struct net_device *d) diff -Nru a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c --- a/drivers/usb/gadget/ether.c Tue Aug 19 09:05:35 2003 +++ b/drivers/usb/gadget/ether.c Tue Aug 19 09:05:35 2003 @@ -1635,6 +1635,7 @@ } unregister_netdev (dev->net); + free_netdev(dev->net); /* assuming we used keventd, it must quiesce too */ flush_scheduled_work (); From shemminger@osdl.org Tue Aug 19 12:53:11 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 12:53:16 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JJrBFl023903 for ; Tue, 19 Aug 2003 12:53:11 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7JJl5o25248; Tue, 19 Aug 2003 12:47:05 -0700 Date: Tue, 19 Aug 2003 12:18:00 -0700 From: Stephen Hemminger To: "David S. Miller" , Jeff Garzik Cc: netdev@oss.sgi.com, Patrick Mochel Subject: [PATCH] (0/9) free_netdev -- delay freeing of net_device structure till after last use Message-Id: <20030819121800.009db89b.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5072 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 4088 Lines: 145 The following set of patches fixes the problem caused by having a network class device entry held open when removing a network module. The simplest case of this is: rmmod e100 ; Tue, 19 Aug 2003 12:55:26 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id MAA12135; Tue, 19 Aug 2003 12:48:18 -0700 Date: Tue, 19 Aug 2003 12:48:18 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: jgarzik@pobox.com, netdev@oss.sgi.com, mochel@osdl.org Subject: Re: [PATCH] (0/9) free_netdev -- delay freeing of net_device structure till after last use Message-Id: <20030819124818.476dc36d.davem@redhat.com> In-Reply-To: <20030819121800.009db89b.shemminger@osdl.org> References: <20030819121800.009db89b.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5073 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 Content-Length: 518 Lines: 17 On Tue, 19 Aug 2003 12:18:00 -0700 Stephen Hemminger wrote: > It should be trivial to maintain source compatiablity with 2.4 > which doesn't need to change since it doesn't have sysfs, > by adding something like this to netdevice.h in 2.4 > > static __inline__ void free_netdev(struct net_device *dev) > { > kfree(dev); > } Yes, but drivers that want to work with all 2.4.x trees will need some kind of define to tip off of. Just providing a HAVE_FREE_NETDEV ought to be sufficient. Jeff? From mcr@sandelman.ottawa.on.ca Tue Aug 19 13:10:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 13:10:08 -0700 (PDT) Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [205.150.200.166] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JKA1Fl025583 for ; Tue, 19 Aug 2003 13:10:02 -0700 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h7JK9jd07382 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 19 Aug 2003 16:09:50 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h7JK9i1e002055 for ; Tue, 19 Aug 2003 16:09:45 -0400 To: netdev@oss.sgi.com Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices In-reply-to: Your message of "Tue, 19 Aug 2003 09:56:11 PDT." <20030819095611.0fb8f9a3.davem@redhat.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 19 Aug 2003 16:09:44 -0400 Message-ID: <2053.1061323784@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-archive-position: 5074 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcr@sandelman.ottawa.on.ca Precedence: bulk X-list: netdev Content-Length: 396 Lines: 8 If a Linux is a system that has a Host's IP, then is it really a router? ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ From jgarzik@pobox.com Tue Aug 19 13:14:13 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 13:14:17 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JKDpFl026121 for ; Tue, 19 Aug 2003 13:14:13 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19pCrW-0004hU-43; Tue, 19 Aug 2003 21:13:50 +0100 Message-ID: <3F4284E6.7070709@pobox.com> Date: Tue, 19 Aug 2003 16:13:26 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: Stephen Hemminger , netdev@oss.sgi.com, mochel@osdl.org Subject: Re: [PATCH] (0/9) free_netdev -- delay freeing of net_device structure till after last use References: <20030819121800.009db89b.shemminger@osdl.org> <20030819124818.476dc36d.davem@redhat.com> In-Reply-To: <20030819124818.476dc36d.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5075 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 Content-Length: 237 Lines: 14 David S. Miller wrote: > Yes, but drivers that want to work with all 2.4.x trees > will need some kind of define to tip off of. Just providing > a HAVE_FREE_NETDEV ought to be sufficient. > > Jeff? Yeah, that works for me. Jeff From davem@redhat.com Tue Aug 19 13:17:32 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 13:17:36 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JKHHFl026723 for ; Tue, 19 Aug 2003 13:17:32 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id NAA12288; Tue, 19 Aug 2003 13:09:21 -0700 Date: Tue, 19 Aug 2003 13:09:21 -0700 From: "David S. Miller" To: Jeff Garzik Cc: shemminger@osdl.org, netdev@oss.sgi.com, mochel@osdl.org Subject: Re: [PATCH] (0/9) free_netdev -- delay freeing of net_device structure till after last use Message-Id: <20030819130921.7c750408.davem@redhat.com> In-Reply-To: <3F4284E6.7070709@pobox.com> References: <20030819121800.009db89b.shemminger@osdl.org> <20030819124818.476dc36d.davem@redhat.com> <3F4284E6.7070709@pobox.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5076 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 Content-Length: 443 Lines: 16 On Tue, 19 Aug 2003 16:13:26 -0400 Jeff Garzik wrote: > David S. Miller wrote: > > Yes, but drivers that want to work with all 2.4.x trees > > will need some kind of define to tip off of. Just providing > > a HAVE_FREE_NETDEV ought to be sufficient. > > > > Jeff? > > Yeah, that works for me. Ok, so what I'm going to do is apply all of Stephen's patches and I'll add the HAVE_FREE_NETDEV define to linux/netdevice.h From shemminger@osdl.org Tue Aug 19 13:28:59 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 13:29:03 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JKSwFl027229 for ; Tue, 19 Aug 2003 13:28:59 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7JKSVo06152; Tue, 19 Aug 2003 13:28:31 -0700 Date: Tue, 19 Aug 2003 13:28:19 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: Jeff Garzik , netdev@oss.sgi.com, mochel@osdl.org Subject: Re: [PATCH] (0/9) free_netdev -- delay freeing of net_device structure till after last use Message-Id: <20030819132819.36d8257f.shemminger@osdl.org> In-Reply-To: <20030819130921.7c750408.davem@redhat.com> References: <20030819121800.009db89b.shemminger@osdl.org> <20030819124818.476dc36d.davem@redhat.com> <3F4284E6.7070709@pobox.com> <20030819130921.7c750408.davem@redhat.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5077 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 961 Lines: 32 On Tue, 19 Aug 2003 13:09:21 -0700 "David S. Miller" wrote: > On Tue, 19 Aug 2003 16:13:26 -0400 > Jeff Garzik wrote: > > > David S. Miller wrote: > > > Yes, but drivers that want to work with all 2.4.x trees > > > will need some kind of define to tip off of. Just providing > > > a HAVE_FREE_NETDEV ought to be sufficient. > > > > > > Jeff? > > > > Yeah, that works for me. > > Ok, so what I'm going to do is apply all of Stephen's > patches and I'll add the HAVE_FREE_NETDEV define to > linux/netdevice.h Ok fine. diff -Nru a/include/linux/netdevice.h b/include/linux/netdevice.h --- a/include/linux/netdevice.h Tue Aug 19 13:28:03 2003 +++ b/include/linux/netdevice.h Tue Aug 19 13:28:03 2003 @@ -51,6 +51,7 @@ #define HAVE_ALLOC_NETDEV /* feature macro: alloc_xxxdev functions are available. */ +#define HAVE_FREE_NETDEV #define NET_XMIT_SUCCESS 0 #define NET_XMIT_DROP 1 /* skb dropped */ From shemminger@osdl.org Tue Aug 19 13:31:01 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 13:31:05 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JKV0Fl027588 for ; Tue, 19 Aug 2003 13:31:01 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7JKUYo06770; Tue, 19 Aug 2003 13:30:34 -0700 Date: Tue, 19 Aug 2003 13:30:22 -0700 From: Stephen Hemminger To: Jeff Garzik Cc: "David S. Miller" , netdev@oss.sgi.com, mochel@osdl.org Subject: Re: [PATCH] (0/9) free_netdev -- delay freeing of net_device structure till after last use Message-Id: <20030819133022.3f71906c.shemminger@osdl.org> In-Reply-To: <3F42877B.9040407@pobox.com> References: <20030819121800.009db89b.shemminger@osdl.org> <20030819124818.476dc36d.davem@redhat.com> <3F42877B.9040407@pobox.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5078 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 875 Lines: 26 On Tue, 19 Aug 2003 16:24:27 -0400 Jeff Garzik wrote: > David, > > Considering that these patches introduce only a tiny diff in the > low-level net driver, and that the viro work is still pending, I'm ok > with going ahead and applying these patches. > > Since they mix net/* and drivers/net/*, I would actually prefer that you > merge 100% of the patchset, once the patchset is ok with you. There was a tradeoff between what granularity of patchset. There is no real dependency after the first two. > Also, my tendency is to apply patches 1-8, and not apply patch 9 just > yet. Even though patch 9 is a fix, those specific areas of code, I'm > betting, will change when those drivers are fixed WRT full dynamic > allocation and refcounting. > > Comments? > > Jeff > Yeah, that is why 9 is last, so it can be split or dropped or whatever. From davem@redhat.com Tue Aug 19 13:32:10 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 13:32:14 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JKWAFl027919 for ; Tue, 19 Aug 2003 13:32:10 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id NAA12410; Tue, 19 Aug 2003 13:24:32 -0700 Date: Tue, 19 Aug 2003 13:24:32 -0700 From: "David S. Miller" To: Jeff Garzik Cc: shemminger@osdl.org, netdev@oss.sgi.com, mochel@osdl.org Subject: Re: [PATCH] (0/9) free_netdev -- delay freeing of net_device structure till after last use Message-Id: <20030819132432.4c601c5f.davem@redhat.com> In-Reply-To: <3F42877B.9040407@pobox.com> References: <20030819121800.009db89b.shemminger@osdl.org> <20030819124818.476dc36d.davem@redhat.com> <3F42877B.9040407@pobox.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5079 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 Content-Length: 595 Lines: 18 On Tue, 19 Aug 2003 16:24:27 -0400 Jeff Garzik wrote: > Also, my tendency is to apply patches 1-8, and not apply patch 9 just > yet. Even though patch 9 is a fix, those specific areas of code, I'm > betting, will change when those drivers are fixed WRT full dynamic > allocation and refcounting. > > Comments? I disagree about patch 9. These drivers already dynamically allocate their netdev structs, so they do not require any more fixing. I just double checked each driver changes in patch 9 and to me this is undoubtedly the case. These are just pure bug fixes. From hstenzel@us.ibm.com Tue Aug 19 14:02:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 14:02:40 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JL2OFl028648 for ; Tue, 19 Aug 2003 14:02:35 -0700 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e34.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h7JL1nEh087578; Tue, 19 Aug 2003 17:01:49 -0400 Received: from d03nm118.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.193.83]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h7JL1jGm393026; Tue, 19 Aug 2003 15:01:49 -0600 Received: from us.ibm.com ([9.27.176.216]) by d03nm118.boulder.ibm.com (Lotus Domino Release 6.0.2CF2) with ESMTP id 2003081915014638-38908 ; Tue, 19 Aug 2003 15:01:46 -0600 Message-ID: <3F429039.8090905@us.ibm.com> Date: Tue, 19 Aug 2003 17:01:45 -0400 From: Harley Stenzel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030625 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" Cc: Lars Marowsky-Bree , bloemsaa@xs4all.nl, richard@aspectgroup.co.uk, skraw@ithnet.com, willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices References: <353568DCBAE06148B70767C1B1A93E625EAB57@post.pc.aspectgroup.co.uk> <070c01c36653$7f3c1ab0$c801a8c0@llewella> <20030819083438.26c985b9.davem@redhat.com> <20030819173920.GA3301@marowsky-bree.de> <20030819103613.4485e549.davem@redhat.com> In-Reply-To: <20030819103613.4485e549.davem@redhat.com> X-MIMETrack: Itemize by SMTP Server on D03NM118/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/19/2003 15:01:46, Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/19/2003 15:01:49, Serialize complete at 08/19/2003 15:01:49 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-archive-position: 5080 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hstenzel@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 731 Lines: 19 David S. Miller wrote: > > And, as Alan said, we provide a way for one to obtain your networking > religion of week. To the best of my knowledge, there is presently no way to change the arp behavior of Linux such that it uses the interface-based arp mechanizm in a manner compatable with load-balancing and hot-standby techniques involving aliasing the loopback interface. In all the proposed solutions the cache-update by an arp request problem still exists (arp source ip problem). I would love to be proven wrong. Presently I have to either patch the kernel or suffer the throughput penalty of doing dnat to myself, all to do something that Solaris, AIX, HP-UX, *BSD, and even Windows can do natively. --Harley From jgarzik@pobox.com Tue Aug 19 14:11:23 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 14:11:29 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JLBMFl029046 for ; Tue, 19 Aug 2003 14:11:23 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19pD1y-0004ww-Tf; Tue, 19 Aug 2003 21:24:39 +0100 Message-ID: <3F42877B.9040407@pobox.com> Date: Tue, 19 Aug 2003 16:24:27 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: Stephen Hemminger , netdev@oss.sgi.com, mochel@osdl.org Subject: Re: [PATCH] (0/9) free_netdev -- delay freeing of net_device structure till after last use References: <20030819121800.009db89b.shemminger@osdl.org> <20030819124818.476dc36d.davem@redhat.com> In-Reply-To: <20030819124818.476dc36d.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5081 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 Content-Length: 587 Lines: 20 David, Considering that these patches introduce only a tiny diff in the low-level net driver, and that the viro work is still pending, I'm ok with going ahead and applying these patches. Since they mix net/* and drivers/net/*, I would actually prefer that you merge 100% of the patchset, once the patchset is ok with you. Also, my tendency is to apply patches 1-8, and not apply patch 9 just yet. Even though patch 9 is a fix, those specific areas of code, I'm betting, will change when those drivers are fixed WRT full dynamic allocation and refcounting. Comments? Jeff From shemminger@osdl.org Tue Aug 19 14:13:57 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 14:14:00 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JLDuFl029408 for ; Tue, 19 Aug 2003 14:13:56 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7JLDco20203; Tue, 19 Aug 2003 14:13:40 -0700 Date: Tue, 19 Aug 2003 14:13:26 -0700 From: Stephen Hemminger To: Mike Phillips Cc: linux-tr@linuxtr.net, netdev@oss.sgi.com Subject: [RFT][PATCH] convert 802/tr to seq_file Message-Id: <20030819141326.2a63bad0.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5082 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 4894 Lines: 191 Convert the /proc interface to tokenring routing information to the new seq_file interface. Builds and loads on 2.6.0-test3, but I don't have any real tokenring hardware to make entries show up in table. diff -Nru a/net/802/tr.c b/net/802/tr.c --- a/net/802/tr.c Tue Aug 19 14:07:56 2003 +++ b/net/802/tr.c Tue Aug 19 14:07:56 2003 @@ -33,6 +33,7 @@ #include #include #include +#include #include #include @@ -456,84 +457,108 @@ * routing. */ -#ifndef CONFIG_PROC_FS -static int rif_get_info(char *buffer,char **start, off_t offset, int length) { return 0;} -#else -static int rif_get_info(char *buffer,char **start, off_t offset, int length) -{ - int len=0; - off_t begin=0; - off_t pos=0; - int size,i,j,rcf_len,segment,brdgnmb; - unsigned long now=jiffies; +#ifdef CONFIG_PROC_FS +/* Magic token to indicate first entry (header line) */ +#define RIF_PROC_START ((void *)1) + +static struct rif_cache_s *rif_get_idx(loff_t pos) +{ + int i; + struct rif_cache_s *entry; + loff_t off = 0; + + for(i=0;i < RIF_TABLE_SIZE;i++) + for(entry=rif_table[i];entry;entry=entry->next) { + if (off == pos) + return entry; + ++off; + } + + return NULL; +} + +static void *rif_seq_start(struct seq_file *seq, loff_t *pos) +{ unsigned long flags; - rif_cache entry; + spin_lock_irqsave(&rif_lock, flags); + seq->private = (void *) flags; + + return *pos ? rif_get_idx(*pos - 1) : RIF_PROC_START; +} + +static void *rif_seq_next(struct seq_file *seq, void *v, loff_t *pos) +{ + return rif_get_idx(*pos++); +} + +static void rif_seq_stop(struct seq_file *seq, void *v) +{ + unsigned long flags = (unsigned long) seq->private; + spin_lock_irqsave(&rif_lock, flags); +} - size=sprintf(buffer, +static int rif_seq_show(struct seq_file *seq, void *v) +{ + int j, rcf_len, segment, brdgnmb; + rif_cache entry = v; + + if (v == RIF_PROC_START) + seq_puts(seq, "if TR address TTL rcf routing segments\n"); - pos+=size; - len+=size; + else { + struct net_device *dev = dev_get_by_index(entry->iface); - spin_lock_irqsave(&rif_lock,flags); - for(i=0;i < RIF_TABLE_SIZE;i++) - { - for(entry=rif_table[i];entry;entry=entry->next) { - struct net_device *dev = __dev_get_by_index(entry->iface); + seq_printf(seq, "%s %02X:%02X:%02X:%02X:%02X:%02X %7li ", + dev?dev->name:"?", + entry->addr[0],entry->addr[1],entry->addr[2], + entry->addr[3],entry->addr[4],entry->addr[5], + sysctl_tr_rif_timeout-(jiffies-entry->last_used)); - size=sprintf(buffer+len,"%s %02X:%02X:%02X:%02X:%02X:%02X %7li ", - dev?dev->name:"?",entry->addr[0],entry->addr[1],entry->addr[2],entry->addr[3],entry->addr[4],entry->addr[5], - sysctl_tr_rif_timeout-(now-entry->last_used)); - len+=size; - pos=begin+len; if (entry->local_ring) - size=sprintf(buffer+len,"local\n"); + seq_puts(seq, "local\n"); else { - size=sprintf(buffer+len,"%04X", ntohs(entry->rcf)); + + seq_printf(seq, "%04X", ntohs(entry->rcf)); rcf_len = ((ntohs(entry->rcf) & TR_RCF_LEN_MASK)>>8)-2; if (rcf_len) rcf_len >>= 1; for(j = 1; j < rcf_len; j++) { if(j==1) { segment=ntohs(entry->rseg[j-1])>>4; - len+=size; - pos=begin+len; - size=sprintf(buffer+len," %03X",segment); + seq_printf(seq," %03X",segment); }; segment=ntohs(entry->rseg[j])>>4; brdgnmb=ntohs(entry->rseg[j-1])&0x00f; - len+=size; - pos=begin+len; - size=sprintf(buffer+len,"-%01X-%03X",brdgnmb,segment); + seq_printf(seq,"-%01X-%03X",brdgnmb,segment); } - len+=size; - pos=begin+len; - size=sprintf(buffer+len,"\n"); - } - len+=size; - pos=begin+len; - - if(posoffset+length) - break; } - if(pos>offset+length) - break; - } - spin_unlock_irqrestore(&rif_lock,flags); + return 0; +} + + +static struct seq_operations rif_seq_ops = { + .start = rif_seq_start, + .next = rif_seq_next, + .stop = rif_seq_stop, + .show = rif_seq_show, +}; - *start=buffer+(offset-begin); /* Start of wanted data */ - len-=(offset-begin); /* Start slop */ - if(len>length) - len=length; /* Ending slop */ - if (len<0) - len=0; - return len; +static int rif_seq_open(struct inode *inode, struct file *file) +{ + return seq_open(file, &rif_seq_ops); } + +static struct file_operations rif_seq_fops = { + .owner = THIS_MODULE, + .open = rif_seq_open, + .read = seq_read, + .llseek = seq_lseek, + .release = seq_release, +}; + #endif /* @@ -549,7 +574,7 @@ rif_timer.function = rif_check_expire; add_timer(&rif_timer); - proc_net_create("tr_rif",0,rif_get_info); + proc_net_fops_create("tr_rif", S_IRUGO, &rif_seq_fops); return 0; } From davem@redhat.com Tue Aug 19 15:19:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 15:19:32 -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 h7JMJOFl030361 for ; Tue, 19 Aug 2003 15:19:25 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id PAA13069; Tue, 19 Aug 2003 15:11:37 -0700 Date: Tue, 19 Aug 2003 15:11:37 -0700 From: "David S. Miller" To: Richard Underwood Cc: alan@lxorguk.ukuu.org.uk, skraw@ithnet.com, willy@w.ods.org, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030819151137.3d6e78f2.davem@redhat.com> In-Reply-To: <353568DCBAE06148B70767C1B1A93E625EAB60@post.pc.aspectgroup.co.uk> References: <353568DCBAE06148B70767C1B1A93E625EAB60@post.pc.aspectgroup.co.uk> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5083 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 Content-Length: 347 Lines: 10 On Tue, 19 Aug 2003 23:12:38 +0100 Richard Underwood wrote: > I'm certain that Cisco (for example) won't change their ways. I don't believe this. In cases where we've been able to show their devices to be faulty, they've fixed their kit. Go check out what happened wrt. the ECN issues their firewall products had. From romieu@fr.zoreil.com Tue Aug 19 15:41:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 15:41:31 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JMfOFl031398 for ; Tue, 19 Aug 2003 15:41:25 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id h7JMamxA026427; Wed, 20 Aug 2003 00:36:48 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id h7JMamhL026426; Wed, 20 Aug 2003 00:36:48 +0200 Date: Wed, 20 Aug 2003 00:36:48 +0200 From: Francois Romieu To: Stephen Hemminger Cc: Jean Tourrilhes , "David S. Miller" , irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] (4/4) convert irlan to seq_file interface Message-ID: <20030820003648.A23942@electric-eye.fr.zoreil.com> References: <20030818122702.67e9162d.shemminger@osdl.org> <20030818232554.A7779@electric-eye.fr.zoreil.com> <20030818150514.310f6f5d.shemminger@osdl.org> <20030819002637.B7779@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030819002637.B7779@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Tue, Aug 19, 2003 at 12:26:37AM +0200 X-archive-position: 5084 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1778 Lines: 57 Apply on top of Stephen's serie [1-4]. Compile ok. Style: separate data from code. net/irda/irlan/irlan_filter.c | 34 ++++++++++++++++++++-------------- 1 files changed, 20 insertions(+), 14 deletions(-) diff -puN net/irda/irlan/irlan_filter.c~irlan-fr-0 net/irda/irlan/irlan_filter.c --- linux-2.6.0-test3/net/irda/irlan/irlan_filter.c~irlan-fr-0 Wed Aug 20 00:07:37 2003 +++ linux-2.6.0-test3-fr/net/irda/irlan/irlan_filter.c Wed Aug 20 00:18:50 2003 @@ -218,23 +218,29 @@ void irlan_check_command_param(struct ir * */ #ifdef CONFIG_PROC_FS +#define MASK2STR(m,s) { .mask = m, .str = s } + void irlan_print_filter(struct seq_file *seq, int filter_type) { - if (filter_type & IRLAN_DIRECTED) - seq_printf(seq, "%s", "DIRECTED "); - if (filter_type & IRLAN_FUNCTIONAL) - seq_printf(seq, "%s", "FUNCTIONAL "); - if (filter_type & IRLAN_GROUP) - seq_printf(seq, "%s", "GROUP "); - if (filter_type & IRLAN_MAC_FRAME) - seq_printf(seq, "%s", "MAC_FRAME "); - if (filter_type & IRLAN_MULTICAST) - seq_printf(seq, "%s", "MULTICAST "); - if (filter_type & IRLAN_BROADCAST) - seq_printf(seq, "%s", "BROADCAST "); - if (filter_type & IRLAN_IPX_SOCKET) - seq_printf(seq, "%s", "IPX_SOCKET"); + static struct { + int mask; + const char *str; + } filter_mask2str[] = { + MASK2STR(IRLAN_DIRECTED, "DIRECTED"), + MASK2STR(IRLAN_FUNCTIONAL, "FUNCTIONAL"), + MASK2STR(IRLAN_GROUP, "GROUP"), + MASK2STR(IRLAN_MAC_FRAME, "MAC_FRAME"), + MASK2STR(IRLAN_MULTICAST, "MULTICAST"), + MASK2STR(IRLAN_BROADCAST, "BROADCAST"), + MASK2STR(IRLAN_IPX_SOCKET, "IPX_SOCKET"), + MASK2STR(0, NULL) + }, *p; + for (p = filter_mask2str; p->str; p++) { + if (filter_type & p->mask) + seq_printf(seq, "%s ", p->str); + } seq_putc(seq, '\n'); } +#undef MASK2STR #endif _ From shemminger@osdl.org Tue Aug 19 15:56:56 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 15:57:00 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JMurFl032753 for ; Tue, 19 Aug 2003 15:56:55 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7JMufo15152; Tue, 19 Aug 2003 15:56:41 -0700 Date: Tue, 19 Aug 2003 15:56:29 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] get rid of unused argument Message-Id: <20030819155629.7201f947.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5085 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 773 Lines: 24 dev_get_idx doesn't need the first arg.. diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c Tue Aug 19 15:55:00 2003 +++ b/net/core/dev.c Tue Aug 19 15:55:00 2003 @@ -1836,8 +1836,7 @@ * This is invoked by the /proc filesystem handler to display a device * in detail. */ -static __inline__ struct net_device *dev_get_idx(struct seq_file *seq, - loff_t pos) +static __inline__ struct net_device *dev_get_idx(loff_t pos) { struct net_device *dev; loff_t i; @@ -1850,7 +1849,7 @@ void *dev_seq_start(struct seq_file *seq, loff_t *pos) { read_lock(&dev_base_lock); - return *pos ? dev_get_idx(seq, *pos - 1) : (void *)1; + return *pos ? dev_get_idx(*pos - 1) : (void *)1; } void *dev_seq_next(struct seq_file *seq, void *v, loff_t *pos) From shemminger@osdl.org Tue Aug 19 15:59:32 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 15:59:40 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JMxUFl000608 for ; Tue, 19 Aug 2003 15:59:31 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7JMwxo15981; Tue, 19 Aug 2003 15:58:59 -0700 Date: Tue, 19 Aug 2003 15:58:47 -0700 From: Stephen Hemminger To: Jeff Garzik Cc: jt@hpl.hp.com, "David S. Miller" , irda-users@lists.sourceforge.net, netdev@oss.sgi.com, lists@mdiehl.de Subject: [PATCH] kill old irtty Message-Id: <20030819155847.6ea122e9.shemminger@osdl.org> In-Reply-To: <3F416A5E.2060302@pobox.com> References: <20030815154608.56cf0551.shemminger@osdl.org> <20030815230546.GA31831@bougret.hpl.hp.com> <20030816052048.5858d68a.davem@redhat.com> <20030817001405.GA1916@bougret.hpl.hp.com> <20030816175851.58a2c179.davem@redhat.com> <20030817011131.GA2120@bougret.hpl.hp.com> <20030818090313.7f153d7a.shemminger@osdl.org> <20030818165024.GB5992@bougret.hpl.hp.com> <20030818165321.GH24693@gtf.org> <20030818170850.GE5992@bougret.hpl.hp.com> <3F416A5E.2060302@pobox.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7JMxUFl000608 X-archive-position: 5086 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 29738 Lines: 1101 As suggested by Jean and Jeff, kill the old irtty driver since it is replaced by irtty-sir diff -Nru a/drivers/net/irda/Kconfig b/drivers/net/irda/Kconfig --- a/drivers/net/irda/Kconfig Tue Aug 19 15:54:22 2003 +++ b/drivers/net/irda/Kconfig Tue Aug 19 15:54:22 2003 @@ -68,20 +68,6 @@ comment "Old SIR device drivers" -config IRTTY_OLD - tristate "Old IrTTY (broken)" - depends on IRDA && EXPERIMENTAL - help - Say Y here if you want to build support for the IrTTY line - discipline. If you want to compile it as a module (irtty), say M - here and read . IrTTY makes it - possible to use Linux's own serial driver for all IrDA ports that - are 16550 compatible. Most IrDA chips are 16550 compatible so you - should probably say Y to this option. Using IrTTY will however - limit the speed of the connection to 115200 bps (IrDA SIR mode). - - If unsure, say N. - config IRPORT_SIR tristate "IrPORT (IrDA serial driver)" depends on IRDA diff -Nru a/drivers/net/irda/Makefile b/drivers/net/irda/Makefile --- a/drivers/net/irda/Makefile Tue Aug 19 15:54:22 2003 +++ b/drivers/net/irda/Makefile Tue Aug 19 15:54:22 2003 @@ -5,8 +5,7 @@ # Rewritten to use lists instead of if-statements. # -# Old SIR drivers (irtty is broken) -obj-$(CONFIG_IRTTY_OLD) += irtty.o +# Old SIR drivers obj-$(CONFIG_IRPORT_SIR) += irport.o # FIR drivers obj-$(CONFIG_USB_IRDA) += irda-usb.o diff -Nru a/drivers/net/irda/irtty.c b/drivers/net/irda/irtty.c --- a/drivers/net/irda/irtty.c Tue Aug 19 15:54:22 2003 +++ /dev/null Wed Dec 31 16:00:00 1969 @@ -1,1055 +0,0 @@ -/********************************************************************* - * - * Filename: irtty.c - * Version: 1.1 - * Description: IrDA line discipline implementation - * Status: Experimental. - * Author: Dag Brattli - * Created at: Tue Dec 9 21:18:38 1997 - * Modified at: Sat Mar 11 07:43:30 2000 - * Modified by: Dag Brattli - * Sources: slip.c by Laurence Culhane, - * Fred N. van Kempen, - * - * Copyright (c) 1998-2000 Dag Brattli, All Rights Reserved. - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation; either version 2 of - * the License, or (at your option) any later version. - * - * Neither Dag Brattli nor University of Tromsø admit liability nor - * provide warranty for any of this software. This material is - * provided "AS-IS" and at no charge. - * - ********************************************************************/ - -#include -#include -#include -#include -#include -#include -#include - -#include - -#include -#include -#include -#include - -static int qos_mtt_bits = 0x03; /* 5 ms or more */ - -/* Network device fuction prototypes */ -static int irtty_hard_xmit(struct sk_buff *skb, struct net_device *dev); -static int irtty_net_open(struct net_device *dev); -static int irtty_net_close(struct net_device *dev); -static int irtty_net_ioctl(struct net_device *dev, struct ifreq *rq, int cmd); -static struct net_device_stats *irtty_net_get_stats(struct net_device *dev); - -/* Line discipline function prototypes */ -static int irtty_open(struct tty_struct *tty); -static void irtty_close(struct tty_struct *tty); -static int irtty_ioctl(struct tty_struct *, struct file *, - unsigned int, unsigned long); -static int irtty_receive_room(struct tty_struct *tty); -static void irtty_write_wakeup(struct tty_struct *tty); -static void irtty_receive_buf(struct tty_struct *, const unsigned char *, - char *, int); - -/* IrDA specific function protoctypes */ -static int irtty_is_receiving(struct irtty_cb *self); -static int irtty_set_dtr_rts(struct net_device *dev, int dtr, int rts); -static int irtty_raw_write(struct net_device *dev, __u8 *buf, int len); -static int irtty_raw_read(struct net_device *dev, __u8 *buf, int len); -static int irtty_set_mode(struct net_device *dev, int mode); -static int irtty_change_speed(struct irda_task *task); - -static struct tty_ldisc irda_ldisc = { - .owner = THIS_MODULE, - .magic = TTY_LDISC_MAGIC, - .name = "irda", - .open = irtty_open, - .close = irtty_close, - .ioctl = irtty_ioctl, - .receive_buf = irtty_receive_buf, - .receive_room = irtty_receive_room, - .write_wakeup = irtty_write_wakeup, -}; - -int __init irtty_init(void) -{ - int status; - - if ((status = tty_register_ldisc(N_IRDA, &irda_ldisc)) != 0) { - ERROR("IrDA: can't register line discipline (err = %d)\n", - status); - } - - return status; -} - -/* - * Function irtty_cleanup ( ) - * - * Called when the irda module is removed. Here we remove all instances - * of the driver, and the master array. - */ -static void __exit irtty_cleanup(void) -{ - int ret; - - /* Unregister tty line-discipline */ - if ((ret = tty_register_ldisc(N_IRDA, NULL))) { - ERROR("%s(), can't unregister line discipline (err = %d)\n", - __FUNCTION__, ret); - } - -} - -/* - * Function irtty_open(tty) - * - * This function is called by the TTY module when the IrDA line - * discipline is called for. Because we are sure the tty line exists, - * we only have to link it to a free IrDA channel. - */ -static int irtty_open(struct tty_struct *tty) -{ - struct net_device *dev; - struct irtty_cb *self; - int err; - - IRDA_DEBUG(2, "%s()\n", __FUNCTION__); - ASSERT(tty != NULL, return -EEXIST;); - - /* First make sure we're not already connected. */ - self = (struct irtty_cb *) tty->disc_data; - - if (self != NULL && self->magic == IRTTY_MAGIC) - return -EEXIST; - - /* - * Allocate new instance of the driver - */ - dev = alloc_netdev(sizeof(struct irtty_cb), "irda%d", - irda_device_setup); - if (dev == NULL) { - printk(KERN_ERR "IrDA: Can't allocate memory for " - "IrDA control block!\n"); - return -ENOMEM; - } - - self = dev->priv; - self->netdev = dev; - spin_lock_init(&self->lock); - self->tty = tty; - tty->disc_data = self; - - if (tty->driver->flush_buffer) - tty->driver->flush_buffer(tty); - if (tty->ldisc.flush_buffer) - tty->ldisc.flush_buffer(tty); - self->magic = IRTTY_MAGIC; - self->mode = IRDA_IRLAP; - - /* - * Initialize QoS capabilities, we fill in all the stuff that - * we support. Be careful not to place any restrictions on values - * that are not device dependent (such as link disconnect time) so - * this parameter can be set by IrLAP (or the user) instead. DB - */ - irda_init_max_qos_capabilies(&self->qos); - - /* The only value we must override it the baudrate */ - self->qos.baud_rate.bits = IR_9600|IR_19200|IR_38400|IR_57600| - IR_115200; - self->qos.min_turn_time.bits = qos_mtt_bits; - self->flags = IFF_SIR | IFF_PIO; - irda_qos_bits_to_value(&self->qos); - - /* Specify how much memory we want */ - self->rx_buff.truesize = 4000; - self->tx_buff.truesize = 4000; - - /* Allocate memory if needed */ - if (self->rx_buff.truesize > 0) { - self->rx_buff.head = (__u8 *) kmalloc(self->rx_buff.truesize, - GFP_KERNEL); - if (self->rx_buff.head == NULL) - return -ENOMEM; - memset(self->rx_buff.head, 0, self->rx_buff.truesize); - } - if (self->tx_buff.truesize > 0) { - self->tx_buff.head = (__u8 *) kmalloc(self->tx_buff.truesize, - GFP_KERNEL); - if (self->tx_buff.head == NULL) { - kfree(self->rx_buff.head); - return -ENOMEM; - } - memset(self->tx_buff.head, 0, self->tx_buff.truesize); - } - self->rx_buff.in_frame = FALSE; - self->rx_buff.state = OUTSIDE_FRAME; - self->tx_buff.data = self->tx_buff.head; - self->rx_buff.data = self->rx_buff.head; - - /* Override the network functions we need to use */ - dev->hard_start_xmit = irtty_hard_xmit; - dev->open = irtty_net_open; - dev->stop = irtty_net_close; - dev->get_stats = irtty_net_get_stats; - dev->do_ioctl = irtty_net_ioctl; - - err = register_netdev(dev); - if (err) { - ERROR("%s(), register_netdev() failed!\n", __FUNCTION__); - kfree(dev); - return -1; - } - - MESSAGE("IrDA: Registered device %s\n", dev->name); - - return 0; -} - -/* - * Function irtty_close (tty) - * - * Close down a IrDA channel. This means flushing out any pending queues, - * and then restoring the TTY line discipline to what it was before it got - * hooked to IrDA (which usually is TTY again). - */ -static void irtty_close(struct tty_struct *tty) -{ - struct irtty_cb *self = (struct irtty_cb *) tty->disc_data; - unsigned long flags; - - IRDA_DEBUG(2, "%s()\n", __FUNCTION__); - - /* First make sure we're connected. */ - if (self == NULL || self->tty != tty) - return; - - ASSERT(self->magic == IRTTY_MAGIC, return;); - - /* Stop tty */ - tty->flags &= ~(1 << TTY_DO_WRITE_WAKEUP); - tty->disc_data = 0; - - /* We are not using any dongle anymore! */ - if (self->dongle) - irda_device_dongle_cleanup(self->dongle); - self->dongle = NULL; - - /* Protect access to self->task and self->?x_buff - Jean II */ - spin_lock_irqsave(&self->lock, flags); - - /* Remove speed changing task if any */ - if (self->task) - irda_task_delete(self->task); - - self->tty = NULL; - self->magic = 0; - - if (self->tx_buff.head) - kfree(self->tx_buff.head); - - if (self->rx_buff.head) - kfree(self->rx_buff.head); - spin_unlock_irqrestore(&self->lock, flags); - - /* Remove netdevice */ - unregister_netdev(self->netdev); -} - -/* - * Function irtty_stop_receiver (self, stop) - * - * - * - */ -static void irtty_stop_receiver(struct irtty_cb *self, int stop) -{ - struct termios old_termios; - int cflag; - - old_termios = *(self->tty->termios); - cflag = self->tty->termios->c_cflag; - - if (stop) - cflag &= ~CREAD; - else - cflag |= CREAD; - - /* This is unsafe, but currently under discussion - Jean II */ - self->tty->termios->c_cflag = cflag; - self->tty->driver->set_termios(self->tty, &old_termios); -} - -/* - * Function irtty_do_change_speed (self, speed) - * - * Change the speed of the serial port. - */ -static void __irtty_change_speed(struct irtty_cb *self, __u32 speed) -{ - struct termios old_termios; - int cflag; - - ASSERT(self != NULL, return;); - ASSERT(self->magic == IRTTY_MAGIC, return;); - - old_termios = *(self->tty->termios); - cflag = self->tty->termios->c_cflag; - - cflag &= ~CBAUD; - - IRDA_DEBUG(2, "%s(), Setting speed to %d\n", __FUNCTION__, speed); - - switch (speed) { - case 1200: - cflag |= B1200; - break; - case 2400: - cflag |= B2400; - break; - case 4800: - cflag |= B4800; - break; - case 19200: - cflag |= B19200; - break; - case 38400: - cflag |= B38400; - break; - case 57600: - cflag |= B57600; - break; - case 115200: - cflag |= B115200; - break; - case 9600: - default: - cflag |= B9600; - break; - } - - /* This is unsafe, but currently under discussion - Jean II */ - self->tty->termios->c_cflag = cflag; - self->tty->driver->set_termios(self->tty, &old_termios); - - self->io.speed = speed; -} - -/* - * Function irtty_change_speed (instance, state, param) - * - * State machine for changing speed of the device. We do it this way since - * we cannot use schedule_timeout() when we are in interrupt context - */ -static int irtty_change_speed(struct irda_task *task) -{ - struct irtty_cb *self; - unsigned long flags; - __u32 speed = (__u32) task->param; - int ret = 0; - - IRDA_DEBUG(2, "%s(), <%ld>\n", __FUNCTION__, jiffies); - - self = (struct irtty_cb *) task->instance; - ASSERT(self != NULL, return -1;); - - /* Protect access to self->task - Jean II */ - spin_lock_irqsave(&self->lock, flags); - - /* Check if busy */ - if (self->task && self->task != task) { - IRDA_DEBUG(0, "%s(), busy!\n", __FUNCTION__); - spin_unlock_irqrestore(&self->lock, flags); - return MSECS_TO_JIFFIES(10); - } else - self->task = task; - spin_unlock_irqrestore(&self->lock, flags); - - switch (task->state) { - case IRDA_TASK_INIT: - /* - * Make sure all data is sent before changing the speed of the - * serial port. - */ - if (self->tty->driver->chars_in_buffer(self->tty)) { - /* Keep state, and try again later */ - ret = MSECS_TO_JIFFIES(10); - break; - } else { - /* Transmit buffer is now empty, but it may still - * take over 13 ms for the FIFO to become empty, so - * wait some more to be sure all data is sent - */ - irda_task_next_state(task, IRDA_TASK_WAIT); - ret = MSECS_TO_JIFFIES(13); - } - case IRDA_TASK_WAIT: - if (self->dongle) - irda_task_next_state(task, IRDA_TASK_CHILD_INIT); - else - irda_task_next_state(task, IRDA_TASK_CHILD_DONE); - break; - case IRDA_TASK_CHILD_INIT: - /* Go to default speed */ - __irtty_change_speed(self, 9600); - - /* Change speed of dongle */ - if (irda_task_execute(self->dongle, - self->dongle->issue->change_speed, - NULL, task, (void *) speed)) - { - /* Dongle need more time to change its speed */ - irda_task_next_state(task, IRDA_TASK_CHILD_WAIT); - - /* Give dongle 1 sec to finish */ - ret = MSECS_TO_JIFFIES(1000); - } else - /* Child finished immediately */ - irda_task_next_state(task, IRDA_TASK_CHILD_DONE); - break; - case IRDA_TASK_CHILD_WAIT: - WARNING("%s(), changing speed of dongle timed out!\n", __FUNCTION__); - ret = -1; - break; - case IRDA_TASK_CHILD_DONE: - /* Finally we are ready to change the speed */ - __irtty_change_speed(self, speed); - - irda_task_next_state(task, IRDA_TASK_DONE); - self->task = NULL; - break; - default: - ERROR("%s(), unknown state %d\n", __FUNCTION__, task->state); - irda_task_next_state(task, IRDA_TASK_DONE); - self->task = NULL; - ret = -1; - break; - } - return ret; -} - -/* - * Function irtty_ioctl (tty, file, cmd, arg) - * - * The Swiss army knife of system calls :-) - * - */ -static int irtty_ioctl(struct tty_struct *tty, struct file *file, - unsigned int cmd, unsigned long arg) -{ - dongle_t *dongle; - struct irtty_info info; - struct irtty_cb *self; - int size = _IOC_SIZE(cmd); - int err = 0; - - self = (struct irtty_cb *) tty->disc_data; - - ASSERT(self != NULL, return -ENODEV;); - ASSERT(self->magic == IRTTY_MAGIC, return -EBADR;); - - if (_IOC_DIR(cmd) & _IOC_READ) - err = verify_area(VERIFY_WRITE, (void *) arg, size); - else if (_IOC_DIR(cmd) & _IOC_WRITE) - err = verify_area(VERIFY_READ, (void *) arg, size); - if (err) - return err; - - switch (cmd) { - case TCGETS: - case TCGETA: - /* Unsure about locking here, to check - Jean II */ - return n_tty_ioctl(tty, (struct file *) file, cmd, arg); - break; - case IRTTY_IOCTDONGLE: - /* Initialize dongle */ - dongle = irda_device_dongle_init(self->netdev, (int) arg); - if (!dongle) - break; - - /* Initialize callbacks */ - dongle->set_mode = irtty_set_mode; - dongle->read = irtty_raw_read; - dongle->write = irtty_raw_write; - dongle->set_dtr_rts = irtty_set_dtr_rts; - - /* Now initialize the dongle! */ - dongle->issue->open(dongle, &self->qos); - - /* Reset dongle */ - irda_task_execute(dongle, dongle->issue->reset, NULL, NULL, - NULL); - - /* Make dongle available to driver only now to avoid - * race conditions - Jean II */ - self->dongle = dongle; - break; - case IRTTY_IOCGET: - ASSERT(self->netdev != NULL, return -1;); - - memset(&info, 0, sizeof(struct irtty_info)); - strncpy(info.name, self->netdev->name, 5); - - if (copy_to_user((void *) arg, &info, sizeof(struct irtty_info))) - return -EFAULT; - break; - default: - return -ENOIOCTLCMD; - } - return 0; -} - -/* - * Function irtty_receive_buf( tty, cp, count) - * - * Handle the 'receiver data ready' interrupt. This function is called - * by the 'tty_io' module in the kernel when a block of IrDA data has - * been received, which can now be decapsulated and delivered for - * further processing - */ -static void irtty_receive_buf(struct tty_struct *tty, const unsigned char *cp, - char *fp, int count) -{ - struct irtty_cb *self = (struct irtty_cb *) tty->disc_data; - - if (!self || !self->netdev) { - IRDA_DEBUG(0, "%s(), not ready yet!\n", __FUNCTION__); - return; - } - - // Are we in interrupt context ? What locking is done ? - Jean II - //spin_lock_irqsave(&self->lock, flags); - - /* Read the characters out of the buffer */ - while (count--) { - /* - * Characters received with a parity error, etc? - */ - if (fp && *fp++) { - IRDA_DEBUG(0, "Framing or parity error!\n"); - irda_device_set_media_busy(self->netdev, TRUE); - - cp++; - continue; - } - - switch (self->mode) { - case IRDA_IRLAP: - /* Unwrap and destuff one byte */ - async_unwrap_char(self->netdev, &self->stats, - &self->rx_buff, *cp++); - break; - case IRDA_RAW: - /* What should we do when the buffer is full? */ - if (self->rx_buff.len == self->rx_buff.truesize) - self->rx_buff.len = 0; - - self->rx_buff.data[self->rx_buff.len++] = *cp++; - break; - default: - break; - } - } - //spin_unlock_irqrestore(&self->lock, flags); -} - -/* - * Function irtty_change_speed_complete (task) - * - * Called when the change speed operation completes - * - */ -static int irtty_change_speed_complete(struct irda_task *task) -{ - struct irtty_cb *self; - - IRDA_DEBUG(2, "%s()\n", __FUNCTION__); - - self = (struct irtty_cb *) task->instance; - - ASSERT(self != NULL, return -1;); - ASSERT(self->netdev != NULL, return -1;); - - /* Finished changing speed, so we are not busy any longer */ - /* Signal network layer so it can try to send the frame */ - netif_wake_queue(self->netdev); - - return 0; -} - -/* - * Function irtty_hard_xmit (skb, dev) - * - * Transmit frame - * - */ -static int irtty_hard_xmit(struct sk_buff *skb, struct net_device *dev) -{ - struct irtty_cb *self; - int actual = 0; - __s32 speed; - unsigned long flags; - - self = (struct irtty_cb *) dev->priv; - ASSERT(self != NULL, return 0;); - - /* Lock transmit buffer - * this serialise operations, no need to spinlock - Jean II */ - netif_stop_queue(dev); - - /* Check if we need to change the speed */ - speed = irda_get_next_speed(skb); - if ((speed != self->io.speed) && (speed != -1)) { - /* Check for empty frame */ - if (!skb->len) { - irda_task_execute(self, irtty_change_speed, - irtty_change_speed_complete, - NULL, (void *) speed); - dev_kfree_skb(skb); - return 0; - } else - self->new_speed = speed; - } - - /* Protect access to self->tx_buff - Jean II */ - spin_lock_irqsave(&self->lock, flags); - - /* Init tx buffer*/ - self->tx_buff.data = self->tx_buff.head; - - /* Copy skb to tx_buff while wrapping, stuffing and making CRC */ - self->tx_buff.len = async_wrap_skb(skb, self->tx_buff.data, - self->tx_buff.truesize); - - self->tty->flags |= (1 << TTY_DO_WRITE_WAKEUP); - - dev->trans_start = jiffies; - self->stats.tx_bytes += self->tx_buff.len; - - if (self->tty->driver->write) - actual = self->tty->driver->write(self->tty, 0, - self->tx_buff.data, - self->tx_buff.len); - /* Hide the part we just transmitted */ - self->tx_buff.data += actual; - self->tx_buff.len -= actual; - - spin_unlock_irqrestore(&self->lock, flags); - - dev_kfree_skb(skb); - - return 0; -} - -/* - * Function irtty_receive_room (tty) - * - * Used by the TTY to find out how much data we can receive at a time - * -*/ -static int irtty_receive_room(struct tty_struct *tty) -{ - IRDA_DEBUG(0, "%s()\n", __FUNCTION__); - return 65536; /* We can handle an infinite amount of data. :-) */ -} - -/* - * Function irtty_write_wakeup (tty) - * - * Called by the driver when there's room for more data. If we have - * more packets to send, we send them here. - * - */ -static void irtty_write_wakeup(struct tty_struct *tty) -{ - struct irtty_cb *self = (struct irtty_cb *) tty->disc_data; - int actual = 0; - unsigned long flags; - - /* - * First make sure we're connected. - */ - ASSERT(self != NULL, return;); - ASSERT(self->magic == IRTTY_MAGIC, return;); - - /* Protected via netif_stop_queue(dev); - Jean II */ - - /* Protect access to self->tx_buff - Jean II */ - spin_lock_irqsave(&self->lock, flags); - - /* Finished with frame? */ - if (self->tx_buff.len > 0) { - /* Write data left in transmit buffer */ - actual = tty->driver->write(tty, 0, self->tx_buff.data, - self->tx_buff.len); - - self->tx_buff.data += actual; - self->tx_buff.len -= actual; - spin_unlock_irqrestore(&self->lock, flags); - } else { - /* - * Now serial buffer is almost free & we can start - * transmission of another packet - */ - IRDA_DEBUG(5, "%s(), finished with frame!\n", __FUNCTION__); - - self->stats.tx_packets++; - - tty->flags &= ~(1 << TTY_DO_WRITE_WAKEUP); - - /* Don't change speed with irq off */ - spin_unlock_irqrestore(&self->lock, flags); - - if (self->new_speed) { - IRDA_DEBUG(5, "%s(), Changing speed!\n", __FUNCTION__); - irda_task_execute(self, irtty_change_speed, - irtty_change_speed_complete, - NULL, (void *) self->new_speed); - self->new_speed = 0; - } else { - /* Tell network layer that we want more frames */ - netif_wake_queue(self->netdev); - } - } -} - -/* - * Function irtty_is_receiving (self) - * - * Return TRUE is we are currently receiving a frame - * - */ -static int irtty_is_receiving(struct irtty_cb *self) -{ - return (self->rx_buff.state != OUTSIDE_FRAME); -} - -/* - * Function irtty_set_dtr_rts (tty, dtr, rts) - * - * This function can be used by dongles etc. to set or reset the status - * of the dtr and rts lines - */ -static int irtty_set_dtr_rts(struct net_device *dev, int dtr, int rts) -{ - struct irtty_cb *self; - struct tty_struct *tty; - //unsigned long flags; - mm_segment_t fs; - int arg = 0; - - self = (struct irtty_cb *) dev->priv; - tty = self->tty; - - /* Was protected in ioctl handler, but the serial driver doesn't - * like it. This may need to change. - Jean II */ - //spin_lock_irqsave(&self->lock, flags); - -#ifdef TIOCM_OUT2 /* Not defined for ARM */ - arg = TIOCM_OUT2; -#endif - if (rts) - arg |= TIOCM_RTS; - if (dtr) - arg |= TIOCM_DTR; - - /* - * The ioctl() function, or actually set_modem_info() in serial.c - * expects a pointer to the argument in user space. To hack us - * around this, we use the set_fs() function to fool the routines - * that check if they are called from user space. We also need - * to send a pointer to the argument so get_user() gets happy. DB. - */ - - fs = get_fs(); - set_fs(get_ds()); - - /* This is probably unsafe, but currently under discussion - Jean II */ - if (tty->driver->ioctl(tty, NULL, TIOCMSET, (unsigned long) &arg)) { - IRDA_DEBUG(2, "%s(), error doing ioctl!\n", __FUNCTION__); - } - set_fs(fs); - - //spin_unlock_irqrestore(&self->lock, flags); - - return 0; -} - -/* - * Function irtty_set_mode (self, status) - * - * For the airport dongle, we need support for reading raw characters - * from the IrDA device. This function switches between those modes. - * FALSE is the default mode, and will then treat incoming data as IrDA - * packets. - */ -int irtty_set_mode(struct net_device *dev, int mode) -{ - struct irtty_cb *self; - unsigned long flags; - - self = (struct irtty_cb *) dev->priv; - - ASSERT(self != NULL, return -1;); - - IRDA_DEBUG(2, "%s(), mode=%s\n", __FUNCTION__, infrared_mode[mode]); - - /* Protect access to self->rx_buff - Jean II */ - spin_lock_irqsave(&self->lock, flags); - - /* save status for driver */ - self->mode = mode; - - /* reset the buffer state */ - self->rx_buff.data = self->rx_buff.head; - self->rx_buff.len = 0; - self->rx_buff.state = OUTSIDE_FRAME; - - spin_unlock_irqrestore(&self->lock, flags); - - return 0; -} - -/* - * Function irtty_raw_read (self, buf, len) - * - * Receive incoming data. This function sleeps, so it must only be - * called with a process context. Timeout is currently defined to be - * a multiple of 10 ms. - */ -static int irtty_raw_read(struct net_device *dev, __u8 *buf, int len) -{ - struct irtty_cb *self; - int count; - - self = (struct irtty_cb *) dev->priv; - - ASSERT(self != NULL, return 0;); - ASSERT(self->magic == IRTTY_MAGIC, return 0;); - - return 0; -#if 0 - buf = self->rx_buff.data; - - /* Wait for the requested amount of data to arrive */ - while (len < self->rx_buff.len) { - current->state = TASK_INTERRUPTIBLE; - schedule_timeout(MSECS_TO_JIFFIES(10)); - - if (!timeout--) - break; - } - - count = self->rx_buff.len < len ? self->rx_buff.len : len; - - /* - * Reset the state, this mean that a raw read is sort of a - * datagram read, and _not_ a stream style read. Be aware of the - * difference. Implementing it the other way will just be painful ;-) - */ - self->rx_buff.data = self->rx_buff.head; - self->rx_buff.len = 0; - self->rx_buff.state = OUTSIDE_FRAME; -#endif - /* Return the amount we were able to get */ - return count; -} - -static int irtty_raw_write(struct net_device *dev, __u8 *buf, int len) -{ - struct irtty_cb *self; - int actual = 0; - - self = (struct irtty_cb *) dev->priv; - - ASSERT(self != NULL, return 0;); - ASSERT(self->magic == IRTTY_MAGIC, return 0;); - - if (self->tty->driver->write) - actual = self->tty->driver->write(self->tty, 0, buf, len); - - return actual; -} - -static int irtty_net_open(struct net_device *dev) -{ - struct irtty_cb *self = (struct irtty_cb *) dev->priv; - struct tty_struct *tty = self->tty; - - IRDA_DEBUG(0, "%s()\n", __FUNCTION__); - - ASSERT(self != NULL, return -1;); - ASSERT(self->magic == IRTTY_MAGIC, return -1;); - - /* Ready to play! */ - netif_start_queue(dev); - - /* Make sure we can receive more data */ - irtty_stop_receiver(self, FALSE); - - /* - * Open new IrLAP layer instance, now that everything should be - * initialized properly - */ - self->irlap = irlap_open(dev, &self->qos, tty->name); - - return 0; -} - -static int irtty_net_close(struct net_device *dev) -{ - struct irtty_cb *self = (struct irtty_cb *) dev->priv; - - IRDA_DEBUG(0, "%s()\n", __FUNCTION__); - - ASSERT(self != NULL, return -1;); - ASSERT(self->magic == IRTTY_MAGIC, return -1;); - - /* Make sure we don't receive more data */ - irtty_stop_receiver(self, TRUE); - - /* Stop device */ - netif_stop_queue(dev); - - /* Stop and remove instance of IrLAP */ - if (self->irlap) - irlap_close(self->irlap); - self->irlap = NULL; - - return 0; -} - -/* - * Function irtty_net_ioctl (dev, rq, cmd) - * - * Process IOCTL commands for this device - * - */ -static int irtty_net_ioctl(struct net_device *dev, struct ifreq *rq, int cmd) -{ - struct if_irda_req *irq = (struct if_irda_req *) rq; - struct irtty_cb *self; - dongle_t *dongle; - int ret = 0; - - ASSERT(dev != NULL, return -1;); - - self = dev->priv; - - ASSERT(self != NULL, return -1;); - ASSERT(self->magic == IRTTY_MAGIC, return -1;); - - IRDA_DEBUG(3, "%s(), %s, (cmd=0x%X)\n", __FUNCTION__, dev->name, cmd); - - /* Locking : - * irda_device_dongle_init() can't be locked. - * irda_task_execute() doesn't need to be locked (but - * irtty_change_speed() should protect itself). - * Other calls protect themselves. - * Jean II - */ - - switch (cmd) { - case SIOCSBANDWIDTH: /* Set bandwidth */ - if (!capable(CAP_NET_ADMIN)) - ret = -EPERM; - else - irda_task_execute(self, irtty_change_speed, NULL, NULL, - (void *) irq->ifr_baudrate); - break; - case SIOCSDONGLE: /* Set dongle */ - if (!capable(CAP_NET_ADMIN)) { - ret = -EPERM; - break; - } - - /* Initialize dongle */ - dongle = irda_device_dongle_init(dev, irq->ifr_dongle); - if (!dongle) - break; - - dongle->set_mode = irtty_set_mode; - dongle->read = irtty_raw_read; - dongle->write = irtty_raw_write; - dongle->set_dtr_rts = irtty_set_dtr_rts; - - /* Now initialize the dongle! - * Safe to do unlocked : self->dongle is still NULL. */ - dongle->issue->open(dongle, &self->qos); - - /* Reset dongle */ - irda_task_execute(dongle, dongle->issue->reset, NULL, NULL, - NULL); - - /* Make dongle available to driver only now to avoid - * race conditions - Jean II */ - self->dongle = dongle; - break; - case SIOCSMEDIABUSY: /* Set media busy */ - if (!capable(CAP_NET_ADMIN)) - ret = -EPERM; - else - irda_device_set_media_busy(self->netdev, TRUE); - break; - case SIOCGRECEIVING: /* Check if we are receiving right now */ - irq->ifr_receiving = irtty_is_receiving(self); - break; - case SIOCSDTRRTS: - if (!capable(CAP_NET_ADMIN)) - ret = -EPERM; - else { - irtty_set_dtr_rts(dev, irq->ifr_dtr, irq->ifr_rts); - } - break; - case SIOCSMODE: - if (!capable(CAP_NET_ADMIN)) - ret = -EPERM; - else { - irtty_set_mode(dev, irq->ifr_mode); - } - break; - default: - ret = -EOPNOTSUPP; - } - - return ret; -} - -static struct net_device_stats *irtty_net_get_stats(struct net_device *dev) -{ - struct irtty_cb *self = (struct irtty_cb *) dev->priv; - - return &self->stats; -} - -MODULE_AUTHOR("Dag Brattli "); -MODULE_DESCRIPTION("IrDA TTY device driver"); -MODULE_LICENSE("GPL"); - - -MODULE_PARM(qos_mtt_bits, "i"); -MODULE_PARM_DESC(qos_mtt_bits, "Minimum Turn Time"); - -/* - * Function init_module (void) - * - * Initialize IrTTY module - * - */ -module_init(irtty_init); - -/* - * Function cleanup_module (void) - * - * Cleanup IrTTY module - * - */ -module_exit(irtty_cleanup); From shemminger@osdl.org Tue Aug 19 16:04:09 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 16:04:12 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JN49Fl001025 for ; Tue, 19 Aug 2003 16:04:09 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7JN41o17354; Tue, 19 Aug 2003 16:04:01 -0700 Date: Tue, 19 Aug 2003 16:03:49 -0700 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] sis190 - missing arg to synchronize irq Message-Id: <20030819160349.3e139fdd.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5087 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 404 Lines: 15 Don't have this hardware, but it looks like a simple "never been built on SMP" typo. diff -Nru a/drivers/net/sis190.c b/drivers/net/sis190.c --- a/drivers/net/sis190.c Tue Aug 19 16:02:43 2003 +++ b/drivers/net/sis190.c Tue Aug 19 16:02:43 2003 @@ -1111,7 +1111,7 @@ spin_unlock_irq(&tp->lock); - synchronize_irq(); + synchronize_irq(dev->irq); free_irq(dev->irq, dev); SiS190_tx_clear(tp); From skraw@ithnet.com Tue Aug 19 16:15:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 16:15:51 -0700 (PDT) Received: from heather-ng.ithnet.com (mail3.ithnet.com [217.64.64.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JNFgFl001851 for ; Tue, 19 Aug 2003 16:15:43 -0700 Received: (qmail 30675 invoked by uid 0); 19 Aug 2003 23:15:41 -0000 Received: from skraw@ithnet.com by heather-ng (Processed in 0.610472 secs); 19 Aug 2003 23:15:41 -0000 X-Virus-Status: No Received: from unknown (HELO ithnet.com) (217.64.64.14) by heather-ng.ithnet.com with SMTP; 19 Aug 2003 23:15:40 -0000 X-Sender-Authentication: SMTPafterPOP by from 217.64.64.14 Date: Wed, 20 Aug 2003 01:15:40 +0200 From: Stephan von Krawczynski To: "David S. Miller" Cc: richard@aspectgroup.co.uk, alan@lxorguk.ukuu.org.uk, willy@w.ods.org, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030820011540.27ba635c.skraw@ithnet.com> In-Reply-To: <20030819151137.3d6e78f2.davem@redhat.com> References: <353568DCBAE06148B70767C1B1A93E625EAB60@post.pc.aspectgroup.co.uk> <20030819151137.3d6e78f2.davem@redhat.com> Organization: ith Kommunikationstechnik GmbH X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5088 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: skraw@ithnet.com Precedence: bulk X-list: netdev Content-Length: 1669 Lines: 44 On Tue, 19 Aug 2003 15:11:37 -0700 "David S. Miller" wrote: > On Tue, 19 Aug 2003 23:12:38 +0100 > Richard Underwood wrote: > > > I'm certain that Cisco (for example) won't change their ways. > > I don't believe this. > > In cases where we've been able to show their devices to > be faulty, they've fixed their kit. Go check out what > happened wrt. the ECN issues their firewall products had. Yes, but you failed to explain their fault in this discussed issue so far. Still there is no good explanation for what can be broken if setting the source ip of an arp request with the interface ip instead of the originating ip (iff localhost). According to your own words: 1) the destination host must not care 2) the source ip is no more visible if the request succeeds and a corresponding entry in the table is made. So originating host has no chance to find out what it was later on. Who else should care? This discussion could btw have ended months ago (it is coming up now and then) if a _simple_ way was implemented (like proc-setting) to switch between the two possibilities. I always thought we are doing a consensus project here. I guess it would be utmost simple to create a patch that implements something like: echo > /proc/sys/net/ethX/idontknowwhat 0 (current default behaviour) echo > /proc/sys/net/ethX/idontknowwhat 1 (source ip of arp request following the interface) echo > /proc/sys/net/ethX/idontknowwhat 2 (don't answer arps on this interface) It's _simple_ for the user and contains every piece we talked about so far. Shoot me for not being member of any religion. Regards, Stephan From shemminger@osdl.org Tue Aug 19 16:22:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 16:22:33 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JNMRFl002608 for ; Tue, 19 Aug 2003 16:22:28 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7JNM9o21950; Tue, 19 Aug 2003 16:22:09 -0700 Date: Tue, 19 Aug 2003 16:21:56 -0700 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] Update STRIP driver Message-Id: <20030819162156.4a9f6697.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5089 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 20252 Lines: 705 Update the STRIP driver. - set owner field on tty ldisc - allocate network device objects with alloc_netdev - use list_head macros and put locking around list of devices - convert to seq_file for /proc - use change_mtu hook rather than guessing at mtu changes Don't have the actual hardware, but since it is a serial line discipline based thingy, could easily bring it up and play with it over a serial line. diff -Nru a/drivers/net/wireless/strip.c b/drivers/net/wireless/strip.c --- a/drivers/net/wireless/strip.c Tue Aug 19 16:18:49 2003 +++ b/drivers/net/wireless/strip.c Tue Aug 19 16:18:49 2003 @@ -103,6 +103,7 @@ #include #include #include +#include #include #include #include @@ -259,8 +260,8 @@ * Internal variables. */ - struct strip *next; /* The next struct in the list */ - struct strip **referrer; /* The pointer that points to us */ + struct list_head list; /* Linked list of devices */ + int discard; /* Set if serial error */ int working; /* Is radio working correctly? */ int firmware_level; /* Message structuring level */ @@ -434,8 +435,8 @@ /************************************************************************/ /* Global variables */ -static struct strip *struct_strip_list; -static spinlock_t strip_lock; +static LIST_HEAD(strip_list); +static spinlock_t strip_lock = SPIN_LOCK_UNLOCKED; /************************************************************************/ /* Macros */ @@ -844,11 +845,11 @@ * big enough to receive a large radio neighbour list (currently 4K). */ -static int allocate_buffers(struct strip *strip_info) +static int allocate_buffers(struct strip *strip_info, int mtu) { struct net_device *dev = strip_info->dev; int sx_size = MAX(STRIP_ENCAP_SIZE(MAX_RECV_MTU), 4096); - int tx_size = STRIP_ENCAP_SIZE(dev->mtu) + MaxCommandStringLength; + int tx_size = STRIP_ENCAP_SIZE(mtu) + MaxCommandStringLength; __u8 *r = kmalloc(MAX_RECV_MTU, GFP_ATOMIC); __u8 *s = kmalloc(sx_size, GFP_ATOMIC); __u8 *t = kmalloc(tx_size, GFP_ATOMIC); @@ -858,7 +859,7 @@ strip_info->tx_buff = t; strip_info->sx_size = sx_size; strip_info->tx_size = tx_size; - strip_info->mtu = dev->mtu; + strip_info->mtu = dev->mtu = mtu; return (1); } if (r) @@ -871,34 +872,31 @@ } /* - * MTU has been changed by the IP layer. Unfortunately we are not told - * about this, but we spot it ourselves and fix things up. We could be in + * MTU has been changed by the IP layer. + * We could be in * an upcall from the tty driver, or in an ip packet queue. - * - * Caller must hold the strip_lock */ - -static void strip_changedmtu(struct strip *strip_info) +static int strip_change_mtu(struct net_device *dev, int new_mtu) { + struct strip *strip_info = dev->priv; int old_mtu = strip_info->mtu; - struct net_device *dev = strip_info->dev; unsigned char *orbuff = strip_info->rx_buff; unsigned char *osbuff = strip_info->sx_buff; unsigned char *otbuff = strip_info->tx_buff; - if (dev->mtu > MAX_SEND_MTU) { + if (new_mtu > MAX_SEND_MTU) { printk(KERN_ERR "%s: MTU exceeds maximum allowable (%d), MTU change cancelled.\n", strip_info->dev->name, MAX_SEND_MTU); - dev->mtu = old_mtu; - return; + return -EINVAL; } - if (!allocate_buffers(strip_info)) { + spin_lock_bh(&strip_lock); + if (!allocate_buffers(strip_info, new_mtu)) { printk(KERN_ERR "%s: unable to grow strip buffers, MTU change cancelled.\n", strip_info->dev->name); - dev->mtu = old_mtu; - return; + spin_unlock_bh(&strip_lock); + return -ENOMEM; } if (strip_info->sx_count) { @@ -921,6 +919,7 @@ } } strip_info->tx_head = strip_info->tx_buff; + spin_unlock_bh(&strip_lock); printk(KERN_NOTICE "%s: strip MTU changed fom %d to %d.\n", strip_info->dev->name, old_mtu, strip_info->mtu); @@ -931,6 +930,8 @@ kfree(osbuff); if (otbuff) kfree(otbuff); + + return 0; } static void strip_unlock(struct strip *strip_info) @@ -944,74 +945,6 @@ } -/************************************************************************/ -/* Callback routines for exporting information through /proc */ - -/* - * This function updates the total amount of data printed so far. It then - * determines if the amount of data printed into a buffer has reached the - * offset requested. If it hasn't, then the buffer is shifted over so that - * the next bit of data can be printed over the old bit. If the total - * amount printed so far exceeds the total amount requested, then this - * function returns 1, otherwise 0. - */ -static int -shift_buffer(char *buffer, int requested_offset, int requested_len, - int *total, int *slop, char **buf) -{ - int printed; - - /* printk(KERN_DEBUG "shift: buffer: %d o: %d l: %d t: %d buf: %d\n", - (int) buffer, requested_offset, requested_len, *total, - (int) *buf); */ - printed = *buf - buffer; - if (*total + printed <= requested_offset) { - *total += printed; - *buf = buffer; - } else { - if (*total < requested_offset) { - *slop = requested_offset - *total; - } - *total = requested_offset + printed - *slop; - } - if (*total > requested_offset + requested_len) { - return 1; - } else { - return 0; - } -} - -/* - * This function calculates the actual start of the requested data - * in the buffer. It also calculates actual length of data returned, - * which could be less that the amount of data requested. - */ -static int -calc_start_len(char *buffer, char **start, int requested_offset, - int requested_len, int total, char *buf) -{ - int return_len, buffer_len; - - buffer_len = buf - buffer; - if (buffer_len >= 4095) { - printk(KERN_ERR "STRIP: exceeded /proc buffer size\n"); - } - - /* - * There may be bytes before and after the - * chunk that was actually requested. - */ - return_len = total - requested_offset; - if (return_len < 0) { - return_len = 0; - } - *start = buf - return_len; - if (return_len > requested_len) { - return_len = requested_len; - } - /* printk(KERN_DEBUG "return_len: %d\n", return_len); */ - return return_len; -} /* * If the time is in the near future, time_delta prints the number of @@ -1032,44 +965,89 @@ return (buffer); } -static int sprintf_neighbours(char *buffer, MetricomNodeTable * table, - char *title) +#define STRIP_PROC_HEADER ((void *)1) + +/* get Nth element of the linked list */ +static struct strip *strip_get_idx(loff_t pos) +{ + struct list_head *l; + int i = 0; + + list_for_each_rcu(l, &strip_list) { + if (pos == i) + return list_entry(l, struct strip, list); + ++i; + } + return NULL; +} + +static void *strip_seq_start(struct seq_file *seq, loff_t *pos) +{ + rcu_read_lock(); + return *pos ? strip_get_idx(*pos - 1) : STRIP_PROC_HEADER; +} + +static void *strip_seq_next(struct seq_file *seq, void *v, loff_t *pos) +{ + struct list_head *l; + struct strip *s; + + ++*pos; + if (v == STRIP_PROC_HEADER) + return strip_get_idx(1); + + s = v; + l = &s->list; + list_for_each_continue_rcu(l, &strip_list) { + return list_entry(l, struct strip, list); + } + return NULL; +} + +static void strip_seq_stop(struct seq_file *seq, void *v) +{ + rcu_read_unlock(); +} + +static void strip_seq_neighbours(struct seq_file *seq, + const MetricomNodeTable * table, + const char *title) { /* We wrap this in a do/while loop, so if the table changes */ /* while we're reading it, we just go around and try again. */ struct timeval t; - char *ptr; - unsigned long flags; do { int i; t = table->timestamp; - ptr = buffer; if (table->num_nodes) - ptr += sprintf(ptr, "\n %s\n", title); + seq_printf(seq, "\n %s\n", title); for (i = 0; i < table->num_nodes; i++) { MetricomNode node; - spin_lock_irqsave(&strip_lock, flags); + spin_lock_bh(&strip_lock); node = table->node[i]; - spin_unlock_irqrestore(&strip_lock, flags); - ptr += sprintf(ptr, " %s\n", node.c); + spin_unlock_bh(&strip_lock); + seq_printf(seq, " %s\n", node.c); } } while (table->timestamp.tv_sec != t.tv_sec || table->timestamp.tv_usec != t.tv_usec); - return ptr - buffer; } /* - * This function prints radio status information into the specified buffer. - * I think the buffer size is 4K, so this routine should never print more - * than 4K of data into it. With the maximum of 32 portables and 32 poletops + * This function prints radio status information via the seq_file + * interface. The interface takes care of buffer size and over + * run issues. + * + * The buffer in seq_file is PAGESIZE (4K) + * so this routine should never print more or it will get truncated. + * With the maximum of 32 portables and 32 poletops * reported, the routine outputs 3107 bytes into the buffer. */ -static int sprintf_status_info(char *buffer, struct strip *strip_info) +static void strip_seq_status_info(struct seq_file *seq, + const struct strip *strip_info) { char temp[32]; - char *p = buffer; MetricomAddressString addr_string; /* First, we must copy all of our data to a safe place, */ @@ -1103,98 +1081,104 @@ unsigned long tx_ebytes = strip_info->tx_ebytes; #endif - p += sprintf(p, "\nInterface name\t\t%s\n", if_name); - p += sprintf(p, " Radio working:\t\t%s\n", working ? "Yes" : "No"); + seq_printf(seq, "\nInterface name\t\t%s\n", if_name); + seq_printf(seq, " Radio working:\t\t%s\n", working ? "Yes" : "No"); radio_address_to_string(&true_dev_addr, &addr_string); - p += sprintf(p, " Radio address:\t\t%s\n", addr_string.c); + seq_printf(seq, " Radio address:\t\t%s\n", addr_string.c); if (manual_dev_addr) { radio_address_to_string(&dev_dev_addr, &addr_string); - p += sprintf(p, " Device address:\t%s\n", addr_string.c); + seq_printf(seq, " Device address:\t%s\n", addr_string.c); } - p += sprintf(p, " Firmware version:\t%s", !working ? "Unknown" : + seq_printf(seq, " Firmware version:\t%s", !working ? "Unknown" : !firmware_level ? "Should be upgraded" : firmware_version.c); if (firmware_level >= ChecksummedMessages) - p += sprintf(p, " (Checksums Enabled)"); - p += sprintf(p, "\n"); - p += sprintf(p, " Serial number:\t\t%s\n", serial_number.c); - p += sprintf(p, " Battery voltage:\t%s\n", battery_voltage.c); - p += sprintf(p, " Transmit queue (bytes):%d\n", tx_left); - p += sprintf(p, " Receive packet rate: %ld packets per second\n", + seq_printf(seq, " (Checksums Enabled)"); + seq_printf(seq, "\n"); + seq_printf(seq, " Serial number:\t\t%s\n", serial_number.c); + seq_printf(seq, " Battery voltage:\t%s\n", battery_voltage.c); + seq_printf(seq, " Transmit queue (bytes):%d\n", tx_left); + seq_printf(seq, " Receive packet rate: %ld packets per second\n", rx_average_pps / 8); - p += sprintf(p, " Transmit packet rate: %ld packets per second\n", + seq_printf(seq, " Transmit packet rate: %ld packets per second\n", tx_average_pps / 8); - p += sprintf(p, " Sent packet rate: %ld packets per second\n", + seq_printf(seq, " Sent packet rate: %ld packets per second\n", sx_average_pps / 8); - p += sprintf(p, " Next watchdog probe:\t%s\n", + seq_printf(seq, " Next watchdog probe:\t%s\n", time_delta(temp, watchdog_doprobe)); - p += sprintf(p, " Next watchdog reset:\t%s\n", + seq_printf(seq, " Next watchdog reset:\t%s\n", time_delta(temp, watchdog_doreset)); - p += sprintf(p, " Next gratuitous ARP:\t"); + seq_printf(seq, " Next gratuitous ARP:\t"); if (!memcmp (strip_info->dev->dev_addr, zero_address.c, sizeof(zero_address))) - p += sprintf(p, "Disabled\n"); + seq_printf(seq, "Disabled\n"); else { - p += sprintf(p, "%s\n", time_delta(temp, gratuitous_arp)); - p += sprintf(p, " Next ARP interval:\t%ld seconds\n", + seq_printf(seq, "%s\n", time_delta(temp, gratuitous_arp)); + seq_printf(seq, " Next ARP interval:\t%ld seconds\n", JIFFIE_TO_SEC(arp_interval)); } if (working) { #ifdef EXT_COUNTERS - p += sprintf(p, "\n"); - p += sprintf(p, + seq_printf(seq, "\n"); + seq_printf(seq, " Total bytes: \trx:\t%lu\ttx:\t%lu\n", rx_bytes, tx_bytes); - p += sprintf(p, + seq_printf(seq, " thru radio: \trx:\t%lu\ttx:\t%lu\n", rx_rbytes, tx_rbytes); - p += sprintf(p, + seq_printf(seq, " thru serial port: \trx:\t%lu\ttx:\t%lu\n", rx_sbytes, tx_sbytes); - p += sprintf(p, + seq_printf(seq, " Total stat/err bytes:\trx:\t%lu\ttx:\t%lu\n", rx_ebytes, tx_ebytes); #endif - p += sprintf_neighbours(p, &strip_info->poletops, + strip_seq_neighbours(seq, &strip_info->poletops, "Poletops:"); - p += sprintf_neighbours(p, &strip_info->portables, + strip_seq_neighbours(seq, &strip_info->portables, "Portables:"); } - - return p - buffer; } /* * This function is exports status information from the STRIP driver through * the /proc file system. */ +static int strip_seq_show(struct seq_file *seq, void *v) +{ + if (v == STRIP_PROC_HEADER) + seq_printf(seq, "strip_version: %s\n", StripVersion); + else + strip_seq_status_info(seq, (const struct strip *)v); + return 0; +} -static int get_status_info(char *buffer, char **start, off_t req_offset, - int req_len) + +static struct seq_operations strip_seq_ops = { + .start = strip_seq_start, + .next = strip_seq_next, + .stop = strip_seq_stop, + .show = strip_seq_show, +}; + +static int strip_seq_open(struct inode *inode, struct file *file) { - int total = 0, slop = 0; - struct strip *strip_info = struct_strip_list; - char *buf = buffer; - - buf += sprintf(buf, "strip_version: %s\n", StripVersion); - if (shift_buffer(buffer, req_offset, req_len, &total, &slop, &buf)) - goto exit; - - while (strip_info != NULL) { - buf += sprintf_status_info(buf, strip_info); - if (shift_buffer - (buffer, req_offset, req_len, &total, &slop, &buf)) - break; - strip_info = strip_info->next; - } - exit: - return (calc_start_len - (buffer, start, req_offset, req_len, total, buf)); + return seq_open(file, &strip_seq_ops); } +static struct file_operations strip_seq_fops = { + .owner = THIS_MODULE, + .open = strip_seq_open, + .read = seq_read, + .llseek = seq_lseek, + .release = seq_release, +}; + + + /************************************************************************/ /* Sending routines */ @@ -1578,7 +1562,6 @@ static int strip_xmit(struct sk_buff *skb, struct net_device *dev) { struct strip *strip_info = (struct strip *) (dev->priv); - unsigned long flags; if (!netif_running(dev)) { printk(KERN_ERR "%s: xmit call when iface is down\n", @@ -1617,14 +1600,11 @@ strip_info->dev->name, sx_pps_count / 8); } - spin_lock_irqsave(&strip_lock, flags); - /* See if someone has been ifconfigging */ - if (strip_info->mtu != strip_info->dev->mtu) - strip_changedmtu(strip_info); + spin_lock_bh(&strip_lock); strip_send(strip_info, skb); - spin_unlock_irqrestore(&strip_lock, flags); + spin_unlock_bh(&strip_lock); if (skb) dev_kfree_skb(skb); @@ -2317,18 +2297,12 @@ { struct strip *strip_info = (struct strip *) tty->disc_data; const unsigned char *end = cp + count; - unsigned long flags; if (!strip_info || strip_info->magic != STRIP_MAGIC || !netif_running(strip_info->dev)) return; - spin_lock_irqsave(&strip_lock, flags); - - /* Argh! mtu change time! - costs us the packet part received at the change */ - if (strip_info->mtu != strip_info->dev->mtu) - strip_changedmtu(strip_info); - + spin_lock_bh(&strip_lock); #if 0 { struct timeval tv; @@ -2395,7 +2369,7 @@ } cp++; } - spin_unlock_irqrestore(&strip_lock, flags); + spin_unlock_bh(&strip_lock); } @@ -2483,7 +2457,7 @@ if (strip_info->tty == NULL) return (-ENODEV); - if (!allocate_buffers(strip_info)) + if (!allocate_buffers(strip_info, dev->mtu)) return (-ENOMEM); strip_info->sx_count = 0; @@ -2543,12 +2517,14 @@ * (dynamically assigned) device is registered */ -static int strip_dev_init(struct net_device *dev) +static void strip_dev_setup(struct net_device *dev) { /* * Finish setting up the DEVICE info. */ + SET_MODULE_OWNER(dev); + dev->trans_start = 0; dev->last_rx = 0; dev->tx_queue_len = 30; /* Drop after 30 frames queued */ @@ -2576,7 +2552,7 @@ dev->rebuild_header = strip_rebuild_header; dev->set_mac_address = dev_set_mac_address; dev->get_stats = strip_get_stats; - return 0; + dev->change_mtu = strip_change_mtu; } /* @@ -2585,65 +2561,34 @@ static void strip_free(struct strip *strip_info) { - *(strip_info->referrer) = strip_info->next; - if (strip_info->next) - strip_info->next->referrer = strip_info->referrer; + spin_lock_bh(&strip_lock); + list_del_rcu(&strip_info->list); + spin_unlock_bh(&strip_lock); + strip_info->magic = 0; - if (strip_info->dev) - kfree(strip_info->dev); - kfree(strip_info); + + kfree(strip_info->dev); } + /* * Allocate a new free STRIP channel */ - static struct strip *strip_alloc(void) { - int channel_id = 0; - struct strip **s = &struct_strip_list; + struct list_head *n; struct net_device *dev; - struct strip *strip_info = (struct strip *) - kmalloc(sizeof(struct strip), GFP_KERNEL); + struct strip *strip_info; - if (!strip_info) - return NULL; /* If no more memory, return */ + dev = alloc_netdev(sizeof(struct strip), "st%d", + strip_dev_setup); - /* - * Clear the allocated memory - */ + if (!dev) + return NULL; /* If no more memory, return */ - memset(strip_info, 0, sizeof(struct strip)); - /* allocate the net_device */ - dev = kmalloc(sizeof(struct net_device), GFP_KERNEL); - if (!dev) { - kfree(strip_info); - return NULL; - } + strip_info = dev->priv; strip_info->dev = dev; - SET_MODULE_OWNER(dev); - - /* - * Search the list to find where to put our new entry - * (and in the process decide what channel number it is - * going to be) - */ - - while (*s && (*s)->dev->base_addr == channel_id) { - channel_id++; - s = &(*s)->next; - } - - /* - * Fill in the link pointers - */ - - strip_info->next = *s; - if (*s) - (*s)->referrer = &strip_info->next; - strip_info->referrer = s; - *s = strip_info; strip_info->magic = STRIP_MAGIC; strip_info->tty = NULL; @@ -2654,12 +2599,27 @@ strip_info->idle_timer.data = (long) dev; strip_info->idle_timer.function = strip_IdleTask; - /* Note: strip_info->if_name is currently 8 characters long */ - sprintf(dev->name, "st%d", channel_id); - dev->base_addr = channel_id; - dev->priv = (void *) strip_info; - dev->next = NULL; - dev->init = strip_dev_init; + + spin_lock_bh(&strip_lock); + rescan: + /* + * Search the list to find where to put our new entry + * (and in the process decide what channel number it is + * going to be) + */ + list_for_each(n, &strip_list) { + struct strip *s = hlist_entry(n, struct strip, list); + + if (s->dev->base_addr == dev->base_addr) { + ++dev->base_addr; + goto rescan; + } + } + + sprintf(dev->name, "st%ld", dev->base_addr); + + list_add_tail_rcu(&strip_info->list, &strip_list); + spin_unlock_bh(&strip_lock); return strip_info; } @@ -2809,6 +2769,7 @@ static struct tty_ldisc strip_ldisc = { .magic = TTY_LDISC_MAGIC, .name = "strip", + .owner = THIS_MODULE, .open = strip_open, .close = strip_close, .ioctl = strip_ioctl, @@ -2832,7 +2793,6 @@ printk(signon, StripVersion); - spin_lock_init(&strip_lock); /* * Fill in our line protocol discipline, and register it @@ -2844,7 +2804,7 @@ /* * Register the status file with /proc */ - proc_net_create("strip", S_IFREG | S_IRUGO, get_status_info); + proc_net_fops_create("strip", S_IFREG | S_IRUGO, &strip_seq_fops); return status; } @@ -2857,8 +2817,13 @@ static void __exit strip_exit_driver(void) { int i; - while (struct_strip_list) - strip_free(struct_strip_list); + struct list_head *p,*n; + + /* module ref count rules assure that all entries are unregistered */ + list_for_each_safe(p, n, &strip_list) { + struct strip *s = list_entry(p, struct strip, list); + strip_free(s); + } /* Unregister with the /proc/net file here. */ proc_net_remove("strip"); From romieu@fr.zoreil.com Tue Aug 19 16:28:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 16:28:41 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JNSZFl002956 for ; Tue, 19 Aug 2003 16:28:36 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id h7JNKExA026865; Wed, 20 Aug 2003 01:20:14 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id h7JNKEfw026864; Wed, 20 Aug 2003 01:20:14 +0200 Date: Wed, 20 Aug 2003 01:20:14 +0200 From: Francois Romieu To: Stephen Hemminger Cc: Mike Phillips , linux-tr@linuxtr.net, netdev@oss.sgi.com Subject: Re: [RFT][PATCH] convert 802/tr to seq_file Message-ID: <20030820012014.B23942@electric-eye.fr.zoreil.com> References: <20030819141326.2a63bad0.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030819141326.2a63bad0.shemminger@osdl.org>; from shemminger@osdl.org on Tue, Aug 19, 2003 at 02:13:26PM -0700 X-archive-position: 5090 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 2302 Lines: 93 Stephen Hemminger : > Convert the /proc interface to tokenring routing information > to the new seq_file interface. > > Builds and loads on 2.6.0-test3, but I don't have any real tokenring hardware > to make entries show up in table. > > diff -Nru a/net/802/tr.c b/net/802/tr.c > --- a/net/802/tr.c Tue Aug 19 14:07:56 2003 > +++ b/net/802/tr.c Tue Aug 19 14:07:56 2003 [...] > @@ -456,84 +457,108 @@ > * routing. > */ > > -#ifndef CONFIG_PROC_FS > -static int rif_get_info(char *buffer,char **start, off_t offset, int length) { return 0;} > -#else > -static int rif_get_info(char *buffer,char **start, off_t offset, int length) > -{ > - int len=0; > - off_t begin=0; > - off_t pos=0; > - int size,i,j,rcf_len,segment,brdgnmb; > - unsigned long now=jiffies; > +#ifdef CONFIG_PROC_FS > +/* Magic token to indicate first entry (header line) */ > +#define RIF_PROC_START ((void *)1) > + > +static struct rif_cache_s *rif_get_idx(loff_t pos) > +{ > + int i; > + struct rif_cache_s *entry; > + loff_t off = 0; > + > + for(i=0;i < RIF_TABLE_SIZE;i++) > + for(entry=rif_table[i];entry;entry=entry->next) { > + if (off == pos) > + return entry; > + ++off; > + } > + Add a few more spaces and braces (it's 1:00 AM here |o) ) for (i = 0; i < RIF_TABLE_SIZE; i++) { for (entry = rif_table[i]; entry; entry = entry->next) { if (--pos < 0) return entry; } } (killed "off" btw) > + return NULL; > +} > + > +static void *rif_seq_start(struct seq_file *seq, loff_t *pos) > +{ > unsigned long flags; > > - rif_cache entry; > + spin_lock_irqsave(&rif_lock, flags); > + seq->private = (void *) flags; > + > + return *pos ? rif_get_idx(*pos - 1) : RIF_PROC_START; > +} > + > +static void *rif_seq_next(struct seq_file *seq, void *v, loff_t *pos) > +{ > + return rif_get_idx(*pos++); ^^^^^^ Won't this increment the pointer instead of the value it adresses ? void *v; v = rif_get_idx(*pos + 1); *pos += !!ERR_PTR(v); return v; > +} > + > +static void rif_seq_stop(struct seq_file *seq, void *v) > +{ > + unsigned long flags = (unsigned long) seq->private; > + spin_lock_irqsave(&rif_lock, flags); ^^^^^^^^^^^^^^^^^ This should probably read: + spin_unlock_irqrestore(&rif_lock, flags); -- Ueimor From mcr@sandelman.ottawa.on.ca Tue Aug 19 16:51:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 16:51:32 -0700 (PDT) Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [205.150.200.166] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7JNpMFl005271 for ; Tue, 19 Aug 2003 16:51:27 -0700 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h7JNp5d08510 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 19 Aug 2003 19:51:11 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h7JNp5CA006953 for ; Tue, 19 Aug 2003 19:51:05 -0400 To: netdev@oss.sgi.com Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices In-reply-to: Your message of "Tue, 19 Aug 2003 15:11:37 PDT." <20030819151137.3d6e78f2.davem@redhat.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 19 Aug 2003 19:51:05 -0400 Message-ID: <6952.1061337065@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-archive-position: 5091 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcr@sandelman.ottawa.on.ca Precedence: bulk X-list: netdev Content-Length: 868 Lines: 22 >>>>> "David" == David S Miller writes: >> I'm certain that Cisco (for example) won't change their ways. David> I don't believe this. David> In cases where we've been able to show their devices to be faulty, David> they've fixed their kit. Go check out what happened wrt. the ECN David> issues their firewall products had. That's great news. Is there a Cisco errata that I can point people at? I don't think that the ECN hall of shame knows about this yet... http://urchin.earth.li/ecn/ ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ From jgarzik@pobox.com Tue Aug 19 17:01:19 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 17:01:24 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7K00vFl006867 for ; Tue, 19 Aug 2003 17:01:18 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.14) id 19pDLK-0005Y2-3R; Tue, 19 Aug 2003 21:44:38 +0100 Message-ID: <3F428C2B.9070809@pobox.com> Date: Tue, 19 Aug 2003 16:44:27 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: shemminger@osdl.org, netdev@oss.sgi.com, mochel@osdl.org Subject: Re: [PATCH] (0/9) free_netdev -- delay freeing of net_device structure till after last use References: <20030819121800.009db89b.shemminger@osdl.org> <20030819124818.476dc36d.davem@redhat.com> <3F42877B.9040407@pobox.com> <20030819132432.4c601c5f.davem@redhat.com> In-Reply-To: <20030819132432.4c601c5f.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5092 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 Content-Length: 678 Lines: 29 David S. Miller wrote: > On Tue, 19 Aug 2003 16:24:27 -0400 > Jeff Garzik wrote: > > >>Also, my tendency is to apply patches 1-8, and not apply patch 9 just >>yet. Even though patch 9 is a fix, those specific areas of code, I'm >>betting, will change when those drivers are fixed WRT full dynamic >>allocation and refcounting. >> >>Comments? > > > I disagree about patch 9. > > These drivers already dynamically allocate their netdev > structs, so they do not require any more fixing. I just > double checked each driver changes in patch 9 and to me > this is undoubtedly the case. > > These are just pure bug fixes. Ok with me, then. Jeff From skraw@ithnet.com Tue Aug 19 17:14:38 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 17:14:45 -0700 (PDT) Received: from heather-ng.ithnet.com (mail3.ithnet.com [217.64.64.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7K0EXFl007283 for ; Tue, 19 Aug 2003 17:14:37 -0700 Received: (qmail 25515 invoked by uid 0); 19 Aug 2003 21:53:27 -0000 Received: from skraw@ithnet.com by heather-ng (Processed in 0.5408 secs); 19 Aug 2003 21:53:27 -0000 X-Virus-Status: No Received: from unknown (HELO ithnet.com) (217.64.64.14) by heather-ng.ithnet.com with SMTP; 19 Aug 2003 21:53:26 -0000 X-Sender-Authentication: SMTPafterPOP by from 217.64.64.14 Date: Tue, 19 Aug 2003 23:53:26 +0200 From: Stephan von Krawczynski To: Alan Cox Cc: richard@aspectgroup.co.uk, davem@redhat.com, willy@w.ods.org, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030819235326.2920dacf.skraw@ithnet.com> In-Reply-To: <1061320099.30567.55.camel@dhcp23.swansea.linux.org.uk> References: <353568DCBAE06148B70767C1B1A93E625EAB58@post.pc.aspectgroup.co.uk> <1061320099.30567.55.camel@dhcp23.swansea.linux.org.uk> Organization: ith Kommunikationstechnik GmbH X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5093 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: skraw@ithnet.com Precedence: bulk X-list: netdev Content-Length: 1700 Lines: 34 On 19 Aug 2003 20:08:20 +0100 Alan Cox wrote: > > But if I was to do this in the other direction (arp -d 172.20.240.1; > > ping -I 172.24.0.1 172.20.240.1) then I'd lose connectivity over my default > > route because 172.20.240.1 won't accept ARP packets from IP numbers not on > > the connected subnet. The ARP entry will block any further ARP > > requests from valid IP numbers. > > One thing I agree with you about is that an ARP resolution for an > address via one path should not block a resolution for it by another > path since to begin with the two paths may be to different routers > one of which is down. Sounds logical. Can you explain to me why there should be a difference in the source ip of an arp request originated by an ip packet from another address of the same host compared to a forwarded packet from another host, coming in on some secondary interface? If I understood David correctly the first case will do an arp request with source ip equal to source ip of the packet (originated locally). In the second case (the box has to forward some foreign packet) for sure its interface address will be used, correct? Or does that read: _some_ interface address will be used? Why this difference? The destination host cannot distinguish between these two cases, so they can be as well handled just the same. But it seems obvious that a foreign IP cannot be used as a source for an arp request. And overall, looking at an arp table, what is visible is: interface, MAC and corresponding IP. So as soon as an arp request is successfully completed the box doesn't even remember the source ip of the former arp request, right? Regards, Stephan From jt@bougret.hpl.hp.com Tue Aug 19 17:41:51 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 17:41:56 -0700 (PDT) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7K0fmFl007827 for ; Tue, 19 Aug 2003 17:41:51 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel13.hp.com (Postfix) with ESMTP id 24AA81C0591B; Tue, 19 Aug 2003 17:41:48 -0700 (PDT) Received: from bougret.hpl.hp.com (mail@bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_26305)/8.9.3 HPLabs Timeshare Server) with ESMTP id RAA29483; Tue, 19 Aug 2003 17:41:28 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 19pH2W-0002yF-00; Tue, 19 Aug 2003 17:41:28 -0700 Date: Tue, 19 Aug 2003 17:41:28 -0700 To: Francois Romieu , Stephen Hemminger Cc: "David S. Miller" , irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] (4/4) convert irlan to seq_file interface Message-ID: <20030820004128.GA11382@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20030818122702.67e9162d.shemminger@osdl.org> <20030818232554.A7779@electric-eye.fr.zoreil.com> <20030818150514.310f6f5d.shemminger@osdl.org> <20030819002637.B7779@electric-eye.fr.zoreil.com> <20030820003648.A23942@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030820003648.A23942@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 5094 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev Content-Length: 617 Lines: 18 On Wed, Aug 20, 2003 at 12:36:48AM +0200, Francois Romieu wrote: > Apply on top of Stephen's serie [1-4]. Compile ok. > > Style: separate data from code. By the way, I've totally lost track of who does what. If David Miller doesn't process your patch, send it to me and I'll push it through the usual channels. If any of you guys have issues setting up a testbed, either with real IrDA hardware or a serial cross-over cable, please yell. Testing is one of my hot button, and I don't want to give much excuse ;-) By the way, I'm on vacation starting this thursday, I'll be back in september. Have fun... Jean From davem@redhat.com Tue Aug 19 21:07:01 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 21:07: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 h7K470oO010807 for ; Tue, 19 Aug 2003 21:07:00 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id VAA14913; Tue, 19 Aug 2003 21:00:00 -0700 Date: Tue, 19 Aug 2003 21:00:00 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] get rid of unused argument Message-Id: <20030819210000.42fa2a67.davem@redhat.com> In-Reply-To: <20030819155629.7201f947.shemminger@osdl.org> References: <20030819155629.7201f947.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5096 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 Content-Length: 152 Lines: 6 On Tue, 19 Aug 2003 15:56:29 -0700 Stephen Hemminger wrote: > dev_get_idx doesn't need the first arg.. Applied, thanks Stephen. From davem@redhat.com Tue Aug 19 21:09:56 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 21:09: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 h7K49uoO011159 for ; Tue, 19 Aug 2003 21:09:56 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id VAA14951; Tue, 19 Aug 2003 21:02:42 -0700 Date: Tue, 19 Aug 2003 21:02:41 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: jgarzik@pobox.com, jt@hpl.hp.com, irda-users@lists.sourceforge.net, netdev@oss.sgi.com, lists@mdiehl.de Subject: Re: [PATCH] kill old irtty Message-Id: <20030819210241.1f480c9b.davem@redhat.com> In-Reply-To: <20030819155847.6ea122e9.shemminger@osdl.org> References: <20030815154608.56cf0551.shemminger@osdl.org> <20030815230546.GA31831@bougret.hpl.hp.com> <20030816052048.5858d68a.davem@redhat.com> <20030817001405.GA1916@bougret.hpl.hp.com> <20030816175851.58a2c179.davem@redhat.com> <20030817011131.GA2120@bougret.hpl.hp.com> <20030818090313.7f153d7a.shemminger@osdl.org> <20030818165024.GB5992@bougret.hpl.hp.com> <20030818165321.GH24693@gtf.org> <20030818170850.GE5992@bougret.hpl.hp.com> <3F416A5E.2060302@pobox.com> <20030819155847.6ea122e9.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5097 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 Content-Length: 196 Lines: 7 On Tue, 19 Aug 2003 15:58:47 -0700 Stephen Hemminger wrote: > As suggested by Jean and Jeff, kill the old irtty driver > since it is replaced by irtty-sir Applied, thanks. From davem@redhat.com Tue Aug 19 21:11:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 21:11:19 -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 h7K4BFoO011456 for ; Tue, 19 Aug 2003 21:11:15 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id VAA14997; Tue, 19 Aug 2003 21:04:13 -0700 Date: Tue, 19 Aug 2003 21:04:13 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH] Update STRIP driver Message-Id: <20030819210413.2891f84d.davem@redhat.com> In-Reply-To: <20030819162156.4a9f6697.shemminger@osdl.org> References: <20030819162156.4a9f6697.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5098 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 Content-Length: 386 Lines: 11 On Tue, 19 Aug 2003 16:21:56 -0700 Stephen Hemminger wrote: > Update the STRIP driver. > - set owner field on tty ldisc > - allocate network device objects with alloc_netdev > - use list_head macros and put locking around list of devices > - convert to seq_file for /proc > - use change_mtu hook rather than guessing at mtu changes Applied, thanks Stephen. From davem@redhat.com Tue Aug 19 21:15:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 21:15: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 h7K4FPoO011817 for ; Tue, 19 Aug 2003 21:15:26 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id VAA15075; Tue, 19 Aug 2003 21:08:19 -0700 Date: Tue, 19 Aug 2003 21:08:19 -0700 From: "David S. Miller" To: Robert Olsson Cc: bellucda@tiscali.it, netdev@oss.sgi.com Subject: Re: [PATCH] make pktgen depends on procfs [2.6.0-test3] Message-Id: <20030819210819.42196998.davem@redhat.com> In-Reply-To: <16194.11289.761163.104079@robur.slu.se> References: <200308182326.10798.bellucda@tiscali.it> <16194.11289.761163.104079@robur.slu.se> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5099 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 Content-Length: 384 Lines: 13 On Tue, 19 Aug 2003 15:54:33 +0200 Robert Olsson wrote: > diff -urN 1.0/net/Kconfig 1.1/net/Kconfig > --- 1.0/net/Kconfig 2003-08-18 23:25:02.000000000 +0200 > +++ 1.1/net/Kconfig 2003-08-18 23:25:13.000000000 +0200 > @@ -661,6 +661,7 @@ > > config NET_PKTGEN > tristate "Packet Generator (USE WITH CAUTION)" > + depends on PROC_FS Applied, thanks. From davem@redhat.com Tue Aug 19 21:18:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 21:18:50 -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 h7K4IjoO012166 for ; Tue, 19 Aug 2003 21:18:46 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id VAA15109; Tue, 19 Aug 2003 21:10:30 -0700 Date: Tue, 19 Aug 2003 21:10:29 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: jt@bougret.hpl.hp.com, irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] ircomm - set owner get rid of MOD_INC/MOD_DEC Message-Id: <20030819211029.2506fc55.davem@redhat.com> In-Reply-To: <20030818111746.34b9e52b.shemminger@osdl.org> References: <20030818111746.34b9e52b.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5100 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 Content-Length: 240 Lines: 7 On Mon, 18 Aug 2003 11:17:46 -0700 Stephen Hemminger wrote: > Ircomm in 2.6.0-test3 can just set the owner field in the tty structure > like other drivers, and not mess with MOD_INC/MOD_DEC. Applied, thanks Stephen. From davem@redhat.com Tue Aug 19 21:19:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 21:19: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 h7K4JYoO012285 for ; Tue, 19 Aug 2003 21:19:37 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id VAA15138; Tue, 19 Aug 2003 21:11:33 -0700 Date: Tue, 19 Aug 2003 21:11:33 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: jt@bougret.hpl.hp.com, netdev@oss.sgi.com, irda-users@lists.sourceforge.net Subject: Re: [PATCH] set owner field on /proc/net/irda sub entries Message-Id: <20030819211133.0504abf4.davem@redhat.com> In-Reply-To: <20030818111942.6060b450.shemminger@osdl.org> References: <20030818111942.6060b450.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5101 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 Content-Length: 231 Lines: 7 On Mon, 18 Aug 2003 11:19:42 -0700 Stephen Hemminger wrote: > common net/irda code in 2.6.0-test3 creates directory and sub entries, > but forgets to set owner field on sub entries. Applied, thanks Stephen. From davem@redhat.com Tue Aug 19 21:20:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 21:20:58 -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 h7K4KqoO012730 for ; Tue, 19 Aug 2003 21:20:53 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id VAA15166; Tue, 19 Aug 2003 21:12:40 -0700 Date: Tue, 19 Aug 2003 21:12:40 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: jt@bougret.hpl.hp.com, irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] remove unused function prototype Message-Id: <20030819211240.22ac0360.davem@redhat.com> In-Reply-To: <20030818112215.312fb201.shemminger@osdl.org> References: <20030818112215.312fb201.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5102 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 Content-Length: 167 Lines: 6 On Mon, 18 Aug 2003 11:22:15 -0700 Stephen Hemminger wrote: > Unused function prototype defined but never used on 2.6.0-test3 Applied, thanks. From davem@redhat.com Tue Aug 19 21:22:12 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 21:22:17 -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 h7K4MBoO013090 for ; Tue, 19 Aug 2003 21:22:12 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id VAA15197; Tue, 19 Aug 2003 21:13:55 -0700 Date: Tue, 19 Aug 2003 21:13:55 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: jt@bougret.hpl.hp.com, irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] (1/4) remove hashbin from irlan Message-Id: <20030819211355.2c8664ee.davem@redhat.com> In-Reply-To: <20030818113936.205b5632.shemminger@osdl.org> References: <20030818113936.205b5632.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5103 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 Content-Length: 344 Lines: 11 On Mon, 18 Aug 2003 11:39:36 -0700 Stephen Hemminger wrote: > The locking in hashbin_delete is a problem since unregister_netdevice > can't be called with locks held in 2.6.0-test3. > > Replace it with simpler list macros. > Insertion/deletion protected with RTNL semaphore, and read > uses RCU. Patch applied, thanks. From davem@redhat.com Tue Aug 19 21:23:06 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 21:23:09 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7K4N5oO013389 for ; Tue, 19 Aug 2003 21:23:05 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id VAA15226; Tue, 19 Aug 2003 21:14:53 -0700 Date: Tue, 19 Aug 2003 21:14:52 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: jt@bougret.hpl.hp.com, irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] (2/4) convert irlan to use alloc_netdev Message-Id: <20030819211452.3e4c8bc0.davem@redhat.com> In-Reply-To: <20030818114930.4ca873cf.shemminger@osdl.org> References: <20030818114930.4ca873cf.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5104 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 Content-Length: 202 Lines: 8 On Mon, 18 Aug 2003 11:49:30 -0700 Stephen Hemminger wrote: > This patch to 2.6.0-test3 converts irlan to use alloc_netdev. > > Setup auto free via destructor. Applied, thanks. From davem@redhat.com Tue Aug 19 21:26:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 21:26:05 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7K4Q2oO013823 for ; Tue, 19 Aug 2003 21:26:02 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id VAA15296; Tue, 19 Aug 2003 21:17:49 -0700 Date: Tue, 19 Aug 2003 21:17:49 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: jt@bougret.hpl.hp.com, irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] (4/4) convert irlan to seq_file interface Message-Id: <20030819211749.67c95fad.davem@redhat.com> In-Reply-To: <20030818122702.67e9162d.shemminger@osdl.org> References: <20030818122702.67e9162d.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5105 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 Content-Length: 160 Lines: 6 On Mon, 18 Aug 2003 12:27:02 -0700 Stephen Hemminger wrote: > Convert irlan /proc interface to safer seq_file library. Applied, thanks. From davem@redhat.com Tue Aug 19 21:27:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 21:27:40 -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 h7K4RaoO014159 for ; Tue, 19 Aug 2003 21:27:36 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id VAA15340; Tue, 19 Aug 2003 21:19:17 -0700 Date: Tue, 19 Aug 2003 21:19:17 -0700 From: "David S. Miller" To: Francois Romieu Cc: shemminger@osdl.org, jt@bougret.hpl.hp.com, irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] (4/4) convert irlan to seq_file interface Message-Id: <20030819211917.69f4dde0.davem@redhat.com> In-Reply-To: <20030820003648.A23942@electric-eye.fr.zoreil.com> References: <20030818122702.67e9162d.shemminger@osdl.org> <20030818232554.A7779@electric-eye.fr.zoreil.com> <20030818150514.310f6f5d.shemminger@osdl.org> <20030819002637.B7779@electric-eye.fr.zoreil.com> <20030820003648.A23942@electric-eye.fr.zoreil.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5106 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 Content-Length: 199 Lines: 8 On Wed, 20 Aug 2003 00:36:48 +0200 Francois Romieu wrote: > Apply on top of Stephen's serie [1-4]. Compile ok. > > Style: separate data from code. Applied, thanks Francois. From davem@redhat.com Tue Aug 19 21:28:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 21:28:26 -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 h7K4SMoO014347 for ; Tue, 19 Aug 2003 21:28:22 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id VAA15358; Tue, 19 Aug 2003 21:20:09 -0700 Date: Tue, 19 Aug 2003 21:20:09 -0700 From: "David S. Miller" To: jt@hpl.hp.com Cc: jt@bougret.hpl.hp.com, shemminger@osdl.org, irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] convert ircomm to seq_file interface Message-Id: <20030819212009.36a8dc03.davem@redhat.com> In-Reply-To: <20030818200923.GC6577@bougret.hpl.hp.com> References: <20030818123142.6369fbff.shemminger@osdl.org> <20030818200923.GC6577@bougret.hpl.hp.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5107 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 Content-Length: 440 Lines: 13 On Mon, 18 Aug 2003 13:09:23 -0700 Jean Tourrilhes wrote: > On Mon, Aug 18, 2003 at 12:31:42PM -0700, Stephen Hemminger wrote: > > Convert ircomm /proc interface to seq_file. > > > > Note: don't need spin_lock_irq because list is not ever locked > > from inside interrupt context. > > I don't agree with this change. I'll let you guys work this one out. Let me know when a final version of the patch is ready. From davem@redhat.com Tue Aug 19 21:30:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 21:30: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 h7K4UHoO014813 for ; Tue, 19 Aug 2003 21:30:17 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id VAA15421; Tue, 19 Aug 2003 21:23:14 -0700 Date: Tue, 19 Aug 2003 21:23:14 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: mikep@linuxtr.net, linux-tr@linuxtr.net, netdev@oss.sgi.com Subject: Re: [RFT][PATCH] convert 802/tr to seq_file Message-Id: <20030819212314.3356d22a.davem@redhat.com> In-Reply-To: <20030819141326.2a63bad0.shemminger@osdl.org> References: <20030819141326.2a63bad0.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5108 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 Content-Length: 277 Lines: 10 On Tue, 19 Aug 2003 14:13:26 -0700 Stephen Hemminger wrote: > Convert the /proc interface to tokenring routing information > to the new seq_file interface. Applied, thanks. Please make the coding style cleanups suggested by Francois in the next round. From slblake@petri-meat.com Tue Aug 19 21:58:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 21:58:43 -0700 (PDT) Received: from server26.totalchoicehosting.com (server26.totalchoicehosting.com [207.44.248.87]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7K4wGoO015376 for ; Tue, 19 Aug 2003 21:58:37 -0700 Received: from rdu74-172-134.nc.rr.com ([24.74.172.134]) by server26.totalchoicehosting.com with esmtp (Exim 4.20) id 19pL2p-0005j8-Ju; Tue, 19 Aug 2003 23:58:03 -0500 Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices From: Steven Blake To: "David S. Miller" Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org In-Reply-To: <20030819105307.0b0a6491.davem@redhat.com> References: <353568DCBAE06148B70767C1B1A93E625EAB5C@post.pc.aspectgroup.co.uk> <20030819105307.0b0a6491.davem@redhat.com> Content-Type: text/plain Organization: Message-Id: <1061355487.1223.4.camel@photon> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 20 Aug 2003 00:58:07 -0400 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server26.totalchoicehosting.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com X-archive-position: 5109 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: slblake@petri-meat.com Precedence: bulk X-list: netdev Content-Length: 2849 Lines: 73 On Tue, 2003-08-19 at 13:53, David S. Miller wrote: > BTW, this ARP source address algorithm we use comes from > ipv6, it would be instructive to go and see why they do > things the way they do. Are you sure? See below: ======================================================================== RFC 2461 Neighbor Discovery for IPv6 December 1998 4.3. Neighbor Solicitation Message Format Nodes send Neighbor Solicitations to request the link-layer address of a target node while also providing their own link-layer address to the target. Neighbor Solicitations are multicast when the node needs to resolve an address and unicast when the node seeks to verify the reachability of a neighbor. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Target Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address Either an address assigned to the interface from which this message is sent or (if Duplicate Address Detection is in progress [ADDRCONF]) the unspecified address. Destination Address Either the solicited-node multicast address corresponding to the target address, or the target address. Hop Limit 255 Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header. Narten, et. al. Standards Track [Page 21] ======================================================================== Regards, // Steve From bos@serpentine.com Tue Aug 19 22:05:19 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 22:05:28 -0700 (PDT) Received: from pelerin.serpentine.com (dsl092-013-071.sfo1.dsl.speakeasy.net [66.92.13.71]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7K54woO015863 for ; Tue, 19 Aug 2003 22:05:19 -0700 Received: from camp4.serpentine.com (camp4.serpentine.com [192.168.16.5]) by pelerin.serpentine.com (Postfix) with ESMTP id 88D6D76C317 for ; Tue, 19 Aug 2003 22:04:56 -0700 (PDT) Subject: [TRIVIAL PATCH] export dev->state via sysfs From: "Bryan O'Sullivan" To: netdev@oss.sgi.com Content-Type: text/plain Message-Id: <1061355896.10843.22.camel@camp4.serpentine.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 19 Aug 2003 22:04:56 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 5110 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bos@serpentine.com Precedence: bulk X-list: netdev Content-Length: 869 Lines: 29 This trivial patch exports the netdev state field via sysfs. The motivation is to make it possible to check link state from userspace without having to go through the netlink interface. ; Tue, 19 Aug 2003 22:10:22 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id WAA15662; Tue, 19 Aug 2003 22:03:22 -0700 Date: Tue, 19 Aug 2003 22:03:22 -0700 From: "David S. Miller" To: "Bryan O'Sullivan" Cc: netdev@oss.sgi.com Subject: Re: [TRIVIAL PATCH] export dev->state via sysfs Message-Id: <20030819220322.5b4911eb.davem@redhat.com> In-Reply-To: <1061355896.10843.22.camel@camp4.serpentine.com> References: <1061355896.10843.22.camel@camp4.serpentine.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5111 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 Content-Length: 292 Lines: 8 On 19 Aug 2003 22:04:56 -0700 "Bryan O'Sullivan" wrote: > This trivial patch exports the netdev state field via sysfs. The > motivation is to make it possible to check link state from userspace > without having to go through the netlink interface. Please use ethtool. From pekkas@netcore.fi Tue Aug 19 22:19:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 22:19:33 -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 h7K5JQoO016643 for ; Tue, 19 Aug 2003 22:19:28 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7K5IAT00452; Wed, 20 Aug 2003 08:18:10 +0300 Date: Wed, 20 Aug 2003 08:18:09 +0300 (EEST) From: Pekka Savola To: "David S. Miller" cc: Richard Underwood , , , , , , , , , , , , , Subject: host vs interface address ownership [Re: [2.4 PATCH] bugfix: ARP respond on all devices] In-Reply-To: <20030819095611.0fb8f9a3.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5112 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 Content-Length: 1576 Lines: 40 On Tue, 19 Aug 2003, David S. Miller wrote: > On Tue, 19 Aug 2003 13:02:20 +0100 > Richard Underwood wrote: > > > David S. Miller wrote: > > > Under Linux, by default, IP addresses are owned by the system > > > not by interfaces. This increases the likelyhood of successful > > > communication on a subnet. > > > > > This is crap. > > Nope, the RFCs allow this. > > So this is where we must agree to disagree. Because host ownership of > IP addresses is the basis for all of the arguments and it completely > justifies Linux's ARP behavior on both sides. Maybe I'm missing something -- I'm not sure what exactly you're including in the models -- but wouldn't it be possible to implement the "host ownership" model so that it would STILL honor any RFC out there (and similarly for "interface ownership")? For example, many IETF documents may state things like: The Home Agents List MAY be implemented in any manner consistent with the external behavior described in this document. .. which *seems* (without knowing which RFCs and sections of them you refer to for justifying host/interface ownership) to be a probable intent of allowing either model. Just as long as the external behaviour is consistent, you can implement it with any internal structure you wish. -- 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 pekkas@netcore.fi Tue Aug 19 22:33:09 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 22:33:11 -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 h7K5X7oO017577 for ; Tue, 19 Aug 2003 22:33:08 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7K5VVg00571; Wed, 20 Aug 2003 08:31:38 +0300 Date: Wed, 20 Aug 2003 08:31:31 +0300 (EEST) From: Pekka Savola To: "David S. Miller" cc: Daniel Gryniewicz , , , , , , , , , , , , , , Subject: ARP and knowledge of IP addresses [Re: [2.4 PATCH] bugfix: ARP respond on all devices] In-Reply-To: <20030819112912.359eaea6.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5113 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 Content-Length: 1041 Lines: 27 On Tue, 19 Aug 2003, David S. Miller wrote: [...] > Consider the situation logically. When you're replying to an > ARP, _HOW_ do you know what IP addresses are assigned to _MY_ > outgoing interfaces and _HOW_ do you know what subnets _EXIST_ > on the LAN? > > The answer to both is, you'd don't know these things _EVEN_ if > you are a router/gateway. Maybe I'm missing something but -- isn't it perfectly valid to assume the node *ITSELF* knows about its interfaces, IP addresses, and its routes? (Certainly, it can't know of what subnets exist on the LAN if those haven't been configured on the node, e.g. in the form of an "interface routes".) ARP could look it up. Sure, it would seem a bit like an OSI layering violation, but that's no news as OSI layering isn't strict anyway and has been shredded to pieces already in many other places. -- 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 hadi@cyberus.ca Tue Aug 19 23:44:47 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 23:44:52 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7K6ijoO021649 for ; Tue, 19 Aug 2003 23:44:46 -0700 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.12) id 19ok0M-000DCv-00; Mon, 18 Aug 2003 09:25:04 -0400 Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: Stephan von Krawczynski , willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org In-Reply-To: <20030818055555.248f2a01.davem@redhat.com> References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> <200308171827130739.00C3905F@192.168.128.16> <1061141045.21885.74.camel@dhcp23.swansea.linux.org.uk> <20030817224849.GB734@alpha.home.local> <20030817223118.3cbc497c.davem@redhat.com> <20030818133957.3d3d51d2.skraw@ithnet.com> <20030818044419.0bc24d14.davem@redhat.com> <20030818143401.1352d158.skraw@ithnet.com> <20030818053007.7852ca77.davem@redhat.com> <20030818145316.3a81f70c.skraw@ithnet.com> <20030818055555.248f2a01.davem@redhat.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1061213027.16017.2220.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 18 Aug 2003 09:23:48 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 5114 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 836 Lines: 25 On Mon, 2003-08-18 at 08:55, David S. Miller wrote: > Under Linux, by default, IP addresses are owned by the system > not by interfaces. Folks, the above is the punch line. I am just going over all emails on this thread and i see this point being missed. People are quoting tons of RFCs while the really important point being missed is the above line. > For scenerios where this doesn't work, we have ways to make the > kernel behave the way you want it to. > and you are provided with alternatives if you dont like the way it works. I think even Julian is happy with this. Ok, heres a neat little feature requst: someone create arp rewrite rules with ARPtable so we can have do MAC address aliasing. Guys, Lets have Davem worry about more imporant things. Maybe we should have a web page or FAQ on this topic? cheers, jamal From bloemsaa@xs4all.nl Tue Aug 19 23:55:47 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 19 Aug 2003 23:55:50 -0700 (PDT) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7K6tkoO022100 for ; Tue, 19 Aug 2003 23:55:47 -0700 Received: from llewella (vialle.xs4all.nl [213.84.6.25]) by smtpzilla2.xs4all.nl (8.12.9/8.12.9) with SMTP id h7K6tETg071650; Wed, 20 Aug 2003 08:55:28 +0200 (CEST) Message-ID: <005201c366e8$0a422a20$c801a8c0@llewella> From: "Bas Bloemsaat" To: , "David S. Miller" Cc: "Stephan von Krawczynski" , , , , , , , , , , , References: <20030728213933.F81299@coredump.scriptkiddie.org> <200308171509570955.003E4FEC@192.168.128.16> <200308171516090038.0043F977@192.168.128.16> <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> <200308171555280781.0067FB36@192.168.128.16> <1061134091.21886.40.camel@dhcp23.swansea.linux.org.uk> <200308171759540391.00AA8CAB@192.168.128.16> <1061137577.21885.50.camel@dhcp23.swansea.linux.org.uk> <200308171827130739.00C3905F@192.168.128.16> <1061141045.21885.74.camel@dhcp23.swansea.linux.org.uk> <20030817224849.GB734@alpha.home.local> <20030817223118.3cbc497c.davem@redhat.com> <20030818133957.3d3d51d2.skraw@ithnet.com> <20030818044419.0bc24d14.davem@redhat.com> <20030818143401.1352d158.skraw@ithnet.com> <20030818053007.7852ca77.davem@redhat.com> <20030818145316.3a81f70c.skraw@ithnet.com> <20030818055555.248f2a01.davem@redhat.com> <1061213027.16017.2220.camel@jzny.localdomain> Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Date: Wed, 20 Aug 2003 08:55:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 5115 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bloemsaa@xs4all.nl Precedence: bulk X-list: netdev Content-Length: 1129 Lines: 29 > > Under Linux, by default, IP addresses are owned by the system > > not by interfaces. > > Folks, the above is the punch line. I am just going over all emails on > this thread and i see this point being missed. > People are quoting tons of RFCs while the really important point being > missed is the above line. If that is true, then source routing would not work either: it would just route it back to the host, select the next hop, and choose based on destination routing tables. There would be no way to know which IP address is bound to which interface. If that is true, then then having multiple network interfaces on a segment would in effect mean that you have one IP address on multiple interfaces. As Alan mentioned that is an illegal configuration. If that is true, seperation of firewall interfaces is impossible. All of which isn't the case. I'll let it rest for now. I don't think quoting rfc's, pointing out that it doesn't confirm to any reference implementation of IP, or any argument are going to help. This is not a case where technical merits win. This is politics. I don't care anymore. Regards, Bas From rap@zurich.ibm.com Wed Aug 20 01:55:07 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 01:55:10 -0700 (PDT) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7K8t4oO025281 for ; Wed, 20 Aug 2003 01:55:06 -0700 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-2.de.ibm.com (8.12.9/8.12.8) with ESMTP id h7K8rq7o134034; Wed, 20 Aug 2003 10:53:54 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h7K8nr5t052866; Wed, 20 Aug 2003 10:49:53 +0200 Received: from zurich.ibm.com (dhcp69-191.zurich.ibm.com [9.4.69.191]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA57134; Wed, 20 Aug 2003 10:49:46 +0200 Message-ID: <3F43362A.7090802@zurich.ibm.com> Date: Wed, 20 Aug 2003 10:49:46 +0200 From: Roman Pletka User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020903 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bas Bloemsaat CC: "David S. Miller" , Alan Cox , skraw@ithnet.com, willy@w.ods.org, richard@aspectgroup.co.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices References: <353568DCBAE06148B70767C1B1A93E625EAB58@post.pc.aspectgroup.co.uk><20030819145403.GA3407@alpha.home.local><20030819170751.2b92ba2e.skraw@ithnet.com><20030819085717.56046afd.davem@redhat.com><20030819185219.116fd259.skraw@ithnet.com><1061319864.30565.52.camel@dhcp23.swansea.linux.org.uk> <20030819120131.1999b1ec.davem@redhat.com> <091f01c36686$dade2bf0$c801a8c0@llewella> X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5116 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rap@zurich.ibm.com Precedence: bulk X-list: netdev Content-Length: 299 Lines: 13 Bas Bloemsaat wrote: >>Indeed, would people stop quoting from RFC 985 and >>RFC 826. > > > RFC 826 is referenced from 1009 as describing ARP. So in effect it does > define a standard. RFC 1009 is obsolete too (by 1812 for the sake of completeness). Please stop quoting obsolete RFC's. -- Roman From vnuorval@tcs.hut.fi Wed Aug 20 04:23:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 04:23:21 -0700 (PDT) Received: from mail.tcs.hut.fi (mail.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KBNEoO007382 for ; Wed, 20 Aug 2003 04:23:16 -0700 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by mail.tcs.hut.fi (Postfix) with ESMTP id 2939E80019A; Wed, 20 Aug 2003 14:23:14 +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-6.4) with ESMTP id h7KBNE9s000603; Wed, 20 Aug 2003 14:23:14 +0300 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7KBNCtd000599; Wed, 20 Aug 2003 14:23:12 +0300 Date: Wed, 20 Aug 2003 14:23:12 +0300 (EEST) From: Ville Nuorvala To: davem@redhat.com, Cc: netdev@oss.sgi.com Subject: [PATCH] IPv6: Fix target address for (proxy/anycast) NA In-Reply-To: <20030819083621.2ae4abc8.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-377318441-782513297-1061378592=:541" X-archive-position: 5118 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 Content-Length: 1592 Lines: 41 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---377318441-782513297-1061378592=:541 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, the target address in neighbor advertisements must be the solicited address. Otherwise proxy NAs (and NAs for anycast addresses) don't work. Please apply! Thanks, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 ---377318441-782513297-1061378592=:541 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="ndisc_na_target.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="ndisc_na_target.patch" LS0tIGxpbnV4LTIuNS5PTEQvbmV0L2lwdjYvbmRpc2MuYwkyMDAzLTA4LTIw IDE0OjA5OjEzLjAwMDAwMDAwMCArMDMwMA0KKysrIGxpbnV4LTIuNS9uZXQv aXB2Ni9uZGlzYy5jCTIwMDMtMDgtMjAgMTQ6MDk6MjguMDAwMDAwMDAwICsw MzAwDQpAQCAtNDg1LDcgKzQ4NSw3IEBADQogICAgICAgICBtc2ctPmljbXBo LmljbXA2X292ZXJyaWRlICA9ICEhb3ZlcnJpZGU7DQogDQogICAgICAgICAv KiBTZXQgdGhlIHRhcmdldCBhZGRyZXNzLiAqLw0KLQlpcHY2X2FkZHJfY29w eSgmbXNnLT50YXJnZXQsIHNyY19hZGRyKTsNCisJaXB2Nl9hZGRyX2NvcHko Jm1zZy0+dGFyZ2V0LCBzb2xpY2l0ZWRfYWRkcik7DQogDQogCWlmIChpbmNf b3B0KQ0KIAkJbmRpc2NfZmlsbF9vcHRpb24obXNnLT5vcHQsIE5EX09QVF9U QVJHRVRfTExfQUREUiwgZGV2LT5kZXZfYWRkciwgZGV2LT5hZGRyX2xlbik7 DQo= ---377318441-782513297-1061378592=:541-- From vnuorval@tcs.hut.fi Wed Aug 20 04:40:19 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 04:40:26 -0700 (PDT) Received: from mail.tcs.hut.fi (mail.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KBeFoO008179 for ; Wed, 20 Aug 2003 04:40:18 -0700 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by mail.tcs.hut.fi (Postfix) with ESMTP id C77718000B7; Wed, 20 Aug 2003 14:40:14 +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-6.4) with ESMTP id h7KBeE9s000683; Wed, 20 Aug 2003 14:40:14 +0300 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7KBeEeM000679; Wed, 20 Aug 2003 14:40:14 +0300 Date: Wed, 20 Aug 2003 14:40:14 +0300 (EEST) From: Ville Nuorvala To: davem@redhat.com, Cc: netdev@oss.sgi.com Subject: [PATCH] IPv6: Protect proxied addresses against DAD Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-377318441-2045924552-1061379614=:541" X-archive-position: 5119 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 Content-Length: 2809 Lines: 61 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---377318441-2045924552-1061379614=:541 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, a proxy has to reply to DAD probes, otherwise it can't protect its addresses. The attached patch fixes this, please apply! Thanks, Ville PS. Dave, you misspelled my email address in csets 1.1199.1.10, 1.1199.1.12 and 1.1199.1.16 ;) -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 ---377318441-2045924552-1061379614=:541 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="proxy_dad.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="proxy_dad.patch" LS0tIGxpbnV4LTIuNS5PTEQvbmV0L2lwdjYvbmRpc2MuYwkyMDAzLTA4LTIw IDE0OjEwOjE2LjAwMDAwMDAwMCArMDMwMA0KKysrIGxpbnV4LTIuNS9uZXQv aXB2Ni9uZGlzYy5jCTIwMDMtMDgtMjAgMTQ6MTA6MzAuMDAwMDAwMDAwICsw MzAwDQpAQCAtODYxLDcgKzg2MSw4IEBADQogCQlzdHJ1Y3QgaW5ldDZfZGV2 ICppbjZfZGV2ID0gaW42X2Rldl9nZXQoZGV2KTsNCiANCiAJCWlmIChpbjZf ZGV2ICYmIGluNl9kZXYtPmNuZi5mb3J3YXJkaW5nICYmDQotCQkgICAgKGFk ZHJfdHlwZSAmIElQVjZfQUREUl9VTklDQVNUKSAmJg0KKwkJICAgIChhZGRy X3R5cGUgJiBJUFY2X0FERFJfVU5JQ0FTVCB8fA0KKwkJICAgICBhZGRyX3R5 cGUgPT0gSVBWNl9BRERSX0FOWSkgJiYNCiAJCSAgICBwbmVpZ2hfbG9va3Vw KCZuZF90YmwsICZtc2ctPnRhcmdldCwgZGV2LCAwKSkgew0KIAkJCWludCBp bmMgPSBpcHY2X2FkZHJfdHlwZShkYWRkcikmSVBWNl9BRERSX01VTFRJQ0FT VDsNCiANCkBAIC04NzQsMTIgKzg3NSwyMCBAQA0KIAkJCQllbHNlDQogCQkJ CQluZF90Ymwuc3RhdHMucmN2X3Byb2Jlc191Y2FzdCsrOw0KIAkJCQkJDQot CQkJCW5laWdoID0gbmVpZ2hfZXZlbnRfbnMoJm5kX3RibCwgbGxhZGRyLCBz YWRkciwgZGV2KTsNCisJCQkJaWYgKGFkZHJfdHlwZSAmIElQVjZfQUREUl9V TklDQVNUKSB7DQorCQkJCQluZWlnaCA9IG5laWdoX2V2ZW50X25zKCZuZF90 YmwsIGxsYWRkciwgc2FkZHIsIGRldik7DQogDQotCQkJCWlmIChuZWlnaCkg ew0KLQkJCQkJbmRpc2Nfc2VuZF9uYShkZXYsIG5laWdoLCBzYWRkciwgJm1z Zy0+dGFyZ2V0LA0KLQkJCQkJCSAgICAgIDAsIDEsIDAsIDEpOw0KLQkJCQkJ bmVpZ2hfcmVsZWFzZShuZWlnaCk7DQorCQkJCQlpZiAobmVpZ2gpIHsNCisJ CQkJCQluZGlzY19zZW5kX25hKGRldiwgbmVpZ2gsIHNhZGRyLCAmbXNnLT50 YXJnZXQsDQorCQkJCQkJCSAgICAgIDAsIDEsIDAsIDEpOw0KKwkJCQkJCW5l aWdoX3JlbGVhc2UobmVpZ2gpOw0KKwkJCQkJfQ0KKwkJCQl9IGVsc2Ugew0K KwkJCQkJLyogcHJveHkgc2hvdWxkIGFsc28gcHJvdGVjdCBhZ2FpbnN0IERB RCAqLw0KKwkJCQkJc3RydWN0IGluNl9hZGRyIG1hZGRyOw0KKwkJCQkJaXB2 Nl9hZGRyX2FsbF9ub2RlcygmbWFkZHIpOw0KKwkJCQkJbmRpc2Nfc2VuZF9u YShkZXYsIE5VTEwsICZtYWRkciwgJm1zZy0+dGFyZ2V0LCANCisJCQkJCQkg ICAgICAwLCAwLCAwLCAxKTsNCiAJCQkJfQ0KIAkJCX0gZWxzZSB7DQogCQkJ CXN0cnVjdCBza19idWZmICpuID0gc2tiX2Nsb25lKHNrYiwgR0ZQX0FUT01J Qyk7DQo= ---377318441-2045924552-1061379614=:541-- From yoshfuji@linux-ipv6.org Wed Aug 20 04:42:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 04:42:52 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KBggoO008571 for ; Wed, 20 Aug 2003 04:42:44 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h7KBh41M005944; Wed, 20 Aug 2003 20:43:04 +0900 Date: Wed, 20 Aug 2003 20:43:04 +0900 (JST) Message-Id: <20030820.204304.07033882.yoshfuji@linux-ipv6.org> To: vnuorval@tcs.hut.fi Cc: davem@redhat.com, netdev@oss.sgi.com, usagi-core@linux-ipv6.org Subject: Re: (usagi-core 15040) [PATCH] IPv6: Protect proxied addresses against DAD From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 5120 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 720 Lines: 18 In article (at Wed, 20 Aug 2003 14:40:14 +0300 (EEST)), Ville Nuorvala says: > --- linux-2.5.OLD/net/ipv6/ndisc.c 2003-08-20 14:10:16.000000000 +0300 > +++ linux-2.5/net/ipv6/ndisc.c 2003-08-20 14:10:30.000000000 +0300 > @@ -861,7 +861,8 @@ > struct inet6_dev *in6_dev = in6_dev_get(dev); > > if (in6_dev && in6_dev->cnf.forwarding && > - (addr_type & IPV6_ADDR_UNICAST) && > + (addr_type & IPV6_ADDR_UNICAST || > + addr_type == IPV6_ADDR_ANY) && > pneigh_lookup(&nd_tbl, &msg->target, dev, 0)) { > int inc = ipv6_addr_type(daddr)&IPV6_ADDR_MULTICAST; > I believe we don't need this chunk. --ypshfuj From emann@mrv.com Wed Aug 20 05:50:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 05:50:23 -0700 (PDT) Received: from apollo.nbase.co.il (apollo.nbase.co.il [194.90.137.2]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KCoDoO010642 for ; Wed, 20 Aug 2003 05:50:15 -0700 Received: from mrv.com ([194.90.139.36]) by apollo.nbase.co.il (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-44418U200L2S100) with ESMTP id AAA360; Wed, 20 Aug 2003 15:54:41 +0200 Message-ID: <3F436EE7.1030104@mrv.com> Date: Wed, 20 Aug 2003 15:51:51 +0300 From: Eran Mann User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: [patch 2.4] kernel oops on VLAN removal References: <3F424405.6020002@mrv.com> <20030819124154.75ec0383.davem@redhat.com> In-Reply-To: <20030819124154.75ec0383.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5121 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: emann@mrv.com Precedence: bulk X-list: netdev Content-Length: 773 Lines: 28 David S. Miller wrote: > On Tue, 19 Aug 2003 18:36:37 +0300 > Eran Mann wrote: > > >>The current code attempts to add a proc entry for each vlan device, >>however there is no check whether this attempt succeeded. When a device >>is unregistered it tries to remove the proc entry, if none was added >>the oops follows... > > > Patch applied to my 2.4.x tree, scheduled for 2.4.23-preX > > Can someone check out 2.6.x? > It looks the same in 2.6.0-test3. The patch applies (with small offsets) and works (the oops is much harder to trigger in 2.6.x since PROC_NDYNAMIC is increased to 16384, I had to reduce it to 4096 to trigger the oops). -- Eran Mann Senior Software Engineer MRV International Tel: 972-4-9936297 Fax: 972-4-9890430 www.mrv.com From hstenzel@us.ibm.com Wed Aug 20 05:54:38 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 05:54:43 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KCsaoO011085 for ; Wed, 20 Aug 2003 05:54:37 -0700 Received: from westrelay05.boulder.ibm.com (westrelay05.boulder.ibm.com [9.17.193.33]) by e34.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h7KCrZEh192814; Wed, 20 Aug 2003 08:53:35 -0400 Received: from d03nm118.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.193.81]) by westrelay05.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h7KCqnT5152560; Wed, 20 Aug 2003 06:52:50 -0600 Received: from us.ibm.com ([9.27.176.216]) by d03nm118.boulder.ibm.com (Lotus Domino Release 6.0.2CF2) with ESMTP id 2003082006521047-58663 ; Wed, 20 Aug 2003 06:52:10 -0600 Message-ID: <3F436EF9.1040502@us.ibm.com> Date: Wed, 20 Aug 2003 08:52:09 -0400 From: Harley Stenzel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030625 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" Cc: Richard Underwood , skraw@ithnet.com, willy@w.ods.org, alan@lxorguk.ukuu.org.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices References: <353568DCBAE06148B70767C1B1A93E625EAB5D@post.pc.aspectgroup.co.uk> <20030819112103.373fce27.davem@redhat.com> In-Reply-To: <20030819112103.373fce27.davem@redhat.com> X-MIMETrack: Itemize by SMTP Server on D03NM118/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/20/2003 06:52:10, Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/20/2003 06:52:50, Serialize complete at 08/20/2003 06:52:50 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-archive-position: 5122 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hstenzel@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 980 Lines: 27 David S. Miller wrote: > On Tue, 19 Aug 2003 19:05:13 +0100 > Richard Underwood wrote: > >> The ARP request represents all FUTURE >>packets being sent out that interface, not just the one single packet that >>happened to kick of this ARP request. > > That's RIGHT! And by your own argument the source address > in the ARP request IS IRRELEVANT and is to be ignored! > The source address in the ARP request is not irrelevant, because a broadcast arp request causes all recipients of that broadcast request to update their arp cache entry (if they have a cache entry for that IP) for the IP specified in the source with the MAC specified in the request. So, in an environment where a single address is aliased in multiple places, such as tunnel endpoints and loopback aliases, and in multi-homed same-segment configs, it is unpredictable asto which IP will be bound to which MAC for every machine (or arp cache) on the network. --Harley From vnuorval@tcs.hut.fi Wed Aug 20 05:58:11 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 05:58:16 -0700 (PDT) Received: from mail.tcs.hut.fi (mail.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KCwAoO011489 for ; Wed, 20 Aug 2003 05:58:11 -0700 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by mail.tcs.hut.fi (Postfix) with ESMTP id C5D1E800193; Wed, 20 Aug 2003 15:58:08 +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-6.4) with ESMTP id h7KCw89s000951; Wed, 20 Aug 2003 15:58:08 +0300 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7KCw8D9000947; Wed, 20 Aug 2003 15:58:08 +0300 Date: Wed, 20 Aug 2003 15:58:08 +0300 (EEST) From: Ville Nuorvala To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Cc: davem@redhat.com, , Subject: Re: (usagi-core 15040) [PATCH] IPv6: Protect proxied addresses against DAD In-Reply-To: <20030820.204304.07033882.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-377318441-1858997066-1061384288=:756" X-archive-position: 5123 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 Content-Length: 3985 Lines: 91 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---377318441-1858997066-1061384288=:756 Content-Type: TEXT/PLAIN; charset=iso-8859-15 On Wed, 20 Aug 2003, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote: > In article (at Wed, 20 Aug 2003 14:40:14 +0300 (EEST)), Ville Nuorvala says: > > > --- linux-2.5.OLD/net/ipv6/ndisc.c 2003-08-20 14:10:16.000000000 +0300 > > +++ linux-2.5/net/ipv6/ndisc.c 2003-08-20 14:10:30.000000000 +0300 > > @@ -861,7 +861,8 @@ > > struct inet6_dev *in6_dev = in6_dev_get(dev); > > > > if (in6_dev && in6_dev->cnf.forwarding && > > - (addr_type & IPV6_ADDR_UNICAST) && > > + (addr_type & IPV6_ADDR_UNICAST || > > + addr_type == IPV6_ADDR_ANY) && > > pneigh_lookup(&nd_tbl, &msg->target, dev, 0)) { > > int inc = ipv6_addr_type(daddr)&IPV6_ADDR_MULTICAST; > > > > I believe we don't need this chunk. No, it is needed. Normal neighbor solicitations are sent using a unicast source address, but DAD probes are sent using the unspecified address as source. If the check for IPV6_ADDR_ANY isn't done right there, the proxy won't handle the DAD probes, since it never enters the shown if block. The new if (addr_type & IPV6_ADDR_UNICAST) { ... } else { <- addr_type == IPV6_ADDR_ANY ... } block inside it handles the different cases sending a unicast NA to a normal NS and a multicast NA to a DAD. I've updated the comment in my new patch to clarify this. Please use it instead. Regards, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 ---377318441-1858997066-1061384288=:756 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="proxy_dad_v2.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="proxy_dad_v2.patch" LS0tIGxpbnV4LTIuNS5PTEQvbmV0L2lwdjYvbmRpc2MuYwkyMDAzLTA4LTIw IDE0OjEwOjE2LjAwMDAwMDAwMCArMDMwMA0KKysrIGxpbnV4LTIuNS9uZXQv aXB2Ni9uZGlzYy5jCTIwMDMtMDgtMjAgMTU6Mzk6MzkuMDAwMDAwMDAwICsw MzAwDQpAQCAtODYxLDcgKzg2MSw4IEBADQogCQlzdHJ1Y3QgaW5ldDZfZGV2 ICppbjZfZGV2ID0gaW42X2Rldl9nZXQoZGV2KTsNCiANCiAJCWlmIChpbjZf ZGV2ICYmIGluNl9kZXYtPmNuZi5mb3J3YXJkaW5nICYmDQotCQkgICAgKGFk ZHJfdHlwZSAmIElQVjZfQUREUl9VTklDQVNUKSAmJg0KKwkJICAgIChhZGRy X3R5cGUgJiBJUFY2X0FERFJfVU5JQ0FTVCB8fA0KKwkJICAgICBhZGRyX3R5 cGUgPT0gSVBWNl9BRERSX0FOWSkgJiYNCiAJCSAgICBwbmVpZ2hfbG9va3Vw KCZuZF90YmwsICZtc2ctPnRhcmdldCwgZGV2LCAwKSkgew0KIAkJCWludCBp bmMgPSBpcHY2X2FkZHJfdHlwZShkYWRkcikmSVBWNl9BRERSX01VTFRJQ0FT VDsNCiANCkBAIC04NzQsMTIgKzg3NSwxOSBAQA0KIAkJCQllbHNlDQogCQkJ CQluZF90Ymwuc3RhdHMucmN2X3Byb2Jlc191Y2FzdCsrOw0KIAkJCQkJDQot CQkJCW5laWdoID0gbmVpZ2hfZXZlbnRfbnMoJm5kX3RibCwgbGxhZGRyLCBz YWRkciwgZGV2KTsNCisJCQkJaWYgKGFkZHJfdHlwZSAmIElQVjZfQUREUl9V TklDQVNUKSB7DQorCQkJCQluZWlnaCA9IG5laWdoX2V2ZW50X25zKCZuZF90 YmwsIGxsYWRkciwgc2FkZHIsIGRldik7DQogDQotCQkJCWlmIChuZWlnaCkg ew0KLQkJCQkJbmRpc2Nfc2VuZF9uYShkZXYsIG5laWdoLCBzYWRkciwgJm1z Zy0+dGFyZ2V0LA0KLQkJCQkJCSAgICAgIDAsIDEsIDAsIDEpOw0KLQkJCQkJ bmVpZ2hfcmVsZWFzZShuZWlnaCk7DQorCQkJCQlpZiAobmVpZ2gpIHsNCisJ CQkJCQluZGlzY19zZW5kX25hKGRldiwgbmVpZ2gsIHNhZGRyLCAmbXNnLT50 YXJnZXQsDQorCQkJCQkJCSAgICAgIDAsIDEsIDAsIDEpOw0KKwkJCQkJCW5l aWdoX3JlbGVhc2UobmVpZ2gpOw0KKwkJCQkJfQ0KKwkJCQl9IGVsc2UgeyAv KiBhZGRyX3R5cGUgPT0gSVBWNl9BRERSX0FOWSwgaS5lLiBhIERBRCBwcm9i ZSAqLyANCisJCQkJCXN0cnVjdCBpbjZfYWRkciBtYWRkcjsNCisJCQkJCWlw djZfYWRkcl9hbGxfbm9kZXMoJm1hZGRyKTsNCisJCQkJCW5kaXNjX3NlbmRf bmEoZGV2LCBOVUxMLCAmbWFkZHIsICZtc2ctPnRhcmdldCwgDQorCQkJCQkJ ICAgICAgMCwgMCwgMCwgMSk7DQogCQkJCX0NCiAJCQl9IGVsc2Ugew0KIAkJ CQlzdHJ1Y3Qgc2tfYnVmZiAqbiA9IHNrYl9jbG9uZShza2IsIEdGUF9BVE9N SUMpOw0K ---377318441-1858997066-1061384288=:756-- From yoshfuji@linux-ipv6.org Wed Aug 20 06:39:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 06:39:25 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KDdEoO013673 for ; Wed, 20 Aug 2003 06:39:15 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h7KDdY1M006377; Wed, 20 Aug 2003 22:39:34 +0900 Date: Wed, 20 Aug 2003 22:39:33 +0900 (JST) Message-Id: <20030820.223933.69651454.yoshfuji@linux-ipv6.org> To: vnuorval@tcs.hut.fi Cc: davem@redhat.com, netdev@oss.sgi.com, usagi-core@linux-ipv6.org Subject: Re: (usagi-core 15040) [PATCH] IPv6: Protect proxied addresses against DAD From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20030820.204304.07033882.yoshfuji@linux-ipv6.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 5124 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 864 Lines: 22 In article (at Wed, 20 Aug 2003 15:58:08 +0300 (EEST)), Ville Nuorvala says: > > > if (in6_dev && in6_dev->cnf.forwarding && > > > - (addr_type & IPV6_ADDR_UNICAST) && > > > + (addr_type & IPV6_ADDR_UNICAST || > > > + addr_type == IPV6_ADDR_ANY) && > > > pneigh_lookup(&nd_tbl, &msg->target, dev, 0)) { > > > int inc = ipv6_addr_type(daddr)&IPV6_ADDR_MULTICAST; > > > > > > > I believe we don't need this chunk. > > No, it is needed. Normal neighbor solicitations are sent using a unicast > source address, but DAD probes are sent using the unspecified address as > source. Oops, sorry, I read it as it were "ANYCAST." I agree. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From skraw@ithnet.com Wed Aug 20 07:15:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 07:15:42 -0700 (PDT) Received: from heather-ng.ithnet.com (mail3.ithnet.com [217.64.64.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KEFEoO015037 for ; Wed, 20 Aug 2003 07:15:36 -0700 Received: (qmail 31377 invoked by uid 0); 20 Aug 2003 14:15:14 -0000 Received: from skraw@ithnet.com by heather-ng (Processed in 0.566363 secs); 20 Aug 2003 14:15:14 -0000 X-Virus-Status: No Received: from unknown (HELO ithnet.com) (217.64.64.14) by heather-ng.ithnet.com with SMTP; 20 Aug 2003 14:15:13 -0000 X-Sender-Authentication: SMTPafterPOP by from 217.64.64.14 Date: Wed, 20 Aug 2003 16:15:12 +0200 From: Stephan von Krawczynski To: Roman Pletka Cc: bloemsaa@xs4all.nl, davem@redhat.com, alan@lxorguk.ukuu.org.uk, willy@w.ods.org, richard@aspectgroup.co.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030820161512.6ccdd963.skraw@ithnet.com> In-Reply-To: <3F43362A.7090802@zurich.ibm.com> References: <353568DCBAE06148B70767C1B1A93E625EAB58@post.pc.aspectgroup.co.uk> <20030819145403.GA3407@alpha.home.local> <20030819170751.2b92ba2e.skraw@ithnet.com> <20030819085717.56046afd.davem@redhat.com> <20030819185219.116fd259.skraw@ithnet.com> <3F43362A.7090802@zurich.ibm.com> Organization: ith Kommunikationstechnik GmbH X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5125 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: skraw@ithnet.com Precedence: bulk X-list: netdev Content-Length: 1585 Lines: 62 On Wed, 20 Aug 2003 10:49:46 +0200 Roman Pletka wrote: > Bas Bloemsaat wrote: > >>Indeed, would people stop quoting from RFC 985 and > >>RFC 826. > > > > > > RFC 826 is referenced from 1009 as describing ARP. So in effect it does > > define a standard. > > RFC 1009 is obsolete too (by 1812 for the sake of completeness). > Please stop quoting obsolete RFC's. > > -- Roman One of the big advantages of RFCs is that everybody can read them. In fact if one names a special RFC for proving something he said, he should at least have read it once: 3.3.2 Address Resolution Protocol - ARP Routers that implement ARP MUST be compliant and SHOULD be unconditionally compliant with the requirements in [INTRO:2]. ... INTRO:2. Internet Engineering Task Force (R. Braden, Editor), "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, USC/Information Sciences Institute, October 1989. => 2.3.2 Address Resolution Protocol -- ARP 2.3.2.1 ARP Cache Validation An implementation of the Address Resolution Protocol (ARP) [LINK:2] MUST provide a mechanism to flush out-of-date cache entries. If this mechanism involves a timeout, it SHOULD be possible to configure the timeout value. ... [LINK:2] "An Ethernet Address Resolution Protocol," D. Plummer, RFC-826, November 1982. => RFC-826 is _valid_ Why do you think it is not valid, Roman? Where do you read that? Regards, Stephan From rap@zurich.ibm.com Wed Aug 20 07:50:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 07:50:29 -0700 (PDT) Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KEoGoO016459 for ; Wed, 20 Aug 2003 07:50:21 -0700 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h7KEn59e080716; Wed, 20 Aug 2003 16:49:07 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h7KEhm5t016526; Wed, 20 Aug 2003 16:43:48 +0200 Received: from zurich.ibm.com (dhcp69-191.zurich.ibm.com [9.4.69.191]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA178024; Wed, 20 Aug 2003 16:43:42 +0200 Message-ID: <3F43891E.9060204@zurich.ibm.com> Date: Wed, 20 Aug 2003 16:43:42 +0200 From: Roman Pletka User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020903 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephan von Krawczynski CC: bloemsaa@xs4all.nl, davem@redhat.com, alan@lxorguk.ukuu.org.uk, willy@w.ods.org, richard@aspectgroup.co.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices References: <353568DCBAE06148B70767C1B1A93E625EAB58@post.pc.aspectgroup.co.uk> <20030819145403.GA3407@alpha.home.local> <20030819170751.2b92ba2e.skraw@ithnet.com> <20030819085717.56046afd.davem@redhat.com> <20030819185219.116fd259.skraw@ithnet.com> <3F43362A.7090802@zurich.ibm.com> <20030820161512.6ccdd963.skraw@ithnet.com> X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5126 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rap@zurich.ibm.com Precedence: bulk X-list: netdev Content-Length: 810 Lines: 26 Stephan von Krawczynski wrote: > > 2.3.2 Address Resolution Protocol -- ARP > > 2.3.2.1 ARP Cache Validation > > An implementation of the Address Resolution Protocol (ARP) > [LINK:2] MUST provide a mechanism to flush out-of-date cache > entries. If this mechanism involves a timeout, it SHOULD be > possible to configure the timeout value. > > ... > > [LINK:2] "An Ethernet Address Resolution Protocol," D. Plummer, RFC-826, > November 1982. > > > Please read carefully what you have quoted: It says: *An* implementation... and then goes on with a citation of RFC 826. A simple citation does not make a valid standard yet. It just refers to it as an example for this specific issue. That's all. -- Roman From richard@aspectgroup.co.uk Wed Aug 20 07:50:23 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 07:50:29 -0700 (PDT) Received: from letters.pc.aspectgroup.co.uk (granite.aspectgroup.co.uk [212.187.249.254]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KEoMoO016467 for ; Wed, 20 Aug 2003 07:50:23 -0700 Received: by letters.pc.aspectgroup.co.uk with Internet Mail Service (5.5.2656.59) id ; Wed, 20 Aug 2003 09:58:52 +0100 Message-ID: <353568DCBAE06148B70767C1B1A93E625EAB61@post.pc.aspectgroup.co.uk> From: Richard Underwood To: "'David S. Miller'" , Alan Cox Cc: skraw@ithnet.com, willy@w.ods.org, Richard Underwood , carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: RE: [2.4 PATCH] bugfix: ARP respond on all devices Date: Wed, 20 Aug 2003 09:58:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-archive-position: 5127 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: richard@aspectgroup.co.uk Precedence: bulk X-list: netdev Content-Length: 3791 Lines: 102 David S. Miller wrote: > > Indeed, would people stop quoting from RFC 985 and > RFC 826. In case anyone missed it, the following message was posted to linux-net and netdev. This is currently a draft standard, but anyone implementing IPv6 should be following it. It clearly states that the the source address for the equivalent of the ARP request should be the INTERFACE address. While it doesn't directly apply to IPv4 (except for David's claim that IPv4 ARP is based on IPv6 ARP) it does clarify the situation nicely. I, for one, will be glad when (!) we all migrade to IPv6 and we can once and all be done with this nonsense, unless Linux plans to deviate from the standard? Thanks, Richard -----Original Message----- From: Steven Blake [mailto:slblake@petri-meat.com] Sent: 20 August 2003 05:58 To: David S. Miller Cc: netdev@oss.sgi.com; linux-net@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices On Tue, 2003-08-19 at 13:53, David S. Miller wrote: > BTW, this ARP source address algorithm we use comes from > ipv6, it would be instructive to go and see why they do > things the way they do. Are you sure? See below: ======================================================================== RFC 2461 Neighbor Discovery for IPv6 December 1998 4.3. Neighbor Solicitation Message Format Nodes send Neighbor Solicitations to request the link-layer address of a target node while also providing their own link-layer address to the target. Neighbor Solicitations are multicast when the node needs to resolve an address and unicast when the node seeks to verify the reachability of a neighbor. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Target Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address Either an address assigned to the interface from which this message is sent or (if Duplicate Address Detection is in progress [ADDRCONF]) the unspecified address. Destination Address Either the solicited-node multicast address corresponding to the target address, or the target address. Hop Limit 255 Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header. Narten, et. al. Standards Track [Page 21] ======================================================================== Regards, // Steve From yedok@hotmail.com Wed Aug 20 08:04:04 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 08:04:10 -0700 (PDT) Received: from hotmail.com (bay7-f102.bay7.hotmail.com [64.4.11.102]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KF44oO017517 for ; Wed, 20 Aug 2003 08:04:04 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 20 Aug 2003 08:03:58 -0700 Received: from 143.127.3.10 by by7fd.bay7.hotmail.msn.com with HTTP; Wed, 20 Aug 2003 15:03:58 GMT X-Originating-IP: [143.127.3.10] X-Originating-Email: [yedok@hotmail.com] From: "Narik Alatees" To: linux-net@vger.kernel.org, netdev@oss.sgi.com Cc: kuznet@ms2.inr.ac.ru, davem@redhat.com Subject: Suggestion to Improve delivery to local destinations Date: Wed, 20 Aug 2003 08:03:58 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Aug 2003 15:03:58.0900 (UTC) FILETIME=[487ED740:01C3672C] X-archive-position: 5128 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yedok@hotmail.com Precedence: bulk X-list: netdev Content-Length: 1068 Lines: 26 Currently ip_route_output_slow() sets rth->u.dst.output = ip_output; And then there is this line in the same function: if (flags & RTCF_LOCAL) { rth->u.dst.input = ip_local_deliver; rth->rt_spec_dst = fl.fl4_dst; } Basically what this means is that when the user calls skb->dst->output(), neighbour resolution would be implicitly performed. And at the time of actually sending an ARP request for link layer address the transmission is bypassed (due to the check in neigh_event_send()) and a dummy neighbour entry for the loopback device is constructured. I propose that in the above code fragment rth->u.dst.output be changed to ip_dev_loopback_xmit() (much like what happens inside of ip_mc_output()). I think this would _significantly_ improve performance in the delivery-to-local-destination case. What do you think? tx yedok _________________________________________________________________ Get MSN 8 and help protect your children with advanced parental controls. http://join.msn.com/?page=features/parental From hadi@cyberus.ca Wed Aug 20 08:28:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 08:28:23 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KFSHoO018528 for ; Wed, 20 Aug 2003 08:28:18 -0700 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.12) id 19pUsi-0001P9-00; Wed, 20 Aug 2003 11:28:16 -0400 Subject: RE: [2.4 PATCH] bugfix: ARP respond on all devices From: jamal Reply-To: hadi@cyberus.ca To: Richard Underwood Cc: "'David S. Miller'" , Alan Cox , skraw@ithnet.com, willy@w.ods.org, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org In-Reply-To: <1061393011.1029.51.camel@jzny.localdomain> References: <353568DCBAE06148B70767C1B1A93E625EAB61@post.pc.aspectgroup.co.uk> <1061393011.1029.51.camel@jzny.localdomain> Content-Type: text/plain Organization: jamalopolis Message-Id: <1061393295.1030.54.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Aug 2003 11:28:15 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 5129 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 264 Lines: 11 On Wed, 2003-08-20 at 11:23, jamal wrote: > What Dave meant is the state machine used in 2461 for IPV6 is actually > used in v4 as well. I should have said in linux - dont think in any BSD derived OSes. To be specific look at the neighbor code. cheers, jamal From garzik@gtf.org Wed Aug 20 08:47:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 08:47:37 -0700 (PDT) Received: from havoc.gtf.org (havoc.gtf.org [63.247.75.124]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KFlWoO019382 for ; Wed, 20 Aug 2003 08:47:34 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id 581196643; Wed, 20 Aug 2003 11:47:27 -0400 (EDT) Date: Wed, 20 Aug 2003 11:47:27 -0400 From: Jeff Garzik To: netdev@oss.sgi.com Subject: Best way to hook incoming eth pkts? Message-ID: <20030820154727.GB9119@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: 5130 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 Content-Length: 817 Lines: 27 All, netconsole, netdump, and ATA-over-ethernet (and others?) all have a need to directly send and receive ethernet packets from inside the kernel. The sending part is easy and obvious. The receive part isn't. Essentially, all the things mentioned above need some way to listen for incoming ethernet packets. ATA-over-ethernet has its own IANA-registered ethernet type, but netconsole and netdump are using IP/UDP instead of a custom ethernet protocol. So, two questions for the gurus of the crowd ;-) 1) What is the best way for an in-kernel piece of software to receive ethernet packets that are intended for it? 2) Possibly related to #1, is it a good or bad idea to consider sending netconsole/netdump directly over ethernet, eschewing the IP/UDP/syslog stuff? Comments and insight requested. Jeff From skraw@ithnet.com Wed Aug 20 08:55:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 08:55:29 -0700 (PDT) Received: from heather-ng.ithnet.com (mail3.ithnet.com [217.64.64.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KFt6oO019927 for ; Wed, 20 Aug 2003 08:55:22 -0700 Received: (qmail 10816 invoked by uid 0); 20 Aug 2003 15:55:05 -0000 Received: from skraw@ithnet.com by heather-ng (Processed in 0.456824 secs); 20 Aug 2003 15:55:05 -0000 X-Virus-Status: No Received: from unknown (HELO ithnet.com) (217.64.64.14) by heather-ng.ithnet.com with SMTP; 20 Aug 2003 15:55:05 -0000 X-Sender-Authentication: SMTPafterPOP by from 217.64.64.14 Date: Wed, 20 Aug 2003 17:55:04 +0200 From: Stephan von Krawczynski To: Roman Pletka Cc: bloemsaa@xs4all.nl, davem@redhat.com, alan@lxorguk.ukuu.org.uk, willy@w.ods.org, richard@aspectgroup.co.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030820175504.07658147.skraw@ithnet.com> In-Reply-To: <3F43891E.9060204@zurich.ibm.com> References: <353568DCBAE06148B70767C1B1A93E625EAB58@post.pc.aspectgroup.co.uk> <20030819145403.GA3407@alpha.home.local> <20030819170751.2b92ba2e.skraw@ithnet.com> <20030819085717.56046afd.davem@redhat.com> <20030819185219.116fd259.skraw@ithnet.com> <3F43891E.9060204@zurich.ibm.com> Organization: ith Kommunikationstechnik GmbH X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5131 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: skraw@ithnet.com Precedence: bulk X-list: netdev Content-Length: 1275 Lines: 38 On Wed, 20 Aug 2003 16:43:42 +0200 Roman Pletka wrote: > Stephan von Krawczynski wrote: > > > > 2.3.2 Address Resolution Protocol -- ARP > > > > 2.3.2.1 ARP Cache Validation > > > > An implementation of the Address Resolution Protocol (ARP) > > [LINK:2] MUST provide a mechanism to flush out-of-date cache > > entries. If this mechanism involves a timeout, it SHOULD be > > possible to configure the timeout value. > > > > ... > > > > [LINK:2] "An Ethernet Address Resolution Protocol," D. Plummer, RFC-826, > > November 1982. > > > > > > > > Please read carefully what you have quoted: > It says: *An* implementation... and then goes on with a citation of RFC 826. > A simple citation does not make a valid standard yet. It just refers to it > as an example for this specific issue. That's all. Sorry, but my reading is this "An implementation of the ( Address Resolution Protocol (ARP) [LINK:2] ) ..." Do you understand what I mean? If you insist on RFC-826 being only one of several (possible) ARP implementations, can you then please name an RFC where ARP as a protocol is clearly defined? I mean there must be one, or not? Regards, Stephan From shmulik.hen@intel.com Wed Aug 20 09:11:43 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 09:11:48 -0700 (PDT) Received: from hermes.hd.intel.com (fmr09.intel.com [192.52.57.35]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KGBfoO021143 for ; Wed, 20 Aug 2003 09:11:42 -0700 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.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 h7KG9KO05859 for ; Wed, 20 Aug 2003 16:09:20 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.hd.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 h7KG6Xq26360 for ; Wed, 20 Aug 2003 16:06:33 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.254.188]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003082009112818206 ; Wed, 20 Aug 2003 09:11:29 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Shmulik Hen Reply-To: shmulik.hen@intel.com Organization: Intel corp. To: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: [patch][bonding] fix kernel panic when removing the primary slave Date: Wed, 20 Aug 2003 19:11:27 +0300 User-Agent: KMail/1.4.3 References: <200308201733.31144.shmulik.hen@intel.com> In-Reply-To: <200308201733.31144.shmulik.hen@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200308201911.27902.shmulik.hen@intel.com> X-archive-position: 5133 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Content-Length: 1353 Lines: 41 When releasing the primary slave, there is a kernel panic because the bond->primary_slave is not set to NULL until after calling change_active_interface(), even though the slave was already detached from the slave list. Patch is against 2.4.22-rc2. -- | Shmulik Hen Advanced Network Services | | Israel Design Center, Jerusalem | | LAN Access Division, Platform Networking | | Intel Communications Group, Intel corp. | diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c 2003-08-20 17:17:57.000000000 +0300 +++ b/drivers/net/bonding/bond_main.c 2003-08-20 17:19:11.000000000 +0300 @@ -1976,6 +1976,10 @@ static int bond_release(struct net_devic /* release the slave from its bond */ bond_detach_slave(bond, our_slave); + if (bond->primary_slave == our_slave) { + bond->primary_slave = NULL; + } + printk (KERN_INFO "%s: releasing %s interface %s", master->name, (our_slave->state == BOND_STATE_ACTIVE) ? "active" : "backup", @@ -1994,10 +1998,6 @@ static int bond_release(struct net_devic master->name); } - if (bond->primary_slave == our_slave) { - bond->primary_slave = NULL; - } - if ((bond_mode == BOND_MODE_TLB) || (bond_mode == BOND_MODE_ALB)) { /* must be called only after the slave has been From jt@bougret.hpl.hp.com Wed Aug 20 09:48:58 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 09:49:03 -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 h7KGmvoO022816 for ; Wed, 20 Aug 2003 09:48:58 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel12.hp.com (Postfix) with ESMTP id 524D01C00BE9; Wed, 20 Aug 2003 09:48:57 -0700 (PDT) Received: from bougret.hpl.hp.com (mail@bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_26305)/8.9.3 HPLabs Timeshare Server) with ESMTP id JAA06251; Wed, 20 Aug 2003 09:48:53 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 19pW8j-0003fB-00; Wed, 20 Aug 2003 09:48:53 -0700 Date: Wed, 20 Aug 2003 09:48:53 -0700 To: "David S. Miller" Cc: shemminger@osdl.org, irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] convert ircomm to seq_file interface Message-ID: <20030820164853.GB14035@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20030818123142.6369fbff.shemminger@osdl.org> <20030818200923.GC6577@bougret.hpl.hp.com> <20030819212009.36a8dc03.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030819212009.36a8dc03.davem@redhat.com> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 5135 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev Content-Length: 798 Lines: 23 On Tue, Aug 19, 2003 at 09:20:09PM -0700, David S. Miller wrote: > On Mon, 18 Aug 2003 13:09:23 -0700 > Jean Tourrilhes wrote: > > > On Mon, Aug 18, 2003 at 12:31:42PM -0700, Stephen Hemminger wrote: > > > Convert ircomm /proc interface to seq_file. > > > > > > Note: don't need spin_lock_irq because list is not ever locked > > > from inside interrupt context. > > > > I don't agree with this change. > > I'll let you guys work this one out. Let me know when a > final version of the patch is ready. Oh, that's fairly simple. You just need to revert the spin_lock() to a spin_lock_irqsave(). By the way, I would prefer Stephen to not rock the boat when it come to locking, I know that the locking of the IrDA stack is still "fragile" in areas. Have fun... Jean From rap@zurich.ibm.com Wed Aug 20 09:49:20 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 09:49:24 -0700 (PDT) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KGnIoO022880 for ; Wed, 20 Aug 2003 09:49:19 -0700 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-2.de.ibm.com (8.12.9/8.12.8) with ESMTP id h7KGm57o157912; Wed, 20 Aug 2003 18:48:06 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h7KGlsFH246322; Wed, 20 Aug 2003 18:47:54 +0200 Received: from zurich.ibm.com (dhcp69-191.zurich.ibm.com [9.4.69.191]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id SAA90466; Wed, 20 Aug 2003 18:47:46 +0200 Message-ID: <3F43A631.50308@zurich.ibm.com> Date: Wed, 20 Aug 2003 18:47:45 +0200 From: Roman Pletka User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020903 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephan von Krawczynski CC: bloemsaa@xs4all.nl, davem@redhat.com, alan@lxorguk.ukuu.org.uk, willy@w.ods.org, richard@aspectgroup.co.uk, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices References: <353568DCBAE06148B70767C1B1A93E625EAB58@post.pc.aspectgroup.co.uk> <20030819145403.GA3407@alpha.home.local> <20030819170751.2b92ba2e.skraw@ithnet.com> <20030819085717.56046afd.davem@redhat.com> <20030819185219.116fd259.skraw@ithnet.com> <3F43891E.9060204@zurich.ibm.com> <20030820175504.07658147.skraw@ithnet.com> X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5136 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rap@zurich.ibm.com Precedence: bulk X-list: netdev Content-Length: 982 Lines: 28 Stephan von Krawczynski wrote: >On Wed, 20 Aug 2003 16:43:42 +0200 >Roman Pletka wrote: > > >>Please read carefully what you have quoted: >>It says: *An* implementation... and then goes on with a citation of RFC 826. >>A simple citation does not make a valid standard yet. It just refers to it >>as an example for this specific issue. That's all. > > >Sorry, but my reading is this "An implementation of the ( Address Resolution >Protocol (ARP) [LINK:2] ) ..." >Do you understand what I mean? > >If you insist on RFC-826 being only one of several (possible) ARP >implementations, can you then please name an RFC where ARP as a protocol is >clearly defined? I mean there must be one, or not? This is not the point. As has already been mentioned some days ago by davem RFC 826 explicitely states at the beginning that it is not the specification of an Internet Standard and thats what I meant. So let's stop spinning round on this. -- Roman From davidsen@tmr.com Wed Aug 20 09:59:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 09:59:42 -0700 (PDT) Received: from gatekeeper.tmr.com (tmr-02.dsl.thebiz.net [216.238.38.204]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KGxYoO023711 for ; Wed, 20 Aug 2003 09:59:36 -0700 Received: from localhost (davidsen@localhost) by gatekeeper.tmr.com (8.9.0/8.9.0) with SMTP id MAA14734; Wed, 20 Aug 2003 12:49:14 -0400 Date: Wed, 20 Aug 2003 12:49:14 -0400 (EDT) From: Bill Davidsen To: Daniel Gryniewicz cc: "David S. Miller" , alan@lxorguk.ukuu.org.uk, richard@aspectgroup.co.uk, skraw@ithnet.com, willy@w.ods.org, carlosev@newipnet.com, lamont@scriptkiddie.org, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices In-Reply-To: <1061320363.3744.14.camel@athena.fprintf.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5137 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davidsen@tmr.com Precedence: bulk X-list: netdev Content-Length: 1995 Lines: 42 On 19 Aug 2003, Daniel Gryniewicz wrote: > I realize that, but is that a reason to keep linux from working with > these? (And it's not just cisco, all the *BSDs (and therefore anything > that took the BSD stack such as MS) work this way too.) As nearly as I > can tell, there's no way to make linux work with these, and the > situation I gave is one where linux could easily get it right, and > isn't. Saying "They're broken. Tough." is not really helpful. At > least can we get a "work with broken other systems in certain > circumstances" switch somewhere? I have been asking for a similar thing as well, David mentioned some things that would break, but I believe they break if you use source routing, so that seems not to be a real objection. > > (Funny you should mention Cisco, as we write routing software and must > interoperate with Cisco. What Cisco says *does* go in the routing > community, if you wish your product to be used. Currently, when our > customers come to us, we have to say "Either don't use Linux or run 2.2 > with the arp fix patch.") Unless all your customers do odd things with networking, or you are not using source routing for some reason, you don't do customers a favor by giving that advice. Most users have one NIC with one IP and Linux works. The Linux implementation is not broken by standard, it's just that there were two ways to do it, and the one chosen is allowed by frequently non-functional. I find it interesting that we can't change networking because a few complex systems would have to be reconfigured, but we *can* change modules which requires config changes on probably 90% of all systems (commercial distributions). Linus has rethought some of his design decisions, but David seems intent on not only keeping this one, but preventing the addition of a flag which would solve the problem for most people. -- bill davidsen CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. From davem@redhat.com Wed Aug 20 10:11:06 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 10:11:11 -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 h7KHB3oO026161 for ; Wed, 20 Aug 2003 10:11:06 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id KAA20012; Wed, 20 Aug 2003 10:00:44 -0700 Date: Wed, 20 Aug 2003 10:00:44 -0700 From: "David S. Miller" To: Bill Davidsen Cc: dang@fprintf.net, alan@lxorguk.ukuu.org.uk, richard@aspectgroup.co.uk, skraw@ithnet.com, willy@w.ods.org, carlosev@newipnet.com, lamont@scriptkiddie.org, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030820100044.3127d612.davem@redhat.com> In-Reply-To: References: <1061320363.3744.14.camel@athena.fprintf.net> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5138 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 Content-Length: 1163 Lines: 27 On Wed, 20 Aug 2003 12:49:14 -0400 (EDT) Bill Davidsen wrote: > On 19 Aug 2003, Daniel Gryniewicz wrote: > > I have been asking for a similar thing as well, David mentioned some > things that would break, but I believe they break if you use source > routing, so that seems not to be a real objection. It's not about source routing. It's about failover and being able to use ARP on interfaces which don't have addresses assigned to them yet. > I find it interesting that we can't change networking because a few > complex systems would have to be reconfigured, but we *can* change modules > which requires config changes on probably 90% of all systems (commercial > distributions). Decisions about Networking will always be in a different domain because the way one behaves has effects upon other systems not just the local one. BTW, another thing which makes the source address selection for outgoing ARPs a real touchy area is the following. Some weird configurations actually respond with different ARP answers based upon the source address in the ARP request. You can ask Julian Anastasov about such (arguably pathological) setups. From jiri@gaisler.com Wed Aug 20 10:30:42 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 10:30:47 -0700 (PDT) Received: from mail32.megamailservers.com (mail32.megamailservers.com [216.251.36.32]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KHUeoO027027 for ; Wed, 20 Aug 2003 10:30:42 -0700 Received: from gaisler.com (h33n2fls33o837.telia.com [217.209.138.33]) (authenticated bits=0) by mail32.megamailservers.com (8.12.9/8.12.9) with ESMTP id h7KHUaq3065768; Wed, 20 Aug 2003 13:30:39 -0400 (EDT) X-Authenticated-User: jiri.gaisler.com Message-ID: <3F43B061.3010805@gaisler.com> Date: Wed, 20 Aug 2003 19:31:13 +0200 From: Jiri Gaisler Reply-To: jiri@gaisler.com Organization: Gaisler Research User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete Zaitcev CC: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Clean kernel patch for LEON/SPARC References: <3F43551A.1060901@gaisler.com> <20030820123311.A6511@devserv.devel.redhat.com> In-Reply-To: <20030820123311.A6511@devserv.devel.redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5139 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jiri@gaisler.com Precedence: bulk X-list: netdev Content-Length: 1382 Lines: 45 Pete Zaitcev wrote: > The serial has to go to Russell King, but I can look, too. > Best of all is to cc to linux-kernel. > > About Ethernet, it probably ought to go to netdev@oss.sgi.com. > I am not quite sure. > I have made three patches that makes up the leon/sparc port for linux-2.5.75: * linux-2.5.75_kernel_only.diff - leon support in kernel * linux-2.5.75_open_eth.diff - opencores ethernet driver * linux-2.5.75_leon_uart.diff - leon uart driver The total size is about 150 Kbyte, so to avoid a large email the patches can be downloaded from: http://www.gaisler.com/patches.html I don't have Russell King's email address, maybe you could forward this mail to him? > Did you guys figure out the cause of the severe problem > with cache corruption? Yes, this was a virtual address aliasing problem. Leon2 has virtual caches but the MMU has no aliasing detection, so we are forced to flush the cache on each task switch. Our next processor (leon3) will have to switch to either physical caches or have some form of aliasing detection ... Regards, Jiri. -- ------------------------------------------------------------------------- Gaisler Research, Stora Nygatan 13, 41108 Goteborg, Sweden, +46-31802405 fax: +46-31802407 email: info@gaisler.com, home page: www.gaisler.com ------------------------------------------------------------------------- From greearb@candelatech.com Wed Aug 20 10:44:48 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 10:44:52 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-084.evrtwa1.dsl-verizon.net [4.33.45.84]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KHiloO027722 for ; Wed, 20 Aug 2003 10:44:48 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h7KHiftf014572; Wed, 20 Aug 2003 10:44:41 -0700 Message-ID: <3F43B389.5060602@candelatech.com> Date: Wed, 20 Aug 2003 10:44:41 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: linux-kernel@vger.kernel.org, "'netdev@oss.sgi.com'" Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices References: <1061320363.3744.14.camel@athena.fprintf.net> <20030820100044.3127d612.davem@redhat.com> In-Reply-To: <20030820100044.3127d612.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5140 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 1306 Lines: 36 David S. Miller wrote: > On Wed, 20 Aug 2003 12:49:14 -0400 (EDT) > Bill Davidsen wrote: > > >>On 19 Aug 2003, Daniel Gryniewicz wrote: >> >>I have been asking for a similar thing as well, David mentioned some >>things that would break, but I believe they break if you use source >>routing, so that seems not to be a real objection. > > > It's not about source routing. It's about failover and being > able to use ARP on interfaces which don't have addresses assigned > to them yet. [snip] > BTW, another thing which makes the source address selection for > outgoing ARPs a real touchy area is the following. Some weird > configurations actually respond with different ARP answers based upon > the source address in the ARP request. You can ask Julian Anastasov > about such (arguably pathological) setups. It seems that these reasons would not preclude the addition of a flag that would default to the current behaviour but allow the behaviour that other setups desire easily? That seems to be all that folks are really arguing for. If/when the user enabled this new flag, then they should be fully responsible for the change in behaviour, and they can deal with it as needed. -- Ben Greear Candela Technologies Inc http://www.candelatech.com From bos@serpentine.com Wed Aug 20 10:48:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 10:48:27 -0700 (PDT) Received: from mail.keyresearch.com (64.221.211.208.ptr.us.xo.net [64.221.211.208]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KHmNoO028136 for ; Wed, 20 Aug 2003 10:48:24 -0700 Received: (qmail 15638 invoked from network); 20 Aug 2003 17:48:17 -0000 Received: from serpentine.internal.keyresearch.com (192.168.3.63) by fileserver.internal.keyresearch.com with SMTP; 20 Aug 2003 17:48:17 -0000 Subject: Re: Best way to hook incoming eth pkts? From: "Bryan O'Sullivan" To: Jeff Garzik Cc: netdev@oss.sgi.com In-Reply-To: <20030820154727.GB9119@gtf.org> References: <20030820154727.GB9119@gtf.org> Content-Type: text/plain Message-Id: <1061401697.12293.8.camel@serpentine.internal.keyresearch.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 20 Aug 2003 10:48:17 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 5141 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bos@serpentine.com Precedence: bulk X-list: netdev Content-Length: 558 Lines: 14 On Wed, 2003-08-20 at 08:47, Jeff Garzik wrote: > ATA-over-ethernet has its own > IANA-registered ethernet type, but netconsole and netdump are using > IP/UDP instead of a custom ethernet protocol. This is useful, because it minimises the work needed to get them going over other transports, such as Myrinet. I'd rather not see the UDP encapsulation go away. Netconsole is already messy enough to configure and deal with; Matt Mackall's 2.6 forward port, that makes configuration more IP-oriented instead of less, is a step in the right direction. ; Wed, 20 Aug 2003 10:49:44 -0700 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h7KHnSd14534 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Wed, 20 Aug 2003 13:49:34 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h7KHnS0t006757 for ; Wed, 20 Aug 2003 13:49:28 -0400 To: netdev@oss.sgi.com Subject: Re: Best way to hook incoming eth pkts? In-reply-to: Your message of "Wed, 20 Aug 2003 11:47:27 EDT." <20030820154727.GB9119@gtf.org> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 20 Aug 2003 13:49:28 -0400 Message-ID: <6756.1061401768@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-archive-position: 5142 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcr@sandelman.ottawa.on.ca Precedence: bulk X-list: netdev Content-Length: 2151 Lines: 52 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jeff" == Jeff Garzik writes: Jeff> Essentially, all the things mentioned above need some way to listen Jeff> for incoming ethernet packets. ATA-over-ethernet has its own Jeff> IANA-registered ethernet type, but netconsole and netdump are using Jeff> IP/UDP instead of a custom ethernet protocol. Jeff> So, two questions for the gurus of the crowd ;-) Jeff> 1) What is the best way for an in-kernel piece of software to Jeff> receive ethernet packets that are intended for it? For ethernet protocols, you can just register the protocol handler, and you will get them. Jeff> 2) Possibly related to #1, is it a good or bad idea to consider Jeff> sending netconsole/netdump directly over ethernet, eschewing the Jeff> IP/UDP/syslog stuff? netconsole makes me really nervous, and I'd rather it was not over IP. (If you need a far-away remote console, then get another box with multiple serial ports + SSH, or get an Annex, or...) Another thing which would like UDP packets is the IPsec NAT-T stuff. It is even weirder, because some packets need to be *returned* to the UDP socket. (I didn't design this protocol, and argued against putting the ESP and IKE traffic on the same port, but I lost that argument. I would have prefered to implement Teredo, and then do IPv4-ESP-IPv6-UDP-IPv4 instead, since it would encourage IPv6) ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP0O0p4qHRg3pndX9AQGjoAP/R37iSdbaK2aWqAwPZvY1DQ9JVSGdk+bq RBhtuixa3V2SC/kqacw6eUf4gbEMZZgtA0IP4tP0vYXYv3eIUBeB4wJGTBD7Sezn Tzwc1hJo/Eplbts+kirAM1DJ9Oh8/2HVVWvEQbyGvOqAE2WKzRrQYiCDuyuarH/F ksardhGJKcM= =daOJ -----END PGP SIGNATURE----- From davem@redhat.com Wed Aug 20 10:55:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 10:55: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 h7KHtdoO028958 for ; Wed, 20 Aug 2003 10:55:40 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id KAA20452; Wed, 20 Aug 2003 10:48:32 -0700 Date: Wed, 20 Aug 2003 10:48:31 -0700 From: "David S. Miller" To: Ben Greear Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Message-Id: <20030820104831.6235f3b9.davem@redhat.com> In-Reply-To: <3F43B389.5060602@candelatech.com> References: <1061320363.3744.14.camel@athena.fprintf.net> <20030820100044.3127d612.davem@redhat.com> <3F43B389.5060602@candelatech.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5143 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 Content-Length: 987 Lines: 28 On Wed, 20 Aug 2003 10:44:41 -0700 Ben Greear wrote: > It seems that these reasons would not preclude the addition of a flag > that would default to the current behaviour but allow the behaviour that > other setups desire easily? I would accept a patch that did something like the following in arp_solicit(). if (skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL && (in_dev->conf.shared_media || inet_addr_onlink(dev, skb->nh.iph->saddr, 0))) saddr = skb->nh.iph->saddr; else saddr = inet_select_addr(dev, target, RT_SCOPE_LINE); Then people can frob the shared_media sysctl for devices where they want the behavior to be that we will only use addresses assigned to the device as the solicitor address. The shared_media setting defaults to one and thus would preserve current behavior by default. The idea is not mine, Alexey suggested it to me the other day. I hope this pleases people wrt. ARP request solicitor address handling. From garzik@gtf.org Wed Aug 20 10:59:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 10:59:38 -0700 (PDT) Received: from havoc.gtf.org (havoc.gtf.org [63.247.75.124]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KHxZoO029378 for ; Wed, 20 Aug 2003 10:59:35 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id B3BF36645; Wed, 20 Aug 2003 13:59:29 -0400 (EDT) Date: Wed, 20 Aug 2003 13:59:29 -0400 From: Jeff Garzik To: Michael Richardson Cc: netdev@oss.sgi.com Subject: Re: Best way to hook incoming eth pkts? Message-ID: <20030820175929.GD23984@gtf.org> References: <20030820154727.GB9119@gtf.org> <6756.1061401768@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6756.1061401768@marajade.sandelman.ottawa.on.ca> User-Agent: Mutt/1.3.28i X-archive-position: 5144 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 Content-Length: 394 Lines: 15 On Wed, Aug 20, 2003 at 01:49:28PM -0400, Michael Richardson wrote: > For ethernet protocols, you can just register the protocol handler, and you > will get them. Dumb question: how? example code, or relevant functions to grep for? grepping for 'register.*prot' didn't seem to turn up anything useful, and I didn't see any register*ether functions in linux/if_ether.h. Thanks, Jeff From davem@redhat.com Wed Aug 20 11:01:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 11:01:53 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KI1noO029789 for ; Wed, 20 Aug 2003 11:01:50 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id KAA20502; Wed, 20 Aug 2003 10:54:38 -0700 Date: Wed, 20 Aug 2003 10:54:37 -0700 From: "David S. Miller" To: Jeff Garzik Cc: mcr@sandelman.ottawa.on.ca, netdev@oss.sgi.com Subject: Re: Best way to hook incoming eth pkts? Message-Id: <20030820105437.73dc86db.davem@redhat.com> In-Reply-To: <20030820175929.GD23984@gtf.org> References: <20030820154727.GB9119@gtf.org> <6756.1061401768@marajade.sandelman.ottawa.on.ca> <20030820175929.GD23984@gtf.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5145 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 Content-Length: 372 Lines: 10 On Wed, 20 Aug 2003 13:59:29 -0400 Jeff Garzik wrote: > On Wed, Aug 20, 2003 at 01:49:28PM -0400, Michael Richardson wrote: > > For ethernet protocols, you can just register the protocol handler, and you > > will get them. > > Dumb question: how? example code, or relevant functions to grep for? He's talking about net/core/dev.c:dev_add_pack() From davem@redhat.com Wed Aug 20 11:25:10 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 11:25: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 h7KIP5oO030847 for ; Wed, 20 Aug 2003 11:25:09 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id LAA20765; Wed, 20 Aug 2003 11:17:16 -0700 Date: Wed, 20 Aug 2003 11:17:16 -0700 From: "David S. Miller" To: Jeff Garzik Cc: mcr@sandelman.ottawa.on.ca, netdev@oss.sgi.com Subject: Re: Best way to hook incoming eth pkts? Message-Id: <20030820111716.1329256b.davem@redhat.com> In-Reply-To: <20030820181512.GE23984@gtf.org> References: <20030820154727.GB9119@gtf.org> <6756.1061401768@marajade.sandelman.ottawa.on.ca> <20030820175929.GD23984@gtf.org> <20030820105437.73dc86db.davem@redhat.com> <20030820181512.GE23984@gtf.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5146 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 Content-Length: 385 Lines: 10 On Wed, 20 Aug 2003 14:15:12 -0400 Jeff Garzik wrote: > Tangent, from reading dev.c: Is it ok that dev_queue_xmit_nit does not > check the return value of struct packet_type's ->func hook? It seems to > do so in all other cases... The return value isn't really used currently. It provides congestion heuristics that maybe eventually will be taken advantage of. From davem@redhat.com Wed Aug 20 11:28:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 11:28:50 -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 h7KISkoO031237 for ; Wed, 20 Aug 2003 11:28:46 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id LAA20837; Wed, 20 Aug 2003 11:20:35 -0700 Date: Wed, 20 Aug 2003 11:20:34 -0700 From: "David S. Miller" To: Ville Nuorvala Cc: usagi-core@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [PATCH] IPv6: Fix target address for (proxy/anycast) NA Message-Id: <20030820112034.1f0158b1.davem@redhat.com> In-Reply-To: References: <20030819083621.2ae4abc8.davem@redhat.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5147 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 Content-Length: 250 Lines: 7 On Wed, 20 Aug 2003 14:23:12 +0300 (EEST) Ville Nuorvala wrote: > the target address in neighbor advertisements must be the solicited > address. Otherwise proxy NAs (and NAs for anycast addresses) don't work. Applied, thanks. From davem@redhat.com Wed Aug 20 11:32:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 11:32:28 -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 h7KIWOoO031688 for ; Wed, 20 Aug 2003 11:32:24 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id LAA20886; Wed, 20 Aug 2003 11:24:14 -0700 Date: Wed, 20 Aug 2003 11:24:14 -0700 From: "David S. Miller" To: Ville Nuorvala Cc: usagi-core@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [PATCH] IPv6: Protect proxied addresses against DAD Message-Id: <20030820112414.6fcb4ee5.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5148 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 Content-Length: 238 Lines: 7 On Wed, 20 Aug 2003 14:40:14 +0300 (EEST) Ville Nuorvala wrote: > a proxy has to reply to DAD probes, otherwise it can't protect its > addresses. The attached patch fixes this, please apply! Patch applied, thanks. From garzik@gtf.org Wed Aug 20 11:32:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 11:32:30 -0700 (PDT) Received: from havoc.gtf.org (havoc.gtf.org [63.247.75.124]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KIWFoO031680 for ; Wed, 20 Aug 2003 11:32:16 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id 4FA1D663B; Wed, 20 Aug 2003 13:51:41 -0400 (EDT) Date: Wed, 20 Aug 2003 13:51:41 -0400 From: Jeff Garzik To: "Bryan O'Sullivan" Cc: netdev@oss.sgi.com Subject: Re: Best way to hook incoming eth pkts? Message-ID: <20030820175141.GB23984@gtf.org> References: <20030820154727.GB9119@gtf.org> <1061401697.12293.8.camel@serpentine.internal.keyresearch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1061401697.12293.8.camel@serpentine.internal.keyresearch.com> User-Agent: Mutt/1.3.28i X-archive-position: 5149 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 Content-Length: 796 Lines: 22 On Wed, Aug 20, 2003 at 10:48:17AM -0700, Bryan O'Sullivan wrote: > On Wed, 2003-08-20 at 08:47, Jeff Garzik wrote: > > > ATA-over-ethernet has its own > > IANA-registered ethernet type, but netconsole and netdump are using > > IP/UDP instead of a custom ethernet protocol. > > This is useful, because it minimises the work needed to get them going > over other transports, such as Myrinet. I'd rather not see the UDP > encapsulation go away. Netconsole is already messy enough to configure > and deal with; Matt Mackall's 2.6 forward port, that makes configuration > more IP-oriented instead of less, is a step in the right direction. Configuration has zero to do with the protocol of choice. I fully agree that current RH netconsole/netdump configuration is positively awful... Jeff From davem@redhat.com Wed Aug 20 11:38:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 11:38:58 -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 h7KIchoO032543 for ; Wed, 20 Aug 2003 11:38:49 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id LAA20942; Wed, 20 Aug 2003 11:31:32 -0700 Date: Wed, 20 Aug 2003 11:31:32 -0700 From: "David S. Miller" To: Eran Mann Cc: netdev@oss.sgi.com Subject: Re: [patch 2.4] kernel oops on VLAN removal Message-Id: <20030820113132.30d067a6.davem@redhat.com> In-Reply-To: <3F436EE7.1030104@mrv.com> References: <3F424405.6020002@mrv.com> <20030819124154.75ec0383.davem@redhat.com> <3F436EE7.1030104@mrv.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5150 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 Content-Length: 411 Lines: 12 On Wed, 20 Aug 2003 15:51:51 +0300 Eran Mann wrote: > David S. Miller wrote: > > Can someone check out 2.6.x? > > > It looks the same in 2.6.0-test3. The patch applies (with small offsets) > and works (the oops is much harder to trigger in 2.6.x since > PROC_NDYNAMIC is increased to 16384, I had to reduce it to 4096 to > trigger the oops). Thanks, I've put the patch into my 2.6.x tree. From garzik@gtf.org Wed Aug 20 11:49:07 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 11:49:10 -0700 (PDT) Received: from havoc.gtf.org (havoc.gtf.org [63.247.75.124]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KImtoO000755 for ; Wed, 20 Aug 2003 11:48:56 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id BA1D86647; Wed, 20 Aug 2003 14:15:12 -0400 (EDT) Date: Wed, 20 Aug 2003 14:15:12 -0400 From: Jeff Garzik To: "David S. Miller" Cc: mcr@sandelman.ottawa.on.ca, netdev@oss.sgi.com Subject: Re: Best way to hook incoming eth pkts? Message-ID: <20030820181512.GE23984@gtf.org> References: <20030820154727.GB9119@gtf.org> <6756.1061401768@marajade.sandelman.ottawa.on.ca> <20030820175929.GD23984@gtf.org> <20030820105437.73dc86db.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030820105437.73dc86db.davem@redhat.com> User-Agent: Mutt/1.3.28i X-archive-position: 5151 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 Content-Length: 654 Lines: 21 On Wed, Aug 20, 2003 at 10:54:37AM -0700, David S. Miller wrote: > On Wed, 20 Aug 2003 13:59:29 -0400 > Jeff Garzik wrote: > > > On Wed, Aug 20, 2003 at 01:49:28PM -0400, Michael Richardson wrote: > > > For ethernet protocols, you can just register the protocol handler, and you > > > will get them. > > > > Dumb question: how? example code, or relevant functions to grep for? > > He's talking about net/core/dev.c:dev_add_pack() Thanks much. Tangent, from reading dev.c: Is it ok that dev_queue_xmit_nit does not check the return value of struct packet_type's ->func hook? It seems to do so in all other cases... Jeff From shmulik.hen@intel.com Wed Aug 20 11:55:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 11:55:48 -0700 (PDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KItioO001295 for ; Wed, 20 Aug 2003 11:55:45 -0700 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h7KInRr09791 for ; Wed, 20 Aug 2003 18:49:27 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h7KDtd527421 for ; Wed, 20 Aug 2003 13:55:40 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.254.188]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003082007333326343 ; Wed, 20 Aug 2003 07:33:34 -0700 Content-Type: text/plain; charset="us-ascii" From: Shmulik Hen Reply-To: shmulik.hen@intel.com Organization: Intel corp. Subject: [patch][bonding] fix kernel panic when removing the primary slave Date: Wed, 20 Aug 2003 17:33:31 +0300 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit To: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Message-Id: <200308201733.31144.shmulik.hen@intel.com> X-archive-position: 5152 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Content-Length: 1356 Lines: 44 When releasing the primary slave, there is a kernel panic because the bond->primary_slave is not set to NULL until after calling change_active_interface(), even though the slave was already detached from the slave list. Patch is against 2.4.22-rc2. -- | Shmulik Hen Advanced Network Services | | Israel Design Center, Jerusalem | | LAN Access Division, Platform Networking | | Intel Communications Group, Intel corp. | diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c 2003-08-20 17:17:57.000000000 +0300 +++ b/drivers/net/bonding/bond_main.c 2003-08-20 17:19:11.000000000 +0300 @@ -1976,6 +1976,10 @@ static int bond_release(struct net_devic /* release the slave from its bond */ bond_detach_slave(bond, our_slave); + if (bond->primary_slave == our_slave) { + bond->primary_slave = NULL; + } + printk (KERN_INFO "%s: releasing %s interface %s", master->name, (our_slave->state == BOND_STATE_ACTIVE) ? "active" : "backup", @@ -1994,10 +1998,6 @@ static int bond_release(struct net_devic master->name); } - if (bond->primary_slave == our_slave) { - bond->primary_slave = NULL; - } - if ((bond_mode == BOND_MODE_TLB) || (bond_mode == BOND_MODE_ALB)) { /* must be called only after the slave has been From pe1rxq@amsat.org Wed Aug 20 12:16:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 12:16:20 -0700 (PDT) Received: from amsfep12-int.chello.nl (amsfep12-int.chello.nl [213.46.243.18] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KJGCoO002939 for ; Wed, 20 Aug 2003 12:16:13 -0700 Received: from mail.chello.nl ([212.83.83.7]) by amsfep12-int.chello.nl (InterMail vM.5.01.05.17 201-253-122-126-117-20021021) with SMTP id <20030820184303.GSSJ26845.amsfep12-int.chello.nl@mail.chello.nl>; Wed, 20 Aug 2003 20:43:03 +0200 Date: Wed, 20 Aug 2003 20:45:18 +0200 From: Jeroen Vreeken To: "David S . Miller" Cc: shemminger@osdl.org, linux-hams@vger.kernel.org, ralf@linux-mips.org, netdev@oss.sgi.com Subject: [PATCH] ax25 changes Message-ID: <20030820204518.C5568@jeroen.pe1rxq.ampr.org> References: <20030812194653.A28977@jeroen.pe1rxq.ampr.org> <20030812135655.7334887b.shemminger@osdl.org> <20030812230951.E28977@jeroen.pe1rxq.ampr.org> <20030812153901.6e700dcb.shemminger@osdl.org> <20030813010301.K28977@jeroen.pe1rxq.ampr.org> <20030812172151.7de0c950.shemminger@osdl.org> <20030813031159.6c6c9629.davem@redhat.com> <20030813173446.A2604@jeroen.pe1rxq.ampr.org> <20030813084252.7b667fb8.davem@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="AWniW0JNca5xppdA" Content-Transfer-Encoding: 8bit In-Reply-To: <20030813084252.7b667fb8.davem@redhat.com>; from davem@redhat.com on Wed, Aug 13, 2003 at 17:42:52 +0200 X-Mailer: Balsa 1.1.0 X-archive-position: 5153 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pe1rxq@amsat.org Precedence: bulk X-list: netdev Content-Length: 34084 Lines: 564 --AWniW0JNca5xppdA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit On 2003.08.13 17:42:52 +0200 David S. Miller wrote: > On Wed, 13 Aug 2003 17:34:46 +0200 > Jeroen Vreeken wrote: > > > This is my last patch (rxq4) plus Stephen's last three (dev locking, > > setsockopt, seq_file) > > Please don't combine the patches, I want the each individual > patch with the author and his comments for that change. > > If you combine all the work, this information gets lost. After posting this mega patch I have been away for some days.... Fortunatly Stephen already reduced the amount of work by doing the netrom stuff. The next four patches are the remaining ax25 (and a litle netrom) patches: ax25_cb-lock.diff This is the biggest one: - ax25_cb's use refcounting - the ax25_cb list uses hlists - Lots of socket locking. This patch touches almost everything in the ax25 directory. hard_header.diff Makes ax25_subr.c use the devices hard_header_len instead of some predicted worst case. (also contains a small socket locking patch) iface-lists.diff Fixes the list usage and list locking in ax25_iface.c netrom-refcnt.diff Small changes to netrom as a result of the ax25_cb refcounting. Jeroen --AWniW0JNca5xppdA Content-Type: application/octet-stream; charset=us-ascii Content-Disposition: attachment; filename="netrom-refcnt.diff" --- linux-2.6.0-test3.bk/net/netrom/nr_route.c 2003-08-20 19:17:18.000000000 +0200 +++ linux-2.6.0-test3.bk.rxq/net/netrom/nr_route.c 2003-08-20 19:34:51.000000000 +0200 @@ -735,7 +735,7 @@ if (nr_neigh == NULL) return; nr_neigh->ax25 = NULL; - // ax25_cb_put(ax25); + ax25_cb_put(ax25); if (++nr_neigh->failed < sysctl_netrom_link_fails_count) { nr_neigh_put(nr_neigh); @@ -829,7 +829,7 @@ ax25s = ax25_send_frame(skb, 256, (ax25_address *)dev->dev_addr, &nr_neigh->callsign, nr_neigh->digipeat, nr_neigh->dev); if (nr_neigh->ax25 && ax25s) { /* We were already holding this ax25_cb */ - // ax25_cb_put(ax25s); + ax25_cb_put(ax25s); } nr_neigh->ax25 = ax25s; --AWniW0JNca5xppdA Content-Type: application/octet-stream; charset=ISO-8859-1 Content-Disposition: attachment; filename="ax25_cb-lock.diff" Content-Transfer-Encoding: quoted-printable diff -ruN linux-2.6.0-test3.bk/net/ax25/af_ax25.c linux-2.6.0-test3.bk.rxq/= net/ax25/af_ax25.c=0A--- linux-2.6.0-test3.bk/net/ax25/af_ax25.c 2003-08-20= 19:00:29.000000000 +0200=0A+++ linux-2.6.0-test3.bk.rxq/net/ax25/af_ax25.c= 2003-08-20 19:58:29.000000000 +0200=0A@@ -51,54 +51,27 @@=0A =0A =0A =0A-a= x25_cb *ax25_list;=0A+HLIST_HEAD(ax25_list);=0A spinlock_t ax25_list_lock = =3D SPIN_LOCK_UNLOCKED;=0A =0A static struct proto_ops ax25_proto_ops;=0A = =0A-/*=0A- * Free an allocated ax25 control block. This is done to centrali= se=0A- * the MOD count code.=0A- */=0A-void ax25_free_cb(ax25_cb *ax25)=0A-= {=0A- if (ax25->digipeat !=3D NULL) {=0A- kfree(ax25->digipeat);=0A- ax25= ->digipeat =3D NULL;=0A- }=0A-=0A- kfree(ax25);=0A-}=0A-=0A static void ax2= 5_free_sock(struct sock *sk)=0A {=0A- ax25_free_cb(ax25_sk(sk));=0A+ ax25_c= b_put(ax25_sk(sk));=0A }=0A =0A /*=0A * Socket removal during an interrupt= is now safe.=0A */=0A-static void ax25_remove_socket(ax25_cb *ax25)=0A+st= atic void ax25_cb_del(ax25_cb *ax25)=0A {=0A- ax25_cb *s;=0A-=0A- spin_lock= _bh(&ax25_list_lock);=0A- if ((s =3D ax25_list) =3D=3D ax25) {=0A- ax25_li= st =3D s->next;=0A+ if (!hlist_unhashed(&ax25->ax25_node)) {=0A+ spin_lock= _bh(&ax25_list_lock);=0A+ hlist_del_init(&ax25->ax25_node);=0A spin_unlo= ck_bh(&ax25_list_lock);=0A- return;=0A- }=0A-=0A- while (s !=3D NULL && s-= >next !=3D NULL) {=0A- if (s->next =3D=3D ax25) {=0A- s->next =3D ax25->= next;=0A- spin_unlock_bh(&ax25_list_lock);=0A- return;=0A- }=0A-=0A- = s =3D s->next;=0A+ ax25_cb_put(ax25);=0A }=0A- spin_unlock_bh(&ax25_list_= lock);=0A }=0A =0A /*=0A@@ -108,12 +81,13 @@=0A {=0A ax25_dev *ax25_dev;= =0A ax25_cb *s;=0A+ struct hlist_node *node;=0A =0A if ((ax25_dev =3D ax2= 5_dev_ax25dev(dev)) =3D=3D NULL)=0A return;=0A =0A spin_lock_bh(&ax25_li= st_lock);=0A- for (s =3D ax25_list; s !=3D NULL; s =3D s->next) {=0A+ ax25_= for_each(s, node, &ax25_list) {=0A if (s->ax25_dev =3D=3D ax25_dev) {=0A = s->ax25_dev =3D NULL;=0A ax25_disconnect(s, ENETUNREACH);=0A@@ -153,1= 1 +127,11 @@=0A /*=0A * Add a socket to the bound sockets list.=0A */=0A-= void ax25_insert_socket(ax25_cb *ax25)=0A+void ax25_cb_add(ax25_cb *ax25)= =0A {=0A spin_lock_bh(&ax25_list_lock);=0A- ax25->next =3D ax25_list;=0A- = ax25_list =3D ax25;=0A+ ax25_cb_hold(ax25);=0A+ hlist_add_head(&ax25->ax25= _node, &ax25_list);=0A spin_unlock_bh(&ax25_list_lock);=0A }=0A =0A@@ -169= ,17 +143,18 @@=0A struct net_device *dev, int type)=0A {=0A ax25_cb *s;= =0A+ struct hlist_node *node;=0A =0A spin_lock_bh(&ax25_list_lock);=0A- fo= r (s =3D ax25_list; s !=3D NULL; s =3D s->next) {=0A+ ax25_for_each(s, node= , &ax25_list) {=0A if ((s->iamdigi && !digi) || (!s->iamdigi && digi))=0A= continue;=0A if (s->sk && !ax25cmp(&s->source_addr, addr) &&=0A = s->sk->sk_type =3D=3D type && s->sk->sk_state =3D=3D TCP_LISTEN) {=0A /= * If device is null we match any device */=0A if (s->ax25_dev =3D=3D NUL= L || s->ax25_dev->dev =3D=3D dev) {=0A+ sock_hold(s->sk);=0A spin_un= lock_bh(&ax25_list_lock);=0A-=0A return s->sk;=0A }=0A }=0A@@ -197= ,9 +172,10 @@=0A {=0A struct sock *sk =3D NULL;=0A ax25_cb *s;=0A+ struct= hlist_node *node;=0A =0A spin_lock_bh(&ax25_list_lock);=0A- for (s =3D ax= 25_list; s !=3D NULL; s =3D s->next) {=0A+ ax25_for_each(s, node, &ax25_lis= t) {=0A if (s->sk && !ax25cmp(&s->source_addr, my_addr) &&=0A !ax25= cmp(&s->dest_addr, dest_addr) &&=0A s->sk->sk_type =3D=3D type) {=0A@= @ -223,9 +199,10 @@=0A ax25_digi *digi, struct net_device *dev)=0A {=0A a= x25_cb *s;=0A+ struct hlist_node *node;=0A =0A spin_lock_bh(&ax25_list_loc= k);=0A- for (s =3D ax25_list; s !=3D NULL; s =3D s->next) {=0A+ ax25_for_ea= ch(s, node, &ax25_list) {=0A if (s->sk && s->sk->sk_type !=3D SOCK_SEQPAC= KET)=0A continue;=0A if (s->ax25_dev =3D=3D NULL)=0A@@ -240,6 +217,7 @= @=0A if (s->digipeat !=3D NULL && s->digipeat->ndigi !=3D 0)=0A co= ntinue;=0A }=0A+ ax25_cb_hold(s);=0A spin_unlock_bh(&ax25_list_lock= );=0A =0A return s;=0A@@ -257,9 +235,10 @@=0A {=0A struct sock *sk =3D = NULL;=0A ax25_cb *s;=0A+ struct hlist_node *node;=0A =0A spin_lock_bh(&ax= 25_list_lock);=0A- for (s =3D ax25_list; s !=3D NULL; s =3D s->next) {=0A+ = ax25_for_each(s, node, &ax25_list) {=0A if (s->sk !=3D NULL && ax25cmp(&s= ->source_addr, addr) =3D=3D 0 &&=0A s->sk->sk_type =3D=3D SOCK_RAW) {= =0A sk =3D s->sk;=0A@@ -267,6 +246,7 @@=0A break;=0A }=0A }=0A+=0A= spin_unlock_bh(&ax25_list_lock);=0A =0A return sk;=0A@@ -299,7 +279,16 @= @=0A */=0A static void ax25_destroy_timer(unsigned long data)=0A {=0A- ax2= 5_destroy_socket((ax25_cb *)data);=0A+ ax25_cb *ax25=3D(ax25_cb *)data;=0A+= struct sock *sk;=0A+ =0A+ sk=3Dax25->sk;=0A+ =0A+ bh_lock_sock(sk);=0A+ so= ck_hold(sk);=0A+ ax25_destroy_socket(ax25);=0A+ bh_unlock_sock(sk);=0A+ soc= k_put(sk);=0A }=0A =0A /*=0A@@ -312,7 +301,7 @@=0A {=0A struct sk_buff *sk= b;=0A =0A- ax25_remove_socket(ax25);=0A+ ax25_cb_del(ax25);=0A =0A ax25_st= op_heartbeat(ax25);=0A ax25_stop_t1timer(ax25);=0A@@ -337,22 +326,27 @@=0A= =0A kfree_skb(skb);=0A }=0A+ while ((skb =3D skb_dequeue(&ax25->sk->= sk_write_queue)) !=3D NULL) {=0A+ kfree_skb(skb);=0A+ }=0A }=0A =0A if= (ax25->sk !=3D NULL) {=0A if (atomic_read(&ax25->sk->sk_wmem_alloc) ||= =0A atomic_read(&ax25->sk->sk_rmem_alloc)) {=0A /* Defer: outstand= ing buffers */=0A- init_timer(&ax25->timer);=0A- ax25->timer.expires = =3D jiffies + 10 * HZ;=0A- ax25->timer.function =3D ax25_destroy_timer;= =0A- ax25->timer.data =3D (unsigned long)ax25;=0A- add_timer(&ax25-= >timer);=0A+ init_timer(&ax25->dtimer);=0A+ ax25->dtimer.expires =3D j= iffies + 2 * HZ;=0A+ ax25->dtimer.function =3D ax25_destroy_timer;=0A+ = ax25->dtimer.data =3D (unsigned long)ax25;=0A+ add_timer(&ax25->dtime= r);=0A } else {=0A- sock_put(ax25->sk);=0A+ struct sock *sk=3Dax25->s= k;=0A+ ax25->sk=3DNULL;=0A+ sock_put(sk);=0A }=0A } else {=0A- ax25= _free_cb(ax25);=0A+ ax25_cb_put(ax25);=0A }=0A }=0A =0A@@ -421,7 +415,7 @= @=0A =0A case AX25_N2:=0A if (ax25_ctl.arg < 1 || ax25_ctl.arg > 31)= =0A- return -EINVAL;=0A+ return -EINVAL;=0A ax25->n2count =3D 0;= =0A ax25->n2 =3D ax25_ctl.arg;=0A break;=0A@@ -448,7 +442,7 @@=0A = return -EINVAL;=0A }=0A =0A- return 0;=0A+ return 0;=0A }=0A =0A /*= =0A@@ -507,6 +501,7 @@=0A return NULL;=0A =0A memset(ax25, 0x00, sizeof(= *ax25));=0A+ atomic_set(&ax25->refcount, 1);=0A =0A skb_queue_head_init(&a= x25->write_queue);=0A skb_queue_head_init(&ax25->frag_queue);=0A@@ -655,6 = +650,7 @@=0A (sock->state !=3D SS_UNCONNECTED ||=0A sk->sk_state= =3D=3D TCP_LISTEN)) {=0A res =3D -EADDRNOTAVAIL;=0A+ dev_put(dev);=0A= break;=0A }=0A =0A@@ -877,7 +873,7 @@=0A break;=0A default:=0A s= k_free(sk);=0A- ax25_free_cb(ax25);=0A+ ax25_cb_put(ax25);=0A return NU= LL;=0A }=0A =0A@@ -937,6 +933,7 @@=0A if (sk =3D=3D NULL)=0A return 0;= =0A =0A+ sock_hold(sk);=0A lock_sock(sk);=0A ax25 =3D ax25_sk(sk);=0A =0A= @@ -944,13 +941,15 @@=0A switch (ax25->state) {=0A case AX25_STATE_0:= =0A ax25_disconnect(ax25, 0);=0A- goto drop;=0A+ ax25_destroy_socket= (ax25);=0A+ break;=0A =0A case AX25_STATE_1:=0A case AX25_STATE_2:=0A= ax25_send_control(ax25, AX25_DISC, AX25_POLLON, AX25_COMMAND);=0A ax= 25_disconnect(ax25, 0);=0A- goto drop;=0A+ ax25_destroy_socket(ax25);= =0A+ break;=0A =0A case AX25_STATE_3:=0A case AX25_STATE_4:=0A@@ -993= ,16 +992,14 @@=0A sk->sk_shutdown |=3D SEND_SHUTDOWN;=0A sk->sk_state_c= hange(sk);=0A sock_set_flag(sk, SOCK_DEAD);=0A- goto drop;=0A+ ax25_des= troy_socket(ax25);=0A }=0A =0A sock->sk =3D NULL;=0A sk->sk_socket =3D= NULL; /* Not used, but we should do this */=0A release_sock(sk);=0A- retu= rn 0;=0A- drop:=0A- release_sock(sk);=0A- ax25_destroy_socket(ax25);=0A+ so= ck_put(sk);=0A+=0A return 0;=0A }=0A =0A@@ -1077,7 +1074,7 @@=0A ax25_fi= llin_cb(ax25, ax25_dev);=0A =0A done:=0A- ax25_insert_socket(ax25);=0A+ ax2= 5_cb_add(ax25);=0A sk->sk_zapped =3D 0;=0A =0A out:=0A@@ -1093,7 +1090,7 @= @=0A int addr_len, int flags)=0A {=0A struct sock *sk =3D sock->sk;=0A- a= x25_cb *ax25 =3D ax25_sk(sk);=0A+ ax25_cb *ax25 =3D ax25_sk(sk), *ax25t;=0A= struct full_sockaddr_ax25 *fsa =3D (struct full_sockaddr_ax25 *)uaddr;=0A= ax25_digi *digi =3D NULL;=0A int ct =3D 0, err =3D 0;=0A@@ -1199,7 +1196= ,7 @@=0A goto out;=0A =0A ax25_fillin_cb(ax25, ax25->ax25_dev);=0A- a= x25_insert_socket(ax25);=0A+ ax25_cb_add(ax25);=0A } else {=0A if (ax25= ->ax25_dev =3D=3D NULL) {=0A err =3D -EHOSTUNREACH;=0A@@ -1208,11 +1205,= 12 @@=0A }=0A =0A if (sk->sk_type =3D=3D SOCK_SEQPACKET &&=0A- ax25_f= ind_cb(&ax25->source_addr, &fsa->fsa_ax25.sax25_call, digi,=0A- ax25= ->ax25_dev->dev)) {=0A+ (ax25t=3Dax25_find_cb(&ax25->source_addr, &fsa-= >fsa_ax25.sax25_call, digi,=0A+ ax25->ax25_dev->dev))) {=0A if (di= gi !=3D NULL)=0A kfree(digi);=0A err =3D -EADDRINUSE; /* Already such= a connection */=0A+ ax25_cb_put(ax25t);=0A goto out;=0A }=0A =0A@@ -12= 73,6 +1271,8 @@=0A lock_sock(sk);=0A continue;=0A }=0A+ curren= t->state =3D TASK_RUNNING;=0A+ remove_wait_queue(sk->sk_sleep, &wait);=0A= return -ERESTARTSYS;=0A }=0A current->state =3D TASK_RUNNING;=0A@@ = -1288,10 +1288,11 @@=0A =0A sock->state =3D SS_CONNECTED;=0A =0A+ err=3D0;= =0A out:=0A release_sock(sk);=0A =0A- return 0;=0A+ return err;=0A }=0A = =0A =0A@@ -1331,15 +1332,18 @@=0A if (skb)=0A break;=0A =0A- current-= >state =3D TASK_INTERRUPTIBLE;=0A release_sock(sk);=0A+ current->state = =3D TASK_INTERRUPTIBLE;=0A if (flags & O_NONBLOCK)=0A return -EWOULDBL= OCK;=0A if (!signal_pending(tsk)) {=0A schedule();=0A+ current->stat= e =3D TASK_RUNNING;=0A lock_sock(sk);=0A continue;=0A }=0A+ curren= t->state =3D TASK_RUNNING;=0A+ remove_wait_queue(sk->sk_sleep, &wait);=0A = return -ERESTARTSYS;=0A }=0A current->state =3D TASK_RUNNING;=0A@@ -151= 9,7 +1523,7 @@=0A SOCK_DEBUG(sk, "AX.25: sendto: building packet.\n");=0A = =0A /* Assume the worst case */=0A- size =3D len + 3 + ax25_addr_size(dp) = + AX25_BPQ_HEADER_LEN;=0A+ size =3D len + ax25->ax25_dev->dev->hard_header_= len;=0A =0A skb =3D sock_alloc_send_skb(sk, size, msg->msg_flags&MSG_DONTW= AIT, &err);=0A if (skb =3D=3D NULL)=0A@@ -1780,7 +1784,7 @@=0A =0A /* ol= d structure? */=0A if (cmd =3D=3D SIOCAX25GETINFOOLD) {=0A- static int = warned;=0A+ static int warned =3D 0;=0A if (!warned) {=0A printk(K= ERN_INFO "%s uses old SIOCAX25GETINFO\n",=0A current->comm);=0A@@ -184= 5,6 +1849,7 @@=0A int len =3D 0;=0A off_t pos =3D 0;=0A off_t begin =3D = 0;=0A+ struct hlist_node *node;=0A =0A spin_lock_bh(&ax25_list_lock);=0A = =0A@@ -1853,7 +1858,7 @@=0A * magic dev src_addr dest_addr,digi1,digi2,..= st vs vr va t1 t1 t2 t2 t3 t3 idle idle n2 n2 rtt window paclen Snd-Q Rcv-= Q inode=0A */=0A =0A- for (ax25 =3D ax25_list; ax25 !=3D NULL; ax25 =3D a= x25->next) {=0A+ ax25_for_each(ax25, node, &ax25_list) {=0A len +=3D spri= ntf(buffer+len, "%8.8lx %s %s%s ",=0A (long) ax25,=0A ax25->ax25_de= v =3D=3D NULL? "???" : ax25->ax25_dev->dev->name,=0A@@ -1882,10 +1887,12 @@= =0A ax25->paclen);=0A =0A if (ax25->sk !=3D NULL) {=0A+ bh_lock_sock= (ax25->sk);=0A len +=3D sprintf(buffer + len, " %d %d %ld\n",=0A ato= mic_read(&ax25->sk->sk_wmem_alloc),=0A atomic_read(&ax25->sk->sk_rmem_a= lloc),=0A ax25->sk->sk_socket !=3D NULL ? SOCK_INODE(ax25->sk->sk_socke= t)->i_ino : 0L);=0A+ bh_unlock_sock(ax25->sk);=0A } else {=0A len += =3D sprintf(buffer + len, " * * *\n");=0A }=0Adiff -ruN linux-2.6.0-test3= .bk/net/ax25/ax25_ds_in.c linux-2.6.0-test3.bk.rxq/net/ax25/ax25_ds_in.c=0A= --- linux-2.6.0-test3.bk/net/ax25/ax25_ds_in.c 2003-08-20 19:00:30.00000000= 0 +0200=0A+++ linux-2.6.0-test3.bk.rxq/net/ax25/ax25_ds_in.c 2003-08-20 19:= 58:29.000000000 +0200=0A@@ -65,6 +65,7 @@=0A ax25->state =3D AX25_STATE= _3;=0A ax25->n2count =3D 0;=0A if (ax25->sk !=3D NULL) {=0A+ bh_lock_= sock(ax25->sk);=0A ax25->sk->sk_state =3D TCP_ESTABLISHED;=0A /*=0A = * For WAIT_SABM connections we will produce an accept=0A@@ -72,6 +73,7 @= @=0A */=0A if (!sock_flag(ax25->sk, SOCK_DEAD))=0A ax25->sk->sk_= state_change(ax25->sk);=0A+ bh_unlock_sock(ax25->sk);=0A }=0A ax25_da= ma_on(ax25);=0A =0Adiff -ruN linux-2.6.0-test3.bk/net/ax25/ax25_ds_subr.c l= inux-2.6.0-test3.bk.rxq/net/ax25/ax25_ds_subr.c=0A--- linux-2.6.0-test3.bk/= net/ax25/ax25_ds_subr.c 2003-08-20 19:00:30.000000000 +0200=0A+++ linux-2.6= .0-test3.bk.rxq/net/ax25/ax25_ds_subr.c 2003-08-20 19:58:29.000000000 +0200= =0A@@ -40,6 +40,7 @@=0A void ax25_ds_enquiry_response(ax25_cb *ax25)=0A {= =0A ax25_cb *ax25o;=0A+ struct hlist_node *node;=0A =0A /* Please note th= at neither DK4EG=B4s nor DG2FEF=B4s=0A * DAMA spec mention the following = behaviour as seen=0A@@ -80,7 +81,7 @@=0A ax25_ds_set_timer(ax25->ax25_dev)= ;=0A =0A spin_lock_bh(&ax25_list_lock);=0A- for (ax25o =3D ax25_list; ax25= o !=3D NULL; ax25o =3D ax25o->next) {=0A+ ax25_for_each(ax25o, node, &ax25_= list) {=0A if (ax25o =3D=3D ax25)=0A continue;=0A =0A@@ -160,9 +161,10= @@=0A {=0A ax25_cb *ax25;=0A int res =3D 0;=0A+ struct hlist_node *node;= =0A =0A spin_lock_bh(&ax25_list_lock);=0A- for (ax25 =3D ax25_list; ax25 != =3D NULL ; ax25 =3D ax25->next)=0A+ ax25_for_each(ax25, node, &ax25_list)= =0A if (ax25->ax25_dev =3D=3D ax25_dev && (ax25->condition & AX25_COND_DA= MA_MODE) && ax25->state > AX25_STATE_1) {=0A res =3D 1;=0A break;=0Ad= iff -ruN linux-2.6.0-test3.bk/net/ax25/ax25_ds_timer.c linux-2.6.0-test3.bk= .rxq/net/ax25/ax25_ds_timer.c=0A--- linux-2.6.0-test3.bk/net/ax25/ax25_ds_t= imer.c 2003-08-20 19:00:29.000000000 +0200=0A+++ linux-2.6.0-test3.bk.rxq/n= et/ax25/ax25_ds_timer.c 2003-08-20 19:58:29.000000000 +0200=0A@@ -74,6 +74,= 7 @@=0A {=0A ax25_dev *ax25_dev =3D (struct ax25_dev *) arg;=0A ax25_cb *= ax25;=0A+ struct hlist_node *node;=0A =0A if (ax25_dev =3D=3D NULL || !ax2= 5_dev->dama.slave)=0A return; /* Yikes! */=0A@@ -84,7 +85,7 @@=0A }=0A= =0A spin_lock_bh(&ax25_list_lock);=0A- for (ax25=3Dax25_list; ax25 !=3D N= ULL; ax25 =3D ax25->next) {=0A+ ax25_for_each(ax25, node, &ax25_list) {=0A = if (ax25->ax25_dev !=3D ax25_dev || !(ax25->condition & AX25_COND_DAMA_MO= DE))=0A continue;=0A =0A@@ -98,15 +99,26 @@=0A =0A void ax25_ds_heartbea= t_expiry(ax25_cb *ax25)=0A {=0A+ struct sock *sk=3Dax25->sk;=0A+=0A+ if (sk= )=0A+ bh_lock_sock(sk);=0A+=0A switch (ax25->state) {=0A =0A case AX25_S= TATE_0:=0A /* Magic here: If we listen() and a new link dies before it=0A= is accepted() it isn't 'dead' so doesn't get removed. */=0A- if (!ax= 25->sk || sock_flag(ax25->sk, SOCK_DESTROY) ||=0A- (ax25->sk->sk_state= =3D=3D TCP_LISTEN &&=0A- sock_flag(ax25->sk, SOCK_DEAD))) {=0A- ax= 25_destroy_socket(ax25);=0A+ if (!sk || sock_flag(sk, SOCK_DESTROY) ||=0A+= (sk->sk_state =3D=3D TCP_LISTEN &&=0A+ sock_flag(sk, SOCK_DEAD)= )) {=0A+ if (sk) {=0A+ sock_hold(sk);=0A+ ax25_destroy_socket(ax25)= ;=0A+ sock_put(sk);=0A+ bh_unlock_sock(sk);=0A+ } else=0A+ ax25_= destroy_socket(ax25);=0A return;=0A }=0A break;=0A@@ -115,9 +127,9 @= @=0A /*=0A * Check the state of the receive buffer.=0A */=0A- if (= ax25->sk !=3D NULL) {=0A- if (atomic_read(&ax25->sk->sk_rmem_alloc) <=0A-= (ax25->sk->sk_rcvbuf / 2) &&=0A+ if (sk !=3D NULL) {=0A+ if (atom= ic_read(&sk->sk_rmem_alloc) <=0A+ (sk->sk_rcvbuf / 2) &&=0A (a= x25->condition & AX25_COND_OWN_RX_BUSY)) {=0A ax25->condition &=3D ~AX2= 5_COND_OWN_RX_BUSY;=0A ax25->condition &=3D ~AX25_COND_ACK_PENDING;=0A@= @ -127,6 +139,9 @@=0A break;=0A }=0A =0A+ if (sk)=0A+ bh_unlock_sock(sk= );=0A+=0A ax25_start_heartbeat(ax25);=0A }=0A =0A@@ -157,6 +172,7 @@=0A a= x25_stop_t3timer(ax25);=0A =0A if (ax25->sk !=3D NULL) {=0A+ bh_lock_sock= (ax25->sk);=0A ax25->sk->sk_state =3D TCP_CLOSE;=0A ax25->sk->sk_er= r =3D 0;=0A ax25->sk->sk_shutdown |=3D SEND_SHUTDOWN;=0A@@ -164,6 += 180,7 @@=0A ax25->sk->sk_state_change(ax25->sk);=0A sock_set_flag(ax2= 5->sk, SOCK_DEAD);=0A }=0A+ bh_lock_sock(ax25->sk);=0A }=0A }=0A =0Adif= f -ruN linux-2.6.0-test3.bk/net/ax25/ax25_in.c linux-2.6.0-test3.bk.rxq/net= /ax25/ax25_in.c=0A--- linux-2.6.0-test3.bk/net/ax25/ax25_in.c 2003-08-20 19= :00:29.000000000 +0200=0A+++ linux-2.6.0-test3.bk.rxq/net/ax25/ax25_in.c 20= 03-08-20 19:58:29.000000000 +0200=0A@@ -147,6 +147,7 @@=0A }=0A =0A if (a= x25->sk !=3D NULL && ax25->ax25_dev->values[AX25_VALUES_CONMODE] =3D=3D 2) = {=0A+ bh_lock_sock(ax25->sk);=0A if ((!ax25->pidincl && ax25->sk->sk_pro= tocol =3D=3D pid) ||=0A ax25->pidincl) {=0A if (sock_queue_rcv_skb= (ax25->sk, skb) =3D=3D 0)=0A@@ -154,6 +155,7 @@=0A else=0A ax25->con= dition |=3D AX25_COND_OWN_RX_BUSY;=0A }=0A+ bh_unlock_sock(ax25->sk);=0A= }=0A =0A return queued;=0A@@ -329,6 +331,7 @@=0A if (ax25_process_rx_f= rame(ax25, skb, type, dama) =3D=3D 0)=0A kfree_skb(skb);=0A =0A+ ax25_c= b_put(ax25);=0A return 0;=0A }=0A =0A@@ -357,11 +360,14 @@=0A sk =3D a= x25_find_listener(next_digi, 1, dev, SOCK_SEQPACKET);=0A =0A if (sk !=3D N= ULL) {=0A+ bh_lock_sock(sk);=0A if (sk->sk_ack_backlog =3D=3D sk->sk_max= _ack_backlog ||=0A (make =3D ax25_make_new(sk, ax25_dev)) =3D=3D NULL= ) {=0A if (mine)=0A ax25_return_dm(dev, &src, &dest, &dp);=0A kfr= ee_skb(skb);=0A+ bh_unlock_sock(sk);=0A+ sock_put(sk);=0A =0A return= 0;=0A }=0A@@ -374,6 +380,8 @@=0A make->sk_pair =3D sk;=0A =0A sk->s= k_ack_backlog++;=0A+ bh_unlock_sock(sk);=0A+ sock_put(sk);=0A } else {= =0A if (!mine) {=0A kfree_skb(skb);=0A@@ -429,7 +437,7 @@=0A =0A ax25= ->state =3D AX25_STATE_3;=0A =0A- ax25_insert_socket(ax25);=0A+ ax25_cb_add= (ax25);=0A =0A ax25_start_heartbeat(ax25);=0A ax25_start_t3timer(ax25);= =0Adiff -ruN linux-2.6.0-test3.bk/net/ax25/ax25_ip.c linux-2.6.0-test3.bk.r= xq/net/ax25/ax25_ip.c=0A--- linux-2.6.0-test3.bk/net/ax25/ax25_ip.c 2003-08= -20 19:00:29.000000000 +0200=0A+++ linux-2.6.0-test3.bk.rxq/net/ax25/ax25_i= p.c 2003-08-20 19:58:29.000000000 +0200=0A@@ -107,6 +107,7 @@=0A ax25_addr= ess *src, *dst;=0A ax25_dev *ax25_dev;=0A ax25_route _route, *route =3D &= _route;=0A+ ax25_cb *ax25;=0A =0A dst =3D (ax25_address *)(bp + 1);=0A sr= c =3D (ax25_address *)(bp + 8);=0A@@ -167,9 +168,14 @@=0A skb_pull(oursk= b, AX25_HEADER_LEN - 1); /* Keep PID */=0A ourskb->nh.raw =3D ourskb->da= ta;=0A =0A- ax25_send_frame(ourskb, ax25_dev->values[AX25_VALUES_PACLEN],= &src_c,=0A-&dst_c, route->digipeat, dev);=0A-=0A+ ax25=3Dax25_send_frame= (=0A+ ourskb, =0A+ ax25_dev->values[AX25_VALUES_PACLEN], =0A+ = &src_c,=0A+ &dst_c, route->digipeat, dev);=0A+ if (ax25) {=0A+= ax25_cb_put(ax25);=0A+ }=0A goto put;=0A }=0A }=0Adiff -ruN lin= ux-2.6.0-test3.bk/net/ax25/ax25_out.c linux-2.6.0-test3.bk.rxq/net/ax25/ax2= 5_out.c=0A--- linux-2.6.0-test3.bk/net/ax25/ax25_out.c 2003-08-20 19:00:30.= 000000000 +0200=0A+++ linux-2.6.0-test3.bk.rxq/net/ax25/ax25_out.c 2003-08-= 20 19:58:29.000000000 +0200=0A@@ -71,7 +71,7 @@=0A =0A if (digi !=3D NULL)= {=0A if ((ax25->digipeat =3D kmalloc(sizeof(ax25_digi), GFP_ATOMIC)) =3D= =3D NULL) {=0A- ax25_free_cb(ax25);=0A+ ax25_cb_put(ax25);=0A return= NULL;=0A }=0A memcpy(ax25->digipeat, digi, sizeof(ax25_digi));=0A@@ -9= 3,7 +93,7 @@=0A #endif=0A }=0A =0A- ax25_insert_socket(ax25);=0A+ ax25_cb_= add(ax25);=0A =0A ax25->state =3D AX25_STATE_1;=0A =0Adiff -ruN linux-2.6.= 0-test3.bk/net/ax25/ax25_route.c linux-2.6.0-test3.bk.rxq/net/ax25/ax25_rou= te.c=0A--- linux-2.6.0-test3.bk/net/ax25/ax25_route.c 2003-08-20 19:00:30.0= 00000000 +0200=0A+++ linux-2.6.0-test3.bk.rxq/net/ax25/ax25_route.c 2003-08= -20 19:58:29.000000000 +0200=0A@@ -162,6 +162,7 @@=0A if (ax25_rt->digipe= at !=3D NULL)=0A kfree(ax25_rt->digipeat);=0A kfree(ax25_rt);=0A+ ret= urn;=0A }=0A =0A /*=0A@@ -434,8 +435,11 @@=0A ax25_adjust_path(addr, ax= 25->digipeat);=0A }=0A =0A- if (ax25->sk !=3D NULL)=0A+ if (ax25->sk !=3D = NULL) {=0A+ bh_lock_sock(ax25->sk);=0A ax25->sk->sk_zapped =3D 0;=0A+ b= h_unlock_sock(ax25->sk);=0A+ }=0A =0A put:=0A ax25_put_route(ax25_rt);=0Ad= iff -ruN linux-2.6.0-test3.bk/net/ax25/ax25_std_in.c linux-2.6.0-test3.bk.r= xq/net/ax25/ax25_std_in.c=0A--- linux-2.6.0-test3.bk/net/ax25/ax25_std_in.c= 2003-08-20 19:00:29.000000000 +0200=0A+++ linux-2.6.0-test3.bk.rxq/net/ax2= 5/ax25_std_in.c 2003-08-20 19:58:29.000000000 +0200=0A@@ -73,10 +73,12 @@= =0A ax25->state =3D AX25_STATE_3;=0A ax25->n2count =3D 0;=0A if = (ax25->sk !=3D NULL) {=0A+ bh_lock_sock(ax25->sk);=0A ax25->sk->sk_s= tate =3D TCP_ESTABLISHED;=0A /* For WAIT_SABM connections we will produ= ce an accept ready socket here */=0A if (!sock_flag(ax25->sk, SOCK_DEAD= ))=0A ax25->sk->sk_state_change(ax25->sk);=0A+ bh_unlock_sock(ax25-= >sk);=0A }=0A }=0A break;=0Adiff -ruN linux-2.6.0-test3.bk/net/ax25/= ax25_std_timer.c linux-2.6.0-test3.bk.rxq/net/ax25/ax25_std_timer.c=0A--- l= inux-2.6.0-test3.bk/net/ax25/ax25_std_timer.c 2003-08-20 19:00:29.000000000= +0200=0A+++ linux-2.6.0-test3.bk.rxq/net/ax25/ax25_std_timer.c 2003-08-20 = 19:58:29.000000000 +0200=0A@@ -33,14 +33,25 @@=0A =0A void ax25_std_heartbe= at_expiry(ax25_cb *ax25)=0A {=0A+ struct sock *sk=3Dax25->sk;=0A+ =0A+ if (= sk)=0A+ bh_lock_sock(sk);=0A+=0A switch (ax25->state) {=0A case AX25_STA= TE_0:=0A /* Magic here: If we listen() and a new link dies before it=0A = is accepted() it isn't 'dead' so doesn't get removed. */=0A- if (!ax25= ->sk || sock_flag(ax25->sk, SOCK_DESTROY) ||=0A- (ax25->sk->sk_state = =3D=3D TCP_LISTEN &&=0A- sock_flag(ax25->sk, SOCK_DEAD))) {=0A- ax2= 5_destroy_socket(ax25);=0A+ if (!sk || sock_flag(sk, SOCK_DESTROY) ||=0A+ = (sk->sk_state =3D=3D TCP_LISTEN &&=0A+ sock_flag(sk, SOCK_DEAD))= ) {=0A+ if (sk) {=0A+ sock_hold(sk);=0A+ ax25_destroy_socket(ax25);= =0A+ bh_unlock_sock(sk);=0A+ sock_put(sk);=0A+ } else=0A+ ax25_d= estroy_socket(ax25);=0A return;=0A }=0A break;=0A@@ -50,9 +61,9 @@= =0A /*=0A * Check the state of the receive buffer.=0A */=0A- if (a= x25->sk !=3D NULL) {=0A- if (atomic_read(&ax25->sk->sk_rmem_alloc) <=0A- = (ax25->sk->sk_rcvbuf / 2) &&=0A+ if (sk !=3D NULL) {=0A+ if (atomi= c_read(&sk->sk_rmem_alloc) <=0A+ (sk->sk_rcvbuf / 2) &&=0A (ax= 25->condition & AX25_COND_OWN_RX_BUSY)) {=0A ax25->condition &=3D ~AX25= _COND_OWN_RX_BUSY;=0A ax25->condition &=3D ~AX25_COND_ACK_PENDING;=0A@@= -62,6 +73,9 @@=0A }=0A }=0A =0A+ if (sk)=0A+ bh_unlock_sock(sk);=0A+= =0A ax25_start_heartbeat(ax25);=0A }=0A =0A@@ -94,6 +108,7 @@=0A ax25_sto= p_t3timer(ax25);=0A =0A if (ax25->sk !=3D NULL) {=0A+ bh_lock_sock(ax25->= sk);=0A ax25->sk->sk_state =3D TCP_CLOSE;=0A ax25->sk->sk_err = =3D 0;=0A ax25->sk->sk_shutdown |=3D SEND_SHUTDOWN;=0A@@ -101,6 +116,7 @= @=0A ax25->sk->sk_state_change(ax25->sk);=0A sock_set_flag(ax25->sk, = SOCK_DEAD);=0A }=0A+ bh_unlock_sock(ax25->sk);=0A }=0A }=0A =0Adiff -ru= N linux-2.6.0-test3.bk/net/ax25/ax25_timer.c linux-2.6.0-test3.bk.rxq/net/a= x25/ax25_timer.c=0A--- linux-2.6.0-test3.bk/net/ax25/ax25_timer.c 2003-08-2= 0 19:00:30.000000000 +0200=0A+++ linux-2.6.0-test3.bk.rxq/net/ax25/ax25_tim= er.c 2003-08-20 19:58:29.000000000 +0200=0A@@ -141,13 +141,10 @@=0A {=0A i= nt proto =3D AX25_PROTO_STD_SIMPLEX;=0A ax25_cb *ax25 =3D (ax25_cb *)param= ;=0A- struct sock *sk =3D ax25->sk;=0A =0A if (ax25->ax25_dev)=0A proto = =3D ax25->ax25_dev->values[AX25_VALUES_PROTOCOL];=0A =0A- bh_lock_sock(sk);= =0A-=0A switch (proto) {=0A case AX25_PROTO_STD_SIMPLEX:=0A case AX25_PR= OTO_STD_DUPLEX:=0A@@ -163,15 +160,12 @@=0A break;=0A #endif=0A }=0A- bh_= unlock_sock(sk);=0A }=0A =0A static void ax25_t1timer_expiry(unsigned long = param)=0A {=0A ax25_cb *ax25 =3D (ax25_cb *)param;=0A- struct sock *sk =3D= ax25->sk;=0A =0A- bh_lock_sock(sk);=0A switch (ax25->ax25_dev->values[AX2= 5_VALUES_PROTOCOL]) {=0A case AX25_PROTO_STD_SIMPLEX:=0A case AX25_PROTO_= STD_DUPLEX:=0A@@ -185,15 +179,12 @@=0A break;=0A #endif=0A }=0A- bh_unlo= ck_sock(sk);=0A }=0A =0A static void ax25_t2timer_expiry(unsigned long para= m)=0A {=0A ax25_cb *ax25 =3D (ax25_cb *)param;=0A- struct sock *sk =3D ax2= 5->sk;=0A =0A- bh_lock_sock(sk);=0A switch (ax25->ax25_dev->values[AX25_VA= LUES_PROTOCOL]) {=0A case AX25_PROTO_STD_SIMPLEX:=0A case AX25_PROTO_STD_= DUPLEX:=0A@@ -207,15 +198,12 @@=0A break;=0A #endif=0A }=0A- bh_unlock_s= ock(sk);=0A }=0A =0A static void ax25_t3timer_expiry(unsigned long param)= =0A {=0A ax25_cb *ax25 =3D (ax25_cb *)param;=0A- struct sock *sk =3D ax25-= >sk;=0A =0A- bh_lock_sock(sk);=0A switch (ax25->ax25_dev->values[AX25_VALU= ES_PROTOCOL]) {=0A case AX25_PROTO_STD_SIMPLEX:=0A case AX25_PROTO_STD_DU= PLEX:=0A@@ -231,15 +219,12 @@=0A break;=0A #endif=0A }=0A- bh_unlock_soc= k(sk);=0A }=0A =0A static void ax25_idletimer_expiry(unsigned long param)= =0A {=0A ax25_cb *ax25 =3D (ax25_cb *)param;=0A- struct sock *sk =3D ax25-= >sk;=0A =0A- bh_lock_sock(sk);=0A switch (ax25->ax25_dev->values[AX25_VALU= ES_PROTOCOL]) {=0A case AX25_PROTO_STD_SIMPLEX:=0A case AX25_PROTO_STD_DU= PLEX:=0A@@ -255,5 +240,4 @@=0A break;=0A #endif=0A }=0A- bh_unlock_sock(= sk);=0A }=0Adiff -ruN linux-2.6.0-test3.bk/net/ax25/sysctl_net_ax25.c linux= -2.6.0-test3.bk.rxq/net/ax25/sysctl_net_ax25.c=0A--- linux-2.6.0-test3.bk/n= et/ax25/sysctl_net_ax25.c 2003-08-20 19:00:29.000000000 +0200=0A+++ linux-2= .6.0-test3.bk.rxq/net/ax25/sysctl_net_ax25.c 2003-08-20 19:58:29.000000000 = +0200=0A@@ -204,8 +204,10 @@=0A for (ax25_table_size =3D sizeof(ctl_table)= , ax25_dev =3D ax25_dev_list; ax25_dev !=3D NULL; ax25_dev =3D ax25_dev->ne= xt)=0A ax25_table_size +=3D sizeof(ctl_table);=0A =0A- if ((ax25_table = =3D kmalloc(ax25_table_size, GFP_ATOMIC)) =3D=3D NULL)=0A+ if ((ax25_table = =3D kmalloc(ax25_table_size, GFP_ATOMIC)) =3D=3D NULL) {=0A+ spin_unlock_b= h(&ax25_dev_lock);=0A return;=0A+ }=0A =0A memset(ax25_table, 0x00, ax25= _table_size);=0A =0A--- linux-2.6.0-test3.bk/include/net/ax25.h 2003-08-20 = 19:05:22.000000000 +0200=0A+++ linux-2.6.0-test3.bk.rxq/include/net/ax25.h = 2003-08-20 19:41:56.000000000 +0200=0A@@ -10,6 +10,7 @@=0A #include =0A #include =0A #include =0A+#incl= ude =0A #include =0A =0A #define AX25_T1CLAMPLO= 1=0A@@ -180,7 +181,7 @@=0A } ax25_dev;=0A =0A typedef struct ax25_cb {= =0A- struct ax25_cb *next;=0A+ struct hlist_node ax25_node;=0A ax25_addre= ss source_addr, dest_addr;=0A ax25_digi *digipeat;=0A ax25_dev *ax25_d= ev;=0A@@ -197,17 +198,32 @@=0A struct sk_buff_head ack_queue;=0A struct s= k_buff_head frag_queue;=0A unsigned char window;=0A- struct timer_list ti= mer;=0A+ struct timer_list timer, dtimer;=0A struct sock *sk; /* Backlin= k to socket */=0A+ atomic_t refcount;=0A } ax25_cb;=0A =0A #define ax25_sk= (__sk) ((ax25_cb *)(__sk)->sk_protinfo)=0A =0A+#define ax25_for_each(__ax25= , node, list) \=0A+ hlist_for_each_entry(__ax25, node, list, ax25_node)=0A+= =0A+#define ax25_cb_hold(__ax25) \=0A+ atomic_inc(&((__ax25)->refcount))=0A= +=0A+static __inline__ void ax25_cb_put(ax25_cb *ax25)=0A+{=0A+ if (atomic_= dec_and_test(&ax25->refcount)) {=0A+ if (ax25->digipeat)=0A+ kfree(ax25-= >digipeat);=0A+ kfree(ax25);=0A+ }=0A+}=0A+=0A /* af_ax25.c */=0A-extern a= x25_cb *ax25_list;=0A+extern struct hlist_head ax25_list;=0A extern spinloc= k_t ax25_list_lock;=0A-extern void ax25_free_cb(ax25_cb *);=0A-extern void = ax25_insert_socket(ax25_cb *);=0A+extern void ax25_cb_add(ax25_cb *);=0A st= ruct sock *ax25_find_listener(ax25_address *, int, struct net_device *, int= );=0A struct sock *ax25_get_socket(ax25_address *, ax25_address *, int);=0A= extern ax25_cb *ax25_find_cb(ax25_address *, ax25_address *, ax25_digi *, = struct net_device *);=0A --AWniW0JNca5xppdA Content-Type: application/octet-stream; charset=us-ascii Content-Disposition: attachment; filename="hard_header.diff" --- linux-2.6.0-test3.bk/net/ax25/ax25_subr.c 2003-08-20 19:00:29.000000000 +0200 +++ linux-2.6.0-test3.bk.rxq/net/ax25/ax25_subr.c 2003-08-20 19:58:29.000000000 +0200 @@ -158,10 +158,10 @@ struct sk_buff *skb; unsigned char *dptr; - if ((skb = alloc_skb(AX25_BPQ_HEADER_LEN + ax25_addr_size(ax25->digipeat) + 2, GFP_ATOMIC)) == NULL) + if ((skb = alloc_skb(ax25->ax25_dev->dev->hard_header_len + 2, GFP_ATOMIC)) == NULL) return; - skb_reserve(skb, AX25_BPQ_HEADER_LEN + ax25_addr_size(ax25->digipeat)); + skb_reserve(skb, ax25->ax25_dev->dev->hard_header_len); skb->nh.raw = skb->data; @@ -202,10 +202,10 @@ if (dev == NULL) return; - if ((skb = alloc_skb(AX25_BPQ_HEADER_LEN + ax25_addr_size(digi) + 1, GFP_ATOMIC)) == NULL) + if ((skb = alloc_skb(dev->hard_header_len + 1, GFP_ATOMIC)) == NULL) return; /* Next SABM will get DM'd */ - skb_reserve(skb, AX25_BPQ_HEADER_LEN + ax25_addr_size(digi)); + skb_reserve(skb, dev->hard_header_len); skb->nh.raw = skb->data; ax25_digi_invert(digi, &retdigi); @@ -282,6 +282,7 @@ ax25_link_failed(ax25, reason); if (ax25->sk != NULL) { + bh_lock_sock(ax25->sk); ax25->sk->sk_state = TCP_CLOSE; ax25->sk->sk_err = reason; ax25->sk->sk_shutdown |= SEND_SHUTDOWN; @@ -289,5 +290,6 @@ ax25->sk->sk_state_change(ax25->sk); sock_set_flag(ax25->sk, SOCK_DEAD); } + bh_unlock_sock(ax25->sk); } } --AWniW0JNca5xppdA Content-Type: application/octet-stream; charset=us-ascii Content-Disposition: attachment; filename="iface-lists.diff" --- linux-2.6.0-test3.bk/net/ax25/ax25_iface.c 2003-08-20 19:00:29.000000000 +0200 +++ linux-2.6.0-test3.bk.rxq/net/ax25/ax25_iface.c 2003-08-20 19:58:29.000000000 +0200 @@ -33,20 +33,20 @@ struct protocol_struct *next; unsigned int pid; int (*func)(struct sk_buff *, ax25_cb *); -} *protocol_list; +} *protocol_list = NULL; static rwlock_t protocol_list_lock = RW_LOCK_UNLOCKED; static struct linkfail_struct { struct linkfail_struct *next; void (*func)(ax25_cb *, int); -} *linkfail_list; +} *linkfail_list = NULL; static spinlock_t linkfail_lock = SPIN_LOCK_UNLOCKED; static struct listen_struct { struct listen_struct *next; ax25_address callsign; struct net_device *dev; -} *listen_list; +} *listen_list = NULL; static spinlock_t listen_lock = SPIN_LOCK_UNLOCKED; int ax25_protocol_register(unsigned int pid, @@ -129,8 +129,10 @@ spin_lock_bh(&linkfail_lock); linkfail = linkfail_list; - if (linkfail == NULL) + if (linkfail == NULL) { + spin_unlock_bh(&linkfail_lock); return; + } if (linkfail->func == func) { linkfail_list = linkfail->next; @@ -180,8 +182,10 @@ spin_lock_bh(&listen_lock); listen = listen_list; - if (listen == NULL) + if (listen == NULL) { + spin_unlock_bh(&listen_lock); return; + } if (ax25cmp(&listen->callsign, callsign) == 0 && listen->dev == dev) { listen_list = listen->next; @@ -226,8 +230,10 @@ spin_lock_bh(&listen_lock); for (listen = listen_list; listen != NULL; listen = listen->next) - if (ax25cmp(&listen->callsign, callsign) == 0 && (listen->dev == dev || listen->dev == NULL)) + if (ax25cmp(&listen->callsign, callsign) == 0 && (listen->dev == dev || listen->dev == NULL)) { + spin_unlock_bh(&listen_lock); return 1; + } spin_unlock_bh(&listen_lock); return 0; --AWniW0JNca5xppdA-- From davidsen@tmr.com Wed Aug 20 12:17:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 12:17:42 -0700 (PDT) Received: from gatekeeper.tmr.com (tmr-02.dsl.thebiz.net [216.238.38.204]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KJHXoO003373 for ; Wed, 20 Aug 2003 12:17:36 -0700 Received: from localhost (davidsen@localhost) by gatekeeper.tmr.com (8.9.0/8.9.0) with SMTP id PAA15733; Wed, 20 Aug 2003 15:08:03 -0400 Date: Wed, 20 Aug 2003 15:08:03 -0400 (EDT) From: Bill Davidsen To: "David S. Miller" cc: dang@fprintf.net, alan@lxorguk.ukuu.org.uk, richard@aspectgroup.co.uk, skraw@ithnet.com, willy@w.ods.org, carlosev@newipnet.com, lamont@scriptkiddie.org, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices In-Reply-To: <20030820100044.3127d612.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5154 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davidsen@tmr.com Precedence: bulk X-list: netdev Content-Length: 2189 Lines: 54 On Wed, 20 Aug 2003, David S. Miller wrote: > On Wed, 20 Aug 2003 12:49:14 -0400 (EDT) > Bill Davidsen wrote: > > > On 19 Aug 2003, Daniel Gryniewicz wrote: > > > > I have been asking for a similar thing as well, David mentioned some > > things that would break, but I believe they break if you use source > > routing, so that seems not to be a real objection. > > It's not about source routing. It's about failover and being > able to use ARP on interfaces which don't have addresses assigned > to them yet. David mentioned that you could solve the problem by using *rp_filter and source routing. I don't think that's entirely true, but doing so has the same drawbacks and breaks the same things as a flag to make Linux behave like Sun/BSD/Windows (and work with Cisco is the cases previously mentioned). > > > I find it interesting that we can't change networking because a few > > complex systems would have to be reconfigured, but we *can* change modules > > which requires config changes on probably 90% of all systems (commercial > > distributions). > > Decisions about Networking will always be in a different domain > because the way one behaves has effects upon other systems not > just the local one. Yes, that's exactly the point, the way Linux works has bad effects on certain other machines, as in leaves them disconnected to the Linux system. > > BTW, another thing which makes the source address selection for > outgoing ARPs a real touchy area is the following. Some weird > configurations actually respond with different ARP answers based upon > the source address in the ARP request. You can ask Julian Anastasov > about such (arguably pathological) setups. > I don't think anyone is asking for a change in the default behaviour (although my point about breaking modules does apply), people would be satisfied, even ecstatic, if we had a simple way (flag) to set to make Linux work without setting /proc filters, using arpfilter, applying source routes (David's suggestion) and generally jumping through hoops. -- bill davidsen CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. From bloemsaa@xs4all.nl Wed Aug 20 13:08:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 13:08:55 -0700 (PDT) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KK8SoO006061 for ; Wed, 20 Aug 2003 13:08:49 -0700 Received: from llewella (vialle.xs4all.nl [213.84.6.25]) by smtpzilla5.xs4all.nl (8.12.9/8.12.9) with SMTP id h7KK7PEs078066; Wed, 20 Aug 2003 22:07:38 +0200 (CEST) Message-ID: <00a501c36756$b536ed30$c801a8c0@llewella> From: "Bas Bloemsaat" To: "David S. Miller" Cc: , , , , , , , , , , , , References: Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices Date: Wed, 20 Aug 2003 22:07:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 5155 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bloemsaa@xs4all.nl Precedence: bulk X-list: netdev Content-Length: 691 Lines: 17 > I don't think anyone is asking for a change in the default behaviour > (although my point about breaking modules does apply), people would be > satisfied, even ecstatic, if we had a simple way (flag) to set to make > Linux work without setting /proc filters, using arpfilter, applying source > routes (David's suggestion) and generally jumping through hoops. Agree! Just a flag (ARP_ISOLATED, default to 0) in /proc/sys/net/ipv4/conf/*? The default behaviour of the current (and future kernels) stays as it is now, so it doesn't break for anyone, and a lot of people (including me :) benefit from a much easier setup. No need to implement a whole hidden scenario either. Regards, Bas From willy@w.ods.org Wed Aug 20 14:36:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 14:36:37 -0700 (PDT) Received: from www.home.local (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KLaRoO011105 for ; Wed, 20 Aug 2003 14:36:28 -0700 Received: from alpha.home.local (alpha [10.0.1.2]) by www.home.local (8.12.1/8.12.1) with ESMTP id h7KLaKpn000412; Wed, 20 Aug 2003 23:36:20 +0200 Received: (from willy@localhost) by alpha.home.local (8.12.4/8.12.1) id h7KLYhjE024597; Wed, 20 Aug 2003 23:34:43 +0200 Date: Wed, 20 Aug 2003 23:34:43 +0200 From: Willy Tarreau To: "David S. Miller" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [RFC][2.4 PATCH] source address selection for ARP requests Message-ID: <20030820213443.GA23939@alpha.home.local> References: <1061320363.3744.14.camel@athena.fprintf.net> <20030820100044.3127d612.davem@redhat.com> <3F43B389.5060602@candelatech.com> <20030820104831.6235f3b9.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030820104831.6235f3b9.davem@redhat.com> User-Agent: Mutt/1.4i X-archive-position: 5157 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@w.ods.org Precedence: bulk X-list: netdev Content-Length: 5841 Lines: 163 Hi David, On Wed, Aug 20, 2003 at 10:48:31AM -0700, David S. Miller wrote: > On Wed, 20 Aug 2003 10:44:41 -0700 > Ben Greear wrote: > > > It seems that these reasons would not preclude the addition of a flag > > that would default to the current behaviour but allow the behaviour that > > other setups desire easily? > > I would accept a patch that did something like > the following in arp_solicit(). > > if (skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL && > (in_dev->conf.shared_media || > inet_addr_onlink(dev, skb->nh.iph->saddr, 0))) > saddr = skb->nh.iph->saddr; > else > saddr = inet_select_addr(dev, target, RT_SCOPE_LINE); > I finally found some time to code and test both Alexey's idea and the one I derived from it the other day. 1) Alexey's solution (above, patch below) It solves most issues discussed previously, which showed up on somewhat common setups like this one : Server Gateway eth0=10.0.0.1 eth1=11.0.0.1 --------- IP=11.0.0.2 When server receives a ping to 10.0.0.1 from Gateway or some host behind it, it will now properly select 11.0.0.1 for the ARP request prior to sending its echo reply. This behaviour requires the user to explicitly set eth1/shared_media and all/shared_media to 0 (not too hard). => So the patch below fixes most problems. -8<-------------------------- --- linux-2.4.22-rc2/net/ipv4/arp.c Wed Jul 30 09:19:06 2003 +++ linux-2.4.22-rc2-arp/net/ipv4/arp.c Wed Aug 20 21:19:42 2003 @@ -320,13 +320,22 @@ u32 saddr; u8 *dst_ha = NULL; struct net_device *dev = neigh->dev; + struct in_device *in_dev = in_dev_get(dev); u32 target = *(u32*)neigh->primary_key; int probes = atomic_read(&neigh->probes); - if (skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL) + if (in_dev == NULL) + return; + + if (in_dev->ifa_list == NULL || + (skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL && + (IN_DEV_SHARED_MEDIA(in_dev) || + inet_addr_onlink(in_dev, skb->nh.iph->saddr, 0)))) saddr = skb->nh.iph->saddr; else saddr = inet_select_addr(dev, target, RT_SCOPE_LINK); + + in_dev_put(in_dev); if ((probes -= neigh->parms->ucast_probes) < 0) { if (!(neigh->nud_state&NUD_VALID)) -8<-------------------------- However, there still is a case which is not covered : when the source address is itself on the same interface. Let's take the previous example and add an alias to eth1 : Server Gateway eth0=10.0.0.1 eth1=11.0.0.1 --------- IP=11.0.0.2 12.0.0.1 If gateway pings 12.0.0.1, Server will use this address to send its ARP requests (because of the 'inet_addr_onlink' above). The workaround would simply be to move the alias somewhere else... Second, you were concerned about breaking setups with no IP address on eth1 because inet_addr_onlink() will return 0, and inet_select_addr() will fail, in the event they would run with shared_media=0 : Server Gateway eth0=10.0.0.1 eth1=*no IP* ---------- IP=11.0.0.2 In fact, inet_select_addr() is smarter than inet_addr_onlink() in that it can also return non-loopback addresses set to the loopback interface. Moreover, if it fails, it returns 0, which is a good test to drop back to the current behaviour (use skb->nh.iph->saddr). I didn't manage to get my interface to send ARP requests when I have no IP address on it, because I don't know how to do, since I cannot add a route to it. I presume I could make it work with SO_BINDTODEVICE + MSG_DONTROUTE, but I don't have time to try all this. So please look at this code now : -8<------------------------------- diff -urN linux-2.4.22-rc2/net/ipv4/arp.c linux-2.4.22-rc2-arp3/net/ipv4/arp.c --- linux-2.4.22-rc2/net/ipv4/arp.c Wed Jul 30 09:19:06 2003 +++ linux-2.4.22-rc2-arp3/net/ipv4/arp.c Wed Aug 20 23:11:53 2003 @@ -320,13 +320,21 @@ u32 saddr; u8 *dst_ha = NULL; struct net_device *dev = neigh->dev; + struct in_device *in_dev = in_dev_get(dev); u32 target = *(u32*)neigh->primary_key; int probes = atomic_read(&neigh->probes); - if (skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL) - saddr = skb->nh.iph->saddr; + if (in_dev == NULL) + return; + + if (skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL && + (IN_DEV_SHARED_MEDIA(in_dev) || + (saddr = inet_select_addr(dev, target, RT_SCOPE_LINK)) == 0)) + saddr = skb->nh.iph->saddr; else saddr = inet_select_addr(dev, target, RT_SCOPE_LINK); + + in_dev_put(in_dev); if ((probes -= neigh->parms->ucast_probes) < 0) { if (!(neigh->nud_state&NUD_VALID)) -8<------------------------------- It will correctly pick the most appropriate address when shared_media=0, and will also drop back to the current behaviour when there's no IP yet on the device. It also enhances an interesting point compared to the previous one : it allows broken setups such as the one below to select the valid source IP depending on source route : Server Gateway eth0=11.0.0.1 eth1=10.0.0.1 --------- IP=11.0.0.2 ip addr add 11.0.0.1/N dev eth0 ip addr add 10.0.0.1/M dev eth1 scope host ip route add 11.0.0.2 dev eth1 src 11.0.0.1 => ARP requests sent to 11.0.0.2 "correctly" use 11.0.0.1 as the source IP. I'm not sure this setup will concern anyone, but I came across it during my tests of the patch, and thought that for evry setup which people will be able to configure themselves without patching, there will be less whiners ;-) I'd sincerely prefer the later patch to be tested and integrated, but Alexey's first idea was the former, so I don't know which one you'll pick. Of course, if you're willing to apply one of them, I'll try to port them to 2.6. Cheers, Willy From davem@redhat.com Wed Aug 20 14:56:55 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 14:56:58 -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 h7KLusoO012042 for ; Wed, 20 Aug 2003 14:56:55 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id OAA22426; Wed, 20 Aug 2003 14:47:11 -0700 Date: Wed, 20 Aug 2003 14:47:11 -0700 From: "David S. Miller" To: Willy Tarreau Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [RFC][2.4 PATCH] source address selection for ARP requests Message-Id: <20030820144711.13ea5f38.davem@redhat.com> In-Reply-To: <20030820213443.GA23939@alpha.home.local> References: <1061320363.3744.14.camel@athena.fprintf.net> <20030820100044.3127d612.davem@redhat.com> <3F43B389.5060602@candelatech.com> <20030820104831.6235f3b9.davem@redhat.com> <20030820213443.GA23939@alpha.home.local> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5158 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 Content-Length: 239 Lines: 9 On Wed, 20 Aug 2003 23:34:43 +0200 Willy Tarreau wrote: > + if (in_dev == NULL) > + return; A NULL in_dev is what you'll see if no addresses are assigned to the interface, therefore you must treat this case similarly. From willy@w.ods.org Wed Aug 20 15:28:56 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 15:29:03 -0700 (PDT) Received: from www.home.local (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KMSsoO013334 for ; Wed, 20 Aug 2003 15:28:55 -0700 Received: from alpha.home.local (alpha [10.0.1.2]) by www.home.local (8.12.1/8.12.1) with ESMTP id h7KMSlpn000418; Thu, 21 Aug 2003 00:28:47 +0200 Received: (from willy@localhost) by alpha.home.local (8.12.4/8.12.1) id h7KMRBNC025178; Thu, 21 Aug 2003 00:27:11 +0200 Date: Thu, 21 Aug 2003 00:27:10 +0200 From: Willy Tarreau To: "David S. Miller" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [RFC][2.4 PATCH] source address selection for ARP requests Message-ID: <20030820222710.GC734@alpha.home.local> References: <1061320363.3744.14.camel@athena.fprintf.net> <20030820100044.3127d612.davem@redhat.com> <3F43B389.5060602@candelatech.com> <20030820104831.6235f3b9.davem@redhat.com> <20030820213443.GA23939@alpha.home.local> <20030820144711.13ea5f38.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030820144711.13ea5f38.davem@redhat.com> User-Agent: Mutt/1.4i X-archive-position: 5159 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@w.ods.org Precedence: bulk X-list: netdev Content-Length: 2469 Lines: 82 On Wed, Aug 20, 2003 at 02:47:11PM -0700, David S. Miller wrote: > On Wed, 20 Aug 2003 23:34:43 +0200 > Willy Tarreau wrote: > > > + if (in_dev == NULL) > > + return; > > A NULL in_dev is what you'll see if no addresses are > assigned to the interface, therefore you must treat > this case similarly. OK, that's fine. It is what I wanted to test with in_dev->ifa_list==NULL. I don't know if I must keep the test or not (anyway, it doesn't hurt, this isn't a fast path). Better this way ? Cheers, Willy -------- patch 1 : diff -urN linux-2.4.22-rc2/net/ipv4/arp.c linux-2.4.22-rc2-arp/net/ipv4/arp.c --- linux-2.4.22-rc2/net/ipv4/arp.c Fri Aug 1 23:06:29 2003 +++ linux-2.4.22-rc2-arp/net/ipv4/arp.c Thu Aug 21 00:20:19 2003 @@ -320,13 +320,20 @@ u32 saddr; u8 *dst_ha = NULL; struct net_device *dev = neigh->dev; + struct in_device *in_dev = in_dev_get(dev); u32 target = *(u32*)neigh->primary_key; int probes = atomic_read(&neigh->probes); - if (skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL) + if (in_dev == NULL || in_dev->ifa_list == NULL || + (skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL && + (IN_DEV_SHARED_MEDIA(in_dev) || + inet_addr_onlink(in_dev, skb->nh.iph->saddr, 0)))) saddr = skb->nh.iph->saddr; else saddr = inet_select_addr(dev, target, RT_SCOPE_LINK); + + if (in_dev == NULL) + in_dev_put(in_dev); if ((probes -= neigh->parms->ucast_probes) < 0) { if (!(neigh->nud_state&NUD_VALID)) --------- patch 2 : diff -urN linux-2.4.22-rc2/net/ipv4/arp.c linux-2.4.22-rc2-arp2/net/ipv4/arp.c --- linux-2.4.22-rc2/net/ipv4/arp.c Fri Aug 1 23:06:29 2003 +++ linux-2.4.22-rc2-arp2/net/ipv4/arp.c Thu Aug 21 00:24:25 2003 @@ -320,13 +320,19 @@ u32 saddr; u8 *dst_ha = NULL; struct net_device *dev = neigh->dev; + struct in_device *in_dev = in_dev_get(dev); u32 target = *(u32*)neigh->primary_key; int probes = atomic_read(&neigh->probes); - if (skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL) - saddr = skb->nh.iph->saddr; + if (skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL && + (in_dev == NULL || IN_DEV_SHARED_MEDIA(in_dev) || + (saddr = inet_select_addr(dev, target, RT_SCOPE_LINK)) == 0)) + saddr = skb->nh.iph->saddr; else saddr = inet_select_addr(dev, target, RT_SCOPE_LINK); + + if (in_dev == NULL) + in_dev_put(in_dev); if ((probes -= neigh->parms->ucast_probes) < 0) { if (!(neigh->nud_state&NUD_VALID)) From davem@redhat.com Wed Aug 20 15:43:05 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 15:43:10 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KMh4oO014056 for ; Wed, 20 Aug 2003 15:43:05 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id PAA22795; Wed, 20 Aug 2003 15:35:48 -0700 Date: Wed, 20 Aug 2003 15:35:48 -0700 From: "David S. Miller" To: Willy Tarreau Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [RFC][2.4 PATCH] source address selection for ARP requests Message-Id: <20030820153548.60e0cbd8.davem@redhat.com> In-Reply-To: <20030820222710.GC734@alpha.home.local> References: <1061320363.3744.14.camel@athena.fprintf.net> <20030820100044.3127d612.davem@redhat.com> <3F43B389.5060602@candelatech.com> <20030820104831.6235f3b9.davem@redhat.com> <20030820213443.GA23939@alpha.home.local> <20030820144711.13ea5f38.davem@redhat.com> <20030820222710.GC734@alpha.home.local> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5160 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 Content-Length: 152 Lines: 7 On Thu, 21 Aug 2003 00:27:10 +0200 Willy Tarreau wrote: > + if (in_dev == NULL) > + in_dev_put(in_dev); What the heck is this? :-) From willy@w.ods.org Wed Aug 20 16:01:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 16:01:27 -0700 (PDT) Received: from www.home.local (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KN1KoO014913 for ; Wed, 20 Aug 2003 16:01:21 -0700 Received: from alpha.home.local (alpha [10.0.1.2]) by www.home.local (8.12.1/8.12.1) with ESMTP id h7KN1Epn000432; Thu, 21 Aug 2003 01:01:14 +0200 Received: (from willy@localhost) by alpha.home.local (8.12.4/8.12.1) id h7KMxbNA025665; Thu, 21 Aug 2003 00:59:37 +0200 Date: Thu, 21 Aug 2003 00:59:37 +0200 From: Willy Tarreau To: "David S. Miller" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [RFC][2.4 PATCH] source address selection for ARP requests Message-ID: <20030820225937.GB25311@alpha.home.local> References: <1061320363.3744.14.camel@athena.fprintf.net> <20030820100044.3127d612.davem@redhat.com> <3F43B389.5060602@candelatech.com> <20030820104831.6235f3b9.davem@redhat.com> <20030820213443.GA23939@alpha.home.local> <20030820144711.13ea5f38.davem@redhat.com> <20030820222710.GC734@alpha.home.local> <20030820153548.60e0cbd8.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030820153548.60e0cbd8.davem@redhat.com> User-Agent: Mutt/1.4i X-archive-position: 5161 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@w.ods.org Precedence: bulk X-list: netdev Content-Length: 2642 Lines: 79 On Wed, Aug 20, 2003 at 03:35:48PM -0700, David S. Miller wrote: > On Thu, 21 Aug 2003 00:27:10 +0200 > Willy Tarreau wrote: > > > + if (in_dev == NULL) > > + in_dev_put(in_dev); > > What the heck is this? :-) Hmmm... don't you see ? A copy-paste bug, of course ! Sorry for this, I hope noone's fool enough to use it as-is. I guess it's becoming late, and I'm a bit weak in front of my temptations to use 'dd' .... 'P' in vi ! Here's the fixed one (hand-edited, not tested). At least, I'm happy to see that I'm not the only one reading other's patches :-) BTW, you didn't tell me if it's necessary to test in_dev->ifa_list. I see that I kept the test in patch 1 but removed it in patch 2. Willy patch 1 : diff -urN linux-2.4.22-rc2/net/ipv4/arp.c linux-2.4.22-rc2-arp/net/ipv4/arp.c --- linux-2.4.22-rc2/net/ipv4/arp.c Fri Aug 1 23:06:29 2003 +++ linux-2.4.22-rc2-arp/net/ipv4/arp.c Thu Aug 21 00:20:19 2003 @@ -320,13 +320,20 @@ u32 saddr; u8 *dst_ha = NULL; struct net_device *dev = neigh->dev; + struct in_device *in_dev = in_dev_get(dev); u32 target = *(u32*)neigh->primary_key; int probes = atomic_read(&neigh->probes); - if (skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL) + if (in_dev == NULL || in_dev->ifa_list == NULL || + (skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL && + (IN_DEV_SHARED_MEDIA(in_dev) || + inet_addr_onlink(in_dev, skb->nh.iph->saddr, 0)))) saddr = skb->nh.iph->saddr; else saddr = inet_select_addr(dev, target, RT_SCOPE_LINK); + + if (in_dev != NULL) + in_dev_put(in_dev); if ((probes -= neigh->parms->ucast_probes) < 0) { if (!(neigh->nud_state&NUD_VALID)) patch 2 : diff -urN linux-2.4.22-rc2/net/ipv4/arp.c linux-2.4.22-rc2-arp2/net/ipv4/arp.c --- linux-2.4.22-rc2/net/ipv4/arp.c Fri Aug 1 23:06:29 2003 +++ linux-2.4.22-rc2-arp2/net/ipv4/arp.c Thu Aug 21 00:24:25 2003 @@ -320,13 +320,19 @@ u32 saddr; u8 *dst_ha = NULL; struct net_device *dev = neigh->dev; + struct in_device *in_dev = in_dev_get(dev); u32 target = *(u32*)neigh->primary_key; int probes = atomic_read(&neigh->probes); - if (skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL) - saddr = skb->nh.iph->saddr; + if (skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL && + (in_dev == NULL || IN_DEV_SHARED_MEDIA(in_dev) || + (saddr = inet_select_addr(dev, target, RT_SCOPE_LINK)) == 0)) + saddr = skb->nh.iph->saddr; else saddr = inet_select_addr(dev, target, RT_SCOPE_LINK); + + if (in_dev != NULL) + in_dev_put(in_dev); if ((probes -= neigh->parms->ucast_probes) < 0) { if (!(neigh->nud_state&NUD_VALID)) From ja@ssi.bg Wed Aug 20 16:19:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 16:19:24 -0700 (PDT) Received: from u.domain.uli (ja.mac.ssi.bg [217.79.71.194]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7KNJBoO015784 for ; Wed, 20 Aug 2003 16:19:14 -0700 Received: from localhost (IDENT:ja@localhost [127.0.0.1]) by u.domain.uli (8.11.6/8.11.6) with ESMTP id h7KNIWi01720; Thu, 21 Aug 2003 02:18:33 +0300 Date: Thu, 21 Aug 2003 02:18:32 +0300 (EEST) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: "David S. Miller" cc: linux-kernel , Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices In-Reply-To: <20030820104831.6235f3b9.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5162 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ja@ssi.bg Precedence: bulk X-list: netdev Content-Length: 2042 Lines: 58 Hello, On Wed, 20 Aug 2003, David S. Miller wrote: > Then people can frob the shared_media sysctl for devices > where they want the behavior to be that we will only use > addresses assigned to the device as the solicitor address. > > The shared_media setting defaults to one and thus would preserve > current behavior by default. Hm, you are trying to save one additional flag :) > The idea is not mine, Alexey suggested it to me the other day. > > I hope this pleases people wrt. ARP request solicitor address > handling. More ideas/issues: - can we add medium_id checks near the inet_addr_onlink check, i.e. to extend the check for same medium, not only for same outdev, eg. saddr and outdev can be from same medium. That means we have to use ip_dev_find as replacement for inet_addr_type and inet_addr_onlink - fib_validate_source already drops packets from device with in_dev==NULL, there is no good reason to send ARP requests. Even ip_route_output_slow disallows such devices. That is, IP is disabled, so and ARP. - in the last days/weeks I have a doubt how asymmetric routing can safely work with the default behaviour. The arp_queue can contain packets with saddrs from different interfaces and subnets, all to the same resolved target IP. I'm not sure the remote system can properly answer to our requests in this case, at least, can not do it properly without rp_filter_mask [1] if there are 2 or more interfaces. Of course, the problem is when rp_filter is used there. - Broadcasting announcements for one saddr through many devices can create problems for us if we later receive traffic for this saddr when rp_filter=1 and there is no rp_filter_mask set. Can someone provide example setup for asymmetric routing that relies on the current behavior, I'll be glad to think on it. - can we swicth to safe behavior according to the probe number? For example, after the 1st ucast or bcast probe we can switch to source auto selection? [1] http://www.ssi.bg/~ja/#rp_filter_mask Regards -- Julian Anastasov From shemminger@osdl.org Wed Aug 20 17:08:21 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 17:08:26 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7L08KoO017714 for ; Wed, 20 Aug 2003 17:08:21 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7L07ro17097; Wed, 20 Aug 2003 17:07:53 -0700 Date: Wed, 20 Aug 2003 17:07:40 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: linux-tr@linuxtr.net, netdev@oss.sgi.com Subject: [PATCH] (2/6) tr - spin_lock consitency Message-Id: <20030820170740.7a80a9a8.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5164 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1747 Lines: 70 Use spin_lock on hash table consistently, this code is only called from bottom half context, never from interrupt context so use spin_lock_bh. Patch against 2.6.0-test3 bk latest. diff -Nru a/net/802/tr.c b/net/802/tr.c --- a/net/802/tr.c Wed Aug 20 15:51:27 2003 +++ b/net/802/tr.c Wed Aug 20 15:51:27 2003 @@ -236,9 +236,8 @@ struct rif_cache_s *entry; unsigned char *olddata; unsigned char mcast_func_addr[] = {0xC0,0x00,0x00,0x04,0x00,0x00}; - unsigned long flags ; - spin_lock_irqsave(&rif_lock,flags); + spin_lock_bh(&rif_lock); /* * Broadcasts are single route as stated in RFC 1042 @@ -308,7 +307,7 @@ else slack = 18 - ((ntohs(trh->rcf) & TR_RCF_LEN_MASK)>>8); olddata = skb->data; - spin_unlock_irqrestore(&rif_lock,flags); + spin_unlock_bh(&rif_lock); skb_pull(skb, slack); memmove(skb->data, olddata, sizeof(struct trh_hdr) - slack); @@ -418,9 +417,8 @@ { int i; unsigned long now=jiffies; - unsigned long flags ; - spin_lock_irqsave(&rif_lock,flags); + spin_lock_bh(&rif_lock); for(i=0; i < RIF_TABLE_SIZE;i++) { @@ -440,7 +438,7 @@ } } - spin_unlock_irqrestore(&rif_lock,flags); + spin_unlock_bh(&rif_lock); /* * Reset the timer @@ -477,10 +475,7 @@ static void *rif_seq_start(struct seq_file *seq, loff_t *pos) { - unsigned long flags; - - spin_lock_irqsave(&rif_lock, flags); - seq->private = (void *) flags; + spin_lock_bh(&rif_lock); return *pos ? rif_get_idx(*pos - 1) : RIF_PROC_START; } @@ -492,8 +487,7 @@ static void rif_seq_stop(struct seq_file *seq, void *v) { - unsigned long flags = (unsigned long) seq->private; - spin_lock_irqsave(&rif_lock, flags); + spin_unlock_bh(&rif_lock); } static int rif_seq_show(struct seq_file *seq, void *v) From shemminger@osdl.org Wed Aug 20 17:08:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 17:08:34 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7L08VoO017727 for ; Wed, 20 Aug 2003 17:08:31 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7L08Co17150; Wed, 20 Aug 2003 17:08:12 -0700 Date: Wed, 20 Aug 2003 17:08:00 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: linux-tr@linuxtr.net, netdev@oss.sgi.com Subject: [PATCH] (1/6) tr - get rid of typedef Message-Id: <20030820170800.66f882e7.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5165 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1557 Lines: 72 Get rid of the egregious typedef in 802/tr code. This type of pointer aliasing is confusing and gross. Patch against 2.6.0-test3 bk latest. diff -Nru a/net/802/tr.c b/net/802/tr.c --- a/net/802/tr.c Wed Aug 20 15:51:13 2003 +++ b/net/802/tr.c Wed Aug 20 15:51:13 2003 @@ -42,8 +42,6 @@ #define TR_SR_DEBUG 0 -typedef struct rif_cache_s *rif_cache; - /* * Each RIF entry we learn is kept this way */ @@ -53,7 +51,7 @@ int iface; __u16 rcf; __u16 rseg[8]; - rif_cache next; + struct rif_cache_s *next; unsigned long last_used; unsigned char local_ring; }; @@ -65,7 +63,7 @@ * up a lot. */ -static rif_cache rif_table[RIF_TABLE_SIZE]; +static struct rif_cache_s *rif_table[RIF_TABLE_SIZE]; static spinlock_t rif_lock = SPIN_LOCK_UNLOCKED; @@ -235,7 +233,7 @@ { int i, slack; unsigned int hash; - rif_cache entry; + struct rif_cache_s *entry; unsigned char *olddata; unsigned char mcast_func_addr[] = {0xC0,0x00,0x00,0x04,0x00,0x00}; unsigned long flags ; @@ -325,7 +323,7 @@ { int i; unsigned int hash, rii_p = 0; - rif_cache entry; + struct rif_cache_s *entry; spin_lock_bh(&rif_lock); @@ -426,7 +424,7 @@ for(i=0; i < RIF_TABLE_SIZE;i++) { - rif_cache entry, *pentry=rif_table+i; + struct rif_cache_s *entry, **pentry=rif_table+i; while((entry=*pentry)) { /* @@ -501,7 +499,7 @@ static int rif_seq_show(struct seq_file *seq, void *v) { int j, rcf_len, segment, brdgnmb; - rif_cache entry = v; + struct rif_cache_s *entry = v; if (v == RIF_PROC_START) seq_puts(seq, From shemminger@osdl.org Wed Aug 20 17:09:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 17:09:50 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7L09joO018245 for ; Wed, 20 Aug 2003 17:09:46 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7L09Oo17474; Wed, 20 Aug 2003 17:09:24 -0700 Date: Wed, 20 Aug 2003 17:09:11 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: linux-tr@linuxtr.net, netdev@oss.sgi.com Subject: [PATCH] (3/6) tr - mcast_addr need not be on stack Message-Id: <20030820170911.7e3e5471.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5166 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 520 Lines: 17 Multicast address value is put on stack and can just be static const. Patch against 2.6.0-test3 bk latest. diff -Nru a/net/802/tr.c b/net/802/tr.c --- a/net/802/tr.c Wed Aug 20 15:51:56 2003 +++ b/net/802/tr.c Wed Aug 20 15:51:56 2003 @@ -235,7 +235,8 @@ unsigned int hash; struct rif_cache_s *entry; unsigned char *olddata; - unsigned char mcast_func_addr[] = {0xC0,0x00,0x00,0x04,0x00,0x00}; + static const unsigned char mcast_func_addr[] + = {0xC0,0x00,0x00,0x04,0x00,0x00}; spin_lock_bh(&rif_lock); From shemminger@osdl.org Wed Aug 20 17:15:12 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 17:15:19 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7L0FBoO018821 for ; Wed, 20 Aug 2003 17:15:12 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7L0Eko18773; Wed, 20 Aug 2003 17:14:46 -0700 Date: Wed, 20 Aug 2003 17:14:34 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: linux-tr@linuxtr.net, netdev@oss.sgi.com Subject: [PATCH] (4/6) tr - better hash function Message-Id: <20030820171434.3174a152.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5167 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1621 Lines: 68 Rather than a simple for loop sum, use a better hash function for the mac address. Function repurposed from Lennert's bridge code. diff -Nru a/net/802/tr.c b/net/802/tr.c --- a/net/802/tr.c Wed Aug 20 15:52:05 2003 +++ b/net/802/tr.c Wed Aug 20 15:52:05 2003 @@ -78,6 +78,22 @@ int sysctl_tr_rif_timeout = RIF_TIMEOUT; +static inline unsigned long rif_hash(const unsigned char *addr) +{ + unsigned long x; + + x = addr[0]; + x = (x << 2) ^ addr[1]; + x = (x << 2) ^ addr[2]; + x = (x << 2) ^ addr[3]; + x = (x << 2) ^ addr[4]; + x = (x << 2) ^ addr[5]; + + x ^= x >> 8; + + return x & (RIF_TABLE_SIZE - 1); +} + /* * Put the headers on a token ring packet. Token ring source routing * makes this a little more exciting than on ethernet. @@ -231,7 +247,7 @@ void tr_source_route(struct sk_buff *skb,struct trh_hdr *trh,struct net_device *dev) { - int i, slack; + int slack; unsigned int hash; struct rif_cache_s *entry; unsigned char *olddata; @@ -252,8 +268,7 @@ } else { - for(i=0,hash=0;idaddr[i++]); - hash&=RIF_TABLE_SIZE-1; + hash = rif_hash(trh->daddr); /* * Walk the hash table and look for an entry */ @@ -321,7 +336,6 @@ static void tr_add_rif_info(struct trh_hdr *trh, struct net_device *dev) { - int i; unsigned int hash, rii_p = 0; struct rif_cache_s *entry; @@ -341,8 +355,7 @@ } } - for(i=0,hash=0;isaddr[i++]); - hash&=RIF_TABLE_SIZE-1; + hash = rif_hash(trh->saddr); for(entry=rif_table[hash];entry && memcmp(&(entry->addr[0]),&(trh->saddr[0]),TR_ALEN);entry=entry->next); if(entry==NULL) From shemminger@osdl.org Wed Aug 20 17:19:58 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 17:20:05 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7L0JwoO019251 for ; Wed, 20 Aug 2003 17:19:58 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7L0JYo19830; Wed, 20 Aug 2003 17:19:34 -0700 Date: Wed, 20 Aug 2003 17:19:22 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: linux-tr@linuxtr.net, netdev@oss.sgi.com Subject: [PATCH] (6/6) tr - expire timer improvements Message-Id: <20030820171922.1af68a7c.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5168 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 2804 Lines: 108 Cleanup the timer code. It works as is, but: - use timer_ macro's when working with jiffies. - cleanup the #define's - make timer run sooner (ie when next entry will expire) rather than waiting till the next 10 minute quanta. - print TTL value in seconds not jiffies - change formatting to linux style in code the area affected. diff -Nru a/net/802/tr.c b/net/802/tr.c --- a/net/802/tr.c Wed Aug 20 17:01:05 2003 +++ b/net/802/tr.c Wed Aug 20 17:01:05 2003 @@ -67,8 +67,6 @@ static spinlock_t rif_lock = SPIN_LOCK_UNLOCKED; -#define RIF_TIMEOUT 60*10*HZ -#define RIF_CHECK_INTERVAL 60*HZ /* * Garbage disposal timer. @@ -76,7 +74,7 @@ static struct timer_list rif_timer; -int sysctl_tr_rif_timeout = RIF_TIMEOUT; +int sysctl_tr_rif_timeout = 60*10*HZ; static inline unsigned long rif_hash(const unsigned char *addr) { @@ -430,35 +428,33 @@ static void rif_check_expire(unsigned long dummy) { int i; - unsigned long now=jiffies; + unsigned long next_interval = jiffies + sysctl_tr_rif_timeout/2; spin_lock_bh(&rif_lock); - for(i=0; i < RIF_TABLE_SIZE;i++) - { - struct rif_cache_s *entry, **pentry=rif_table+i; - while((entry=*pentry)) - { - /* - * Out it goes - */ - if((now-entry->last_used) > sysctl_tr_rif_timeout) - { - *pentry=entry->next; + for(i =0; i < RIF_TABLE_SIZE; i++) { + struct rif_cache_s *entry, **pentry; + + pentry = rif_table+i; + while((entry=*pentry) != NULL) { + unsigned long expires + = entry->last_used + sysctl_tr_rif_timeout; + + if (time_before_eq(expires, jiffies)) { + *pentry = entry->next; kfree(entry); + } else { + pentry = &entry->next; + + if (time_before(expires, next_interval)) + next_interval = expires; } - else - pentry=&entry->next; } } spin_unlock_bh(&rif_lock); - /* - * Reset the timer - */ - - mod_timer(&rif_timer, jiffies+sysctl_tr_rif_timeout); + mod_timer(&rif_timer, next_interval); } @@ -533,12 +529,14 @@ "if TR address TTL rcf routing segments\n"); else { struct net_device *dev = dev_get_by_index(entry->iface); + long ttl = (long) (entry->last_used + sysctl_tr_rif_timeout) + - (long) jiffies; seq_printf(seq, "%s %02X:%02X:%02X:%02X:%02X:%02X %7li ", dev?dev->name:"?", entry->addr[0],entry->addr[1],entry->addr[2], entry->addr[3],entry->addr[4],entry->addr[5], - sysctl_tr_rif_timeout-(jiffies-entry->last_used)); + ttl/HZ); if (entry->local_ring) seq_puts(seq, "local\n"); @@ -594,7 +592,7 @@ static int __init rif_init(void) { init_timer(&rif_timer); - rif_timer.expires = RIF_TIMEOUT; + rif_timer.expires = sysctl_tr_rif_timeout; rif_timer.data = 0L; rif_timer.function = rif_check_expire; add_timer(&rif_timer); From shemminger@osdl.org Wed Aug 20 17:23:01 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 17:23:06 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7L0N1oO019705 for ; Wed, 20 Aug 2003 17:23:01 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7L0Meo20304; Wed, 20 Aug 2003 17:22:40 -0700 Date: Wed, 20 Aug 2003 17:22:27 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: linux-tr@linuxtr.net, netdev@oss.sgi.com Subject: [PATCH] (5/6) tr - fix the seq_file next operation Message-Id: <20030820172227.04cf127d.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5169 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1202 Lines: 50 Better version of my seq_file next operation. Use current pointer to find next element. Should be more stable with changing list (no duplicate entries). P.s: Tested this stuff on 2.6.0-test3 by creating a test stub to put random entries into the table; no real hardware was needed. diff -Nru a/net/802/tr.c b/net/802/tr.c --- a/net/802/tr.c Wed Aug 20 16:28:21 2003 +++ b/net/802/tr.c Wed Aug 20 16:28:21 2003 @@ -477,8 +477,8 @@ struct rif_cache_s *entry; loff_t off = 0; - for(i=0;i < RIF_TABLE_SIZE;i++) - for(entry=rif_table[i];entry;entry=entry->next) { + for(i = 0; i < RIF_TABLE_SIZE; i++) + for(entry = rif_table[i]; entry; entry = entry->next) { if (off == pos) return entry; ++off; @@ -496,7 +496,26 @@ static void *rif_seq_next(struct seq_file *seq, void *v, loff_t *pos) { - return rif_get_idx(*pos++); + int i; + struct rif_cache_s *ent = v; + + ++*pos; + + if (v == RIF_PROC_START) { + i = -1; + goto scan; + } + + if (ent->next) + return ent->next; + + i = rif_hash(ent->addr); + scan: + while (++i < RIF_TABLE_SIZE) { + if ((ent = rif_table[i]) != NULL) + return ent; + } + return NULL; } static void rif_seq_stop(struct seq_file *seq, void *v) From misiek@pld.ORG.PL Wed Aug 20 17:58:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 17:58:29 -0700 (PDT) Received: from maja.beep.pl (exim@maja.beep.pl [195.245.198.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7L0wMoO022153 for ; Wed, 20 Aug 2003 17:58:24 -0700 Received: from gucio-bb.sys.beep.pl ([195.245.198.12] helo=gucio.beep.pl) by maja.beep.pl with esmtp (Exim 4.22) id 19pdja-0002BA-Bx for netdev@oss.sgi.com; Thu, 21 Aug 2003 02:55:26 +0200 Received: from k83.ath.cx ([80.50.79.154] helo=192.168.0.134) by gucio.beep.pl with asmtp (TLSv1:RC4-MD5:128) (Exim 4.21) id 19pdmJ-0004nW-Kr for netdev@oss.sgi.com; Thu, 21 Aug 2003 02:58:16 +0200 From: Arkadiusz Miskiewicz Organization: SelfOrganizing To: netdev@oss.sgi.com Subject: 2.4.21+O(1) scheduler and eepro100 driver Date: Thu, 21 Aug 2003 02:55:50 +0200 User-Agent: KMail/1.5.3 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-2" Message-Id: <200308210255.50357.misiek@pld.ORG.PL> X-Authenticated-Id: arekm Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7L0wMoO022153 X-archive-position: 5170 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: misiek@pld.ORG.PL Precedence: bulk X-list: netdev Content-Length: 5401 Lines: 142 Hi, I'm having problems with my 2.4.21 SMP kernel patched to use O(1). It sometimes segfault somewhere in networking code. Note that this happens only when I have two processors in machine. Two days ago and before I had this SMP kernel on that machine (Intel SMRK2 server platform) but only one processor. Yesterday we added second CPU and such things started to happen. Three oopses so far in about 12 hours. [root@gucio root]# cat /proc/version Linux version 2.4.21 (builder@ep09) (gcc version 2.95.4 20010319 (prerelease)) #1 SMP Wed Aug 13 06:27:47 UTC 2003 [root@gucio root]# lsmod Module Size Used by Not tainted softdog 1732 1 cls_u32 5124 1 (autoclean) sch_htb 19328 1 (autoclean) sch_sfq 3680 3 (autoclean) iptable_filter 1792 1 (autoclean) ip_tables 12128 1 [iptable_filter] eepro100 18636 2 (autoclean) mii 2480 0 (autoclean) [eepro100] ext2 46176 1 (autoclean) usb-ohci 18528 0 (unused) usbcore 63776 1 (autoclean) [usb-ohci] unix 16516 30 (autoclean) reiserfs 191552 6 (autoclean) sd_mod 11040 22 (autoclean) aic7xxx 153708 11 (autoclean) scsi_mod 92784 2 (autoclean) [sd_mod aic7xxx] cpu: 0, clocks: 1330022, slice: 443340 cpu: 1, clocks: 1330022, slice: 443340 Unable to handle kernel NULL pointer dereference at virtual address 00000000 00000000 *pde = 10619067 Oops: 0000 CPU: 1 EIP: 0010:[<00000000>] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 00000000 ebx: 00000000 ecx: 00000000 edx: 000005b4 esi: 00000000 edi: 00000000 ebp: 00000000 esp: dc641e64 ds: 0018 es: 0018 ss: 0018 Process httpd (pid: 14357, stackpage=dc641000) Stack: 00000000 00000000 00000000 c021770b 00000000 000005b4 cc290910 d3772180 c01d7114 49064af1 cc290910 000005b4 00000000 dc641f08 00000000 cfabb580 dc641f80 dc641f48 d1fa54a4 d1d2f800 d1d2f800 d328e300 cfabb6bc cfabb5b8 Call Trace: [] [] [] [] [] [] [] [] Code: Bad EIP value. >>EIP; 00000000 Before first symbol >>esp; dc641e64 <___strtok+1c2eb1fc/204a9398> Trace; c021770b Trace; c01d7114 Trace; c01cea8a Trace; c01f4226 Trace; c01b1568 Trace; c01b1784 Trace; c013d3c6 Trace; c01089b3 <__read_lock_failed+10d7/148c> Unable to handle kernel paging request at virtual address 6f7020ea 6f7020ea *pde = 00000000 Oops: 0000 CPU: 1 EIP: 0010:[<6f7020ea>] Not tainted EFLAGS: 00010246 eax: 00000000 ebx: 6973206f ecx: 00000000 edx: 000005a8 esi: 75616e20 edi: 6e6f7a63 ebp: 79646767 esp: c6e79e64 ds: 0018 es: 0018 ss: 0018 Process httpd (pid: 5889, stackpage=c6e79000) Stack: 6b656c77 7020e661 6569776f c021770b 00000000 000005a8 c8a84910 c46330c0 c01d7114 01a3bb44 c8a84910 000005a8 00000000 c6e79f08 00000000 d95a8560 c6e79f80 c6e79f48 d6cf07a4 0000002b deafac20 00000070 d95a869c d95a8598 Call Trace: [] [] [] [] [] [] [] Code: Bad EIP value. >>EIP; 6f7020ea Before first symbol <===== >>esp; c6e79e64 <___strtok+6b231fc/204a9398> Trace; c021770b Trace; c01d7114 Trace; c01f4226 Trace; c01b1568 Trace; c01b1784 Trace; c013d3c6 Trace; c01089b3 <__read_lock_failed+10d7/148c> Unable to handle kernel paging request at virtual address 1a477479 1a477479 *pde = 00000000 Oops: 0000 CPU: 1 EIP: 0010:[<1a477479>] Not tainted EFLAGS: 00010246 eax: 00000000 ebx: a645b3b6 ecx: 00000000 edx: 000005a8 esi: da0b845d edi: fb15b864 ebp: b485ba05 esp: d6b31e64 ds: 0018 es: 0018 ss: 0018 Process httpd (pid: 29083, stackpage=d6b31000) Stack: 2b8fb8fb 30bb3cb0 e87f032f c021770b 00000000 000005a8 cc074110 d5ab1480 c01d7114 49d6cb64 cc074110 000005a8 00000000 d6b31f08 00000000 d38b8060 d6b31f80 d6b31f48 ddc5d604 dfc32818 00000000 dfcb6600 d38b819c d38b8098 Call Trace: [] [] [] [] [] [] [] [] Code: Bad EIP value. >>EIP; 1a477479 Before first symbol <===== >>esi; da0b845d <___strtok+19d617f5/204a9398> >>esp; d6b31e64 <___strtok+167db1fc/204a9398> Trace; c021770b Trace; c01d7114 Trace; e0807f6f <[scsi_mod]scsi_io_completion+1e7/3ec> Trace; c01f4226 Trace; c01b1568 Trace; c01b1784 Trace; c013d3c6 Trace; c01089b3 <__read_lock_failed+10d7/148c> If you need anything else let me known. Config is similar to this one: http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/kernel-ia32-smp.config?rev=1.37 -- Arkadiusz Mi¶kiewicz CS at FoE, Wroclaw University of Technology arekm.pld-linux.org AM2-6BONE, 1024/3DB19BBD, arekm(at)ircnet, PLD/Linux From hadi@cyberus.ca Wed Aug 20 18:54:05 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 18:54:15 -0700 (PDT) Received: from mail.cyberus.ca (mail.cyberus.ca [209.195.118.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7L1s4oO023889 for ; Wed, 20 Aug 2003 18:54:05 -0700 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.12) id 19pUo8-0000uN-00; Wed, 20 Aug 2003 11:23:32 -0400 Subject: RE: [2.4 PATCH] bugfix: ARP respond on all devices From: jamal Reply-To: hadi@cyberus.ca To: Richard Underwood Cc: "'David S. Miller'" , Alan Cox , skraw@ithnet.com, willy@w.ods.org, carlosev@newipnet.com, lamont@scriptkiddie.org, davidsen@tmr.com, bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com, linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org, linux-kernel@vger.kernel.org In-Reply-To: <353568DCBAE06148B70767C1B1A93E625EAB61@post.pc.aspectgroup.co.uk> References: <353568DCBAE06148B70767C1B1A93E625EAB61@post.pc.aspectgroup.co.uk> Content-Type: text/plain Organization: jamalopolis Message-Id: <1061393011.1029.51.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Aug 2003 11:23:31 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 5171 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 4376 Lines: 117 What Dave meant is the state machine used in 2461 for IPV6 is actually used in v4 as well. There is no equivalent RFC that is valid for IPv4. Maybe one can be written (fire! fire! where are the firemen?). for V6 (ndisc not ARP) check the validation tests the usagi people have been doing against 2461. cheers, jamal On Wed, 2003-08-20 at 04:58, Richard Underwood wrote: > David S. Miller wrote: > > > > Indeed, would people stop quoting from RFC 985 and > > RFC 826. > > In case anyone missed it, the following message was posted to > linux-net and netdev. This is currently a draft standard, but anyone > implementing IPv6 should be following it. It clearly states that the the > source address for the equivalent of the ARP request should be the INTERFACE > address. > > While it doesn't directly apply to IPv4 (except for David's claim > that IPv4 ARP is based on IPv6 ARP) it does clarify the situation nicely. > > I, for one, will be glad when (!) we all migrade to IPv6 and we can > once and all be done with this nonsense, unless Linux plans to deviate from > the standard? > > Thanks, > > Richard > > -----Original Message----- > From: Steven Blake [mailto:slblake@petri-meat.com] > Sent: 20 August 2003 05:58 > To: David S. Miller > Cc: netdev@oss.sgi.com; linux-net@vger.kernel.org > Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices > > > On Tue, 2003-08-19 at 13:53, David S. Miller wrote: > > > BTW, this ARP source address algorithm we use comes from > > ipv6, it would be instructive to go and see why they do > > things the way they do. > > Are you sure? See below: > > ======================================================================== > > RFC 2461 Neighbor Discovery for IPv6 December 1998 > > > 4.3. Neighbor Solicitation Message Format > > Nodes send Neighbor Solicitations to request the link-layer address > of a target node while also providing their own link-layer address to > the target. Neighbor Solicitations are multicast when the node needs > to resolve an address and unicast when the node seeks to verify the > reachability of a neighbor. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Code | Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Target Address + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Options ... > +-+-+-+-+-+-+-+-+-+-+-+- > > IP Fields: > > Source Address > Either an address assigned to the interface from > which this message is sent or (if Duplicate Address > Detection is in progress [ADDRCONF]) the > unspecified address. > > Destination Address > Either the solicited-node multicast address > corresponding to the target address, or the target > address. > > Hop Limit 255 > > Authentication Header > If a Security Association for the IP Authentication > Header exists between the sender and the > destination address, then the sender SHOULD include > this header. > > > > > > Narten, et. al. Standards Track [Page 21] > > ======================================================================== > > > Regards, > > // Steve > > From willy@www.linux.org.uk Wed Aug 20 20:19:42 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 20:19:48 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7L3JfoO028214 for ; Wed, 20 Aug 2003 20:19:42 -0700 Received: from willy by www.linux.org.uk with local (Exim 4.14) id 19pfz8-0000G7-Gn for netdev@oss.sgi.com; Thu, 21 Aug 2003 04:19:38 +0100 Date: Thu, 21 Aug 2003 04:19:38 +0100 From: Matthew Wilcox To: netdev@oss.sgi.com Subject: socket(7) error? Message-ID: <20030821031938.GA19630@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 5173 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@debian.org Precedence: bulk X-list: netdev Content-Length: 1238 Lines: 28 Hi. There's a bug report from Martin Pool against manpages-dev suggesting the following paragraph from socket(7) is incorrect: SO_RCVTIMEO and SO_SNDTIMEO Specify the sending or receiving timeouts until reporting an error. They are fixed to a protocol specific setting in Linux and cannot be read or written. Their functionality can be emu- lated using alarm(2) or setitimer(2). He says: In fact, these options do seem to be at least partially implemented in Linux 2.4.20. You can at least set and retrieve a value against a socket, and it does seem to affect the (complex) network scheduling code. I have not actually tested that they work as advertised, so it might be good to check with somebody who knows more about it. But the manpage does seem to be at least partially wrong. This is me checking with people who know more about it ;-) Let me know what to say and I'll send a patch to Andries. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From kennell@ecn.purdue.edu Wed Aug 20 21:38:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 20 Aug 2003 21:38:36 -0700 (PDT) Received: from dynamo.ecn.purdue.edu (dynamo.ecn.purdue.edu [128.46.200.24]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7L4cAoO030995 for ; Wed, 20 Aug 2003 21:38:11 -0700 Received: from k7.localnet (12-222-91-60.client.insightBB.com [12.222.91.60]) (authenticated bits=0) by dynamo.ecn.purdue.edu (8.12.9/8.12.9) with ESMTP id h7L4b7eL021066 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Aug 2003 23:37:07 -0500 (EST) Subject: Re: [OT] Connection tracking for IPSec From: Rick Kennell Reply-To: netdev@oss.sgi.com To: Andrew McGregor Cc: Felipe Alfaro Solana , LKML , netdev@oss.sgi.com In-Reply-To: <1710000.1061417560@ijir> References: <1061378568.668.9.camel@teapot.felipe-alfaro.com> <23600000.1061383792@ijir> <1061388988.3804.8.camel@teapot.felipe-alfaro.com> <1710000.1061417560@ijir> Content-Type: text/plain Organization: Purdue University School of Electrical and Computer Engineering Message-Id: <1061440621.16712.289.camel@k7.localnet> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Wed, 20 Aug 2003 23:37:01 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned-ECN: by AMaVIS version 11 (perl 5.8) (http://amavis.org/) X-archive-position: 5174 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kennell@ecn.purdue.edu Precedence: bulk X-list: netdev Content-Length: 2574 Lines: 51 On Wed, 2003-08-20 at 17:12, Andrew McGregor wrote: > --On Wednesday, August 20, 2003 04:16:28 PM +0200 Felipe Alfaro Solana > wrote: > > The problem here is that opening up protocols 50 and 51, makes *any* > > IPSec-protected traffic to pass the firewall, but I still want that any > > traffic (IPSec-protected or not) be applied the connection-track > > filters. For normal (no IPSec) traffic, an incoming packet is only > > accepted if it belongs to a connection that was initiated locally. For > > IPSec traffic, I just want the same. I don't want any kind of > > IPSec-protected traffic to be able to pass through the firewall, only > > traffic that belongs to a connection that was initiated locally on the > > machine receiving it. > > It doesn't make sense for this configuration to fail in this way, I agree. > > Essentially, the ESP and AH transforms should be a magic netfilter rule, so > you can insert them in a netfilter chain and do this sort of thing. If > they aren't, we should at least have the input and output chains traversed > by packets both before and after the transforms. I brought up the same thing in the netfilter and netfilter-dev lists last month. http://www.spinics.net/lists/netfilter/msg18030.html I think there's no need for a special netfilter rule if the assumption is made that an ESP packet reaching the "mangle" chain of the "INPUT" table is definitely destined for a local process. At that point, it should be automatically unencapsulated so that its true protocol and port numbers can be interrogated. e.g. if we know an ESP packet is for this machine, do the unencapsulation as early as possible. Since there's not yet a consensus on the behavior of things like NAT-based forwarding of IPsec packets I think this is a safe assumption. (But my opinion generally doesn't count for much.) If it's important to remember that the packet had been an ESP packet, netfilter can be set up to mark it as such in the PREROUTING mangle chain so that it can later be filtered appropriately. This seems similar to what I've read is done in FreeBSD: http://www.bsdforums.org/forums/showthread.php?threadid=11725 > The issue exists, I'm convinced. Dang, I'm going to run into it too one > day soon. Another thing that needs looking at, in case noone else fixes it > first. That's sort of what I thought too. And, yeah, I'd be real happy if someone else did it before I tried to. 8^) -- Rick Kennell Purdue University School of Electrical and Computer Engineering From scott.feldman@intel.com Thu Aug 21 00:18:07 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Aug 2003 00:18:10 -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 h7L7I6oO004044 for ; Thu, 21 Aug 2003 00:18:07 -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 h7L78vM11495 for ; Thu, 21 Aug 2003 07:08:58 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h7L2G9v22603 for ; Thu, 21 Aug 2003 02:16:09 GMT Received: from [134.134.3.171] ([134.134.3.171]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003082019234227209 for ; Wed, 20 Aug 2003 19:23:42 -0700 Date: Wed, 20 Aug 2003 19:44:33 -0700 (PDT) From: "Feldman, Scott" X-X-Sender: scott.feldman@localhost.localdomain Reply-To: "Feldman, Scott" To: netdev@oss.sgi.com Subject: e100 "Lucky 13" release Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5178 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 Content-Length: 3515 Lines: 122 More NAPI updates from jchapman@katalix.com. http://sf.net/projects/e1000, e100-3.0.0_dev13.tar.gz He's getting respectable NAPI perf numbers with this. Note the polling exit condition. -scott --- e100-3.0.0_dev12/src/e100.c 2003-08-04 20:20:42.000000000 -0700 +++ e100-3.0.0_dev13/src/e100.c 2003-08-20 18:28:56.000000000 -0700 @@ -150,11 +150,12 @@ #include #include #include +#include #include "kcompat.h" #define DRV_NAME "e100" -#define DRV_VERSION "3.0.0_dev12" +#define DRV_VERSION "3.0.0_dev13" #define DRV_DESCRIPTION "Intel(R) PRO/100 Network Driver" #define DRV_COPYRIGHT "Copyright(c) 1999-2003 Intel Corporation" #define PFX DRV_NAME ": " @@ -1171,7 +1172,7 @@ static void e100_watchdog(unsigned long mod_timer(&nic->watchdog, jiffies + 2 * HZ); } -static void e100_xmit_prepare(struct nic *nic, struct cb *cb, +static inline void e100_xmit_prepare(struct nic *nic, struct cb *cb, struct sk_buff *skb) { cb->command = nic->tx_command; @@ -1200,7 +1201,7 @@ static int e100_xmit_frame(struct sk_buf return 0; } -static inline void e100_tx_clean(struct nic *nic) +static inline int e100_tx_clean(struct nic *nic) { struct cb *cb; int tx_cleaned = 0; @@ -1234,6 +1235,8 @@ static inline void e100_tx_clean(struct /* Recover from running out of Tx resources in xmit_frame */ if(unlikely(tx_cleaned && netif_queue_stopped(nic->netdev))) netif_wake_queue(nic->netdev); + + return tx_cleaned; } static void e100_clean_cbs(struct nic *nic, int free_mem) @@ -1334,9 +1337,9 @@ static inline void e100_rx_rfa_add_tail( struct rx_list *prev = (struct rx_list *)curr->list.prev; if(likely(prev->skb != NULL)) { struct rfd *prev_rfd = (struct rfd *)prev->skb->data; - prev_rfd->command = 0; put_unaligned(cpu_to_le32(curr->dma_addr), (u32 *)&prev_rfd->link); + prev_rfd->command = 0; pci_dma_sync_single(nic->pdev, prev->dma_addr, sizeof(struct rfd), PCI_DMA_TODEVICE); } @@ -1384,7 +1387,7 @@ static inline int e100_rx_indicate(struc if(unlikely(!(rfd_status & cb_ok)) || actual_size > nic->netdev->mtu + VLAN_ETH_HLEN) { /* Don't indicate if errors */ - dev_kfree_skb_irq(skb); + dev_kfree_skb_any(skb); } else { nic->net_stats.rx_packets++; nic->net_stats.rx_bytes += actual_size; @@ -1494,14 +1497,12 @@ static irqreturn_t e100_intr(int irq, vo e100_write_flush(nic); #ifdef CONFIG_E100_NAPI - if(likely(netif_rx_schedule_prep(netdev))) { - e100_disable_irq(nic); - __netif_rx_schedule(netdev); - } + e100_disable_irq(nic); + netif_rx_schedule(netdev); #else - if(likely(stat_ack & stat_ack_rx)) + if(stat_ack & stat_ack_rx) e100_rx_clean(nic, NULL, 0); - if(likely(stat_ack & stat_ack_tx)) + if(stat_ack & stat_ack_tx) e100_tx_clean(nic); #endif @@ -1514,19 +1515,21 @@ static int e100_poll(struct net_device * struct nic *nic = netdev->priv; unsigned int work_to_do = min(netdev->quota, *budget); unsigned int work_done = 0; + int tx_cleaned; e100_rx_clean(nic, &work_done, work_to_do); - e100_tx_clean(nic); + tx_cleaned = e100_tx_clean(nic); - *budget -= work_done; - netdev->quota -= work_done; - - if(likely(work_done < work_to_do)) { + /* If no Rx and Tx cleanup work was done, exit polling mode. */ + if(!tx_cleaned && (work_done == 0)) { netif_rx_complete(netdev); e100_enable_irq(nic); return 0; } + *budget -= work_done; + netdev->quota -= work_done; + return 1; } #endif From ak@suse.de Thu Aug 21 04:13:01 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Aug 2003 04:13:07 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7LBCnoO016827 for ; Thu, 21 Aug 2003 04:12:50 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id EBE218DA4D; Thu, 21 Aug 2003 12:42:44 +0200 (CEST) Date: Thu, 21 Aug 2003 12:42:44 +0200 From: Andi Kleen To: Matthew Wilcox Cc: netdev@oss.sgi.com Subject: Re: socket(7) error? Message-ID: <20030821104244.GC28496@wotan.suse.de> References: <20030821031938.GA19630@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030821031938.GA19630@parcelfarce.linux.theplanet.co.uk> X-archive-position: 5179 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 893 Lines: 23 On Thu, Aug 21, 2003 at 04:19:38AM +0100, Matthew Wilcox wrote: > > Hi. There's a bug report from Martin Pool against manpages-dev suggesting > the following paragraph from socket(7) is incorrect: > > SO_RCVTIMEO and SO_SNDTIMEO > Specify the sending or receiving timeouts until reporting an > error. They are fixed to a protocol specific setting in Linux > and cannot be read or written. Their functionality can be emu- > lated using alarm(2) or setitimer(2). > > He says: > > In fact, these options do seem to be at least partially implemented > in Linux 2.4.20. You can at least set and retrieve a value against > a socket, and it does seem to affect the (complex) network scheduling > code. It was correct when the manpage was written, but wasn't updated later when option was implemented. -Andi From vinay-rc@naturesoft.net Thu Aug 21 07:53:13 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Aug 2003 07:53:18 -0700 (PDT) Received: from naturesoft.net ([203.145.184.221]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7LEr8oO006885 for ; Thu, 21 Aug 2003 07:53:10 -0700 Received: from [192.168.0.15] (helo=lima.royalchallenge.com) by naturesoft.net with esmtp (Exim 3.35 #1) id 19pqip-0006qh-00; Thu, 21 Aug 2003 20:17:31 +0530 Subject: [PATCH 2.6.0-test3-bk8][ATM] fix ambassador.c From: Vinay K Nallamothu To: linux-atm-general@lists.sourceforge.net, netdev@oss.sgi.com Cc: Kernel List Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 21 Aug 2003 20:45:05 +0530 Message-Id: <1061478906.1069.23.camel@lima.royalchallenge.com> Mime-Version: 1.0 X-archive-position: 5180 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vinay-rc@naturesoft.net Precedence: bulk X-list: netdev Hi, drivers/atm/ambassador.c: This patch cleans up sti/cli usage as well as minor timer cleanups. ambassador.c | 34 ++++++++++++++-------------------- 1 files changed, 14 insertions(+), 20 deletions(-) diff -urN linux-2.6.0-test3-bk8/drivers/atm/ambassador.c linux-2.6.0-test3-nvk/drivers/atm/ambassador.c --- linux-2.6.0-test3-bk8/drivers/atm/ambassador.c 2003-08-21 20:21:53.000000000 +0530 +++ linux-2.6.0-test3-nvk/drivers/atm/ambassador.c 2003-08-21 20:04:04.000000000 +0530 @@ -310,10 +310,12 @@ 0xdeadbeef }; +static void do_housekeeping (unsigned long arg); /********** globals **********/ + static amb_dev * amb_devs = NULL; -static struct timer_list housekeeping; +static struct timer_list housekeeping = TIMER_INITIALIZER(do_housekeeping, 0, 1); static unsigned short debug = 0; static unsigned int cmds = 8; @@ -952,8 +954,9 @@ rx_in * rx; unsigned long flags; - save_flags (flags); - cli(); + + txq = &dev->txq; + spin_lock_irqsave(&txq->lock, flags); PRINTK (KERN_INFO, "don't panic - putting adapter into reset"); wr_plain (dev, offsetof(amb_mem, reset_control), @@ -964,7 +967,7 @@ cmd->request = cpu_to_be32 (SRB_COMPLETE); PRINTK (KERN_INFO, "completing all TXs"); - txq = &dev->txq; + tx = txq->in.ptr; while (txq->pending--) { if (tx == txq->in.start) @@ -978,6 +981,7 @@ PRINTK (KERN_INFO, "freeing all RX buffers"); for (pool = 0; pool < NUM_RX_POOLS; ++pool) { rxq = &dev->rxq[pool]; + spin_lock(&rxq->lock); rx = rxq->in.ptr; while (rxq->pending--) { if (rx == rxq->in.start) @@ -985,11 +989,12 @@ --rx; dev_kfree_skb_any (bus_to_virt (rx->handle)); } + spin_unlock(&rxq->lock); } PRINTK (KERN_INFO, "don't panic over - close all VCs and rmmod"); set_bit (dead, &dev->flags); - restore_flags (flags); + spin_unlock_irqrestore(&txq->lock, flags); return; } #endif @@ -1671,13 +1676,6 @@ }; /********** housekeeping **********/ - -static inline void set_timer (struct timer_list * timer, unsigned long delay) { - timer->expires = jiffies + delay; - add_timer (timer); - return; -} - static void do_housekeeping (unsigned long arg) { amb_dev * dev = amb_devs; // data is set to zero at module unload @@ -1693,7 +1691,7 @@ dev = dev->prev; } - set_timer (&housekeeping, 10*HZ); + mod_timer(&housekeeping, jiffies + 10*HZ); } return; @@ -2559,7 +2557,7 @@ /********** module entry **********/ -static int __init amb_module_init (void) { +static int __devinit amb_module_init (void) { int devs; PRINTD (DBG_FLOW|DBG_INIT, "init_module"); @@ -2579,11 +2577,7 @@ devs = amb_probe(); if (devs) { - init_timer (&housekeeping); - housekeeping.function = do_housekeeping; - // paranoia - housekeeping.data = 1; - set_timer (&housekeeping, 0); + mod_timer (&housekeeping, jiffies); } else { PRINTK (KERN_INFO, "no (usable) adapters found"); } @@ -2593,7 +2587,7 @@ /********** module exit **********/ -static void __exit amb_module_exit (void) { +static void __devexit amb_module_exit (void) { amb_dev * dev; PRINTD (DBG_FLOW|DBG_INIT, "cleanup_module"); From romieu@fr.zoreil.com Thu Aug 21 10:38:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Aug 2003 10:38:50 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7LHcgoO013450 for ; Thu, 21 Aug 2003 10:38:44 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id h7LHVnxA018948; Thu, 21 Aug 2003 19:31:49 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id h7LHVntZ018947; Thu, 21 Aug 2003 19:31:49 +0200 Date: Thu, 21 Aug 2003 19:31:49 +0200 From: Francois Romieu To: Vinay K Nallamothu Cc: linux-atm-general@lists.sourceforge.net, netdev@oss.sgi.com, Kernel List Subject: Re: [PATCH 2.6.0-test3-bk8][ATM] fix ambassador.c Message-ID: <20030821193149.A18920@electric-eye.fr.zoreil.com> References: <1061478906.1069.23.camel@lima.royalchallenge.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1061478906.1069.23.camel@lima.royalchallenge.com>; from vinay-rc@naturesoft.net on Thu, Aug 21, 2003 at 08:45:05PM +0530 X-archive-position: 5181 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Vinay K Nallamothu : [...] > drivers/atm/ambassador.c: > This patch cleans up sti/cli usage as well as minor timer cleanups. [...] The "dont_panic" function which uses cli/sti is only called from code belonging to a "#if 0" section since revision 1.1 according to bk. Remove it, everybody should feel better. -- Ueimor From davem@redhat.com Thu Aug 21 12:25:55 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Aug 2003 12:25:57 -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 h7LJPsoO017721 for ; Thu, 21 Aug 2003 12:25:55 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id MAA30599; Thu, 21 Aug 2003 12:18:33 -0700 Date: Thu, 21 Aug 2003 12:18:32 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: linux-tr@linuxtr.net, netdev@oss.sgi.com Subject: Re: [PATCH] (6/6) tr - expire timer improvements Message-Id: <20030821121832.60cee81f.davem@redhat.com> In-Reply-To: <20030820171922.1af68a7c.shemminger@osdl.org> References: <20030820171922.1af68a7c.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5183 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 All 6 patches applied, thanks Stephen. From davem@redhat.com Thu Aug 21 12:25:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Aug 2003 12:25:38 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7LJPWoO017667 for ; Thu, 21 Aug 2003 12:25:33 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id MAA30588; Thu, 21 Aug 2003 12:18:11 -0700 Date: Thu, 21 Aug 2003 12:18:10 -0700 From: "David S. Miller" To: Jeroen Vreeken Cc: shemminger@osdl.org, linux-hams@vger.kernel.org, ralf@linux-mips.org, netdev@oss.sgi.com Subject: Re: [PATCH] ax25 changes Message-Id: <20030821121810.308f90cc.davem@redhat.com> In-Reply-To: <20030820204518.C5568@jeroen.pe1rxq.ampr.org> References: <20030812194653.A28977@jeroen.pe1rxq.ampr.org> <20030812135655.7334887b.shemminger@osdl.org> <20030812230951.E28977@jeroen.pe1rxq.ampr.org> <20030812153901.6e700dcb.shemminger@osdl.org> <20030813010301.K28977@jeroen.pe1rxq.ampr.org> <20030812172151.7de0c950.shemminger@osdl.org> <20030813031159.6c6c9629.davem@redhat.com> <20030813173446.A2604@jeroen.pe1rxq.ampr.org> <20030813084252.7b667fb8.davem@redhat.com> <20030820204518.C5568@jeroen.pe1rxq.ampr.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5182 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 20 Aug 2003 20:45:18 +0200 Jeroen Vreeken wrote: > Fortunatly Stephen already reduced the amount of work by doing the netrom > stuff. > The next four patches are the remaining ax25 (and a litle netrom) patches: Applied, thanks Jeroen. From misiek@pld.ORG.PL Thu Aug 21 12:55:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Aug 2003 12:56:03 -0700 (PDT) Received: from maja.beep.pl (maja.beep.pl [195.245.198.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7LJtpoO021030 for ; Thu, 21 Aug 2003 12:55:53 -0700 Received: from gucio-bb.sys.beep.pl ([195.245.198.12] helo=gucio.beep.pl) by maja.beep.pl with esmtp (Exim 4.22) id 19pvU4-0007t2-Bp for netdev@oss.sgi.com; Thu, 21 Aug 2003 21:52:36 +0200 Received: from k83.ath.cx ([80.50.56.11] helo=arm.k83.ath.cx) by gucio.beep.pl with asmtp (TLSv1:RC4-MD5:128) (Exim 4.21) id 19pvWl-0004bS-B4 for netdev@oss.sgi.com; Thu, 21 Aug 2003 21:55:25 +0200 From: Arkadiusz Miskiewicz Organization: SelfOrganizing To: netdev@oss.sgi.com Subject: Re: 2.4.21+O(1) scheduler and eepro100 driver Date: Thu, 21 Aug 2003 21:53:23 +0200 User-Agent: KMail/1.5.3 References: <200308210255.50357.misiek@pld.ORG.PL> In-Reply-To: <200308210255.50357.misiek@pld.ORG.PL> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Disposition: inline Message-Id: <200308212153.23487.misiek@pld.ORG.PL> X-Authenticated-Id: arekm Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7LJtpoO021030 X-archive-position: 5184 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: misiek@pld.ORG.PL Precedence: bulk X-list: netdev > I'm having problems with my 2.4.21 SMP kernel patched to use O(1). It > sometimes segfault somewhere in networking code. And more: Unable to handle kernel NULL pointer dereference at virtual address 00000000 00f8989b *pde = 069eb067 Oops: 0002 CPU: 1 EIP: 0010:[<00f8989b>] Not tainted EFLAGS: 00010246 eax: 00000000 ebx: 8e0a0ccc ecx: 00000000 edx: 000005a8 esi: ea000030 edi: 78c0d089 ebp: e0988986 esp: db905e64 ds: 0018 es: 0018 ss: 0018 Process httpd (pid: 17881, stackpage=db905000) Stack: c2e02089 10371983 99501823 c021770b 00000000 000005a8 c2026910 c662c7a0 c01d7114 01cddbb6 c2026910 000005a8 00000000 db905f08 00000000 cf5db060 db905f80 db905f48 da2bc484 df212920 df212920 c78cc2e0 cf5db19c cf5db098 Call Trace: [] [] [] [] [] [] [] [] Code: Bad EIP value. >>EIP; 00f8989b Before first symbol <===== >>ebp; e0988986 <[unix].bss.end+5c903/100f7d> >>esp; db905e64 <___strtok+1b5af1fc/204a9398> Trace; c021770b Trace; c01d7114 Trace; c01cea8a Trace; c01f4226 Trace; c01b1568 Trace; c01b1784 Trace; c013d3c6 Trace; c01089b3 <__read_lock_failed+10d7/148c> <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000 00f8989b *pde = 17a10067 Oops: 0002 CPU: 0 EIP: 0010:[<00f8989b>] Not tainted EFLAGS: 00010246 eax: 00000000 ebx: 8e0a0ccc ecx: 00000000 edx: 000005b4 esi: ea000030 edi: 78c0d089 ebp: e0988986 esp: d24d5e64 ds: 0018 es: 0018 ss: 0018 Process httpd (pid: 18026, stackpage=d24d5000) Stack: c2e02089 10371983 99501823 c021770b 00000000 000005b4 d53c5910 dc8d6160 c01d7114 01d94ab3 d53c5910 000005b4 00000000 d24d5f08 00000000 c32d1560 d24d5f80 d24d5f48 c8bb95a4 dfc56380 dfc61e10 41c66200 c32d169c c32d1598 Call Trace: [] [] [] [] [] [] [] Code: Bad EIP value. >>EIP; 00f8989b Before first symbol <===== >>ebp; e0988986 <[unix].bss.end+5c903/100f7d> >>esp; d24d5e64 <___strtok+1217f1fc/204a9398> Trace; c021770b Trace; c01d7114 Trace; c01f4226 Trace; c01b1568 Trace; c01b1784 Trace; c013d3c6 Trace; c01089b3 <__read_lock_failed+10d7/148c> Unable to handle kernel paging request at virtual address ba3716b7 ba3716b7 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] Not tainted EFLAGS: 00010246 eax: 00000000 ebx: 19a19088 ecx: 00000000 edx: 00000200 esi: 37399c21 edi: 7c7a3714 ebp: f0183718 esp: dc277e64 ds: 0018 es: 0018 ss: 0018 Process httpd (pid: 17539, stackpage=dc277000) Stack: 83d73a93 f97674bd 49df1a39 c021770b 00000000 00000200 c8a79910 d1d2fa40 c01d7114 01cc7f3e c8a79910 00000200 00000000 dc277f08 00000000 d619baa0 dc277f80 dc277f48 d3d1d8c4 c02b9118 dc276000 00000004 d619bbdc d619bad8 Call Trace: [] [] [] [] [] [] [] Code: Bad EIP value. >>EIP; ba3716b7 Before first symbol <===== >>esp; dc277e64 <___strtok+1bf211fc/204a9398> Trace; c021770b Trace; c01d7114 Trace; c01f4226 Trace; c01b1568 Trace; c01b1784 Trace; c013d3c6 Trace; c01089b3 <__read_lock_failed+10d7/148c> <1>Unable to handle kernel paging request at virtual address 20202020 20202020 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[<20202020>] Not tainted EFLAGS: 00010246 eax: 00000000 ebx: 200a0d29 ecx: 00000000 edx: 000005a8 esi: 74417261 edi: 736f7028 ebp: 68632e65 esp: cf58be64 ds: 0018 es: 0018 ss: 0018 Process httpd (pid: 17583, stackpage=cf58b000) Stack: 61747320 20737574 7874203d c021770b 00000000 000005a8 c6231910 d9886900 c01d7114 02273e70 c6231910 000005a8 00000000 cf58bf08 00000000 d2de2a80 cf58bf80 cf58bf48 cdf5caa4 0000002b deafac20 00000070 d2de2bbc d2de2ab8 Call Trace: [] [] [] [] [] [] [] Code: Bad EIP value. >>EIP; 20202020 Before first symbol <===== >>esp; cf58be64 <___strtok+f2351fc/204a9398> Trace; c021770b Trace; c01d7114 Trace; c01f4226 Trace; c01b1568 Trace; c01b1784 Trace; c013d3c6 Trace; c01089b3 <__read_lock_failed+10d7/148c> Unable to handle kernel NULL pointer dereference at virtual address 00000000 09050688 *pde = 09ea5067 Oops: 0002 CPU: 1 EIP: 0010:[<09050688>] Not tainted EFLAGS: 00010246 eax: 00000000 ebx: 06882036 ecx: 00000000 edx: 000005b4 esi: 0b050688 edi: 68bf1c00 ebp: 203678b5 esp: dccf3e64 ds: 0018 es: 0018 ss: 0018 Process httpd (pid: 14769, stackpage=dccf3000) Stack: 98aa1c00 06882036 1c000a05 c021770b 00000000 000005b4 c3700910 dd307c80 c01d7114 49d6cc5f c3700910 000005b4 00000000 dccf3f08 00000000 d3595060 dccf3f80 dccf3f48 cd0aeee4 dfc32818 00000000 dfcb6600 d359519c d3595098 Call Trace: [] [] [] [] [] [] [] [] Code: Bad EIP value. >>EIP; 09050688 Before first symbol <===== >>esp; dccf3e64 <___strtok+1c99d1fc/204a9398> Trace; c021770b Trace; c01d7114 Trace; e0807f6f <[scsi_mod]scsi_io_completion+1e7/3ec> Trace; c01f4226 Trace; c01b1568 Trace; c01b1784 Trace; c013d3c6 Trace; c01089b3 <__read_lock_failed+10d7/148c> Unable to handle kernel paging request at virtual address 20202020 20202020 *pde = 00000000 Oops: 0000 CPU: 1 EIP: 0010:[<20202020>] Not tainted EFLAGS: 00010246 eax: 00000000 ebx: 20202020 ecx: 00000000 edx: 000005b4 esi: 2f3c3b70 edi: 0a0d3e70 ebp: 73626e26 esp: d002be64 ds: 0018 es: 0018 ss: 0018 Process httpd (pid: 7744, stackpage=d002b000) Stack: 703c2020 6d693c3e 72732067 c021770b 00000000 000005b4 dcb77910 d22aa3c0 c01d7114 01bb5b81 dcb77910 000005b4 00000000 d002bf08 00000000 ddd26040 d002bf80 d002bf48 d6a665e4 c02b9ad8 d002a000 d6a664c0 ddd2617c ddd26078 Call Trace: [] [] [] [] [] [] [] Code: Bad EIP value. >>EIP; 20202020 Before first symbol <===== >>esp; d002be64 <___strtok+fcd51fc/204a9398> Trace; c021770b Trace; c01d7114 Trace; c01f4226 Trace; c01b1568 Trace; c01b1784 Trace; c013d3c6 Trace; c01089b3 <__read_lock_failed+10d7/148c> dmesg: Linux version 2.4.21 (builder@ep09) (gcc version 2.95.4 20010319 (prerelease)) #1 SMP Wed Aug 13 06:27:47 UTC 2003 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009f800 (usable) BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000001ffd0000 (usable) BIOS-e820: 000000001ffd0000 - 000000001ffff000 (ACPI data) BIOS-e820: 000000001ffff000 - 0000000020000000 (ACPI NVS) BIOS-e820: 00000000fec00000 - 00000000fec02000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved) 0MB HIGHMEM available. 511MB LOWMEM available. found SMP MP-table at 000ff780 hm, page 000ff000 reserved twice. hm, page 00100000 reserved twice. hm, page 000f1000 reserved twice. hm, page 000f2000 reserved twice. On node 0 totalpages: 131024 zone(0): 4096 pages. zone(1): 126928 pages. zone(2): 0 pages. Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: INTEL Product ID: CNB30LE APIC at: 0xFEE00000 Processor #0 Pentium(tm) Pro APIC version 17 Processor #1 Pentium(tm) Pro APIC version 17 I/O APIC #4 Version 17 at 0xFEC00000. I/O APIC #5 Version 17 at 0xFEC01000. Enabling APIC mode: Flat. Using 2 I/O APICs Processors: 2 Kernel command line: BOOT_IMAGE=pld-2.4.21-1.6s ro root=803 console=tty0 console=ttyS0,9600n81 Initializing CPU#0 Detected 931.030 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1854.66 BogoMIPS Memory: 514856k/524096k available (1133k kernel code, 8852k reserved, 479k data, 116k init, 0k highmem) Dentry cache hash table entries: 65536 (order: 7, 524288 bytes) Inode cache hash table entries: 32768 (order: 6, 262144 bytes) Mount cache hash table entries: 512 (order: 0, 4096 bytes) Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes) Page-cache hash table entries: 131072 (order: 7, 524288 bytes) CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K CPU serial number disabled. Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After generic, caps: 0383fbff 00000000 00000000 00000000 CPU: Common caps: 0383fbff 00000000 00000000 00000000 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au) mtrr: detected mtrr type: Intel CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check reporting enabled on CPU#0. CPU: After generic, caps: 0383fbff 00000000 00000000 00000000 CPU: Common caps: 0383fbff 00000000 00000000 00000000 CPU0: Intel Pentium III (Coppermine) stepping 06 per-CPU timeslice cutoff: 731.28 usecs. task migration cache decay timeout: 10 msecs. enabled ExtINT on CPU#0 ESR value before enabling vector: 00000004 ESR value after enabling vector: 00000000 Booting processor 1/1 eip 2000 Initializing CPU#1 masked ExtINT on CPU#1 ESR value before enabling vector: 00000000 ESR value after enabling vector: 00000000 Calibrating delay loop... 1861.22 BogoMIPS CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K CPU serial number disabled. Intel machine check reporting enabled on CPU#1. CPU: After generic, caps: 0383fbff 00000000 00000000 00000000 CPU: Common caps: 0383fbff 00000000 00000000 00000000 CPU1: Intel Pentium III (Coppermine) stepping 06 Total of 2 processors activated (3715.89 BogoMIPS). ENABLING IO-APIC IRQs Setting 4 in the phys_id_present_map ...changing IO-APIC physical APIC ID to 4 ... ok. Setting 5 in the phys_id_present_map ...changing IO-APIC physical APIC ID to 5 ... ok. init IO_APIC IRQs IO-APIC (apicid-pin) 4-0, 4-3, 4-5, 4-9, 4-11, 5-2, 5-3, 5-4, 5-5, 5-6, 5-10, 5-11, 5-12, 5-13, 5-14, 5-15 not connected. ..TIMER: vector=0x31 pin1=2 pin2=0 ..MP-BIOS bug: 8254 timer not connected to IO-APIC ...trying to set up timer (IRQ0) through the 8259A ... ..... (found pin 0) ...works. number of MP IRQ sources: 17. number of IO-APIC #4 registers: 16. number of IO-APIC #5 registers: 16. testing the IO APIC....................... IO APIC #4...... .... register #00: 04000000 ....... : physical APIC id: 04 ....... : Delivery Type: 0 ....... : LTS : 0 .... register #01: 000F0011 ....... : max redirection entries: 000F ....... : PRQ implemented: 0 ....... : IO APIC version: 0011 .... register #02: 00000000 ....... : arbitration: 00 .... IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 003 03 0 0 0 0 0 1 1 31 01 003 03 0 0 0 0 0 1 1 39 02 000 00 1 0 0 0 0 0 0 00 03 000 00 1 0 0 0 0 0 0 00 04 003 03 0 0 0 0 0 1 1 41 05 000 00 1 0 0 0 0 0 0 00 06 003 03 0 0 0 0 0 1 1 49 07 003 03 0 0 0 0 0 1 1 51 08 003 03 0 0 0 0 0 1 1 59 09 000 00 1 0 0 0 0 0 0 00 0a 003 03 1 1 0 1 0 1 1 61 0b 000 00 1 0 0 0 0 0 0 00 0c 003 03 0 0 0 0 0 1 1 69 0d 003 03 0 0 0 0 0 1 1 71 0e 003 03 0 0 0 0 0 1 1 79 0f 003 03 0 0 0 0 0 1 1 81 IO APIC #5...... .... register #00: 05000000 ....... : physical APIC id: 05 ....... : Delivery Type: 0 ....... : LTS : 0 .... register #01: 000F0011 ....... : max redirection entries: 000F ....... : PRQ implemented: 0 ....... : IO APIC version: 0011 .... register #02: 06000000 ....... : arbitration: 06 .... IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 003 03 1 1 0 1 0 1 1 89 01 003 03 1 1 0 1 0 1 1 91 02 000 00 1 0 0 0 0 0 0 00 03 000 00 1 0 0 0 0 0 0 00 04 000 00 1 0 0 0 0 0 0 00 05 000 00 1 0 0 0 0 0 0 00 06 000 00 1 0 0 0 0 0 0 00 07 003 03 1 1 0 1 0 1 1 99 08 003 03 1 1 0 1 0 1 1 A1 09 003 03 1 1 0 1 0 1 1 A9 0a 000 00 1 0 0 0 0 0 0 00 0b 000 00 1 0 0 0 0 0 0 00 0c 000 00 1 0 0 0 0 0 0 00 0d 000 00 1 0 0 0 0 0 0 00 0e 000 00 1 0 0 0 0 0 0 00 0f 000 00 1 0 0 0 0 0 0 00 IRQ to pin mappings: IRQ0 -> 0:0 IRQ1 -> 0:1 IRQ4 -> 0:4 IRQ6 -> 0:6 IRQ7 -> 0:7 IRQ8 -> 0:8 IRQ10 -> 0:10 IRQ12 -> 0:12 IRQ13 -> 0:13 IRQ14 -> 0:14 IRQ15 -> 0:15 IRQ16 -> 1:0 IRQ17 -> 1:1 IRQ23 -> 1:7 IRQ24 -> 1:8 IRQ25 -> 1:9 .................................... done. Using local APIC timer interrupts. calibrating APIC timer ... ..... CPU clock speed is 931.0161 MHz. ..... host bus clock speed is 133.0022 MHz. cpu: 0, clocks: 1330022, slice: 443340 CPU0 cpu: 1, clocks: 1330022, slice: 443340 CPU1 checking TSC synchronization across CPUs: passed. migration_task 0 on cpu=0 migration_task 1 on cpu=1 PCI: PCI BIOS revision 2.10 entry at 0xfda65, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Discovered primary peer bus 01 [IRQ] PCI->APIC IRQ transform: (B0,I4,P0) -> 23 PCI->APIC IRQ transform: (B0,I7,P0) -> 17 PCI->APIC IRQ transform: (B0,I8,P0) -> 16 PCI->APIC IRQ transform: (B0,I15,P0) -> 10 PCI->APIC IRQ transform: (B1,I4,P0) -> 24 PCI->APIC IRQ transform: (B1,I4,P1) -> 25 Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd kinoded started VFS: Disk quotas vdquot_6.5.1 devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au) devfs: boot_options: 0x0 ACPI-0107: *** Error: Acpi_load_tables: Could not load namespace: AE_NOT_FOUND ACPI-0116: *** Error: Acpi_load_tables: Could not load tables: AE_NOT_FOUND ACPI: System description table load failed Detected PS/2 Mouse Port. pty: 512 Unix98 ptys configured keyboard: Timeout - AT keyboard not present?(ed) keyboard: Timeout - AT keyboard not present?(f4) Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A NET4: Frame Diverter 0.46 RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize IEEE 802.2 LLC for Linux 2.1 (c) 1996 Tim Alpaerts NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 4096 buckets, 32Kbytes TCP: Hash tables configured (established 32768 bind 32768) Linux IP multicast router 0.06 plus PIM-SM Measuring network checksumming speed basic : 441.600 MB/sec simple : 217.600 MB/sec func 3Dnow! skipped: not supported by CPU func AMD MMX skipped: not supported by CPU SSE1+ : 1056.000 MB/sec csum: using csum function: SSE1+ basic : 140.800 MB/sec simple : 128.000 MB/sec func AND MMX skipped: not supported by CPU SSE1+ : 332.800 MB/sec SSE1 : 339.200 MB/sec csum: using csum_copy function: SSE1 RAMDISK: Compressed image found at block 0 Freeing initrd memory: 248k freed VFS: Mounted root (romfs filesystem) readonly. SCSI subsystem driver Revision: 1.00 scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36 aic7899: Ultra160 Wide Channel A, SCSI Id=11, 32/253 SCBs scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36 aic7899: Ultra160 Wide Channel B, SCSI Id=12, 32/253 SCBs blk: queue dfc39e18, I/O limit 4095Mb (mask 0xffffffff) (scsi1:A:0): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit) (scsi1:A:1): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit) Vendor: IBM Model: DDYS-T36950M Rev: S9YB Type: Direct-Access ANSI SCSI revision: 03 blk: queue dfc32818, I/O limit 4095Mb (mask 0xffffffff) Vendor: SEAGATE Model: ST336732LC Rev: 0022 Type: Direct-Access ANSI SCSI revision: 03 blk: queue dfc32418, I/O limit 4095Mb (mask 0xffffffff) Vendor: ESG-SHV Model: SCA HSBP M14 Rev: 0.01 Type: Processor ANSI SCSI revision: 02 blk: queue dfc2b218, I/O limit 4095Mb (mask 0xffffffff) scsi1:A:0:0: Tagged Queuing enabled. Depth 253 scsi1:A:1:0: Tagged Queuing enabled. Depth 253 Attached scsi disk sda at scsi1, channel 0, id 0, lun 0 Attached scsi disk sdb at scsi1, channel 0, id 1, lun 0 SCSI device sda: 71687340 512-byte hdwr sectors (36704 MB) Partition check: /dev/scsi/host1/bus0/target0/lun0: p1 p2 p3 p4 < p5 p6 p7 p8 p9 > SCSI device sdb: 71687369 512-byte hdwr sectors (36704 MB) /dev/scsi/host1/bus0/target1/lun0: p1 reiserfs: found format "3.5" with standard journal reiserfs: using ordered data mode reiserfs: checking transaction log (device sd(8,3)) ... for (sd(8,3)) Using r5 hash to sort names VFS: Mounted root (reiserfs filesystem) readonly. Trying to move old root to /initrd ... okay Freeing unused kernel memory: 116k freed -- Arkadiusz Mi¶kiewicz CS at FoE, Wroclaw University of Technology arekm.pld-linux.org AM2-6BONE, 1024/3DB19BBD, arekm(at)ircnet, PLD/Linux From mszeredi@inf.bme.hu Thu Aug 21 13:25:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Aug 2003 13:25:32 -0700 (PDT) Received: from kempelen.iit.bme.hu (kempelen.iit.bme.hu [152.66.241.120]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7LKPQoO022710 for ; Thu, 21 Aug 2003 13:25:27 -0700 Received: (from mszeredi@localhost) by kempelen.iit.bme.hu (8.11.7+Sun/8.11.6) id h7LKPQ225880; Thu, 21 Aug 2003 22:25:26 +0200 (MET DST) Date: Thu, 21 Aug 2003 22:25:26 +0200 (MET DST) Message-Id: <200308212025.h7LKPQ225880@kempelen.iit.bme.hu> From: Szeredi Miklos To: netdev@oss.sgi.com Subject: Wake on Lan with epic100 X-archive-position: 5185 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mszeredi@inf.bme.hu Precedence: bulk X-list: netdev Hi! I'm trying to set up an SMC Etherpower II card to perform a WOL, without success. The WOL connector is connected to the motherboard, and WOL is enabled in the BIOS. Am I correct in assuming, that this is a driver issue? I.e. the driver should initialize the card to receive WOL packet and signal the host to wake up. Are there some datasheets for this chipset which describe, how this should be done? Thanks, Miklos Szeredi From shemminger@osdl.org Thu Aug 21 16:30:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Aug 2003 16:30:50 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7LNUioO000920 for ; Thu, 21 Aug 2003 16:30:46 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7LNUXo31335; Thu, 21 Aug 2003 16:30:33 -0700 Date: Thu, 21 Aug 2003 16:30:19 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] IPV4 route cache /proc interface cleanup Message-Id: <20030821163019.66cfe65c.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5188 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 4887 Lines: 181 This patch to 2.6.0-test3 uses seq_file for /proc/net/rt_cache_stat Someone else already did the hard one /proc/net/rt_cache Couple of other little nits: * use proc_net_fops_create to setup * collapse two_line setup functions into the init routine * proc_exit routine was never called and can go. * cleaner to refer to proc_net as base rather than net/rt_acct Tested and output format is same as before on my SMP machine diff -Nru a/net/ipv4/route.c b/net/ipv4/route.c --- a/net/ipv4/route.c Thu Aug 21 16:21:04 2003 +++ b/net/ipv4/route.c Thu Aug 21 16:21:04 2003 @@ -312,49 +312,6 @@ return 0; } -static int rt_cache_stat_get_info(char *buffer, char **start, off_t offset, int length) -{ - unsigned int dst_entries = atomic_read(&ipv4_dst_ops.entries); - int i; - int len = 0; - - for (i = 0; i < NR_CPUS; i++) { - if (!cpu_possible(i)) - continue; - len += sprintf(buffer+len, "%08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x \n", - dst_entries, - per_cpu_ptr(rt_cache_stat, i)->in_hit, - per_cpu_ptr(rt_cache_stat, i)->in_slow_tot, - per_cpu_ptr(rt_cache_stat, i)->in_slow_mc, - per_cpu_ptr(rt_cache_stat, i)->in_no_route, - per_cpu_ptr(rt_cache_stat, i)->in_brd, - per_cpu_ptr(rt_cache_stat, i)->in_martian_dst, - per_cpu_ptr(rt_cache_stat, i)->in_martian_src, - - per_cpu_ptr(rt_cache_stat, i)->out_hit, - per_cpu_ptr(rt_cache_stat, i)->out_slow_tot, - per_cpu_ptr(rt_cache_stat, i)->out_slow_mc, - - per_cpu_ptr(rt_cache_stat, i)->gc_total, - per_cpu_ptr(rt_cache_stat, i)->gc_ignored, - per_cpu_ptr(rt_cache_stat, i)->gc_goal_miss, - per_cpu_ptr(rt_cache_stat, i)->gc_dst_overflow, - per_cpu_ptr(rt_cache_stat, i)->in_hlist_search, - per_cpu_ptr(rt_cache_stat, i)->out_hlist_search - - ); - } - len -= offset; - - if (len > length) - len = length; - if (len < 0) - len = 0; - - *start = buffer + offset; - return len; -} - static struct seq_operations rt_cache_seq_ops = { .start = rt_cache_seq_start, .next = rt_cache_seq_next, @@ -391,22 +348,89 @@ .release = seq_release_private, }; -int __init rt_cache_proc_init(void) + +static void *rt_cpu_seq_start(struct seq_file *seq, loff_t *pos) { - int rc = 0; - struct proc_dir_entry *p = create_proc_entry("rt_cache", S_IRUGO, - proc_net); - if (p) - p->proc_fops = &rt_cache_seq_fops; - else - rc = -ENOMEM; - return rc; + int cpu; + + for (cpu = *pos; cpu < NR_CPUS; ++cpu) { + if (!cpu_possible(cpu)) + continue; + *pos = cpu; + return per_cpu_ptr(rt_cache_stat, cpu); + } + return NULL; +} + +static void *rt_cpu_seq_next(struct seq_file *seq, void *v, loff_t *pos) +{ + int cpu; + + for (cpu = *pos + 1; cpu < NR_CPUS; ++cpu) { + if (!cpu_possible(cpu)) + continue; + *pos = cpu; + return per_cpu_ptr(rt_cache_stat, cpu); + } + return NULL; + } -void __init rt_cache_proc_exit(void) +static void rt_cpu_seq_stop(struct seq_file *seq, void *v) { - remove_proc_entry("rt_cache", proc_net); + } + +static int rt_cpu_seq_show(struct seq_file *seq, void *v) +{ + struct rt_cache_stat *st = v; + + seq_printf(seq,"%08x %08x %08x %08x %08x %08x %08x %08x " + " %08x %08x %08x %08x %08x %08x %08x %08x %08x \n", + atomic_read(&ipv4_dst_ops.entries), + st->in_hit, + st->in_slow_tot, + st->in_slow_mc, + st->in_no_route, + st->in_brd, + st->in_martian_dst, + st->in_martian_src, + + st->out_hit, + st->out_slow_tot, + st->out_slow_mc, + + st->gc_total, + st->gc_ignored, + st->gc_goal_miss, + st->gc_dst_overflow, + st->in_hlist_search, + st->out_hlist_search + ); + return 0; +} + +static struct seq_operations rt_cpu_seq_ops = { + .start = rt_cpu_seq_start, + .next = rt_cpu_seq_next, + .stop = rt_cpu_seq_stop, + .show = rt_cpu_seq_show, +}; + + +static int rt_cpu_seq_open(struct inode *inode, struct file *file) +{ + return seq_open(file, &rt_cpu_seq_ops); +} + +static struct file_operations rt_cpu_seq_fops = { + .owner = THIS_MODULE, + .open = rt_cpu_seq_open, + .read = seq_read, + .llseek = seq_lseek, + .release = seq_release_private, +}; + #endif /* CONFIG_PROC_FS */ static __inline__ void rt_free(struct rtable *rt) @@ -2779,11 +2803,12 @@ add_timer(&rt_secret_timer); #ifdef CONFIG_PROC_FS - if (rt_cache_proc_init()) + if (!proc_net_fops_create("rt_cache", S_IRUGO, &rt_cache_seq_fops) || + !proc_net_fops_create("rt_cache_stat", S_IRUGO, &rt_cpu_seq_fops)) goto out_enomem; - proc_net_create ("rt_cache_stat", 0, rt_cache_stat_get_info); + #ifdef CONFIG_NET_CLS_ROUTE - create_proc_read_entry("net/rt_acct", 0, 0, ip_rt_acct_read, NULL); + create_proc_read_entry("rt_acct", proc_net, 0, ip_rt_acct_read, NULL); #endif #endif #ifdef CONFIG_XFRM From shemminger@osdl.org Thu Aug 21 16:53:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Aug 2003 16:53:57 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7LNrjoO002264 for ; Thu, 21 Aug 2003 16:53:45 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7LNrBo05056; Thu, 21 Aug 2003 16:53:11 -0700 Date: Thu, 21 Aug 2003 16:52:58 -0700 From: Stephen Hemminger To: Chad Tindel , Jay Vosburgh , "David S. Miller" , Jeff Garzik Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] convering bonding driver /proc interface to seq_file Message-Id: <20030821165258.45f1ec53.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5189 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 11069 Lines: 365 This patch converts /proc/net/bondXX/info to the seq_file interface; patch is against 2.6.0-test3; but seq_file has been backported to latest 2.4 as well. It also fixes a bug with multiple bond devices. The original code mushes all the bond device status information together. In other words, /proc/net/bond0/info gives the same output as /proc/net/bond1/info. I fixed this in this version, by stuffing a link back to the bonding data structure in the created proc_dir_entry; which is then used to only pickup the slaves for that pseudo-device. Don't think anyone ever used more that one device, because they probably would have noticed this. The name "/proc/net/bond0/info" is kind of unconventional, but now changing that in a almost stable release would be bad. Better choice would be "/proc/net/bonding/bond0". --- linux-2.5/drivers/net/bonding/bond_main.c 2003-08-20 11:19:42.000000000 -0700 +++ linux-2.5-net/drivers/net/bonding/bond_main.c 2003-08-21 16:42:57.130509618 -0700 @@ -402,6 +402,8 @@ #include #include #include +#include +#include #include #include @@ -545,14 +547,6 @@ static int bond_release_all(struct net_device *master); static int bond_sethwaddr(struct net_device *master, struct net_device *slave); -/* - * bond_get_info is the interface into the /proc filesystem. This is - * a different interface than the BOND_INFO_QUERY ioctl. That is done - * through the generic networking ioctl interface, and bond_info_query - * is the internal function which provides that information. - */ -static int bond_get_info(char *buf, char **start, off_t offset, int length); - /* Caller must hold bond->ptrlock for write */ static inline struct slave* bond_assign_current_slave(struct bonding *bond,struct slave *newslave) @@ -3327,133 +3321,195 @@ return stats; } -static int bond_get_info(char *buf, char **start, off_t offset, int length) -{ - bonding_t *bond; - int len = 0; - off_t begin = 0; - u16 link; - slave_t *slave = NULL; +#ifdef CONFIG_PROC_FS - len += sprintf(buf + len, "%s\n", version); +#define BOND_PROC_HEADER ((void *)1) /* magic pointer for header line */ + +static void *bond_info_seq_start(struct seq_file *seq, loff_t *pos) +{ + bonding_t *bond = seq->private; + loff_t off = 0; + slave_t *slave; read_lock(&dev_base_lock); - list_for_each_entry(bond, &bond_dev_list, bond_list) { - /* - * This function locks the mutex, so we can't lock it until - * afterwards - */ - link = bond_check_mii_link(bond); - len += sprintf(buf + len, "Bonding Mode: %s\n", - bond_mode_name()); + if (*pos == 0) + return BOND_PROC_HEADER; - if ((bond_mode == BOND_MODE_ACTIVEBACKUP) || - (bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { - read_lock_bh(&bond->lock); - read_lock(&bond->ptrlock); - if (bond->current_slave != NULL) { - len += sprintf(buf + len, - "Currently Active Slave: %s\n", - bond->current_slave->dev->name); - } - read_unlock(&bond->ptrlock); - read_unlock_bh(&bond->lock); - } - - len += sprintf(buf + len, "MII Status: "); - len += sprintf(buf + len, - link == BMSR_LSTATUS ? "up\n" : "down\n"); - len += sprintf(buf + len, "MII Polling Interval (ms): %d\n", - miimon); - len += sprintf(buf + len, "Up Delay (ms): %d\n", - updelay * miimon); - len += sprintf(buf + len, "Down Delay (ms): %d\n", - downdelay * miimon); - len += sprintf(buf + len, "Multicast Mode: %s\n", - multicast_mode_name()); + read_lock_bh(&bond->lock); + for (slave = bond->prev; slave != (slave_t *)bond; slave = slave->prev) { + if (++off == *pos) + return slave; + } + + return NULL; +} + +static void *bond_info_seq_next(struct seq_file *seq, void *v, loff_t *pos) +{ + bonding_t *bond = seq->private; + slave_t *slave = v; + ++*pos; + if (v == BOND_PROC_HEADER) { read_lock_bh(&bond->lock); + slave = bond->prev; + } else { + slave = slave->prev; + } + return (slave == (slave_t *) bond) ? NULL : slave; +} - if (bond_mode == BOND_MODE_8023AD) { - struct ad_info ad_info; +static void bond_info_seq_stop(struct seq_file *seq, void *v) +{ + bonding_t *bond = seq->private; + + if (v != BOND_PROC_HEADER) + read_unlock_bh(&bond->lock); + read_unlock(&dev_base_lock); +} - len += sprintf(buf + len, "\n802.3ad info\n"); +static void bond_info_show_master(struct seq_file *seq, bonding_t *bond) +{ + u16 link = bond_check_mii_link(bond); - if (bond_3ad_get_active_agg_info(bond, &ad_info)) { - len += sprintf(buf + len, "bond %s has no active aggregator\n", bond->device->name); - } else { - len += sprintf(buf + len, "Active Aggregator Info:\n"); + seq_printf(seq, "Bonding Mode: %s\n", + bond_mode_name()); - len += sprintf(buf + len, "\tAggregator ID: %d\n", ad_info.aggregator_id); - len += sprintf(buf + len, "\tNumber of ports: %d\n", ad_info.ports); - len += sprintf(buf + len, "\tActor Key: %d\n", ad_info.actor_key); - len += sprintf(buf + len, "\tPartner Key: %d\n", ad_info.partner_key); - len += sprintf(buf + len, "\tPartner Mac Address: %02x:%02x:%02x:%02x:%02x:%02x\n", - ad_info.partner_system[0], - ad_info.partner_system[1], - ad_info.partner_system[2], - ad_info.partner_system[3], - ad_info.partner_system[4], - ad_info.partner_system[5]); - } + if ((bond_mode == BOND_MODE_ACTIVEBACKUP) || + (bond_mode == BOND_MODE_TLB) || + (bond_mode == BOND_MODE_ALB)) { + read_lock_bh(&bond->lock); + read_lock(&bond->ptrlock); + if (bond->current_slave != NULL) { + seq_printf(seq, + "Currently Active Slave: %s\n", + bond->current_slave->dev->name); } + read_unlock(&bond->ptrlock); + read_unlock_bh(&bond->lock); + } - for (slave = bond->prev; slave != (slave_t *)bond; - slave = slave->prev) { - len += sprintf(buf + len, "\nSlave Interface: %s\n", slave->dev->name); - - len += sprintf(buf + len, "MII Status: "); - - len += sprintf(buf + len, - slave->link == BOND_LINK_UP ? - "up\n" : "down\n"); - len += sprintf(buf + len, "Link Failure Count: %d\n", - slave->link_failure_count); - - if (app_abi_ver >= 1) { - len += sprintf(buf + len, - "Permanent HW addr: %02x:%02x:%02x:%02x:%02x:%02x\n", - slave->perm_hwaddr[0], - slave->perm_hwaddr[1], - slave->perm_hwaddr[2], - slave->perm_hwaddr[3], - slave->perm_hwaddr[4], - slave->perm_hwaddr[5]); - } + seq_printf(seq, "MII Status: "); + seq_printf(seq, + link == BMSR_LSTATUS ? "up\n" : "down\n"); + seq_printf(seq, "MII Polling Interval (ms): %d\n", + miimon); + seq_printf(seq, "Up Delay (ms): %d\n", + updelay * miimon); + seq_printf(seq, "Down Delay (ms): %d\n", + downdelay * miimon); + seq_printf(seq, "Multicast Mode: %s\n", + multicast_mode_name()); - if (bond_mode == BOND_MODE_8023AD) { - struct aggregator *agg = SLAVE_AD_INFO(slave).port.aggregator; - if (agg) { - len += sprintf(buf + len, "Aggregator ID: %d\n", - agg->aggregator_identifier); - } else { - len += sprintf(buf + len, "Aggregator ID: N/A\n"); - } - } - } - read_unlock_bh(&bond->lock); + if (bond_mode == BOND_MODE_8023AD) { + struct ad_info ad_info; - /* - * Figure out the calcs for the /proc/net interface - */ - *start = buf + (offset - begin); - len -= (offset - begin); - if (len > length) { - len = length; - } - if (len < 0) { - len = 0; + seq_printf(seq, "\n802.3ad info\n"); + + if (bond_3ad_get_active_agg_info(bond, &ad_info)) { + seq_printf(seq, "bond %s has no active aggregator\n", bond->device->name); + } else { + seq_printf(seq, "Active Aggregator Info:\n"); + + seq_printf(seq, "\tAggregator ID: %d\n", ad_info.aggregator_id); + seq_printf(seq, "\tNumber of ports: %d\n", ad_info.ports); + seq_printf(seq, "\tActor Key: %d\n", ad_info.actor_key); + seq_printf(seq, "\tPartner Key: %d\n", ad_info.partner_key); + seq_printf(seq, "\tPartner Mac Address: %02x:%02x:%02x:%02x:%02x:%02x\n", + ad_info.partner_system[0], + ad_info.partner_system[1], + ad_info.partner_system[2], + ad_info.partner_system[3], + ad_info.partner_system[4], + ad_info.partner_system[5]); } + } + +} + +static void bond_info_show_slave(struct seq_file *seq, const slave_t *slave) +{ + + seq_printf(seq, "\nSlave Interface: %s\n", slave->dev->name); + seq_printf(seq, "MII Status: "); + + seq_printf(seq, + slave->link == BOND_LINK_UP ? + "up\n" : "down\n"); + seq_printf(seq, "Link Failure Count: %d\n", + slave->link_failure_count); + + if (app_abi_ver >= 1) { + seq_printf(seq, + "Permanent HW addr: %02x:%02x:%02x:%02x:%02x:%02x\n", + slave->perm_hwaddr[0], + slave->perm_hwaddr[1], + slave->perm_hwaddr[2], + slave->perm_hwaddr[3], + slave->perm_hwaddr[4], + slave->perm_hwaddr[5]); } - read_unlock(&dev_base_lock); - return len; + if (bond_mode == BOND_MODE_8023AD) { + const struct aggregator *agg + = SLAVE_AD_INFO(slave).port.aggregator; + + if (agg) + seq_printf(seq, "Aggregator ID: %d\n", + agg->aggregator_identifier); + else + seq_printf(seq, "Aggregator ID: N/A\n"); + } +} + +static int bond_info_seq_show(struct seq_file *seq, void *v) +{ + if (v == BOND_PROC_HEADER) { + seq_printf(seq, "%s\n", version); + bond_info_show_master(seq, seq->private); + } else + bond_info_show_slave(seq, v); + return 0; } + +static struct seq_operations bond_info_seq_ops = { + .start = bond_info_seq_start, + .next = bond_info_seq_next, + .stop = bond_info_seq_stop, + .show = bond_info_seq_show, +}; + +static int bond_info_open(struct inode *inode, struct file *file) +{ + struct seq_file *seq; + struct proc_dir_entry *proc; + int rc; + + rc = seq_open(file, &bond_info_seq_ops); + if (!rc) { + /* recover the pointer buried in proc_dir_entry data */ + seq = file->private_data; + proc = PDE(inode); + seq->private = proc->data; + } + return rc; +} + +static struct file_operations bond_info_fops = { + .owner = THIS_MODULE, + .open = bond_info_open, + .read = seq_read, + .llseek = seq_lseek, + .release = seq_release, +}; + + +#endif + static int bond_event(struct notifier_block *this, unsigned long event, void *ptr) { @@ -3560,15 +3616,15 @@ bond->bond_proc_dir->owner = THIS_MODULE; bond->bond_proc_info_file = - create_proc_info_entry("info", 0, bond->bond_proc_dir, - bond_get_info); + create_proc_entry("info", 0, bond->bond_proc_dir); if (bond->bond_proc_info_file == NULL) { printk(KERN_ERR "%s: Cannot init /proc/net/%s/info\n", dev->name, dev->name); remove_proc_entry(dev->name, proc_net); return -ENOMEM; } - bond->bond_proc_info_file->owner = THIS_MODULE; + bond->bond_proc_info_file->data = bond; + bond->bond_proc_info_file->proc_fops = &bond_info_fops; #endif /* CONFIG_PROC_FS */ From jmorris@intercode.com.au Thu Aug 21 17:19:42 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Aug 2003 17:19:47 -0700 (PDT) Received: from blackbird.intercode.com.au (IDENT:EkDTmA28H8KccYWI/U1T8EPkFv6f4rst@blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7M0JQoO004360 for ; Thu, 21 Aug 2003 17:19:35 -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 h7M0H9C13893; Fri, 22 Aug 2003 10:17:11 +1000 Date: Fri, 22 Aug 2003 10:17:07 +1000 (EST) From: James Morris To: Stephen Hemminger cc: Chad Tindel , Jay Vosburgh , "David S. Miller" , Jeff Garzik , , Subject: Re: [PATCH] convering bonding driver /proc interface to seq_file In-Reply-To: <20030821165258.45f1ec53.shemminger@osdl.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5190 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 Content-Length: 321 Lines: 14 On Thu, 21 Aug 2003, Stephen Hemminger wrote: > The name "/proc/net/bond0/info" is kind of unconventional, but now > changing that in a almost stable release would be bad. Better choice > would be "/proc/net/bonding/bond0". I'm not sure it's too late to do this. - James -- James Morris From ctindel@calma.pair.com Thu Aug 21 17:27:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Aug 2003 17:27:48 -0700 (PDT) Received: from calma.pair.com (calma.pair.com [209.68.1.95]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7M0RhoO005504 for ; Thu, 21 Aug 2003 17:27:44 -0700 Received: (qmail 99884 invoked by uid 3059); 22 Aug 2003 00:27:42 -0000 Date: Thu, 21 Aug 2003 20:27:42 -0400 From: "Chad N. Tindel" To: James Morris Cc: Stephen Hemminger , Jay Vosburgh , "David S. Miller" , Jeff Garzik , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] convering bonding driver /proc interface to seq_file Message-ID: <20030822002742.GA99843@calma.pair.com> Mail-Followup-To: James Morris , Stephen Hemminger , Jay Vosburgh , "David S. Miller" , Jeff Garzik , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com References: <20030821165258.45f1ec53.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-archive-position: 5191 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chad@tindel.net Precedence: bulk X-list: netdev Content-Length: 285 Lines: 10 > > The name "/proc/net/bond0/info" is kind of unconventional, but now > > changing that in a almost stable release would be bad. Better choice > > would be "/proc/net/bonding/bond0". > > I'm not sure it's too late to do this. It certainly would match what other drivers do. Chad From latten@austin.ibm.com Thu Aug 21 18:40:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Aug 2003 18:40:32 -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 h7M1ePoO010961 for ; Thu, 21 Aug 2003 18:40:25 -0700 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e33.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h7M1dfj3283968; Thu, 21 Aug 2003 21:39:42 -0400 Received: from austin.ibm.com (d03av03.boulder.ibm.com [9.17.193.83]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h7M1deJO417506; Thu, 21 Aug 2003 19:39:40 -0600 Received: from faith.austin.ibm.com (faith.austin.ibm.com [9.41.94.16]) by austin.ibm.com (8.12.9/8.12.9) with ESMTP id h7M1deN2098020; Thu, 21 Aug 2003 20:39:40 -0500 Received: from faith.austin.ibm.com (localhost.localdomain [127.0.0.1]) by faith.austin.ibm.com (8.12.5/8.12.8) with ESMTP id h7M1nmKn017800; Thu, 21 Aug 2003 20:49:48 -0500 Received: (from jml@localhost) by faith.austin.ibm.com (8.12.5/8.12.5/Submit) id h7M1nlAU017798; Thu, 21 Aug 2003 20:49:47 -0500 Date: Thu, 21 Aug 2003 20:49:47 -0500 From: latten@austin.ibm.com Message-Id: <200308220149.h7M1nlAU017798@faith.austin.ibm.com> To: netdev@oss.sgi.com Subject: IPSecv6/Neighbor discovery crash Cc: kazunori@miyazawa.org X-archive-position: 5192 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: latten@austin.ibm.com Precedence: bulk X-list: netdev Content-Length: 2229 Lines: 57 I am using linux-2.6.0-test3 + patch-2.6.0-test3-bk7 on SMP machines. Upon configuring AH, I do a ping6 to test connectivity and I get the following trace. (see first crash) I have seen this crash with ESP configured also. This only seems to happen when IPSecv6 is configured. So far, I have not been able to track down the culprit... I have not been able to determine if it is a lock... icmpv6_echo_reply() takes a lock on the socket and will let it go when done... Has anyone else seen this? Joy Unable to handle kernel NULL pointer dereference at virtual address 00000164 printing eip: c0445767 *pde = 00000000 Oops: 0000 [#1] CPU: 0 EIP: 0060:[] Not tainted EFLAGS: 00010246 EIP is at ndisc_build_ll_hdr+0x17/0x1e0 eax: 00000000 ebx: f7564bc0 ecx: f550ce60 edx: f6d388c0 esi: c1af9430 edi: 00000000 ebp: c05c1c90 esp: c05c1c44 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=c05c0000 task=c050f020) Stack: c1ab41a0 f29ad1c4 f3128624 f3128640 00000206 0000000c 3a000246 f70803e0 f7080408 c1aff200 c05c1cb0 c0460b4d f70803e0 f7564bc0 c1af944c c1aff214 f7564bc0 f7564bc0 c1af94cc c05c1cb0 c0445970 f7564bc0 00000000 c1af9430 Call Trace: [] ah6_output+0x26d/0x510 [] ndisc_output+0x40/0x80 [] ip6_push_pending_frames+0x22f/0x380 [] icmpv6_push_pending_frames+0x116/0x1a0 [] icmpv6_echo_reply+0x28a/0x340 [] icmpv6_rcv+0x264/0x590 [] ip6_input+0x120/0x2e0 [] ipv6_rcv+0x13e/0x250 [] netif_receive_skb+0x16b/0x200 [] process_backlog+0x84/0x120 [] net_rx_action+0x83/0x110 [] do_softirq+0xe7/0xf0 [] do_IRQ+0x15d/0x200 [] smp_apic_timer_interrupt+0xcd/0x140 [] default_idle+0x0/0x40 [] common_interrupt+0x18/0x20 [] default_idle+0x0/0x40 [] default_idle+0x30/0x40 [] cpu_idle+0x46/0x50 [] rest_init+0x0/0x80 [] start_kernel+0x19e/0x1f0 [] unknown_bootoption+0x0/0x110 Code: 8b 80 64 01 00 00 85 c0 75 14 ba 01 00 00 00 8b 5d f4 89 d0 <0>Kernel panic: Fatal exception in interrupt In interrupt handler - not syncing From davem@redhat.com Thu Aug 21 18:54:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Aug 2003 18:54:53 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7M1smoO011674 for ; Thu, 21 Aug 2003 18:54:50 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id SAA32192; Thu, 21 Aug 2003 18:46:40 -0700 Date: Thu, 21 Aug 2003 18:46:40 -0700 From: "David S. Miller" To: latten@austin.ibm.com Cc: netdev@oss.sgi.com, kazunori@miyazawa.org Subject: Re: IPSecv6/Neighbor discovery crash Message-Id: <20030821184640.2cb89b87.davem@redhat.com> In-Reply-To: <200308220149.h7M1nlAU017798@faith.austin.ibm.com> References: <200308220149.h7M1nlAU017798@faith.austin.ibm.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5193 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 Content-Length: 197 Lines: 7 On Thu, 21 Aug 2003 20:49:47 -0500 latten@austin.ibm.com wrote: > EIP is at ndisc_build_ll_hdr+0x17/0x1e0 So what exactly is NULL in ndisc_build_ll_hdr(), is it 'dev'? That'd be really weird... From marcia@pantheon.yale.edu Thu Aug 21 19:57:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Aug 2003 19:57:20 -0700 (PDT) Received: from pantheon-po01.its.yale.edu (pantheon-po01.its.yale.edu [130.132.50.18]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7M2vFoO014363 for ; Thu, 21 Aug 2003 19:57:17 -0700 Received: (from marcia@localhost) by pantheon-po01.its.yale.edu (8.11.6p2/8.11.6) id h7M2vEI09102 for netdev@oss.sgi.com; Thu, 21 Aug 2003 22:57:14 -0400 (EDT) Date: Thu, 21 Aug 2003 22:57:14 -0400 (EDT) Message-Id: <200308220257.h7M2vEI09102@pantheon-po01.its.yale.edu> To: netdev@oss.sgi.com Auto-Submitted: auto-generated From: "Marcia J Schels" Subject: Away From My Mail X-archive-position: 5194 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: marcia.schels@yale.edu Precedence: bulk X-list: netdev Content-Length: 258 Lines: 6 I'm out of the office until Tuesday, September 2nd. If you need to reach someone urgently, please call Maya Satmary at 203.432.3262 so that she can redirect your call. For any off-hours emergency please call the ITS Machine room at 432.6506. Thank you. From kazunori@miyazawa.org Thu Aug 21 22:55:21 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Aug 2003 22:55:28 -0700 (PDT) Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7M5tKoO021663 for ; Thu, 21 Aug 2003 22:55:21 -0700 Received: from monza.miyazawa.org ([2001:200:103:3:2d0:59ff:feab:4ac0]) (AUTH: LOGIN kazunori, ) by miyazawa.org with esmtp; Fri, 22 Aug 2003 14:46:17 +0900 Date: Fri, 22 Aug 2003 14:55:53 +0900 From: Kazunori Miyazawa To: "David S. Miller" , latten@austin.ibm.com Cc: netdev@oss.sgi.com Subject: Re: IPSecv6/Neighbor discovery crash Message-Id: <20030822145553.0ca08046.kazunori@miyazawa.org> In-Reply-To: <20030821184640.2cb89b87.davem@redhat.com> References: <200308220149.h7M1nlAU017798@faith.austin.ibm.com> <20030821184640.2cb89b87.davem@redhat.com> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5196 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kazunori@miyazawa.org Precedence: bulk X-list: netdev Content-Length: 1404 Lines: 50 On Thu, 21 Aug 2003 18:46:40 -0700 "David S. Miller" wrote: > On Thu, 21 Aug 2003 20:49:47 -0500 > latten@austin.ibm.com wrote: > > > EIP is at ndisc_build_ll_hdr+0x17/0x1e0 > > So what exactly is NULL in ndisc_build_ll_hdr(), is > it 'dev'? That'd be really weird... > I had same crach. I guess it is due to xfrm cache. My impression about the problem is likes this. When we configure IPsec and src and dst of neighbour discoery match the configuration occasionally, The kernel creates and caches the stackable dst like this because ndisc_send_* want to use it dst->output(ah6_output) +- child->output(ndisc_output) Then it receives icmpv6 echo request. It replys by using the cached stackable dst like above. The kernel however must use another stackable dst like dst->output(ah6_output) +- child->output(ip6_output) It is the issue. The kernel can not tell first stackable dst from second stackable dst because it can not know the last output function. I believe we need to change the kernel to use ip6_output ( or another common output function) to send neighbour discovery packet instead of ndisc_output essentially. But it may make the kernel be unstable. I think there is not so much request to use IPsec with neighbour discovery. I think it is better to remove xfrm_lookup from ndisc_send_* functions at the moment. Best regards, --Kazunori Miyazawa From vinay-rc@naturesoft.net Fri Aug 22 02:33:51 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Aug 2003 02:34:01 -0700 (PDT) Received: from naturesoft.net ([203.145.184.221]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7M9XaoO009143 for ; Fri, 22 Aug 2003 02:33:43 -0700 Received: from [192.168.0.15] (helo=lima.royalchallenge.com) by naturesoft.net with esmtp (Exim 3.35 #1) id 19q8Bg-0004wb-00; Fri, 22 Aug 2003 14:56:28 +0530 Subject: Re: [PATCH 2.6.0-test3-bk8][ATM] fix ambassador.c From: Vinay K Nallamothu To: Francois Romieu Cc: linux-atm-general@lists.sourceforge.net, netdev@oss.sgi.com, Kernel List In-Reply-To: <20030821193149.A18920@electric-eye.fr.zoreil.com> References: <1061478906.1069.23.camel@lima.royalchallenge.com> <20030821193149.A18920@electric-eye.fr.zoreil.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 22 Aug 2003 15:24:15 +0530 Message-Id: <1061546055.1108.7.camel@lima.royalchallenge.com> Mime-Version: 1.0 X-archive-position: 5197 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vinay-rc@naturesoft.net Precedence: bulk X-list: netdev Content-Length: 5816 Lines: 217 On Thu, 2003-08-21 at 23:01, Francois Romieu wrote: > Vinay K Nallamothu : > [...] > > drivers/atm/ambassador.c: > > This patch cleans up sti/cli usage as well as minor timer cleanups. > [...] > > The "dont_panic" function which uses cli/sti is only called from code > belonging to a "#if 0" section since revision 1.1 according to bk. > > Remove it, everybody should feel better. Thanks for the suggestions. Here is the updated patch. Applies cleanly against 2.6.0-test3-bk9 drivers/atm/ambassador.c: 1. remove the function dont_panic which is mostly unused. 2. remove amb_ioctl which is never used. 3. minor timer code cleanups ambassador.c | 132 ++--------------------------------------------------------- 1 files changed, 6 insertions(+), 126 deletions(-) diff -urN linux-2.6.0-test3-bk9/drivers/atm/ambassador.c linux-2.6.0-test3-nvk/drivers/atm/ambassador.c --- linux-2.6.0-test3-bk9/drivers/atm/ambassador.c 2003-08-22 15:04:47.000000000 +0530 +++ linux-2.6.0-test3-nvk/drivers/atm/ambassador.c 2003-08-22 14:56:11.000000000 +0530 @@ -310,10 +310,11 @@ 0xdeadbeef }; +static void do_housekeeping (unsigned long arg); /********** globals **********/ static amb_dev * amb_devs = NULL; -static struct timer_list housekeeping; +static struct timer_list housekeeping = TIMER_INITIALIZER(do_housekeeping, 0, 1); static unsigned short debug = 0; static unsigned int cmds = 8; @@ -937,63 +938,6 @@ return IRQ_HANDLED; } -/********** don't panic... yeah, right **********/ - -#ifdef DEBUG_AMBASSADOR -static void dont_panic (amb_dev * dev) { - amb_cq * cq = &dev->cq; - volatile amb_cq_ptrs * ptrs = &cq->ptrs; - amb_txq * txq; - amb_rxq * rxq; - command * cmd; - tx_in * tx; - tx_simple * tx_descr; - unsigned char pool; - rx_in * rx; - - unsigned long flags; - save_flags (flags); - cli(); - - PRINTK (KERN_INFO, "don't panic - putting adapter into reset"); - wr_plain (dev, offsetof(amb_mem, reset_control), - rd_plain (dev, offsetof(amb_mem, reset_control)) | AMB_RESET_BITS); - - PRINTK (KERN_INFO, "marking all commands complete"); - for (cmd = ptrs->start; cmd < ptrs->limit; ++cmd) - cmd->request = cpu_to_be32 (SRB_COMPLETE); - - PRINTK (KERN_INFO, "completing all TXs"); - txq = &dev->txq; - tx = txq->in.ptr; - while (txq->pending--) { - if (tx == txq->in.start) - tx = txq->in.limit; - --tx; - tx_descr = bus_to_virt (be32_to_cpu (tx->tx_descr_addr)); - amb_kfree_skb (tx_descr->skb); - kfree (tx_descr); - } - - PRINTK (KERN_INFO, "freeing all RX buffers"); - for (pool = 0; pool < NUM_RX_POOLS; ++pool) { - rxq = &dev->rxq[pool]; - rx = rxq->in.ptr; - while (rxq->pending--) { - if (rx == rxq->in.start) - rx = rxq->in.limit; - --rx; - dev_kfree_skb_any (bus_to_virt (rx->handle)); - } - } - - PRINTK (KERN_INFO, "don't panic over - close all VCs and rmmod"); - set_bit (dead, &dev->flags); - restore_flags (flags); - return; -} -#endif - /********** make rate (not quite as much fun as Horizon) **********/ static unsigned int make_rate (unsigned int rate, rounding r, @@ -1420,32 +1364,6 @@ return; } -/********** DebugIoctl **********/ - -#if 0 -static int amb_ioctl (struct atm_dev * dev, unsigned int cmd, void * arg) { - unsigned short newdebug; - if (cmd == AMB_SETDEBUG) { - if (!capable(CAP_NET_ADMIN)) - return -EPERM; - if (copy_from_user (&newdebug, arg, sizeof(newdebug))) { - // moan - return -EFAULT; - } else { - debug = newdebug; - return 0; - } - } else if (cmd == AMB_DONTPANIC) { - if (!capable(CAP_NET_ADMIN)) - return -EPERM; - dont_panic (dev); - } else { - // moan - return -ENOIOCTLCMD; - } -} -#endif - /********** Set socket options for a VC **********/ // int amb_getsockopt (struct atm_vcc * atm_vcc, int level, int optname, void * optval, int optlen); @@ -1524,33 +1442,6 @@ tx.tx_descr_length = cpu_to_be16 (sizeof(tx_frag)+sizeof(tx_frag_end)); tx.tx_descr_addr = cpu_to_be32 (virt_to_bus (&tx_descr->tx_frag)); -#ifdef DEBUG_AMBASSADOR - /* wey-hey! */ - if (vc == 1023) { - unsigned int i; - unsigned short d = 0; - char * s = skb->data; - switch (*s++) { - case 'D': { - for (i = 0; i < 4; ++i) { - d = (d<<4) | ((*s <= '9') ? (*s - '0') : (*s - 'a' + 10)); - ++s; - } - PRINTK (KERN_INFO, "debug bitmap is now %hx", debug = d); - break; - } - case 'R': { - if (*s++ == 'e' && *s++ == 's' && *s++ == 'e' && *s++ == 't') - dont_panic (dev); - break; - } - default: { - break; - } - } - } -#endif - while (tx_give (dev, &tx)) schedule(); return 0; @@ -1663,21 +1554,14 @@ /********** Operation Structure **********/ static const struct atmdev_ops amb_ops = { - .open = amb_open, + .open = amb_open, .close = amb_close, - .send = amb_send, + .send = amb_send, .proc_read = amb_proc_read, .owner = THIS_MODULE, }; /********** housekeeping **********/ - -static inline void set_timer (struct timer_list * timer, unsigned long delay) { - timer->expires = jiffies + delay; - add_timer (timer); - return; -} - static void do_housekeeping (unsigned long arg) { amb_dev * dev = amb_devs; // data is set to zero at module unload @@ -1693,7 +1577,7 @@ dev = dev->prev; } - set_timer (&housekeeping, 10*HZ); + mod_timer(&housekeeping, jiffies + 10*HZ); } return; @@ -2579,11 +2463,7 @@ devs = amb_probe(); if (devs) { - init_timer (&housekeeping); - housekeeping.function = do_housekeeping; - // paranoia - housekeeping.data = 1; - set_timer (&housekeeping, 0); + mod_timer (&housekeeping, jiffies); } else { PRINTK (KERN_INFO, "no (usable) adapters found"); } From MAILER-DAEMON@oss.sgi.com Fri Aug 22 06:37:30 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Aug 2003 06:37:34 -0700 (PDT) Received: from mail.lineo.com (apollo.lineo.com [64.50.107.70]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7MDbUoO026425 for ; Fri, 22 Aug 2003 06:37:30 -0700 Received: (qmail 8241 invoked by uid 129); 22 Aug 2003 13:37:26 -0000 Date: 22 Aug 2003 13:37:26 -0000 From: "System Anti-Virus Administrator" To: netdev@oss.sgi.com Cc: mis@lineo.com Subject: Illegal attachment type found in sent message "Thank you!" Message-ID: X-Tnz-Problem-Type: 40 MIME-Version: 1.0 Content-type: text/plain X-archive-position: 5200 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mis@lineo.com Precedence: bulk X-list: netdev Content-Length: 1037 Lines: 43 Attention: . A Illegal attachment type was found in an Email message you sent. This Email scanner intercepted it and stopped the entire message reaching it's destination. The Illegal attachment type was reported to be: PIF attachments disallowed Please contact your I.T support personnel with any queries regarding this policy. Your message was sent with the following envelope: MAIL FROM: netdev@oss.sgi.com RCPT TO: andersen@lineo.com ... and with the following headers: From: To: Subject: Thank you! Date: Fri, 22 Aug 2003 22:37:25 +0900 The original message is kept in: apollo.lineo.com:/var/spool/qmailscan/quarantine where the System Anti-Virus Administrator can further diagnose it. The Email scanner reported the following when it scanned that message: --- ---perlscanner results --- Illegal attachment type 'PIF attachments disallowed' found in file /var/spool/qmailscan/apollo.lineo.com10615594434088234/document_all.pif --- From Thorsten.Thiel@medical.bruker.de Fri Aug 22 07:34:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Aug 2003 07:34:47 -0700 (PDT) Received: from relay.bruker.de (qmailr@bam.bruker.de [149.236.1.1]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7MEYNoO028606 for ; Fri, 22 Aug 2003 07:34:44 -0700 Received: (qmail 20141 invoked from network); 22 Aug 2003 14:34:15 -0000 Received: from unknown (HELO bam.bruker.de) (149.236.1.2) by bam.bruker.de with SMTP; 22 Aug 2003 14:34:15 -0000 Received: from mailserver.bruker.de ([149.236.4.16]) by bam.bruker.de; Fri, 22 Aug 2003 16:34:18 +0200 (MEST) Received: by mailserver.bruker.de with MERCUR-SMTP/POP3/IMAP4-Server (v3.30.09 AS-0098310) for ; Fri, 22 Aug 2003 16:33:28 +0200 To: Date: Fri, 22 Aug 2003 16:33:28 +0200 From: Subject: Reply from Thorsten.Thiel@medical.bruker.de Message-Id: <03082216332895300@mailserver.bruker.de> X-AntiVirus: scanned for viruses by AMaViS 0.2.0-pre6 (http://aachalon.de/AMaViS/) X-archive-position: 5201 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Thorsten.Thiel@medical.bruker.de Precedence: bulk X-list: netdev Content-Length: 535 Lines: 23 Hello, I will be out office until September 3rd, 2003. Your email has been saved and I will respond to it upon my return if I cannot access my e-mail during my absence. In urgent cases please contact Dr. Stefan Widmaier: Stefan.Widmaier@bruker-biospin.de +49 7243 504 563 Best regards, Thorsten Thiel _______________________________ Thorsten Thiel, Ph.D. Product Manager Bruker BioSpin MRI D - 76275 Ettlingen Thorsten.Thiel@bruker-biospin.de Phone:+49 (0)7243 504 517 Fax: +49 (0)7243 504 539 http://www.bruker-biospin.de From cfriesen@nortelnetworks.com Fri Aug 22 08:23:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Aug 2003 08:23:40 -0700 (PDT) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7MFNVoO030965 for ; Fri, 22 Aug 2003 08:23:32 -0700 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7MFNNQ16223; Fri, 22 Aug 2003 11:23:23 -0400 (EDT) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QYKXLSBH; Fri, 22 Aug 2003 11:23:23 -0400 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q8C6JMR8; Fri, 22 Aug 2003 11:23:24 -0400 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id BC37C2D957; Fri, 22 Aug 2003 11:23:22 -0400 (EDT) Message-ID: <3F46356A.804@nortelnetworks.com> Date: Fri, 22 Aug 2003 11:23:22 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Linux Kernel Mailing List , netdev@oss.sgi.com Subject: help??? trying to trace code path of outgoing udp packet Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5202 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfriesen@nortelnetworks.com Precedence: bulk X-list: netdev Content-Length: 950 Lines: 29 I'm trying to figure out the code path taken by an outgoing udp packet, and I'm having a bit of trouble figuring out which functions are called by which function pointers. The path that I have so far is this: udp_sendmsg udp.c ip_build_xmit ip_output.c output_maybe_reroute ip_output.c skb->dst->output ip_output ip_output.c ip_finish_output ip_output.c ip_finish_output2 ip_output.c dst->neighbour->output Is this correct? Where does it go from here and how does it eventually end up in the driver? In the case in question, the network device is the tulip chip and traffic shaping is not enabled, but we do have advanced routing turned on. Thanks, Chris -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com From niv@us.ibm.com Fri Aug 22 08:36:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Aug 2003 08:36:49 -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 h7MFadoO031743 for ; Fri, 22 Aug 2003 08:36:45 -0700 Received: from westrelay05.boulder.ibm.com (westrelay05.boulder.ibm.com [9.17.193.33]) by e33.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h7MFaMj3272400; Fri, 22 Aug 2003 11:36:22 -0400 Received: from us.ibm.com (d03av03.boulder.ibm.com [9.17.193.83]) by westrelay05.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h7MFaG98150930; Fri, 22 Aug 2003 09:36:19 -0600 Message-ID: <3F46386A.4080009@us.ibm.com> Date: Fri, 22 Aug 2003 08:36:10 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Friesen CC: Linux Kernel Mailing List , netdev@oss.sgi.com Subject: Re: help??? trying to trace code path of outgoing udp packet References: <3F46356A.804@nortelnetworks.com> In-Reply-To: <3F46356A.804@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5203 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 277 Lines: 18 Chris Friesen wrote: > ip_finish_output ip_output.c > ip_finish_output2 ip_output.c dst->neighbour->output | V dev_queue_xmit() qdisc_run() qdisc_restart() dev->hard_start_xmit() [driver xmit routine] this is for the default queuing discipline. thanks, Nivedita From cfriesen@nortelnetworks.com Fri Aug 22 09:53:04 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Aug 2003 09:53:33 -0700 (PDT) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7MGqNoO002809 for ; Fri, 22 Aug 2003 09:53:03 -0700 Received: from zcard307.ca.nortel.com (americasm03.nt.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7MGqFK18663; Fri, 22 Aug 2003 12:52:15 -0400 (EDT) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RL9ZS9Z7; Fri, 22 Aug 2003 12:52:15 -0400 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q8C6JMZF; Fri, 22 Aug 2003 12:52:15 -0400 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 84BF52D957; Fri, 22 Aug 2003 12:52:14 -0400 (EDT) Message-ID: <3F464A3E.2050203@nortelnetworks.com> Date: Fri, 22 Aug 2003 12:52:14 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Nivedita Singhvi Cc: Linux Kernel Mailing List , netdev@oss.sgi.com Subject: Re: help??? trying to trace code path of outgoing udp packet References: <3F46356A.804@nortelnetworks.com> <3F46386A.4080009@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5205 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfriesen@nortelnetworks.com Precedence: bulk X-list: netdev Content-Length: 632 Lines: 26 Nivedita Singhvi wrote: > Chris Friesen wrote: > >> ip_finish_output ip_output.c >> ip_finish_output2 ip_output.c dst->neighbour->output > > > | > V > dev_queue_xmit() > qdisc_run() > qdisc_restart() > dev->hard_start_xmit() [driver xmit routine] > > this is for the default queuing discipline. Thanks. That should give me enough to track down what I'm looking for. Chris -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com From davem@redhat.com Fri Aug 22 10:59:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Aug 2003 11:00:26 -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 h7MHxDoO008335 for ; Fri, 22 Aug 2003 10:59:54 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id KAA02118; Fri, 22 Aug 2003 10:50:16 -0700 Date: Fri, 22 Aug 2003 10:50:16 -0700 From: "David S. Miller" To: Kazunori Miyazawa Cc: latten@austin.ibm.com, netdev@oss.sgi.com Subject: Re: IPSecv6/Neighbor discovery crash Message-Id: <20030822105016.72e710b8.davem@redhat.com> In-Reply-To: <20030822145553.0ca08046.kazunori@miyazawa.org> References: <200308220149.h7M1nlAU017798@faith.austin.ibm.com> <20030821184640.2cb89b87.davem@redhat.com> <20030822145553.0ca08046.kazunori@miyazawa.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5206 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 Content-Length: 322 Lines: 9 On Fri, 22 Aug 2003 14:55:53 +0900 Kazunori Miyazawa wrote: > I guess it is due to xfrm cache. I don't think so, fl.fl_icmp_type will be different for ICMP echo flow lookup than for the ndisc ones. Therefore flow cache will not return the older ndisc stacked DST for the ICMP echo flow lookup. From yedok@hotmail.com Fri Aug 22 12:20:58 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Aug 2003 12:21:01 -0700 (PDT) Received: from hotmail.com (bay7-f42.bay7.hotmail.com [64.4.11.42]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7MJKwoO017456 for ; Fri, 22 Aug 2003 12:20:58 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 22 Aug 2003 12:20:53 -0700 Received: from 143.127.3.10 by by7fd.bay7.hotmail.msn.com with HTTP; Fri, 22 Aug 2003 19:20:52 GMT X-Originating-IP: [143.127.3.10] X-Originating-Email: [yedok@hotmail.com] From: "David Geller" To: linux-net@vger.kernel.org Cc: netdev@oss.sgi.com Subject: Why no dead gateway detection for Multipath routes? Date: Fri, 22 Aug 2003 12:20:52 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Aug 2003 19:20:53.0026 (UTC) FILETIME=[80DB5020:01C368E2] X-archive-position: 5207 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yedok@hotmail.com Precedence: bulk X-list: netdev Content-Length: 703 Lines: 18 Hi, Why doesn't linux do dead gateway detection for multipath routes? To be more specific, why isn't something like fib_detect_death() called inside fib_select_multipath(), whereas it is called in fib_select_default()? Isn't this a violation of the MUST part of section 3.3.1.4 of RFC 1122? 3.3.1.4 Dead Gateway Detection The IP layer MUST be able to detect the failure of a "next- hop" gateway that is listed in its route cache and to choose an alternate gateway (see Section 3.3.1.5). _________________________________________________________________ Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige using MSN Messenger http://www.msnmessenger-download.com/imastar From shemminger@osdl.org Fri Aug 22 13:04:57 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Aug 2003 13:05:06 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7MK4voO022820 for ; Fri, 22 Aug 2003 13:04:57 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7MK3Vo17037; Fri, 22 Aug 2003 13:03:32 -0700 Date: Fri, 22 Aug 2003 13:03:17 -0700 From: Stephen Hemminger To: James Morris Cc: Chad Tindel , Jay Vosburgh , "David S. Miller" , Jeff Garzik , , Subject: [PATCH] change /proc/bond0/info to /proc/bonding/bond0 Message-Id: <20030822130317.06d130d9.shemminger@osdl.org> In-Reply-To: References: <20030821165258.45f1ec53.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5208 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 4636 Lines: 138 On Fri, 22 Aug 2003 10:17:07 +1000 (EST) James Morris wrote: > On Thu, 21 Aug 2003, Stephen Hemminger wrote: > > > The name "/proc/net/bond0/info" is kind of unconventional, but now > > changing that in a almost stable release would be bad. Better choice > > would be "/proc/net/bonding/bond0". > > I'm not sure it's too late to do this. Changes the name of the /proc entry on 2.6.0-test3 with my earlier patch. Also, documentation and comments are updated. This version will work if the /proc creation fails; a warning is printed but see no reason to prevent module from loading. diff -Nru a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt --- a/Documentation/networking/bonding.txt Fri Aug 22 13:00:24 2003 +++ b/Documentation/networking/bonding.txt Fri Aug 22 13:00:24 2003 @@ -529,7 +529,7 @@ ---------------------------- The bonding driver information files reside in the /proc/net/bond* directories. -Sample contents of /proc/net/bond0/info after the driver is loaded with +Sample contents of /proc/net/bonding/bond0 after the driver is loaded with parameters of mode=0 and miimon=1000 is shown below. Bonding Mode: load balancing (round-robin) diff -Nru a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Fri Aug 22 13:00:24 2003 +++ b/drivers/net/bonding/bond_main.c Fri Aug 22 13:00:24 2003 @@ -119,7 +119,7 @@ * * 2001/6/01 - Chad N. Tindel * - Added /proc support for getting bond and slave information. - * Information is in /proc/net//info. + * Information is in /proc/net/bonding/ * - Changed the locking when calling bond_close to prevent deadlock. * * 2001/8/05 - Janice Girouard @@ -501,6 +501,7 @@ }; static LIST_HEAD(bond_dev_list); +static struct proc_dir_entry *bond_proc_dir; MODULE_PARM(max_bonds, "i"); MODULE_PARM_DESC(max_bonds, "Max number of bonded devices"); @@ -3607,27 +3608,21 @@ } #ifdef CONFIG_PROC_FS - bond->bond_proc_dir = proc_mkdir(dev->name, proc_net); - if (bond->bond_proc_dir == NULL) { - printk(KERN_ERR "%s: Cannot init /proc/net/%s/\n", - dev->name, dev->name); - return -ENOMEM; - } - bond->bond_proc_dir->owner = THIS_MODULE; - - bond->bond_proc_info_file = - create_proc_entry("info", 0, bond->bond_proc_dir); - if (bond->bond_proc_info_file == NULL) { - printk(KERN_ERR "%s: Cannot init /proc/net/%s/info\n", - dev->name, dev->name); - remove_proc_entry(dev->name, proc_net); - return -ENOMEM; + if (bond_proc_dir) { + bond->bond_proc_file = create_proc_entry(dev->name, + S_IRUGO, + bond_proc_dir); + if (bond->bond_proc_file == NULL) { + printk(KERN_WARNING "%s: Cannot create " + "/proc/net/bonding/%s\n", + dev->name, dev->name); + } else { + bond->bond_proc_file->data = bond; + bond->bond_proc_file->proc_fops = &bond_info_fops; + } } - bond->bond_proc_info_file->data = bond; - bond->bond_proc_info_file->proc_fops = &bond_info_fops; #endif /* CONFIG_PROC_FS */ - list_add_tail(&bond->bond_list, &bond_dev_list); return 0; } @@ -3908,6 +3903,15 @@ register_netdevice_notifier(&bond_netdev_notifier); +#ifdef CONFIG_PROC_FS + bond_proc_dir = proc_mkdir("bonding", proc_net); + if (bond_proc_dir == NULL) + printk(KERN_WARNING "bonding_init(): can not create " + "/proc/net/bonding"); + else + bond_proc_dir->owner = THIS_MODULE; +#endif + for (no = 0; no < max_bonds; no++) { struct net_device *dev; char name[IFNAMSIZ]; @@ -3943,13 +3947,15 @@ list_for_each_entry_safe(bond, nxt, &bond_dev_list, bond_list) { struct net_device *dev = bond->device; -#ifdef CONFIG_PROC_FS - remove_proc_entry("info", bond->bond_proc_dir); - remove_proc_entry(dev->name, proc_net); -#endif + + if (bond_proc_dir) + remove_proc_entry(dev->name, bond_proc_dir); unregister_netdev(dev); free_netdev(dev); } + + if (bond_proc_dir) + remove_proc_entry("bonding", proc_net); } module_init(bonding_init); diff -Nru a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h --- a/drivers/net/bonding/bonding.h Fri Aug 22 13:00:24 2003 +++ b/drivers/net/bonding/bonding.h Fri Aug 22 13:00:24 2003 @@ -101,8 +101,7 @@ struct timer_list arp_timer; struct net_device_stats *stats; #ifdef CONFIG_PROC_FS - struct proc_dir_entry *bond_proc_dir; - struct proc_dir_entry *bond_proc_info_file; + struct proc_dir_entry *bond_proc_file; #endif /* CONFIG_PROC_FS */ struct list_head bond_list; struct net_device *device; From shemminger@osdl.org Fri Aug 22 13:14:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Aug 2003 13:14:31 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7MKEPoO024780 for ; Fri, 22 Aug 2003 13:14:26 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7MKDgo18501; Fri, 22 Aug 2003 13:13:42 -0700 Date: Fri, 22 Aug 2003 13:13:28 -0700 From: Stephen Hemminger To: Jeroen Vreeken Cc: "David S . Miller" , linux-hams@vger.kernel.org, ralf@linux-mips.org, netdev@oss.sgi.com Subject: [PATCH] ax25 - make sure and hold ref to dev Message-Id: <20030822131328.1696430e.shemminger@osdl.org> In-Reply-To: <20030820204518.C5568@jeroen.pe1rxq.ampr.org> References: <20030812194653.A28977@jeroen.pe1rxq.ampr.org> <20030812135655.7334887b.shemminger@osdl.org> <20030812230951.E28977@jeroen.pe1rxq.ampr.org> <20030812153901.6e700dcb.shemminger@osdl.org> <20030813010301.K28977@jeroen.pe1rxq.ampr.org> <20030812172151.7de0c950.shemminger@osdl.org> <20030813031159.6c6c9629.davem@redhat.com> <20030813173446.A2604@jeroen.pe1rxq.ampr.org> <20030813084252.7b667fb8.davem@redhat.com> <20030820204518.C5568@jeroen.pe1rxq.ampr.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5209 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1262 Lines: 45 The lower layers of ax25 hold a reference to the underlying device but don't increment the ref count. This is safe because it does the right thing when UNREGISTER notification comes in, but it is better to do the right thing. I tested this by messing with bpqether and ax25 to make sure both can be unloaded correctly. diff -Nru a/net/ax25/ax25_dev.c b/net/ax25/ax25_dev.c --- a/net/ax25/ax25_dev.c Fri Aug 22 08:20:46 2003 +++ b/net/ax25/ax25_dev.c Fri Aug 22 08:20:46 2003 @@ -67,6 +67,7 @@ dev->ax25_ptr = ax25_dev; ax25_dev->dev = dev; + dev_hold(dev); ax25_dev->forward = NULL; ax25_dev->values[AX25_VALUES_IPDEFMODE] = AX25_DEF_IPDEFMODE; @@ -121,6 +122,7 @@ if ((s = ax25_dev_list) == ax25_dev) { ax25_dev_list = s->next; spin_unlock_bh(&ax25_dev_lock); + dev_put(dev); kfree(ax25_dev); ax25_register_sysctl(); return; @@ -130,6 +132,7 @@ if (s->next == ax25_dev) { s->next = ax25_dev->next; spin_unlock_bh(&ax25_dev_lock); + dev_put(dev); kfree(ax25_dev); ax25_register_sysctl(); return; @@ -196,8 +199,8 @@ ax25_dev = ax25_dev_list; while (ax25_dev != NULL) { s = ax25_dev; + dev_put(ax25_dev->dev); ax25_dev = ax25_dev->next; - kfree(s); } ax25_dev_list = NULL; From shemminger@osdl.org Fri Aug 22 13:37:19 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Aug 2003 13:37:26 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7MKaxoO028179 for ; Fri, 22 Aug 2003 13:37:18 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7MKG0o18870; Fri, 22 Aug 2003 13:16:01 -0700 Date: Fri, 22 Aug 2003 13:15:47 -0700 From: Stephen Hemminger To: Jeroen Vreeken Cc: "David S . Miller" , linux-hams@vger.kernel.org, ralf@linux-mips.org, netdev@oss.sgi.com Subject: [RFT][PATCH] ax25 using seq_file Message-Id: <20030822131547.0d95fb16.shemminger@osdl.org> In-Reply-To: <20030820204518.C5568@jeroen.pe1rxq.ampr.org> References: <20030812194653.A28977@jeroen.pe1rxq.ampr.org> <20030812135655.7334887b.shemminger@osdl.org> <20030812230951.E28977@jeroen.pe1rxq.ampr.org> <20030812153901.6e700dcb.shemminger@osdl.org> <20030813010301.K28977@jeroen.pe1rxq.ampr.org> <20030812172151.7de0c950.shemminger@osdl.org> <20030813031159.6c6c9629.davem@redhat.com> <20030813173446.A2604@jeroen.pe1rxq.ampr.org> <20030813084252.7b667fb8.davem@redhat.com> <20030820204518.C5568@jeroen.pe1rxq.ampr.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5210 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 11993 Lines: 460 Convert AX25 to use the seq_file interface for it's /proc hook. Jeroen could you test this with real hardware, since without hardware the table always comes up empty which is not a good enough test. diff -Nru a/include/net/ax25.h b/include/net/ax25.h --- a/include/net/ax25.h Fri Aug 22 08:21:10 2003 +++ b/include/net/ax25.h Fri Aug 22 08:21:10 2003 @@ -314,7 +314,7 @@ /* ax25_route.c */ extern void ax25_rt_device_down(struct net_device *); extern int ax25_rt_ioctl(unsigned int, void *); -extern int ax25_rt_get_info(char *, char **, off_t, int); +extern struct file_operations ax25_route_fops; extern int ax25_rt_autobind(ax25_cb *, ax25_address *); extern ax25_route *ax25_rt_find_route(ax25_route *, ax25_address *, struct net_device *); @@ -373,7 +373,7 @@ extern int ax25_uid_policy; extern ax25_address *ax25_findbyuid(uid_t); extern int ax25_uid_ioctl(int, struct sockaddr_ax25 *); -extern int ax25_uid_get_info(char *, char **, off_t, int); +extern struct file_operations ax25_uid_fops; extern void ax25_uid_free(void); /* sysctl_net_ax25.c */ diff -Nru a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c --- a/net/ax25/af_ax25.c Fri Aug 22 08:21:10 2003 +++ b/net/ax25/af_ax25.c Fri Aug 22 08:21:10 2003 @@ -1842,81 +1842,107 @@ return res; } -static int ax25_get_info(char *buffer, char **start, off_t offset, int length) +#ifdef CONFIG_PROC_FS + +static void *ax25_info_start(struct seq_file *seq, loff_t *pos) { - ax25_cb *ax25; - int k; - int len = 0; - off_t pos = 0; - off_t begin = 0; + struct ax25_cb *ax25; struct hlist_node *node; + int i = 0; spin_lock_bh(&ax25_list_lock); + ax25_for_each(ax25, node, &ax25_list) { + if (i == *pos) + return ax25; + ++i; + } + return NULL; +} + +static void *ax25_info_next(struct seq_file *seq, void *v, loff_t *pos) +{ + ++*pos; + + return hlist_entry( ((struct ax25_cb *)v)->ax25_node.next, + struct ax25_cb, ax25_node); +} + +static void ax25_info_stop(struct seq_file *seq, void *v) +{ + spin_unlock_bh(&ax25_list_lock); +} + +static int ax25_info_show(struct seq_file *seq, void *v) +{ + ax25_cb *ax25 = v; + int k; + /* * New format: * magic dev src_addr dest_addr,digi1,digi2,.. st vs vr va t1 t1 t2 t2 t3 t3 idle idle n2 n2 rtt window paclen Snd-Q Rcv-Q inode */ - ax25_for_each(ax25, node, &ax25_list) { - len += sprintf(buffer+len, "%8.8lx %s %s%s ", - (long) ax25, - ax25->ax25_dev == NULL? "???" : ax25->ax25_dev->dev->name, - ax2asc(&ax25->source_addr), - ax25->iamdigi? "*":""); - - len += sprintf(buffer+len, "%s", ax2asc(&ax25->dest_addr)); - - for (k=0; (ax25->digipeat != NULL) && (k < ax25->digipeat->ndigi); k++) { - len += sprintf(buffer+len, ",%s%s", - ax2asc(&ax25->digipeat->calls[k]), - ax25->digipeat->repeated[k]? "*":""); - } - - len += sprintf(buffer+len, " %d %d %d %d %lu %lu %lu %lu %lu %lu %lu %lu %d %d %lu %d %d", - ax25->state, - ax25->vs, ax25->vr, ax25->va, - ax25_display_timer(&ax25->t1timer) / HZ, ax25->t1 / HZ, - ax25_display_timer(&ax25->t2timer) / HZ, ax25->t2 / HZ, - ax25_display_timer(&ax25->t3timer) / HZ, ax25->t3 / HZ, - ax25_display_timer(&ax25->idletimer) / (60 * HZ), - ax25->idle / (60 * HZ), - ax25->n2count, ax25->n2, - ax25->rtt / HZ, - ax25->window, - ax25->paclen); - - if (ax25->sk != NULL) { - bh_lock_sock(ax25->sk); - len += sprintf(buffer + len, " %d %d %ld\n", - atomic_read(&ax25->sk->sk_wmem_alloc), - atomic_read(&ax25->sk->sk_rmem_alloc), - ax25->sk->sk_socket != NULL ? SOCK_INODE(ax25->sk->sk_socket)->i_ino : 0L); - bh_unlock_sock(ax25->sk); - } else { - len += sprintf(buffer + len, " * * *\n"); - } - - pos = begin + len; - - if (pos < offset) { - len = 0; - begin = pos; - } + seq_printf(seq, "%8.8lx %s %s%s ", + (long) ax25, + ax25->ax25_dev == NULL? "???" : ax25->ax25_dev->dev->name, + ax2asc(&ax25->source_addr), + ax25->iamdigi? "*":""); + seq_printf(seq, "%s", ax2asc(&ax25->dest_addr)); + + for (k=0; (ax25->digipeat != NULL) && (k < ax25->digipeat->ndigi); k++) { + seq_printf(seq, ",%s%s", + ax2asc(&ax25->digipeat->calls[k]), + ax25->digipeat->repeated[k]? "*":""); + } - if (pos > offset + length) - break; + seq_printf(seq, " %d %d %d %d %lu %lu %lu %lu %lu %lu %lu %lu %d %d %lu %d %d", + ax25->state, + ax25->vs, ax25->vr, ax25->va, + ax25_display_timer(&ax25->t1timer) / HZ, ax25->t1 / HZ, + ax25_display_timer(&ax25->t2timer) / HZ, ax25->t2 / HZ, + ax25_display_timer(&ax25->t3timer) / HZ, ax25->t3 / HZ, + ax25_display_timer(&ax25->idletimer) / (60 * HZ), + ax25->idle / (60 * HZ), + ax25->n2count, ax25->n2, + ax25->rtt / HZ, + ax25->window, + ax25->paclen); + + if (ax25->sk != NULL) { + bh_lock_sock(ax25->sk); + seq_printf(seq," %d %d %ld\n", + atomic_read(&ax25->sk->sk_wmem_alloc), + atomic_read(&ax25->sk->sk_rmem_alloc), + ax25->sk->sk_socket != NULL ? SOCK_INODE(ax25->sk->sk_socket)->i_ino : 0L); + bh_unlock_sock(ax25->sk); + } else { + seq_puts(seq, " * * *\n"); } + return 0; +} - spin_unlock_bh(&ax25_list_lock); +static struct seq_operations ax25_info_seqops = { + .start = ax25_info_start, + .next = ax25_info_next, + .stop = ax25_info_stop, + .show = ax25_info_show, +}; - *start = buffer + (offset - begin); - len -= (offset - begin); +static int ax25_info_open(struct inode *inode, struct file *file) +{ + return seq_open(file, &ax25_info_seqops); +} - if (len > length) len = length; +static struct file_operations ax25_info_fops = { + .owner = THIS_MODULE, + .open = ax25_info_open, + .read = seq_read, + .llseek = seq_lseek, + .release = seq_release, +}; - return(len); -} +#endif static struct net_proto_family ax25_family_ops = { .family = PF_AX25, @@ -1986,9 +2012,9 @@ register_netdevice_notifier(&ax25_dev_notifier); ax25_register_sysctl(); - proc_net_create("ax25_route", 0, ax25_rt_get_info); - proc_net_create("ax25", 0, ax25_get_info); - proc_net_create("ax25_calls", 0, ax25_uid_get_info); + proc_net_fops_create("ax25_route", S_IRUGO, &ax25_route_fops); + proc_net_fops_create("ax25", S_IRUGO, &ax25_info_fops); + proc_net_fops_create("ax25_calls", S_IRUGO, &ax25_uid_fops); printk(banner); return 0; diff -Nru a/net/ax25/ax25_route.c b/net/ax25/ax25_route.c --- a/net/ax25/ax25_route.c Fri Aug 22 08:21:10 2003 +++ b/net/ax25/ax25_route.c Fri Aug 22 08:21:10 2003 @@ -34,6 +34,7 @@ #include #include #include +#include static ax25_route *ax25_route_list; static rwlock_t ax25_route_lock = RW_LOCK_UNLOCKED; @@ -278,66 +279,100 @@ } } -int ax25_rt_get_info(char *buffer, char **start, off_t offset, int length) -{ - ax25_route *ax25_rt; - int len = 0; - off_t pos = 0; - off_t begin = 0; - char *callsign; - int i; +#ifdef CONFIG_PROC_FS - read_lock(&ax25_route_lock); +#define AX25_PROC_START ((void *)1) - len += sprintf(buffer, "callsign dev mode digipeaters\n"); +static void *ax25_rt_seq_start(struct seq_file *seq, loff_t *pos) +{ + struct ax25_route *ax25_rt; + int i = 1; + + read_lock(&ax25_route_lock); + if (*pos == 0) + return AX25_PROC_START; for (ax25_rt = ax25_route_list; ax25_rt != NULL; ax25_rt = ax25_rt->next) { + if (i == *pos) + return ax25_rt; + ++i; + } + + return NULL; +} + +static void *ax25_rt_seq_next(struct seq_file *seq, void *v, loff_t *pos) +{ + ++*pos; + return (v == AX25_PROC_START) ? ax25_route_list : + ((struct ax25_route *) v)->next; +} + +static void ax25_rt_seq_stop(struct seq_file *seq, void *v) +{ + read_unlock(&ax25_route_lock); +} + +static int ax25_rt_seq_show(struct seq_file *seq, void *v) +{ + if (v == AX25_PROC_START) + seq_puts(seq, "callsign dev mode digipeaters\n"); + else { + struct ax25_route *ax25_rt = v; + const char *callsign; + int i; + if (ax25cmp(&ax25_rt->callsign, &null_ax25_address) == 0) callsign = "default"; else callsign = ax2asc(&ax25_rt->callsign); - len += sprintf(buffer + len, "%-9s %-4s", + + seq_printf(seq, "%-9s %-4s", callsign, ax25_rt->dev ? ax25_rt->dev->name : "???"); switch (ax25_rt->ip_mode) { case 'V': - len += sprintf(buffer + len, " vc"); + seq_puts(seq, " vc"); break; case 'D': - len += sprintf(buffer + len, " dg"); + seq_puts(seq, " dg"); break; default: - len += sprintf(buffer + len, " *"); + seq_puts(seq, " *"); break; } if (ax25_rt->digipeat != NULL) for (i = 0; i < ax25_rt->digipeat->ndigi; i++) - len += sprintf(buffer + len, " %s", ax2asc(&ax25_rt->digipeat->calls[i])); - - len += sprintf(buffer + len, "\n"); + seq_printf(seq, " %s", ax2asc(&ax25_rt->digipeat->calls[i])); - pos = begin + len; - - if (pos < offset) { - len = 0; - begin = pos; - } - - if (pos > offset + length) - break; + seq_puts(seq, "\n"); } - read_unlock(&ax25_route_lock); - - *start = buffer + (offset - begin); - len -= (offset - begin); + return 0; +} - if (len > length) - len = length; +static struct seq_operations ax25_rt_seqops = { + .start = ax25_rt_seq_start, + .next = ax25_rt_seq_next, + .stop = ax25_rt_seq_stop, + .show = ax25_rt_seq_show, +}; - return len; +static int ax25_rt_info_open(struct inode *inode, struct file *file) +{ + return seq_open(file, &ax25_rt_seqops); } + +struct file_operations ax25_route_fops = { + .owner = THIS_MODULE, + .open = ax25_rt_info_open, + .read = seq_read, + .llseek = seq_lseek, + .release = seq_release, +}; + +#endif /* * Find AX.25 route diff -Nru a/net/ax25/ax25_uid.c b/net/ax25/ax25_uid.c --- a/net/ax25/ax25_uid.c Fri Aug 22 08:21:10 2003 +++ b/net/ax25/ax25_uid.c Fri Aug 22 08:21:10 2003 @@ -30,6 +30,7 @@ #include #include #include +#include #include #include #include @@ -141,39 +142,73 @@ return -EINVAL; /*NOTREACHED */ } -int ax25_uid_get_info(char *buffer, char **start, off_t offset, int length) +#ifdef CONFIG_PROC_FS + +#define AX25_PROC_START ((void *)1) + +static void *ax25_uid_seq_start(struct seq_file *seq, loff_t *pos) { - ax25_uid_assoc *pt; - int len = 0; - off_t pos = 0; - off_t begin = 0; + struct ax25_uid_assoc *pt; + int i = 1; read_lock(&ax25_uid_lock); - len += sprintf(buffer, "Policy: %d\n", ax25_uid_policy); + if (*pos == 0) + return AX25_PROC_START; for (pt = ax25_uid_list; pt != NULL; pt = pt->next) { - len += sprintf(buffer + len, "%6d %s\n", pt->uid, ax2asc(&pt->call)); - - pos = begin + len; + if (i == *pos) + return pt; + ++i; + } + return NULL; +} - if (pos < offset) { - len = 0; - begin = pos; - } +static void *ax25_uid_seq_next(struct seq_file *seq, void *v, loff_t *pos) +{ + ++*pos; + return (v == AX25_PROC_START) ? ax25_uid_list : + ((struct ax25_uid_assoc *) v)->next; +} - if (pos > offset + length) - break; - } +static void ax25_uid_seq_stop(struct seq_file *seq, void *v) +{ read_unlock(&ax25_uid_lock); +} + +static int ax25_uid_seq_show(struct seq_file *seq, void *v) +{ + if (v == AX25_PROC_START) + seq_printf(seq, "Policy: %d\n", ax25_uid_policy); + else { + struct ax25_uid_assoc *pt = v; + - *start = buffer + (offset - begin); - len -= offset - begin; + seq_printf(seq, "%6d %s\n", pt->uid, ax2asc(&pt->call)); + } + return 0; +} - if (len > length) - len = length; +static struct seq_operations ax25_uid_seqops = { + .start = ax25_uid_seq_start, + .next = ax25_uid_seq_next, + .stop = ax25_uid_seq_stop, + .show = ax25_uid_seq_show, +}; - return len; +static int ax25_uid_info_open(struct inode *inode, struct file *file) +{ + return seq_open(file, &ax25_uid_seqops); } + +struct file_operations ax25_uid_fops = { + .owner = THIS_MODULE, + .open = ax25_uid_info_open, + .read = seq_read, + .llseek = seq_lseek, + .release = seq_release, +}; + +#endif /* * Free all memory associated with UID/Callsign structures. From latten@austin.ibm.com Fri Aug 22 16:03:12 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Aug 2003 16:03:44 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7MN2VoO016403 for ; Fri, 22 Aug 2003 16:03:12 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h7MN1oEh371662; Fri, 22 Aug 2003 19:01:50 -0400 Received: from austin.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h7MN1nO9165006; Fri, 22 Aug 2003 17:01:49 -0600 Received: from faith.austin.ibm.com (faith.austin.ibm.com [9.41.94.16]) by austin.ibm.com (8.12.9/8.12.9) with ESMTP id h7MN1mN2088568; Fri, 22 Aug 2003 18:01:48 -0500 Received: from faith.austin.ibm.com (localhost.localdomain [127.0.0.1]) by faith.austin.ibm.com (8.12.5/8.12.8) with ESMTP id h7MNCBKn019007; Fri, 22 Aug 2003 18:12:11 -0500 Received: (from jml@localhost) by faith.austin.ibm.com (8.12.5/8.12.5/Submit) id h7MNCAJl019005; Fri, 22 Aug 2003 18:12:10 -0500 Date: Fri, 22 Aug 2003 18:12:10 -0500 From: latten@austin.ibm.com Message-Id: <200308222312.h7MNCAJl019005@faith.austin.ibm.com> To: davem@redhat.com, kazunori@miyazawa.org Subject: Re: IPSecv6/Neighbor discovery crash Cc: netdev@oss.sgi.com X-archive-position: 5212 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: latten@austin.ibm.com Precedence: bulk X-list: netdev Content-Length: 1829 Lines: 62 I tried my old standby of putting a few printk's to help debug. I put them in ndisc_output() and ndisc_build_ll_hdr() and they get printed out ok except when the crash occurs. I get absolutely nothing. So I do not know where or what are some of the values ndisc_output() or ndisc_build_ll_addr() are using. Nothing gets written to my log file when I do the ping6. I too had been thinking similar to Miyazawa-san... Joy On Thu, 21 Aug 2003 18:46:40 -0700 "David S. Miller" wrote: > On Thu, 21 Aug 2003 20:49:47 -0500 > latten@austin.ibm.com wrote: > > > EIP is at ndisc_build_ll_hdr+0x17/0x1e0 > > So what exactly is NULL in ndisc_build_ll_hdr(), is > it 'dev'? That'd be really weird... > I had same crach. I guess it is due to xfrm cache. My impression about the problem is likes this. When we configure IPsec and src and dst of neighbour discoery match the configuration occasionally, The kernel creates and caches the stackable dst like this because ndisc_send_* want to use it dst->output(ah6_output) +- child->output(ndisc_output) Then it receives icmpv6 echo request. It replys by using the cached stackable dst like above. The kernel however must use another stackable dst like dst->output(ah6_output) +- child->output(ip6_output) It is the issue. The kernel can not tell first stackable dst from second stackable dst because it can not know the last output function. I believe we need to change the kernel to use ip6_output ( or another common output function) to send neighbour discovery packet instead of ndisc_output essentially. But it may make the kernel be unstable. I think there is not so much request to use IPsec with neighbour discovery. I think it is better to remove xfrm_lookup from ndisc_send_* functions at the moment. Best regards, --Kazunori Miyazawa From davem@redhat.com Fri Aug 22 16:06:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Aug 2003 16:07:06 -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 h7MN5qoO017303 for ; Fri, 22 Aug 2003 16:06:33 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id PAA03144; Fri, 22 Aug 2003 15:58:12 -0700 Date: Fri, 22 Aug 2003 15:58:12 -0700 From: "David S. Miller" To: latten@austin.ibm.com Cc: kazunori@miyazawa.org, netdev@oss.sgi.com Subject: Re: IPSecv6/Neighbor discovery crash Message-Id: <20030822155812.06ab718f.davem@redhat.com> In-Reply-To: <200308222312.h7MNCAJl019005@faith.austin.ibm.com> References: <200308222312.h7MNCAJl019005@faith.austin.ibm.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5213 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 Content-Length: 641 Lines: 21 On Fri, 22 Aug 2003 18:12:10 -0500 latten@austin.ibm.com wrote: > So I do not know where or what are some of > the values ndisc_output() or ndisc_build_ll_addr() are using. > Nothing gets written to my log file when I do the ping6. ... > > > EIP is at ndisc_build_ll_hdr+0x17/0x1e0 Why not save yourself all that debugging effort and just use gdb on the kernel image and: (gdb) x/10i ndisc_build_ll_hdr+0x17 then match that assembler up with the output of: bash$ make net/ipv6/ndisc.s I'm flabbergasted that someone would resort to printk()'s to figure out the precise location of this OOPS when the OOPS says exactly the location :( From latten@austin.ibm.com Fri Aug 22 18:01:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Aug 2003 18:02:18 -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 h7N113oO022295 for ; Fri, 22 Aug 2003 18:01:44 -0700 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e33.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h7N10Oj3330788; Fri, 22 Aug 2003 21:00:24 -0400 Received: from austin.ibm.com (d03av03.boulder.ibm.com [9.17.193.83]) by westrelay03.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h7N10Nvq325422; Fri, 22 Aug 2003 19:00:24 -0600 Received: from faith.austin.ibm.com (faith.austin.ibm.com [9.41.94.16]) by austin.ibm.com (8.12.9/8.12.9) with ESMTP id h7N10NN2093530; Fri, 22 Aug 2003 20:00:23 -0500 Received: from faith.austin.ibm.com (localhost.localdomain [127.0.0.1]) by faith.austin.ibm.com (8.12.5/8.12.8) with ESMTP id h7N1AlKn019143; Fri, 22 Aug 2003 20:10:47 -0500 Received: (from jml@localhost) by faith.austin.ibm.com (8.12.5/8.12.5/Submit) id h7N1AkOc019141; Fri, 22 Aug 2003 20:10:47 -0500 Date: Fri, 22 Aug 2003 20:10:47 -0500 From: latten@austin.ibm.com Message-Id: <200308230110.h7N1AkOc019141@faith.austin.ibm.com> To: davem@redhat.com Subject: Re: IPSecv6/Neighbor discovery crash Cc: kazunori@miyazawa.org, netdev@oss.sgi.com X-archive-position: 5214 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: latten@austin.ibm.com Precedence: bulk X-list: netdev Content-Length: 785 Lines: 30 Sighhhhh and red-face.... I won't make that mistake again. I'm learning. OK, yes, it seems to be complaining about dev->hard_header... Joy On Fri, 22 Aug 2003 18:12:10 -0500 latten@austin.ibm.com wrote: > So I do not know where or what are some of > the values ndisc_output() or ndisc_build_ll_addr() are using. > Nothing gets written to my log file when I do the ping6. ... > > > EIP is at ndisc_build_ll_hdr+0x17/0x1e0 Why not save yourself all that debugging effort and just use gdb on the kernel image and: (gdb) x/10i ndisc_build_ll_hdr+0x17 then match that assembler up with the output of: bash$ make net/ipv6/ndisc.s I'm flabbergasted that someone would resort to printk()'s to figure out the precise location of this OOPS when the OOPS says exactly the location :( From MAILER-DAEMON@oss.sgi.com Fri Aug 22 23:07:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 22 Aug 2003 23:08:28 -0700 (PDT) Received: from smtp-out2.iol.cz (smtp-out2.iol.cz [194.228.2.87]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7N672oO003280 for ; Fri, 22 Aug 2003 23:07:43 -0700 Received: from smtp-in.iol.cz (12.10.168.192.in-addr.arpa [192.168.10.12]) by smtp-out2.iol.cz (Internet on Line ESMTP server) with ESMTP id B30013592D for ; Sat, 23 Aug 2003 07:37:10 +0200 (CEST) Received: from process-daemon.mta-in1.iol.cz by mta-in1.iol.cz (Internet on Line ESMTP Server) id <0HK200J014T2QI@mta-in1.iol.cz> for netdev@oss.sgi.com; Sat, 23 Aug 2003 07:37:10 +0200 (MEST) Received: from mta-in1.iol.cz (Internet on Line ESMTP Server) id <0HK200J2E4XXQE@mta-in1.iol.cz>; Sat, 23 Aug 2003 07:37:10 +0200 (MEST) Date: Sat, 23 Aug 2003 07:37:10 +0200 (MEST) From: Internet on Line Mail Delivery Subject: Delivery Notification: Delivery has failed To: netdev@oss.sgi.com Message-id: <0HK200J2I4XYQE@mta-in1.iol.cz> MIME-version: 1.0 Content-type: multipart/report; boundary="Boundary_(ID_Q3TLP4hemtqYeRlFj/sDSw)"; report-type=delivery-status X-archive-position: 5215 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: postmaster@iol.cz Precedence: bulk X-list: netdev Content-Length: 3608 Lines: 91 --Boundary_(ID_Q3TLP4hemtqYeRlFj/sDSw) Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT This report relates to a message you sent with the following header fields: Return-path: Received: from tcp-daemon.mta-in1.iol.cz by mta-in1.iol.cz (Internet on Line ESMTP Server) id <0HK200J2E4XXQE@mta-in1.iol.cz> (original mail from netdev@oss.sgi.com); Sat, 23 Aug 2003 07:37:10 +0200 (MEST) Received: from YZC ([218.79.139.244]) by mta-in1.iol.cz (Internet on Line ESMTP Server) id <0HK200J013Q5OR@mta-in1.iol.cz> (original mail from netdev@oss.sgi.com) for iolpostmaster@imaginet.cz (ORCPT postmaster@iol.cz); Sat, 23 Aug 2003 07:37:09 +0200 (MEST) Received: from YZC ([218.79.139.244]) by mta-in1.iol.cz (Internet on Line ESMTP Server) with ESMTP id <0HK200I094XCX7@mta-in1.iol.cz> for postmaster+filtered@iol.cz (ORCPT postmaster@iol.cz); Sat, 23 Aug 2003 07:37:09 +0200 (MEST) Date: Sat, 23 Aug 2003 13:32:47 +0800 From: netdev@oss.sgi.com Subject: Re: Approved To: postmaster@iol.cz Message-id: <0HK200I0B4XEX7@mta-in1.iol.cz> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: multipart/mixed; boundary="Boundary_(ID_SraHn+BEPawb0hDPzHWcQQ)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-MailScanner: Found to be clean Your message cannot be delivered to the following recipients: Recipient address: postmaster@iol.cz Original address: postmaster@iol.cz Reason: SMTP transmission failure has occurred Diagnostic code: smtp;550 Error: Rejected, probably sent by a W32.HLLW.Mankx virus Remote system: dns;smarthost.iol.cz (TCP|192.168.10.12|35277|194.228.2.71|25) (smtp-out1.iol.cz ESMTP server [Internet on Line]) --Boundary_(ID_Q3TLP4hemtqYeRlFj/sDSw) Content-type: message/delivery-status Original-envelope-id: 0HK200J4Z4XXOR@mta-in1.iol.cz Reporting-MTA: dns;mta-in1.iol.cz (tcp-daemon) Original-recipient: rfc822;postmaster@iol.cz Final-recipient: rfc822;postmaster@iol.cz Action: failed Status: 5.0.0 (SMTP transmission failure has occurred) Remote-MTA: dns;smarthost.iol.cz (TCP|192.168.10.12|35277|194.228.2.71|25) (smtp-out1.iol.cz ESMTP server [Internet on Line]) Diagnostic-code: smtp;550 Error: Rejected, probably sent by a W32.HLLW.Mankx virus --Boundary_(ID_Q3TLP4hemtqYeRlFj/sDSw) Content-type: TEXT/RFC822-HEADERS Return-path: Received: from tcp-daemon.mta-in1.iol.cz by mta-in1.iol.cz (Internet on Line ESMTP Server) id <0HK200J2E4XXQE@mta-in1.iol.cz> (original mail from netdev@oss.sgi.com); Sat, 23 Aug 2003 07:37:10 +0200 (MEST) Received: from YZC ([218.79.139.244]) by mta-in1.iol.cz (Internet on Line ESMTP Server) id <0HK200J013Q5OR@mta-in1.iol.cz> (original mail from netdev@oss.sgi.com) for iolpostmaster@imaginet.cz (ORCPT postmaster@iol.cz); Sat, 23 Aug 2003 07:37:09 +0200 (MEST) Received: from YZC ([218.79.139.244]) by mta-in1.iol.cz (Internet on Line ESMTP Server) with ESMTP id <0HK200I094XCX7@mta-in1.iol.cz> for postmaster+filtered@iol.cz (ORCPT postmaster@iol.cz); Sat, 23 Aug 2003 07:37:09 +0200 (MEST) Date: Sat, 23 Aug 2003 13:32:47 +0800 From: netdev@oss.sgi.com Subject: Re: Approved To: postmaster@iol.cz Message-id: <0HK200I0B4XEX7@mta-in1.iol.cz> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: TEXT/PLAIN Content-transfer-encoding: QUOTED-PRINTABLE Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-MailScanner: Found to be clean --Boundary_(ID_Q3TLP4hemtqYeRlFj/sDSw)-- From vinay-rc@naturesoft.net Sat Aug 23 01:50:07 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 23 Aug 2003 01:50:40 -0700 (PDT) Received: from naturesoft.net ([203.145.184.221]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7N8nHoO013942 for ; Sat, 23 Aug 2003 01:50:05 -0700 Received: from [192.168.0.15] (helo=lima.royalchallenge.com) by naturesoft.net with esmtp (Exim 3.35 #1) id 19qTzb-0000sA-00; Sat, 23 Aug 2003 14:13:27 +0530 Subject: [PATCH 2.6.0-test4][ATM][RESEND] fix ambassador.c From: Vinay K Nallamothu To: netdev@oss.sgi.com Cc: LKML Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 23 Aug 2003 14:41:31 +0530 Message-Id: <1061629891.1121.7.camel@lima.royalchallenge.com> Mime-Version: 1.0 X-archive-position: 5216 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vinay-rc@naturesoft.net Precedence: bulk X-list: netdev Content-Length: 5369 Lines: 207 Hi, This patch cleans up the code making use of sti/cli. drivers/atm/ambassador.c: 1. remove the function dont_panic which is mostly unused. 2. remove amb_ioctl which is never used. 3. minor timer code cleanups ambassador.c | 132 ++--------------------------------------------------------- 1 files changed, 6 insertions(+), 126 deletions(-) diff -urN linux-2.6.0-test3-bk9/drivers/atm/ambassador.c linux-2.6.0-test3-nvk/drivers/atm/ambassador.c --- linux-2.6.0-test3-bk9/drivers/atm/ambassador.c 2003-08-22 15:04:47.000000000 +0530 +++ linux-2.6.0-test3-nvk/drivers/atm/ambassador.c 2003-08-22 14:56:11.000000000 +0530 @@ -310,10 +310,11 @@ 0xdeadbeef }; +static void do_housekeeping (unsigned long arg); /********** globals **********/ static amb_dev * amb_devs = NULL; -static struct timer_list housekeeping; +static struct timer_list housekeeping = TIMER_INITIALIZER(do_housekeeping, 0, 1); static unsigned short debug = 0; static unsigned int cmds = 8; @@ -937,63 +938,6 @@ return IRQ_HANDLED; } -/********** don't panic... yeah, right **********/ - -#ifdef DEBUG_AMBASSADOR -static void dont_panic (amb_dev * dev) { - amb_cq * cq = &dev->cq; - volatile amb_cq_ptrs * ptrs = &cq->ptrs; - amb_txq * txq; - amb_rxq * rxq; - command * cmd; - tx_in * tx; - tx_simple * tx_descr; - unsigned char pool; - rx_in * rx; - - unsigned long flags; - save_flags (flags); - cli(); - - PRINTK (KERN_INFO, "don't panic - putting adapter into reset"); - wr_plain (dev, offsetof(amb_mem, reset_control), - rd_plain (dev, offsetof(amb_mem, reset_control)) | AMB_RESET_BITS); - - PRINTK (KERN_INFO, "marking all commands complete"); - for (cmd = ptrs->start; cmd < ptrs->limit; ++cmd) - cmd->request = cpu_to_be32 (SRB_COMPLETE); - - PRINTK (KERN_INFO, "completing all TXs"); - txq = &dev->txq; - tx = txq->in.ptr; - while (txq->pending--) { - if (tx == txq->in.start) - tx = txq->in.limit; - --tx; - tx_descr = bus_to_virt (be32_to_cpu (tx->tx_descr_addr)); - amb_kfree_skb (tx_descr->skb); - kfree (tx_descr); - } - - PRINTK (KERN_INFO, "freeing all RX buffers"); - for (pool = 0; pool < NUM_RX_POOLS; ++pool) { - rxq = &dev->rxq[pool]; - rx = rxq->in.ptr; - while (rxq->pending--) { - if (rx == rxq->in.start) - rx = rxq->in.limit; - --rx; - dev_kfree_skb_any (bus_to_virt (rx->handle)); - } - } - - PRINTK (KERN_INFO, "don't panic over - close all VCs and rmmod"); - set_bit (dead, &dev->flags); - restore_flags (flags); - return; -} -#endif - /********** make rate (not quite as much fun as Horizon) **********/ static unsigned int make_rate (unsigned int rate, rounding r, @@ -1420,32 +1364,6 @@ return; } -/********** DebugIoctl **********/ - -#if 0 -static int amb_ioctl (struct atm_dev * dev, unsigned int cmd, void * arg) { - unsigned short newdebug; - if (cmd == AMB_SETDEBUG) { - if (!capable(CAP_NET_ADMIN)) - return -EPERM; - if (copy_from_user (&newdebug, arg, sizeof(newdebug))) { - // moan - return -EFAULT; - } else { - debug = newdebug; - return 0; - } - } else if (cmd == AMB_DONTPANIC) { - if (!capable(CAP_NET_ADMIN)) - return -EPERM; - dont_panic (dev); - } else { - // moan - return -ENOIOCTLCMD; - } -} -#endif - /********** Set socket options for a VC **********/ // int amb_getsockopt (struct atm_vcc * atm_vcc, int level, int optname, void * optval, int optlen); @@ -1524,33 +1442,6 @@ tx.tx_descr_length = cpu_to_be16 (sizeof(tx_frag)+sizeof(tx_frag_end)); tx.tx_descr_addr = cpu_to_be32 (virt_to_bus (&tx_descr->tx_frag)); -#ifdef DEBUG_AMBASSADOR - /* wey-hey! */ - if (vc == 1023) { - unsigned int i; - unsigned short d = 0; - char * s = skb->data; - switch (*s++) { - case 'D': { - for (i = 0; i < 4; ++i) { - d = (d<<4) | ((*s <= '9') ? (*s - '0') : (*s - 'a' + 10)); - ++s; - } - PRINTK (KERN_INFO, "debug bitmap is now %hx", debug = d); - break; - } - case 'R': { - if (*s++ == 'e' && *s++ == 's' && *s++ == 'e' && *s++ == 't') - dont_panic (dev); - break; - } - default: { - break; - } - } - } -#endif - while (tx_give (dev, &tx)) schedule(); return 0; @@ -1663,21 +1554,14 @@ /********** Operation Structure **********/ static const struct atmdev_ops amb_ops = { - .open = amb_open, + .open = amb_open, .close = amb_close, - .send = amb_send, + .send = amb_send, .proc_read = amb_proc_read, .owner = THIS_MODULE, }; /********** housekeeping **********/ - -static inline void set_timer (struct timer_list * timer, unsigned long delay) { - timer->expires = jiffies + delay; - add_timer (timer); - return; -} - static void do_housekeeping (unsigned long arg) { amb_dev * dev = amb_devs; // data is set to zero at module unload @@ -1693,7 +1577,7 @@ dev = dev->prev; } - set_timer (&housekeeping, 10*HZ); + mod_timer(&housekeeping, jiffies + 10*HZ); } return; @@ -2579,11 +2463,7 @@ devs = amb_probe(); if (devs) { - init_timer (&housekeeping); - housekeeping.function = do_housekeeping; - // paranoia - housekeeping.data = 1; - set_timer (&housekeeping, 0); + mod_timer (&housekeeping, jiffies); } else { PRINTK (KERN_INFO, "no (usable) adapters found"); } From vinay-rc@naturesoft.net Sat Aug 23 05:51:51 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 23 Aug 2003 05:52:25 -0700 (PDT) Received: from naturesoft.net ([203.145.184.221]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7NCp9oO029173 for ; Sat, 23 Aug 2003 05:51:50 -0700 Received: from [192.168.0.15] (helo=lima.royalchallenge.com) by naturesoft.net with esmtp (Exim 3.35 #1) id 19qXlh-0005jB-00; Sat, 23 Aug 2003 18:15:21 +0530 Subject: [PATCH 2.6.0-test4][NET] 3c509.c: remove device.name field From: Vinay K Nallamothu To: netdev@oss.sgi.com Cc: LKML Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 23 Aug 2003 18:43:29 +0530 Message-Id: <1061644409.1141.18.camel@lima.royalchallenge.com> Mime-Version: 1.0 X-archive-position: 5219 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vinay-rc@naturesoft.net Precedence: bulk X-list: netdev Content-Length: 488 Lines: 17 Hi, This patch removes the device name field which is no longer present. --- linux-2.6.0-test4/drivers/net/3c509.c 2003-08-23 13:14:30.000000000 +0530 +++ linux-2.6.0-test4-nvk/drivers/net/3c509.c 2003-08-23 18:34:35.000000000 +0530 @@ -629,8 +629,6 @@ el3_mca_adapter_names[mdev->index], slot + 1); /* claim the slot */ - strncpy(device->name, el3_mca_adapter_names[mdev->index], - sizeof(device->name)); mca_device_set_claim(mdev, 1); if_port = pos4 & 0x03; From vinay-rc@naturesoft.net Sat Aug 23 06:00:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 23 Aug 2003 06:01:15 -0700 (PDT) Received: from naturesoft.net ([203.145.184.221]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7NCxwoO029881 for ; Sat, 23 Aug 2003 06:00:40 -0700 Received: from [192.168.0.15] (helo=lima.royalchallenge.com) by naturesoft.net with esmtp (Exim 3.35 #1) id 19qXuD-0005xk-00; Sat, 23 Aug 2003 18:24:10 +0530 Subject: [PATCH 2.6.0-test4][NET] sk_mca.c: fix linker error From: Vinay K Nallamothu To: netdev@oss.sgi.com Cc: LKML Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 23 Aug 2003 18:52:18 +0530 Message-Id: <1061644938.2787.22.camel@lima.royalchallenge.com> Mime-Version: 1.0 X-archive-position: 5220 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vinay-rc@naturesoft.net Precedence: bulk X-list: netdev Content-Length: 473 Lines: 18 Hi, This patch fixes the following linker error due to a typo: *** Warning: "spin_lock_irqrestore" [drivers/net/sk_mca.ko] undefined! --- linux-2.6.0-test4/drivers/net/sk_mca.c 2003-07-28 10:43:57.000000000 +0530 +++ linux-2.6.0-test4-nvk/drivers/net/sk_mca.c 2003-08-23 18:47:55.000000000 +0530 @@ -280,7 +280,7 @@ /* reenable interrupts */ - spin_lock_irqrestore(&priv->lock, flags); + spin_unlock_irqrestore(&priv->lock, flags); } /* get LANCE register */ From vinay-rc@naturesoft.net Sat Aug 23 06:23:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 23 Aug 2003 06:24:10 -0700 (PDT) Received: from naturesoft.net ([203.145.184.221]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7NDMsoO031400 for ; Sat, 23 Aug 2003 06:23:36 -0700 Received: from [192.168.0.15] (helo=lima.royalchallenge.com) by naturesoft.net with esmtp (Exim 3.35 #1) id 19qYGQ-0006OJ-00; Sat, 23 Aug 2003 18:47:06 +0530 Subject: Re: [PATCH 2.6.0-test4][NET] sk_mca.c: fix linker error From: Vinay K Nallamothu To: Vinay K Nallamothu Cc: netdev@oss.sgi.com, LKML In-Reply-To: <1061644938.2787.22.camel@lima.royalchallenge.com> References: <1061644938.2787.22.camel@lima.royalchallenge.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 23 Aug 2003 19:15:15 +0530 Message-Id: <1061646315.1141.26.camel@lima.royalchallenge.com> Mime-Version: 1.0 X-archive-position: 5221 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vinay-rc@naturesoft.net Precedence: bulk X-list: netdev Content-Length: 963 Lines: 38 On Sat, 2003-08-23 at 18:52, Vinay K Nallamothu wrote: > Hi, > > This patch fixes the following linker error due to a typo: > > *** Warning: "spin_lock_irqrestore" [drivers/net/sk_mca.ko] undefined! Oops. missed out few more. Here is the updated patch. --- linux-2.6.0-test4/drivers/net/sk_mca.c 2003-07-28 10:43:57.000000000 +0530 +++ linux-2.6.0-test4-nvk/drivers/net/sk_mca.c 2003-08-23 19:12:16.000000000 +0530 @@ -280,7 +280,7 @@ /* reenable interrupts */ - spin_lock_irqrestore(&priv->lock, flags); + spin_unlock_irqrestore(&priv->lock, flags); } /* get LANCE register */ @@ -319,7 +319,7 @@ /* reenable interrupts */ - spin_lock_irqrestore(&priv->lock, flags); + spin_unlock_irqrestore(&priv->lock, flags); return res; } @@ -993,7 +993,7 @@ if (priv->txbusy == 0) SetLANCE(dev, LANCE_CSR0, CSR0_INEA | CSR0_TDMD); - spin_lock_irqrestore(&priv->lock, flags); + spin_unlock_irqrestore(&priv->lock, flags); tx_done: From shmulik.hen@intel.com Sat Aug 23 06:35:55 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 23 Aug 2003 06:36:33 -0700 (PDT) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7NDZCoO032137 for ; Sat, 23 Aug 2003 06:35:54 -0700 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.76 2003/08/21 22:58:26 rfjohns1 Exp $) with ESMTP id h7NDThj21507 for ; Sat, 23 Aug 2003 13:29:43 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h7NDcAg15010 for ; Sat, 23 Aug 2003 13:38:10 GMT Received: from hasmsx331.ger.corp.intel.com ([143.185.63.144]) by hasmsxvs01.iil.intel.com (NAVGW 2.5.2.11) with SMTP id M2003082316350214905 ; Sat, 23 Aug 2003 16:35:02 +0300 Received: from hasmsx403.ger.corp.intel.com ([143.185.63.109]) by hasmsx331.ger.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 23 Aug 2003 16:35:02 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [PATCH] convering bonding driver /proc interface to seq_file Date: Sat, 23 Aug 2003 16:35:02 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] convering bonding driver /proc interface to seq_file Thread-Index: AcNoSkcEN+t2IRI/TqCyY6qO/WMKPgBLszsQ From: "Hen, Shmulik" To: "Stephen Hemminger" , "Chad Tindel" , "Jay Vosburgh" , "David S. Miller" , "Jeff Garzik" Cc: , X-OriginalArrivalTime: 23 Aug 2003 13:35:02.0565 (UTC) FILETIME=[5B07FD50:01C3697B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7NDZCoO032137 X-archive-position: 5222 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Content-Length: 13207 Lines: 450 Guys, We have already submitted a patch that does the exact same thing (give back info only for the queried bond) that is sitting in Jeff's net-drivers queue. It is a part of a whole set of patches meant to get the 2.4 and 2.6 versions synched (referred to as back porting patch set, or set #1). The patch set is being held until Marcelo goes to 2.4.23-pre1. Jeff also said something about reservation he might have about that set, so we're still waiting. Could everyone please hold off the bonding modifications for only a short while until we get this sorted out? We have a bunch of other patch sets in queue that add lots of new stuff and they all depend on that first set being accepted. If I'm asking for too much, let me know, but do it gently :) -- | Shmulik Hen Advanced Network Services | | Israel Design Center, Jerusalem | | LAN Access Division, Platform Networking | | Intel Communications Group, Intel corp. | > -----Original Message----- > From: Stephen Hemminger [mailto:shemminger@osdl.org] > Sent: Friday, August 22, 2003 2:53 AM > To: Chad Tindel; Jay Vosburgh; David S. Miller; Jeff Garzik > Cc: bonding-devel@lists.sourceforge.net; netdev@oss.sgi.com > Subject: [PATCH] convering bonding driver /proc interface to seq_file > > > This patch converts /proc/net/bondXX/info to the seq_file interface; > patch is against 2.6.0-test3; but seq_file has been > backported to latest > 2.4 as well. > > It also fixes a bug with multiple bond devices. The original code > mushes all the bond device status information together. In > other words, > /proc/net/bond0/info gives the same output as /proc/net/bond1/info. > > I fixed this in this version, by stuffing a link back to the bonding > data structure in the created proc_dir_entry; which is then used > to only pickup the slaves for that pseudo-device. > > Don't think anyone ever used more that one device, because they > probably would have noticed this. > > The name "/proc/net/bond0/info" is kind of unconventional, but now > changing that in a almost stable release would be bad. Better choice > would be "/proc/net/bonding/bond0". > > --- linux-2.5/drivers/net/bonding/bond_main.c 2003-08-20 > 11:19:42.000000000 -0700 > +++ linux-2.5-net/drivers/net/bonding/bond_main.c > 2003-08-21 16:42:57.130509618 -0700 > @@ -402,6 +402,8 @@ > #include > #include > #include > +#include > +#include > #include > #include > > @@ -545,14 +547,6 @@ > static int bond_release_all(struct net_device *master); > static int bond_sethwaddr(struct net_device *master, struct > net_device *slave); > > -/* > - * bond_get_info is the interface into the /proc filesystem. This is > - * a different interface than the BOND_INFO_QUERY ioctl. > That is done > - * through the generic networking ioctl interface, and > bond_info_query > - * is the internal function which provides that information. > - */ > -static int bond_get_info(char *buf, char **start, off_t > offset, int length); > - > /* Caller must hold bond->ptrlock for write */ > static inline struct slave* > bond_assign_current_slave(struct bonding *bond,struct slave > *newslave) > @@ -3327,133 +3321,195 @@ > return stats; > } > > -static int bond_get_info(char *buf, char **start, off_t > offset, int length) > -{ > - bonding_t *bond; > - int len = 0; > - off_t begin = 0; > - u16 link; > - slave_t *slave = NULL; > +#ifdef CONFIG_PROC_FS > > - len += sprintf(buf + len, "%s\n", version); > +#define BOND_PROC_HEADER ((void *)1) /* magic pointer for > header line */ > + > +static void *bond_info_seq_start(struct seq_file *seq, loff_t *pos) > +{ > + bonding_t *bond = seq->private; > + loff_t off = 0; > + slave_t *slave; > > read_lock(&dev_base_lock); > - list_for_each_entry(bond, &bond_dev_list, bond_list) { > - /* > - * This function locks the mutex, so we can't > lock it until > - * afterwards > - */ > - link = bond_check_mii_link(bond); > > - len += sprintf(buf + len, "Bonding Mode: %s\n", > - bond_mode_name()); > + if (*pos == 0) > + return BOND_PROC_HEADER; > > - if ((bond_mode == BOND_MODE_ACTIVEBACKUP) || > - (bond_mode == BOND_MODE_TLB) || > - (bond_mode == BOND_MODE_ALB)) { > - read_lock_bh(&bond->lock); > - read_lock(&bond->ptrlock); > - if (bond->current_slave != NULL) { > - len += sprintf(buf + len, > - "Currently Active Slave: %s\n", > - bond->current_slave->dev->name); > - } > - read_unlock(&bond->ptrlock); > - read_unlock_bh(&bond->lock); > - } > - > - len += sprintf(buf + len, "MII Status: "); > - len += sprintf(buf + len, > - link == BMSR_LSTATUS ? "up\n" : > "down\n"); > - len += sprintf(buf + len, "MII Polling Interval > (ms): %d\n", > - miimon); > - len += sprintf(buf + len, "Up Delay (ms): %d\n", > - updelay * miimon); > - len += sprintf(buf + len, "Down Delay (ms): %d\n", > - downdelay * miimon); > - len += sprintf(buf + len, "Multicast Mode: %s\n", > - multicast_mode_name()); > + read_lock_bh(&bond->lock); > + for (slave = bond->prev; slave != (slave_t *)bond; > slave = slave->prev) { > + if (++off == *pos) > + return slave; > + } > + > + return NULL; > +} > + > +static void *bond_info_seq_next(struct seq_file *seq, void > *v, loff_t *pos) > +{ > + bonding_t *bond = seq->private; > + slave_t *slave = v; > > + ++*pos; > + if (v == BOND_PROC_HEADER) { > read_lock_bh(&bond->lock); > + slave = bond->prev; > + } else { > + slave = slave->prev; > + } > + return (slave == (slave_t *) bond) ? NULL : slave; > +} > > - if (bond_mode == BOND_MODE_8023AD) { > - struct ad_info ad_info; > +static void bond_info_seq_stop(struct seq_file *seq, void *v) > +{ > + bonding_t *bond = seq->private; > + > + if (v != BOND_PROC_HEADER) > + read_unlock_bh(&bond->lock); > + read_unlock(&dev_base_lock); > +} > > - len += sprintf(buf + len, "\n802.3ad info\n"); > +static void bond_info_show_master(struct seq_file *seq, > bonding_t *bond) > +{ > + u16 link = bond_check_mii_link(bond); > > - if (bond_3ad_get_active_agg_info(bond, > &ad_info)) { > - len += sprintf(buf + len, "bond > %s has no active aggregator\n", bond->device->name); > - } else { > - len += sprintf(buf + len, > "Active Aggregator Info:\n"); > + seq_printf(seq, "Bonding Mode: %s\n", > + bond_mode_name()); > > - len += sprintf(buf + len, > "\tAggregator ID: %d\n", ad_info.aggregator_id); > - len += sprintf(buf + len, > "\tNumber of ports: %d\n", ad_info.ports); > - len += sprintf(buf + len, > "\tActor Key: %d\n", ad_info.actor_key); > - len += sprintf(buf + len, > "\tPartner Key: %d\n", ad_info.partner_key); > - len += sprintf(buf + len, > "\tPartner Mac Address: %02x:%02x:%02x:%02x:%02x:%02x\n", > - ad_info.partner_system[0], > - ad_info.partner_system[1], > - ad_info.partner_system[2], > - ad_info.partner_system[3], > - ad_info.partner_system[4], > - ad_info.partner_system[5]); > - } > + if ((bond_mode == BOND_MODE_ACTIVEBACKUP) || > + (bond_mode == BOND_MODE_TLB) || > + (bond_mode == BOND_MODE_ALB)) { > + read_lock_bh(&bond->lock); > + read_lock(&bond->ptrlock); > + if (bond->current_slave != NULL) { > + seq_printf(seq, > + "Currently Active Slave: %s\n", > + bond->current_slave->dev->name); > } > + read_unlock(&bond->ptrlock); > + read_unlock_bh(&bond->lock); > + } > > - for (slave = bond->prev; slave != (slave_t *)bond; > - slave = slave->prev) { > - len += sprintf(buf + len, "\nSlave > Interface: %s\n", slave->dev->name); > - > - len += sprintf(buf + len, "MII Status: "); > - > - len += sprintf(buf + len, > - slave->link == BOND_LINK_UP ? > - "up\n" : "down\n"); > - len += sprintf(buf + len, "Link Failure > Count: %d\n", > - slave->link_failure_count); > - > - if (app_abi_ver >= 1) { > - len += sprintf(buf + len, > - "Permanent HW > addr: %02x:%02x:%02x:%02x:%02x:%02x\n", > - slave->perm_hwaddr[0], > - slave->perm_hwaddr[1], > - slave->perm_hwaddr[2], > - slave->perm_hwaddr[3], > - slave->perm_hwaddr[4], > - slave->perm_hwaddr[5]); > - } > + seq_printf(seq, "MII Status: "); > + seq_printf(seq, > + link == BMSR_LSTATUS ? "up\n" : "down\n"); > + seq_printf(seq, "MII Polling Interval (ms): %d\n", > + miimon); > + seq_printf(seq, "Up Delay (ms): %d\n", > + updelay * miimon); > + seq_printf(seq, "Down Delay (ms): %d\n", > + downdelay * miimon); > + seq_printf(seq, "Multicast Mode: %s\n", > + multicast_mode_name()); > > - if (bond_mode == BOND_MODE_8023AD) { > - struct aggregator *agg = > SLAVE_AD_INFO(slave).port.aggregator; > > - if (agg) { > - len += sprintf(buf + > len, "Aggregator ID: %d\n", > - > agg->aggregator_identifier); > - } else { > - len += sprintf(buf + > len, "Aggregator ID: N/A\n"); > - } > - } > - } > - read_unlock_bh(&bond->lock); > + if (bond_mode == BOND_MODE_8023AD) { > + struct ad_info ad_info; > > - /* > - * Figure out the calcs for the /proc/net interface > - */ > - *start = buf + (offset - begin); > - len -= (offset - begin); > - if (len > length) { > - len = length; > - } > - if (len < 0) { > - len = 0; > + seq_printf(seq, "\n802.3ad info\n"); > + > + if (bond_3ad_get_active_agg_info(bond, &ad_info)) { > + seq_printf(seq, "bond %s has no active > aggregator\n", bond->device->name); > + } else { > + seq_printf(seq, "Active Aggregator Info:\n"); > + > + seq_printf(seq, "\tAggregator ID: > %d\n", ad_info.aggregator_id); > + seq_printf(seq, "\tNumber of ports: > %d\n", ad_info.ports); > + seq_printf(seq, "\tActor Key: %d\n", > ad_info.actor_key); > + seq_printf(seq, "\tPartner Key: %d\n", > ad_info.partner_key); > + seq_printf(seq, "\tPartner Mac Address: > %02x:%02x:%02x:%02x:%02x:%02x\n", > + ad_info.partner_system[0], > + ad_info.partner_system[1], > + ad_info.partner_system[2], > + ad_info.partner_system[3], > + ad_info.partner_system[4], > + ad_info.partner_system[5]); > } > + } > + > +} > + > +static void bond_info_show_slave(struct seq_file *seq, const > slave_t *slave) > +{ > + > + seq_printf(seq, "\nSlave Interface: %s\n", slave->dev->name); > > + seq_printf(seq, "MII Status: "); > + > + seq_printf(seq, > + slave->link == BOND_LINK_UP ? > + "up\n" : "down\n"); > + seq_printf(seq, "Link Failure Count: %d\n", > + slave->link_failure_count); > + > + if (app_abi_ver >= 1) { > + seq_printf(seq, > + "Permanent HW addr: > %02x:%02x:%02x:%02x:%02x:%02x\n", > + slave->perm_hwaddr[0], > + slave->perm_hwaddr[1], > + slave->perm_hwaddr[2], > + slave->perm_hwaddr[3], > + slave->perm_hwaddr[4], > + slave->perm_hwaddr[5]); > } > - read_unlock(&dev_base_lock); > > - return len; > + if (bond_mode == BOND_MODE_8023AD) { > + const struct aggregator *agg > + = SLAVE_AD_INFO(slave).port.aggregator; > + > + if (agg) > + seq_printf(seq, "Aggregator ID: %d\n", > + agg->aggregator_identifier); > + else > + seq_printf(seq, "Aggregator ID: N/A\n"); > + } > +} > + > +static int bond_info_seq_show(struct seq_file *seq, void *v) > +{ > + if (v == BOND_PROC_HEADER) { > + seq_printf(seq, "%s\n", version); > + bond_info_show_master(seq, seq->private); > + } else > + bond_info_show_slave(seq, v); > + return 0; > } > > + > +static struct seq_operations bond_info_seq_ops = { > + .start = bond_info_seq_start, > + .next = bond_info_seq_next, > + .stop = bond_info_seq_stop, > + .show = bond_info_seq_show, > +}; > + > +static int bond_info_open(struct inode *inode, struct file *file) > +{ > + struct seq_file *seq; > + struct proc_dir_entry *proc; > + int rc; > + > + rc = seq_open(file, &bond_info_seq_ops); > + if (!rc) { > + /* recover the pointer buried in proc_dir_entry data */ > + seq = file->private_data; > + proc = PDE(inode); > + seq->private = proc->data; > + } > + return rc; > +} > + > +static struct file_operations bond_info_fops = { > + .owner = THIS_MODULE, > + .open = bond_info_open, > + .read = seq_read, > + .llseek = seq_lseek, > + .release = seq_release, > +}; > + > + > +#endif > + > static int bond_event(struct notifier_block *this, unsigned > long event, > void *ptr) > { > @@ -3560,15 +3616,15 @@ > bond->bond_proc_dir->owner = THIS_MODULE; > > bond->bond_proc_info_file = > - create_proc_info_entry("info", 0, bond->bond_proc_dir, > - bond_get_info); > + create_proc_entry("info", 0, bond->bond_proc_dir); > if (bond->bond_proc_info_file == NULL) { > printk(KERN_ERR "%s: Cannot init /proc/net/%s/info\n", > dev->name, dev->name); > remove_proc_entry(dev->name, proc_net); > return -ENOMEM; > } > - bond->bond_proc_info_file->owner = THIS_MODULE; > + bond->bond_proc_info_file->data = bond; > + bond->bond_proc_info_file->proc_fops = &bond_info_fops; > #endif /* CONFIG_PROC_FS */ > > > > From romieu@fr.zoreil.com Sat Aug 23 07:08:57 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 23 Aug 2003 07:09:32 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7NE8FoO001211 for ; Sat, 23 Aug 2003 07:08:56 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id h7NDgcxA011482; Sat, 23 Aug 2003 15:42:38 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id h7NDgVxw011481; Sat, 23 Aug 2003 15:42:32 +0200 Date: Sat, 23 Aug 2003 15:42:31 +0200 From: Francois Romieu To: Jeff Garzik Cc: torvalds@osdl.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [bk patches] net driver updates Message-ID: <20030823154231.A11381@electric-eye.fr.zoreil.com> References: <20030817183137.GA18521@gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030817183137.GA18521@gtf.org>; from jgarzik@pobox.com on Sun, Aug 17, 2003 at 02:31:37PM -0400 X-Organisation: Hungry patch-scripts (c) users X-archive-position: 5224 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 753 Lines: 25 Jeff Garzik : [net-drivers-2.6 update] > drivers/net/sis190.c | 2094 +++++++++++++++++++++++++++++--------- synchronize_irq() requires an argument when built with CONFIG_SMP. drivers/net/sis190.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/net/sis190.c~synchronize_irq-missing-arg-sis190 drivers/net/sis190.c --- linux-2.6.0-test4/drivers/net/sis190.c~synchronize_irq-missing-arg-sis190 Sat Aug 23 15:37:35 2003 +++ linux-2.6.0-test4-fr/drivers/net/sis190.c Sat Aug 23 15:37:35 2003 @@ -1111,7 +1111,7 @@ SiS190_close(struct net_device *dev) spin_unlock_irq(&tp->lock); - synchronize_irq(); + synchronize_irq(dev->irq); free_irq(dev->irq, dev); SiS190_tx_clear(tp); _ From shmulik.hen@intel.com Sat Aug 23 07:25:55 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 23 Aug 2003 07:26:33 -0700 (PDT) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7NEPCoO002053 for ; Sat, 23 Aug 2003 07:25:53 -0700 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.76 2003/08/21 22:58:26 rfjohns1 Exp $) with ESMTP id h7NEJjj25868 for ; Sat, 23 Aug 2003 14:19:45 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h7NESCg18757 for ; Sat, 23 Aug 2003 14:28:12 GMT Received: from hasmsx331.ger.corp.intel.com ([143.185.63.144]) by hasmsxvs01.iil.intel.com (NAVGW 2.5.2.11) with SMTP id M2003082317250505203 ; Sat, 23 Aug 2003 17:25:05 +0300 Received: from hasmsx403.ger.corp.intel.com ([143.185.63.109]) by hasmsx331.ger.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 23 Aug 2003 17:25:05 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [PATCH] convering bonding driver /proc interface to seq_file Date: Sat, 23 Aug 2003 17:25:04 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] convering bonding driver /proc interface to seq_file Thread-Index: AcNoSkcEN+t2IRI/TqCyY6qO/WMKPgBLszsQAAGWkvA= From: "Hen, Shmulik" To: "Hen, Shmulik" , "Stephen Hemminger" , "Chad Tindel" , "Jay Vosburgh" , "David S. Miller" , "Jeff Garzik" Cc: , X-OriginalArrivalTime: 23 Aug 2003 14:25:05.0347 (UTC) FILETIME=[58D42930:01C36982] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7NEPCoO002053 X-archive-position: 5225 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Content-Length: 15023 Lines: 480 There is one more reason for my plea that I didn't mention: Currently the bonding version in 2.6 is way behind what's in 2.4. We are hoping that once the stuff in 2.4 is synched, we could just copy everything from 2.4 to 2.6 as is, and once that's done, continue regular development on 2.6 and back port into 2.4 from time to time. Also, instead of using a seq_file interface and using a pointer to skip to the relevant part, we've used a different proc creation interface that allows passing a pointer to bond and thus retrieve just the relevant bond device's data. Shmulik. > -----Original Message----- > From: Hen, Shmulik > Sent: Saturday, August 23, 2003 4:35 PM > To: 'Stephen Hemminger'; Chad Tindel; Jay Vosburgh; David S. Miller; > Jeff Garzik > Cc: bonding-devel@lists.sourceforge.net; netdev@oss.sgi.com > Subject: RE: [PATCH] convering bonding driver /proc interface to > seq_file > > > Guys, > > We have already submitted a patch that does the exact same > thing (give back info only for the queried bond) that is > sitting in Jeff's net-drivers queue. It is a part of a whole > set of patches meant to get the 2.4 and 2.6 versions > synched (referred to as back porting patch set, or set #1). > > The patch set is being held until Marcelo goes to 2.4.23-pre1. > Jeff also said something about reservation he might have about > that set, so we're still waiting. > > Could everyone please hold off the bonding modifications for > only a short while until we get this sorted out? We have a > bunch of other patch sets in queue that add lots of new stuff > and they all depend on that first set being accepted. > > If I'm asking for too much, let me know, but do it gently :) > > -- > | Shmulik Hen Advanced Network Services | > | Israel Design Center, Jerusalem | > | LAN Access Division, Platform Networking | > | Intel Communications Group, Intel corp. | > > > > > -----Original Message----- > > From: Stephen Hemminger [mailto:shemminger@osdl.org] > > Sent: Friday, August 22, 2003 2:53 AM > > To: Chad Tindel; Jay Vosburgh; David S. Miller; Jeff Garzik > > Cc: bonding-devel@lists.sourceforge.net; netdev@oss.sgi.com > > Subject: [PATCH] convering bonding driver /proc interface > to seq_file > > > > > > This patch converts /proc/net/bondXX/info to the seq_file interface; > > patch is against 2.6.0-test3; but seq_file has been > > backported to latest > > 2.4 as well. > > > > It also fixes a bug with multiple bond devices. The original code > > mushes all the bond device status information together. In > > other words, > > /proc/net/bond0/info gives the same output as /proc/net/bond1/info. > > > > I fixed this in this version, by stuffing a link back to the bonding > > data structure in the created proc_dir_entry; which is then used > > to only pickup the slaves for that pseudo-device. > > > > Don't think anyone ever used more that one device, because they > > probably would have noticed this. > > > > The name "/proc/net/bond0/info" is kind of unconventional, but now > > changing that in a almost stable release would be bad. > Better choice > > would be "/proc/net/bonding/bond0". > > > > --- linux-2.5/drivers/net/bonding/bond_main.c 2003-08-20 > > 11:19:42.000000000 -0700 > > +++ linux-2.5-net/drivers/net/bonding/bond_main.c > > 2003-08-21 16:42:57.130509618 -0700 > > @@ -402,6 +402,8 @@ > > #include > > #include > > #include > > +#include > > +#include > > #include > > #include > > > > @@ -545,14 +547,6 @@ > > static int bond_release_all(struct net_device *master); > > static int bond_sethwaddr(struct net_device *master, struct > > net_device *slave); > > > > -/* > > - * bond_get_info is the interface into the /proc > filesystem. This is > > - * a different interface than the BOND_INFO_QUERY ioctl. > > That is done > > - * through the generic networking ioctl interface, and > > bond_info_query > > - * is the internal function which provides that information. > > - */ > > -static int bond_get_info(char *buf, char **start, off_t > > offset, int length); > > - > > /* Caller must hold bond->ptrlock for write */ > > static inline struct slave* > > bond_assign_current_slave(struct bonding *bond,struct slave > > *newslave) > > @@ -3327,133 +3321,195 @@ > > return stats; > > } > > > > -static int bond_get_info(char *buf, char **start, off_t > > offset, int length) > > -{ > > - bonding_t *bond; > > - int len = 0; > > - off_t begin = 0; > > - u16 link; > > - slave_t *slave = NULL; > > +#ifdef CONFIG_PROC_FS > > > > - len += sprintf(buf + len, "%s\n", version); > > +#define BOND_PROC_HEADER ((void *)1) /* magic pointer for > > header line */ > > + > > +static void *bond_info_seq_start(struct seq_file *seq, loff_t *pos) > > +{ > > + bonding_t *bond = seq->private; > > + loff_t off = 0; > > + slave_t *slave; > > > > read_lock(&dev_base_lock); > > - list_for_each_entry(bond, &bond_dev_list, bond_list) { > > - /* > > - * This function locks the mutex, so we can't > > lock it until > > - * afterwards > > - */ > > - link = bond_check_mii_link(bond); > > > > - len += sprintf(buf + len, "Bonding Mode: %s\n", > > - bond_mode_name()); > > + if (*pos == 0) > > + return BOND_PROC_HEADER; > > > > - if ((bond_mode == BOND_MODE_ACTIVEBACKUP) || > > - (bond_mode == BOND_MODE_TLB) || > > - (bond_mode == BOND_MODE_ALB)) { > > - read_lock_bh(&bond->lock); > > - read_lock(&bond->ptrlock); > > - if (bond->current_slave != NULL) { > > - len += sprintf(buf + len, > > - "Currently Active Slave: %s\n", > > - bond->current_slave->dev->name); > > - } > > - read_unlock(&bond->ptrlock); > > - read_unlock_bh(&bond->lock); > > - } > > - > > - len += sprintf(buf + len, "MII Status: "); > > - len += sprintf(buf + len, > > - link == BMSR_LSTATUS ? "up\n" : > > "down\n"); > > - len += sprintf(buf + len, "MII Polling Interval > > (ms): %d\n", > > - miimon); > > - len += sprintf(buf + len, "Up Delay (ms): %d\n", > > - updelay * miimon); > > - len += sprintf(buf + len, "Down Delay (ms): %d\n", > > - downdelay * miimon); > > - len += sprintf(buf + len, "Multicast Mode: %s\n", > > - multicast_mode_name()); > > + read_lock_bh(&bond->lock); > > + for (slave = bond->prev; slave != (slave_t *)bond; > > slave = slave->prev) { > > + if (++off == *pos) > > + return slave; > > + } > > + > > + return NULL; > > +} > > + > > +static void *bond_info_seq_next(struct seq_file *seq, void > > *v, loff_t *pos) > > +{ > > + bonding_t *bond = seq->private; > > + slave_t *slave = v; > > > > + ++*pos; > > + if (v == BOND_PROC_HEADER) { > > read_lock_bh(&bond->lock); > > + slave = bond->prev; > > + } else { > > + slave = slave->prev; > > + } > > + return (slave == (slave_t *) bond) ? NULL : slave; > > +} > > > > - if (bond_mode == BOND_MODE_8023AD) { > > - struct ad_info ad_info; > > +static void bond_info_seq_stop(struct seq_file *seq, void *v) > > +{ > > + bonding_t *bond = seq->private; > > + > > + if (v != BOND_PROC_HEADER) > > + read_unlock_bh(&bond->lock); > > + read_unlock(&dev_base_lock); > > +} > > > > - len += sprintf(buf + len, "\n802.3ad info\n"); > > +static void bond_info_show_master(struct seq_file *seq, > > bonding_t *bond) > > +{ > > + u16 link = bond_check_mii_link(bond); > > > > - if (bond_3ad_get_active_agg_info(bond, > > &ad_info)) { > > - len += sprintf(buf + len, "bond > > %s has no active aggregator\n", bond->device->name); > > - } else { > > - len += sprintf(buf + len, > > "Active Aggregator Info:\n"); > > + seq_printf(seq, "Bonding Mode: %s\n", > > + bond_mode_name()); > > > > - len += sprintf(buf + len, > > "\tAggregator ID: %d\n", ad_info.aggregator_id); > > - len += sprintf(buf + len, > > "\tNumber of ports: %d\n", ad_info.ports); > > - len += sprintf(buf + len, > > "\tActor Key: %d\n", ad_info.actor_key); > > - len += sprintf(buf + len, > > "\tPartner Key: %d\n", ad_info.partner_key); > > - len += sprintf(buf + len, > > "\tPartner Mac Address: %02x:%02x:%02x:%02x:%02x:%02x\n", > > - > ad_info.partner_system[0], > > - > ad_info.partner_system[1], > > - > ad_info.partner_system[2], > > - > ad_info.partner_system[3], > > - > ad_info.partner_system[4], > > - > ad_info.partner_system[5]); > > - } > > + if ((bond_mode == BOND_MODE_ACTIVEBACKUP) || > > + (bond_mode == BOND_MODE_TLB) || > > + (bond_mode == BOND_MODE_ALB)) { > > + read_lock_bh(&bond->lock); > > + read_lock(&bond->ptrlock); > > + if (bond->current_slave != NULL) { > > + seq_printf(seq, > > + "Currently Active Slave: %s\n", > > + bond->current_slave->dev->name); > > } > > + read_unlock(&bond->ptrlock); > > + read_unlock_bh(&bond->lock); > > + } > > > > - for (slave = bond->prev; slave != (slave_t *)bond; > > - slave = slave->prev) { > > - len += sprintf(buf + len, "\nSlave > > Interface: %s\n", slave->dev->name); > > - > > - len += sprintf(buf + len, "MII Status: "); > > - > > - len += sprintf(buf + len, > > - slave->link == BOND_LINK_UP ? > > - "up\n" : "down\n"); > > - len += sprintf(buf + len, "Link Failure > > Count: %d\n", > > - slave->link_failure_count); > > - > > - if (app_abi_ver >= 1) { > > - len += sprintf(buf + len, > > - "Permanent HW > > addr: %02x:%02x:%02x:%02x:%02x:%02x\n", > > - slave->perm_hwaddr[0], > > - slave->perm_hwaddr[1], > > - slave->perm_hwaddr[2], > > - slave->perm_hwaddr[3], > > - slave->perm_hwaddr[4], > > - slave->perm_hwaddr[5]); > > - } > > + seq_printf(seq, "MII Status: "); > > + seq_printf(seq, > > + link == BMSR_LSTATUS ? "up\n" : "down\n"); > > + seq_printf(seq, "MII Polling Interval (ms): %d\n", > > + miimon); > > + seq_printf(seq, "Up Delay (ms): %d\n", > > + updelay * miimon); > > + seq_printf(seq, "Down Delay (ms): %d\n", > > + downdelay * miimon); > > + seq_printf(seq, "Multicast Mode: %s\n", > > + multicast_mode_name()); > > > > - if (bond_mode == BOND_MODE_8023AD) { > > - struct aggregator *agg = > > SLAVE_AD_INFO(slave).port.aggregator; > > > > - if (agg) { > > - len += sprintf(buf + > > len, "Aggregator ID: %d\n", > > - > > agg->aggregator_identifier); > > - } else { > > - len += sprintf(buf + > > len, "Aggregator ID: N/A\n"); > > - } > > - } > > - } > > - read_unlock_bh(&bond->lock); > > + if (bond_mode == BOND_MODE_8023AD) { > > + struct ad_info ad_info; > > > > - /* > > - * Figure out the calcs for the /proc/net interface > > - */ > > - *start = buf + (offset - begin); > > - len -= (offset - begin); > > - if (len > length) { > > - len = length; > > - } > > - if (len < 0) { > > - len = 0; > > + seq_printf(seq, "\n802.3ad info\n"); > > + > > + if (bond_3ad_get_active_agg_info(bond, &ad_info)) { > > + seq_printf(seq, "bond %s has no active > > aggregator\n", bond->device->name); > > + } else { > > + seq_printf(seq, "Active Aggregator Info:\n"); > > + > > + seq_printf(seq, "\tAggregator ID: > > %d\n", ad_info.aggregator_id); > > + seq_printf(seq, "\tNumber of ports: > > %d\n", ad_info.ports); > > + seq_printf(seq, "\tActor Key: %d\n", > > ad_info.actor_key); > > + seq_printf(seq, "\tPartner Key: %d\n", > > ad_info.partner_key); > > + seq_printf(seq, "\tPartner Mac Address: > > %02x:%02x:%02x:%02x:%02x:%02x\n", > > + ad_info.partner_system[0], > > + ad_info.partner_system[1], > > + ad_info.partner_system[2], > > + ad_info.partner_system[3], > > + ad_info.partner_system[4], > > + ad_info.partner_system[5]); > > } > > + } > > + > > +} > > + > > +static void bond_info_show_slave(struct seq_file *seq, const > > slave_t *slave) > > +{ > > + > > + seq_printf(seq, "\nSlave Interface: %s\n", slave->dev->name); > > > > + seq_printf(seq, "MII Status: "); > > + > > + seq_printf(seq, > > + slave->link == BOND_LINK_UP ? > > + "up\n" : "down\n"); > > + seq_printf(seq, "Link Failure Count: %d\n", > > + slave->link_failure_count); > > + > > + if (app_abi_ver >= 1) { > > + seq_printf(seq, > > + "Permanent HW addr: > > %02x:%02x:%02x:%02x:%02x:%02x\n", > > + slave->perm_hwaddr[0], > > + slave->perm_hwaddr[1], > > + slave->perm_hwaddr[2], > > + slave->perm_hwaddr[3], > > + slave->perm_hwaddr[4], > > + slave->perm_hwaddr[5]); > > } > > - read_unlock(&dev_base_lock); > > > > - return len; > > + if (bond_mode == BOND_MODE_8023AD) { > > + const struct aggregator *agg > > + = SLAVE_AD_INFO(slave).port.aggregator; > > + > > + if (agg) > > + seq_printf(seq, "Aggregator ID: %d\n", > > + agg->aggregator_identifier); > > + else > > + seq_printf(seq, "Aggregator ID: N/A\n"); > > + } > > +} > > + > > +static int bond_info_seq_show(struct seq_file *seq, void *v) > > +{ > > + if (v == BOND_PROC_HEADER) { > > + seq_printf(seq, "%s\n", version); > > + bond_info_show_master(seq, seq->private); > > + } else > > + bond_info_show_slave(seq, v); > > + return 0; > > } > > > > + > > +static struct seq_operations bond_info_seq_ops = { > > + .start = bond_info_seq_start, > > + .next = bond_info_seq_next, > > + .stop = bond_info_seq_stop, > > + .show = bond_info_seq_show, > > +}; > > + > > +static int bond_info_open(struct inode *inode, struct file *file) > > +{ > > + struct seq_file *seq; > > + struct proc_dir_entry *proc; > > + int rc; > > + > > + rc = seq_open(file, &bond_info_seq_ops); > > + if (!rc) { > > + /* recover the pointer buried in proc_dir_entry data */ > > + seq = file->private_data; > > + proc = PDE(inode); > > + seq->private = proc->data; > > + } > > + return rc; > > +} > > + > > +static struct file_operations bond_info_fops = { > > + .owner = THIS_MODULE, > > + .open = bond_info_open, > > + .read = seq_read, > > + .llseek = seq_lseek, > > + .release = seq_release, > > +}; > > + > > + > > +#endif > > + > > static int bond_event(struct notifier_block *this, unsigned > > long event, > > void *ptr) > > { > > @@ -3560,15 +3616,15 @@ > > bond->bond_proc_dir->owner = THIS_MODULE; > > > > bond->bond_proc_info_file = > > - create_proc_info_entry("info", 0, bond->bond_proc_dir, > > - bond_get_info); > > + create_proc_entry("info", 0, bond->bond_proc_dir); > > if (bond->bond_proc_info_file == NULL) { > > printk(KERN_ERR "%s: Cannot init /proc/net/%s/info\n", > > dev->name, dev->name); > > remove_proc_entry(dev->name, proc_net); > > return -ENOMEM; > > } > > - bond->bond_proc_info_file->owner = THIS_MODULE; > > + bond->bond_proc_info_file->data = bond; > > + bond->bond_proc_info_file->proc_fops = &bond_info_fops; > > #endif /* CONFIG_PROC_FS */ > > > > > > > > > From cloos@jhcloos.com Sat Aug 23 12:50:08 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 23 Aug 2003 12:50:40 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [64.240.156.239]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7NJnRoO012287 for ; Sat, 23 Aug 2003 12:50:08 -0700 Received: from lugabout.jhcloos.org (ppp18.m6k-1.buf-ch.ny.localnet.com [207.251.198.18]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "lugabout.jhcloos.org", Issuer "ca.jhcloos.com" (verified OK)) by ore.jhcloos.com (Postfix) with ESMTP id 1F5F11C59A for ; Sat, 23 Aug 2003 14:49:23 -0500 (CDT) Received: from lugabout.jhcloos.org (localhost [127.0.0.1]) by lugabout.jhcloos.org (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id 3E39F25C0C for ; Sat, 23 Aug 2003 19:49:16 +0000 (GMT) To: netdev@oss.sgi.com Subject: tcp socket missing from /proc/net/tcp From: "James H. Cloos Jr." Date: 23 Aug 2003 15:49:16 -0400 Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 5227 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cloos@jhcloos.com Precedence: bulk X-list: netdev Content-Length: 621 Lines: 20 I'm currently at 2.6 as of cset: tmolina@cablespeed.com|ChangeSet|20030809164017|32866 (the last one on 2003/Aug/09) I've currently got an open ssh session to a remote box that does not show up in /proc/net/tcp (I also checked /proc/net/tcp6 even though the remote box doesn't do v6; it is not there either). One possible issue is that I did an 'ifconfig sit1 down' and an 'ifconfig sit1 up' while the ssh session was up (for an unrelated reason). Hmmm. I just opened another ssh to that same box and now both show up again in /proc/net/tcp. v6 is copiled in, firewall stuff is a mix on in and modules. -JimC From davidsen@tmr.com Sat Aug 23 14:00:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 23 Aug 2003 14:01:48 -0700 (PDT) Received: from gatekeeper.tmr.com (tmr-02.dsl.thebiz.net [216.238.38.204]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7NL0DoO020339 for ; Sat, 23 Aug 2003 14:00:54 -0700 Received: from localhost (davidsen@localhost) by gatekeeper.tmr.com (8.9.0/8.9.0) with SMTP id QAA01050; Sat, 23 Aug 2003 16:50:39 -0400 Date: Sat, 23 Aug 2003 16:50:39 -0400 (EDT) From: Bill Davidsen To: "David S. Miller" cc: Ben Greear , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices In-Reply-To: <20030820104831.6235f3b9.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5228 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davidsen@tmr.com Precedence: bulk X-list: netdev Content-Length: 1820 Lines: 48 On Wed, 20 Aug 2003, David S. Miller wrote: > On Wed, 20 Aug 2003 10:44:41 -0700 > Ben Greear wrote: > > > It seems that these reasons would not preclude the addition of a flag > > that would default to the current behaviour but allow the behaviour that > > other setups desire easily? > > I would accept a patch that did something like > the following in arp_solicit(). > > if (skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL && > (in_dev->conf.shared_media || > inet_addr_onlink(dev, skb->nh.iph->saddr, 0))) > saddr = skb->nh.iph->saddr; > else > saddr = inet_select_addr(dev, target, RT_SCOPE_LINE); > > Then people can frob the shared_media sysctl for devices > where they want the behavior to be that we will only use > addresses assigned to the device as the solicitor address. > > The shared_media setting defaults to one and thus would preserve > current behavior by default. > > The idea is not mine, Alexey suggested it to me the other day. > > I hope this pleases people wrt. ARP request solicitor address > handling. I'm not sure if you changed your mind or someone finally made a proposal you like on the ARP issue, but is there an implementation your would find acceptable (other than source routing) to send packets out from the NIC with the SIP configured when there are multiple NICs and IPs in the same subnet? Using a random NIC for a given SIP confuses Cisco routers (and other things). Source routing becomes very complicated when there are a lot of IPs and they are changing, and there are several patches which force binding a SIP to a NIC, but you don't seem to like any of them. Please suggest a better way. -- bill davidsen CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. From skewer@terra.com.br Sat Aug 23 14:22:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 23 Aug 2003 14:22:46 -0700 (PDT) Received: from ivoti.terra.com.br (ivoti.terra.com.br [200.176.3.20]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7NLLWoO021649 for ; Sat, 23 Aug 2003 14:22:13 -0700 Received: from gunga.terra.com.br (gunga.terra.com.br [200.176.3.45]) by ivoti.terra.com.br (Postfix) with ESMTP id 4085D79C18B for ; Sat, 23 Aug 2003 18:21:31 -0300 (BRT) Received: from terra.com.br (200-203-020-235.paemt7002.dsl.brasiltelecom.net.br [200.203.20.235]) (authenticated user mmabreu) by gunga.terra.com.br (Postfix) with ESMTP id B13EB128078 for ; Sat, 23 Aug 2003 18:21:30 -0300 (BRT) Message-ID: <3F47DAEE.7050908@terra.com.br> Date: Sat, 23 Aug 2003 18:21:50 -0300 From: Marcelo Abreu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: pt-br, en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: [PATCH][TRIVIAL] dummy.c: remove dead comment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5229 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: skewer@terra.com.br Precedence: bulk X-list: netdev Content-Length: 438 Lines: 20 Hi, This applies to 2.4 and 2.6. The line this comment refers to does not exist anymore. --- linux-2.4.21/drivers/net/dummy.c 2001-09-30 16:26:06.000000000 -0300 +++ linux-2.4.21-/drivers/net/dummy.c 2003-08-23 17:42:02.000000000 -0300 @@ -28,8 +28,6 @@ Alan Cox, 30th May 1994 */ -/* To have statistics (just packets sent) define this */ - #include #include #include From jchapman@katalix.com Sat Aug 23 16:40:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 23 Aug 2003 16:40:49 -0700 (PDT) Received: from plesk.avahost.net ([216.40.206.200]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7NNdYoO026060 for ; Sat, 23 Aug 2003 16:40:15 -0700 Received: (qmail 16290 invoked by uid 10623); 24 Aug 2003 06:57:04 -0000 Received: from 212.56.89.216 ( [212.56.89.216]) as user jchapman@localhost by webmail.katalix.com with HTTP; Sun, 24 Aug 2003 07:57:04 +0100 Message-ID: <1061708224.3f4861c063706@webmail.katalix.com> Date: Sun, 24 Aug 2003 07:57:04 +0100 From: jc To: netdev@oss.sgi.com Subject: NAPI poll: why not consider transmit cleanup work before exiting poll mode? MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 212.56.89.216 X-archive-position: 5231 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jchapman@katalix.com Precedence: bulk X-list: netdev Content-Length: 2079 Lines: 75 Why don't NAPI drivers consider transmit completion work before doing netif_rx_complete() and re-enabling interrupts? NAPI drivers do netif_rx_complete() in their poll routines if no rx work is done but ignore whether they do any tx work. When the driver transmits bursty data (i.e. no rx events, only tx completion events) the driver's dev->poll always re-enables interrupts each time it is called, resulting in suboptimal performance. The latest e100 development driver (e100-3.0.0dev13) has been modified so that its dev->poll does netif_rx_complete() only if no receive _or_ transmit work is done. Thus, under bursty receive or transmit load, interrupts stay off even if the traffic is in only one direction. Here's a patch fragment showing the key code changes. Notice that the condition for doing netif_rx_complete() now includes a test of whether any transmit work was done. Is this breaking NAPI rules? If not, should other NAPI drivers do the same? -jc ---- @@ -1200,7 +1201,7 @@ return 0; } -static inline void e100_tx_clean(struct nic *nic) +static inline int e100_tx_clean(struct nic *nic) { struct cb *cb; int tx_cleaned = 0; @@ -1234,6 +1235,8 @@ /* Recover from running out of Tx resources in xmit_frame */ if(unlikely(tx_cleaned && netif_queue_stopped(nic->netdev))) netif_wake_queue(nic->netdev); + + return tx_cleaned; } @@ -1514,19 +1515,21 @@ struct nic *nic = netdev->priv; unsigned int work_to_do = min(netdev->quota, *budget); unsigned int work_done = 0; + int tx_cleaned; e100_rx_clean(nic, &work_done, work_to_do); - e100_tx_clean(nic); + tx_cleaned = e100_tx_clean(nic); - *budget -= work_done; - netdev->quota -= work_done; - - if(work_done == 0) { + /* If no Rx and Tx cleanup work was done, exit polling mode. */ + if(!tx_cleaned && (work_done == 0)) { netif_rx_complete(netdev); e100_enable_irq(nic); return 0; } + *budget -= work_done; + netdev->quota -= work_done; + return 1; } #endif ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ From davem@redhat.com Sat Aug 23 17:35:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 23 Aug 2003 17:36:04 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7O0YooO028035 for ; Sat, 23 Aug 2003 17:35:30 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id RAA05610; Sat, 23 Aug 2003 17:27:10 -0700 Date: Sat, 23 Aug 2003 17:27:10 -0700 From: "David S. Miller" To: "James H. Cloos Jr." Cc: netdev@oss.sgi.com Subject: Re: tcp socket missing from /proc/net/tcp Message-Id: <20030823172710.478f30f9.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5232 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 Content-Length: 395 Lines: 11 On 23 Aug 2003 15:49:16 -0400 "James H. Cloos Jr." wrote: > I've currently got an open ssh session to a remote box that does not > show up in /proc/net/tcp (I also checked /proc/net/tcp6 even though > the remote box doesn't do v6; it is not there either). Not surprising, nothing seems to be initializing net/ipv6/tcp_ipv6.c:tcp6_seq_fops I'd welcome patches to fix this. From yoshfuji@linux-ipv6.org Sat Aug 23 18:08:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 23 Aug 2003 18:08:52 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7O17aoO029145 for ; Sat, 23 Aug 2003 18:08:18 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h7O17r1M028836; Sun, 24 Aug 2003 10:07:54 +0900 Date: Sun, 24 Aug 2003 10:07:53 +0900 (JST) Message-Id: <20030824.100753.63798138.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: cloos@jhcloos.com, netdev@oss.sgi.com Subject: Re: tcp socket missing from /proc/net/tcp From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20030823172710.478f30f9.davem@redhat.com> References: <20030823172710.478f30f9.davem@redhat.com> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 5233 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 743 Lines: 18 In article <20030823172710.478f30f9.davem@redhat.com> (at Sat, 23 Aug 2003 17:27:10 -0700), "David S. Miller" says: > On 23 Aug 2003 15:49:16 -0400 > "James H. Cloos Jr." wrote: > > > I've currently got an open ssh session to a remote box that does not > > show up in /proc/net/tcp (I also checked /proc/net/tcp6 even though > > the remote box doesn't do v6; it is not there either). > > Not surprising, nothing seems to be initializing > net/ipv6/tcp_ipv6.c:tcp6_seq_fops net/ipv4/tcp_ipv4.c:tcp_proc_register() called by tcp6_proc_init() does this. Or, do I miss something? -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From davem@redhat.com Sat Aug 23 21:29:23 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 23 Aug 2003 21:29:55 -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 h7O4SgoO002092 for ; Sat, 23 Aug 2003 21:29:23 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id VAA06003; Sat, 23 Aug 2003 21:20:55 -0700 Date: Sat, 23 Aug 2003 21:20:55 -0700 From: "David S. Miller" To: "YOSHIFUJI Hideaki / _$B5HF#1QL@" Cc: cloos@jhcloos.com, netdev@oss.sgi.com Subject: Re: tcp socket missing from /proc/net/tcp Message-Id: <20030823212055.4d8e41ef.davem@redhat.com> In-Reply-To: <20030824.100753.63798138.yoshfuji@linux-ipv6.org> References: <20030823172710.478f30f9.davem@redhat.com> <20030824.100753.63798138.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5234 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 Content-Length: 244 Lines: 7 On Sun, 24 Aug 2003 10:07:53 +0900 (JST) YOSHIFUJI Hideaki / _$B5HF#1QL@ wrote: > net/ipv4/tcp_ipv4.c:tcp_proc_register() called by tcp6_proc_init() does this. > Or, do I miss something? You're right, I missed that. From davem@redhat.com Sat Aug 23 21:58:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 23 Aug 2003 21:58:51 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7O4vToO002869 for ; Sat, 23 Aug 2003 21:58:10 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id VAA06083; Sat, 23 Aug 2003 21:49:40 -0700 Date: Sat, 23 Aug 2003 21:49:39 -0700 From: "David S. Miller" To: linux-net@vger.kernel.org Cc: netdev@oss.sgi.com, jgarzik@pobox.com Subject: [PATCH] Tigon3 driver update Message-Id: <20030823214939.0c012f3d.davem@redhat.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5235 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 Content-Length: 129040 Lines: 3099 Included is a Tigon3 driver test patch against current 2.6.0-testX kernels. Features: 1) Full 5705/5782/5788/5901 support. 2) More reliable PHY resetting on 5703/5704/5705. 3) Updated TSO support, it is not enabled by default but one can turn it on using a current version of ethtool. Feedback welcome. Enjoy. # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1315 -> 1.1330 # drivers/net/tg3.h 1.25 -> 1.30 # net/core/ethtool.c 1.2 -> 1.3 # include/linux/ethtool.h 1.19 -> 1.20 # include/linux/pci_ids.h 1.116 -> 1.119 # drivers/pci/pci.ids 1.50 -> 1.51 # drivers/net/tg3.c 1.82 -> 1.96 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 03/08/22 davem@nuts.ninka.net 1.1316 # [TG3]: Initial implementation of 5705 support. # -------------------------------------------- # 03/08/22 jgarzik@redhat.com 1.1317 # [TG3]: Bug fixes for 5705 support. # # - (major) status block DMA address wasn't being set, for 5705. whoops. :) # - (minor) pass 5705-specific RX_STD_MAX_SIZE # - (minor) don't program RCVBDI_JUMBO_THRESH reg on 5705 # - (very minor) re-order *THRESH, HOSTCC* regs per bcm570x driver order # -------------------------------------------- # 03/08/22 jgarzik@redhat.com 1.1318 # [TG3]: More 5705 updates. # # - do not zero stats/status block on 5705, they don't exist # (in controller memory, at least) # - define TG3_MAX_MTU macro such that it takes a (tp) pointer arg, # because the value varies between 5705 and non-5705 # - use the macro to simply tg3_change_mtu # -------------------------------------------- # 03/08/22 jgarzik@redhat.com 1.1319 # [TG3]: More 5705 fixes. # # - call set-wire-speed phy function from tg3_phy_reset, not just _phy_probe # - disable set-wire-speed usage on certain chips, per bcm5700 driver # -------------------------------------------- # 03/08/22 jgarzik@redhat.com 1.1320 # [TG3]: Another 5705 fix: enable eeprom write prot as needed. # -------------------------------------------- # 03/08/22 jgarzik@redhat.com 1.1321 # [TG3]: Only write the on-nic sram addr on non-5705. # -------------------------------------------- # 03/08/22 jgarzik@redhat.com 1.1322 # [TG3]: Add 5782 pci id. # -------------------------------------------- # 03/08/22 davem@nuts.ninka.net 1.1323 # [TG3]: Fix statistics on 5705. # -------------------------------------------- # 03/08/22 davem@nuts.ninka.net 1.1324 # [TG3]: Do not reset the RX_MAC unless PHY is Serdes. # # Bug discovered by Michael Chan @ Broadcom. # -------------------------------------------- # 03/08/22 davem@nuts.ninka.net 1.1325 # [TG3]: More missing PCI IDs. # -------------------------------------------- # 03/08/23 davem@nuts.ninka.net 1.1326 # [TG3]: Reset PHY more reliably on 570{3,4,5} chips. # -------------------------------------------- # 03/08/23 davem@nuts.ninka.net 1.1327 # [TG3]: Fix 5788/5901, update TSO code. # - Do not set RDMAC_MODE_FIFO_LONG_BURST on 5788 # - Do not set WDMAC_MODE_RX_ACCEL on 5788 # - Note that 5788 cannot use tagged irq status. # - 5788 cannot do TSO # - 5788 cannot do NETIF_F_HIGHDMA. # - 5901 is 10/100 only. # - Update TSO firmware, add 5705 specific TSO firmware. # - Update TSO packet handling in ->hard_start_xmit() to # match updated TSO firmware. # - TSO is still off by default until more perf analysis is done. # -------------------------------------------- # 03/08/23 davem@nuts.ninka.net 1.1328 # [TG3]: Differentiate between TSO capable and TSO enabled. # -------------------------------------------- # 03/08/23 davem@nuts.ninka.net 1.1329 # [ETHTOOL]: Add {G,S}TSO support to ethtool_ops. # -------------------------------------------- # 03/08/23 davem@nuts.ninka.net 1.1330 # [TG3]: Add {get,set}_tso ethtool_ops support. # # Also, include TSO support code when NETIF_F_TSO is available # but do not enable TSO by default even on capable cards. User # can turn it on via ethtool. # -------------------------------------------- # diff -Nru a/drivers/net/tg3.c b/drivers/net/tg3.c --- a/drivers/net/tg3.c Sat Aug 23 21:49:57 2003 +++ b/drivers/net/tg3.c Sat Aug 23 21:49:57 2003 @@ -27,6 +27,8 @@ #include #include +#include + #include #include #include @@ -45,12 +47,9 @@ #endif #ifdef NETIF_F_TSO -/* XXX Works but still disabled, decreases TCP performance to 7MB/sec even - * XXX over gigabit. - */ -#define TG3_DO_TSO 0 +#define TG3_TSO_SUPPORT 1 #else -#define TG3_DO_TSO 0 +#define TG3_TSO_SUPPORT 0 #endif #include "tg3.h" @@ -80,7 +79,8 @@ /* hardware minimum and maximum for a single frame's data payload */ #define TG3_MIN_MTU 60 -#define TG3_MAX_MTU 9000 +#define TG3_MAX_MTU(tp) \ + (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705 ? 9000 : 1500) /* These numbers seem to be hard coded in the NIC firmware somehow. * You can't change the ring sizes, but you can change where you place @@ -90,7 +90,17 @@ #define TG3_DEF_RX_RING_PENDING 200 #define TG3_RX_JUMBO_RING_SIZE 256 #define TG3_DEF_RX_JUMBO_RING_PENDING 100 -#define TG3_RX_RCB_RING_SIZE 1024 + +/* Do not place this n-ring entries value into the tp struct itself, + * we really want to expose these constants to GCC so that modulo et + * al. operations are done with shifts and masks instead of with + * hw multiply/modulo instructions. Another solution would be to + * replace things like '% foo' with '& (foo - 1)'. + */ +#define TG3_RX_RCB_RING_SIZE(tp) \ + (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705 ? \ + 512 : 1024) + #define TG3_TX_RING_SIZE 512 #define TG3_DEF_TX_RING_PENDING (TG3_TX_RING_SIZE - 1) @@ -98,8 +108,8 @@ TG3_RX_RING_SIZE) #define TG3_RX_JUMBO_RING_BYTES (sizeof(struct tg3_rx_buffer_desc) * \ TG3_RX_JUMBO_RING_SIZE) -#define TG3_RX_RCB_RING_BYTES (sizeof(struct tg3_rx_buffer_desc) * \ - TG3_RX_RCB_RING_SIZE) +#define TG3_RX_RCB_RING_BYTES(tp) (sizeof(struct tg3_rx_buffer_desc) * \ + TG3_RX_RCB_RING_SIZE(tp)) #define TG3_TX_RING_BYTES (sizeof(struct tg3_tx_buffer_desc) * \ TG3_TX_RING_SIZE) #define TX_RING_GAP(TP) \ @@ -140,6 +150,14 @@ PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5702FE, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, + { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5705, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, + { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5705_2, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, + { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5705M, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, + { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5705M_2, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5702X, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5703X, @@ -150,6 +168,14 @@ PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5703A3, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, + { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5782, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, + { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5788, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, + { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5901, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, + { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5901_2, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, { PCI_VENDOR_ID_SYSKONNECT, 0x4400, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, { PCI_VENDOR_ID_ALTIMA, PCI_DEVICE_ID_ALTIMA_AC1000, @@ -288,17 +314,28 @@ static void tg3_switch_clocks(struct tg3 *tp) { - if (tr32(TG3PCI_CLOCK_CTRL) & CLOCK_CTRL_44MHZ_CORE) { + u32 clock_ctrl = tr32(TG3PCI_CLOCK_CTRL); + u32 orig_clock_ctrl; + + orig_clock_ctrl = clock_ctrl; + clock_ctrl &= (CLOCK_CTRL_FORCE_CLKRUN | + CLOCK_CTRL_CLKRUN_OENABLE | + 0x1f); + tp->pci_clock_ctrl = clock_ctrl; + + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705 && + (orig_clock_ctrl & CLOCK_CTRL_44MHZ_CORE) != 0) { tw32(TG3PCI_CLOCK_CTRL, + clock_ctrl | (CLOCK_CTRL_44MHZ_CORE | CLOCK_CTRL_ALTCLK)); tr32(TG3PCI_CLOCK_CTRL); udelay(40); tw32(TG3PCI_CLOCK_CTRL, - (CLOCK_CTRL_ALTCLK)); + clock_ctrl | (CLOCK_CTRL_ALTCLK)); tr32(TG3PCI_CLOCK_CTRL); udelay(40); } - tw32(TG3PCI_CLOCK_CTRL, 0); + tw32(TG3PCI_CLOCK_CTRL, clock_ctrl); tr32(TG3PCI_CLOCK_CTRL); udelay(40); } @@ -401,24 +438,22 @@ return ret; } -/* This will reset the tigon3 PHY if there is no valid - * link unless the FORCE argument is non-zero. - */ -static int tg3_phy_reset(struct tg3 *tp, int force) +static void tg3_phy_set_wirespeed(struct tg3 *tp) { - u32 phy_status, phy_control; - int err, limit; + u32 val; - err = tg3_readphy(tp, MII_BMSR, &phy_status); - err |= tg3_readphy(tp, MII_BMSR, &phy_status); - if (err != 0) - return -EBUSY; + if (tp->tg3_flags2 & TG3_FLG2_NO_ETH_WIRE_SPEED) + return; - /* If we have link, and not forcing a reset, then nothing - * to do. - */ - if ((phy_status & BMSR_LSTATUS) != 0 && (force == 0)) - return 0; + tg3_writephy(tp, MII_TG3_AUX_CTRL, 0x7007); + tg3_readphy(tp, MII_TG3_AUX_CTRL, &val); + tg3_writephy(tp, MII_TG3_AUX_CTRL, (val | (1 << 15) | (1 << 4))); +} + +static int tg3_bmcr_reset(struct tg3 *tp) +{ + u32 phy_control; + int limit, err; /* OK, reset it, and poll the BMCR_RESET bit until it * clears or we time out. @@ -436,12 +471,303 @@ if ((phy_control & BMCR_RESET) == 0) { udelay(40); - return 0; + break; } udelay(10); } + if (limit <= 0) + return -EBUSY; - return -EBUSY; + return 0; +} + +static int tg3_wait_macro_done(struct tg3 *tp) +{ + int limit = 100; + + while (limit--) { + u32 tmp32; + + tg3_readphy(tp, 0x16, &tmp32); + if ((tmp32 & 0x1000) == 0) + break; + } + if (limit <= 0) + return -EBUSY; + + return 0; +} + +static int tg3_phy_write_and_check_testpat(struct tg3 *tp, int *resetp) +{ + static const u32 test_pat[4][6] = { + { 0x00005555, 0x00000005, 0x00002aaa, 0x0000000a, 0x00003456, 0x00000003 }, + { 0x00002aaa, 0x0000000a, 0x00003333, 0x00000003, 0x0000789a, 0x00000005 }, + { 0x00005a5a, 0x00000005, 0x00002a6a, 0x0000000a, 0x00001bcd, 0x00000003 }, + { 0x00002a5a, 0x0000000a, 0x000033c3, 0x00000003, 0x00002ef1, 0x00000005 } + }; + int chan; + + for (chan = 0; chan < 4; chan++) { + int i; + + tg3_writephy(tp, MII_TG3_DSP_ADDRESS, + (chan * 0x2000) | 0x0200); + tg3_writephy(tp, 0x16, 0x0002); + + for (i = 0; i < 6; i++) + tg3_writephy(tp, MII_TG3_DSP_RW_PORT, + test_pat[chan][i]); + + tg3_writephy(tp, 0x16, 0x0202); + if (tg3_wait_macro_done(tp)) { + *resetp = 1; + return -EBUSY; + } + + tg3_writephy(tp, MII_TG3_DSP_ADDRESS, + (chan * 0x2000) | 0x0200); + tg3_writephy(tp, 0x16, 0x0082); + if (tg3_wait_macro_done(tp)) { + *resetp = 1; + return -EBUSY; + } + + tg3_writephy(tp, 0x16, 0x0802); + if (tg3_wait_macro_done(tp)) { + *resetp = 1; + return -EBUSY; + } + + for (i = 0; i < 6; i += 2) { + u32 low, high; + + tg3_readphy(tp, MII_TG3_DSP_RW_PORT, &low); + tg3_readphy(tp, MII_TG3_DSP_RW_PORT, &high); + if (tg3_wait_macro_done(tp)) { + *resetp = 1; + return -EBUSY; + } + low &= 0x7fff; + high &= 0x000f; + if (low != test_pat[chan][i] || + high != test_pat[chan][i+1]) { + tg3_writephy(tp, MII_TG3_DSP_ADDRESS, 0x000b); + tg3_writephy(tp, MII_TG3_DSP_RW_PORT, 0x4001); + tg3_writephy(tp, MII_TG3_DSP_RW_PORT, 0x4005); + + return -EBUSY; + } + } + } + + return 0; +} + +static int tg3_phy_reset_chanpat(struct tg3 *tp) +{ + int chan; + + for (chan = 0; chan < 4; chan++) { + int i; + + tg3_writephy(tp, MII_TG3_DSP_ADDRESS, + (chan * 0x2000) | 0x0200); + tg3_writephy(tp, 0x16, 0x0002); + for (i = 0; i < 6; i++) + tg3_writephy(tp, MII_TG3_DSP_RW_PORT, 0x000); + tg3_writephy(tp, 0x16, 0x0202); + if (tg3_wait_macro_done(tp)) + return -EBUSY; + } + + return 0; +} + +static int tg3_phy_reset_5703_4_5(struct tg3 *tp) +{ + u32 reg32, phy9_orig; + int retries, do_phy_reset, err; + + retries = 10; + do_phy_reset = 1; + do { + if (do_phy_reset) { + err = tg3_bmcr_reset(tp); + if (err) + return err; + do_phy_reset = 0; + } + + /* Disable transmitter and interrupt. */ + tg3_readphy(tp, MII_TG3_EXT_CTRL, ®32); + reg32 |= 0x3000; + tg3_writephy(tp, MII_TG3_EXT_CTRL, reg32); + + /* Set full-duplex, 1000 mbps. */ + tg3_writephy(tp, MII_BMCR, + BMCR_FULLDPLX | TG3_BMCR_SPEED1000); + + /* Set to master mode. */ + tg3_readphy(tp, MII_TG3_CTRL, &phy9_orig); + tg3_writephy(tp, MII_TG3_CTRL, + (MII_TG3_CTRL_AS_MASTER | + MII_TG3_CTRL_ENABLE_AS_MASTER)); + + /* Enable SM_DSP_CLOCK and 6dB. */ + tg3_writephy(tp, MII_TG3_AUX_CTRL, 0x0c00); + + /* Block the PHY control access. */ + tg3_writephy(tp, MII_TG3_DSP_ADDRESS, 0x8005); + tg3_writephy(tp, MII_TG3_DSP_RW_PORT, 0x0800); + + err = tg3_phy_write_and_check_testpat(tp, &do_phy_reset); + if (!err) + break; + } while (--retries); + + err = tg3_phy_reset_chanpat(tp); + if (err) + return err; + + tg3_writephy(tp, MII_TG3_DSP_ADDRESS, 0x8005); + tg3_writephy(tp, MII_TG3_DSP_RW_PORT, 0x0000); + + tg3_writephy(tp, MII_TG3_DSP_ADDRESS, 0x8200); + tg3_writephy(tp, 0x16, 0x0000); + + tg3_writephy(tp, MII_TG3_AUX_CTRL, 0x0400); + + tg3_writephy(tp, MII_TG3_CTRL, phy9_orig); + + tg3_readphy(tp, MII_TG3_EXT_CTRL, ®32); + reg32 &= ~0x3000; + tg3_writephy(tp, MII_TG3_EXT_CTRL, reg32); + + return err; +} + +/* This will reset the tigon3 PHY if there is no valid + * link unless the FORCE argument is non-zero. + */ +static int tg3_phy_reset(struct tg3 *tp, int force) +{ + u32 phy_status; + int err; + + err = tg3_readphy(tp, MII_BMSR, &phy_status); + err |= tg3_readphy(tp, MII_BMSR, &phy_status); + if (err != 0) + return -EBUSY; + + /* If we have link, and not forcing a reset, then nothing + * to do. + */ + if ((phy_status & BMSR_LSTATUS) != 0 && (force == 0)) + return 0; + + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5703 || + GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5704 || + GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705) { + err = tg3_phy_reset_5703_4_5(tp); + if (err) + return err; + goto out; + } + + err = tg3_bmcr_reset(tp); + if (err) + return err; + +out: + tg3_phy_set_wirespeed(tp); + return 0; +} + +static void tg3_frob_aux_power(struct tg3 *tp) +{ + struct tg3 *tp_peer = tp; + + if ((tp->tg3_flags & TG3_FLAG_EEPROM_WRITE_PROT) != 0) + return; + + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5704) { + tp_peer = pci_get_drvdata(tp->pdev_peer); + if (!tp_peer) + BUG(); + } + + + if ((tp->tg3_flags & TG3_FLAG_WOL_ENABLE) != 0 || + (tp_peer->tg3_flags & TG3_FLAG_WOL_ENABLE) != 0) { + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700 || + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701) { + tw32(GRC_LOCAL_CTRL, tp->grc_local_ctrl | + (GRC_LCLCTRL_GPIO_OE0 | + GRC_LCLCTRL_GPIO_OE1 | + GRC_LCLCTRL_GPIO_OE2 | + GRC_LCLCTRL_GPIO_OUTPUT0 | + GRC_LCLCTRL_GPIO_OUTPUT1)); + tr32(GRC_LOCAL_CTRL); + udelay(100); + } else { + if (tp_peer != tp && + (tp_peer->tg3_flags & TG3_FLAG_INIT_COMPLETE) != 0) + return; + + tw32(GRC_LOCAL_CTRL, tp->grc_local_ctrl | + (GRC_LCLCTRL_GPIO_OE0 | + GRC_LCLCTRL_GPIO_OE1 | + GRC_LCLCTRL_GPIO_OE2 | + GRC_LCLCTRL_GPIO_OUTPUT1 | + GRC_LCLCTRL_GPIO_OUTPUT2)); + tr32(GRC_LOCAL_CTRL); + udelay(100); + + tw32(GRC_LOCAL_CTRL, tp->grc_local_ctrl | + (GRC_LCLCTRL_GPIO_OE0 | + GRC_LCLCTRL_GPIO_OE1 | + GRC_LCLCTRL_GPIO_OE2 | + GRC_LCLCTRL_GPIO_OUTPUT0 | + GRC_LCLCTRL_GPIO_OUTPUT1 | + GRC_LCLCTRL_GPIO_OUTPUT2)); + tr32(GRC_LOCAL_CTRL); + udelay(100); + + tw32(GRC_LOCAL_CTRL, tp->grc_local_ctrl | + (GRC_LCLCTRL_GPIO_OE0 | + GRC_LCLCTRL_GPIO_OE1 | + GRC_LCLCTRL_GPIO_OE2 | + GRC_LCLCTRL_GPIO_OUTPUT0 | + GRC_LCLCTRL_GPIO_OUTPUT1)); + tr32(GRC_LOCAL_CTRL); + udelay(100); + } + } else { + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5700 && + GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5701) { + if (tp_peer != tp && + (tp_peer->tg3_flags & TG3_FLAG_INIT_COMPLETE) != 0) + return; + + tw32(GRC_LOCAL_CTRL, tp->grc_local_ctrl | + (GRC_LCLCTRL_GPIO_OE1 | + GRC_LCLCTRL_GPIO_OUTPUT1)); + tr32(GRC_LOCAL_CTRL); + udelay(100); + + tw32(GRC_LOCAL_CTRL, tp->grc_local_ctrl | + (GRC_LCLCTRL_GPIO_OE1)); + tr32(GRC_LOCAL_CTRL); + udelay(100); + + tw32(GRC_LOCAL_CTRL, tp->grc_local_ctrl | + (GRC_LCLCTRL_GPIO_OE1 | + GRC_LCLCTRL_GPIO_OUTPUT1)); + tr32(GRC_LOCAL_CTRL); + udelay(100); + } + } } static int tg3_setup_phy(struct tg3 *); @@ -547,89 +873,65 @@ udelay(10); } - if (tp->tg3_flags & TG3_FLAG_WOL_SPEED_100MB) { + if (!(tp->tg3_flags & TG3_FLAG_WOL_SPEED_100MB) && + (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700 || + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701)) { u32 base_val; - base_val = 0; - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700 || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701) - base_val |= (CLOCK_CTRL_RXCLK_DISABLE | - CLOCK_CTRL_TXCLK_DISABLE); - - tw32(TG3PCI_CLOCK_CTRL, base_val | - CLOCK_CTRL_ALTCLK); - tr32(TG3PCI_CLOCK_CTRL); - udelay(40); + base_val = tp->pci_clock_ctrl; + base_val |= (CLOCK_CTRL_RXCLK_DISABLE | + CLOCK_CTRL_TXCLK_DISABLE); tw32(TG3PCI_CLOCK_CTRL, base_val | CLOCK_CTRL_ALTCLK | - CLOCK_CTRL_44MHZ_CORE); - tr32(TG3PCI_CLOCK_CTRL); - udelay(40); - - tw32(TG3PCI_CLOCK_CTRL, base_val | - CLOCK_CTRL_44MHZ_CORE); + CLOCK_CTRL_PWRDOWN_PLL133); tr32(TG3PCI_CLOCK_CTRL); udelay(40); } else { - u32 base_val; + u32 newbits1, newbits2; - base_val = 0; if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700 || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701) - base_val |= (CLOCK_CTRL_RXCLK_DISABLE | - CLOCK_CTRL_TXCLK_DISABLE); + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701) { + newbits1 = (CLOCK_CTRL_RXCLK_DISABLE | + CLOCK_CTRL_TXCLK_DISABLE | + CLOCK_CTRL_ALTCLK); + newbits2 = newbits1 | CLOCK_CTRL_44MHZ_CORE; + } else if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) { + newbits1 = CLOCK_CTRL_625_CORE; + newbits2 = newbits1 | CLOCK_CTRL_ALTCLK; + } else { + newbits1 = CLOCK_CTRL_ALTCLK; + newbits2 = newbits1 | CLOCK_CTRL_44MHZ_CORE; + } - tw32(TG3PCI_CLOCK_CTRL, base_val | - CLOCK_CTRL_ALTCLK | - CLOCK_CTRL_PWRDOWN_PLL133); + tw32(TG3PCI_CLOCK_CTRL, tp->pci_clock_ctrl | newbits1); tr32(TG3PCI_CLOCK_CTRL); udelay(40); - } - if (!(tp->tg3_flags & TG3_FLAG_EEPROM_WRITE_PROT) && - (tp->tg3_flags & TG3_FLAG_WOL_ENABLE)) { - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700 || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701) { - tw32(GRC_LOCAL_CTRL, - (GRC_LCLCTRL_GPIO_OE0 | - GRC_LCLCTRL_GPIO_OE1 | - GRC_LCLCTRL_GPIO_OE2 | - GRC_LCLCTRL_GPIO_OUTPUT0 | - GRC_LCLCTRL_GPIO_OUTPUT1)); - tr32(GRC_LOCAL_CTRL); - udelay(100); - } else { - tw32(GRC_LOCAL_CTRL, - (GRC_LCLCTRL_GPIO_OE0 | - GRC_LCLCTRL_GPIO_OE1 | - GRC_LCLCTRL_GPIO_OE2 | - GRC_LCLCTRL_GPIO_OUTPUT1 | - GRC_LCLCTRL_GPIO_OUTPUT2)); - tr32(GRC_LOCAL_CTRL); - udelay(100); + tw32(TG3PCI_CLOCK_CTRL, tp->pci_clock_ctrl | newbits2); + tr32(TG3PCI_CLOCK_CTRL); + udelay(40); - tw32(GRC_LOCAL_CTRL, - (GRC_LCLCTRL_GPIO_OE0 | - GRC_LCLCTRL_GPIO_OE1 | - GRC_LCLCTRL_GPIO_OE2 | - GRC_LCLCTRL_GPIO_OUTPUT0 | - GRC_LCLCTRL_GPIO_OUTPUT1 | - GRC_LCLCTRL_GPIO_OUTPUT2)); - tr32(GRC_LOCAL_CTRL); - udelay(100); + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705) { + u32 newbits3; - tw32(GRC_LOCAL_CTRL, - (GRC_LCLCTRL_GPIO_OE0 | - GRC_LCLCTRL_GPIO_OE1 | - GRC_LCLCTRL_GPIO_OE2 | - GRC_LCLCTRL_GPIO_OUTPUT0 | - GRC_LCLCTRL_GPIO_OUTPUT1)); - tr32(GRC_LOCAL_CTRL); - udelay(100); + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700 || + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701) { + newbits3 = (CLOCK_CTRL_RXCLK_DISABLE | + CLOCK_CTRL_TXCLK_DISABLE | + CLOCK_CTRL_44MHZ_CORE); + } else { + newbits3 = CLOCK_CTRL_44MHZ_CORE; + } + + tw32(TG3PCI_CLOCK_CTRL, tp->pci_clock_ctrl | newbits3); + tr32(TG3PCI_CLOCK_CTRL); + udelay(40); } } + tg3_frob_aux_power(tp); + /* Finally, set the new power state. */ pci_write_config_word(tp->pdev, pm + PCI_PM_CTRL, power_control); @@ -948,11 +1250,10 @@ /* Some third-party PHYs need to be reset on link going * down. - * - * XXX 5705 note: This workaround also applies to 5705_a0 */ if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5703 || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5704) && + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5704 || + tp->pci_chip_rev_id == CHIPREV_ID_5705_A0) && netif_carrier_ok(tp->dev)) { tg3_readphy(tp, MII_BMSR, &bmsr); tg3_readphy(tp, MII_BMSR, &bmsr); @@ -1942,7 +2243,7 @@ int received; hw_idx = tp->hw_status->idx[0].rx_producer; - sw_idx = rx_rcb_ptr % TG3_RX_RCB_RING_SIZE; + sw_idx = rx_rcb_ptr % TG3_RX_RCB_RING_SIZE(tp); work_mask = 0; received = 0; while (sw_idx != hw_idx && budget > 0) { @@ -2043,13 +2344,13 @@ (*post_ptr)++; next_pkt_nopost: rx_rcb_ptr++; - sw_idx = rx_rcb_ptr % TG3_RX_RCB_RING_SIZE; + sw_idx = rx_rcb_ptr % TG3_RX_RCB_RING_SIZE(tp); } /* ACK the status ring. */ tp->rx_rcb_ptr = rx_rcb_ptr; tw32_mailbox(MAILBOX_RCVRET_CON_IDX_0 + TG3_64BIT_REG_LOW, - (rx_rcb_ptr % TG3_RX_RCB_RING_SIZE)); + (rx_rcb_ptr % TG3_RX_RCB_RING_SIZE(tp))); if (tp->tg3_flags & TG3_FLAG_MBOX_WRITE_REORDER) tr32(MAILBOX_RCVRET_CON_IDX_0 + TG3_64BIT_REG_LOW); @@ -2388,19 +2689,34 @@ base_flags = 0; if (skb->ip_summed == CHECKSUM_HW) base_flags |= TXD_FLAG_TCPUDP_CSUM; -#if TG3_DO_TSO != 0 - if ((mss = skb_shinfo(skb)->tso_size) != 0) { - static int times = 0; +#if TG3_TSO_SUPPORT != 0 + mss = 0; + if (skb->len > (tp->dev->mtu + ETH_HLEN) && + (mss = skb_shinfo(skb)->tso_size) != 0) { + int tcp_opt_len, ip_tcp_len; + + tcp_opt_len = ((skb->h.th->doff - 5) * 4); + ip_tcp_len = (skb->nh.iph->ihl * 4) + sizeof(struct tcphdr); - mss += ((skb->h.th->doff * 4) - 20); base_flags |= (TXD_FLAG_CPU_PRE_DMA | TXD_FLAG_CPU_POST_DMA); - if (times++ < 5) { - printk("tg3_xmit: tso_size[%u] tso_segs[%u] len[%u]\n", - (unsigned int) skb_shinfo(skb)->tso_size, - (unsigned int) skb_shinfo(skb)->tso_segs, - skb->len); + skb->nh.iph->check = 0; + skb->nh.iph->tot_len = ntohs(mss + ip_tcp_len + tcp_opt_len); + skb->h.th->check = ~csum_tcpudp_magic(skb->nh.iph->saddr, + skb->nh.iph->daddr, + 0, IPPROTO_TCP, 0); + + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) { + if (tcp_opt_len || skb->nh.iph->ihl > 5) { + int tsflags; + + tsflags = ((skb->nh.iph->ihl - 5) + + (tcp_opt_len >> 2)); + mss |= (tsflags << 11); + } + } else { + mss += tcp_opt_len; } } #else @@ -2580,23 +2896,34 @@ base_flags = 0; if (skb->ip_summed == CHECKSUM_HW) base_flags |= TXD_FLAG_TCPUDP_CSUM; -#if TG3_DO_TSO != 0 - if ((mss = skb_shinfo(skb)->tso_size) != 0) { - static int times = 0; +#if TG3_TSO_SUPPORT != 0 + mss = 0; + if (skb->len > (tp->dev->mtu + ETH_HLEN) && + (mss = skb_shinfo(skb)->tso_size) != 0) { + int tcp_opt_len, ip_tcp_len; - /* TSO firmware wants TCP options included in - * tx descriptor MSS value. - */ - mss += ((skb->h.th->doff * 4) - 20); + tcp_opt_len = ((skb->h.th->doff - 5) * 4); + ip_tcp_len = (skb->nh.iph->ihl * 4) + sizeof(struct tcphdr); base_flags |= (TXD_FLAG_CPU_PRE_DMA | TXD_FLAG_CPU_POST_DMA); - if (times++ < 5) { - printk("tg3_xmit: tso_size[%u] tso_segs[%u] len[%u]\n", - (unsigned int) skb_shinfo(skb)->tso_size, - (unsigned int) skb_shinfo(skb)->tso_segs, - skb->len); + skb->nh.iph->check = 0; + skb->nh.iph->tot_len = ntohs(mss + ip_tcp_len + tcp_opt_len); + skb->h.th->check = ~csum_tcpudp_magic(skb->nh.iph->saddr, + skb->nh.iph->daddr, + 0, IPPROTO_TCP, 0); + + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) { + if (tcp_opt_len || skb->nh.iph->ihl > 5) { + int tsflags; + + tsflags = ((skb->nh.iph->ihl - 5) + + (tcp_opt_len >> 2)); + mss |= (tsflags << 11); + } + } else { + mss += tcp_opt_len; } } #else @@ -2698,7 +3025,7 @@ { struct tg3 *tp = dev->priv; - if (new_mtu < TG3_MIN_MTU || new_mtu > TG3_MAX_MTU) + if (new_mtu < TG3_MIN_MTU || new_mtu > TG3_MAX_MTU(tp)) return -EINVAL; if (!netif_running(dev)) { @@ -2816,7 +3143,7 @@ /* Zero out all descriptors. */ memset(tp->rx_std, 0, TG3_RX_RING_BYTES); memset(tp->rx_jumbo, 0, TG3_RX_JUMBO_RING_BYTES); - memset(tp->rx_rcb, 0, TG3_RX_RCB_RING_BYTES); + memset(tp->rx_rcb, 0, TG3_RX_RCB_RING_BYTES(tp)); if (tp->tg3_flags & TG3_FLAG_HOST_TXDS) { memset(tp->tx_ring, 0, TG3_TX_RING_BYTES); @@ -2899,7 +3226,7 @@ tp->rx_jumbo = NULL; } if (tp->rx_rcb) { - pci_free_consistent(tp->pdev, TG3_RX_RCB_RING_BYTES, + pci_free_consistent(tp->pdev, TG3_RX_RCB_RING_BYTES(tp), tp->rx_rcb, tp->rx_rcb_mapping); tp->rx_rcb = NULL; } @@ -2957,7 +3284,7 @@ if (!tp->rx_jumbo) goto err_out; - tp->rx_rcb = pci_alloc_consistent(tp->pdev, TG3_RX_RCB_RING_BYTES, + tp->rx_rcb = pci_alloc_consistent(tp->pdev, TG3_RX_RCB_RING_BYTES(tp), &tp->rx_rcb_mapping); if (!tp->rx_rcb) goto err_out; @@ -3004,6 +3331,23 @@ unsigned int i; u32 val; + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) { + switch (ofs) { + case RCVLSC_MODE: + case DMAC_MODE: + case MBFREE_MODE: + case BUFMGR_MODE: + case MEMARB_MODE: + /* We can't enable/disable these bits of the + * 5705, just say success. + */ + return 0; + + default: + break; + }; + } + val = tr32(ofs); val &= ~enable_bit; tw32(ofs, val); @@ -3127,7 +3471,10 @@ tp->tg3_flags &= ~TG3_FLAG_5701_REG_WRITE_BUG; /* do the reset */ - tw32(GRC_MISC_CFG, GRC_MISC_CFG_CORECLK_RESET); + val = GRC_MISC_CFG_CORECLK_RESET; + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) + val |= GRC_MISC_CFG_KEEP_GPHY_POWER; + tw32(GRC_MISC_CFG, val); /* restore 5701 hardware bug workaround flag */ tp->tg3_flags = flags_save; @@ -3163,6 +3510,13 @@ tw32(MEMARB_MODE, MEMARB_MODE_ENABLE); + if ((tp->nic_sram_data_cfg & NIC_SRAM_DATA_CFG_MINI_PCI) != 0 && + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) { + tp->pci_clock_ctrl |= + (CLOCK_CTRL_FORCE_CLKRUN | CLOCK_CTRL_CLKRUN_OENABLE); + tw32(TG3PCI_CLOCK_CTRL, tp->pci_clock_ctrl); + } + tw32(TG3PCI_MISC_HOST_CTRL, tp->misc_host_ctrl); } @@ -3358,28 +3712,32 @@ #define TX_CPU_SCRATCH_SIZE 0x04000 /* tp->lock is held. */ -static int tg3_reset_cpu(struct tg3 *tp, u32 offset) +static int tg3_halt_cpu(struct tg3 *tp, u32 offset) { int i; - tw32(offset + CPU_STATE, 0xffffffff); - tw32(offset + CPU_MODE, CPU_MODE_RESET); + if (offset == TX_CPU_BASE && + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) + BUG(); + if (offset == RX_CPU_BASE) { - for (i = 0; i < 10000; i++) - if (!(tr32(offset + CPU_MODE) & CPU_MODE_RESET)) + for (i = 0; i < 10000; i++) { + tw32(offset + CPU_STATE, 0xffffffff); + tw32(offset + CPU_MODE, CPU_MODE_HALT); + if (tr32(offset + CPU_MODE) & CPU_MODE_HALT) break; + } + tw32(offset + CPU_STATE, 0xffffffff); - tw32(offset + CPU_MODE, CPU_MODE_RESET); + tw32(offset + CPU_MODE, CPU_MODE_HALT); tr32(offset + CPU_MODE); udelay(10); } else { for (i = 0; i < 10000; i++) { - if (!(tr32(offset + CPU_MODE) & CPU_MODE_RESET)) - break; tw32(offset + CPU_STATE, 0xffffffff); - tw32(offset + CPU_MODE, CPU_MODE_RESET); - tr32(offset + CPU_MODE); - udelay(10); + tw32(offset + CPU_MODE, CPU_MODE_HALT); + if (tr32(offset + CPU_MODE) & CPU_MODE_HALT) + break; } } @@ -3411,38 +3769,52 @@ { int err, i; u32 orig_tg3_flags = tp->tg3_flags; + void (*write_op)(struct tg3 *, u32, u32); + + if (cpu_base == TX_CPU_BASE && + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) { + printk(KERN_ERR PFX "tg3_load_firmware_cpu: Trying to load " + "TX cpu firmware on %s which is 5705.\n", + tp->dev->name); + return -EINVAL; + } + + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) + write_op = tg3_write_mem; + else + write_op = tg3_write_indirect_reg32; /* Force use of PCI config space for indirect register * write calls. */ tp->tg3_flags |= TG3_FLAG_PCIX_TARGET_HWBUG; - err = tg3_reset_cpu(tp, cpu_base); + err = tg3_halt_cpu(tp, cpu_base); if (err) goto out; for (i = 0; i < cpu_scratch_size; i += sizeof(u32)) - tg3_write_indirect_reg32(tp, cpu_scratch_base + i, 0); + write_op(tp, cpu_scratch_base + i, 0); tw32(cpu_base + CPU_STATE, 0xffffffff); tw32(cpu_base + CPU_MODE, tr32(cpu_base+CPU_MODE)|CPU_MODE_HALT); for (i = 0; i < (info->text_len / sizeof(u32)); i++) - tg3_write_indirect_reg32(tp, (cpu_scratch_base + - (info->text_base & 0xffff) + - (i * sizeof(u32))), - (info->text_data ? - info->text_data[i] : 0)); + write_op(tp, (cpu_scratch_base + + (info->text_base & 0xffff) + + (i * sizeof(u32))), + (info->text_data ? + info->text_data[i] : 0)); for (i = 0; i < (info->rodata_len / sizeof(u32)); i++) - tg3_write_indirect_reg32(tp, (cpu_scratch_base + - (info->rodata_base & 0xffff) + - (i * sizeof(u32))), - (info->rodata_data ? - info->rodata_data[i] : 0)); + write_op(tp, (cpu_scratch_base + + (info->rodata_base & 0xffff) + + (i * sizeof(u32))), + (info->rodata_data ? + info->rodata_data[i] : 0)); for (i = 0; i < (info->data_len / sizeof(u32)); i++) - tg3_write_indirect_reg32(tp, (cpu_scratch_base + - (info->data_base & 0xffff) + - (i * sizeof(u32))), - (info->data_data ? - info->data_data[i] : 0)); + write_op(tp, (cpu_scratch_base + + (info->data_base & 0xffff) + + (i * sizeof(u32))), + (info->data_data ? + info->data_data[i] : 0)); err = 0; @@ -3513,269 +3885,318 @@ return 0; } -#if TG3_DO_TSO != 0 +#if TG3_TSO_SUPPORT != 0 #define TG3_TSO_FW_RELEASE_MAJOR 0x1 -#define TG3_TSO_FW_RELASE_MINOR 0x8 +#define TG3_TSO_FW_RELASE_MINOR 0x3 #define TG3_TSO_FW_RELEASE_FIX 0x0 #define TG3_TSO_FW_START_ADDR 0x08000000 #define TG3_TSO_FW_TEXT_ADDR 0x08000000 -#define TG3_TSO_FW_TEXT_LEN 0x1650 +#define TG3_TSO_FW_TEXT_LEN 0x1ac0 #define TG3_TSO_FW_RODATA_ADDR 0x08001650 -#define TG3_TSO_FW_RODATA_LEN 0x30 +#define TG3_TSO_FW_RODATA_LEN 0x60 #define TG3_TSO_FW_DATA_ADDR 0x080016a0 #define TG3_TSO_FW_DATA_LEN 0x20 #define TG3_TSO_FW_SBSS_ADDR 0x080016c0 -#define TG3_TSO_FW_SBSS_LEN 0x14 +#define TG3_TSO_FW_SBSS_LEN 0x2c #define TG3_TSO_FW_BSS_ADDR 0x080016e0 -#define TG3_TSO_FW_BSS_LEN 0x8fc +#define TG3_TSO_FW_BSS_LEN 0x890 static u32 tg3TsoFwText[] = { 0x00000000, 0x10000003, 0x00000000, 0x0000000d, 0x0000000d, 0x3c1d0800, 0x37bd4000, 0x03a0f021, 0x3c100800, 0x26100000, 0x0e000010, 0x00000000, - 0x0000000d, 0x00000000, 0x00000000, 0x00000000, 0x27bdffe0, 0x3c1bc000, - 0xafbf0018, 0x0e000058, 0xaf60680c, 0x3c040800, 0x24841650, 0x03602821, - 0x24060001, 0x24070004, 0xafa00010, 0x0e00006c, 0xafa00014, 0x8f625c50, - 0x34420001, 0xaf625c50, 0x8f625c90, 0x34420001, 0xaf625c90, 0x2402ffff, - 0x0e000098, 0xaf625404, 0x8fbf0018, 0x03e00008, 0x27bd0020, 0x00000000, - 0x00000000, 0x00000000, 0x24030b60, 0x24050fff, 0xac000b50, 0x00002021, - 0xac640000, 0x24630004, 0x0065102b, 0x1440fffc, 0x24840001, 0x24030b60, - 0x0065102b, 0x10400011, 0x00002021, 0x24090b54, 0x3c06dead, 0x34c6beef, - 0x24080b58, 0x24070b5c, 0x8c620000, 0x50440006, 0x24630004, 0xad260000, - 0x8c620000, 0xace40000, 0xad020000, 0x24630004, 0x0065102b, 0x1440fff6, - 0x24840001, 0x03e00008, 0x00000000, 0x27bdfff8, 0x18800009, 0x00002821, - 0x8f63680c, 0x8f62680c, 0x1043fffe, 0x00000000, 0x24a50001, 0x00a4102a, - 0x1440fff9, 0x00000000, 0x03e00008, 0x27bd0008, 0x3c020800, 0x34423000, - 0x3c030800, 0x34633000, 0x3c040800, 0x348437ff, 0x3c010800, 0xac2216c4, - 0x24020040, 0x3c010800, 0xac2216c8, 0x3c010800, 0xac2016c0, 0xac600000, - 0x24630004, 0x0083102b, 0x5040fffd, 0xac600000, 0x03e00008, 0x00000000, - 0x00804821, 0x8faa0010, 0x3c020800, 0x8c4216c0, 0x3c040800, 0x8c8416c8, - 0x8fab0014, 0x24430001, 0x0044102b, 0x3c010800, 0xac2316c0, 0x14400003, - 0x00004021, 0x3c010800, 0xac2016c0, 0x3c020800, 0x8c4216c0, 0x3c030800, - 0x8c6316c4, 0x91240000, 0x00021140, 0x00431021, 0x00481021, 0x25080001, - 0xa0440000, 0x29020008, 0x1440fff4, 0x25290001, 0x3c020800, 0x8c4216c0, - 0x3c030800, 0x8c6316c4, 0x8f64680c, 0x00021140, 0x00431021, 0xac440008, - 0xac45000c, 0xac460010, 0xac470014, 0xac4a0018, 0x03e00008, 0xac4b001c, - 0x00000000, 0x00000000, 0x27bdffe0, 0xafbf0018, 0xafb10014, 0x0e0000b6, - 0xafb00010, 0x24110001, 0x8f706820, 0x32020100, 0x10400003, 0x00000000, - 0x0e000127, 0x00000000, 0x8f706820, 0x32022000, 0x10400004, 0x32020001, - 0x0e00025a, 0x24040001, 0x32020001, 0x10400003, 0x00000000, 0x0e0000e6, - 0x00000000, 0x0a00009e, 0xaf715028, 0x8fbf0018, 0x8fb10014, 0x8fb00010, - 0x03e00008, 0x27bd0020, 0x27bdffe0, 0x3c040800, 0x24841660, 0x00002821, - 0x00003021, 0x00003821, 0xafbf0018, 0xafa00010, 0x0e00006c, 0xafa00014, - 0x3c010800, 0xa4201fb8, 0x3c010800, 0xa02016f8, 0x3c010800, 0xac2016fc, - 0x3c010800, 0xac201700, 0x3c010800, 0xac201704, 0x3c010800, 0xac20170c, - 0x3c010800, 0xac201718, 0x3c010800, 0xac20171c, 0x8f624434, 0x3c010800, - 0xac2216e8, 0x8f624438, 0x3c010800, 0xac2216ec, 0x8f624410, 0x3c010800, - 0xac2016e0, 0x3c010800, 0xac2016e4, 0x3c010800, 0xac201fc0, 0x3c010800, - 0xac201f68, 0x3c010800, 0xac201f6c, 0x3c010800, 0xac2216f0, 0x8fbf0018, - 0x03e00008, 0x27bd0020, 0x27bdffe0, 0x3c040800, 0x2484166c, 0x00002821, - 0x00003021, 0x00003821, 0xafbf0018, 0xafa00010, 0x0e00006c, 0xafa00014, - 0x3c040800, 0x24841660, 0x00002821, 0x00003021, 0x00003821, 0xafa00010, - 0x0e00006c, 0xafa00014, 0x3c010800, 0xa4201fb8, 0x3c010800, 0xa02016f8, - 0x3c010800, 0xac2016fc, 0x3c010800, 0xac201700, 0x3c010800, 0xac201704, - 0x3c010800, 0xac20170c, 0x3c010800, 0xac201718, 0x3c010800, 0xac20171c, - 0x8f624434, 0x3c010800, 0xac2216e8, 0x8f624438, 0x3c010800, 0xac2216ec, - 0x8f624410, 0x3c010800, 0xac2016e0, 0x3c010800, 0xac2016e4, 0x3c010800, - 0xac201fc0, 0x3c010800, 0xac201f68, 0x3c010800, 0xac201f6c, 0x3c010800, - 0xac2216f0, 0x0e000120, 0x00002021, 0x8fbf0018, 0x03e00008, 0x27bd0020, - 0x24020001, 0x8f636820, 0x00821004, 0x00021027, 0x00621824, 0x03e00008, - 0xaf636820, 0x27bdffd0, 0x3c0300ff, 0xafbf002c, 0xafb60028, 0xafb50024, - 0xafb40020, 0xafb3001c, 0xafb20018, 0xafb10014, 0xafb00010, 0x8f665c5c, - 0x3c040800, 0x2484171c, 0x8c820000, 0x3463fff8, 0x14460005, 0x00c38824, - 0x3c020800, 0x904216f8, 0x14400115, 0x00000000, 0x00111902, 0x306300ff, - 0x30c20003, 0x000211c0, 0x00623825, 0x00e02821, 0x00061602, 0xac860000, - 0x3c030800, 0x906316f8, 0x3044000f, 0x1460002b, 0x00804021, 0x24020001, - 0x3c010800, 0xa02216f8, 0x00071100, 0x00821025, 0x3c010800, 0xac2016fc, - 0x3c010800, 0xac201700, 0x3c010800, 0xac201704, 0x3c010800, 0xac20170c, - 0x3c010800, 0xac201718, 0x3c010800, 0xac201710, 0x3c010800, 0xac201714, - 0x3c010800, 0xa4221fb8, 0x9623000c, 0x30628000, 0x10400008, 0x30627fff, - 0x2442003e, 0x3c010800, 0xa42216f6, 0x24020001, 0x3c010800, 0x0a00016e, - 0xac221fd4, 0x24620036, 0x3c010800, 0xa42216f6, 0x3c010800, 0xac201fd4, - 0x3c010800, 0xac201fd0, 0x3c010800, 0x0a000176, 0xac201fd8, 0x9622000c, - 0x3c010800, 0xa4221fcc, 0x3c040800, 0x248416fc, 0x8c820000, 0x00021100, - 0x3c010800, 0x00220821, 0xac311728, 0x8c820000, 0x00021100, 0x3c010800, - 0x00220821, 0xac26172c, 0x8c820000, 0x24a30001, 0x306701ff, 0x00021100, - 0x3c010800, 0x00220821, 0xac271730, 0x8c820000, 0x00021100, 0x3c010800, - 0x00220821, 0xac281734, 0x96230008, 0x3c020800, 0x8c42170c, 0x00432821, - 0x3c010800, 0xac25170c, 0x9622000a, 0x30420004, 0x14400019, 0x00071100, - 0x3c02c000, 0x00c21825, 0xaf635c5c, 0x8f625c50, 0x30420002, 0x1440fffc, - 0x00000000, 0x8f630c14, 0x3063000f, 0x2c620002, 0x1440001e, 0x00000000, - 0x8f630c14, 0x3c020800, 0x8c4216b4, 0x3063000f, 0x24420001, 0x3c010800, - 0xac2216b4, 0x2c620002, 0x1040fff7, 0x00000000, 0x0a0001c1, 0x00000000, - 0x3c030800, 0x8c6316e0, 0x3c040800, 0x948416f4, 0x01021025, 0x3c010800, - 0xa4221fba, 0x24020001, 0x3c010800, 0xac221718, 0x24630001, 0x0085202a, - 0x3c010800, 0x10800003, 0xac2316e0, 0x3c010800, 0xa42516f4, 0x3c030800, - 0x246316fc, 0x8c620000, 0x24420001, 0xac620000, 0x28420080, 0x14400005, - 0x24020001, 0x0e0002df, 0x24040002, 0x0a000250, 0x00000000, 0x3c030800, - 0x906316f8, 0x1462007c, 0x24020003, 0x3c160800, 0x96d616f6, 0x3c050800, - 0x8ca5170c, 0x32c4ffff, 0x00a4102a, 0x14400078, 0x00000000, 0x3c020800, - 0x8c421718, 0x10400005, 0x32c2ffff, 0x14a40003, 0x00000000, 0x3c010800, - 0xac231fd0, 0x10400062, 0x00009021, 0x0040a021, 0x3c150800, 0x26b51700, - 0x26b30010, 0x8ea20000, 0x00028100, 0x3c110800, 0x02308821, 0x0e0002e1, - 0x8e311728, 0x00403021, 0x10c00059, 0x00000000, 0x9628000a, 0x31020040, - 0x10400004, 0x2407180c, 0x8e22000c, 0x2407188c, 0xacc20018, 0x31021000, - 0x10400004, 0x34e32000, 0x00081040, 0x3042c000, 0x00623825, 0x3c030800, - 0x00701821, 0x8c631730, 0x3c020800, 0x00501021, 0x8c421734, 0x00031d00, - 0x00021400, 0x00621825, 0xacc30014, 0x8ea30004, 0x96220008, 0x00432023, - 0x3242ffff, 0x3083ffff, 0x00431021, 0x0282102a, 0x14400002, 0x02d22823, - 0x00802821, 0x8e620000, 0x30a4ffff, 0x00441021, 0xae620000, 0x8e220000, - 0xacc20000, 0x8e220004, 0x8e63fff4, 0x00431021, 0xacc20004, 0xa4c5000e, - 0x8e62fff4, 0x00441021, 0xae62fff4, 0x96230008, 0x0043102a, 0x14400005, - 0x02459021, 0x8e62fff0, 0xae60fff4, 0x24420001, 0xae62fff0, 0xacc00008, - 0x3242ffff, 0x14540008, 0x24020305, 0x31020080, 0x54400001, 0x34e70010, - 0x24020905, 0xa4c2000c, 0x0a000233, 0x34e70020, 0xa4c2000c, 0x30e2ffff, - 0xacc20010, 0x3c020800, 0x8c421fd0, 0x10400003, 0x3c024b65, 0x0a00023d, - 0x34427654, 0x3c02b49a, 0x344289ab, 0xacc2001c, 0x0e000560, 0x00c02021, - 0x3242ffff, 0x0054102b, 0x1440ffa4, 0x00000000, 0x24020002, 0x3c010800, - 0x0a000250, 0xa02216f8, 0x8ea208bc, 0x24420001, 0x0a000250, 0xaea208bc, - 0x14620003, 0x00000000, 0x0e000450, 0x00000000, 0x8fbf002c, 0x8fb60028, - 0x8fb50024, 0x8fb40020, 0x8fb3001c, 0x8fb20018, 0x8fb10014, 0x8fb00010, - 0x03e00008, 0x27bd0030, 0x27bdffd8, 0xafb3001c, 0x00809821, 0xafbf0020, - 0xafb20018, 0xafb10014, 0xafb00010, 0x8f725c9c, 0x3c0200ff, 0x3442fff8, - 0x3c040800, 0x24841714, 0x02428824, 0x9623000e, 0x8c820000, 0x00431021, - 0xac820000, 0x8e220010, 0x30420020, 0x14400011, 0x00000000, 0x0e0002f7, + 0x0000000d, 0x00000000, 0x00000000, 0x00000000, 0x27bdffe0, 0x3c04fefe, + 0xafbf0018, 0x0e0005e0, 0x34840002, 0x0e000670, 0x00000000, 0x3c030800, + 0x90631b78, 0x24020002, 0x3c040800, 0x24841acc, 0x14620003, 0x24050001, + 0x3c040800, 0x24841ac0, 0x24060002, 0x00003821, 0xafa00010, 0x0e000684, + 0xafa00014, 0x8f625c50, 0x34420001, 0xaf625c50, 0x8f625c90, 0x34420001, + 0xaf625c90, 0x2402ffff, 0x0e000034, 0xaf625404, 0x8fbf0018, 0x03e00008, + 0x27bd0020, 0x00000000, 0x00000000, 0x00000000, 0x27bdffe0, 0xafbf0018, + 0xafb10014, 0x0e000052, 0xafb00010, 0x24110001, 0x8f706820, 0x32020100, + 0x10400003, 0x00000000, 0x0e0000b2, 0x00000000, 0x8f706820, 0x32022000, + 0x10400004, 0x32020001, 0x0e0001e3, 0x24040001, 0x32020001, 0x10400003, + 0x00000000, 0x0e00009a, 0x00000000, 0x0a00003a, 0xaf715028, 0x8fbf0018, + 0x8fb10014, 0x8fb00010, 0x03e00008, 0x27bd0020, 0x27bdffe0, 0x3c040800, + 0x24841ae0, 0x00002821, 0x00003021, 0x00003821, 0xafbf0018, 0xafa00010, + 0x0e000684, 0xafa00014, 0x3c040800, 0x248423e8, 0xa4800000, 0x3c010800, + 0xa0201ba8, 0x3c010800, 0xac201bac, 0x3c010800, 0xac201bb0, 0x3c010800, + 0xac201bb4, 0x3c010800, 0xac201bbc, 0x3c010800, 0xac201bc8, 0x3c010800, + 0xac201bcc, 0x8f624434, 0x3c010800, 0xac221b98, 0x8f624438, 0x3c010800, + 0xac221b9c, 0x8f624410, 0xac80f7a8, 0x3c010800, 0xac201b94, 0x3c010800, + 0xac2023f0, 0x3c010800, 0xac2023d8, 0x3c010800, 0xac2023dc, 0x3c010800, + 0xac202410, 0x3c010800, 0xac221ba0, 0x8f620068, 0x24030007, 0x00021702, + 0x10430005, 0x00000000, 0x8f620068, 0x00021702, 0x14400004, 0x24020001, + 0x3c010800, 0x0a00008e, 0xac20241c, 0xac820034, 0x3c040800, 0x24841aec, + 0x3c050800, 0x8ca5241c, 0x00003021, 0x00003821, 0xafa00010, 0x0e000684, + 0xafa00014, 0x8fbf0018, 0x03e00008, 0x27bd0020, 0x27bdffe0, 0x3c040800, + 0x24841af8, 0x00002821, 0x00003021, 0x00003821, 0xafbf0018, 0xafa00010, + 0x0e000684, 0xafa00014, 0x0e000052, 0x00000000, 0x0e0000ab, 0x00002021, + 0x8fbf0018, 0x03e00008, 0x27bd0020, 0x24020001, 0x8f636820, 0x00821004, + 0x00021027, 0x00621824, 0x03e00008, 0xaf636820, 0x27bdffd0, 0xafbf002c, + 0xafb60028, 0xafb50024, 0xafb40020, 0xafb3001c, 0xafb20018, 0xafb10014, + 0xafb00010, 0x8f665c5c, 0x3c030800, 0x24631bcc, 0x8c620000, 0x14460005, + 0x3c0200ff, 0x3c020800, 0x90421ba8, 0x14400115, 0x3c0200ff, 0x3442fff8, + 0x00c28824, 0xac660000, 0x00111902, 0x306300ff, 0x30c20003, 0x000211c0, + 0x00623825, 0x00e02821, 0x00061602, 0x3c030800, 0x90631ba8, 0x3044000f, + 0x1460002b, 0x00804021, 0x24020001, 0x3c010800, 0xa0221ba8, 0x00071100, + 0x00821025, 0x3c010800, 0xac201bac, 0x3c010800, 0xac201bb0, 0x3c010800, + 0xac201bb4, 0x3c010800, 0xac201bbc, 0x3c010800, 0xac201bc8, 0x3c010800, + 0xac201bc0, 0x3c010800, 0xac201bc4, 0x3c010800, 0xa42223e8, 0x9623000c, + 0x30628000, 0x10400008, 0x30627fff, 0x2442003e, 0x3c010800, 0xa4221ba6, + 0x24020001, 0x3c010800, 0x0a0000f9, 0xac222404, 0x24620036, 0x3c010800, + 0xa4221ba6, 0x3c010800, 0xac202404, 0x3c010800, 0xac202400, 0x3c010800, + 0x0a000101, 0xac202408, 0x9622000c, 0x3c010800, 0xa42223fc, 0x3c040800, + 0x24841bac, 0x8c820000, 0x00021100, 0x3c010800, 0x00220821, 0xac311bd8, + 0x8c820000, 0x00021100, 0x3c010800, 0x00220821, 0xac261bdc, 0x8c820000, + 0x24a30001, 0x306701ff, 0x00021100, 0x3c010800, 0x00220821, 0xac271be0, + 0x8c820000, 0x00021100, 0x3c010800, 0x00220821, 0xac281be4, 0x96230008, + 0x3c020800, 0x8c421bbc, 0x00432821, 0x3c010800, 0xac251bbc, 0x9622000a, + 0x30420004, 0x14400018, 0x00071100, 0x8f630c14, 0x3063000f, 0x2c620002, + 0x1440000b, 0x3c02c000, 0x8f630c14, 0x3c020800, 0x8c421b50, 0x3063000f, + 0x24420001, 0x3c010800, 0xac221b50, 0x2c620002, 0x1040fff7, 0x3c02c000, + 0x00c21825, 0xaf635c5c, 0x8f625c50, 0x30420002, 0x10400014, 0x00000000, + 0x0a000133, 0x00000000, 0x3c030800, 0x8c631b90, 0x3c040800, 0x94841ba4, + 0x01021025, 0x3c010800, 0xa42223ea, 0x24020001, 0x3c010800, 0xac221bc8, + 0x24630001, 0x0085202a, 0x3c010800, 0x10800003, 0xac231b90, 0x3c010800, + 0xa4251ba4, 0x3c060800, 0x24c61bac, 0x8cc20000, 0x24420001, 0xacc20000, + 0x28420080, 0x14400005, 0x00000000, 0x0e00065e, 0x24040002, 0x0a0001d9, + 0x00000000, 0x3c020800, 0x8c421bc8, 0x1040007f, 0x24020001, 0x3c040800, + 0x90841ba8, 0x14820077, 0x24020003, 0x3c150800, 0x96b51ba6, 0x3c050800, + 0x8ca51bbc, 0x32a3ffff, 0x00a3102a, 0x14400073, 0x00000000, 0x14a30003, + 0x00000000, 0x3c010800, 0xac242400, 0x10600061, 0x00009021, 0x24d60004, + 0x0060a021, 0x24d30014, 0x8ec20000, 0x00028100, 0x3c110800, 0x02308821, + 0x0e00062d, 0x8e311bd8, 0x00403021, 0x10c00059, 0x00000000, 0x9628000a, + 0x31020040, 0x10400004, 0x2407180c, 0x8e22000c, 0x2407188c, 0xacc20018, + 0x31021000, 0x10400004, 0x34e32000, 0x00081040, 0x3042c000, 0x00623825, + 0x3c030800, 0x00701821, 0x8c631be0, 0x3c020800, 0x00501021, 0x8c421be4, + 0x00031d00, 0x00021400, 0x00621825, 0xacc30014, 0x8ec30004, 0x96220008, + 0x00432023, 0x3242ffff, 0x3083ffff, 0x00431021, 0x0282102a, 0x14400002, + 0x02b22823, 0x00802821, 0x8e620000, 0x30a4ffff, 0x00441021, 0xae620000, + 0x8e220000, 0xacc20000, 0x8e220004, 0x8e63fff4, 0x00431021, 0xacc20004, + 0xa4c5000e, 0x8e62fff4, 0x00441021, 0xae62fff4, 0x96230008, 0x0043102a, + 0x14400005, 0x02459021, 0x8e62fff0, 0xae60fff4, 0x24420001, 0xae62fff0, + 0xacc00008, 0x3242ffff, 0x14540008, 0x24020305, 0x31020080, 0x54400001, + 0x34e70010, 0x24020905, 0xa4c2000c, 0x0a0001bc, 0x34e70020, 0xa4c2000c, + 0x3c020800, 0x8c422400, 0x10400003, 0x3c024b65, 0x0a0001c4, 0x34427654, + 0x3c02b49a, 0x344289ab, 0xacc2001c, 0x30e2ffff, 0xacc20010, 0x0e0005aa, + 0x00c02021, 0x3242ffff, 0x0054102b, 0x1440ffa4, 0x00000000, 0x24020002, + 0x3c010800, 0x0a0001d9, 0xa0221ba8, 0x8ec2083c, 0x24420001, 0x0a0001d9, + 0xaec2083c, 0x14820003, 0x00000000, 0x0e0004b9, 0x00000000, 0x8fbf002c, + 0x8fb60028, 0x8fb50024, 0x8fb40020, 0x8fb3001c, 0x8fb20018, 0x8fb10014, + 0x8fb00010, 0x03e00008, 0x27bd0030, 0x27bdffd0, 0xafbf0028, 0xafb30024, + 0xafb20020, 0xafb1001c, 0xafb00018, 0x8f725c9c, 0x3c0200ff, 0x3442fff8, + 0x3c060800, 0x24c61bc4, 0x02428824, 0x9623000e, 0x8cc20000, 0x00431021, + 0xacc20000, 0x8e220010, 0x30420020, 0x14400011, 0x00809821, 0x0e000643, 0x02202021, 0x3c02c000, 0x02421825, 0xaf635c9c, 0x8f625c90, 0x30420002, - 0x10400061, 0x00000000, 0xaf635c9c, 0x8f625c90, 0x30420002, 0x1040005c, - 0x00000000, 0x0a000278, 0x00000000, 0x8e220008, 0x00021c02, 0x000321c0, - 0x3042ffff, 0x3c030800, 0x906316f8, 0x000229c0, 0x24020002, 0x14620003, - 0x3c034b65, 0x0a000290, 0x00008021, 0x8e22001c, 0x34637654, 0x10430002, - 0x24100002, 0x24100001, 0x0e000300, 0x02003021, 0x24020003, 0x3c010800, - 0xa02216f8, 0x24020002, 0x1202000a, 0x24020001, 0x3c030800, 0x8c631fd0, - 0x10620006, 0x00000000, 0x3c020800, 0x94421fb8, 0x00021400, 0x0a0002cd, - 0xae220014, 0x3c040800, 0x24841fba, 0x94820000, 0x00021400, 0xae220014, - 0x3c020800, 0x8c42171c, 0x3c03c000, 0x3c010800, 0xa02016f8, 0x00431025, - 0xaf625c5c, 0x8f625c50, 0x30420002, 0x10400009, 0x00000000, 0x2484f762, + 0x10400121, 0x00000000, 0xaf635c9c, 0x8f625c90, 0x30420002, 0x1040011c, + 0x00000000, 0x0a000200, 0x00000000, 0x8e240008, 0x8e230014, 0x00041402, + 0x000241c0, 0x00031502, 0x304201ff, 0x2442ffff, 0x3042007f, 0x00031942, + 0x30637800, 0x00021100, 0x24424000, 0x00625021, 0x9542000a, 0x3084ffff, + 0x30420008, 0x104000b3, 0x000429c0, 0x3c020800, 0x8c422410, 0x1440002d, + 0x25050008, 0x95020014, 0x3c010800, 0xa42223e0, 0x8d070010, 0x00071402, + 0x3c010800, 0xa42223e2, 0x3c010800, 0xa42723e4, 0x9502000e, 0x30e3ffff, + 0x00431023, 0x3c010800, 0xac222418, 0x8f626800, 0x3c030010, 0x00431024, + 0x10400005, 0x00000000, 0x9503001a, 0x9502001c, 0x0a000235, 0x00431021, + 0x9502001a, 0x3c010800, 0xac22240c, 0x3c02c000, 0x02421825, 0x3c010800, + 0xac282410, 0x3c010800, 0xac322414, 0xaf635c9c, 0x8f625c90, 0x30420002, + 0x104000df, 0x00000000, 0xaf635c9c, 0x8f625c90, 0x30420002, 0x104000da, + 0x00000000, 0x0a000242, 0x00000000, 0x9502000e, 0x3c030800, 0x946323e4, + 0x00434823, 0x3123ffff, 0x2c620008, 0x1040001c, 0x00000000, 0x95020014, + 0x24420028, 0x00a22821, 0x00031042, 0x1840000b, 0x00002021, 0x24c60848, + 0x00403821, 0x94a30000, 0x8cc20000, 0x24840001, 0x00431021, 0xacc20000, + 0x0087102a, 0x1440fff9, 0x24a50002, 0x31220001, 0x1040001f, 0x3c024000, + 0x3c040800, 0x2484240c, 0xa0a00001, 0x94a30000, 0x8c820000, 0x00431021, + 0x0a000281, 0xac820000, 0x8f626800, 0x3c030010, 0x00431024, 0x10400009, + 0x00000000, 0x9502001a, 0x3c030800, 0x8c63240c, 0x00431021, 0x3c010800, + 0xac22240c, 0x0a000282, 0x3c024000, 0x9502001a, 0x9504001c, 0x3c030800, + 0x8c63240c, 0x00441023, 0x00621821, 0x3c010800, 0xac23240c, 0x3c024000, + 0x02421825, 0xaf635c9c, 0x8f625c90, 0x30420002, 0x1440fffc, 0x00000000, + 0x9542000a, 0x30420010, 0x10400095, 0x00000000, 0x3c060800, 0x24c62410, + 0x3c020800, 0x944223e4, 0x8cc50000, 0x3c040800, 0x8c842418, 0x24420030, + 0x00a22821, 0x94a20004, 0x3c030800, 0x8c63240c, 0x00441023, 0x00621821, + 0x00603821, 0x00032402, 0x30e2ffff, 0x00823821, 0x00071402, 0x00e23821, + 0x00071027, 0x3c010800, 0xac23240c, 0xa4a20006, 0x3c030800, 0x8c632414, + 0x3c0200ff, 0x3442fff8, 0x00628824, 0x96220008, 0x24040001, 0x24034000, + 0x000241c0, 0x00e01021, 0xa502001a, 0xa500001c, 0xacc00000, 0x3c010800, + 0xac241b70, 0xaf635cb8, 0x8f625cb0, 0x30420002, 0x10400003, 0x00000000, + 0x3c010800, 0xac201b70, 0x8e220008, 0xaf625cb8, 0x8f625cb0, 0x30420002, + 0x10400003, 0x00000000, 0x3c010800, 0xac201b70, 0x3c020800, 0x8c421b70, + 0x1040ffec, 0x00000000, 0x3c040800, 0x0e000643, 0x8c842414, 0x0a000320, + 0x00000000, 0x3c030800, 0x90631ba8, 0x24020002, 0x14620003, 0x3c034b65, + 0x0a0002d7, 0x00008021, 0x8e22001c, 0x34637654, 0x10430002, 0x24100002, + 0x24100001, 0x01002021, 0x0e000346, 0x02003021, 0x24020003, 0x3c010800, + 0xa0221ba8, 0x24020002, 0x1202000a, 0x24020001, 0x3c030800, 0x8c632400, + 0x10620006, 0x00000000, 0x3c020800, 0x944223e8, 0x00021400, 0x0a000315, + 0xae220014, 0x3c040800, 0x248423ea, 0x94820000, 0x00021400, 0xae220014, + 0x3c020800, 0x8c421bcc, 0x3c03c000, 0x3c010800, 0xa0201ba8, 0x00431025, + 0xaf625c5c, 0x8f625c50, 0x30420002, 0x10400009, 0x00000000, 0x2484f7e2, 0x8c820000, 0x00431025, 0xaf625c5c, 0x8f625c50, 0x30420002, 0x1440fffa, - 0x00000000, 0x3c020800, 0x244216e4, 0x8c430000, 0x24630001, 0xac430000, - 0x8f630c14, 0x3063000f, 0x2c620002, 0x1440000b, 0x00009821, 0x8f630c14, - 0x3c020800, 0x8c4216b4, 0x3063000f, 0x24420001, 0x3c010800, 0xac2216b4, - 0x2c620002, 0x1040fff7, 0x00009821, 0x3c024000, 0x02421825, 0xaf635c9c, + 0x00000000, 0x3c020800, 0x24421b94, 0x8c430000, 0x24630001, 0xac430000, + 0x8f630c14, 0x3063000f, 0x2c620002, 0x1440000c, 0x3c024000, 0x8f630c14, + 0x3c020800, 0x8c421b50, 0x3063000f, 0x24420001, 0x3c010800, 0xac221b50, + 0x2c620002, 0x1040fff7, 0x00000000, 0x3c024000, 0x02421825, 0xaf635c9c, 0x8f625c90, 0x30420002, 0x1440fffc, 0x00000000, 0x12600003, 0x00000000, - 0x0e000450, 0x00000000, 0x8fbf0020, 0x8fb3001c, 0x8fb20018, 0x8fb10014, - 0x8fb00010, 0x03e00008, 0x27bd0028, 0x0a0002df, 0x00000000, 0x8f634450, - 0x3c040800, 0x248416e8, 0x8c820000, 0x00031c02, 0x0043102b, 0x14400007, - 0x3c038000, 0x8c840004, 0x8f624450, 0x00021c02, 0x0083102b, 0x1040fffc, - 0x3c038000, 0xaf634444, 0x8f624444, 0x00431024, 0x1440fffd, 0x00000000, - 0x8f624448, 0x03e00008, 0x3042ffff, 0x3c024000, 0x00822025, 0xaf645c38, - 0x8f625c30, 0x30420002, 0x1440fffc, 0x00000000, 0x03e00008, 0x00000000, - 0x27bdffe0, 0x00805021, 0x14c00017, 0x254c0008, 0x3c020800, 0x8c421fd4, - 0x1040000a, 0x2402003e, 0x3c010800, 0xa4221fb0, 0x24020016, 0x3c010800, - 0xa4221fb2, 0x2402002a, 0x3c010800, 0x0a00031a, 0xa4221fb4, 0x95420014, - 0x3c010800, 0xa4221fb0, 0x8d430010, 0x00031402, 0x3c010800, 0xa4221fb2, - 0x3c010800, 0xa4231fb4, 0x3c040800, 0x94841fb4, 0x3c030800, 0x94631fb2, - 0x958d0006, 0x3c020800, 0x94421fb0, 0x00832023, 0x01a27023, 0x3065ffff, - 0x24a20028, 0x01824021, 0x3082ffff, 0x14c0001a, 0x01025821, 0x9562000c, - 0x3042003f, 0x3c010800, 0xa4221fb6, 0x95620004, 0x95630006, 0x3c010800, - 0xac201fc4, 0x3c010800, 0xac201fc8, 0x00021400, 0x00431025, 0x3c010800, - 0xac221720, 0x95020004, 0x3c010800, 0xa4221724, 0x95030002, 0x01a51023, - 0x0043102a, 0x10400010, 0x24020001, 0x3c010800, 0x0a00034e, 0xac221fd8, - 0x3c030800, 0x8c631fc8, 0x3c020800, 0x94421724, 0x00431021, 0xa5020004, - 0x3c020800, 0x94421720, 0xa5620004, 0x3c020800, 0x8c421720, 0xa5620006, - 0x3c020800, 0x8c421fd0, 0x3c070800, 0x8ce71fc4, 0x3c050800, 0x144000c7, - 0x8ca51fc8, 0x3c020800, 0x94421724, 0x00451821, 0x3063ffff, 0x0062182b, - 0x24020002, 0x10c2000d, 0x00a32823, 0x3c020800, 0x94421fb6, 0x30420009, - 0x10400008, 0x00000000, 0x9562000c, 0x3042fff6, 0xa562000c, 0x3c020800, - 0x94421fb6, 0x30420009, 0x00e23823, 0x3c020800, 0x8c421fd8, 0x1040004b, - 0x24020002, 0x01003021, 0x3c020800, 0x94421fb2, 0x00003821, 0xa500000a, - 0x01a21023, 0xa5020002, 0x3082ffff, 0x00021042, 0x18400008, 0x00002821, - 0x00401821, 0x94c20000, 0x24e70001, 0x00a22821, 0x00e3102a, 0x1440fffb, - 0x24c60002, 0x00051c02, 0x30a2ffff, 0x00622821, 0x00051402, 0x00a22821, - 0x00a04821, 0x00051027, 0xa502000a, 0x00002821, 0x2506000c, 0x00003821, - 0x94c20000, 0x24e70001, 0x00a22821, 0x2ce20004, 0x1440fffb, 0x24c60002, - 0x95020002, 0x00003821, 0x91030009, 0x00442023, 0x01603021, 0x3082ffff, - 0xa4c00010, 0x00621821, 0x00021042, 0x18400010, 0x00a32821, 0x00404021, - 0x94c20000, 0x24c60002, 0x00a22821, 0x30c2007f, 0x14400006, 0x24e70001, - 0x8d430000, 0x3c02007f, 0x3442ff80, 0x00625024, 0x25460008, 0x00e8102a, - 0x1440fff3, 0x00000000, 0x30820001, 0x10400005, 0x00051c02, 0xa0c00001, - 0x94c20000, 0x00a22821, 0x00051c02, 0x30a2ffff, 0x00622821, 0x00051402, - 0x00a22821, 0x0a000415, 0x30a5ffff, 0x14c20063, 0x00000000, 0x3c090800, - 0x95291fb2, 0x95030002, 0x01a91023, 0x1062005d, 0x01003021, 0x00003821, - 0x00002821, 0x01a91023, 0xa5020002, 0x3082ffff, 0x00021042, 0x18400008, - 0xa500000a, 0x00401821, 0x94c20000, 0x24e70001, 0x00a22821, 0x00e3102a, - 0x1440fffb, 0x24c60002, 0x00051c02, 0x30a2ffff, 0x00622821, 0x00051402, - 0x00a22821, 0x00a04821, 0x00051027, 0xa502000a, 0x00002821, 0x2506000c, - 0x00003821, 0x94c20000, 0x24e70001, 0x00a22821, 0x2ce20004, 0x1440fffb, - 0x24c60002, 0x95020002, 0x00003821, 0x91030009, 0x00442023, 0x01603021, - 0x3082ffff, 0xa4c00010, 0x3c040800, 0x94841fb4, 0x00621821, 0x00a32821, - 0x00051c02, 0x30a2ffff, 0x00622821, 0x00051c02, 0x3c020800, 0x94421fb0, - 0x00a34021, 0x00441023, 0x00021fc2, 0x00431021, 0x00021043, 0x18400010, - 0x00002821, 0x00402021, 0x94c20000, 0x24c60002, 0x00a22821, 0x30c2007f, - 0x14400006, 0x24e70001, 0x8d430000, 0x3c02007f, 0x3442ff80, 0x00625024, - 0x25460008, 0x00e4102a, 0x1440fff3, 0x00000000, 0x3c020800, 0x94421fcc, - 0x00a22821, 0x00051c02, 0x30a2ffff, 0x00622821, 0x00051402, 0x00a22821, - 0x3102ffff, 0x00a22821, 0x00051c02, 0x30a2ffff, 0x00622821, 0x00051402, - 0x00a22821, 0x00a02021, 0x00051027, 0xa5620010, 0xad800014, 0x0a000435, - 0xad800000, 0x8d830010, 0x00602021, 0x10a00007, 0x00034c02, 0x01252821, - 0x00051402, 0x30a3ffff, 0x00432821, 0x00051402, 0x00a24821, 0x00091027, - 0xa502000a, 0x3c030800, 0x94631fb4, 0x3082ffff, 0x01a21021, 0x00432823, - 0x00a72821, 0x00051c02, 0x30a2ffff, 0x00622821, 0x00051402, 0x00a22821, - 0x00a02021, 0x00051027, 0xa5620010, 0x3082ffff, 0x00091c00, 0x00431025, - 0xad820010, 0x3c020800, 0x8c421fd4, 0x10400002, 0x25a2fff2, 0xa5820034, - 0x3c020800, 0x8c421fc8, 0x3c030800, 0x8c631720, 0x24420001, 0x3c010800, - 0xac221fc8, 0x3c020800, 0x8c421fc4, 0x31c4ffff, 0x00641821, 0x3c010800, - 0xac231720, 0x00441021, 0x3c010800, 0xac221fc4, 0x03e00008, 0x27bd0020, - 0x27bdffc8, 0x3c040800, 0x248416f8, 0xafbf0034, 0xafbe0030, 0xafb7002c, - 0xafb60028, 0xafb50024, 0xafb40020, 0xafb3001c, 0xafb20018, 0xafb10014, - 0xafb00010, 0x90830000, 0x24020003, 0x146200f4, 0x00000000, 0x3c020800, - 0x8c421710, 0x3c030800, 0x8c63170c, 0x3c1e0800, 0x97de16f6, 0x0043102a, - 0x104000eb, 0x3c168000, 0x249708c4, 0x33d5ffff, 0x24920018, 0x3c020800, - 0x8c421718, 0x104000e4, 0x00000000, 0x3c140800, 0x96941fb0, 0x3282ffff, - 0x104000d6, 0x00008021, 0x00409821, 0x00008821, 0x8f634450, 0x3c020800, - 0x8c4216e8, 0x00031c02, 0x0043102b, 0x14400008, 0x00000000, 0x3c040800, - 0x8c8416ec, 0x8f624450, 0x00021c02, 0x0083102b, 0x1040fffc, 0x00000000, - 0xaf764444, 0x8f624444, 0x00561024, 0x10400006, 0x00000000, 0x3c038000, - 0x8f624444, 0x00431024, 0x1440fffd, 0x00000000, 0x8f624448, 0x3046ffff, - 0x10c0005f, 0x00000000, 0x3c090800, 0x01314821, 0x8d291728, 0x9528000a, - 0x31020040, 0x10400004, 0x2407180c, 0x8d22000c, 0x2407188c, 0xacc20018, - 0x31021000, 0x10400004, 0x34e32000, 0x00081040, 0x3042c000, 0x00623825, - 0x31020080, 0x54400001, 0x34e70010, 0x3c020800, 0x00511021, 0x8c421730, - 0x3c030800, 0x00711821, 0x8c631734, 0x00021500, 0x00031c00, 0x00431025, - 0xacc20014, 0x95240008, 0x3202ffff, 0x00821021, 0x0262102a, 0x14400002, - 0x02902823, 0x00802821, 0x8d220000, 0x02058021, 0xacc20000, 0x8d220004, - 0x00c02021, 0x26310010, 0xac820004, 0x30e2ffff, 0xac800008, 0xa485000e, - 0xac820010, 0x24020305, 0x0e000560, 0xa482000c, 0x3202ffff, 0x0053102b, - 0x1440ffaf, 0x3202ffff, 0x0a00054c, 0x00000000, 0x8e420000, 0x8e43fffc, - 0x0043102a, 0x10400084, 0x00000000, 0x8e45fff0, 0x8f644450, 0x3c030800, - 0x8c6316e8, 0x00051100, 0x3c090800, 0x01224821, 0x8d291728, 0x00041402, - 0x0062182b, 0x14600008, 0x00000000, 0x3c030800, 0x8c6316ec, 0x8f624450, - 0x00021402, 0x0062102b, 0x1040fffc, 0x00000000, 0xaf764444, 0x8f624444, - 0x00561024, 0x10400006, 0x00000000, 0x3c038000, 0x8f624444, 0x00431024, - 0x1440fffd, 0x00000000, 0x8f624448, 0x3046ffff, 0x14c00005, 0x00000000, - 0x8ee20000, 0x24420001, 0x0a000554, 0xaee20000, 0x9528000a, 0x31020040, - 0x10400004, 0x2407180c, 0x8d22000c, 0x2407188c, 0xacc20018, 0x31021000, - 0x10400004, 0x34e32000, 0x00081040, 0x3042c000, 0x00623825, 0x00051900, - 0x3c020800, 0x00431021, 0x8c421730, 0x3c010800, 0x00230821, 0x8c231734, - 0x00021500, 0x00031c00, 0x00431025, 0xacc20014, 0x3c030800, 0x8c631704, - 0x95220008, 0x00432023, 0x3202ffff, 0x3083ffff, 0x00431021, 0x02a2102a, - 0x14400002, 0x03d02823, 0x00802821, 0x8e420000, 0x30a4ffff, 0x00441021, - 0xae420000, 0xa4c5000e, 0x8d220000, 0xacc20000, 0x8d220004, 0x8e43fff4, - 0x00431021, 0xacc20004, 0x8e43fff4, 0x95220008, 0x00641821, 0x0062102a, - 0x14400006, 0x02058021, 0x8e42fff0, 0xae40fff4, 0x24420001, 0x0a000530, - 0xae42fff0, 0xae43fff4, 0xacc00008, 0x3202ffff, 0x10550003, 0x31020004, - 0x10400006, 0x24020305, 0x31020080, 0x54400001, 0x34e70010, 0x34e70020, - 0x24020905, 0xa4c2000c, 0x30e2ffff, 0xacc20010, 0x3c030800, 0x8c63170c, - 0x3c020800, 0x8c421710, 0x54620004, 0x3c02b49a, 0x3c024b65, 0x0a000548, - 0x34427654, 0x344289ab, 0xacc2001c, 0x0e000560, 0x00c02021, 0x3202ffff, - 0x0055102b, 0x1440ff7e, 0x00000000, 0x8e420000, 0x8e43fffc, 0x0043102a, - 0x1440ff1a, 0x00000000, 0x8fbf0034, 0x8fbe0030, 0x8fb7002c, 0x8fb60028, - 0x8fb50024, 0x8fb40020, 0x8fb3001c, 0x8fb20018, 0x8fb10014, 0x8fb00010, - 0x03e00008, 0x27bd0038, 0x27bdffe8, 0xafbf0014, 0xafb00010, 0x8f624450, - 0x8f634410, 0x0a00056f, 0x00808021, 0x8f626820, 0x30422000, 0x10400003, - 0x00000000, 0x0e00025a, 0x00002021, 0x8f624450, 0x8f634410, 0x3042ffff, - 0x0043102b, 0x1440fff5, 0x00000000, 0x8f630c14, 0x3063000f, 0x2c620002, - 0x1440000b, 0x00000000, 0x8f630c14, 0x3c020800, 0x8c4216b4, 0x3063000f, - 0x24420001, 0x3c010800, 0xac2216b4, 0x2c620002, 0x1040fff7, 0x00000000, - 0xaf705c18, 0x8f625c10, 0x30420002, 0x10400009, 0x00000000, 0x8f626820, - 0x30422000, 0x1040fff8, 0x00000000, 0x0e00025a, 0x00002021, 0x0a000582, - 0x00000000, 0x8fbf0014, 0x8fb00010, 0x03e00008, 0x27bd0018, 0x00000000, - 0x00000000 + 0x0e0004b9, 0x00000000, 0x8fbf0028, 0x8fb30024, 0x8fb20020, 0x8fb1001c, + 0x8fb00018, 0x03e00008, 0x27bd0030, 0x8f634450, 0x3c040800, 0x24841b98, + 0x8c820000, 0x00031c02, 0x0043102b, 0x14400007, 0x3c038000, 0x8c840004, + 0x8f624450, 0x00021c02, 0x0083102b, 0x1040fffc, 0x3c038000, 0xaf634444, + 0x8f624444, 0x00431024, 0x1440fffd, 0x00000000, 0x8f624448, 0x03e00008, + 0x3042ffff, 0x3c024000, 0x00822025, 0xaf645c38, 0x8f625c30, 0x30420002, + 0x1440fffc, 0x00000000, 0x03e00008, 0x00000000, 0x27bdffe0, 0x00805821, + 0x14c00017, 0x256e0008, 0x3c020800, 0x8c422404, 0x1040000a, 0x2402003e, + 0x3c010800, 0xa42223e0, 0x24020016, 0x3c010800, 0xa42223e2, 0x2402002a, + 0x3c010800, 0x0a000360, 0xa42223e4, 0x95620014, 0x3c010800, 0xa42223e0, + 0x8d670010, 0x00071402, 0x3c010800, 0xa42223e2, 0x3c010800, 0xa42723e4, + 0x3c040800, 0x948423e4, 0x3c030800, 0x946323e2, 0x95cf0006, 0x3c020800, + 0x944223e0, 0x00832023, 0x01e2c023, 0x3065ffff, 0x24a20028, 0x01c24821, + 0x3082ffff, 0x14c0001a, 0x01226021, 0x9582000c, 0x3042003f, 0x3c010800, + 0xa42223e6, 0x95820004, 0x95830006, 0x3c010800, 0xac2023f4, 0x3c010800, + 0xac2023f8, 0x00021400, 0x00431025, 0x3c010800, 0xac221bd0, 0x95220004, + 0x3c010800, 0xa4221bd4, 0x95230002, 0x01e51023, 0x0043102a, 0x10400010, + 0x24020001, 0x3c010800, 0x0a000394, 0xac222408, 0x3c030800, 0x8c6323f8, + 0x3c020800, 0x94421bd4, 0x00431021, 0xa5220004, 0x3c020800, 0x94421bd0, + 0xa5820004, 0x3c020800, 0x8c421bd0, 0xa5820006, 0x3c020800, 0x8c422400, + 0x3c0d0800, 0x8dad23f4, 0x3c0a0800, 0x144000e5, 0x8d4a23f8, 0x3c020800, + 0x94421bd4, 0x004a1821, 0x3063ffff, 0x0062182b, 0x24020002, 0x10c2000d, + 0x01435023, 0x3c020800, 0x944223e6, 0x30420009, 0x10400008, 0x00000000, + 0x9582000c, 0x3042fff6, 0xa582000c, 0x3c020800, 0x944223e6, 0x30420009, + 0x01a26823, 0x3c020800, 0x8c422408, 0x1040004a, 0x01203821, 0x3c020800, + 0x944223e2, 0x00004021, 0xa520000a, 0x01e21023, 0xa5220002, 0x3082ffff, + 0x00021042, 0x18400008, 0x00003021, 0x00401821, 0x94e20000, 0x25080001, + 0x00c23021, 0x0103102a, 0x1440fffb, 0x24e70002, 0x00061c02, 0x30c2ffff, + 0x00623021, 0x00061402, 0x00c23021, 0x00c02821, 0x00061027, 0xa522000a, + 0x00003021, 0x2527000c, 0x00004021, 0x94e20000, 0x25080001, 0x00c23021, + 0x2d020004, 0x1440fffb, 0x24e70002, 0x95220002, 0x00004021, 0x91230009, + 0x00442023, 0x01803821, 0x3082ffff, 0xa4e00010, 0x00621821, 0x00021042, + 0x18400010, 0x00c33021, 0x00404821, 0x94e20000, 0x24e70002, 0x00c23021, + 0x30e2007f, 0x14400006, 0x25080001, 0x8d630000, 0x3c02007f, 0x3442ff80, + 0x00625824, 0x25670008, 0x0109102a, 0x1440fff3, 0x00000000, 0x30820001, + 0x10400005, 0x00061c02, 0xa0e00001, 0x94e20000, 0x00c23021, 0x00061c02, + 0x30c2ffff, 0x00623021, 0x00061402, 0x00c23021, 0x0a000479, 0x30c6ffff, + 0x24020002, 0x14c20081, 0x00000000, 0x3c020800, 0x8c42241c, 0x14400007, + 0x00000000, 0x3c020800, 0x944223e2, 0x95230002, 0x01e21023, 0x10620077, + 0x00000000, 0x3c020800, 0x944223e2, 0x01e21023, 0xa5220002, 0x3c020800, + 0x8c42241c, 0x1040001a, 0x31e3ffff, 0x8dc70010, 0x3c020800, 0x94421ba6, + 0x00e04021, 0x00072c02, 0x00aa2021, 0x00431023, 0x00823823, 0x00072402, + 0x30e2ffff, 0x00823821, 0x00071027, 0xa522000a, 0x3102ffff, 0x3c040800, + 0x948423e4, 0x00453023, 0x00e02821, 0x00641823, 0x006d1821, 0x00c33021, + 0x00061c02, 0x30c2ffff, 0x0a000479, 0x00623021, 0x01203821, 0x00004021, + 0x3082ffff, 0x00021042, 0x18400008, 0x00003021, 0x00401821, 0x94e20000, + 0x25080001, 0x00c23021, 0x0103102a, 0x1440fffb, 0x24e70002, 0x00061c02, + 0x30c2ffff, 0x00623021, 0x00061402, 0x00c23021, 0x00c02821, 0x00061027, + 0xa522000a, 0x00003021, 0x2527000c, 0x00004021, 0x94e20000, 0x25080001, + 0x00c23021, 0x2d020004, 0x1440fffb, 0x24e70002, 0x95220002, 0x00004021, + 0x91230009, 0x00442023, 0x01803821, 0x3082ffff, 0xa4e00010, 0x3c040800, + 0x948423e4, 0x00621821, 0x00c33021, 0x00061c02, 0x30c2ffff, 0x00623021, + 0x00061c02, 0x3c020800, 0x944223e0, 0x00c34821, 0x00441023, 0x00021fc2, + 0x00431021, 0x00021043, 0x18400010, 0x00003021, 0x00402021, 0x94e20000, + 0x24e70002, 0x00c23021, 0x30e2007f, 0x14400006, 0x25080001, 0x8d630000, + 0x3c02007f, 0x3442ff80, 0x00625824, 0x25670008, 0x0104102a, 0x1440fff3, + 0x00000000, 0x3c020800, 0x944223fc, 0x00c23021, 0x3122ffff, 0x00c23021, + 0x00061c02, 0x30c2ffff, 0x00623021, 0x00061402, 0x00c23021, 0x00c04021, + 0x00061027, 0xa5820010, 0xadc00014, 0x0a000499, 0xadc00000, 0x8dc70010, + 0x00e04021, 0x11400007, 0x00072c02, 0x00aa3021, 0x00061402, 0x30c3ffff, + 0x00433021, 0x00061402, 0x00c22821, 0x00051027, 0xa522000a, 0x3c030800, + 0x946323e4, 0x3102ffff, 0x01e21021, 0x00433023, 0x00cd3021, 0x00061c02, + 0x30c2ffff, 0x00623021, 0x00061402, 0x00c23021, 0x00c04021, 0x00061027, + 0xa5820010, 0x3102ffff, 0x00051c00, 0x00431025, 0xadc20010, 0x3c020800, + 0x8c422404, 0x10400002, 0x25e2fff2, 0xa5c20034, 0x3c020800, 0x8c4223f8, + 0x3c040800, 0x8c8423f4, 0x24420001, 0x3c010800, 0xac2223f8, 0x3c020800, + 0x8c421bd0, 0x3303ffff, 0x00832021, 0x3c010800, 0xac2423f4, 0x00431821, + 0x0062102b, 0x10400003, 0x2482ffff, 0x3c010800, 0xac2223f4, 0x3c010800, + 0xac231bd0, 0x03e00008, 0x27bd0020, 0x27bdffb8, 0x3c050800, 0x24a51ba8, + 0xafbf0044, 0xafbe0040, 0xafb7003c, 0xafb60038, 0xafb50034, 0xafb40030, + 0xafb3002c, 0xafb20028, 0xafb10024, 0xafb00020, 0x90a30000, 0x24020003, + 0x146200d5, 0x00000000, 0x3c090800, 0x95291ba6, 0x3c020800, 0x944223e0, + 0x3c030800, 0x8c631bc0, 0x3c040800, 0x8c841bbc, 0x01221023, 0x0064182a, + 0xa7a9001e, 0x106000c8, 0xa7a20016, 0x24be0020, 0x97b6001e, 0x24b30018, + 0x24b70014, 0x8fc20000, 0x14400008, 0x00000000, 0x8fc2fff8, 0x97a30016, + 0x8fc4fff4, 0x00431021, 0x0082202a, 0x148000ba, 0x00000000, 0x97d50818, + 0x32a2ffff, 0x104000ad, 0x00009021, 0x0040a021, 0x00008821, 0x0e00062d, + 0x00000000, 0x00403021, 0x14c00007, 0x00000000, 0x3c020800, 0x8c4223ec, + 0x24420001, 0x3c010800, 0x0a00059e, 0xac2223ec, 0x3c100800, 0x02118021, + 0x8e101bd8, 0x9608000a, 0x31020040, 0x10400004, 0x2407180c, 0x8e02000c, + 0x2407188c, 0xacc20018, 0x31021000, 0x10400004, 0x34e32000, 0x00081040, + 0x3042c000, 0x00623825, 0x31020080, 0x54400001, 0x34e70010, 0x3c020800, + 0x00511021, 0x8c421be0, 0x3c030800, 0x00711821, 0x8c631be4, 0x00021500, + 0x00031c00, 0x00431025, 0xacc20014, 0x96040008, 0x3242ffff, 0x00821021, + 0x0282102a, 0x14400002, 0x02b22823, 0x00802821, 0x8e020000, 0x02459021, + 0xacc20000, 0x8e020004, 0x00c02021, 0x26310010, 0xac820004, 0x30e2ffff, + 0xac800008, 0xa485000e, 0xac820010, 0x24020305, 0x0e0005aa, 0xa482000c, + 0x3242ffff, 0x0054102b, 0x1440ffc0, 0x3242ffff, 0x0a000596, 0x00000000, + 0x8e620000, 0x8e63fffc, 0x0043102a, 0x1040006c, 0x00000000, 0x8e62fff0, + 0x00028900, 0x3c100800, 0x02118021, 0x0e00062d, 0x8e101bd8, 0x00403021, + 0x14c00005, 0x00000000, 0x8e62082c, 0x24420001, 0x0a00059e, 0xae62082c, + 0x9608000a, 0x31020040, 0x10400004, 0x2407180c, 0x8e02000c, 0x2407188c, + 0xacc20018, 0x31021000, 0x10400004, 0x34e32000, 0x00081040, 0x3042c000, + 0x00623825, 0x3c020800, 0x00511021, 0x8c421be0, 0x3c030800, 0x00711821, + 0x8c631be4, 0x00021500, 0x00031c00, 0x00431025, 0xacc20014, 0x8e63fff4, + 0x96020008, 0x00432023, 0x3242ffff, 0x3083ffff, 0x00431021, 0x02c2102a, + 0x10400003, 0x00802821, 0x97a9001e, 0x01322823, 0x8e620000, 0x30a4ffff, + 0x00441021, 0xae620000, 0xa4c5000e, 0x8e020000, 0xacc20000, 0x8e020004, + 0x8e63fff4, 0x00431021, 0xacc20004, 0x8e63fff4, 0x96020008, 0x00641821, + 0x0062102a, 0x14400006, 0x02459021, 0x8e62fff0, 0xae60fff4, 0x24420001, + 0x0a000579, 0xae62fff0, 0xae63fff4, 0xacc00008, 0x3242ffff, 0x10560003, + 0x31020004, 0x10400006, 0x24020305, 0x31020080, 0x54400001, 0x34e70010, + 0x34e70020, 0x24020905, 0xa4c2000c, 0x8ee30000, 0x8ee20004, 0x14620007, + 0x3c02b49a, 0x8ee20860, 0x54400001, 0x34e70400, 0x3c024b65, 0x0a000590, + 0x34427654, 0x344289ab, 0xacc2001c, 0x30e2ffff, 0xacc20010, 0x0e0005aa, + 0x00c02021, 0x3242ffff, 0x0056102b, 0x1440ff96, 0x00000000, 0x8e620000, + 0x8e63fffc, 0x0043102a, 0x1440ff3e, 0x00000000, 0x8fbf0044, 0x8fbe0040, + 0x8fb7003c, 0x8fb60038, 0x8fb50034, 0x8fb40030, 0x8fb3002c, 0x8fb20028, + 0x8fb10024, 0x8fb00020, 0x03e00008, 0x27bd0048, 0x27bdffe8, 0xafbf0014, + 0xafb00010, 0x8f624450, 0x8f634410, 0x0a0005b9, 0x00808021, 0x8f626820, + 0x30422000, 0x10400003, 0x00000000, 0x0e0001e3, 0x00002021, 0x8f624450, + 0x8f634410, 0x3042ffff, 0x0043102b, 0x1440fff5, 0x00000000, 0x8f630c14, + 0x3063000f, 0x2c620002, 0x1440000b, 0x00000000, 0x8f630c14, 0x3c020800, + 0x8c421b50, 0x3063000f, 0x24420001, 0x3c010800, 0xac221b50, 0x2c620002, + 0x1040fff7, 0x00000000, 0xaf705c18, 0x8f625c10, 0x30420002, 0x10400009, + 0x00000000, 0x8f626820, 0x30422000, 0x1040fff8, 0x00000000, 0x0e0001e3, + 0x00002021, 0x0a0005cc, 0x00000000, 0x8fbf0014, 0x8fb00010, 0x03e00008, + 0x27bd0018, 0x00000000, 0x00000000, 0x00000000, 0x27bdffe8, 0x3c1bc000, + 0xafbf0014, 0xafb00010, 0xaf60680c, 0x8f626804, 0x34420082, 0xaf626804, + 0x8f634000, 0x24020b50, 0x3c010800, 0xac221b64, 0x24020b78, 0x3c010800, + 0xac221b74, 0x34630002, 0xaf634000, 0x0e00060d, 0x00808021, 0x3c010800, + 0xa0221b78, 0x304200ff, 0x24030002, 0x14430005, 0x00000000, 0x3c020800, + 0x8c421b64, 0x0a000600, 0xac5000c0, 0x3c020800, 0x8c421b64, 0xac5000bc, + 0x8f624434, 0x8f634438, 0x8f644410, 0x3c010800, 0xac221b6c, 0x3c010800, + 0xac231b7c, 0x3c010800, 0xac241b68, 0x8fbf0014, 0x8fb00010, 0x03e00008, + 0x27bd0018, 0x3c040800, 0x8c870000, 0x3c03aa55, 0x3463aa55, 0x3c06c003, + 0xac830000, 0x8cc20000, 0x14430007, 0x24050002, 0x3c0355aa, 0x346355aa, + 0xac830000, 0x8cc20000, 0x50430001, 0x24050001, 0x3c020800, 0xac470000, + 0x03e00008, 0x00a01021, 0x27bdfff8, 0x18800009, 0x00002821, 0x8f63680c, + 0x8f62680c, 0x1043fffe, 0x00000000, 0x24a50001, 0x00a4102a, 0x1440fff9, + 0x00000000, 0x03e00008, 0x27bd0008, 0x8f634450, 0x3c020800, 0x8c421b6c, + 0x00031c02, 0x0043102b, 0x14400008, 0x3c038000, 0x3c040800, 0x8c841b7c, + 0x8f624450, 0x00021c02, 0x0083102b, 0x1040fffc, 0x3c038000, 0xaf634444, + 0x8f624444, 0x00431024, 0x1440fffd, 0x00000000, 0x8f624448, 0x03e00008, + 0x3042ffff, 0x3082ffff, 0x2442e000, 0x2c422001, 0x14400003, 0x3c024000, + 0x0a000650, 0x2402ffff, 0x00822025, 0xaf645c38, 0x8f625c30, 0x30420002, + 0x1440fffc, 0x00001021, 0x03e00008, 0x00000000, 0x8f624450, 0x3c030800, + 0x8c631b68, 0x0a000659, 0x3042ffff, 0x8f624450, 0x3042ffff, 0x0043102b, + 0x1440fffc, 0x00000000, 0x03e00008, 0x00000000, 0x27bdffe0, 0x00802821, + 0x3c040800, 0x24841b10, 0x00003021, 0x00003821, 0xafbf0018, 0xafa00010, + 0x0e000684, 0xafa00014, 0x0a000668, 0x00000000, 0x8fbf0018, 0x03e00008, + 0x27bd0020, 0x00000000, 0x00000000, 0x00000000, 0x3c020800, 0x34423000, + 0x3c030800, 0x34633000, 0x3c040800, 0x348437ff, 0x3c010800, 0xac221b84, + 0x24020040, 0x3c010800, 0xac221b88, 0x3c010800, 0xac201b80, 0xac600000, + 0x24630004, 0x0083102b, 0x5040fffd, 0xac600000, 0x03e00008, 0x00000000, + 0x00804821, 0x8faa0010, 0x3c020800, 0x8c421b80, 0x3c040800, 0x8c841b88, + 0x8fab0014, 0x24430001, 0x0044102b, 0x3c010800, 0xac231b80, 0x14400003, + 0x00004021, 0x3c010800, 0xac201b80, 0x3c020800, 0x8c421b80, 0x3c030800, + 0x8c631b84, 0x91240000, 0x00021140, 0x00431021, 0x00481021, 0x25080001, + 0xa0440000, 0x29020008, 0x1440fff4, 0x25290001, 0x3c020800, 0x8c421b80, + 0x3c030800, 0x8c631b84, 0x8f64680c, 0x00021140, 0x00431021, 0xac440008, + 0xac45000c, 0xac460010, 0xac470014, 0xac4a0018, 0x03e00008, 0xac4b001c, + 0x00000000, 0x00000000, }; u32 tg3TsoFwRodata[] = { - 0x4d61696e, 0x43707542, 0x00000000, 0x00000000, 0x74637073, 0x6567496e, - 0x00000000, 0x53774576, 0x656e7430, 0x00000000, 0x00000000, 0x00000000, - 0x00000000 + 0x4d61696e, 0x43707542, 0x00000000, 0x4d61696e, 0x43707541, + 0x00000000, 0x00000000, 0x00000000, 0x73746b6f, 0x66666c64, + 0x496e0000, 0x73746b6f, 0x66662a2a, 0x00000000, 0x53774576, + 0x656e7430, 0x00000000, 0x00000000, 0x00000000, 0x00000000, + 0x66617461, 0x6c457272, 0x00000000, 0x00000000, 0x00000000 }; #if 0 /* All zeros, don't eat up space with it. */ @@ -3785,63 +4206,274 @@ }; #endif +/* 5705 needs a special version of the TSO firmware. */ +#define TG3_TSO5_FW_RELEASE_MAJOR 0x1 +#define TG3_TSO5_FW_RELASE_MINOR 0x1 +#define TG3_TSO5_FW_RELEASE_FIX 0x0 +#define TG3_TSO5_FW_START_ADDR 0x00010000 +#define TG3_TSO5_FW_TEXT_ADDR 0x00010000 +#define TG3_TSO5_FW_TEXT_LEN 0xeb0 +#define TG3_TSO5_FW_RODATA_ADDR 0x00010eb0 +#define TG3_TSO5_FW_RODATA_LEN 0x50 +#define TG3_TSO5_FW_DATA_ADDR 0x00010f20 +#define TG3_TSO5_FW_DATA_LEN 0x20 +#define TG3_TSO5_FW_SBSS_ADDR 0x00010f40 +#define TG3_TSO5_FW_SBSS_LEN 0x28 +#define TG3_TSO5_FW_BSS_ADDR 0x00010f70 +#define TG3_TSO5_FW_BSS_LEN 0x88 + +static u32 tg3Tso5FwText[] = { + 0x0c004003, 0x00000000, 0x00010f30, 0x00000000, 0x10000003, 0x00000000, + 0x0000000d, 0x0000000d, 0x3c1d0001, 0x37bde000, 0x03a0f021, 0x3c100001, + 0x26100000, 0x0c004010, 0x00000000, 0x0000000d, 0x27bdffe0, 0x3c04fefe, + 0xafbf0018, 0x0c0042f0, 0x34840002, 0x0c00436c, 0x00000000, 0x3c030001, + 0x90630f54, 0x24020002, 0x3c040001, 0x24840ebc, 0x14620003, 0x24050001, + 0x3c040001, 0x24840eb0, 0x24060001, 0x00003821, 0xafa00010, 0x0c004380, + 0xafa00014, 0x0c00402c, 0x00000000, 0x8fbf0018, 0x03e00008, 0x27bd0020, + 0x00000000, 0x00000000, 0x27bdffe0, 0xafbf001c, 0xafb20018, 0xafb10014, + 0x0c0042d3, 0xafb00010, 0x3c128000, 0x24110001, 0x8f706810, 0x32020400, + 0x10400007, 0x00000000, 0x8f641008, 0x00921024, 0x14400003, 0x00000000, + 0x0c004064, 0x00000000, 0x3c020001, 0x90420f76, 0x10510003, 0x32020200, + 0x1040fff1, 0x00000000, 0x0c0041b4, 0x00000000, 0x08004034, 0x00000000, + 0x8fbf001c, 0x8fb20018, 0x8fb10014, 0x8fb00010, 0x03e00008, 0x27bd0020, + 0x27bdffe0, 0x3c040001, 0x24840ed0, 0x00002821, 0x00003021, 0x00003821, + 0xafbf0018, 0xafa00010, 0x0c004380, 0xafa00014, 0x0000d021, 0x24020130, + 0xaf625000, 0x3c010001, 0xa4200f70, 0x3c010001, 0xa0200f77, 0x8fbf0018, + 0x03e00008, 0x27bd0020, 0x00000000, 0x00000000, 0x3c030001, 0x24630f80, + 0x90620000, 0x27bdfff0, 0x14400003, 0x0080c021, 0x08004073, 0x00004821, + 0x3c022000, 0x03021024, 0x10400003, 0x24090002, 0x08004073, 0xa0600000, + 0x24090001, 0x00181040, 0x30431f80, 0x346f8008, 0x1520004b, 0x25eb0028, + 0x3c040001, 0x00832021, 0x8c848010, 0x3c050001, 0x24a50f9a, 0x00041402, + 0xa0a20000, 0x3c010001, 0xa0240f9b, 0x3c020001, 0x00431021, 0x94428014, + 0x3c010001, 0xa0220f9c, 0x3c0c0001, 0x01836021, 0x8d8c8018, 0x304200ff, + 0x24420008, 0x000220c3, 0x24020001, 0x3c010001, 0xa0220f80, 0x0124102b, + 0x1040000c, 0x00003821, 0x24a6000e, 0x01602821, 0x8ca20000, 0x8ca30004, + 0x24a50008, 0x24e70001, 0xacc20000, 0xacc30004, 0x00e4102b, 0x1440fff8, + 0x24c60008, 0x00003821, 0x3c080001, 0x25080f9b, 0x91060000, 0x3c020001, + 0x90420f9c, 0x2503000d, 0x00c32821, 0x00461023, 0x00021fc2, 0x00431021, + 0x00021043, 0x1840000c, 0x00002021, 0x91020001, 0x00461023, 0x00021fc2, + 0x00431021, 0x00021843, 0x94a20000, 0x24e70001, 0x00822021, 0x00e3102a, + 0x1440fffb, 0x24a50002, 0x00041c02, 0x3082ffff, 0x00622021, 0x00041402, + 0x00822021, 0x3c02ffff, 0x01821024, 0x3083ffff, 0x00431025, 0x3c010001, + 0x080040fa, 0xac220fa0, 0x3c050001, 0x24a50f9c, 0x90a20000, 0x3c0c0001, + 0x01836021, 0x8d8c8018, 0x000220c2, 0x1080000e, 0x00003821, 0x01603021, + 0x24a5000c, 0x8ca20000, 0x8ca30004, 0x24a50008, 0x24e70001, 0xacc20000, + 0xacc30004, 0x00e4102b, 0x1440fff8, 0x24c60008, 0x3c050001, 0x24a50f9c, + 0x90a20000, 0x30430007, 0x24020004, 0x10620011, 0x28620005, 0x10400005, + 0x24020002, 0x10620008, 0x000710c0, 0x080040fa, 0x00000000, 0x24020006, + 0x1062000e, 0x000710c0, 0x080040fa, 0x00000000, 0x00a21821, 0x9463000c, + 0x004b1021, 0x080040fa, 0xa4430000, 0x000710c0, 0x00a21821, 0x8c63000c, + 0x004b1021, 0x080040fa, 0xac430000, 0x00a21821, 0x8c63000c, 0x004b2021, + 0x00a21021, 0xac830000, 0x94420010, 0xa4820004, 0x95e70006, 0x3c020001, + 0x90420f9c, 0x3c030001, 0x90630f9a, 0x00e2c823, 0x3c020001, 0x90420f9b, + 0x24630028, 0x01e34021, 0x24420028, 0x15200012, 0x01e23021, 0x94c2000c, + 0x3c010001, 0xa4220f98, 0x94c20004, 0x94c30006, 0x3c010001, 0xa4200f96, + 0x3c010001, 0xa4200f92, 0x00021400, 0x00431025, 0x3c010001, 0xac220f8c, + 0x95020004, 0x3c010001, 0x08004124, 0xa4220f90, 0x3c020001, 0x94420f90, + 0x3c030001, 0x94630f92, 0x00431021, 0xa5020004, 0x3c020001, 0x94420f8c, + 0xa4c20004, 0x3c020001, 0x8c420f8c, 0xa4c20006, 0x3c040001, 0x94840f92, + 0x3c020001, 0x94420f90, 0x3c0a0001, 0x954a0f96, 0x00441821, 0x3063ffff, + 0x0062182a, 0x24020002, 0x1122000b, 0x00832023, 0x3c030001, 0x94630f98, + 0x30620009, 0x10400006, 0x3062fff6, 0xa4c2000c, 0x3c020001, 0x94420f98, + 0x30420009, 0x01425023, 0x24020001, 0x1122001b, 0x29220002, 0x50400005, + 0x24020002, 0x11200007, 0x31a2ffff, 0x08004197, 0x00000000, 0x1122001d, + 0x24020016, 0x08004197, 0x31a2ffff, 0x3c0e0001, 0x95ce0fa0, 0x10800005, + 0x01806821, 0x01c42021, 0x00041c02, 0x3082ffff, 0x00627021, 0x000e1027, + 0xa502000a, 0x3c030001, 0x90630f9b, 0x31a2ffff, 0x00e21021, 0x0800418d, + 0x00432023, 0x3c020001, 0x94420fa0, 0x00442021, 0x00041c02, 0x3082ffff, + 0x00622021, 0x00807021, 0x00041027, 0x08004185, 0xa502000a, 0x3c050001, + 0x24a50f9a, 0x90a30000, 0x14620002, 0x24e2fff2, 0xa5e20034, 0x90a20000, + 0x00e21023, 0xa5020002, 0x3c030001, 0x94630fa0, 0x3c020001, 0x94420f7a, + 0x30e5ffff, 0x00641821, 0x00451023, 0x00622023, 0x00041c02, 0x3082ffff, + 0x00622021, 0x00041027, 0xa502000a, 0x3c030001, 0x90630f9c, 0x24620001, + 0x14a20005, 0x00807021, 0x01631021, 0x90420000, 0x08004185, 0x00026200, + 0x24620002, 0x14a20003, 0x306200fe, 0x004b1021, 0x944c0000, 0x3c020001, + 0x94420fa2, 0x3183ffff, 0x3c040001, 0x90840f9b, 0x00431021, 0x00e21021, + 0x00442023, 0x008a2021, 0x00041c02, 0x3082ffff, 0x00622021, 0x00041402, + 0x00822021, 0x00806821, 0x00041027, 0xa4c20010, 0x31a2ffff, 0x000e1c00, + 0x00431025, 0x3c040001, 0x24840f92, 0xade20010, 0x94820000, 0x3c050001, + 0x94a50f96, 0x3c030001, 0x8c630f8c, 0x24420001, 0x00b92821, 0xa4820000, + 0x3322ffff, 0x00622021, 0x0083182b, 0x3c010001, 0xa4250f96, 0x10600003, + 0x24a2ffff, 0x3c010001, 0xa4220f96, 0x3c024000, 0x03021025, 0x3c010001, + 0xac240f8c, 0xaf621008, 0x03e00008, 0x27bd0010, 0x3c030001, 0x90630f76, + 0x27bdffe8, 0x24020001, 0xafbf0014, 0x10620026, 0xafb00010, 0x8f620cf4, + 0x2442ffff, 0x3042007f, 0x00021100, 0x8c434000, 0x3c010001, 0xac230f84, + 0x8c434008, 0x24444000, 0x8c5c4004, 0x30620040, 0x14400002, 0x24020088, + 0x24020008, 0x3c010001, 0xa4220f88, 0x30620004, 0x10400005, 0x24020001, + 0x3c010001, 0xa0220f77, 0x080041d5, 0x00031402, 0x3c010001, 0xa0200f77, + 0x00031402, 0x3c010001, 0xa4220f74, 0x9483000c, 0x24020001, 0x3c010001, + 0xa4200f70, 0x3c010001, 0xa0220f76, 0x3c010001, 0xa4230f82, 0x24020001, + 0x1342001e, 0x00000000, 0x13400005, 0x24020003, 0x13420067, 0x00000000, + 0x080042cf, 0x00000000, 0x3c020001, 0x94420f82, 0x241a0001, 0x3c010001, + 0xa4200f7e, 0x3c010001, 0xa4200f72, 0x304407ff, 0x00021bc2, 0x00031823, + 0x3063003e, 0x34630036, 0x00021242, 0x3042003c, 0x00621821, 0x3c010001, + 0xa4240f78, 0x00832021, 0x24630030, 0x3c010001, 0xa4240f7a, 0x3c010001, + 0xa4230f7c, 0x3c060001, 0x24c60f72, 0x94c50000, 0x94c30002, 0x3c040001, + 0x94840f7a, 0x00651021, 0x0044102a, 0x10400013, 0x3c108000, 0x00a31021, + 0xa4c20000, 0x3c02a000, 0xaf620cf4, 0x3c010001, 0xa0200f76, 0x8f641008, + 0x00901024, 0x14400003, 0x00000000, 0x0c004064, 0x00000000, 0x8f620cf4, + 0x00501024, 0x104000b7, 0x00000000, 0x0800420f, 0x00000000, 0x3c030001, + 0x94630f70, 0x00851023, 0xa4c40000, 0x00621821, 0x3042ffff, 0x3c010001, + 0xa4230f70, 0xaf620ce8, 0x3c020001, 0x94420f88, 0x34420024, 0xaf620cec, + 0x94c30002, 0x3c020001, 0x94420f70, 0x14620012, 0x3c028000, 0x3c108000, + 0x3c02a000, 0xaf620cf4, 0x3c010001, 0xa0200f76, 0x8f641008, 0x00901024, + 0x14400003, 0x00000000, 0x0c004064, 0x00000000, 0x8f620cf4, 0x00501024, + 0x1440fff7, 0x00000000, 0x080042cf, 0x241a0003, 0xaf620cf4, 0x3c108000, + 0x8f641008, 0x00901024, 0x14400003, 0x00000000, 0x0c004064, 0x00000000, + 0x8f620cf4, 0x00501024, 0x1440fff7, 0x00000000, 0x080042cf, 0x241a0003, + 0x3c070001, 0x24e70f70, 0x94e20000, 0x03821021, 0xaf620ce0, 0x3c020001, + 0x8c420f84, 0xaf620ce4, 0x3c050001, 0x94a50f74, 0x94e30000, 0x3c040001, + 0x94840f78, 0x3c020001, 0x94420f7e, 0x00a32823, 0x00822023, 0x30a6ffff, + 0x3083ffff, 0x00c3102b, 0x14400043, 0x00000000, 0x3c020001, 0x94420f7c, + 0x00021400, 0x00621025, 0xaf620ce8, 0x94e20000, 0x3c030001, 0x94630f74, + 0x00441021, 0xa4e20000, 0x3042ffff, 0x14430021, 0x3c020008, 0x3c020001, + 0x90420f77, 0x10400006, 0x3c03000c, 0x3c020001, 0x94420f88, 0x34630624, + 0x0800427c, 0x0000d021, 0x3c020001, 0x94420f88, 0x3c030008, 0x34630624, + 0x00431025, 0xaf620cec, 0x3c108000, 0x3c02a000, 0xaf620cf4, 0x3c010001, + 0xa0200f76, 0x8f641008, 0x00901024, 0x14400003, 0x00000000, 0x0c004064, + 0x00000000, 0x8f620cf4, 0x00501024, 0x10400015, 0x00000000, 0x08004283, + 0x00000000, 0x3c030001, 0x94630f88, 0x34420624, 0x3c108000, 0x00621825, + 0x3c028000, 0xaf630cec, 0xaf620cf4, 0x8f641008, 0x00901024, 0x14400003, + 0x00000000, 0x0c004064, 0x00000000, 0x8f620cf4, 0x00501024, 0x1440fff7, + 0x00000000, 0x3c010001, 0x080042cf, 0xa4200f7e, 0x3c020001, 0x94420f7c, + 0x00021400, 0x00c21025, 0xaf620ce8, 0x3c020001, 0x90420f77, 0x10400009, + 0x3c03000c, 0x3c020001, 0x94420f88, 0x34630624, 0x0000d021, 0x00431025, + 0xaf620cec, 0x080042c1, 0x3c108000, 0x3c020001, 0x94420f88, 0x3c030008, + 0x34630604, 0x00431025, 0xaf620cec, 0x3c020001, 0x94420f7e, 0x00451021, + 0x3c010001, 0xa4220f7e, 0x3c108000, 0x3c02a000, 0xaf620cf4, 0x3c010001, + 0xa0200f76, 0x8f641008, 0x00901024, 0x14400003, 0x00000000, 0x0c004064, + 0x00000000, 0x8f620cf4, 0x00501024, 0x1440fff7, 0x00000000, 0x8fbf0014, + 0x8fb00010, 0x03e00008, 0x27bd0018, 0x27bdffe0, 0x3c040001, 0x24840ee0, + 0x00002821, 0x00003021, 0x00003821, 0xafbf0018, 0xafa00010, 0x0c004380, + 0xafa00014, 0x0000d021, 0x24020130, 0xaf625000, 0x3c010001, 0xa4200f70, + 0x3c010001, 0xa0200f77, 0x8f636804, 0x3c020001, 0x3442e000, 0x00621824, + 0x3c020001, 0x14620003, 0x00000000, 0x080042eb, 0x00000000, 0x8fbf0018, + 0x03e00008, 0x27bd0020, 0x27bdffe8, 0x3c1bc000, 0xafbf0014, 0xafb00010, + 0xaf60680c, 0x8f626804, 0x34420082, 0xaf626804, 0x8f634000, 0x24020b50, + 0x3c010001, 0xac220f40, 0x24020b78, 0x3c010001, 0xac220f50, 0x34630002, + 0xaf634000, 0x0c00431d, 0x00808021, 0x3c010001, 0xa0220f54, 0x304200ff, + 0x24030002, 0x14430005, 0x00000000, 0x3c020001, 0x8c420f40, 0x08004310, + 0xac5000c0, 0x3c020001, 0x8c420f40, 0xac5000bc, 0x8f624434, 0x8f634438, + 0x8f644410, 0x3c010001, 0xac220f48, 0x3c010001, 0xac230f58, 0x3c010001, + 0xac240f44, 0x8fbf0014, 0x8fb00010, 0x03e00008, 0x27bd0018, 0x03e00008, + 0x24020001, 0x27bdfff8, 0x18800009, 0x00002821, 0x8f63680c, 0x8f62680c, + 0x1043fffe, 0x00000000, 0x24a50001, 0x00a4102a, 0x1440fff9, 0x00000000, + 0x03e00008, 0x27bd0008, 0x8f634450, 0x3c020001, 0x8c420f48, 0x00031c02, + 0x0043102b, 0x14400008, 0x3c038000, 0x3c040001, 0x8c840f58, 0x8f624450, + 0x00021c02, 0x0083102b, 0x1040fffc, 0x3c038000, 0xaf634444, 0x8f624444, + 0x00431024, 0x1440fffd, 0x00000000, 0x8f624448, 0x03e00008, 0x3042ffff, + 0x3082ffff, 0x2442e000, 0x2c422001, 0x14400003, 0x3c024000, 0x0800434f, + 0x2402ffff, 0x00822025, 0xaf645c38, 0x8f625c30, 0x30420002, 0x1440fffc, + 0x00001021, 0x03e00008, 0x00000000, 0x8f624450, 0x3c030001, 0x8c630f44, + 0x08004358, 0x3042ffff, 0x8f624450, 0x3042ffff, 0x0043102b, 0x1440fffc, + 0x00000000, 0x03e00008, 0x00000000, 0x27bdffe0, 0x00802821, 0x3c040001, + 0x24840ef0, 0x00003021, 0x00003821, 0xafbf0018, 0xafa00010, 0x0c004380, + 0xafa00014, 0x08004367, 0x00000000, 0x8fbf0018, 0x03e00008, 0x27bd0020, + 0x3c020001, 0x3442d600, 0x3c030001, 0x3463d600, 0x3c040001, 0x3484ddff, + 0x3c010001, 0xac220f60, 0x24020040, 0x3c010001, 0xac220f64, 0x3c010001, + 0xac200f5c, 0xac600000, 0x24630004, 0x0083102b, 0x5040fffd, 0xac600000, + 0x03e00008, 0x00000000, 0x00804821, 0x8faa0010, 0x3c020001, 0x8c420f5c, + 0x3c040001, 0x8c840f64, 0x8fab0014, 0x24430001, 0x0044102b, 0x3c010001, + 0xac230f5c, 0x14400003, 0x00004021, 0x3c010001, 0xac200f5c, 0x3c020001, + 0x8c420f5c, 0x3c030001, 0x8c630f60, 0x91240000, 0x00021140, 0x00431021, + 0x00481021, 0x25080001, 0xa0440000, 0x29020008, 0x1440fff4, 0x25290001, + 0x3c020001, 0x8c420f5c, 0x3c030001, 0x8c630f60, 0x8f64680c, 0x00021140, + 0x00431021, 0xac440008, 0xac45000c, 0xac460010, 0xac470014, 0xac4a0018, + 0x03e00008, 0xac4b001c, 0x00000000, 0x00000000, +}; + +u32 tg3Tso5FwRodata[] = { + 0x4d61696e, 0x43707542, 0x00000000, 0x4d61696e, 0x43707541, 0x00000000, + 0x00000000, 0x00000000, 0x73746b6f, 0x66666c64, 0x00000000, 0x00000000, + 0x73746b6f, 0x66666c64, 0x00000000, 0x00000000, 0x66617461, 0x6c457272, + 0x00000000, 0x00000000, 0x00000000 +}; + +u32 tg3Tso5FwData[] = { + 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x73746b6f, + 0x66666c64, 0x5f76312e, 0x312e3000, 0x00000000 +}; + /* tp->lock is held. */ static int tg3_load_tso_firmware(struct tg3 *tp) { struct fw_info info; + unsigned long cpu_base, cpu_scratch_base, cpu_scratch_size; int err, i; - info.text_base = TG3_TSO_FW_TEXT_ADDR; - info.text_len = TG3_TSO_FW_TEXT_LEN; - info.text_data = &tg3TsoFwText[0]; - info.rodata_base = TG3_TSO_FW_RODATA_ADDR; - info.rodata_len = TG3_TSO_FW_RODATA_LEN; - info.rodata_data = &tg3TsoFwRodata[0]; - info.data_base = TG3_TSO_FW_DATA_ADDR; - info.data_len = TG3_TSO_FW_DATA_LEN; - info.data_data = NULL; + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) { + info.text_base = TG3_TSO5_FW_TEXT_ADDR; + info.text_len = TG3_TSO5_FW_TEXT_LEN; + info.text_data = &tg3Tso5FwText[0]; + info.rodata_base = TG3_TSO5_FW_RODATA_ADDR; + info.rodata_len = TG3_TSO5_FW_RODATA_LEN; + info.rodata_data = &tg3Tso5FwRodata[0]; + info.data_base = TG3_TSO5_FW_DATA_ADDR; + info.data_len = TG3_TSO5_FW_DATA_LEN; + info.data_data = &tg3Tso5FwData[0]; + cpu_base = RX_CPU_BASE; + cpu_scratch_base = NIC_SRAM_MBUF_POOL_BASE5705; + cpu_scratch_size = (info.text_len + + info.rodata_len + + info.data_len + + TG3_TSO5_FW_SBSS_LEN + + TG3_TSO5_FW_BSS_LEN); + } else { + info.text_base = TG3_TSO_FW_TEXT_ADDR; + info.text_len = TG3_TSO_FW_TEXT_LEN; + info.text_data = &tg3TsoFwText[0]; + info.rodata_base = TG3_TSO_FW_RODATA_ADDR; + info.rodata_len = TG3_TSO_FW_RODATA_LEN; + info.rodata_data = &tg3TsoFwRodata[0]; + info.data_base = TG3_TSO_FW_DATA_ADDR; + info.data_len = TG3_TSO_FW_DATA_LEN; + info.data_data = NULL; + cpu_base = TX_CPU_BASE; + cpu_scratch_base = TX_CPU_SCRATCH_BASE; + cpu_scratch_size = TX_CPU_SCRATCH_SIZE; + } - err = tg3_load_firmware_cpu(tp, TX_CPU_BASE, - TX_CPU_SCRATCH_BASE, TX_CPU_SCRATCH_SIZE, + err = tg3_load_firmware_cpu(tp, cpu_base, + cpu_scratch_base, cpu_scratch_size, &info); if (err) return err; - /* Now startup only the TX cpu. */ - tw32(TX_CPU_BASE + CPU_STATE, 0xffffffff); - tw32(TX_CPU_BASE + CPU_PC, TG3_TSO_FW_TEXT_ADDR); + /* Now startup the cpu. */ + tw32(cpu_base + CPU_STATE, 0xffffffff); + tw32(cpu_base + CPU_PC, info.text_base); /* Flush posted writes. */ - tr32(TX_CPU_BASE + CPU_PC); + tr32(cpu_base + CPU_PC); for (i = 0; i < 5; i++) { - if (tr32(TX_CPU_BASE + CPU_PC) == TG3_TSO_FW_TEXT_ADDR) + if (tr32(cpu_base + CPU_PC) == info.text_base) break; - tw32(TX_CPU_BASE + CPU_STATE, 0xffffffff); - tw32(TX_CPU_BASE + CPU_MODE, CPU_MODE_HALT); - tw32(TX_CPU_BASE + CPU_PC, TG3_TSO_FW_TEXT_ADDR); + tw32(cpu_base + CPU_STATE, 0xffffffff); + tw32(cpu_base + CPU_MODE, CPU_MODE_HALT); + tw32(cpu_base + CPU_PC, info.text_base); /* Flush posted writes. */ - tr32(TX_CPU_BASE + CPU_PC); + tr32(cpu_base + CPU_PC); udelay(1000); } if (i >= 5) { printk(KERN_ERR PFX "tg3_load_tso_firmware fails for %s " - "to set TX CPU PC, is %08x should be %08x\n", - tp->dev->name, tr32(TX_CPU_BASE + CPU_PC), - TG3_TSO_FW_TEXT_ADDR); + "to set CPU PC, is %08x should be %08x\n", + tp->dev->name, tr32(cpu_base + CPU_PC), + info.text_base); return -ENODEV; } - tw32(TX_CPU_BASE + CPU_STATE, 0xffffffff); - tw32(TX_CPU_BASE + CPU_MODE, 0x00000000); + tw32(cpu_base + CPU_STATE, 0xffffffff); + tw32(cpu_base + CPU_MODE, 0x00000000); /* Flush posted writes. */ - tr32(TX_CPU_BASE + CPU_MODE); + tr32(cpu_base + CPU_MODE); return 0; } -#endif /* TG3_DO_TSO != 0 */ +#endif /* TG3_TSO_SUPPORT != 0 */ /* tp->lock is held. */ static void __tg3_set_mac_addr(struct tg3 *tp) @@ -3860,6 +4492,15 @@ tw32(MAC_ADDR_0_LOW + (i * 8), addr_low); } + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5700 && + GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5701 && + GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705) { + for (i = 0; i < 12; i++) { + tw32(MAC_EXTADDR_0_HIGH + (i * 8), addr_high); + tw32(MAC_EXTADDR_0_LOW + (i * 8), addr_low); + } + } + addr_high = (tp->dev->dev_addr[0] + tp->dev->dev_addr[1] + tp->dev->dev_addr[2] + @@ -3893,23 +4534,19 @@ u32 nic_addr) { tg3_write_mem(tp, - (bdinfo_addr + - TG3_BDINFO_HOST_ADDR + - TG3_64BIT_REG_HIGH), + (bdinfo_addr + TG3_BDINFO_HOST_ADDR + TG3_64BIT_REG_HIGH), ((u64) mapping >> 32)); tg3_write_mem(tp, - (bdinfo_addr + - TG3_BDINFO_HOST_ADDR + - TG3_64BIT_REG_LOW), + (bdinfo_addr + TG3_BDINFO_HOST_ADDR + TG3_64BIT_REG_LOW), ((u64) mapping & 0xffffffff)); tg3_write_mem(tp, - (bdinfo_addr + - TG3_BDINFO_MAXLEN_FLAGS), + (bdinfo_addr + TG3_BDINFO_MAXLEN_FLAGS), maxlen_flags); - tg3_write_mem(tp, - (bdinfo_addr + - TG3_BDINFO_NIC_ADDR), - nic_addr); + + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705) + tg3_write_mem(tp, + (bdinfo_addr + TG3_BDINFO_NIC_ADDR), + nic_addr); } static void __tg3_set_rx_mode(struct net_device *); @@ -3917,8 +4554,8 @@ /* tp->lock is held. */ static int tg3_reset_hw(struct tg3 *tp) { - u32 val; - int i, err; + u32 val, rdmac_mode; + int i, err, limit; tg3_disable_ints(tp); @@ -3970,9 +4607,8 @@ * B3 tigon3 silicon. This bit has no effect on any * other revision. */ - val = tr32(TG3PCI_CLOCK_CTRL); - val |= CLOCK_CTRL_DELAY_PCI_GRANT; - tw32(TG3PCI_CLOCK_CTRL, val); + tp->pci_clock_ctrl |= CLOCK_CTRL_DELAY_PCI_GRANT; + tw32(TG3PCI_CLOCK_CTRL, tp->pci_clock_ctrl); tr32(TG3PCI_CLOCK_CTRL); if (tp->pci_chip_rev_id == CHIPREV_ID_5704_A0 && @@ -3990,11 +4626,13 @@ tg3_init_rings(tp); /* Clear statistics/status block in chip, and status block in ram. */ - for (i = NIC_SRAM_STATS_BLK; - i < NIC_SRAM_STATUS_BLK + TG3_HW_STATUS_SIZE; - i += sizeof(u32)) { - tg3_write_mem(tp, i, 0); - udelay(40); + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705) { + for (i = NIC_SRAM_STATS_BLK; + i < NIC_SRAM_STATUS_BLK + TG3_HW_STATUS_SIZE; + i += sizeof(u32)) { + tg3_write_mem(tp, i, 0); + udelay(40); + } } memset(tp->hw_status, 0, TG3_HW_STATUS_SIZE); @@ -4025,13 +4663,31 @@ (65 << GRC_MISC_CFG_PRESCALAR_SHIFT)); /* Initialize MBUF/DESC pool. */ - tw32(BUFMGR_MB_POOL_ADDR, NIC_SRAM_MBUF_POOL_BASE); - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5704) - tw32(BUFMGR_MB_POOL_SIZE, NIC_SRAM_MBUF_POOL_SIZE64); - else - tw32(BUFMGR_MB_POOL_SIZE, NIC_SRAM_MBUF_POOL_SIZE96); - tw32(BUFMGR_DMA_DESC_POOL_ADDR, NIC_SRAM_DMA_DESC_POOL_BASE); - tw32(BUFMGR_DMA_DESC_POOL_SIZE, NIC_SRAM_DMA_DESC_POOL_SIZE); + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705) { + tw32(BUFMGR_MB_POOL_ADDR, NIC_SRAM_MBUF_POOL_BASE); + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5704) + tw32(BUFMGR_MB_POOL_SIZE, NIC_SRAM_MBUF_POOL_SIZE64); + else + tw32(BUFMGR_MB_POOL_SIZE, NIC_SRAM_MBUF_POOL_SIZE96); + tw32(BUFMGR_DMA_DESC_POOL_ADDR, NIC_SRAM_DMA_DESC_POOL_BASE); + tw32(BUFMGR_DMA_DESC_POOL_SIZE, NIC_SRAM_DMA_DESC_POOL_SIZE); + } +#if TG3_TSO_SUPPORT != 0 + else if (tp->tg3_flags2 & TG3_FLG2_TSO_CAPABLE) { + int fw_len; + + fw_len = (TG3_TSO5_FW_TEXT_LEN + + TG3_TSO5_FW_RODATA_LEN + + TG3_TSO5_FW_DATA_LEN + + TG3_TSO5_FW_SBSS_LEN + + TG3_TSO5_FW_BSS_LEN); + fw_len = (fw_len + (0x80 - 1)) & ~(0x80 - 1); + tw32(BUFMGR_MB_POOL_ADDR, + NIC_SRAM_MBUF_POOL_BASE5705 + fw_len); + tw32(BUFMGR_MB_POOL_SIZE, + NIC_SRAM_MBUF_POOL_SIZE5705 - fw_len - 0xa00); + } +#endif if (!(tp->tg3_flags & TG3_FLAG_JUMBO_ENABLE)) { tw32(BUFMGR_MB_RDMA_LOW_WATER, @@ -4078,6 +4734,9 @@ return -ENODEV; } + /* Setup replenish threshold. */ + tw32(RCVBDI_STD_THRESH, tp->rx_pending / 8); + /* Initialize TG3_BDINFO's at: * RCVDBDI_STD_BD: standard eth size rx ring * RCVDBDI_JUMBO_BD: jumbo frame rx ring @@ -4099,35 +4758,50 @@ ((u64) tp->rx_std_mapping >> 32)); tw32(RCVDBDI_STD_BD + TG3_BDINFO_HOST_ADDR + TG3_64BIT_REG_LOW, ((u64) tp->rx_std_mapping & 0xffffffff)); - tw32(RCVDBDI_STD_BD + TG3_BDINFO_MAXLEN_FLAGS, - RX_STD_MAX_SIZE << BDINFO_FLAGS_MAXLEN_SHIFT); tw32(RCVDBDI_STD_BD + TG3_BDINFO_NIC_ADDR, NIC_SRAM_RX_BUFFER_DESC); - tw32(RCVDBDI_MINI_BD + TG3_BDINFO_MAXLEN_FLAGS, - BDINFO_FLAGS_DISABLED); - - if (tp->tg3_flags & TG3_FLAG_JUMBO_ENABLE) { - tw32(RCVDBDI_JUMBO_BD + TG3_BDINFO_HOST_ADDR + TG3_64BIT_REG_HIGH, - ((u64) tp->rx_jumbo_mapping >> 32)); - tw32(RCVDBDI_JUMBO_BD + TG3_BDINFO_HOST_ADDR + TG3_64BIT_REG_LOW, - ((u64) tp->rx_jumbo_mapping & 0xffffffff)); - tw32(RCVDBDI_JUMBO_BD + TG3_BDINFO_MAXLEN_FLAGS, - RX_JUMBO_MAX_SIZE << BDINFO_FLAGS_MAXLEN_SHIFT); - tw32(RCVDBDI_JUMBO_BD + TG3_BDINFO_NIC_ADDR, - NIC_SRAM_RX_JUMBO_BUFFER_DESC); + /* Don't even try to program the JUMBO/MINI buffer descriptor + * configs on 5705. + */ + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) { + tw32(RCVDBDI_STD_BD + TG3_BDINFO_MAXLEN_FLAGS, + RX_STD_MAX_SIZE_5705 << BDINFO_FLAGS_MAXLEN_SHIFT); } else { - tw32(RCVDBDI_JUMBO_BD + TG3_BDINFO_MAXLEN_FLAGS, + tw32(RCVDBDI_STD_BD + TG3_BDINFO_MAXLEN_FLAGS, + RX_STD_MAX_SIZE << BDINFO_FLAGS_MAXLEN_SHIFT); + + tw32(RCVDBDI_MINI_BD + TG3_BDINFO_MAXLEN_FLAGS, BDINFO_FLAGS_DISABLED); - } - /* Setup replenish thresholds. */ - tw32(RCVBDI_STD_THRESH, tp->rx_pending / 8); - tw32(RCVBDI_JUMBO_THRESH, tp->rx_jumbo_pending / 8); + /* Setup replenish threshold. */ + tw32(RCVBDI_JUMBO_THRESH, tp->rx_jumbo_pending / 8); + + if (tp->tg3_flags & TG3_FLAG_JUMBO_ENABLE) { + tw32(RCVDBDI_JUMBO_BD + TG3_BDINFO_HOST_ADDR + TG3_64BIT_REG_HIGH, + ((u64) tp->rx_jumbo_mapping >> 32)); + tw32(RCVDBDI_JUMBO_BD + TG3_BDINFO_HOST_ADDR + TG3_64BIT_REG_LOW, + ((u64) tp->rx_jumbo_mapping & 0xffffffff)); + tw32(RCVDBDI_JUMBO_BD + TG3_BDINFO_MAXLEN_FLAGS, + RX_JUMBO_MAX_SIZE << BDINFO_FLAGS_MAXLEN_SHIFT); + tw32(RCVDBDI_JUMBO_BD + TG3_BDINFO_NIC_ADDR, + NIC_SRAM_RX_JUMBO_BUFFER_DESC); + } else { + tw32(RCVDBDI_JUMBO_BD + TG3_BDINFO_MAXLEN_FLAGS, + BDINFO_FLAGS_DISABLED); + } - /* Clear out send RCB ring in SRAM. */ - for (i = NIC_SRAM_SEND_RCB; i < NIC_SRAM_RCV_RET_RCB; i += TG3_BDINFO_SIZE) - tg3_write_mem(tp, i + TG3_BDINFO_MAXLEN_FLAGS, BDINFO_FLAGS_DISABLED); + } + + /* There is only one send ring on 5705, no need to explicitly + * disable the others. + */ + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705) { + /* Clear out send RCB ring in SRAM. */ + for (i = NIC_SRAM_SEND_RCB; i < NIC_SRAM_RCV_RET_RCB; i += TG3_BDINFO_SIZE) + tg3_write_mem(tp, i + TG3_BDINFO_MAXLEN_FLAGS, + BDINFO_FLAGS_DISABLED); + } tp->tx_prod = 0; tp->tx_cons = 0; @@ -4149,9 +4823,15 @@ NIC_SRAM_TX_BUFFER_DESC); } - for (i = NIC_SRAM_RCV_RET_RCB; i < NIC_SRAM_STATS_BLK; i += TG3_BDINFO_SIZE) { - tg3_write_mem(tp, i + TG3_BDINFO_MAXLEN_FLAGS, - BDINFO_FLAGS_DISABLED); + /* There is only one receive return ring on 5705, no need to explicitly + * disable the others. + */ + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705) { + for (i = NIC_SRAM_RCV_RET_RCB; i < NIC_SRAM_STATS_BLK; + i += TG3_BDINFO_SIZE) { + tg3_write_mem(tp, i + TG3_BDINFO_MAXLEN_FLAGS, + BDINFO_FLAGS_DISABLED); + } } tp->rx_rcb_ptr = 0; @@ -4161,7 +4841,7 @@ tg3_set_bdinfo(tp, NIC_SRAM_RCV_RET_RCB, tp->rx_rcb_mapping, - (TG3_RX_RCB_RING_SIZE << + (TG3_RX_RCB_RING_SIZE(tp) << BDINFO_FLAGS_MAXLEN_SHIFT), 0); @@ -4198,8 +4878,36 @@ tw32(MAC_RCV_RULE_CFG, RCV_RULE_CFG_DEFAULT_CLASS); tw32(RCVLPC_CONFIG, 0x0181); + /* Calculate RDMAC_MODE setting early, we need it to determine + * the RCVLPC_STATE_ENABLE mask. + */ + rdmac_mode = (RDMAC_MODE_ENABLE | RDMAC_MODE_TGTABORT_ENAB | + RDMAC_MODE_MSTABORT_ENAB | RDMAC_MODE_PARITYERR_ENAB | + RDMAC_MODE_ADDROFLOW_ENAB | RDMAC_MODE_FIFOOFLOW_ENAB | + RDMAC_MODE_FIFOURUN_ENAB | RDMAC_MODE_FIFOOREAD_ENAB | + RDMAC_MODE_LNGREAD_ENAB); + if (tp->tg3_flags & TG3_FLAG_SPLIT_MODE) + rdmac_mode |= RDMAC_MODE_SPLIT_ENABLE; + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) { + if (tp->pci_chip_rev_id != CHIPREV_ID_5705_A0) { + if (tp->tg3_flags2 & TG3_FLG2_TSO_CAPABLE) { + rdmac_mode |= RDMAC_MODE_FIFO_SIZE_128; + } else if (!(tr32(TG3PCI_PCISTATE) & PCISTATE_BUS_SPEED_HIGH) && + !(tp->tg3_flags2 & TG3_FLG2_IS_5788)) { + rdmac_mode |= RDMAC_MODE_FIFO_LONG_BURST; + } + } + } + /* Receive/send statistics. */ - tw32(RCVLPC_STATS_ENABLE, 0xffffff); + if ((rdmac_mode & RDMAC_MODE_FIFO_SIZE_128) && + (tp->tg3_flags2 & TG3_FLG2_TSO_CAPABLE)) { + val = tr32(RCVLPC_STATS_ENABLE); + val &= ~RCVLPC_STATSENAB_LNGBRST_RFIX; + tw32(RCVLPC_STATS_ENABLE, val); + } else { + tw32(RCVLPC_STATS_ENABLE, 0xffffff); + } tw32(RCVLPC_STATSCTRL, RCVLPC_STATSCTRL_ENABLE); tw32(SNDDATAI_STATSENAB, 0xffffff); tw32(SNDDATAI_STATSCTRL, @@ -4215,33 +4923,43 @@ } tw32(HOSTCC_RXCOL_TICKS, 0); - tw32(HOSTCC_RXMAX_FRAMES, 1); - tw32(HOSTCC_RXCOAL_TICK_INT, 0); - tw32(HOSTCC_RXCOAL_MAXF_INT, 1); tw32(HOSTCC_TXCOL_TICKS, LOW_TXCOL_TICKS); + tw32(HOSTCC_RXMAX_FRAMES, 1); tw32(HOSTCC_TXMAX_FRAMES, LOW_RXMAX_FRAMES); - tw32(HOSTCC_TXCOAL_TICK_INT, 0); + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705) + tw32(HOSTCC_RXCOAL_TICK_INT, 0); + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705) + tw32(HOSTCC_TXCOAL_TICK_INT, 0); + tw32(HOSTCC_RXCOAL_MAXF_INT, 1); tw32(HOSTCC_TXCOAL_MAXF_INT, 0); - tw32(HOSTCC_STAT_COAL_TICKS, - DEFAULT_STAT_COAL_TICKS); - /* Status/statistics block address. */ - tw32(HOSTCC_STATS_BLK_HOST_ADDR + TG3_64BIT_REG_HIGH, - ((u64) tp->stats_mapping >> 32)); - tw32(HOSTCC_STATS_BLK_HOST_ADDR + TG3_64BIT_REG_LOW, - ((u64) tp->stats_mapping & 0xffffffff)); + /* set status block DMA address */ tw32(HOSTCC_STATUS_BLK_HOST_ADDR + TG3_64BIT_REG_HIGH, ((u64) tp->status_mapping >> 32)); tw32(HOSTCC_STATUS_BLK_HOST_ADDR + TG3_64BIT_REG_LOW, ((u64) tp->status_mapping & 0xffffffff)); - tw32(HOSTCC_STATS_BLK_NIC_ADDR, NIC_SRAM_STATS_BLK); - tw32(HOSTCC_STATUS_BLK_NIC_ADDR, NIC_SRAM_STATUS_BLK); + + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705) { + /* Status/statistics block address. See tg3_timer, + * the tg3_periodic_fetch_stats call there, and + * tg3_get_stats to see how this works for 5705 chips. + */ + tw32(HOSTCC_STAT_COAL_TICKS, + DEFAULT_STAT_COAL_TICKS); + tw32(HOSTCC_STATS_BLK_HOST_ADDR + TG3_64BIT_REG_HIGH, + ((u64) tp->stats_mapping >> 32)); + tw32(HOSTCC_STATS_BLK_HOST_ADDR + TG3_64BIT_REG_LOW, + ((u64) tp->stats_mapping & 0xffffffff)); + tw32(HOSTCC_STATS_BLK_NIC_ADDR, NIC_SRAM_STATS_BLK); + tw32(HOSTCC_STATUS_BLK_NIC_ADDR, NIC_SRAM_STATUS_BLK); + } tw32(HOSTCC_MODE, HOSTCC_MODE_ENABLE | tp->coalesce_mode); tw32(RCVCC_MODE, RCVCC_MODE_ENABLE | RCVCC_MODE_ATTN_ENABLE); tw32(RCVLPC_MODE, RCVLPC_MODE_ENABLE); - tw32(RCVLSC_MODE, RCVLSC_MODE_ENABLE | RCVLSC_MODE_ATTN_ENABLE); + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705) + tw32(RCVLSC_MODE, RCVLSC_MODE_ENABLE | RCVLSC_MODE_ATTN_ENABLE); tp->mac_mode = MAC_MODE_TXSTAT_ENABLE | MAC_MODE_RXSTAT_ENABLE | MAC_MODE_TDE_ENABLE | MAC_MODE_RDE_ENABLE | MAC_MODE_FHDE_ENABLE; @@ -4260,42 +4978,47 @@ tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, 0); tr32(MAILBOX_INTERRUPT_0); - tw32(DMAC_MODE, DMAC_MODE_ENABLE); - tr32(DMAC_MODE); - udelay(40); + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705) { + tw32(DMAC_MODE, DMAC_MODE_ENABLE); + tr32(DMAC_MODE); + udelay(40); + } - tw32(WDMAC_MODE, (WDMAC_MODE_ENABLE | WDMAC_MODE_TGTABORT_ENAB | - WDMAC_MODE_MSTABORT_ENAB | WDMAC_MODE_PARITYERR_ENAB | - WDMAC_MODE_ADDROFLOW_ENAB | WDMAC_MODE_FIFOOFLOW_ENAB | - WDMAC_MODE_FIFOURUN_ENAB | WDMAC_MODE_FIFOOREAD_ENAB | - WDMAC_MODE_LNGREAD_ENAB)); + val = (WDMAC_MODE_ENABLE | WDMAC_MODE_TGTABORT_ENAB | + WDMAC_MODE_MSTABORT_ENAB | WDMAC_MODE_PARITYERR_ENAB | + WDMAC_MODE_ADDROFLOW_ENAB | WDMAC_MODE_FIFOOFLOW_ENAB | + WDMAC_MODE_FIFOURUN_ENAB | WDMAC_MODE_FIFOOREAD_ENAB | + WDMAC_MODE_LNGREAD_ENAB); + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705 && + (tr32(TG3PCI_PCISTATE) & PCISTATE_BUS_SPEED_HIGH) != 0 && + !(tp->tg3_flags2 & TG3_FLG2_IS_5788)) + val |= WDMAC_MODE_RX_ACCEL; + tw32(WDMAC_MODE, val); tr32(WDMAC_MODE); udelay(40); - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5704 && - (tp->tg3_flags & TG3_FLAG_PCIX_MODE)) { + if ((tp->tg3_flags & TG3_FLAG_PCIX_MODE) != 0) { val = tr32(TG3PCI_X_CAPS); - val &= ~(PCIX_CAPS_SPLIT_MASK | PCIX_CAPS_BURST_MASK); - val |= (PCIX_CAPS_MAX_BURST_5704 << PCIX_CAPS_BURST_SHIFT); - if (tp->tg3_flags & TG3_FLAG_SPLIT_MODE) - val |= (tp->split_mode_max_reqs << - PCIX_CAPS_SPLIT_SHIFT); + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5703) { + val &= ~PCIX_CAPS_BURST_MASK; + val |= (PCIX_CAPS_MAX_BURST_CPIOB << PCIX_CAPS_BURST_SHIFT); + } else if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5704) { + val &= ~(PCIX_CAPS_SPLIT_MASK | PCIX_CAPS_BURST_MASK); + val |= (PCIX_CAPS_MAX_BURST_CPIOB << PCIX_CAPS_BURST_SHIFT); + if (tp->tg3_flags & TG3_FLAG_SPLIT_MODE) + val |= (tp->split_mode_max_reqs << + PCIX_CAPS_SPLIT_SHIFT); + } tw32(TG3PCI_X_CAPS, val); } - val = (RDMAC_MODE_ENABLE | RDMAC_MODE_TGTABORT_ENAB | - RDMAC_MODE_MSTABORT_ENAB | RDMAC_MODE_PARITYERR_ENAB | - RDMAC_MODE_ADDROFLOW_ENAB | RDMAC_MODE_FIFOOFLOW_ENAB | - RDMAC_MODE_FIFOURUN_ENAB | RDMAC_MODE_FIFOOREAD_ENAB | - RDMAC_MODE_LNGREAD_ENAB); - if (tp->tg3_flags & TG3_FLAG_SPLIT_MODE) - val |= RDMAC_MODE_SPLIT_ENABLE; - tw32(RDMAC_MODE, val); + tw32(RDMAC_MODE, rdmac_mode); tr32(RDMAC_MODE); udelay(40); tw32(RCVDCC_MODE, RCVDCC_MODE_ENABLE | RCVDCC_MODE_ATTN_ENABLE); - tw32(MBFREE_MODE, MBFREE_MODE_ENABLE); + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705) + tw32(MBFREE_MODE, MBFREE_MODE_ENABLE); tw32(SNDDATAC_MODE, SNDDATAC_MODE_ENABLE); tw32(SNDBDC_MODE, SNDBDC_MODE_ENABLE | SNDBDC_MODE_ATTN_ENABLE); tw32(RCVBDI_MODE, RCVBDI_MODE_ENABLE | RCVBDI_MODE_RCB_ATTN_ENAB); @@ -4310,8 +5033,8 @@ return err; } -#if TG3_DO_TSO != 0 - if (tp->dev->features & NETIF_F_TSO) { +#if TG3_TSO_SUPPORT != 0 + if (tp->tg3_flags2 & TG3_FLG2_TSO_CAPABLE) { err = tg3_load_tso_firmware(tp); if (err) return err; @@ -4342,9 +5065,11 @@ tw32(MAC_LED_CTRL, 0); tw32(MAC_MI_STAT, MAC_MI_STAT_LNKSTAT_ATTN_ENAB); - tw32(MAC_RX_MODE, RX_MODE_RESET); - tr32(MAC_RX_MODE); - udelay(10); + if (tp->phy_id == PHY_ID_SERDES) { + tw32(MAC_RX_MODE, RX_MODE_RESET); + tr32(MAC_RX_MODE); + udelay(10); + } tw32(MAC_RX_MODE, tp->rx_mode); tr32(MAC_RX_MODE); udelay(10); @@ -4378,22 +5103,48 @@ tw32(MAC_RCV_VALUE_0, 0xffffffff & RCV_RULE_DISABLE_MASK); tw32(MAC_RCV_RULE_1, 0x86000004 & RCV_RULE_DISABLE_MASK); tw32(MAC_RCV_VALUE_1, 0xffffffff & RCV_RULE_DISABLE_MASK); -#if 0 - tw32(MAC_RCV_RULE_2, 0); tw32(MAC_RCV_VALUE_2, 0); - tw32(MAC_RCV_RULE_3, 0); tw32(MAC_RCV_VALUE_3, 0); -#endif - tw32(MAC_RCV_RULE_4, 0); tw32(MAC_RCV_VALUE_4, 0); - tw32(MAC_RCV_RULE_5, 0); tw32(MAC_RCV_VALUE_5, 0); - tw32(MAC_RCV_RULE_6, 0); tw32(MAC_RCV_VALUE_6, 0); - tw32(MAC_RCV_RULE_7, 0); tw32(MAC_RCV_VALUE_7, 0); - tw32(MAC_RCV_RULE_8, 0); tw32(MAC_RCV_VALUE_8, 0); - tw32(MAC_RCV_RULE_9, 0); tw32(MAC_RCV_VALUE_9, 0); - tw32(MAC_RCV_RULE_10, 0); tw32(MAC_RCV_VALUE_10, 0); - tw32(MAC_RCV_RULE_11, 0); tw32(MAC_RCV_VALUE_11, 0); - tw32(MAC_RCV_RULE_12, 0); tw32(MAC_RCV_VALUE_12, 0); - tw32(MAC_RCV_RULE_13, 0); tw32(MAC_RCV_VALUE_13, 0); - tw32(MAC_RCV_RULE_14, 0); tw32(MAC_RCV_VALUE_14, 0); - tw32(MAC_RCV_RULE_15, 0); tw32(MAC_RCV_VALUE_15, 0); + + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) + limit = 8; + else + limit = 16; + if (tp->tg3_flags & TG3_FLAG_ENABLE_ASF) + limit -= 4; + switch (limit) { + case 16: + tw32(MAC_RCV_RULE_15, 0); tw32(MAC_RCV_VALUE_15, 0); + case 15: + tw32(MAC_RCV_RULE_14, 0); tw32(MAC_RCV_VALUE_14, 0); + case 14: + tw32(MAC_RCV_RULE_13, 0); tw32(MAC_RCV_VALUE_13, 0); + case 13: + tw32(MAC_RCV_RULE_12, 0); tw32(MAC_RCV_VALUE_12, 0); + case 12: + tw32(MAC_RCV_RULE_11, 0); tw32(MAC_RCV_VALUE_11, 0); + case 11: + tw32(MAC_RCV_RULE_10, 0); tw32(MAC_RCV_VALUE_10, 0); + case 10: + tw32(MAC_RCV_RULE_9, 0); tw32(MAC_RCV_VALUE_9, 0); + case 9: + tw32(MAC_RCV_RULE_8, 0); tw32(MAC_RCV_VALUE_8, 0); + case 8: + tw32(MAC_RCV_RULE_7, 0); tw32(MAC_RCV_VALUE_7, 0); + case 7: + tw32(MAC_RCV_RULE_6, 0); tw32(MAC_RCV_VALUE_6, 0); + case 6: + tw32(MAC_RCV_RULE_5, 0); tw32(MAC_RCV_VALUE_5, 0); + case 5: + tw32(MAC_RCV_RULE_4, 0); tw32(MAC_RCV_VALUE_4, 0); + case 4: + /* tw32(MAC_RCV_RULE_3, 0); tw32(MAC_RCV_VALUE_3, 0); */ + case 3: + /* tw32(MAC_RCV_RULE_2, 0); tw32(MAC_RCV_VALUE_2, 0); */ + case 2: + case 1: + + default: + break; + }; if (tp->tg3_flags & TG3_FLAG_INIT_COMPLETE) tg3_enable_ints(tp); @@ -4423,6 +5174,50 @@ return err; } +#define TG3_STAT_ADD32(PSTAT, REG) \ +do { u32 __val = tr32(REG); \ + (PSTAT)->low += __val; \ + if ((PSTAT)->low < __val) \ + (PSTAT)->high += 1; \ +} while (0) + +static void tg3_periodic_fetch_stats(struct tg3 *tp) +{ + struct tg3_hw_stats *sp = tp->hw_stats; + + if (!netif_carrier_ok(tp->dev)) + return; + + TG3_STAT_ADD32(&sp->tx_octets, MAC_TX_STATS_OCTETS); + TG3_STAT_ADD32(&sp->tx_collisions, MAC_TX_STATS_COLLISIONS); + TG3_STAT_ADD32(&sp->tx_xon_sent, MAC_TX_STATS_XON_SENT); + TG3_STAT_ADD32(&sp->tx_xoff_sent, MAC_TX_STATS_XOFF_SENT); + TG3_STAT_ADD32(&sp->tx_mac_errors, MAC_TX_STATS_MAC_ERRORS); + TG3_STAT_ADD32(&sp->tx_single_collisions, MAC_TX_STATS_SINGLE_COLLISIONS); + TG3_STAT_ADD32(&sp->tx_mult_collisions, MAC_TX_STATS_MULT_COLLISIONS); + TG3_STAT_ADD32(&sp->tx_deferred, MAC_TX_STATS_DEFERRED); + TG3_STAT_ADD32(&sp->tx_excessive_collisions, MAC_TX_STATS_EXCESSIVE_COL); + TG3_STAT_ADD32(&sp->tx_late_collisions, MAC_TX_STATS_LATE_COL); + TG3_STAT_ADD32(&sp->tx_ucast_packets, MAC_TX_STATS_UCAST); + TG3_STAT_ADD32(&sp->tx_mcast_packets, MAC_TX_STATS_MCAST); + TG3_STAT_ADD32(&sp->tx_bcast_packets, MAC_TX_STATS_BCAST); + + TG3_STAT_ADD32(&sp->rx_octets, MAC_RX_STATS_OCTETS); + TG3_STAT_ADD32(&sp->rx_fragments, MAC_RX_STATS_FRAGMENTS); + TG3_STAT_ADD32(&sp->rx_ucast_packets, MAC_RX_STATS_UCAST); + TG3_STAT_ADD32(&sp->rx_mcast_packets, MAC_RX_STATS_MCAST); + TG3_STAT_ADD32(&sp->rx_bcast_packets, MAC_RX_STATS_BCAST); + TG3_STAT_ADD32(&sp->rx_fcs_errors, MAC_RX_STATS_FCS_ERRORS); + TG3_STAT_ADD32(&sp->rx_align_errors, MAC_RX_STATS_ALIGN_ERRORS); + TG3_STAT_ADD32(&sp->rx_xon_pause_rcvd, MAC_RX_STATS_XON_PAUSE_RECVD); + TG3_STAT_ADD32(&sp->rx_xoff_pause_rcvd, MAC_RX_STATS_XOFF_PAUSE_RECVD); + TG3_STAT_ADD32(&sp->rx_mac_ctrl_rcvd, MAC_RX_STATS_MAC_CTRL_RECVD); + TG3_STAT_ADD32(&sp->rx_xoff_entered, MAC_RX_STATS_XOFF_ENTERED); + TG3_STAT_ADD32(&sp->rx_frame_too_long_errors, MAC_RX_STATS_FRAME_TOO_LONG); + TG3_STAT_ADD32(&sp->rx_jabbers, MAC_RX_STATS_JABBERS); + TG3_STAT_ADD32(&sp->rx_undersize_packets, MAC_RX_STATS_UNDERSIZE); +} + static void tg3_timer(unsigned long __opaque) { struct tg3 *tp = (struct tg3 *) __opaque; @@ -4451,6 +5246,9 @@ return; } + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) + tg3_periodic_fetch_stats(tp); + /* This part only runs once per second. */ if (!--tp->timer_counter) { if (tp->tg3_flags & TG3_FLAG_USE_LINKCHG_REG) { @@ -4908,7 +5706,9 @@ get_stat64(&hw_stats->rx_bcast_packets); stats->tx_packets = old_stats->tx_packets + - get_stat64(&hw_stats->COS_out_packets[0]); + get_stat64(&hw_stats->tx_ucast_packets) + + get_stat64(&hw_stats->tx_mcast_packets) + + get_stat64(&hw_stats->tx_bcast_packets); stats->rx_bytes = old_stats->rx_bytes + get_stat64(&hw_stats->rx_octets); @@ -5232,6 +6032,28 @@ tp->msg_enable = value; } +static u32 tg3_get_tso(struct net_device *dev) +{ + return (dev->features & NETIF_F_TSO) != 0; +} + +static int tg3_set_tso(struct net_device *dev, u32 value) +{ + struct tg3 *tp = dev->priv; + + if (!(tp->tg3_flags2 & TG3_FLG2_TSO_CAPABLE)) { + if (value) + return -EINVAL; + return 0; + } else { + if (!value) + dev->features &= ~NETIF_F_TSO; + else + dev->features |= NETIF_F_TSO; + return 0; + } +} + static int tg3_nway_reset(struct net_device *dev) { struct tg3 *tp = dev->priv; @@ -5279,6 +6101,10 @@ spin_lock(&tp->tx_lock); tp->rx_pending = ering->rx_pending; + + if ((tp->tg3_flags2 & TG3_FLG2_MAX_RXPEND_64) && + tp->rx_pending > 64) + tp->rx_pending = 64; tp->rx_jumbo_pending = ering->rx_jumbo_pending; tp->tx_pending = ering->tx_pending; @@ -5467,6 +6293,8 @@ .set_tx_csum = tg3_set_tx_csum, .get_sg = ethtool_op_get_sg, .set_sg = ethtool_op_set_sg, + .get_tso = tg3_get_tso, + .set_tso = tg3_set_tso, }; /* Chips other than 5700/5701 use the NVRAM for fetching info. */ @@ -5669,6 +6497,7 @@ u32 nic_cfg; tg3_read_mem(tp, NIC_SRAM_DATA_CFG, &nic_cfg); + tp->nic_sram_data_cfg = nic_cfg; eeprom_signature_found = 1; @@ -5702,8 +6531,10 @@ eeprom_led_mode = led_mode_auto; break; }; - if ((tp->pci_chip_rev_id == CHIPREV_ID_5703_A1 || - tp->pci_chip_rev_id == CHIPREV_ID_5703_A2) && + + if (((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5703) || + (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5704) || + (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705)) && (nic_cfg & NIC_SRAM_DATA_CFG_EEPROM_WP)) tp->tg3_flags |= TG3_FLAG_EEPROM_WRITE_PROT; @@ -5785,9 +6616,7 @@ } /* Enable Ethernet@WireSpeed */ - tg3_writephy(tp, MII_TG3_AUX_CTRL, 0x7007); - tg3_readphy(tp, MII_TG3_AUX_CTRL, &val); - tg3_writephy(tp, MII_TG3_AUX_CTRL, (val | (1 << 15) | (1 << 4))); + tg3_phy_set_wirespeed(tp); if (!err && ((tp->phy_id & PHY_ID_MASK) == PHY_ID_BCM5401)) { err = tg3_init_5401phy_dsp(tp); @@ -6085,7 +6914,15 @@ tp->tg3_flags |= TG3_FLAG_WOL_SPEED_100MB; } + /* A few boards don't want Ethernet@WireSpeed phy feature */ + if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700) || + ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) && + (tp->pci_chip_rev_id != CHIPREV_ID_5705_A0) && + (tp->pci_chip_rev_id != CHIPREV_ID_5705_A1))) + tp->tg3_flags2 |= TG3_FLG2_NO_ETH_WIRE_SPEED; + /* Only 5701 and later support tagged irq status mode. + * Also, 5788 chips cannot use tagged irq status. * * However, since we are using NAPI avoid tagged irq status * because the interrupt condition is more difficult to @@ -6142,7 +6979,8 @@ /* Determine if TX descriptors will reside in * main memory or in the chip SRAM. */ - if (tp->tg3_flags & TG3_FLAG_PCIX_TARGET_HWBUG) + if ((tp->tg3_flags & TG3_FLAG_PCIX_TARGET_HWBUG) != 0 || + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) tp->tg3_flags |= TG3_FLAG_HOST_TXDS; grc_misc_cfg = tr32(GRC_MISC_CFG); @@ -6154,8 +6992,18 @@ tp->split_mode_max_reqs = SPLIT_MODE_5704_MAX_REQ; } - /* this one is limited to 10/100 only */ - if (grc_misc_cfg == GRC_MISC_CFG_BOARD_ID_5702FE) + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705 && + (grc_misc_cfg == GRC_MISC_CFG_BOARD_ID_5788 || + grc_misc_cfg == GRC_MISC_CFG_BOARD_ID_5788M)) + tp->tg3_flags2 |= TG3_FLG2_IS_5788; + + /* these are limited to 10/100 only */ + if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5703 && + (grc_misc_cfg == 0x8000 || grc_misc_cfg == 0x4000)) || + (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705 && + tp->pdev->vendor == PCI_VENDOR_ID_BROADCOM && + (tp->pdev->device == PCI_DEVICE_ID_TIGON3_5901 || + tp->pdev->device == PCI_DEVICE_ID_TIGON3_5901_2))) tp->tg3_flags |= TG3_FLAG_10_100_ONLY; err = tg3_phy_probe(tp); @@ -6414,8 +7262,6 @@ goto out_nofree; } - tw32(TG3PCI_CLOCK_CTRL, 0); - if ((tp->tg3_flags & TG3_FLAG_PCIX_MODE) == 0) { tp->dma_rwctrl = (0x7 << DMA_RWCTRL_PCI_WRITE_CMD_SHIFT) | @@ -6423,7 +7269,9 @@ (0x7 << DMA_RWCTRL_WRITE_WATER_SHIFT) | (0x7 << DMA_RWCTRL_READ_WATER_SHIFT) | (0x0f << DMA_RWCTRL_MIN_DMA_SHIFT); - /* XXX 5705 note: set MIN_DMA to zero here */ + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) + tp->dma_rwctrl &= ~(DMA_RWCTRL_MIN_DMA + << DMA_RWCTRL_MIN_DMA_SHIFT); } else { if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5704) tp->dma_rwctrl = @@ -6526,6 +7374,11 @@ tw32(TG3PCI_DMA_RW_CTRL, tp->dma_rwctrl); +#if 0 + /* Unneeded, already done by tg3_get_invariants. */ + tg3_switch_clocks(tp); +#endif + ret = 0; if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5700 && GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5701) @@ -6630,12 +7483,35 @@ case PHY_ID_BCM5701: return "5701"; case PHY_ID_BCM5703: return "5703"; case PHY_ID_BCM5704: return "5704"; + case PHY_ID_BCM5705: return "5705"; case PHY_ID_BCM8002: return "8002"; case PHY_ID_SERDES: return "serdes"; default: return "unknown"; }; } +static struct pci_dev * __devinit tg3_find_5704_peer(struct tg3 *tp) +{ + struct pci_dev *peer = NULL; + unsigned int func; + + for (func = 0; func < 7; func++) { + unsigned int devfn = tp->pdev->devfn; + + devfn &= ~7; + devfn |= func; + + if (devfn == tp->pdev->devfn) + continue; + peer = pci_find_slot(tp->pdev->bus->number, devfn); + if (peer) + break; + } + if (!peer || peer == tp->pdev) + BUG(); + return peer; +} + static int __devinit tg3_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) { @@ -6794,6 +7670,44 @@ goto err_out_iounmap; } + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) { + tp->bufmgr_config.mbuf_read_dma_low_water = + DEFAULT_MB_RDMA_LOW_WATER_5705; + tp->bufmgr_config.mbuf_mac_rx_low_water = + DEFAULT_MB_MACRX_LOW_WATER_5705; + tp->bufmgr_config.mbuf_high_water = + DEFAULT_MB_HIGH_WATER_5705; + } + +#if TG3_TSO_SUPPORT != 0 + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700 || + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701 || + tp->pci_chip_rev_id == CHIPREV_ID_5705_A0 || + (tp->tg3_flags & TG3_FLAG_ENABLE_ASF) != 0 || + (tp->tg3_flags2 & TG3_FLG2_IS_5788)) { + tp->tg3_flags2 &= ~TG3_FLG2_TSO_CAPABLE; + } else { + tp->tg3_flags2 |= TG3_FLG2_TSO_CAPABLE; + } + + /* TSO is off by default, user can enable using ethtool. */ +#if 0 + if (tp->tg3_flags2 & TG3_FLG2_TSO_CAPABLE) + dev->features |= NETIF_F_TSO; +#endif + +#endif + + if (tp->pci_chip_rev_id == CHIPREV_ID_5705_A1 && + !(tp->tg3_flags2 & TG3_FLG2_TSO_CAPABLE) && + !(tr32(TG3PCI_PCISTATE) & PCISTATE_BUS_SPEED_HIGH)) { + tp->tg3_flags2 |= TG3_FLG2_MAX_RXPEND_64; + tp->rx_pending = 64; + } + + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5704) + tp->pdev_peer = tg3_find_5704_peer(tp); + err = tg3_get_device_address(tp); if (err) { printk(KERN_ERR PFX "Could not obtain valid ethernet address, " @@ -6816,16 +7730,8 @@ } else tp->tg3_flags &= ~TG3_FLAG_RX_CHECKSUMS; -#if TG3_DO_TSO != 0 - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700 || - (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701 && - tp->pci_chip_rev_id <= CHIPREV_ID_5701_B2)) { - /* Not TSO capable. */ - dev->features &= ~NETIF_F_TSO; - } else { - dev->features |= NETIF_F_TSO; - } -#endif + if (tp->tg3_flags2 & TG3_FLG2_IS_5788) + dev->features &= ~NETIF_F_HIGHDMA; err = register_netdev(dev); if (err) { diff -Nru a/drivers/net/tg3.h b/drivers/net/tg3.h --- a/drivers/net/tg3.h Sat Aug 23 21:49:57 2003 +++ b/drivers/net/tg3.h Sat Aug 23 21:49:57 2003 @@ -24,6 +24,7 @@ #define RX_COPY_THRESHOLD 256 #define RX_STD_MAX_SIZE 1536 +#define RX_STD_MAX_SIZE_5705 512 #define RX_JUMBO_MAX_SIZE 0xdeadbeef /* XXX */ /* First 256 bytes are a mirror of PCI config space. */ @@ -59,7 +60,7 @@ #define PCIX_CAPS_SPLIT_SHIFT 20 #define PCIX_CAPS_BURST_MASK 0x000c0000 #define PCIX_CAPS_BURST_SHIFT 18 -#define PCIX_CAPS_MAX_BURST_5704 2 +#define PCIX_CAPS_MAX_BURST_CPIOB 2 #define TG3PCI_PM_CAP_PTR 0x00000041 #define TG3PCI_X_COMMAND 0x00000042 #define TG3PCI_X_STATUS 0x00000044 @@ -115,11 +116,14 @@ #define CHIPREV_ID_5704_A0 0x2000 #define CHIPREV_ID_5704_A1 0x2001 #define CHIPREV_ID_5704_A2 0x2002 +#define CHIPREV_ID_5705_A0 0x3000 +#define CHIPREV_ID_5705_A1 0x3001 #define GET_ASIC_REV(CHIP_REV_ID) ((CHIP_REV_ID) >> 12) #define ASIC_REV_5700 0x07 #define ASIC_REV_5701 0x00 #define ASIC_REV_5703 0x01 #define ASIC_REV_5704 0x02 +#define ASIC_REV_5705 0x03 #define GET_CHIP_REV(CHIP_REV_ID) ((CHIP_REV_ID) >> 8) #define CHIPREV_5700_AX 0x70 #define CHIPREV_5700_BX 0x71 @@ -180,6 +184,9 @@ #define CLOCK_CTRL_ALTCLK 0x00001000 #define CLOCK_CTRL_PWRDOWN_PLL133 0x00008000 #define CLOCK_CTRL_44MHZ_CORE 0x00040000 +#define CLOCK_CTRL_625_CORE 0x00100000 +#define CLOCK_CTRL_FORCE_CLKRUN 0x00200000 +#define CLOCK_CTRL_CLKRUN_OENABLE 0x00400000 #define CLOCK_CTRL_DELAY_PCI_GRANT 0x80000000 #define TG3PCI_REG_BASE_ADDR 0x00000078 #define TG3PCI_MEM_WIN_BASE_ADDR 0x0000007c @@ -457,17 +464,89 @@ #define MAC_RCV_RULE_CFG 0x00000500 #define RCV_RULE_CFG_DEFAULT_CLASS 0x00000008 #define MAC_LOW_WMARK_MAX_RX_FRAME 0x00000504 -/* 0x504 --> 0x590 unused */ +/* 0x508 --> 0x520 unused */ +#define MAC_HASHREGU_0 0x00000520 +#define MAC_HASHREGU_1 0x00000524 +#define MAC_HASHREGU_2 0x00000528 +#define MAC_HASHREGU_3 0x0000052c +#define MAC_EXTADDR_0_HIGH 0x00000530 +#define MAC_EXTADDR_0_LOW 0x00000534 +#define MAC_EXTADDR_1_HIGH 0x00000538 +#define MAC_EXTADDR_1_LOW 0x0000053c +#define MAC_EXTADDR_2_HIGH 0x00000540 +#define MAC_EXTADDR_2_LOW 0x00000544 +#define MAC_EXTADDR_3_HIGH 0x00000548 +#define MAC_EXTADDR_3_LOW 0x0000054c +#define MAC_EXTADDR_4_HIGH 0x00000550 +#define MAC_EXTADDR_4_LOW 0x00000554 +#define MAC_EXTADDR_5_HIGH 0x00000558 +#define MAC_EXTADDR_5_LOW 0x0000055c +#define MAC_EXTADDR_6_HIGH 0x00000560 +#define MAC_EXTADDR_6_LOW 0x00000564 +#define MAC_EXTADDR_7_HIGH 0x00000568 +#define MAC_EXTADDR_7_LOW 0x0000056c +#define MAC_EXTADDR_8_HIGH 0x00000570 +#define MAC_EXTADDR_8_LOW 0x00000574 +#define MAC_EXTADDR_9_HIGH 0x00000578 +#define MAC_EXTADDR_9_LOW 0x0000057c +#define MAC_EXTADDR_10_HIGH 0x00000580 +#define MAC_EXTADDR_10_LOW 0x00000584 +#define MAC_EXTADDR_11_HIGH 0x00000588 +#define MAC_EXTADDR_11_LOW 0x0000058c #define MAC_SERDES_CFG 0x00000590 #define MAC_SERDES_STAT 0x00000594 /* 0x598 --> 0x600 unused */ #define MAC_TX_MAC_STATE_BASE 0x00000600 /* 16 bytes */ #define MAC_RX_MAC_STATE_BASE 0x00000610 /* 20 bytes */ /* 0x624 --> 0x800 unused */ -#define MAC_RX_STATS_BASE 0x00000800 /* 26 32-bit words */ -/* 0x868 --> 0x880 unused */ -#define MAC_TX_STATS_BASE 0x00000880 /* 28 32-bit words */ -/* 0x8f0 --> 0xc00 unused */ +#define MAC_TX_STATS_OCTETS 0x00000800 +#define MAC_TX_STATS_RESV1 0x00000804 +#define MAC_TX_STATS_COLLISIONS 0x00000808 +#define MAC_TX_STATS_XON_SENT 0x0000080c +#define MAC_TX_STATS_XOFF_SENT 0x00000810 +#define MAC_TX_STATS_RESV2 0x00000814 +#define MAC_TX_STATS_MAC_ERRORS 0x00000818 +#define MAC_TX_STATS_SINGLE_COLLISIONS 0x0000081c +#define MAC_TX_STATS_MULT_COLLISIONS 0x00000820 +#define MAC_TX_STATS_DEFERRED 0x00000824 +#define MAC_TX_STATS_RESV3 0x00000828 +#define MAC_TX_STATS_EXCESSIVE_COL 0x0000082c +#define MAC_TX_STATS_LATE_COL 0x00000830 +#define MAC_TX_STATS_RESV4_1 0x00000834 +#define MAC_TX_STATS_RESV4_2 0x00000838 +#define MAC_TX_STATS_RESV4_3 0x0000083c +#define MAC_TX_STATS_RESV4_4 0x00000840 +#define MAC_TX_STATS_RESV4_5 0x00000844 +#define MAC_TX_STATS_RESV4_6 0x00000848 +#define MAC_TX_STATS_RESV4_7 0x0000084c +#define MAC_TX_STATS_RESV4_8 0x00000850 +#define MAC_TX_STATS_RESV4_9 0x00000854 +#define MAC_TX_STATS_RESV4_10 0x00000858 +#define MAC_TX_STATS_RESV4_11 0x0000085c +#define MAC_TX_STATS_RESV4_12 0x00000860 +#define MAC_TX_STATS_RESV4_13 0x00000864 +#define MAC_TX_STATS_RESV4_14 0x00000868 +#define MAC_TX_STATS_UCAST 0x0000086c +#define MAC_TX_STATS_MCAST 0x00000870 +#define MAC_TX_STATS_BCAST 0x00000874 +#define MAC_TX_STATS_RESV5_1 0x00000878 +#define MAC_TX_STATS_RESV5_2 0x0000087c +#define MAC_RX_STATS_OCTETS 0x00000880 +#define MAC_RX_STATS_RESV1 0x00000884 +#define MAC_RX_STATS_FRAGMENTS 0x00000888 +#define MAC_RX_STATS_UCAST 0x0000088c +#define MAC_RX_STATS_MCAST 0x00000890 +#define MAC_RX_STATS_BCAST 0x00000894 +#define MAC_RX_STATS_FCS_ERRORS 0x00000898 +#define MAC_RX_STATS_ALIGN_ERRORS 0x0000089c +#define MAC_RX_STATS_XON_PAUSE_RECVD 0x000008a0 +#define MAC_RX_STATS_XOFF_PAUSE_RECVD 0x000008a4 +#define MAC_RX_STATS_MAC_CTRL_RECVD 0x000008a8 +#define MAC_RX_STATS_XOFF_ENTERED 0x000008ac +#define MAC_RX_STATS_FRAME_TOO_LONG 0x000008b0 +#define MAC_RX_STATS_JABBERS 0x000008b4 +#define MAC_RX_STATS_UNDERSIZE 0x000008b8 +/* 0x8bc --> 0xc00 unused */ /* Send data initiator control registers */ #define SNDDATAI_MODE 0x00000c00 @@ -599,6 +678,7 @@ #define RCVLPC_STATSCTRL_ENABLE 0x00000001 #define RCVLPC_STATSCTRL_FASTUPD 0x00000002 #define RCVLPC_STATS_ENABLE 0x00002018 +#define RCVLPC_STATSENAB_LNGBRST_RFIX 0x00400000 #define RCVLPC_STATS_INCMASK 0x0000201c /* 0x2020 --> 0x2100 unused */ #define RCVLPC_SELLST_BASE 0x00002100 /* 16 16-byte entries */ @@ -812,13 +892,16 @@ #define BUFMGR_MB_POOL_ADDR 0x00004408 #define BUFMGR_MB_POOL_SIZE 0x0000440c #define BUFMGR_MB_RDMA_LOW_WATER 0x00004410 -#define DEFAULT_MB_RDMA_LOW_WATER 0x00000040 +#define DEFAULT_MB_RDMA_LOW_WATER 0x00000050 +#define DEFAULT_MB_RDMA_LOW_WATER_5705 0x00000000 #define DEFAULT_MB_RDMA_LOW_WATER_JUMBO 0x00000130 #define BUFMGR_MB_MACRX_LOW_WATER 0x00004414 #define DEFAULT_MB_MACRX_LOW_WATER 0x00000020 +#define DEFAULT_MB_MACRX_LOW_WATER_5705 0x00000010 #define DEFAULT_MB_MACRX_LOW_WATER_JUMBO 0x00000098 #define BUFMGR_MB_HIGH_WATER 0x00004418 #define DEFAULT_MB_HIGH_WATER 0x00000060 +#define DEFAULT_MB_HIGH_WATER_5705 0x00000060 #define DEFAULT_MB_HIGH_WATER_JUMBO 0x0000017c #define BUFMGR_RX_MB_ALLOC_REQ 0x0000441c #define BUFMGR_MB_ALLOC_BIT 0x10000000 @@ -854,6 +937,8 @@ #define RDMAC_MODE_LNGREAD_ENAB 0x00000200 #define RDMAC_MODE_SPLIT_ENABLE 0x00000800 #define RDMAC_MODE_SPLIT_RESET 0x00001000 +#define RDMAC_MODE_FIFO_SIZE_128 0x00020000 +#define RDMAC_MODE_FIFO_LONG_BURST 0x00030000 #define RDMAC_STATUS 0x00004804 #define RDMAC_STATUS_TGTABORT 0x00000004 #define RDMAC_STATUS_MSTABORT 0x00000008 @@ -877,6 +962,7 @@ #define WDMAC_MODE_FIFOURUN_ENAB 0x00000080 #define WDMAC_MODE_FIFOOREAD_ENAB 0x00000100 #define WDMAC_MODE_LNGREAD_ENAB 0x00000200 +#define WDMAC_MODE_RX_ACCEL 0x00000400 #define WDMAC_STATUS 0x00004c04 #define WDMAC_STATUS_TGTABORT 0x00000004 #define WDMAC_STATUS_MSTABORT 0x00000008 @@ -1140,7 +1226,10 @@ #define GRC_MISC_CFG_BOARD_ID_5704 0x00000000 #define GRC_MISC_CFG_BOARD_ID_5704CIOBE 0x00004000 #define GRC_MISC_CFG_BOARD_ID_5704_A2 0x00008000 +#define GRC_MISC_CFG_BOARD_ID_5788 0x00010000 +#define GRC_MISC_CFG_BOARD_ID_5788M 0x00018000 #define GRC_MISC_CFG_BOARD_ID_AC91002A1 0x00018000 +#define GRC_MISC_CFG_KEEP_GPHY_POWER 0x04000000 #define GRC_LOCAL_CTRL 0x00006808 #define GRC_LCLCTRL_INT_ACTIVE 0x00000001 #define GRC_LCLCTRL_CLEARINT 0x00000002 @@ -1275,6 +1364,7 @@ #define NIC_SRAM_DATA_CFG_WOL_ENABLE 0x00000040 #define NIC_SRAM_DATA_CFG_ASF_ENABLE 0x00000080 #define NIC_SRAM_DATA_CFG_EEPROM_WP 0x00000100 +#define NIC_SRAM_DATA_CFG_MINI_PCI 0x00001000 #define NIC_SRAM_DATA_CFG_FIBER_WOL 0x00004000 #define NIC_SRAM_DATA_PHY_ID 0x00000b74 @@ -1312,6 +1402,8 @@ #define NIC_SRAM_MBUF_POOL_BASE 0x00008000 #define NIC_SRAM_MBUF_POOL_SIZE96 0x00018000 #define NIC_SRAM_MBUF_POOL_SIZE64 0x00010000 +#define NIC_SRAM_MBUF_POOL_BASE5705 0x00010000 +#define NIC_SRAM_MBUF_POOL_SIZE5705 0x0000e000 /* Currently this is fixed. */ #define PHY_ADDR 0x01 @@ -1824,6 +1916,10 @@ u32 tg3_flags2; #define TG3_FLG2_RESTART_TIMER 0x00000001 #define TG3_FLG2_SUN_5704 0x00000002 +#define TG3_FLG2_NO_ETH_WIRE_SPEED 0x00000004 +#define TG3_FLG2_IS_5788 0x00000008 +#define TG3_FLG2_MAX_RXPEND_64 0x00000010 +#define TG3_FLG2_TSO_CAPABLE 0x00000020 u32 split_mode_max_reqs; #define SPLIT_MODE_5704_MAX_REQ 3 @@ -1868,6 +1964,7 @@ #define PHY_ID_BCM5701 0x60008110 #define PHY_ID_BCM5703 0x60008160 #define PHY_ID_BCM5704 0x60008190 +#define PHY_ID_BCM5705 0x600081a0 #define PHY_ID_BCM8002 0x60010140 #define PHY_ID_SERDES 0xfeedbee0 #define PHY_ID_INVALID 0xffffffff @@ -1880,6 +1977,9 @@ enum phy_led_mode led_mode; char board_part_number[24]; + u32 nic_sram_data_cfg; + u32 pci_clock_ctrl; + struct pci_dev *pdev_peer; /* This macro assumes the passed PHY ID is already masked * with PHY_ID_MASK. @@ -1888,6 +1988,7 @@ ((X) == PHY_ID_BCM5400 || (X) == PHY_ID_BCM5401 || \ (X) == PHY_ID_BCM5411 || (X) == PHY_ID_BCM5701 || \ (X) == PHY_ID_BCM5703 || (X) == PHY_ID_BCM5704 || \ + (X) == PHY_ID_BCM5705 || \ (X) == PHY_ID_BCM8002 || (X) == PHY_ID_SERDES) struct tg3_hw_stats *hw_stats; diff -Nru a/drivers/pci/pci.ids b/drivers/pci/pci.ids --- a/drivers/pci/pci.ids Sat Aug 23 21:49:57 2003 +++ b/drivers/pci/pci.ids Sat Aug 23 21:49:57 2003 @@ -5313,9 +5313,12 @@ 1166 1648 NetXtreme CIOB-E 1000Base-T 164d NetXtreme BCM5702FE Gigabit Ethernet 1653 NetXtreme BCM5705 Gigabit Ethernet + 1654 NetXtreme BCM5705 Gigabit Ethernet 165d NetXtreme BCM5705M Gigabit Ethernet + 165e NetXtreme BCM5705M Gigabit Ethernet 1696 NetXtreme BCM5782 Gigabit Ethernet 14e4 000d NetXtreme BCM5782 1000Base-T + 169c NetXtreme BCM5788 Gigabit Ethernet 16a6 NetXtreme BCM5702 Gigabit Ethernet 0e11 00bb NC7760 Gigabit Server Adapter (PCI-X, 10/100/1000-T) 1028 0126 BCM5702 1000Base-T @@ -5337,6 +5340,8 @@ 16c7 NetXtreme BCM5703 Gigabit Ethernet 14e4 0009 NetXtreme BCM5703 1000Base-T 14e4 000a NetXtreme BCM5703 1000Base-SX + 170d NetXtreme BCM5901 Gigabit Ethernet + 170e NetXtreme BCM5901 Gigabit Ethernet 4210 BCM4210 iLine10 HomePNA 2.0 4211 BCM4211 iLine10 HomePNA 2.0 + V.90 56k modem 4212 BCM4212 v.90 56k modem diff -Nru a/include/linux/ethtool.h b/include/linux/ethtool.h --- a/include/linux/ethtool.h Sat Aug 23 21:49:57 2003 +++ b/include/linux/ethtool.h Sat Aug 23 21:49:57 2003 @@ -284,6 +284,8 @@ * set_tx_csum: Turn transmit checksums on or off * get_sg: Report whether scatter-gather is enabled * set_sg: Turn scatter-gather on or off + * get_tso: Report whether TCP segmentation offload is enabled + * set_tso: Turn TCP segmentation offload on or off * self_test: Run specified self-tests * get_strings: Return a set of strings that describe the requested objects * phys_id: Identify the device @@ -337,6 +339,8 @@ int (*set_tx_csum)(struct net_device *, u32); u32 (*get_sg)(struct net_device *); int (*set_sg)(struct net_device *, u32); + u32 (*get_tso)(struct net_device *); + int (*set_tso)(struct net_device *, u32); int (*self_test_count)(struct net_device *); void (*self_test)(struct net_device *, struct ethtool_test *, u64 *); void (*get_strings)(struct net_device *, u32 stringset, u8 *); diff -Nru a/include/linux/pci_ids.h b/include/linux/pci_ids.h --- a/include/linux/pci_ids.h Sat Aug 23 21:49:57 2003 +++ b/include/linux/pci_ids.h Sat Aug 23 21:49:57 2003 @@ -1758,11 +1758,19 @@ #define PCI_DEVICE_ID_TIGON3_5703 0x1647 #define PCI_DEVICE_ID_TIGON3_5704 0x1648 #define PCI_DEVICE_ID_TIGON3_5702FE 0x164d +#define PCI_DEVICE_ID_TIGON3_5705 0x1653 +#define PCI_DEVICE_ID_TIGON3_5705_2 0x1654 +#define PCI_DEVICE_ID_TIGON3_5705M 0x165d +#define PCI_DEVICE_ID_TIGON3_5705M_2 0x165e +#define PCI_DEVICE_ID_TIGON3_5782 0x1696 +#define PCI_DEVICE_ID_TIGON3_5788 0x169c #define PCI_DEVICE_ID_TIGON3_5702X 0x16a6 #define PCI_DEVICE_ID_TIGON3_5703X 0x16a7 #define PCI_DEVICE_ID_TIGON3_5704S 0x16a8 #define PCI_DEVICE_ID_TIGON3_5702A3 0x16c6 #define PCI_DEVICE_ID_TIGON3_5703A3 0x16c7 +#define PCI_DEVICE_ID_TIGON3_5901 0x170d +#define PCI_DEVICE_ID_TIGON3_5901_2 0x170e #define PCI_DEVICE_ID_BCM4401 0x4401 #define PCI_VENDOR_ID_SYBA 0x1592 diff -Nru a/net/core/ethtool.c b/net/core/ethtool.c --- a/net/core/ethtool.c Sat Aug 23 21:49:57 2003 +++ b/net/core/ethtool.c Sat Aug 23 21:49:57 2003 @@ -454,6 +454,33 @@ return dev->ethtool_ops->set_sg(dev, edata.data); } +static int ethtool_get_tso(struct net_device *dev, char *useraddr) +{ + struct ethtool_value edata = { ETHTOOL_GTSO }; + + if (!dev->ethtool_ops->get_tso) + return -EOPNOTSUPP; + + edata.data = dev->ethtool_ops->get_tso(dev); + + if (copy_to_user(useraddr, &edata, sizeof(edata))) + return -EFAULT; + return 0; +} + +static int ethtool_set_tso(struct net_device *dev, char *useraddr) +{ + struct ethtool_value edata; + + if (!dev->ethtool_ops->set_tso) + return -EOPNOTSUPP; + + if (copy_from_user(&edata, useraddr, sizeof(edata))) + return -EFAULT; + + return dev->ethtool_ops->set_tso(dev, edata.data); +} + static int ethtool_self_test(struct net_device *dev, char *useraddr) { struct ethtool_test test; @@ -653,6 +680,10 @@ return ethtool_get_sg(dev, useraddr); case ETHTOOL_SSG: return ethtool_set_sg(dev, useraddr); + case ETHTOOL_GTSO: + return ethtool_get_tso(dev, useraddr); + case ETHTOOL_STSO: + return ethtool_set_tso(dev, useraddr); case ETHTOOL_TEST: return ethtool_self_test(dev, useraddr); case ETHTOOL_GSTRINGS: From garzik@gtf.org Sat Aug 23 23:05:47 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 23 Aug 2003 23:06:22 -0700 (PDT) Received: from havoc.gtf.org (havoc.gtf.org [63.247.75.124]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7O656oO004522 for ; Sat, 23 Aug 2003 23:05:46 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id A7009663C; Sun, 24 Aug 2003 02:05:00 -0400 (EDT) Date: Sun, 24 Aug 2003 02:05:00 -0400 From: Jeff Garzik To: "David S. Miller" Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] Tigon3 driver update Message-ID: <20030824060500.GA28682@gtf.org> References: <20030823214939.0c012f3d.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030823214939.0c012f3d.davem@redhat.com> User-Agent: Mutt/1.3.28i X-archive-position: 5236 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 Content-Length: 621 Lines: 24 On Sat, Aug 23, 2003 at 09:49:39PM -0700, David S. Miller wrote: > > Included is a Tigon3 driver test patch against current > 2.6.0-testX kernels. > > Features: > > 1) Full 5705/5782/5788/5901 support. > 2) More reliable PHY resetting on 5703/5704/5705. > 3) Updated TSO support, it is not enabled by default > but one can turn it on using a current version of ethtool. > > Feedback welcome. Looks good, thanks. One minor: The tg3_[gs]et_tso code should be generic, like the tiny helpers at the top of net/core/ethtool.c. (well, tg3_get_tso is generic, and tg3_set_tso could call the generic helper) Jeff From devnetfs@yahoo.com Sat Aug 23 23:46:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 23 Aug 2003 23:47:25 -0700 (PDT) Received: from web20414.mail.yahoo.com (web20402.mail.yahoo.com [66.163.169.90]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7O6kDoO005599 for ; Sat, 23 Aug 2003 23:46:53 -0700 Message-ID: <20030824064612.30641.qmail@web20414.mail.yahoo.com> Received: from [143.127.3.10] by web20402.mail.yahoo.com via HTTP; Sat, 23 Aug 2003 23:46:12 PDT Date: Sat, 23 Aug 2003 23:46:12 -0700 (PDT) From: devnetfs Subject: UDP receive path: is this safe? To: netdev@oss.sgi.com, linux-net@vger.kernel.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 5237 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: devnetfs@yahoo.com Precedence: bulk X-list: netdev Content-Length: 895 Lines: 33 Hello, I've created an in-kernel udp socket and set sock->data_ready to my function foo(). inside foo() i do a skb_recv_datagram() to get (in noblock mode) the skb's received on the socket. is this safe/correct to do? as sock->data_ready() path for udp is: udp_rcv() -> udp_queue_rcv_skb() -> sock_queue_rcv_skb() -> data_ready() and skb_recv_datagram() calls skb_dequeue()... any possible races? as i think there can be multiples callers inside foo() at the same time (correct?). but then skb_dequeue() should be safe. but i am unsure of call-path from udp_rcv() to data_ready()? please enlighten. i want to avoid the overhead of converting an skb to iovec (by calling udp_recvmsg) and hence pursuing this path. thanks in advance, A. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From Robert.Olsson@data.slu.se Sun Aug 24 01:21:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Aug 2003 01:21:50 -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 h7O8KaoO008063 for ; Sun, 24 Aug 2003 01:21:17 -0700 Received: (from robert@localhost) by robur.slu.se (8.9.3p2/8.9.3) id KAA22762; Sun, 24 Aug 2003 10:20:20 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16200.30020.89263.682253@robur.slu.se> Date: Sun, 24 Aug 2003 10:20:20 +0200 To: jc Cc: netdev@oss.sgi.com, Robert.Olsson@data.slu.se Subject: NAPI poll: why not consider transmit cleanup work before exiting poll mode? In-Reply-To: <1061708224.3f4861c063706@webmail.katalix.com> References: <1061708224.3f4861c063706@webmail.katalix.com> X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 5239 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 Content-Length: 464 Lines: 20 jc writes: Hello! > Why don't NAPI drivers consider transmit completion work before doing > netif_rx_complete() and re-enabling interrupts? Well if you see benefits it's worth a test. I think some variant was tested. Did we run into problem when all interrupts disappeared? Make a patchlet for e1000 I'll give this a try in our setup. Any experimental data from your tests? > Is this breaking NAPI rules? No it shouldn't. Cheers. --ro From davem@redhat.com Sun Aug 24 03:50:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Aug 2003 03:51:26 -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 h7OAnvoO014114 for ; Sun, 24 Aug 2003 03:50:37 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id DAA06931; Sun, 24 Aug 2003 03:15:57 -0700 Date: Sun, 24 Aug 2003 03:15:57 -0700 From: "David S. Miller" To: Jeff Garzik Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] Tigon3 driver update Message-Id: <20030824031557.48574e0f.davem@redhat.com> In-Reply-To: <20030824060500.GA28682@gtf.org> References: <20030823214939.0c012f3d.davem@redhat.com> <20030824060500.GA28682@gtf.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5240 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 Content-Length: 131641 Lines: 3173 On Sun, 24 Aug 2003 02:05:00 -0400 Jeff Garzik wrote: > The tg3_[gs]et_tso code should be generic, like the tiny helpers at the > top of net/core/ethtool.c. (well, tg3_get_tso is generic, and > tg3_set_tso could call the generic helper) Sounds good, and I fixed some other bugs I discovered meanwhile. Here is the updated patch. Also, for the BK inclined the changes are also available from: bk://kernel.bkbits.net/davem/tg3-2.5 Thanks. # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1315 -> 1.1335 # drivers/net/tg3.h 1.25 -> 1.30 # net/core/ethtool.c 1.2 -> 1.4 # include/linux/ethtool.h 1.19 -> 1.21 # net/netsyms.c 1.96 -> 1.97 # include/linux/pci_ids.h 1.116 -> 1.119 # drivers/pci/pci.ids 1.50 -> 1.51 # drivers/net/tg3.c 1.82 -> 1.100 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 03/08/22 davem@nuts.ninka.net 1.1316 # [TG3]: Initial implementation of 5705 support. # -------------------------------------------- # 03/08/22 jgarzik@redhat.com 1.1317 # [TG3]: Bug fixes for 5705 support. # # - (major) status block DMA address wasn't being set, for 5705. whoops. :) # - (minor) pass 5705-specific RX_STD_MAX_SIZE # - (minor) don't program RCVBDI_JUMBO_THRESH reg on 5705 # - (very minor) re-order *THRESH, HOSTCC* regs per bcm570x driver order # -------------------------------------------- # 03/08/22 jgarzik@redhat.com 1.1318 # [TG3]: More 5705 updates. # # - do not zero stats/status block on 5705, they don't exist # (in controller memory, at least) # - define TG3_MAX_MTU macro such that it takes a (tp) pointer arg, # because the value varies between 5705 and non-5705 # - use the macro to simply tg3_change_mtu # -------------------------------------------- # 03/08/22 jgarzik@redhat.com 1.1319 # [TG3]: More 5705 fixes. # # - call set-wire-speed phy function from tg3_phy_reset, not just _phy_probe # - disable set-wire-speed usage on certain chips, per bcm5700 driver # -------------------------------------------- # 03/08/22 jgarzik@redhat.com 1.1320 # [TG3]: Another 5705 fix: enable eeprom write prot as needed. # -------------------------------------------- # 03/08/22 jgarzik@redhat.com 1.1321 # [TG3]: Only write the on-nic sram addr on non-5705. # -------------------------------------------- # 03/08/22 jgarzik@redhat.com 1.1322 # [TG3]: Add 5782 pci id. # -------------------------------------------- # 03/08/22 davem@nuts.ninka.net 1.1323 # [TG3]: Fix statistics on 5705. # -------------------------------------------- # 03/08/22 davem@nuts.ninka.net 1.1324 # [TG3]: Do not reset the RX_MAC unless PHY is Serdes. # # Bug discovered by Michael Chan @ Broadcom. # -------------------------------------------- # 03/08/22 davem@nuts.ninka.net 1.1325 # [TG3]: More missing PCI IDs. # -------------------------------------------- # 03/08/23 davem@nuts.ninka.net 1.1326 # [TG3]: Reset PHY more reliably on 570{3,4,5} chips. # -------------------------------------------- # 03/08/23 davem@nuts.ninka.net 1.1327 # [TG3]: Fix 5788/5901, update TSO code. # - Do not set RDMAC_MODE_FIFO_LONG_BURST on 5788 # - Do not set WDMAC_MODE_RX_ACCEL on 5788 # - Note that 5788 cannot use tagged irq status. # - 5788 cannot do TSO # - 5788 cannot do NETIF_F_HIGHDMA. # - 5901 is 10/100 only. # - Update TSO firmware, add 5705 specific TSO firmware. # - Update TSO packet handling in ->hard_start_xmit() to # match updated TSO firmware. # - TSO is still off by default until more perf analysis is done. # -------------------------------------------- # 03/08/23 davem@nuts.ninka.net 1.1328 # [TG3]: Differentiate between TSO capable and TSO enabled. # -------------------------------------------- # 03/08/23 davem@nuts.ninka.net 1.1329 # [ETHTOOL]: Add {G,S}TSO support to ethtool_ops. # -------------------------------------------- # 03/08/23 davem@nuts.ninka.net 1.1330 # [TG3]: Add {get,set}_tso ethtool_ops support. # # Also, include TSO support code when NETIF_F_TSO is available # but do not enable TSO by default even on capable cards. User # can turn it on via ethtool. # -------------------------------------------- # 03/08/23 davem@nuts.ninka.net 1.1331 # [TG3]: Bump version/reldate. # -------------------------------------------- # 03/08/23 davem@nuts.ninka.net 1.1332 # [TG3]: Fix tg3_phy_reset_5703_4_5 chip rev test. # -------------------------------------------- # 03/08/23 davem@nuts.ninka.net 1.1333 # [TG3]: Bump version/reldate. # -------------------------------------------- # 03/08/24 davem@nuts.ninka.net 1.1334 # [ETHTOOL]: Add ethtool_op_{set,get}_tso helpers. # -------------------------------------------- # 03/08/24 davem@nuts.ninka.net 1.1335 # [TG3]: More fixes and enhancements. # - Use ethtool_op_{get,set}_tso(). # - Avoid partial byte enables on DMA writes, this upsets several # non-x86 PCI controllers. # -------------------------------------------- # diff -Nru a/drivers/net/tg3.c b/drivers/net/tg3.c --- a/drivers/net/tg3.c Sun Aug 24 03:19:42 2003 +++ b/drivers/net/tg3.c Sun Aug 24 03:19:42 2003 @@ -2,7 +2,7 @@ * tg3.c: Broadcom Tigon3 ethernet driver. * * Copyright (C) 2001, 2002, 2003 David S. Miller (davem@redhat.com) - * Copyright (C) 2001, 2002 Jeff Garzik (jgarzik@pobox.com) + * Copyright (C) 2001, 2002, 2003 Jeff Garzik (jgarzik@pobox.com) */ #include @@ -27,6 +27,8 @@ #include #include +#include + #include #include #include @@ -45,20 +47,17 @@ #endif #ifdef NETIF_F_TSO -/* XXX Works but still disabled, decreases TCP performance to 7MB/sec even - * XXX over gigabit. - */ -#define TG3_DO_TSO 0 +#define TG3_TSO_SUPPORT 1 #else -#define TG3_DO_TSO 0 +#define TG3_TSO_SUPPORT 0 #endif #include "tg3.h" #define DRV_MODULE_NAME "tg3" #define PFX DRV_MODULE_NAME ": " -#define DRV_MODULE_VERSION "1.9" -#define DRV_MODULE_RELDATE "August 3, 2003" +#define DRV_MODULE_VERSION "2.2" +#define DRV_MODULE_RELDATE "August 24, 2003" #define TG3_DEF_MAC_MODE 0 #define TG3_DEF_RX_MODE 0 @@ -80,7 +79,8 @@ /* hardware minimum and maximum for a single frame's data payload */ #define TG3_MIN_MTU 60 -#define TG3_MAX_MTU 9000 +#define TG3_MAX_MTU(tp) \ + (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705 ? 9000 : 1500) /* These numbers seem to be hard coded in the NIC firmware somehow. * You can't change the ring sizes, but you can change where you place @@ -90,7 +90,17 @@ #define TG3_DEF_RX_RING_PENDING 200 #define TG3_RX_JUMBO_RING_SIZE 256 #define TG3_DEF_RX_JUMBO_RING_PENDING 100 -#define TG3_RX_RCB_RING_SIZE 1024 + +/* Do not place this n-ring entries value into the tp struct itself, + * we really want to expose these constants to GCC so that modulo et + * al. operations are done with shifts and masks instead of with + * hw multiply/modulo instructions. Another solution would be to + * replace things like '% foo' with '& (foo - 1)'. + */ +#define TG3_RX_RCB_RING_SIZE(tp) \ + (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705 ? \ + 512 : 1024) + #define TG3_TX_RING_SIZE 512 #define TG3_DEF_TX_RING_PENDING (TG3_TX_RING_SIZE - 1) @@ -98,8 +108,8 @@ TG3_RX_RING_SIZE) #define TG3_RX_JUMBO_RING_BYTES (sizeof(struct tg3_rx_buffer_desc) * \ TG3_RX_JUMBO_RING_SIZE) -#define TG3_RX_RCB_RING_BYTES (sizeof(struct tg3_rx_buffer_desc) * \ - TG3_RX_RCB_RING_SIZE) +#define TG3_RX_RCB_RING_BYTES(tp) (sizeof(struct tg3_rx_buffer_desc) * \ + TG3_RX_RCB_RING_SIZE(tp)) #define TG3_TX_RING_BYTES (sizeof(struct tg3_tx_buffer_desc) * \ TG3_TX_RING_SIZE) #define TX_RING_GAP(TP) \ @@ -140,6 +150,14 @@ PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5702FE, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, + { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5705, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, + { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5705_2, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, + { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5705M, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, + { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5705M_2, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5702X, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5703X, @@ -150,6 +168,14 @@ PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5703A3, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, + { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5782, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, + { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5788, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, + { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5901, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, + { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5901_2, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, { PCI_VENDOR_ID_SYSKONNECT, 0x4400, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, { PCI_VENDOR_ID_ALTIMA, PCI_DEVICE_ID_ALTIMA_AC1000, @@ -288,17 +314,28 @@ static void tg3_switch_clocks(struct tg3 *tp) { - if (tr32(TG3PCI_CLOCK_CTRL) & CLOCK_CTRL_44MHZ_CORE) { + u32 clock_ctrl = tr32(TG3PCI_CLOCK_CTRL); + u32 orig_clock_ctrl; + + orig_clock_ctrl = clock_ctrl; + clock_ctrl &= (CLOCK_CTRL_FORCE_CLKRUN | + CLOCK_CTRL_CLKRUN_OENABLE | + 0x1f); + tp->pci_clock_ctrl = clock_ctrl; + + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705 && + (orig_clock_ctrl & CLOCK_CTRL_44MHZ_CORE) != 0) { tw32(TG3PCI_CLOCK_CTRL, + clock_ctrl | (CLOCK_CTRL_44MHZ_CORE | CLOCK_CTRL_ALTCLK)); tr32(TG3PCI_CLOCK_CTRL); udelay(40); tw32(TG3PCI_CLOCK_CTRL, - (CLOCK_CTRL_ALTCLK)); + clock_ctrl | (CLOCK_CTRL_ALTCLK)); tr32(TG3PCI_CLOCK_CTRL); udelay(40); } - tw32(TG3PCI_CLOCK_CTRL, 0); + tw32(TG3PCI_CLOCK_CTRL, clock_ctrl); tr32(TG3PCI_CLOCK_CTRL); udelay(40); } @@ -401,24 +438,22 @@ return ret; } -/* This will reset the tigon3 PHY if there is no valid - * link unless the FORCE argument is non-zero. - */ -static int tg3_phy_reset(struct tg3 *tp, int force) +static void tg3_phy_set_wirespeed(struct tg3 *tp) { - u32 phy_status, phy_control; - int err, limit; + u32 val; - err = tg3_readphy(tp, MII_BMSR, &phy_status); - err |= tg3_readphy(tp, MII_BMSR, &phy_status); - if (err != 0) - return -EBUSY; + if (tp->tg3_flags2 & TG3_FLG2_NO_ETH_WIRE_SPEED) + return; - /* If we have link, and not forcing a reset, then nothing - * to do. - */ - if ((phy_status & BMSR_LSTATUS) != 0 && (force == 0)) - return 0; + tg3_writephy(tp, MII_TG3_AUX_CTRL, 0x7007); + tg3_readphy(tp, MII_TG3_AUX_CTRL, &val); + tg3_writephy(tp, MII_TG3_AUX_CTRL, (val | (1 << 15) | (1 << 4))); +} + +static int tg3_bmcr_reset(struct tg3 *tp) +{ + u32 phy_control; + int limit, err; /* OK, reset it, and poll the BMCR_RESET bit until it * clears or we time out. @@ -436,12 +471,303 @@ if ((phy_control & BMCR_RESET) == 0) { udelay(40); - return 0; + break; } udelay(10); } + if (limit <= 0) + return -EBUSY; + + return 0; +} + +static int tg3_wait_macro_done(struct tg3 *tp) +{ + int limit = 100; + + while (limit--) { + u32 tmp32; + + tg3_readphy(tp, 0x16, &tmp32); + if ((tmp32 & 0x1000) == 0) + break; + } + if (limit <= 0) + return -EBUSY; + + return 0; +} + +static int tg3_phy_write_and_check_testpat(struct tg3 *tp, int *resetp) +{ + static const u32 test_pat[4][6] = { + { 0x00005555, 0x00000005, 0x00002aaa, 0x0000000a, 0x00003456, 0x00000003 }, + { 0x00002aaa, 0x0000000a, 0x00003333, 0x00000003, 0x0000789a, 0x00000005 }, + { 0x00005a5a, 0x00000005, 0x00002a6a, 0x0000000a, 0x00001bcd, 0x00000003 }, + { 0x00002a5a, 0x0000000a, 0x000033c3, 0x00000003, 0x00002ef1, 0x00000005 } + }; + int chan; + + for (chan = 0; chan < 4; chan++) { + int i; + + tg3_writephy(tp, MII_TG3_DSP_ADDRESS, + (chan * 0x2000) | 0x0200); + tg3_writephy(tp, 0x16, 0x0002); + + for (i = 0; i < 6; i++) + tg3_writephy(tp, MII_TG3_DSP_RW_PORT, + test_pat[chan][i]); + + tg3_writephy(tp, 0x16, 0x0202); + if (tg3_wait_macro_done(tp)) { + *resetp = 1; + return -EBUSY; + } + + tg3_writephy(tp, MII_TG3_DSP_ADDRESS, + (chan * 0x2000) | 0x0200); + tg3_writephy(tp, 0x16, 0x0082); + if (tg3_wait_macro_done(tp)) { + *resetp = 1; + return -EBUSY; + } + + tg3_writephy(tp, 0x16, 0x0802); + if (tg3_wait_macro_done(tp)) { + *resetp = 1; + return -EBUSY; + } + + for (i = 0; i < 6; i += 2) { + u32 low, high; + + tg3_readphy(tp, MII_TG3_DSP_RW_PORT, &low); + tg3_readphy(tp, MII_TG3_DSP_RW_PORT, &high); + if (tg3_wait_macro_done(tp)) { + *resetp = 1; + return -EBUSY; + } + low &= 0x7fff; + high &= 0x000f; + if (low != test_pat[chan][i] || + high != test_pat[chan][i+1]) { + tg3_writephy(tp, MII_TG3_DSP_ADDRESS, 0x000b); + tg3_writephy(tp, MII_TG3_DSP_RW_PORT, 0x4001); + tg3_writephy(tp, MII_TG3_DSP_RW_PORT, 0x4005); + + return -EBUSY; + } + } + } + + return 0; +} + +static int tg3_phy_reset_chanpat(struct tg3 *tp) +{ + int chan; + + for (chan = 0; chan < 4; chan++) { + int i; + + tg3_writephy(tp, MII_TG3_DSP_ADDRESS, + (chan * 0x2000) | 0x0200); + tg3_writephy(tp, 0x16, 0x0002); + for (i = 0; i < 6; i++) + tg3_writephy(tp, MII_TG3_DSP_RW_PORT, 0x000); + tg3_writephy(tp, 0x16, 0x0202); + if (tg3_wait_macro_done(tp)) + return -EBUSY; + } - return -EBUSY; + return 0; +} + +static int tg3_phy_reset_5703_4_5(struct tg3 *tp) +{ + u32 reg32, phy9_orig; + int retries, do_phy_reset, err; + + retries = 10; + do_phy_reset = 1; + do { + if (do_phy_reset) { + err = tg3_bmcr_reset(tp); + if (err) + return err; + do_phy_reset = 0; + } + + /* Disable transmitter and interrupt. */ + tg3_readphy(tp, MII_TG3_EXT_CTRL, ®32); + reg32 |= 0x3000; + tg3_writephy(tp, MII_TG3_EXT_CTRL, reg32); + + /* Set full-duplex, 1000 mbps. */ + tg3_writephy(tp, MII_BMCR, + BMCR_FULLDPLX | TG3_BMCR_SPEED1000); + + /* Set to master mode. */ + tg3_readphy(tp, MII_TG3_CTRL, &phy9_orig); + tg3_writephy(tp, MII_TG3_CTRL, + (MII_TG3_CTRL_AS_MASTER | + MII_TG3_CTRL_ENABLE_AS_MASTER)); + + /* Enable SM_DSP_CLOCK and 6dB. */ + tg3_writephy(tp, MII_TG3_AUX_CTRL, 0x0c00); + + /* Block the PHY control access. */ + tg3_writephy(tp, MII_TG3_DSP_ADDRESS, 0x8005); + tg3_writephy(tp, MII_TG3_DSP_RW_PORT, 0x0800); + + err = tg3_phy_write_and_check_testpat(tp, &do_phy_reset); + if (!err) + break; + } while (--retries); + + err = tg3_phy_reset_chanpat(tp); + if (err) + return err; + + tg3_writephy(tp, MII_TG3_DSP_ADDRESS, 0x8005); + tg3_writephy(tp, MII_TG3_DSP_RW_PORT, 0x0000); + + tg3_writephy(tp, MII_TG3_DSP_ADDRESS, 0x8200); + tg3_writephy(tp, 0x16, 0x0000); + + tg3_writephy(tp, MII_TG3_AUX_CTRL, 0x0400); + + tg3_writephy(tp, MII_TG3_CTRL, phy9_orig); + + tg3_readphy(tp, MII_TG3_EXT_CTRL, ®32); + reg32 &= ~0x3000; + tg3_writephy(tp, MII_TG3_EXT_CTRL, reg32); + + return err; +} + +/* This will reset the tigon3 PHY if there is no valid + * link unless the FORCE argument is non-zero. + */ +static int tg3_phy_reset(struct tg3 *tp, int force) +{ + u32 phy_status; + int err; + + err = tg3_readphy(tp, MII_BMSR, &phy_status); + err |= tg3_readphy(tp, MII_BMSR, &phy_status); + if (err != 0) + return -EBUSY; + + /* If we have link, and not forcing a reset, then nothing + * to do. + */ + if ((phy_status & BMSR_LSTATUS) != 0 && (force == 0)) + return 0; + + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5703 || + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5704 || + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) { + err = tg3_phy_reset_5703_4_5(tp); + if (err) + return err; + goto out; + } + + err = tg3_bmcr_reset(tp); + if (err) + return err; + +out: + tg3_phy_set_wirespeed(tp); + return 0; +} + +static void tg3_frob_aux_power(struct tg3 *tp) +{ + struct tg3 *tp_peer = tp; + + if ((tp->tg3_flags & TG3_FLAG_EEPROM_WRITE_PROT) != 0) + return; + + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5704) { + tp_peer = pci_get_drvdata(tp->pdev_peer); + if (!tp_peer) + BUG(); + } + + + if ((tp->tg3_flags & TG3_FLAG_WOL_ENABLE) != 0 || + (tp_peer->tg3_flags & TG3_FLAG_WOL_ENABLE) != 0) { + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700 || + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701) { + tw32(GRC_LOCAL_CTRL, tp->grc_local_ctrl | + (GRC_LCLCTRL_GPIO_OE0 | + GRC_LCLCTRL_GPIO_OE1 | + GRC_LCLCTRL_GPIO_OE2 | + GRC_LCLCTRL_GPIO_OUTPUT0 | + GRC_LCLCTRL_GPIO_OUTPUT1)); + tr32(GRC_LOCAL_CTRL); + udelay(100); + } else { + if (tp_peer != tp && + (tp_peer->tg3_flags & TG3_FLAG_INIT_COMPLETE) != 0) + return; + + tw32(GRC_LOCAL_CTRL, tp->grc_local_ctrl | + (GRC_LCLCTRL_GPIO_OE0 | + GRC_LCLCTRL_GPIO_OE1 | + GRC_LCLCTRL_GPIO_OE2 | + GRC_LCLCTRL_GPIO_OUTPUT1 | + GRC_LCLCTRL_GPIO_OUTPUT2)); + tr32(GRC_LOCAL_CTRL); + udelay(100); + + tw32(GRC_LOCAL_CTRL, tp->grc_local_ctrl | + (GRC_LCLCTRL_GPIO_OE0 | + GRC_LCLCTRL_GPIO_OE1 | + GRC_LCLCTRL_GPIO_OE2 | + GRC_LCLCTRL_GPIO_OUTPUT0 | + GRC_LCLCTRL_GPIO_OUTPUT1 | + GRC_LCLCTRL_GPIO_OUTPUT2)); + tr32(GRC_LOCAL_CTRL); + udelay(100); + + tw32(GRC_LOCAL_CTRL, tp->grc_local_ctrl | + (GRC_LCLCTRL_GPIO_OE0 | + GRC_LCLCTRL_GPIO_OE1 | + GRC_LCLCTRL_GPIO_OE2 | + GRC_LCLCTRL_GPIO_OUTPUT0 | + GRC_LCLCTRL_GPIO_OUTPUT1)); + tr32(GRC_LOCAL_CTRL); + udelay(100); + } + } else { + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5700 && + GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5701) { + if (tp_peer != tp && + (tp_peer->tg3_flags & TG3_FLAG_INIT_COMPLETE) != 0) + return; + + tw32(GRC_LOCAL_CTRL, tp->grc_local_ctrl | + (GRC_LCLCTRL_GPIO_OE1 | + GRC_LCLCTRL_GPIO_OUTPUT1)); + tr32(GRC_LOCAL_CTRL); + udelay(100); + + tw32(GRC_LOCAL_CTRL, tp->grc_local_ctrl | + (GRC_LCLCTRL_GPIO_OE1)); + tr32(GRC_LOCAL_CTRL); + udelay(100); + + tw32(GRC_LOCAL_CTRL, tp->grc_local_ctrl | + (GRC_LCLCTRL_GPIO_OE1 | + GRC_LCLCTRL_GPIO_OUTPUT1)); + tr32(GRC_LOCAL_CTRL); + udelay(100); + } + } } static int tg3_setup_phy(struct tg3 *); @@ -547,89 +873,65 @@ udelay(10); } - if (tp->tg3_flags & TG3_FLAG_WOL_SPEED_100MB) { + if (!(tp->tg3_flags & TG3_FLAG_WOL_SPEED_100MB) && + (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700 || + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701)) { u32 base_val; - base_val = 0; - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700 || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701) - base_val |= (CLOCK_CTRL_RXCLK_DISABLE | - CLOCK_CTRL_TXCLK_DISABLE); - - tw32(TG3PCI_CLOCK_CTRL, base_val | - CLOCK_CTRL_ALTCLK); - tr32(TG3PCI_CLOCK_CTRL); - udelay(40); + base_val = tp->pci_clock_ctrl; + base_val |= (CLOCK_CTRL_RXCLK_DISABLE | + CLOCK_CTRL_TXCLK_DISABLE); tw32(TG3PCI_CLOCK_CTRL, base_val | CLOCK_CTRL_ALTCLK | - CLOCK_CTRL_44MHZ_CORE); - tr32(TG3PCI_CLOCK_CTRL); - udelay(40); - - tw32(TG3PCI_CLOCK_CTRL, base_val | - CLOCK_CTRL_44MHZ_CORE); + CLOCK_CTRL_PWRDOWN_PLL133); tr32(TG3PCI_CLOCK_CTRL); udelay(40); } else { - u32 base_val; + u32 newbits1, newbits2; - base_val = 0; if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700 || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701) - base_val |= (CLOCK_CTRL_RXCLK_DISABLE | - CLOCK_CTRL_TXCLK_DISABLE); + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701) { + newbits1 = (CLOCK_CTRL_RXCLK_DISABLE | + CLOCK_CTRL_TXCLK_DISABLE | + CLOCK_CTRL_ALTCLK); + newbits2 = newbits1 | CLOCK_CTRL_44MHZ_CORE; + } else if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) { + newbits1 = CLOCK_CTRL_625_CORE; + newbits2 = newbits1 | CLOCK_CTRL_ALTCLK; + } else { + newbits1 = CLOCK_CTRL_ALTCLK; + newbits2 = newbits1 | CLOCK_CTRL_44MHZ_CORE; + } - tw32(TG3PCI_CLOCK_CTRL, base_val | - CLOCK_CTRL_ALTCLK | - CLOCK_CTRL_PWRDOWN_PLL133); + tw32(TG3PCI_CLOCK_CTRL, tp->pci_clock_ctrl | newbits1); tr32(TG3PCI_CLOCK_CTRL); udelay(40); - } - if (!(tp->tg3_flags & TG3_FLAG_EEPROM_WRITE_PROT) && - (tp->tg3_flags & TG3_FLAG_WOL_ENABLE)) { - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700 || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701) { - tw32(GRC_LOCAL_CTRL, - (GRC_LCLCTRL_GPIO_OE0 | - GRC_LCLCTRL_GPIO_OE1 | - GRC_LCLCTRL_GPIO_OE2 | - GRC_LCLCTRL_GPIO_OUTPUT0 | - GRC_LCLCTRL_GPIO_OUTPUT1)); - tr32(GRC_LOCAL_CTRL); - udelay(100); - } else { - tw32(GRC_LOCAL_CTRL, - (GRC_LCLCTRL_GPIO_OE0 | - GRC_LCLCTRL_GPIO_OE1 | - GRC_LCLCTRL_GPIO_OE2 | - GRC_LCLCTRL_GPIO_OUTPUT1 | - GRC_LCLCTRL_GPIO_OUTPUT2)); - tr32(GRC_LOCAL_CTRL); - udelay(100); + tw32(TG3PCI_CLOCK_CTRL, tp->pci_clock_ctrl | newbits2); + tr32(TG3PCI_CLOCK_CTRL); + udelay(40); - tw32(GRC_LOCAL_CTRL, - (GRC_LCLCTRL_GPIO_OE0 | - GRC_LCLCTRL_GPIO_OE1 | - GRC_LCLCTRL_GPIO_OE2 | - GRC_LCLCTRL_GPIO_OUTPUT0 | - GRC_LCLCTRL_GPIO_OUTPUT1 | - GRC_LCLCTRL_GPIO_OUTPUT2)); - tr32(GRC_LOCAL_CTRL); - udelay(100); + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705) { + u32 newbits3; - tw32(GRC_LOCAL_CTRL, - (GRC_LCLCTRL_GPIO_OE0 | - GRC_LCLCTRL_GPIO_OE1 | - GRC_LCLCTRL_GPIO_OE2 | - GRC_LCLCTRL_GPIO_OUTPUT0 | - GRC_LCLCTRL_GPIO_OUTPUT1)); - tr32(GRC_LOCAL_CTRL); - udelay(100); + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700 || + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701) { + newbits3 = (CLOCK_CTRL_RXCLK_DISABLE | + CLOCK_CTRL_TXCLK_DISABLE | + CLOCK_CTRL_44MHZ_CORE); + } else { + newbits3 = CLOCK_CTRL_44MHZ_CORE; + } + + tw32(TG3PCI_CLOCK_CTRL, tp->pci_clock_ctrl | newbits3); + tr32(TG3PCI_CLOCK_CTRL); + udelay(40); } } + tg3_frob_aux_power(tp); + /* Finally, set the new power state. */ pci_write_config_word(tp->pdev, pm + PCI_PM_CTRL, power_control); @@ -948,11 +1250,10 @@ /* Some third-party PHYs need to be reset on link going * down. - * - * XXX 5705 note: This workaround also applies to 5705_a0 */ if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5703 || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5704) && + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5704 || + tp->pci_chip_rev_id == CHIPREV_ID_5705_A0) && netif_carrier_ok(tp->dev)) { tg3_readphy(tp, MII_BMSR, &bmsr); tg3_readphy(tp, MII_BMSR, &bmsr); @@ -1942,7 +2243,7 @@ int received; hw_idx = tp->hw_status->idx[0].rx_producer; - sw_idx = rx_rcb_ptr % TG3_RX_RCB_RING_SIZE; + sw_idx = rx_rcb_ptr % TG3_RX_RCB_RING_SIZE(tp); work_mask = 0; received = 0; while (sw_idx != hw_idx && budget > 0) { @@ -2043,13 +2344,13 @@ (*post_ptr)++; next_pkt_nopost: rx_rcb_ptr++; - sw_idx = rx_rcb_ptr % TG3_RX_RCB_RING_SIZE; + sw_idx = rx_rcb_ptr % TG3_RX_RCB_RING_SIZE(tp); } /* ACK the status ring. */ tp->rx_rcb_ptr = rx_rcb_ptr; tw32_mailbox(MAILBOX_RCVRET_CON_IDX_0 + TG3_64BIT_REG_LOW, - (rx_rcb_ptr % TG3_RX_RCB_RING_SIZE)); + (rx_rcb_ptr % TG3_RX_RCB_RING_SIZE(tp))); if (tp->tg3_flags & TG3_FLAG_MBOX_WRITE_REORDER) tr32(MAILBOX_RCVRET_CON_IDX_0 + TG3_64BIT_REG_LOW); @@ -2388,19 +2689,34 @@ base_flags = 0; if (skb->ip_summed == CHECKSUM_HW) base_flags |= TXD_FLAG_TCPUDP_CSUM; -#if TG3_DO_TSO != 0 - if ((mss = skb_shinfo(skb)->tso_size) != 0) { - static int times = 0; +#if TG3_TSO_SUPPORT != 0 + mss = 0; + if (skb->len > (tp->dev->mtu + ETH_HLEN) && + (mss = skb_shinfo(skb)->tso_size) != 0) { + int tcp_opt_len, ip_tcp_len; + + tcp_opt_len = ((skb->h.th->doff - 5) * 4); + ip_tcp_len = (skb->nh.iph->ihl * 4) + sizeof(struct tcphdr); - mss += ((skb->h.th->doff * 4) - 20); base_flags |= (TXD_FLAG_CPU_PRE_DMA | TXD_FLAG_CPU_POST_DMA); - if (times++ < 5) { - printk("tg3_xmit: tso_size[%u] tso_segs[%u] len[%u]\n", - (unsigned int) skb_shinfo(skb)->tso_size, - (unsigned int) skb_shinfo(skb)->tso_segs, - skb->len); + skb->nh.iph->check = 0; + skb->nh.iph->tot_len = ntohs(mss + ip_tcp_len + tcp_opt_len); + skb->h.th->check = ~csum_tcpudp_magic(skb->nh.iph->saddr, + skb->nh.iph->daddr, + 0, IPPROTO_TCP, 0); + + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) { + if (tcp_opt_len || skb->nh.iph->ihl > 5) { + int tsflags; + + tsflags = ((skb->nh.iph->ihl - 5) + + (tcp_opt_len >> 2)); + mss |= (tsflags << 11); + } + } else { + mss += tcp_opt_len; } } #else @@ -2580,23 +2896,34 @@ base_flags = 0; if (skb->ip_summed == CHECKSUM_HW) base_flags |= TXD_FLAG_TCPUDP_CSUM; -#if TG3_DO_TSO != 0 - if ((mss = skb_shinfo(skb)->tso_size) != 0) { - static int times = 0; +#if TG3_TSO_SUPPORT != 0 + mss = 0; + if (skb->len > (tp->dev->mtu + ETH_HLEN) && + (mss = skb_shinfo(skb)->tso_size) != 0) { + int tcp_opt_len, ip_tcp_len; - /* TSO firmware wants TCP options included in - * tx descriptor MSS value. - */ - mss += ((skb->h.th->doff * 4) - 20); + tcp_opt_len = ((skb->h.th->doff - 5) * 4); + ip_tcp_len = (skb->nh.iph->ihl * 4) + sizeof(struct tcphdr); base_flags |= (TXD_FLAG_CPU_PRE_DMA | TXD_FLAG_CPU_POST_DMA); - if (times++ < 5) { - printk("tg3_xmit: tso_size[%u] tso_segs[%u] len[%u]\n", - (unsigned int) skb_shinfo(skb)->tso_size, - (unsigned int) skb_shinfo(skb)->tso_segs, - skb->len); + skb->nh.iph->check = 0; + skb->nh.iph->tot_len = ntohs(mss + ip_tcp_len + tcp_opt_len); + skb->h.th->check = ~csum_tcpudp_magic(skb->nh.iph->saddr, + skb->nh.iph->daddr, + 0, IPPROTO_TCP, 0); + + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) { + if (tcp_opt_len || skb->nh.iph->ihl > 5) { + int tsflags; + + tsflags = ((skb->nh.iph->ihl - 5) + + (tcp_opt_len >> 2)); + mss |= (tsflags << 11); + } + } else { + mss += tcp_opt_len; } } #else @@ -2698,7 +3025,7 @@ { struct tg3 *tp = dev->priv; - if (new_mtu < TG3_MIN_MTU || new_mtu > TG3_MAX_MTU) + if (new_mtu < TG3_MIN_MTU || new_mtu > TG3_MAX_MTU(tp)) return -EINVAL; if (!netif_running(dev)) { @@ -2816,7 +3143,7 @@ /* Zero out all descriptors. */ memset(tp->rx_std, 0, TG3_RX_RING_BYTES); memset(tp->rx_jumbo, 0, TG3_RX_JUMBO_RING_BYTES); - memset(tp->rx_rcb, 0, TG3_RX_RCB_RING_BYTES); + memset(tp->rx_rcb, 0, TG3_RX_RCB_RING_BYTES(tp)); if (tp->tg3_flags & TG3_FLAG_HOST_TXDS) { memset(tp->tx_ring, 0, TG3_TX_RING_BYTES); @@ -2899,7 +3226,7 @@ tp->rx_jumbo = NULL; } if (tp->rx_rcb) { - pci_free_consistent(tp->pdev, TG3_RX_RCB_RING_BYTES, + pci_free_consistent(tp->pdev, TG3_RX_RCB_RING_BYTES(tp), tp->rx_rcb, tp->rx_rcb_mapping); tp->rx_rcb = NULL; } @@ -2957,7 +3284,7 @@ if (!tp->rx_jumbo) goto err_out; - tp->rx_rcb = pci_alloc_consistent(tp->pdev, TG3_RX_RCB_RING_BYTES, + tp->rx_rcb = pci_alloc_consistent(tp->pdev, TG3_RX_RCB_RING_BYTES(tp), &tp->rx_rcb_mapping); if (!tp->rx_rcb) goto err_out; @@ -3004,6 +3331,23 @@ unsigned int i; u32 val; + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) { + switch (ofs) { + case RCVLSC_MODE: + case DMAC_MODE: + case MBFREE_MODE: + case BUFMGR_MODE: + case MEMARB_MODE: + /* We can't enable/disable these bits of the + * 5705, just say success. + */ + return 0; + + default: + break; + }; + } + val = tr32(ofs); val &= ~enable_bit; tw32(ofs, val); @@ -3127,7 +3471,10 @@ tp->tg3_flags &= ~TG3_FLAG_5701_REG_WRITE_BUG; /* do the reset */ - tw32(GRC_MISC_CFG, GRC_MISC_CFG_CORECLK_RESET); + val = GRC_MISC_CFG_CORECLK_RESET; + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) + val |= GRC_MISC_CFG_KEEP_GPHY_POWER; + tw32(GRC_MISC_CFG, val); /* restore 5701 hardware bug workaround flag */ tp->tg3_flags = flags_save; @@ -3163,6 +3510,13 @@ tw32(MEMARB_MODE, MEMARB_MODE_ENABLE); + if ((tp->nic_sram_data_cfg & NIC_SRAM_DATA_CFG_MINI_PCI) != 0 && + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) { + tp->pci_clock_ctrl |= + (CLOCK_CTRL_FORCE_CLKRUN | CLOCK_CTRL_CLKRUN_OENABLE); + tw32(TG3PCI_CLOCK_CTRL, tp->pci_clock_ctrl); + } + tw32(TG3PCI_MISC_HOST_CTRL, tp->misc_host_ctrl); } @@ -3358,28 +3712,32 @@ #define TX_CPU_SCRATCH_SIZE 0x04000 /* tp->lock is held. */ -static int tg3_reset_cpu(struct tg3 *tp, u32 offset) +static int tg3_halt_cpu(struct tg3 *tp, u32 offset) { int i; - tw32(offset + CPU_STATE, 0xffffffff); - tw32(offset + CPU_MODE, CPU_MODE_RESET); + if (offset == TX_CPU_BASE && + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) + BUG(); + if (offset == RX_CPU_BASE) { - for (i = 0; i < 10000; i++) - if (!(tr32(offset + CPU_MODE) & CPU_MODE_RESET)) + for (i = 0; i < 10000; i++) { + tw32(offset + CPU_STATE, 0xffffffff); + tw32(offset + CPU_MODE, CPU_MODE_HALT); + if (tr32(offset + CPU_MODE) & CPU_MODE_HALT) break; + } + tw32(offset + CPU_STATE, 0xffffffff); - tw32(offset + CPU_MODE, CPU_MODE_RESET); + tw32(offset + CPU_MODE, CPU_MODE_HALT); tr32(offset + CPU_MODE); udelay(10); } else { for (i = 0; i < 10000; i++) { - if (!(tr32(offset + CPU_MODE) & CPU_MODE_RESET)) - break; tw32(offset + CPU_STATE, 0xffffffff); - tw32(offset + CPU_MODE, CPU_MODE_RESET); - tr32(offset + CPU_MODE); - udelay(10); + tw32(offset + CPU_MODE, CPU_MODE_HALT); + if (tr32(offset + CPU_MODE) & CPU_MODE_HALT) + break; } } @@ -3411,38 +3769,52 @@ { int err, i; u32 orig_tg3_flags = tp->tg3_flags; + void (*write_op)(struct tg3 *, u32, u32); + + if (cpu_base == TX_CPU_BASE && + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) { + printk(KERN_ERR PFX "tg3_load_firmware_cpu: Trying to load " + "TX cpu firmware on %s which is 5705.\n", + tp->dev->name); + return -EINVAL; + } + + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) + write_op = tg3_write_mem; + else + write_op = tg3_write_indirect_reg32; /* Force use of PCI config space for indirect register * write calls. */ tp->tg3_flags |= TG3_FLAG_PCIX_TARGET_HWBUG; - err = tg3_reset_cpu(tp, cpu_base); + err = tg3_halt_cpu(tp, cpu_base); if (err) goto out; for (i = 0; i < cpu_scratch_size; i += sizeof(u32)) - tg3_write_indirect_reg32(tp, cpu_scratch_base + i, 0); + write_op(tp, cpu_scratch_base + i, 0); tw32(cpu_base + CPU_STATE, 0xffffffff); tw32(cpu_base + CPU_MODE, tr32(cpu_base+CPU_MODE)|CPU_MODE_HALT); for (i = 0; i < (info->text_len / sizeof(u32)); i++) - tg3_write_indirect_reg32(tp, (cpu_scratch_base + - (info->text_base & 0xffff) + - (i * sizeof(u32))), - (info->text_data ? - info->text_data[i] : 0)); + write_op(tp, (cpu_scratch_base + + (info->text_base & 0xffff) + + (i * sizeof(u32))), + (info->text_data ? + info->text_data[i] : 0)); for (i = 0; i < (info->rodata_len / sizeof(u32)); i++) - tg3_write_indirect_reg32(tp, (cpu_scratch_base + - (info->rodata_base & 0xffff) + - (i * sizeof(u32))), - (info->rodata_data ? - info->rodata_data[i] : 0)); + write_op(tp, (cpu_scratch_base + + (info->rodata_base & 0xffff) + + (i * sizeof(u32))), + (info->rodata_data ? + info->rodata_data[i] : 0)); for (i = 0; i < (info->data_len / sizeof(u32)); i++) - tg3_write_indirect_reg32(tp, (cpu_scratch_base + - (info->data_base & 0xffff) + - (i * sizeof(u32))), - (info->data_data ? - info->data_data[i] : 0)); + write_op(tp, (cpu_scratch_base + + (info->data_base & 0xffff) + + (i * sizeof(u32))), + (info->data_data ? + info->data_data[i] : 0)); err = 0; @@ -3513,269 +3885,318 @@ return 0; } -#if TG3_DO_TSO != 0 +#if TG3_TSO_SUPPORT != 0 #define TG3_TSO_FW_RELEASE_MAJOR 0x1 -#define TG3_TSO_FW_RELASE_MINOR 0x8 +#define TG3_TSO_FW_RELASE_MINOR 0x3 #define TG3_TSO_FW_RELEASE_FIX 0x0 #define TG3_TSO_FW_START_ADDR 0x08000000 #define TG3_TSO_FW_TEXT_ADDR 0x08000000 -#define TG3_TSO_FW_TEXT_LEN 0x1650 +#define TG3_TSO_FW_TEXT_LEN 0x1ac0 #define TG3_TSO_FW_RODATA_ADDR 0x08001650 -#define TG3_TSO_FW_RODATA_LEN 0x30 +#define TG3_TSO_FW_RODATA_LEN 0x60 #define TG3_TSO_FW_DATA_ADDR 0x080016a0 #define TG3_TSO_FW_DATA_LEN 0x20 #define TG3_TSO_FW_SBSS_ADDR 0x080016c0 -#define TG3_TSO_FW_SBSS_LEN 0x14 +#define TG3_TSO_FW_SBSS_LEN 0x2c #define TG3_TSO_FW_BSS_ADDR 0x080016e0 -#define TG3_TSO_FW_BSS_LEN 0x8fc +#define TG3_TSO_FW_BSS_LEN 0x890 static u32 tg3TsoFwText[] = { 0x00000000, 0x10000003, 0x00000000, 0x0000000d, 0x0000000d, 0x3c1d0800, 0x37bd4000, 0x03a0f021, 0x3c100800, 0x26100000, 0x0e000010, 0x00000000, - 0x0000000d, 0x00000000, 0x00000000, 0x00000000, 0x27bdffe0, 0x3c1bc000, - 0xafbf0018, 0x0e000058, 0xaf60680c, 0x3c040800, 0x24841650, 0x03602821, - 0x24060001, 0x24070004, 0xafa00010, 0x0e00006c, 0xafa00014, 0x8f625c50, - 0x34420001, 0xaf625c50, 0x8f625c90, 0x34420001, 0xaf625c90, 0x2402ffff, - 0x0e000098, 0xaf625404, 0x8fbf0018, 0x03e00008, 0x27bd0020, 0x00000000, - 0x00000000, 0x00000000, 0x24030b60, 0x24050fff, 0xac000b50, 0x00002021, - 0xac640000, 0x24630004, 0x0065102b, 0x1440fffc, 0x24840001, 0x24030b60, - 0x0065102b, 0x10400011, 0x00002021, 0x24090b54, 0x3c06dead, 0x34c6beef, - 0x24080b58, 0x24070b5c, 0x8c620000, 0x50440006, 0x24630004, 0xad260000, - 0x8c620000, 0xace40000, 0xad020000, 0x24630004, 0x0065102b, 0x1440fff6, - 0x24840001, 0x03e00008, 0x00000000, 0x27bdfff8, 0x18800009, 0x00002821, - 0x8f63680c, 0x8f62680c, 0x1043fffe, 0x00000000, 0x24a50001, 0x00a4102a, - 0x1440fff9, 0x00000000, 0x03e00008, 0x27bd0008, 0x3c020800, 0x34423000, - 0x3c030800, 0x34633000, 0x3c040800, 0x348437ff, 0x3c010800, 0xac2216c4, - 0x24020040, 0x3c010800, 0xac2216c8, 0x3c010800, 0xac2016c0, 0xac600000, - 0x24630004, 0x0083102b, 0x5040fffd, 0xac600000, 0x03e00008, 0x00000000, - 0x00804821, 0x8faa0010, 0x3c020800, 0x8c4216c0, 0x3c040800, 0x8c8416c8, - 0x8fab0014, 0x24430001, 0x0044102b, 0x3c010800, 0xac2316c0, 0x14400003, - 0x00004021, 0x3c010800, 0xac2016c0, 0x3c020800, 0x8c4216c0, 0x3c030800, - 0x8c6316c4, 0x91240000, 0x00021140, 0x00431021, 0x00481021, 0x25080001, - 0xa0440000, 0x29020008, 0x1440fff4, 0x25290001, 0x3c020800, 0x8c4216c0, - 0x3c030800, 0x8c6316c4, 0x8f64680c, 0x00021140, 0x00431021, 0xac440008, - 0xac45000c, 0xac460010, 0xac470014, 0xac4a0018, 0x03e00008, 0xac4b001c, - 0x00000000, 0x00000000, 0x27bdffe0, 0xafbf0018, 0xafb10014, 0x0e0000b6, - 0xafb00010, 0x24110001, 0x8f706820, 0x32020100, 0x10400003, 0x00000000, - 0x0e000127, 0x00000000, 0x8f706820, 0x32022000, 0x10400004, 0x32020001, - 0x0e00025a, 0x24040001, 0x32020001, 0x10400003, 0x00000000, 0x0e0000e6, - 0x00000000, 0x0a00009e, 0xaf715028, 0x8fbf0018, 0x8fb10014, 0x8fb00010, - 0x03e00008, 0x27bd0020, 0x27bdffe0, 0x3c040800, 0x24841660, 0x00002821, - 0x00003021, 0x00003821, 0xafbf0018, 0xafa00010, 0x0e00006c, 0xafa00014, - 0x3c010800, 0xa4201fb8, 0x3c010800, 0xa02016f8, 0x3c010800, 0xac2016fc, - 0x3c010800, 0xac201700, 0x3c010800, 0xac201704, 0x3c010800, 0xac20170c, - 0x3c010800, 0xac201718, 0x3c010800, 0xac20171c, 0x8f624434, 0x3c010800, - 0xac2216e8, 0x8f624438, 0x3c010800, 0xac2216ec, 0x8f624410, 0x3c010800, - 0xac2016e0, 0x3c010800, 0xac2016e4, 0x3c010800, 0xac201fc0, 0x3c010800, - 0xac201f68, 0x3c010800, 0xac201f6c, 0x3c010800, 0xac2216f0, 0x8fbf0018, - 0x03e00008, 0x27bd0020, 0x27bdffe0, 0x3c040800, 0x2484166c, 0x00002821, - 0x00003021, 0x00003821, 0xafbf0018, 0xafa00010, 0x0e00006c, 0xafa00014, - 0x3c040800, 0x24841660, 0x00002821, 0x00003021, 0x00003821, 0xafa00010, - 0x0e00006c, 0xafa00014, 0x3c010800, 0xa4201fb8, 0x3c010800, 0xa02016f8, - 0x3c010800, 0xac2016fc, 0x3c010800, 0xac201700, 0x3c010800, 0xac201704, - 0x3c010800, 0xac20170c, 0x3c010800, 0xac201718, 0x3c010800, 0xac20171c, - 0x8f624434, 0x3c010800, 0xac2216e8, 0x8f624438, 0x3c010800, 0xac2216ec, - 0x8f624410, 0x3c010800, 0xac2016e0, 0x3c010800, 0xac2016e4, 0x3c010800, - 0xac201fc0, 0x3c010800, 0xac201f68, 0x3c010800, 0xac201f6c, 0x3c010800, - 0xac2216f0, 0x0e000120, 0x00002021, 0x8fbf0018, 0x03e00008, 0x27bd0020, - 0x24020001, 0x8f636820, 0x00821004, 0x00021027, 0x00621824, 0x03e00008, - 0xaf636820, 0x27bdffd0, 0x3c0300ff, 0xafbf002c, 0xafb60028, 0xafb50024, - 0xafb40020, 0xafb3001c, 0xafb20018, 0xafb10014, 0xafb00010, 0x8f665c5c, - 0x3c040800, 0x2484171c, 0x8c820000, 0x3463fff8, 0x14460005, 0x00c38824, - 0x3c020800, 0x904216f8, 0x14400115, 0x00000000, 0x00111902, 0x306300ff, - 0x30c20003, 0x000211c0, 0x00623825, 0x00e02821, 0x00061602, 0xac860000, - 0x3c030800, 0x906316f8, 0x3044000f, 0x1460002b, 0x00804021, 0x24020001, - 0x3c010800, 0xa02216f8, 0x00071100, 0x00821025, 0x3c010800, 0xac2016fc, - 0x3c010800, 0xac201700, 0x3c010800, 0xac201704, 0x3c010800, 0xac20170c, - 0x3c010800, 0xac201718, 0x3c010800, 0xac201710, 0x3c010800, 0xac201714, - 0x3c010800, 0xa4221fb8, 0x9623000c, 0x30628000, 0x10400008, 0x30627fff, - 0x2442003e, 0x3c010800, 0xa42216f6, 0x24020001, 0x3c010800, 0x0a00016e, - 0xac221fd4, 0x24620036, 0x3c010800, 0xa42216f6, 0x3c010800, 0xac201fd4, - 0x3c010800, 0xac201fd0, 0x3c010800, 0x0a000176, 0xac201fd8, 0x9622000c, - 0x3c010800, 0xa4221fcc, 0x3c040800, 0x248416fc, 0x8c820000, 0x00021100, - 0x3c010800, 0x00220821, 0xac311728, 0x8c820000, 0x00021100, 0x3c010800, - 0x00220821, 0xac26172c, 0x8c820000, 0x24a30001, 0x306701ff, 0x00021100, - 0x3c010800, 0x00220821, 0xac271730, 0x8c820000, 0x00021100, 0x3c010800, - 0x00220821, 0xac281734, 0x96230008, 0x3c020800, 0x8c42170c, 0x00432821, - 0x3c010800, 0xac25170c, 0x9622000a, 0x30420004, 0x14400019, 0x00071100, - 0x3c02c000, 0x00c21825, 0xaf635c5c, 0x8f625c50, 0x30420002, 0x1440fffc, - 0x00000000, 0x8f630c14, 0x3063000f, 0x2c620002, 0x1440001e, 0x00000000, - 0x8f630c14, 0x3c020800, 0x8c4216b4, 0x3063000f, 0x24420001, 0x3c010800, - 0xac2216b4, 0x2c620002, 0x1040fff7, 0x00000000, 0x0a0001c1, 0x00000000, - 0x3c030800, 0x8c6316e0, 0x3c040800, 0x948416f4, 0x01021025, 0x3c010800, - 0xa4221fba, 0x24020001, 0x3c010800, 0xac221718, 0x24630001, 0x0085202a, - 0x3c010800, 0x10800003, 0xac2316e0, 0x3c010800, 0xa42516f4, 0x3c030800, - 0x246316fc, 0x8c620000, 0x24420001, 0xac620000, 0x28420080, 0x14400005, - 0x24020001, 0x0e0002df, 0x24040002, 0x0a000250, 0x00000000, 0x3c030800, - 0x906316f8, 0x1462007c, 0x24020003, 0x3c160800, 0x96d616f6, 0x3c050800, - 0x8ca5170c, 0x32c4ffff, 0x00a4102a, 0x14400078, 0x00000000, 0x3c020800, - 0x8c421718, 0x10400005, 0x32c2ffff, 0x14a40003, 0x00000000, 0x3c010800, - 0xac231fd0, 0x10400062, 0x00009021, 0x0040a021, 0x3c150800, 0x26b51700, - 0x26b30010, 0x8ea20000, 0x00028100, 0x3c110800, 0x02308821, 0x0e0002e1, - 0x8e311728, 0x00403021, 0x10c00059, 0x00000000, 0x9628000a, 0x31020040, - 0x10400004, 0x2407180c, 0x8e22000c, 0x2407188c, 0xacc20018, 0x31021000, - 0x10400004, 0x34e32000, 0x00081040, 0x3042c000, 0x00623825, 0x3c030800, - 0x00701821, 0x8c631730, 0x3c020800, 0x00501021, 0x8c421734, 0x00031d00, - 0x00021400, 0x00621825, 0xacc30014, 0x8ea30004, 0x96220008, 0x00432023, - 0x3242ffff, 0x3083ffff, 0x00431021, 0x0282102a, 0x14400002, 0x02d22823, - 0x00802821, 0x8e620000, 0x30a4ffff, 0x00441021, 0xae620000, 0x8e220000, - 0xacc20000, 0x8e220004, 0x8e63fff4, 0x00431021, 0xacc20004, 0xa4c5000e, - 0x8e62fff4, 0x00441021, 0xae62fff4, 0x96230008, 0x0043102a, 0x14400005, - 0x02459021, 0x8e62fff0, 0xae60fff4, 0x24420001, 0xae62fff0, 0xacc00008, - 0x3242ffff, 0x14540008, 0x24020305, 0x31020080, 0x54400001, 0x34e70010, - 0x24020905, 0xa4c2000c, 0x0a000233, 0x34e70020, 0xa4c2000c, 0x30e2ffff, - 0xacc20010, 0x3c020800, 0x8c421fd0, 0x10400003, 0x3c024b65, 0x0a00023d, - 0x34427654, 0x3c02b49a, 0x344289ab, 0xacc2001c, 0x0e000560, 0x00c02021, - 0x3242ffff, 0x0054102b, 0x1440ffa4, 0x00000000, 0x24020002, 0x3c010800, - 0x0a000250, 0xa02216f8, 0x8ea208bc, 0x24420001, 0x0a000250, 0xaea208bc, - 0x14620003, 0x00000000, 0x0e000450, 0x00000000, 0x8fbf002c, 0x8fb60028, - 0x8fb50024, 0x8fb40020, 0x8fb3001c, 0x8fb20018, 0x8fb10014, 0x8fb00010, - 0x03e00008, 0x27bd0030, 0x27bdffd8, 0xafb3001c, 0x00809821, 0xafbf0020, - 0xafb20018, 0xafb10014, 0xafb00010, 0x8f725c9c, 0x3c0200ff, 0x3442fff8, - 0x3c040800, 0x24841714, 0x02428824, 0x9623000e, 0x8c820000, 0x00431021, - 0xac820000, 0x8e220010, 0x30420020, 0x14400011, 0x00000000, 0x0e0002f7, + 0x0000000d, 0x00000000, 0x00000000, 0x00000000, 0x27bdffe0, 0x3c04fefe, + 0xafbf0018, 0x0e0005e0, 0x34840002, 0x0e000670, 0x00000000, 0x3c030800, + 0x90631b78, 0x24020002, 0x3c040800, 0x24841acc, 0x14620003, 0x24050001, + 0x3c040800, 0x24841ac0, 0x24060002, 0x00003821, 0xafa00010, 0x0e000684, + 0xafa00014, 0x8f625c50, 0x34420001, 0xaf625c50, 0x8f625c90, 0x34420001, + 0xaf625c90, 0x2402ffff, 0x0e000034, 0xaf625404, 0x8fbf0018, 0x03e00008, + 0x27bd0020, 0x00000000, 0x00000000, 0x00000000, 0x27bdffe0, 0xafbf0018, + 0xafb10014, 0x0e000052, 0xafb00010, 0x24110001, 0x8f706820, 0x32020100, + 0x10400003, 0x00000000, 0x0e0000b2, 0x00000000, 0x8f706820, 0x32022000, + 0x10400004, 0x32020001, 0x0e0001e3, 0x24040001, 0x32020001, 0x10400003, + 0x00000000, 0x0e00009a, 0x00000000, 0x0a00003a, 0xaf715028, 0x8fbf0018, + 0x8fb10014, 0x8fb00010, 0x03e00008, 0x27bd0020, 0x27bdffe0, 0x3c040800, + 0x24841ae0, 0x00002821, 0x00003021, 0x00003821, 0xafbf0018, 0xafa00010, + 0x0e000684, 0xafa00014, 0x3c040800, 0x248423e8, 0xa4800000, 0x3c010800, + 0xa0201ba8, 0x3c010800, 0xac201bac, 0x3c010800, 0xac201bb0, 0x3c010800, + 0xac201bb4, 0x3c010800, 0xac201bbc, 0x3c010800, 0xac201bc8, 0x3c010800, + 0xac201bcc, 0x8f624434, 0x3c010800, 0xac221b98, 0x8f624438, 0x3c010800, + 0xac221b9c, 0x8f624410, 0xac80f7a8, 0x3c010800, 0xac201b94, 0x3c010800, + 0xac2023f0, 0x3c010800, 0xac2023d8, 0x3c010800, 0xac2023dc, 0x3c010800, + 0xac202410, 0x3c010800, 0xac221ba0, 0x8f620068, 0x24030007, 0x00021702, + 0x10430005, 0x00000000, 0x8f620068, 0x00021702, 0x14400004, 0x24020001, + 0x3c010800, 0x0a00008e, 0xac20241c, 0xac820034, 0x3c040800, 0x24841aec, + 0x3c050800, 0x8ca5241c, 0x00003021, 0x00003821, 0xafa00010, 0x0e000684, + 0xafa00014, 0x8fbf0018, 0x03e00008, 0x27bd0020, 0x27bdffe0, 0x3c040800, + 0x24841af8, 0x00002821, 0x00003021, 0x00003821, 0xafbf0018, 0xafa00010, + 0x0e000684, 0xafa00014, 0x0e000052, 0x00000000, 0x0e0000ab, 0x00002021, + 0x8fbf0018, 0x03e00008, 0x27bd0020, 0x24020001, 0x8f636820, 0x00821004, + 0x00021027, 0x00621824, 0x03e00008, 0xaf636820, 0x27bdffd0, 0xafbf002c, + 0xafb60028, 0xafb50024, 0xafb40020, 0xafb3001c, 0xafb20018, 0xafb10014, + 0xafb00010, 0x8f665c5c, 0x3c030800, 0x24631bcc, 0x8c620000, 0x14460005, + 0x3c0200ff, 0x3c020800, 0x90421ba8, 0x14400115, 0x3c0200ff, 0x3442fff8, + 0x00c28824, 0xac660000, 0x00111902, 0x306300ff, 0x30c20003, 0x000211c0, + 0x00623825, 0x00e02821, 0x00061602, 0x3c030800, 0x90631ba8, 0x3044000f, + 0x1460002b, 0x00804021, 0x24020001, 0x3c010800, 0xa0221ba8, 0x00071100, + 0x00821025, 0x3c010800, 0xac201bac, 0x3c010800, 0xac201bb0, 0x3c010800, + 0xac201bb4, 0x3c010800, 0xac201bbc, 0x3c010800, 0xac201bc8, 0x3c010800, + 0xac201bc0, 0x3c010800, 0xac201bc4, 0x3c010800, 0xa42223e8, 0x9623000c, + 0x30628000, 0x10400008, 0x30627fff, 0x2442003e, 0x3c010800, 0xa4221ba6, + 0x24020001, 0x3c010800, 0x0a0000f9, 0xac222404, 0x24620036, 0x3c010800, + 0xa4221ba6, 0x3c010800, 0xac202404, 0x3c010800, 0xac202400, 0x3c010800, + 0x0a000101, 0xac202408, 0x9622000c, 0x3c010800, 0xa42223fc, 0x3c040800, + 0x24841bac, 0x8c820000, 0x00021100, 0x3c010800, 0x00220821, 0xac311bd8, + 0x8c820000, 0x00021100, 0x3c010800, 0x00220821, 0xac261bdc, 0x8c820000, + 0x24a30001, 0x306701ff, 0x00021100, 0x3c010800, 0x00220821, 0xac271be0, + 0x8c820000, 0x00021100, 0x3c010800, 0x00220821, 0xac281be4, 0x96230008, + 0x3c020800, 0x8c421bbc, 0x00432821, 0x3c010800, 0xac251bbc, 0x9622000a, + 0x30420004, 0x14400018, 0x00071100, 0x8f630c14, 0x3063000f, 0x2c620002, + 0x1440000b, 0x3c02c000, 0x8f630c14, 0x3c020800, 0x8c421b50, 0x3063000f, + 0x24420001, 0x3c010800, 0xac221b50, 0x2c620002, 0x1040fff7, 0x3c02c000, + 0x00c21825, 0xaf635c5c, 0x8f625c50, 0x30420002, 0x10400014, 0x00000000, + 0x0a000133, 0x00000000, 0x3c030800, 0x8c631b90, 0x3c040800, 0x94841ba4, + 0x01021025, 0x3c010800, 0xa42223ea, 0x24020001, 0x3c010800, 0xac221bc8, + 0x24630001, 0x0085202a, 0x3c010800, 0x10800003, 0xac231b90, 0x3c010800, + 0xa4251ba4, 0x3c060800, 0x24c61bac, 0x8cc20000, 0x24420001, 0xacc20000, + 0x28420080, 0x14400005, 0x00000000, 0x0e00065e, 0x24040002, 0x0a0001d9, + 0x00000000, 0x3c020800, 0x8c421bc8, 0x1040007f, 0x24020001, 0x3c040800, + 0x90841ba8, 0x14820077, 0x24020003, 0x3c150800, 0x96b51ba6, 0x3c050800, + 0x8ca51bbc, 0x32a3ffff, 0x00a3102a, 0x14400073, 0x00000000, 0x14a30003, + 0x00000000, 0x3c010800, 0xac242400, 0x10600061, 0x00009021, 0x24d60004, + 0x0060a021, 0x24d30014, 0x8ec20000, 0x00028100, 0x3c110800, 0x02308821, + 0x0e00062d, 0x8e311bd8, 0x00403021, 0x10c00059, 0x00000000, 0x9628000a, + 0x31020040, 0x10400004, 0x2407180c, 0x8e22000c, 0x2407188c, 0xacc20018, + 0x31021000, 0x10400004, 0x34e32000, 0x00081040, 0x3042c000, 0x00623825, + 0x3c030800, 0x00701821, 0x8c631be0, 0x3c020800, 0x00501021, 0x8c421be4, + 0x00031d00, 0x00021400, 0x00621825, 0xacc30014, 0x8ec30004, 0x96220008, + 0x00432023, 0x3242ffff, 0x3083ffff, 0x00431021, 0x0282102a, 0x14400002, + 0x02b22823, 0x00802821, 0x8e620000, 0x30a4ffff, 0x00441021, 0xae620000, + 0x8e220000, 0xacc20000, 0x8e220004, 0x8e63fff4, 0x00431021, 0xacc20004, + 0xa4c5000e, 0x8e62fff4, 0x00441021, 0xae62fff4, 0x96230008, 0x0043102a, + 0x14400005, 0x02459021, 0x8e62fff0, 0xae60fff4, 0x24420001, 0xae62fff0, + 0xacc00008, 0x3242ffff, 0x14540008, 0x24020305, 0x31020080, 0x54400001, + 0x34e70010, 0x24020905, 0xa4c2000c, 0x0a0001bc, 0x34e70020, 0xa4c2000c, + 0x3c020800, 0x8c422400, 0x10400003, 0x3c024b65, 0x0a0001c4, 0x34427654, + 0x3c02b49a, 0x344289ab, 0xacc2001c, 0x30e2ffff, 0xacc20010, 0x0e0005aa, + 0x00c02021, 0x3242ffff, 0x0054102b, 0x1440ffa4, 0x00000000, 0x24020002, + 0x3c010800, 0x0a0001d9, 0xa0221ba8, 0x8ec2083c, 0x24420001, 0x0a0001d9, + 0xaec2083c, 0x14820003, 0x00000000, 0x0e0004b9, 0x00000000, 0x8fbf002c, + 0x8fb60028, 0x8fb50024, 0x8fb40020, 0x8fb3001c, 0x8fb20018, 0x8fb10014, + 0x8fb00010, 0x03e00008, 0x27bd0030, 0x27bdffd0, 0xafbf0028, 0xafb30024, + 0xafb20020, 0xafb1001c, 0xafb00018, 0x8f725c9c, 0x3c0200ff, 0x3442fff8, + 0x3c060800, 0x24c61bc4, 0x02428824, 0x9623000e, 0x8cc20000, 0x00431021, + 0xacc20000, 0x8e220010, 0x30420020, 0x14400011, 0x00809821, 0x0e000643, 0x02202021, 0x3c02c000, 0x02421825, 0xaf635c9c, 0x8f625c90, 0x30420002, - 0x10400061, 0x00000000, 0xaf635c9c, 0x8f625c90, 0x30420002, 0x1040005c, - 0x00000000, 0x0a000278, 0x00000000, 0x8e220008, 0x00021c02, 0x000321c0, - 0x3042ffff, 0x3c030800, 0x906316f8, 0x000229c0, 0x24020002, 0x14620003, - 0x3c034b65, 0x0a000290, 0x00008021, 0x8e22001c, 0x34637654, 0x10430002, - 0x24100002, 0x24100001, 0x0e000300, 0x02003021, 0x24020003, 0x3c010800, - 0xa02216f8, 0x24020002, 0x1202000a, 0x24020001, 0x3c030800, 0x8c631fd0, - 0x10620006, 0x00000000, 0x3c020800, 0x94421fb8, 0x00021400, 0x0a0002cd, - 0xae220014, 0x3c040800, 0x24841fba, 0x94820000, 0x00021400, 0xae220014, - 0x3c020800, 0x8c42171c, 0x3c03c000, 0x3c010800, 0xa02016f8, 0x00431025, - 0xaf625c5c, 0x8f625c50, 0x30420002, 0x10400009, 0x00000000, 0x2484f762, + 0x10400121, 0x00000000, 0xaf635c9c, 0x8f625c90, 0x30420002, 0x1040011c, + 0x00000000, 0x0a000200, 0x00000000, 0x8e240008, 0x8e230014, 0x00041402, + 0x000241c0, 0x00031502, 0x304201ff, 0x2442ffff, 0x3042007f, 0x00031942, + 0x30637800, 0x00021100, 0x24424000, 0x00625021, 0x9542000a, 0x3084ffff, + 0x30420008, 0x104000b3, 0x000429c0, 0x3c020800, 0x8c422410, 0x1440002d, + 0x25050008, 0x95020014, 0x3c010800, 0xa42223e0, 0x8d070010, 0x00071402, + 0x3c010800, 0xa42223e2, 0x3c010800, 0xa42723e4, 0x9502000e, 0x30e3ffff, + 0x00431023, 0x3c010800, 0xac222418, 0x8f626800, 0x3c030010, 0x00431024, + 0x10400005, 0x00000000, 0x9503001a, 0x9502001c, 0x0a000235, 0x00431021, + 0x9502001a, 0x3c010800, 0xac22240c, 0x3c02c000, 0x02421825, 0x3c010800, + 0xac282410, 0x3c010800, 0xac322414, 0xaf635c9c, 0x8f625c90, 0x30420002, + 0x104000df, 0x00000000, 0xaf635c9c, 0x8f625c90, 0x30420002, 0x104000da, + 0x00000000, 0x0a000242, 0x00000000, 0x9502000e, 0x3c030800, 0x946323e4, + 0x00434823, 0x3123ffff, 0x2c620008, 0x1040001c, 0x00000000, 0x95020014, + 0x24420028, 0x00a22821, 0x00031042, 0x1840000b, 0x00002021, 0x24c60848, + 0x00403821, 0x94a30000, 0x8cc20000, 0x24840001, 0x00431021, 0xacc20000, + 0x0087102a, 0x1440fff9, 0x24a50002, 0x31220001, 0x1040001f, 0x3c024000, + 0x3c040800, 0x2484240c, 0xa0a00001, 0x94a30000, 0x8c820000, 0x00431021, + 0x0a000281, 0xac820000, 0x8f626800, 0x3c030010, 0x00431024, 0x10400009, + 0x00000000, 0x9502001a, 0x3c030800, 0x8c63240c, 0x00431021, 0x3c010800, + 0xac22240c, 0x0a000282, 0x3c024000, 0x9502001a, 0x9504001c, 0x3c030800, + 0x8c63240c, 0x00441023, 0x00621821, 0x3c010800, 0xac23240c, 0x3c024000, + 0x02421825, 0xaf635c9c, 0x8f625c90, 0x30420002, 0x1440fffc, 0x00000000, + 0x9542000a, 0x30420010, 0x10400095, 0x00000000, 0x3c060800, 0x24c62410, + 0x3c020800, 0x944223e4, 0x8cc50000, 0x3c040800, 0x8c842418, 0x24420030, + 0x00a22821, 0x94a20004, 0x3c030800, 0x8c63240c, 0x00441023, 0x00621821, + 0x00603821, 0x00032402, 0x30e2ffff, 0x00823821, 0x00071402, 0x00e23821, + 0x00071027, 0x3c010800, 0xac23240c, 0xa4a20006, 0x3c030800, 0x8c632414, + 0x3c0200ff, 0x3442fff8, 0x00628824, 0x96220008, 0x24040001, 0x24034000, + 0x000241c0, 0x00e01021, 0xa502001a, 0xa500001c, 0xacc00000, 0x3c010800, + 0xac241b70, 0xaf635cb8, 0x8f625cb0, 0x30420002, 0x10400003, 0x00000000, + 0x3c010800, 0xac201b70, 0x8e220008, 0xaf625cb8, 0x8f625cb0, 0x30420002, + 0x10400003, 0x00000000, 0x3c010800, 0xac201b70, 0x3c020800, 0x8c421b70, + 0x1040ffec, 0x00000000, 0x3c040800, 0x0e000643, 0x8c842414, 0x0a000320, + 0x00000000, 0x3c030800, 0x90631ba8, 0x24020002, 0x14620003, 0x3c034b65, + 0x0a0002d7, 0x00008021, 0x8e22001c, 0x34637654, 0x10430002, 0x24100002, + 0x24100001, 0x01002021, 0x0e000346, 0x02003021, 0x24020003, 0x3c010800, + 0xa0221ba8, 0x24020002, 0x1202000a, 0x24020001, 0x3c030800, 0x8c632400, + 0x10620006, 0x00000000, 0x3c020800, 0x944223e8, 0x00021400, 0x0a000315, + 0xae220014, 0x3c040800, 0x248423ea, 0x94820000, 0x00021400, 0xae220014, + 0x3c020800, 0x8c421bcc, 0x3c03c000, 0x3c010800, 0xa0201ba8, 0x00431025, + 0xaf625c5c, 0x8f625c50, 0x30420002, 0x10400009, 0x00000000, 0x2484f7e2, 0x8c820000, 0x00431025, 0xaf625c5c, 0x8f625c50, 0x30420002, 0x1440fffa, - 0x00000000, 0x3c020800, 0x244216e4, 0x8c430000, 0x24630001, 0xac430000, - 0x8f630c14, 0x3063000f, 0x2c620002, 0x1440000b, 0x00009821, 0x8f630c14, - 0x3c020800, 0x8c4216b4, 0x3063000f, 0x24420001, 0x3c010800, 0xac2216b4, - 0x2c620002, 0x1040fff7, 0x00009821, 0x3c024000, 0x02421825, 0xaf635c9c, + 0x00000000, 0x3c020800, 0x24421b94, 0x8c430000, 0x24630001, 0xac430000, + 0x8f630c14, 0x3063000f, 0x2c620002, 0x1440000c, 0x3c024000, 0x8f630c14, + 0x3c020800, 0x8c421b50, 0x3063000f, 0x24420001, 0x3c010800, 0xac221b50, + 0x2c620002, 0x1040fff7, 0x00000000, 0x3c024000, 0x02421825, 0xaf635c9c, 0x8f625c90, 0x30420002, 0x1440fffc, 0x00000000, 0x12600003, 0x00000000, - 0x0e000450, 0x00000000, 0x8fbf0020, 0x8fb3001c, 0x8fb20018, 0x8fb10014, - 0x8fb00010, 0x03e00008, 0x27bd0028, 0x0a0002df, 0x00000000, 0x8f634450, - 0x3c040800, 0x248416e8, 0x8c820000, 0x00031c02, 0x0043102b, 0x14400007, - 0x3c038000, 0x8c840004, 0x8f624450, 0x00021c02, 0x0083102b, 0x1040fffc, - 0x3c038000, 0xaf634444, 0x8f624444, 0x00431024, 0x1440fffd, 0x00000000, - 0x8f624448, 0x03e00008, 0x3042ffff, 0x3c024000, 0x00822025, 0xaf645c38, - 0x8f625c30, 0x30420002, 0x1440fffc, 0x00000000, 0x03e00008, 0x00000000, - 0x27bdffe0, 0x00805021, 0x14c00017, 0x254c0008, 0x3c020800, 0x8c421fd4, - 0x1040000a, 0x2402003e, 0x3c010800, 0xa4221fb0, 0x24020016, 0x3c010800, - 0xa4221fb2, 0x2402002a, 0x3c010800, 0x0a00031a, 0xa4221fb4, 0x95420014, - 0x3c010800, 0xa4221fb0, 0x8d430010, 0x00031402, 0x3c010800, 0xa4221fb2, - 0x3c010800, 0xa4231fb4, 0x3c040800, 0x94841fb4, 0x3c030800, 0x94631fb2, - 0x958d0006, 0x3c020800, 0x94421fb0, 0x00832023, 0x01a27023, 0x3065ffff, - 0x24a20028, 0x01824021, 0x3082ffff, 0x14c0001a, 0x01025821, 0x9562000c, - 0x3042003f, 0x3c010800, 0xa4221fb6, 0x95620004, 0x95630006, 0x3c010800, - 0xac201fc4, 0x3c010800, 0xac201fc8, 0x00021400, 0x00431025, 0x3c010800, - 0xac221720, 0x95020004, 0x3c010800, 0xa4221724, 0x95030002, 0x01a51023, - 0x0043102a, 0x10400010, 0x24020001, 0x3c010800, 0x0a00034e, 0xac221fd8, - 0x3c030800, 0x8c631fc8, 0x3c020800, 0x94421724, 0x00431021, 0xa5020004, - 0x3c020800, 0x94421720, 0xa5620004, 0x3c020800, 0x8c421720, 0xa5620006, - 0x3c020800, 0x8c421fd0, 0x3c070800, 0x8ce71fc4, 0x3c050800, 0x144000c7, - 0x8ca51fc8, 0x3c020800, 0x94421724, 0x00451821, 0x3063ffff, 0x0062182b, - 0x24020002, 0x10c2000d, 0x00a32823, 0x3c020800, 0x94421fb6, 0x30420009, - 0x10400008, 0x00000000, 0x9562000c, 0x3042fff6, 0xa562000c, 0x3c020800, - 0x94421fb6, 0x30420009, 0x00e23823, 0x3c020800, 0x8c421fd8, 0x1040004b, - 0x24020002, 0x01003021, 0x3c020800, 0x94421fb2, 0x00003821, 0xa500000a, - 0x01a21023, 0xa5020002, 0x3082ffff, 0x00021042, 0x18400008, 0x00002821, - 0x00401821, 0x94c20000, 0x24e70001, 0x00a22821, 0x00e3102a, 0x1440fffb, - 0x24c60002, 0x00051c02, 0x30a2ffff, 0x00622821, 0x00051402, 0x00a22821, - 0x00a04821, 0x00051027, 0xa502000a, 0x00002821, 0x2506000c, 0x00003821, - 0x94c20000, 0x24e70001, 0x00a22821, 0x2ce20004, 0x1440fffb, 0x24c60002, - 0x95020002, 0x00003821, 0x91030009, 0x00442023, 0x01603021, 0x3082ffff, - 0xa4c00010, 0x00621821, 0x00021042, 0x18400010, 0x00a32821, 0x00404021, - 0x94c20000, 0x24c60002, 0x00a22821, 0x30c2007f, 0x14400006, 0x24e70001, - 0x8d430000, 0x3c02007f, 0x3442ff80, 0x00625024, 0x25460008, 0x00e8102a, - 0x1440fff3, 0x00000000, 0x30820001, 0x10400005, 0x00051c02, 0xa0c00001, - 0x94c20000, 0x00a22821, 0x00051c02, 0x30a2ffff, 0x00622821, 0x00051402, - 0x00a22821, 0x0a000415, 0x30a5ffff, 0x14c20063, 0x00000000, 0x3c090800, - 0x95291fb2, 0x95030002, 0x01a91023, 0x1062005d, 0x01003021, 0x00003821, - 0x00002821, 0x01a91023, 0xa5020002, 0x3082ffff, 0x00021042, 0x18400008, - 0xa500000a, 0x00401821, 0x94c20000, 0x24e70001, 0x00a22821, 0x00e3102a, - 0x1440fffb, 0x24c60002, 0x00051c02, 0x30a2ffff, 0x00622821, 0x00051402, - 0x00a22821, 0x00a04821, 0x00051027, 0xa502000a, 0x00002821, 0x2506000c, - 0x00003821, 0x94c20000, 0x24e70001, 0x00a22821, 0x2ce20004, 0x1440fffb, - 0x24c60002, 0x95020002, 0x00003821, 0x91030009, 0x00442023, 0x01603021, - 0x3082ffff, 0xa4c00010, 0x3c040800, 0x94841fb4, 0x00621821, 0x00a32821, - 0x00051c02, 0x30a2ffff, 0x00622821, 0x00051c02, 0x3c020800, 0x94421fb0, - 0x00a34021, 0x00441023, 0x00021fc2, 0x00431021, 0x00021043, 0x18400010, - 0x00002821, 0x00402021, 0x94c20000, 0x24c60002, 0x00a22821, 0x30c2007f, - 0x14400006, 0x24e70001, 0x8d430000, 0x3c02007f, 0x3442ff80, 0x00625024, - 0x25460008, 0x00e4102a, 0x1440fff3, 0x00000000, 0x3c020800, 0x94421fcc, - 0x00a22821, 0x00051c02, 0x30a2ffff, 0x00622821, 0x00051402, 0x00a22821, - 0x3102ffff, 0x00a22821, 0x00051c02, 0x30a2ffff, 0x00622821, 0x00051402, - 0x00a22821, 0x00a02021, 0x00051027, 0xa5620010, 0xad800014, 0x0a000435, - 0xad800000, 0x8d830010, 0x00602021, 0x10a00007, 0x00034c02, 0x01252821, - 0x00051402, 0x30a3ffff, 0x00432821, 0x00051402, 0x00a24821, 0x00091027, - 0xa502000a, 0x3c030800, 0x94631fb4, 0x3082ffff, 0x01a21021, 0x00432823, - 0x00a72821, 0x00051c02, 0x30a2ffff, 0x00622821, 0x00051402, 0x00a22821, - 0x00a02021, 0x00051027, 0xa5620010, 0x3082ffff, 0x00091c00, 0x00431025, - 0xad820010, 0x3c020800, 0x8c421fd4, 0x10400002, 0x25a2fff2, 0xa5820034, - 0x3c020800, 0x8c421fc8, 0x3c030800, 0x8c631720, 0x24420001, 0x3c010800, - 0xac221fc8, 0x3c020800, 0x8c421fc4, 0x31c4ffff, 0x00641821, 0x3c010800, - 0xac231720, 0x00441021, 0x3c010800, 0xac221fc4, 0x03e00008, 0x27bd0020, - 0x27bdffc8, 0x3c040800, 0x248416f8, 0xafbf0034, 0xafbe0030, 0xafb7002c, - 0xafb60028, 0xafb50024, 0xafb40020, 0xafb3001c, 0xafb20018, 0xafb10014, - 0xafb00010, 0x90830000, 0x24020003, 0x146200f4, 0x00000000, 0x3c020800, - 0x8c421710, 0x3c030800, 0x8c63170c, 0x3c1e0800, 0x97de16f6, 0x0043102a, - 0x104000eb, 0x3c168000, 0x249708c4, 0x33d5ffff, 0x24920018, 0x3c020800, - 0x8c421718, 0x104000e4, 0x00000000, 0x3c140800, 0x96941fb0, 0x3282ffff, - 0x104000d6, 0x00008021, 0x00409821, 0x00008821, 0x8f634450, 0x3c020800, - 0x8c4216e8, 0x00031c02, 0x0043102b, 0x14400008, 0x00000000, 0x3c040800, - 0x8c8416ec, 0x8f624450, 0x00021c02, 0x0083102b, 0x1040fffc, 0x00000000, - 0xaf764444, 0x8f624444, 0x00561024, 0x10400006, 0x00000000, 0x3c038000, - 0x8f624444, 0x00431024, 0x1440fffd, 0x00000000, 0x8f624448, 0x3046ffff, - 0x10c0005f, 0x00000000, 0x3c090800, 0x01314821, 0x8d291728, 0x9528000a, - 0x31020040, 0x10400004, 0x2407180c, 0x8d22000c, 0x2407188c, 0xacc20018, - 0x31021000, 0x10400004, 0x34e32000, 0x00081040, 0x3042c000, 0x00623825, - 0x31020080, 0x54400001, 0x34e70010, 0x3c020800, 0x00511021, 0x8c421730, - 0x3c030800, 0x00711821, 0x8c631734, 0x00021500, 0x00031c00, 0x00431025, - 0xacc20014, 0x95240008, 0x3202ffff, 0x00821021, 0x0262102a, 0x14400002, - 0x02902823, 0x00802821, 0x8d220000, 0x02058021, 0xacc20000, 0x8d220004, - 0x00c02021, 0x26310010, 0xac820004, 0x30e2ffff, 0xac800008, 0xa485000e, - 0xac820010, 0x24020305, 0x0e000560, 0xa482000c, 0x3202ffff, 0x0053102b, - 0x1440ffaf, 0x3202ffff, 0x0a00054c, 0x00000000, 0x8e420000, 0x8e43fffc, - 0x0043102a, 0x10400084, 0x00000000, 0x8e45fff0, 0x8f644450, 0x3c030800, - 0x8c6316e8, 0x00051100, 0x3c090800, 0x01224821, 0x8d291728, 0x00041402, - 0x0062182b, 0x14600008, 0x00000000, 0x3c030800, 0x8c6316ec, 0x8f624450, - 0x00021402, 0x0062102b, 0x1040fffc, 0x00000000, 0xaf764444, 0x8f624444, - 0x00561024, 0x10400006, 0x00000000, 0x3c038000, 0x8f624444, 0x00431024, - 0x1440fffd, 0x00000000, 0x8f624448, 0x3046ffff, 0x14c00005, 0x00000000, - 0x8ee20000, 0x24420001, 0x0a000554, 0xaee20000, 0x9528000a, 0x31020040, - 0x10400004, 0x2407180c, 0x8d22000c, 0x2407188c, 0xacc20018, 0x31021000, - 0x10400004, 0x34e32000, 0x00081040, 0x3042c000, 0x00623825, 0x00051900, - 0x3c020800, 0x00431021, 0x8c421730, 0x3c010800, 0x00230821, 0x8c231734, - 0x00021500, 0x00031c00, 0x00431025, 0xacc20014, 0x3c030800, 0x8c631704, - 0x95220008, 0x00432023, 0x3202ffff, 0x3083ffff, 0x00431021, 0x02a2102a, - 0x14400002, 0x03d02823, 0x00802821, 0x8e420000, 0x30a4ffff, 0x00441021, - 0xae420000, 0xa4c5000e, 0x8d220000, 0xacc20000, 0x8d220004, 0x8e43fff4, - 0x00431021, 0xacc20004, 0x8e43fff4, 0x95220008, 0x00641821, 0x0062102a, - 0x14400006, 0x02058021, 0x8e42fff0, 0xae40fff4, 0x24420001, 0x0a000530, - 0xae42fff0, 0xae43fff4, 0xacc00008, 0x3202ffff, 0x10550003, 0x31020004, - 0x10400006, 0x24020305, 0x31020080, 0x54400001, 0x34e70010, 0x34e70020, - 0x24020905, 0xa4c2000c, 0x30e2ffff, 0xacc20010, 0x3c030800, 0x8c63170c, - 0x3c020800, 0x8c421710, 0x54620004, 0x3c02b49a, 0x3c024b65, 0x0a000548, - 0x34427654, 0x344289ab, 0xacc2001c, 0x0e000560, 0x00c02021, 0x3202ffff, - 0x0055102b, 0x1440ff7e, 0x00000000, 0x8e420000, 0x8e43fffc, 0x0043102a, - 0x1440ff1a, 0x00000000, 0x8fbf0034, 0x8fbe0030, 0x8fb7002c, 0x8fb60028, - 0x8fb50024, 0x8fb40020, 0x8fb3001c, 0x8fb20018, 0x8fb10014, 0x8fb00010, - 0x03e00008, 0x27bd0038, 0x27bdffe8, 0xafbf0014, 0xafb00010, 0x8f624450, - 0x8f634410, 0x0a00056f, 0x00808021, 0x8f626820, 0x30422000, 0x10400003, - 0x00000000, 0x0e00025a, 0x00002021, 0x8f624450, 0x8f634410, 0x3042ffff, - 0x0043102b, 0x1440fff5, 0x00000000, 0x8f630c14, 0x3063000f, 0x2c620002, - 0x1440000b, 0x00000000, 0x8f630c14, 0x3c020800, 0x8c4216b4, 0x3063000f, - 0x24420001, 0x3c010800, 0xac2216b4, 0x2c620002, 0x1040fff7, 0x00000000, - 0xaf705c18, 0x8f625c10, 0x30420002, 0x10400009, 0x00000000, 0x8f626820, - 0x30422000, 0x1040fff8, 0x00000000, 0x0e00025a, 0x00002021, 0x0a000582, - 0x00000000, 0x8fbf0014, 0x8fb00010, 0x03e00008, 0x27bd0018, 0x00000000, - 0x00000000 + 0x0e0004b9, 0x00000000, 0x8fbf0028, 0x8fb30024, 0x8fb20020, 0x8fb1001c, + 0x8fb00018, 0x03e00008, 0x27bd0030, 0x8f634450, 0x3c040800, 0x24841b98, + 0x8c820000, 0x00031c02, 0x0043102b, 0x14400007, 0x3c038000, 0x8c840004, + 0x8f624450, 0x00021c02, 0x0083102b, 0x1040fffc, 0x3c038000, 0xaf634444, + 0x8f624444, 0x00431024, 0x1440fffd, 0x00000000, 0x8f624448, 0x03e00008, + 0x3042ffff, 0x3c024000, 0x00822025, 0xaf645c38, 0x8f625c30, 0x30420002, + 0x1440fffc, 0x00000000, 0x03e00008, 0x00000000, 0x27bdffe0, 0x00805821, + 0x14c00017, 0x256e0008, 0x3c020800, 0x8c422404, 0x1040000a, 0x2402003e, + 0x3c010800, 0xa42223e0, 0x24020016, 0x3c010800, 0xa42223e2, 0x2402002a, + 0x3c010800, 0x0a000360, 0xa42223e4, 0x95620014, 0x3c010800, 0xa42223e0, + 0x8d670010, 0x00071402, 0x3c010800, 0xa42223e2, 0x3c010800, 0xa42723e4, + 0x3c040800, 0x948423e4, 0x3c030800, 0x946323e2, 0x95cf0006, 0x3c020800, + 0x944223e0, 0x00832023, 0x01e2c023, 0x3065ffff, 0x24a20028, 0x01c24821, + 0x3082ffff, 0x14c0001a, 0x01226021, 0x9582000c, 0x3042003f, 0x3c010800, + 0xa42223e6, 0x95820004, 0x95830006, 0x3c010800, 0xac2023f4, 0x3c010800, + 0xac2023f8, 0x00021400, 0x00431025, 0x3c010800, 0xac221bd0, 0x95220004, + 0x3c010800, 0xa4221bd4, 0x95230002, 0x01e51023, 0x0043102a, 0x10400010, + 0x24020001, 0x3c010800, 0x0a000394, 0xac222408, 0x3c030800, 0x8c6323f8, + 0x3c020800, 0x94421bd4, 0x00431021, 0xa5220004, 0x3c020800, 0x94421bd0, + 0xa5820004, 0x3c020800, 0x8c421bd0, 0xa5820006, 0x3c020800, 0x8c422400, + 0x3c0d0800, 0x8dad23f4, 0x3c0a0800, 0x144000e5, 0x8d4a23f8, 0x3c020800, + 0x94421bd4, 0x004a1821, 0x3063ffff, 0x0062182b, 0x24020002, 0x10c2000d, + 0x01435023, 0x3c020800, 0x944223e6, 0x30420009, 0x10400008, 0x00000000, + 0x9582000c, 0x3042fff6, 0xa582000c, 0x3c020800, 0x944223e6, 0x30420009, + 0x01a26823, 0x3c020800, 0x8c422408, 0x1040004a, 0x01203821, 0x3c020800, + 0x944223e2, 0x00004021, 0xa520000a, 0x01e21023, 0xa5220002, 0x3082ffff, + 0x00021042, 0x18400008, 0x00003021, 0x00401821, 0x94e20000, 0x25080001, + 0x00c23021, 0x0103102a, 0x1440fffb, 0x24e70002, 0x00061c02, 0x30c2ffff, + 0x00623021, 0x00061402, 0x00c23021, 0x00c02821, 0x00061027, 0xa522000a, + 0x00003021, 0x2527000c, 0x00004021, 0x94e20000, 0x25080001, 0x00c23021, + 0x2d020004, 0x1440fffb, 0x24e70002, 0x95220002, 0x00004021, 0x91230009, + 0x00442023, 0x01803821, 0x3082ffff, 0xa4e00010, 0x00621821, 0x00021042, + 0x18400010, 0x00c33021, 0x00404821, 0x94e20000, 0x24e70002, 0x00c23021, + 0x30e2007f, 0x14400006, 0x25080001, 0x8d630000, 0x3c02007f, 0x3442ff80, + 0x00625824, 0x25670008, 0x0109102a, 0x1440fff3, 0x00000000, 0x30820001, + 0x10400005, 0x00061c02, 0xa0e00001, 0x94e20000, 0x00c23021, 0x00061c02, + 0x30c2ffff, 0x00623021, 0x00061402, 0x00c23021, 0x0a000479, 0x30c6ffff, + 0x24020002, 0x14c20081, 0x00000000, 0x3c020800, 0x8c42241c, 0x14400007, + 0x00000000, 0x3c020800, 0x944223e2, 0x95230002, 0x01e21023, 0x10620077, + 0x00000000, 0x3c020800, 0x944223e2, 0x01e21023, 0xa5220002, 0x3c020800, + 0x8c42241c, 0x1040001a, 0x31e3ffff, 0x8dc70010, 0x3c020800, 0x94421ba6, + 0x00e04021, 0x00072c02, 0x00aa2021, 0x00431023, 0x00823823, 0x00072402, + 0x30e2ffff, 0x00823821, 0x00071027, 0xa522000a, 0x3102ffff, 0x3c040800, + 0x948423e4, 0x00453023, 0x00e02821, 0x00641823, 0x006d1821, 0x00c33021, + 0x00061c02, 0x30c2ffff, 0x0a000479, 0x00623021, 0x01203821, 0x00004021, + 0x3082ffff, 0x00021042, 0x18400008, 0x00003021, 0x00401821, 0x94e20000, + 0x25080001, 0x00c23021, 0x0103102a, 0x1440fffb, 0x24e70002, 0x00061c02, + 0x30c2ffff, 0x00623021, 0x00061402, 0x00c23021, 0x00c02821, 0x00061027, + 0xa522000a, 0x00003021, 0x2527000c, 0x00004021, 0x94e20000, 0x25080001, + 0x00c23021, 0x2d020004, 0x1440fffb, 0x24e70002, 0x95220002, 0x00004021, + 0x91230009, 0x00442023, 0x01803821, 0x3082ffff, 0xa4e00010, 0x3c040800, + 0x948423e4, 0x00621821, 0x00c33021, 0x00061c02, 0x30c2ffff, 0x00623021, + 0x00061c02, 0x3c020800, 0x944223e0, 0x00c34821, 0x00441023, 0x00021fc2, + 0x00431021, 0x00021043, 0x18400010, 0x00003021, 0x00402021, 0x94e20000, + 0x24e70002, 0x00c23021, 0x30e2007f, 0x14400006, 0x25080001, 0x8d630000, + 0x3c02007f, 0x3442ff80, 0x00625824, 0x25670008, 0x0104102a, 0x1440fff3, + 0x00000000, 0x3c020800, 0x944223fc, 0x00c23021, 0x3122ffff, 0x00c23021, + 0x00061c02, 0x30c2ffff, 0x00623021, 0x00061402, 0x00c23021, 0x00c04021, + 0x00061027, 0xa5820010, 0xadc00014, 0x0a000499, 0xadc00000, 0x8dc70010, + 0x00e04021, 0x11400007, 0x00072c02, 0x00aa3021, 0x00061402, 0x30c3ffff, + 0x00433021, 0x00061402, 0x00c22821, 0x00051027, 0xa522000a, 0x3c030800, + 0x946323e4, 0x3102ffff, 0x01e21021, 0x00433023, 0x00cd3021, 0x00061c02, + 0x30c2ffff, 0x00623021, 0x00061402, 0x00c23021, 0x00c04021, 0x00061027, + 0xa5820010, 0x3102ffff, 0x00051c00, 0x00431025, 0xadc20010, 0x3c020800, + 0x8c422404, 0x10400002, 0x25e2fff2, 0xa5c20034, 0x3c020800, 0x8c4223f8, + 0x3c040800, 0x8c8423f4, 0x24420001, 0x3c010800, 0xac2223f8, 0x3c020800, + 0x8c421bd0, 0x3303ffff, 0x00832021, 0x3c010800, 0xac2423f4, 0x00431821, + 0x0062102b, 0x10400003, 0x2482ffff, 0x3c010800, 0xac2223f4, 0x3c010800, + 0xac231bd0, 0x03e00008, 0x27bd0020, 0x27bdffb8, 0x3c050800, 0x24a51ba8, + 0xafbf0044, 0xafbe0040, 0xafb7003c, 0xafb60038, 0xafb50034, 0xafb40030, + 0xafb3002c, 0xafb20028, 0xafb10024, 0xafb00020, 0x90a30000, 0x24020003, + 0x146200d5, 0x00000000, 0x3c090800, 0x95291ba6, 0x3c020800, 0x944223e0, + 0x3c030800, 0x8c631bc0, 0x3c040800, 0x8c841bbc, 0x01221023, 0x0064182a, + 0xa7a9001e, 0x106000c8, 0xa7a20016, 0x24be0020, 0x97b6001e, 0x24b30018, + 0x24b70014, 0x8fc20000, 0x14400008, 0x00000000, 0x8fc2fff8, 0x97a30016, + 0x8fc4fff4, 0x00431021, 0x0082202a, 0x148000ba, 0x00000000, 0x97d50818, + 0x32a2ffff, 0x104000ad, 0x00009021, 0x0040a021, 0x00008821, 0x0e00062d, + 0x00000000, 0x00403021, 0x14c00007, 0x00000000, 0x3c020800, 0x8c4223ec, + 0x24420001, 0x3c010800, 0x0a00059e, 0xac2223ec, 0x3c100800, 0x02118021, + 0x8e101bd8, 0x9608000a, 0x31020040, 0x10400004, 0x2407180c, 0x8e02000c, + 0x2407188c, 0xacc20018, 0x31021000, 0x10400004, 0x34e32000, 0x00081040, + 0x3042c000, 0x00623825, 0x31020080, 0x54400001, 0x34e70010, 0x3c020800, + 0x00511021, 0x8c421be0, 0x3c030800, 0x00711821, 0x8c631be4, 0x00021500, + 0x00031c00, 0x00431025, 0xacc20014, 0x96040008, 0x3242ffff, 0x00821021, + 0x0282102a, 0x14400002, 0x02b22823, 0x00802821, 0x8e020000, 0x02459021, + 0xacc20000, 0x8e020004, 0x00c02021, 0x26310010, 0xac820004, 0x30e2ffff, + 0xac800008, 0xa485000e, 0xac820010, 0x24020305, 0x0e0005aa, 0xa482000c, + 0x3242ffff, 0x0054102b, 0x1440ffc0, 0x3242ffff, 0x0a000596, 0x00000000, + 0x8e620000, 0x8e63fffc, 0x0043102a, 0x1040006c, 0x00000000, 0x8e62fff0, + 0x00028900, 0x3c100800, 0x02118021, 0x0e00062d, 0x8e101bd8, 0x00403021, + 0x14c00005, 0x00000000, 0x8e62082c, 0x24420001, 0x0a00059e, 0xae62082c, + 0x9608000a, 0x31020040, 0x10400004, 0x2407180c, 0x8e02000c, 0x2407188c, + 0xacc20018, 0x31021000, 0x10400004, 0x34e32000, 0x00081040, 0x3042c000, + 0x00623825, 0x3c020800, 0x00511021, 0x8c421be0, 0x3c030800, 0x00711821, + 0x8c631be4, 0x00021500, 0x00031c00, 0x00431025, 0xacc20014, 0x8e63fff4, + 0x96020008, 0x00432023, 0x3242ffff, 0x3083ffff, 0x00431021, 0x02c2102a, + 0x10400003, 0x00802821, 0x97a9001e, 0x01322823, 0x8e620000, 0x30a4ffff, + 0x00441021, 0xae620000, 0xa4c5000e, 0x8e020000, 0xacc20000, 0x8e020004, + 0x8e63fff4, 0x00431021, 0xacc20004, 0x8e63fff4, 0x96020008, 0x00641821, + 0x0062102a, 0x14400006, 0x02459021, 0x8e62fff0, 0xae60fff4, 0x24420001, + 0x0a000579, 0xae62fff0, 0xae63fff4, 0xacc00008, 0x3242ffff, 0x10560003, + 0x31020004, 0x10400006, 0x24020305, 0x31020080, 0x54400001, 0x34e70010, + 0x34e70020, 0x24020905, 0xa4c2000c, 0x8ee30000, 0x8ee20004, 0x14620007, + 0x3c02b49a, 0x8ee20860, 0x54400001, 0x34e70400, 0x3c024b65, 0x0a000590, + 0x34427654, 0x344289ab, 0xacc2001c, 0x30e2ffff, 0xacc20010, 0x0e0005aa, + 0x00c02021, 0x3242ffff, 0x0056102b, 0x1440ff96, 0x00000000, 0x8e620000, + 0x8e63fffc, 0x0043102a, 0x1440ff3e, 0x00000000, 0x8fbf0044, 0x8fbe0040, + 0x8fb7003c, 0x8fb60038, 0x8fb50034, 0x8fb40030, 0x8fb3002c, 0x8fb20028, + 0x8fb10024, 0x8fb00020, 0x03e00008, 0x27bd0048, 0x27bdffe8, 0xafbf0014, + 0xafb00010, 0x8f624450, 0x8f634410, 0x0a0005b9, 0x00808021, 0x8f626820, + 0x30422000, 0x10400003, 0x00000000, 0x0e0001e3, 0x00002021, 0x8f624450, + 0x8f634410, 0x3042ffff, 0x0043102b, 0x1440fff5, 0x00000000, 0x8f630c14, + 0x3063000f, 0x2c620002, 0x1440000b, 0x00000000, 0x8f630c14, 0x3c020800, + 0x8c421b50, 0x3063000f, 0x24420001, 0x3c010800, 0xac221b50, 0x2c620002, + 0x1040fff7, 0x00000000, 0xaf705c18, 0x8f625c10, 0x30420002, 0x10400009, + 0x00000000, 0x8f626820, 0x30422000, 0x1040fff8, 0x00000000, 0x0e0001e3, + 0x00002021, 0x0a0005cc, 0x00000000, 0x8fbf0014, 0x8fb00010, 0x03e00008, + 0x27bd0018, 0x00000000, 0x00000000, 0x00000000, 0x27bdffe8, 0x3c1bc000, + 0xafbf0014, 0xafb00010, 0xaf60680c, 0x8f626804, 0x34420082, 0xaf626804, + 0x8f634000, 0x24020b50, 0x3c010800, 0xac221b64, 0x24020b78, 0x3c010800, + 0xac221b74, 0x34630002, 0xaf634000, 0x0e00060d, 0x00808021, 0x3c010800, + 0xa0221b78, 0x304200ff, 0x24030002, 0x14430005, 0x00000000, 0x3c020800, + 0x8c421b64, 0x0a000600, 0xac5000c0, 0x3c020800, 0x8c421b64, 0xac5000bc, + 0x8f624434, 0x8f634438, 0x8f644410, 0x3c010800, 0xac221b6c, 0x3c010800, + 0xac231b7c, 0x3c010800, 0xac241b68, 0x8fbf0014, 0x8fb00010, 0x03e00008, + 0x27bd0018, 0x3c040800, 0x8c870000, 0x3c03aa55, 0x3463aa55, 0x3c06c003, + 0xac830000, 0x8cc20000, 0x14430007, 0x24050002, 0x3c0355aa, 0x346355aa, + 0xac830000, 0x8cc20000, 0x50430001, 0x24050001, 0x3c020800, 0xac470000, + 0x03e00008, 0x00a01021, 0x27bdfff8, 0x18800009, 0x00002821, 0x8f63680c, + 0x8f62680c, 0x1043fffe, 0x00000000, 0x24a50001, 0x00a4102a, 0x1440fff9, + 0x00000000, 0x03e00008, 0x27bd0008, 0x8f634450, 0x3c020800, 0x8c421b6c, + 0x00031c02, 0x0043102b, 0x14400008, 0x3c038000, 0x3c040800, 0x8c841b7c, + 0x8f624450, 0x00021c02, 0x0083102b, 0x1040fffc, 0x3c038000, 0xaf634444, + 0x8f624444, 0x00431024, 0x1440fffd, 0x00000000, 0x8f624448, 0x03e00008, + 0x3042ffff, 0x3082ffff, 0x2442e000, 0x2c422001, 0x14400003, 0x3c024000, + 0x0a000650, 0x2402ffff, 0x00822025, 0xaf645c38, 0x8f625c30, 0x30420002, + 0x1440fffc, 0x00001021, 0x03e00008, 0x00000000, 0x8f624450, 0x3c030800, + 0x8c631b68, 0x0a000659, 0x3042ffff, 0x8f624450, 0x3042ffff, 0x0043102b, + 0x1440fffc, 0x00000000, 0x03e00008, 0x00000000, 0x27bdffe0, 0x00802821, + 0x3c040800, 0x24841b10, 0x00003021, 0x00003821, 0xafbf0018, 0xafa00010, + 0x0e000684, 0xafa00014, 0x0a000668, 0x00000000, 0x8fbf0018, 0x03e00008, + 0x27bd0020, 0x00000000, 0x00000000, 0x00000000, 0x3c020800, 0x34423000, + 0x3c030800, 0x34633000, 0x3c040800, 0x348437ff, 0x3c010800, 0xac221b84, + 0x24020040, 0x3c010800, 0xac221b88, 0x3c010800, 0xac201b80, 0xac600000, + 0x24630004, 0x0083102b, 0x5040fffd, 0xac600000, 0x03e00008, 0x00000000, + 0x00804821, 0x8faa0010, 0x3c020800, 0x8c421b80, 0x3c040800, 0x8c841b88, + 0x8fab0014, 0x24430001, 0x0044102b, 0x3c010800, 0xac231b80, 0x14400003, + 0x00004021, 0x3c010800, 0xac201b80, 0x3c020800, 0x8c421b80, 0x3c030800, + 0x8c631b84, 0x91240000, 0x00021140, 0x00431021, 0x00481021, 0x25080001, + 0xa0440000, 0x29020008, 0x1440fff4, 0x25290001, 0x3c020800, 0x8c421b80, + 0x3c030800, 0x8c631b84, 0x8f64680c, 0x00021140, 0x00431021, 0xac440008, + 0xac45000c, 0xac460010, 0xac470014, 0xac4a0018, 0x03e00008, 0xac4b001c, + 0x00000000, 0x00000000, }; u32 tg3TsoFwRodata[] = { - 0x4d61696e, 0x43707542, 0x00000000, 0x00000000, 0x74637073, 0x6567496e, - 0x00000000, 0x53774576, 0x656e7430, 0x00000000, 0x00000000, 0x00000000, - 0x00000000 + 0x4d61696e, 0x43707542, 0x00000000, 0x4d61696e, 0x43707541, + 0x00000000, 0x00000000, 0x00000000, 0x73746b6f, 0x66666c64, + 0x496e0000, 0x73746b6f, 0x66662a2a, 0x00000000, 0x53774576, + 0x656e7430, 0x00000000, 0x00000000, 0x00000000, 0x00000000, + 0x66617461, 0x6c457272, 0x00000000, 0x00000000, 0x00000000 }; #if 0 /* All zeros, don't eat up space with it. */ @@ -3785,63 +4206,274 @@ }; #endif +/* 5705 needs a special version of the TSO firmware. */ +#define TG3_TSO5_FW_RELEASE_MAJOR 0x1 +#define TG3_TSO5_FW_RELASE_MINOR 0x1 +#define TG3_TSO5_FW_RELEASE_FIX 0x0 +#define TG3_TSO5_FW_START_ADDR 0x00010000 +#define TG3_TSO5_FW_TEXT_ADDR 0x00010000 +#define TG3_TSO5_FW_TEXT_LEN 0xeb0 +#define TG3_TSO5_FW_RODATA_ADDR 0x00010eb0 +#define TG3_TSO5_FW_RODATA_LEN 0x50 +#define TG3_TSO5_FW_DATA_ADDR 0x00010f20 +#define TG3_TSO5_FW_DATA_LEN 0x20 +#define TG3_TSO5_FW_SBSS_ADDR 0x00010f40 +#define TG3_TSO5_FW_SBSS_LEN 0x28 +#define TG3_TSO5_FW_BSS_ADDR 0x00010f70 +#define TG3_TSO5_FW_BSS_LEN 0x88 + +static u32 tg3Tso5FwText[] = { + 0x0c004003, 0x00000000, 0x00010f30, 0x00000000, 0x10000003, 0x00000000, + 0x0000000d, 0x0000000d, 0x3c1d0001, 0x37bde000, 0x03a0f021, 0x3c100001, + 0x26100000, 0x0c004010, 0x00000000, 0x0000000d, 0x27bdffe0, 0x3c04fefe, + 0xafbf0018, 0x0c0042f0, 0x34840002, 0x0c00436c, 0x00000000, 0x3c030001, + 0x90630f54, 0x24020002, 0x3c040001, 0x24840ebc, 0x14620003, 0x24050001, + 0x3c040001, 0x24840eb0, 0x24060001, 0x00003821, 0xafa00010, 0x0c004380, + 0xafa00014, 0x0c00402c, 0x00000000, 0x8fbf0018, 0x03e00008, 0x27bd0020, + 0x00000000, 0x00000000, 0x27bdffe0, 0xafbf001c, 0xafb20018, 0xafb10014, + 0x0c0042d3, 0xafb00010, 0x3c128000, 0x24110001, 0x8f706810, 0x32020400, + 0x10400007, 0x00000000, 0x8f641008, 0x00921024, 0x14400003, 0x00000000, + 0x0c004064, 0x00000000, 0x3c020001, 0x90420f76, 0x10510003, 0x32020200, + 0x1040fff1, 0x00000000, 0x0c0041b4, 0x00000000, 0x08004034, 0x00000000, + 0x8fbf001c, 0x8fb20018, 0x8fb10014, 0x8fb00010, 0x03e00008, 0x27bd0020, + 0x27bdffe0, 0x3c040001, 0x24840ed0, 0x00002821, 0x00003021, 0x00003821, + 0xafbf0018, 0xafa00010, 0x0c004380, 0xafa00014, 0x0000d021, 0x24020130, + 0xaf625000, 0x3c010001, 0xa4200f70, 0x3c010001, 0xa0200f77, 0x8fbf0018, + 0x03e00008, 0x27bd0020, 0x00000000, 0x00000000, 0x3c030001, 0x24630f80, + 0x90620000, 0x27bdfff0, 0x14400003, 0x0080c021, 0x08004073, 0x00004821, + 0x3c022000, 0x03021024, 0x10400003, 0x24090002, 0x08004073, 0xa0600000, + 0x24090001, 0x00181040, 0x30431f80, 0x346f8008, 0x1520004b, 0x25eb0028, + 0x3c040001, 0x00832021, 0x8c848010, 0x3c050001, 0x24a50f9a, 0x00041402, + 0xa0a20000, 0x3c010001, 0xa0240f9b, 0x3c020001, 0x00431021, 0x94428014, + 0x3c010001, 0xa0220f9c, 0x3c0c0001, 0x01836021, 0x8d8c8018, 0x304200ff, + 0x24420008, 0x000220c3, 0x24020001, 0x3c010001, 0xa0220f80, 0x0124102b, + 0x1040000c, 0x00003821, 0x24a6000e, 0x01602821, 0x8ca20000, 0x8ca30004, + 0x24a50008, 0x24e70001, 0xacc20000, 0xacc30004, 0x00e4102b, 0x1440fff8, + 0x24c60008, 0x00003821, 0x3c080001, 0x25080f9b, 0x91060000, 0x3c020001, + 0x90420f9c, 0x2503000d, 0x00c32821, 0x00461023, 0x00021fc2, 0x00431021, + 0x00021043, 0x1840000c, 0x00002021, 0x91020001, 0x00461023, 0x00021fc2, + 0x00431021, 0x00021843, 0x94a20000, 0x24e70001, 0x00822021, 0x00e3102a, + 0x1440fffb, 0x24a50002, 0x00041c02, 0x3082ffff, 0x00622021, 0x00041402, + 0x00822021, 0x3c02ffff, 0x01821024, 0x3083ffff, 0x00431025, 0x3c010001, + 0x080040fa, 0xac220fa0, 0x3c050001, 0x24a50f9c, 0x90a20000, 0x3c0c0001, + 0x01836021, 0x8d8c8018, 0x000220c2, 0x1080000e, 0x00003821, 0x01603021, + 0x24a5000c, 0x8ca20000, 0x8ca30004, 0x24a50008, 0x24e70001, 0xacc20000, + 0xacc30004, 0x00e4102b, 0x1440fff8, 0x24c60008, 0x3c050001, 0x24a50f9c, + 0x90a20000, 0x30430007, 0x24020004, 0x10620011, 0x28620005, 0x10400005, + 0x24020002, 0x10620008, 0x000710c0, 0x080040fa, 0x00000000, 0x24020006, + 0x1062000e, 0x000710c0, 0x080040fa, 0x00000000, 0x00a21821, 0x9463000c, + 0x004b1021, 0x080040fa, 0xa4430000, 0x000710c0, 0x00a21821, 0x8c63000c, + 0x004b1021, 0x080040fa, 0xac430000, 0x00a21821, 0x8c63000c, 0x004b2021, + 0x00a21021, 0xac830000, 0x94420010, 0xa4820004, 0x95e70006, 0x3c020001, + 0x90420f9c, 0x3c030001, 0x90630f9a, 0x00e2c823, 0x3c020001, 0x90420f9b, + 0x24630028, 0x01e34021, 0x24420028, 0x15200012, 0x01e23021, 0x94c2000c, + 0x3c010001, 0xa4220f98, 0x94c20004, 0x94c30006, 0x3c010001, 0xa4200f96, + 0x3c010001, 0xa4200f92, 0x00021400, 0x00431025, 0x3c010001, 0xac220f8c, + 0x95020004, 0x3c010001, 0x08004124, 0xa4220f90, 0x3c020001, 0x94420f90, + 0x3c030001, 0x94630f92, 0x00431021, 0xa5020004, 0x3c020001, 0x94420f8c, + 0xa4c20004, 0x3c020001, 0x8c420f8c, 0xa4c20006, 0x3c040001, 0x94840f92, + 0x3c020001, 0x94420f90, 0x3c0a0001, 0x954a0f96, 0x00441821, 0x3063ffff, + 0x0062182a, 0x24020002, 0x1122000b, 0x00832023, 0x3c030001, 0x94630f98, + 0x30620009, 0x10400006, 0x3062fff6, 0xa4c2000c, 0x3c020001, 0x94420f98, + 0x30420009, 0x01425023, 0x24020001, 0x1122001b, 0x29220002, 0x50400005, + 0x24020002, 0x11200007, 0x31a2ffff, 0x08004197, 0x00000000, 0x1122001d, + 0x24020016, 0x08004197, 0x31a2ffff, 0x3c0e0001, 0x95ce0fa0, 0x10800005, + 0x01806821, 0x01c42021, 0x00041c02, 0x3082ffff, 0x00627021, 0x000e1027, + 0xa502000a, 0x3c030001, 0x90630f9b, 0x31a2ffff, 0x00e21021, 0x0800418d, + 0x00432023, 0x3c020001, 0x94420fa0, 0x00442021, 0x00041c02, 0x3082ffff, + 0x00622021, 0x00807021, 0x00041027, 0x08004185, 0xa502000a, 0x3c050001, + 0x24a50f9a, 0x90a30000, 0x14620002, 0x24e2fff2, 0xa5e20034, 0x90a20000, + 0x00e21023, 0xa5020002, 0x3c030001, 0x94630fa0, 0x3c020001, 0x94420f7a, + 0x30e5ffff, 0x00641821, 0x00451023, 0x00622023, 0x00041c02, 0x3082ffff, + 0x00622021, 0x00041027, 0xa502000a, 0x3c030001, 0x90630f9c, 0x24620001, + 0x14a20005, 0x00807021, 0x01631021, 0x90420000, 0x08004185, 0x00026200, + 0x24620002, 0x14a20003, 0x306200fe, 0x004b1021, 0x944c0000, 0x3c020001, + 0x94420fa2, 0x3183ffff, 0x3c040001, 0x90840f9b, 0x00431021, 0x00e21021, + 0x00442023, 0x008a2021, 0x00041c02, 0x3082ffff, 0x00622021, 0x00041402, + 0x00822021, 0x00806821, 0x00041027, 0xa4c20010, 0x31a2ffff, 0x000e1c00, + 0x00431025, 0x3c040001, 0x24840f92, 0xade20010, 0x94820000, 0x3c050001, + 0x94a50f96, 0x3c030001, 0x8c630f8c, 0x24420001, 0x00b92821, 0xa4820000, + 0x3322ffff, 0x00622021, 0x0083182b, 0x3c010001, 0xa4250f96, 0x10600003, + 0x24a2ffff, 0x3c010001, 0xa4220f96, 0x3c024000, 0x03021025, 0x3c010001, + 0xac240f8c, 0xaf621008, 0x03e00008, 0x27bd0010, 0x3c030001, 0x90630f76, + 0x27bdffe8, 0x24020001, 0xafbf0014, 0x10620026, 0xafb00010, 0x8f620cf4, + 0x2442ffff, 0x3042007f, 0x00021100, 0x8c434000, 0x3c010001, 0xac230f84, + 0x8c434008, 0x24444000, 0x8c5c4004, 0x30620040, 0x14400002, 0x24020088, + 0x24020008, 0x3c010001, 0xa4220f88, 0x30620004, 0x10400005, 0x24020001, + 0x3c010001, 0xa0220f77, 0x080041d5, 0x00031402, 0x3c010001, 0xa0200f77, + 0x00031402, 0x3c010001, 0xa4220f74, 0x9483000c, 0x24020001, 0x3c010001, + 0xa4200f70, 0x3c010001, 0xa0220f76, 0x3c010001, 0xa4230f82, 0x24020001, + 0x1342001e, 0x00000000, 0x13400005, 0x24020003, 0x13420067, 0x00000000, + 0x080042cf, 0x00000000, 0x3c020001, 0x94420f82, 0x241a0001, 0x3c010001, + 0xa4200f7e, 0x3c010001, 0xa4200f72, 0x304407ff, 0x00021bc2, 0x00031823, + 0x3063003e, 0x34630036, 0x00021242, 0x3042003c, 0x00621821, 0x3c010001, + 0xa4240f78, 0x00832021, 0x24630030, 0x3c010001, 0xa4240f7a, 0x3c010001, + 0xa4230f7c, 0x3c060001, 0x24c60f72, 0x94c50000, 0x94c30002, 0x3c040001, + 0x94840f7a, 0x00651021, 0x0044102a, 0x10400013, 0x3c108000, 0x00a31021, + 0xa4c20000, 0x3c02a000, 0xaf620cf4, 0x3c010001, 0xa0200f76, 0x8f641008, + 0x00901024, 0x14400003, 0x00000000, 0x0c004064, 0x00000000, 0x8f620cf4, + 0x00501024, 0x104000b7, 0x00000000, 0x0800420f, 0x00000000, 0x3c030001, + 0x94630f70, 0x00851023, 0xa4c40000, 0x00621821, 0x3042ffff, 0x3c010001, + 0xa4230f70, 0xaf620ce8, 0x3c020001, 0x94420f88, 0x34420024, 0xaf620cec, + 0x94c30002, 0x3c020001, 0x94420f70, 0x14620012, 0x3c028000, 0x3c108000, + 0x3c02a000, 0xaf620cf4, 0x3c010001, 0xa0200f76, 0x8f641008, 0x00901024, + 0x14400003, 0x00000000, 0x0c004064, 0x00000000, 0x8f620cf4, 0x00501024, + 0x1440fff7, 0x00000000, 0x080042cf, 0x241a0003, 0xaf620cf4, 0x3c108000, + 0x8f641008, 0x00901024, 0x14400003, 0x00000000, 0x0c004064, 0x00000000, + 0x8f620cf4, 0x00501024, 0x1440fff7, 0x00000000, 0x080042cf, 0x241a0003, + 0x3c070001, 0x24e70f70, 0x94e20000, 0x03821021, 0xaf620ce0, 0x3c020001, + 0x8c420f84, 0xaf620ce4, 0x3c050001, 0x94a50f74, 0x94e30000, 0x3c040001, + 0x94840f78, 0x3c020001, 0x94420f7e, 0x00a32823, 0x00822023, 0x30a6ffff, + 0x3083ffff, 0x00c3102b, 0x14400043, 0x00000000, 0x3c020001, 0x94420f7c, + 0x00021400, 0x00621025, 0xaf620ce8, 0x94e20000, 0x3c030001, 0x94630f74, + 0x00441021, 0xa4e20000, 0x3042ffff, 0x14430021, 0x3c020008, 0x3c020001, + 0x90420f77, 0x10400006, 0x3c03000c, 0x3c020001, 0x94420f88, 0x34630624, + 0x0800427c, 0x0000d021, 0x3c020001, 0x94420f88, 0x3c030008, 0x34630624, + 0x00431025, 0xaf620cec, 0x3c108000, 0x3c02a000, 0xaf620cf4, 0x3c010001, + 0xa0200f76, 0x8f641008, 0x00901024, 0x14400003, 0x00000000, 0x0c004064, + 0x00000000, 0x8f620cf4, 0x00501024, 0x10400015, 0x00000000, 0x08004283, + 0x00000000, 0x3c030001, 0x94630f88, 0x34420624, 0x3c108000, 0x00621825, + 0x3c028000, 0xaf630cec, 0xaf620cf4, 0x8f641008, 0x00901024, 0x14400003, + 0x00000000, 0x0c004064, 0x00000000, 0x8f620cf4, 0x00501024, 0x1440fff7, + 0x00000000, 0x3c010001, 0x080042cf, 0xa4200f7e, 0x3c020001, 0x94420f7c, + 0x00021400, 0x00c21025, 0xaf620ce8, 0x3c020001, 0x90420f77, 0x10400009, + 0x3c03000c, 0x3c020001, 0x94420f88, 0x34630624, 0x0000d021, 0x00431025, + 0xaf620cec, 0x080042c1, 0x3c108000, 0x3c020001, 0x94420f88, 0x3c030008, + 0x34630604, 0x00431025, 0xaf620cec, 0x3c020001, 0x94420f7e, 0x00451021, + 0x3c010001, 0xa4220f7e, 0x3c108000, 0x3c02a000, 0xaf620cf4, 0x3c010001, + 0xa0200f76, 0x8f641008, 0x00901024, 0x14400003, 0x00000000, 0x0c004064, + 0x00000000, 0x8f620cf4, 0x00501024, 0x1440fff7, 0x00000000, 0x8fbf0014, + 0x8fb00010, 0x03e00008, 0x27bd0018, 0x27bdffe0, 0x3c040001, 0x24840ee0, + 0x00002821, 0x00003021, 0x00003821, 0xafbf0018, 0xafa00010, 0x0c004380, + 0xafa00014, 0x0000d021, 0x24020130, 0xaf625000, 0x3c010001, 0xa4200f70, + 0x3c010001, 0xa0200f77, 0x8f636804, 0x3c020001, 0x3442e000, 0x00621824, + 0x3c020001, 0x14620003, 0x00000000, 0x080042eb, 0x00000000, 0x8fbf0018, + 0x03e00008, 0x27bd0020, 0x27bdffe8, 0x3c1bc000, 0xafbf0014, 0xafb00010, + 0xaf60680c, 0x8f626804, 0x34420082, 0xaf626804, 0x8f634000, 0x24020b50, + 0x3c010001, 0xac220f40, 0x24020b78, 0x3c010001, 0xac220f50, 0x34630002, + 0xaf634000, 0x0c00431d, 0x00808021, 0x3c010001, 0xa0220f54, 0x304200ff, + 0x24030002, 0x14430005, 0x00000000, 0x3c020001, 0x8c420f40, 0x08004310, + 0xac5000c0, 0x3c020001, 0x8c420f40, 0xac5000bc, 0x8f624434, 0x8f634438, + 0x8f644410, 0x3c010001, 0xac220f48, 0x3c010001, 0xac230f58, 0x3c010001, + 0xac240f44, 0x8fbf0014, 0x8fb00010, 0x03e00008, 0x27bd0018, 0x03e00008, + 0x24020001, 0x27bdfff8, 0x18800009, 0x00002821, 0x8f63680c, 0x8f62680c, + 0x1043fffe, 0x00000000, 0x24a50001, 0x00a4102a, 0x1440fff9, 0x00000000, + 0x03e00008, 0x27bd0008, 0x8f634450, 0x3c020001, 0x8c420f48, 0x00031c02, + 0x0043102b, 0x14400008, 0x3c038000, 0x3c040001, 0x8c840f58, 0x8f624450, + 0x00021c02, 0x0083102b, 0x1040fffc, 0x3c038000, 0xaf634444, 0x8f624444, + 0x00431024, 0x1440fffd, 0x00000000, 0x8f624448, 0x03e00008, 0x3042ffff, + 0x3082ffff, 0x2442e000, 0x2c422001, 0x14400003, 0x3c024000, 0x0800434f, + 0x2402ffff, 0x00822025, 0xaf645c38, 0x8f625c30, 0x30420002, 0x1440fffc, + 0x00001021, 0x03e00008, 0x00000000, 0x8f624450, 0x3c030001, 0x8c630f44, + 0x08004358, 0x3042ffff, 0x8f624450, 0x3042ffff, 0x0043102b, 0x1440fffc, + 0x00000000, 0x03e00008, 0x00000000, 0x27bdffe0, 0x00802821, 0x3c040001, + 0x24840ef0, 0x00003021, 0x00003821, 0xafbf0018, 0xafa00010, 0x0c004380, + 0xafa00014, 0x08004367, 0x00000000, 0x8fbf0018, 0x03e00008, 0x27bd0020, + 0x3c020001, 0x3442d600, 0x3c030001, 0x3463d600, 0x3c040001, 0x3484ddff, + 0x3c010001, 0xac220f60, 0x24020040, 0x3c010001, 0xac220f64, 0x3c010001, + 0xac200f5c, 0xac600000, 0x24630004, 0x0083102b, 0x5040fffd, 0xac600000, + 0x03e00008, 0x00000000, 0x00804821, 0x8faa0010, 0x3c020001, 0x8c420f5c, + 0x3c040001, 0x8c840f64, 0x8fab0014, 0x24430001, 0x0044102b, 0x3c010001, + 0xac230f5c, 0x14400003, 0x00004021, 0x3c010001, 0xac200f5c, 0x3c020001, + 0x8c420f5c, 0x3c030001, 0x8c630f60, 0x91240000, 0x00021140, 0x00431021, + 0x00481021, 0x25080001, 0xa0440000, 0x29020008, 0x1440fff4, 0x25290001, + 0x3c020001, 0x8c420f5c, 0x3c030001, 0x8c630f60, 0x8f64680c, 0x00021140, + 0x00431021, 0xac440008, 0xac45000c, 0xac460010, 0xac470014, 0xac4a0018, + 0x03e00008, 0xac4b001c, 0x00000000, 0x00000000, +}; + +u32 tg3Tso5FwRodata[] = { + 0x4d61696e, 0x43707542, 0x00000000, 0x4d61696e, 0x43707541, 0x00000000, + 0x00000000, 0x00000000, 0x73746b6f, 0x66666c64, 0x00000000, 0x00000000, + 0x73746b6f, 0x66666c64, 0x00000000, 0x00000000, 0x66617461, 0x6c457272, + 0x00000000, 0x00000000, 0x00000000 +}; + +u32 tg3Tso5FwData[] = { + 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x73746b6f, + 0x66666c64, 0x5f76312e, 0x312e3000, 0x00000000 +}; + /* tp->lock is held. */ static int tg3_load_tso_firmware(struct tg3 *tp) { struct fw_info info; + unsigned long cpu_base, cpu_scratch_base, cpu_scratch_size; int err, i; - info.text_base = TG3_TSO_FW_TEXT_ADDR; - info.text_len = TG3_TSO_FW_TEXT_LEN; - info.text_data = &tg3TsoFwText[0]; - info.rodata_base = TG3_TSO_FW_RODATA_ADDR; - info.rodata_len = TG3_TSO_FW_RODATA_LEN; - info.rodata_data = &tg3TsoFwRodata[0]; - info.data_base = TG3_TSO_FW_DATA_ADDR; - info.data_len = TG3_TSO_FW_DATA_LEN; - info.data_data = NULL; + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) { + info.text_base = TG3_TSO5_FW_TEXT_ADDR; + info.text_len = TG3_TSO5_FW_TEXT_LEN; + info.text_data = &tg3Tso5FwText[0]; + info.rodata_base = TG3_TSO5_FW_RODATA_ADDR; + info.rodata_len = TG3_TSO5_FW_RODATA_LEN; + info.rodata_data = &tg3Tso5FwRodata[0]; + info.data_base = TG3_TSO5_FW_DATA_ADDR; + info.data_len = TG3_TSO5_FW_DATA_LEN; + info.data_data = &tg3Tso5FwData[0]; + cpu_base = RX_CPU_BASE; + cpu_scratch_base = NIC_SRAM_MBUF_POOL_BASE5705; + cpu_scratch_size = (info.text_len + + info.rodata_len + + info.data_len + + TG3_TSO5_FW_SBSS_LEN + + TG3_TSO5_FW_BSS_LEN); + } else { + info.text_base = TG3_TSO_FW_TEXT_ADDR; + info.text_len = TG3_TSO_FW_TEXT_LEN; + info.text_data = &tg3TsoFwText[0]; + info.rodata_base = TG3_TSO_FW_RODATA_ADDR; + info.rodata_len = TG3_TSO_FW_RODATA_LEN; + info.rodata_data = &tg3TsoFwRodata[0]; + info.data_base = TG3_TSO_FW_DATA_ADDR; + info.data_len = TG3_TSO_FW_DATA_LEN; + info.data_data = NULL; + cpu_base = TX_CPU_BASE; + cpu_scratch_base = TX_CPU_SCRATCH_BASE; + cpu_scratch_size = TX_CPU_SCRATCH_SIZE; + } - err = tg3_load_firmware_cpu(tp, TX_CPU_BASE, - TX_CPU_SCRATCH_BASE, TX_CPU_SCRATCH_SIZE, + err = tg3_load_firmware_cpu(tp, cpu_base, + cpu_scratch_base, cpu_scratch_size, &info); if (err) return err; - /* Now startup only the TX cpu. */ - tw32(TX_CPU_BASE + CPU_STATE, 0xffffffff); - tw32(TX_CPU_BASE + CPU_PC, TG3_TSO_FW_TEXT_ADDR); + /* Now startup the cpu. */ + tw32(cpu_base + CPU_STATE, 0xffffffff); + tw32(cpu_base + CPU_PC, info.text_base); /* Flush posted writes. */ - tr32(TX_CPU_BASE + CPU_PC); + tr32(cpu_base + CPU_PC); for (i = 0; i < 5; i++) { - if (tr32(TX_CPU_BASE + CPU_PC) == TG3_TSO_FW_TEXT_ADDR) + if (tr32(cpu_base + CPU_PC) == info.text_base) break; - tw32(TX_CPU_BASE + CPU_STATE, 0xffffffff); - tw32(TX_CPU_BASE + CPU_MODE, CPU_MODE_HALT); - tw32(TX_CPU_BASE + CPU_PC, TG3_TSO_FW_TEXT_ADDR); + tw32(cpu_base + CPU_STATE, 0xffffffff); + tw32(cpu_base + CPU_MODE, CPU_MODE_HALT); + tw32(cpu_base + CPU_PC, info.text_base); /* Flush posted writes. */ - tr32(TX_CPU_BASE + CPU_PC); + tr32(cpu_base + CPU_PC); udelay(1000); } if (i >= 5) { printk(KERN_ERR PFX "tg3_load_tso_firmware fails for %s " - "to set TX CPU PC, is %08x should be %08x\n", - tp->dev->name, tr32(TX_CPU_BASE + CPU_PC), - TG3_TSO_FW_TEXT_ADDR); + "to set CPU PC, is %08x should be %08x\n", + tp->dev->name, tr32(cpu_base + CPU_PC), + info.text_base); return -ENODEV; } - tw32(TX_CPU_BASE + CPU_STATE, 0xffffffff); - tw32(TX_CPU_BASE + CPU_MODE, 0x00000000); + tw32(cpu_base + CPU_STATE, 0xffffffff); + tw32(cpu_base + CPU_MODE, 0x00000000); /* Flush posted writes. */ - tr32(TX_CPU_BASE + CPU_MODE); + tr32(cpu_base + CPU_MODE); return 0; } -#endif /* TG3_DO_TSO != 0 */ +#endif /* TG3_TSO_SUPPORT != 0 */ /* tp->lock is held. */ static void __tg3_set_mac_addr(struct tg3 *tp) @@ -3860,6 +4492,15 @@ tw32(MAC_ADDR_0_LOW + (i * 8), addr_low); } + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5700 && + GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5701 && + GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705) { + for (i = 0; i < 12; i++) { + tw32(MAC_EXTADDR_0_HIGH + (i * 8), addr_high); + tw32(MAC_EXTADDR_0_LOW + (i * 8), addr_low); + } + } + addr_high = (tp->dev->dev_addr[0] + tp->dev->dev_addr[1] + tp->dev->dev_addr[2] + @@ -3893,23 +4534,19 @@ u32 nic_addr) { tg3_write_mem(tp, - (bdinfo_addr + - TG3_BDINFO_HOST_ADDR + - TG3_64BIT_REG_HIGH), + (bdinfo_addr + TG3_BDINFO_HOST_ADDR + TG3_64BIT_REG_HIGH), ((u64) mapping >> 32)); tg3_write_mem(tp, - (bdinfo_addr + - TG3_BDINFO_HOST_ADDR + - TG3_64BIT_REG_LOW), + (bdinfo_addr + TG3_BDINFO_HOST_ADDR + TG3_64BIT_REG_LOW), ((u64) mapping & 0xffffffff)); tg3_write_mem(tp, - (bdinfo_addr + - TG3_BDINFO_MAXLEN_FLAGS), + (bdinfo_addr + TG3_BDINFO_MAXLEN_FLAGS), maxlen_flags); - tg3_write_mem(tp, - (bdinfo_addr + - TG3_BDINFO_NIC_ADDR), - nic_addr); + + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705) + tg3_write_mem(tp, + (bdinfo_addr + TG3_BDINFO_NIC_ADDR), + nic_addr); } static void __tg3_set_rx_mode(struct net_device *); @@ -3917,8 +4554,8 @@ /* tp->lock is held. */ static int tg3_reset_hw(struct tg3 *tp) { - u32 val; - int i, err; + u32 val, rdmac_mode; + int i, err, limit; tg3_disable_ints(tp); @@ -3970,9 +4607,8 @@ * B3 tigon3 silicon. This bit has no effect on any * other revision. */ - val = tr32(TG3PCI_CLOCK_CTRL); - val |= CLOCK_CTRL_DELAY_PCI_GRANT; - tw32(TG3PCI_CLOCK_CTRL, val); + tp->pci_clock_ctrl |= CLOCK_CTRL_DELAY_PCI_GRANT; + tw32(TG3PCI_CLOCK_CTRL, tp->pci_clock_ctrl); tr32(TG3PCI_CLOCK_CTRL); if (tp->pci_chip_rev_id == CHIPREV_ID_5704_A0 && @@ -3990,11 +4626,13 @@ tg3_init_rings(tp); /* Clear statistics/status block in chip, and status block in ram. */ - for (i = NIC_SRAM_STATS_BLK; - i < NIC_SRAM_STATUS_BLK + TG3_HW_STATUS_SIZE; - i += sizeof(u32)) { - tg3_write_mem(tp, i, 0); - udelay(40); + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705) { + for (i = NIC_SRAM_STATS_BLK; + i < NIC_SRAM_STATUS_BLK + TG3_HW_STATUS_SIZE; + i += sizeof(u32)) { + tg3_write_mem(tp, i, 0); + udelay(40); + } } memset(tp->hw_status, 0, TG3_HW_STATUS_SIZE); @@ -4025,13 +4663,31 @@ (65 << GRC_MISC_CFG_PRESCALAR_SHIFT)); /* Initialize MBUF/DESC pool. */ - tw32(BUFMGR_MB_POOL_ADDR, NIC_SRAM_MBUF_POOL_BASE); - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5704) - tw32(BUFMGR_MB_POOL_SIZE, NIC_SRAM_MBUF_POOL_SIZE64); - else - tw32(BUFMGR_MB_POOL_SIZE, NIC_SRAM_MBUF_POOL_SIZE96); - tw32(BUFMGR_DMA_DESC_POOL_ADDR, NIC_SRAM_DMA_DESC_POOL_BASE); - tw32(BUFMGR_DMA_DESC_POOL_SIZE, NIC_SRAM_DMA_DESC_POOL_SIZE); + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705) { + tw32(BUFMGR_MB_POOL_ADDR, NIC_SRAM_MBUF_POOL_BASE); + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5704) + tw32(BUFMGR_MB_POOL_SIZE, NIC_SRAM_MBUF_POOL_SIZE64); + else + tw32(BUFMGR_MB_POOL_SIZE, NIC_SRAM_MBUF_POOL_SIZE96); + tw32(BUFMGR_DMA_DESC_POOL_ADDR, NIC_SRAM_DMA_DESC_POOL_BASE); + tw32(BUFMGR_DMA_DESC_POOL_SIZE, NIC_SRAM_DMA_DESC_POOL_SIZE); + } +#if TG3_TSO_SUPPORT != 0 + else if (tp->tg3_flags2 & TG3_FLG2_TSO_CAPABLE) { + int fw_len; + + fw_len = (TG3_TSO5_FW_TEXT_LEN + + TG3_TSO5_FW_RODATA_LEN + + TG3_TSO5_FW_DATA_LEN + + TG3_TSO5_FW_SBSS_LEN + + TG3_TSO5_FW_BSS_LEN); + fw_len = (fw_len + (0x80 - 1)) & ~(0x80 - 1); + tw32(BUFMGR_MB_POOL_ADDR, + NIC_SRAM_MBUF_POOL_BASE5705 + fw_len); + tw32(BUFMGR_MB_POOL_SIZE, + NIC_SRAM_MBUF_POOL_SIZE5705 - fw_len - 0xa00); + } +#endif if (!(tp->tg3_flags & TG3_FLAG_JUMBO_ENABLE)) { tw32(BUFMGR_MB_RDMA_LOW_WATER, @@ -4078,6 +4734,9 @@ return -ENODEV; } + /* Setup replenish threshold. */ + tw32(RCVBDI_STD_THRESH, tp->rx_pending / 8); + /* Initialize TG3_BDINFO's at: * RCVDBDI_STD_BD: standard eth size rx ring * RCVDBDI_JUMBO_BD: jumbo frame rx ring @@ -4099,35 +4758,50 @@ ((u64) tp->rx_std_mapping >> 32)); tw32(RCVDBDI_STD_BD + TG3_BDINFO_HOST_ADDR + TG3_64BIT_REG_LOW, ((u64) tp->rx_std_mapping & 0xffffffff)); - tw32(RCVDBDI_STD_BD + TG3_BDINFO_MAXLEN_FLAGS, - RX_STD_MAX_SIZE << BDINFO_FLAGS_MAXLEN_SHIFT); tw32(RCVDBDI_STD_BD + TG3_BDINFO_NIC_ADDR, NIC_SRAM_RX_BUFFER_DESC); - tw32(RCVDBDI_MINI_BD + TG3_BDINFO_MAXLEN_FLAGS, - BDINFO_FLAGS_DISABLED); - - if (tp->tg3_flags & TG3_FLAG_JUMBO_ENABLE) { - tw32(RCVDBDI_JUMBO_BD + TG3_BDINFO_HOST_ADDR + TG3_64BIT_REG_HIGH, - ((u64) tp->rx_jumbo_mapping >> 32)); - tw32(RCVDBDI_JUMBO_BD + TG3_BDINFO_HOST_ADDR + TG3_64BIT_REG_LOW, - ((u64) tp->rx_jumbo_mapping & 0xffffffff)); - tw32(RCVDBDI_JUMBO_BD + TG3_BDINFO_MAXLEN_FLAGS, - RX_JUMBO_MAX_SIZE << BDINFO_FLAGS_MAXLEN_SHIFT); - tw32(RCVDBDI_JUMBO_BD + TG3_BDINFO_NIC_ADDR, - NIC_SRAM_RX_JUMBO_BUFFER_DESC); + /* Don't even try to program the JUMBO/MINI buffer descriptor + * configs on 5705. + */ + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) { + tw32(RCVDBDI_STD_BD + TG3_BDINFO_MAXLEN_FLAGS, + RX_STD_MAX_SIZE_5705 << BDINFO_FLAGS_MAXLEN_SHIFT); } else { - tw32(RCVDBDI_JUMBO_BD + TG3_BDINFO_MAXLEN_FLAGS, + tw32(RCVDBDI_STD_BD + TG3_BDINFO_MAXLEN_FLAGS, + RX_STD_MAX_SIZE << BDINFO_FLAGS_MAXLEN_SHIFT); + + tw32(RCVDBDI_MINI_BD + TG3_BDINFO_MAXLEN_FLAGS, BDINFO_FLAGS_DISABLED); - } - /* Setup replenish thresholds. */ - tw32(RCVBDI_STD_THRESH, tp->rx_pending / 8); - tw32(RCVBDI_JUMBO_THRESH, tp->rx_jumbo_pending / 8); + /* Setup replenish threshold. */ + tw32(RCVBDI_JUMBO_THRESH, tp->rx_jumbo_pending / 8); - /* Clear out send RCB ring in SRAM. */ - for (i = NIC_SRAM_SEND_RCB; i < NIC_SRAM_RCV_RET_RCB; i += TG3_BDINFO_SIZE) - tg3_write_mem(tp, i + TG3_BDINFO_MAXLEN_FLAGS, BDINFO_FLAGS_DISABLED); + if (tp->tg3_flags & TG3_FLAG_JUMBO_ENABLE) { + tw32(RCVDBDI_JUMBO_BD + TG3_BDINFO_HOST_ADDR + TG3_64BIT_REG_HIGH, + ((u64) tp->rx_jumbo_mapping >> 32)); + tw32(RCVDBDI_JUMBO_BD + TG3_BDINFO_HOST_ADDR + TG3_64BIT_REG_LOW, + ((u64) tp->rx_jumbo_mapping & 0xffffffff)); + tw32(RCVDBDI_JUMBO_BD + TG3_BDINFO_MAXLEN_FLAGS, + RX_JUMBO_MAX_SIZE << BDINFO_FLAGS_MAXLEN_SHIFT); + tw32(RCVDBDI_JUMBO_BD + TG3_BDINFO_NIC_ADDR, + NIC_SRAM_RX_JUMBO_BUFFER_DESC); + } else { + tw32(RCVDBDI_JUMBO_BD + TG3_BDINFO_MAXLEN_FLAGS, + BDINFO_FLAGS_DISABLED); + } + + } + + /* There is only one send ring on 5705, no need to explicitly + * disable the others. + */ + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705) { + /* Clear out send RCB ring in SRAM. */ + for (i = NIC_SRAM_SEND_RCB; i < NIC_SRAM_RCV_RET_RCB; i += TG3_BDINFO_SIZE) + tg3_write_mem(tp, i + TG3_BDINFO_MAXLEN_FLAGS, + BDINFO_FLAGS_DISABLED); + } tp->tx_prod = 0; tp->tx_cons = 0; @@ -4149,9 +4823,15 @@ NIC_SRAM_TX_BUFFER_DESC); } - for (i = NIC_SRAM_RCV_RET_RCB; i < NIC_SRAM_STATS_BLK; i += TG3_BDINFO_SIZE) { - tg3_write_mem(tp, i + TG3_BDINFO_MAXLEN_FLAGS, - BDINFO_FLAGS_DISABLED); + /* There is only one receive return ring on 5705, no need to explicitly + * disable the others. + */ + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705) { + for (i = NIC_SRAM_RCV_RET_RCB; i < NIC_SRAM_STATS_BLK; + i += TG3_BDINFO_SIZE) { + tg3_write_mem(tp, i + TG3_BDINFO_MAXLEN_FLAGS, + BDINFO_FLAGS_DISABLED); + } } tp->rx_rcb_ptr = 0; @@ -4161,7 +4841,7 @@ tg3_set_bdinfo(tp, NIC_SRAM_RCV_RET_RCB, tp->rx_rcb_mapping, - (TG3_RX_RCB_RING_SIZE << + (TG3_RX_RCB_RING_SIZE(tp) << BDINFO_FLAGS_MAXLEN_SHIFT), 0); @@ -4198,8 +4878,36 @@ tw32(MAC_RCV_RULE_CFG, RCV_RULE_CFG_DEFAULT_CLASS); tw32(RCVLPC_CONFIG, 0x0181); + /* Calculate RDMAC_MODE setting early, we need it to determine + * the RCVLPC_STATE_ENABLE mask. + */ + rdmac_mode = (RDMAC_MODE_ENABLE | RDMAC_MODE_TGTABORT_ENAB | + RDMAC_MODE_MSTABORT_ENAB | RDMAC_MODE_PARITYERR_ENAB | + RDMAC_MODE_ADDROFLOW_ENAB | RDMAC_MODE_FIFOOFLOW_ENAB | + RDMAC_MODE_FIFOURUN_ENAB | RDMAC_MODE_FIFOOREAD_ENAB | + RDMAC_MODE_LNGREAD_ENAB); + if (tp->tg3_flags & TG3_FLAG_SPLIT_MODE) + rdmac_mode |= RDMAC_MODE_SPLIT_ENABLE; + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) { + if (tp->pci_chip_rev_id != CHIPREV_ID_5705_A0) { + if (tp->tg3_flags2 & TG3_FLG2_TSO_CAPABLE) { + rdmac_mode |= RDMAC_MODE_FIFO_SIZE_128; + } else if (!(tr32(TG3PCI_PCISTATE) & PCISTATE_BUS_SPEED_HIGH) && + !(tp->tg3_flags2 & TG3_FLG2_IS_5788)) { + rdmac_mode |= RDMAC_MODE_FIFO_LONG_BURST; + } + } + } + /* Receive/send statistics. */ - tw32(RCVLPC_STATS_ENABLE, 0xffffff); + if ((rdmac_mode & RDMAC_MODE_FIFO_SIZE_128) && + (tp->tg3_flags2 & TG3_FLG2_TSO_CAPABLE)) { + val = tr32(RCVLPC_STATS_ENABLE); + val &= ~RCVLPC_STATSENAB_LNGBRST_RFIX; + tw32(RCVLPC_STATS_ENABLE, val); + } else { + tw32(RCVLPC_STATS_ENABLE, 0xffffff); + } tw32(RCVLPC_STATSCTRL, RCVLPC_STATSCTRL_ENABLE); tw32(SNDDATAI_STATSENAB, 0xffffff); tw32(SNDDATAI_STATSCTRL, @@ -4215,33 +4923,43 @@ } tw32(HOSTCC_RXCOL_TICKS, 0); - tw32(HOSTCC_RXMAX_FRAMES, 1); - tw32(HOSTCC_RXCOAL_TICK_INT, 0); - tw32(HOSTCC_RXCOAL_MAXF_INT, 1); tw32(HOSTCC_TXCOL_TICKS, LOW_TXCOL_TICKS); + tw32(HOSTCC_RXMAX_FRAMES, 1); tw32(HOSTCC_TXMAX_FRAMES, LOW_RXMAX_FRAMES); - tw32(HOSTCC_TXCOAL_TICK_INT, 0); + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705) + tw32(HOSTCC_RXCOAL_TICK_INT, 0); + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705) + tw32(HOSTCC_TXCOAL_TICK_INT, 0); + tw32(HOSTCC_RXCOAL_MAXF_INT, 1); tw32(HOSTCC_TXCOAL_MAXF_INT, 0); - tw32(HOSTCC_STAT_COAL_TICKS, - DEFAULT_STAT_COAL_TICKS); - /* Status/statistics block address. */ - tw32(HOSTCC_STATS_BLK_HOST_ADDR + TG3_64BIT_REG_HIGH, - ((u64) tp->stats_mapping >> 32)); - tw32(HOSTCC_STATS_BLK_HOST_ADDR + TG3_64BIT_REG_LOW, - ((u64) tp->stats_mapping & 0xffffffff)); + /* set status block DMA address */ tw32(HOSTCC_STATUS_BLK_HOST_ADDR + TG3_64BIT_REG_HIGH, ((u64) tp->status_mapping >> 32)); tw32(HOSTCC_STATUS_BLK_HOST_ADDR + TG3_64BIT_REG_LOW, ((u64) tp->status_mapping & 0xffffffff)); - tw32(HOSTCC_STATS_BLK_NIC_ADDR, NIC_SRAM_STATS_BLK); - tw32(HOSTCC_STATUS_BLK_NIC_ADDR, NIC_SRAM_STATUS_BLK); + + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705) { + /* Status/statistics block address. See tg3_timer, + * the tg3_periodic_fetch_stats call there, and + * tg3_get_stats to see how this works for 5705 chips. + */ + tw32(HOSTCC_STAT_COAL_TICKS, + DEFAULT_STAT_COAL_TICKS); + tw32(HOSTCC_STATS_BLK_HOST_ADDR + TG3_64BIT_REG_HIGH, + ((u64) tp->stats_mapping >> 32)); + tw32(HOSTCC_STATS_BLK_HOST_ADDR + TG3_64BIT_REG_LOW, + ((u64) tp->stats_mapping & 0xffffffff)); + tw32(HOSTCC_STATS_BLK_NIC_ADDR, NIC_SRAM_STATS_BLK); + tw32(HOSTCC_STATUS_BLK_NIC_ADDR, NIC_SRAM_STATUS_BLK); + } tw32(HOSTCC_MODE, HOSTCC_MODE_ENABLE | tp->coalesce_mode); tw32(RCVCC_MODE, RCVCC_MODE_ENABLE | RCVCC_MODE_ATTN_ENABLE); tw32(RCVLPC_MODE, RCVLPC_MODE_ENABLE); - tw32(RCVLSC_MODE, RCVLSC_MODE_ENABLE | RCVLSC_MODE_ATTN_ENABLE); + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705) + tw32(RCVLSC_MODE, RCVLSC_MODE_ENABLE | RCVLSC_MODE_ATTN_ENABLE); tp->mac_mode = MAC_MODE_TXSTAT_ENABLE | MAC_MODE_RXSTAT_ENABLE | MAC_MODE_TDE_ENABLE | MAC_MODE_RDE_ENABLE | MAC_MODE_FHDE_ENABLE; @@ -4260,42 +4978,47 @@ tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, 0); tr32(MAILBOX_INTERRUPT_0); - tw32(DMAC_MODE, DMAC_MODE_ENABLE); - tr32(DMAC_MODE); - udelay(40); + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705) { + tw32(DMAC_MODE, DMAC_MODE_ENABLE); + tr32(DMAC_MODE); + udelay(40); + } - tw32(WDMAC_MODE, (WDMAC_MODE_ENABLE | WDMAC_MODE_TGTABORT_ENAB | - WDMAC_MODE_MSTABORT_ENAB | WDMAC_MODE_PARITYERR_ENAB | - WDMAC_MODE_ADDROFLOW_ENAB | WDMAC_MODE_FIFOOFLOW_ENAB | - WDMAC_MODE_FIFOURUN_ENAB | WDMAC_MODE_FIFOOREAD_ENAB | - WDMAC_MODE_LNGREAD_ENAB)); + val = (WDMAC_MODE_ENABLE | WDMAC_MODE_TGTABORT_ENAB | + WDMAC_MODE_MSTABORT_ENAB | WDMAC_MODE_PARITYERR_ENAB | + WDMAC_MODE_ADDROFLOW_ENAB | WDMAC_MODE_FIFOOFLOW_ENAB | + WDMAC_MODE_FIFOURUN_ENAB | WDMAC_MODE_FIFOOREAD_ENAB | + WDMAC_MODE_LNGREAD_ENAB); + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705 && + (tr32(TG3PCI_PCISTATE) & PCISTATE_BUS_SPEED_HIGH) != 0 && + !(tp->tg3_flags2 & TG3_FLG2_IS_5788)) + val |= WDMAC_MODE_RX_ACCEL; + tw32(WDMAC_MODE, val); tr32(WDMAC_MODE); udelay(40); - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5704 && - (tp->tg3_flags & TG3_FLAG_PCIX_MODE)) { + if ((tp->tg3_flags & TG3_FLAG_PCIX_MODE) != 0) { val = tr32(TG3PCI_X_CAPS); - val &= ~(PCIX_CAPS_SPLIT_MASK | PCIX_CAPS_BURST_MASK); - val |= (PCIX_CAPS_MAX_BURST_5704 << PCIX_CAPS_BURST_SHIFT); - if (tp->tg3_flags & TG3_FLAG_SPLIT_MODE) - val |= (tp->split_mode_max_reqs << - PCIX_CAPS_SPLIT_SHIFT); + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5703) { + val &= ~PCIX_CAPS_BURST_MASK; + val |= (PCIX_CAPS_MAX_BURST_CPIOB << PCIX_CAPS_BURST_SHIFT); + } else if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5704) { + val &= ~(PCIX_CAPS_SPLIT_MASK | PCIX_CAPS_BURST_MASK); + val |= (PCIX_CAPS_MAX_BURST_CPIOB << PCIX_CAPS_BURST_SHIFT); + if (tp->tg3_flags & TG3_FLAG_SPLIT_MODE) + val |= (tp->split_mode_max_reqs << + PCIX_CAPS_SPLIT_SHIFT); + } tw32(TG3PCI_X_CAPS, val); } - val = (RDMAC_MODE_ENABLE | RDMAC_MODE_TGTABORT_ENAB | - RDMAC_MODE_MSTABORT_ENAB | RDMAC_MODE_PARITYERR_ENAB | - RDMAC_MODE_ADDROFLOW_ENAB | RDMAC_MODE_FIFOOFLOW_ENAB | - RDMAC_MODE_FIFOURUN_ENAB | RDMAC_MODE_FIFOOREAD_ENAB | - RDMAC_MODE_LNGREAD_ENAB); - if (tp->tg3_flags & TG3_FLAG_SPLIT_MODE) - val |= RDMAC_MODE_SPLIT_ENABLE; - tw32(RDMAC_MODE, val); + tw32(RDMAC_MODE, rdmac_mode); tr32(RDMAC_MODE); udelay(40); tw32(RCVDCC_MODE, RCVDCC_MODE_ENABLE | RCVDCC_MODE_ATTN_ENABLE); - tw32(MBFREE_MODE, MBFREE_MODE_ENABLE); + if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705) + tw32(MBFREE_MODE, MBFREE_MODE_ENABLE); tw32(SNDDATAC_MODE, SNDDATAC_MODE_ENABLE); tw32(SNDBDC_MODE, SNDBDC_MODE_ENABLE | SNDBDC_MODE_ATTN_ENABLE); tw32(RCVBDI_MODE, RCVBDI_MODE_ENABLE | RCVBDI_MODE_RCB_ATTN_ENAB); @@ -4310,8 +5033,8 @@ return err; } -#if TG3_DO_TSO != 0 - if (tp->dev->features & NETIF_F_TSO) { +#if TG3_TSO_SUPPORT != 0 + if (tp->tg3_flags2 & TG3_FLG2_TSO_CAPABLE) { err = tg3_load_tso_firmware(tp); if (err) return err; @@ -4342,9 +5065,11 @@ tw32(MAC_LED_CTRL, 0); tw32(MAC_MI_STAT, MAC_MI_STAT_LNKSTAT_ATTN_ENAB); - tw32(MAC_RX_MODE, RX_MODE_RESET); - tr32(MAC_RX_MODE); - udelay(10); + if (tp->phy_id == PHY_ID_SERDES) { + tw32(MAC_RX_MODE, RX_MODE_RESET); + tr32(MAC_RX_MODE); + udelay(10); + } tw32(MAC_RX_MODE, tp->rx_mode); tr32(MAC_RX_MODE); udelay(10); @@ -4378,22 +5103,48 @@ tw32(MAC_RCV_VALUE_0, 0xffffffff & RCV_RULE_DISABLE_MASK); tw32(MAC_RCV_RULE_1, 0x86000004 & RCV_RULE_DISABLE_MASK); tw32(MAC_RCV_VALUE_1, 0xffffffff & RCV_RULE_DISABLE_MASK); -#if 0 - tw32(MAC_RCV_RULE_2, 0); tw32(MAC_RCV_VALUE_2, 0); - tw32(MAC_RCV_RULE_3, 0); tw32(MAC_RCV_VALUE_3, 0); -#endif - tw32(MAC_RCV_RULE_4, 0); tw32(MAC_RCV_VALUE_4, 0); - tw32(MAC_RCV_RULE_5, 0); tw32(MAC_RCV_VALUE_5, 0); - tw32(MAC_RCV_RULE_6, 0); tw32(MAC_RCV_VALUE_6, 0); - tw32(MAC_RCV_RULE_7, 0); tw32(MAC_RCV_VALUE_7, 0); - tw32(MAC_RCV_RULE_8, 0); tw32(MAC_RCV_VALUE_8, 0); - tw32(MAC_RCV_RULE_9, 0); tw32(MAC_RCV_VALUE_9, 0); - tw32(MAC_RCV_RULE_10, 0); tw32(MAC_RCV_VALUE_10, 0); - tw32(MAC_RCV_RULE_11, 0); tw32(MAC_RCV_VALUE_11, 0); - tw32(MAC_RCV_RULE_12, 0); tw32(MAC_RCV_VALUE_12, 0); - tw32(MAC_RCV_RULE_13, 0); tw32(MAC_RCV_VALUE_13, 0); - tw32(MAC_RCV_RULE_14, 0); tw32(MAC_RCV_VALUE_14, 0); - tw32(MAC_RCV_RULE_15, 0); tw32(MAC_RCV_VALUE_15, 0); + + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) + limit = 8; + else + limit = 16; + if (tp->tg3_flags & TG3_FLAG_ENABLE_ASF) + limit -= 4; + switch (limit) { + case 16: + tw32(MAC_RCV_RULE_15, 0); tw32(MAC_RCV_VALUE_15, 0); + case 15: + tw32(MAC_RCV_RULE_14, 0); tw32(MAC_RCV_VALUE_14, 0); + case 14: + tw32(MAC_RCV_RULE_13, 0); tw32(MAC_RCV_VALUE_13, 0); + case 13: + tw32(MAC_RCV_RULE_12, 0); tw32(MAC_RCV_VALUE_12, 0); + case 12: + tw32(MAC_RCV_RULE_11, 0); tw32(MAC_RCV_VALUE_11, 0); + case 11: + tw32(MAC_RCV_RULE_10, 0); tw32(MAC_RCV_VALUE_10, 0); + case 10: + tw32(MAC_RCV_RULE_9, 0); tw32(MAC_RCV_VALUE_9, 0); + case 9: + tw32(MAC_RCV_RULE_8, 0); tw32(MAC_RCV_VALUE_8, 0); + case 8: + tw32(MAC_RCV_RULE_7, 0); tw32(MAC_RCV_VALUE_7, 0); + case 7: + tw32(MAC_RCV_RULE_6, 0); tw32(MAC_RCV_VALUE_6, 0); + case 6: + tw32(MAC_RCV_RULE_5, 0); tw32(MAC_RCV_VALUE_5, 0); + case 5: + tw32(MAC_RCV_RULE_4, 0); tw32(MAC_RCV_VALUE_4, 0); + case 4: + /* tw32(MAC_RCV_RULE_3, 0); tw32(MAC_RCV_VALUE_3, 0); */ + case 3: + /* tw32(MAC_RCV_RULE_2, 0); tw32(MAC_RCV_VALUE_2, 0); */ + case 2: + case 1: + + default: + break; + }; if (tp->tg3_flags & TG3_FLAG_INIT_COMPLETE) tg3_enable_ints(tp); @@ -4423,6 +5174,50 @@ return err; } +#define TG3_STAT_ADD32(PSTAT, REG) \ +do { u32 __val = tr32(REG); \ + (PSTAT)->low += __val; \ + if ((PSTAT)->low < __val) \ + (PSTAT)->high += 1; \ +} while (0) + +static void tg3_periodic_fetch_stats(struct tg3 *tp) +{ + struct tg3_hw_stats *sp = tp->hw_stats; + + if (!netif_carrier_ok(tp->dev)) + return; + + TG3_STAT_ADD32(&sp->tx_octets, MAC_TX_STATS_OCTETS); + TG3_STAT_ADD32(&sp->tx_collisions, MAC_TX_STATS_COLLISIONS); + TG3_STAT_ADD32(&sp->tx_xon_sent, MAC_TX_STATS_XON_SENT); + TG3_STAT_ADD32(&sp->tx_xoff_sent, MAC_TX_STATS_XOFF_SENT); + TG3_STAT_ADD32(&sp->tx_mac_errors, MAC_TX_STATS_MAC_ERRORS); + TG3_STAT_ADD32(&sp->tx_single_collisions, MAC_TX_STATS_SINGLE_COLLISIONS); + TG3_STAT_ADD32(&sp->tx_mult_collisions, MAC_TX_STATS_MULT_COLLISIONS); + TG3_STAT_ADD32(&sp->tx_deferred, MAC_TX_STATS_DEFERRED); + TG3_STAT_ADD32(&sp->tx_excessive_collisions, MAC_TX_STATS_EXCESSIVE_COL); + TG3_STAT_ADD32(&sp->tx_late_collisions, MAC_TX_STATS_LATE_COL); + TG3_STAT_ADD32(&sp->tx_ucast_packets, MAC_TX_STATS_UCAST); + TG3_STAT_ADD32(&sp->tx_mcast_packets, MAC_TX_STATS_MCAST); + TG3_STAT_ADD32(&sp->tx_bcast_packets, MAC_TX_STATS_BCAST); + + TG3_STAT_ADD32(&sp->rx_octets, MAC_RX_STATS_OCTETS); + TG3_STAT_ADD32(&sp->rx_fragments, MAC_RX_STATS_FRAGMENTS); + TG3_STAT_ADD32(&sp->rx_ucast_packets, MAC_RX_STATS_UCAST); + TG3_STAT_ADD32(&sp->rx_mcast_packets, MAC_RX_STATS_MCAST); + TG3_STAT_ADD32(&sp->rx_bcast_packets, MAC_RX_STATS_BCAST); + TG3_STAT_ADD32(&sp->rx_fcs_errors, MAC_RX_STATS_FCS_ERRORS); + TG3_STAT_ADD32(&sp->rx_align_errors, MAC_RX_STATS_ALIGN_ERRORS); + TG3_STAT_ADD32(&sp->rx_xon_pause_rcvd, MAC_RX_STATS_XON_PAUSE_RECVD); + TG3_STAT_ADD32(&sp->rx_xoff_pause_rcvd, MAC_RX_STATS_XOFF_PAUSE_RECVD); + TG3_STAT_ADD32(&sp->rx_mac_ctrl_rcvd, MAC_RX_STATS_MAC_CTRL_RECVD); + TG3_STAT_ADD32(&sp->rx_xoff_entered, MAC_RX_STATS_XOFF_ENTERED); + TG3_STAT_ADD32(&sp->rx_frame_too_long_errors, MAC_RX_STATS_FRAME_TOO_LONG); + TG3_STAT_ADD32(&sp->rx_jabbers, MAC_RX_STATS_JABBERS); + TG3_STAT_ADD32(&sp->rx_undersize_packets, MAC_RX_STATS_UNDERSIZE); +} + static void tg3_timer(unsigned long __opaque) { struct tg3 *tp = (struct tg3 *) __opaque; @@ -4451,6 +5246,9 @@ return; } + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) + tg3_periodic_fetch_stats(tp); + /* This part only runs once per second. */ if (!--tp->timer_counter) { if (tp->tg3_flags & TG3_FLAG_USE_LINKCHG_REG) { @@ -4908,7 +5706,9 @@ get_stat64(&hw_stats->rx_bcast_packets); stats->tx_packets = old_stats->tx_packets + - get_stat64(&hw_stats->COS_out_packets[0]); + get_stat64(&hw_stats->tx_ucast_packets) + + get_stat64(&hw_stats->tx_mcast_packets) + + get_stat64(&hw_stats->tx_bcast_packets); stats->rx_bytes = old_stats->rx_bytes + get_stat64(&hw_stats->rx_octets); @@ -5232,6 +6032,18 @@ tp->msg_enable = value; } +static int tg3_set_tso(struct net_device *dev, u32 value) +{ + struct tg3 *tp = dev->priv; + + if (!(tp->tg3_flags2 & TG3_FLG2_TSO_CAPABLE)) { + if (value) + return -EINVAL; + return 0; + } + return ethtool_op_set_tso(dev, value); +} + static int tg3_nway_reset(struct net_device *dev) { struct tg3 *tp = dev->priv; @@ -5279,6 +6091,10 @@ spin_lock(&tp->tx_lock); tp->rx_pending = ering->rx_pending; + + if ((tp->tg3_flags2 & TG3_FLG2_MAX_RXPEND_64) && + tp->rx_pending > 64) + tp->rx_pending = 64; tp->rx_jumbo_pending = ering->rx_jumbo_pending; tp->tx_pending = ering->tx_pending; @@ -5467,6 +6283,8 @@ .set_tx_csum = tg3_set_tx_csum, .get_sg = ethtool_op_get_sg, .set_sg = ethtool_op_set_sg, + .get_tso = ethtool_op_get_tso, + .set_tso = tg3_set_tso, }; /* Chips other than 5700/5701 use the NVRAM for fetching info. */ @@ -5669,6 +6487,7 @@ u32 nic_cfg; tg3_read_mem(tp, NIC_SRAM_DATA_CFG, &nic_cfg); + tp->nic_sram_data_cfg = nic_cfg; eeprom_signature_found = 1; @@ -5702,8 +6521,10 @@ eeprom_led_mode = led_mode_auto; break; }; - if ((tp->pci_chip_rev_id == CHIPREV_ID_5703_A1 || - tp->pci_chip_rev_id == CHIPREV_ID_5703_A2) && + + if (((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5703) || + (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5704) || + (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705)) && (nic_cfg & NIC_SRAM_DATA_CFG_EEPROM_WP)) tp->tg3_flags |= TG3_FLAG_EEPROM_WRITE_PROT; @@ -5785,9 +6606,7 @@ } /* Enable Ethernet@WireSpeed */ - tg3_writephy(tp, MII_TG3_AUX_CTRL, 0x7007); - tg3_readphy(tp, MII_TG3_AUX_CTRL, &val); - tg3_writephy(tp, MII_TG3_AUX_CTRL, (val | (1 << 15) | (1 << 4))); + tg3_phy_set_wirespeed(tp); if (!err && ((tp->phy_id & PHY_ID_MASK) == PHY_ID_BCM5401)) { err = tg3_init_5401phy_dsp(tp); @@ -6085,7 +6904,15 @@ tp->tg3_flags |= TG3_FLAG_WOL_SPEED_100MB; } + /* A few boards don't want Ethernet@WireSpeed phy feature */ + if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700) || + ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) && + (tp->pci_chip_rev_id != CHIPREV_ID_5705_A0) && + (tp->pci_chip_rev_id != CHIPREV_ID_5705_A1))) + tp->tg3_flags2 |= TG3_FLG2_NO_ETH_WIRE_SPEED; + /* Only 5701 and later support tagged irq status mode. + * Also, 5788 chips cannot use tagged irq status. * * However, since we are using NAPI avoid tagged irq status * because the interrupt condition is more difficult to @@ -6142,7 +6969,8 @@ /* Determine if TX descriptors will reside in * main memory or in the chip SRAM. */ - if (tp->tg3_flags & TG3_FLAG_PCIX_TARGET_HWBUG) + if ((tp->tg3_flags & TG3_FLAG_PCIX_TARGET_HWBUG) != 0 || + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) tp->tg3_flags |= TG3_FLAG_HOST_TXDS; grc_misc_cfg = tr32(GRC_MISC_CFG); @@ -6154,8 +6982,18 @@ tp->split_mode_max_reqs = SPLIT_MODE_5704_MAX_REQ; } - /* this one is limited to 10/100 only */ - if (grc_misc_cfg == GRC_MISC_CFG_BOARD_ID_5702FE) + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705 && + (grc_misc_cfg == GRC_MISC_CFG_BOARD_ID_5788 || + grc_misc_cfg == GRC_MISC_CFG_BOARD_ID_5788M)) + tp->tg3_flags2 |= TG3_FLG2_IS_5788; + + /* these are limited to 10/100 only */ + if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5703 && + (grc_misc_cfg == 0x8000 || grc_misc_cfg == 0x4000)) || + (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705 && + tp->pdev->vendor == PCI_VENDOR_ID_BROADCOM && + (tp->pdev->device == PCI_DEVICE_ID_TIGON3_5901 || + tp->pdev->device == PCI_DEVICE_ID_TIGON3_5901_2))) tp->tg3_flags |= TG3_FLAG_10_100_ONLY; err = tg3_phy_probe(tp); @@ -6414,8 +7252,6 @@ goto out_nofree; } - tw32(TG3PCI_CLOCK_CTRL, 0); - if ((tp->tg3_flags & TG3_FLAG_PCIX_MODE) == 0) { tp->dma_rwctrl = (0x7 << DMA_RWCTRL_PCI_WRITE_CMD_SHIFT) | @@ -6423,7 +7259,9 @@ (0x7 << DMA_RWCTRL_WRITE_WATER_SHIFT) | (0x7 << DMA_RWCTRL_READ_WATER_SHIFT) | (0x0f << DMA_RWCTRL_MIN_DMA_SHIFT); - /* XXX 5705 note: set MIN_DMA to zero here */ + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) + tp->dma_rwctrl &= ~(DMA_RWCTRL_MIN_DMA + << DMA_RWCTRL_MIN_DMA_SHIFT); } else { if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5704) tp->dma_rwctrl = @@ -6524,8 +7362,15 @@ tp->dma_rwctrl |= DMA_RWCTRL_USE_MEM_READ_MULT; } + tp->dma_rwctrl |= DMA_RWCTRL_ASSERT_ALL_BE; + tw32(TG3PCI_DMA_RW_CTRL, tp->dma_rwctrl); +#if 0 + /* Unneeded, already done by tg3_get_invariants. */ + tg3_switch_clocks(tp); +#endif + ret = 0; if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5700 && GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5701) @@ -6630,12 +7475,35 @@ case PHY_ID_BCM5701: return "5701"; case PHY_ID_BCM5703: return "5703"; case PHY_ID_BCM5704: return "5704"; + case PHY_ID_BCM5705: return "5705"; case PHY_ID_BCM8002: return "8002"; case PHY_ID_SERDES: return "serdes"; default: return "unknown"; }; } +static struct pci_dev * __devinit tg3_find_5704_peer(struct tg3 *tp) +{ + struct pci_dev *peer = NULL; + unsigned int func; + + for (func = 0; func < 7; func++) { + unsigned int devfn = tp->pdev->devfn; + + devfn &= ~7; + devfn |= func; + + if (devfn == tp->pdev->devfn) + continue; + peer = pci_find_slot(tp->pdev->bus->number, devfn); + if (peer) + break; + } + if (!peer || peer == tp->pdev) + BUG(); + return peer; +} + static int __devinit tg3_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) { @@ -6794,6 +7662,44 @@ goto err_out_iounmap; } + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) { + tp->bufmgr_config.mbuf_read_dma_low_water = + DEFAULT_MB_RDMA_LOW_WATER_5705; + tp->bufmgr_config.mbuf_mac_rx_low_water = + DEFAULT_MB_MACRX_LOW_WATER_5705; + tp->bufmgr_config.mbuf_high_water = + DEFAULT_MB_HIGH_WATER_5705; + } + +#if TG3_TSO_SUPPORT != 0 + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700 || + GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701 || + tp->pci_chip_rev_id == CHIPREV_ID_5705_A0 || + (tp->tg3_flags & TG3_FLAG_ENABLE_ASF) != 0 || + (tp->tg3_flags2 & TG3_FLG2_IS_5788)) { + tp->tg3_flags2 &= ~TG3_FLG2_TSO_CAPABLE; + } else { + tp->tg3_flags2 |= TG3_FLG2_TSO_CAPABLE; + } + + /* TSO is off by default, user can enable using ethtool. */ +#if 0 + if (tp->tg3_flags2 & TG3_FLG2_TSO_CAPABLE) + dev->features |= NETIF_F_TSO; +#endif + +#endif + + if (tp->pci_chip_rev_id == CHIPREV_ID_5705_A1 && + !(tp->tg3_flags2 & TG3_FLG2_TSO_CAPABLE) && + !(tr32(TG3PCI_PCISTATE) & PCISTATE_BUS_SPEED_HIGH)) { + tp->tg3_flags2 |= TG3_FLG2_MAX_RXPEND_64; + tp->rx_pending = 64; + } + + if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5704) + tp->pdev_peer = tg3_find_5704_peer(tp); + err = tg3_get_device_address(tp); if (err) { printk(KERN_ERR PFX "Could not obtain valid ethernet address, " @@ -6816,16 +7722,8 @@ } else tp->tg3_flags &= ~TG3_FLAG_RX_CHECKSUMS; -#if TG3_DO_TSO != 0 - if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700 || - (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701 && - tp->pci_chip_rev_id <= CHIPREV_ID_5701_B2)) { - /* Not TSO capable. */ - dev->features &= ~NETIF_F_TSO; - } else { - dev->features |= NETIF_F_TSO; - } -#endif + if (tp->tg3_flags2 & TG3_FLG2_IS_5788) + dev->features &= ~NETIF_F_HIGHDMA; err = register_netdev(dev); if (err) { diff -Nru a/drivers/net/tg3.h b/drivers/net/tg3.h --- a/drivers/net/tg3.h Sun Aug 24 03:19:42 2003 +++ b/drivers/net/tg3.h Sun Aug 24 03:19:42 2003 @@ -24,6 +24,7 @@ #define RX_COPY_THRESHOLD 256 #define RX_STD_MAX_SIZE 1536 +#define RX_STD_MAX_SIZE_5705 512 #define RX_JUMBO_MAX_SIZE 0xdeadbeef /* XXX */ /* First 256 bytes are a mirror of PCI config space. */ @@ -59,7 +60,7 @@ #define PCIX_CAPS_SPLIT_SHIFT 20 #define PCIX_CAPS_BURST_MASK 0x000c0000 #define PCIX_CAPS_BURST_SHIFT 18 -#define PCIX_CAPS_MAX_BURST_5704 2 +#define PCIX_CAPS_MAX_BURST_CPIOB 2 #define TG3PCI_PM_CAP_PTR 0x00000041 #define TG3PCI_X_COMMAND 0x00000042 #define TG3PCI_X_STATUS 0x00000044 @@ -115,11 +116,14 @@ #define CHIPREV_ID_5704_A0 0x2000 #define CHIPREV_ID_5704_A1 0x2001 #define CHIPREV_ID_5704_A2 0x2002 +#define CHIPREV_ID_5705_A0 0x3000 +#define CHIPREV_ID_5705_A1 0x3001 #define GET_ASIC_REV(CHIP_REV_ID) ((CHIP_REV_ID) >> 12) #define ASIC_REV_5700 0x07 #define ASIC_REV_5701 0x00 #define ASIC_REV_5703 0x01 #define ASIC_REV_5704 0x02 +#define ASIC_REV_5705 0x03 #define GET_CHIP_REV(CHIP_REV_ID) ((CHIP_REV_ID) >> 8) #define CHIPREV_5700_AX 0x70 #define CHIPREV_5700_BX 0x71 @@ -180,6 +184,9 @@ #define CLOCK_CTRL_ALTCLK 0x00001000 #define CLOCK_CTRL_PWRDOWN_PLL133 0x00008000 #define CLOCK_CTRL_44MHZ_CORE 0x00040000 +#define CLOCK_CTRL_625_CORE 0x00100000 +#define CLOCK_CTRL_FORCE_CLKRUN 0x00200000 +#define CLOCK_CTRL_CLKRUN_OENABLE 0x00400000 #define CLOCK_CTRL_DELAY_PCI_GRANT 0x80000000 #define TG3PCI_REG_BASE_ADDR 0x00000078 #define TG3PCI_MEM_WIN_BASE_ADDR 0x0000007c @@ -457,17 +464,89 @@ #define MAC_RCV_RULE_CFG 0x00000500 #define RCV_RULE_CFG_DEFAULT_CLASS 0x00000008 #define MAC_LOW_WMARK_MAX_RX_FRAME 0x00000504 -/* 0x504 --> 0x590 unused */ +/* 0x508 --> 0x520 unused */ +#define MAC_HASHREGU_0 0x00000520 +#define MAC_HASHREGU_1 0x00000524 +#define MAC_HASHREGU_2 0x00000528 +#define MAC_HASHREGU_3 0x0000052c +#define MAC_EXTADDR_0_HIGH 0x00000530 +#define MAC_EXTADDR_0_LOW 0x00000534 +#define MAC_EXTADDR_1_HIGH 0x00000538 +#define MAC_EXTADDR_1_LOW 0x0000053c +#define MAC_EXTADDR_2_HIGH 0x00000540 +#define MAC_EXTADDR_2_LOW 0x00000544 +#define MAC_EXTADDR_3_HIGH 0x00000548 +#define MAC_EXTADDR_3_LOW 0x0000054c +#define MAC_EXTADDR_4_HIGH 0x00000550 +#define MAC_EXTADDR_4_LOW 0x00000554 +#define MAC_EXTADDR_5_HIGH 0x00000558 +#define MAC_EXTADDR_5_LOW 0x0000055c +#define MAC_EXTADDR_6_HIGH 0x00000560 +#define MAC_EXTADDR_6_LOW 0x00000564 +#define MAC_EXTADDR_7_HIGH 0x00000568 +#define MAC_EXTADDR_7_LOW 0x0000056c +#define MAC_EXTADDR_8_HIGH 0x00000570 +#define MAC_EXTADDR_8_LOW 0x00000574 +#define MAC_EXTADDR_9_HIGH 0x00000578 +#define MAC_EXTADDR_9_LOW 0x0000057c +#define MAC_EXTADDR_10_HIGH 0x00000580 +#define MAC_EXTADDR_10_LOW 0x00000584 +#define MAC_EXTADDR_11_HIGH 0x00000588 +#define MAC_EXTADDR_11_LOW 0x0000058c #define MAC_SERDES_CFG 0x00000590 #define MAC_SERDES_STAT 0x00000594 /* 0x598 --> 0x600 unused */ #define MAC_TX_MAC_STATE_BASE 0x00000600 /* 16 bytes */ #define MAC_RX_MAC_STATE_BASE 0x00000610 /* 20 bytes */ /* 0x624 --> 0x800 unused */ -#define MAC_RX_STATS_BASE 0x00000800 /* 26 32-bit words */ -/* 0x868 --> 0x880 unused */ -#define MAC_TX_STATS_BASE 0x00000880 /* 28 32-bit words */ -/* 0x8f0 --> 0xc00 unused */ +#define MAC_TX_STATS_OCTETS 0x00000800 +#define MAC_TX_STATS_RESV1 0x00000804 +#define MAC_TX_STATS_COLLISIONS 0x00000808 +#define MAC_TX_STATS_XON_SENT 0x0000080c +#define MAC_TX_STATS_XOFF_SENT 0x00000810 +#define MAC_TX_STATS_RESV2 0x00000814 +#define MAC_TX_STATS_MAC_ERRORS 0x00000818 +#define MAC_TX_STATS_SINGLE_COLLISIONS 0x0000081c +#define MAC_TX_STATS_MULT_COLLISIONS 0x00000820 +#define MAC_TX_STATS_DEFERRED 0x00000824 +#define MAC_TX_STATS_RESV3 0x00000828 +#define MAC_TX_STATS_EXCESSIVE_COL 0x0000082c +#define MAC_TX_STATS_LATE_COL 0x00000830 +#define MAC_TX_STATS_RESV4_1 0x00000834 +#define MAC_TX_STATS_RESV4_2 0x00000838 +#define MAC_TX_STATS_RESV4_3 0x0000083c +#define MAC_TX_STATS_RESV4_4 0x00000840 +#define MAC_TX_STATS_RESV4_5 0x00000844 +#define MAC_TX_STATS_RESV4_6 0x00000848 +#define MAC_TX_STATS_RESV4_7 0x0000084c +#define MAC_TX_STATS_RESV4_8 0x00000850 +#define MAC_TX_STATS_RESV4_9 0x00000854 +#define MAC_TX_STATS_RESV4_10 0x00000858 +#define MAC_TX_STATS_RESV4_11 0x0000085c +#define MAC_TX_STATS_RESV4_12 0x00000860 +#define MAC_TX_STATS_RESV4_13 0x00000864 +#define MAC_TX_STATS_RESV4_14 0x00000868 +#define MAC_TX_STATS_UCAST 0x0000086c +#define MAC_TX_STATS_MCAST 0x00000870 +#define MAC_TX_STATS_BCAST 0x00000874 +#define MAC_TX_STATS_RESV5_1 0x00000878 +#define MAC_TX_STATS_RESV5_2 0x0000087c +#define MAC_RX_STATS_OCTETS 0x00000880 +#define MAC_RX_STATS_RESV1 0x00000884 +#define MAC_RX_STATS_FRAGMENTS 0x00000888 +#define MAC_RX_STATS_UCAST 0x0000088c +#define MAC_RX_STATS_MCAST 0x00000890 +#define MAC_RX_STATS_BCAST 0x00000894 +#define MAC_RX_STATS_FCS_ERRORS 0x00000898 +#define MAC_RX_STATS_ALIGN_ERRORS 0x0000089c +#define MAC_RX_STATS_XON_PAUSE_RECVD 0x000008a0 +#define MAC_RX_STATS_XOFF_PAUSE_RECVD 0x000008a4 +#define MAC_RX_STATS_MAC_CTRL_RECVD 0x000008a8 +#define MAC_RX_STATS_XOFF_ENTERED 0x000008ac +#define MAC_RX_STATS_FRAME_TOO_LONG 0x000008b0 +#define MAC_RX_STATS_JABBERS 0x000008b4 +#define MAC_RX_STATS_UNDERSIZE 0x000008b8 +/* 0x8bc --> 0xc00 unused */ /* Send data initiator control registers */ #define SNDDATAI_MODE 0x00000c00 @@ -599,6 +678,7 @@ #define RCVLPC_STATSCTRL_ENABLE 0x00000001 #define RCVLPC_STATSCTRL_FASTUPD 0x00000002 #define RCVLPC_STATS_ENABLE 0x00002018 +#define RCVLPC_STATSENAB_LNGBRST_RFIX 0x00400000 #define RCVLPC_STATS_INCMASK 0x0000201c /* 0x2020 --> 0x2100 unused */ #define RCVLPC_SELLST_BASE 0x00002100 /* 16 16-byte entries */ @@ -812,13 +892,16 @@ #define BUFMGR_MB_POOL_ADDR 0x00004408 #define BUFMGR_MB_POOL_SIZE 0x0000440c #define BUFMGR_MB_RDMA_LOW_WATER 0x00004410 -#define DEFAULT_MB_RDMA_LOW_WATER 0x00000040 +#define DEFAULT_MB_RDMA_LOW_WATER 0x00000050 +#define DEFAULT_MB_RDMA_LOW_WATER_5705 0x00000000 #define DEFAULT_MB_RDMA_LOW_WATER_JUMBO 0x00000130 #define BUFMGR_MB_MACRX_LOW_WATER 0x00004414 #define DEFAULT_MB_MACRX_LOW_WATER 0x00000020 +#define DEFAULT_MB_MACRX_LOW_WATER_5705 0x00000010 #define DEFAULT_MB_MACRX_LOW_WATER_JUMBO 0x00000098 #define BUFMGR_MB_HIGH_WATER 0x00004418 #define DEFAULT_MB_HIGH_WATER 0x00000060 +#define DEFAULT_MB_HIGH_WATER_5705 0x00000060 #define DEFAULT_MB_HIGH_WATER_JUMBO 0x0000017c #define BUFMGR_RX_MB_ALLOC_REQ 0x0000441c #define BUFMGR_MB_ALLOC_BIT 0x10000000 @@ -854,6 +937,8 @@ #define RDMAC_MODE_LNGREAD_ENAB 0x00000200 #define RDMAC_MODE_SPLIT_ENABLE 0x00000800 #define RDMAC_MODE_SPLIT_RESET 0x00001000 +#define RDMAC_MODE_FIFO_SIZE_128 0x00020000 +#define RDMAC_MODE_FIFO_LONG_BURST 0x00030000 #define RDMAC_STATUS 0x00004804 #define RDMAC_STATUS_TGTABORT 0x00000004 #define RDMAC_STATUS_MSTABORT 0x00000008 @@ -877,6 +962,7 @@ #define WDMAC_MODE_FIFOURUN_ENAB 0x00000080 #define WDMAC_MODE_FIFOOREAD_ENAB 0x00000100 #define WDMAC_MODE_LNGREAD_ENAB 0x00000200 +#define WDMAC_MODE_RX_ACCEL 0x00000400 #define WDMAC_STATUS 0x00004c04 #define WDMAC_STATUS_TGTABORT 0x00000004 #define WDMAC_STATUS_MSTABORT 0x00000008 @@ -1140,7 +1226,10 @@ #define GRC_MISC_CFG_BOARD_ID_5704 0x00000000 #define GRC_MISC_CFG_BOARD_ID_5704CIOBE 0x00004000 #define GRC_MISC_CFG_BOARD_ID_5704_A2 0x00008000 +#define GRC_MISC_CFG_BOARD_ID_5788 0x00010000 +#define GRC_MISC_CFG_BOARD_ID_5788M 0x00018000 #define GRC_MISC_CFG_BOARD_ID_AC91002A1 0x00018000 +#define GRC_MISC_CFG_KEEP_GPHY_POWER 0x04000000 #define GRC_LOCAL_CTRL 0x00006808 #define GRC_LCLCTRL_INT_ACTIVE 0x00000001 #define GRC_LCLCTRL_CLEARINT 0x00000002 @@ -1275,6 +1364,7 @@ #define NIC_SRAM_DATA_CFG_WOL_ENABLE 0x00000040 #define NIC_SRAM_DATA_CFG_ASF_ENABLE 0x00000080 #define NIC_SRAM_DATA_CFG_EEPROM_WP 0x00000100 +#define NIC_SRAM_DATA_CFG_MINI_PCI 0x00001000 #define NIC_SRAM_DATA_CFG_FIBER_WOL 0x00004000 #define NIC_SRAM_DATA_PHY_ID 0x00000b74 @@ -1312,6 +1402,8 @@ #define NIC_SRAM_MBUF_POOL_BASE 0x00008000 #define NIC_SRAM_MBUF_POOL_SIZE96 0x00018000 #define NIC_SRAM_MBUF_POOL_SIZE64 0x00010000 +#define NIC_SRAM_MBUF_POOL_BASE5705 0x00010000 +#define NIC_SRAM_MBUF_POOL_SIZE5705 0x0000e000 /* Currently this is fixed. */ #define PHY_ADDR 0x01 @@ -1824,6 +1916,10 @@ u32 tg3_flags2; #define TG3_FLG2_RESTART_TIMER 0x00000001 #define TG3_FLG2_SUN_5704 0x00000002 +#define TG3_FLG2_NO_ETH_WIRE_SPEED 0x00000004 +#define TG3_FLG2_IS_5788 0x00000008 +#define TG3_FLG2_MAX_RXPEND_64 0x00000010 +#define TG3_FLG2_TSO_CAPABLE 0x00000020 u32 split_mode_max_reqs; #define SPLIT_MODE_5704_MAX_REQ 3 @@ -1868,6 +1964,7 @@ #define PHY_ID_BCM5701 0x60008110 #define PHY_ID_BCM5703 0x60008160 #define PHY_ID_BCM5704 0x60008190 +#define PHY_ID_BCM5705 0x600081a0 #define PHY_ID_BCM8002 0x60010140 #define PHY_ID_SERDES 0xfeedbee0 #define PHY_ID_INVALID 0xffffffff @@ -1880,6 +1977,9 @@ enum phy_led_mode led_mode; char board_part_number[24]; + u32 nic_sram_data_cfg; + u32 pci_clock_ctrl; + struct pci_dev *pdev_peer; /* This macro assumes the passed PHY ID is already masked * with PHY_ID_MASK. @@ -1888,6 +1988,7 @@ ((X) == PHY_ID_BCM5400 || (X) == PHY_ID_BCM5401 || \ (X) == PHY_ID_BCM5411 || (X) == PHY_ID_BCM5701 || \ (X) == PHY_ID_BCM5703 || (X) == PHY_ID_BCM5704 || \ + (X) == PHY_ID_BCM5705 || \ (X) == PHY_ID_BCM8002 || (X) == PHY_ID_SERDES) struct tg3_hw_stats *hw_stats; diff -Nru a/drivers/pci/pci.ids b/drivers/pci/pci.ids --- a/drivers/pci/pci.ids Sun Aug 24 03:19:42 2003 +++ b/drivers/pci/pci.ids Sun Aug 24 03:19:42 2003 @@ -5313,9 +5313,12 @@ 1166 1648 NetXtreme CIOB-E 1000Base-T 164d NetXtreme BCM5702FE Gigabit Ethernet 1653 NetXtreme BCM5705 Gigabit Ethernet + 1654 NetXtreme BCM5705 Gigabit Ethernet 165d NetXtreme BCM5705M Gigabit Ethernet + 165e NetXtreme BCM5705M Gigabit Ethernet 1696 NetXtreme BCM5782 Gigabit Ethernet 14e4 000d NetXtreme BCM5782 1000Base-T + 169c NetXtreme BCM5788 Gigabit Ethernet 16a6 NetXtreme BCM5702 Gigabit Ethernet 0e11 00bb NC7760 Gigabit Server Adapter (PCI-X, 10/100/1000-T) 1028 0126 BCM5702 1000Base-T @@ -5337,6 +5340,8 @@ 16c7 NetXtreme BCM5703 Gigabit Ethernet 14e4 0009 NetXtreme BCM5703 1000Base-T 14e4 000a NetXtreme BCM5703 1000Base-SX + 170d NetXtreme BCM5901 Gigabit Ethernet + 170e NetXtreme BCM5901 Gigabit Ethernet 4210 BCM4210 iLine10 HomePNA 2.0 4211 BCM4211 iLine10 HomePNA 2.0 + V.90 56k modem 4212 BCM4212 v.90 56k modem diff -Nru a/include/linux/ethtool.h b/include/linux/ethtool.h --- a/include/linux/ethtool.h Sun Aug 24 03:19:42 2003 +++ b/include/linux/ethtool.h Sun Aug 24 03:19:42 2003 @@ -257,6 +257,8 @@ u32 ethtool_op_get_tx_csum(struct net_device *dev); u32 ethtool_op_get_sg(struct net_device *dev); int ethtool_op_set_sg(struct net_device *dev, u32 data); +u32 ethtool_op_get_tso(struct net_device *dev); +int ethtool_op_set_tso(struct net_device *dev, u32 data); /** * ðtool_ops - Alter and report network device settings @@ -284,6 +286,8 @@ * set_tx_csum: Turn transmit checksums on or off * get_sg: Report whether scatter-gather is enabled * set_sg: Turn scatter-gather on or off + * get_tso: Report whether TCP segmentation offload is enabled + * set_tso: Turn TCP segmentation offload on or off * self_test: Run specified self-tests * get_strings: Return a set of strings that describe the requested objects * phys_id: Identify the device @@ -337,6 +341,8 @@ int (*set_tx_csum)(struct net_device *, u32); u32 (*get_sg)(struct net_device *); int (*set_sg)(struct net_device *, u32); + u32 (*get_tso)(struct net_device *); + int (*set_tso)(struct net_device *, u32); int (*self_test_count)(struct net_device *); void (*self_test)(struct net_device *, struct ethtool_test *, u64 *); void (*get_strings)(struct net_device *, u32 stringset, u8 *); diff -Nru a/include/linux/pci_ids.h b/include/linux/pci_ids.h --- a/include/linux/pci_ids.h Sun Aug 24 03:19:42 2003 +++ b/include/linux/pci_ids.h Sun Aug 24 03:19:42 2003 @@ -1758,11 +1758,19 @@ #define PCI_DEVICE_ID_TIGON3_5703 0x1647 #define PCI_DEVICE_ID_TIGON3_5704 0x1648 #define PCI_DEVICE_ID_TIGON3_5702FE 0x164d +#define PCI_DEVICE_ID_TIGON3_5705 0x1653 +#define PCI_DEVICE_ID_TIGON3_5705_2 0x1654 +#define PCI_DEVICE_ID_TIGON3_5705M 0x165d +#define PCI_DEVICE_ID_TIGON3_5705M_2 0x165e +#define PCI_DEVICE_ID_TIGON3_5782 0x1696 +#define PCI_DEVICE_ID_TIGON3_5788 0x169c #define PCI_DEVICE_ID_TIGON3_5702X 0x16a6 #define PCI_DEVICE_ID_TIGON3_5703X 0x16a7 #define PCI_DEVICE_ID_TIGON3_5704S 0x16a8 #define PCI_DEVICE_ID_TIGON3_5702A3 0x16c6 #define PCI_DEVICE_ID_TIGON3_5703A3 0x16c7 +#define PCI_DEVICE_ID_TIGON3_5901 0x170d +#define PCI_DEVICE_ID_TIGON3_5901_2 0x170e #define PCI_DEVICE_ID_BCM4401 0x4401 #define PCI_VENDOR_ID_SYBA 0x1592 diff -Nru a/net/core/ethtool.c b/net/core/ethtool.c --- a/net/core/ethtool.c Sun Aug 24 03:19:42 2003 +++ b/net/core/ethtool.c Sun Aug 24 03:19:42 2003 @@ -45,6 +45,21 @@ return 0; } +u32 ethtool_op_get_tso(struct net_device *dev) +{ + return (dev->features & NETIF_F_TSO) != 0; +} + +int ethtool_op_set_tso(struct net_device *dev, u32 data) +{ + if (data) + dev->features |= NETIF_F_TSO; + else + dev->features &= ~NETIF_F_TSO; + + return 0; +} + /* Handlers for each ethtool command */ static int ethtool_get_settings(struct net_device *dev, void *useraddr) @@ -454,6 +469,33 @@ return dev->ethtool_ops->set_sg(dev, edata.data); } +static int ethtool_get_tso(struct net_device *dev, char *useraddr) +{ + struct ethtool_value edata = { ETHTOOL_GTSO }; + + if (!dev->ethtool_ops->get_tso) + return -EOPNOTSUPP; + + edata.data = dev->ethtool_ops->get_tso(dev); + + if (copy_to_user(useraddr, &edata, sizeof(edata))) + return -EFAULT; + return 0; +} + +static int ethtool_set_tso(struct net_device *dev, char *useraddr) +{ + struct ethtool_value edata; + + if (!dev->ethtool_ops->set_tso) + return -EOPNOTSUPP; + + if (copy_from_user(&edata, useraddr, sizeof(edata))) + return -EFAULT; + + return dev->ethtool_ops->set_tso(dev, edata.data); +} + static int ethtool_self_test(struct net_device *dev, char *useraddr) { struct ethtool_test test; @@ -653,6 +695,10 @@ return ethtool_get_sg(dev, useraddr); case ETHTOOL_SSG: return ethtool_set_sg(dev, useraddr); + case ETHTOOL_GTSO: + return ethtool_get_tso(dev, useraddr); + case ETHTOOL_STSO: + return ethtool_set_tso(dev, useraddr); case ETHTOOL_TEST: return ethtool_self_test(dev, useraddr); case ETHTOOL_GSTRINGS: diff -Nru a/net/netsyms.c b/net/netsyms.c --- a/net/netsyms.c Sun Aug 24 03:19:42 2003 +++ b/net/netsyms.c Sun Aug 24 03:19:42 2003 @@ -633,5 +633,7 @@ EXPORT_SYMBOL(ethtool_op_get_tx_csum); EXPORT_SYMBOL(ethtool_op_get_sg); EXPORT_SYMBOL(ethtool_op_set_sg); +EXPORT_SYMBOL(ethtool_op_get_tso); +EXPORT_SYMBOL(ethtool_op_set_tso); #endif /* CONFIG_NET */ From davem@redhat.com Sun Aug 24 03:55:06 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Aug 2003 03:55:39 -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 h7OAsPoO014435 for ; Sun, 24 Aug 2003 03:55:06 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id DAA07017; Sun, 24 Aug 2003 03:46:37 -0700 Date: Sun, 24 Aug 2003 03:46:37 -0700 From: "David S. Miller" To: Vinay K Nallamothu Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2.6.0-test4][ATM][RESEND] fix ambassador.c Message-Id: <20030824034637.522fdeb3.davem@redhat.com> In-Reply-To: <1061629891.1121.7.camel@lima.royalchallenge.com> References: <1061629891.1121.7.camel@lima.royalchallenge.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5241 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 Content-Length: 277 Lines: 8 On 23 Aug 2003 14:41:31 +0530 Vinay K Nallamothu wrote: > This patch cleans up the code making use of sti/cli. Please make sure to send this to the ATM maintainer. He's very responsible so I only take significant ATM patches that come through him. From davem@redhat.com Sun Aug 24 03:56:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Aug 2003 03:56:35 -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 h7OAtMoO014535 for ; Sun, 24 Aug 2003 03:56:02 -0700 Received: from pizda.ninka.net (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with SMTP id DAA07027; Sun, 24 Aug 2003 03:47:35 -0700 Date: Sun, 24 Aug 2003 03:47:35 -0700 From: "David S. Miller" To: Vinay K Nallamothu Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2.6.0-test4][NET] 3c509.c: remove device.name field Message-Id: <20030824034735.534b8c68.davem@redhat.com> In-Reply-To: <1061644409.1141.18.camel@lima.royalchallenge.com> References: <1061644409.1141.18.camel@lima.royalchallenge.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5242 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 Content-Length: 323 Lines: 8 On 23 Aug 2003 18:43:29 +0530 Vinay K Nallamothu wrote: > This patch removes the device name field which is no longer present. This doesn't look like the right fix. You can't just delete these lines, you should rather replace them with accesses to whatever the MCA device struct name field is. From laurent.deniel@free.fr Sun Aug 24 04:20:32 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Aug 2003 04:21:11 -0700 (PDT) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7OBJfoO016002 for ; Sun, 24 Aug 2003 04:20:22 -0700 Received: from free.fr (rennes-1-a7-62-147-97-176.dial.proxad.net [62.147.97.176]) by postfix3-2.free.fr (Postfix) with ESMTP id 97D4DC903; Sun, 24 Aug 2003 12:41:41 +0200 (CEST) Message-ID: <3F489659.6040507@free.fr> Date: Sun, 24 Aug 2003 12:41:29 +0200 From: Laurent Deniel Organization: Home User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: "Hen, Shmulik" Cc: Stephen Hemminger , Chad Tindel , Jay Vosburgh , "David S. Miller" , Jeff Garzik , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [Bonding-devel] RE: [PATCH] convering bonding driver /proc interface to seq_file References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5243 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laurent.deniel@free.fr Precedence: bulk X-list: netdev Content-Length: 411 Lines: 15 Hen, Shmulik wrote: > Guys, > > Could everyone please hold off the bonding modifications for > only a short while until we get this sorted out? We have a > bunch of other patch sets in queue that add lots of new stuff > and they all depend on that first set being accepted. Could you give a short description of what is pending ? this could avoid duplicate efforts, or worst, incompatible ones ... Laurent From davem@pizda.ninka.net Sun Aug 24 04:24:57 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Aug 2003 04:25:30 -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 h7OBOGoO021302 for ; Sun, 24 Aug 2003 04:24:56 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id EAA07317; Sun, 24 Aug 2003 04:16:32 -0700 Date: Sun, 24 Aug 2003 04:16:32 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] IPV4 route cache /proc interface cleanup Message-Id: <20030824041632.705d2b96.davem@redhat.com> In-Reply-To: <20030821163019.66cfe65c.shemminger@osdl.org> References: <20030821163019.66cfe65c.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5244 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 Content-Length: 487 Lines: 13 On Thu, 21 Aug 2003 16:30:19 -0700 Stephen Hemminger wrote: > This patch to 2.6.0-test3 uses seq_file for /proc/net/rt_cache_stat > Someone else already did the hard one /proc/net/rt_cache > > Couple of other little nits: > * use proc_net_fops_create to setup > * collapse two_line setup functions into the init routine > * proc_exit routine was never called and can go. > * cleaner to refer to proc_net as base rather than net/rt_acct Applied, thanks Stephen. From davem@pizda.ninka.net Sun Aug 24 04:36:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Aug 2003 04:37:00 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7OBZkoO021942 for ; Sun, 24 Aug 2003 04:36:26 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id EAA13471; Sun, 24 Aug 2003 04:28:01 -0700 Date: Sun, 24 Aug 2003 04:28:01 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: pe1rxq@amsat.org, linux-hams@vger.kernel.org, ralf@linux-mips.org, netdev@oss.sgi.com Subject: Re: [PATCH] ax25 - make sure and hold ref to dev Message-Id: <20030824042801.6dd5b99b.davem@redhat.com> In-Reply-To: <20030822131328.1696430e.shemminger@osdl.org> References: <20030812194653.A28977@jeroen.pe1rxq.ampr.org> <20030812135655.7334887b.shemminger@osdl.org> <20030812230951.E28977@jeroen.pe1rxq.ampr.org> <20030812153901.6e700dcb.shemminger@osdl.org> <20030813010301.K28977@jeroen.pe1rxq.ampr.org> <20030812172151.7de0c950.shemminger@osdl.org> <20030813031159.6c6c9629.davem@redhat.com> <20030813173446.A2604@jeroen.pe1rxq.ampr.org> <20030813084252.7b667fb8.davem@redhat.com> <20030820204518.C5568@jeroen.pe1rxq.ampr.org> <20030822131328.1696430e.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5245 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 Content-Length: 343 Lines: 9 On Fri, 22 Aug 2003 13:13:28 -0700 Stephen Hemminger wrote: > The lower layers of ax25 hold a reference to the underlying device > but don't increment the ref count. This is safe because it does the > right thing when UNREGISTER notification comes in, but it is better > to do the right thing. Applied, thanks Stephen. From davem@pizda.ninka.net Sun Aug 24 04:37:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Aug 2003 04:37: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 h7OBatoO021980 for ; Sun, 24 Aug 2003 04:37:36 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id EAA13494; Sun, 24 Aug 2003 04:29:11 -0700 Date: Sun, 24 Aug 2003 04:29:11 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: pe1rxq@amsat.org, linux-hams@vger.kernel.org, ralf@linux-mips.org, netdev@oss.sgi.com Subject: Re: [RFT][PATCH] ax25 using seq_file Message-Id: <20030824042911.785aff76.davem@redhat.com> In-Reply-To: <20030822131547.0d95fb16.shemminger@osdl.org> References: <20030812194653.A28977@jeroen.pe1rxq.ampr.org> <20030812135655.7334887b.shemminger@osdl.org> <20030812230951.E28977@jeroen.pe1rxq.ampr.org> <20030812153901.6e700dcb.shemminger@osdl.org> <20030813010301.K28977@jeroen.pe1rxq.ampr.org> <20030812172151.7de0c950.shemminger@osdl.org> <20030813031159.6c6c9629.davem@redhat.com> <20030813173446.A2604@jeroen.pe1rxq.ampr.org> <20030813084252.7b667fb8.davem@redhat.com> <20030820204518.C5568@jeroen.pe1rxq.ampr.org> <20030822131547.0d95fb16.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5246 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 Content-Length: 368 Lines: 11 On Fri, 22 Aug 2003 13:15:47 -0700 Stephen Hemminger wrote: > Convert AX25 to use the seq_file interface for it's /proc hook. > > Jeroen could you test this with real hardware, since without hardware > the table always comes up empty which is not a good enough test. Meanwhile I've applied this. If problems are found you can send me fixes. From davem@pizda.ninka.net Sun Aug 24 04:50:19 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Aug 2003 04:50: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 h7OBncoO022975 for ; Sun, 24 Aug 2003 04:50:19 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id EAA13693; Sun, 24 Aug 2003 04:41:50 -0700 Date: Sun, 24 Aug 2003 04:41:50 -0700 From: "David S. Miller" To: Vinay K Nallamothu Cc: vinay-rc@naturesoft.net, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2.6.0-test4][NET] sk_mca.c: fix linker error Message-Id: <20030824044150.6b396fdc.davem@redhat.com> In-Reply-To: <1061646315.1141.26.camel@lima.royalchallenge.com> References: <1061644938.2787.22.camel@lima.royalchallenge.com> <1061646315.1141.26.camel@lima.royalchallenge.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5247 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 Content-Length: 369 Lines: 12 On 23 Aug 2003 19:15:15 +0530 Vinay K Nallamothu wrote: > On Sat, 2003-08-23 at 18:52, Vinay K Nallamothu wrote: > > Hi, > > > > This patch fixes the following linker error due to a typo: > > > > *** Warning: "spin_lock_irqrestore" [drivers/net/sk_mca.ko] undefined! > Oops. missed out few more. Here is the updated patch. Aplied, thanks. From davem@pizda.ninka.net Sun Aug 24 04:58:07 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Aug 2003 04:58: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 h7OBvRoO023533 for ; Sun, 24 Aug 2003 04:58:07 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id EAA13801; Sun, 24 Aug 2003 04:49:40 -0700 Date: Sun, 24 Aug 2003 04:49:39 -0700 From: "David S. Miller" To: Marcelo Abreu Cc: netdev@oss.sgi.com Subject: Re: [PATCH][TRIVIAL] dummy.c: remove dead comment Message-Id: <20030824044939.08f76ab0.davem@redhat.com> In-Reply-To: <3F47DAEE.7050908@terra.com.br> References: <3F47DAEE.7050908@terra.com.br> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5248 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 Content-Length: 156 Lines: 6 On Sat, 23 Aug 2003 18:21:50 -0300 Marcelo Abreu wrote: > The line this comment refers to does not exist anymore. Applied, thanks. From vinay-rc@naturesoft.net Sun Aug 24 05:03:59 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Aug 2003 05:04:32 -0700 (PDT) Received: from naturesoft.net ([203.145.184.221]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7OC3HoO024057 for ; Sun, 24 Aug 2003 05:03:58 -0700 Received: from [192.168.0.15] (helo=lima.royalchallenge.com) by naturesoft.net with esmtp (Exim 3.35 #1) id 19qtUi-0008JT-00; Sun, 24 Aug 2003 17:27:16 +0530 Subject: Re: [PATCH 2.6.0-test4][NET] 3c509.c: remove device.name field From: Vinay K Nallamothu To: "David S. Miller" Cc: netdev@oss.sgi.com, LKML In-Reply-To: <20030824034735.534b8c68.davem@redhat.com> References: <1061644409.1141.18.camel@lima.royalchallenge.com> <20030824034735.534b8c68.davem@redhat.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 24 Aug 2003 17:55:40 +0530 Message-Id: <1061727940.1288.4.camel@lima.royalchallenge.com> Mime-Version: 1.0 X-archive-position: 5249 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vinay-rc@naturesoft.net Precedence: bulk X-list: netdev Content-Length: 981 Lines: 32 Hi Dave, On Sun, 2003-08-24 at 16:17, David S. Miller wrote: > On 23 Aug 2003 18:43:29 +0530 > Vinay K Nallamothu wrote: > > > This patch removes the device name field which is no longer present. > > This doesn't look like the right fix. You can't just > delete these lines, you should rather replace them with > accesses to whatever the MCA device struct name field is. > > Pls find the updated patch (hopefully right this time) below: Thanks vinay --- linux-2.6.0-test4/drivers/net/3c509.c 2003-08-23 13:14:30.000000000 +0530 +++ linux-2.6.0-test4-nvk/drivers/net/3c509.c 2003-08-24 17:51:19.000000000 +0530 @@ -629,8 +629,8 @@ el3_mca_adapter_names[mdev->index], slot + 1); /* claim the slot */ - strncpy(device->name, el3_mca_adapter_names[mdev->index], - sizeof(device->name)); + strncpy(mdev->name, el3_mca_adapter_names[mdev->index], + sizeof(mdev->name)); mca_device_set_claim(mdev, 1); if_port = pos4 & 0x03; From davem@pizda.ninka.net Sun Aug 24 05:11:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Aug 2003 05:12:14 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7OCB0oO024648 for ; Sun, 24 Aug 2003 05:11:40 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id FAA14000; Sun, 24 Aug 2003 05:03:08 -0700 Date: Sun, 24 Aug 2003 05:03:08 -0700 From: "David S. Miller" To: Vinay K Nallamothu Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2.6.0-test4][NET] 3c509.c: remove device.name field Message-Id: <20030824050308.0a3feee0.davem@redhat.com> In-Reply-To: <1061727940.1288.4.camel@lima.royalchallenge.com> References: <1061644409.1141.18.camel@lima.royalchallenge.com> <20030824034735.534b8c68.davem@redhat.com> <1061727940.1288.4.camel@lima.royalchallenge.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5250 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 Content-Length: 584 Lines: 17 On 24 Aug 2003 17:55:40 +0530 Vinay K Nallamothu wrote: > On Sun, 2003-08-24 at 16:17, David S. Miller wrote: > > On 23 Aug 2003 18:43:29 +0530 > > Vinay K Nallamothu wrote: > > > > > This patch removes the device name field which is no longer present. > > > > This doesn't look like the right fix. You can't just > > delete these lines, you should rather replace them with > > accesses to whatever the MCA device struct name field is. > > > > > Pls find the updated patch (hopefully right this time) below: Applied, thanks. From vinay-rc@naturesoft.net Sun Aug 24 07:44:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Aug 2003 07:44:41 -0700 (PDT) Received: from naturesoft.net ([203.145.184.221]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7OEiZoO029998 for ; Sun, 24 Aug 2003 07:44:36 -0700 Received: from [192.168.0.15] (helo=lima.royalchallenge.com) by naturesoft.net with esmtp (Exim 3.35 #1) id 19qw0r-0003CD-00; Sun, 24 Aug 2003 20:08:37 +0530 Subject: [PATCH 2.6.0-test4][NET] ni5010.c: remove cli/sti From: Vinay K Nallamothu To: netdev@oss.sgi.com Cc: LKML Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 24 Aug 2003 20:37:04 +0530 Message-Id: <1061737624.1288.9.camel@lima.royalchallenge.com> Mime-Version: 1.0 X-archive-position: 5251 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vinay-rc@naturesoft.net Precedence: bulk X-list: netdev Content-Length: 1491 Lines: 56 Hi, drivers/net/ni5010.c: This patch replaces cli/sti with spinlocks. Compiles fine though untested. Vinay --- linux-2.6.0-test4/drivers/net/ni5010.c 2003-07-15 17:22:18.000000000 +0530 +++ linux-2.6.0-test4-nvk/drivers/net/ni5010.c 2003-08-24 20:29:35.000000000 +0530 @@ -96,6 +96,7 @@ struct net_device_stats stats; int o_pkt_size; int i_pkt_size; + spinlock_t tx_lock; }; /* Index to functions, as function prototypes. */ @@ -280,11 +281,16 @@ /* DMA is not supported (yet?), so no use detecting it */ if (dev->priv == NULL) { + struct ni5010_local* lp; + dev->priv = kmalloc(sizeof(struct ni5010_local), GFP_KERNEL|GFP_DMA); if (dev->priv == NULL) { printk(KERN_WARNING "%s: Failed to allocate private memory\n", dev->name); return -ENOMEM; } + + lp = (struct ni5010_local*)dev->priv; + spin_lock_init(&lp->tx_lock); } PRINTK2((KERN_DEBUG "%s: I/O #10 passed!\n", dev->name)); @@ -693,8 +699,7 @@ buf_offs = NI5010_BUFSIZE - length - pad; lp->o_pkt_size = length + pad; - save_flags(flags); - cli(); + spin_lock_irqsave(&lp->tx_lock, flags); outb(0, EDLC_RMASK); /* Mask all receive interrupts */ outb(0, IE_MMODE); /* Put Xmit buffer on system bus */ @@ -712,7 +717,7 @@ outb(MM_EN_XMT | MM_MUX, IE_MMODE); /* Begin transmission */ outb(XM_ALL, EDLC_XMASK); /* Cause interrupt after completion or fail */ - restore_flags(flags); + spin_unlock_irqrestore(&lp->tx_lock, flags); netif_wake_queue(dev); From shmulik.hen@intel.com Sun Aug 24 07:50:32 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Aug 2003 07:50:37 -0700 (PDT) Received: from hermes.hd.intel.com (fmr09.intel.com [192.52.57.35]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7OEoVoO030462 for ; Sun, 24 Aug 2003 07:50:32 -0700 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.76 2003/08/21 22:58:26 rfjohns1 Exp $) with ESMTP id h7OEm9p28106 for ; Sun, 24 Aug 2003 14:48:09 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by petasus.hd.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 h7OEjLW25915 for ; Sun, 24 Aug 2003 14:45:21 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.254.188]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003082407502220956 ; Sun, 24 Aug 2003 07:50:23 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Shmulik Hen Reply-To: shmulik.hen@intel.com Organization: Intel corp. To: Laurent Deniel Subject: Re: [Bonding-devel] RE: [PATCH] convering bonding driver /proc interface to seq_file Date: Sun, 24 Aug 2003 17:50:21 +0300 User-Agent: KMail/1.4.3 Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com References: <3F489659.6040507@free.fr> In-Reply-To: <3F489659.6040507@free.fr> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200308241750.21391.shmulik.hen@intel.com> X-archive-position: 5252 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Content-Length: 1542 Lines: 33 On Sunday 24 August 2003 01:41 pm, Laurent Deniel wrote: > Hen, Shmulik wrote: > > Guys, > > > > Could everyone please hold off the bonding modifications for > > only a short while until we get this sorted out? We have a > > bunch of other patch sets in queue that add lots of new stuff > > and they all depend on that first set being accepted. > > Could you give a short description of what is pending ? this > could avoid duplicate efforts, or worst, incompatible ones ... Mostly I referred to the 3 patch sets already sent to the lists two weeks ago. These patch sets handled back porting stuff from 2.6 to 2.4, correctly handle propagation of settings from a bond device to its slaves and lots of code cleanup. These patches are currently in Jeff's net-drivers queue, and hopefully they'll be merged into 2.4 and from there into 2.6 again, getting 2.6 bonding fully updated. In the near future, among other things, we are planning to consolidate VLAN support over all teaming modes, add support for multiple bonds with different modes, add the ability to dynamically add and remove bond devices and add the ability to dynamically change bond params. Further into the future, we intend to add support for hardware offloading stuff like zero copy, checksumming and VLAN, so owners of newer adapters can benefit from increased banwidth, etc. -- | Shmulik Hen Advanced Network Services | | Israel Design Center, Jerusalem | | LAN Access Division, Platform Networking | | Intel Communications Group, Intel corp. | From jmorris@intercode.com.au Sun Aug 24 08:16:48 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Aug 2003 08:16:57 -0700 (PDT) Received: from blackbird.intercode.com.au (IDENT:B8excxnRL34trTxYK7+btLbTNEUU+Ovz@blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7OFGOoO031797 for ; Sun, 24 Aug 2003 08:16:46 -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 h7OFFEC24395; Mon, 25 Aug 2003 01:15:15 +1000 Date: Mon, 25 Aug 2003 01:15:13 +1000 (EST) From: James Morris To: "Hen, Shmulik" cc: Stephen Hemminger , Chad Tindel , Jay Vosburgh , "David S. Miller" , Jeff Garzik , , Subject: RE: [PATCH] convering bonding driver /proc interface to seq_file In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5253 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 Content-Length: 451 Lines: 17 On Sat, 23 Aug 2003, Hen, Shmulik wrote: > Also, instead of using a seq_file interface and using a > pointer to skip to the relevant part, we've used a different > proc creation interface that allows passing a pointer to bond > and thus retrieve just the relevant bond device's data. Can you provide a pointer to this code? seq_file is the standard and preferred way to do this kind of thing. - James -- James Morris From shmulik.hen@intel.com Sun Aug 24 10:13:12 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Aug 2003 10:13:17 -0700 (PDT) Received: from hermes.py.intel.com (hermes.py.intel.com [146.152.216.3]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7OHDBoO005690 for ; Sun, 24 Aug 2003 10:13:12 -0700 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.76 2003/08/21 22:58:26 rfjohns1 Exp $) with ESMTP id h7OH8ZX24433 for ; Sun, 24 Aug 2003 17:08:35 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108]) by petasus.py.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 h7OHD2n17049 for ; Sun, 24 Aug 2003 17:13:02 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.254.188]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003082410125829462 ; Sun, 24 Aug 2003 10:12:59 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Shmulik Hen Reply-To: shmulik.hen@intel.com Organization: Intel corp. To: James Morris Subject: Re: [PATCH] convering bonding driver /proc interface to seq_file Date: Sun, 24 Aug 2003 20:12:58 +0300 User-Agent: KMail/1.4.3 Cc: , References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200308242012.58116.shmulik.hen@intel.com> X-archive-position: 5255 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Content-Length: 1168 Lines: 30 On Sunday 24 August 2003 06:15 pm, James Morris wrote: > > Can you provide a pointer to this code? > Please see my email from August 8th with subject: "[SET 1][PATCH 3/6][bonding] backport 2.6 changes to 2.4" sent to netdev@oss.sgi.com and bonding-devel@lists.sourceforge.net. > seq_file is the standard and preferred way to do this kind of > thing. Yes, we know. We wanted to convert to seq_file too, but as it turns out, in order to create a separate proc file for each bond device you need to use the PDE(inode) macro which doesn't exist in 2.4 yet. Since we wanted to maintain compatibility in the bonding module between 2.4 and 2.6 as much as possible, we figured that as a first step we'll start using bond_read_proc() instead of bond_get_info() to allow just that. BTW, we really like the change from /proc/net/bond0/info to /proc/net/bonding/bond0. We thought we'll add that into our cleanup patch set that should come out once the back porting set is accepted. -- | Shmulik Hen Advanced Network Services | | Israel Design Center, Jerusalem | | LAN Access Division, Platform Networking | | Intel Communications Group, Intel corp. | From zaitcev@redhat.com Sun Aug 24 14:58:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Aug 2003 14:58:53 -0700 (PDT) Received: from devserv.devel.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7OLwmoO020940 for ; Sun, 24 Aug 2003 14:58:49 -0700 Received: (from zaitcev@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h7OLwGu10553; Sun, 24 Aug 2003 17:58:16 -0400 Date: Sun, 24 Aug 2003 17:58:16 -0400 From: Pete Zaitcev To: linux390@de.ibm.com Cc: netdev@oss.sgi.com, Pete Zaitcev Subject: Patch for oops in ctc Message-ID: <20030824175816.A872@devserv.devel.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-archive-position: 5257 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zaitcev@redhat.com Precedence: bulk X-list: netdev Content-Length: 1773 Lines: 48 Martin & others: the following bug is still with us. What's the deal? The matter is clear, calling dst_link_failure from an interrupt is illegal (and pointless). I have a separate patch which adds carrier control to ctc according to DaveM's suggestions, but let's at least fix the bug first. -- Pete diff -ur -X dontdiff linux-2.6.0-test4/drivers/s390/net/ctcmain.c linux-2.6.0-test4-s390/drivers/s390/net/ctcmain.c --- linux-2.6.0-test4/drivers/s390/net/ctcmain.c 2003-08-24 14:24:50.000000000 -0700 +++ linux-2.6.0-test4-s390/drivers/s390/net/ctcmain.c 2003-08-24 14:53:25.000000000 -0700 @@ -2441,14 +2441,12 @@ /** * If channels are not running, try to restart them - * notify anybody about a link failure and throw - * away packet. + * and throw away packet. */ if (fsm_getstate(privptr->fsm) != DEV_STATE_RUNNING) { fsm_event(privptr->fsm, DEV_EVENT_START, dev); if (privptr->protocol == CTC_PROTO_LINUX_TTY) return -EBUSY; - dst_link_failure(skb); dev_kfree_skb(skb); privptr->stats.tx_dropped++; privptr->stats.tx_errors++; diff -ur -X dontdiff linux-2.6.0-test4/drivers/s390/net/netiucv.c linux-2.6.0-test4-s390/drivers/s390/net/netiucv.c --- linux-2.6.0-test4/drivers/s390/net/netiucv.c 2003-08-24 14:24:50.000000000 -0700 +++ linux-2.6.0-test4-s390/drivers/s390/net/netiucv.c 2003-08-24 14:51:10.000000000 -0700 @@ -1195,12 +1195,10 @@ /** * If connection is not running, try to restart it - * notify anybody about a link failure and throw - * away packet. + * and throw away packet. */ if (fsm_getstate(privptr->fsm) != DEV_STATE_RUNNING) { fsm_event(privptr->fsm, DEV_EVENT_START, dev); - dst_link_failure(skb); dev_kfree_skb(skb); privptr->stats.tx_dropped++; privptr->stats.tx_errors++; From pe1rxq@amsat.org Sun Aug 24 15:33:08 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 24 Aug 2003 15:33:12 -0700 (PDT) Received: from amsfep14-int.chello.nl (amsfep14-int.chello.nl [213.46.243.22]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7OMX6oO022838 for ; Sun, 24 Aug 2003 15:33:08 -0700 Received: from mail.chello.nl ([212.83.83.7]) by amsfep14-int.chello.nl (InterMail vM.5.01.05.17 201-253-122-126-117-20021021) with SMTP id <20030824223300.UJDK13847.amsfep14-int.chello.nl@mail.chello.nl>; Mon, 25 Aug 2003 00:33:00 +0200 Date: Mon, 25 Aug 2003 00:35:35 +0200 From: Jeroen Vreeken To: "David S . Miller" Cc: Stephen Hemminger , linux-hams@vger.kernel.org, ralf@linux-mips.org, netdev@oss.sgi.com Subject: Re: [RFT][PATCH] ax25 using seq_file Message-ID: <20030825003535.A25139@jeroen.pe1rxq.ampr.org> References: <20030812230951.E28977@jeroen.pe1rxq.ampr.org> <20030812153901.6e700dcb.shemminger@osdl.org> <20030813010301.K28977@jeroen.pe1rxq.ampr.org> <20030812172151.7de0c950.shemminger@osdl.org> <20030813031159.6c6c9629.davem@redhat.com> <20030813173446.A2604@jeroen.pe1rxq.ampr.org> <20030813084252.7b667fb8.davem@redhat.com> <20030820204518.C5568@jeroen.pe1rxq.ampr.org> <20030822131547.0d95fb16.shemminger@osdl.org> <20030824042911.785aff76.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <20030824042911.785aff76.davem@redhat.com>; from davem@redhat.com on Sun, Aug 24, 2003 at 13:29:11 +0200 X-Mailer: Balsa 1.1.0 X-archive-position: 5258 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pe1rxq@amsat.org Precedence: bulk X-list: netdev Content-Length: 649 Lines: 20 On 2003.08.24 13:29:11 +0200 David S. Miller wrote: > On Fri, 22 Aug 2003 13:15:47 -0700 > Stephen Hemminger wrote: > > > Convert AX25 to use the seq_file interface for it's /proc hook. > > > > Jeroen could you test this with real hardware, since without hardware > > the table always comes up empty which is not a good enough test. > > Meanwhile I've applied this. If problems are found you can > send me fixes. > No problems so far.... I gave it a try this evening and until now it keeps running fine with the seq_file patches. I can read the /proc files as much as I like with varying connections going on. Jeroen From vinay-rc@naturesoft.net Mon Aug 25 04:11:05 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Aug 2003 04:11:16 -0700 (PDT) Received: from naturesoft.net ([203.145.184.221]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7PBAkoO007061 for ; Mon, 25 Aug 2003 04:11:00 -0700 Received: from [192.168.0.15] (helo=lima.royalchallenge.com) by naturesoft.net with esmtp (Exim 3.35 #1) id 19rF7Z-0000sl-00; Mon, 25 Aug 2003 16:32:49 +0530 Subject: Re: [PATCH 2.6.0-test4][NET] ni5010.c: remove cli/sti From: Vinay K Nallamothu To: Manfred Spraul Cc: LKML , netdev@oss.sgi.com In-Reply-To: <3F48E870.2070205@colorfullife.com> References: <3F48E870.2070205@colorfullife.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 25 Aug 2003 17:01:29 +0530 Message-Id: <1061811091.1080.3.camel@lima.royalchallenge.com> Mime-Version: 1.0 X-archive-position: 5264 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vinay-rc@naturesoft.net Precedence: bulk X-list: netdev Content-Length: 2543 Lines: 89 Hi, On Sun, 2003-08-24 at 22:01, Manfred Spraul wrote: > Vinay wrote: > > >drivers/net/ni5010.c: > >This patch replaces cli/sti with spinlocks. Compiles fine though > >untested. > > > > > I don't have the hardware either, but the patch seems to be wrong: > The cli() call was in hardware_send_packet(). I assume that this > function should be synchronized against concurrent interrupts - both > functions access the hardware. Due to the dev_xmit_lock, the networking > core already guarantees that hardware_send_packet is never reentered. > cli() provided protection against concurrent interrupts on other cpus, > spin_lock_irqsave() doesn't. > > Could you add a spin_lock()/spin_unlock() into ni5010_interrupt? Thanks for the suggestions. I have updated the patch accordingly. Hope the locking is sufficient. Thanks vinay --- linux-2.6.0-test4/drivers/net/ni5010.c 2003-07-15 17:22:18.000000000 +0530 +++ linux-2.6.0-test4-nvk/drivers/net/ni5010.c 2003-08-25 16:56:02.000000000 +0530 @@ -96,6 +96,7 @@ struct net_device_stats stats; int o_pkt_size; int i_pkt_size; + spinlock_t lock; }; /* Index to functions, as function prototypes. */ @@ -280,11 +281,16 @@ /* DMA is not supported (yet?), so no use detecting it */ if (dev->priv == NULL) { + struct ni5010_local* lp; + dev->priv = kmalloc(sizeof(struct ni5010_local), GFP_KERNEL|GFP_DMA); if (dev->priv == NULL) { printk(KERN_WARNING "%s: Failed to allocate private memory\n", dev->name); return -ENOMEM; } + + lp = (struct ni5010_local*)dev->priv; + spin_lock_init(&lp->lock); } PRINTK2((KERN_DEBUG "%s: I/O #10 passed!\n", dev->name)); @@ -463,6 +469,7 @@ ioaddr = dev->base_addr; lp = (struct ni5010_local *)dev->priv; + spin_lock(&lp->lock); status = inb(IE_ISTAT); PRINTK3((KERN_DEBUG "%s: IE_ISTAT = %#02x\n", dev->name, status)); @@ -479,6 +486,7 @@ if (!xmit_was_error) reset_receiver(dev); + spin_unlock(&lp->lock); return IRQ_HANDLED; } @@ -693,8 +701,7 @@ buf_offs = NI5010_BUFSIZE - length - pad; lp->o_pkt_size = length + pad; - save_flags(flags); - cli(); + spin_lock_irqsave(&lp->lock, flags); outb(0, EDLC_RMASK); /* Mask all receive interrupts */ outb(0, IE_MMODE); /* Put Xmit buffer on system bus */ @@ -712,7 +719,7 @@ outb(MM_EN_XMT | MM_MUX, IE_MMODE); /* Begin transmission */ outb(XM_ALL, EDLC_XMASK); /* Cause interrupt after completion or fail */ - restore_flags(flags); + spin_unlock_irqrestore(&lp->lock, flags); netif_wake_queue(dev); From laforge@gnumonks.org Mon Aug 25 04:15:56 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Aug 2003 04:16:05 -0700 (PDT) Received: from coruscant.gnumonks.org (mail@coruscant.franken.de [193.174.159.226]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7PBFsoO007530 for ; Mon, 25 Aug 2003 04:15:56 -0700 Received: from [192.168.200.2] (helo=sunbeam.gnumonks.org) by coruscant.gnumonks.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.20) id 19rFKC-0004bf-Mu; Mon, 25 Aug 2003 13:15:52 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.20) id 19rFDb-0004fZ-AF; Mon, 25 Aug 2003 13:09:03 +0200 Date: Mon, 25 Aug 2003 13:09:03 +0200 From: Harald Welte To: Lennert Buytenhek Cc: netdev@oss.sgi.com Subject: Re: [PATCH,RFC] explicit connection confirmation Message-ID: <20030825110903.GA17715@sunbeam.de.gnumonks.org> References: <20021107093207.GA30666@gnu.org> <20030814131156.GA21892@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: <20030814131156.GA21892@gnu.org> X-Operating-system: Linux sunbeam 2.6.0-test1-nftest X-Date: Today is Boomtime, the 18th day of Bureaucracy in the YOLD 3169 User-Agent: Mutt/1.5.4i X-archive-position: 5265 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 1505 Lines: 50 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 14, 2003 at 09:11:56AM -0400, Lennert Buytenhek wrote: > Hi, >=20 > Below is the original email I sent to netdev about nine months ago > announcing selective connection acceptance support for TCP sockets. > I have forward-ported the 2.4.18 patch to 2.6.0-test2, included below. > No functional changes have been made. That is great! Thanks for not forgetting about this issue. I think this feature would really be great to develop _really_ transparent proxies. > Could someone have a look at it? I'm not a core networking guy, but it looks fine to me. Dave, Andi, Alexey, James: Would this be a candidate for kernel inclusion at some point? > Lennert --=20 - Harald Welte http://www.gnumonks.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Se5PXaXGVTD0i/8RAnsnAKCD+2JPd5DJOUBY6xOtjWROd4rpMgCeO1dB j9lZUVR/McLciqfBaKkoT34= =MakQ -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- From chas@cmf.nrl.navy.mil Mon Aug 25 05:22:42 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Aug 2003 05:22:51 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7PCMeoO013030 for ; Mon, 25 Aug 2003 05:22:41 -0700 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.7/8.12.7) with ESMTP id h7PCM3sG003428; Mon, 25 Aug 2003 08:22:05 -0400 (EDT) Message-Id: <200308251222.h7PCM3sG003428@ginger.cmf.nrl.navy.mil> To: "David S. Miller" cc: Vinay K Nallamothu , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Reply-to: chas3@users.sourceforge.net Subject: Re: [PATCH 2.6.0-test4][ATM][RESEND] fix ambassador.c In-Reply-To: Message from "David S. Miller" of "Sun, 24 Aug 2003 03:46:37 PDT." <20030824034637.522fdeb3.davem@redhat.com> Date: Mon, 25 Aug 2003 08:22:04 -0400 From: chas williams X-Spam-Score: () hits=-2.9 X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 5266 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 6927 Lines: 245 In message <20030824034637.522fdeb3.davem@redhat.com>,"David S. Miller" writes: >Please make sure to send this to the ATM maintainer. He's very >responsible so I only take significant ATM patches that come through responsible perhaps but slow. anyway the changes seem fine. del_timer during module exit should probably be del_timer_sync so i have included that as a seperate patch. [atm]: [ambassador] clean up the code making use of sti/cli (from vinay-rc@naturesoft.net) # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1281 -> 1.1282 # drivers/atm/ambassador.c 1.14 -> 1.15 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 03/08/25 chas@relax.cmf.nrl.navy.mil 1.1282 # [ambassador] clean up the code making use of sti/cli (from vinay-rc@naturesoft.net) # -------------------------------------------- # diff -Nru a/drivers/atm/ambassador.c b/drivers/atm/ambassador.c --- a/drivers/atm/ambassador.c Mon Aug 25 08:12:53 2003 +++ b/drivers/atm/ambassador.c Mon Aug 25 08:12:53 2003 @@ -310,10 +310,11 @@ 0xdeadbeef }; +static void do_housekeeping (unsigned long arg); /********** globals **********/ static amb_dev * amb_devs = NULL; -static struct timer_list housekeeping; +static struct timer_list housekeeping = TIMER_INITIALIZER(do_housekeeping, 0, 1); static unsigned short debug = 0; static unsigned int cmds = 8; @@ -937,63 +938,6 @@ return IRQ_HANDLED; } -/********** don't panic... yeah, right **********/ - -#ifdef DEBUG_AMBASSADOR -static void dont_panic (amb_dev * dev) { - amb_cq * cq = &dev->cq; - volatile amb_cq_ptrs * ptrs = &cq->ptrs; - amb_txq * txq; - amb_rxq * rxq; - command * cmd; - tx_in * tx; - tx_simple * tx_descr; - unsigned char pool; - rx_in * rx; - - unsigned long flags; - save_flags (flags); - cli(); - - PRINTK (KERN_INFO, "don't panic - putting adapter into reset"); - wr_plain (dev, offsetof(amb_mem, reset_control), - rd_plain (dev, offsetof(amb_mem, reset_control)) | AMB_RESET_BITS); - - PRINTK (KERN_INFO, "marking all commands complete"); - for (cmd = ptrs->start; cmd < ptrs->limit; ++cmd) - cmd->request = cpu_to_be32 (SRB_COMPLETE); - - PRINTK (KERN_INFO, "completing all TXs"); - txq = &dev->txq; - tx = txq->in.ptr; - while (txq->pending--) { - if (tx == txq->in.start) - tx = txq->in.limit; - --tx; - tx_descr = bus_to_virt (be32_to_cpu (tx->tx_descr_addr)); - amb_kfree_skb (tx_descr->skb); - kfree (tx_descr); - } - - PRINTK (KERN_INFO, "freeing all RX buffers"); - for (pool = 0; pool < NUM_RX_POOLS; ++pool) { - rxq = &dev->rxq[pool]; - rx = rxq->in.ptr; - while (rxq->pending--) { - if (rx == rxq->in.start) - rx = rxq->in.limit; - --rx; - dev_kfree_skb_any (bus_to_virt (rx->handle)); - } - } - - PRINTK (KERN_INFO, "don't panic over - close all VCs and rmmod"); - set_bit (dead, &dev->flags); - restore_flags (flags); - return; -} -#endif - /********** make rate (not quite as much fun as Horizon) **********/ static unsigned int make_rate (unsigned int rate, rounding r, @@ -1420,32 +1364,6 @@ return; } -/********** DebugIoctl **********/ - -#if 0 -static int amb_ioctl (struct atm_dev * dev, unsigned int cmd, void * arg) { - unsigned short newdebug; - if (cmd == AMB_SETDEBUG) { - if (!capable(CAP_NET_ADMIN)) - return -EPERM; - if (copy_from_user (&newdebug, arg, sizeof(newdebug))) { - // moan - return -EFAULT; - } else { - debug = newdebug; - return 0; - } - } else if (cmd == AMB_DONTPANIC) { - if (!capable(CAP_NET_ADMIN)) - return -EPERM; - dont_panic (dev); - } else { - // moan - return -ENOIOCTLCMD; - } -} -#endif - /********** Set socket options for a VC **********/ // int amb_getsockopt (struct atm_vcc * atm_vcc, int level, int optname, void * optval, int optlen); @@ -1524,33 +1442,6 @@ tx.tx_descr_length = cpu_to_be16 (sizeof(tx_frag)+sizeof(tx_frag_end)); tx.tx_descr_addr = cpu_to_be32 (virt_to_bus (&tx_descr->tx_frag)); -#ifdef DEBUG_AMBASSADOR - /* wey-hey! */ - if (vc == 1023) { - unsigned int i; - unsigned short d = 0; - char * s = skb->data; - switch (*s++) { - case 'D': { - for (i = 0; i < 4; ++i) { - d = (d<<4) | ((*s <= '9') ? (*s - '0') : (*s - 'a' + 10)); - ++s; - } - PRINTK (KERN_INFO, "debug bitmap is now %hx", debug = d); - break; - } - case 'R': { - if (*s++ == 'e' && *s++ == 's' && *s++ == 'e' && *s++ == 't') - dont_panic (dev); - break; - } - default: { - break; - } - } - } -#endif - while (tx_give (dev, &tx)) schedule(); return 0; @@ -1663,21 +1554,14 @@ /********** Operation Structure **********/ static const struct atmdev_ops amb_ops = { - .open = amb_open, + .open = amb_open, .close = amb_close, - .send = amb_send, + .send = amb_send, .proc_read = amb_proc_read, .owner = THIS_MODULE, }; /********** housekeeping **********/ - -static inline void set_timer (struct timer_list * timer, unsigned long delay) { - timer->expires = jiffies + delay; - add_timer (timer); - return; -} - static void do_housekeeping (unsigned long arg) { amb_dev * dev = amb_devs; // data is set to zero at module unload @@ -1693,7 +1577,7 @@ dev = dev->prev; } - set_timer (&housekeeping, 10*HZ); + mod_timer(&housekeeping, jiffies + 10*HZ); } return; @@ -2579,11 +2463,7 @@ devs = amb_probe(); if (devs) { - init_timer (&housekeeping); - housekeeping.function = do_housekeeping; - // paranoia - housekeeping.data = 1; - set_timer (&housekeeping, 0); + mod_timer (&housekeeping, jiffies); } else { PRINTK (KERN_INFO, "no (usable) adapters found"); } [atm]: [ambassador] use del_timer_sync instead # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1282 -> 1.1283 # drivers/atm/ambassador.c 1.15 -> 1.16 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 03/08/25 chas@relax.cmf.nrl.navy.mil 1.1283 # [ambassador] use del_timer_sync instead # -------------------------------------------- # diff -Nru a/drivers/atm/ambassador.c b/drivers/atm/ambassador.c --- a/drivers/atm/ambassador.c Mon Aug 25 08:13:04 2003 +++ b/drivers/atm/ambassador.c Mon Aug 25 08:13:04 2003 @@ -2480,7 +2480,7 @@ // paranoia housekeeping.data = 0; - del_timer (&housekeeping); + del_timer_sync(&housekeeping); while (amb_devs) { dev = amb_devs; From cfriesen@nortelnetworks.com Mon Aug 25 08:08:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Aug 2003 08:08:56 -0700 (PDT) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7PF8qoO023697 for ; Mon, 25 Aug 2003 08:08:53 -0700 Received: from zcard307.ca.nortel.com (americasm01.nt.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7PF8iK24673; Mon, 25 Aug 2003 11:08:44 -0400 (EDT) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id R3KYN1J5; Mon, 25 Aug 2003 11:08:45 -0400 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q8C6JQD2; Mon, 25 Aug 2003 11:08:45 -0400 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 3CD142D957; Mon, 25 Aug 2003 11:08:43 -0400 (EDT) Message-ID: <3F4A267B.1000405@nortelnetworks.com> Date: Mon, 25 Aug 2003 11:08:43 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Linux Kernel Mailing List , netdev@oss.sgi.com Subject: why are error messages suppressed if IP_RECVERR is not set? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5267 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfriesen@nortelnetworks.com Precedence: bulk X-list: netdev I'm tracking down an issue where we are sending udp packets and they are being dropped (I suspect) in the device queue. In ip_build_xmit() we get the error code back saying that the packet was dropped, but unless IP_RECVERR is set, it seems that this error is hidden from userspace. I notice that the man page says that sendto will never give an errno of ENOBUFS, but if you turn on IP_RECVERR this is exactly what will happen. I guess I have two questions then: 1) why do we hide the fact that we've dropped the packet, and 2) why doesn't the man page talk about the IP_RECVERR option? I'm using 2.4.18, if it matters. Thanks, Chris -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com From shemminger@osdl.org Mon Aug 25 08:47:21 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Aug 2003 08:48:00 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7PFkeoO031715 for ; Mon, 25 Aug 2003 08:47:21 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7PFjao06903; Mon, 25 Aug 2003 08:45:36 -0700 Date: Mon, 25 Aug 2003 08:45:21 -0700 From: Stephen Hemminger To: James Morris Cc: "Hen, Shmulik" , Chad Tindel , Jay Vosburgh , "David S. Miller" , Jeff Garzik , , Subject: Re: [PATCH] convering bonding driver /proc interface to seq_file Message-Id: <20030825084521.4e3e916c.shemminger@osdl.org> In-Reply-To: References: Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5268 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Mon, 25 Aug 2003 01:15:13 +1000 (EST) James Morris wrote: > On Sat, 23 Aug 2003, Hen, Shmulik wrote: > > > Also, instead of using a seq_file interface and using a > > pointer to skip to the relevant part, we've used a different > > proc creation interface that allows passing a pointer to bond > > and thus retrieve just the relevant bond device's data. > > Can you provide a pointer to this code? > > seq_file is the standard and preferred way to do this kind of thing. Using a pointer with seq_file was really easy. init... bond->bond_proc_file = create_proc_entry(dev->name, S_IRUGO, bond_proc_dir); if (bond->bonc_proc_file) { bond->bond_proc_file->data = bond; bond->bond_proc_file->proc_fops = &bond_info_fops; } open... rc = seq_open(file, &bond_info_seq_ops); if (!rc) { seq = file->private_data; seq->private = PDE(inode)->data; } From shmulik.hen@intel.com Mon Aug 25 11:43:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Aug 2003 11:43:41 -0700 (PDT) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7PIhVoO017700 for ; Mon, 25 Aug 2003 11:43:35 -0700 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.76 2003/08/21 22:58:26 rfjohns1 Exp $) with ESMTP id h7PIc4W23919 for ; Mon, 25 Aug 2003 18:38:04 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h7PIkWR19747 for ; Mon, 25 Aug 2003 18:46:33 GMT Received: from hasmsx331.ger.corp.intel.com ([143.185.63.144]) by hasmsxvs01.iil.intel.com (NAVGW 2.5.2.11) with SMTP id M2003082521432407131 ; Mon, 25 Aug 2003 21:43:24 +0300 Received: from hasmsx403.ger.corp.intel.com ([143.185.63.109]) by hasmsx331.ger.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 25 Aug 2003 21:43:24 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [PATCH] convering bonding driver /proc interface to seq_file Date: Mon, 25 Aug 2003 21:43:24 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] convering bonding driver /proc interface to seq_file Thread-Index: AcNrL7+Qq6ZJTHQkRxGIJFUoe9lQxgACMhig From: "Hen, Shmulik" To: "Stephen Hemminger" , "James Morris" Cc: , X-OriginalArrivalTime: 25 Aug 2003 18:43:24.0386 (UTC) FILETIME=[C3CD5420:01C36B38] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7PIhVoO017700 X-archive-position: 5269 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev > -----Original Message----- > From: Stephen Hemminger [mailto:shemminger@osdl.org] > Sent: Monday, August 25, 2003 6:45 PM > To: James Morris > Cc: Hen, Shmulik; Chad Tindel; Jay Vosburgh; David S. Miller; > Jeff Garzik; bonding-devel@lists.sourceforge.net; netdev@oss.sgi.com > Subject: Re: [PATCH] convering bonding driver /proc interface > to seq_file > > Using a pointer with seq_file was really easy. [snip] > seq->private = PDE(inode)->data; Yes, but PDE(inode) does not exist in 2.4 yet, and we wanted to achieve compatibility between bonding in 2.6 and 2.4 first so we may then update 2.6 bonding which is too far behind what's in 2.4 bonding. Once this is done it will be possible to develop on 2.6, and back port into 2.4 from time to time. Shmulik. From shemminger@osdl.org Mon Aug 25 12:27:51 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Aug 2003 12:27:58 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7PJRooO020312 for ; Mon, 25 Aug 2003 12:27:51 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7PJRIo25840; Mon, 25 Aug 2003 12:27:18 -0700 Date: Mon, 25 Aug 2003 12:27:03 -0700 From: Stephen Hemminger To: "Hen, Shmulik" Cc: "James Morris" , , Subject: Re: [PATCH] convering bonding driver /proc interface to seq_file Message-Id: <20030825122703.47cefa5b.shemminger@osdl.org> In-Reply-To: References: Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5270 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Mon, 25 Aug 2003 21:43:24 +0300 "Hen, Shmulik" wrote: > > -----Original Message----- > > From: Stephen Hemminger [mailto:shemminger@osdl.org] > > Sent: Monday, August 25, 2003 6:45 PM > > To: James Morris > > Cc: Hen, Shmulik; Chad Tindel; Jay Vosburgh; David S. Miller; > > Jeff Garzik; bonding-devel@lists.sourceforge.net; netdev@oss.sgi.com > > Subject: Re: [PATCH] convering bonding driver /proc interface > > to seq_file > > > > Using a pointer with seq_file was really easy. > [snip] > > seq->private = PDE(inode)->data; > > Yes, but PDE(inode) does not exist in 2.4 yet, and we wanted > to achieve compatibility between bonding in 2.6 and 2.4 first > so we may then update 2.6 bonding which is too far behind > what's in 2.4 bonding. Once this is done it will be possible > to develop on 2.6, and back port into 2.4 from time to time. > > > Shmulik. #ifndef PDE #define PDE(i) ((struct proc_dir_entry *)(i)->u.generic_ip) #endif From jkenisto@us.ibm.com Mon Aug 25 14:34:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Aug 2003 14:34:29 -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 h7PLYHoO028838 for ; Mon, 25 Aug 2003 14:34:23 -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 h7PLXGhu156650; Mon, 25 Aug 2003 17:33:16 -0400 Received: from us.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h7PLXDfp301946; Mon, 25 Aug 2003 15:33:14 -0600 Message-ID: <3F4A8027.6FE3F594@us.ibm.com> Date: Mon, 25 Aug 2003 14:31:19 -0700 From: Jim Keniston X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: LKML , netdev CC: Jeff Garzik , "Feldman, Scott" , Larry Kessler , Greg KH , Randy Dunlap , Alan Cox , Andrew Morton , jkenisto Subject: [PATCH 1/4] Net device error logging, revised Content-Type: multipart/mixed; boundary="------------0907E3D825C8371F67E79D17" X-archive-position: 5271 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkenisto@us.ibm.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------0907E3D825C8371F67E79D17 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This patch extends the concept of Linux 2.6's dev_* logging macros to support network devices. Analogous netdev_* macros are defined. This feature is part of an effort to simplify error-log analysis by providing more consistent and informative messages. This is a modification of a proposal from May. The changes reflect suggestions made on LKML, at the Kernel Summit, and at OLS. Calls to the netdev_* macros (netdev_printk and wrappers such as netdev_err) are intended to replace calls to printk in network device drivers. These macros have the following characteristics: - Same format + args as the corresponding printk call. - Approximately the same amount of text as the corresponding printk call. - The first arg is a pointer to the net_device struct. - The second (optional) arg, which is a NETIF_MSG_* message level, can be used to implement verbosity control. - Standard message prefixes: verbose (see below) during probe, or just the interface name once the device is registered. - The current implementation just calls printk. However, the netdev_* interface (and availability of the net_device pointer) opens the door for logging additional information (via printk, via evlog/netlink, etc.) as desired, with no change to driver code. Examples: netdev_err(netdev, RX_ERR, "No mem: dropped packet\n"); logs a message such as the following if the NETIF_MSG_RX_ERR bit is set in netdev->msg_enable. eth2: No mem: dropped packet netdev_err(netdev,, "The EEPROM Checksum Is Not Valid\n"); unconditionally logs a message such as: eth%d (e1000 0000:00:03.0): The EEPROM Checksum Is Not Valid The message's prefix includes the driver name and bus ID because the message is logged at probe time, before netdev is registered. Note that the netdev_* interface can be used in v2.4 drivers as well, but in a v2.4 implementation, the message prefix would always be just the interface name. Three other patches are included in subsequent emails. These patch the e100, e1000, and tg3 Ethernet drivers to use the netdev_* macros. (For e100 and e1000, they also add the necessary scaffolding for verbosity control via the NETIF_MSG_* message levels). Jim Keniston IBM Linux Technology Center ----- --------------0907E3D825C8371F67E79D17 Content-Type: text/plain; charset=us-ascii; name="netdev-2.6.0-test4.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netdev-2.6.0-test4.patch" diff -Naur linux.org/include/linux/netdevice.h linux.netdev.patched/include/linux/netdevice.h --- linux.org/include/linux/netdevice.h Mon Aug 25 13:29:38 2003 +++ linux.netdev.patched/include/linux/netdevice.h Mon Aug 25 13:29:38 2003 @@ -470,6 +470,9 @@ struct divert_blk *divert; #endif /* CONFIG_NET_DIVERT */ + /* NETIF_MSG_* flags to control the types of events we log */ + int msg_enable; + /* class/net/name entry */ struct class_device class_dev; }; @@ -743,6 +746,8 @@ NETIF_MSG_PKTDATA = 0x1000, NETIF_MSG_HW = 0x2000, NETIF_MSG_WOL = 0x4000, + NETIF_MSG_ALL = -1, /* always log message */ + NETIF_MSG_ = -1 /* always log message */ }; #define netif_msg_drv(p) ((p)->msg_enable & NETIF_MSG_DRV) @@ -869,6 +874,36 @@ extern void dev_clear_fastroute(struct net_device *dev); #endif +/* debugging and troubleshooting/diagnostic helpers. */ +/** + * netdev_printk() - Log message with interface name, gated by message level + * @sevlevel: severity level -- e.g., KERN_INFO + * @netdev: net_device pointer + * @msglevel: a standard message-level flag with the NETIF_MSG_ prefix removed. + * Unless msglevel is NETIF_MSG_ALL, or omitted, log the message only if + * that flag is set in netdev->msg_enable. + * @format: as with printk + * @args: as with printk + */ +extern int __netdev_printk(const char *sevlevel, + const struct net_device *netdev, int msglevel, const char *format, ...); +#define netdev_printk(sevlevel, netdev, msglevel, format, arg...) \ + __netdev_printk(sevlevel , netdev , NETIF_MSG_##msglevel , \ + format , ## arg) + +#ifdef DEBUG +#define netdev_dbg(netdev, msglevel, format, arg...) \ + netdev_printk(KERN_DEBUG , netdev , msglevel , format , ## arg) +#else +#define netdev_dbg(netdev, msglevel, format, arg...) do {} while (0) +#endif + +#define netdev_err(netdev, msglevel, format, arg...) \ + netdev_printk(KERN_ERR , netdev , msglevel , format , ## arg) +#define netdev_info(netdev, msglevel, format, arg...) \ + netdev_printk(KERN_INFO , netdev , msglevel , format , ## arg) +#define netdev_warn(netdev, msglevel, format, arg...) \ + netdev_printk(KERN_WARNING , netdev , msglevel , format , ## arg) #endif /* __KERNEL__ */ diff -Naur linux.org/net/core/dev.c linux.netdev.patched/net/core/dev.c --- linux.org/net/core/dev.c Mon Aug 25 13:29:38 2003 +++ linux.netdev.patched/net/core/dev.c Mon Aug 25 13:29:38 2003 @@ -3116,5 +3116,71 @@ out: return rc; } - subsys_initcall(net_dev_init); + +/** + * __netdev_printk() - Log message with interface name, gated by message level + * @sevlevel: severity level -- e.g., KERN_INFO + * @netdev: net_device pointer + * @msglevel: a standard message-level flag such as NETIF_MSG_PROBE. + * Unless msglevel is NETIF_MSG_ALL, log the message only if + * that flag is set in netdev->msg_enable. + * @format: as with printk + * @args: as with printk + * + * Does the work for the netdev_printk macro. + * For a lot of network drivers, the probe function looks like + * ... + * netdev = alloc_netdev(...); // or alloc_etherdev(...) + * SET_NETDEV_DEV(netdev, dev); + * ... + * register_netdev(netdev); + * ... + * netdev_printk and its wrappers (e.g., netdev_err) can be used as + * soon as you have a valid net_device pointer -- e.g., from alloc_netdev, + * alloc_etherdev, or init_etherdev. (Before that, use dev_printk and + * its wrappers to report device errors.) It's common for an interface to + * have a name like "eth%d" until the device is successfully configured, + * and the call to register_netdev changes it to a "real" name like "eth0". + * + * If the interface's reg_state is NETREG_REGISTERED, we assume that it has + * been successfully set up in sysfs, and we prepend only the interface name + * to the message -- e.g., "eth0: NIC Link is Down". The interface + * name can be used to find eth0's driver, bus ID, etc. in sysfs. + * + * For any other value of reg_state, we prepend the driver name and bus ID + * as well as the (possibly incomplete) interface name -- e.g., + * "eth%d (e100 0000:00:03.0): Failed to map PCI address..." + * + * Probe functions that alloc and register in one step (via init_etherdev), + * or otherwise register the device before the probe completes successfully, + * may need to take other steps to ensure that the failing device is clearly + * identified. + */ +int __netdev_printk(const char *sevlevel, const struct net_device *netdev, + int msglevel, const char *format, ...) +{ + if (!netdev || !format) { + return -EINVAL; + } + if (msglevel == NETIF_MSG_ALL || (netdev->msg_enable & msglevel)) { + char msg[512]; + va_list args; + struct device *dev = netdev->class_dev.dev; + + va_start(args, format); + vsnprintf(msg, 512, format, args); + va_end(args); + + if (!sevlevel) { + sevlevel = ""; + } + if (netdev->reg_state == NETREG_REGISTERED || !dev) { + printk("%s%s: %s", sevlevel, netdev->name, msg); + } else { + printk("%s%s (%s %s): %s", sevlevel, netdev->name, + dev->driver->name, dev->bus_id, msg); + } + } + return 0; +} diff -Naur linux.org/net/netsyms.c linux.netdev.patched/net/netsyms.c --- linux.org/net/netsyms.c Mon Aug 25 13:29:38 2003 +++ linux.netdev.patched/net/netsyms.c Mon Aug 25 13:29:38 2003 @@ -210,6 +210,7 @@ EXPORT_SYMBOL(net_ratelimit); EXPORT_SYMBOL(net_random); EXPORT_SYMBOL(net_srandom); +EXPORT_SYMBOL(__netdev_printk); /* Needed by smbfs.o */ EXPORT_SYMBOL(__scm_destroy); --------------0907E3D825C8371F67E79D17-- From jkenisto@us.ibm.com Mon Aug 25 14:42:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Aug 2003 14:42:32 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7PLgOoO029891 for ; Mon, 25 Aug 2003 14:42:24 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h7PLfWUj318704; Mon, 25 Aug 2003 17:41:32 -0400 Received: from us.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h7PLfTfp132424; Mon, 25 Aug 2003 15:41:30 -0600 Message-ID: <3F4A8217.33647992@us.ibm.com> Date: Mon, 25 Aug 2003 14:39:35 -0700 From: Jim Keniston X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: LKML , netdev , Jeff Garzik , "Feldman, Scott" , Larry Kessler , Greg KH , Randy Dunlap , Alan Cox , Andrew Morton , jkenisto Subject: Subject: [PATCH 2/4] Net device error logging, revised (e100) References: <3F4A8027.6FE3F594@us.ibm.com> Content-Type: multipart/mixed; boundary="------------09E8359C42A09191C013F7B9" X-archive-position: 5272 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkenisto@us.ibm.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------09E8359C42A09191C013F7B9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here's a patch to modify the v2.6.0-test4 e100 driver to use netdev_* macros and support verbosity control via the NETIF_MSG_* message levels. Jim Keniston IBM Linux Technology Center --------------09E8359C42A09191C013F7B9 Content-Type: text/plain; charset=us-ascii; name="e100-2.6.0-test4.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="e100-2.6.0-test4.patch" diff -Naur linux.org/drivers/net/e100/e100_config.c linux.e100.patched/drivers/net/e100/e100_config.c --- linux.org/drivers/net/e100/e100_config.c Mon Aug 25 13:29:38 2003 +++ linux.e100.patched/drivers/net/e100/e100_config.c Mon Aug 25 13:29:38 2003 @@ -565,7 +565,8 @@ config_byte = CB_CFIG_LOOPBACK_EXTERNAL; break; default: - printk(KERN_NOTICE "e100: e100_config_loopback_mode: " + netdev_printk(KERN_NOTICE, bdp->device,, + "e100_config_loopback_mode: " "Invalid argument 'mode': %d\n", mode); goto exit; } diff -Naur linux.org/drivers/net/e100/e100_main.c linux.e100.patched/drivers/net/e100/e100_main.c --- linux.org/drivers/net/e100/e100_main.c Mon Aug 25 13:29:38 2003 +++ linux.e100.patched/drivers/net/e100/e100_main.c Mon Aug 25 13:29:38 2003 @@ -78,6 +78,7 @@ #include #include #include +#include #include "e100.h" #include "e100_ucode.h" #include "e100_config.h" @@ -215,12 +216,19 @@ static void e100_dump_stats_cntrs(struct e100_private *); static void e100_check_options(int board, struct e100_private *bdp); -static void e100_set_int_option(int *, int, int, int, int, char *); +static void e100_set_int_option(struct e100_private *bdp, int *, + int, int, int, int, char *); static void e100_set_bool_option(struct e100_private *bdp, int, u32, int, char *); unsigned char e100_wait_exec_cmplx(struct e100_private *, u32, u8, u8); void e100_exec_cmplx(struct e100_private *, u32, u8); +static int debug = -1; +#define E100_DFLT_MSGLVL (NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_LINK) + +module_param(debug, int, 0); +MODULE_PARM_DESC(debug, "e100 debug level: 0 (quiet) to 15 (verbose)"); + /** * e100_get_rx_struct - retrieve cell to hold skb buff from the pool * @bdp: atapter's private data struct @@ -433,15 +441,12 @@ e100_wait_exec_simple(struct e100_private *bdp, u8 scb_cmd_low) { if (!e100_wait_scb(bdp)) { - printk(KERN_DEBUG "e100: %s: e100_wait_exec_simple: failed\n", - bdp->device->name); + netdev_dbg(bdp->device,, "e100_wait_exec_simple: failed\n"); #ifdef E100_CU_DEBUG - printk(KERN_ERR "e100: %s: Last command (%x/%x) " - "timeout\n", bdp->device->name, + netdev_err(bdp->device,, "Last command (%x/%x) timeout\n", bdp->last_cmd, bdp->last_sub_cmd); - printk(KERN_ERR "e100: %s: Current simple command (%x) " - "can't be executed\n", - bdp->device->name, scb_cmd_low); + netdev_err(bdp->device,, "Current simple command (%x) " + "can't be executed\n", scb_cmd_low); #endif return false; } @@ -466,12 +471,10 @@ { if (!e100_wait_scb(bdp)) { #ifdef E100_CU_DEBUG - printk(KERN_ERR "e100: %s: Last command (%x/%x) " - "timeout\n", bdp->device->name, + netdev_err(bdp->device,, "Last command (%x/%x) timeout\n", bdp->last_cmd, bdp->last_sub_cmd); - printk(KERN_ERR "e100: %s: Current complex command " - "(%x/%x) can't be executed\n", - bdp->device->name, cmd, sub_cmd); + netdev_err(bdp->device,, "Current complex command " + "(%x/%x) can't be executed\n", cmd, sub_cmd); #endif return false; } @@ -562,7 +565,7 @@ dev = alloc_etherdev(sizeof (struct e100_private)); if (dev == NULL) { - printk(KERN_ERR "e100: Not able to alloc etherdev struct\n"); + dev_err(&pcid->dev, "Not able to alloc etherdev struct\n"); rc = -ENODEV; goto out; } @@ -584,6 +587,15 @@ pci_set_drvdata(pcid, dev); SET_NETDEV_DEV(dev, &pcid->dev); + if (debug < 0) { + dev->msg_enable = E100_DFLT_MSGLVL; + } else if (debug >= 8 * sizeof(int)) { + /* All levels enabled */ + dev->msg_enable = -1; + } else { + dev->msg_enable = (1 << debug) - 1; + } + if ((rc = e100_alloc_space(bdp)) != 0) { goto err_dev; } @@ -655,7 +667,7 @@ e100_check_options(e100nics, bdp); if (!e100_init(bdp)) { - printk(KERN_ERR "e100: Failed to initialize, instance #%d\n", + netdev_err(dev,, "Failed to initialize, instance #%d\n", e100nics); rc = -ENODEV; goto err_unregister_netdev; @@ -665,7 +677,7 @@ cal_checksum = e100_eeprom_calculate_chksum(bdp); read_checksum = e100_eeprom_read(bdp, (bdp->eeprom_size - 1)); if (cal_checksum != read_checksum) { - printk(KERN_ERR "e100: Corrupted EEPROM on instance #%d\n", + netdev_err(dev,, "Corrupted EEPROM on instance #%d\n", e100nics); rc = -ENODEV; goto err_unregister_netdev; @@ -675,9 +687,8 @@ e100_get_speed_duplex_caps(bdp); - printk(KERN_NOTICE - "e100: %s: %s\n", - bdp->device->name, "Intel(R) PRO/100 Network Connection"); + netdev_printk(KERN_NOTICE, + dev, PROBE, "Intel(R) PRO/100 Network Connection\n"); e100_print_brd_conf(bdp); bdp->wolsupported = 0; @@ -694,8 +705,6 @@ bdp->wolopts = WAKE_MAGIC; } - printk(KERN_NOTICE "\n"); - goto out; err_unregister_netdev: @@ -839,26 +848,28 @@ e100_check_options(int board, struct e100_private *bdp) { if (board >= E100_MAX_NIC) { - printk(KERN_NOTICE - "e100: No configuration available for board #%d\n", - board); - printk(KERN_NOTICE "e100: Using defaults for all values\n"); + netdev_printk(KERN_NOTICE, bdp->device, PROBE, + "No configuration available for board #%d. " + "Using defaults for all values\n", board); board = E100_MAX_NIC; } - e100_set_int_option(&(bdp->params.TxDescriptors), TxDescriptors[board], + e100_set_int_option(bdp, &(bdp->params.TxDescriptors), + TxDescriptors[board], E100_MIN_TCB, E100_MAX_TCB, E100_DEFAULT_TCB, "TxDescriptor count"); - e100_set_int_option(&(bdp->params.RxDescriptors), RxDescriptors[board], + e100_set_int_option(bdp, &(bdp->params.RxDescriptors), + RxDescriptors[board], E100_MIN_RFD, E100_MAX_RFD, E100_DEFAULT_RFD, "RxDescriptor count"); - e100_set_int_option(&(bdp->params.e100_speed_duplex), + e100_set_int_option(bdp, &(bdp->params.e100_speed_duplex), e100_speed_duplex[board], 0, 4, E100_DEFAULT_SPEED_DUPLEX, "speed/duplex mode"); - e100_set_int_option(&(bdp->params.ber), ber[board], 0, ZLOCK_MAX_ERRORS, + e100_set_int_option(bdp, &(bdp->params.ber), ber[board], 0, + ZLOCK_MAX_ERRORS, E100_DEFAULT_BER, "Bit Error Rate count"); e100_set_bool_option(bdp, XsumRX[board], PRM_XSUMRX, E100_DEFAULT_XSUM, @@ -883,11 +894,11 @@ E100_DEFAULT_BUNDLE_SMALL_FR, "CPU saver bundle small frames value"); - e100_set_int_option(&(bdp->params.IntDelay), IntDelay[board], 0x0, + e100_set_int_option(bdp, &(bdp->params.IntDelay), IntDelay[board], 0x0, 0xFFFF, E100_DEFAULT_CPUSAVER_INTERRUPT_DELAY, "CPU saver interrupt delay value"); - e100_set_int_option(&(bdp->params.BundleMax), BundleMax[board], 0x1, + e100_set_int_option(bdp, &(bdp->params.BundleMax), BundleMax[board], 0x1, 0xFFFF, E100_DEFAULT_CPUSAVER_BUNDLE_MAX, "CPU saver bundle max value"); @@ -895,6 +906,7 @@ /** * e100_set_int_option - check and set an integer option + * @bdp: adapter's private data struct * @option: a pointer to the relevant option field * @val: the value specified * @min: the minimum valid value @@ -907,22 +919,22 @@ * Otherwise, if the value is invalid, change it to the default. */ void __devinit -e100_set_int_option(int *option, int val, int min, int max, int default_val, - char *name) +e100_set_int_option(struct e100_private *bdp, int *option, int val, + int min, int max, int default_val, char *name) { if (val == -1) { /* no value specified. use default */ *option = default_val; } else if ((val < min) || (val > max)) { - printk(KERN_NOTICE - "e100: Invalid %s specified (%i). " - "Valid range is %i-%i\n", - name, val, min, max); - printk(KERN_NOTICE "e100: Using default %s of %i\n", name, - default_val); + netdev_printk(KERN_NOTICE, bdp->device, PROBE, + "Invalid %s specified (%i). " + "Valid range is %i-%i. " + "Using default %s of %i\n", + name, val, min, max, name, default_val); *option = default_val; } else { - printk(KERN_INFO "e100: Using specified %s of %i\n", name, val); + netdev_info(bdp->device, PROBE, + "Using specified %s of %i\n", name, val); *option = val; } } @@ -949,17 +961,17 @@ bdp->params.b_params |= mask; } else if ((val != true) && (val != false)) { - printk(KERN_NOTICE - "e100: Invalid %s specified (%i). " - "Valid values are %i/%i\n", - name, val, false, true); - printk(KERN_NOTICE "e100: Using default %s of %i\n", name, - default_val); + netdev_printk(KERN_NOTICE, bdp->device, PROBE, + "Invalid %s specified (%i). " + "Valid values are %i/%i. " + "Using default %s of %i\n", + name, val, false, true, name, default_val); if (default_val) bdp->params.b_params |= mask; } else { - printk(KERN_INFO "e100: Using specified %s of %i\n", name, val); + netdev_info(bdp->device, PROBE, + "Using specified %s of %i\n", name, val); if (val) bdp->params.b_params |= mask; } @@ -1181,8 +1193,7 @@ } if (!e100_exec_non_cu_cmd(bdp, cmd)) { - printk(KERN_WARNING "e100: %s: Multicast setup failed\n", - dev->name); + netdev_warn(dev,, "Multicast setup failed\n"); } } @@ -1262,20 +1273,20 @@ if (!e100_selftest(bdp, &st_timeout, &st_result)) { if (st_timeout) { - printk(KERN_ERR "e100: selftest timeout\n"); + netdev_err(bdp->device,, "selftest timeout\n"); } else { - printk(KERN_ERR "e100: selftest failed. Results: %x\n", - st_result); + netdev_err(bdp->device,, + "selftest failed. Results: %x\n", st_result); } return false; } else - printk(KERN_DEBUG "e100: selftest OK.\n"); + netdev_dbg(bdp->device,, "selftest OK.\n"); /* read the MAC address from the eprom */ e100_rd_eaddr(bdp); if (!is_valid_ether_addr(bdp->device->dev_addr)) { - printk(KERN_ERR "e100: Invalid Ethernet address\n"); + netdev_err(bdp->device,, "Invalid Ethernet address\n"); return false; } /* read NIC's part number */ @@ -1426,7 +1437,7 @@ return true; err: - printk(KERN_ERR "e100: hw init failed\n"); + netdev_err(bdp->device,, "hw init failed\n"); return false; } @@ -1555,8 +1566,7 @@ return 0; err: - printk(KERN_ERR - "e100: Failed to allocate memory\n"); + netdev_err(bdp->device,, "Failed to allocate memory\n"); return -ENOMEM; } @@ -1697,8 +1707,7 @@ #ifdef E100_CU_DEBUG if (e100_cu_unknown_state(bdp)) { - printk(KERN_ERR "e100: %s: CU unknown state in e100_watchdog\n", - dev->name); + netdev_err(dev,, "CU unknown state in e100_watchdog\n"); } #endif if (!netif_running(dev)) { @@ -1708,9 +1717,9 @@ /* check if link state has changed */ if (e100_phy_check(bdp)) { if (netif_carrier_ok(dev)) { - printk(KERN_ERR - "e100: %s NIC Link is Up %d Mbps %s duplex\n", - bdp->device->name, bdp->cur_line_speed, + netdev_err(dev, LINK, + "NIC Link is Up %d Mbps %s duplex\n", + bdp->cur_line_speed, (bdp->cur_dplx_mode == HALF_DUPLEX) ? "Half" : "Full"); @@ -1718,8 +1727,7 @@ e100_config(bdp); } else { - printk(KERN_ERR "e100: %s NIC Link is Down\n", - bdp->device->name); + netdev_err(dev, LINK, "NIC Link is Down\n"); } } @@ -2289,14 +2297,12 @@ case START_WAIT: // The last command was a non_tx CU command if (!e100_wait_cus_idle(bdp)) - printk(KERN_DEBUG - "e100: %s: cu_start: timeout waiting for cu\n", - bdp->device->name); + netdev_dbg(bdp->device,, + "cu_start: timeout waiting for cu\n"); if (!e100_wait_exec_cmplx(bdp, (u32) (tcb->tcb_phys), SCB_CUC_START, CB_TRANSMIT)) { - printk(KERN_DEBUG - "e100: %s: cu_start: timeout waiting for scb\n", - bdp->device->name); + netdev_dbg(bdp->device,, + "cu_start: timeout waiting for scb\n"); e100_exec_cmplx(bdp, (u32) (tcb->tcb_phys), SCB_CUC_START); ret = false; @@ -2414,8 +2420,7 @@ res = e100_exec_non_cu_cmd(bdp, cmd); if (!res) - printk(KERN_WARNING "e100: %s: IA setup failed\n", - bdp->device->name); + netdev_warn(bdp->device,, "IA setup failed\n"); exit: return res; @@ -2460,9 +2465,7 @@ spin_lock(&bdp->bd_lock); if (!e100_wait_exec_cmplx(bdp, rx_struct->dma_addr, SCB_RUC_START, 0)) { - printk(KERN_DEBUG - "e100: %s: start_ru: wait_scb failed\n", - bdp->device->name); + netdev_dbg(bdp->device,, "start_ru: wait_scb failed\n"); e100_exec_cmplx(bdp, rx_struct->dma_addr, SCB_RUC_START); } if (bdp->next_cu_cmd == RESUME_NO_WAIT) { @@ -2707,8 +2710,8 @@ spin_lock_bh(&(bdp->bd_non_tx_lock)); } else { #ifdef E100_CU_DEBUG - printk(KERN_ERR "e100: %s: non-TX command (%x) " - "timeout\n", bdp->device->name, sub_cmd); + netdev_err(bdp->device,, "non-TX command (%x) " + "timeout\n", sub_cmd); #endif rc = false; goto exit; @@ -2961,14 +2964,17 @@ { /* Print the string if checksum Offloading was enabled */ if (bdp->flags & DF_CSUM_OFFLOAD) - printk(KERN_NOTICE " Hardware receive checksums enabled\n"); + netdev_printk(KERN_NOTICE, bdp->device, PROBE, + " Hardware receive checksums enabled\n"); else { if (bdp->rev_id >= D101MA_REV_ID) - printk(KERN_NOTICE " Hardware receive checksums disabled\n"); + netdev_printk(KERN_NOTICE, bdp->device, PROBE, + " Hardware receive checksums disabled\n"); } if ((bdp->flags & DF_UCODE_LOADED)) - printk(KERN_NOTICE " cpu cycle saver enabled\n"); + netdev_printk(KERN_NOTICE, bdp->device, PROBE, + " cpu cycle saver enabled\n"); } /** @@ -3017,8 +3023,8 @@ bdp->scb = (scb_t *) ioremap_nocache(dev->mem_start, sizeof (scb_t)); if (!bdp->scb) { - printk(KERN_ERR "e100: %s: Failed to map PCI address 0x%lX\n", - dev->name, pci_resource_start(pcid, 0)); + netdev_err(dev,, "Failed to map PCI address 0x%lX\n", + pci_resource_start(pcid, 0)); rc = -ENOMEM; goto err_region; } @@ -3092,7 +3098,7 @@ return false; if (!e100_setup_iaaddr(bdp, bdp->device->dev_addr)) { - printk(KERN_ERR "e100: e100_configure_device: " + netdev_err(bdp->device,, "e100_configure_device: " "setup iaaddr failed\n"); return false; } @@ -3122,7 +3128,7 @@ e100_sw_reset(bdp, cmd); if (cmd == PORT_SOFTWARE_RESET) { if (!e100_configure_device(bdp)) - printk(KERN_ERR "e100: e100_deisolate_driver:" + netdev_err(bdp->device,, "e100_deisolate_driver:" " device configuration failed\n"); } @@ -3206,6 +3212,20 @@ case ETHTOOL_PHYS_ID: rc = e100_ethtool_led_blink(dev,ifr); break; + case ETHTOOL_GMSGLVL: { + struct ethtool_value eval = {ETHTOOL_GMSGLVL}; + eval.data = dev->msg_enable; + if (copy_to_user(ifr->ifr_data, &eval, sizeof(eval))) + return -EFAULT; + return 0; + } + case ETHTOOL_SMSGLVL: { + struct ethtool_value eval; + if (copy_from_user(&eval, ifr->ifr_data, sizeof(eval))) + return -EFAULT; + dev->msg_enable = eval.data; + return 0; + } #ifdef ETHTOOL_GRINGPARAM case ETHTOOL_GRINGPARAM: { struct ethtool_ringparam ering; @@ -3843,8 +3863,7 @@ res = e100_exec_non_cu_cmd(bdp, cmd); if (!res) - printk(KERN_WARNING "e100: %s: Filter setup failed\n", - bdp->device->name); + netdev_warn(bdp->device,, "Filter setup failed\n"); exit: return res; @@ -3859,10 +3878,10 @@ if (e100_config(bdp)) { if (bdp->wolopts & (WAKE_UCAST | WAKE_ARP)) if (!e100_setup_filter(bdp)) - printk(KERN_ERR - "e100: WOL options failed\n"); + netdev_err(bdp->device,, + "WOL options failed\n"); } else { - printk(KERN_ERR "e100: config WOL failed\n"); + netdev_err(bdp->device,, "config WOL failed\n"); } } #endif @@ -4159,9 +4178,9 @@ #ifdef E100_CU_DEBUG if (!(non_tx_cmd->cb_status & __constant_cpu_to_le16(CB_STATUS_COMPLETE))) - printk(KERN_ERR "e100: %s: Queued " + netdev_err(bdp->device,, "Queued " "command (%x) timeout\n", - bdp->device->name, sub_cmd); + sub_cmd); #endif list_del(&(active_command->list_elem)); e100_free_non_tx_cmd(bdp, active_command); diff -Naur linux.org/drivers/net/e100/e100_phy.c linux.e100.patched/drivers/net/e100/e100_phy.c --- linux.org/drivers/net/e100/e100_phy.c Mon Aug 25 13:29:38 2003 +++ linux.e100.patched/drivers/net/e100/e100_phy.c Mon Aug 25 13:29:38 2003 @@ -72,7 +72,7 @@ if (mdi_cntrl & MDI_PHY_READY) return 0; else { - printk(KERN_ERR "e100: MDI write timeout\n"); + netdev_err(bdp->device,, "MDI write timeout\n"); return 1; } } @@ -127,7 +127,7 @@ return 0; } else { - printk(KERN_ERR "e100: MDI read timeout\n"); + netdev_err(bdp->device,, "MDI read timeout\n"); return 1; } } @@ -236,22 +236,20 @@ switch (bdp->params.e100_speed_duplex) { case E100_AUTONEG: /* The adapter can't autoneg. so set to 10/HALF */ - printk(KERN_INFO - "e100: 503 serial component detected which " - "cannot autonegotiate\n"); - printk(KERN_INFO - "e100: speed/duplex forced to " + netdev_info(bdp->device, PROBE, + "503 serial component detected which " + "cannot autonegotiate. " + "speed/duplex forced to " "10Mbps / Half duplex\n"); bdp->params.e100_speed_duplex = E100_SPEED_10_HALF; break; case E100_SPEED_100_HALF: case E100_SPEED_100_FULL: - printk(KERN_ERR - "e100: 503 serial component detected " - "which does not support 100Mbps\n"); - printk(KERN_ERR - "e100: Change the forced speed/duplex " + netdev_err(bdp->device,, + "503 serial component detected " + "which does not support 100Mbps. " + "Change the forced speed/duplex " "to a supported setting\n"); return false; } @@ -269,7 +267,7 @@ if ((bdp->params.e100_speed_duplex != E100_AUTONEG) && (bdp->params.e100_speed_duplex != E100_SPEED_100_FULL)) { /* just inform user about 100 full */ - printk(KERN_ERR "e100: NC3133 NIC can only run " + netdev_err(bdp->device,, "NC3133 NIC can only run " "at 100Mbps full duplex\n"); } diff -Naur linux.org/drivers/net/e100/e100_test.c linux.e100.patched/drivers/net/e100/e100_test.c --- linux.org/drivers/net/e100/e100_test.c Mon Aug 25 13:29:38 2003 +++ linux.e100.patched/drivers/net/e100/e100_test.c Mon Aug 25 13:29:38 2003 @@ -44,7 +44,7 @@ static void e100_diag_config_loopback(struct e100_private *, u8, u8, u8 *,u8 *); static u8 e100_diag_loopback_alloc(struct e100_private *); static void e100_diag_loopback_cu_ru_exec(struct e100_private *); -static u8 e100_diag_check_pkt(u8 *); +static u8 e100_diag_check_pkt(struct e100_private *bdp, u8 *); static void e100_diag_loopback_free(struct e100_private *); static int e100_cable_diag(struct e100_private *bdp); @@ -169,19 +169,19 @@ { u8 rc = 0; - printk(KERN_DEBUG "%s: PHY loopback test starts\n", dev->name); + netdev_printk(KERN_DEBUG, dev,, "PHY loopback test starts\n"); e100_hw_init(dev->priv); if (!e100_diag_one_loopback(dev, PHY_LOOPBACK)) { rc |= PHY_LOOPBACK; } - printk(KERN_DEBUG "%s: PHY loopback test ends\n", dev->name); + netdev_printk(KERN_DEBUG, dev,, "PHY loopback test ends\n"); - printk(KERN_DEBUG "%s: MAC loopback test starts\n", dev->name); + netdev_printk(KERN_DEBUG, dev,, "MAC loopback test starts\n"); e100_hw_init(dev->priv); if (!e100_diag_one_loopback(dev, MAC_LOOPBACK)) { rc |= MAC_LOOPBACK; } - printk(KERN_DEBUG "%s: MAC loopback test ends\n", dev->name); + netdev_printk(KERN_DEBUG, dev,, "MAC loopback test ends\n"); return rc; } @@ -349,7 +349,7 @@ { /*load CU & RU base */ if(!e100_wait_exec_cmplx(bdp, bdp->loopback.dma_handle, SCB_RUC_START, 0)) - printk(KERN_ERR "e100: SCB_RUC_START failed!\n"); + netdev_err(bdp->device,, "SCB_RUC_START failed!\n"); bdp->next_cu_cmd = START_WAIT; e100_start_cu(bdp, bdp->loopback.tcb); @@ -359,20 +359,23 @@ /** * e100_diag_check_pkt - checks if a given packet is a loopback packet * @bdp: atapter's private data struct + * @datap: pointer to packet data * * Returns true if OK false otherwise. */ static u8 -e100_diag_check_pkt(u8 *datap) +e100_diag_check_pkt(struct e100_private *bdp, u8 *datap) { int i; for (i = 0; i<512; i++) { if( !((*datap)==0xFF && (*(datap + 512) == 0xBA)) ) { - printk (KERN_ERR "e100: check loopback packet failed at: %x\n", i); + netdev_err(bdp->device,, + "check loopback packet failed at: %x\n", i); return false; } } - printk (KERN_DEBUG "e100: Check received loopback packet OK\n"); + netdev_printk(KERN_DEBUG, bdp->device,, + "Check received loopback packet OK\n"); return true; } @@ -404,11 +407,13 @@ } if (rfd_status & RFD_STATUS_COMPLETE) { - printk(KERN_DEBUG "e100: Loopback packet received\n"); - return e100_diag_check_pkt(((u8 *)rfdp+bdp->rfd_size)); + netdev_printk(KERN_DEBUG, bdp->device,, + "Loopback packet received\n"); + return e100_diag_check_pkt(bdp, + ((u8 *)rfdp+bdp->rfd_size)); } else { - printk(KERN_ERR "e100: Loopback packet not received\n"); + netdev_err(bdp->device,, "Loopback packet not received\n"); return false; } } --------------09E8359C42A09191C013F7B9-- From jkenisto@us.ibm.com Mon Aug 25 14:45:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Aug 2003 14:45:40 -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 h7PLjZoO030325 for ; Mon, 25 Aug 2003 14:45:36 -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 h7PLh4hu222594; Mon, 25 Aug 2003 17:43:04 -0400 Received: from us.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h7PLh2fp263664; Mon, 25 Aug 2003 15:43:03 -0600 Message-ID: <3F4A8274.CC498C22@us.ibm.com> Date: Mon, 25 Aug 2003 14:41:08 -0700 From: Jim Keniston X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: LKML , netdev , Jeff Garzik , "Feldman, Scott" , Larry Kessler , Greg KH , Randy Dunlap , Alan Cox , Andrew Morton , jkenisto Subject: Subject: [PATCH 3/4] Net device error logging, revised (e1000) References: <3F4A8027.6FE3F594@us.ibm.com> Content-Type: multipart/mixed; boundary="------------9E478A7045D2DC2C7D0081CA" X-archive-position: 5274 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkenisto@us.ibm.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------9E478A7045D2DC2C7D0081CA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here's a patch to modify the v2.6.0-test4 e1000 driver to use netdev_* macros and support verbosity control via the NETIF_MSG_* message levels. Jim Keniston IBM Linux Technology Center --------------9E478A7045D2DC2C7D0081CA Content-Type: text/plain; charset=us-ascii; name="e1000-2.6.0-test4.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="e1000-2.6.0-test4.patch" diff -Naur linux.org/drivers/net/e1000/e1000.h linux.e1000.patched/drivers/net/e1000/e1000.h --- linux.org/drivers/net/e1000/e1000.h Mon Aug 25 13:29:38 2003 +++ linux.e1000.patched/drivers/net/e1000/e1000.h Mon Aug 25 13:29:38 2003 @@ -35,6 +35,7 @@ #include #include #include +#include #include #include #include @@ -81,14 +82,6 @@ struct e1000_adapter; #include "e1000_hw.h" - -#if DBG -#define E1000_DBG(args...) printk(KERN_DEBUG "e1000: " args) -#else -#define E1000_DBG(args...) -#endif - -#define E1000_ERR(args...) printk(KERN_ERR "e1000: " args) #define E1000_MAX_INTR 10 diff -Naur linux.org/drivers/net/e1000/e1000_ethtool.c linux.e1000.patched/drivers/net/e1000/e1000_ethtool.c --- linux.org/drivers/net/e1000/e1000_ethtool.c Mon Aug 25 13:29:38 2003 +++ linux.e1000.patched/drivers/net/e1000/e1000_ethtool.c Mon Aug 25 13:29:38 2003 @@ -1576,6 +1576,20 @@ return 0; } #endif + case ETHTOOL_GMSGLVL: { + struct ethtool_value edata = {ETHTOOL_GMSGLVL}; + edata.data = netdev->msg_enable; + if (copy_to_user(addr, &edata, sizeof(edata))) + return -EFAULT; + return 0; + } + case ETHTOOL_SMSGLVL: { + struct ethtool_value edata; + if (copy_from_user(&edata, addr, sizeof(edata))) + return -EFAULT; + netdev->msg_enable = edata.data; + return 0; + } default: return -EOPNOTSUPP; } diff -Naur linux.org/drivers/net/e1000/e1000_main.c linux.e1000.patched/drivers/net/e1000/e1000_main.c --- linux.org/drivers/net/e1000/e1000_main.c Mon Aug 25 13:29:38 2003 +++ linux.e1000.patched/drivers/net/e1000/e1000_main.c Mon Aug 25 13:29:38 2003 @@ -178,9 +178,14 @@ #endif }; +static int debug = -1; +#define E1000_DFLT_MSGLVL (NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_LINK) + MODULE_AUTHOR("Intel Corporation, "); MODULE_DESCRIPTION("Intel(R) PRO/1000 Network Driver"); MODULE_LICENSE("GPL"); +module_param(debug, int, 0); +MODULE_PARM_DESC(debug, "e1000 debug level: 0 (quiet) to 15 (verbose)"); /** * e1000_init_module - Driver Registration Routine @@ -337,7 +342,8 @@ pci_using_dac = 1; } else { if((i = pci_set_dma_mask(pdev, PCI_DMA_32BIT))) { - E1000_ERR("No usable DMA configuration, aborting\n"); + dev_err(&pdev->dev, + "No usable DMA configuration, aborting\n"); return i; } pci_using_dac = 0; @@ -361,6 +367,15 @@ adapter->pdev = pdev; adapter->hw.back = adapter; + if (debug < 0) { + netdev->msg_enable = E1000_DFLT_MSGLVL; + } else if (debug >= 8 * sizeof(int)) { + /* All levels enabled */ + netdev->msg_enable = -1; + } else { + netdev->msg_enable = (1 << debug) - 1; + } + mmio_start = pci_resource_start(pdev, BAR_0); mmio_len = pci_resource_len(pdev, BAR_0); @@ -429,7 +444,7 @@ /* make sure the EEPROM is good */ if(e1000_validate_eeprom_checksum(&adapter->hw) < 0) { - printk(KERN_ERR "The EEPROM Checksum Is Not Valid\n"); + netdev_err(netdev,, "The EEPROM Checksum Is Not Valid\n"); goto err_eeprom; } @@ -467,8 +482,7 @@ netif_carrier_off(netdev); netif_stop_queue(netdev); - printk(KERN_INFO "%s: Intel(R) PRO/1000 Network Connection\n", - netdev->name); + netdev_info(netdev, PROBE, "Intel(R) PRO/1000 Network Connection\n"); e1000_check_options(adapter); /* Initial Wake on LAN setting @@ -569,7 +583,7 @@ /* identify the MAC */ if (e1000_set_mac_type(hw)) { - E1000_ERR("Unknown MAC Type\n"); + netdev_err(netdev,, "Unknown MAC Type\n"); return -1; } @@ -1329,9 +1343,8 @@ &adapter->link_speed, &adapter->link_duplex); - printk(KERN_INFO - "e1000: %s NIC Link is Up %d Mbps %s\n", - netdev->name, adapter->link_speed, + netdev_info(netdev, LINK, "NIC Link is Up %d Mbps %s\n", + adapter->link_speed, adapter->link_duplex == FULL_DUPLEX ? "Full Duplex" : "Half Duplex"); @@ -1344,9 +1357,7 @@ if(netif_carrier_ok(netdev)) { adapter->link_speed = 0; adapter->link_duplex = 0; - printk(KERN_INFO - "e1000: %s NIC Link is Down\n", - netdev->name); + netdev_info(netdev, LINK, "NIC Link is Down\n"); netif_carrier_off(netdev); netif_stop_queue(netdev); mod_timer(&adapter->phy_info_timer, jiffies + 2 * HZ); @@ -1758,7 +1769,7 @@ if((max_frame < MINIMUM_ETHERNET_FRAME_SIZE) || (max_frame > MAX_JUMBO_FRAME_SIZE)) { - E1000_ERR("Invalid MTU setting\n"); + netdev_err(netdev,, "Invalid MTU setting\n"); return -EINVAL; } @@ -1766,7 +1777,7 @@ adapter->rx_buffer_len = E1000_RXBUFFER_2048; } else if(adapter->hw.mac_type < e1000_82543) { - E1000_ERR("Jumbo Frames not supported on 82542\n"); + netdev_err(netdev,, "Jumbo Frames not supported on 82542\n"); return -EINVAL; } else if(max_frame <= E1000_RXBUFFER_4096) { @@ -2147,7 +2158,8 @@ /* All receives must fit into a single buffer */ - E1000_DBG("Receive packet consumed multiple buffers\n"); + netdev_dbg(netdev, RX_ERR, + "Receive packet consumed multiple buffers\n"); dev_kfree_skb_irq(skb); rx_desc->status = 0; diff -Naur linux.org/drivers/net/e1000/e1000_param.c linux.e1000.patched/drivers/net/e1000/e1000_param.c --- linux.org/drivers/net/e1000/e1000_param.c Mon Aug 25 13:29:38 2003 +++ linux.e1000.patched/drivers/net/e1000/e1000_param.c Mon Aug 25 13:29:38 2003 @@ -244,7 +244,8 @@ }; static int __devinit -e1000_validate_option(int *value, struct e1000_option *opt) +e1000_validate_option(int *value, struct e1000_option *opt, + struct net_device *netdev) { if(*value == OPTION_UNSET) { *value = opt->def; @@ -255,16 +256,17 @@ case enable_option: switch (*value) { case OPTION_ENABLED: - printk(KERN_INFO "%s Enabled\n", opt->name); + netdev_info(netdev, PROBE, "%s Enabled\n", opt->name); return 0; case OPTION_DISABLED: - printk(KERN_INFO "%s Disabled\n", opt->name); + netdev_info(netdev, PROBE, "%s Disabled\n", opt->name); return 0; } break; case range_option: if(*value >= opt->arg.r.min && *value <= opt->arg.r.max) { - printk(KERN_INFO "%s set to %i\n", opt->name, *value); + netdev_info(netdev, PROBE, + "%s set to %i\n", opt->name, *value); return 0; } break; @@ -276,7 +278,8 @@ ent = &opt->arg.l.p[i]; if(*value == ent->i) { if(ent->str[0] != '\0') - printk(KERN_INFO "%s\n", ent->str); + netdev_info(netdev, PROBE, "%s\n", + ent->str); return 0; } } @@ -286,8 +289,8 @@ BUG(); } - printk(KERN_INFO "Invalid %s specified (%i) %s\n", - opt->name, *value, opt->err); + netdev_info(netdev,, "Invalid %s specified (%i) %s\n", + opt->name, *value, opt->err); *value = opt->def; return -1; } @@ -308,11 +311,12 @@ void __devinit e1000_check_options(struct e1000_adapter *adapter) { + struct net_device *netdev = adapter->netdev; int bd = adapter->bd_number; if(bd >= E1000_MAX_NIC) { - printk(KERN_NOTICE - "Warning: no configuration for board #%i\n", bd); - printk(KERN_NOTICE "Using defaults for all values\n"); + netdev_warn(netdev, PROBE, + "Warning: no configuration for board #%i. " + "Using defaults for all values\n", bd); bd = E1000_MAX_NIC; } @@ -330,7 +334,7 @@ MAX_TXD : MAX_82544_TXD; tx_ring->count = TxDescriptors[bd]; - e1000_validate_option(&tx_ring->count, &opt); + e1000_validate_option(&tx_ring->count, &opt, netdev); E1000_ROUNDUP(tx_ring->count, REQ_TX_DESCRIPTOR_MULTIPLE); } { /* Receive Descriptor Count */ @@ -346,7 +350,7 @@ opt.arg.r.max = mac_type < e1000_82544 ? MAX_RXD : MAX_82544_RXD; rx_ring->count = RxDescriptors[bd]; - e1000_validate_option(&rx_ring->count, &opt); + e1000_validate_option(&rx_ring->count, &opt, netdev); E1000_ROUNDUP(rx_ring->count, REQ_RX_DESCRIPTOR_MULTIPLE); } { /* Checksum Offload Enable/Disable */ @@ -358,7 +362,7 @@ }; int rx_csum = XsumRX[bd]; - e1000_validate_option(&rx_csum, &opt); + e1000_validate_option(&rx_csum, &opt, netdev); adapter->rx_csum = rx_csum; } { /* Flow Control */ @@ -380,7 +384,7 @@ }; int fc = FlowControl[bd]; - e1000_validate_option(&fc, &opt); + e1000_validate_option(&fc, &opt, netdev); adapter->hw.fc = adapter->hw.original_fc = fc; } { /* Transmit Interrupt Delay */ @@ -394,7 +398,7 @@ }; adapter->tx_int_delay = TxIntDelay[bd]; - e1000_validate_option(&adapter->tx_int_delay, &opt); + e1000_validate_option(&adapter->tx_int_delay, &opt, netdev); } { /* Transmit Absolute Interrupt Delay */ struct e1000_option opt = { @@ -407,7 +411,7 @@ }; adapter->tx_abs_int_delay = TxAbsIntDelay[bd]; - e1000_validate_option(&adapter->tx_abs_int_delay, &opt); + e1000_validate_option(&adapter->tx_abs_int_delay, &opt, netdev); } { /* Receive Interrupt Delay */ struct e1000_option opt = { @@ -420,7 +424,7 @@ }; adapter->rx_int_delay = RxIntDelay[bd]; - e1000_validate_option(&adapter->rx_int_delay, &opt); + e1000_validate_option(&adapter->rx_int_delay, &opt, netdev); } { /* Receive Absolute Interrupt Delay */ struct e1000_option opt = { @@ -433,7 +437,7 @@ }; adapter->rx_abs_int_delay = RxAbsIntDelay[bd]; - e1000_validate_option(&adapter->rx_abs_int_delay, &opt); + e1000_validate_option(&adapter->rx_abs_int_delay, &opt, netdev); } { /* Interrupt Throttling Rate */ struct e1000_option opt = { @@ -447,12 +451,12 @@ adapter->itr = InterruptThrottleRate[bd]; if(adapter->itr == 0) { - printk(KERN_INFO "%s turned off\n", opt.name); + netdev_info(netdev, PROBE, "%s turned off\n", opt.name); } else if(adapter->itr == 1 || adapter->itr == -1) { /* Dynamic mode */ adapter->itr = 1; } else { - e1000_validate_option(&adapter->itr, &opt); + e1000_validate_option(&adapter->itr, &opt, netdev); } } @@ -478,20 +482,24 @@ static void __devinit e1000_check_fiber_options(struct e1000_adapter *adapter) { + struct net_device *netdev = adapter->netdev; int bd = adapter->bd_number; bd = bd > E1000_MAX_NIC ? E1000_MAX_NIC : bd; if((Speed[bd] != OPTION_UNSET)) { - printk(KERN_INFO "Speed not valid for fiber adapters, " - "parameter ignored\n"); + netdev_info(netdev, PROBE, + "Speed not valid for fiber adapters, " + "parameter ignored\n"); } if((Duplex[bd] != OPTION_UNSET)) { - printk(KERN_INFO "Duplex not valid for fiber adapters, " - "parameter ignored\n"); + netdev_info(netdev, PROBE, + "Duplex not valid for fiber adapters, " + "parameter ignored\n"); } if((AutoNeg[bd] != OPTION_UNSET)) { - printk(KERN_INFO "AutoNeg not valid for fiber adapters, " - "parameter ignored\n"); + netdev_info(netdev, PROBE, + "AutoNeg not valid for fiber adapters, " + "parameter ignored\n"); } } @@ -505,6 +513,7 @@ static void __devinit e1000_check_copper_options(struct e1000_adapter *adapter) { + struct net_device *netdev = adapter->netdev; int speed, dplx; int bd = adapter->bd_number; bd = bd > E1000_MAX_NIC ? E1000_MAX_NIC : bd; @@ -525,7 +534,7 @@ }; speed = Speed[bd]; - e1000_validate_option(&speed, &opt); + e1000_validate_option(&speed, &opt, netdev); } { /* Duplex */ struct e1000_opt_list dplx_list[] = {{ 0, "" }, @@ -542,13 +551,13 @@ }; dplx = Duplex[bd]; - e1000_validate_option(&dplx, &opt); + e1000_validate_option(&dplx, &opt, netdev); } if(AutoNeg[bd] != OPTION_UNSET && (speed != 0 || dplx != 0)) { - printk(KERN_INFO - "AutoNeg specified along with Speed or Duplex, " - "parameter ignored\n"); + netdev_info(netdev, PROBE, + "AutoNeg specified along with Speed or Duplex, " + "parameter ignored\n"); adapter->hw.autoneg_advertised = AUTONEG_ADV_DEFAULT; } else { /* Autoneg */ struct e1000_opt_list an_list[] = @@ -595,7 +604,7 @@ }; int an = AutoNeg[bd]; - e1000_validate_option(&an, &opt); + e1000_validate_option(&an, &opt, netdev); adapter->hw.autoneg_advertised = an; } @@ -603,78 +612,82 @@ case 0: adapter->hw.autoneg = 1; if(Speed[bd] != OPTION_UNSET || Duplex[bd] != OPTION_UNSET) - printk(KERN_INFO + netdev_info(netdev, PROBE, "Speed and duplex autonegotiation enabled\n"); break; case HALF_DUPLEX: - printk(KERN_INFO "Half Duplex specified without Speed\n"); - printk(KERN_INFO "Using Autonegotiation at Half Duplex only\n"); + netdev_info(netdev, PROBE, + "Half Duplex specified without Speed. " + "Using Autonegotiation at Half Duplex only\n"); adapter->hw.autoneg = 1; adapter->hw.autoneg_advertised = ADVERTISE_10_HALF | ADVERTISE_100_HALF; break; case FULL_DUPLEX: - printk(KERN_INFO "Full Duplex specified without Speed\n"); - printk(KERN_INFO "Using Autonegotiation at Full Duplex only\n"); + netdev_info(netdev, PROBE, + "Full Duplex specified without Speed. " + "Using Autonegotiation at Full Duplex only\n"); adapter->hw.autoneg = 1; adapter->hw.autoneg_advertised = ADVERTISE_10_FULL | ADVERTISE_100_FULL | ADVERTISE_1000_FULL; break; case SPEED_10: - printk(KERN_INFO "10 Mbps Speed specified without Duplex\n"); - printk(KERN_INFO "Using Autonegotiation at 10 Mbps only\n"); + netdev_info(netdev, PROBE, + "10 Mbps Speed specified without Duplex. " + "Using Autonegotiation at 10 Mbps only\n"); adapter->hw.autoneg = 1; adapter->hw.autoneg_advertised = ADVERTISE_10_HALF | ADVERTISE_10_FULL; break; case SPEED_10 + HALF_DUPLEX: - printk(KERN_INFO "Forcing to 10 Mbps Half Duplex\n"); + netdev_info(netdev, PROBE, "Forcing to 10 Mbps Half Duplex\n"); adapter->hw.autoneg = 0; adapter->hw.forced_speed_duplex = e1000_10_half; adapter->hw.autoneg_advertised = 0; break; case SPEED_10 + FULL_DUPLEX: - printk(KERN_INFO "Forcing to 10 Mbps Full Duplex\n"); + netdev_info(netdev, PROBE, "Forcing to 10 Mbps Full Duplex\n"); adapter->hw.autoneg = 0; adapter->hw.forced_speed_duplex = e1000_10_full; adapter->hw.autoneg_advertised = 0; break; case SPEED_100: - printk(KERN_INFO "100 Mbps Speed specified without Duplex\n"); - printk(KERN_INFO "Using Autonegotiation at 100 Mbps only\n"); + netdev_info(netdev, PROBE, + "100 Mbps Speed specified without Duplex. " + "Using Autonegotiation at 100 Mbps only\n"); adapter->hw.autoneg = 1; adapter->hw.autoneg_advertised = ADVERTISE_100_HALF | ADVERTISE_100_FULL; break; case SPEED_100 + HALF_DUPLEX: - printk(KERN_INFO "Forcing to 100 Mbps Half Duplex\n"); + netdev_info(netdev, PROBE, "Forcing to 100 Mbps Half Duplex\n"); adapter->hw.autoneg = 0; adapter->hw.forced_speed_duplex = e1000_100_half; adapter->hw.autoneg_advertised = 0; break; case SPEED_100 + FULL_DUPLEX: - printk(KERN_INFO "Forcing to 100 Mbps Full Duplex\n"); + netdev_info(netdev, PROBE, "Forcing to 100 Mbps Full Duplex\n"); adapter->hw.autoneg = 0; adapter->hw.forced_speed_duplex = e1000_100_full; adapter->hw.autoneg_advertised = 0; break; case SPEED_1000: - printk(KERN_INFO "1000 Mbps Speed specified without Duplex\n"); - printk(KERN_INFO - "Using Autonegotiation at 1000 Mbps Full Duplex only\n"); + netdev_info(netdev, PROBE, + "1000 Mbps Speed specified without Duplex. " + "Using Autonegotiation at 1000 Mbps Full Duplex only\n"); adapter->hw.autoneg = 1; adapter->hw.autoneg_advertised = ADVERTISE_1000_FULL; break; case SPEED_1000 + HALF_DUPLEX: - printk(KERN_INFO "Half Duplex is not supported at 1000 Mbps\n"); - printk(KERN_INFO - "Using Autonegotiation at 1000 Mbps Full Duplex only\n"); + netdev_info(netdev, PROBE, + "Half Duplex is not supported at 1000 Mbps. " + "Using Autonegotiation at 1000 Mbps Full Duplex only\n"); adapter->hw.autoneg = 1; adapter->hw.autoneg_advertised = ADVERTISE_1000_FULL; break; case SPEED_1000 + FULL_DUPLEX: - printk(KERN_INFO + netdev_info(netdev, PROBE, "Using Autonegotiation at 1000 Mbps Full Duplex only\n"); adapter->hw.autoneg = 1; adapter->hw.autoneg_advertised = ADVERTISE_1000_FULL; @@ -685,8 +698,9 @@ /* Speed, AutoNeg and MDI/MDI-X must all play nice */ if (e1000_validate_mdi_setting(&(adapter->hw)) < 0) { - printk(KERN_INFO "Speed, AutoNeg and MDI-X specifications are " - "incompatible. Setting MDI-X to a compatible value.\n"); + netdev_info(netdev, PROBE, + "Speed, AutoNeg and MDI-X specifications are " + "incompatible. Setting MDI-X to a compatible value.\n"); } } --------------9E478A7045D2DC2C7D0081CA-- From jkenisto@us.ibm.com Mon Aug 25 14:45:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Aug 2003 14:45:38 -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 h7PLjYoO030324 for ; Mon, 25 Aug 2003 14:45:34 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h7PLiwRZ509204; Mon, 25 Aug 2003 17:44:58 -0400 Received: from us.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h7PLitfp296180; Mon, 25 Aug 2003 15:44:56 -0600 Message-ID: <3F4A82E5.215E29AA@us.ibm.com> Date: Mon, 25 Aug 2003 14:43:01 -0700 From: Jim Keniston X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: LKML , netdev , Jeff Garzik , "Feldman, Scott" , Larry Kessler , Greg KH , Randy Dunlap , Alan Cox , Andrew Morton , jkenisto Subject: [PATCH 4/4] Net device error logging, revised (tg3) References: <3F4A8027.6FE3F594@us.ibm.com> Content-Type: multipart/mixed; boundary="------------BFB5D3C9AFDADD903AFF3D3E" X-archive-position: 5273 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkenisto@us.ibm.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------BFB5D3C9AFDADD903AFF3D3E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here's a patch to modify the v2.6.0-test4 tg3 driver to use netdev_* macros. Jim Keniston IBM Linux Technology Center --------------BFB5D3C9AFDADD903AFF3D3E Content-Type: text/plain; charset=us-ascii; name="tg3-2.6.0-test4.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tg3-2.6.0-test4.patch" diff -Naur linux.org/drivers/net/tg3.c linux.tg3.patched/drivers/net/tg3.c --- linux.org/drivers/net/tg3.c Mon Aug 25 13:29:39 2003 +++ linux.tg3.patched/drivers/net/tg3.c Mon Aug 25 13:29:39 2003 @@ -489,9 +489,8 @@ break; default: - printk(KERN_WARNING PFX "%s: Invalid power state (%d) " - "requested.\n", - tp->dev->name, state); + netdev_warn(tp->dev,, "Invalid power state (%d) " + "requested.\n", state); return -EINVAL; }; @@ -639,10 +638,10 @@ static void tg3_link_report(struct tg3 *tp) { if (!netif_carrier_ok(tp->dev)) { - printk(KERN_INFO PFX "%s: Link is down.\n", tp->dev->name); + netdev_info(tp->dev, LINK, "Link is down.\n"); } else { - printk(KERN_INFO PFX "%s: Link is up at %d Mbps, %s duplex.\n", - tp->dev->name, + netdev_info(tp->dev, LINK, + "Link is up at %d Mbps, %s duplex.\n", (tp->link_config.active_speed == SPEED_1000 ? 1000 : (tp->link_config.active_speed == SPEED_100 ? @@ -650,9 +649,8 @@ (tp->link_config.active_duplex == DUPLEX_FULL ? "full" : "half")); - printk(KERN_INFO PFX "%s: Flow control is %s for TX and " + netdev_info(tp->dev, LINK, "Flow control is %s for TX and " "%s for RX.\n", - tp->dev->name, (tp->tg3_flags & TG3_FLAG_TX_PAUSE) ? "on" : "off", (tp->tg3_flags & TG3_FLAG_RX_PAUSE) ? "on" : "off"); } @@ -2231,8 +2229,7 @@ { struct tg3 *tp = dev->priv; - printk(KERN_ERR PFX "%s: transmit timed out, resetting\n", - dev->name); + netdev_err(dev, TX_ERR, "transmit timed out, resetting\n"); schedule_work(&tp->reset_task); } @@ -2379,8 +2376,7 @@ if (unlikely(TX_BUFFS_AVAIL(tp) <= (skb_shinfo(skb)->nr_frags + 1))) { netif_stop_queue(dev); spin_unlock_irqrestore(&tp->tx_lock, flags); - printk(KERN_ERR PFX "%s: BUG! Tx Ring full when queue awake!\n", - dev->name); + netdev_err(dev, TX_ERR, "BUG! Tx Ring full when queue awake!\n"); return 1; } @@ -2397,7 +2393,8 @@ TXD_FLAG_CPU_POST_DMA); if (times++ < 5) { - printk("tg3_xmit: tso_size[%u] tso_segs[%u] len[%u]\n", + netdev_info(dev,, + "tg3_xmit: tso_size[%u] tso_segs[%u] len[%u]\n", (unsigned int) skb_shinfo(skb)->tso_size, (unsigned int) skb_shinfo(skb)->tso_segs, skb->len); @@ -2571,8 +2568,7 @@ if (unlikely(TX_BUFFS_AVAIL(tp) <= (skb_shinfo(skb)->nr_frags + 1))) { netif_stop_queue(dev); spin_unlock_irqrestore(&tp->tx_lock, flags); - printk(KERN_ERR PFX "%s: BUG! Tx Ring full when queue awake!\n", - dev->name); + netdev_err(dev, TX_ERR, "BUG! Tx Ring full when queue awake!\n"); return 1; } @@ -2593,7 +2589,8 @@ TXD_FLAG_CPU_POST_DMA); if (times++ < 5) { - printk("tg3_xmit: tso_size[%u] tso_segs[%u] len[%u]\n", + netdev_info(dev,, + "tg3_xmit: tso_size[%u] tso_segs[%u] len[%u]\n", (unsigned int) skb_shinfo(skb)->tso_size, (unsigned int) skb_shinfo(skb)->tso_segs, skb->len); @@ -3017,7 +3014,7 @@ } if (i == MAX_WAIT_CNT) { - printk(KERN_ERR PFX "tg3_stop_block timed out, " + netdev_err(tp->dev,, "tg3_stop_block timed out, " "ofs=%lx enable_bit=%x\n", ofs, enable_bit); return -ENODEV; @@ -3070,9 +3067,9 @@ break; } if (i >= MAX_WAIT_CNT) { - printk(KERN_ERR PFX "tg3_abort_hw timed out for %s, " + netdev_err(tp->dev,, "tg3_abort_hw timed out; " "TX_MODE_ENABLE will not clear MAC_TX_MODE=%08x\n", - tp->dev->name, tr32(MAC_TX_MODE)); + tr32(MAC_TX_MODE)); return -ENODEV; } @@ -3208,9 +3205,8 @@ if (i >= 100000 && !(tp->tg3_flags2 & TG3_FLG2_SUN_5704)) { - printk(KERN_ERR PFX "tg3_halt timed out for %s, " - "firmware will not restart magic=%08x\n", - tp->dev->name, val); + netdev_err(tp->dev,, "tg3_halt timed out, " + "firmware will not restart magic=%08x\n", val); return -ENODEV; } @@ -3384,9 +3380,7 @@ } if (i >= 10000) { - printk(KERN_ERR PFX "tg3_reset_cpu timed out for %s, " - "and %s CPU\n", - tp->dev->name, + netdev_err(tp->dev,, "tg3_reset_cpu timed out for %s CPU\n", (offset == RX_CPU_BASE ? "RX" : "TX")); return -ENODEV; } @@ -3498,9 +3492,9 @@ udelay(1000); } if (i >= 5) { - printk(KERN_ERR PFX "tg3_load_firmware fails for %s " + netdev_err(tp->dev,, "tg3_load_firmware fails " "to set RX CPU PC, is %08x should be %08x\n", - tp->dev->name, tr32(RX_CPU_BASE + CPU_PC), + tr32(RX_CPU_BASE + CPU_PC), TG3_FW_TEXT_ADDR); return -ENODEV; } @@ -3826,9 +3820,9 @@ udelay(1000); } if (i >= 5) { - printk(KERN_ERR PFX "tg3_load_tso_firmware fails for %s " + netdev_err(tp->dev,, "tg3_load_tso_firmware fails " "to set TX CPU PC, is %08x should be %08x\n", - tp->dev->name, tr32(TX_CPU_BASE + CPU_PC), + tr32(TX_CPU_BASE + CPU_PC), TG3_TSO_FW_TEXT_ADDR); return -ENODEV; } @@ -3953,9 +3947,8 @@ } if (i >= 100000 && !(tp->tg3_flags2 & TG3_FLG2_SUN_5704)) { - printk(KERN_ERR PFX "tg3_reset_hw timed out for %s, " - "firmware will not restart magic=%08x\n", - tp->dev->name, val); + netdev_err(tp->dev,, "tg3_reset_hw timed out, " + "firmware will not restart magic=%08x\n", val); return -ENODEV; } @@ -4060,8 +4053,7 @@ udelay(10); } if (i >= 2000) { - printk(KERN_ERR PFX "tg3_reset_hw cannot enable BUFMGR for %s.\n", - tp->dev->name); + netdev_err(tp->dev,, "tg3_reset_hw cannot enable BUFMGR.\n"); return -ENODEV; } @@ -4073,8 +4065,7 @@ udelay(10); } if (i >= 2000) { - printk(KERN_ERR PFX "tg3_reset_hw cannot reset FTQ for %s.\n", - tp->dev->name); + netdev_err(tp->dev,, "tg3_reset_hw cannot reset FTQ.\n"); return -ENODEV; } @@ -5222,14 +5213,12 @@ static u32 tg3_get_msglevel(struct net_device *dev) { - struct tg3 *tp = dev->priv; - return tp->msg_enable; + return dev->msg_enable; } static void tg3_set_msglevel(struct net_device *dev, u32 value) { - struct tg3 *tp = dev->priv; - tp->msg_enable = value; + dev->msg_enable = value; } static int tg3_nway_reset(struct net_device *dev) @@ -5550,7 +5539,7 @@ int i, saw_done_clear; if (tp->tg3_flags2 & TG3_FLG2_SUN_5704) { - printk(KERN_ERR PFX "Attempt to do nvram_read on Sun 5704\n"); + netdev_err(tp->dev,, "Attempt to do nvram_read on Sun 5704\n"); return -EINVAL; } @@ -6049,7 +6038,7 @@ /* Force the chip into D0. */ err = tg3_set_power_state(tp, 0); if (err) { - printk(KERN_ERR PFX "(%s) transition to D0 failed\n", + netdev_err(tp->dev,, "(%s) transition to D0 failed\n", pci_name(tp->pdev)); return err; } @@ -6160,7 +6149,8 @@ err = tg3_phy_probe(tp); if (err) { - printk(KERN_ERR PFX "(%s) phy probe failed, err %d\n", + netdev_err(tp->dev,, + "(%s) phy probe failed, err %d\n", pci_name(tp->pdev), err); /* ... but do not return immediately ... */ } @@ -6643,20 +6633,21 @@ unsigned long tg3reg_base, tg3reg_len; struct net_device *dev; struct tg3 *tp; - int i, err, pci_using_dac, pm_cap; + int err, pci_using_dac, pm_cap; + unsigned char *mac; if (tg3_version_printed++ == 0) printk(KERN_INFO "%s", version); err = pci_enable_device(pdev); if (err) { - printk(KERN_ERR PFX "Cannot enable PCI device, " + dev_err(&pdev->dev, "Cannot enable PCI device, " "aborting.\n"); return err; } if (!(pci_resource_flags(pdev, 0) & IORESOURCE_MEM)) { - printk(KERN_ERR PFX "Cannot find proper PCI device " + dev_err(&pdev->dev, "Cannot find proper PCI device " "base address, aborting.\n"); err = -ENODEV; goto err_out_disable_pdev; @@ -6664,7 +6655,7 @@ err = pci_request_regions(pdev, DRV_MODULE_NAME); if (err) { - printk(KERN_ERR PFX "Cannot obtain PCI resources, " + dev_err(&pdev->dev, "Cannot obtain PCI resources, " "aborting.\n"); goto err_out_disable_pdev; } @@ -6674,7 +6665,7 @@ /* Find power-management capability. */ pm_cap = pci_find_capability(pdev, PCI_CAP_ID_PM); if (pm_cap == 0) { - printk(KERN_ERR PFX "Cannot find PowerManagement capability, " + dev_err(&pdev->dev, "Cannot find PowerManagement capability, " "aborting.\n"); goto err_out_free_res; } @@ -6683,14 +6674,14 @@ if (!pci_set_dma_mask(pdev, 0xffffffffffffffffULL)) { pci_using_dac = 1; if (pci_set_consistent_dma_mask(pdev, 0xffffffffffffffffULL)) { - printk(KERN_ERR PFX "Unable to obtain 64 bit DMA " + dev_err(&pdev->dev, "Unable to obtain 64 bit DMA " "for consistent allocations\n"); goto err_out_free_res; } } else { err = pci_set_dma_mask(pdev, (u64) 0xffffffff); if (err) { - printk(KERN_ERR PFX "No usable DMA configuration, " + dev_err(&pdev->dev, "No usable DMA configuration, " "aborting.\n"); goto err_out_free_res; } @@ -6702,7 +6693,7 @@ dev = alloc_etherdev(sizeof(*tp)); if (!dev) { - printk(KERN_ERR PFX "Etherdev alloc failed, aborting.\n"); + dev_err(&pdev->dev, "Etherdev alloc failed, aborting.\n"); err = -ENOMEM; goto err_out_free_res; } @@ -6727,9 +6718,9 @@ tp->tx_mode = TG3_DEF_TX_MODE; tp->mi_mode = MAC_MI_MODE_BASE; if (tg3_debug > 0) - tp->msg_enable = tg3_debug; + dev->msg_enable = tg3_debug; else - tp->msg_enable = TG3_DEF_MSG_ENABLE; + dev->msg_enable = TG3_DEF_MSG_ENABLE; /* The word/byte swap controls here control register access byte * swapping. DMA data byte swapping is controlled in the GRC_MODE @@ -6759,7 +6750,7 @@ tp->regs = (unsigned long) ioremap(tg3reg_base, tg3reg_len); if (tp->regs == 0UL) { - printk(KERN_ERR PFX "Cannot map device registers, " + netdev_err(dev,, "Cannot map device registers, " "aborting.\n"); err = -ENOMEM; goto err_out_free_dev; @@ -6789,21 +6780,21 @@ err = tg3_get_invariants(tp); if (err) { - printk(KERN_ERR PFX "Problem fetching invariants of chip, " + netdev_err(dev,, "Problem fetching invariants of chip, " "aborting.\n"); goto err_out_iounmap; } err = tg3_get_device_address(tp); if (err) { - printk(KERN_ERR PFX "Could not obtain valid ethernet address, " + netdev_err(dev,, "Could not obtain valid ethernet address, " "aborting.\n"); goto err_out_iounmap; } err = tg3_test_dma(tp); if (err) { - printk(KERN_ERR PFX "DMA engine test failed, aborting.\n"); + netdev_err(dev,, "DMA engine test failed, aborting.\n"); goto err_out_iounmap; } @@ -6829,7 +6820,7 @@ err = register_netdev(dev); if (err) { - printk(KERN_ERR PFX "Cannot register net device, " + netdev_err(dev,, "Cannot register net device, " "aborting.\n"); goto err_out_iounmap; } @@ -6842,8 +6833,9 @@ */ pci_save_state(tp->pdev, tp->pci_cfg_state); - printk(KERN_INFO "%s: Tigon3 [partno(%s) rev %04x PHY(%s)] (PCI%s:%s:%s) %sBaseT Ethernet ", - dev->name, + mac = dev->dev_addr; + netdev_info(dev, PROBE, "Tigon3 [partno(%s) rev %04x PHY(%s)] (PCI%s:%s:%s) %sBaseT Ethernet " + "%02x:%02x:%02x:%02x:%02x:%02x\n", tp->board_part_number, tp->pci_chip_rev_id, tg3_phy_string(tp), @@ -6852,11 +6844,8 @@ ((tp->tg3_flags & TG3_FLAG_PCIX_MODE) ? "133MHz" : "66MHz") : ((tp->tg3_flags & TG3_FLAG_PCIX_MODE) ? "100MHz" : "33MHz")), ((tp->tg3_flags & TG3_FLAG_PCI_32BIT) ? "32-bit" : "64-bit"), - (tp->tg3_flags & TG3_FLAG_10_100_ONLY) ? "10/100" : "10/100/1000"); - - for (i = 0; i < 6; i++) - printk("%2.2x%c", dev->dev_addr[i], - i == 5 ? '\n' : ':'); + (tp->tg3_flags & TG3_FLAG_10_100_ONLY) ? "10/100" : "10/100/1000", + mac[0], mac[1], mac[2], mac[3], mac[4], mac[5]); return 0; --------------BFB5D3C9AFDADD903AFF3D3E-- From garzik@gtf.org Mon Aug 25 16:08:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Aug 2003 16:08:23 -0700 (PDT) Received: from havoc.gtf.org (havoc.gtf.org [63.247.75.124]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7PN8FoO002743 for ; Mon, 25 Aug 2003 16:08:16 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id B94EB6647; Mon, 25 Aug 2003 19:08:09 -0400 (EDT) Date: Mon, 25 Aug 2003 19:08:09 -0400 From: Jeff Garzik To: marcelo@conectiva.com.br Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [bk patches] net driver updates Message-ID: <20030825230809.GA11073@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: 5275 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 Marcelo, please do a bk pull bk://kernel.bkbits.net/jgarzik/net-drivers-2.4 I have sent the patch separately for your review. Others may download the patch from: ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.4/2.4.22-netdrvr1.patch.bz2 This will update the following files: drivers/net/8139cp.c | 4 drivers/net/8139too.c | 10 drivers/net/bonding/bond_main.c | 17 - drivers/net/bonding/bonding.h | 2 drivers/net/net_init.c | 3 drivers/net/tulip/tulip_core.c | 1 drivers/net/wireless/airo.c | 568 ++++++++++++++++++++++------------------ include/linux/netdevice.h | 2 8 files changed, 342 insertions(+), 265 deletions(-) through these ChangeSets: (03/08/18 1.1064.1.13) [netdrvr 8139too] fix resume behavior, by correctly saving/restoring pci state. (03/08/18 1.1064.1.12) [netdrvr 8139cp] fix h/w vlan offload It wants big endian vlan tags. IEEE, or just weird? (03/08/18 1.1064.1.11) [wireless airo] Replaces task queues by simpler kernel_thread (03/08/18 1.1064.1.10) [wireless airo] Fixes unregistering of PCI cards (03/08/17 1.1064.1.9) [netdrvr tulip] add pci id for 3com 3CSOHO100B-TX (03/08/07 1.1064.1.8) [netdrvr bonding] embed stats struct inside bonding private struct Simplification: Don't allocate the stats struct via kmalloc, embed it inside it's parent bonding_t. (03/08/07 1.1064.1.7) [net] export alloc_netdev (03/08/07 1.1064.1.6) [PATCH] Fix adhoc config (03/08/07 1.1064.1.5) [PATCH] Safer unload code (03/08/07 1.1064.1.4) [PATCH] MIC support with newer firmware (03/08/07 1.1064.1.3) [PATCH] Missing lines for Wireless Extensions 16 (03/08/07 1.1064.1.2) [netdrvr airo] MAC type changed to unsigned (03/08/07 1.1064.1.1) [netdrvr airo] Missing defines (only for documentation) From ralph@istop.com Mon Aug 25 20:41:58 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Aug 2003 20:42:31 -0700 (PDT) Received: from smtp.istop.com (dci.doncaster.on.ca [66.11.168.194]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7Q3fGoO028157 for ; Mon, 25 Aug 2003 20:41:57 -0700 Received: from ns.istop.com (ns.istop.com [66.11.168.199]) by smtp.istop.com (Postfix) with ESMTP id F1E20369A6 for ; Mon, 25 Aug 2003 23:41:11 -0400 (EDT) Date: Mon, 25 Aug 2003 23:41:11 -0400 (EDT) From: Ralph Doncaster Reply-To: ralph+d@istop.com To: netdev@oss.sgi.com Subject: route-cache performance Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5276 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ralph@istop.com Precedence: bulk X-list: netdev So far things look really good with 2.4.22-rc2 with a 1G Celery and e1000. This is just send-only with full (123K) routes and then a small routing table. Tomorrow I'll test forwarding (in one e1000, out the other). Here's with a full table: 34 e1000_irq_enable 0.7083 67 kmalloc 0.8375 147 memcpy_fromiovecend 0.9187 115 kfree_skbmem 1.0268 103 pfifo_fast_dequeue 1.2875 511 raw_getrawfrag 2.2812 272 __generic_copy_from_user 2.4286 322 handle_IRQ_event 2.8750 203 kfree 3.1719 198 system_call 3.5357 And with < 10 routes: 29 kmalloc 0.3625 45 kfree_skbmem 0.4018 66 memcpy_fromiovecend 0.4125 23 e1000_irq_enable 0.4792 53 pfifo_fast_dequeue 0.6625 256 raw_getrawfrag 1.1429 149 __generic_copy_from_user 1.3304 170 handle_IRQ_event 1.5179 113 kfree 1.7656 115 system_call 2.0536 Juno was able to send ~330kpps, which is pretty decent. From the profiles it looks like every packet sent by juno leads to a kmalloc/kfree. If that interpretation is correct then a fixed skb pool should lead to a significant performance improvement. Ralph Doncaster, IStop.com president 6042147 Canada Inc. From yoshfuji@linux-ipv6.org Mon Aug 25 23:03:48 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Aug 2003 23:04:20 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7Q636oO001713 for ; Mon, 25 Aug 2003 23:03:47 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h7Q63X1M009608; Tue, 26 Aug 2003 15:03:33 +0900 Date: Tue, 26 Aug 2003 15:03:31 +0900 (JST) Message-Id: <20030826.150331.102449369.yoshfuji@linux-ipv6.org> To: sebek64@post.cz Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [OOPS] less /proc/net/igmp From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20030825163206.GA1340@penguin.penguin> References: <20030825163206.GA1340@penguin.penguin> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 5277 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Hello. In article <20030825163206.GA1340@penguin.penguin> (at Mon, 25 Aug 2003 18:32:06 +0200), Marcel Sebek says: > This Oops appears on 2.5.74+ kernels (including 2.6.0-test4) when > I'm trying to read /proc/net/igmp with 'less', 'cat' displays > the file content without oops: : > [snip] > ... > bash# mount /proc > bash# cat /proc/net/igmp > Idx Device : Count Querier Group Users Timer Reporter > bash# less /proc/net/igmp > Idx Device : Count Querier Group Users Timer Reporter > bash# ifup -a > bash# cat /proc/net/igmp > Idx Device : Count Querier Group Users Timer Reporter > 1 lo : 0 V2 > 010000E0 1 0:FFFA22F0 0 > bash# less /proc/net/igmp > Unable to handle kernel paging request at virtual address 08051be0 > printing eip: > 08051be0 > *pde = 0fb66067 > *pfe = 00000000 > Oops: 0004 [#1] > CPU: 0 > EIP: 0073:[<08051be0>] Not tainted > EFLAGS: 00010246 > EIP is at 0x8051be0 > eax: 0805fb68 ebx: 00000001 ecx: 00000000 edx: 00000019 > esi: 08060649 edi: 08057543 ebp: bffffd8c esp: bfffda50 > ds: 007b es: 007b ss: 007b > Process less (pid 20, threadinfo = cfab6000 task = c13560cd) > <0>Kernel panic: Fatal exception in interrupt > In interrupt handler - not syncing I could not reproduce this issue. anyone? -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From yoshfuji@wide.ad.jp Mon Aug 25 23:32:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Aug 2003 23:32:55 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7Q6VeoO005275 for ; Mon, 25 Aug 2003 23:32:21 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h7Q6W91M009793 for ; Tue, 26 Aug 2003 15:32:09 +0900 Resent-Date: Tue, 26 Aug 2003 15:32:07 +0900 (JST) Resent-Message-Id: <20030826.153207.87647235.yoshfuji@wide.ad.jp> Resent-To: netdev@oss.sgi.com Resent-From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Subject: Re: [OOPS] less /proc/net/igmp From: Owen Ford To: linux-kernel@vger.kernel.org In-Reply-To: <20030826.150331.102449369.yoshfuji@linux-ipv6.org> References: <20030825163206.GA1340@penguin.penguin> <20030826.150331.102449369.yoshfuji@linux-ipv6.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ybMvwcf5ocIVo1p3LmD1" Message-Id: <1061878985.3463.2.camel@spider.hotmonkeyporn.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 26 Aug 2003 01:23:06 -0500 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org X-archive-position: 5278 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@wide.ad.jp Precedence: bulk X-list: netdev --=-ybMvwcf5ocIVo1p3LmD1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 2003-08-26 at 01:03, YOSHIFUJI Hideaki / =E5=90=89=E8=97=A4=E8=8B= =B1=E6=98=8E wrote: > Hello. >=20 > In article <20030825163206.GA1340@penguin.penguin> (at Mon, 25 Aug 2003 1= 8:32:06 +0200), Marcel Sebek says: >=20 > > This Oops appears on 2.5.74+ kernels (including 2.6.0-test4) when > > I'm trying to read /proc/net/igmp with 'less', 'cat' displays > > the file content without oops: > : > > [snip] > > ... > > bash# mount /proc > > bash# cat /proc/net/igmp > > Idx Device : Count Querier Group Users Timer Reporter > > bash# less /proc/net/igmp > > Idx Device : Count Querier Group Users Timer Reporter > > bash# ifup -a > > bash# cat /proc/net/igmp > > Idx Device : Count Querier Group Users Timer Reporter > > 1 lo : 0 V2 > > 010000E0 1 0:FFFA22F0 0 > > bash# less /proc/net/igmp > > Unable to handle kernel paging request at virtual address 08051be0 > > printing eip: > > 08051be0 > > *pde =3D 0fb66067 > > *pfe =3D 00000000 > > Oops: 0004 [#1] > > CPU: 0 > > EIP: 0073:[<08051be0>] Not tainted > > EFLAGS: 00010246 > > EIP is at 0x8051be0 > > eax: 0805fb68 ebx: 00000001 ecx: 00000000 edx: 00000019 > > esi: 08060649 edi: 08057543 ebp: bffffd8c esp: bfffda50 > > ds: 007b es: 007b ss: 007b > > Process less (pid 20, threadinfo =3D cfab6000 task =3D c13560cd) > > <0>Kernel panic: Fatal exception in interrupt > > In interrupt handler - not syncing >=20 > I could not reproduce this issue. anyone? I can confirm. I have it with 2.6.0-test4. Let me know what useful info I can provide. The oops is the same. --=20 Owen Ford --=-ybMvwcf5ocIVo1p3LmD1 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/SvzJ4bjUYpnk5/QRAi2GAJ9EGzA7p+6L6nNm5zqwj5FzxsAbbgCgrE8F rLZRH4wydMudYix9lCA4bQg= =MN0v -----END PGP SIGNATURE----- --=-ybMvwcf5ocIVo1p3LmD1-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From yoshfuji@wide.ad.jp Mon Aug 25 23:58:12 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 25 Aug 2003 23:58:45 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7Q6vUoO006551 for ; Mon, 25 Aug 2003 23:58:11 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h7Q6vx1M009923 for ; Tue, 26 Aug 2003 15:57:59 +0900 Resent-Date: Tue, 26 Aug 2003 15:57:59 +0900 (JST) Resent-Message-Id: <20030826.155759.59651991.yoshfuji@wide.ad.jp> Resent-To: netdev@oss.sgi.com Resent-From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Message-ID: <3F4B011B.6080300@lanil.mine.nu> Date: Tue, 26 Aug 2003 08:41:31 +0200 From: Christian Axelsson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030823 Thunderbird/0.2a X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcel Sebek CC: linux-kernel@vger.kernel.org Subject: Re: [OOPS] less /proc/net/igmp References: <20030825163206.GA1340@penguin.penguin> In-Reply-To: <20030825163206.GA1340@penguin.penguin> X-Enigmail-Version: 0.81.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org X-archive-position: 5279 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@wide.ad.jp Precedence: bulk X-list: netdev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I can verify this on 2.6.0-test4-mm1 and 2.6.0-test3-mm4 - -- Christan Axelsson smiler@lanil.mine.nu -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/SwEbyqbmAWw8VdkRAg6SAJ98RVCbWmsVTH/vtg0McK7vSshn4QCffiI9 q7B10AWRBqYC64JD0UHG6LQ= =lpLs -----END PGP SIGNATURE----- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From pp@ee.oulu.fi Tue Aug 26 00:01:39 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Aug 2003 00:02:13 -0700 (PDT) Received: from ee.oulu.fi (ee.oulu.fi [130.231.61.23]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7Q70voO007085 for ; Tue, 26 Aug 2003 00:01:38 -0700 Received: from tk28.oulu.fi (tk28 [130.231.48.68]) by ee.oulu.fi (8.12.9/8.12.9) with ESMTP id h7Q70tkM015607; Tue, 26 Aug 2003 10:00:55 +0300 (EEST) Received: (from pp@localhost) by tk28.oulu.fi (8.12.9/8.12.9/Submit) id h7Q70t0n021053; Tue, 26 Aug 2003 10:00:55 +0300 (EEST) Date: Tue, 26 Aug 2003 10:00:55 +0300 From: Pekka Pietikainen To: David Antliff Cc: davem@redhat.com, netdev@oss.sgi.com Subject: Re: b44 driver in Linux 2.4.22 Message-ID: <20030826070055.GA19639@ee.oulu.fi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-archive-position: 5280 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pp@ee.oulu.fi Precedence: bulk X-list: netdev On Tue, Aug 26, 2003 at 09:38:45AM +1200, David Antliff wrote: > > Hi, > > Does the b44 driver you wrote in Linux 2.4.22 support magic > packet Wake-On-Lan? Hi Not in the current version. Doesn't look that difficult to add though, so I might at some point have a go at implementing it. Just need to figure out how to test it, I assume there's ACPI hell involved :/ > Also, just out of curiosity, is this driver based on Michael Chan's > Broadcom bcm4400 driver? Dave would know best since he wrote the beast, but I believe it's written using bcm4400 as "documentation" and really based on the generic Linux ethernet driver template (so tg3.c with tg3 bits changed into b44 bits :-) ) From yoshfuji@wide.ad.jp Tue Aug 26 00:24:52 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Aug 2003 00:25:00 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7Q7OooO008782 for ; Tue, 26 Aug 2003 00:24:52 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h7Q7PJ1M010114 for ; Tue, 26 Aug 2003 16:25:19 +0900 Resent-Date: Tue, 26 Aug 2003 16:25:19 +0900 (JST) Resent-Message-Id: <20030826.162519.52156166.yoshfuji@wide.ad.jp> Resent-To: netdev@oss.sgi.com Resent-From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Subject: Re: [OOPS] less /proc/net/igmp From: Owen Ford To: lkml In-Reply-To: <3F4B011B.6080300@lanil.mine.nu> References: <20030825163206.GA1340@penguin.penguin> <3F4B011B.6080300@lanil.mine.nu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-hWTPbeYLmD95xVeTRAM/" Message-Id: <1061881803.3507.1.camel@spider.hotmonkeyporn.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 26 Aug 2003 02:10:04 -0500 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org X-archive-position: 5281 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@wide.ad.jp Precedence: bulk X-list: netdev --=-hWTPbeYLmD95xVeTRAM/ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2003-08-26 at 01:41, Christian Axelsson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > I can verify this on 2.6.0-test4-mm1 and 2.6.0-test3-mm4 >=20 > - -- > Christan Axelsson > smiler@lanil.mine.nu > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.2 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org >=20 > iD8DBQE/SwEbyqbmAWw8VdkRAg6SAJ98RVCbWmsVTH/vtg0McK7vSshn4QCffiI9 > q7B10AWRBqYC64JD0UHG6LQ=3D > =3DlpLs > -----END PGP SIGNATURE----- >=20 >=20 > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" i= n > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ It goes back even farther. I have it with all of the 2.6 series. --=20 Owen Ford --=-hWTPbeYLmD95xVeTRAM/ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/SwfL4bjUYpnk5/QRAkUBAJ97wvoVwBUBpd9qFAXsiSVvto3LeACgyYZn Mf04erAx1IHCotOpY8aIadM= =8m1D -----END PGP SIGNATURE----- --=-hWTPbeYLmD95xVeTRAM/-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From akpm@osdl.org Tue Aug 26 00:37:01 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Aug 2003 00:37:05 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7Q7b1oO009457 for ; Tue, 26 Aug 2003 00:37:01 -0700 Received: from mnm (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id h7Q7ato15493; Tue, 26 Aug 2003 00:36:55 -0700 Date: Tue, 26 Aug 2003 00:39:49 -0700 From: Andrew Morton To: netdev@oss.sgi.com Cc: uwe.schmeling@t-online.de Subject: Fw: [Bugme-new] [Bug 1148] New: when using ipsec with DSL connections communication will hang if mtu is 1500(the default value) Message-Id: <20030826003949.78ea3d07.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5282 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Begin forwarded message: Date: Tue, 26 Aug 2003 00:07:57 -0700 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 1148] New: when using ipsec with DSL connections communication will hang if mtu is 1500(the default value) http://bugme.osdl.org/show_bug.cgi?id=1148 Summary: when using ipsec with DSL connections communication will hang if mtu is 1500(the default value) Kernel Version: 2.6.0-test4 Status: NEW Severity: normal Owner: bugme-janitors@lists.osdl.org Submitter: uwe.schmeling@t-online.de Distribution: Hardware Environment: Software Environment: Problem Description: Steps to reproduce: Startup a tunneling connection, if one of the gw interfaces has mtu=1500, communication will hang after transfering some data through tunnel. As far as I know the problem will occure with DSL connections only. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From shmulik.hen@intel.com Tue Aug 26 00:45:38 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Aug 2003 00:45:42 -0700 (PDT) Received: from hermes.py.intel.com (hermes.py.intel.com [146.152.216.3]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7Q7jboO010251 for ; Tue, 26 Aug 2003 00:45:38 -0700 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.76 2003/08/21 22:58:26 rfjohns1 Exp $) with ESMTP id h7Q7f0C21581 for ; Tue, 26 Aug 2003 07:41:00 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.py.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 h7Q7jRD08748 for ; Tue, 26 Aug 2003 07:45:27 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.254.188]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003082600451718263 ; Tue, 26 Aug 2003 00:45:19 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Shmulik Hen Reply-To: shmulik.hen@intel.com Organization: Intel corp. To: "Stephen Hemminger" Subject: Re: [PATCH] convering bonding driver /proc interface to seq_file Date: Tue, 26 Aug 2003 10:45:16 +0300 User-Agent: KMail/1.4.3 Cc: "James Morris" , , References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200308261045.16910.shmulik.hen@intel.com> X-archive-position: 5283 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev On Monday 25 August 2003 10:27 pm, Stephen Hemminger wrote: > > #ifndef PDE > #define PDE(i) ((struct proc_dir_entry *)(i)->u.generic_ip) > #endif When you're right, you're right. We didn't know we could do that safely in 2.4. How about the following suggestion: I'll take it as my personal commitment to implement the fix you've suggested, along with that of James, but only after the 2.4<->2.6 synchronization is complete. After all, my word is my bond(ing) :) -- | Shmulik Hen Advanced Network Services | | Israel Design Center, Jerusalem | | LAN Access Division, Platform Networking | | Intel Communications Group, Intel corp. | From yoshfuji@linux-ipv6.org Tue Aug 26 01:32:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Aug 2003 01:32:22 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7Q8WDoO013042 for ; Tue, 26 Aug 2003 01:32:14 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h7Q8WR1M010484; Tue, 26 Aug 2003 17:32:27 +0900 Date: Tue, 26 Aug 2003 17:32:26 +0900 (JST) Message-Id: <20030826.173226.114994096.yoshfuji@linux-ipv6.org> To: oford@arghblech.com Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [OOPS] less /proc/net/igmp From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <1061878985.3463.2.camel@spider.hotmonkeyporn.com> References: <20030825163206.GA1340@penguin.penguin> <20030826.150331.102449369.yoshfuji@linux-ipv6.org> <1061878985.3463.2.camel@spider.hotmonkeyporn.com> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 5284 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Please CC: netdev. In article <1061878985.3463.2.camel@spider.hotmonkeyporn.com> (at 26 Aug 2003 01:23:06 -0500), Owen Ford says: > > I could not reproduce this issue. anyone? > > I can confirm. I have it with 2.6.0-test4. > > Let me know what useful info I can provide. The oops is the same. Okay, everyone. I'll try to fix this. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From davem@pizda.ninka.net Tue Aug 26 02:30:59 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Aug 2003 02:31:03 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7Q9UwoO019806 for ; Tue, 26 Aug 2003 02:30:59 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id CAA19243; Tue, 26 Aug 2003 02:22:52 -0700 Date: Tue, 26 Aug 2003 02:22:52 -0700 From: "David S. Miller" To: Andrew Morton Cc: netdev@oss.sgi.com, uwe.schmeling@t-online.de Subject: Re: Fw: [Bugme-new] [Bug 1148] New: when using ipsec with DSL connections communication will hang if mtu is 1500(the default value) Message-Id: <20030826022252.054773d6.davem@redhat.com> In-Reply-To: <20030826003949.78ea3d07.akpm@osdl.org> References: <20030826003949.78ea3d07.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5285 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 26 Aug 2003 00:39:49 -0700 Andrew Morton wrote: > Begin forwarded message: We don't do PMTU properly in tunneled mode, known problem but fix won't happen any time soon as it's non-trivial to cure this properly. From davem@pizda.ninka.net Tue Aug 26 02:33:21 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Aug 2003 02:33:27 -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 h7Q9XKoO020218 for ; Tue, 26 Aug 2003 02:33:20 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id CAA19272; Tue, 26 Aug 2003 02:25:09 -0700 Date: Tue, 26 Aug 2003 02:25:09 -0700 From: "David S. Miller" To: Pekka Pietikainen Cc: dave.antliff@paradise.net.nz, netdev@oss.sgi.com Subject: Re: b44 driver in Linux 2.4.22 Message-Id: <20030826022509.65ca3f4e.davem@redhat.com> In-Reply-To: <20030826070055.GA19639@ee.oulu.fi> References: <20030826070055.GA19639@ee.oulu.fi> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5286 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 26 Aug 2003 10:00:55 +0300 Pekka Pietikainen wrote: > On Tue, Aug 26, 2003 at 09:38:45AM +1200, David Antliff wrote: > > Also, just out of curiosity, is this driver based on Michael Chan's > > Broadcom bcm4400 driver? > > Dave would know best since he wrote the beast, but I believe it's > written using bcm4400 as "documentation" and really based on the > generic Linux ethernet driver template (so tg3.c with tg3 bits changed > into b44 bits :-) ) That's correct. From jmorris@intercode.com.au Tue Aug 26 03:30:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Aug 2003 03:30:27 -0700 (PDT) Received: from blackbird.intercode.com.au (IDENT:rdtkOafHDB1UjPaL+1Omfe/PLeAnJm7c@blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7QAUBoO026416 for ; Tue, 26 Aug 2003 03:30:15 -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 h7QATdC26936; Tue, 26 Aug 2003 20:29:42 +1000 Date: Tue, 26 Aug 2003 20:29:39 +1000 (EST) From: James Morris To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: sebek64@post.cz, , Subject: Re: [OOPS] less /proc/net/igmp In-Reply-To: <20030826.150331.102449369.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 5287 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@intercode.com.au Precedence: bulk X-list: netdev On Tue, 26 Aug 2003, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote: > I could not reproduce this issue. anyone? 'less /proc/net/igmp' does it for me. - James -- James Morris From vinay-rc@naturesoft.net Tue Aug 26 07:01:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Aug 2003 07:01:58 -0700 (PDT) Received: from naturesoft.net ([203.145.184.221]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7QE1poO015900 for ; Tue, 26 Aug 2003 07:01:53 -0700 Received: from trial.naturesoft.com ([192.168.0.15] helo=lima.royalchallenge.com) by naturesoft.net with esmtp (Exim 3.35 #1) id 19reIL-0003UD-00; Tue, 26 Aug 2003 19:25:37 +0530 Subject: [PATCH 2.6.0-test4][IPv6] ip6_flowlabel.c: timer cleanups From: Vinay K Nallamothu To: netdev@oss.sgi.com Cc: LKML Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 26 Aug 2003 19:54:41 +0530 Message-Id: <1061907882.1108.28.camel@lima.royalchallenge.com> Mime-Version: 1.0 X-archive-position: 5288 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vinay-rc@naturesoft.net Precedence: bulk X-list: netdev Hi, Compiles fine though untested. A similar patch should be applicable to 2.4 also. net/ipv6/ip6_flowlabel.c: This patch does the following modifications to timer management: 1. use static timer initializer 2. replace del_timer/add_timer with mod_timer --- linux-2.6.0-test4/net/ipv6/ip6_flowlabel.c 2003-07-15 17:23:45.000000000 +0530 +++ linux-2.6.0-test4-nvk/net/ipv6/ip6_flowlabel.c 2003-08-26 19:49:34.000000000 +0530 @@ -49,7 +49,8 @@ static atomic_t fl_size = ATOMIC_INIT(0); static struct ip6_flowlabel *fl_ht[FL_HASH_MASK+1]; -static struct timer_list ip6_fl_gc_timer; +static void ip6_fl_gc(unsigned long dummy); +static struct timer_list ip6_fl_gc_timer = TIMER_INITIALIZER(ip6_fl_gc, 0, 0); /* FL hash table lock: it protects only of GC */ @@ -104,10 +105,9 @@ fl->opt = NULL; kfree(opt); } - if (!del_timer(&ip6_fl_gc_timer) || - (long)(ip6_fl_gc_timer.expires - ttd) > 0) - ip6_fl_gc_timer.expires = ttd; - add_timer(&ip6_fl_gc_timer); + if (!timer_pending(&ip6_fl_gc_timer) || + time_after(ip6_fl_gc_timer.expires, ttd)) + mod_timer(&ip6_fl_gc_timer, ttd); } } @@ -692,10 +692,6 @@ { #ifdef CONFIG_PROC_FS struct proc_dir_entry *p; -#endif - init_timer(&ip6_fl_gc_timer); - ip6_fl_gc_timer.function = ip6_fl_gc; -#ifdef CONFIG_PROC_FS p = create_proc_entry("ip6_flowlabel", S_IRUGO, proc_net); if (p) p->proc_fops = &ip6fl_seq_fops; From da-x@gmx.net Tue Aug 26 08:56:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Aug 2003 08:56:09 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7QFtwoO012219 for ; Tue, 26 Aug 2003 08:55:59 -0700 Received: (qmail 8293 invoked by uid 65534); 26 Aug 2003 15:38:14 -0000 Received: from DSL212-235-106-20.bb.netvision.net.il (HELO callisto.yi.org) (212.235.106.20) by mail.gmx.net (mp004) with SMTP; 26 Aug 2003 17:38:14 +0200 Date: Tue, 26 Aug 2003 18:38:12 +0300 From: Dan Aloni To: netdev@oss.sgi.com Subject: [BK PATCH 2.6] fix sysctl breakage during network device renaming, for ipv4 Message-ID: <20030826153812.GA2216@callisto.yi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-archive-position: 5290 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: da-x@gmx.net Precedence: bulk X-list: netdev Content-Length: 5379 Lines: 170 You can import this changeset into BK by piping this whole message to: '| bk receive [path to repository]' or apply the patch as usual. =================================================================== ChangeSet@1.1292, 2003-08-26 18:30:17+03:00, da-x@gmx.net Sysctl assumes its ctl_table.procname field is const, but the networking points ctl_table.procname to dev->name. When renaming a network device using SIOCSIFNAME, dev->name is modified and sysctl's assumption breaks, causing this behaviour, at least: 1. sysctl wouldn't be able to remove the proc entry when the device requests to be unregistered, because it would be using the new name instead of the old one. 2. proc entries for devices remain with the old name after rename. This change includes allocating the current device name to a new copy upon registering with sysctl, plus re-registering with sysctl when the device is renamed. This only fixes IPv4. Fixes for ax25, core/neighbour.c, decnet, and ipv6 are also planned. devinet.c | 45 ++++++++++++++++++++++++++++++++++++++++----- 1 files changed, 40 insertions(+), 5 deletions(-) diff -Nru a/net/ipv4/devinet.c b/net/ipv4/devinet.c --- a/net/ipv4/devinet.c Tue Aug 26 18:31:08 2003 +++ b/net/ipv4/devinet.c Tue Aug 26 18:31:08 2003 @@ -904,6 +904,11 @@ * not interesting to applications using netlink. */ inetdev_changename(dev, in_dev); + +#ifdef CONFIG_SYSCTL + devinet_sysctl_unregister(&in_dev->cnf); + devinet_sysctl_register(in_dev, &in_dev->cnf); +#endif break; } out: @@ -1295,12 +1300,21 @@ }, }; +static char *strdup(char *s) +{ + char *rv = kmalloc(strlen(s)+1, GFP_KERNEL); + if (rv) + strcpy(rv, s); + return rv; +} + static void devinet_sysctl_register(struct in_device *in_dev, struct ipv4_devconf *p) { int i; struct net_device *dev = in_dev ? in_dev->dev : NULL; struct devinet_sysctl_table *t = kmalloc(sizeof(*t), GFP_KERNEL); + char *dev_name = NULL; if (!t) return; @@ -1309,13 +1323,25 @@ t->devinet_vars[i].data += (char *)p - (char *)&ipv4_devconf; t->devinet_vars[i].de = NULL; } + if (dev) { - t->devinet_dev[0].procname = dev->name; + dev_name = dev->name; t->devinet_dev[0].ctl_name = dev->ifindex; } else { - t->devinet_dev[0].procname = "default"; + dev_name = "default"; t->devinet_dev[0].ctl_name = NET_PROTO_CONF_DEFAULT; } + + /* + * Make a copy of dev_name, because '.procname' is regarded as const + * by sysctl and we wouldn't want anyone to change it under our feet + * (see SIOCSIFNAME). + */ + dev_name = strdup(dev_name); + if (!dev_name) + goto free; + + t->devinet_dev[0].procname = dev_name; t->devinet_dev[0].child = t->devinet_vars; t->devinet_dev[0].de = NULL; t->devinet_conf_dir[0].child = t->devinet_dev; @@ -1327,9 +1353,17 @@ t->sysctl_header = register_sysctl_table(t->devinet_root_dir, 0); if (!t->sysctl_header) - kfree(t); - else - p->sysctl = t; + goto free_procname; + + p->sysctl = t; + return; + + /* error path */ + free_procname: + kfree(dev_name); + free: + kfree(t); + return; } static void devinet_sysctl_unregister(struct ipv4_devconf *p) @@ -1338,6 +1372,7 @@ struct devinet_sysctl_table *t = p->sysctl; p->sysctl = NULL; unregister_sysctl_table(t->sysctl_header); + kfree(t->devinet_dev[0].procname); kfree(t); } } =================================================================== This BitKeeper patch contains the following changesets: + ## Wrapped with gzip_uu ## M'XL( #Q]2S\ [56^V_;-A#^V?PK;@VP/&K+>EB*;,-!NC3IC*9)D+08AK8P M:(FV5ECQ8I--FR1O#M^W]WIHP[@G6*RUXAIZY$N;;OX\9U3S_:#K1/8G=-MY,2.0SL.BVVW$P8=LDHXW;1D M=,ZISB138J(-C_?5+A^?1O3LT/4S;3!I.B_3 \\=:-GD%_AO25R0"!XV*M(I4*6R!5.0: 4X'FDZ M3IFUE"+B=,%@DK TA@37!%>Z">-,@YXQP (SU0FX5-8BH1_W5\+B-FJ=68& M%OPV8QPDPX'QPABTBF*LDHA!ILS*P_#VXF%X=?/BS65SYV]@+$2<(*88*(]- M )6S.%0%CZ5.!(>Q9'2NFA#1(IJ>H>.8S>@J$9EL M60,HI-B/[X!2Q(&0?6 M(DMC?JC1' P1@U^RA5BQG+6A!8QKN8&UH5)F(K]* I+]D3&%R4!/#))QR::) MTDRR&+/'#"8DHHN=C$7E7V%EF)(U%'PQY8S&(";YO$ 'P9F5>[C6#DV"]9L( M64)0!C%-.*P3/:L=\X!T@D#J'?-"E.'PYZU)4Y1W$NXLC6..HTAP$Y9I9@"VOC"HB[E+;;E+HDJH ML554+$+K!]GQ$D,.[5<4CDPGZZ/K8 $*R-F?)=#;&PEN1Z:4(&ZZ9 M=T^R7 5 )68E50)Q4<[+'5Z#[W>['7*W$Q+2^I<7(3:UR=EW'EP$TT8.'5.G,PG=;CQ^(A+?B&*D)W!\S[:[6S?PPDXN MC5_:?E\C?Q0E^42Y)21=L>@\P$"6FG\;JX._G< _W7;PQL]ETG4^%TF[^U61 M[-C0\O\7E;S?=>I^'_]3CYH.O4,Y0G'+GX?RZ#B]N9J^&KT\/O#Q=MKTFB4L4<%I]%. MJXY^3O@HU]V(3X[[7YK6AH5=$SYS.& <=9H,\: [A9 HC1(2&7&1<**TC+/E M43DX)G^21G$O5S" ^2*7G".T2AD_4L?/G2:\NKH;O;Z\O[F\-F"2"1S)U3&B M0J-HN<%!$Y19D0S/9$SPJD_^0MI#Q[,]<*KXB&^45V$ -^^NK_MFW7%P_0-Y MB7?&>&SS#)-$OULR)T"(Z)W6B? &G ";RA<[;7 M%)7C[E@XK,_-PZ*AIE3&YJPKC]\BS'A3-:%1L37;'5IKBM),^08/":/*E99K M/(5B[%_40)@PU#(3Y4@QMG_.'EMFNMT@^X3*4E4S5?)_JB?0!Z^IP-TFDK&^ MH:M;9U6WX/][^^/N;0"O0"99'FN2=;3:*/*+P^[;)V5M >@ZUKW MRP0S*5'VE_C<(PGRU+U'&G,SL<\CMZ@7]/%>0$2#>F)*6RY^DP]ZU2^AT8Q% 5; Tue, 26 Aug 2003 09:54:45 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h7QGsn1M015121; Wed, 27 Aug 2003 01:54:50 +0900 Date: Wed, 27 Aug 2003 01:54:48 +0900 (JST) Message-Id: <20030827.015448.70287953.yoshfuji@linux-ipv6.org> To: sebek64@post.cz, oford@arghblech.com, smiler@lanil.mine.nu, jmorris@intercode.com.au Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [OOPS] less /proc/net/igmp From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20030826.173226.114994096.yoshfuji@linux-ipv6.org> References: <20030826.150331.102449369.yoshfuji@linux-ipv6.org> <1061878985.3463.2.camel@spider.hotmonkeyporn.com> <20030826.173226.114994096.yoshfuji@linux-ipv6.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-archive-position: 5291 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 3005 Lines: 119 Hello. In article <20030826.173226.114994096.yoshfuji@linux-ipv6.org> (at Tue, 26 Aug 2003 17:32:26 +0900 (JST)), YOSHIFUJI Hideaki / $B5HF#1QL@(B says: > > I can confirm. I have it with 2.6.0-test4. > > > > Let me know what useful info I can provide. The oops is the same. > > Okay, everyone. I'll try to fix this. Please try this patch. Index: linux-2.6/net/ipv4/igmp.c =================================================================== RCS file: /home/cvs/linux-2.5/net/ipv4/igmp.c,v retrieving revision 1.33 diff -u -r1.33 igmp.c --- linux-2.6/net/ipv4/igmp.c 21 Aug 2003 17:47:23 -0000 1.33 +++ linux-2.6/net/ipv4/igmp.c 26 Aug 2003 15:18:03 -0000 @@ -2122,6 +2122,7 @@ break; } read_unlock(&in_dev->lock); + in_dev_put(in_dev); } return im; } @@ -2181,7 +2182,9 @@ if (likely(state->in_dev != NULL)) { read_unlock(&state->in_dev->lock); in_dev_put(state->in_dev); + state->in_dev = NULL; } + state->dev = NULL; read_unlock(&dev_base_lock); } @@ -2284,6 +2287,7 @@ spin_unlock_bh(&im->lock); } read_unlock_bh(&idev->lock); + in_dev_put(idev); } return psf; } @@ -2350,12 +2354,16 @@ static void igmp_mcf_seq_stop(struct seq_file *seq, void *v) { struct igmp_mcf_iter_state *state = igmp_mcf_seq_private(seq); - if (likely(state->im != NULL)) + if (likely(state->im != NULL)) { spin_unlock_bh(&state->im->lock); + state->im = NULL; + } if (likely(state->idev != NULL)) { read_unlock_bh(&state->idev->lock); in_dev_put(state->idev); + state->idev = NULL; } + state->dev = NULL; read_unlock(&dev_base_lock); } Index: linux-2.6/net/ipv6/mcast.c =================================================================== RCS file: /home/cvs/linux-2.5/net/ipv6/mcast.c,v retrieving revision 1.30 diff -u -r1.30 mcast.c --- linux-2.6/net/ipv6/mcast.c 21 Aug 2003 23:44:54 -0000 1.30 +++ linux-2.6/net/ipv6/mcast.c 26 Aug 2003 15:18:03 -0000 @@ -2078,6 +2078,7 @@ break; } read_unlock_bh(&idev->lock); + in6_dev_put(idev); } return im; } @@ -2135,7 +2136,9 @@ if (likely(state->idev != NULL)) { read_unlock_bh(&state->idev->lock); in6_dev_put(state->idev); + state->idev = NULL; } + state->dev = NULL; read_unlock(&dev_base_lock); } @@ -2225,6 +2228,7 @@ spin_unlock_bh(&im->mca_lock); } read_unlock_bh(&idev->lock); + in6_dev_put(idev); } return psf; } @@ -2291,12 +2295,16 @@ static void igmp6_mcf_seq_stop(struct seq_file *seq, void *v) { struct igmp6_mcf_iter_state *state = igmp6_mcf_seq_private(seq); - if (likely(state->im != NULL)) + if (likely(state->im != NULL)) { spin_unlock_bh(&state->im->mca_lock); + state->im = NULL; + } if (likely(state->idev != NULL)) { read_unlock_bh(&state->idev->lock); in6_dev_put(state->idev); + state->idev = NULL; } + state->dev = NULL; read_unlock(&dev_base_lock); } -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From mfedyk@matchmail.com Tue Aug 26 10:18:04 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Aug 2003 10:18:09 -0700 (PDT) Received: from mmp-linux.matchmail.com (adsl-63-194-239-202.dsl.lsan03.pacbell.net [63.194.239.202]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7QHI4oO019194 for ; Tue, 26 Aug 2003 10:18:04 -0700 Received: from [10.0.0.122] (helo=mis-mike-wstn) by mmp-linux.matchmail.com with esmtp (Exim 3.36 #1 (Debian)) id 19rhS7-0000sK-00; Tue, 26 Aug 2003 10:17:55 -0700 Received: from mfedyk by mis-mike-wstn with local (Exim 3.35 #1 (Debian)) id 19rhS6-0004XL-00; Tue, 26 Aug 2003 10:17:54 -0700 Date: Tue, 26 Aug 2003 10:17:54 -0700 From: Mike Fedyk To: Francois Romieu Cc: Jeff Garzik , torvalds@osdl.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [bk patches] net driver updates Message-ID: <20030826171754.GD16831@matchmail.com> Mail-Followup-To: Francois Romieu , Jeff Garzik , torvalds@osdl.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com References: <20030817183137.GA18521@gtf.org> <20030823154231.A11381@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030823154231.A11381@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.5.4i X-archive-position: 5292 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mfedyk@matchmail.com Precedence: bulk X-list: netdev On Sat, Aug 23, 2003 at 03:42:31PM +0200, Francois Romieu wrote: > Jeff Garzik : > [net-drivers-2.6 update] > > drivers/net/sis190.c | 2094 +++++++++++++++++++++++++++++--------- > > > synchronize_irq() requires an argument when built with CONFIG_SMP. Shouldn't it also require it for the UP case? Or is this one of those subtle things that tells you it's not working on SMP? From jgarzik@pobox.com Tue Aug 26 10:25:56 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Aug 2003 10:26:00 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7QHPsoO020357 for ; Tue, 26 Aug 2003 10:25:56 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11]:33575 helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.22) id 19rhZo-0004F7-M1; Tue, 26 Aug 2003 18:25:52 +0100 Message-ID: <3F4B9814.2090202@pobox.com> Date: Tue, 26 Aug 2003 13:25:40 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: Mike Fedyk CC: Francois Romieu , torvalds@osdl.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [bk patches] net driver updates References: <20030817183137.GA18521@gtf.org> <20030823154231.A11381@electric-eye.fr.zoreil.com> <20030826171754.GD16831@matchmail.com> In-Reply-To: <20030826171754.GD16831@matchmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5293 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 Mike Fedyk wrote: > On Sat, Aug 23, 2003 at 03:42:31PM +0200, Francois Romieu wrote: > >>Jeff Garzik : >>[net-drivers-2.6 update] >> >>> drivers/net/sis190.c | 2094 +++++++++++++++++++++++++++++--------- >> >> >>synchronize_irq() requires an argument when built with CONFIG_SMP. > > > Shouldn't it also require it for the UP case? Or is this one of those > subtle things that tells you it's not working on SMP? the latter :) Jeff From jgarzik@pobox.com Tue Aug 26 10:47:43 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Aug 2003 10:47:46 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7QHlgoO022120 for ; Tue, 26 Aug 2003 10:47:43 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11]:33584 helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.22) id 19rhuv-0004hO-Gn; Tue, 26 Aug 2003 18:47:41 +0100 Message-ID: <3F4B9D31.7020901@pobox.com> Date: Tue, 26 Aug 2003 13:47:29 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: Francois Romieu CC: torvalds@osdl.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [bk patches] net driver updates References: <20030817183137.GA18521@gtf.org> <20030823154231.A11381@electric-eye.fr.zoreil.com> In-Reply-To: <20030823154231.A11381@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5294 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 thanks, applied From greg@kroah.com Tue Aug 26 12:03:59 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Aug 2003 12:04:09 -0700 (PDT) Received: from perch.kroah.org (mail.kroah.org [65.200.24.183]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7QJ3woO027122 for ; Tue, 26 Aug 2003 12:03:59 -0700 Received: from DYN318096BLD.beaverton.ibm.com (bi01p1.co.us.ibm.com [32.97.110.142]) (authenticated) by perch.kroah.org (8.11.6/8.11.6) with ESMTP id h7QJ1YI23360; Tue, 26 Aug 2003 12:01:34 -0700 Received: from greg by echidna.kroah.org with local (masqmail 0.2.19) id 19ric9-0sH-00; Tue, 26 Aug 2003 11:32:21 -0700 Date: Tue, 26 Aug 2003 11:32:21 -0700 From: Greg KH To: Jim Keniston Cc: LKML , netdev , Jeff Garzik , "Feldman, Scott" , Larry Kessler , Randy Dunlap , Alan Cox , Andrew Morton Subject: Re: [PATCH 1/4] Net device error logging, revised Message-ID: <20030826183221.GB3167@kroah.com> References: <3F4A8027.6FE3F594@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F4A8027.6FE3F594@us.ibm.com> User-Agent: Mutt/1.4.1i X-archive-position: 5295 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greg@kroah.com Precedence: bulk X-list: netdev On Mon, Aug 25, 2003 at 02:31:19PM -0700, Jim Keniston wrote: > +int __netdev_printk(const char *sevlevel, const struct net_device *netdev, > + int msglevel, const char *format, ...) > +{ > + if (!netdev || !format) { > + return -EINVAL; > + } > + if (msglevel == NETIF_MSG_ALL || (netdev->msg_enable & msglevel)) { > + char msg[512]; 512 bytes on the stack? Any way to prevent this from happening? With the push to make the stack even smaller in 2.7, people will not like this. thanks, greg k-h From oford@arghblech.com Tue Aug 26 13:18:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Aug 2003 13:18:51 -0700 (PDT) Received: from ms-smtp-02.texas.rr.com (ms-smtp-02.texas.rr.com [24.93.36.230]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7QKIjoO031655 for ; Tue, 26 Aug 2003 13:18:46 -0700 Received: from spider.hotmonkeyporn.com (cs671084-162.houston.rr.com [67.10.84.162]) by ms-smtp-02.texas.rr.com (8.12.5/8.12.2) with ESMTP id h7QKIS42011692; Tue, 26 Aug 2003 15:18:33 -0500 (CDT) Subject: Re: [OOPS] less /proc/net/igmp From: Owen Ford To: YOSHIFUJI Hideaki / =?UTF-8?Q?=E5=90=89=E8=97=A4=E8=8B=B1?= =?UTF-8?Q?=E6=98=8E?= Cc: sebek64@post.cz, smiler@lanil.mine.nu, jmorris@intercode.com.au, lkml , netdev@oss.sgi.com In-Reply-To: <20030827.015448.70287953.yoshfuji@linux-ipv6.org> References: <20030826.150331.102449369.yoshfuji@linux-ipv6.org> <1061878985.3463.2.camel@spider.hotmonkeyporn.com> <20030826.173226.114994096.yoshfuji@linux-ipv6.org> <20030827.015448.70287953.yoshfuji@linux-ipv6.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-PeS/01pZdZ+R0lb8Y0wo" Message-Id: <1061929108.3946.1.camel@spider.hotmonkeyporn.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 26 Aug 2003 15:18:28 -0500 X-archive-position: 5296 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: oford@arghblech.com Precedence: bulk X-list: netdev --=-PeS/01pZdZ+R0lb8Y0wo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 2003-08-26 at 11:54, YOSHIFUJI Hideaki / =E5=90=89=E8=97=A4=E8=8B= =B1=E6=98=8E wrote: > Hello. >=20 > In article <20030826.173226.114994096.yoshfuji@linux-ipv6.org> (at Tue, 2= 6 Aug 2003 17:32:26 +0900 (JST)), YOSHIFUJI Hideaki / =E5=90=89=E8=97=A4=E8= =8B=B1=E6=98=8E says: >=20 > > > I can confirm. I have it with 2.6.0-test4. > > >=20 > > > Let me know what useful info I can provide. The oops is the same. > >=20 > > Okay, everyone. I'll try to fix this. >=20 > Please try this patch. That seems to have done the job nicely. Thanks. =20 --=20 Owen Ford --=-PeS/01pZdZ+R0lb8Y0wo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/S8CU4bjUYpnk5/QRAkl3AJ918JN3kzIZWCjhaaaDdUFUYdy7vgCgj5Q3 3XADkcptoVsOgMKthnWz9Pg= =AORG -----END PGP SIGNATURE----- --=-PeS/01pZdZ+R0lb8Y0wo-- From garzik@gtf.org Tue Aug 26 13:51:43 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Aug 2003 13:51:49 -0700 (PDT) Received: from havoc.gtf.org (havoc.gtf.org [63.247.75.124]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7QKpgoO001082 for ; Tue, 26 Aug 2003 13:51:42 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id D84AF6658; Tue, 26 Aug 2003 16:51:36 -0400 (EDT) Date: Tue, 26 Aug 2003 16:51:36 -0400 From: Jeff Garzik To: netdev@oss.sgi.com Subject: [bk] 2.6.x net driver queue snapshot Message-ID: <20030826205136.GA32063@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: 5297 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 Snapshot of the current 2.6.x net driver queue. Notably, collects sis190 fixes. BK users: bk pull bk://kernel.bkbits.net/jgarzik/net-drivers-2.6 or bk pull http://gkernel.bkbits.net/net-drivers-2.6 This will update the following files: drivers/net/3c501.c | 91 +-------- drivers/net/3c501.h | 2 drivers/net/3c503.c | 71 +------ drivers/net/3c505.c | 96 ++-------- drivers/net/3c507.c | 97 ++-------- drivers/net/3c515.c | 94 ++------- drivers/net/3c523.c | 73 +------ drivers/net/3c527.c | 94 ++------- drivers/net/3c59x.c | 47 +--- drivers/net/8139cp.c | 444 ++++++++++++++++++----------------------------- drivers/net/Kconfig | 2 drivers/net/sis190.c | 79 +++++--- drivers/net/sis900.c | 43 +--- drivers/net/tulip/dmfe.c | 62 +----- 14 files changed, 393 insertions(+), 902 deletions(-) through these ChangeSets: (03/08/26 1.1301) [netdrvr] ethtool_ops support for 3c515, 3c523, 3c527, and dmfe (03/08/26 1.1300) [netdrvr] ethtool_ops support in 3c503, 3c505, 3c507 (03/08/26 1.1299) [netdrvr 3c501] ethtool_ops support (03/08/26 1.1298) [netdrvr sis190] make driver depend on CONFIG_BROKEN Until RX path is cleaned up to use PCI DMA API and not virt_to_bus. (03/08/26 1.1297) [netdrvr sis190] convert TX path to use PCI DMA API Also, minor changes: * mark ->hard_start_xmit ETH_ZLEN test as unlikely() * use cpu_to_le32() and le32_to_cpu() in TX path * fix two leak in error path, in ->hard_start_xmit * don't test netif_queue_stopped() in TX completion path, netif_wake_queue() already does that. (03/08/26 1.1296) [netdrvr 8139cp] ethtool_ops support (03/08/26 1.1295) [netdrvr sis900] ethtool_ops support (03/08/26 1.1294) [netdrvr 3c59x] ethtool_ops support (03/08/26 1.1293) [netdrvr sis190] pass irq argument to synchronize_irq() Looks like this driver wasn't tested on SMP :) (03/08/26 1.1292) [netdrvr sis190] fix build with older gcc older gcc's do not support C99/C++ style of variable declarations. From mcr@sandelman.ottawa.on.ca Tue Aug 26 14:00:12 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Aug 2003 14:00:16 -0700 (PDT) Received: from noxmail.sandelman.ottawa.on.ca ([205.150.200.166]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7QKxpoO001702 for ; Tue, 26 Aug 2003 14:00:11 -0700 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h7QKxhd13328 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Tue, 26 Aug 2003 16:59:49 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h7QKxgO8020711; Tue, 26 Aug 2003 16:59:42 -0400 To: Andrew Morton cc: netdev@oss.sgi.com, uwe.schmeling@t-online.de Subject: Re: Fw: [Bugme-new] [Bug 1148] New: when using ipsec with DSL connections communication will hang if mtu is 1500(the default value) In-reply-to: Your message of "Tue, 26 Aug 2003 00:39:49 PDT." <20030826003949.78ea3d07.akpm@osdl.org> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 26 Aug 2003 16:59:42 -0400 Message-ID: <20709.1061931582@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-archive-position: 5298 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcr@sandelman.ottawa.on.ca Precedence: bulk X-list: netdev >>>>> "Andrew" == Andrew Morton writes: Andrew> Distribution: Andrew> Hardware Environment: Andrew> Software Environment: Andrew> Problem Description: Andrew> Steps to reproduce: Andrew> Startup a tunneling connection, if one of the gw interfaces has Andrew> mtu=1500, Andrew> communication will hang after transfering some data through Andrew> tunnel. As far as I Andrew> know the problem will occure with DSL connections only. If by "DSL", you mean PPPoE, then you are dealing with layers of tunnels. This sure sounds like a classif pmtud blackhole problem. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ From garzik@gtf.org Tue Aug 26 14:29:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Aug 2003 14:29:33 -0700 (PDT) Received: from havoc.gtf.org (havoc.gtf.org [63.247.75.124]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7QLTHoO003632 for ; Tue, 26 Aug 2003 14:29:18 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id 74A9D660D; Tue, 26 Aug 2003 16:50:42 -0400 (EDT) Date: Tue, 26 Aug 2003 16:50:42 -0400 From: Jeff Garzik To: netdev@oss.sgi.com Subject: [bk] 2.4.x net driver queue snapshot Message-ID: <20030826205042.GA31910@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: 5299 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 Here is just a snapshot of my 2.4 net driver queue. Marcelo pulled yesterday, including some bonding bits. No GNU patch for snapshots, as the queue is still being grown... BK users: bk pull bk://kernel.bkbits.net/jgarzik/net-drivers-2.4 or bk pull http://gkernel.bkbits.net/net-drivers-2.4 This will update the following files: drivers/net/3c501.c | 93 ++-------- drivers/net/3c503.c | 71 +------ drivers/net/3c505.c | 92 +-------- drivers/net/3c507.c | 97 ++-------- drivers/net/3c515.c | 94 ++-------- drivers/net/3c523.c | 73 +------ drivers/net/3c527.c | 94 ++-------- drivers/net/3c59x.c | 50 ++--- drivers/net/8139cp.c | 472 ++++++++++++++++++++------------------------------- drivers/net/dmfe.c | 61 +----- drivers/net/sis900.c | 53 ++--- 11 files changed, 362 insertions(+), 888 deletions(-) through these ChangeSets: (03/08/26 1.1085) [netdrvr] ethtool_ops support for 3c515, 3c523, 3c527, and dmfe (03/08/26 1.1084) [netdrvr] ethtool_ops support in 3c503, 3c505, 3c507 (03/08/26 1.1083) [netdrvr 3c501] ethtool_ops support (03/08/26 1.1082) [netdrvr 3c59x] add a piece missed in previous ethtool_ops patch Contributed by Matthew Wilcox. (03/08/26 1.1081) [netdrvr 8139cp] ethtool_ops support (03/08/26 1.1080) [netdrvr 8139cp] minor bits from 2.6 (03/08/26 1.1079) [netdrvr sis900] minor bits from 2.6 (03/08/26 1.1078) [netdrvr sis900] ethtool_ops support (03/08/26 1.1077) [netdrvr 3c59x] ethtool_ops support From romieu@fr.zoreil.com Tue Aug 26 15:08:20 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Aug 2003 15:08:27 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7QM8IoO006699 for ; Tue, 26 Aug 2003 15:08:19 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id h7QM7axA023539; Wed, 27 Aug 2003 00:07:36 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id h7QM7a7f023538; Wed, 27 Aug 2003 00:07:36 +0200 Date: Wed, 27 Aug 2003 00:07:36 +0200 From: Francois Romieu To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [patch] 2.6.0-test4 - more sis190 nit I/II Message-ID: <20030827000736.A23532@electric-eye.fr.zoreil.com> References: <20030826205136.GA32063@gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030826205136.GA32063@gtf.org>; from jgarzik@pobox.com on Tue, Aug 26, 2003 at 04:51:36PM -0400 X-archive-position: 5300 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Jeff Garzik : [....] > (03/08/26 1.1293) > [netdrvr sis190] pass irq argument to synchronize_irq() > > Looks like this driver wasn't tested on SMP :) The following patch should apply on top of this. Compiled, untested. Driver does not need to enforce 256 byte alignment for data returned from pci_alloc_consistent(). - {rx/tx}_dma_aligned and {rx/td}_dma_raw are both replaced by {rx/tx}_dma; - {rx/tx}_desc_raw is replaced by direct use of {Rx/Tx}DescArray; - SiS190_open() + fixup for a lack of kmalloc() failure handling; + (return status) there is no need for both retval/rc: merge them; + anonymous printk() fixup: the name of the guilty device is printed; - define {RX/TX}_DESC_TOTAL_SIZE because I am too lazy to read twice the same lengthy arithmetic expression. drivers/net/sis190.c | 78 ++++++++++++++++++++++----------------------------- 1 files changed, 35 insertions(+), 43 deletions(-) diff -puN drivers/net/sis190.c~redundant-alignment-sis190 drivers/net/sis190.c --- linux-2.6.0-test4/drivers/net/sis190.c~redundant-alignment-sis190 Tue Aug 26 21:55:14 2003 +++ linux-2.6.0-test4-fr/drivers/net/sis190.c Tue Aug 26 22:22:09 2003 @@ -76,6 +76,8 @@ static int multicast_filter_limit = 32; #define NUM_TX_DESC 64 /* Number of Tx descriptor registers */ #define NUM_RX_DESC 64 /* Number of Rx descriptor registers */ +#define TX_DESC_TOTAL_SIZE ((NUM_TX_DESC * sizeof (struct TxDesc)) + 256) +#define RX_DESC_TOTAL_SIZE ((NUM_RX_DESC * sizeof (struct RxDesc)) + 256) #define RX_BUF_SIZE 1536 /* Rx Buffer size */ #define SiS190_MIN_IO_SIZE 0x80 @@ -311,12 +313,8 @@ struct sis190_private { unsigned long cur_rx; /* Index into the Rx descriptor buffer of next Rx pkt. */ unsigned long cur_tx; /* Index into the Tx descriptor buffer of next Rx pkt. */ unsigned long dirty_tx; - void *tx_desc_raw; /* Tx descriptor buffer */ - dma_addr_t tx_dma_raw; - dma_addr_t tx_dma_aligned; - void *rx_desc_raw; /* Rx descriptor buffer */ - dma_addr_t rx_dma_raw; - dma_addr_t rx_dma_aligned; + dma_addr_t tx_dma; + dma_addr_t rx_dma; struct TxDesc *TxDescArray; /* Index of 256-alignment Tx Descriptor buffer */ struct RxDesc *RxDescArray; /* Index of 256-alignment Rx Descriptor buffer */ unsigned char *RxBufferRings; /* Index of Rx Buffer */ @@ -714,54 +712,50 @@ static int SiS190_open(struct net_device *dev) { struct sis190_private *tp = dev->priv; - int retval; - u8 diff; int rc; - retval = - request_irq(dev->irq, SiS190_interrupt, SA_SHIRQ, dev->name, dev); - if (retval) { - return retval; - } + rc = request_irq(dev->irq, SiS190_interrupt, SA_SHIRQ, dev->name, dev); + if (rc) + goto out; - tp->tx_desc_raw = pci_alloc_consistent(tp->pci_dev, - (NUM_TX_DESC * sizeof (struct TxDesc)) + 256, - &tp->tx_dma_raw); - if (!tp->tx_desc_raw) { + /* + * Rx and Tx descriptors need 256 bytes alignment. + * pci_alloc_consistent() guarantees a stronger alignment. + */ + tp->TxDescArray = pci_alloc_consistent(tp->pci_dev, TX_DESC_TOTAL_SIZE, + &tp->tx_dma); + if (!tp->TxDescArray) { rc = -ENOMEM; goto err_out; } - // Tx Desscriptor needs 256 bytes alignment; - diff = 256 - (tp->tx_dma_raw - ((tp->tx_dma_raw >> 8) << 8)); - tp->tx_dma_aligned = tp->tx_dma_raw + diff; - tp->TxDescArray = (struct TxDesc *) (tp->tx_desc_raw + diff); - - tp->rx_desc_raw = pci_alloc_consistent(tp->pci_dev, - (NUM_RX_DESC * sizeof (struct RxDesc)) + 256, - &tp->rx_dma_raw); - if (!tp->rx_desc_raw) { + + tp->RxDescArray = pci_alloc_consistent(tp->pci_dev, RX_DESC_TOTAL_SIZE, + &tp->rx_dma); + if (!tp->RxDescArray) { rc = -ENOMEM; goto err_out_free_tx; } - // Rx Desscriptor needs 256 bytes alignment; - diff = 256 - (tp->rx_dma_raw - ((tp->rx_dma_raw >> 8) << 8)); - tp->rx_dma_aligned = tp->rx_dma_raw + diff; - tp->RxDescArray = (struct RxDesc *) (tp->rx_desc_raw + diff); tp->RxBufferRings = kmalloc(RX_BUF_SIZE * NUM_RX_DESC, GFP_KERNEL); if (tp->RxBufferRings == NULL) { - printk(KERN_INFO "Allocate RxBufferRing failed\n"); + printk(KERN_INFO "%s: allocate RxBufferRing failed\n", + dev->name); + rc = -ENOMEM; + goto err_out_free_rx; } SiS190_init_ring(dev); SiS190_hw_start(dev); - return 0; +out: + return rc; +err_out_free_rx: + pci_free_consistent(tp->pci_dev, RX_DESC_TOTAL_SIZE, tp->RxDescArray, + tp->rx_dma); err_out_free_tx: - pci_free_consistent(tp->pci_dev, - (NUM_TX_DESC * sizeof (struct TxDesc)) + 256, - tp->tx_desc_raw, tp->tx_dma_raw); + pci_free_consistent(tp->pci_dev, TX_DESC_TOTAL_SIZE, tp->TxDescArray, + tp->tx_dma); err_out: free_irq(dev->irq, dev); return rc; @@ -780,10 +774,10 @@ SiS190_hw_start(struct net_device *dev) SiS_W32(IntrControl, 0x0); SiS_W32(0x0, 0x01a00); - SiS_W32(0x4, tp->tx_dma_aligned); + SiS_W32(0x4, tp->tx_dma); SiS_W32(0x10, 0x1a00); - SiS_W32(0x14, tp->rx_dma_aligned); + SiS_W32(0x14, tp->rx_dma); SiS_W32(0x20, 0xffffffff); SiS_W32(0x24, 0x0); @@ -1115,12 +1109,10 @@ SiS190_close(struct net_device *dev) free_irq(dev->irq, dev); SiS190_tx_clear(tp); - pci_free_consistent(tp->pci_dev, - (NUM_TX_DESC * sizeof (struct TxDesc)) + 256, - tp->tx_desc_raw, tp->tx_dma_raw); - pci_free_consistent(tp->pci_dev, - (NUM_RX_DESC * sizeof (struct RxDesc)) + 256, - tp->rx_desc_raw, tp->rx_dma_raw); + pci_free_consistent(tp->pci_dev, TX_DESC_TOTAL_SIZE, tp->TxDescArray, + tp->tx_dma); + pci_free_consistent(tp->pci_dev, RX_DESC_TOTAL_SIZE, tp->RxDescArray, + tp->rx_dma); tp->TxDescArray = NULL; tp->RxDescArray = NULL; kfree(tp->RxBufferRings); _ From romieu@fr.zoreil.com Tue Aug 26 15:18:19 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Aug 2003 15:18:23 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7QMIHoO007767 for ; Tue, 26 Aug 2003 15:18:18 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id h7QMEbxA023662; Wed, 27 Aug 2003 00:14:37 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id h7QMEb7R023661; Wed, 27 Aug 2003 00:14:37 +0200 Date: Wed, 27 Aug 2003 00:14:37 +0200 From: Francois Romieu To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [patch] 2.6.0-test4 - more sis190 nit II/II Message-ID: <20030827001437.B23532@electric-eye.fr.zoreil.com> References: <20030826205136.GA32063@gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030826205136.GA32063@gtf.org>; from jgarzik@pobox.com on Tue, Aug 26, 2003 at 04:51:36PM -0400 X-archive-position: 5301 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Jeff Garzik : [...] > (03/08/26 1.1298) > [netdrvr sis190] make driver depend on CONFIG_BROKEN > > Until RX path is cleaned up to use PCI DMA API and > not virt_to_bus. > > (03/08/26 1.1297) > [netdrvr sis190] convert TX path to use PCI DMA API > > Also, minor changes: > * mark ->hard_start_xmit ETH_ZLEN test as unlikely() > * use cpu_to_le32() and le32_to_cpu() in TX path > * fix two leak in error path, in ->hard_start_xmit > * don't test netif_queue_stopped() in TX completion path, > netif_wake_queue() already does that. > Is plain old patch for the previous items available somewhere ? I had just finished that (no more work on it before 24h): Missing pieces for DMA-API. - SiS190_init_ring: the global area for the received data is mapped. This area is persistent during the whole driver's life. It only needs to be unmapped in SiS190_close() as no other exit/error path exists. - SiS190_rx_interrupt: no map/unmap for received data buffer. A single sync operation is done. Btw, there is no need to store the same value in RxDescArray[cur_rx].buf_addr over and over again. - SiS190_start_xmit: transmitted data buffer is mapped. - SiS190_tx_clear/SiS190_tx_interrupt: transmitted data buffer is unmapped. drivers/net/sis190.c | 109 ++++++++++++++++++++++++++------------------------- 1 files changed, 57 insertions(+), 52 deletions(-) diff -puN drivers/net/sis190.c~sis190-dma-mapping drivers/net/sis190.c --- linux-2.6.0-test4/drivers/net/sis190.c~sis190-dma-mapping Tue Aug 26 22:28:01 2003 +++ linux-2.6.0-test4-fr/drivers/net/sis190.c Wed Aug 27 00:00:54 2003 @@ -824,19 +824,19 @@ SiS190_init_ring(struct net_device *dev) tp->Tx_skbuff[i] = NULL; } for (i = 0; i < NUM_RX_DESC; i++) { + struct RxDesc *desc = tp->RxDescArray + i; - tp->RxDescArray[i].PSize = 0x0; + desc->PSize = 0x0; if (i == (NUM_RX_DESC - 1)) - tp->RxDescArray[i].buf_Len = BIT_31 + RX_BUF_SIZE; //bit 31 is End bit + desc->buf_Len = BIT_31 + RX_BUF_SIZE; //bit 31 is End bit else - tp->RxDescArray[i].buf_Len = RX_BUF_SIZE; - -#warning Replace virt_to_bus with DMA mapping - tp->RxBufferRing[i] = &(tp->RxBufferRings[i * RX_BUF_SIZE]); - tp->RxDescArray[i].buf_addr = virt_to_bus(tp->RxBufferRing[i]); - tp->RxDescArray[i].status = OWNbit | INTbit; + desc->buf_Len = RX_BUF_SIZE; + tp->RxBufferRing[i] = tp->RxBufferRings + i * RX_BUF_SIZE; + desc->buf_addr = pci_map_single(tp->pci_dev, + tp->RxBufferRing[i], RX_BUF_SIZE, PCI_DMA_FROMDEVICE); + desc->status = OWNbit | INTbit; } } @@ -848,8 +848,14 @@ SiS190_tx_clear(struct sis190_private *t tp->cur_tx = 0; for (i = 0; i < NUM_TX_DESC; i++) { - if (tp->Tx_skbuff[i] != NULL) { - dev_kfree_skb(tp->Tx_skbuff[i]); + struct sk_buff *skb = tp->Tx_skbuff[i]; + + if (skb != NULL) { + pci_unmap_single(tp->pci_dev, + tp->TxDescArray[i].buf_addr, + (skb->len > ETH_ZLEN) ? skb->len : ETH_ZLEN, + PCI_DMA_TODEVICE); + dev_kfree_skb(skb); tp->Tx_skbuff[i] = NULL; tp->stats.tx_dropped++; } @@ -888,6 +894,7 @@ SiS190_start_xmit(struct sk_buff *skb, s struct sis190_private *tp = dev->priv; void *ioaddr = tp->mmio_addr; int entry = tp->cur_tx % NUM_TX_DESC; + struct TxDesc *desc = tp->TxDescArray + entry; if (skb->len < ETH_ZLEN) { skb = skb_padto(skb, ETH_ZLEN); @@ -897,23 +904,17 @@ SiS190_start_xmit(struct sk_buff *skb, s spin_lock_irq(&tp->lock); - if ((tp->TxDescArray[entry].status & OWNbit) == 0) { -#warning Replace virt_to_bus with DMA mapping + if ((desc->status & OWNbit) == 0) { tp->Tx_skbuff[entry] = skb; - tp->TxDescArray[entry].buf_addr = virt_to_bus(skb->data); - tp->TxDescArray[entry].PSize = - ((skb->len > ETH_ZLEN) ? skb->len : ETH_ZLEN); - - if (entry != (NUM_TX_DESC - 1)) { - tp->TxDescArray[entry].buf_Len = - tp->TxDescArray[entry].PSize; - } else { - tp->TxDescArray[entry].buf_Len = - tp->TxDescArray[entry].PSize | ENDbit; - } + desc->buf_addr = pci_map_single(tp->pci_dev, skb->data, + desc->PSize, PCI_DMA_TODEVICE); + desc->PSize = ((skb->len > ETH_ZLEN) ? skb->len : ETH_ZLEN); + + desc->buf_Len = desc->PSize; + if (entry == (NUM_TX_DESC - 1)) + desc->buf_Len |= ENDbit; - tp->TxDescArray[entry].status |= - (OWNbit | INTbit | DEFbit | CRCbit | PADbit); + desc->status |= (OWNbit | INTbit | DEFbit | CRCbit | PADbit); SiS_W32(TxControl, 0x1a11); //Start Send @@ -946,10 +947,17 @@ SiS190_tx_interrupt(struct net_device *d tx_left = tp->cur_tx - dirty_tx; while (tx_left > 0) { - if ((tp->TxDescArray[entry].status & OWNbit) == 0) { - dev_kfree_skb_irq(tp-> - Tx_skbuff[dirty_tx % NUM_TX_DESC]); - tp->Tx_skbuff[dirty_tx % NUM_TX_DESC] = NULL; + const int dirty = dirty_tx % NUM_TX_DESC; + struct TxDesc *desc = tp->TxDescArray + dirty; + + if ((desc->status & OWNbit) == 0) { + struct sk_buff *skb = tp->Tx_skbuff[dirty]; + + pci_unmap_single(tp->pci_dev, desc->buf_addr, + (skb->len > ETH_ZLEN) ? skb->len : ETH_ZLEN, + PCI_DMA_TODEVICE); + dev_kfree_skb_irq(skb); + tp->Tx_skbuff[dirty] = NULL; tp->stats.tx_packets++; dirty_tx++; tx_left--; @@ -968,29 +976,30 @@ static void SiS190_rx_interrupt(struct net_device *dev, struct sis190_private *tp, void *ioaddr) { - int cur_rx; - struct sk_buff *skb; - int pkt_size = 0; + int cur_rx = tp->cur_rx; + struct RxDesc *desc = tp->RxDescArray + cur_rx; assert(dev != NULL); assert(tp != NULL); assert(ioaddr != NULL); - cur_rx = tp->cur_rx; - while ((tp->RxDescArray[cur_rx].status & OWNbit) == 0) { + while ((desc->status & OWNbit) == 0) { - if (tp->RxDescArray[cur_rx].PSize & 0x0080000) { + if (desc->PSize & 0x0080000) { printk(KERN_INFO "%s: Rx ERROR!!!\n", dev->name); tp->stats.rx_errors++; tp->stats.rx_length_errors++; - } else if (!(tp->RxDescArray[cur_rx].PSize & 0x0010000)) { + } else if (!(desc->PSize & 0x0010000)) { printk(KERN_INFO "%s: Rx ERROR!!!\n", dev->name); tp->stats.rx_errors++; tp->stats.rx_crc_errors++; } else { - pkt_size = - (int) (tp->RxDescArray[cur_rx]. - PSize & 0x0000FFFF) - 4; + struct sk_buff *skb; + int pkt_size; + + pkt_size = (int) (desc->PSize & 0x0000FFFF) - 4; + pci_dma_sync_single(tp->pci_dev, desc->buf_addr, + RX_BUF_SIZE, PCI_DMA_FROMDEVICE); skb = dev_alloc_skb(pkt_size + 2); if (skb != NULL) { skb->dev = dev; @@ -1001,24 +1010,18 @@ SiS190_rx_interrupt(struct net_device *d skb->protocol = eth_type_trans(skb, dev); netif_rx(skb); - tp->RxDescArray[cur_rx].PSize = 0x0; + desc->PSize = 0x0; if (cur_rx == (NUM_RX_DESC - 1)) - tp->RxDescArray[cur_rx].buf_Len = - ENDbit + RX_BUF_SIZE; + desc->buf_Len = ENDbit + RX_BUF_SIZE; else - tp->RxDescArray[cur_rx].buf_Len = - RX_BUF_SIZE; + desc->buf_Len = RX_BUF_SIZE; -#warning Replace virt_to_bus with DMA mapping - tp->RxDescArray[cur_rx].buf_addr = - virt_to_bus(tp->RxBufferRing[cur_rx]); dev->last_rx = jiffies; tp->stats.rx_bytes += pkt_size; tp->stats.rx_packets++; - tp->RxDescArray[cur_rx].status = - OWNbit | INTbit; + desc->status = OWNbit | INTbit; } else { printk(KERN_WARNING "%s: Memory squeeze, deferring packet.\n", @@ -1030,7 +1033,7 @@ SiS190_rx_interrupt(struct net_device *d } cur_rx = (cur_rx + 1) % NUM_RX_DESC; - + desc = tp->RxDescArray + cur_rx; } tp->cur_rx = cur_rx; @@ -1114,11 +1117,13 @@ SiS190_close(struct net_device *dev) pci_free_consistent(tp->pci_dev, RX_DESC_TOTAL_SIZE, tp->RxDescArray, tp->rx_dma); tp->TxDescArray = NULL; - tp->RxDescArray = NULL; - kfree(tp->RxBufferRings); for (i = 0; i < NUM_RX_DESC; i++) { + pci_unmap_single(tp->pci_dev, tp->RxDescArray[i].buf_addr, + RX_BUF_SIZE, PCI_DMA_FROMDEVICE); tp->RxBufferRing[i] = NULL; } + tp->RxDescArray = NULL; + kfree(tp->RxBufferRings); return 0; } _ From jgarzik@pobox.com Tue Aug 26 15:24:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Aug 2003 15:24:51 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7QMOloO008646 for ; Tue, 26 Aug 2003 15:24:48 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11]:33672 helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.22) id 19rmF4-0000SK-09; Tue, 26 Aug 2003 23:24:46 +0100 Message-ID: <3F4BDE22.4050309@pobox.com> Date: Tue, 26 Aug 2003 18:24:34 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: Francois Romieu CC: netdev@oss.sgi.com Subject: Re: [patch] 2.6.0-test4 - more sis190 nit I/II References: <20030826205136.GA32063@gtf.org> <20030827000736.A23532@electric-eye.fr.zoreil.com> In-Reply-To: <20030827000736.A23532@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5302 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 thanks, applied. From garzik@gtf.org Tue Aug 26 16:26:08 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Aug 2003 16:26:18 -0700 (PDT) Received: from havoc.gtf.org (havoc.gtf.org [63.247.75.124]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7QNPvoO011596 for ; Tue, 26 Aug 2003 16:25:57 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id 7887F660D; Tue, 26 Aug 2003 18:48:37 -0400 (EDT) Date: Tue, 26 Aug 2003 18:48:37 -0400 From: Jeff Garzik To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Cc: romieu@fr.zoreil.com Subject: [bk patches] 2.5.x net driver queue Message-ID: <20030826224837.GA9628@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: 5303 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 BK users: bk pull bk://kernel.bkbits.net/jgarzik/net-drivers-2.6 Patch users: ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.0-test4-bk2-netdrvr1.patch.bz2 This will update the following files: drivers/net/3c501.c | 91 +------- drivers/net/3c501.h | 2 drivers/net/3c503.c | 71 ------ drivers/net/3c505.c | 96 +------- drivers/net/3c507.c | 97 +------- drivers/net/3c515.c | 94 +------- drivers/net/3c523.c | 73 ------ drivers/net/3c527.c | 94 +------- drivers/net/3c59x.c | 47 +--- drivers/net/8139cp.c | 444 +++++++++++++++------------------------- drivers/net/Kconfig | 2 drivers/net/pcmcia/3c574_cs.c | 28 -- drivers/net/pcmcia/3c589_cs.c | 81 +------ drivers/net/pcmcia/axnet_cs.c | 28 -- drivers/net/pcmcia/fmvj18x_cs.c | 75 +----- drivers/net/pcmcia/ibmtr_cs.c | 35 --- drivers/net/pcmcia/nmclan_cs.c | 77 ++---- drivers/net/pcmcia/pcnet_cs.c | 41 --- drivers/net/pcmcia/xirc2ps_cs.c | 28 -- drivers/net/sis190.c | 157 +++++++------- drivers/net/sis900.c | 43 +-- drivers/net/tulip/dmfe.c | 62 +---- drivers/net/tulip/xircom_cb.c | 38 --- drivers/net/wireless/ray_cs.c | 32 -- 24 files changed, 559 insertions(+), 1277 deletions(-) through these ChangeSets: (03/08/26 1.1306) [netdrvr sis190] remove unneeded alignment code, other small fixes Driver does not need to enforce 256 byte alignment for data returned from pci_alloc_consistent(). - {rx/tx}_dma_aligned and {rx/td}_dma_raw are both replaced by {rx/tx}_dma; - {rx/tx}_desc_raw is replaced by direct use of {Rx/Tx}DescArray; - SiS190_open() + fixup for a lack of kmalloc() failure handling; + (return status) there is no need for both retval/rc: merge them; + anonymous printk() fixup: the name of the guilty device is printed; - define {RX/TX}_DESC_TOTAL_SIZE because I am too lazy to read twice the same lengthy arithmetic expression. (03/08/26 1.1305) [wireless ray_cs] ethtool_ops support (03/08/26 1.1304) [netdrvr xircom_cb] ethtool_ops support Also, export PCI bus id via ETHTOOL_GDRVINFO. (03/08/26 1.1303) [netdrvr pcmcia] convert several drivers to ethtool_ops Drivers updated: fmvj18x_cs, ibmtr_cs, nmclan_cs, pcnet_cs, xirc2ps_cs. (03/08/26 1.1302) [netdrvr pcmcia] ethtool_ops for 3c574, 3c589, axnet (03/08/26 1.1301) [netdrvr] ethtool_ops support for 3c515, 3c523, 3c527, and dmfe (03/08/26 1.1300) [netdrvr] ethtool_ops support in 3c503, 3c505, 3c507 (03/08/26 1.1299) [netdrvr 3c501] ethtool_ops support (03/08/26 1.1298) [netdrvr sis190] make driver depend on CONFIG_BROKEN Until RX path is cleaned up to use PCI DMA API and not virt_to_bus. (03/08/26 1.1297) [netdrvr sis190] convert TX path to use PCI DMA API Also, minor changes: * mark ->hard_start_xmit ETH_ZLEN test as unlikely() * use cpu_to_le32() and le32_to_cpu() in TX path * fix two leak in error path, in ->hard_start_xmit * don't test netif_queue_stopped() in TX completion path, netif_wake_queue() already does that. (03/08/26 1.1296) [netdrvr 8139cp] ethtool_ops support (03/08/26 1.1295) [netdrvr sis900] ethtool_ops support (03/08/26 1.1294) [netdrvr 3c59x] ethtool_ops support (03/08/26 1.1293) [netdrvr sis190] pass irq argument to synchronize_irq() Looks like this driver wasn't tested on SMP :) (03/08/26 1.1292) [netdrvr sis190] fix build with older gcc older gcc's do not support C99/C++ style of variable declarations. From jkenisto@us.ibm.com Tue Aug 26 16:36:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Aug 2003 16:36:51 -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 h7QNadoO012295 for ; Tue, 26 Aug 2003 16:36:46 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h7QNa3RZ491888; Tue, 26 Aug 2003 19:36:03 -0400 Received: from us.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h7QNa1SG280264; Tue, 26 Aug 2003 17:36:02 -0600 Message-ID: <3F4BEE68.A6C862C2@us.ibm.com> Date: Tue, 26 Aug 2003 16:34:00 -0700 From: Jim Keniston X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Greg KH CC: LKML , netdev , Jeff Garzik , "Feldman, Scott" , Larry Kessler , Randy Dunlap , Alan Cox , Andrew Morton Subject: Re: [PATCH 1/4] Net device error logging, revised References: <3F4A8027.6FE3F594@us.ibm.com> <20030826183221.GB3167@kroah.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 5304 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkenisto@us.ibm.com Precedence: bulk X-list: netdev Greg KH wrote: > > On Mon, Aug 25, 2003 at 02:31:19PM -0700, Jim Keniston wrote: > > +int __netdev_printk(const char *sevlevel, const struct net_device *netdev, > > + int msglevel, const char *format, ...) > > +{ > > + if (!netdev || !format) { > > + return -EINVAL; > > + } > > + if (msglevel == NETIF_MSG_ALL || (netdev->msg_enable & msglevel)) { > > + char msg[512]; > > 512 bytes on the stack? Any way to prevent this from happening? With > the push to make the stack even smaller in 2.7, people will not like > this. > > thanks, > > greg k-h The following options come to mind: 1. Keep the msg buffer, but make it smaller. Around 120 bytes would probably be big enough for the vast majority of messages. (printk() uses a 1024-byte buffer, but it's static -- see #2.) 2. Use a big, static buffer, protected by a spinlock. printk() does this. 3. Do the whole thing in a macro, as in previous proposals. The size of the macro expansion could be reduced somewhat by doing the encode-prefix step in a function -- something like: #define netdev_printk(sevlevel, netdev, msglevel, format, arg...) \ do { \ if (NETIF_MSG_##msglevel == NETIF_MSG_ALL || ((netdev)->msg_enable & NETIF_MSG_##msglevel)) { \ char pfx[40]; \ printk(sevlevel "%s: " format , make_netdev_msg_prefix(pfx, netdev) , ## arg); \ }} while (0) This would make your code bigger, but not that much bigger for the common case where the msglevel is omitted (and the 'if(...)' is optimized out). Jim From yoshfuji@linux-ipv6.org Tue Aug 26 16:39:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Aug 2003 16:39:03 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7QNcwoO012824 for ; Tue, 26 Aug 2003 16:38:59 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h7QNdQ1M017249; Wed, 27 Aug 2003 08:39:27 +0900 Date: Wed, 27 Aug 2003 08:39:26 +0900 (JST) Message-Id: <20030827.083926.50662159.yoshfuji@linux-ipv6.org> To: davem@redhat.com CC: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [OOPS] less /proc/net/igmp From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <1061929108.3946.1.camel@spider.hotmonkeyporn.com> References: <20030826.173226.114994096.yoshfuji@linux-ipv6.org> <20030827.015448.70287953.yoshfuji@linux-ipv6.org> <1061929108.3946.1.camel@spider.hotmonkeyporn.com> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 5305 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <1061929108.3946.1.camel@spider.hotmonkeyporn.com> (at 26 Aug 2003 15:18:28 -0500), Owen Ford says: > > > Okay, everyone. I'll try to fix this. > > > > Please try this patch. > > That seems to have done the job nicely. Thanks. Thanks. David, please apply. D: Fixing several refcnt mistakes in seq_file handlers for D: /proc/net/{igmp,igmp6,msfilter,msfilter6}. Thanks in advance. --yoshfuji From shemminger@osdl.org Tue Aug 26 18:06:51 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Aug 2003 18:07:01 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7R16poO024528 for ; Tue, 26 Aug 2003 18:06:51 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7R16go23782; Tue, 26 Aug 2003 18:06:42 -0700 Date: Tue, 26 Aug 2003 18:06:26 -0700 From: Stephen Hemminger To: Jim Keniston Cc: Greg KH , LKML , netdev , Jeff Garzik , "Feldman, Scott" , Larry Kessler , Randy Dunlap , Alan Cox , Andrew Morton Subject: Re: [PATCH 1/4] Net device error logging, revised Message-Id: <20030826180626.50778705.shemminger@osdl.org> In-Reply-To: <3F4BEE68.A6C862C2@us.ibm.com> References: <3F4A8027.6FE3F594@us.ibm.com> <20030826183221.GB3167@kroah.com> <3F4BEE68.A6C862C2@us.ibm.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5307 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1241 Lines: 26 > The following options come to mind: > 1. Keep the msg buffer, but make it smaller. Around 120 bytes would probably be > big enough for the vast majority of messages. (printk() uses a 1024-byte buffer, > but it's static -- see #2.) > > 2. Use a big, static buffer, protected by a spinlock. printk() does this. > > 3. Do the whole thing in a macro, as in previous proposals. The size of the macro > expansion could be reduced somewhat by doing the encode-prefix step in a function -- > something like: > > #define netdev_printk(sevlevel, netdev, msglevel, format, arg...) \ > do { \ > if (NETIF_MSG_##msglevel == NETIF_MSG_ALL || ((netdev)->msg_enable & NETIF_MSG_##msglevel)) { \ > char pfx[40]; \ > printk(sevlevel "%s: " format , make_netdev_msg_prefix(pfx, netdev) , ## arg); \ > }} while (0) > > This would make your code bigger, but not that much bigger for the common case where > the msglevel is omitted (and the 'if(...)' is optimized out). Is there some way to tack copy and prepend what you want onto the format string, and add additional arguments to the call to printk? That way you wouldn't need space for the potentially large resulting string, but only enough room for the expanded format string. From jkenisto@us.ibm.com Tue Aug 26 18:10:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Aug 2003 18:10:30 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7R1AJoO025133 for ; Tue, 26 Aug 2003 18:10:22 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h7R1A1Uj335426; Tue, 26 Aug 2003 21:10:01 -0400 Received: from us.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h7R19xHK187970; Tue, 26 Aug 2003 19:10:00 -0600 Message-ID: <3F4C046D.77CF7E03@us.ibm.com> Date: Tue, 26 Aug 2003 18:07:57 -0700 From: Jim Keniston X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Garzik CC: Greg KH , LKML , netdev , "Feldman, Scott" , Larry Kessler , Randy Dunlap , Alan Cox , Andrew Morton Subject: Re: [PATCH 1/4] Net device error logging, revised References: <3F4A8027.6FE3F594@us.ibm.com> <20030826183221.GB3167@kroah.com> <3F4BEE68.A6C862C2@us.ibm.com> <3F4BF265.5050101@pobox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 5308 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkenisto@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2030 Lines: 48 Jeff Garzik wrote: > > Jim Keniston wrote: > > #define netdev_printk(sevlevel, netdev, msglevel, format, arg...) \ > > do { \ > > if (NETIF_MSG_##msglevel == NETIF_MSG_ALL || ((netdev)->msg_enable & NETIF_MSG_##msglevel)) { \ > > char pfx[40]; \ > > printk(sevlevel "%s: " format , make_netdev_msg_prefix(pfx, netdev) , ## arg); \ > > }} while (0) > > > > This would make your code bigger, but not that much bigger for the common case where > > the msglevel is omitted (and the 'if(...)' is optimized out). > > "NETIF_MSG_" is silly and should be eliminated. From this, I infer that you think that the option to "omit" the msglevel arg -- e.g., netdev_err(dev,, "NIC is fried!\n"); /* always logged */ -- is silly. No big deal. Its sole purpose is to help keep netdev_* calls terse. > A separate "NETIF_MSG_ALL" test is not needed, because msg_enable is a > bitmask. A msg_enable of 0xffffffff will naturally create a NETIF_MSG_ALL. But how do you code a netdev_* call where you ALWAYS want the message (including netdev_printk-style prefix) logged, regardless of the value of msg_enable? That's what NETIF_MSG_ALL is for (and why it might be better called NETIF_MSG_ALWAYS)... netdev_err(dev, ALL, "NIC is fried!\n"); /* always logged */ or netdev_err(dev, ALWAYS, "NIC is fried!\n"); /* always logged */ > > Also, whatever mechanism is created, it needs to preserve the feature of > the existing system: > > if (a quick bitmask test) > do something > > And preferably "do something" is not inlined, because printk'ing -- > although it may appear in a fast path during debugging -- cannot be > considered a fast path itself. > > Jeff Sorry, I'm not sure what you're getting at here. netdev_* doesn't prevent people from using the existing netif_msg_* macros; it just provides shorthand for the (usual) case where "do something" is "printk". Jim From ralph@istop.com Tue Aug 26 20:30:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Aug 2003 20:30:34 -0700 (PDT) Received: from smtp.istop.com (dci.doncaster.on.ca [66.11.168.194]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7R3UKoO003812 for ; Tue, 26 Aug 2003 20:30:21 -0700 Received: from ns.istop.com (ns.istop.com [66.11.168.199]) by smtp.istop.com (Postfix) with ESMTP id A273E369D2 for ; Tue, 26 Aug 2003 23:02:22 -0400 (EDT) Date: Tue, 26 Aug 2003 23:02:22 -0400 (EDT) From: Ralph Doncaster Reply-To: ralph+d@istop.com To: "netdev@oss.sgi.com" Subject: Re: route-cache performance In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5309 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ralph@istop.com Precedence: bulk X-list: netdev Content-Length: 1449 Lines: 31 With my latest testing I'm having problems getting Linux to go under full load generating packets with juno. With just sending I was able to get 330kpps and 0% idle with just one juno thread. I setup a test for routing performance with a routing loop between 2 identical boxes; one running FreeBSD 5.0 and the other running Linux 2.4.22rc2. On my first attempt I forgot to enable polling on the BSD box and caused livelock. On my second attempt (polling enabled) the Linux box was still at 52% idle, even with 4 juno threads. The BSD box was showing 49% idle. The the aggregate throughput of the 4 juno threads was just 92kpps. The linux box was running zebra with full BGP routes (same setup as the test I posted about yesterday). Here's the profile details: 136 raw_getrawfrag 0.6071 73 kfree_skbmem 0.6518 150 skb_release_data 0.9375 48 kmem_cache_free 1.0000 121 __generic_copy_from_user 1.0804 198 eth_type_trans 1.1250 86 system_call 1.5357 177 handle_IRQ_event 1.5804 175 kfree 2.7344 4455 default_idle 69.6094 What changes can I make to max out the Linux box? Ralph Doncaster, IStop.com president 6042147 Canada Inc. From davem@pizda.ninka.net Tue Aug 26 23:13:13 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 26 Aug 2003 23:13:23 -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 h7R6DDoO012829 for ; Tue, 26 Aug 2003 23:13:13 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id XAA21871; Tue, 26 Aug 2003 23:04:55 -0700 Date: Tue, 26 Aug 2003 23:04:55 -0700 From: "David S. Miller" To: Michael Richardson Cc: akpm@osdl.org, netdev@oss.sgi.com, uwe.schmeling@t-online.de Subject: Re: Fw: [Bugme-new] [Bug 1148] New: when using ipsec with DSL connections communication will hang if mtu is 1500(the default value) Message-Id: <20030826230455.70059a69.davem@redhat.com> In-Reply-To: <20709.1061931582@marajade.sandelman.ottawa.on.ca> References: <20030826003949.78ea3d07.akpm@osdl.org> <20709.1061931582@marajade.sandelman.ottawa.on.ca> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5310 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 Content-Length: 261 Lines: 7 On Tue, 26 Aug 2003 16:59:42 -0400 Michael Richardson wrote: > This sure sounds like a classif pmtud blackhole problem. Regardless of his configuration, we don't propagate PMTU's over tunneled IPSEC connections properly at all. From jgarzik@pobox.com Wed Aug 27 00:53:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Aug 2003 00:54:11 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7R7qmoO016511 for ; Wed, 27 Aug 2003 00:53:29 -0700 Received: from rdu26-227-011.nc.rr.com ([66.26.227.11]:33727 helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.22) id 19rnal-0001XK-Tf; Wed, 27 Aug 2003 00:51:16 +0100 Message-ID: <3F4BF265.5050101@pobox.com> Date: Tue, 26 Aug 2003 19:51:01 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: Jim Keniston CC: Greg KH , LKML , netdev , "Feldman, Scott" , Larry Kessler , Randy Dunlap , Alan Cox , Andrew Morton Subject: Re: [PATCH 1/4] Net device error logging, revised References: <3F4A8027.6FE3F594@us.ibm.com> <20030826183221.GB3167@kroah.com> <3F4BEE68.A6C862C2@us.ibm.com> In-Reply-To: <3F4BEE68.A6C862C2@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5312 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 Content-Length: 1000 Lines: 30 Jim Keniston wrote: > #define netdev_printk(sevlevel, netdev, msglevel, format, arg...) \ > do { \ > if (NETIF_MSG_##msglevel == NETIF_MSG_ALL || ((netdev)->msg_enable & NETIF_MSG_##msglevel)) { \ > char pfx[40]; \ > printk(sevlevel "%s: " format , make_netdev_msg_prefix(pfx, netdev) , ## arg); \ > }} while (0) > > This would make your code bigger, but not that much bigger for the common case where > the msglevel is omitted (and the 'if(...)' is optimized out). "NETIF_MSG_" is silly and should be eliminated. A separate "NETIF_MSG_ALL" test is not needed, because msg_enable is a bitmask. A msg_enable of 0xffffffff will naturally create a NETIF_MSG_ALL. Also, whatever mechanism is created, it needs to preserve the feature of the existing system: if (a quick bitmask test) do something And preferably "do something" is not inlined, because printk'ing -- although it may appear in a fast path during debugging -- cannot be considered a fast path itself. Jeff From davem@pizda.ninka.net Wed Aug 27 04:30:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Aug 2003 04:31: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 h7RBTroO024261 for ; Wed, 27 Aug 2003 04:30:33 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id EAA22767; Wed, 27 Aug 2003 04:20:36 -0700 Date: Wed, 27 Aug 2003 04:20:36 -0700 From: "David S. Miller" To: Ville Nuorvala Cc: usagi-core@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [PATCH] IPv6: Allow nested IPv6 encapsulations on same node Message-Id: <20030827042036.3a00aca8.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5313 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 Content-Length: 403 Lines: 10 On Wed, 27 Aug 2003 14:26:42 +0300 (EEST) Ville Nuorvala wrote: > this incremental patch allows nested IPv6 encapsulations on the same node > by allocating separate sockets for all ip6_tnl devices. Please apply! If you didn't use sockets to send the packets out, you wouldn't have this problem to begin with. Why do you need to use sockets? Just send the packets out normally. From davem@pizda.ninka.net Wed Aug 27 06:55:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Aug 2003 06:55:50 -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 h7RDsZoO029343 for ; Wed, 27 Aug 2003 06:55:16 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id GAA23158; Wed, 27 Aug 2003 06:45:14 -0700 Date: Wed, 27 Aug 2003 06:45:14 -0700 From: "David S. Miller" To: Ville Nuorvala Cc: usagi-core@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [PATCH] IPv6: Allow nested IPv6 encapsulations on same node Message-Id: <20030827064514.7c060a64.davem@redhat.com> In-Reply-To: References: <20030827042036.3a00aca8.davem@redhat.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5314 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 27 Aug 2003 16:22:38 +0300 (EEST) Ville Nuorvala wrote: > On Wed, 27 Aug 2003, David S. Miller wrote: > > Why do you need to use sockets? Just send the packets out normally. > > Well ok, I don't need to use sockets, but I do need to use socks :) You don't need socks either. Using sockets is just a waste of memory, and you're only using them because of an interface problem. Do you see what I'm trying to say? From cloos@jhcloos.com Wed Aug 27 07:56:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Aug 2003 07:56:30 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [64.240.156.239]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7REtgoO003804 for ; Wed, 27 Aug 2003 07:56:23 -0700 Received: from lugabout.jhcloos.org (ppp4.pm3-12.buf-ch.ny.localnet.com [207.251.211.196]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "lugabout.jhcloos.org", Issuer "ca.jhcloos.com" (verified OK)) by ore.jhcloos.com (Postfix) with ESMTP id 0256E1C595 for ; Wed, 27 Aug 2003 09:55:34 -0500 (CDT) Received: from lugabout.jhcloos.org (localhost [127.0.0.1]) by lugabout.jhcloos.org (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id 37EDF25AA6 for ; Wed, 27 Aug 2003 08:36:48 +0000 (GMT) Resent-To: netdev@oss.sgi.com Resent-From: "James H. Cloos Jr." Resent-Message-ID: Resent-Date: 27 Aug 2003 04:36:46 -0400 X-From-Line: cloos@jhcloos.com Wed Aug 27 05:41:56 2003 X-Original-To: cloos@jhcloos.com Delivered-To: cloos@localhost.jhcloos.org Received: from lugabout.jhcloos.org (localhost [127.0.0.1]) by lugabout.jhcloos.org (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id 02B4B25AA6 for ; Wed, 27 Aug 2003 05:41:54 +0000 (GMT) To: "James H. Cloos Jr." Subject: Re: tcp socket missing from /proc/net/tcp References: From: "James H. Cloos Jr." In-Reply-To: Date: 27 Aug 2003 01:41:53 -0400 Message-ID: Lines: 11 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 5315 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cloos@jhcloos.com Precedence: bulk X-list: netdev A further update: The socket does not need to be open when sit1 is taked down; I've a rsync now that is showing the same symptom, but was started well after a 'ifconfig sit1 down'. After an ssh occured and closed, the rsync started showing up. Perhaps there is an off-by-one error? -JimC From willy@www.linux.org.uk Wed Aug 27 08:56:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Aug 2003 08:57:19 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7RFu3oO005353 for ; Wed, 27 Aug 2003 08:56:44 -0700 Received: from willy by www.linux.org.uk with local (Exim 4.22) id 19s2eQ-0006Pk-9a; Wed, 27 Aug 2003 16:56:02 +0100 Date: Wed, 27 Aug 2003 16:56:02 +0100 From: Matthew Wilcox To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] ethtool_ops bug Message-ID: <20030827155602.GD22294@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 5316 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@debian.org Precedence: bulk X-list: netdev C's switch statements need breaks. I know that. Index: net/core/ethtool.c =================================================================== RCS file: /var/cvs/linux-2.6/net/core/ethtool.c,v retrieving revision 1.1 diff -u -p -r1.1 ethtool.c --- net/core/ethtool.c 23 Aug 2003 02:47:29 -0000 1.1 +++ net/core/ethtool.c 27 Aug 2003 15:55:03 -0000 @@ -502,15 +502,15 @@ static int ethtool_get_strings(struct ne switch (gstrings.string_set) { case ETH_SS_TEST: - if (ops->self_test_count) - gstrings.len = ops->self_test_count(dev); - else + if (!ops->self_test_count) return -EOPNOTSUPP; + gstrings.len = ops->self_test_count(dev); + break; case ETH_SS_STATS: - if (ops->get_stats_count) - gstrings.len = ops->get_stats_count(dev); - else + if (!ops->get_stats_count) return -EOPNOTSUPP; + gstrings.len = ops->get_stats_count(dev); + break; default: return -EINVAL; } -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk From Robert.Olsson@data.slu.se Wed Aug 27 09:03:13 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Aug 2003 09:03:20 -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 h7RG2VoO005789 for ; Wed, 27 Aug 2003 09:03:13 -0700 Received: (from robert@localhost) by robur.slu.se (8.9.3p2/8.9.3) id SAA07780; Wed, 27 Aug 2003 18:02:14 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16204.54790.564102.63649@robur.slu.se> Date: Wed, 27 Aug 2003 18:02:14 +0200 To: ralph+d@istop.com Cc: "netdev@oss.sgi.com" Subject: Re: route-cache performance In-Reply-To: References: X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 5317 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 Hello! Ralph Doncaster writes: > Here's the profile details: You should see the fib/hash functions in your profile. Below is oprofile on 2.6 during DoS. About 110 kpps throughput. Cpu type: P4 / Xeon Cpu speed was (MHz estimation) : 1800.98 Counter 0 counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped) with a unit mask of 0x01 (count cycles when processor is active) count 180000 vma samples % symbol name c0247fc8 95046 30.6702 fn_hash_lookup c021bd30 23382 7.54509 ip_route_input c01329bc 14384 4.64154 free_block c021b590 13912 4.48923 ip_route_input_slow c0132b14 11488 3.70704 kmem_cache_alloc c01be81c 10614 3.42501 e1000_clean_rx_irq c0216078 9394 3.03133 eth_type_trans c021a218 7662 2.47243 rt_intern_hash c0220348 6720 2.16846 ip_output c021cebc 6552 2.11425 dst_free c020ba20 6128 1.97743 skb_release_data c012619c 5871 1.8945 rcu_do_batch c020b8e0 5734 1.85029 alloc_skb c0132bf0 4887 1.57698 kfree c0211a28 4446 1.43467 dst_alloc c01bebf0 4338 1.39982 e1000_alloc_rx_buffers c0215f10 4228 1.36432 eth_header c0132804 4222 1.36239 cache_alloc_refill c01bd778 4213 1.35948 e1000_xmit_frame c0212080 4136 1.33464 neigh_lookup c01be674 3947 1.27365 e1000_clean_tx_irq c0132bb4 3823 1.23364 kmem_cache_free c02465bc 3631 1.17168 fib_validate_source c0219950 3178 1.0255 rt_hash_code c020bb28 2962 0.955801 __kfree_skb c021b26c 2944 0.949993 rt_set_nexthop Cheers. --ro From shmulik.hen@intel.com Wed Aug 27 09:59:42 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Aug 2003 10:00:16 -0700 (PDT) Received: from hermes.py.intel.com (hermes.py.intel.com [146.152.216.3]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7RGx1oO008979 for ; Wed, 27 Aug 2003 09:59:42 -0700 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.76 2003/08/21 22:58:26 rfjohns1 Exp $) with ESMTP id h7RGsOw02357 for ; Wed, 27 Aug 2003 16:54:24 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.py.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 h7RGwot27497 for ; Wed, 27 Aug 2003 16:58:51 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.254.188]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003082709585205331 ; Wed, 27 Aug 2003 09:58:53 -0700 Content-Type: text/plain; charset="us-ascii" From: Shmulik Hen Reply-To: shmulik.hen@intel.com Organization: Intel corp. To: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: [bonding][0/3] Synchronizing 2.4-2.6 Date: Wed, 27 Aug 2003 19:58:52 +0300 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200308271958.52063.shmulik.hen@intel.com> X-archive-position: 5318 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Hi, The following 3 patch sets are meant to get bonding in 2.4 and 2.6 synchronized. I'm sending the sets again, this time diff'd against the freshly release 2.4.22, in order to include bug fixes that we realready accepted. The 3 sets are not independent and each one relies on the application of the previous. Once all sets are accepted, all bonding related files can be copied as is from 2.4 to 2.6 and get both versions to match. o Set 1 handles back porting new stuff from 2.6 into 2.4 while fixing some implementation bugs. o Set 2 merges stuff from Jay Vosburgh's 5/22 experimental release for propagating settings from the bond to its slaves with our enhancements and fixes. o Set 3 is a wholesale cleanup of the bonding code. Next in store are: o Stephen Hemminger's converting bonding driver /proc interface to seq_file, along with changing /proc/bond0/info to /proc/bonding/bond0 o cleanup of the 802.3ad code (was not included in this release since it requires some code re-factoring first). o lots of new stuff :) -- | Shmulik Hen Advanced Network Services | | Israel Design Center, Jerusalem | | LAN Access Division, Platform Networking | | Intel Communications Group, Intel corp. | From shmulik.hen@intel.com Wed Aug 27 10:01:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Aug 2003 10:02:02 -0700 (PDT) Received: from hermes.py.intel.com (hermes.py.intel.com [146.152.216.3]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7RH0moO009112 for ; Wed, 27 Aug 2003 10:01:29 -0700 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.76 2003/08/21 22:58:26 rfjohns1 Exp $) with ESMTP id h7RGuBw03456 for ; Wed, 27 Aug 2003 16:56:11 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.py.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 h7RH0bt28531 for ; Wed, 27 Aug 2003 17:00:37 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.254.188]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003082710003900674 ; Wed, 27 Aug 2003 10:00:40 -0700 Content-Type: text/plain; charset="us-ascii" From: Shmulik Hen Reply-To: shmulik.hen@intel.com Organization: Intel corp. To: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: [bonding][1/3] Synchronizing 2.4-2.6 Date: Wed, 27 Aug 2003 20:00:39 +0300 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200308272000.39229.shmulik.hen@intel.com> X-archive-position: 5319 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev This is set 1 that handles backporting bonding stuff from 2.6 into 2.4 while fixing some implementation bugs. Applies on 2.4.22. patch set can be downloaded from: http://osdn.dl.sourceforge.net/sourceforge/bonding/patch_set_1_backport.tar.bz2 This will update the following files: Documentation/networking/ifenslave.c drivers/net/bonding/bonding.h drivers/net/bonding/bond_main.c drivers/net/net_init.c include/linux/list.h include/linux/netdevice.h Description: patch 1 - Add list_for_each_entry_safe() patch 2 - Export alloc_netdev() patch 3 - Fix /proc read function patch 4 - Put the bond's net_device_stats inside the bond struct patch 5 - Use a linked list to handle multiple bond devices patch 6 - Update versions/contributions in header and bump version -- | Shmulik Hen Advanced Network Services | | Israel Design Center, Jerusalem | | LAN Access Division, Platform Networking | | Intel Communications Group, Intel corp. | From shmulik.hen@intel.com Wed Aug 27 10:04:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Aug 2003 10:04:57 -0700 (PDT) Received: from hermes.py.intel.com (hermes.py.intel.com [146.152.216.3]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7RH3ioO009709 for ; Wed, 27 Aug 2003 10:04:25 -0700 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.76 2003/08/21 22:58:26 rfjohns1 Exp $) with ESMTP id h7RGx7w05395 for ; Wed, 27 Aug 2003 16:59:07 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.py.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 h7RH3Wt00455 for ; Wed, 27 Aug 2003 17:03:33 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.254.188]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003082710032222323 ; Wed, 27 Aug 2003 10:03:25 -0700 Content-Type: text/plain; charset="us-ascii" From: Shmulik Hen Reply-To: shmulik.hen@intel.com Organization: Intel corp. To: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: [bonding][2/3] Synchronizing 2.4-2.6 Date: Wed, 27 Aug 2003 20:03:09 +0300 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200308272003.09957.shmulik.hen@intel.com> X-archive-position: 5320 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev This is set 2 that merges parts of Jay Vosburgh's experimental propagation stuff from 5/22 with all the fixes/enhancements we've developed according to the RFC published on bond-devel list on 6/2. Applies on 2.4.22. Assumes patch set 1 was already applied. patch set can be downloaded from: http://osdn.dl.sourceforge.net/sourceforge/bonding/patch_set_2_propagation.tar.bz2 This will update the following files: drivers/net/bonding/bond_alb.c drivers/net/bonding/bond_alb.h drivers/net/bonding/bonding.h drivers/net/bonding/bond_main.c Description: patch 1 - Distinguish between modes that use a primary slave from those that don't, and propagate settings accordingly; Consolidate change_active opeartions and add reselect_active and find_best opeartions. patch 2 - Change monitoring function use the above functionality. patch 3 - Modes that don't use primary don't use the above functionality. patch 4 - Decouple promiscuous handling from the multicast mode setting. patch 5 - Add support for changing HW address and MTU with proper unwind in old modes. patch 6 - Same thing for ALB/TLB modes. patch 7 - Consolidate /proc code, add CHANGENAME handler patch 8 - Enhance netdev notification handling. Add comment block and bump version. -- | Shmulik Hen Advanced Network Services | | Israel Design Center, Jerusalem | | LAN Access Division, Platform Networking | | Intel Communications Group, Intel corp. | From shmulik.hen@intel.com Wed Aug 27 10:09:10 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Aug 2003 10:09:12 -0700 (PDT) Received: from hermes.py.intel.com (hermes.py.intel.com [146.152.216.3]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7RH8ToO010491 for ; Wed, 27 Aug 2003 10:09:09 -0700 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.76 2003/08/21 22:58:26 rfjohns1 Exp $) with ESMTP id h7RH3pw08011 for ; Wed, 27 Aug 2003 17:03:51 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.py.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 h7RH8It03004 for ; Wed, 27 Aug 2003 17:08:18 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.254.188]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003082710082018767 ; Wed, 27 Aug 2003 10:08:21 -0700 Content-Type: text/plain; charset="us-ascii" From: Shmulik Hen Reply-To: shmulik.hen@intel.com Organization: Intel corp. To: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: [bonding][3/3] Synchronizing 2.4-2.6 Date: Wed, 27 Aug 2003 20:08:20 +0300 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200308272008.20139.shmulik.hen@intel.com> X-archive-position: 5321 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev From another mail from Jay Vosburgh: > > This sort of wholesale cleanup is something I've been > itching to do for a long time, but never had the time for. I'm all > in favor of it in general; I'll have to see what I think about all > of the specific changes after I look through the rest of the > patches. In general, the bonding source has gotten fairly messy > and hard to follow, so I think cleanup is needed. > This is set 3 - the wholesale cleanup. It's a re-send, only it was divided into smaller change sets to make them more readable and smaller in size. A few new things were added as well. Applies on 2.4.22. Assumes patch set 2 was already applied. patch set can be downloaded from: http://osdn.dl.sourceforge.net/sourceforge/bonding/patch_set_3_cleanup.tar.bz2 This will update the following files: Documentation/networking/bonding.txt Documentation/networking/ifenslave.c drivers/net/bonding/bond_3ad.c drivers/net/bonding/bond_alb.c drivers/net/bonding/bond_alb.h drivers/net/bonding/bonding.h drivers/net/bonding/bond_main.c include/linux/if_bonding.h Description: patch 1 - ifenslave.c lite - no more IP settings + code re-org. patch 2 - convert all debug prints to use the dprintk macro and consolidate format of all prints (e.g. "bonding: Error: ..."). patch 3 - death of typedef. eliminate bonding_t/slave_t and consolidate casting. patch 4 - remove dead code and redundant checks. add a few new checks where needed. patch 5 - consolidate timers initialization, error checking and re-queuing. patch 6 - convert too long if-else to a switch-case. Fix all locations that handles bond->primary. patch 7 - eliminate the multicast_more module param and use the USES_PRIMARY macro instead. patch 8 - consolidate slave list iterations. patch 9 - consolidate function declarations: o all functions begin with bond_ o return value, function name and all params are on the same line. patch 10 - consolidate names of function params and variables (e.g. bond_dev instead of dev|master|master_dev). patch 11 - change names for a few of the members of struct bonding. patch 12 - consolidate return values of functions. patch 13 - put curly braces around all if, else, for, while, switch statements. consolidate if conditions e.g. (ptr == NULL) --> (!ptr) patch 14 - chomp all trailing white space. patch 15 - remove duplicate empty lines. add empty lines to improve readability. patch 16 - fix indentations. patch 17 - code re-organization in bond_main.c according to context (e.g. module initialization, bond initialization, device entry points, monitoring, etc.). it just looks unreadable, but in fact its very simple :) -- | Shmulik Hen Advanced Network Services | | Israel Design Center, Jerusalem | | LAN Access Division, Platform Networking | | Intel Communications Group, Intel corp. | From jgarzik@pobox.com Wed Aug 27 14:56:39 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Aug 2003 14:57:11 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7RLtvoO020301 for ; Wed, 27 Aug 2003 14:56:38 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:32798 helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.22) id 19s8Gj-0008CT-1N; Wed, 27 Aug 2003 22:55:57 +0100 Message-ID: <3F4D28E2.6070905@pobox.com> Date: Wed, 27 Aug 2003 17:55:46 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: Matthew Wilcox CC: netdev@oss.sgi.com Subject: Re: [PATCH] ethtool_ops bug References: <20030827155602.GD22294@parcelfarce.linux.theplanet.co.uk> In-Reply-To: <20030827155602.GD22294@parcelfarce.linux.theplanet.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5322 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 thanks, applied to 2.4 and 2.6 From jgarzik@pobox.com Wed Aug 27 15:23:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Aug 2003 15:24:03 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7RMMloO021165 for ; Wed, 27 Aug 2003 15:23:28 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:32807 helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.22) id 19s8gg-0008U2-H3; Wed, 27 Aug 2003 23:22:46 +0100 Message-ID: <3F4D2F2B.2090401@pobox.com> Date: Wed, 27 Aug 2003 18:22:35 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: Maillist netdev CC: davem@redhat.com Subject: ethtool_features? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5323 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 Hum. Instead of adding all these _get_foo ops to test dev->features bits, would anyone mind if I created a single _get_features() ethtool sub-ioctl? Given the current ethtool_ops code, its implementation would in fact be completely transparent to low-level drivers. It need only be implemented in net/core/ethtool.c, without even adding a new hook. Jeff From garzik@gtf.org Wed Aug 27 15:28:48 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Aug 2003 15:29:23 -0700 (PDT) Received: from havoc.gtf.org (havoc.gtf.org [63.247.75.124]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7RMS5oO021550 for ; Wed, 27 Aug 2003 15:28:46 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id 6685E666D; Wed, 27 Aug 2003 18:27:55 -0400 (EDT) Date: Wed, 27 Aug 2003 18:27:55 -0400 From: Jeff Garzik To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [bk patches] 2.6.x net driver queue Message-ID: <20030827222755.GA10445@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: 5324 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 Here's the pile waiting for Linus, so far. BK users: bk pull bk://kernel.bkbits.net/jgarzik/net-drivers-2.6 or bk pull http://gkernel.bkbits.net/net-drivers-2.6 Patch users: ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.0-test4-bk2-netdrvr2.patch.bz2 This will update the following files: drivers/net/3c501.c | 91 ---- drivers/net/3c501.h | 2 drivers/net/3c503.c | 71 --- drivers/net/3c505.c | 96 +--- drivers/net/3c507.c | 97 +---- drivers/net/3c515.c | 94 ---- drivers/net/3c523.c | 73 --- drivers/net/3c527.c | 94 ---- drivers/net/3c59x.c | 47 -- drivers/net/8139cp.c | 444 +++++++++-------------- drivers/net/8139too.c | 391 +++++++------------- drivers/net/Kconfig | 4 drivers/net/pcmcia/3c574_cs.c | 28 - drivers/net/pcmcia/3c589_cs.c | 81 +--- drivers/net/pcmcia/axnet_cs.c | 28 - drivers/net/pcmcia/fmvj18x_cs.c | 75 +-- drivers/net/pcmcia/ibmtr_cs.c | 35 - drivers/net/pcmcia/nmclan_cs.c | 77 +-- drivers/net/pcmcia/pcnet_cs.c | 41 -- drivers/net/pcmcia/xirc2ps_cs.c | 28 - drivers/net/sis190.c | 221 ++++++----- drivers/net/sis900.c | 62 +-- drivers/net/tulip/dmfe.c | 62 --- drivers/net/tulip/xircom_cb.c | 38 - drivers/net/wireless/airo.c | 772 +++++++++++++++++++++++++++++++++------- drivers/net/wireless/ray_cs.c | 32 - net/core/ethtool.c | 12 27 files changed, 1398 insertions(+), 1698 deletions(-) through these ChangeSets: (03/08/27 1.1316) [netdrvr sis190] use PCI DMA API for RX buffers Missing pieces for DMA-API on the Rx side: - SiS190_init_ring: the global area for the received data is mapped. This area is persistent during the whole driver's life. It only needs to be unmapped in SiS190_close() as no other exit/error path exists. - SiS190_rx_interrupt: no map/unmap for received data buffer. A single sync operation is done. Btw, there is no need to store the same value in RxDescArray[cur_rx].buf_addr over and over again. - Remove driver dependancy on CONFIG_BROKEN. (03/08/27 1.1315) [netdrvr 8139too] ethtool_ops support (03/08/27 1.1314) [ethtool] fix ethtool_get_strings counting bug (03/08/26 1.1313) [netdrvr sis190] small bug fixes * call pci_set_dma_mask * remove erroneous call to unregister_netdev in _init_board() (03/08/26 1.1312) [wireless airo] add support for MIC and latest firmwares (03/08/26 1.1311) [netdrvr sis900] don't call pci_find_device from irq context I realized that I've had this patch in my tree for a while, and forgot to send it to you and lkml. The patch below fixes bug number 923: http://bugme.osdl.org/show_bug.cgi?id=923 (basically keeps us from calling pci_find_device from interrupt context.) It's been tested by a few people with this device, and they say it works just fine for them. Please forward it on up the food chain. (03/08/26 1.1310) [netdrvr 8139too] add more h/w revision ids (03/08/26 1.1309) [netdrvr 8139too] remove unused RxConfigMask (03/08/26 1.1308) [netdrvr 8139too] lwake unlock fix (03/08/26 1.1307) [netdrvr 8139too] use mii_check_media lib function, instead of homebrew MII bitbanging. (03/08/26 1.1306) [netdrvr sis190] remove unneeded alignment code, other small fixes Driver does not need to enforce 256 byte alignment for data returned from pci_alloc_consistent(). - {rx/tx}_dma_aligned and {rx/td}_dma_raw are both replaced by {rx/tx}_dma; - {rx/tx}_desc_raw is replaced by direct use of {Rx/Tx}DescArray; - SiS190_open() + fixup for a lack of kmalloc() failure handling; + (return status) there is no need for both retval/rc: merge them; + anonymous printk() fixup: the name of the guilty device is printed; - define {RX/TX}_DESC_TOTAL_SIZE because I am too lazy to read twice the same lengthy arithmetic expression. (03/08/26 1.1305) [wireless ray_cs] ethtool_ops support (03/08/26 1.1304) [netdrvr xircom_cb] ethtool_ops support Also, export PCI bus id via ETHTOOL_GDRVINFO. (03/08/26 1.1303) [netdrvr pcmcia] convert several drivers to ethtool_ops Drivers updated: fmvj18x_cs, ibmtr_cs, nmclan_cs, pcnet_cs, xirc2ps_cs. (03/08/26 1.1302) [netdrvr pcmcia] ethtool_ops for 3c574, 3c589, axnet (03/08/26 1.1301) [netdrvr] ethtool_ops support for 3c515, 3c523, 3c527, and dmfe (03/08/26 1.1300) [netdrvr] ethtool_ops support in 3c503, 3c505, 3c507 (03/08/26 1.1299) [netdrvr 3c501] ethtool_ops support (03/08/26 1.1298) [netdrvr sis190] make driver depend on CONFIG_BROKEN Until RX path is cleaned up to use PCI DMA API and not virt_to_bus. (03/08/26 1.1297) [netdrvr sis190] convert TX path to use PCI DMA API Also, minor changes: * mark ->hard_start_xmit ETH_ZLEN test as unlikely() * use cpu_to_le32() and le32_to_cpu() in TX path * fix two leak in error path, in ->hard_start_xmit * don't test netif_queue_stopped() in TX completion path, netif_wake_queue() already does that. (03/08/26 1.1296) [netdrvr 8139cp] ethtool_ops support (03/08/26 1.1295) [netdrvr sis900] ethtool_ops support (03/08/26 1.1294) [netdrvr 3c59x] ethtool_ops support (03/08/26 1.1293) [netdrvr sis190] pass irq argument to synchronize_irq() Looks like this driver wasn't tested on SMP :) (03/08/26 1.1292) [netdrvr sis190] fix build with older gcc older gcc's do not support C99/C++ style of variable declarations. From garzik@gtf.org Wed Aug 27 15:43:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Aug 2003 15:44:27 -0700 (PDT) Received: from havoc.gtf.org (havoc.gtf.org [63.247.75.124]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7RMh9oO022174 for ; Wed, 27 Aug 2003 15:43:50 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id 24012666D; Wed, 27 Aug 2003 18:43:04 -0400 (EDT) Date: Wed, 27 Aug 2003 18:43:04 -0400 From: Jeff Garzik To: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [patch] 2.4.x net driver queue Message-ID: <20030827224304.GA11863@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: 5325 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 So that I may synchronize with a few folks, here is the current net driver queue for 2.4.x. A fair chunk of the older commits have been submitted to Marcelo. BK users: Outta luck until M pulls previous batch :) Patch users: ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.4/2.4.23-pre1-netdrvr1.patch.bz2 This will update the following files: Documentation/networking/ifenslave.c | 1 drivers/net/3c501.c | 93 -- drivers/net/3c503.c | 71 - drivers/net/3c505.c | 92 -- drivers/net/3c507.c | 97 -- drivers/net/3c515.c | 94 -- drivers/net/3c523.c | 73 - drivers/net/3c527.c | 94 -- drivers/net/3c59x.c | 50 - drivers/net/8139cp.c | 472 ++++------- drivers/net/8139too.c | 424 ++++------ drivers/net/bonding/bond_alb.c | 144 +++ drivers/net/bonding/bond_alb.h | 8 drivers/net/bonding/bond_main.c | 1416 ++++++++++++++++++++--------------- drivers/net/bonding/bonding.h | 3 drivers/net/dmfe.c | 61 - drivers/net/pcmcia/3c574_cs.c | 30 drivers/net/pcmcia/3c589_cs.c | 83 -- drivers/net/pcmcia/aironet4500_cs.c | 76 - drivers/net/pcmcia/axnet_cs.c | 31 drivers/net/pcmcia/fmvj18x_cs.c | 75 - drivers/net/pcmcia/ibmtr_cs.c | 35 drivers/net/pcmcia/netwave_cs.c | 69 - drivers/net/pcmcia/nmclan_cs.c | 77 - drivers/net/pcmcia/pcnet_cs.c | 43 - drivers/net/pcmcia/ray_cs.c | 32 drivers/net/pcmcia/wavelan_cs.c | 30 drivers/net/pcmcia/xirc2ps_cs.c | 28 drivers/net/pcmcia/xircom_cb.c | 38 drivers/net/sis900.c | 72 - drivers/net/wireless/airo.c | 753 +++++++++++++++--- include/linux/list.h | 13 include/linux/netdevice.h | 4 net/core/ethtool.c | 12 34 files changed, 2346 insertions(+), 2348 deletions(-) through these ChangeSets: (03/08/27 1.1107) [netdrvr 8139too] ethtool_ops support (03/08/27 1.1106) [ethtool] fix ethtool_get_strings counting bug (03/08/27 1.1105) [netdrvr bonding] Enhance netdev notification handling. Also, add comment block and bump version. (03/08/27 1.1104) [netdrvr bonding] Consolidate /proc code, add CHANGENAME handler (03/08/27 1.1103) [netdrvr bonding] support for changing MAC addr, MTU in ALB/TLB modes (03/08/27 1.1102) [netdrvr bonding] support for changing HW address and MTU (03/08/27 1.1101) [netdrvr bonding] Decouple promiscuous handling from the multicast mode setting. (03/08/27 1.1100) [netdrvr bonding] Modes that don't use primary don't use the new prop. code (03/08/27 1.1099) [netdrvr bonding] Change monitoring function to use new slave setting propagation (03/08/27 1.1098) [netdrvr bonding] update slave setting propagation Distinguish between modes that use a primary slave from those that don't, and propagate settings accordingly; Consolidate change_active opeartions and add reselect_active and find_best opeartions. (03/08/27 1.1097) [netdrvr bonding] add another ifenslave.c include (03/08/27 1.1096) [netdrvr bonding] update credits/version (03/08/27 1.1095) [netdrvr bonding] use linked list to handle multiple bond devices (03/08/27 1.1094) [netdrvr bonding] fix /proc read function (03/08/27 1.1093) [list] backport list_for_each_entry_safe macro from 2.6 (03/08/26 1.1091) [wireless airo] build fixes (03/08/26 1.1090) [wireless airo] add support for MIC and latest firmwares (03/08/26 1.1089) [netdrvr sis900] don't call pci_find_device from irq context I realized that I've had this patch in my tree for a while, and forgot to send it to you and lkml. The patch below fixes bug number 923: http://bugme.osdl.org/show_bug.cgi?id=923 (basically keeps us from calling pci_find_device from interrupt context.) It's been tested by a few people with this device, and they say it works just fine for them. Please forward it on up the food chain. (03/08/26 1.1088) [netdrvr 8139too] add more h/w revision ids (03/08/26 1.1087) [netdrvr 8139too] remove unused RxConfigMask (03/08/26 1.1086) [netdrvr 8139too] lwake unlock fix (03/08/26 1.1085) [netdrvr 8139too] use mii_check_media lib function, instead of homebrew MII bitbanging. (03/08/26 1.1076.1.14) [netdrvr 8139too] minor bits from 2.6 Keeping the driver in sync to ease maintenance headaches. (03/08/26 1.1076.1.13) [netdrvr pcmcia] ethtool_ops support for several more pcmcia drivers Drivers updated: fmvj18x_cs, ibmtr_cs, netwave_cs, nmclan_cs, pcnet_cs, ray_cs, wavelan_cs, xirc2ps_cs, xircom_cb. (03/08/26 1.1076.1.12) [netdrvr pcmcia] use SET_ETHTOOL_OPS in 3c574, 3c589, aironet4500, and axnet (03/08/26 1.1076.1.11) [NET] add SET_ETHTOOL_OPS back-compat hook (03/08/26 1.1076.1.10) [netdrvr pcmcia] ethtool_ops for 3c574, 3c589, aironet4500, axnet (03/08/26 1.1076.1.9) [netdrvr] ethtool_ops support for 3c515, 3c523, 3c527, and dmfe (03/08/26 1.1076.1.8) [netdrvr] ethtool_ops support in 3c503, 3c505, 3c507 (03/08/26 1.1076.1.7) [netdrvr 3c501] ethtool_ops support (03/08/26 1.1076.1.6) [netdrvr 3c59x] add a piece missed in previous ethtool_ops patch Contributed by Matthew Wilcox. (03/08/26 1.1076.1.5) [netdrvr 8139cp] ethtool_ops support (03/08/26 1.1076.1.4) [netdrvr 8139cp] minor bits from 2.6 (03/08/26 1.1076.1.3) [netdrvr sis900] minor bits from 2.6 (03/08/26 1.1076.1.2) [netdrvr sis900] ethtool_ops support (03/08/26 1.1076.1.1) [netdrvr 3c59x] ethtool_ops support From jgarzik@pobox.com Wed Aug 27 15:57:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Aug 2003 15:58:09 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7RMusoO023135 for ; Wed, 27 Aug 2003 15:57:35 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:32797 helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.22) id 19s8Cw-0008A7-W6; Wed, 27 Aug 2003 22:52:03 +0100 Message-ID: <3F4D27F8.9050500@pobox.com> Date: Wed, 27 Aug 2003 17:51:52 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: shmulik.hen@intel.com CC: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [bonding][2/3] Synchronizing 2.4-2.6 References: <200308272003.09957.shmulik.hen@intel.com> In-Reply-To: <200308272003.09957.shmulik.hen@intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5326 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 Shmulik Hen wrote: > This is set 2 that merges parts of Jay Vosburgh's experimental > propagation stuff from 5/22 with all the fixes/enhancements > we've developed according to the RFC published on bond-devel > list on 6/2. > > Applies on 2.4.22. Assumes patch set 1 was already applied. As Jay mentioned he had approved through the end of set 2, and set 2 looks good to me, I applied all 8 patches to 2.4. Let's now take an operational pause in 2.4, and get 2.6 back into sync. Would some hearty bonding team member(s) be willing to do that? I would _really_ prefer that the revision history be maintained, which makes it a non-trivial exercise, time-wise... Jeff From shemminger@osdl.org Wed Aug 27 16:43:43 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Aug 2003 16:44:16 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7RNhgWZ024482 for ; Wed, 27 Aug 2003 16:43:43 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7RNhRo12655; Wed, 27 Aug 2003 16:43:27 -0700 Date: Wed, 27 Aug 2003 16:43:14 -0700 From: Stephen Hemminger To: "David S. Miller" , Jay Schulist Cc: netdev@oss.sgi.com, linux-atalk@lists.netspace.org Subject: [BUG] Interrupted appletalk echo request Message-Id: <20030827164314.606f7877.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5327 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Testing some other things and ran into a problem (2.4 and 2.6) if DDP socket program is interrupted while AARP entries are unresolved. Enclosed is a instrumented version console log. What is happening is that the AARP entry is getting expired when the retries get exhausted. This cause it flush all the skb's in its packet_queue. The socket for the socket buffer is still okay, but the sleep task_list is garbage and points to poisoned entries. DDP is doing the right thing and not destroying the socket if there are outstanding writes. Does it need to clean up the socket sleep queue or is that need to be done at a higher level. Also, AARP shouldn't have an unbounded packet_queue for unresolved entries... [root@zqx3 root]# aecho 6.101 send f588b610 kick retry f588b610 kick retry f588b610 kick retry f588b610 kick retry f588b610 kick retry f588b610 kick retry f588b610 kick retry f588b610 kick retry f588b610 kick retry f588b610 kick retry limit f588b610 expire f588b610 send f588b610 kick retry f588b610 kick retry f588b610 kick retry f588b610 kick retry f588b610 atalk_remove_socket atalk_destroy socket wmem=292 ----6.101 AEP Statistics---- 4 packets sent, 0 packets received, 100% packet loss [root@zqx3 root]# kick retry f588b610 kick retry f588b610 kick retry f588b610 kick retry f588b610 kick retry f588b610 kick retry limit f588b610 expire f588b610 eip: c011dbf9 ------------[ cut here ]------------ kernel BUG at include/asm/spinlock.h:120! invalid operand: 0000 [#1] CPU: 0 EIP: 0060:[] Not tainted EFLAGS: 00010086 EIP is at __wake_up+0x90/0x9a eax: 0000000e ebx: f5069244 ecx: 00000001 edx: c02e7ee0 esi: 00000001 edi: 00000001 ebp: c035de64 esp: c035de3c ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=c035c000 task=c02e5280) Stack: c02afefe c011dbf9 00000282 00004ef0 00000296 00000000 ffffffac f5069244 eac71104 f588b610 c035de80 c024aa4f c03894ff f5794e44 c0389121 eac71104 f588b614 c035de90 c024a123 eac71104 00000000 c035dea8 c024afaf f5794e44 Call Trace: [] __wake_up+0x0/0x9a [] sock_def_write_space+0xa8/0xbd [] sock_wfree+0x48/0x4a [] __kfree_skb+0x49/0xd9 [] __aarp_expire+0xcb/0x115 [appletalk] [] __aarp_kick+0x3b/0x6a [appletalk] [] aarp_expire_timeout+0x6c/0xd7 [appletalk] [] aarp_expire_timeout+0x0/0xd7 [appletalk] [] run_timer_softirq+0xed/0x226 [] scheduler_tick+0xf2/0x3df [] wake_up_process+0x26/0x2a [] do_softirq+0xd3/0xd5 [] smp_apic_timer_interrupt+0xd9/0x141 [] default_idle+0x0/0x32 [] apic_timer_interrupt+0x1a/0x20 [] default_idle+0x0/0x32 [] default_idle+0x2d/0x32 [] cpu_idle+0x3a/0x43 [] rest_init+0x0/0x80 [] start_kernel+0x1a5/0x1ef [] unknown_bootoption+0x0/0xfa Code: 0f 0b 78 00 a6 fe 2a c0 eb 89 55 89 e5 83 ec 10 c7 44 24 0c <0>Kernel panic: Fatal exception in interrupt In interrupt handler - not syncing From yoshfuji@linux-ipv6.org Wed Aug 27 17:33:56 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Aug 2003 17:34:30 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7S0XsWZ028118 for ; Wed, 27 Aug 2003 17:33:55 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h7S0YK1M023649; Thu, 28 Aug 2003 09:34:21 +0900 Date: Thu, 28 Aug 2003 09:34:20 +0900 (JST) Message-Id: <20030828.093420.37091433.yoshfuji@linux-ipv6.org> To: jfbeam@bluetronic.net Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: /proc/net/* read drops data From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 5328 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article (at Wed, 27 Aug 2003 19:58:17 -0400 (EDT)), Ricky Beam says: > On Wed, 27 Aug 2003, Ricky Beam wrote: > >This smells like a simple "off by one" bug, but I've been too busy to go > >look at the code. > > Ah hah! it's a block size problem... netstat reads 1024 at a time. > > Using dd... > > [root:pts/5{9}]gir:~/[7:55pm]:dd if=/proc/net/udp bs=1024 | wc > 2+1 records in > 2+1 records out > 18 216 2304 Good idea. I'll chase this bug. --yoshfuji From rddunlap@osdl.org Wed Aug 27 22:04:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Aug 2003 22:04:47 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7S54DWZ007024 for ; Wed, 27 Aug 2003 22:04:14 -0700 Received: from midway.verizon.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7S545o11607; Wed, 27 Aug 2003 22:04:05 -0700 Date: Wed, 27 Aug 2003 22:02:12 -0700 From: "Randy.Dunlap" To: netdev@oss.sgi.com Cc: wensong@linuxvirtualserver.org Subject: [PATCH] fix ipvs printk parameter types Message-Id: <20030827220212.7ccf6ddf.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5330 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 Content-Length: 4654 Lines: 132 Hi, Please apply. patch_name: ipvs_sizes.patch patch_version: 2003-08-27.18:16:43 author: Randy.Dunlap description: ipvs: fix gcc warnings of mismatched printk parameter types; product: Linux product_versions: 260-test4 maintainer: Wensong Zhang (?) diffstat: = net/ipv4/ipvs/ip_vs_conn.c | 2 +- net/ipv4/ipvs/ip_vs_dh.c | 4 ++-- net/ipv4/ipvs/ip_vs_lblc.c | 4 ++-- net/ipv4/ipvs/ip_vs_lblcr.c | 4 ++-- net/ipv4/ipvs/ip_vs_sh.c | 4 ++-- net/ipv4/ipvs/ip_vs_sync.c | 2 +- 6 files changed, 10 insertions(+), 10 deletions(-) diff -Naur ./net/ipv4/ipvs/ip_vs_conn.c~ipvssize ./net/ipv4/ipvs/ip_vs_conn.c --- ./net/ipv4/ipvs/ip_vs_conn.c~ipvssize Fri Aug 22 16:59:44 2003 +++ ./net/ipv4/ipvs/ip_vs_conn.c Wed Aug 27 10:02:37 2003 @@ -837,7 +837,7 @@ "(size=%d, memory=%ldKbytes)\n", IP_VS_CONN_TAB_SIZE, (long)(IP_VS_CONN_TAB_SIZE*sizeof(struct list_head))/1024); - IP_VS_DBG(0, "Each connection entry needs %d bytes at least\n", + IP_VS_DBG(0, "Each connection entry needs %Zd bytes at least\n", sizeof(struct ip_vs_conn)); for (idx = 0; idx < IP_VS_CONN_TAB_SIZE; idx++) { diff -Naur ./net/ipv4/ipvs/ip_vs_lblc.c~ipvssize ./net/ipv4/ipvs/ip_vs_lblc.c --- ./net/ipv4/ipvs/ip_vs_lblc.c~ipvssize Fri Aug 22 16:59:37 2003 +++ ./net/ipv4/ipvs/ip_vs_lblc.c Wed Aug 27 10:18:35 2003 @@ -396,7 +396,7 @@ return -ENOMEM; } svc->sched_data = tbl; - IP_VS_DBG(6, "LBLC hash table (memory=%dbytes) allocated for " + IP_VS_DBG(6, "LBLC hash table (memory=%Zdbytes) allocated for " "current service\n", sizeof(struct ip_vs_lblc_table)); @@ -436,7 +436,7 @@ /* release the table itself */ kfree(svc->sched_data); - IP_VS_DBG(6, "LBLC hash table (memory=%dbytes) released\n", + IP_VS_DBG(6, "LBLC hash table (memory=%Zdbytes) released\n", sizeof(struct ip_vs_lblc_table)); return 0; diff -Naur ./net/ipv4/ipvs/ip_vs_lblcr.c~ipvssize ./net/ipv4/ipvs/ip_vs_lblcr.c --- ./net/ipv4/ipvs/ip_vs_lblcr.c~ipvssize Fri Aug 22 16:58:50 2003 +++ ./net/ipv4/ipvs/ip_vs_lblcr.c Wed Aug 27 10:19:24 2003 @@ -649,7 +649,7 @@ return -ENOMEM; } svc->sched_data = tbl; - IP_VS_DBG(6, "LBLCR hash table (memory=%dbytes) allocated for " + IP_VS_DBG(6, "LBLCR hash table (memory=%Zdbytes) allocated for " "current service\n", sizeof(struct ip_vs_lblcr_table)); @@ -692,7 +692,7 @@ /* release the table itself */ kfree(svc->sched_data); - IP_VS_DBG(6, "LBLCR hash table (memory=%dbytes) released\n", + IP_VS_DBG(6, "LBLCR hash table (memory=%Zdbytes) released\n", sizeof(struct ip_vs_lblcr_table)); return 0; diff -Naur ./net/ipv4/ipvs/ip_vs_sh.c~ipvssize ./net/ipv4/ipvs/ip_vs_sh.c --- ./net/ipv4/ipvs/ip_vs_sh.c~ipvssize Fri Aug 22 16:58:07 2003 +++ ./net/ipv4/ipvs/ip_vs_sh.c Wed Aug 27 10:30:04 2003 @@ -144,7 +144,7 @@ return -ENOMEM; } svc->sched_data = tbl; - IP_VS_DBG(6, "SH hash table (memory=%dbytes) allocated for " + IP_VS_DBG(6, "SH hash table (memory=%Zdbytes) allocated for " "current service\n", sizeof(struct ip_vs_sh_bucket)*IP_VS_SH_TAB_SIZE); @@ -164,7 +164,7 @@ /* release the table itself */ kfree(svc->sched_data); - IP_VS_DBG(6, "SH hash table (memory=%dbytes) released\n", + IP_VS_DBG(6, "SH hash table (memory=%Zdbytes) released\n", sizeof(struct ip_vs_sh_bucket)*IP_VS_SH_TAB_SIZE); return 0; diff -Naur ./net/ipv4/ipvs/ip_vs_sync.c~ipvssize ./net/ipv4/ipvs/ip_vs_sync.c --- ./net/ipv4/ipvs/ip_vs_sync.c~ipvssize Fri Aug 22 16:50:52 2003 +++ ./net/ipv4/ipvs/ip_vs_sync.c Wed Aug 27 12:14:47 2003 @@ -851,7 +851,7 @@ return -EEXIST; IP_VS_DBG(7, "%s: pid %d\n", __FUNCTION__, current->pid); - IP_VS_DBG(7, "Each ip_vs_sync_conn entry need %d bytes\n", + IP_VS_DBG(7, "Each ip_vs_sync_conn entry need %Zd bytes\n", sizeof(struct ip_vs_sync_conn)); ip_vs_sync_state |= state; diff -Naur ./net/ipv4/ipvs/ip_vs_dh.c~ipvssize ./net/ipv4/ipvs/ip_vs_dh.c --- ./net/ipv4/ipvs/ip_vs_dh.c~ipvssize Wed Aug 27 12:18:00 2003 +++ ./net/ipv4/ipvs/ip_vs_dh.c Wed Aug 27 12:18:31 2003 @@ -147,7 +147,7 @@ return -ENOMEM; } svc->sched_data = tbl; - IP_VS_DBG(6, "DH hash table (memory=%dbytes) allocated for " + IP_VS_DBG(6, "DH hash table (memory=%Zdbytes) allocated for " "current service\n", sizeof(struct ip_vs_dh_bucket)*IP_VS_DH_TAB_SIZE); @@ -167,7 +167,7 @@ /* release the table itself */ kfree(svc->sched_data); - IP_VS_DBG(6, "DH hash table (memory=%dbytes) released\n", + IP_VS_DBG(6, "DH hash table (memory=%Zdbytes) released\n", sizeof(struct ip_vs_dh_bucket)*IP_VS_DH_TAB_SIZE); return 0; -- ~Randy From rddunlap@osdl.org Wed Aug 27 22:06:30 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Aug 2003 22:07:04 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7S56TWZ007689 for ; Wed, 27 Aug 2003 22:06:30 -0700 Received: from midway.verizon.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7S56Oo11913; Wed, 27 Aug 2003 22:06:24 -0700 Date: Wed, 27 Aug 2003 22:04:31 -0700 From: "Randy.Dunlap" To: netdev@oss.sgi.com Cc: sri@us.ibm.com Subject: [PATCH] fix sctp printk parameter types Message-Id: <20030827220431.2e1e7826.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5331 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 Content-Length: 707 Lines: 27 Hi, Please apply. patch_name: sctp_sizes.patch patch_version: 2003-08-27.18:18:12 author: Randy.Dunlap description: sctp: fix printk parameter type (gcc warning); product: Linux product_versions: 260-test4 maintainer: sri@us.ibm.com diff -Naur ./net/sctp/socket.c~sctpsize ./net/sctp/socket.c --- ./net/sctp/socket.c~sctpsize Fri Aug 22 17:03:25 2003 +++ ./net/sctp/socket.c Wed Aug 27 10:35:06 2003 @@ -852,7 +852,7 @@ associd = sinfo->sinfo_assoc_id; } - SCTP_DEBUG_PRINTK("msg_len: %Zd, sinfo_flags: 0x%x\n", + SCTP_DEBUG_PRINTK("msg_len: %d, sinfo_flags: 0x%x\n", msg_len, sinfo_flags); /* MSG_EOF or MSG_ABORT cannot be set on a TCP-style socket. */ -- ~Randy From rddunlap@osdl.org Wed Aug 27 22:08:12 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Aug 2003 22:08:44 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7S58BWZ008058 for ; Wed, 27 Aug 2003 22:08:11 -0700 Received: from midway.verizon.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7S585o12022; Wed, 27 Aug 2003 22:08:05 -0700 Date: Wed, 27 Aug 2003 22:06:12 -0700 From: "Randy.Dunlap" To: netdev@oss.sgi.com Cc: jpr@f6fbb.org Subject: [PATCH] yam: function needs a return Message-Id: <20030827220612.52553e1d.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5332 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 Content-Length: 685 Lines: 27 Hi, Please apply. patch_name: yam_retval.patch patch_version: 2003-08-27.18:19:03 author: Randy.Dunlap description: yam: function needs a return statement; product: Linux product_versions: 260-test4 maintainer: jpr@f6fbb.org diff -Naur ./drivers/net/hamradio/yam.c~retval ./drivers/net/hamradio/yam.c --- ./drivers/net/hamradio/yam.c~retval Fri Aug 22 16:58:10 2003 +++ ./drivers/net/hamradio/yam.c Wed Aug 27 12:03:13 2003 @@ -807,7 +807,7 @@ seq_printf(seq, " RxInt %u\n", yp->nb_rxint); seq_printf(seq, " RxOver %lu\n", yp->stats.rx_fifo_errors); seq_printf(seq, "\n"); - + return 0; } static struct seq_operations yam_seqops = { -- ~Randy From davem@pizda.ninka.net Wed Aug 27 23:33:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Aug 2003 23:33:48 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7S6XiWZ012879 for ; Wed, 27 Aug 2003 23:33:45 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id XAA24999; Wed, 27 Aug 2003 23:25:14 -0700 Date: Wed, 27 Aug 2003 23:25:14 -0700 From: "David S. Miller" To: Vinay K Nallamothu Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2.6.0-test4][IPv6] ip6_flowlabel.c: timer cleanups Message-Id: <20030827232514.0854fc06.davem@redhat.com> In-Reply-To: <1061907882.1108.28.camel@lima.royalchallenge.com> References: <1061907882.1108.28.camel@lima.royalchallenge.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5333 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 Content-Length: 590 Lines: 21 On 26 Aug 2003 19:54:41 +0530 Vinay K Nallamothu wrote: > @@ -104,10 +105,9 @@ > fl->opt = NULL; > kfree(opt); > } > - if (!del_timer(&ip6_fl_gc_timer) || > - (long)(ip6_fl_gc_timer.expires - ttd) > 0) > - ip6_fl_gc_timer.expires = ttd; > - add_timer(&ip6_fl_gc_timer); > + if (!timer_pending(&ip6_fl_gc_timer) || > + time_after(ip6_fl_gc_timer.expires, ttd)) > + mod_timer(&ip6_fl_gc_timer, ttd); > } > } > This code is still racey. This code needs to hold the toplevel ip6_fl_lock during the GC timer manipulations and tests. From davem@pizda.ninka.net Wed Aug 27 23:37:12 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Aug 2003 23:37:15 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7S6bCWZ013637 for ; Wed, 27 Aug 2003 23:37:12 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id XAA25006; Wed, 27 Aug 2003 23:28:47 -0700 Date: Wed, 27 Aug 2003 23:28:47 -0700 From: "David S. Miller" To: Dan Aloni Cc: netdev@oss.sgi.com Subject: Re: [BK PATCH 2.6] fix sysctl breakage during network device renaming, for ipv4 Message-Id: <20030827232847.68cc17a6.davem@redhat.com> In-Reply-To: <20030826153812.GA2216@callisto.yi.org> References: <20030826153812.GA2216@callisto.yi.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5334 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 Content-Length: 955 Lines: 21 On Tue, 26 Aug 2003 18:38:12 +0300 Dan Aloni wrote: > Sysctl assumes its ctl_table.procname field is const, but the > networking points ctl_table.procname to dev->name. When renaming > a network device using SIOCSIFNAME, dev->name is modified and > sysctl's assumption breaks, causing this behaviour, at least: > > 1. sysctl wouldn't be able to remove the proc entry when the > device requests to be unregistered, because it would be > using the new name instead of the old one. > 2. proc entries for devices remain with the old name after > rename. > > This change includes allocating the current device name to a > new copy upon registering with sysctl, plus re-registering with > sysctl when the device is renamed. Conceptually this change is OK. But please don't put generic things like a strdup() implementation statically into net/ipv4/devinet.c, it does not belong there. From davem@pizda.ninka.net Wed Aug 27 23:48:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 27 Aug 2003 23:48:43 -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.5) with SMTP id h7S6meWZ014338 for ; Wed, 27 Aug 2003 23:48:40 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id XAA25054; Wed, 27 Aug 2003 23:40:10 -0700 Date: Wed, 27 Aug 2003 23:40:10 -0700 From: "David S. Miller" To: "YOSHIFUJI Hideaki / _$B5HF#1QL@" Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [OOPS] less /proc/net/igmp Message-Id: <20030827234010.0b0b2e69.davem@redhat.com> In-Reply-To: <20030827.083926.50662159.yoshfuji@linux-ipv6.org> References: <20030826.173226.114994096.yoshfuji@linux-ipv6.org> <20030827.015448.70287953.yoshfuji@linux-ipv6.org> <1061929108.3946.1.camel@spider.hotmonkeyporn.com> <20030827.083926.50662159.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5335 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 Content-Length: 411 Lines: 11 On Wed, 27 Aug 2003 08:39:26 +0900 (JST) YOSHIFUJI Hideaki / _$B5HF#1QL@ wrote: > In article <1061929108.3946.1.camel@spider.hotmonkeyporn.com> (at 26 Aug 2003 15:18:28 -0500), Owen Ford says: > > Thanks. David, please apply. > > D: Fixing several refcnt mistakes in seq_file handlers for > D: /proc/net/{igmp,igmp6,msfilter,msfilter6}. Applied, thank you. From davem@pizda.ninka.net Thu Aug 28 00:01:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Aug 2003 00:01: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.5) with SMTP id h7S71LWZ016347 for ; Thu, 28 Aug 2003 00:01:22 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id XAA25124; Wed, 27 Aug 2003 23:52:58 -0700 Date: Wed, 27 Aug 2003 23:52:58 -0700 From: "David S. Miller" To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: Re: ethtool_features? Message-Id: <20030827235258.7229c8e1.davem@redhat.com> In-Reply-To: <3F4D2F2B.2090401@pobox.com> References: <3F4D2F2B.2090401@pobox.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5336 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 Content-Length: 383 Lines: 10 On Wed, 27 Aug 2003 18:22:35 -0400 Jeff Garzik wrote: > Hum. Instead of adding all these _get_foo ops to test dev->features > bits, would anyone mind if I created a single _get_features() ethtool > sub-ioctl? I'm personally OK with this _iff_ you add values local to ethtool for the various feature bits. Ie. don't export the NETIF_F_* values to userspace. From davem@pizda.ninka.net Thu Aug 28 00:19:05 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Aug 2003 00:19:11 -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.5) with SMTP id h7S7J5WZ025531 for ; Thu, 28 Aug 2003 00:19:05 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id AAA25209; Thu, 28 Aug 2003 00:09:40 -0700 Date: Thu, 28 Aug 2003 00:09:40 -0700 From: "David S. Miller" To: Ville Nuorvala Cc: usagi-core@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [PATCH] IPv6: Use ip6_dst_lookup() in ip6_tunnel.c Message-Id: <20030828000940.189f8c98.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5337 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 Content-Length: 440 Lines: 13 On Wed, 27 Aug 2003 14:13:31 +0300 (EEST) Ville Nuorvala wrote: > I cleaned up ip6ip6_tnl_xmit() a bit by using ip6_dst_lookup(). As an > added bonus IPsec processing of the tunneled packets should now be > possible. Please apply! This patch doesn't apply cleanly for some reason, there were some other changes to ip6_tunnel.c lately. Can you regenerate this against Andrew Mortons 2.6.0-test4--mm2 patch? Thanks. From davem@pizda.ninka.net Thu Aug 28 00:20:21 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Aug 2003 00:20: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.5) with SMTP id h7S7KKWZ025731 for ; Thu, 28 Aug 2003 00:20:21 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id AAA25216; Thu, 28 Aug 2003 00:10:56 -0700 Date: Thu, 28 Aug 2003 00:10:55 -0700 From: "David S. Miller" To: Ville Nuorvala Cc: usagi-core@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [PATCH] IPv6: Allow nested IPv6 encapsulations on same node Message-Id: <20030828001055.1aa32481.davem@redhat.com> In-Reply-To: References: <20030827064514.7c060a64.davem@redhat.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5338 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 Content-Length: 521 Lines: 12 On Wed, 27 Aug 2003 19:42:21 +0300 (EEST) Ville Nuorvala wrote: > In the old days ip6_build_xmit() was the way to go if you wanted > fragmentation, but now ip6_fragment() _seems_ to be able to handle the > whole thing without the help of ip6_append_data() & Co. > > I'll have to test this and get back to you! Another point is that you really don't want to use sockets here for another reason, you're going to get artificial queueing limits bacause each tunnel packet gets charged to the socket. From shmulik.hen@intel.com Thu Aug 28 00:26:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Aug 2003 00:27:13 -0700 (PDT) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7S7QcWZ026445 for ; Thu, 28 Aug 2003 00:26:39 -0700 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.78 2003/08/27 22:23:27 dmccart Exp $) with ESMTP id h7S7L9k17811 for ; Thu, 28 Aug 2003 07:21:09 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h7S7TdY03007 for ; Thu, 28 Aug 2003 07:29:40 GMT Received: from hasmsx331.ger.corp.intel.com ([143.185.63.144]) by hasmsxvs01.iil.intel.com (NAVGW 2.5.2.11) with SMTP id M2003082810263114518 ; Thu, 28 Aug 2003 10:26:31 +0300 Received: from hasmsx403.ger.corp.intel.com ([143.185.63.109]) by hasmsx331.ger.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 28 Aug 2003 10:26:31 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [bonding][2/3] Synchronizing 2.4-2.6 Date: Thu, 28 Aug 2003 10:26:31 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [bonding][2/3] Synchronizing 2.4-2.6 Thread-Index: AcNs5XxxCmdQKmYkTQOdsJUdYEZgogAT7LkA From: "Hen, Shmulik" To: "Jeff Garzik" Cc: , X-OriginalArrivalTime: 28 Aug 2003 07:26:31.0487 (UTC) FILETIME=[B3DDFCF0:01C36D35] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7S7QcWZ026445 X-archive-position: 5339 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Content-Length: 1339 Lines: 43 > -----Original Message----- > From: Jeff Garzik [mailto:jgarzik@pobox.com] > Sent: Thursday, August 28, 2003 12:52 AM > To: Hen, Shmulik > Cc: bonding-devel@lists.sourceforge.net; netdev@oss.sgi.com > Subject: Re: [bonding][2/3] Synchronizing 2.4-2.6 > > > Shmulik Hen wrote: > > This is set 2 that merges parts of Jay Vosburgh's experimental > > propagation stuff from 5/22 with all the fixes/enhancements > > we've developed according to the RFC published on bond-devel > > list on 6/2. > > > > Applies on 2.4.22. Assumes patch set 1 was already applied. > > > As Jay mentioned he had approved through the end of set 2, and set 2 > looks good to me, I applied all 8 patches to 2.4. > Does that mean patch set 2 was also applied ? Because that was the first thing to do to get versions synched. > Let's now take an operational pause in 2.4, and get 2.6 back > into sync. > Would some hearty bonding team member(s) be willing to do that? > After patch set 1, It should be as easy as just copying all the bonding related files from 2.4 to 2.6. I guess I can do that on Sunday if someone hasn't already done it before. > I would _really_ prefer that the revision history be > maintained, which > makes it a non-trivial exercise, time-wise... Where should that be maintained ? I could suggest the CVS on SFG. Shmulik. From davem@pizda.ninka.net Thu Aug 28 01:23:48 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Aug 2003 01:23:57 -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.5) with SMTP id h7S8NmWZ031961 for ; Thu, 28 Aug 2003 01:23:48 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id BAA25838; Thu, 28 Aug 2003 01:15:19 -0700 Date: Thu, 28 Aug 2003 01:15:19 -0700 From: "David S. Miller" To: "Randy.Dunlap" Cc: netdev@oss.sgi.com, sri@us.ibm.com Subject: Re: [PATCH] fix sctp printk parameter types Message-Id: <20030828011519.318e4f5b.davem@redhat.com> In-Reply-To: <20030827220431.2e1e7826.rddunlap@osdl.org> References: <20030827220431.2e1e7826.rddunlap@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5340 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 Content-Length: 112 Lines: 6 On Wed, 27 Aug 2003 22:04:31 -0700 "Randy.Dunlap" wrote: > Please apply. Applied, thanks. From davem@pizda.ninka.net Thu Aug 28 01:24:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Aug 2003 01:24:40 -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.5) with SMTP id h7S8OaWZ000744 for ; Thu, 28 Aug 2003 01:24:37 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id BAA25860; Thu, 28 Aug 2003 01:16:05 -0700 Date: Thu, 28 Aug 2003 01:16:05 -0700 From: "David S. Miller" To: "Randy.Dunlap" Cc: netdev@oss.sgi.com, wensong@linuxvirtualserver.org Subject: Re: [PATCH] fix ipvs printk parameter types Message-Id: <20030828011605.5813e9e0.davem@redhat.com> In-Reply-To: <20030827220212.7ccf6ddf.rddunlap@osdl.org> References: <20030827220212.7ccf6ddf.rddunlap@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5341 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 Content-Length: 112 Lines: 6 On Wed, 27 Aug 2003 22:02:12 -0700 "Randy.Dunlap" wrote: > Please apply. Applied, thanks. From davem@pizda.ninka.net Thu Aug 28 01:27:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Aug 2003 01:27:17 -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.5) with SMTP id h7S8RCWZ001629 for ; Thu, 28 Aug 2003 01:27:14 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id BAA25892; Thu, 28 Aug 2003 01:17:50 -0700 Date: Thu, 28 Aug 2003 01:17:50 -0700 From: "David S. Miller" To: "Randy.Dunlap" Cc: netdev@oss.sgi.com, jpr@f6fbb.org Subject: Re: [PATCH] yam: function needs a return Message-Id: <20030828011750.1fff2999.davem@redhat.com> In-Reply-To: <20030827220612.52553e1d.rddunlap@osdl.org> References: <20030827220612.52553e1d.rddunlap@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5342 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 Content-Length: 112 Lines: 6 On Wed, 27 Aug 2003 22:06:12 -0700 "Randy.Dunlap" wrote: > Please apply. Applied, thanks. From jgarzik@pobox.com Thu Aug 28 03:51:09 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Aug 2003 03:51:44 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7SAp7WZ010625 for ; Thu, 28 Aug 2003 03:51:08 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:32792 helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.22) id 19s7to-00080Z-Ae; Wed, 27 Aug 2003 22:32:16 +0100 Message-ID: <3F4D2355.8010803@pobox.com> Date: Wed, 27 Aug 2003 17:32:05 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: shmulik.hen@intel.com CC: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [bonding][1/3] Synchronizing 2.4-2.6 References: <200308272000.39229.shmulik.hen@intel.com> In-Reply-To: <200308272000.39229.shmulik.hen@intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5343 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 Content-Length: 1022 Lines: 49 Shmulik Hen wrote: > This is set 1 that handles backporting bonding stuff from 2.6 into 2.4 > while fixing some implementation bugs. > > Applies on 2.4.22. > > patch set can be downloaded from: > http://osdn.dl.sourceforge.net/sourceforge/bonding/patch_set_1_backport.tar.bz2 > > This will update the following files: > > Documentation/networking/ifenslave.c > drivers/net/bonding/bonding.h > drivers/net/bonding/bond_main.c > drivers/net/net_init.c > include/linux/list.h > include/linux/netdevice.h > > Description: > patch 1 - Add list_for_each_entry_safe() applied > patch 2 - Export alloc_netdev() already applied and upstream > patch 3 - Fix /proc read function applied > patch 4 - Put the bond's net_device_stats inside the bond struct already applied and upstream > patch 5 - Use a linked list to handle multiple bond devices applied > patch 6 - Update versions/contributions in header and bump version applied... even though a non-described ifenslave.c change snuck into this patch. From jgarzik@pobox.com Thu Aug 28 09:02:57 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Aug 2003 09:03:32 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7SG2uWZ031704 for ; Thu, 28 Aug 2003 09:02:57 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:33122 helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.22) id 19sPEc-0007EK-7D; Thu, 28 Aug 2003 17:02:54 +0100 Message-ID: <3F4E27A2.9060204@pobox.com> Date: Thu, 28 Aug 2003 12:02:42 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: "Hen, Shmulik" CC: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [bonding][2/3] Synchronizing 2.4-2.6 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5344 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 Content-Length: 1350 Lines: 48 Hen, Shmulik wrote: >>-----Original Message----- >>From: Jeff Garzik [mailto:jgarzik@pobox.com] >>Sent: Thursday, August 28, 2003 12:52 AM >>To: Hen, Shmulik >>Cc: bonding-devel@lists.sourceforge.net; netdev@oss.sgi.com >>Subject: Re: [bonding][2/3] Synchronizing 2.4-2.6 >> >> >>Shmulik Hen wrote: >> >>>This is set 2 that merges parts of Jay Vosburgh's experimental >>>propagation stuff from 5/22 with all the fixes/enhancements >>>we've developed according to the RFC published on bond-devel >>>list on 6/2. >>> >>>Applies on 2.4.22. Assumes patch set 1 was already applied. >> >> >>As Jay mentioned he had approved through the end of set 2, and set 2 >>looks good to me, I applied all 8 patches to 2.4. >> > > > Does that mean patch set 2 was also applied ? Yes. >>Let's now take an operational pause in 2.4, and get 2.6 back >>into sync. >> Would some hearty bonding team member(s) be willing to do that? >> > > > After patch set 1, It should be as easy as just copying all the > bonding related files from 2.4 to 2.6. I guess I can do that on > Sunday if someone hasn't already done it before. I had hoped to preserve the revision history. Simply copying the files over does not do that :( What I mean by preserving revision history is, changes should be submitted to 2.6 in the same granularity as they were to 2.4... Jeff From laurent.deniel@free.fr Thu Aug 28 10:38:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Aug 2003 10:39:19 -0700 (PDT) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7SHcZWZ005576 for ; Thu, 28 Aug 2003 10:38:36 -0700 Received: from free.fr (rennes-1-a7-62-147-99-106.dial.proxad.net [62.147.99.106]) by postfix3-1.free.fr (Postfix) with ESMTP id 30031C2EC; Thu, 28 Aug 2003 19:38:32 +0200 (CEST) Message-ID: <3F4E391F.6030403@free.fr> Date: Thu, 28 Aug 2003 19:17:19 +0200 From: Laurent Deniel Organization: Home User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: shmulik.hen@intel.com Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [Bonding-devel] [bonding][3/3] Synchronizing 2.4-2.6 References: <200308272008.20139.shmulik.hen@intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5345 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laurent.deniel@free.fr Precedence: bulk X-list: netdev Content-Length: 553 Lines: 17 Shmulik Hen wrote: > > patch 7 - eliminate the multicast_more module param and use the > USES_PRIMARY macro instead. Do you know that this breaks upward compatibility ? i.e. this now assumes that for instance in active backup mode, only the active slave registers the multicast addresses (i.e. multicast_mode = 1) while the default from the very beginning was all NIC (multicast_mode = 0). And this removes the possiblity of disabling multicast stuff. But if everyone is OK ... (I'd be since I currently only use multicast_mode = 1 ;-) Laurent From anton@samba.org Thu Aug 28 10:51:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Aug 2003 10:51:52 -0700 (PDT) Received: from lists.samba.org (dp.samba.org [66.70.73.150]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7SHpGWZ006572 for ; Thu, 28 Aug 2003 10:51:16 -0700 Received: by lists.samba.org (Postfix, from userid 504) id 102512CDB5; Thu, 28 Aug 2003 17:51:16 +0000 (GMT) Date: Fri, 29 Aug 2003 03:48:59 +1000 From: Anton Blanchard To: netdev@oss.sgi.com Subject: send to self patch Message-ID: <20030828174859.GG12541@krispykreme> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-archive-position: 5346 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: anton@samba.org Precedence: bulk X-list: netdev Content-Length: 6216 Lines: 207 Hi, Here in the lab we often want to send TCP/IP data out over looped back networks. We do have tools to send and receive raw packets but sometimes thats not enough. eg When running netperf, you dont always need two machines. If you are just trying to stress a box (eg to find a bug like the NAPI one we hit a week or two ago) then running loopback is fine. We also have exercisers that run over TCP/IP and checksum sent data vs received data. I stumbled upon a patch by Julian Anastasov, and have found it works well. Is there any chance of getting this (or something like it) into 2.6? http://www.ssi.bg/~ja/#loop Anton diff -ur v2.5.73/linux/Documentation/filesystems/proc.txt linux/Documentation/filesystems/proc.txt --- v2.5.73/linux/Documentation/filesystems/proc.txt Sun Jun 15 10:23:55 2003 +++ linux/Documentation/filesystems/proc.txt Tue Jul 1 23:29:02 2003 @@ -1502,6 +1502,15 @@ Log packets with source addresses with no known route to kernel log. +loop +---- + +By default (loop=0) the traffic between local IP addresses +is routed via interface "lo". Setting this flag for two +interfaces allows traffic between their IP addresses to +be looped externally. This is useful for setups where the +interfaces are attached to same broadcast medium. + mc_forwarding ------------- diff -ur v2.5.73/linux/Documentation/networking/ip-sysctl.txt linux/Documentation/networking/ip-sysctl.txt --- v2.5.73/linux/Documentation/networking/ip-sysctl.txt Sun Jun 15 10:23:56 2003 +++ linux/Documentation/networking/ip-sysctl.txt Tue Jul 1 23:27:02 2003 @@ -390,6 +390,13 @@ forwarding - BOOLEAN Enable IP forwarding on this interface. +loop - BOOLEAN + By default (loop=0) the traffic between local IP addresses + is routed via interface "lo". Setting this flag for two + interfaces allows traffic between their IP addresses to + be looped externally. This is useful for setups where the + interfaces are attached to same broadcast medium. + mc_forwarding - BOOLEAN Do multicast routing. The kernel needs to be compiled with CONFIG_MROUTE and a multicast routing daemon is required. diff -ur v2.5.73/linux/include/linux/inetdevice.h linux/include/linux/inetdevice.h --- v2.5.73/linux/include/linux/inetdevice.h Sun Apr 20 11:02:16 2003 +++ linux/include/linux/inetdevice.h Mon Jun 30 23:46:20 2003 @@ -21,6 +21,7 @@ int medium_id; int no_xfrm; int no_policy; + int loop; void *sysctl; }; @@ -70,6 +71,7 @@ (ipv4_devconf.accept_redirects || (in_dev)->cnf.accept_redirects))) #define IN_DEV_ARPFILTER(in_dev) (ipv4_devconf.arp_filter || (in_dev)->cnf.arp_filter) +#define IN_DEV_LOOP(in_dev) ((in_dev)->cnf.loop) struct in_ifaddr { diff -ur v2.5.73/linux/include/linux/sysctl.h linux/include/linux/sysctl.h --- v2.5.73/linux/include/linux/sysctl.h Sun Jun 15 10:25:03 2003 +++ linux/include/linux/sysctl.h Mon Jun 30 23:47:14 2003 @@ -359,6 +359,7 @@ NET_IPV4_CONF_MEDIUM_ID=14, NET_IPV4_CONF_NOXFRM=15, NET_IPV4_CONF_NOPOLICY=16, + NET_IPV4_CONF_LOOP=17, }; /* /proc/sys/net/ipv6 */ diff -ur v2.5.73/linux/net/ipv4/devinet.c linux/net/ipv4/devinet.c --- v2.5.73/linux/net/ipv4/devinet.c Sun Jun 15 10:25:07 2003 +++ linux/net/ipv4/devinet.c Mon Jun 30 23:49:26 2003 @@ -1122,7 +1122,7 @@ static struct devinet_sysctl_table { struct ctl_table_header *sysctl_header; - ctl_table devinet_vars[17]; + ctl_table devinet_vars[18]; ctl_table devinet_dev[2]; ctl_table devinet_conf_dir[2]; ctl_table devinet_proto_dir[2]; @@ -1258,6 +1258,14 @@ .mode = 0644, .proc_handler = &ipv4_doint_and_flush, .strategy = &ipv4_doint_and_flush_strategy, + }, + { + .ctl_name = NET_IPV4_CONF_LOOP, + .procname = "loop", + .data = &ipv4_devconf.loop, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, }, }, .devinet_dev = { diff -ur v2.5.73/linux/net/ipv4/fib_frontend.c linux/net/ipv4/fib_frontend.c --- v2.5.73/linux/net/ipv4/fib_frontend.c Wed May 28 00:02:50 2003 +++ linux/net/ipv4/fib_frontend.c Mon Jun 30 23:52:38 2003 @@ -167,15 +167,16 @@ .tos = tos } }, .iif = oif }; struct fib_result res; - int no_addr, rpf; + int no_addr, rpf, loop; int ret; - no_addr = rpf = 0; + no_addr = rpf = loop = 0; read_lock(&inetdev_lock); in_dev = __in_dev_get(dev); if (in_dev) { no_addr = in_dev->ifa_list == NULL; rpf = IN_DEV_RPFILTER(in_dev); + loop = IN_DEV_LOOP(in_dev); } read_unlock(&inetdev_lock); @@ -184,6 +185,11 @@ if (fib_lookup(&fl, &res)) goto last_resort; + if (loop && res.type == RTN_LOCAL) { + *spec_dst = FIB_RES_PREFSRC(res); + fib_res_put(&res); + return 0; + } if (res.type != RTN_UNICAST) goto e_inval_res; *spec_dst = FIB_RES_PREFSRC(res); diff -ur v2.5.73/linux/net/ipv4/route.c linux/net/ipv4/route.c --- v2.5.73/linux/net/ipv4/route.c Tue Jun 17 21:39:39 2003 +++ linux/net/ipv4/route.c Tue Jul 1 00:29:05 2003 @@ -1967,6 +1967,11 @@ dev_put(dev_out); goto out; /* Wrong error code */ } + err = -ENETDOWN; + if (!(dev_out->flags&IFF_UP)) { + dev_put(dev_out); + goto out; + } if (LOCAL_MCAST(oldflp->fl4_dst) || oldflp->fl4_dst == 0xFFFFFFFF) { if (!fl.fl4_src) @@ -2036,10 +2041,41 @@ goto e_inval; if (res.type == RTN_LOCAL) { - if (!fl.fl4_src) - fl.fl4_src = fl.fl4_dst; + struct in_device *in_dev; + u32 src; + if (dev_out) dev_put(dev_out); + dev_out = FIB_RES_DEV(res); + in_dev = in_dev_get(dev_out); + src = fl.fl4_src? : FIB_RES_PREFSRC(res); + if (in_dev && IN_DEV_LOOP(in_dev) && src) { + struct net_device *dev_src; + + in_dev_put(in_dev); + in_dev = NULL; + dev_src = ip_dev_find(src); + if (dev_src && dev_src != dev_out && + (in_dev = in_dev_get(dev_src)) && + IN_DEV_LOOP(in_dev)) { + in_dev_put(in_dev); + dev_out = dev_src; + fl.fl4_src = src; + fl.oif = dev_out->ifindex; + res.type = RTN_UNICAST; + if (res.fi) { + fib_info_put(res.fi); + res.fi = NULL; + } + goto make_route; + } + if (dev_src) + dev_put(dev_src); + } + if (in_dev) + in_dev_put(in_dev); + if (!fl.fl4_src) + fl.fl4_src = fl.fl4_dst; dev_out = &loopback_dev; dev_hold(dev_out); fl.oif = dev_out->ifindex; From jleu@nero.doit.wisc.edu Thu Aug 28 11:22:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Aug 2003 11:23:29 -0700 (PDT) Received: from nero.doit.wisc.edu (IDENT:root@nero.doit.wisc.edu [128.104.17.130]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7SIMqWZ013140 for ; Thu, 28 Aug 2003 11:22:52 -0700 Received: (from jleu@localhost) by nero.doit.wisc.edu (8.11.6/8.11.6) id h7SJMl906837; Thu, 28 Aug 2003 14:22:47 -0500 Date: Thu, 28 Aug 2003 14:22:47 -0500 From: "James R. Leu" To: Anton Blanchard Cc: netdev@oss.sgi.com Subject: Re: send to self patch Message-ID: <20030828142246.A6499@mindspring.com> Reply-To: jleu@mindspring.com References: <20030828174859.GG12541@krispykreme> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030828174859.GG12541@krispykreme>; from anton@samba.org on Fri, Aug 29, 2003 at 03:48:59AM +1000 Organization: none X-archive-position: 5347 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jleu@mindspring.com Precedence: bulk X-list: netdev Content-Length: 7398 Lines: 224 While the various 'send-to-self' patches are useful for exactly what you are trying to do, I think a more generic solution, which has as one of it's features the ability to 'send-to-self', should be integrated into the kernel (I think it might be too late for anything new to be added to 2.6). Since I'm not the type to criticize without providing an alternate solution, take a look at http://linux-vrf.sf.net/ for my attempt at solving a larger problem (virtual routing and forwarding), which also solves the 'send-to-self' problem (by creating a vrf and place one of the 'send-to-self' interfaces in that vrf). The patch is against a 2.4.19 kernel, but should apply to 2.4.20-21. On Fri, Aug 29, 2003 at 03:48:59AM +1000, Anton Blanchard wrote: > > Hi, > > Here in the lab we often want to send TCP/IP data out over looped back > networks. We do have tools to send and receive raw packets but sometimes > thats not enough. > > eg When running netperf, you dont always need two machines. If you are > just trying to stress a box (eg to find a bug like the NAPI one we hit a > week or two ago) then running loopback is fine. > > We also have exercisers that run over TCP/IP and checksum sent data vs > received data. > > I stumbled upon a patch by Julian Anastasov, and have found it works well. > Is there any chance of getting this (or something like it) into 2.6? > > http://www.ssi.bg/~ja/#loop > > Anton > > diff -ur v2.5.73/linux/Documentation/filesystems/proc.txt linux/Documentation/filesystems/proc.txt > --- v2.5.73/linux/Documentation/filesystems/proc.txt Sun Jun 15 10:23:55 2003 > +++ linux/Documentation/filesystems/proc.txt Tue Jul 1 23:29:02 2003 > @@ -1502,6 +1502,15 @@ > > Log packets with source addresses with no known route to kernel log. > > +loop > +---- > + > +By default (loop=0) the traffic between local IP addresses > +is routed via interface "lo". Setting this flag for two > +interfaces allows traffic between their IP addresses to > +be looped externally. This is useful for setups where the > +interfaces are attached to same broadcast medium. > + > mc_forwarding > ------------- > > diff -ur v2.5.73/linux/Documentation/networking/ip-sysctl.txt linux/Documentation/networking/ip-sysctl.txt > --- v2.5.73/linux/Documentation/networking/ip-sysctl.txt Sun Jun 15 10:23:56 2003 > +++ linux/Documentation/networking/ip-sysctl.txt Tue Jul 1 23:27:02 2003 > @@ -390,6 +390,13 @@ > forwarding - BOOLEAN > Enable IP forwarding on this interface. > > +loop - BOOLEAN > + By default (loop=0) the traffic between local IP addresses > + is routed via interface "lo". Setting this flag for two > + interfaces allows traffic between their IP addresses to > + be looped externally. This is useful for setups where the > + interfaces are attached to same broadcast medium. > + > mc_forwarding - BOOLEAN > Do multicast routing. The kernel needs to be compiled with CONFIG_MROUTE > and a multicast routing daemon is required. > diff -ur v2.5.73/linux/include/linux/inetdevice.h linux/include/linux/inetdevice.h > --- v2.5.73/linux/include/linux/inetdevice.h Sun Apr 20 11:02:16 2003 > +++ linux/include/linux/inetdevice.h Mon Jun 30 23:46:20 2003 > @@ -21,6 +21,7 @@ > int medium_id; > int no_xfrm; > int no_policy; > + int loop; > void *sysctl; > }; > > @@ -70,6 +71,7 @@ > (ipv4_devconf.accept_redirects || (in_dev)->cnf.accept_redirects))) > > #define IN_DEV_ARPFILTER(in_dev) (ipv4_devconf.arp_filter || (in_dev)->cnf.arp_filter) > +#define IN_DEV_LOOP(in_dev) ((in_dev)->cnf.loop) > > struct in_ifaddr > { > diff -ur v2.5.73/linux/include/linux/sysctl.h linux/include/linux/sysctl.h > --- v2.5.73/linux/include/linux/sysctl.h Sun Jun 15 10:25:03 2003 > +++ linux/include/linux/sysctl.h Mon Jun 30 23:47:14 2003 > @@ -359,6 +359,7 @@ > NET_IPV4_CONF_MEDIUM_ID=14, > NET_IPV4_CONF_NOXFRM=15, > NET_IPV4_CONF_NOPOLICY=16, > + NET_IPV4_CONF_LOOP=17, > }; > > /* /proc/sys/net/ipv6 */ > diff -ur v2.5.73/linux/net/ipv4/devinet.c linux/net/ipv4/devinet.c > --- v2.5.73/linux/net/ipv4/devinet.c Sun Jun 15 10:25:07 2003 > +++ linux/net/ipv4/devinet.c Mon Jun 30 23:49:26 2003 > @@ -1122,7 +1122,7 @@ > > static struct devinet_sysctl_table { > struct ctl_table_header *sysctl_header; > - ctl_table devinet_vars[17]; > + ctl_table devinet_vars[18]; > ctl_table devinet_dev[2]; > ctl_table devinet_conf_dir[2]; > ctl_table devinet_proto_dir[2]; > @@ -1258,6 +1258,14 @@ > .mode = 0644, > .proc_handler = &ipv4_doint_and_flush, > .strategy = &ipv4_doint_and_flush_strategy, > + }, > + { > + .ctl_name = NET_IPV4_CONF_LOOP, > + .procname = "loop", > + .data = &ipv4_devconf.loop, > + .maxlen = sizeof(int), > + .mode = 0644, > + .proc_handler = &proc_dointvec, > }, > }, > .devinet_dev = { > diff -ur v2.5.73/linux/net/ipv4/fib_frontend.c linux/net/ipv4/fib_frontend.c > --- v2.5.73/linux/net/ipv4/fib_frontend.c Wed May 28 00:02:50 2003 > +++ linux/net/ipv4/fib_frontend.c Mon Jun 30 23:52:38 2003 > @@ -167,15 +167,16 @@ > .tos = tos } }, > .iif = oif }; > struct fib_result res; > - int no_addr, rpf; > + int no_addr, rpf, loop; > int ret; > > - no_addr = rpf = 0; > + no_addr = rpf = loop = 0; > read_lock(&inetdev_lock); > in_dev = __in_dev_get(dev); > if (in_dev) { > no_addr = in_dev->ifa_list == NULL; > rpf = IN_DEV_RPFILTER(in_dev); > + loop = IN_DEV_LOOP(in_dev); > } > read_unlock(&inetdev_lock); > > @@ -184,6 +185,11 @@ > > if (fib_lookup(&fl, &res)) > goto last_resort; > + if (loop && res.type == RTN_LOCAL) { > + *spec_dst = FIB_RES_PREFSRC(res); > + fib_res_put(&res); > + return 0; > + } > if (res.type != RTN_UNICAST) > goto e_inval_res; > *spec_dst = FIB_RES_PREFSRC(res); > diff -ur v2.5.73/linux/net/ipv4/route.c linux/net/ipv4/route.c > --- v2.5.73/linux/net/ipv4/route.c Tue Jun 17 21:39:39 2003 > +++ linux/net/ipv4/route.c Tue Jul 1 00:29:05 2003 > @@ -1967,6 +1967,11 @@ > dev_put(dev_out); > goto out; /* Wrong error code */ > } > + err = -ENETDOWN; > + if (!(dev_out->flags&IFF_UP)) { > + dev_put(dev_out); > + goto out; > + } > > if (LOCAL_MCAST(oldflp->fl4_dst) || oldflp->fl4_dst == 0xFFFFFFFF) { > if (!fl.fl4_src) > @@ -2036,10 +2041,41 @@ > goto e_inval; > > if (res.type == RTN_LOCAL) { > - if (!fl.fl4_src) > - fl.fl4_src = fl.fl4_dst; > + struct in_device *in_dev; > + u32 src; > + > if (dev_out) > dev_put(dev_out); > + dev_out = FIB_RES_DEV(res); > + in_dev = in_dev_get(dev_out); > + src = fl.fl4_src? : FIB_RES_PREFSRC(res); > + if (in_dev && IN_DEV_LOOP(in_dev) && src) { > + struct net_device *dev_src; > + > + in_dev_put(in_dev); > + in_dev = NULL; > + dev_src = ip_dev_find(src); > + if (dev_src && dev_src != dev_out && > + (in_dev = in_dev_get(dev_src)) && > + IN_DEV_LOOP(in_dev)) { > + in_dev_put(in_dev); > + dev_out = dev_src; > + fl.fl4_src = src; > + fl.oif = dev_out->ifindex; > + res.type = RTN_UNICAST; > + if (res.fi) { > + fib_info_put(res.fi); > + res.fi = NULL; > + } > + goto make_route; > + } > + if (dev_src) > + dev_put(dev_src); > + } > + if (in_dev) > + in_dev_put(in_dev); > + if (!fl.fl4_src) > + fl.fl4_src = fl.fl4_dst; > dev_out = &loopback_dev; > dev_hold(dev_out); > fl.oif = dev_out->ifindex; -- James R. Leu From anton@samba.org Thu Aug 28 11:47:47 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Aug 2003 11:48:21 -0700 (PDT) Received: from lists.samba.org (dp.samba.org [66.70.73.150]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7SIlaWZ014784 for ; Thu, 28 Aug 2003 11:47:37 -0700 Received: by lists.samba.org (Postfix, from userid 504) id 7C7E02C141; Thu, 28 Aug 2003 18:01:21 +0000 (GMT) Date: Fri, 29 Aug 2003 04:00:19 +1000 From: Anton Blanchard To: netdev@oss.sgi.com Subject: 100 network limit Message-ID: <20030828180019.GH12541@krispykreme> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-archive-position: 5348 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: anton@samba.org Precedence: bulk X-list: netdev Content-Length: 1137 Lines: 32 Hi, We hit the 100 network naming limit :) Yes the comment is correct, we need to fix the algorithm. dev_base_lock really starts to show up (eg in dev_get_by_index), especially when doing IO to raw sockets (does every packet to a raw socket result in a dev_get_by_index? Couldnt we embed a pointer to the device in the socket?) Anyway as a short term fix Jamal suggested making a sysctl for this maximum. If fixing this all properly is out of the question for 2.6, would the sysctl approach be satisfactory? The other option is to just bump the limit and recognise that the user is on his own if performance sucks. Anton diff -ru gr14/net/core/dev.c gr14_work/net/core/dev.c --- gr14/net/core/dev.c 2003-08-18 13:40:43.000000000 -0500 +++ gr14_work/net/core/dev.c 2003-08-28 12:56:45.000000000 -0500 @@ -630,9 +630,9 @@ return -EINVAL; /* - * If you need over 100 please also fix the algorithm... + * If you need over 200 please also fix the algorithm... */ - for (i = 0; i < 100; i++) { + for (i = 0; i < 200; i++) { snprintf(buf, sizeof(buf), name, i); if (!__dev_get_by_name(buf)) { strcpy(dev->name, buf); From ak@suse.de Thu Aug 28 12:09:04 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Aug 2003 12:09:37 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7SJ92WZ016290 for ; Thu, 28 Aug 2003 12:09:03 -0700 Received: from Hermes.suse.de (Hermes.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 63589157860B; Thu, 28 Aug 2003 21:08:56 +0200 (CEST) Date: Thu, 28 Aug 2003 21:08:55 +0200 From: Andi Kleen To: Anton Blanchard Cc: netdev@oss.sgi.com Subject: Re: 100 network limit Message-Id: <20030828210855.58759b69.ak@suse.de> In-Reply-To: <20030828180019.GH12541@krispykreme> References: <20030828180019.GH12541@krispykreme> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5349 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 525 Lines: 14 On Fri, 29 Aug 2003 04:00:19 +1000 Anton Blanchard wrote: > Anyway as a short term fix Jamal suggested making a sysctl for this > maximum. If fixing this all properly is out of the question for 2.6, > would the sysctl approach be satisfactory? The other option is to just > bump the limit and recognise that the user is on his own if performance > sucks. You could just add a bitmap with a reasonable upper limit (1024?) and use find_first_zero_bit() I doubt doing that would be very intrusive. -Andi From jgarzik@pobox.com Thu Aug 28 14:01:17 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Aug 2003 14:01:21 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7SL1GWZ022290 for ; Thu, 28 Aug 2003 14:01:17 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:33222 helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.22) id 19sTtK-0006bu-QS; Thu, 28 Aug 2003 22:01:14 +0100 Message-ID: <3F4E6D8F.6070003@pobox.com> Date: Thu, 28 Aug 2003 17:01:03 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: smarchetto1@tin.it CC: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: NAPI on 8139too References: <1062094999.3149.33.camel@localhost> In-Reply-To: <1062094999.3149.33.camel@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5350 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 Content-Length: 446 Lines: 15 Michele 'mydecay' Marchetto wrote: > I was wondering why NAPI hasn't been ported on 8139too yet.. I think it would be a good idea. You can stuff a lot of 68-byte packets into a 32K or 64K contiguous buffer. Jes Sorensen wrote a patch a while ago that sampling the incoming rate, and backed off if the rate was too high -- basically a poor man's NAPI. So, volunteers? Just convert the RX path to NAPI, not all interrupt events. Jeff From bos@keyresearch.com Thu Aug 28 14:21:58 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Aug 2003 14:22:32 -0700 (PDT) Received: from mail.keyresearch.com (64.221.211.208.ptr.us.xo.net [64.221.211.208]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7SLLvWZ023644 for ; Thu, 28 Aug 2003 14:21:58 -0700 Received: (qmail 11632 invoked from network); 28 Aug 2003 21:21:52 -0000 Received: from serpentine.internal.keyresearch.com (192.168.3.63) by fileserver.internal.keyresearch.com with SMTP; 28 Aug 2003 21:21:52 -0000 Subject: [ANNOUNCE] netplug, a daemon that handles network cables getting plugged in and out From: "Bryan O'Sullivan" To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Content-Type: text/plain Message-Id: <1062105712.12285.78.camel@serpentine.internal.keyresearch.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 28 Aug 2003 14:21:52 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 5351 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bos@keyresearch.com Precedence: bulk X-list: netdev Content-Length: 355 Lines: 10 Netplug is a daemon that responds to network cables being plugged in or out by bringing a network interface up or down. This is extremely useful for DHCP-managed systems that move around a lot, such as laptops and systems in cluster environments. For more details and download instructions, see the netplug homepage: http://www.red-bean.com/~bos/ ; Thu, 28 Aug 2003 14:36:02 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:33236 helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.22) id 19sUQy-0007EZ-1t; Thu, 28 Aug 2003 22:36:00 +0100 Message-ID: <3F4E75B5.4020401@pobox.com> Date: Thu, 28 Aug 2003 17:35:49 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: "Bryan O'Sullivan" CC: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [ANNOUNCE] netplug, a daemon that handles network cables getting plugged in and out References: <1062105712.12285.78.camel@serpentine.internal.keyresearch.com> In-Reply-To: <1062105712.12285.78.camel@serpentine.internal.keyresearch.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5352 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 Content-Length: 469 Lines: 16 Bryan O'Sullivan wrote: > Netplug is a daemon that responds to network cables being plugged in or > out by bringing a network interface up or down. This is extremely > useful for DHCP-managed systems that move around a lot, such as laptops > and systems in cluster environments. > > For more details and download instructions, see the netplug homepage: > http://www.red-bean.com/~bos/ Does it make use of the link status notification stuff in 2.6.x? ;-) Jeff From hch@infradead.org Thu Aug 28 14:46:57 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Aug 2003 14:47:31 -0700 (PDT) Received: from phoenix.infradead.org (pub234.cambridge.redhat.com [213.86.99.234] (may be forged)) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7SLkuWZ025411 for ; Thu, 28 Aug 2003 14:46:57 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.22) id 19sUbU-0003P6-Gv; Thu, 28 Aug 2003 22:46:52 +0100 Date: Thu, 28 Aug 2003 22:46:52 +0100 From: Christoph Hellwig To: "Bryan O'Sullivan" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [ANNOUNCE] netplug, a daemon that handles network cables getting plugged in and out Message-ID: <20030828224652.A13004@infradead.org> Mail-Followup-To: Christoph Hellwig , Bryan O'Sullivan , linux-kernel@vger.kernel.org, netdev@oss.sgi.com References: <1062105712.12285.78.camel@serpentine.internal.keyresearch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1062105712.12285.78.camel@serpentine.internal.keyresearch.com>; from bos@keyresearch.com on Thu, Aug 28, 2003 at 02:21:52PM -0700 X-archive-position: 5354 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev Content-Length: 375 Lines: 8 On Thu, Aug 28, 2003 at 02:21:52PM -0700, Bryan O'Sullivan wrote: > Netplug is a daemon that responds to network cables being plugged in or > out by bringing a network interface up or down. This is extremely > useful for DHCP-managed systems that move around a lot, such as laptops > and systems in cluster environments. What's the difference to / advantage over ifplugd? From greearb@candelatech.com Thu Aug 28 14:46:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Aug 2003 14:47:18 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-084.evrtwa1.dsl-verizon.net [4.33.45.84]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7SLkjWZ025394 for ; Thu, 28 Aug 2003 14:46:45 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h7SLkdx0003116; Thu, 28 Aug 2003 14:46:39 -0700 Message-ID: <3F4E783F.6080707@candelatech.com> Date: Thu, 28 Aug 2003 14:46:39 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: Anton Blanchard , netdev@oss.sgi.com Subject: Re: 100 network limit References: <20030828180019.GH12541@krispykreme> <20030828210855.58759b69.ak@suse.de> In-Reply-To: <20030828210855.58759b69.ak@suse.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5353 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 1102 Lines: 32 Andi Kleen wrote: > On Fri, 29 Aug 2003 04:00:19 +1000 > Anton Blanchard wrote: > > > >>Anyway as a short term fix Jamal suggested making a sysctl for this >>maximum. If fixing this all properly is out of the question for 2.6, >>would the sysctl approach be satisfactory? The other option is to just >>bump the limit and recognise that the user is on his own if performance >>sucks. > > > You could just add a bitmap with a reasonable upper limit (1024?) and use > find_first_zero_bit() I doubt doing that would be very intrusive. > > -Andi Since you can rename devices, that might not work. A long time ago I hashed the devices, both by name and by index...that gives good lookup performance, at least. As for create-time issues, that is definately slow path, and even searching linearly 4 or 8k devices is not a big deal (in my opinion). So, why not make the hard-coded 100 limit be more like 8196 or something really large? (It could still be adjustable if needed.) Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From bos@keyresearch.com Thu Aug 28 14:50:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Aug 2003 14:50:55 -0700 (PDT) Received: from mail.keyresearch.com (64.221.211.208.ptr.us.xo.net [64.221.211.208]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7SLoLWZ026185 for ; Thu, 28 Aug 2003 14:50:21 -0700 Received: (qmail 12458 invoked from network); 28 Aug 2003 21:50:16 -0000 Received: from serpentine.internal.keyresearch.com (192.168.3.63) by fileserver.internal.keyresearch.com with SMTP; 28 Aug 2003 21:50:16 -0000 Subject: Re: [ANNOUNCE] netplug, a daemon that handles network cables getting plugged in and out From: "Bryan O'Sullivan" To: Christoph Hellwig Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <20030828224652.A13004@infradead.org> References: <1062105712.12285.78.camel@serpentine.internal.keyresearch.com> <20030828224652.A13004@infradead.org> Content-Type: text/plain Message-Id: <1062107416.12285.87.camel@serpentine.internal.keyresearch.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 28 Aug 2003 14:50:16 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 5355 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bos@keyresearch.com Precedence: bulk X-list: netdev Content-Length: 201 Lines: 9 On Thu, 2003-08-28 at 14:46, Christoph Hellwig wrote: > What's the difference to / advantage over ifplugd? They're about the same, but I didn't know of the existence of ifplugd until just now. ; Thu, 28 Aug 2003 14:54:26 -0700 Received: from werewolf.able.es ([212.97.178.242]) by aneto.able.es (Netscape Messaging Server 4.15 aneto Mar 14 2002 21:29:48) with ESMTP id HKCQ5Y02.4EJ; Thu, 28 Aug 2003 23:51:34 +0100 Date: Thu, 28 Aug 2003 23:54:17 +0200 From: "J.A. Magallon" To: "Bryan O'Sullivan" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [ANNOUNCE] netplug, a daemon that handles network cables getting plugged in and out Message-ID: <20030828215417.GA22215@werewolf.able.es> References: <1062105712.12285.78.camel@serpentine.internal.keyresearch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1062105712.12285.78.camel@serpentine.internal.keyresearch.com>; from bos@keyresearch.com on Thu, Aug 28, 2003 at 23:21:52 +0200 X-Mailer: Balsa 2.0.14 X-archive-position: 5356 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jamagallon@able.es Precedence: bulk X-list: netdev Content-Length: 794 Lines: 22 On 08.28, Bryan O'Sullivan wrote: > Netplug is a daemon that responds to network cables being plugged in or > out by bringing a network interface up or down. This is extremely > useful for DHCP-managed systems that move around a lot, such as laptops > and systems in cluster environments. > > For more details and download instructions, see the netplug homepage: > http://www.red-bean.com/~bos/ > I feel sorry, but did you ever knew this existed ? http://www.stud.uni-hamburg.de/users/lennart/projects/ifplugd/ :( -- J.A. Magallon \ Software is like sex: werewolf.able.es \ It's better when it's free Mandrake Linux release 9.2 (Cooker) for i586 Linux 2.4.22-jam1m (gcc 3.3.1 (Mandrake Linux 9.2 3.3.1-1mdk)) From jamagallon@able.es Thu Aug 28 15:46:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Aug 2003 15:46:39 -0700 (PDT) Received: from aneto.able.es (aneto.able.es [212.97.163.22]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7SMjxWZ031311 for ; Thu, 28 Aug 2003 15:46:02 -0700 Received: from werewolf.able.es ([212.97.178.242]) by aneto.able.es (Netscape Messaging Server 4.15 aneto Mar 14 2002 21:29:48) with ESMTP id HKCSJX00.NEK; Fri, 29 Aug 2003 00:43:09 +0100 Date: Fri, 29 Aug 2003 00:45:53 +0200 From: "J.A. Magallon" To: Jeff Garzik Cc: "J.A. Magallon" , "Bryan O'Sullivan" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [ANNOUNCE] netplug, a daemon that handles network cables getting plugged in and out Message-ID: <20030828224553.GC23528@werewolf.able.es> References: <1062105712.12285.78.camel@serpentine.internal.keyresearch.com> <20030828215417.GA22215@werewolf.able.es> <3F4E8373.1040204@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3F4E8373.1040204@pobox.com>; from jgarzik@pobox.com on Fri, Aug 29, 2003 at 00:34:27 +0200 X-Mailer: Balsa 2.0.14 X-archive-position: 5357 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jamagallon@able.es Precedence: bulk X-list: netdev Content-Length: 1992 Lines: 60 On 08.29, Jeff Garzik wrote: > J.A. Magallon wrote: > > On 08.28, Bryan O'Sullivan wrote: > > > >>Netplug is a daemon that responds to network cables being plugged in or > >>out by bringing a network interface up or down. This is extremely > >>useful for DHCP-managed systems that move around a lot, such as laptops > >>and systems in cluster environments. > >> > >>For more details and download instructions, see the netplug homepage: > >>http://www.red-bean.com/~bos/ > >> > > > > > > I feel sorry, but did you ever knew this existed ? > > > > http://www.stud.uni-hamburg.de/users/lennart/projects/ifplugd/ > > > ifplugd doesn't appear to use netlink. Did I miss something? > > netlink is definitely the preferred way to get link notification. Maybe > the two authors can work together to merge the best parts of both... > That would be very nice, but there is still a problem. Does netlink solve the fact that there are cards (at least in 2.4) that do not support any detection method: ne2k-pci SIOCETHTOOL failed (Operation not permitted) SIOCGMIIPHY failed (Operation not permitted) SIOCDEVPRIVATE failed (Operation not supported) 3c59x (3c980-TX) SIOCETHTOOL failed (Operation not permitted) SIOCGMIIPHY failed (Operation not permitted) SIOCDEVPRIVATE: unplugged 3c59x (3c905C-TX/TX-M) SIOCETHTOOL failed (Operation not supported) SIOCGMIIPHY: link beat detected SIOCDEVPRIVATE: link beat detected e100 SIOCETHTOOL: link beat detected SIOCGMIIPHY: link beat detected SIOCDEVPRIVATE failed (Operation not supported) e1000 SIOCETHTOOL: link beat detected SIOCGMIIPHY: link beat detected SIOCDEVPRIVATE failed (Operation not supported) -- J.A. Magallon \ Software is like sex: werewolf.able.es \ It's better when it's free Mandrake Linux release 9.2 (Cooker) for i586 Linux 2.4.22-jam1m (gcc 3.3.1 (Mandrake Linux 9.2 3.3.1-1mdk)) From bos@keyresearch.com Thu Aug 28 15:49:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Aug 2003 15:49:59 -0700 (PDT) Received: from mail.keyresearch.com (64.221.211.208.ptr.us.xo.net [64.221.211.208]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7SMnQWZ031761 for ; Thu, 28 Aug 2003 15:49:26 -0700 Received: (qmail 14258 invoked from network); 28 Aug 2003 22:49:21 -0000 Received: from serpentine.internal.keyresearch.com (192.168.3.63) by fileserver.internal.keyresearch.com with SMTP; 28 Aug 2003 22:49:21 -0000 Subject: Re: [ANNOUNCE] netplug, a daemon that handles network cables getting plugged in and out From: "Bryan O'Sullivan" To: "J.A. Magallon" Cc: Jeff Garzik , linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <20030828224553.GC23528@werewolf.able.es> References: <1062105712.12285.78.camel@serpentine.internal.keyresearch.com> <20030828215417.GA22215@werewolf.able.es> <3F4E8373.1040204@pobox.com> <20030828224553.GC23528@werewolf.able.es> Content-Type: text/plain Message-Id: <1062110960.12285.94.camel@serpentine.internal.keyresearch.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 28 Aug 2003 15:49:21 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 5358 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bos@keyresearch.com Precedence: bulk X-list: netdev Content-Length: 416 Lines: 12 On Thu, 2003-08-28 at 15:45, J.A. Magallon wrote: > That would be very nice, but there is still a problem. > Does netlink solve the fact that there are cards (at least in 2.4) > that do not support any detection method: netlink doesn't work through the ioctl interface at all. If a card is capable of reporting that its flags include IFF_UP or IFF_RUNNING via the netlink interface, then netplug will work. ; Thu, 28 Aug 2003 16:21:34 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:33253 helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.22) id 19sVLl-0007si-GQ; Thu, 28 Aug 2003 23:34:41 +0100 Message-ID: <3F4E8373.1040204@pobox.com> Date: Thu, 28 Aug 2003 18:34:27 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: "J.A. Magallon" CC: "Bryan O'Sullivan" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [ANNOUNCE] netplug, a daemon that handles network cables getting plugged in and out References: <1062105712.12285.78.camel@serpentine.internal.keyresearch.com> <20030828215417.GA22215@werewolf.able.es> In-Reply-To: <20030828215417.GA22215@werewolf.able.es> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5359 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 Content-Length: 771 Lines: 27 J.A. Magallon wrote: > On 08.28, Bryan O'Sullivan wrote: > >>Netplug is a daemon that responds to network cables being plugged in or >>out by bringing a network interface up or down. This is extremely >>useful for DHCP-managed systems that move around a lot, such as laptops >>and systems in cluster environments. >> >>For more details and download instructions, see the netplug homepage: >>http://www.red-bean.com/~bos/ >> > > > I feel sorry, but did you ever knew this existed ? > > http://www.stud.uni-hamburg.de/users/lennart/projects/ifplugd/ ifplugd doesn't appear to use netlink. Did I miss something? netlink is definitely the preferred way to get link notification. Maybe the two authors can work together to merge the best parts of both... Jeff From davem@pizda.ninka.net Thu Aug 28 16:50:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Aug 2003 16:50:48 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7SNoEWZ004449 for ; Thu, 28 Aug 2003 16:50:15 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id QAA28287; Thu, 28 Aug 2003 16:41:43 -0700 Date: Thu, 28 Aug 2003 16:41:43 -0700 From: "David S. Miller" To: Ben Greear Cc: ak@suse.de, anton@samba.org, netdev@oss.sgi.com Subject: Re: 100 network limit Message-Id: <20030828164143.536d8d8a.davem@redhat.com> In-Reply-To: <3F4E783F.6080707@candelatech.com> References: <20030828180019.GH12541@krispykreme> <20030828210855.58759b69.ak@suse.de> <3F4E783F.6080707@candelatech.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5360 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 Content-Length: 693 Lines: 18 On Thu, 28 Aug 2003 14:46:39 -0700 Ben Greear wrote: > Since you can rename devices, that might not work. A long time ago > I hashed the devices, both by name and by index...that gives good > lookup performance, at least. As for create-time issues, that is > definately slow path, and even searching linearly 4 or 8k devices is > not a big deal (in my opinion). So, why not make the hard-coded 100 > limit be more like 8196 or something really large? (It could still > be adjustable if needed.) Right, it's also not going to fix the locking problems. I would suggest two things: 1) Ben's hashing patch for lookups. 2) RCU'ing read access to the device list. From ak@suse.de Thu Aug 28 17:03:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Aug 2003 17:04:25 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7T03mWZ005680 for ; Thu, 28 Aug 2003 17:03:49 -0700 Received: from Hermes.suse.de (Hermes.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 68A0F157AB0A; Fri, 29 Aug 2003 02:03:42 +0200 (CEST) Date: Fri, 29 Aug 2003 02:03:41 +0200 From: Andi Kleen To: Ben Greear Cc: anton@samba.org, netdev@oss.sgi.com Subject: Re: 100 network limit Message-Id: <20030829020341.706356e7.ak@suse.de> In-Reply-To: <3F4E783F.6080707@candelatech.com> References: <20030828180019.GH12541@krispykreme> <20030828210855.58759b69.ak@suse.de> <3F4E783F.6080707@candelatech.com> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5361 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 395 Lines: 13 On Thu, 28 Aug 2003 14:46:39 -0700 Ben Greear wrote: > > Since you can rename devices, that might not work. When someone renames eth1 to eth2 and the bitmap doesn't have eth2 set and selects it then you can just retry, searching for further free bits. When someone renames eth2 to eth1 the rename code should just clear the bit of eth2 before the rename. -Andi From aaronl@vitelus.com Thu Aug 28 17:36:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Aug 2003 17:37:06 -0700 (PDT) Received: from vitelus.com (mail@vitelus.com [64.81.243.207]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7T0aWWZ008054 for ; Thu, 28 Aug 2003 17:36:32 -0700 Received: from aaronl by vitelus.com with local (Exim 4.20 #1 (Debian)) id 19sXDe-0002W6-OC; Thu, 28 Aug 2003 17:34:26 -0700 Date: Thu, 28 Aug 2003 17:34:26 -0700 From: Aaron Lehmann To: "Bryan O'Sullivan" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [ANNOUNCE] netplug, a daemon that handles network cables getting plugged in and out Message-ID: <20030829003426.GF12249@vitelus.com> References: <1062105712.12285.78.camel@serpentine.internal.keyresearch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1062105712.12285.78.camel@serpentine.internal.keyresearch.com> User-Agent: Mutt/1.5.4i X-archive-position: 5362 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: aaronl@vitelus.com Precedence: bulk X-list: netdev Content-Length: 776 Lines: 14 On Thu, Aug 28, 2003 at 02:21:52PM -0700, Bryan O'Sullivan wrote: > Netplug is a daemon that responds to network cables being plugged in or > out by bringing a network interface up or down. This is extremely > useful for DHCP-managed systems that move around a lot, such as laptops > and systems in cluster environments. > > For more details and download instructions, see the netplug homepage: > http://www.red-bean.com/~bos/ Thank you, thank you, thank you. I was just thinking today how annoying it is that whenever I boot up my laptop, dhclient runs and tries to get an IP address on the ethernet interface until it's ^C'd. Since I often use the Ethernet interface this is not a bad default, but dhclient can't even realize on its own that there's no cable plugged in. From dhollis@davehollis.com Thu Aug 28 19:11:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Aug 2003 19:12:09 -0700 (PDT) Received: from bender.davehollis.com (user-0cal2fl.cable.mindspring.com [24.170.137.245]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7T2BXWZ013211 for ; Thu, 28 Aug 2003 19:11:34 -0700 Received: from davehollis.com ([192.168.1.189]) (authenticated bits=0) by bender.davehollis.com (8.12.8/8.12.8) with ESMTP id h7T2BPxW019121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Aug 2003 22:11:28 -0400 Message-ID: <3F4EB641.3040107@davehollis.com> Date: Thu, 28 Aug 2003 22:11:13 -0400 From: David T Hollis User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aaron Lehmann CC: "Bryan O'Sullivan" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [ANNOUNCE] netplug, a daemon that handles network cables getting plugged in and out References: <1062105712.12285.78.camel@serpentine.internal.keyresearch.com> <20030829003426.GF12249@vitelus.com> In-Reply-To: <20030829003426.GF12249@vitelus.com> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-archive-position: 5363 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dhollis@davehollis.com Precedence: bulk X-list: netdev Content-Length: 1343 Lines: 32 Aaron Lehmann wrote: >On Thu, Aug 28, 2003 at 02:21:52PM -0700, Bryan O'Sullivan wrote: > > >>Netplug is a daemon that responds to network cables being plugged in or >>out by bringing a network interface up or down. This is extremely >>useful for DHCP-managed systems that move around a lot, such as laptops >>and systems in cluster environments. >> >>For more details and download instructions, see the netplug homepage: >>http://www.red-bean.com/~bos/ >> >> > >Thank you, thank you, thank you. I was just thinking today how >annoying it is that whenever I boot up my laptop, dhclient runs and tries >to get an IP address on the ethernet interface until it's ^C'd. Since >I often use the Ethernet interface this is not a bad default, but dhclient >can't even realize on its own that there's no cable plugged in. >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ > > Hmm, that seems to raise the question - why doesn't dhclient just handle that? On a DHCP interface, it's running anyway. if it paid attention to link status, it would know when to re-request an IP. If you are statically assigned, you don't really care anyway. From greearb@candelatech.com Thu Aug 28 20:45:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 28 Aug 2003 20:46:03 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-084.evrtwa1.dsl-verizon.net [4.33.45.84]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7T3jSWZ017920 for ; Thu, 28 Aug 2003 20:45:28 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h7T3jMFo005968; Thu, 28 Aug 2003 20:45:22 -0700 Message-ID: <3F4ECC52.5000406@candelatech.com> Date: Thu, 28 Aug 2003 20:45:22 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: ak@suse.de, anton@samba.org, netdev@oss.sgi.com Subject: Re: 100 network limit References: <20030828180019.GH12541@krispykreme> <20030828210855.58759b69.ak@suse.de> <3F4E783F.6080707@candelatech.com> <20030828164143.536d8d8a.davem@redhat.com> In-Reply-To: <20030828164143.536d8d8a.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5364 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 1184 Lines: 39 David S. Miller wrote: > On Thu, 28 Aug 2003 14:46:39 -0700 > Ben Greear wrote: > > >>Since you can rename devices, that might not work. A long time ago >>I hashed the devices, both by name and by index...that gives good >>lookup performance, at least. As for create-time issues, that is >>definately slow path, and even searching linearly 4 or 8k devices is >>not a big deal (in my opinion). So, why not make the hard-coded 100 >>limit be more like 8196 or something really large? (It could still >>be adjustable if needed.) > > > Right, it's also not going to fix the locking problems. > > I would suggest two things: > > 1) Ben's hashing patch for lookups. > > 2) RCU'ing read access to the device list. > I'm at least mostly on vacation for a week or so... Here is a pointer to the old patch I did..but it's ~2.5 years old. If anyone wants to get it working with recent code, please be my guest. Otherwise, I'll try to get something together in a few weeks. http://www.cs.helsinki.fi/linux/linux-kernel/2001-00/1227.html Take it easy, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From zrzeng@linuxforum.net Fri Aug 29 01:19:10 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Aug 2003 01:19:42 -0700 (PDT) Received: from ftp.linuxforum.net (branch-2-h194.sta.net.cn [61.152.210.194] (may be forged)) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7T8J8WZ002637 for ; Fri, 29 Aug 2003 01:19:09 -0700 Received: from 218.95.29.1 (HELO homepc) (envelope-from zrzeng@linuxforum.net) by ftp.linuxforum.net (quarkmail-1.2.1) with SMTP id S4556817AbTH2IK4 for netdev@oss.sgi.com; Fri, 29 Aug 2003 16:10:56 +0800 Message-ID: <001901c36e08$4fa4cce0$0301a8c0@homepc> From: "John Zeng" To: Subject: Please help, Two simple questions regarding Linux TCP codes Date: Fri, 29 Aug 2003 16:34:06 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-archive-position: 5365 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zrzeng@linuxforum.net Precedence: bulk X-list: netdev Content-Length: 1771 Lines: 53 Hi, all, I am a pretty newbie in Linux TCP codes, now I know the overall operation of the Linux TCP codes, but some details has really confused me for a long time, would anyone there please kindly help me? thank you very much. ------------------------------------- Q.1) in tcp_input.c, there is a function called tcp_check_reno_reordering(), as following: static void tcp_check_reno_reordering(struct tcp_opt *tp, int addend) { u32 holes; holes = max(tp->lost_out, 1U); holes = min(holes, tp->packets_out); if (tp->sacked_out + holes > tp->packets_out) { tp->sacked_out = tp->packets_out - holes; tcp_update_reordering(tp, tp->packets_out+addend, 0); } } In my imagination, only when segments are duplicated in the network, will the statement "tp->sacked_out + holes > tp->packets_out" be true. but because the function name shows that it is related to reordering, I must have missed some important points, could you please tell me what is the situation? i.e. in what reordering circumstances will "tp->sacked_out + holes > tp->packets_out" be true? ------------------------------- Q.2)what is the rationale behind of the function _tcp_grow_window()? to be more specific, what is the rationale of the while loop? i.e. why can we judge that when "truesize <= skb->len" is true, we can increase the window by 2*tp->ack.rcv_mss? static int __tcp_grow_window(struct sock *sk, struct tcp_opt *tp, struct sk_buff *skb) { /* Optimize this! */ int truesize = tcp_win_from_space(skb->truesize)/2; int window = tcp_full_space(sk)/2; while (tp->rcv_ssthresh <= window) { if (truesize <= skb->len) return 2*tp->ack.rcv_mss; truesize >>= 1; window >>= 1; } return 0; } From P@draigBrady.com Fri Aug 29 03:18:43 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Aug 2003 03:19:16 -0700 (PDT) Received: from corvil.com (gate.corvil.net [213.94.219.177]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7TAIfWZ012453 for ; Fri, 29 Aug 2003 03:18:43 -0700 Received: from draigBrady.com (pixelbeat.local.corvil.com [172.18.1.170]) by corvil.com (8.12.9/8.12.5) with ESMTP id h7TAIdxe091120 for ; Fri, 29 Aug 2003 11:18:40 +0100 (IST) (envelope-from P@draigBrady.com) Message-ID: <3F4F280E.1020507@draigBrady.com> Date: Fri, 29 Aug 2003 11:16:46 +0100 From: P@draigBrady.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: e100 NAPI performance Content-Type: text/plain; charset=ISO-8859-15; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by corvil.com id h7TAIdxe091120 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7TAIfWZ012453 X-archive-position: 5367 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: P@draigBrady.com Precedence: bulk X-list: netdev Content-Length: 946 Lines: 39 Hi, I didn't get any feedback on the following mail. Also in case this patch wasn't noticed, I think it's a no brainer to apply? http://tardis.linux.ie/1637/sourceforge.net cheers, Pádraig. -------- Original Message -------- Subject: e100 NAPI performance Date: Mon, 25 Aug 2003 14:12:05 +0100 From: P@draigBrady.com To: e1000-devel@lists.sourceforge.net Hi, I'm testing the latest e100 driver (3.0.0_dev13) in a device here that is purely used to capture traffic, and I'm testing with 64 byte packets. I've turned on NAPI and can recv up to 120K packets/s fine. (btw the driver without NAPI is fine up to 101K packets/s). Above this though the packet capture rate actually decreases At 130K packets/s only 110K/s are received, and 16K/s are rx fifo overruns. I thought NAPI was supposed to keep a bound on the worst case? any advice on improving performance like ethtool params or something? CPU is 1.2GHz PIII linux kernel is 2.4.20 From chas@cmf.nrl.navy.mil Fri Aug 29 08:49:48 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Aug 2003 08:50:20 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7TFnlWZ000652 for ; Fri, 29 Aug 2003 08:49:47 -0700 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.7/8.12.7) with ESMTP id h7TFngl5014364 for ; Fri, 29 Aug 2003 11:49:42 -0400 (EDT) Message-Id: <200308291549.h7TFngl5014364@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Subject: forcing bottom half to a specific processor on numa Reply-To: chas3@users.sourceforge.net Date: Fri, 29 Aug 2003 11:49:43 -0400 From: chas williams X-Spam-Score: (**) hits=2.5 X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 5370 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 964 Lines: 28 for my network card (its an atm card but that really doesnt matter in this case since the work done is fundamentally very similar) on a numa machine i would prefer that the bottom half processing happen on a processor that is 'local' (or atleast closer) to the card. primarily, so that any copies to/from the card and buffers that might allocated be given to card come from the memory on the processor to prevent undo traffic on the machine's interconnect. my particular h/w is the sn2. i do something like the following to force the tasklet be scheduled on the 'local' processor: ... he_dev->cnode = nasid_to_cnodeid(NASID_GET(he_dev->membase)); ... __tasklet_schedule(void *data) { struct he_dev *he_dev = (struct he_dev *) data; tasklet_schedule(&he_dev->tasklet); } he_irq_handler() { ... smp_call_function_single(he_dev->cnode, __tasklet_schedule, he_dev, 0, 0); ... } is there a reason i shouldnt do this? is there a better way? From bos@keyresearch.com Fri Aug 29 10:43:21 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Aug 2003 10:43:56 -0700 (PDT) Received: from mail.keyresearch.com (64.221.211.208.ptr.us.xo.net [64.221.211.208]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7THhJWZ009100 for ; Fri, 29 Aug 2003 10:43:20 -0700 Received: (qmail 4443 invoked from network); 29 Aug 2003 17:43:13 -0000 Received: from serpentine.internal.keyresearch.com (192.168.3.63) by fileserver.internal.keyresearch.com with SMTP; 29 Aug 2003 17:43:13 -0000 Subject: Re: [ANNOUNCE] netplug, a daemon that handles network cables getting plugged in and out From: "Bryan O'Sullivan" To: David T Hollis Cc: Aaron Lehmann , linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <3F4EB641.3040107@davehollis.com> References: <1062105712.12285.78.camel@serpentine.internal.keyresearch.com> <20030829003426.GF12249@vitelus.com> <3F4EB641.3040107@davehollis.com> Content-Type: text/plain Message-Id: <1062178992.12285.130.camel@serpentine.internal.keyresearch.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 29 Aug 2003 10:43:13 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 5371 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bos@keyresearch.com Precedence: bulk X-list: netdev Content-Length: 583 Lines: 17 On Thu, 2003-08-28 at 19:11, David T Hollis wrote: > Hmm, that seems to raise the question - why doesn't dhclient just handle > that? Because it has as little knowledge of how the OS works as possible. It's intended to run on all kinds of Unix platforms, not just Linux. > On a DHCP interface, it's running anyway. if it paid attention > to link status, it would know when to re-request an IP. There are no cross-platform standards for this kind of thing, so they'd need modules for Linux, FreeBSD, Solaris, AIX, etc., etc. I'm sure they'd be happy to accept patches. ; Fri, 29 Aug 2003 10:52:33 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7THqDo26781; Fri, 29 Aug 2003 10:52:13 -0700 Date: Fri, 29 Aug 2003 10:48:57 -0700 From: Stephen Hemminger To: Arnaldo Carvalho de Melo , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (2/3) llc - need to set owner on created sockets. Message-Id: <20030829104857.027a8c6f.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5374 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 539 Lines: 15 LLC needs to set owner field on sockets it creates, otherwise it is possible to remove module with detached sockets still outstanding. diff -Nru a/net/llc/llc_main.c b/net/llc/llc_main.c --- a/net/llc/llc_main.c Fri Aug 29 09:27:28 2003 +++ b/net/llc/llc_main.c Fri Aug 29 09:27:28 2003 @@ -229,6 +229,7 @@ if (llc_sk_init(sk)) goto outsk; sock_init_data(NULL, sk); + sk_set_owner(sk, THIS_MODULE); #ifdef LLC_REFCNT_DEBUG atomic_inc(&llc_sock_nr); printk(KERN_DEBUG "LLC socket %p created in %s, now we have %d alive\n", sk, From shemminger@osdl.org Fri Aug 29 10:52:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Aug 2003 10:53:07 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7THqWWZ009831 for ; Fri, 29 Aug 2003 10:52:33 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7THqDo26790; Fri, 29 Aug 2003 10:52:13 -0700 Date: Fri, 29 Aug 2003 10:51:40 -0700 From: Stephen Hemminger To: Arnaldo Carvalho de Melo , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (3/3) llc - set owner on /proc/net/llc directory Message-Id: <20030829105140.72c5fad3.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5373 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 503 Lines: 15 Owner field on /proc/net/llc directory needs to be set, otherwise badness if some application has directory open while module being unloaded. diff -Nru a/net/llc/llc_proc.c b/net/llc/llc_proc.c --- a/net/llc/llc_proc.c Fri Aug 29 09:27:45 2003 +++ b/net/llc/llc_proc.c Fri Aug 29 09:27:45 2003 @@ -245,6 +245,7 @@ llc_proc_dir = proc_mkdir("llc", proc_net); if (!llc_proc_dir) goto out; + llc_proc_dir->owner = THIS_MODULE; p = create_proc_entry("socket", S_IRUGO, llc_proc_dir); if (!p) From shemminger@osdl.org Fri Aug 29 10:52:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Aug 2003 10:53:07 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7THqWWZ009830 for ; Fri, 29 Aug 2003 10:52:33 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7THqCo26772; Fri, 29 Aug 2003 10:52:12 -0700 Date: Fri, 29 Aug 2003 10:47:13 -0700 From: Stephen Hemminger To: Arnaldo Carvalho de Melo , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (1/3) llc - need to may_pull header Message-Id: <20030829104713.1ae98328.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5372 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1507 Lines: 52 LLC needs to call may_pull before overlaying the header data structure. Otherwise there is no guarantee that the data isn't sitting in fragments. diff -Nru a/net/llc/llc_mac.c b/net/llc/llc_mac.c --- a/net/llc/llc_mac.c Fri Aug 29 09:02:19 2003 +++ b/net/llc/llc_mac.c Fri Aug 29 09:02:19 2003 @@ -35,7 +35,7 @@ u8 llc_mac_null_var[IFHWADDRLEN]; -static void fix_up_incoming_skb(struct sk_buff *skb); +static int fix_up_incoming_skb(struct sk_buff *skb); static void llc_station_rcv(struct sk_buff *skb); static void llc_sap_rcv(struct llc_sap *sap, struct sk_buff *skb); @@ -69,7 +69,8 @@ skb = skb_share_check(skb, GFP_ATOMIC); if (!skb) goto out; - fix_up_incoming_skb(skb); + if (!fix_up_incoming_skb(skb)) + goto drop; pdu = llc_pdu_sn_hdr(skb); if (!pdu->dsap) { /* NULL DSAP, refer to station */ dprintk("%s: calling llc_station_rcv!\n", __FUNCTION__); @@ -172,11 +173,15 @@ * by looking at the two lowest-order bits of the first control field * byte; field is either 3 or 4 bytes long. */ -static void fix_up_incoming_skb(struct sk_buff *skb) +static int fix_up_incoming_skb(struct sk_buff *skb) { u8 llc_len = 2; - struct llc_pdu_sn *pdu = (struct llc_pdu_sn *)skb->data; + struct llc_pdu_sn *pdu; + + if (!pskb_may_pull(skb, sizeof(*pdu))) + return 0; + pdu = (struct llc_pdu_sn *)skb->data; if ((pdu->ctrl_1 & LLC_PDU_TYPE_MASK) == LLC_PDU_TYPE_U) llc_len = 1; llc_len += 2; @@ -188,6 +193,7 @@ skb_trim(skb, data_size); } + return 1; } /* From shemminger@osdl.org Fri Aug 29 11:19:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Aug 2003 11:19:54 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7TIJLWZ012143 for ; Fri, 29 Aug 2003 11:19:21 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7TIJ9o03678; Fri, 29 Aug 2003 11:19:09 -0700 Date: Fri, 29 Aug 2003 11:18:55 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] econet - set socket owner field Message-Id: <20030829111855.1425b7aa.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5375 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 489 Lines: 14 All sockets created by a protocol need to have owner field set to prevent problems with orphaned sockets during module unload. diff -Nru a/net/econet/af_econet.c b/net/econet/af_econet.c --- a/net/econet/af_econet.c Fri Aug 29 11:15:12 2003 +++ b/net/econet/af_econet.c Fri Aug 29 11:15:12 2003 @@ -562,6 +562,7 @@ sk->sk_reuse = 1; sock->ops = &econet_ops; sock_init_data(sock,sk); + sk_set_owner(sk, THIS_MODULE); eo = ec_sk(sk) = kmalloc(sizeof(*eo), GFP_KERNEL); if (!eo) From shemminger@osdl.org Fri Aug 29 11:37:38 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Aug 2003 11:38:10 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7TIbbWZ013815 for ; Fri, 29 Aug 2003 11:37:38 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7TIbJo07925; Fri, 29 Aug 2003 11:37:19 -0700 Date: Fri, 29 Aug 2003 11:37:04 -0700 From: Stephen Hemminger To: Arnaldo Carvalho de Melo , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] ipx - set socket owner field Message-Id: <20030829113704.548a9af4.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5376 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 488 Lines: 16 All sockets created by a protocol need to have owner field set to prevent problems with orphaned sockets during module unload. Patch for 2.6.0-test4 diff -Nru a/net/ipx/af_ipx.c b/net/ipx/af_ipx.c --- a/net/ipx/af_ipx.c Fri Aug 29 11:20:48 2003 +++ b/net/ipx/af_ipx.c Fri Aug 29 11:20:48 2003 @@ -1365,6 +1365,7 @@ atomic_read(&ipx_sock_nr)); #endif sock_init_data(sock, sk); + sk_set_owner(sk, THIS_MODULE); sk->sk_no_check = 1; /* Checksum off by default */ rc = 0; out: From shemminger@osdl.org Fri Aug 29 11:38:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Aug 2003 11:39:10 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7TIcZWZ013931 for ; Fri, 29 Aug 2003 11:38:36 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7TIcDo08030; Fri, 29 Aug 2003 11:38:13 -0700 Date: Fri, 29 Aug 2003 11:37:58 -0700 From: Stephen Hemminger To: Chas Williams , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] atm - set socket owner field Message-Id: <20030829113758.6970f039.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5377 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 488 Lines: 16 All sockets created by a protocol need to have owner field set to prevent problems with orphaned sockets during module unload. Patch for 2.6.0-test4 diff -Nru a/net/atm/common.c b/net/atm/common.c --- a/net/atm/common.c Fri Aug 29 11:24:19 2003 +++ b/net/atm/common.c Fri Aug 29 11:24:19 2003 @@ -279,6 +279,7 @@ if (!sk) return -ENOMEM; sock_init_data(sock, sk); + sk_set_owner(sk, THIS_MODULE); sk->sk_state_change = vcc_def_wakeup; sk->sk_write_space = vcc_write_space; From shemminger@osdl.org Fri Aug 29 11:42:39 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Aug 2003 11:43:13 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7TIgdWZ014712 for ; Fri, 29 Aug 2003 11:42:39 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7TIgNo08849; Fri, 29 Aug 2003 11:42:24 -0700 Date: Fri, 29 Aug 2003 11:42:08 -0700 From: Stephen Hemminger To: ralf@linux-mips.org, "David S. Miller" Cc: linux-hams@vger.kernel.org, netdev@oss.sgi.com Subject: [PATCH] set socket owner (ax25, rose, netrom) Message-Id: <20030829114208.40f10cca.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5378 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1612 Lines: 62 AX25, NETROM, ROSE all need to set the socket owner field, otherwise it is possible to remove the module when there are orphaned sockets. Patch against 2.6.0-test4 diff -Nru a/net/x25/af_x25.c b/net/x25/af_x25.c --- a/net/x25/af_x25.c Fri Aug 29 11:23:32 2003 +++ b/net/x25/af_x25.c Fri Aug 29 11:23:32 2003 @@ -449,6 +449,7 @@ x25->sk = sk; sock_init_data(NULL, sk); + sk_set_owner(sk, THIS_MODULE); skb_queue_head_init(&x25->ack_queue); skb_queue_head_init(&x25->fragment_queue); @@ -478,6 +479,7 @@ x25 = x25_sk(sk); sock_init_data(sock, sk); + sk_set_owner(sk, THIS_MODULE); init_timer(&x25->timer); diff -Nru a/net/rose/af_rose.c b/net/rose/af_rose.c --- a/net/rose/af_rose.c Fri Aug 29 11:22:10 2003 +++ b/net/rose/af_rose.c Fri Aug 29 11:22:10 2003 @@ -518,6 +518,7 @@ rose = rose_sk(sk); sock_init_data(sock, sk); + sk_set_owner(sk, THIS_MODULE); skb_queue_head_init(&rose->ack_queue); #ifdef M_BIT @@ -556,6 +557,7 @@ rose = rose_sk(sk); sock_init_data(NULL, sk); + sk_set_owner(sk, THIS_MODULE); skb_queue_head_init(&rose->ack_queue); #ifdef M_BIT diff -Nru a/net/netrom/af_netrom.c b/net/netrom/af_netrom.c --- a/net/netrom/af_netrom.c Fri Aug 29 11:22:49 2003 +++ b/net/netrom/af_netrom.c Fri Aug 29 11:22:49 2003 @@ -433,6 +433,7 @@ nr = nr_sk(sk); sock_init_data(sock, sk); + sk_set_owner(sk, THIS_MODULE); sock->ops = &nr_proto_ops; sk->sk_protocol = protocol; @@ -473,6 +474,7 @@ nr = nr_sk(sk); sock_init_data(NULL, sk); + sk_set_owner(sk, THIS_MODULE); sk->sk_type = osk->sk_type; sk->sk_socket = osk->sk_socket; From shemminger@osdl.org Fri Aug 29 11:44:56 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Aug 2003 11:45:28 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7TIitWZ015143 for ; Fri, 29 Aug 2003 11:44:56 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7TIiLo09177; Fri, 29 Aug 2003 11:44:21 -0700 Date: Fri, 29 Aug 2003 11:44:06 -0700 From: Stephen Hemminger To: Jean Tourrilhes , "David S. Miller" Cc: irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] irda - need to set socket owner Message-Id: <20030829114406.52a429bd.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5379 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 616 Lines: 16 All protocols need to set the socket owner field to prevent module unloading when there are still orphaned sockets. Patch against 2.6.0-test4 (but should work on 2.4 as well). diff -Nru a/net/irda/af_irda.c b/net/irda/af_irda.c --- a/net/irda/af_irda.c Fri Aug 29 11:21:32 2003 +++ b/net/irda/af_irda.c Fri Aug 29 11:21:32 2003 @@ -1098,6 +1098,7 @@ /* Initialise networking socket struct */ sock_init_data(sock, sk); /* Note : set sk->sk_refcnt to 1 */ + sk_set_owner(sk, THIS_MODULE); sk->sk_family = PF_IRDA; sk->sk_protocol = protocol; /* Link networking socket and IrDA socket structs together */ From shemminger@osdl.org Fri Aug 29 14:22:39 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Aug 2003 14:23:18 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7TLMcWZ024380 for ; Fri, 29 Aug 2003 14:22:39 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7TLMQo19538; Fri, 29 Aug 2003 14:22:26 -0700 Date: Fri, 29 Aug 2003 13:51:19 -0700 From: Stephen Hemminger To: Jay Schulist , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (0/13) appletalk bug fixes Message-Id: <20030829135119.78d98961.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5383 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 793 Lines: 21 Started out just converting aarp to use seq_file, and getting my old "new protocol" patch tested. In the process ran into a bunch of races relating to module unload. This set addresses: 1. Setting owner field on DDP sockets (bug) 2. Invert logic on release (readability) 3. Align headers with columns (cosmetic) 4. Keep track of last sent 5. Purge aarp entries on unload (bug) 6. aarp deltimer_sync 7. aarp convert to seq_file 8. set owner on /proc/net/atalk directory 9. Update comment in DDP about modules 10. Orphan DDP sockets on destroy (bug) 11. Change /proc/net/aarp to /proc/net/atalk/arp 12. Keep netdevice references for pointers held 13. Update DDP to new protocol format These have been tested on 2.6.0-test4 by running a ethertalk between the SUT and a reference 2.4 system. From shemminger@osdl.org Fri Aug 29 14:22:42 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Aug 2003 14:23:22 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7TLMfWZ024387 for ; Fri, 29 Aug 2003 14:22:41 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7TLMTo19566; Fri, 29 Aug 2003 14:22:29 -0700 Date: Fri, 29 Aug 2003 14:16:38 -0700 From: Stephen Hemminger To: Jay Schulist , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (12/13) ddp do netdev hold/put Message-Id: <20030829141638.70712365.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5388 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 917 Lines: 38 DDP holds a pointer to underlying network device, but doesn't do the refcount bookeeping that it should. diff -Nru a/net/appletalk/ddp.c b/net/appletalk/ddp.c --- a/net/appletalk/ddp.c Fri Aug 29 13:33:24 2003 +++ b/net/appletalk/ddp.c Fri Aug 29 13:33:24 2003 @@ -232,6 +232,7 @@ while ((tmp = *iface) != NULL) { if (tmp->dev == dev) { *iface = tmp->next; + dev_put(dev); kfree(tmp); dev->atalk_ptr = NULL; } else @@ -248,6 +249,7 @@ if (!iface) goto out; + dev_hold(dev); iface->dev = dev; dev->atalk_ptr = iface; iface->address = *sa; @@ -609,6 +611,7 @@ (!(tmp->flags&RTF_GATEWAY) || tmp->target.s_node == addr->s_node)) { *r = tmp->next; + dev_put(tmp->dev); kfree(tmp); goto out; } @@ -633,6 +636,7 @@ while ((tmp = *r) != NULL) { if (tmp->dev == dev) { *r = tmp->next; + dev_put(dev); kfree(tmp); } else r = &tmp->next; From shemminger@osdl.org Fri Aug 29 14:22:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Aug 2003 14:23:20 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7TLMdWZ024382 for ; Fri, 29 Aug 2003 14:22:40 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7TLMRo19546; Fri, 29 Aug 2003 14:22:27 -0700 Date: Fri, 29 Aug 2003 13:54:27 -0700 From: Stephen Hemminger To: Jay Schulist , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (2/13) ddp - invert logic for clarity Message-Id: <20030829135427.21845e3c.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5385 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1506 Lines: 48 It is a lot clearer to invert the logic used in the destroy_socket so that it ends up as a positive expression, rather than a double negative. The SOCK_DEAD is redundant and can be eliminated because it is always set in the atalk_release() the only caller. diff -Nru a/net/appletalk/ddp.c b/net/appletalk/ddp.c --- a/net/appletalk/ddp.c Fri Aug 29 11:02:41 2003 +++ b/net/appletalk/ddp.c Fri Aug 29 11:02:41 2003 @@ -183,13 +183,12 @@ { struct sock *sk = (struct sock *)data; - if (!atomic_read(&sk->sk_wmem_alloc) && - !atomic_read(&sk->sk_rmem_alloc) && sock_flag(sk, SOCK_DEAD)) - sock_put(sk); - else { + if (atomic_read(&sk->sk_wmem_alloc) || + atomic_read(&sk->sk_rmem_alloc)) { sk->sk_timer.expires = jiffies + SOCK_DESTROY_TIME; add_timer(&sk->sk_timer); - } + } else + sock_put(sk); } static inline void atalk_destroy_socket(struct sock *sk) @@ -197,16 +196,15 @@ atalk_remove_socket(sk); skb_queue_purge(&sk->sk_receive_queue); - if (!atomic_read(&sk->sk_wmem_alloc) && - !atomic_read(&sk->sk_rmem_alloc) && sock_flag(sk, SOCK_DEAD)) - sock_put(sk); - else { + if (atomic_read(&sk->sk_wmem_alloc) || + atomic_read(&sk->sk_rmem_alloc)) { init_timer(&sk->sk_timer); sk->sk_timer.expires = jiffies + SOCK_DESTROY_TIME; sk->sk_timer.function = atalk_destroy_timer; sk->sk_timer.data = (unsigned long)sk; add_timer(&sk->sk_timer); - } + } else + sock_put(sk); } /**************************************************************************\ From shemminger@osdl.org Fri Aug 29 14:22:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Aug 2003 14:23:20 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7TLMhWZ024393 for ; Fri, 29 Aug 2003 14:22:44 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7TLMNo19507; Fri, 29 Aug 2003 14:22:23 -0700 Date: Fri, 29 Aug 2003 11:20:59 -0700 From: Stephen Hemminger To: Maxim Krasnyansky , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] bluetooth - set sock owner Message-Id: <20030829112059.29414fc5.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5386 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 473 Lines: 14 All sockets created by a protocol need to have owner field set to prevent problems with orphaned sockets during module unload. diff -Nru a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c --- a/net/bluetooth/af_bluetooth.c Fri Aug 29 11:14:03 2003 +++ b/net/bluetooth/af_bluetooth.c Fri Aug 29 11:14:03 2003 @@ -130,6 +130,7 @@ } sock_init_data(sock, sk); + sk_set_owner(sk, THIS_MODULE); INIT_LIST_HEAD(&bt_sk(sk)->accept_q); sk->sk_zapped = 0; From shemminger@osdl.org Fri Aug 29 14:22:38 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Aug 2003 14:23:18 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7TLMbWZ024376 for ; Fri, 29 Aug 2003 14:22:37 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7TLMPo19521; Fri, 29 Aug 2003 14:22:25 -0700 Date: Fri, 29 Aug 2003 14:01:59 -0700 From: Stephen Hemminger To: Jay Schulist , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (4/13) aarp - set last_sent Message-Id: <20030829140159.4ec0927e.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5382 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 491 Lines: 14 Aarp has a field for last_sent which is used in the /proc/net/aarp display, but it is never set. diff -Nru a/net/appletalk/aarp.c b/net/appletalk/aarp.c --- a/net/appletalk/aarp.c Fri Aug 29 13:30:20 2003 +++ b/net/appletalk/aarp.c Fri Aug 29 13:30:20 2003 @@ -145,6 +145,7 @@ aarp_dl->request(aarp_dl, skb, aarp_eth_multicast); /* Update the sending count */ a->xmit_count++; + a->last_sent = jiffies; } /* This runs under aarp_lock and in softint context, so only atomic memory From shemminger@osdl.org Fri Aug 29 14:22:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Aug 2003 14:23:13 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7TLMbWZ024375 for ; Fri, 29 Aug 2003 14:22:37 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7TLMPo19515; Fri, 29 Aug 2003 14:22:25 -0700 Date: Fri, 29 Aug 2003 14:00:58 -0700 From: Stephen Hemminger To: Jay Schulist , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (6/13) aarp - del_timer_sync Message-Id: <20030829140058.772e5350.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5380 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 574 Lines: 16 Aarp module unload needs to use del_timer_sync to handle the race condition where timer starts or is running during module unload. diff -Nru a/net/appletalk/aarp.c b/net/appletalk/aarp.c --- a/net/appletalk/aarp.c Fri Aug 29 13:31:18 2003 +++ b/net/appletalk/aarp.c Fri Aug 29 13:31:18 2003 @@ -981,7 +981,7 @@ /* General module cleanup. Called from cleanup_module() in ddp.c. */ void aarp_cleanup_module(void) { - del_timer(&aarp_timer); + del_timer_sync(&aarp_timer); unregister_netdevice_notifier(&aarp_notifier); unregister_snap_client(aarp_dl); aarp_purge(); From shemminger@osdl.org Fri Aug 29 14:22:39 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Aug 2003 14:23:23 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7TLMcWZ024377 for ; Fri, 29 Aug 2003 14:22:38 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7TLMPo19529; Fri, 29 Aug 2003 14:22:25 -0700 Date: Fri, 29 Aug 2003 14:05:33 -0700 From: Stephen Hemminger To: Jay Schulist , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (7/13) aarp convert to seq_file Message-Id: <20030829140533.5f5c5f4e.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5391 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 8342 Lines: 282 Convert aarp to seq_file interface. The output format is slightly changed: - address is printed in same format as /proc/net/atalk/interface - retry and last_sent are only shown for unresolved entries - times shown in seconds.hundreths rather than raw jiffies - column headers changed to same format as /proc/net/atalk/interface diff -Nru a/net/appletalk/aarp.c b/net/appletalk/aarp.c --- a/net/appletalk/aarp.c Fri Aug 29 13:31:39 2003 +++ b/net/appletalk/aarp.c Fri Aug 29 13:31:39 2003 @@ -37,6 +37,7 @@ #include #include #include +#include int sysctl_aarp_expiry_time = AARP_EXPIRY_TIME; int sysctl_aarp_tick_time = AARP_TICK_TIME; @@ -888,96 +889,176 @@ write_unlock_bh(&aarp_lock); } -/* Called from proc fs */ -static int aarp_get_info(char *buffer, char **start, off_t offset, int length) +#ifdef CONFIG_PROC_FS +struct aarp_iter_state { + int bucket; + struct aarp_entry **table; +}; + +/* + * Get the aarp entry that is in the chain described + * by the iterator. + * If pos is set then skip till that index. + * pos = 1 is the first entry + */ +static struct aarp_entry *iter_next(struct aarp_iter_state *iter, loff_t *pos) { - /* we should dump all our AARP entries */ + int ct = iter->bucket; + struct aarp_entry **table = iter->table; + loff_t off = 0; struct aarp_entry *entry; - int ct, len = sprintf(buffer, - "%-10.10s %-10.10s%-18.18s%12.12s%12.12s " - "xmit_count status\n", - "address", "device", "hw addr", "last_sent", - "expires"); + + rescan: + while(ct < AARP_HASH_SIZE) { + for (entry = table[ct]; entry; entry = entry->next) { + if (!pos || ++off == *pos) { + iter->table = table; + iter->bucket = ct; + return entry; + } + } + ++ct; + } + + if (table == resolved) { + ct = 0; + table = unresolved; + goto rescan; + } + if (table == unresolved) { + ct = 0; + table = proxies; + goto rescan; + } + return NULL; +} + +static void *aarp_seq_start(struct seq_file *seq, loff_t *pos) +{ + struct aarp_iter_state *iter = seq->private; read_lock_bh(&aarp_lock); + iter->table = resolved; + iter->bucket = 0; - for (ct = 0; ct < AARP_HASH_SIZE; ct++) { - for (entry = resolved[ct]; entry; entry = entry->next) { - len += sprintf(buffer + len, "%6u:%-3u ", - (unsigned int)ntohs(entry->target_addr.s_net), - (unsigned int)(entry->target_addr.s_node)); - len += sprintf(buffer + len, "%-10.10s", - entry->dev->name); - len += sprintf(buffer + len, - "%2.2X:%2.2X:%2.2X:%2.2X:%2.2X:%2.2X", - (int)(entry->hwaddr[0] & 0x000000FF), - (int)(entry->hwaddr[1] & 0x000000FF), - (int)(entry->hwaddr[2] & 0x000000FF), - (int)(entry->hwaddr[3] & 0x000000FF), - (int)(entry->hwaddr[4] & 0x000000FF), - (int)(entry->hwaddr[5] & 0x000000FF)); - len += sprintf(buffer + len, "%12lu ""%12lu ", - (unsigned long)entry->last_sent, - (unsigned long)entry->expires_at); - len += sprintf(buffer + len, "%10u", - (unsigned int)entry->xmit_count); + return *pos ? iter_next(iter, pos) : ((void *)1); +} - len += sprintf(buffer + len, " resolved\n"); - } - } +static void *aarp_seq_next(struct seq_file *seq, void *v, loff_t *pos) +{ + struct aarp_entry *entry = v; + struct aarp_iter_state *iter = seq->private; - for (ct = 0; ct < AARP_HASH_SIZE; ct++) { - for (entry = unresolved[ct]; entry; entry = entry->next) { - len += sprintf(buffer + len, "%6u:%-3u ", - (unsigned int)ntohs(entry->target_addr.s_net), - (unsigned int)(entry->target_addr.s_node)); - len += sprintf(buffer + len, "%-10.10s", - entry->dev->name); - len += sprintf(buffer + len, - "%2.2X:%2.2X:%2.2X:%2.2X:%2.2X:%2.2X", - (int)(entry->hwaddr[0] & 0x000000FF), - (int)(entry->hwaddr[1] & 0x000000FF), - (int)(entry->hwaddr[2] & 0x000000FF), - (int)(entry->hwaddr[3] & 0x000000FF), - (int)(entry->hwaddr[4] & 0x000000FF), - (int)(entry->hwaddr[5] & 0x000000FF)); - len += sprintf(buffer + len, "%12lu ""%12lu ", - (unsigned long)entry->last_sent, - (unsigned long)entry->expires_at); - len += sprintf(buffer + len, "%10u", - (unsigned int)entry->xmit_count); - len += sprintf(buffer + len, " unresolved\n"); - } - } + ++*pos; - for (ct = 0; ct < AARP_HASH_SIZE; ct++) { - for (entry = proxies[ct]; entry; entry = entry->next) { - len += sprintf(buffer + len, "%6u:%-3u ", - (unsigned int)ntohs(entry->target_addr.s_net), - (unsigned int)(entry->target_addr.s_node)); - len += sprintf(buffer + len, "%-10.10s", - entry->dev->name); - len += sprintf(buffer + len, - "%2.2X:%2.2X:%2.2X:%2.2X:%2.2X:%2.2X", - (int)(entry->hwaddr[0] & 0x000000FF), - (int)(entry->hwaddr[1] & 0x000000FF), - (int)(entry->hwaddr[2] & 0x000000FF), - (int)(entry->hwaddr[3] & 0x000000FF), - (int)(entry->hwaddr[4] & 0x000000FF), - (int)(entry->hwaddr[5] & 0x000000FF)); - len += sprintf(buffer + len, "%12lu ""%12lu ", - (unsigned long)entry->last_sent, - (unsigned long)entry->expires_at); - len += sprintf(buffer + len, "%10u", - (unsigned int)entry->xmit_count); - len += sprintf(buffer + len, " proxy\n"); - } + /* first line after header */ + if (v == ((void *)1)) + entry = iter_next(iter, NULL); + + /* next entry in current bucket */ + else if (entry->next) + entry = entry->next; + + /* next bucket or table */ + else { + ++iter->bucket; + entry = iter_next(iter, NULL); } + return entry; +} +static void aarp_seq_stop(struct seq_file *seq, void *v) +{ read_unlock_bh(&aarp_lock); - return len; } +static const char *dt2str(unsigned long ticks) +{ + static char buf[32]; + + sprintf(buf, "%ld.%02ld", ticks / HZ, ((ticks % HZ) * 100 ) / HZ); + + return buf; +} + +static int aarp_seq_show(struct seq_file *seq, void *v) +{ + struct aarp_iter_state *iter = seq->private; + struct aarp_entry *entry = v; + unsigned long now = jiffies; + + if (v == ((void *)1)) + seq_puts(seq, + "Address Interface Hardware Address" + " Expires LastSend Retry Status\n"); + else { + seq_printf(seq, "%04X:%02X %-12s", + ntohs(entry->target_addr.s_net), + (unsigned int) entry->target_addr.s_node, + entry->dev ? entry->dev->name : "????"); + seq_printf(seq, "%02X:%02X:%02X:%02X:%02X:%02X", + entry->hwaddr[0] & 0xFF, + entry->hwaddr[1] & 0xFF, + entry->hwaddr[2] & 0xFF, + entry->hwaddr[3] & 0xFF, + entry->hwaddr[4] & 0xFF, + entry->hwaddr[5] & 0xFF); + seq_printf(seq, " %8s", + dt2str((long)entry->expires_at - (long)now)); + if (iter->table == unresolved) + seq_printf(seq, " %8s %6hu", + dt2str(now - entry->last_sent), + entry->xmit_count); + else + seq_puts(seq, " "); + seq_printf(seq, " %s\n", + (iter->table == resolved) ? "resolved" + : (iter->table == unresolved) ? "unresolved" + : (iter->table == proxies) ? "proxies" + : "unknown"); + } + return 0; +} + +static struct seq_operations aarp_seq_ops = { + .start = aarp_seq_start, + .next = aarp_seq_next, + .stop = aarp_seq_stop, + .show = aarp_seq_show, +}; + +static int aarp_seq_open(struct inode *inode, struct file *file) +{ + struct seq_file *seq; + int rc = -ENOMEM; + struct aarp_iter_state *s = kmalloc(sizeof(*s), GFP_KERNEL); + + if (!s) + goto out; + + rc = seq_open(file, &aarp_seq_ops); + if (rc) + goto out_kfree; + + seq = file->private_data; + seq->private = s; + memset(s, 0, sizeof(*s)); +out: + return rc; +out_kfree: + kfree(s); + goto out; +} + +struct file_operations atalk_seq_arp_fops = { + .owner = THIS_MODULE, + .open = aarp_seq_open, + .read = seq_read, + .llseek = seq_lseek, + .release = seq_release_private, +}; +#endif + /* General module cleanup. Called from cleanup_module() in ddp.c. */ void aarp_cleanup_module(void) { @@ -990,7 +1071,7 @@ #ifdef CONFIG_PROC_FS void aarp_register_proc_fs(void) { - proc_net_create("aarp", 0, aarp_get_info); + proc_net_fops_create("aarp", S_IRUGO, &atalk_seq_arp_fops); } void aarp_unregister_proc_fs(void) From shemminger@osdl.org Fri Aug 29 14:22:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Aug 2003 14:23:22 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7TLMfWZ024388 for ; Fri, 29 Aug 2003 14:22:44 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7TLMTo19570; Fri, 29 Aug 2003 14:22:29 -0700 Date: Fri, 29 Aug 2003 14:20:34 -0700 From: Stephen Hemminger To: Jay Schulist , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (13/13) ddp - convert to new protocol interface Message-Id: <20030829142034.6caff2bc.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5387 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 5507 Lines: 208 Convert ddp to the new protocol interface which means it has to handle fragmented skb's. The only big change is in the checksum routine which has to do more work (like skb_checksum). Minor speedup is folding the carry to avoid a branch. Tested against a 2.4 system and by running both code over a range of packets. diff -Nru a/net/appletalk/ddp.c b/net/appletalk/ddp.c --- a/net/appletalk/ddp.c Fri Aug 29 13:33:48 2003 +++ b/net/appletalk/ddp.c Fri Aug 29 13:33:48 2003 @@ -932,24 +932,95 @@ * Checksum: This is 'optional'. It's quite likely also a good * candidate for assembler hackery 8) */ -unsigned short atalk_checksum(struct ddpehdr *ddp, int len) +static unsigned long atalk_sum_partial(const unsigned char *data, + int len, unsigned long sum) { - unsigned long sum = 0; /* Assume unsigned long is >16 bits */ - unsigned char *data = (unsigned char *)ddp; - - len -= 4; /* skip header 4 bytes */ - data += 4; - /* This ought to be unwrapped neatly. I'll trust gcc for now */ while (len--) { - sum += *data; + sum += *data++; sum <<= 1; - if (sum & 0x10000) { - sum++; - sum &= 0xFFFF; + sum = ((sum >> 16) + sum) & 0xFFFF; + } + return sum; +} + +/* Checksum skb data -- similar to skb_checksum */ +static unsigned long atalk_sum_skb(const struct sk_buff *skb, int offset, + int len, unsigned long sum) +{ + int start = skb_headlen(skb); + int i, copy; + + /* checksum stuff in header space */ + if ( (copy = start - offset) > 0) { + if (copy > len) + copy = len; + sum = atalk_sum_partial(skb->data + offset, copy, sum); + if ( (len -= copy) == 0) + return sum; + + offset += copy; + } + + /* checksum stuff in frags */ + for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) { + int end; + + BUG_TRAP(start <= offset + len); + + end = start + skb_shinfo(skb)->frags[i].size; + if ((copy = end - offset) > 0) { + u8 *vaddr; + skb_frag_t *frag = &skb_shinfo(skb)->frags[i]; + + if (copy > len) + copy = len; + vaddr = kmap_skb_frag(frag); + sum = atalk_sum_partial(vaddr + frag->page_offset + + offset - start, copy, sum); + kunmap_skb_frag(vaddr); + + if (!(len -= copy)) + return sum; + offset += copy; } - data++; + start = end; } + + if (skb_shinfo(skb)->frag_list) { + struct sk_buff *list = skb_shinfo(skb)->frag_list; + + for (; list; list = list->next) { + int end; + + BUG_TRAP(start <= offset + len); + + end = start + list->len; + if ((copy = end - offset) > 0) { + if (copy > len) + copy = len; + sum = atalk_sum_skb(list, offset - start, + copy, sum); + if ((len -= copy) == 0) + return sum; + offset += copy; + } + start = end; + } + } + + BUG_ON(len > 0); + + return sum; +} + +static unsigned short atalk_checksum(const struct sk_buff *skb, int len) +{ + unsigned long sum; + + /* skip header 4 bytes */ + sum = atalk_sum_skb(skb, 4, len-4, 0); + /* Use 0xFFFF for 0. 0 itself means none */ return sum ? htons((unsigned short)sum) : 0xFFFF; } @@ -1331,25 +1402,27 @@ static int atalk_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt) { - struct ddpehdr *ddp = ddp_hdr(skb); + struct ddpehdr *ddp; struct sock *sock; struct atalk_iface *atif; struct sockaddr_at tosat; int origlen; struct ddpebits ddphv; - /* Size check */ - if (skb->len < sizeof(*ddp)) + /* Don't mangle buffer if shared */ + if (!(skb = skb_share_check(skb, GFP_ATOMIC))) + goto out; + + /* Size check and make sure header is contiguous */ + if (!pskb_may_pull(skb, sizeof(*ddp))) goto freeit; + ddp = ddp_hdr(skb); + /* * Fix up the length field [Ok this is horrible but otherwise * I end up with unions of bit fields and messy bit field order * compiler/endian dependencies..] - * - * FIXME: This is a write to a shared object. Granted it - * happens to be safe BUT.. (Its safe as user space will not - * run until we put it back) */ *((__u16 *)&ddphv) = ntohs(*((__u16 *)ddp)); @@ -1370,7 +1443,7 @@ * valid for net byte orders all over the networking code... */ if (ddp->deh_sum && - atalk_checksum(ddp, ddphv.deh_len) != ddp->deh_sum) + atalk_checksum(skb, ddphv.deh_len) != ddp->deh_sum) /* Not a valid AppleTalk frame - dustbin time */ goto freeit; @@ -1429,14 +1502,16 @@ if (!ap || skb->len < sizeof(struct ddpshdr)) goto freeit; + + /* Don't mangle buffer if shared */ + if (!(skb = skb_share_check(skb, GFP_ATOMIC))) + return 0; + /* * The push leaves us with a ddephdr not an shdr, and * handily the port bytes in the right place preset. */ - - skb_push(skb, sizeof(*ddp) - 4); - /* FIXME: use skb->cb to be able to use shared skbs */ - ddp = (struct ddpehdr *)skb->data; + ddp = (struct ddpehdr *) skb_push(skb, sizeof(*ddp) - 4); /* Now fill in the long header */ @@ -1588,7 +1663,7 @@ if (sk->sk_no_check == 1) ddp->deh_sum = 0; else - ddp->deh_sum = atalk_checksum(ddp, len + sizeof(*ddp)); + ddp->deh_sum = atalk_checksum(skb, len + sizeof(*ddp)); /* * Loopback broadcast packets to non gateway targets (ie routes @@ -1797,11 +1872,13 @@ struct packet_type ltalk_packet_type = { .type = __constant_htons(ETH_P_LOCALTALK), .func = ltalk_rcv, + .data = (void *)1, }; struct packet_type ppptalk_packet_type = { .type = __constant_htons(ETH_P_PPPTALK), .func = atalk_rcv, + .data = (void *)1, }; static unsigned char ddp_snap_id[] = { 0x08, 0x00, 0x07, 0x80, 0x9B }; From shemminger@osdl.org Fri Aug 29 14:22:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Aug 2003 14:23:24 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7TLMfWZ024386 for ; Fri, 29 Aug 2003 14:22:41 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7TLMTo19562; Fri, 29 Aug 2003 14:22:29 -0700 Date: Fri, 29 Aug 2003 13:55:55 -0700 From: Stephen Hemminger To: Jay Schulist , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (1/13) appletalk - ddp set socket owner Message-Id: <20030829135555.31d277a0.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5394 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 692 Lines: 21 DDP needs to set the socket owner, without this it is possible to OOPS. What happens is a socket is closed, but data is outstanding so it is orphaned to be cleaned up later. Then if appletalk module is unloaded, the timer code ends up referencing dead memory. By setting the owner field, the module can't be unloaded. Path applies to 2.6.0-test4. diff -Nru a/net/appletalk/ddp.c b/net/appletalk/ddp.c --- a/net/appletalk/ddp.c Fri Aug 29 11:02:16 2003 +++ b/net/appletalk/ddp.c Fri Aug 29 11:02:16 2003 @@ -983,6 +983,8 @@ rc = 0; sock->ops = &atalk_dgram_ops; sock_init_data(sock, sk); + sk_set_owner(sk, THIS_MODULE); + /* Checksums on by default */ sk->sk_zapped = 1; out: From shemminger@osdl.org Fri Aug 29 14:22:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Aug 2003 14:23:19 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7TLMeWZ024384 for ; Fri, 29 Aug 2003 14:22:40 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7TLMSo19554; Fri, 29 Aug 2003 14:22:28 -0700 Date: Fri, 29 Aug 2003 13:55:47 -0700 From: Stephen Hemminger To: Jay Schulist , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (3/13) atalk_proc whitespace in header Message-Id: <20030829135547.142856e4.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5384 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 527 Lines: 15 The header for /proc/net/atalk/interfaces is not lined up right with the data because it has a tab rather than spaces. diff -Nru a/net/appletalk/atalk_proc.c b/net/appletalk/atalk_proc.c --- a/net/appletalk/atalk_proc.c Fri Aug 29 11:02:59 2003 +++ b/net/appletalk/atalk_proc.c Fri Aug 29 11:02:59 2003 @@ -64,7 +64,7 @@ struct atalk_iface *iface; if (v == (void *)1) { - seq_puts(seq, "Interface Address Networks " + seq_puts(seq, "Interface Address Networks " "Status\n"); goto out; } From shemminger@osdl.org Fri Aug 29 14:22:39 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Aug 2003 14:23:23 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7TLMdWZ024381 for ; Fri, 29 Aug 2003 14:22:39 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7TLMRo19542; Fri, 29 Aug 2003 14:22:27 -0700 Date: Fri, 29 Aug 2003 14:08:00 -0700 From: Stephen Hemminger To: Jay Schulist , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (9/13) ddp module comment update Message-Id: <20030829140800.5587a03d.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5392 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 846 Lines: 23 MOD_INC/DEC are gone, so update the comment to match today's reality. diff -Nru a/net/appletalk/ddp.c b/net/appletalk/ddp.c --- a/net/appletalk/ddp.c Fri Aug 29 13:32:21 2003 +++ b/net/appletalk/ddp.c Fri Aug 29 13:32:21 2003 @@ -1844,13 +1844,10 @@ module_init(atalk_init); /* - * Note on MOD_{INC,DEC}_USE_COUNT: - * - * Use counts are incremented/decremented when - * sockets are created/deleted. - * - * AppleTalk interfaces are not incremented until atalkd is run - * and are only decremented when they are downed. + * No explicit module reference count manipulation is needed in the + * protocol. Socket layer sets module reference count for us + * and interfaces reference counting is done + * by the network device layer. * * Ergo, before the AppleTalk module can be removed, all AppleTalk * sockets be closed from user space. From shemminger@osdl.org Fri Aug 29 14:22:39 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Aug 2003 14:23:23 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7TLMcWZ024379 for ; Fri, 29 Aug 2003 14:22:39 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7TLMQo19534; Fri, 29 Aug 2003 14:22:26 -0700 Date: Fri, 29 Aug 2003 14:06:51 -0700 From: Stephen Hemminger To: Jay Schulist , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (8/13) set owner of /proc/net/atalk directory Message-Id: <20030829140651.4ec38b3e.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5390 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 480 Lines: 14 Set owner to prevent problems when directory is open during module unload. diff -Nru a/net/appletalk/atalk_proc.c b/net/appletalk/atalk_proc.c --- a/net/appletalk/atalk_proc.c Fri Aug 29 13:32:04 2003 +++ b/net/appletalk/atalk_proc.c Fri Aug 29 13:32:04 2003 @@ -275,6 +275,7 @@ atalk_proc_dir = proc_mkdir("atalk", proc_net); if (!atalk_proc_dir) goto out; + atalk_proc_dir->owner = THIS_MODULE; p = create_proc_entry("interface", S_IRUGO, atalk_proc_dir); if (!p) From jkenisto@us.ibm.com Fri Aug 29 14:24:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Aug 2003 14:25:16 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7TLOdWZ025714 for ; Fri, 29 Aug 2003 14:24:40 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h7TLODUj356374; Fri, 29 Aug 2003 17:24:13 -0400 Received: from us.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h7TLOA30144714; Fri, 29 Aug 2003 15:24:11 -0600 Message-ID: <3F4FC3FF.8A704B85@us.ibm.com> Date: Fri, 29 Aug 2003 14:22:07 -0700 From: Jim Keniston X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Hemminger CC: Greg KH , LKML , netdev , Jeff Garzik , "Feldman, Scott" , Larry Kessler , Randy Dunlap , Alan Cox , Andrew Morton , Daniel Stekloff , Hien Nguyen , jkenisto Subject: Re: [PATCH 1/4] Net device error logging, revised References: <3F4A8027.6FE3F594@us.ibm.com> <20030826183221.GB3167@kroah.com> <3F4BEE68.A6C862C2@us.ibm.com> <20030826180626.50778705.shemminger@osdl.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 5395 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkenisto@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1503 Lines: 33 Stephen Hemminger wrote: > > > The following options come to mind: > > 1. Keep the msg buffer, but make it smaller. Around 120 bytes would probably be > > big enough for the vast majority of messages. (printk() uses a 1024-byte buffer, > > but it's static -- see #2.) > > > > 2. Use a big, static buffer, protected by a spinlock. printk() does this. > > > > 3. Do the whole thing in a macro, as in previous proposals. The size of the macro > > expansion could be reduced somewhat by doing the encode-prefix step in a function -- > > something like: [more on #3 snipped] > > Is there some way to tack copy and prepend what you want onto the format > string, and add additional arguments to the call to printk? That way you > wouldn't need space for the potentially large resulting string, but only > enough room for the expanded format string. Interesting idea. I pondered this for a while. But even if you postulate a varargs version of printk (which doesn't exist), it's not really feasible to do this in a function. There's no way for a function to prepend args to a va_list. That means you'd have to encode the text of the prefix as part of the format string, and that would require you to allocate room for prefix+format, which is still a lot of stack. Also, the fact that the interface name itself may contain "%d" or some such makes it even messier. Greg K-H thinks #2 is a reasonable solution (you're about to serialize on printk's lock anyway), so I'll go with that. Thanks. Jim From shemminger@osdl.org Fri Aug 29 14:22:39 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Aug 2003 14:23:17 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7TLMbWZ024374 for ; Fri, 29 Aug 2003 14:22:38 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7TLMOo19511; Fri, 29 Aug 2003 14:22:24 -0700 Date: Fri, 29 Aug 2003 14:00:46 -0700 From: Stephen Hemminger To: Jay Schulist , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (5/13) aarp purge table on module unload Message-Id: <20030829140046.1241f018.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5381 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1113 Lines: 47 Aarp does not clean the arp table when the appletalk module is unloaded, and therefore can leak memory. diff -Nru a/net/appletalk/aarp.c b/net/appletalk/aarp.c --- a/net/appletalk/aarp.c Fri Aug 29 13:31:00 2003 +++ b/net/appletalk/aarp.c Fri Aug 29 13:31:00 2003 @@ -339,6 +339,32 @@ return NOTIFY_DONE; } +/* Expire all entries in a hash chain */ +static void __aarp_expire_all(struct aarp_entry **n) +{ + struct aarp_entry *t; + + while (*n) { + t = *n; + *n = (*n)->next; + __aarp_expire(t); + } +} + +/* Cleanup all hash chains -- module unloading */ +static void aarp_purge(void) +{ + int ct; + + write_lock_bh(&aarp_lock); + for (ct = 0; ct < AARP_HASH_SIZE; ct++) { + __aarp_expire_all(&resolved[ct]); + __aarp_expire_all(&unresolved[ct]); + __aarp_expire_all(&proxies[ct]); + } + write_unlock_bh(&aarp_lock); +} + /* * Create a new aarp entry. This must use GFP_ATOMIC because it * runs while holding spinlocks. @@ -958,6 +984,7 @@ del_timer(&aarp_timer); unregister_netdevice_notifier(&aarp_notifier); unregister_snap_client(aarp_dl); + aarp_purge(); } #ifdef CONFIG_PROC_FS From shemminger@osdl.org Fri Aug 29 14:22:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Aug 2003 14:23:22 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7TLMeWZ024383 for ; Fri, 29 Aug 2003 14:22:40 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7TLMSo19550; Fri, 29 Aug 2003 14:22:28 -0700 Date: Fri, 29 Aug 2003 14:12:28 -0700 From: Stephen Hemminger To: Jay Schulist , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (10/13) ddp socket orphan Message-Id: <20030829141228.6a35664c.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5389 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 922 Lines: 26 This fixes the problem caused by interrupting aecho causing an oops. What happened was that the sock was detached from the user process but sk->sk_sleep was still so when write data was freed it would do a wakeup on a poisoned data. The sk_state_change code that was there isn't necessary, because we are in middle of release so no user process can be waiting. sock_orphan does the right thing and sets SOCK_DEAD. This is similar to what some other protocols do. But some will have the same sk->sk_sleep problem... diff -Nru a/net/appletalk/ddp.c b/net/appletalk/ddp.c --- a/net/appletalk/ddp.c Fri Aug 29 13:32:35 2003 +++ b/net/appletalk/ddp.c Fri Aug 29 13:32:35 2003 @@ -998,10 +998,7 @@ struct sock *sk = sock->sk; if (sk) { - if (!sock_flag(sk, SOCK_DEAD)) { - sk->sk_state_change(sk); - sock_set_flag(sk, SOCK_DEAD); - } + sock_orphan(sk); sock->sk = NULL; atalk_destroy_socket(sk); } From shemminger@osdl.org Fri Aug 29 14:22:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Aug 2003 14:23:23 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7TLMeWZ024385 for ; Fri, 29 Aug 2003 14:22:41 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h7TLMSo19558; Fri, 29 Aug 2003 14:22:28 -0700 Date: Fri, 29 Aug 2003 14:14:45 -0700 From: Stephen Hemminger To: Jay Schulist , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (11/13) move /proc/net/aarp to /proc/net/atalk/arp Message-Id: <20030829141445.1a5cb912.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5393 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 2638 Lines: 95 Move aarp /proc interface like all the others in 2.6; the other appletalk /proc interfaces were moved to /proc/net/atalk but aarp was overlooked. diff -Nru a/net/appletalk/aarp.c b/net/appletalk/aarp.c --- a/net/appletalk/aarp.c Fri Aug 29 13:33:03 2003 +++ b/net/appletalk/aarp.c Fri Aug 29 13:33:03 2003 @@ -1067,15 +1067,3 @@ unregister_snap_client(aarp_dl); aarp_purge(); } - -#ifdef CONFIG_PROC_FS -void aarp_register_proc_fs(void) -{ - proc_net_fops_create("aarp", S_IRUGO, &atalk_seq_arp_fops); -} - -void aarp_unregister_proc_fs(void) -{ - proc_net_remove("aarp"); -} -#endif diff -Nru a/net/appletalk/atalk_proc.c b/net/appletalk/atalk_proc.c --- a/net/appletalk/atalk_proc.c Fri Aug 29 13:33:03 2003 +++ b/net/appletalk/atalk_proc.c Fri Aug 29 13:33:03 2003 @@ -16,6 +16,8 @@ #include #ifdef CONFIG_PROC_FS +extern struct file_operations atalk_seq_arp_fops; + static __inline__ struct atalk_iface *atalk_get_interface_idx(loff_t pos) { struct atalk_iface *i; @@ -292,9 +294,16 @@ goto out_socket; p->proc_fops = &atalk_seq_socket_fops; + p = create_proc_entry("arp", S_IRUGO, atalk_proc_dir); + if (!p) + goto out_arp; + p->proc_fops = &atalk_seq_arp_fops; + rc = 0; out: return rc; +out_arp: + remove_proc_entry("socket", atalk_proc_dir); out_socket: remove_proc_entry("route", atalk_proc_dir); out_route: @@ -309,6 +318,7 @@ remove_proc_entry("interface", atalk_proc_dir); remove_proc_entry("route", atalk_proc_dir); remove_proc_entry("socket", atalk_proc_dir); + remove_proc_entry("arp", atalk_proc_dir); remove_proc_entry("atalk", proc_net); } diff -Nru a/net/appletalk/ddp.c b/net/appletalk/ddp.c --- a/net/appletalk/ddp.c Fri Aug 29 13:33:03 2003 +++ b/net/appletalk/ddp.c Fri Aug 29 13:33:03 2003 @@ -61,11 +61,6 @@ #include #include -#ifdef CONFIG_PROC_FS -extern void aarp_register_proc_fs(void); -extern void aarp_unregister_proc_fs(void); -#endif - extern void aarp_cleanup_module(void); extern void aarp_probe_network(struct atalk_iface *atif); @@ -1831,9 +1826,6 @@ register_netdevice_notifier(&ddp_notifier); aarp_proto_init(); atalk_proc_init(); -#ifdef CONFIG_PROC_FS - aarp_register_proc_fs(); -#endif /* CONFIG_PROC_FS */ atalk_register_sysctl(); printk(atalk_banner); return 0; @@ -1855,9 +1847,6 @@ atalk_unregister_sysctl(); #endif /* CONFIG_SYSCTL */ atalk_proc_exit(); -#ifdef CONFIG_PROC_FS - aarp_unregister_proc_fs(); -#endif /* CONFIG_PROC_FS */ aarp_cleanup_module(); /* General aarp clean-up. */ unregister_netdevice_notifier(&ddp_notifier); dev_remove_pack(<alk_packet_type); From atm@EnterZone.Net Fri Aug 29 15:24:59 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Aug 2003 15:25:33 -0700 (PDT) Received: from Overkill.EnterZone.Net (IDENT:root@Overkill.EnterZone.Net [66.35.65.2]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7TMOwWZ032540 for ; Fri, 29 Aug 2003 15:24:59 -0700 Received: from Overkill.EnterZone.Net (IDENT:atm@localhost [127.0.0.1]) by Overkill.EnterZone.Net (8.12.9/8.11.0) with ESMTP id h7TMOvoG004775 for ; Fri, 29 Aug 2003 18:24:58 -0400 Received: from localhost (atm@localhost) by Overkill.EnterZone.Net (8.12.9/8.12.8/Submit) with ESMTP id h7TMOvGf004772 for ; Fri, 29 Aug 2003 18:24:57 -0400 X-Authentication-Warning: Overkill.EnterZone.Net: atm owned process doing -bs Date: Fri, 29 Aug 2003 18:24:57 -0400 (EDT) From: John Fraizer To: netdev@oss.sgi.com Subject: Re: [Linux-ATM-General] Neighbor Table Overflow? (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 5396 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: atm@EnterZone.Net Precedence: bulk X-list: netdev Content-Length: 4950 Lines: 142 It would appear that there is a bug in part of the linux IP stack. I was told that this might be the correct address to send the information to regarding tickling the bug. --- John Fraizer | High-Security Datacenter Services | President | Dedicated circuits 64k - 155M OC3 | EnterZone, Inc | Virtual, Dedicated, Colocation | http://www.enterzone.net/ | Network Consulting Services | ---------- Forwarded message ---------- Date: Fri, 29 Aug 2003 10:26:23 -0400 (EDT) From: John Fraizer To: Mike Westall Cc: Linux-atm-general Subject: Re: [Linux-ATM-General] Neighbor Table Overflow? Perhaps someone can pass this up to the right people who do the IP stack. It would appear to be a bug. --- John Fraizer | High-Security Datacenter Services | President | Dedicated circuits 64k - 155M OC3 | EnterZone, Inc | Virtual, Dedicated, Colocation | http://www.enterzone.net/ | Network Consulting Services | On Fri, 29 Aug 2003, Mike Westall wrote: > The interactions between routing and arp are somewhat > complex. This problem seems to have been triggered by > an attempt to route the sunk packets. The message > "overflow" message is issued by rt_intern_hash which > calls arp_bind_neighbour() > > 634 if (rt->rt_type == RTN_UNICAST || rt->key.iif == 0) { > 635 int err = arp_bind_neighbour(&rt->u.dst); > > Apparently arp_bind_neighbour() fails to check for the > NOARP condition. > > > John Fraizer wrote: > > > > Well, in the face of the local microsoft exploits and the worm effects on > > the arp caches of many layer-3 switches and access concentrators, that > > doesn't terribly surprise me. I figured this might be the case but, I > > wasn't sure. The strange part is that "arp -n" doesn't show too aweful > > many entries total. With the typical backscatter we see 24x7 on the net, > > I'll always see a few "incomplete" entries in the arp cache. > > > > The machine in question has a /27 bound up on lec0, a couple of /30's on > > GigE interfaces and a /32 "loopback" address bound up on dummy0. > > > > I do have a sinkhole route for a /19 destined to dummy0. Is it possible > > that the stack is still trying to do ARP when a packet arrives for an > > address in the /19 that doesn't have a more specific route in our IGP and > > it gets dumped to dummy0? > > > > The interface shows: > > > > 4: dummy0: mtu 1500 qdisc noqueue > > link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff > > > > > > I just removed the static sinkhole route from that route and started > > sinking that traffic (traffic destined for addresses we don't have bound > > up yet) on one of our core routers and the messages went away. > > > > Strange that we would fill the arp cache sinking "garbage" traffic to a > > dummy interface that is set NOARP. > > > > Can anyone explain this to me? > > > > I appreciate it! > > > > --- > > John Fraizer | High-Security Datacenter Services | > > President | Dedicated circuits 64k - 155M OC3 | > > EnterZone, Inc | Virtual, Dedicated, Colocation | > > http://www.enterzone.net/ | Network Consulting Services | > > > > > > On Thu, 28 Aug 2003, Mike Westall wrote: > > > > > >>Appears to be generated because the ARP cache is full. > >>Since the size limits there default to 512 and 1024 entries > >>that would be pretty unusual in most environments unless > >>something else was screwed up in some major way. > >> > >>Hard to say what the something else might be though. > >> > >>MIke > >> > >> > >>John Fraizer wrote: > >> > >> > >>>Can someone tell me specificly what causes the following messages? > >>> > >>>Aug 28 14:27:37 Router kernel: NET: 124 messages suppressed. > >>>Aug 28 14:27:37 Router kernel: Neighbour table overflow. > >>>Aug 28 14:27:37 Router last message repeated 2 times > >>>Aug 28 14:27:39 Router kernel: NET: 207 messages suppressed. > >>>Aug 28 14:27:39 Router kernel: Neighbour table overflow. > >>> > >>>This is Linux kernel 2.4.18, running linux-atm-2.4.0 with Fore LE155 NICs > >>>using LANE. > >>> > >>>Thanks, > >>> > >>>--- > >>>John Fraizer | High-Security Datacenter Services | > >>>President | Dedicated circuits 64k - 155M OC3 | > >>>EnterZone, Inc | Virtual, Dedicated, Colocation | > >>>http://www.enterzone.net/ | Network Consulting Services | > >>> > > > > > > > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Linux-atm-general mailing list > Linux-atm-general@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-atm-general > From davem@pizda.ninka.net Fri Aug 29 16:53:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Fri, 29 Aug 2003 16:54:15 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7TNrfWZ005211 for ; Fri, 29 Aug 2003 16:53:41 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id QAA31207; Fri, 29 Aug 2003 16:44:21 -0700 Date: Fri, 29 Aug 2003 16:44:21 -0700 From: "David S. Miller" To: chas3@users.sourceforge.net Cc: chas@cmf.nrl.navy.mil, netdev@oss.sgi.com Subject: Re: forcing bottom half to a specific processor on numa Message-Id: <20030829164421.549c20d1.davem@redhat.com> In-Reply-To: <200308291549.h7TFngl5014364@ginger.cmf.nrl.navy.mil> References: <200308291549.h7TFngl5014364@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5397 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 Content-Length: 421 Lines: 11 On Fri, 29 Aug 2003 11:49:43 -0400 chas williams wrote: > is there a reason i shouldnt do this? is there a better way? Just bind the interrupts of your card to a processor local to the numa node in question using the IRQ affinity stuff. Then all softints you schedule will run on that processor too, when you schedule a softint or a tasklet it runs on the cpu where you perform that schedule. From bdschuym@pandora.be Sat Aug 30 06:21:38 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 30 Aug 2003 06:22:13 -0700 (PDT) Received: from astra.telenet-ops.be (astra.telenet-ops.be [195.130.132.58]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7UDLbWZ030164 for ; Sat, 30 Aug 2003 06:21:38 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by astra.telenet-ops.be (Postfix) with SMTP id 97BAB37EB0; Sat, 30 Aug 2003 15:21:36 +0200 (MEST) Received: from 192.168.123.138 (D5763FDE.kabel.telenet.be [213.118.63.222]) by astra.telenet-ops.be (Postfix) with ESMTP id 2911237F05; Sat, 30 Aug 2003 15:21:24 +0200 (MEST) From: Bart De Schuymer To: "David S.Miller" Subject: Re: [PATCH/RFC] disallow vlan devices on top of a logical bridge device Date: Sat, 30 Aug 2003 15:21:42 +0200 User-Agent: KMail/1.5 Cc: Stephen Hemminger , Ben Greear , netdev@oss.sgi.com References: <200308301504.03241.bdschuym@pandora.be> In-Reply-To: <200308301504.03241.bdschuym@pandora.be> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200308301521.42279.bdschuym@pandora.be> X-archive-position: 5398 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bdschuym@pandora.be Precedence: bulk X-list: netdev Content-Length: 268 Lines: 10 On Saturday 30 August 2003 15:04, Bart De Schuymer wrote: > Also, situations like eth0.15 being a bridge port of br0.16 seem > unwanted (to me). That should be: eth0.15 being a bridge port of br0, and sending locally generated traffic through br0.15. cheers, Bart From bdschuym@pandora.be Sat Aug 30 06:41:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 30 Aug 2003 06:42:02 -0700 (PDT) Received: from apate.telenet-ops.be (apate.telenet-ops.be [195.130.132.57]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7UDfHWZ031670 for ; Sat, 30 Aug 2003 06:41:18 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by apate.telenet-ops.be (Postfix) with SMTP id B0E2F37E47; Sat, 30 Aug 2003 15:03:54 +0200 (MEST) Received: from 192.168.123.138 (D5763FDE.kabel.telenet.be [213.118.63.222]) by apate.telenet-ops.be (Postfix) with ESMTP id 6CA1D37F31; Sat, 30 Aug 2003 15:03:45 +0200 (MEST) From: Bart De Schuymer To: "David S.Miller" Subject: [PATCH/RFC] disallow vlan devices on top of a logical bridge device Date: Sat, 30 Aug 2003 15:04:03 +0200 User-Agent: KMail/1.5 Cc: Stephen Hemminger , Ben Greear , netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200308301504.03241.bdschuym@pandora.be> X-archive-position: 5400 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bdschuym@pandora.be Precedence: bulk X-list: netdev Content-Length: 822 Lines: 27 Hi all, The patch below disables making vlan devices on top of bridge devices, f.e. br0.12 would be impossible. I'm no vlan expert, but I don't see the use for this and allowing it will make the bridge-nf code hairy if we want to let {ip,arp}tables see {IP,ARP} traffic that is embedded in a vlan header. Also, situations like eth0.15 being a bridge port of br0.16 seem unwanted (to me). Dave, please apply, unless someone more knowledgeable (than me) about this disagrees. cheers, Bart --- linux-2.6.0-test4/net/bridge/br_if.c.old 2003-08-30 13:51:26.000000000 +0200 +++ linux-2.6.0-test4/net/bridge/br_if.c 2003-08-30 14:38:58.000000000 +0200 @@ -98,6 +98,8 @@ static struct net_bridge *new_nb(const c if (!dev) return NULL; + dev->features |= NETIF_F_VLAN_CHALLENGED; + br = dev->priv; br->dev = dev; From vinay-rc@naturesoft.net Sat Aug 30 08:40:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 30 Aug 2003 08:41:06 -0700 (PDT) Received: from naturesoft.net ([203.145.184.221]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7UFeQWZ005064 for ; Sat, 30 Aug 2003 08:40:27 -0700 Received: from ashishnehra.naturesoft.com ([192.168.0.15] helo=lima.royalchallenge.com) by naturesoft.net with esmtp (Exim 3.35 #1) id 19t7jN-0006eM-00; Sat, 30 Aug 2003 21:03:37 +0530 Subject: [PATCH 2.4.22-pre1][NET] timer cleanups From: Vinay K Nallamothu To: netdev@oss.sgi.com Cc: LKML Content-Type: text/plain Organization: NatureSoft Private Limited Message-Id: <1062258097.8532.26.camel@lima.royalchallenge.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Sat, 30 Aug 2003 21:11:37 +0530 Content-Transfer-Encoding: 7bit X-archive-position: 5401 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vinay-rc@naturesoft.net Precedence: bulk X-list: netdev Content-Length: 13122 Lines: 390 Hi, This patch does the following timer code cleanup: 1. Change del_timer/add_timer to mod_timer 2. Use static timer initialisation wherever applicable drivers/net/hamradio/6pack.c | 38 ++++++++++---------------------- drivers/net/wan/sdla_ppp.c | 4 --- net/atm/lec.c | 5 ---- net/ipv4/netfilter/ip_conntrack_core.c | 12 ++++------ net/ipv4/netfilter/ip_fw_compat_redir.c | 12 +++------- net/ipv6/ip6_flowlabel.c | 12 ++++------ net/netrom/nr_loopback.c | 19 +++------------- net/rose/rose_loopback.c | 20 +++------------- net/sched/sch_cbq.c | 7 ++--- net/sched/sch_sfq.c | 11 ++++----- net/wanrouter/af_wanpipe.c | 7 +---- 11 files changed, 46 insertions(+), 101 deletions(-) diff -urN linux-2.4.22/drivers/net/hamradio/6pack.c linux-2.4.22-nvk/drivers/net/hamradio/6pack.c --- linux-2.4.22/drivers/net/hamradio/6pack.c 2003-06-14 10:03:18.000000000 +0530 +++ linux-2.4.22-nvk/drivers/net/hamradio/6pack.c 2003-08-30 15:26:04.000000000 +0530 @@ -140,7 +140,7 @@ MODULE_PARM(sixpack_maxdev, "i"); MODULE_PARM_DESC(sixpack_maxdev, "number of 6PACK devices"); -static void sp_start_tx_timer(struct sixpack *); +static inline void sp_start_tx_timer(struct sixpack *); static void sp_xmit_on_air(unsigned long); static void resync_tnc(unsigned long); static void sixpack_decode(struct sixpack *, unsigned char[], int); @@ -480,7 +480,12 @@ netif_start_queue(dev); init_timer(&sp->tx_t); + sp->tx_t.data = (unsigned long) sp; + sp->tx_t.function = sp_xmit_on_air; + init_timer(&sp->resync_t); + sp->resync_t.data = (unsigned long) sp; + sp->resync_t.function = resync_tnc; return 0; } @@ -803,15 +808,10 @@ /* ----> 6pack timer interrupt handler and friends. <---- */ -static void sp_start_tx_timer(struct sixpack *sp) +static inline void sp_start_tx_timer(struct sixpack *sp) { int when = sp->slottime; - - del_timer(&sp->tx_t); - sp->tx_t.data = (unsigned long) sp; - sp->tx_t.function = sp_xmit_on_air; - sp->tx_t.expires = jiffies + ((when+1)*HZ)/100; - add_timer(&sp->tx_t); + mod_timer(&sp->tx_t, jiffies + ((when+1)*HZ)/100); } @@ -883,12 +883,7 @@ sp->tty->driver.write(sp->tty, 0, &inbyte, 1); - del_timer(&sp->resync_t); - sp->resync_t.data = (unsigned long) sp; - sp->resync_t.function = resync_tnc; - sp->resync_t.expires = jiffies + SIXP_RESYNC_TIMEOUT; - add_timer(&sp->resync_t); - + mod_timer(&sp->resync_t.expires, jiffies + SIXP_RESYNC_TIMEOUT); return 0; } @@ -940,13 +935,8 @@ /* if the state byte has been received, the TNC is present, so the resync timer can be reset. */ - if (sp->tnc_ok == 1) { - del_timer(&sp->resync_t); - sp->resync_t.data = (unsigned long) sp; - sp->resync_t.function = resync_tnc; - sp->resync_t.expires = jiffies + SIXP_INIT_RESYNC_TIMEOUT; - add_timer(&sp->resync_t); - } + if (sp->tnc_ok == 1) + mod_timer(&sp->resync_t, jiffies + SIXP_INIT_RESYNC_TIMEOUT); sp->status1 = cmd & SIXP_PRIO_DATA_MASK; } @@ -982,11 +972,7 @@ /* Start resync timer again -- the TNC might be still absent */ - del_timer(&sp->resync_t); - sp->resync_t.data = (unsigned long) sp; - sp->resync_t.function = resync_tnc; - sp->resync_t.expires = jiffies + SIXP_RESYNC_TIMEOUT; - add_timer(&sp->resync_t); + mod_timer(&sp->resync_t, jiffies + SIXP_RESYNC_TIMEOUT); } diff -urN linux-2.4.22/drivers/net/wan/sdla_ppp.c linux-2.4.22-nvk/drivers/net/wan/sdla_ppp.c --- linux-2.4.22/drivers/net/wan/sdla_ppp.c 2003-06-14 10:03:17.000000000 +0530 +++ linux-2.4.22-nvk/drivers/net/wan/sdla_ppp.c 2003-08-26 11:12:56.000000000 +0530 @@ -841,9 +841,7 @@ /* Start the PPP configuration after 1sec delay. * This will give the interface initilization time * to finish its configuration */ - del_timer(&ppp_priv_area->poll_delay_timer); - ppp_priv_area->poll_delay_timer.expires = jiffies+HZ; - add_timer(&ppp_priv_area->poll_delay_timer); + mod_timer(&ppp_priv_area->poll_delay_timer, jiffies + HZ); return 0; } diff -urN linux-2.4.22/net/atm/lec.c linux-2.4.22-nvk/net/atm/lec.c --- linux-2.4.22/net/atm/lec.c 2003-08-26 10:08:26.000000000 +0530 +++ linux-2.4.22-nvk/net/atm/lec.c 2003-08-30 16:37:57.000000000 +0530 @@ -1489,8 +1489,6 @@ entry = (struct lec_arp_table *)data; - del_timer(&entry->timer); - DPRINTK("lec_arp_expire_arp\n"); if (entry->status == ESI_ARP_PENDING) { if (entry->no_tries <= entry->priv->max_retry_count) { @@ -1500,8 +1498,7 @@ send_to_lecd(entry->priv, l_arp_xmt, entry->mac_addr, NULL, NULL); entry->no_tries++; } - entry->timer.expires = jiffies + (1*HZ); - add_timer(&entry->timer); + mod_timer(&entry->timer, jiffies + 1 * HZ); } } diff -urN linux-2.4.22/net/ipv4/netfilter/ip_conntrack_core.c linux-2.4.22-nvk/net/ipv4/netfilter/ip_conntrack_core.c --- linux-2.4.22/net/ipv4/netfilter/ip_conntrack_core.c 2003-08-26 10:08:30.000000000 +0530 +++ linux-2.4.22-nvk/net/ipv4/netfilter/ip_conntrack_core.c 2003-08-26 21:54:45.000000000 +0530 @@ -954,13 +954,12 @@ the data filled out by the helper over the old one */ DEBUGP("expect_related: resent packet\n"); if (related_to->helper->timeout) { - if (!del_timer(&old->timeout)) { + if (!timer_pending(&old->timeout)) { /* expectation is dying. Fall through */ old = NULL; } else { - old->timeout.expires = jiffies + - related_to->helper->timeout * HZ; - add_timer(&old->timeout); + mod_timer(&old->timeout, jiffies + + related_to->helper->timeout * HZ); } } @@ -1182,9 +1181,8 @@ ct->timeout.expires = extra_jiffies; else { /* Need del_timer for race avoidance (may already be dying). */ - if (del_timer(&ct->timeout)) { - ct->timeout.expires = jiffies + extra_jiffies; - add_timer(&ct->timeout); + if (timer_pending(&ct->timeout)) { + mod_timer(&ct->timeout, extra_jiffies); } } WRITE_UNLOCK(&ip_conntrack_lock); diff -urN linux-2.4.22/net/ipv4/netfilter/ip_fw_compat_redir.c linux-2.4.22-nvk/net/ipv4/netfilter/ip_fw_compat_redir.c --- linux-2.4.22/net/ipv4/netfilter/ip_fw_compat_redir.c 2003-06-14 10:03:12.000000000 +0530 +++ linux-2.4.22-nvk/net/ipv4/netfilter/ip_fw_compat_redir.c 2003-08-30 14:41:23.000000000 +0530 @@ -270,10 +270,8 @@ if (redir) { DEBUGP("Doing tcp redirect again.\n"); do_tcp_redir(skb, redir); - if (del_timer(&redir->destroyme)) { - redir->destroyme.expires = jiffies + REDIR_TIMEOUT; - add_timer(&redir->destroyme); - } + if (timer_pending(&redir->destroyme)) + mod_timer(&redir->destroyme, jiffies + REDIR_TIMEOUT); } UNLOCK_BH(&redir_lock); } @@ -298,10 +296,8 @@ if (redir) { DEBUGP("Doing tcp unredirect.\n"); do_tcp_unredir(skb, redir); - if (del_timer(&redir->destroyme)) { - redir->destroyme.expires = jiffies + REDIR_TIMEOUT; - add_timer(&redir->destroyme); - } + if (timer_pending(&redir->destroyme)) + mod_timer(&redir->destroyme, jiffies + REDIR_TIMEOUT); } UNLOCK_BH(&redir_lock); } diff -urN linux-2.4.22/net/ipv6/ip6_flowlabel.c linux-2.4.22-nvk/net/ipv6/ip6_flowlabel.c --- linux-2.4.22/net/ipv6/ip6_flowlabel.c 2003-06-14 10:03:12.000000000 +0530 +++ linux-2.4.22-nvk/net/ipv6/ip6_flowlabel.c 2003-08-26 21:10:46.000000000 +0530 @@ -48,7 +48,8 @@ static atomic_t fl_size = ATOMIC_INIT(0); static struct ip6_flowlabel *fl_ht[FL_HASH_MASK+1]; -static struct timer_list ip6_fl_gc_timer; +static void ip6_fl_gc(unsigned long dummy); +static struct timer_list ip6_fl_gc_timer = TIMER_INITIALIZER(ip6_fl_gc, 0, 0); /* FL hash table lock: it protects only of GC */ @@ -103,10 +104,9 @@ fl->opt = NULL; kfree(opt); } - if (!del_timer(&ip6_fl_gc_timer) || - (long)(ip6_fl_gc_timer.expires - ttd) > 0) - ip6_fl_gc_timer.expires = ttd; - add_timer(&ip6_fl_gc_timer); + if (!timer_pending(&ip6_fl_gc_timer) || + time_after(ip6_fl_gc_timer.expires, ttd)) + mod_timer(&ip6_fl_gc_timer, ttd); } } @@ -609,8 +609,6 @@ void ip6_flowlabel_init() { - init_timer(&ip6_fl_gc_timer); - ip6_fl_gc_timer.function = ip6_fl_gc; #ifdef CONFIG_PROC_FS create_proc_read_entry("net/ip6_flowlabel", 0, 0, ip6_fl_read_proc, NULL); #endif diff -urN linux-2.4.22/net/netrom/nr_loopback.c linux-2.4.22-nvk/net/netrom/nr_loopback.c --- linux-2.4.22/net/netrom/nr_loopback.c 2003-06-14 10:03:12.000000000 +0530 +++ linux-2.4.22-nvk/net/netrom/nr_loopback.c 2003-08-30 16:21:47.000000000 +0530 @@ -23,8 +23,10 @@ #include #include +static void nr_loopback_timer(unsigned long); + static struct sk_buff_head loopback_queue; -static struct timer_list loopback_timer; +static struct timer_list loopback_timer = TIMER_INITIALIZER(nr_loopback_timer, 0, 0); static void nr_set_loopback_timer(void); @@ -51,26 +53,13 @@ skb_queue_tail(&loopback_queue, skbn); if (!nr_loopback_running()) - nr_set_loopback_timer(); + mod_timer(&loopback_timer, jiffies + 10); } kfree_skb(skb); return 1; } -static void nr_loopback_timer(unsigned long); - -static void nr_set_loopback_timer(void) -{ - del_timer(&loopback_timer); - - loopback_timer.data = 0; - loopback_timer.function = &nr_loopback_timer; - loopback_timer.expires = jiffies + 10; - - add_timer(&loopback_timer); -} - static void nr_loopback_timer(unsigned long param) { struct sk_buff *skb; diff -urN linux-2.4.22/net/rose/rose_loopback.c linux-2.4.22-nvk/net/rose/rose_loopback.c --- linux-2.4.22/net/rose/rose_loopback.c 2003-06-14 10:03:13.000000000 +0530 +++ linux-2.4.22-nvk/net/rose/rose_loopback.c 2003-08-30 15:41:40.000000000 +0530 @@ -22,10 +22,10 @@ #include #include -static struct sk_buff_head loopback_queue; -static struct timer_list loopback_timer; +static void rose_loopback_timer(unsigned long); -static void rose_set_loopback_timer(void); +static struct sk_buff_head loopback_queue; +static struct timer_list loopback_timer = TIMER_INITIALIZER(rose_loopback_timer, 0, 0); void rose_loopback_init(void) { @@ -51,24 +51,12 @@ skb_queue_tail(&loopback_queue, skbn); if (!rose_loopback_running()) - rose_set_loopback_timer(); + mod_timer(&loopback_timer, jiffies + 10); } return 1; } -static void rose_loopback_timer(unsigned long); - -static void rose_set_loopback_timer(void) -{ - del_timer(&loopback_timer); - - loopback_timer.data = 0; - loopback_timer.function = &rose_loopback_timer; - loopback_timer.expires = jiffies + 10; - - add_timer(&loopback_timer); -} static void rose_loopback_timer(unsigned long param) { diff -urN linux-2.4.22/net/sched/sch_cbq.c linux-2.4.22-nvk/net/sched/sch_cbq.c --- linux-2.4.22/net/sched/sch_cbq.c 2003-08-26 10:08:36.000000000 +0530 +++ linux-2.4.22-nvk/net/sched/sch_cbq.c 2003-08-30 14:56:04.000000000 +0530 @@ -554,10 +554,9 @@ cl->penalized = sched; cl->cpriority = TC_CBQ_MAXPRIO; q->pmask |= (1<delay_timer) && - (long)(q->delay_timer.expires - sched) > 0) - q->delay_timer.expires = sched; - add_timer(&q->delay_timer); + if (timer_pending(&q->delay_timer) && + time_after(q->delay_timer.expires, sched)) + mod_timer(&q->delay_timer, sched); cl->delayed = 1; cl->xstats.overactions++; return; diff -urN linux-2.4.22/net/sched/sch_sfq.c linux-2.4.22-nvk/net/sched/sch_sfq.c --- linux-2.4.22/net/sched/sch_sfq.c 2003-08-26 10:08:36.000000000 +0530 +++ linux-2.4.22-nvk/net/sched/sch_sfq.c 2003-08-30 14:51:57.000000000 +0530 @@ -371,7 +371,6 @@ struct sfq_sched_data *q = (struct sfq_sched_data *)sch->data; q->perturbation = net_random()&0x1F; - q->perturb_timer.expires = jiffies + q->perturb_period; if (q->perturb_period) { q->perturb_timer.expires = jiffies + q->perturb_period; @@ -396,11 +395,11 @@ while (sch->q.qlen >= q->limit-1) sfq_drop(sch); - del_timer(&q->perturb_timer); - if (q->perturb_period) { - q->perturb_timer.expires = jiffies + q->perturb_period; - add_timer(&q->perturb_timer); - } + if (q->perturb_period) + mod_timer(&q->perturb_timer, jiffies + q->perturb_period); + else + del_timer(&q->perturb_timer); + sch_tree_unlock(sch); return 0; } diff -urN linux-2.4.22/net/wanrouter/af_wanpipe.c linux-2.4.22-nvk/net/wanrouter/af_wanpipe.c --- linux-2.4.22/net/wanrouter/af_wanpipe.c 2003-06-14 10:03:13.000000000 +0530 +++ linux-2.4.22-nvk/net/wanrouter/af_wanpipe.c 2003-08-26 11:21:31.000000000 +0530 @@ -649,11 +649,8 @@ skb_queue_tail(&sk->write_queue,skb); atomic_inc(&sk->protinfo.af_wanpipe->packet_sent); - if (!(test_and_set_bit(0,&sk->protinfo.af_wanpipe->timer))){ - del_timer(&sk->protinfo.af_wanpipe->tx_timer); - sk->protinfo.af_wanpipe->tx_timer.expires=jiffies+1; - add_timer(&sk->protinfo.af_wanpipe->tx_timer); - } + if (!test_and_set_bit(0,&sk->protinfo.af_wanpipe->timer)) + mod_timer(&sk->protinfo.af_wanpipe->tx_timer, jiffies + 1); return(len); From jgarzik@pobox.com Sat Aug 30 10:51:04 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 30 Aug 2003 10:51:39 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7UHp3WZ015268 for ; Sat, 30 Aug 2003 10:51:04 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:33083 helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.22) id 19t9sL-0003Nf-Nq; Sat, 30 Aug 2003 18:51:01 +0100 Message-ID: <3F50E3FD.1000703@pobox.com> Date: Sat, 30 Aug 2003 13:50:53 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: mzyngier@freesurf.fr CC: akpm@osdl.org, linux-net@vger.kernel.org, Maillist netdev Subject: Re: [PATCH][2.6] de4x5 cleanup References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5404 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 Content-Length: 1004 Lines: 33 Marc Zyngier wrote: > Jeff, Andrew, > > The enclosed patch tries to clean the tulip de4x5 driver, and update > it to some of the 2.6 APIs : > > - Use PCI and EISA probing APIs > - Use generic DMA API > - Fix DE425 init on the Jensen > - Remove de4x5 from Space.c > > It's been tested on x86 and Alpha, with a DE425 (21040, EISA), a DE435 > (21040, PCI) and a quad DLink (4*21143, PCI). > > The major problem with this patch is that, because of the Space.c > removal, interfaces get potentially renumbered. This has been > discussed to death on lkml, without any obvious solution. IMHO, we'd > better remove as many drivers as we can from Space.c before > 2.6.0-final ships... It looks pretty good. My big objection isn't the Space.c stuff but de4x5 itself. I had hoped it would be gone by now :) Oh well, not your fault. A quick review of the patch looks good, and this is work that has long wanted doing (if de4x5 wasn't simply erased). I'll apply after a more thorough review. Jeff From shmulik.hen@intel.com Sat Aug 30 12:01:20 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 30 Aug 2003 12:01:53 -0700 (PDT) Received: from hermes.hd.intel.com (fmr09.intel.com [192.52.57.35]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7UJ1JWZ020594 for ; Sat, 30 Aug 2003 12:01:20 -0700 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.79 2003/08/28 20:22:14 dmccart Exp $) with ESMTP id h7UIwuO18250 for ; Sat, 30 Aug 2003 18:58:56 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.hd.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 h7UIu5I09986 for ; Sat, 30 Aug 2003 18:56:06 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.254.188]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003083012010911562 ; Sat, 30 Aug 2003 12:01:10 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Shmulik Hen Reply-To: shmulik.hen@intel.com Organization: Intel corp. To: Jeff Garzik Subject: Re: [bonding][1/3] Synchronizing 2.4-2.6 Date: Sat, 30 Aug 2003 22:01:08 +0300 User-Agent: KMail/1.4.3 Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com References: <200308272000.39229.shmulik.hen@intel.com> <3F4D2355.8010803@pobox.com> In-Reply-To: <3F4D2355.8010803@pobox.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200308302201.09003.shmulik.hen@intel.com> X-archive-position: 5405 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Content-Length: 750 Lines: 21 On Thursday 28 August 2003 12:32 am, Jeff Garzik wrote: > Shmulik Hen wrote: > > > patch 6 - Update versions/contributions in header and bump > > version > > applied... even though a non-described ifenslave.c change snuck > into this patch. This patch was supposed to put some order into a bunch of bug fix patches that went in without going through an official maintainer. I was afraid they're going to get lost, so I stuck the above into a patch. One of those patches fixed compilation problems on ia64 architecture, but caused problems in a Red Hat release instead. Since I didn't see a separate patch for that, I thought I'll put it here too. Didn't think it'll cause problems as it was a one-liner. I'll learn eventually :). Shmulik. From shmulik.hen@intel.com Sat Aug 30 12:05:56 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 30 Aug 2003 12:06:29 -0700 (PDT) Received: from hermes.hd.intel.com (fmr09.intel.com [192.52.57.35]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7UJ5tWZ021161 for ; Sat, 30 Aug 2003 12:05:55 -0700 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.79 2003/08/28 20:22:14 dmccart Exp $) with ESMTP id h7UJ3WO19765 for ; Sat, 30 Aug 2003 19:03:32 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.hd.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 h7UJ0fI12067 for ; Sat, 30 Aug 2003 19:00:41 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.254.188]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003083012054623352 ; Sat, 30 Aug 2003 12:05:47 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Shmulik Hen Reply-To: shmulik.hen@intel.com Organization: Intel corp. To: , Subject: Re: [bonding][0/3] Synchronizing 2.4-2.6 Date: Sat, 30 Aug 2003 22:05:45 +0300 User-Agent: KMail/1.4.3 References: <200308271958.52063.shmulik.hen@intel.com> In-Reply-To: <200308271958.52063.shmulik.hen@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200308302205.45924.shmulik.hen@intel.com> X-archive-position: 5406 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Content-Length: 620 Lines: 21 On Wednesday 27 August 2003 07:58 pm, Hen, Shmulik wrote: > > Next in store are: > o Stephen Hemminger's converting bonding driver /proc interface to > seq_file, along with changing /proc/bond0/info to > /proc/bonding/bond0 Forgot to mention free_netdev(). Is it 2.4 compatible ? > o cleanup of the 802.3ad code (was not included in this release > since it requires some code re-factoring first). > o lots of new stuff :) -- | Shmulik Hen Advanced Network Services | | Israel Design Center, Jerusalem | | LAN Access Division, Platform Networking | | Intel Communications Group, Intel corp. | From maz@misterjones.org Sat Aug 30 12:06:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 30 Aug 2003 12:06:50 -0700 (PDT) Received: from young-lust.wild-wind.fr.eu.org (lopsy-lu.misterjones.org [62.4.18.26]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7UJ6GWZ021186 for ; Sat, 30 Aug 2003 12:06:17 -0700 Received: from hina.wild-wind.fr.eu.org ([192.168.70.139]) by young-lust.wild-wind.fr.eu.org with esmtp (Exim 3.35 #1 (Debian)) id 19tB6Y-0000Ff-00; Sat, 30 Aug 2003 21:09:46 +0200 Received: from maz by hina.wild-wind.fr.eu.org with local (Exim 3.36 #1 (Debian)) id 19tB1G-0005yi-00; Sat, 30 Aug 2003 21:04:18 +0200 To: Jeff Garzik Cc: akpm@osdl.org, linux-net@vger.kernel.org, Maillist netdev Subject: Re: [PATCH][2.6] de4x5 cleanup Organization: Metropolis -- Nowhere X-Attribution: maz Reply-to: mzyngier@freesurf.fr References: <3F50E3FD.1000703@pobox.com> From: Marc Zyngier Date: Sat, 30 Aug 2003 21:04:18 +0200 Message-ID: In-Reply-To: <3F50E3FD.1000703@pobox.com> (Jeff Garzik's message of "Sat, 30 Aug 2003 13:50:53 -0400") MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 5407 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mzyngier@freesurf.fr Precedence: bulk X-list: netdev Content-Length: 580 Lines: 18 >>>>> "Jeff" == Jeff Garzik writes: Jeff> It looks pretty good. My big objection isn't the Space.c stuff Jeff> but de4x5 itself. I had hoped it would be gone by now :) Oh Jeff> well, not your fault. Well... I too, had hoped the tulip (and its dc21040 derivative) driver would be the only one. While it works nicely on modern stuff (2114[023]), it has some problems on a few of my test boxes (mostly Alphas with onboard 21040). And most of all, tulip doesn't support EISA :-). Thanks, M. -- Places change, faces change. Life is so very strange. From shmulik.hen@intel.com Sat Aug 30 12:39:51 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 30 Aug 2003 12:40:25 -0700 (PDT) Received: from hermes.hd.intel.com (fmr09.intel.com [192.52.57.35]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7UJdoWZ023269 for ; Sat, 30 Aug 2003 12:39:50 -0700 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.79 2003/08/28 20:22:14 dmccart Exp $) with ESMTP id h7UJbQO02116 for ; Sat, 30 Aug 2003 19:37:27 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.hd.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 h7UJYaI27490 for ; Sat, 30 Aug 2003 19:34:36 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.254.188]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003083012394025040 ; Sat, 30 Aug 2003 12:39:42 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Shmulik Hen Reply-To: shmulik.hen@intel.com Organization: Intel corp. To: Jeff Garzik Subject: Re: [Bonding-devel] Re: [bonding][2/3] Synchronizing 2.4-2.6 Date: Sat, 30 Aug 2003 22:39:40 +0300 User-Agent: KMail/1.4.3 Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com References: <3F4E27A2.9060204@pobox.com> In-Reply-To: <3F4E27A2.9060204@pobox.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200308302239.40237.shmulik.hen@intel.com> X-archive-position: 5408 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Content-Length: 829 Lines: 22 On Thursday 28 August 2003 07:02 pm, Jeff Garzik wrote: > Hen, Shmulik wrote: > > After patch set 1, It should be as easy as just copying all the > > bonding related files from 2.4 to 2.6. I guess I can do that on > > Sunday if someone hasn't already done it before. > > I had hoped to preserve the revision history. Simply copying the > files over does not do that :( > > What I mean by preserving revision history is, changes should be > submitted to 2.6 in the same granularity as they were to 2.4... > God, I wish I was an English speaking person... :( Amir, on the other hand, understood exactly what you intended, so there should be something ready for tomorrow that brings 2.6 to the same point as 2.4 after set 1, in small steps. After that, sets 2 and 3 could be applied the same way for 2.4 and 2.6. Shmulik. From greearb@candelatech.com Sat Aug 30 12:46:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 30 Aug 2003 12:47:04 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-084.evrtwa1.dsl-verizon.net [4.33.45.84]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7UJkUWZ023880 for ; Sat, 30 Aug 2003 12:46:31 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h7UJkMFo013594; Sat, 30 Aug 2003 12:46:23 -0700 Message-ID: <3F50FF0E.9020004@candelatech.com> Date: Sat, 30 Aug 2003 12:46:22 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bart De Schuymer CC: "David S.Miller" , Stephen Hemminger , netdev@oss.sgi.com, vlan@wanfear.com Subject: Re: [PATCH/RFC] disallow vlan devices on top of a logical bridge device References: <200308301504.03241.bdschuym@pandora.be> In-Reply-To: <200308301504.03241.bdschuym@pandora.be> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5409 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 1291 Lines: 44 Bart De Schuymer wrote: > Hi all, > > The patch below disables making vlan devices on top of bridge > devices, f.e. br0.12 would be impossible. > I'm no vlan expert, but I don't see the use for this and allowing it > will make the bridge-nf code hairy if we want to let {ip,arp}tables see > {IP,ARP} traffic that is embedded in a vlan header. > Also, situations like eth0.15 being a bridge port of br0.16 seem > unwanted (to me). > Dave, please apply, unless someone more knowledgeable (than me) about > this disagrees. I have never tried to do this, so I don't have a problem with this patch. However, I'm forwarding this to the vlan mailing list, as I know there are folks there who use vlans and bridging a lot.... For those who care, please speak up if you need this functionality for some reason... Ben > > cheers, > Bart > > --- linux-2.6.0-test4/net/bridge/br_if.c.old 2003-08-30 13:51:26.000000000 +0200 > +++ linux-2.6.0-test4/net/bridge/br_if.c 2003-08-30 14:38:58.000000000 +0200 > @@ -98,6 +98,8 @@ static struct net_bridge *new_nb(const c > if (!dev) > return NULL; > > + dev->features |= NETIF_F_VLAN_CHALLENGED; > + > br = dev->priv; > br->dev = dev; > > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb@candelatech.com Sat Aug 30 12:56:08 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 30 Aug 2003 12:56:41 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-084.evrtwa1.dsl-verizon.net [4.33.45.84]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7UJu7WZ024591 for ; Sat, 30 Aug 2003 12:56:08 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h7UJtpFo013699; Sat, 30 Aug 2003 12:55:52 -0700 Message-ID: <3F510147.8070309@candelatech.com> Date: Sat, 30 Aug 2003 12:55:51 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: shmulik.hen@intel.com CC: Jeff Garzik , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [Bonding-devel] Re: [bonding][2/3] Synchronizing 2.4-2.6 References: <3F4E27A2.9060204@pobox.com> <200308302239.40237.shmulik.hen@intel.com> In-Reply-To: <200308302239.40237.shmulik.hen@intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5410 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 760 Lines: 29 Shmulik Hen wrote: > On Thursday 28 August 2003 07:02 pm, Jeff Garzik wrote: > >>Hen, Shmulik wrote: >> >>>After patch set 1, It should be as easy as just copying all the >>>bonding related files from 2.4 to 2.6. I guess I can do that on >>>Sunday if someone hasn't already done it before. >> >>I had hoped to preserve the revision history. Simply copying the >>files over does not do that :( >> >>What I mean by preserving revision history is, changes should be >>submitted to 2.6 in the same granularity as they were to 2.4... >> > > > God, I wish I was an English speaking person... :( Don't feel bad, I had no clue what he was asking for either :) Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From jgarzik@pobox.com Sat Aug 30 13:28:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 30 Aug 2003 13:29:21 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7UKSjWZ026481 for ; Sat, 30 Aug 2003 13:28:46 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:33159 helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.22) id 19tBD4-0003sQ-1J; Sat, 30 Aug 2003 20:16:30 +0100 Message-ID: <3F50F805.9090805@pobox.com> Date: Sat, 30 Aug 2003 15:16:21 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: mzyngier@freesurf.fr CC: akpm@osdl.org, linux-net@vger.kernel.org, Maillist netdev Subject: Re: [PATCH][2.6] de4x5 cleanup References: <3F50E3FD.1000703@pobox.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5411 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 Content-Length: 1058 Lines: 32 Marc Zyngier wrote: >>>>>>"Jeff" == Jeff Garzik writes: > > > Jeff> It looks pretty good. My big objection isn't the Space.c stuff > Jeff> but de4x5 itself. I had hoped it would be gone by now :) Oh > Jeff> well, not your fault. > > Well... I too, had hoped the tulip (and its dc21040 derivative) > driver would be the only one. While it works nicely on modern stuff > (2114[023]), it has some problems on a few of my test boxes (mostly > Alphas with onboard 21040). Well, 2.6 tulip intentionally doesn't work at all on 21040 and 21041 :) That's what de2104x driver is for. Can you give that a beating, and verify that it works for you? I know that 2114x chips with sym phys still have some issues; jamal has created a patch that fixes that (mostly updates tulip with the latest Becker phy code from Donald's tulip.c), which in turn fixes some 2114x issues on alpha. > And most of all, tulip doesn't support EISA :-). If it meant I could kill de4x5, then I would be all for adding EISA support to tulip... :) Jeff From maz@misterjones.org Sat Aug 30 14:24:06 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 30 Aug 2003 14:24:38 -0700 (PDT) Received: from young-lust.wild-wind.fr.eu.org (lopsy-lu.misterjones.org [62.4.18.26]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7ULO4WZ029374 for ; Sat, 30 Aug 2003 14:24:05 -0700 Received: from hina.wild-wind.fr.eu.org ([192.168.70.139]) by young-lust.wild-wind.fr.eu.org with esmtp (Exim 3.35 #1 (Debian)) id 19tDFr-0000NV-00; Sat, 30 Aug 2003 23:27:31 +0200 Received: from maz by hina.wild-wind.fr.eu.org with local (Exim 3.36 #1 (Debian)) id 19tDAY-00060m-00; Sat, 30 Aug 2003 23:22:02 +0200 To: Jeff Garzik Cc: akpm@osdl.org, linux-net@vger.kernel.org, Maillist netdev Subject: Re: [PATCH][2.6] de4x5 cleanup Organization: Metropolis -- Nowhere X-Attribution: maz Reply-to: mzyngier@freesurf.fr References: <3F50E3FD.1000703@pobox.com> <3F50F805.9090805@pobox.com> From: Marc Zyngier Date: Sat, 30 Aug 2003 23:22:02 +0200 Message-ID: In-Reply-To: <3F50F805.9090805@pobox.com> (Jeff Garzik's message of "Sat, 30 Aug 2003 15:16:21 -0400") MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 5412 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mzyngier@freesurf.fr Precedence: bulk X-list: netdev Content-Length: 968 Lines: 26 >>>>> "Jeff" == Jeff Garzik writes: Jeff> Well, 2.6 tulip intentionally doesn't work at all on 21040 and Jeff> 21041 :) That's what de2104x driver is for. Can you give that a Jeff> beating, and verify that it works for you? Last time I checked, I had ugly Oopses on one of my alpha boxes (AS-255), but that whas a few month ago, and I had other stuff to fix at the moment. I'll give it a go tomorrow. Jeff> If it meant I could kill de4x5, then I would be all for adding Jeff> EISA support to tulip... :) I'm afraid this would introduce a lot of the ugly crap that is currently in de4x5 (21040 is seen through an EISA to PCI bridge, with a sparse mapping)... I'll have a look at what we can do without introduce too many hacks. If de2104x behaves correctly, another solution would be to turn de4x5 to be EISA only. That would be a good way to finally kill it ;-). Thanks, M. -- Places change, faces change. Life is so very strange. From jgarzik@pobox.com Sat Aug 30 14:27:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 30 Aug 2003 14:28:08 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7ULRYWZ029912 for ; Sat, 30 Aug 2003 14:27:34 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:33177 helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.22) id 19tDFt-0004gk-FF; Sat, 30 Aug 2003 22:27:33 +0100 Message-ID: <3F5116BD.9030601@pobox.com> Date: Sat, 30 Aug 2003 17:27:25 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: shmulik.hen@intel.com CC: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [bonding][0/3] Synchronizing 2.4-2.6 References: <200308271958.52063.shmulik.hen@intel.com> <200308302205.45924.shmulik.hen@intel.com> In-Reply-To: <200308302205.45924.shmulik.hen@intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5413 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 Content-Length: 369 Lines: 19 Shmulik Hen wrote: > On Wednesday 27 August 2003 07:58 pm, Hen, Shmulik wrote: > >>Next in store are: >> o Stephen Hemminger's converting bonding driver /proc interface to >> seq_file, along with changing /proc/bond0/info to >> /proc/bonding/bond0 > > > Forgot to mention free_netdev(). > Is it 2.4 compatible ? Only if you create a patch for 2.4 :) Jeff From khc@pm.waw.pl Sat Aug 30 14:58:51 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 30 Aug 2003 14:59:23 -0700 (PDT) Received: from hq.pm.waw.pl (hq.pm.waw.pl [195.116.170.10]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7ULweWZ031663 for ; Sat, 30 Aug 2003 14:58:41 -0700 Received: by hq.pm.waw.pl (Postfix, from userid 10) id 6A2F73232; Sat, 30 Aug 2003 23:19:29 +0200 (CEST) Received: by defiant.pm.waw.pl (Postfix, from userid 500) id D1C383C7A0; Sat, 30 Aug 2003 23:16:00 +0200 (CEST) To: Bart De Schuymer Cc: "David S.Miller" , Stephen Hemminger , Ben Greear , netdev@oss.sgi.com Subject: Re: [PATCH/RFC] disallow vlan devices on top of a logical bridge device References: <200308301504.03241.bdschuym@pandora.be> From: Krzysztof Halasa Date: 30 Aug 2003 23:16:00 +0200 In-Reply-To: <200308301504.03241.bdschuym@pandora.be> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 5414 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: khc@pm.waw.pl Precedence: bulk X-list: netdev Content-Length: 549 Lines: 14 Bart De Schuymer writes: > The patch below disables making vlan devices on top of bridge > devices, f.e. br0.12 would be impossible. > I'm no vlan expert, but I don't see the use for this There could be some - I'm not using such setup, but I can imagine doing trunk bridging. This is sometimes used with dumb (non-VLAN but 1518 bytes-capable) switches. With Linux, it might be used as well, especially if someone wants STP to manage trunks and not VLANs (with many VLANs it may make perfect sense) -- Krzysztof Halasa, B*FH From AntiVir@zeus.unive.it Sat Aug 30 18:46:43 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 30 Aug 2003 18:47:16 -0700 (PDT) Received: from zeus.unive.it (zeus.unive.it [157.138.1.81]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7V1kfWZ010043 for ; Sat, 30 Aug 2003 18:46:42 -0700 Received: from zeus.unive.it (localhost.localdomain [127.0.0.1]) by zeus.unive.it (8.12.9/8.12.9) with ESMTP id h7V1kdKX002914 for ; Sun, 31 Aug 2003 03:46:39 +0200 Received: (from uucp@localhost) by zeus.unive.it (8.12.9/8.12.9/Submit) id h7V1kcsv002912 for ; Sun, 31 Aug 2003 03:46:38 +0200 Date: Sun, 31 Aug 2003 03:46:38 +0200 From: AntiVir@zeus.unive.it Message-Id: <200308310146.h7V1kcsv002912@zeus.unive.it> To: Subject: AntiVir ALERT [your mail: "Thank you!"] X-AntiVirus: checked by AntiVir Milter 1.0.0.8; AVE 6.21.0.1; VDF 6.21.0.32 X-archive-position: 5415 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: AntiVir@zeus.unive.it Precedence: bulk X-list: netdev * * * * * * * * * * * * * * * AntiVir ALERT * * * * * * * * * * * * * * * This version of AntiVir is licensed and full featured. AntiVir has detected the following in a mail from your address: Worm/Sobig.F The mail was not delivered. Please remove any potential malicious software from your computer before sending a new mail with attachments. Mail-Info: --8<-- From: To: Date: Sun, 31 Aug 2003 10:46:41 +0900 Subject: Thank you! --8<-- -- AntiVir for UNIX Copyright (C) 1994-2002 by H+BEDV Datentechnik GmbH. All rights reserved. For more information see http://www.antivir.de/ or http://www.hbedv.com/ From davem@pizda.ninka.net Sat Aug 30 19:14:09 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 30 Aug 2003 19:14: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.5) with SMTP id h7V2E9WZ011530 for ; Sat, 30 Aug 2003 19:14:09 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id TAA29706; Sat, 30 Aug 2003 19:05:16 -0700 Date: Sat, 30 Aug 2003 19:05:16 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: acme@conectiva.com.br, netdev@oss.sgi.com Subject: Re: [PATCH] (3/3) llc - set owner on /proc/net/llc directory Message-Id: <20030830190516.0738ee3d.davem@redhat.com> In-Reply-To: <20030829105140.72c5fad3.shemminger@osdl.org> References: <20030829105140.72c5fad3.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5416 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 All three LLC patches applied, thanks Stephen. From davem@pizda.ninka.net Sat Aug 30 19:14:55 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 30 Aug 2003 19:15:28 -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.5) with SMTP id h7V2EsWZ011588 for ; Sat, 30 Aug 2003 19:14:55 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id TAA29733; Sat, 30 Aug 2003 19:06:02 -0700 Date: Sat, 30 Aug 2003 19:06:02 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] econet - set socket owner field Message-Id: <20030830190602.53aaa259.davem@redhat.com> In-Reply-To: <20030829111855.1425b7aa.shemminger@osdl.org> References: <20030829111855.1425b7aa.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5417 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 29 Aug 2003 11:18:55 -0700 Stephen Hemminger wrote: > All sockets created by a protocol need to have owner field set > to prevent problems with orphaned sockets during module unload. Applied, thanks. From davem@pizda.ninka.net Sat Aug 30 19:15:43 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 30 Aug 2003 19:16:17 -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.5) with SMTP id h7V2FhWZ012013 for ; Sat, 30 Aug 2003 19:15:43 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id TAA29755; Sat, 30 Aug 2003 19:06:50 -0700 Date: Sat, 30 Aug 2003 19:06:50 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: acme@conectiva.com.br, netdev@oss.sgi.com Subject: Re: [PATCH] ipx - set socket owner field Message-Id: <20030830190650.0a785a8c.davem@redhat.com> In-Reply-To: <20030829113704.548a9af4.shemminger@osdl.org> References: <20030829113704.548a9af4.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5418 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 29 Aug 2003 11:37:04 -0700 Stephen Hemminger wrote: > All sockets created by a protocol need to have owner field set > to prevent problems with orphaned sockets during module unload. Applied, thanks. From davem@pizda.ninka.net Sat Aug 30 19:16:23 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 30 Aug 2003 19:16:55 -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.5) with SMTP id h7V2GMWZ012293 for ; Sat, 30 Aug 2003 19:16:23 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id TAA29777; Sat, 30 Aug 2003 19:07:28 -0700 Date: Sat, 30 Aug 2003 19:07:28 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: chas@cmf.nrl.navy.mil, netdev@oss.sgi.com Subject: Re: [PATCH] atm - set socket owner field Message-Id: <20030830190728.72e1599d.davem@redhat.com> In-Reply-To: <20030829113758.6970f039.shemminger@osdl.org> References: <20030829113758.6970f039.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5419 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 29 Aug 2003 11:37:58 -0700 Stephen Hemminger wrote: > All sockets created by a protocol need to have owner field set > to prevent problems with orphaned sockets during module unload. Applied, thanks. From davem@pizda.ninka.net Sat Aug 30 19:17:32 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 30 Aug 2003 19:18:05 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7V2HVWZ012886 for ; Sat, 30 Aug 2003 19:17:32 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id TAA29808; Sat, 30 Aug 2003 19:08:36 -0700 Date: Sat, 30 Aug 2003 19:08:36 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: ralf@linux-mips.org, linux-hams@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] set socket owner (ax25, rose, netrom) Message-Id: <20030830190836.41064340.davem@redhat.com> In-Reply-To: <20030829114208.40f10cca.shemminger@osdl.org> References: <20030829114208.40f10cca.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5420 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 29 Aug 2003 11:42:08 -0700 Stephen Hemminger wrote: > AX25, NETROM, ROSE all need to set the socket owner field, otherwise it is possible > to remove the module when there are orphaned sockets. Applied, thanks. From davem@pizda.ninka.net Sat Aug 30 19:18:10 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 30 Aug 2003 19:18: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.5) with SMTP id h7V2IAWZ012983 for ; Sat, 30 Aug 2003 19:18:10 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id TAA29839; Sat, 30 Aug 2003 19:09:17 -0700 Date: Sat, 30 Aug 2003 19:09:17 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: jt@bougret.hpl.hp.com, irda-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] irda - need to set socket owner Message-Id: <20030830190917.78b7a8a7.davem@redhat.com> In-Reply-To: <20030829114406.52a429bd.shemminger@osdl.org> References: <20030829114406.52a429bd.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5421 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 29 Aug 2003 11:44:06 -0700 Stephen Hemminger wrote: > All protocols need to set the socket owner field to prevent > module unloading when there are still orphaned sockets. Applied, thanks. From garzik@gtf.org Sat Aug 30 19:24:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 30 Aug 2003 19:25:22 -0700 (PDT) Received: from havoc.gtf.org (havoc.gtf.org [63.247.75.124]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7V2OdWZ013822 for ; Sat, 30 Aug 2003 19:24:40 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id 7A71D664A; Sat, 30 Aug 2003 22:24:30 -0400 (EDT) Date: Sat, 30 Aug 2003 22:24:30 -0400 From: Jeff Garzik To: netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: [RFR] 8139cp Message-ID: <20030831022430.GA10032@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: 5422 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev The previous sis190 review was a wild success, with tons of great feedback. Let's see if there's similar interest... I just updated 8139cp to use NAPI, and am calling it 1.0. Hit me with your best shot ;-) The code that follows is the 2.4 version, but the 2.6 version is practically the same (three one-line diffs). Jeff /* 8139cp.c: A Linux PCI Ethernet driver for the RealTek 8139C+ chips. */ /* Copyright 2001,2002 Jeff Garzik Copyright (C) 2001, 2002 David S. Miller (davem@redhat.com) [tg3.c] Copyright (C) 2000, 2001 David S. Miller (davem@redhat.com) [sungem.c] Copyright 2001 Manfred Spraul [natsemi.c] Copyright 1999-2001 by Donald Becker. [natsemi.c] Written 1997-2001 by Donald Becker. [8139too.c] Copyright 1998-2001 by Jes Sorensen, . [acenic.c] This software may be used and distributed according to the terms of the GNU General Public License (GPL), incorporated herein by reference. Drivers based on or derived from this code fall under the GPL and must retain the authorship, copyright and license notice. This file is not a complete program and may only be used when the entire operating system is licensed under the GPL. See the file COPYING in this distribution for more information. Contributors: Wake-on-LAN support - Felipe Damasio PCI suspend/resume - Felipe Damasio LinkChg interrupt - Felipe Damasio TODO: * Test Tx checksumming thoroughly * dev->tx_timeout Low priority TODO: * Complete reset on PciErr * Consider Rx interrupt mitigation using TimerIntr * Investigate using skb->priority with h/w VLAN priority * Investigate using High Priority Tx Queue with skb->priority * Adjust Rx FIFO threshold and Max Rx DMA burst on Rx FIFO error * Adjust Tx FIFO threshold and Max Tx DMA burst on Tx FIFO error * Implement Tx software interrupt mitigation via Tx descriptor bit * The real minimum of CP_MIN_MTU is 4 bytes. However, for this to be supported, one must(?) turn on packet padding. * Support external MII transceivers (patch available) NOTES: * TX checksumming is considered experimental. It is off by default, use ethtool to turn it on. */ #define DRV_NAME "8139cp" #define DRV_VERSION "1.0" #define DRV_RELDATE "Aug 30, 2003" #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include /* VLAN tagging feature enable/disable */ #if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE) #define CP_VLAN_TAG_USED 1 #define CP_VLAN_TX_TAG(tx_desc,vlan_tag_value) \ do { (tx_desc)->opts2 = (vlan_tag_value); } while (0) #else #define CP_VLAN_TAG_USED 0 #define CP_VLAN_TX_TAG(tx_desc,vlan_tag_value) \ do { (tx_desc)->opts2 = 0; } while (0) #endif /* These identify the driver base version and may not be removed. */ static char version[] __devinitdata = KERN_INFO DRV_NAME ": 10/100 PCI Ethernet driver v" DRV_VERSION " (" DRV_RELDATE ")\n"; MODULE_AUTHOR("Jeff Garzik "); MODULE_DESCRIPTION("RealTek RTL-8139C+ series 10/100 PCI Ethernet driver"); MODULE_LICENSE("GPL"); static int debug = -1; MODULE_PARM (debug, "i"); MODULE_PARM_DESC (debug, "8139cp: bitmapped message enable number"); /* Maximum number of multicast addresses to filter (vs. Rx-all-multicast). The RTL chips use a 64 element hash table based on the Ethernet CRC. */ static int multicast_filter_limit = 32; MODULE_PARM (multicast_filter_limit, "i"); MODULE_PARM_DESC (multicast_filter_limit, "8139cp: maximum number of filtered multicast addresses"); #define PFX DRV_NAME ": " #ifndef TRUE #define FALSE 0 #define TRUE (!FALSE) #endif #define CP_DEF_MSG_ENABLE (NETIF_MSG_DRV | \ NETIF_MSG_PROBE | \ NETIF_MSG_LINK) #define CP_NUM_STATS 14 /* struct cp_dma_stats, plus one */ #define CP_STATS_SIZE 64 /* size in bytes of DMA stats block */ #define CP_REGS_SIZE (0xff + 1) #define CP_REGS_VER 1 /* version 1 */ #define CP_RX_RING_SIZE 64 #define CP_TX_RING_SIZE 64 #define CP_RING_BYTES \ ((sizeof(struct cp_desc) * CP_RX_RING_SIZE) + \ (sizeof(struct cp_desc) * CP_TX_RING_SIZE) + \ CP_STATS_SIZE) #define NEXT_TX(N) (((N) + 1) & (CP_TX_RING_SIZE - 1)) #define NEXT_RX(N) (((N) + 1) & (CP_RX_RING_SIZE - 1)) #define TX_BUFFS_AVAIL(CP) \ (((CP)->tx_tail <= (CP)->tx_head) ? \ (CP)->tx_tail + (CP_TX_RING_SIZE - 1) - (CP)->tx_head : \ (CP)->tx_tail - (CP)->tx_head - 1) #define PKT_BUF_SZ 1536 /* Size of each temporary Rx buffer.*/ #define RX_OFFSET 2 #define CP_INTERNAL_PHY 32 /* The following settings are log_2(bytes)-4: 0 == 16 bytes .. 6==1024, 7==end of packet. */ #define RX_FIFO_THRESH 5 /* Rx buffer level before first PCI xfer. */ #define RX_DMA_BURST 4 /* Maximum PCI burst, '4' is 256 */ #define TX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */ #define TX_EARLY_THRESH 256 /* Early Tx threshold, in bytes */ /* Time in jiffies before concluding the transmitter is hung. */ #define TX_TIMEOUT (6*HZ) /* hardware minimum and maximum for a single frame's data payload */ #define CP_MIN_MTU 60 /* TODO: allow lower, but pad */ #define CP_MAX_MTU 4096 enum { /* NIC register offsets */ MAC0 = 0x00, /* Ethernet hardware address. */ MAR0 = 0x08, /* Multicast filter. */ StatsAddr = 0x10, /* 64-bit start addr of 64-byte DMA stats blk */ TxRingAddr = 0x20, /* 64-bit start addr of Tx ring */ HiTxRingAddr = 0x28, /* 64-bit start addr of high priority Tx ring */ Cmd = 0x37, /* Command register */ IntrMask = 0x3C, /* Interrupt mask */ IntrStatus = 0x3E, /* Interrupt status */ TxConfig = 0x40, /* Tx configuration */ ChipVersion = 0x43, /* 8-bit chip version, inside TxConfig */ RxConfig = 0x44, /* Rx configuration */ Cfg9346 = 0x50, /* EEPROM select/control; Cfg reg [un]lock */ Config1 = 0x52, /* Config1 */ Config3 = 0x59, /* Config3 */ Config4 = 0x5A, /* Config4 */ MultiIntr = 0x5C, /* Multiple interrupt select */ BasicModeCtrl = 0x62, /* MII BMCR */ BasicModeStatus = 0x64, /* MII BMSR */ NWayAdvert = 0x66, /* MII ADVERTISE */ NWayLPAR = 0x68, /* MII LPA */ NWayExpansion = 0x6A, /* MII Expansion */ Config5 = 0xD8, /* Config5 */ TxPoll = 0xD9, /* Tell chip to check Tx descriptors for work */ RxMaxSize = 0xDA, /* Max size of an Rx packet (8169 only) */ CpCmd = 0xE0, /* C+ Command register (C+ mode only) */ IntrMitigate = 0xE2, /* rx/tx interrupt mitigation control */ RxRingAddr = 0xE4, /* 64-bit start addr of Rx ring */ TxThresh = 0xEC, /* Early Tx threshold */ OldRxBufAddr = 0x30, /* DMA address of Rx ring buffer (C mode) */ OldTSD0 = 0x10, /* DMA address of first Tx desc (C mode) */ /* Tx and Rx status descriptors */ DescOwn = (1 << 31), /* Descriptor is owned by NIC */ RingEnd = (1 << 30), /* End of descriptor ring */ FirstFrag = (1 << 29), /* First segment of a packet */ LastFrag = (1 << 28), /* Final segment of a packet */ TxError = (1 << 23), /* Tx error summary */ RxError = (1 << 20), /* Rx error summary */ IPCS = (1 << 18), /* Calculate IP checksum */ UDPCS = (1 << 17), /* Calculate UDP/IP checksum */ TCPCS = (1 << 16), /* Calculate TCP/IP checksum */ TxVlanTag = (1 << 17), /* Add VLAN tag */ RxVlanTagged = (1 << 16), /* Rx VLAN tag available */ IPFail = (1 << 15), /* IP checksum failed */ UDPFail = (1 << 14), /* UDP/IP checksum failed */ TCPFail = (1 << 13), /* TCP/IP checksum failed */ NormalTxPoll = (1 << 6), /* One or more normal Tx packets to send */ PID1 = (1 << 17), /* 2 protocol id bits: 0==non-IP, */ PID0 = (1 << 16), /* 1==UDP/IP, 2==TCP/IP, 3==IP */ RxProtoTCP = 1, RxProtoUDP = 2, RxProtoIP = 3, TxFIFOUnder = (1 << 25), /* Tx FIFO underrun */ TxOWC = (1 << 22), /* Tx Out-of-window collision */ TxLinkFail = (1 << 21), /* Link failed during Tx of packet */ TxMaxCol = (1 << 20), /* Tx aborted due to excessive collisions */ TxColCntShift = 16, /* Shift, to get 4-bit Tx collision cnt */ TxColCntMask = 0x01 | 0x02 | 0x04 | 0x08, /* 4-bit collision count */ RxErrFrame = (1 << 27), /* Rx frame alignment error */ RxMcast = (1 << 26), /* Rx multicast packet rcv'd */ RxErrCRC = (1 << 18), /* Rx CRC error */ RxErrRunt = (1 << 19), /* Rx error, packet < 64 bytes */ RxErrLong = (1 << 21), /* Rx error, packet > 4096 bytes */ RxErrFIFO = (1 << 22), /* Rx error, FIFO overflowed, pkt bad */ /* StatsAddr register */ DumpStats = (1 << 3), /* Begin stats dump */ /* RxConfig register */ RxCfgFIFOShift = 13, /* Shift, to get Rx FIFO thresh value */ RxCfgDMAShift = 8, /* Shift, to get Rx Max DMA value */ AcceptErr = 0x20, /* Accept packets with CRC errors */ AcceptRunt = 0x10, /* Accept runt (<64 bytes) packets */ AcceptBroadcast = 0x08, /* Accept broadcast packets */ AcceptMulticast = 0x04, /* Accept multicast packets */ AcceptMyPhys = 0x02, /* Accept pkts with our MAC as dest */ AcceptAllPhys = 0x01, /* Accept all pkts w/ physical dest */ /* IntrMask / IntrStatus registers */ PciErr = (1 << 15), /* System error on the PCI bus */ TimerIntr = (1 << 14), /* Asserted when TCTR reaches TimerInt value */ LenChg = (1 << 13), /* Cable length change */ SWInt = (1 << 8), /* Software-requested interrupt */ TxEmpty = (1 << 7), /* No Tx descriptors available */ RxFIFOOvr = (1 << 6), /* Rx FIFO Overflow */ LinkChg = (1 << 5), /* Packet underrun, or link change */ RxEmpty = (1 << 4), /* No Rx descriptors available */ TxErr = (1 << 3), /* Tx error */ TxOK = (1 << 2), /* Tx packet sent */ RxErr = (1 << 1), /* Rx error */ RxOK = (1 << 0), /* Rx packet received */ IntrResvd = (1 << 10), /* reserved, according to RealTek engineers, but hardware likes to raise it */ IntrAll = PciErr | TimerIntr | LenChg | SWInt | TxEmpty | RxFIFOOvr | LinkChg | RxEmpty | TxErr | TxOK | RxErr | RxOK | IntrResvd, /* C mode command register */ CmdReset = (1 << 4), /* Enable to reset; self-clearing */ RxOn = (1 << 3), /* Rx mode enable */ TxOn = (1 << 2), /* Tx mode enable */ /* C+ mode command register */ RxVlanOn = (1 << 6), /* Rx VLAN de-tagging enable */ RxChkSum = (1 << 5), /* Rx checksum offload enable */ PCIDAC = (1 << 4), /* PCI Dual Address Cycle (64-bit PCI) */ PCIMulRW = (1 << 3), /* Enable PCI read/write multiple */ CpRxOn = (1 << 1), /* Rx mode enable */ CpTxOn = (1 << 0), /* Tx mode enable */ /* Cfg9436 EEPROM control register */ Cfg9346_Lock = 0x00, /* Lock ConfigX/MII register access */ Cfg9346_Unlock = 0xC0, /* Unlock ConfigX/MII register access */ /* TxConfig register */ IFG = (1 << 25) | (1 << 24), /* standard IEEE interframe gap */ TxDMAShift = 8, /* DMA burst value (0-7) is shift this many bits */ /* Early Tx Threshold register */ TxThreshMask = 0x3f, /* Mask bits 5-0 */ TxThreshMax = 2048, /* Max early Tx threshold */ /* Config1 register */ DriverLoaded = (1 << 5), /* Software marker, driver is loaded */ LWACT = (1 << 4), /* LWAKE active mode */ PMEnable = (1 << 0), /* Enable various PM features of chip */ /* Config3 register */ PARMEnable = (1 << 6), /* Enable auto-loading of PHY parms */ MagicPacket = (1 << 5), /* Wake up when receives a Magic Packet */ LinkUp = (1 << 4), /* Wake up when the cable connection is re-established */ /* Config4 register */ LWPTN = (1 << 1), /* LWAKE Pattern */ LWPME = (1 << 4), /* LANWAKE vs PMEB */ /* Config5 register */ BWF = (1 << 6), /* Accept Broadcast wakeup frame */ MWF = (1 << 5), /* Accept Multicast wakeup frame */ UWF = (1 << 4), /* Accept Unicast wakeup frame */ LANWake = (1 << 1), /* Enable LANWake signal */ PMEStatus = (1 << 0), /* PME status can be reset by PCI RST# */ cp_norx_intr_mask = PciErr | LinkChg | TxOK | TxErr | TxEmpty, cp_rx_intr_mask = RxOK | RxErr | RxEmpty | RxFIFOOvr, cp_intr_mask = cp_rx_intr_mask | cp_norx_intr_mask, }; static const unsigned int cp_rx_config = (RX_FIFO_THRESH << RxCfgFIFOShift) | (RX_DMA_BURST << RxCfgDMAShift); struct cp_desc { u32 opts1; u32 opts2; u64 addr; }; struct ring_info { struct sk_buff *skb; dma_addr_t mapping; unsigned frag; }; struct cp_dma_stats { u64 tx_ok; u64 rx_ok; u64 tx_err; u32 rx_err; u16 rx_fifo; u16 frame_align; u32 tx_ok_1col; u32 tx_ok_mcol; u64 rx_ok_phys; u64 rx_ok_bcast; u32 rx_ok_mcast; u16 tx_abort; u16 tx_underrun; } __attribute__((packed)); struct cp_extra_stats { unsigned long rx_frags; }; struct cp_private { unsigned tx_head; unsigned tx_tail; unsigned rx_tail; void *regs; struct net_device *dev; spinlock_t lock; struct cp_desc *rx_ring; struct cp_desc *tx_ring; struct ring_info tx_skb[CP_TX_RING_SIZE]; struct ring_info rx_skb[CP_RX_RING_SIZE]; unsigned rx_buf_sz; dma_addr_t ring_dma; #if CP_VLAN_TAG_USED struct vlan_group *vlgrp; #endif u32 msg_enable; struct net_device_stats net_stats; struct cp_extra_stats cp_stats; struct cp_dma_stats *nic_stats; dma_addr_t nic_stats_dma; struct pci_dev *pdev; u32 rx_config; struct sk_buff *frag_skb; unsigned dropping_frag : 1; unsigned pci_using_dac : 1; unsigned int board_type; unsigned int wol_enabled : 1; /* Is Wake-on-LAN enabled? */ u32 power_state[16]; struct mii_if_info mii_if; }; #define cpr8(reg) readb(cp->regs + (reg)) #define cpr16(reg) readw(cp->regs + (reg)) #define cpr32(reg) readl(cp->regs + (reg)) #define cpw8(reg,val) writeb((val), cp->regs + (reg)) #define cpw16(reg,val) writew((val), cp->regs + (reg)) #define cpw32(reg,val) writel((val), cp->regs + (reg)) #define cpw8_f(reg,val) do { \ writeb((val), cp->regs + (reg)); \ readb(cp->regs + (reg)); \ } while (0) #define cpw16_f(reg,val) do { \ writew((val), cp->regs + (reg)); \ readw(cp->regs + (reg)); \ } while (0) #define cpw32_f(reg,val) do { \ writel((val), cp->regs + (reg)); \ readl(cp->regs + (reg)); \ } while (0) static void __cp_set_rx_mode (struct net_device *dev); static void cp_tx (struct cp_private *cp); static void cp_clean_rings (struct cp_private *cp); enum board_type { RTL8139Cp, }; static struct cp_board_info { const char *name; } cp_board_tbl[] __devinitdata = { /* RTL8139Cp */ { "RTL-8139C+" }, }; static struct pci_device_id cp_pci_tbl[] = { { PCI_VENDOR_ID_REALTEK, PCI_DEVICE_ID_REALTEK_8139, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139Cp }, { }, }; MODULE_DEVICE_TABLE(pci, cp_pci_tbl); static struct { const char str[ETH_GSTRING_LEN]; } ethtool_stats_keys[] = { { "tx_ok" }, { "rx_ok" }, { "tx_err" }, { "rx_err" }, { "rx_fifo" }, { "frame_align" }, { "tx_ok_1col" }, { "tx_ok_mcol" }, { "rx_ok_phys" }, { "rx_ok_bcast" }, { "rx_ok_mcast" }, { "tx_abort" }, { "tx_underrun" }, { "rx_frags" }, }; static inline void cp_set_rxbufsize (struct cp_private *cp) { unsigned int mtu = cp->dev->mtu; if (mtu > ETH_DATA_LEN) /* MTU + ethernet header + FCS + optional VLAN tag */ cp->rx_buf_sz = mtu + ETH_HLEN + 8; else cp->rx_buf_sz = PKT_BUF_SZ; } static inline void cp_rx_skb (struct cp_private *cp, struct sk_buff *skb, struct cp_desc *desc) { skb->protocol = eth_type_trans (skb, cp->dev); cp->net_stats.rx_packets++; cp->net_stats.rx_bytes += skb->len; cp->dev->last_rx = jiffies; #if CP_VLAN_TAG_USED if (cp->vlgrp && (desc->opts2 & RxVlanTagged)) { vlan_hwaccel_rx(skb, cp->vlgrp, be16_to_cpu(desc->opts2 & 0xffff)); } else #endif netif_receive_skb(skb); } static void cp_rx_err_acct (struct cp_private *cp, unsigned rx_tail, u32 status, u32 len) { if (netif_msg_rx_err (cp)) printk (KERN_DEBUG "%s: rx err, slot %d status 0x%x len %d\n", cp->dev->name, rx_tail, status, len); cp->net_stats.rx_errors++; if (status & RxErrFrame) cp->net_stats.rx_frame_errors++; if (status & RxErrCRC) cp->net_stats.rx_crc_errors++; if ((status & RxErrRunt) || (status & RxErrLong)) cp->net_stats.rx_length_errors++; if ((status & (FirstFrag | LastFrag)) != (FirstFrag | LastFrag)) cp->net_stats.rx_length_errors++; if (status & RxErrFIFO) cp->net_stats.rx_fifo_errors++; } static inline unsigned int cp_rx_csum_ok (u32 status) { unsigned int protocol = (status >> 16) & 0x3; if (likely((protocol == RxProtoTCP) && (!(status & TCPFail)))) return 1; else if ((protocol == RxProtoUDP) && (!(status & UDPFail))) return 1; else if ((protocol == RxProtoIP) && (!(status & IPFail))) return 1; return 0; } static int cp_rx_poll (struct net_device *dev, int *budget) { struct cp_private *cp = dev->priv; unsigned rx_tail = cp->rx_tail; unsigned rx_work = dev->quota; unsigned rx = 0; rx_status_loop: cpw16(IntrStatus, cp_rx_intr_mask); while (1) { u32 status, len; dma_addr_t mapping; struct sk_buff *skb, *new_skb; struct cp_desc *desc; unsigned buflen; skb = cp->rx_skb[rx_tail].skb; if (!skb) BUG(); desc = &cp->rx_ring[rx_tail]; status = le32_to_cpu(desc->opts1); if (status & DescOwn) break; len = (status & 0x1fff) - 4; mapping = cp->rx_skb[rx_tail].mapping; if ((status & (FirstFrag | LastFrag)) != (FirstFrag | LastFrag)) { /* we don't support incoming fragmented frames. * instead, we attempt to ensure that the * pre-allocated RX skbs are properly sized such * that RX fragments are never encountered */ cp_rx_err_acct(cp, rx_tail, status, len); cp->net_stats.rx_dropped++; goto rx_next; } if (status & (RxError | RxErrFIFO)) { cp_rx_err_acct(cp, rx_tail, status, len); goto rx_next; } if (netif_msg_rx_status(cp)) printk(KERN_DEBUG "%s: rx slot %d status 0x%x len %d\n", cp->dev->name, rx_tail, status, len); buflen = cp->rx_buf_sz + RX_OFFSET; new_skb = dev_alloc_skb (buflen); if (!new_skb) { cp->net_stats.rx_dropped++; goto rx_next; } skb_reserve(new_skb, RX_OFFSET); new_skb->dev = cp->dev; pci_unmap_single(cp->pdev, mapping, buflen, PCI_DMA_FROMDEVICE); /* Handle checksum offloading for incoming packets. */ if (cp_rx_csum_ok(status)) skb->ip_summed = CHECKSUM_UNNECESSARY; else skb->ip_summed = CHECKSUM_NONE; skb_put(skb, len); mapping = cp->rx_skb[rx_tail].mapping = pci_map_single(cp->pdev, new_skb->tail, buflen, PCI_DMA_FROMDEVICE); cp->rx_skb[rx_tail].skb = new_skb; cp_rx_skb(cp, skb, desc); rx++; rx_next: cp->rx_ring[rx_tail].opts2 = 0; cp->rx_ring[rx_tail].addr = cpu_to_le64(mapping); if (rx_tail == (CP_RX_RING_SIZE - 1)) desc->opts1 = cpu_to_le32(DescOwn | RingEnd | cp->rx_buf_sz); else desc->opts1 = cpu_to_le32(DescOwn | cp->rx_buf_sz); rx_tail = NEXT_RX(rx_tail); if (!rx_work--) break; } cp->rx_tail = rx_tail; dev->quota -= rx; *budget -= rx; /* if we did not reach work limit, then we're done with * this round of polling */ if (rx_work) { if (cpr16(IntrStatus) & cp_rx_intr_mask) goto rx_status_loop; cpw16_f(IntrMask, cp_intr_mask); netif_rx_complete(dev); return 0; /* done */ } return 1; /* not done */ } static irqreturn_t cp_interrupt (int irq, void *dev_instance, struct pt_regs *regs) { struct net_device *dev = dev_instance; struct cp_private *cp = dev->priv; u16 status; status = cpr16(IntrStatus); if (!status || (status == 0xFFFF)) return IRQ_NONE; if (netif_msg_intr(cp)) printk(KERN_DEBUG "%s: intr, status %04x cmd %02x cpcmd %04x\n", dev->name, status, cpr8(Cmd), cpr16(CpCmd)); cpw16(IntrStatus, status & ~cp_rx_intr_mask); spin_lock(&cp->lock); if (status & (RxOK | RxErr | RxEmpty | RxFIFOOvr)) { if (netif_rx_schedule_prep(dev)) { cpw16_f(IntrMask, cp_norx_intr_mask); __netif_rx_schedule(dev); } } if (status & (TxOK | TxErr | TxEmpty | SWInt)) cp_tx(cp); if (status & LinkChg) mii_check_media(&cp->mii_if, netif_msg_link(cp), FALSE); if (status & PciErr) { u16 pci_status; pci_read_config_word(cp->pdev, PCI_STATUS, &pci_status); pci_write_config_word(cp->pdev, PCI_STATUS, pci_status); printk(KERN_ERR "%s: PCI bus error, status=%04x, PCI status=%04x\n", dev->name, status, pci_status); /* TODO: reset hardware */ } spin_unlock(&cp->lock); return IRQ_HANDLED; } static void cp_tx (struct cp_private *cp) { unsigned tx_head = cp->tx_head; unsigned tx_tail = cp->tx_tail; while (tx_tail != tx_head) { struct sk_buff *skb; u32 status; rmb(); status = le32_to_cpu(cp->tx_ring[tx_tail].opts1); if (status & DescOwn) break; skb = cp->tx_skb[tx_tail].skb; if (!skb) BUG(); pci_unmap_single(cp->pdev, cp->tx_skb[tx_tail].mapping, skb->len, PCI_DMA_TODEVICE); if (status & LastFrag) { if (status & (TxError | TxFIFOUnder)) { if (netif_msg_tx_err(cp)) printk(KERN_DEBUG "%s: tx err, status 0x%x\n", cp->dev->name, status); cp->net_stats.tx_errors++; if (status & TxOWC) cp->net_stats.tx_window_errors++; if (status & TxMaxCol) cp->net_stats.tx_aborted_errors++; if (status & TxLinkFail) cp->net_stats.tx_carrier_errors++; if (status & TxFIFOUnder) cp->net_stats.tx_fifo_errors++; } else { cp->net_stats.collisions += ((status >> TxColCntShift) & TxColCntMask); cp->net_stats.tx_packets++; cp->net_stats.tx_bytes += skb->len; if (netif_msg_tx_done(cp)) printk(KERN_DEBUG "%s: tx done, slot %d\n", cp->dev->name, tx_tail); } dev_kfree_skb_irq(skb); } cp->tx_skb[tx_tail].skb = NULL; tx_tail = NEXT_TX(tx_tail); } cp->tx_tail = tx_tail; if (netif_queue_stopped(cp->dev) && (TX_BUFFS_AVAIL(cp) > (MAX_SKB_FRAGS + 1))) netif_wake_queue(cp->dev); } static int cp_start_xmit (struct sk_buff *skb, struct net_device *dev) { struct cp_private *cp = dev->priv; unsigned entry; u32 eor; #if CP_VLAN_TAG_USED u32 vlan_tag = 0; #endif spin_lock_irq(&cp->lock); /* This is a hard error, log it. */ if (TX_BUFFS_AVAIL(cp) <= (skb_shinfo(skb)->nr_frags + 1)) { netif_stop_queue(dev); spin_unlock_irq(&cp->lock); printk(KERN_ERR PFX "%s: BUG! Tx Ring full when queue awake!\n", dev->name); return 1; } #if CP_VLAN_TAG_USED if (cp->vlgrp && vlan_tx_tag_present(skb)) vlan_tag = TxVlanTag | cpu_to_be16(vlan_tx_tag_get(skb)); #endif entry = cp->tx_head; eor = (entry == (CP_TX_RING_SIZE - 1)) ? RingEnd : 0; if (skb_shinfo(skb)->nr_frags == 0) { struct cp_desc *txd = &cp->tx_ring[entry]; u32 len; dma_addr_t mapping; len = skb->len; mapping = pci_map_single(cp->pdev, skb->data, len, PCI_DMA_TODEVICE); CP_VLAN_TX_TAG(txd, vlan_tag); txd->addr = cpu_to_le64(mapping); wmb(); if (skb->ip_summed == CHECKSUM_HW) { const struct iphdr *ip = skb->nh.iph; if (ip->protocol == IPPROTO_TCP) txd->opts1 = cpu_to_le32(eor | len | DescOwn | FirstFrag | LastFrag | IPCS | TCPCS); else if (ip->protocol == IPPROTO_UDP) txd->opts1 = cpu_to_le32(eor | len | DescOwn | FirstFrag | LastFrag | IPCS | UDPCS); else BUG(); } else txd->opts1 = cpu_to_le32(eor | len | DescOwn | FirstFrag | LastFrag); wmb(); cp->tx_skb[entry].skb = skb; cp->tx_skb[entry].mapping = mapping; cp->tx_skb[entry].frag = 0; entry = NEXT_TX(entry); } else { struct cp_desc *txd; u32 first_len, first_eor; dma_addr_t first_mapping; int frag, first_entry = entry; const struct iphdr *ip = skb->nh.iph; /* We must give this initial chunk to the device last. * Otherwise we could race with the device. */ first_eor = eor; first_len = skb_headlen(skb); first_mapping = pci_map_single(cp->pdev, skb->data, first_len, PCI_DMA_TODEVICE); cp->tx_skb[entry].skb = skb; cp->tx_skb[entry].mapping = first_mapping; cp->tx_skb[entry].frag = 1; entry = NEXT_TX(entry); for (frag = 0; frag < skb_shinfo(skb)->nr_frags; frag++) { skb_frag_t *this_frag = &skb_shinfo(skb)->frags[frag]; u32 len; u32 ctrl; dma_addr_t mapping; len = this_frag->size; mapping = pci_map_single(cp->pdev, ((void *) page_address(this_frag->page) + this_frag->page_offset), len, PCI_DMA_TODEVICE); eor = (entry == (CP_TX_RING_SIZE - 1)) ? RingEnd : 0; if (skb->ip_summed == CHECKSUM_HW) { ctrl = eor | len | DescOwn | IPCS; if (ip->protocol == IPPROTO_TCP) ctrl |= TCPCS; else if (ip->protocol == IPPROTO_UDP) ctrl |= UDPCS; else BUG(); } else ctrl = eor | len | DescOwn; if (frag == skb_shinfo(skb)->nr_frags - 1) ctrl |= LastFrag; txd = &cp->tx_ring[entry]; CP_VLAN_TX_TAG(txd, vlan_tag); txd->addr = cpu_to_le64(mapping); wmb(); txd->opts1 = cpu_to_le32(ctrl); wmb(); cp->tx_skb[entry].skb = skb; cp->tx_skb[entry].mapping = mapping; cp->tx_skb[entry].frag = frag + 2; entry = NEXT_TX(entry); } txd = &cp->tx_ring[first_entry]; CP_VLAN_TX_TAG(txd, vlan_tag); txd->addr = cpu_to_le64(first_mapping); wmb(); if (skb->ip_summed == CHECKSUM_HW) { if (ip->protocol == IPPROTO_TCP) txd->opts1 = cpu_to_le32(first_eor | first_len | FirstFrag | DescOwn | IPCS | TCPCS); else if (ip->protocol == IPPROTO_UDP) txd->opts1 = cpu_to_le32(first_eor | first_len | FirstFrag | DescOwn | IPCS | UDPCS); else BUG(); } else txd->opts1 = cpu_to_le32(first_eor | first_len | FirstFrag | DescOwn); wmb(); } cp->tx_head = entry; if (netif_msg_tx_queued(cp)) printk(KERN_DEBUG "%s: tx queued, slot %d, skblen %d\n", dev->name, entry, skb->len); if (TX_BUFFS_AVAIL(cp) <= (MAX_SKB_FRAGS + 1)) netif_stop_queue(dev); spin_unlock_irq(&cp->lock); cpw8(TxPoll, NormalTxPoll); dev->trans_start = jiffies; return 0; } /* Set or clear the multicast filter for this adaptor. This routine is not state sensitive and need not be SMP locked. */ static void __cp_set_rx_mode (struct net_device *dev) { struct cp_private *cp = dev->priv; u32 mc_filter[2]; /* Multicast hash filter */ int i, rx_mode; u32 tmp; /* Note: do not reorder, GCC is clever about common statements. */ if (dev->flags & IFF_PROMISC) { /* Unconditionally log net taps. */ printk (KERN_NOTICE "%s: Promiscuous mode enabled.\n", dev->name); rx_mode = AcceptBroadcast | AcceptMulticast | AcceptMyPhys | AcceptAllPhys; mc_filter[1] = mc_filter[0] = 0xffffffff; } else if ((dev->mc_count > multicast_filter_limit) || (dev->flags & IFF_ALLMULTI)) { /* Too many to filter perfectly -- accept all multicasts. */ rx_mode = AcceptBroadcast | AcceptMulticast | AcceptMyPhys; mc_filter[1] = mc_filter[0] = 0xffffffff; } else { struct dev_mc_list *mclist; rx_mode = AcceptBroadcast | AcceptMyPhys; mc_filter[1] = mc_filter[0] = 0; for (i = 0, mclist = dev->mc_list; mclist && i < dev->mc_count; i++, mclist = mclist->next) { int bit_nr = ether_crc(ETH_ALEN, mclist->dmi_addr) >> 26; mc_filter[bit_nr >> 5] |= 1 << (bit_nr & 31); rx_mode |= AcceptMulticast; } } /* We can safely update without stopping the chip. */ tmp = cp_rx_config | rx_mode; if (cp->rx_config != tmp) { cpw32_f (RxConfig, tmp); cp->rx_config = tmp; } cpw32_f (MAR0 + 0, mc_filter[0]); cpw32_f (MAR0 + 4, mc_filter[1]); } static void cp_set_rx_mode (struct net_device *dev) { unsigned long flags; struct cp_private *cp = dev->priv; spin_lock_irqsave (&cp->lock, flags); __cp_set_rx_mode(dev); spin_unlock_irqrestore (&cp->lock, flags); } static void __cp_get_stats(struct cp_private *cp) { /* XXX implement */ } static struct net_device_stats *cp_get_stats(struct net_device *dev) { struct cp_private *cp = dev->priv; /* The chip only need report frame silently dropped. */ spin_lock_irq(&cp->lock); if (netif_running(dev) && netif_device_present(dev)) __cp_get_stats(cp); spin_unlock_irq(&cp->lock); return &cp->net_stats; } static void cp_stop_hw (struct cp_private *cp) { struct net_device *dev = cp->dev; cpw16(IntrStatus, ~(cpr16(IntrStatus))); cpw16_f(IntrMask, 0); cpw8(Cmd, 0); cpw16_f(CpCmd, 0); cpw16(IntrStatus, ~(cpr16(IntrStatus))); synchronize_irq(); udelay(10); cp->rx_tail = 0; cp->tx_head = cp->tx_tail = 0; (void) dev; /* avoid compiler warning when synchronize_irq() * disappears during !CONFIG_SMP */ } static void cp_reset_hw (struct cp_private *cp) { unsigned work = 1000; cpw8(Cmd, CmdReset); while (work--) { if (!(cpr8(Cmd) & CmdReset)) return; set_current_state(TASK_UNINTERRUPTIBLE); schedule_timeout(10); } printk(KERN_ERR "%s: hardware reset timeout\n", cp->dev->name); } static inline void cp_start_hw (struct cp_private *cp) { u16 pci_dac = cp->pci_using_dac ? PCIDAC : 0; cpw16(CpCmd, pci_dac | PCIMulRW | RxChkSum | CpRxOn | CpTxOn); cpw8(Cmd, RxOn | TxOn); } static void cp_init_hw (struct cp_private *cp) { struct net_device *dev = cp->dev; cp_reset_hw(cp); cpw8_f (Cfg9346, Cfg9346_Unlock); /* Restore our idea of the MAC address. */ cpw32_f (MAC0 + 0, cpu_to_le32 (*(u32 *) (dev->dev_addr + 0))); cpw32_f (MAC0 + 4, cpu_to_le32 (*(u32 *) (dev->dev_addr + 4))); cp_start_hw(cp); cpw8(TxThresh, 0x06); /* XXX convert magic num to a constant */ __cp_set_rx_mode(dev); cpw32_f (TxConfig, IFG | (TX_DMA_BURST << TxDMAShift)); cpw8(Config1, cpr8(Config1) | DriverLoaded | PMEnable); /* Disable Wake-on-LAN. Can be turned on with ETHTOOL_SWOL */ if (cp->board_type == RTL8139Cp) { cpw8(Config3, PARMEnable); cp->wol_enabled = 0; } cpw8(Config5, cpr8(Config5) & PMEStatus); cpw32_f(HiTxRingAddr, 0); cpw32_f(HiTxRingAddr + 4, 0); cpw32_f(RxRingAddr, cp->ring_dma); cpw32_f(RxRingAddr + 4, 0); /* FIXME: 64-bit PCI */ cpw32_f(TxRingAddr, cp->ring_dma + (sizeof(struct cp_desc) * CP_RX_RING_SIZE)); cpw32_f(TxRingAddr + 4, 0); /* FIXME: 64-bit PCI */ cpw16(MultiIntr, 0); cpw16_f(IntrMask, cp_intr_mask); cpw8_f(Cfg9346, Cfg9346_Lock); } static int cp_refill_rx (struct cp_private *cp) { unsigned i; for (i = 0; i < CP_RX_RING_SIZE; i++) { struct sk_buff *skb; skb = dev_alloc_skb(cp->rx_buf_sz + RX_OFFSET); if (!skb) goto err_out; skb->dev = cp->dev; skb_reserve(skb, RX_OFFSET); cp->rx_skb[i].mapping = pci_map_single(cp->pdev, skb->tail, cp->rx_buf_sz, PCI_DMA_FROMDEVICE); cp->rx_skb[i].skb = skb; cp->rx_skb[i].frag = 0; cp->rx_ring[i].opts2 = 0; cp->rx_ring[i].addr = cpu_to_le64(cp->rx_skb[i].mapping); if (i == (CP_RX_RING_SIZE - 1)) cp->rx_ring[i].opts1 = cpu_to_le32(DescOwn | RingEnd | cp->rx_buf_sz); else cp->rx_ring[i].opts1 = cpu_to_le32(DescOwn | cp->rx_buf_sz); } return 0; err_out: cp_clean_rings(cp); return -ENOMEM; } static int cp_init_rings (struct cp_private *cp) { memset(cp->tx_ring, 0, sizeof(struct cp_desc) * CP_TX_RING_SIZE); cp->tx_ring[CP_TX_RING_SIZE - 1].opts1 = cpu_to_le32(RingEnd); cp->rx_tail = 0; cp->tx_head = cp->tx_tail = 0; return cp_refill_rx (cp); } static int cp_alloc_rings (struct cp_private *cp) { void *mem; mem = pci_alloc_consistent(cp->pdev, CP_RING_BYTES, &cp->ring_dma); if (!mem) return -ENOMEM; cp->rx_ring = mem; cp->tx_ring = &cp->rx_ring[CP_RX_RING_SIZE]; mem += (CP_RING_BYTES - CP_STATS_SIZE); cp->nic_stats = mem; cp->nic_stats_dma = cp->ring_dma + (CP_RING_BYTES - CP_STATS_SIZE); return cp_init_rings(cp); } static void cp_clean_rings (struct cp_private *cp) { unsigned i; memset(cp->rx_ring, 0, sizeof(struct cp_desc) * CP_RX_RING_SIZE); memset(cp->tx_ring, 0, sizeof(struct cp_desc) * CP_TX_RING_SIZE); for (i = 0; i < CP_RX_RING_SIZE; i++) { if (cp->rx_skb[i].skb) { pci_unmap_single(cp->pdev, cp->rx_skb[i].mapping, cp->rx_buf_sz, PCI_DMA_FROMDEVICE); dev_kfree_skb(cp->rx_skb[i].skb); } } for (i = 0; i < CP_TX_RING_SIZE; i++) { if (cp->tx_skb[i].skb) { struct sk_buff *skb = cp->tx_skb[i].skb; pci_unmap_single(cp->pdev, cp->tx_skb[i].mapping, skb->len, PCI_DMA_TODEVICE); dev_kfree_skb(skb); cp->net_stats.tx_dropped++; } } memset(&cp->rx_skb, 0, sizeof(struct ring_info) * CP_RX_RING_SIZE); memset(&cp->tx_skb, 0, sizeof(struct ring_info) * CP_TX_RING_SIZE); } static void cp_free_rings (struct cp_private *cp) { cp_clean_rings(cp); pci_free_consistent(cp->pdev, CP_RING_BYTES, cp->rx_ring, cp->ring_dma); cp->rx_ring = NULL; cp->tx_ring = NULL; cp->nic_stats = NULL; } static int cp_open (struct net_device *dev) { struct cp_private *cp = dev->priv; int rc; if (netif_msg_ifup(cp)) printk(KERN_DEBUG "%s: enabling interface\n", dev->name); rc = cp_alloc_rings(cp); if (rc) return rc; cp_init_hw(cp); rc = request_irq(dev->irq, cp_interrupt, SA_SHIRQ, dev->name, dev); if (rc) goto err_out_hw; netif_carrier_off(dev); mii_check_media(&cp->mii_if, netif_msg_link(cp), TRUE); netif_start_queue(dev); return 0; err_out_hw: cp_stop_hw(cp); cp_free_rings(cp); return rc; } static int cp_close (struct net_device *dev) { struct cp_private *cp = dev->priv; if (netif_msg_ifdown(cp)) printk(KERN_DEBUG "%s: disabling interface\n", dev->name); netif_stop_queue(dev); netif_carrier_off(dev); spin_lock_irq(&cp->lock); cp_stop_hw(cp); spin_unlock_irq(&cp->lock); free_irq(dev->irq, dev); cp_free_rings(cp); return 0; } #ifdef BROKEN static int cp_change_mtu(struct net_device *dev, int new_mtu) { struct cp_private *cp = dev->priv; int rc; /* check for invalid MTU, according to hardware limits */ if (new_mtu < CP_MIN_MTU || new_mtu > CP_MAX_MTU) return -EINVAL; /* if network interface not up, no need for complexity */ if (!netif_running(dev)) { dev->mtu = new_mtu; cp_set_rxbufsize(cp); /* set new rx buf size */ return 0; } spin_lock_irq(&cp->lock); cp_stop_hw(cp); /* stop h/w and free rings */ cp_clean_rings(cp); dev->mtu = new_mtu; cp_set_rxbufsize(cp); /* set new rx buf size */ rc = cp_init_rings(cp); /* realloc and restart h/w */ cp_start_hw(cp); spin_unlock_irq(&cp->lock); return rc; } #endif /* BROKEN */ static char mii_2_8139_map[8] = { BasicModeCtrl, BasicModeStatus, 0, 0, NWayAdvert, NWayLPAR, NWayExpansion, 0 }; static int mdio_read(struct net_device *dev, int phy_id, int location) { struct cp_private *cp = dev->priv; return location < 8 && mii_2_8139_map[location] ? readw(cp->regs + mii_2_8139_map[location]) : 0; } static void mdio_write(struct net_device *dev, int phy_id, int location, int value) { struct cp_private *cp = dev->priv; if (location == 0) { cpw8(Cfg9346, Cfg9346_Unlock); cpw16(BasicModeCtrl, value); cpw8(Cfg9346, Cfg9346_Lock); } else if (location < 8 && mii_2_8139_map[location]) cpw16(mii_2_8139_map[location], value); } /* Set the ethtool Wake-on-LAN settings */ static int netdev_set_wol (struct cp_private *cp, const struct ethtool_wolinfo *wol) { u8 options; options = cpr8 (Config3) & ~(LinkUp | MagicPacket); /* If WOL is being disabled, no need for complexity */ if (wol->wolopts) { if (wol->wolopts & WAKE_PHY) options |= LinkUp; if (wol->wolopts & WAKE_MAGIC) options |= MagicPacket; } cpw8 (Cfg9346, Cfg9346_Unlock); cpw8 (Config3, options); cpw8 (Cfg9346, Cfg9346_Lock); options = 0; /* Paranoia setting */ options = cpr8 (Config5) & ~(UWF | MWF | BWF); /* If WOL is being disabled, no need for complexity */ if (wol->wolopts) { if (wol->wolopts & WAKE_UCAST) options |= UWF; if (wol->wolopts & WAKE_BCAST) options |= BWF; if (wol->wolopts & WAKE_MCAST) options |= MWF; } cpw8 (Config5, options); cp->wol_enabled = (wol->wolopts) ? 1 : 0; return 0; } /* Get the ethtool Wake-on-LAN settings */ static void netdev_get_wol (struct cp_private *cp, struct ethtool_wolinfo *wol) { u8 options; wol->wolopts = 0; /* Start from scratch */ wol->supported = WAKE_PHY | WAKE_BCAST | WAKE_MAGIC | WAKE_MCAST | WAKE_UCAST; /* We don't need to go on if WOL is disabled */ if (!cp->wol_enabled) return; options = cpr8 (Config3); if (options & LinkUp) wol->wolopts |= WAKE_PHY; if (options & MagicPacket) wol->wolopts |= WAKE_MAGIC; options = 0; /* Paranoia setting */ options = cpr8 (Config5); if (options & UWF) wol->wolopts |= WAKE_UCAST; if (options & BWF) wol->wolopts |= WAKE_BCAST; if (options & MWF) wol->wolopts |= WAKE_MCAST; } static void cp_get_drvinfo (struct net_device *dev, struct ethtool_drvinfo *info) { struct cp_private *cp = dev->priv; strcpy (info->driver, DRV_NAME); strcpy (info->version, DRV_VERSION); strcpy (info->bus_info, pci_name(cp->pdev)); } static int cp_get_regs_len(struct net_device *dev) { return CP_REGS_SIZE; } static int cp_get_stats_count (struct net_device *dev) { return CP_NUM_STATS; } static int cp_get_settings(struct net_device *dev, struct ethtool_cmd *cmd) { struct cp_private *cp = dev->priv; int rc; spin_lock_irq(&cp->lock); rc = mii_ethtool_gset(&cp->mii_if, cmd); spin_unlock_irq(&cp->lock); return rc; } static int cp_set_settings(struct net_device *dev, struct ethtool_cmd *cmd) { struct cp_private *cp = dev->priv; int rc; spin_lock_irq(&cp->lock); rc = mii_ethtool_sset(&cp->mii_if, cmd); spin_unlock_irq(&cp->lock); return rc; } static int cp_nway_reset(struct net_device *dev) { struct cp_private *cp = dev->priv; return mii_nway_restart(&cp->mii_if); } static u32 cp_get_msglevel(struct net_device *dev) { struct cp_private *cp = dev->priv; return cp->msg_enable; } static void cp_set_msglevel(struct net_device *dev, u32 value) { struct cp_private *cp = dev->priv; cp->msg_enable = value; } static u32 cp_get_rx_csum(struct net_device *dev) { struct cp_private *cp = dev->priv; return (cpr16(CpCmd) & RxChkSum) ? 1 : 0; } static int cp_set_rx_csum(struct net_device *dev, u32 data) { struct cp_private *cp = dev->priv; u16 cmd = cpr16(CpCmd), newcmd; newcmd = cmd; if (data) newcmd |= RxChkSum; else newcmd &= ~RxChkSum; if (newcmd != cmd) { spin_lock_irq(&cp->lock); cpw16_f(CpCmd, newcmd); spin_unlock_irq(&cp->lock); } return 0; } /* move this to net/core/ethtool.c */ static int ethtool_op_set_tx_csum(struct net_device *dev, u32 data) { if (data) dev->features |= NETIF_F_IP_CSUM; else dev->features &= ~NETIF_F_IP_CSUM; return 0; } static void cp_get_regs(struct net_device *dev, struct ethtool_regs *regs, void *p) { struct cp_private *cp = dev->priv; if (regs->len < CP_REGS_SIZE) return /* -EINVAL */; regs->version = CP_REGS_VER; spin_lock_irq(&cp->lock); memcpy_fromio(p, cp->regs, CP_REGS_SIZE); spin_unlock_irq(&cp->lock); } static void cp_get_wol (struct net_device *dev, struct ethtool_wolinfo *wol) { struct cp_private *cp = dev->priv; spin_lock_irq (&cp->lock); netdev_get_wol (cp, wol); spin_unlock_irq (&cp->lock); } static int cp_set_wol (struct net_device *dev, struct ethtool_wolinfo *wol) { struct cp_private *cp = dev->priv; int rc; spin_lock_irq (&cp->lock); rc = netdev_set_wol (cp, wol); spin_unlock_irq (&cp->lock); return rc; } static void cp_get_strings (struct net_device *dev, u32 stringset, u8 *buf) { switch (stringset) { case ETH_SS_STATS: memcpy(buf, ðtool_stats_keys, sizeof(ethtool_stats_keys)); break; default: BUG(); break; } } static void cp_get_ethtool_stats (struct net_device *dev, struct ethtool_stats *estats, u64 *tmp_stats) { struct cp_private *cp = dev->priv; unsigned int work = 100; int i; /* begin NIC statistics dump */ cpw32(StatsAddr + 4, 0); /* FIXME: 64-bit PCI */ cpw32(StatsAddr, cp->nic_stats_dma | DumpStats); cpr32(StatsAddr); while (work-- > 0) { if ((cpr32(StatsAddr) & DumpStats) == 0) break; cpu_relax(); } if (cpr32(StatsAddr) & DumpStats) return /* -EIO */; i = 0; tmp_stats[i++] = le64_to_cpu(cp->nic_stats->tx_ok); tmp_stats[i++] = le64_to_cpu(cp->nic_stats->rx_ok); tmp_stats[i++] = le64_to_cpu(cp->nic_stats->tx_err); tmp_stats[i++] = le32_to_cpu(cp->nic_stats->rx_err); tmp_stats[i++] = le16_to_cpu(cp->nic_stats->rx_fifo); tmp_stats[i++] = le16_to_cpu(cp->nic_stats->frame_align); tmp_stats[i++] = le32_to_cpu(cp->nic_stats->tx_ok_1col); tmp_stats[i++] = le32_to_cpu(cp->nic_stats->tx_ok_mcol); tmp_stats[i++] = le64_to_cpu(cp->nic_stats->rx_ok_phys); tmp_stats[i++] = le64_to_cpu(cp->nic_stats->rx_ok_bcast); tmp_stats[i++] = le32_to_cpu(cp->nic_stats->rx_ok_mcast); tmp_stats[i++] = le16_to_cpu(cp->nic_stats->tx_abort); tmp_stats[i++] = le16_to_cpu(cp->nic_stats->tx_underrun); tmp_stats[i++] = cp->cp_stats.rx_frags; if (i != CP_NUM_STATS) BUG(); } static struct ethtool_ops cp_ethtool_ops = { .get_drvinfo = cp_get_drvinfo, .get_regs_len = cp_get_regs_len, .get_stats_count = cp_get_stats_count, .get_settings = cp_get_settings, .set_settings = cp_set_settings, .nway_reset = cp_nway_reset, .get_link = ethtool_op_get_link, .get_msglevel = cp_get_msglevel, .set_msglevel = cp_set_msglevel, .get_rx_csum = cp_get_rx_csum, .set_rx_csum = cp_set_rx_csum, .get_tx_csum = ethtool_op_get_tx_csum, .set_tx_csum = ethtool_op_set_tx_csum, /* local! */ .get_sg = ethtool_op_get_sg, .set_sg = ethtool_op_set_sg, .get_regs = cp_get_regs, .get_wol = cp_get_wol, .set_wol = cp_set_wol, .get_strings = cp_get_strings, .get_ethtool_stats = cp_get_ethtool_stats, }; static int cp_ioctl (struct net_device *dev, struct ifreq *rq, int cmd) { struct cp_private *cp = dev->priv; struct mii_ioctl_data *mii = (struct mii_ioctl_data *) &rq->ifr_data; int rc; if (!netif_running(dev)) return -EINVAL; spin_lock_irq(&cp->lock); rc = generic_mii_ioctl(&cp->mii_if, mii, cmd, NULL); spin_unlock_irq(&cp->lock); return rc; } #if CP_VLAN_TAG_USED static void cp_vlan_rx_register(struct net_device *dev, struct vlan_group *grp) { struct cp_private *cp = dev->priv; spin_lock_irq(&cp->lock); cp->vlgrp = grp; cpw16(CpCmd, cpr16(CpCmd) | RxVlanOn); spin_unlock_irq(&cp->lock); } static void cp_vlan_rx_kill_vid(struct net_device *dev, unsigned short vid) { struct cp_private *cp = dev->priv; spin_lock_irq(&cp->lock); cpw16(CpCmd, cpr16(CpCmd) & ~RxVlanOn); if (cp->vlgrp) cp->vlgrp->vlan_devices[vid] = NULL; spin_unlock_irq(&cp->lock); } #endif /* Serial EEPROM section. */ /* EEPROM_Ctrl bits. */ #define EE_SHIFT_CLK 0x04 /* EEPROM shift clock. */ #define EE_CS 0x08 /* EEPROM chip select. */ #define EE_DATA_WRITE 0x02 /* EEPROM chip data in. */ #define EE_WRITE_0 0x00 #define EE_WRITE_1 0x02 #define EE_DATA_READ 0x01 /* EEPROM chip data out. */ #define EE_ENB (0x80 | EE_CS) /* Delay between EEPROM clock transitions. No extra delay is needed with 33Mhz PCI, but 66Mhz may change this. */ #define eeprom_delay() readl(ee_addr) /* The EEPROM commands include the alway-set leading bit. */ #define EE_WRITE_CMD (5) #define EE_READ_CMD (6) #define EE_ERASE_CMD (7) static int __devinit read_eeprom (void *ioaddr, int location, int addr_len) { int i; unsigned retval = 0; void *ee_addr = ioaddr + Cfg9346; int read_cmd = location | (EE_READ_CMD << addr_len); writeb (EE_ENB & ~EE_CS, ee_addr); writeb (EE_ENB, ee_addr); eeprom_delay (); /* Shift the read command bits out. */ for (i = 4 + addr_len; i >= 0; i--) { int dataval = (read_cmd & (1 << i)) ? EE_DATA_WRITE : 0; writeb (EE_ENB | dataval, ee_addr); eeprom_delay (); writeb (EE_ENB | dataval | EE_SHIFT_CLK, ee_addr); eeprom_delay (); } writeb (EE_ENB, ee_addr); eeprom_delay (); for (i = 16; i > 0; i--) { writeb (EE_ENB | EE_SHIFT_CLK, ee_addr); eeprom_delay (); retval = (retval << 1) | ((readb (ee_addr) & EE_DATA_READ) ? 1 : 0); writeb (EE_ENB, ee_addr); eeprom_delay (); } /* Terminate the EEPROM access. */ writeb (~EE_CS, ee_addr); eeprom_delay (); return retval; } /* Put the board into D3cold state and wait for WakeUp signal */ static void cp_set_d3_state (struct cp_private *cp) { pci_enable_wake (cp->pdev, 0, 1); /* Enable PME# generation */ pci_set_power_state (cp->pdev, 3); } static int __devinit cp_init_one (struct pci_dev *pdev, const struct pci_device_id *ent) { struct net_device *dev; struct cp_private *cp; int rc; void *regs; long pciaddr; unsigned int addr_len, i; u8 pci_rev, cache_size; unsigned int board_type = (unsigned int) ent->driver_data; #ifndef MODULE static int version_printed; if (version_printed++ == 0) printk("%s", version); #endif pci_read_config_byte(pdev, PCI_REVISION_ID, &pci_rev); if (pdev->vendor == PCI_VENDOR_ID_REALTEK && pdev->device == PCI_DEVICE_ID_REALTEK_8139 && pci_rev < 0x20) { printk(KERN_ERR PFX "pci dev %s (id %04x:%04x rev %02x) is not an 8139C+ compatible chip\n", pci_name(pdev), pdev->vendor, pdev->device, pci_rev); printk(KERN_ERR PFX "Try the \"8139too\" driver instead.\n"); return -ENODEV; } dev = alloc_etherdev(sizeof(struct cp_private)); if (!dev) return -ENOMEM; SET_MODULE_OWNER(dev); cp = dev->priv; cp->pdev = pdev; cp->board_type = board_type; cp->dev = dev; cp->msg_enable = (debug < 0 ? CP_DEF_MSG_ENABLE : debug); spin_lock_init (&cp->lock); cp->mii_if.dev = dev; cp->mii_if.mdio_read = mdio_read; cp->mii_if.mdio_write = mdio_write; cp->mii_if.phy_id = CP_INTERNAL_PHY; cp->mii_if.phy_id_mask = 0x1f; cp->mii_if.reg_num_mask = 0x1f; cp_set_rxbufsize(cp); rc = pci_enable_device(pdev); if (rc) goto err_out_free; rc = pci_request_regions(pdev, DRV_NAME); if (rc) goto err_out_disable; if (pdev->irq < 2) { rc = -EIO; printk(KERN_ERR PFX "invalid irq (%d) for pci dev %s\n", pdev->irq, pci_name(pdev)); goto err_out_res; } pciaddr = pci_resource_start(pdev, 1); if (!pciaddr) { rc = -EIO; printk(KERN_ERR PFX "no MMIO resource for pci dev %s\n", pci_name(pdev)); goto err_out_res; } if (pci_resource_len(pdev, 1) < CP_REGS_SIZE) { rc = -EIO; printk(KERN_ERR PFX "MMIO resource (%lx) too small on pci dev %s\n", pci_resource_len(pdev, 1), pci_name(pdev)); goto err_out_res; } /* Configure DMA attributes. */ if (!pci_set_dma_mask(pdev, (u64) 0xffffffffffffffffULL)) { cp->pci_using_dac = 1; } else { rc = pci_set_dma_mask(pdev, (u64) 0xffffffff); if (rc) { printk(KERN_ERR PFX "No usable DMA configuration, " "aborting.\n"); goto err_out_res; } cp->pci_using_dac = 0; } regs = ioremap_nocache(pciaddr, CP_REGS_SIZE); if (!regs) { rc = -EIO; printk(KERN_ERR PFX "Cannot map PCI MMIO (%lx@%lx) on pci dev %s\n", pci_resource_len(pdev, 1), pciaddr, pci_name(pdev)); goto err_out_res; } dev->base_addr = (unsigned long) regs; cp->regs = regs; cp_stop_hw(cp); /* read MAC address from EEPROM */ addr_len = read_eeprom (regs, 0, 8) == 0x8129 ? 8 : 6; for (i = 0; i < 3; i++) ((u16 *) (dev->dev_addr))[i] = le16_to_cpu (read_eeprom (regs, i + 7, addr_len)); dev->open = cp_open; dev->stop = cp_close; dev->set_multicast_list = cp_set_rx_mode; dev->hard_start_xmit = cp_start_xmit; dev->get_stats = cp_get_stats; dev->do_ioctl = cp_ioctl; dev->poll = cp_rx_poll; dev->weight = 16; /* arbitrary? from NAPI_HOWTO.txt. */ #ifdef BROKEN dev->change_mtu = cp_change_mtu; #endif dev->ethtool_ops = &cp_ethtool_ops; #if 0 dev->tx_timeout = cp_tx_timeout; dev->watchdog_timeo = TX_TIMEOUT; #endif #if CP_VLAN_TAG_USED dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX; dev->vlan_rx_register = cp_vlan_rx_register; dev->vlan_rx_kill_vid = cp_vlan_rx_kill_vid; #endif dev->irq = pdev->irq; rc = register_netdev(dev); if (rc) goto err_out_iomap; printk (KERN_INFO "%s: %s at 0x%lx, " "%02x:%02x:%02x:%02x:%02x:%02x, " "IRQ %d\n", dev->name, cp_board_tbl[board_type].name, dev->base_addr, dev->dev_addr[0], dev->dev_addr[1], dev->dev_addr[2], dev->dev_addr[3], dev->dev_addr[4], dev->dev_addr[5], dev->irq); pci_set_drvdata(pdev, dev); /* * Looks like this is necessary to deal with on all architectures, * even this %$#%$# N440BX Intel based thing doesn't get it right. * Ie. having two NICs in the machine, one will have the cache * line set at boot time, the other will not. */ pci_read_config_byte(pdev, PCI_CACHE_LINE_SIZE, &cache_size); cache_size <<= 2; if (cache_size != SMP_CACHE_BYTES) { printk(KERN_INFO "%s: PCI cache line size set incorrectly " "(%i bytes) by BIOS/FW, ", dev->name, cache_size); if (cache_size > SMP_CACHE_BYTES) printk("expecting %i\n", SMP_CACHE_BYTES); else { printk("correcting to %i\n", SMP_CACHE_BYTES); pci_write_config_byte(pdev, PCI_CACHE_LINE_SIZE, SMP_CACHE_BYTES >> 2); } } /* enable busmastering and memory-write-invalidate */ pci_set_master(pdev); pci_set_mwi(pdev); if (cp->wol_enabled) cp_set_d3_state (cp); return 0; err_out_iomap: iounmap(regs); err_out_res: pci_release_regions(pdev); err_out_disable: pci_disable_device(pdev); err_out_free: kfree(dev); return rc; } static void __devexit cp_remove_one (struct pci_dev *pdev) { struct net_device *dev = pci_get_drvdata(pdev); struct cp_private *cp = dev->priv; if (!dev) BUG(); unregister_netdev(dev); iounmap(cp->regs); if (cp->wol_enabled) pci_set_power_state (pdev, 0); pci_release_regions(pdev); pci_disable_device(pdev); pci_set_drvdata(pdev, NULL); kfree(dev); } #ifdef CONFIG_PM static int cp_suspend (struct pci_dev *pdev, u32 state) { struct net_device *dev; struct cp_private *cp; unsigned long flags; dev = pci_get_drvdata (pdev); cp = dev->priv; if (!dev || !netif_running (dev)) return 0; netif_device_detach (dev); netif_stop_queue (dev); spin_lock_irqsave (&cp->lock, flags); /* Disable Rx and Tx */ cpw16 (IntrMask, 0); cpw8 (Cmd, cpr8 (Cmd) & (~RxOn | ~TxOn)); spin_unlock_irqrestore (&cp->lock, flags); if (cp->pdev && cp->wol_enabled) { pci_save_state (cp->pdev, cp->power_state); cp_set_d3_state (cp); } return 0; } static int cp_resume (struct pci_dev *pdev) { struct net_device *dev; struct cp_private *cp; dev = pci_get_drvdata (pdev); cp = dev->priv; netif_device_attach (dev); if (cp->pdev && cp->wol_enabled) { pci_set_power_state (cp->pdev, 0); pci_restore_state (cp->pdev, cp->power_state); } cp_init_hw (cp); netif_start_queue (dev); return 0; } #endif /* CONFIG_PM */ static struct pci_driver cp_driver = { .name = DRV_NAME, .id_table = cp_pci_tbl, .probe = cp_init_one, .remove = __devexit_p(cp_remove_one), #ifdef CONFIG_PM .resume = cp_resume, .suspend = cp_suspend, #endif }; static int __init cp_init (void) { #ifdef MODULE printk("%s", version); #endif return pci_module_init (&cp_driver); } static void __exit cp_exit (void) { pci_unregister_driver (&cp_driver); } module_init(cp_init); module_exit(cp_exit); From purna@jcom.home.ne.jp Sat Aug 30 19:30:43 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 30 Aug 2003 19:31:16 -0700 (PDT) Received: from femail21.im.home.ne.jp (femail21.im.home.ne.jp [203.165.11.236]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7V2UgWZ014426 for ; Sat, 30 Aug 2003 19:30:43 -0700 Received: by femail21.im.home.ne.jp with ESMTP id <20030831023041.LMXS1074.femail21.im.home.ne.jp@smtp102.mf.home.ne.jp>; Sun, 31 Aug 2003 11:30:41 +0900 Received: from jcom.home.ne.jp (61-25-120-68.home.ne.jp [61.25.120.68]) by smtp102.mf.home.ne.jp (s13073000) with ESMTP id h7V2UeIq014642; Sun, 31 Aug 2003 11:30:40 +0900 (JST) Message-ID: <3F515DD0.9000409@jcom.home.ne.jp> Date: Sun, 31 Aug 2003 11:30:40 +0900 From: Yusuf Wilajati Purna User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: jgarzik@pobox.com, netdev@oss.sgi.com CC: purna@jcom.home.ne.jp Subject: [PATCH] fix skb binding time in some network drivers due to skb_padto conversion Content-Type: multipart/mixed; boundary="------------020906000702060209040404" X-archive-position: 5423 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: purna@jcom.home.ne.jp Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------020906000702060209040404 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hi Jeff, It seems that skb_padto security fixes in 2.4 and 2.5 trying to fix "CAN-2003-0001:Multiple ethernet NID device drivers do not pad frames with null bytes", do not put the skb_padto blocks in proper places in the 3c527, eth16i, fmv18x, seeq8005, yellowfin device drivers. In case a driver calls skb_padto(), it is possible that the space available in the original skb buffer tailroom is less than the space to pad. In this case, in short, the skb_padto() will create a new skb buffer, copy data from the original skb buffer to a new skb buffer, free the original buffer, and finally return the new buffer. If this happens to the aforementioned device drivers, they come to point to wrong data. And, for 3c527 and yellowfin, the drivers can unexpectedly double free the original skb buffers since they still point to the original skb buffers. The attached patch against 2.4.23pre1 fixes these issues. If the patch looks okay, please consider including it in 2.4 and 2.5/6. Regards, purna@sm.sony.co.jp --------------020906000702060209040404 Content-Type: text/plain; name="patchfile-skb_padto" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="patchfile-skb_padto" ZGlmZiAtdU5yIGxpbnV4LTIuNC9kcml2ZXJzL25ldC8zYzUyNy5jIGxpbnV4LTIuNGIvZHJp dmVycy9uZXQvM2M1MjcuYwotLS0gbGludXgtMi40L2RyaXZlcnMvbmV0LzNjNTI3LmMJRnJp IEF1ZyAyOSAwNDowMDoxOSAyMDAzCisrKyBsaW51eC0yLjRiL2RyaXZlcnMvbmV0LzNjNTI3 LmMJU2F0IEF1ZyAzMCAwMDo0NDo0NyAyMDAzCkBAIC0xMDgzLDE1ICsxMDgzLDE2IEBACiAJ LyogTlAgaXMgdGhlIGJ1ZmZlciB3ZSB3aWxsIGJlIGxvYWRpbmcgKi8KIAlucD1scC0+dHhf cmluZ1tscC0+dHhfcmluZ19oZWFkXS5wOyAKIAotCS8qIFdlIHdpbGwgbmVlZCB0aGlzIHRv IGZsdXNoIHRoZSBidWZmZXIgb3V0ICovCi0JbHAtPnR4X3JpbmdbbHAtPnR4X3JpbmdfaGVh ZF0uc2tiPXNrYjsKLSAgIAkgICAKICAgIAlpZihza2ItPmxlbiA8IEVUSF9aTEVOKQogICAg CXsKICAgIAkJc2tiID0gc2tiX3BhZHRvKHNrYiwgRVRIX1pMRU4pOwogICAgCQlpZihza2Ig PT0gTlVMTCkKICAgIAkJCWdvdG8gb3V0OwogICAgCX0KKworCS8qIFdlIHdpbGwgbmVlZCB0 aGlzIHRvIGZsdXNoIHRoZSBidWZmZXIgb3V0ICovCisJbHAtPnR4X3JpbmdbbHAtPnR4X3Jp bmdfaGVhZF0uc2tiPXNrYjsKKwogCW5wLT5sZW5ndGggPSAoc2tiLT5sZW4gPCBFVEhfWkxF TikgPyBFVEhfWkxFTiA6IHNrYi0+bGVuOyAKIAkJCQogCW5wLT5kYXRhCT0gdmlydF90b19i dXMoc2tiLT5kYXRhKTsKZGlmZiAtdU5yIGxpbnV4LTIuNC9kcml2ZXJzL25ldC9ldGgxNmku YyBsaW51eC0yLjRiL2RyaXZlcnMvbmV0L2V0aDE2aS5jCi0tLSBsaW51eC0yLjQvZHJpdmVy cy9uZXQvZXRoMTZpLmMJVHVlIEZlYiAgNCAwNDowMDozNCAyMDAzCisrKyBsaW51eC0yLjRi L2RyaXZlcnMvbmV0L2V0aDE2aS5jCVNhdCBBdWcgMzAgMDA6MTA6MzMgMjAwMwpAQCAtMTA1 Nyw3ICsxMDU3LDcgQEAKIAlpbnQgaW9hZGRyID0gZGV2LT5iYXNlX2FkZHI7CiAJaW50IHN0 YXR1cyA9IDA7CiAJdXNob3J0IGxlbmd0aCA9IHNrYi0+bGVuOwotCXVuc2lnbmVkIGNoYXIg KmJ1ZiA9IHNrYi0+ZGF0YTsKKwl1bnNpZ25lZCBjaGFyICpidWY7CiAJdW5zaWduZWQgbG9u ZyBmbGFnczsKIAogCWlmKGxlbmd0aCA8IEVUSF9aTEVOKQpAQCAtMTA2Nyw2ICsxMDY3LDcg QEAKIAkJCXJldHVybiAwOwogCQlsZW5ndGggPSBFVEhfWkxFTjsKIAl9CisJYnVmID0gc2ti LT5kYXRhOwogCiAJbmV0aWZfc3RvcF9xdWV1ZShkZXYpOwogCQkKZGlmZiAtdU5yIGxpbnV4 LTIuNC9kcml2ZXJzL25ldC9mbXYxOHguYyBsaW51eC0yLjRiL2RyaXZlcnMvbmV0L2ZtdjE4 eC5jCi0tLSBsaW51eC0yLjQvZHJpdmVycy9uZXQvZm12MTh4LmMJVHVlIEZlYiAgNCAwNDow MDozNCAyMDAzCisrKyBsaW51eC0yLjRiL2RyaXZlcnMvbmV0L2ZtdjE4eC5jCVNhdCBBdWcg MzAgMDA6MTI6MDYgMjAwMwpAQCAtMzcwLDcgKzM3MCw3IEBACiAJc3RydWN0IG5ldF9sb2Nh bCAqbHAgPSBkZXYtPnByaXY7CiAJaW50IGlvYWRkciA9IGRldi0+YmFzZV9hZGRyOwogCXNo b3J0IGxlbmd0aCA9IHNrYi0+bGVuOwotCXVuc2lnbmVkIGNoYXIgKmJ1ZiA9IHNrYi0+ZGF0 YTsKKwl1bnNpZ25lZCBjaGFyICpidWY7CiAJdW5zaWduZWQgbG9uZyBmbGFnczsKIAogCS8q IEJsb2NrIGEgdHJhbnNtaXQgZnJvbSBvdmVybGFwcGluZy4gICovCkBAIC0zODksNiArMzg5 LDcgQEAKIAkJCXJldHVybiAwOwogCQlsZW5ndGggPSBFVEhfWkxFTjsKIAl9CisJYnVmID0g c2tiLT5kYXRhOwogCQogCWlmIChuZXRfZGVidWcgPiA0KQogCQlwcmludGsoIiVzOiBUcmFu c21pdHRpbmcgYSBwYWNrZXQgb2YgbGVuZ3RoICVsdS5cbiIsIGRldi0+bmFtZSwKZGlmZiAt dU5yIGxpbnV4LTIuNC9kcml2ZXJzL25ldC9zZWVxODAwNS5jIGxpbnV4LTIuNGIvZHJpdmVy cy9uZXQvc2VlcTgwMDUuYwotLS0gbGludXgtMi40L2RyaXZlcnMvbmV0L3NlZXE4MDA1LmMJ VHVlIEZlYiAgNCAwNDowMDozNCAyMDAzCisrKyBsaW51eC0yLjRiL2RyaXZlcnMvbmV0L3Nl ZXE4MDA1LmMJU2F0IEF1ZyAzMCAwMDoxMzoyNyAyMDAzCkBAIC0zNzksNyArMzc5LDcgQEAK IHsKIAlzdHJ1Y3QgbmV0X2xvY2FsICpscCA9IChzdHJ1Y3QgbmV0X2xvY2FsICopZGV2LT5w cml2OwogCXNob3J0IGxlbmd0aCA9IHNrYi0+bGVuOwotCXVuc2lnbmVkIGNoYXIgKmJ1ZiA9 IHNrYi0+ZGF0YTsKKwl1bnNpZ25lZCBjaGFyICpidWY7CiAKIAlpZihsZW5ndGggPCBFVEhf WkxFTikKIAl7CkBAIC0zODgsNiArMzg4LDggQEAKIAkJCXJldHVybiAwOwogCQlsZW5ndGgg PSBFVEhfWkxFTjsKIAl9CisJYnVmID0gc2tiLT5kYXRhOworCiAJLyogQmxvY2sgYSB0aW1l ci1iYXNlZCB0cmFuc21pdCBmcm9tIG92ZXJsYXBwaW5nICovCiAJbmV0aWZfc3RvcF9xdWV1 ZShkZXYpOwogCQpkaWZmIC11TnIgbGludXgtMi40L2RyaXZlcnMvbmV0L3llbGxvd2Zpbi5j IGxpbnV4LTIuNGIvZHJpdmVycy9uZXQveWVsbG93ZmluLmMKLS0tIGxpbnV4LTIuNC9kcml2 ZXJzL25ldC95ZWxsb3dmaW4uYwlUdWUgRmViICA0IDA0OjAwOjM0IDIwMDMKKysrIGxpbnV4 LTIuNGIvZHJpdmVycy9uZXQveWVsbG93ZmluLmMJU2F0IEF1ZyAzMCAwMDoyNjo1NyAyMDAz CkBAIC04NjcsOCArODY3LDYgQEAKIAkvKiBDYWxjdWxhdGUgdGhlIG5leHQgVHggZGVzY3Jp cHRvciBlbnRyeS4gKi8KIAllbnRyeSA9IHlwLT5jdXJfdHggJSBUWF9SSU5HX1NJWkU7CiAK LQl5cC0+dHhfc2tidWZmW2VudHJ5XSA9IHNrYjsKLQogCWlmIChneF9maXgpIHsJLyogTm90 ZTogb25seSB3b3JrcyBmb3IgcGFkZGFibGUgcHJvdG9jb2xzIGUuZy4gIElQLiAqLwogCQlp bnQgY2FjaGVsaW5lX2VuZCA9ICgodW5zaWduZWQgbG9uZylza2ItPmRhdGEgKyBza2ItPmxl bikgJSAzMjsKIAkJLyogRml4IEdYIGNoaXBzZXQgZXJyYXRhLiAqLwpAQCAtODg1LDYgKzg4 Myw4IEBACiAJCQlyZXR1cm4gMDsKIAkJfQogCX0KKwl5cC0+dHhfc2tidWZmW2VudHJ5XSA9 IHNrYjsKKwogI2lmZGVmIE5PX1RYU1RBVFMKIAl5cC0+dHhfcmluZ1tlbnRyeV0uYWRkciA9 IGNwdV90b19sZTMyKHBjaV9tYXBfc2luZ2xlKHlwLT5wY2lfZGV2LCAKIAkJc2tiLT5kYXRh LCBsZW4sIFBDSV9ETUFfVE9ERVZJQ0UpKTsK --------------020906000702060209040404-- From davem@pizda.ninka.net Sat Aug 30 19:32:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 30 Aug 2003 19:33:15 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7V2WeWZ014821 for ; Sat, 30 Aug 2003 19:32:41 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id TAA30083; Sat, 30 Aug 2003 19:23:47 -0700 Date: Sat, 30 Aug 2003 19:23:47 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: jschlst@samba.org, netdev@oss.sgi.com Subject: Re: [PATCH] (0/13) appletalk bug fixes Message-Id: <20030830192347.5b9b2622.davem@redhat.com> In-Reply-To: <20030829135119.78d98961.shemminger@osdl.org> References: <20030829135119.78d98961.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5424 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 29 Aug 2003 13:51:19 -0700 Stephen Hemminger wrote: > 1. Setting owner field on DDP sockets (bug) > 2. Invert logic on release (readability) > 3. Align headers with columns (cosmetic) > 4. Keep track of last sent > 5. Purge aarp entries on unload (bug) > 6. aarp deltimer_sync > 7. aarp convert to seq_file > 8. set owner on /proc/net/atalk directory > 9. Update comment in DDP about modules > 10. Orphan DDP sockets on destroy (bug) > 11. Change /proc/net/aarp to /proc/net/atalk/arp > 12. Keep netdevice references for pointers held > 13. Update DDP to new protocol format Awesome work Stephen, all patches applied. From davem@pizda.ninka.net Sat Aug 30 19:33:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 30 Aug 2003 19:33:57 -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.5) with SMTP id h7V2XOWZ014930 for ; Sat, 30 Aug 2003 19:33:24 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id TAA30105; Sat, 30 Aug 2003 19:24:31 -0700 Date: Sat, 30 Aug 2003 19:24:31 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: maxk@qualcomm.com, netdev@oss.sgi.com Subject: Re: [PATCH] bluetooth - set sock owner Message-Id: <20030830192431.32fc7183.davem@redhat.com> In-Reply-To: <20030829112059.29414fc5.shemminger@osdl.org> References: <20030829112059.29414fc5.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5425 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 29 Aug 2003 11:20:59 -0700 Stephen Hemminger wrote: > All sockets created by a protocol need to have owner field set > to prevent problems with orphaned sockets during module unload. Applied, thanks Stephen. From jgarzik@pobox.com Sat Aug 30 20:34:37 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 30 Aug 2003 20:35:10 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7V3YZWZ017986 for ; Sat, 30 Aug 2003 20:34:36 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:33176 helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.22) id 19tDF9-0004gW-37; Sat, 30 Aug 2003 22:26:47 +0100 Message-ID: <3F51168D.1010306@pobox.com> Date: Sat, 30 Aug 2003 17:26:37 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: shmulik.hen@intel.com CC: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [Bonding-devel] Re: [bonding][2/3] Synchronizing 2.4-2.6 References: <3F4E27A2.9060204@pobox.com> <200308302239.40237.shmulik.hen@intel.com> In-Reply-To: <200308302239.40237.shmulik.hen@intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5426 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 Shmulik Hen wrote: > On Thursday 28 August 2003 07:02 pm, Jeff Garzik wrote: > >>Hen, Shmulik wrote: >> >>>After patch set 1, It should be as easy as just copying all the >>>bonding related files from 2.4 to 2.6. I guess I can do that on >>>Sunday if someone hasn't already done it before. >> >>I had hoped to preserve the revision history. Simply copying the >>files over does not do that :( >> >>What I mean by preserving revision history is, changes should be >>submitted to 2.6 in the same granularity as they were to 2.4... >> > > > God, I wish I was an English speaking person... :( > Amir, on the other hand, understood exactly what you intended, so > there should be something ready for tomorrow that brings 2.6 to the > same point as 2.4 after set 1, in small steps. After that, sets 2 and > 3 could be applied the same way for 2.4 and 2.6. No worries. Even I don't understand myself sometimes. :) Jeff From davem@pizda.ninka.net Sat Aug 30 20:39:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 30 Aug 2003 20:40:17 -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.5) with SMTP id h7V3diWZ018496 for ; Sat, 30 Aug 2003 20:39:45 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id UAA30290; Sat, 30 Aug 2003 20:30:43 -0700 Date: Sat, 30 Aug 2003 20:30:43 -0700 From: "David S. Miller" To: Bart De Schuymer Cc: shemminger@osdl.org, greearb@candelatech.com, netdev@oss.sgi.com Subject: Re: [PATCH/RFC] disallow vlan devices on top of a logical bridge device Message-Id: <20030830203043.0eb1a660.davem@redhat.com> In-Reply-To: <200308301504.03241.bdschuym@pandora.be> References: <200308301504.03241.bdschuym@pandora.be> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5427 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sat, 30 Aug 2003 15:04:03 +0200 Bart De Schuymer wrote: > The patch below disables making vlan devices on top of bridge > devices, f.e. br0.12 would be impossible. I don't think disallowing this merely for the sake of implementation convenience is such a good idea. And from other people's comments, such setups might even be useful. From davem@pizda.ninka.net Sat Aug 30 20:42:08 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 30 Aug 2003 20:42: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.5) with SMTP id h7V3g8WZ018897 for ; Sat, 30 Aug 2003 20:42:08 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id UAA30303; Sat, 30 Aug 2003 20:33:11 -0700 Date: Sat, 30 Aug 2003 20:33:11 -0700 From: "David S. Miller" To: Vinay K Nallamothu Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2.4.22-pre1][NET] timer cleanups Message-Id: <20030830203311.0b8c0807.davem@redhat.com> In-Reply-To: <1062258097.8532.26.camel@lima.royalchallenge.com> References: <1062258097.8532.26.camel@lima.royalchallenge.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5428 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sat, 30 Aug 2003 21:11:37 +0530 Vinay K Nallamothu wrote: > This patch does the following timer code cleanup: > > 1. Change del_timer/add_timer to mod_timer > 2. Use static timer initialisation wherever applicable I'm not accepting this. In particular, the ip6_flowlabel.c change is a bad idea because the code remains racey. Someone submitted a similar move to mod_timer() for ip6_flowlabel earlier this week so see my comments there about what needs to occur to fix the code properly. Just blindly doing these kinds of conversions to mod_timer() is foolhardy. You need to apply some brains to it to make sure you really are getting rid of whatever potential races exist in the code. And in the ip6_flowlabel.c case things are as buggy as they were before. From AntiVir@zeus.unive.it Sat Aug 30 21:19:21 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 30 Aug 2003 21:19:53 -0700 (PDT) Received: from zeus.unive.it (zeus.unive.it [157.138.1.81]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7V4JJWZ020801 for ; Sat, 30 Aug 2003 21:19:20 -0700 Received: from zeus.unive.it (localhost.localdomain [127.0.0.1]) by zeus.unive.it (8.12.9/8.12.9) with ESMTP id h7V4JIKX004681 for ; Sun, 31 Aug 2003 06:19:18 +0200 Received: (from uucp@localhost) by zeus.unive.it (8.12.9/8.12.9/Submit) id h7V4JIfZ004679 for ; Sun, 31 Aug 2003 06:19:18 +0200 Date: Sun, 31 Aug 2003 06:19:18 +0200 From: AntiVir@zeus.unive.it Message-Id: <200308310419.h7V4JIfZ004679@zeus.unive.it> To: Subject: AntiVir ALERT [your mail: "Re: Details"] X-AntiVirus: checked by AntiVir Milter 1.0.0.8; AVE 6.21.0.1; VDF 6.21.0.32 X-archive-position: 5429 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: AntiVir@zeus.unive.it Precedence: bulk X-list: netdev * * * * * * * * * * * * * * * AntiVir ALERT * * * * * * * * * * * * * * * This version of AntiVir is licensed and full featured. AntiVir has detected the following in a mail from your address: Worm/Sobig.F The mail was not delivered. Please remove any potential malicious software from your computer before sending a new mail with attachments. Mail-Info: --8<-- From: To: Date: Sun, 31 Aug 2003 13:19:16 +0900 Subject: Re: Details --8<-- -- AntiVir for UNIX Copyright (C) 1994-2002 by H+BEDV Datentechnik GmbH. All rights reserved. For more information see http://www.antivir.de/ or http://www.hbedv.com/ From davem@pizda.ninka.net Sat Aug 30 22:43:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 30 Aug 2003 22:43:47 -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.5) with SMTP id h7V5hDWZ024749 for ; Sat, 30 Aug 2003 22:43:13 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id WAA30757; Sat, 30 Aug 2003 22:34:19 -0700 Date: Sat, 30 Aug 2003 22:34:19 -0700 From: "David S. Miller" To: Ben Greear Cc: netdev@oss.sgi.com Subject: Re: VLAN patch try 2, tabs instead of spaces Message-Id: <20030830223419.3a9ee2b4.davem@redhat.com> In-Reply-To: <3F3080C4.9070507@candelatech.com> References: <3F3080C4.9070507@candelatech.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5430 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 05 Aug 2003 21:15:00 -0700 Ben Greear wrote: > Same as last time, but now using tabs instead of spaces. I was about to apply this, then I noticed that you whitespace fixed the entire file. Please don't do that, I want just your change not your change + whitespace cleanups. That makes it hard to figure out exactly what your patch actually does amongst all the whitespace changes. From maz@misterjones.org Sun Aug 31 02:33:32 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 31 Aug 2003 02:34:05 -0700 (PDT) Received: from young-lust.wild-wind.fr.eu.org (lopsy-lu.misterjones.org [62.4.18.26]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7V9XUWZ018075 for ; Sun, 31 Aug 2003 02:33:31 -0700 Received: from hina.wild-wind.fr.eu.org ([192.168.70.139]) by young-lust.wild-wind.fr.eu.org with esmtp (Exim 3.35 #1 (Debian)) id 19tOdi-00017b-00; Sun, 31 Aug 2003 11:36:54 +0200 Received: from maz by hina.wild-wind.fr.eu.org with local (Exim 3.36 #1 (Debian)) id 19tOYN-0006Ga-00; Sun, 31 Aug 2003 11:31:23 +0200 To: Jeff Garzik Cc: akpm@osdl.org, linux-net@vger.kernel.org, Maillist netdev Subject: de2104x (was Re: [PATCH][2.6] de4x5 cleanup) Organization: Metropolis -- Nowhere X-Attribution: maz Reply-to: mzyngier@freesurf.fr References: <3F50E3FD.1000703@pobox.com> <3F50F805.9090805@pobox.com> From: Marc Zyngier Date: Sun, 31 Aug 2003 11:31:23 +0200 Message-ID: In-Reply-To: <3F50F805.9090805@pobox.com> (Jeff Garzik's message of "Sat, 30 Aug 2003 15:16:21 -0400") Lines: 114 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 5431 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mzyngier@freesurf.fr Precedence: bulk X-list: netdev >>>>> "Jeff" == Jeff Garzik writes: Jeff> Well, 2.6 tulip intentionally doesn't work at all on 21040 and Jeff> 21041 :) That's what de2104x driver is for. Can you give that a Jeff> beating, and verify that it works for you? So, as promised, I tried de2104x on the AS-255 (which was problematic a few months ago). I must say it works nicely, as long as I don't unplug the cable... Here are the details : otherside:~# lspci 00:06.0 SCSI storage controller: LSI Logic / Symbios Logic (formerly NCR) 53c810 (rev 11) 00:07.0 Non-VGA unclassified device: Intel Corp. 82378IB [SIO ISA Bridge] (rev 43) 00:0d.0 VGA compatible controller: Digital Equipment Corporation PBXGB [TGA2] (rev 22) 00:0e.0 Ethernet controller: Digital Equipment Corporation DECchip 21040 [Tulip] (rev 26) otherside:~# ethtool eth0 Settings for eth0: Supported ports: [ TP AUI ] Supported link modes: 10baseT/Half 10baseT/Full Supports auto-negotiation: No Advertised link modes: 10baseT/Half 10baseT/Full Advertised auto-negotiation: No Speed: Unknown! (5) Duplex: Half Port: AUI PHYAD: 0 Transceiver: internal Auto-negotiation: on Current message level: 0x000000f7 (247) Link detected: yes Note that an AUI port is reported, while the system really has only a 10baseT port. while booting, everything looks OK : [...] de2104x PCI Ethernet driver v0.5.4 (Jan 1, 2002) eth0: 21040 at 0xfffffc0301209000, 00:00:25:4a:21:3a, IRQ 15 [...] eth0: enabling interface eth0: set link 10baseT-HD eth0: mode 0xfffc0040, sia 0xffffffcd,0xffff8f01,0xffffffff,0xffff0000 eth0: set mode 0xfffc0000, set sia 0x8f01,0xffff,0x0 eth0: link up, media 10baseT-HD It works perfectly, until I unplug the cable (I know, I'm a bad boy... ;-), wait 10 seconds, then plug it back : eth0: link down eth0: set link AUI eth0: mode 0xfffc0000, sia 0xffffffc1,0xffff8f09,0xffff0705,0xffff0006 eth0: set mode 0xfffc0000, set sia 0x8f09,0x705,0x6 eth0: link up, media AUI So link is now up, on a non-existant AUI port ?!?! Let's inform the driver that we want the TP port instead : otherside:~# ethtool -s eth0 port tp Cannot set new settings: Invalid argument not setting port So 'tp' is invalid ? Interesting... Let's try the old ifconfig down/up method : eth0: disabling interface eth0: enabling interface eth0: set link AUI eth0: mode 0xfffc0040, sia 0xffffffc1,0xffff8f09,0xffff0705,0xffff0006 eth0: set mode 0xfffc0000, set sia 0x8f09,0x705,0x6 eth0: link up, media AUI No effect... Let's try it again, for fun : eth0: disabling interface eth0: timeout expired stopping DMA eth0: enabling interface eth0: set link AUI eth0: mode 0xfffc0040, sia 0xffffffc1,0xffff8f09,0xffff0705,0xffff0006 eth0: set mode 0xfffc0000, set sia 0x8f09,0x705,0x6 eth0: link up, media AUI Problem stopping DMA ? Frightening ! :-) Finally, I had to reboot the system to get the the network back up (since modules are not really useable currently on alpha, but that's another story). Now, the same thing with the ugly de4x5 : [...] 0000:00:0e.0: DE434/5 at 0x8400, h/w address 00:00:f8:25:4a:21, and requires IRQ15 (provided by PCI BIOS). de4x5.c:V0.546 2001/02/22 davies@maniac.ultranet.com [...] eth0: media is TP. Unplug the cable, wait 10 seconds, plug it back : eth0: media is unconnected, link down or incompatible connection. eth0: media is TP. Works as expected. While this problem is a corner case (the de2104x driver itself works fine), it would be nice if we could solve this issue (loosing network connectivity because someone rebooted the switch is a bad behaviour). I promise this machine wont run de4x5 ever again once it is solved :-). Thanks, M. -- Places change, faces change. Life is so very strange. From hch@lst.de Sun Aug 31 03:05:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 31 Aug 2003 03:06:01 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [212.34.189.10]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7VA5OWZ026298 for ; Sun, 31 Aug 2003 03:05:25 -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 h7VA5MZ4018692 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 31 Aug 2003 12:05:22 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.3) id h7VA5LbF018690; Sun, 31 Aug 2003 12:05:21 +0200 Date: Sun, 31 Aug 2003 12:05:21 +0200 From: Christoph Hellwig To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [PATCH] convert icmpv6_socket to per-cpu data Message-ID: <20030831100521.GB18663@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: 5432 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 per-cpu data works in modules for a while now. Also bring over a comment from the IPv4 version and consolidate the error handling. --- 1.40/net/ipv6/icmp.c Mon Aug 18 12:38:34 2003 +++ edited/net/ipv6/icmp.c Fri Aug 29 12:11:40 2003 @@ -70,12 +70,14 @@ DEFINE_SNMP_STAT(struct icmpv6_mib, icmpv6_statistics); /* - * ICMP socket(s) for flow control. + * The ICMP socket(s). This is the most convenient way to flow control + * our ICMP output as well as maintain a clean interface throughout + * all layers. All Socketless IP sends will soon be gone. + * + * On SMP we have one ICMP socket per-cpu. */ - -/* XXX We can't use per_cpu because this can be modular... */ -static struct socket *__icmpv6_socket[NR_CPUS]; -#define icmpv6_socket __icmpv6_socket[smp_processor_id()] +static DEFINE_PER_CPU(struct socket *, __icmpv6_socket) = NULL; +#define icmpv6_socket __get_cpu_var(__icmpv6_socket) static int icmpv6_rcv(struct sk_buff **pskb, unsigned int *nhoffp); @@ -96,6 +98,7 @@ static __inline__ void icmpv6_xmit_lock(void) { local_bh_disable(); + if (unlikely(!spin_trylock(&icmpv6_socket->sk->sk_lock.slock))) BUG(); } @@ -657,33 +660,23 @@ int __init icmpv6_init(struct net_proto_family *ops) { struct sock *sk; - int i; + int err, i, j; for (i = 0; i < NR_CPUS; i++) { - int err; - if (!cpu_possible(i)) continue; err = sock_create(PF_INET6, SOCK_RAW, IPPROTO_ICMPV6, - &__icmpv6_socket[i]); + &per_cpu(__icmpv6_socket, i)); if (err < 0) { - int j; - printk(KERN_ERR "Failed to initialize the ICMP6 control socket " "(err %d).\n", err); - for (j = 0; j < i; j++) { - if (!cpu_possible(j)) - continue; - sock_release(__icmpv6_socket[j]); - __icmpv6_socket[j] = NULL; /* for safety */ - } - return err; + goto fail; } - sk = __icmpv6_socket[i]->sk; + sk = per_cpu(__icmpv6_socket, i)->sk; sk->sk_allocation = GFP_ATOMIC; sk->sk_sndbuf = SK_WMEM_MAX * 2; sk->sk_prot->unhash(sk); @@ -692,16 +685,20 @@ if (inet6_add_protocol(&icmpv6_protocol, IPPROTO_ICMPV6) < 0) { printk(KERN_ERR "Failed to register ICMP6 protocol\n"); - for (i = 0; i < NR_CPUS; i++) { - if (!cpu_possible(i)) - continue; - sock_release(__icmpv6_socket[i]); - __icmpv6_socket[i] = NULL; - } - return -EAGAIN; + err = -EAGAIN; + goto fail; } return 0; + + fail: + for (j = 0; j < i; j++) { + if (!cpu_possible(j)) + continue; + sock_release(per_cpu(__icmpv6_socket, j)); + } + + return err; } void icmpv6_cleanup(void) @@ -711,8 +708,7 @@ for (i = 0; i < NR_CPUS; i++) { if (!cpu_possible(i)) continue; - sock_release(__icmpv6_socket[i]); - __icmpv6_socket[i] = NULL; /* For safety. */ + sock_release(per_cpu(__icmpv6_socket, i)); } inet6_del_protocol(&icmpv6_protocol, IPPROTO_ICMPV6); } From hch@lst.de Sun Aug 31 03:06:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 31 Aug 2003 03:06:59 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [212.34.189.10]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7VA6OWZ026576 for ; Sun, 31 Aug 2003 03:06:25 -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 h7VA6LZ4018709 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 31 Aug 2003 12:06:21 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.3) id h7VA6LoV018707; Sun, 31 Aug 2003 12:06:21 +0200 Date: Sun, 31 Aug 2003 12:06:21 +0200 From: Christoph Hellwig To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [PATCH] convert ip6_tunnel to per-cpu data Message-ID: <20030831100621.GC18663@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: 5433 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 Code looks like copy & pasted from icmpv6 :) --- 1.6/net/ipv6/ip6_tunnel.c Mon Aug 18 13:52:14 2003 +++ edited/net/ipv6/ip6_tunnel.c Fri Aug 29 12:11:40 2003 @@ -64,8 +64,8 @@ #define IPV6_TCLASS_MASK (IPV6_FLOWINFO_MASK & ~IPV6_FLOWLABEL_MASK) /* socket(s) used by ip6ip6_tnl_xmit() for resending packets */ -static struct socket *__ip6_socket[NR_CPUS]; -#define ip6_socket __ip6_socket[smp_processor_id()] +static DEFINE_PER_CPU(struct socket *, __ip6_socket) = NULL; +#define ip6_socket __get_cpu_var(__ip6_socket) static void ip6_xmit_lock(void) { @@ -1168,7 +1168,7 @@ continue; err = sock_create(PF_INET6, SOCK_RAW, IPPROTO_IPV6, - &__ip6_socket[i]); + &per_cpu(__ip6_socket, i)); if (err < 0) { printk(KERN_ERR "Failed to create the IPv6 tunnel socket " @@ -1176,7 +1176,7 @@ err); goto fail; } - sk = __ip6_socket[i]->sk; + sk = per_cpu(__ip6_socket, i)->sk; sk->sk_allocation = GFP_ATOMIC; np = inet6_sk(sk); @@ -1211,8 +1211,8 @@ for (j = 0; j < i; j++) { if (!cpu_possible(j)) continue; - sock_release(__ip6_socket[j]); - __ip6_socket[j] = NULL; + sock_release(per_cpu(__ip6_socket, j)); + per_cpu(__ip6_socket, j) = NULL; } return err; } @@ -1232,8 +1232,8 @@ for (i = 0; i < NR_CPUS; i++) { if (!cpu_possible(i)) continue; - sock_release(__ip6_socket[i]); - __ip6_socket[i] = NULL; + sock_release(per_cpu(__ip6_socket, i)); + per_cpu(__ip6_socket, i) = NULL; } } From davem@pizda.ninka.net Sun Aug 31 03:24:55 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 31 Aug 2003 03:25:29 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7VAOtWZ000413 for ; Sun, 31 Aug 2003 03:24:55 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id DAA31444; Sun, 31 Aug 2003 03:15:56 -0700 Date: Sun, 31 Aug 2003 03:15:56 -0700 From: "David S. Miller" To: Christoph Hellwig Cc: netdev@oss.sgi.com Subject: Re: [PATCH] convert ip6_tunnel to per-cpu data Message-Id: <20030831031556.6d8ee0e8.davem@redhat.com> In-Reply-To: <20030831100621.GC18663@lst.de> References: <20030831100621.GC18663@lst.de> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5434 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sun, 31 Aug 2003 12:06:21 +0200 Christoph Hellwig wrote: > Code looks like copy & pasted from icmpv6 :) Hold on this one, we're in the process of killing the sockets from this code. From shmulik.hen@intel.com Sun Aug 31 03:55:06 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 31 Aug 2003 03:55:39 -0700 (PDT) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7VAt3WZ005275 for ; Sun, 31 Aug 2003 03:55:05 -0700 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.79 2003/08/28 20:22:14 dmccart Exp $) with ESMTP id h7VAnV806048 for ; Sun, 31 Aug 2003 10:49:31 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h7VAw4E05954 for ; Sun, 31 Aug 2003 10:58:04 GMT Received: from hasmsx331.ger.corp.intel.com ([143.185.63.144]) by hasmsxvs01.iil.intel.com (NAVGW 2.5.2.11) with SMTP id M2003083113545523160 ; Sun, 31 Aug 2003 13:54:55 +0300 Received: from hasmsx403.ger.corp.intel.com ([143.185.63.109]) by hasmsx331.ger.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 31 Aug 2003 13:54:55 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [bonding][0/3] Synchronizing 2.4-2.6 Date: Sun, 31 Aug 2003 13:54:55 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [bonding][0/3] Synchronizing 2.4-2.6 Thread-Index: AcNvPYm6CSdVQb+ESNC7hx25wPrDGwAcMkUw From: "Hen, Shmulik" To: "Jeff Garzik" Cc: , X-OriginalArrivalTime: 31 Aug 2003 10:54:55.0829 (UTC) FILETIME=[50466850:01C36FAE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7VAt3WZ005275 X-archive-position: 5435 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev > -----Original Message----- > From: Jeff Garzik [mailto:jgarzik@pobox.com] > Sent: Sunday, August 31, 2003 12:27 AM > To: Hen, Shmulik > Cc: bonding-devel@lists.sourceforge.net; netdev@oss.sgi.com > Subject: Re: [bonding][0/3] Synchronizing 2.4-2.6 > > > Forgot to mention free_netdev(). > > Is it 2.4 compatible ? > > > Only if you create a patch for 2.4 :) > I probably didn't phrase the question right. Meant to ask if free_netdev exists in 2.4 or do we have to export it as was with alloc_netdev, but hey, I can check this myself now that I'm at my desk again :). Shmulik. From vnuorval@tcs.hut.fi Sun Aug 31 05:14:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 31 Aug 2003 05:15:26 -0700 (PDT) Received: from smtp-4.hut.fi (root@smtp-4.hut.fi [130.233.228.94]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7VCEqWZ027983 for ; Sun, 31 Aug 2003 05:14:53 -0700 Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by smtp-4.hut.fi (8.12.9/8.12.9) with ESMTP id h7VCElgL022842; Sun, 31 Aug 2003 15:14:48 +0300 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 9A9E28000B7; Sun, 31 Aug 2003 15:14:47 +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-6.4) with ESMTP id h7VCEl9s024297; Sun, 31 Aug 2003 15:14:47 +0300 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7VCEkeU024293; Sun, 31 Aug 2003 15:14:46 +0300 Date: Sun, 31 Aug 2003 15:14:46 +0300 (EEST) From: Ville Nuorvala To: "David S. Miller" Cc: Christoph Hellwig , Subject: Re: [PATCH] convert ip6_tunnel to per-cpu data In-Reply-To: <20030831031556.6d8ee0e8.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-4.hut.fi) X-DCC-HUTCC-Metrics: smtp-4.hut.fi 1165; Body=4 Fuz1=4 Fuz2=4 X-archive-position: 5436 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 Sun, 31 Aug 2003, David S. Miller wrote: > On Sun, 31 Aug 2003 12:06:21 +0200 > Christoph Hellwig wrote: > > > Code looks like copy & pasted from icmpv6 :) > > Hold on this one, we're in the process of killing > the sockets from this code. Yes, I've been running socketless tunnels for a couple of days now and everything seems to work all right. I'll send the patch shortly... 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 shmulik.hen@intel.com Sun Aug 31 05:19:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 31 Aug 2003 05:20:21 -0700 (PDT) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7VCJjWZ029247 for ; Sun, 31 Aug 2003 05:19:47 -0700 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.79 2003/08/28 20:22:14 dmccart Exp $) with ESMTP id h7VCEF817895 for ; Sun, 31 Aug 2003 12:14:15 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h7VCMmE15653 for ; Sun, 31 Aug 2003 12:22:48 GMT Received: from hasmsx331.ger.corp.intel.com ([143.185.63.144]) by hasmsxvs01.iil.intel.com (NAVGW 2.5.2.11) with SMTP id M2003083115193903019 ; Sun, 31 Aug 2003 15:19:39 +0300 Received: from hasmsx403.ger.corp.intel.com ([143.185.63.109]) by hasmsx331.ger.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 31 Aug 2003 15:19:39 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [bonding][2/3] Synchronizing 2.4-2.6 Date: Sun, 31 Aug 2003 15:19:39 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Bonding-devel] Re: [bonding][2/3] Synchronizing 2.4-2.6 Thread-Index: AcNvLqxSM9tYw5A8SeeSnHAnCN96ZQAg+YQg From: "Hen, Shmulik" To: "Hen, Shmulik" , "Jeff Garzik" Cc: , X-OriginalArrivalTime: 31 Aug 2003 12:19:39.0376 (UTC) FILETIME=[264E1F00:01C36FBA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7VCJjWZ029247 X-archive-position: 5437 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev > -----Original Message----- > From: Hen, Shmulik > Sent: Saturday, August 30, 2003 10:40 PM > To: Jeff Garzik > Cc: bonding-devel@lists.sourceforge.net; netdev@oss.sgi.com > Subject: Re: [bonding][2/3] Synchronizing 2.4-2.6 > > On Thursday 28 August 2003 07:02 pm, Jeff Garzik wrote: > > Hen, Shmulik wrote: > > > After patch set 1, It should be as easy as just copying all the > > > bonding related files from 2.4 to 2.6. I guess I can do that on > > > Sunday if someone hasn't already done it before. > > > > I had hoped to preserve the revision history. Simply copying the > > files over does not do that :( > > > > What I mean by preserving revision history is, changes should be > > submitted to 2.6 in the same granularity as they were to 2.4... > > > > Amir, on the other hand, understood exactly what you intended, so > there should be something ready for tomorrow that brings 2.6 to the > same point as 2.4 after set 1, in small steps. After that, sets 2 and > 3 could be applied the same way for 2.4 and 2.6. > May have spoken a bit too soon. It seems it won't be possible to get sets 2 and 3 to apply the same way for 2.4 and 2.6. In 2.6, things like MOD_{INC|DEC}_USE_COUNT are already gone, and struct initializers have already been converted to c99 style. Probably some other things as well. Since we don't want the code to have ugly ifdefs in it, we'll need to either split the code :(, or backport more stuff from 2.6 to 2.4 :). We'll have to get back to that later this week (probably not before Wednesday, since there is a pressing internal deadline for us due by Tuesday). Shmulik. From shmulik.hen@intel.com Sun Aug 31 06:04:39 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 31 Aug 2003 06:05:12 -0700 (PDT) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7VD4bWZ006322 for ; Sun, 31 Aug 2003 06:04:39 -0700 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.79 2003/08/28 20:22:14 dmccart Exp $) with ESMTP id h7VCx6723633 for ; Sun, 31 Aug 2003 12:59:07 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h7VD7dJ20450 for ; Sun, 31 Aug 2003 13:07:39 GMT Received: from hasmsx331.ger.corp.intel.com ([143.185.63.144]) by hasmsxvs01.iil.intel.com (NAVGW 2.5.2.11) with SMTP id M2003083116043116294 ; Sun, 31 Aug 2003 16:04:31 +0300 Received: from hasmsx403.ger.corp.intel.com ([143.185.63.109]) by hasmsx331.ger.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 31 Aug 2003 16:04:31 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [bonding][3/3] Synchronizing 2.4-2.6 Date: Sun, 31 Aug 2003 16:04:30 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [bonding][3/3] Synchronizing 2.4-2.6 Thread-Index: AcNsyZcUGRDEDWlgQgyJgt5gapT9DQC9nPAA From: "Hen, Shmulik" To: , X-OriginalArrivalTime: 31 Aug 2003 13:04:31.0299 (UTC) FILETIME=[6AD0F930:01C36FC0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7VD4bWZ006322 X-archive-position: 5438 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Discovered a bug in patch 5. Need to re-do the set. Going to do that towards towards the end of the week. Definitely looking for more input regarding this cleanup - everybody feel free to review the code. Shmulik. > -----Original Message----- > From: Hen, Shmulik > Sent: Wednesday, August 27, 2003 8:08 PM > To: bonding-devel@lists.sourceforge.net; netdev@oss.sgi.com > Subject: [bonding][3/3] Synchronizing 2.4-2.6 > > > From another mail from Jay Vosburgh: > > > > This sort of wholesale cleanup is something I've been > > itching to do for a long time, but never had the time for. I'm all > > in favor of it in general; I'll have to see what I think about all > > of the specific changes after I look through the rest of the > > patches. In general, the bonding source has gotten fairly messy > > and hard to follow, so I think cleanup is needed. > > > > This is set 3 - the wholesale cleanup. It's a re-send, only it was > divided into smaller change sets to make them more readable and > smaller in size. A few new things were added as well. > > Applies on 2.4.22. Assumes patch set 2 was already applied. > > patch set can be downloaded from: > http://osdn.dl.sourceforge.net/sourceforge/bonding/patch_set_3 > _cleanup.tar.bz2 > > This will update the following files: > > Documentation/networking/bonding.txt > Documentation/networking/ifenslave.c > drivers/net/bonding/bond_3ad.c > drivers/net/bonding/bond_alb.c > drivers/net/bonding/bond_alb.h > drivers/net/bonding/bonding.h > drivers/net/bonding/bond_main.c > include/linux/if_bonding.h > > Description: > patch 1 - ifenslave.c lite - no more IP settings + code re-org. > patch 2 - convert all debug prints to use the dprintk macro and > consolidate format of all prints (e.g. "bonding: Error: ..."). > patch 3 - death of typedef. eliminate bonding_t/slave_t and > consolidate casting. > patch 4 - remove dead code and redundant checks. add a few new checks > where needed. > patch 5 - consolidate timers initialization, error checking and > re-queuing. > patch 6 - convert too long if-else to a switch-case. Fix all > locations > that handles bond->primary. > patch 7 - eliminate the multicast_more module param and use the > USES_PRIMARY macro instead. > patch 8 - consolidate slave list iterations. > patch 9 - consolidate function declarations: > o all functions begin with bond_ > o return value, function name and all params are on the > same line. > patch 10 - consolidate names of function params and variables (e.g. > bond_dev instead of dev|master|master_dev). > patch 11 - change names for a few of the members of struct bonding. > patch 12 - consolidate return values of functions. > patch 13 - put curly braces around all if, else, for, while, switch > statements. consolidate if conditions > e.g. (ptr == NULL) --> (!ptr) > patch 14 - chomp all trailing white space. > patch 15 - remove duplicate empty lines. add empty lines to improve > readability. > patch 16 - fix indentations. > patch 17 - code re-organization in bond_main.c according to context > (e.g. module initialization, bond initialization, > device entry > points, monitoring, etc.). > it just looks unreadable, but in fact its very simple :) > > -- > | Shmulik Hen Advanced Network Services | > | Israel Design Center, Jerusalem | > | LAN Access Division, Platform Networking | > | Intel Communications Group, Intel corp. | > > > From garzik@gtf.org Sun Aug 31 07:49:30 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 31 Aug 2003 07:50:07 -0700 (PDT) Received: from havoc.gtf.org (havoc.gtf.org [63.247.75.124]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7VEnIWZ025252 for ; Sun, 31 Aug 2003 07:49:19 -0700 Received: by havoc.gtf.org (Postfix, from userid 500) id 33460664B; Sun, 31 Aug 2003 10:09:43 -0400 (EDT) Date: Sun, 31 Aug 2003 10:09:43 -0400 From: Jeff Garzik To: marcelo@parcelfarce.linux.theplanet.co.uk Cc: marcelo@conectiva.com.br, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [bk patches] 2.4.x net driver updates Message-ID: <20030831140943.GA5198@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: 5439 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 Marcelo, please do a bk pull bk://kernel.bkbits.net/jgarzik/net-drivers-2.4 This will update the following files: drivers/net/3c527.c | 7 drivers/net/8139cp.c | 331 ++++++++++++++++------------------------ drivers/net/8139too.c | 70 ++++---- drivers/net/eth16i.c | 3 drivers/net/fmv18x.c | 3 drivers/net/pcmcia/3c574_cs.c | 9 - drivers/net/pcmcia/axnet_cs.c | 3 drivers/net/pcmcia/pcnet_cs.c | 3 drivers/net/pcmcia/xirc2ps_cs.c | 9 - drivers/net/seeq8005.c | 4 drivers/net/yellowfin.c | 4 11 files changed, 199 insertions(+), 247 deletions(-) through these ChangeSets: (03/08/31 1.1114) [netdrvr] fix skb_padto bugs introduced when skb_padto was introduced It seems that skb_padto security fixes in 2.4 and 2.5 trying to fix "CAN-2003-0001:Multiple ethernet NID device drivers do not pad frames with null bytes", do not put the skb_padto blocks in proper places in the 3c527, eth16i, fmv18x, seeq8005, yellowfin device drivers. In case a driver calls skb_padto(), it is possible that the space available in the original skb buffer tailroom is less than the space to pad. In this case, in short, the skb_padto() will create a new skb buffer, copy data from the original skb buffer to a new skb buffer, free the original buffer, and finally return the new buffer. If this happens to the aforementioned device drivers, they come to point to wrong data. And, for 3c527 and yellowfin, the drivers can unexpectedly double free the original skb buffers since they still point to the original skb buffers. The attached patch against 2.4.23pre1 fixes these issues. (03/08/31 1.1113) [netdrvr 8139too] remove useless board names The only thing that differentiated most of the entries in the board_info[] table and the board_t type was the vendor branding string for the board. This table is a pain to maintain, so we prefer to simply use "RTL8129" or "RTL8139". (03/08/31 1.1112) [netdrvr 8139too] fix and pci ids needed for SH platform a.k.a. Sega Broadband Adapter. (03/08/31 1.1111) [netdrvr pcmcia] support SIOC[GS]MII{PHY,REG} ioctls Updated drivers; 3c574_cs, axnet_cs, pcnet_cs, xirc2ps_cs Thanks to Komuro for pointing this out. (03/08/31 1.1110) [netdrvr 8139too] make features more persistent; fix PCI DAC mode * only set PCIDAC (64-bit PCI) bit in hardware if sizeof(dma_addr_t) > 32. Need a better test for whether 64-bit mode is _really_ needed. * cache chip command register in private struct. this allows the setting of rx-vlan, rx-csum, and other features to be persistent across the entire lifetime of the net device. * remove dead private struct members frag_skb, dropping_frag, and pci_using_dac. (03/08/31 1.1109) [netdrvr 8139cp] stats improvements and fixes * make sure rx_frags is still accounted * query RxMissed register, and clear, upon each get-stats func call (03/08/30 1.1108) [netdrvr 8139cp] bump version (03/08/30 1.1107) [netdrvr 8139cp] fix NAPI bug; remove board_type distinction, not needed (03/08/30 1.1106) [netdrvr 8139cp] small cleanups * remove netif_queue_stopped test, netif_wake_queue already does that * move vlan stuff to top of file * remove __dev markers * update todo list at top of file * remove pci_set_dma_mask argument casts; ULL suffixes preferred. (03/08/30 1.1105) [netdrvr 8139cp] remove mentions of RTL8169 (now handled by "r8169") (03/08/30 1.1104) [netdrvr 8139cp] update todo list in header (03/08/30 1.1103) [netdrvr 8139cp] support NAPI on RX path; Ditch RX frag handling. NAPI is turned on unconditionally for the RX path. The hardware supports interrupt mitigation, so that should be investigated too. RX fragment handling removed. We simply ensure that we alloc buffers large enough to hold incoming packets. Any stray RX frags that occur (shouldn't be any) will be dropped. (03/08/30 1.1102) [netdrvr 8139cp] build TX checksumming code, but default OFF (previously it was ifdef'd) Also, bump version to 1.0. diff -Nru a/drivers/net/3c527.c b/drivers/net/3c527.c --- a/drivers/net/3c527.c Sun Aug 31 10:06:32 2003 +++ b/drivers/net/3c527.c Sun Aug 31 10:06:32 2003 @@ -1083,15 +1083,16 @@ /* NP is the buffer we will be loading */ np=lp->tx_ring[lp->tx_ring_head].p; - /* We will need this to flush the buffer out */ - lp->tx_ring[lp->tx_ring_head].skb=skb; - if(skb->len < ETH_ZLEN) { skb = skb_padto(skb, ETH_ZLEN); if(skb == NULL) goto out; } + + /* We will need this to flush the buffer out */ + lp->tx_ring[lp->tx_ring_head].skb=skb; + np->length = (skb->len < ETH_ZLEN) ? ETH_ZLEN : skb->len; np->data = virt_to_bus(skb->data); diff -Nru a/drivers/net/8139cp.c b/drivers/net/8139cp.c --- a/drivers/net/8139cp.c Sun Aug 31 10:06:32 2003 +++ b/drivers/net/8139cp.c Sun Aug 31 10:06:32 2003 @@ -24,13 +24,13 @@ PCI suspend/resume - Felipe Damasio LinkChg interrupt - Felipe Damasio - TODO, in rough priority order: + TODO: * Test Tx checksumming thoroughly - * dev->tx_timeout - * Constants (module parms?) for Rx work limit + * Implement dev->tx_timeout + + Low priority TODO: * Complete reset on PciErr * Consider Rx interrupt mitigation using TimerIntr - * Handle netif_rx return value * Investigate using skb->priority with h/w VLAN priority * Investigate using High Priority Tx Queue with skb->priority * Adjust Rx FIFO threshold and Max Rx DMA burst on Rx FIFO error @@ -39,13 +39,17 @@ Tx descriptor bit * The real minimum of CP_MIN_MTU is 4 bytes. However, for this to be supported, one must(?) turn on packet padding. - * Support external MII transceivers + * Support external MII transceivers (patch available) + + NOTES: + * TX checksumming is considered experimental. It is off by + default, use ethtool to turn it on. */ #define DRV_NAME "8139cp" -#define DRV_VERSION "0.5" -#define DRV_RELDATE "Aug 26, 2003" +#define DRV_VERSION "1.1" +#define DRV_RELDATE "Aug 30, 2003" #include @@ -68,9 +72,6 @@ #include #include -/* experimental TX checksumming feature enable/disable */ -#undef CP_TX_CHECKSUM - /* VLAN tagging feature enable/disable */ #if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE) #define CP_VLAN_TAG_USED 1 @@ -83,7 +84,7 @@ #endif /* These identify the driver base version and may not be removed. */ -static char version[] __devinitdata = +static char version[] = KERN_INFO DRV_NAME ": 10/100 PCI Ethernet driver v" DRV_VERSION " (" DRV_RELDATE ")\n"; MODULE_AUTHOR("Jeff Garzik "); @@ -157,6 +158,7 @@ TxConfig = 0x40, /* Tx configuration */ ChipVersion = 0x43, /* 8-bit chip version, inside TxConfig */ RxConfig = 0x44, /* Rx configuration */ + RxMissed = 0x4C, /* 24 bits valid, write clears */ Cfg9346 = 0x50, /* EEPROM select/control; Cfg reg [un]lock */ Config1 = 0x52, /* Config1 */ Config3 = 0x59, /* Config3 */ @@ -289,12 +291,11 @@ UWF = (1 << 4), /* Accept Unicast wakeup frame */ LANWake = (1 << 1), /* Enable LANWake signal */ PMEStatus = (1 << 0), /* PME status can be reset by PCI RST# */ -}; -static const unsigned int cp_intr_mask = - PciErr | LinkChg | - RxOK | RxErr | RxEmpty | RxFIFOOvr | - TxOK | TxErr | TxEmpty; + cp_norx_intr_mask = PciErr | LinkChg | TxOK | TxErr | TxEmpty, + cp_rx_intr_mask = RxOK | RxErr | RxEmpty | RxFIFOOvr, + cp_intr_mask = cp_rx_intr_mask | cp_norx_intr_mask, +}; static const unsigned int cp_rx_config = (RX_FIFO_THRESH << RxCfgFIFOShift) | @@ -361,11 +362,7 @@ struct pci_dev *pdev; u32 rx_config; - - struct sk_buff *frag_skb; - unsigned dropping_frag : 1; - unsigned pci_using_dac : 1; - unsigned int board_type; + u16 cpcmd; unsigned int wol_enabled : 1; /* Is Wake-on-LAN enabled? */ u32 power_state[16]; @@ -397,28 +394,9 @@ static void cp_tx (struct cp_private *cp); static void cp_clean_rings (struct cp_private *cp); -enum board_type { - RTL8139Cp, - RTL8169, -}; - -static struct cp_board_info { - const char *name; -} cp_board_tbl[] __devinitdata = { - /* RTL8139Cp */ - { "RTL-8139C+" }, - - /* RTL8169 */ - { "RTL-8169" }, -}; - static struct pci_device_id cp_pci_tbl[] = { { PCI_VENDOR_ID_REALTEK, PCI_DEVICE_ID_REALTEK_8139, - PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139Cp }, -#if 0 - { PCI_VENDOR_ID_REALTEK, PCI_DEVICE_ID_REALTEK_8169, - PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8169 }, -#endif + PCI_ANY_ID, PCI_ANY_ID, 0, 0, }, { }, }; MODULE_DEVICE_TABLE(pci, cp_pci_tbl); @@ -443,6 +421,31 @@ }; +#if CP_VLAN_TAG_USED +static void cp_vlan_rx_register(struct net_device *dev, struct vlan_group *grp) +{ + struct cp_private *cp = dev->priv; + + spin_lock_irq(&cp->lock); + cp->vlgrp = grp; + cp->cpcmd |= RxVlanOn; + cpw16(CpCmd, cp->cpcmd); + spin_unlock_irq(&cp->lock); +} + +static void cp_vlan_rx_kill_vid(struct net_device *dev, unsigned short vid) +{ + struct cp_private *cp = dev->priv; + + spin_lock_irq(&cp->lock); + cp->cpcmd &= ~RxVlanOn; + cpw16(CpCmd, cp->cpcmd); + if (cp->vlgrp) + cp->vlgrp->vlan_devices[vid] = NULL; + spin_unlock_irq(&cp->lock); +} +#endif /* CP_VLAN_TAG_USED */ + static inline void cp_set_rxbufsize (struct cp_private *cp) { unsigned int mtu = cp->dev->mtu; @@ -468,7 +471,7 @@ vlan_hwaccel_rx(skb, cp->vlgrp, be16_to_cpu(desc->opts2 & 0xffff)); } else #endif - netif_rx(skb); + netif_receive_skb(skb); } static void cp_rx_err_acct (struct cp_private *cp, unsigned rx_tail, @@ -483,81 +486,14 @@ cp->net_stats.rx_frame_errors++; if (status & RxErrCRC) cp->net_stats.rx_crc_errors++; - if (status & RxErrRunt) + if ((status & RxErrRunt) || (status & RxErrLong)) cp->net_stats.rx_length_errors++; - if (status & RxErrLong) + if ((status & (FirstFrag | LastFrag)) != (FirstFrag | LastFrag)) cp->net_stats.rx_length_errors++; if (status & RxErrFIFO) cp->net_stats.rx_fifo_errors++; } -static void cp_rx_frag (struct cp_private *cp, unsigned rx_tail, - struct sk_buff *skb, u32 status, u32 len) -{ - struct sk_buff *copy_skb, *frag_skb = cp->frag_skb; - unsigned orig_len = frag_skb ? frag_skb->len : 0; - unsigned target_len = orig_len + len; - unsigned first_frag = status & FirstFrag; - unsigned last_frag = status & LastFrag; - - if (netif_msg_rx_status (cp)) - printk (KERN_DEBUG "%s: rx %s%sfrag, slot %d status 0x%x len %d\n", - cp->dev->name, - cp->dropping_frag ? "dropping " : "", - first_frag ? "first " : - last_frag ? "last " : "", - rx_tail, status, len); - - cp->cp_stats.rx_frags++; - - if (!frag_skb && !first_frag) - cp->dropping_frag = 1; - if (cp->dropping_frag) - goto drop_frag; - - copy_skb = dev_alloc_skb (target_len + RX_OFFSET); - if (!copy_skb) { - printk(KERN_WARNING "%s: rx slot %d alloc failed\n", - cp->dev->name, rx_tail); - - cp->dropping_frag = 1; -drop_frag: - if (frag_skb) { - dev_kfree_skb_irq(frag_skb); - cp->frag_skb = NULL; - } - if (last_frag) { - cp->net_stats.rx_dropped++; - cp->dropping_frag = 0; - } - return; - } - - copy_skb->dev = cp->dev; - skb_reserve(copy_skb, RX_OFFSET); - skb_put(copy_skb, target_len); - if (frag_skb) { - memcpy(copy_skb->data, frag_skb->data, orig_len); - dev_kfree_skb_irq(frag_skb); - } - pci_dma_sync_single(cp->pdev, cp->rx_skb[rx_tail].mapping, - len, PCI_DMA_FROMDEVICE); - memcpy(copy_skb->data + orig_len, skb->data, len); - - copy_skb->ip_summed = CHECKSUM_NONE; - - if (last_frag) { - if (status & (RxError | RxErrFIFO)) { - cp_rx_err_acct(cp, rx_tail, status, len); - dev_kfree_skb_irq(copy_skb); - } else - cp_rx_skb(cp, copy_skb, &cp->rx_ring[rx_tail]); - cp->frag_skb = NULL; - } else { - cp->frag_skb = copy_skb; - } -} - static inline unsigned int cp_rx_csum_ok (u32 status) { unsigned int protocol = (status >> 16) & 0x3; @@ -571,12 +507,18 @@ return 0; } -static void cp_rx (struct cp_private *cp) +static int cp_rx_poll (struct net_device *dev, int *budget) { + struct cp_private *cp = dev->priv; unsigned rx_tail = cp->rx_tail; - unsigned rx_work = 100; + unsigned rx_work = dev->quota; + unsigned rx; - while (rx_work--) { +rx_status_loop: + rx = 0; + cpw16(IntrStatus, cp_rx_intr_mask); + + while (1) { u32 status, len; dma_addr_t mapping; struct sk_buff *skb, *new_skb; @@ -596,7 +538,14 @@ mapping = cp->rx_skb[rx_tail].mapping; if ((status & (FirstFrag | LastFrag)) != (FirstFrag | LastFrag)) { - cp_rx_frag(cp, rx_tail, skb, status, len); + /* we don't support incoming fragmented frames. + * instead, we attempt to ensure that the + * pre-allocated RX skbs are properly sized such + * that RX fragments are never encountered + */ + cp_rx_err_acct(cp, rx_tail, status, len); + cp->net_stats.rx_dropped++; + cp->cp_stats.rx_frags++; goto rx_next; } @@ -637,6 +586,7 @@ cp->rx_skb[rx_tail].skb = new_skb; cp_rx_skb(cp, skb, desc); + rx++; rx_next: cp->rx_ring[rx_tail].opts2 = 0; @@ -647,12 +597,30 @@ else desc->opts1 = cpu_to_le32(DescOwn | cp->rx_buf_sz); rx_tail = NEXT_RX(rx_tail); - } - if (!rx_work) - printk(KERN_WARNING "%s: rx work limit reached\n", cp->dev->name); + if (!rx_work--) + break; + } cp->rx_tail = rx_tail; + + dev->quota -= rx; + *budget -= rx; + + /* if we did not reach work limit, then we're done with + * this round of polling + */ + if (rx_work) { + if (cpr16(IntrStatus) & cp_rx_intr_mask) + goto rx_status_loop; + + cpw16_f(IntrMask, cp_intr_mask); + netif_rx_complete(dev); + + return 0; /* done */ + } + + return 1; /* not done */ } static irqreturn_t @@ -670,12 +638,16 @@ printk(KERN_DEBUG "%s: intr, status %04x cmd %02x cpcmd %04x\n", dev->name, status, cpr8(Cmd), cpr16(CpCmd)); - cpw16_f(IntrStatus, status); + cpw16(IntrStatus, status & ~cp_rx_intr_mask); spin_lock(&cp->lock); - if (status & (RxOK | RxErr | RxEmpty | RxFIFOOvr)) - cp_rx(cp); + if (status & (RxOK | RxErr | RxEmpty | RxFIFOOvr)) { + if (netif_rx_schedule_prep(dev)) { + cpw16_f(IntrMask, cp_norx_intr_mask); + __netif_rx_schedule(dev); + } + } if (status & (TxOK | TxErr | TxEmpty | SWInt)) cp_tx(cp); if (status & LinkChg) @@ -688,6 +660,8 @@ pci_write_config_word(cp->pdev, PCI_STATUS, pci_status); printk(KERN_ERR "%s: PCI bus error, status=%04x, PCI status=%04x\n", dev->name, status, pci_status); + + /* TODO: reset hardware */ } spin_unlock(&cp->lock); @@ -747,7 +721,7 @@ cp->tx_tail = tx_tail; - if (netif_queue_stopped(cp->dev) && (TX_BUFFS_AVAIL(cp) > (MAX_SKB_FRAGS + 1))) + if (TX_BUFFS_AVAIL(cp) > (MAX_SKB_FRAGS + 1)) netif_wake_queue(cp->dev); } @@ -789,7 +763,6 @@ txd->addr = cpu_to_le64(mapping); wmb(); -#ifdef CP_TX_CHECKSUM if (skb->ip_summed == CHECKSUM_HW) { const struct iphdr *ip = skb->nh.iph; if (ip->protocol == IPPROTO_TCP) @@ -803,7 +776,6 @@ else BUG(); } else -#endif txd->opts1 = cpu_to_le32(eor | len | DescOwn | FirstFrag | LastFrag); wmb(); @@ -817,9 +789,7 @@ u32 first_len, first_eor; dma_addr_t first_mapping; int frag, first_entry = entry; -#ifdef CP_TX_CHECKSUM const struct iphdr *ip = skb->nh.iph; -#endif /* We must give this initial chunk to the device last. * Otherwise we could race with the device. @@ -845,7 +815,7 @@ this_frag->page_offset), len, PCI_DMA_TODEVICE); eor = (entry == (CP_TX_RING_SIZE - 1)) ? RingEnd : 0; -#ifdef CP_TX_CHECKSUM + if (skb->ip_summed == CHECKSUM_HW) { ctrl = eor | len | DescOwn | IPCS; if (ip->protocol == IPPROTO_TCP) @@ -855,7 +825,6 @@ else BUG(); } else -#endif ctrl = eor | len | DescOwn; if (frag == skb_shinfo(skb)->nr_frags - 1) @@ -880,7 +849,6 @@ txd->addr = cpu_to_le64(first_mapping); wmb(); -#ifdef CP_TX_CHECKSUM if (skb->ip_summed == CHECKSUM_HW) { if (ip->protocol == IPPROTO_TCP) txd->opts1 = cpu_to_le32(first_eor | first_len | @@ -893,7 +861,6 @@ else BUG(); } else -#endif txd->opts1 = cpu_to_le32(first_eor | first_len | FirstFrag | DescOwn); wmb(); @@ -972,7 +939,9 @@ static void __cp_get_stats(struct cp_private *cp) { - /* XXX implement */ + /* only lower 24 bits valid; write any value to clear */ + cp->net_stats.rx_missed_errors += (cpr32 (RxMissed) & 0xffffff); + cpw32 (RxMissed, 0); } static struct net_device_stats *cp_get_stats(struct net_device *dev) @@ -992,11 +961,10 @@ { struct net_device *dev = cp->dev; - cpw16(IntrMask, 0); - cpr16(IntrMask); + cpw16(IntrStatus, ~(cpr16(IntrStatus))); + cpw16_f(IntrMask, 0); cpw8(Cmd, 0); - cpw16(CpCmd, 0); - cpr16(CpCmd); + cpw16_f(CpCmd, 0); cpw16(IntrStatus, ~(cpr16(IntrStatus))); synchronize_irq(); udelay(10); @@ -1028,11 +996,7 @@ static inline void cp_start_hw (struct cp_private *cp) { - u16 pci_dac = cp->pci_using_dac ? PCIDAC : 0; - if (cp->board_type == RTL8169) - cpw16(CpCmd, pci_dac | PCIMulRW | RxChkSum); - else - cpw16(CpCmd, pci_dac | PCIMulRW | RxChkSum | CpRxOn | CpTxOn); + cpw16(CpCmd, cp->cpcmd); cpw8(Cmd, RxOn | TxOn); } @@ -1056,13 +1020,10 @@ cpw8(Config1, cpr8(Config1) | DriverLoaded | PMEnable); /* Disable Wake-on-LAN. Can be turned on with ETHTOOL_SWOL */ - if (cp->board_type == RTL8139Cp) { - cpw8(Config3, PARMEnable); - cp->wol_enabled = 0; - } + cpw8(Config3, PARMEnable); + cp->wol_enabled = 0; + cpw8(Config5, cpr8(Config5) & PMEStatus); - if (cp->board_type == RTL8169) - cpw16(RxMaxSize, cp->rx_buf_sz); cpw32_f(HiTxRingAddr, 0); cpw32_f(HiTxRingAddr + 4, 0); @@ -1255,8 +1216,6 @@ dev->mtu = new_mtu; cp_set_rxbufsize(cp); /* set new rx buf size */ - if (cp->board_type == RTL8169) - cpw16(RxMaxSize, cp->rx_buf_sz); rc = cp_init_rings(cp); /* realloc and restart h/w */ cp_start_hw(cp); @@ -1426,7 +1385,7 @@ static int cp_set_rx_csum(struct net_device *dev, u32 data) { struct cp_private *cp = dev->priv; - u16 cmd = cpr16(CpCmd), newcmd; + u16 cmd = cp->cpcmd, newcmd; newcmd = cmd; @@ -1437,6 +1396,7 @@ if (newcmd != cmd) { spin_lock_irq(&cp->lock); + cp->cpcmd = newcmd; cpw16_f(CpCmd, newcmd); spin_unlock_irq(&cp->lock); } @@ -1581,29 +1541,6 @@ return rc; } -#if CP_VLAN_TAG_USED -static void cp_vlan_rx_register(struct net_device *dev, struct vlan_group *grp) -{ - struct cp_private *cp = dev->priv; - - spin_lock_irq(&cp->lock); - cp->vlgrp = grp; - cpw16(CpCmd, cpr16(CpCmd) | RxVlanOn); - spin_unlock_irq(&cp->lock); -} - -static void cp_vlan_rx_kill_vid(struct net_device *dev, unsigned short vid) -{ - struct cp_private *cp = dev->priv; - - spin_lock_irq(&cp->lock); - cpw16(CpCmd, cpr16(CpCmd) & ~RxVlanOn); - if (cp->vlgrp) - cp->vlgrp->vlan_devices[vid] = NULL; - spin_unlock_irq(&cp->lock); -} -#endif - /* Serial EEPROM section. */ /* EEPROM_Ctrl bits. */ @@ -1626,7 +1563,7 @@ #define EE_READ_CMD (6) #define EE_ERASE_CMD (7) -static int __devinit read_eeprom (void *ioaddr, int location, int addr_len) +static int read_eeprom (void *ioaddr, int location, int addr_len) { int i; unsigned retval = 0; @@ -1672,17 +1609,15 @@ pci_set_power_state (cp->pdev, 3); } -static int __devinit cp_init_one (struct pci_dev *pdev, - const struct pci_device_id *ent) +static int cp_init_one (struct pci_dev *pdev, const struct pci_device_id *ent) { struct net_device *dev; struct cp_private *cp; int rc; void *regs; long pciaddr; - unsigned int addr_len, i; + unsigned int addr_len, i, pci_using_dac; u8 pci_rev, cache_size; - unsigned int board_type = (unsigned int) ent->driver_data; #ifndef MODULE static int version_printed; @@ -1706,7 +1641,6 @@ SET_MODULE_OWNER(dev); cp = dev->priv; cp->pdev = pdev; - cp->board_type = board_type; cp->dev = dev; cp->msg_enable = (debug < 0 ? CP_DEF_MSG_ENABLE : debug); spin_lock_init (&cp->lock); @@ -1747,18 +1681,22 @@ } /* Configure DMA attributes. */ - if (!pci_set_dma_mask(pdev, (u64) 0xffffffffffffffffULL)) { - cp->pci_using_dac = 1; + if ((sizeof(dma_addr_t) > 32) && + !pci_set_dma_mask(pdev, 0xffffffffffffffffULL)) { + pci_using_dac = 1; } else { - rc = pci_set_dma_mask(pdev, (u64) 0xffffffff); + rc = pci_set_dma_mask(pdev, 0xffffffffULL); if (rc) { printk(KERN_ERR PFX "No usable DMA configuration, " "aborting.\n"); goto err_out_res; } - cp->pci_using_dac = 0; + pci_using_dac = 0; } + cp->cpcmd = (pci_using_dac ? PCIDAC : 0) | + PCIMulRW | RxChkSum | CpRxOn | CpTxOn; + regs = ioremap_nocache(pciaddr, CP_REGS_SIZE); if (!regs) { rc = -EIO; @@ -1783,6 +1721,8 @@ dev->hard_start_xmit = cp_start_xmit; dev->get_stats = cp_get_stats; dev->do_ioctl = cp_ioctl; + dev->poll = cp_rx_poll; + dev->weight = 16; /* arbitrary? from NAPI_HOWTO.txt. */ #ifdef BROKEN dev->change_mtu = cp_change_mtu; #endif @@ -1791,9 +1731,7 @@ dev->tx_timeout = cp_tx_timeout; dev->watchdog_timeo = TX_TIMEOUT; #endif -#ifdef CP_TX_CHECKSUM - dev->features |= NETIF_F_SG | NETIF_F_IP_CSUM; -#endif + #if CP_VLAN_TAG_USED dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX; dev->vlan_rx_register = cp_vlan_rx_register; @@ -1806,11 +1744,10 @@ if (rc) goto err_out_iomap; - printk (KERN_INFO "%s: %s at 0x%lx, " + printk (KERN_INFO "%s: RTL-8139C+ at 0x%lx, " "%02x:%02x:%02x:%02x:%02x:%02x, " "IRQ %d\n", dev->name, - cp_board_tbl[board_type].name, dev->base_addr, dev->dev_addr[0], dev->dev_addr[1], dev->dev_addr[2], dev->dev_addr[3], @@ -1858,7 +1795,7 @@ return rc; } -static void __devexit cp_remove_one (struct pci_dev *pdev) +static void cp_remove_one (struct pci_dev *pdev) { struct net_device *dev = pci_get_drvdata(pdev); struct cp_private *cp = dev->priv; @@ -1931,7 +1868,7 @@ .name = DRV_NAME, .id_table = cp_pci_tbl, .probe = cp_init_one, - .remove = __devexit_p(cp_remove_one), + .remove = cp_remove_one, #ifdef CONFIG_PM .resume = cp_resume, .suspend = cp_suspend, diff -Nru a/drivers/net/8139too.c b/drivers/net/8139too.c --- a/drivers/net/8139too.c Sun Aug 31 10:06:32 2003 +++ b/drivers/net/8139too.c Sun Aug 31 10:06:32 2003 @@ -122,6 +122,11 @@ #define USE_IO_OPS 1 #endif +/* use a 16K rx ring buffer instead of the default 32K */ +#ifdef CONFIG_SH_DREAMCAST +#define USE_BUF16K 1 +#endif + /* define to 1 to enable copious debugging info */ #undef RTL8139_DEBUG @@ -164,7 +169,11 @@ static int debug = -1; /* Size of the in-memory receive ring. */ +#ifdef USE_BUF16K +#define RX_BUF_LEN_IDX 1 /* 0==8K, 1==16K, 2==32K, 3==64K */ +#else #define RX_BUF_LEN_IDX 2 /* 0==8K, 1==16K, 2==32K, 3==64K */ +#endif #define RX_BUF_LEN (8192 << RX_BUF_LEN_IDX) #define RX_BUF_PAD 16 #define RX_BUF_WRAP_PAD 2048 /* spare padding to handle lack of packet wrap */ @@ -211,18 +220,7 @@ typedef enum { RTL8139 = 0, - RTL8139_CB, - SMC1211TX, - /*MPX5030,*/ - DELTA8139, - ADDTRON8139, - DFE538TX, - DFE690TXD, - FE2000VX, - ALLIED8139, RTL8129, - FNW3603TX, - FNW3800TX, } board_t; @@ -231,36 +229,29 @@ const char *name; u32 hw_flags; } board_info[] __devinitdata = { - { "RealTek RTL8139 Fast Ethernet", RTL8139_CAPS }, - { "RealTek RTL8139B PCI/CardBus", RTL8139_CAPS }, - { "SMC1211TX EZCard 10/100 (RealTek RTL8139)", RTL8139_CAPS }, -/* { MPX5030, "Accton MPX5030 (RealTek RTL8139)", RTL8139_CAPS },*/ - { "Delta Electronics 8139 10/100BaseTX", RTL8139_CAPS }, - { "Addtron Technolgy 8139 10/100BaseTX", RTL8139_CAPS }, - { "D-Link DFE-538TX (RealTek RTL8139)", RTL8139_CAPS }, - { "D-Link DFE-690TXD (RealTek RTL8139)", RTL8139_CAPS }, - { "AboCom FE2000VX (RealTek RTL8139)", RTL8139_CAPS }, - { "Allied Telesyn 8139 CardBus", RTL8139_CAPS }, + { "RealTek RTL8139", RTL8139_CAPS }, { "RealTek RTL8129", RTL8129_CAPS }, - { "Planex FNW-3603-TX 10/100 CardBus", RTL8139_CAPS }, - { "Planex FNW-3800-TX 10/100 CardBus", RTL8139_CAPS }, }; static struct pci_device_id rtl8139_pci_tbl[] = { {0x10ec, 0x8139, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 }, - {0x10ec, 0x8138, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139_CB }, - {0x1113, 0x1211, PCI_ANY_ID, PCI_ANY_ID, 0, 0, SMC1211TX }, -/* {0x1113, 0x1211, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MPX5030 },*/ - {0x1500, 0x1360, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DELTA8139 }, - {0x4033, 0x1360, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ADDTRON8139 }, - {0x1186, 0x1300, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DFE538TX }, - {0x1186, 0x1340, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DFE690TXD }, - {0x13d1, 0xab06, PCI_ANY_ID, PCI_ANY_ID, 0, 0, FE2000VX }, - {0x1259, 0xa117, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ALLIED8139 }, - {0x14ea, 0xab06, PCI_ANY_ID, PCI_ANY_ID, 0, 0, FNW3603TX }, - {0x14ea, 0xab07, PCI_ANY_ID, PCI_ANY_ID, 0, 0, FNW3800TX }, - + {0x10ec, 0x8138, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 }, + {0x1113, 0x1211, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 }, + {0x1500, 0x1360, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 }, + {0x4033, 0x1360, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 }, + {0x1186, 0x1300, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 }, + {0x1186, 0x1340, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 }, + {0x13d1, 0xab06, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 }, + {0x1259, 0xa117, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 }, + {0x14ea, 0xab06, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 }, + {0x14ea, 0xab07, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 }, + {0x11db, 0x1234, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 }, + +#ifdef CONFIG_SH_SECUREEDGE5410 + /* Bogus 8139 silicon reports 8129 without external PROM :-( */ + {0x10ec, 0x8129, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 }, +#endif #ifdef CONFIG_8139TOO_8129 {0x10ec, 0x8129, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8129 }, #endif @@ -270,8 +261,8 @@ * so we simply don't match on the main vendor id. */ {PCI_ANY_ID, 0x8139, 0x10ec, 0x8139, 0, 0, RTL8139 }, - {PCI_ANY_ID, 0x8139, 0x1186, 0x1300, 0, 0, DFE538TX }, - {PCI_ANY_ID, 0x8139, 0x13d1, 0xab06, 0, 0, FE2000VX }, + {PCI_ANY_ID, 0x8139, 0x1186, 0x1300, 0, 0, RTL8139 }, + {PCI_ANY_ID, 0x8139, 0x13d1, 0xab06, 0, 0, RTL8139 }, {0,} }; @@ -706,10 +697,17 @@ PCIErr | PCSTimeout | RxUnderrun | RxOverflow | RxFIFOOver | TxErr | TxOK | RxErr | RxOK; +#ifdef USE_BUF16K +static const unsigned int rtl8139_rx_config = + RxCfgRcv16K | RxNoWrap | + (RX_FIFO_THRESH << RxCfgFIFOShift) | + (RX_DMA_BURST << RxCfgDMAShift); +#else static const unsigned int rtl8139_rx_config = RxCfgRcv32K | RxNoWrap | (RX_FIFO_THRESH << RxCfgFIFOShift) | (RX_DMA_BURST << RxCfgDMAShift); +#endif static const unsigned int rtl8139_tx_config = (TX_DMA_BURST << TxDMAShift) | (TX_RETRY << TxRetryShift); diff -Nru a/drivers/net/eth16i.c b/drivers/net/eth16i.c --- a/drivers/net/eth16i.c Sun Aug 31 10:06:32 2003 +++ b/drivers/net/eth16i.c Sun Aug 31 10:06:32 2003 @@ -1057,7 +1057,7 @@ int ioaddr = dev->base_addr; int status = 0; ushort length = skb->len; - unsigned char *buf = skb->data; + unsigned char *buf; unsigned long flags; if(length < ETH_ZLEN) @@ -1067,6 +1067,7 @@ return 0; length = ETH_ZLEN; } + buf = skb->data; netif_stop_queue(dev); diff -Nru a/drivers/net/fmv18x.c b/drivers/net/fmv18x.c --- a/drivers/net/fmv18x.c Sun Aug 31 10:06:32 2003 +++ b/drivers/net/fmv18x.c Sun Aug 31 10:06:32 2003 @@ -370,7 +370,7 @@ struct net_local *lp = dev->priv; int ioaddr = dev->base_addr; short length = skb->len; - unsigned char *buf = skb->data; + unsigned char *buf; unsigned long flags; /* Block a transmit from overlapping. */ @@ -389,6 +389,7 @@ return 0; length = ETH_ZLEN; } + buf = skb->data; if (net_debug > 4) printk("%s: Transmitting a packet of length %lu.\n", dev->name, diff -Nru a/drivers/net/pcmcia/3c574_cs.c b/drivers/net/pcmcia/3c574_cs.c --- a/drivers/net/pcmcia/3c574_cs.c Sun Aug 31 10:06:32 2003 +++ b/drivers/net/pcmcia/3c574_cs.c Sun Aug 31 10:06:32 2003 @@ -1216,9 +1216,11 @@ data[0], data[1], data[2], data[3]); switch(cmd) { - case SIOCDEVPRIVATE: /* Get the address of the PHY in use. */ + case SIOCGMIIPHY: /* Get the address of the PHY in use. */ + case SIOCDEVPRIVATE: data[0] = phy; - case SIOCDEVPRIVATE+1: /* Read the specified MII register. */ + case SIOCGMIIREG: /* Read the specified MII register. */ + case SIOCDEVPRIVATE+1: { int saved_window; unsigned long flags; @@ -1232,7 +1234,8 @@ restore_flags(flags); return 0; } - case SIOCDEVPRIVATE+2: /* Write the specified MII register */ + case SIOCSMIIREG: /* Write the specified MII register */ + case SIOCDEVPRIVATE+2: { int saved_window; unsigned long flags; diff -Nru a/drivers/net/pcmcia/axnet_cs.c b/drivers/net/pcmcia/axnet_cs.c --- a/drivers/net/pcmcia/axnet_cs.c Sun Aug 31 10:06:32 2003 +++ b/drivers/net/pcmcia/axnet_cs.c Sun Aug 31 10:06:32 2003 @@ -843,11 +843,14 @@ u16 *data = (u16 *)&rq->ifr_data; ioaddr_t mii_addr = dev->base_addr + AXNET_MII_EEP; switch (cmd) { + case SIOCGMIIPHY: case SIOCDEVPRIVATE: data[0] = info->phy_id; + case SIOCGMIIREG: /* Read MII PHY register. */ case SIOCDEVPRIVATE+1: data[3] = mdio_read(mii_addr, data[0], data[1] & 0x1f); return 0; + case SIOCSMIIREG: /* Write MII PHY register. */ case SIOCDEVPRIVATE+2: if (!capable(CAP_NET_ADMIN)) return -EPERM; diff -Nru a/drivers/net/pcmcia/pcnet_cs.c b/drivers/net/pcmcia/pcnet_cs.c --- a/drivers/net/pcmcia/pcnet_cs.c Sun Aug 31 10:06:32 2003 +++ b/drivers/net/pcmcia/pcnet_cs.c Sun Aug 31 10:06:32 2003 @@ -1236,11 +1236,14 @@ u16 *data = (u16 *)&rq->ifr_data; ioaddr_t mii_addr = dev->base_addr + DLINK_GPIO; switch (cmd) { + case SIOCGMIIPHY: case SIOCDEVPRIVATE: data[0] = info->phy_id; + case SIOCGMIIREG: /* Read MII PHY register. */ case SIOCDEVPRIVATE+1: data[3] = mdio_read(mii_addr, data[0], data[1] & 0x1f); return 0; + case SIOCSMIIREG: /* Write MII PHY register. */ case SIOCDEVPRIVATE+2: if (!capable(CAP_NET_ADMIN)) return -EPERM; diff -Nru a/drivers/net/pcmcia/xirc2ps_cs.c b/drivers/net/pcmcia/xirc2ps_cs.c --- a/drivers/net/pcmcia/xirc2ps_cs.c Sun Aug 31 10:06:32 2003 +++ b/drivers/net/pcmcia/xirc2ps_cs.c Sun Aug 31 10:06:32 2003 @@ -1749,13 +1749,16 @@ return -EOPNOTSUPP; switch(cmd) { - case SIOCDEVPRIVATE: /* Get the address of the PHY in use. */ + case SIOCGMIIPHY: /* Get the address of the PHY in use. */ + case SIOCDEVPRIVATE: data[0] = 0; /* we have only this address */ /* fall trough */ - case SIOCDEVPRIVATE+1: /* Read the specified MII register. */ + case SIOCGMIIREG: /* Read the specified MII register. */ + case SIOCDEVPRIVATE+1: data[3] = mii_rd(ioaddr, data[0] & 0x1f, data[1] & 0x1f); break; - case SIOCDEVPRIVATE+2: /* Write the specified MII register */ + case SIOCSMIIREG: /* Write the specified MII register */ + case SIOCDEVPRIVATE+2: if (!capable(CAP_NET_ADMIN)) return -EPERM; mii_wr(ioaddr, data[0] & 0x1f, data[1] & 0x1f, data[2], 16); diff -Nru a/drivers/net/seeq8005.c b/drivers/net/seeq8005.c --- a/drivers/net/seeq8005.c Sun Aug 31 10:06:32 2003 +++ b/drivers/net/seeq8005.c Sun Aug 31 10:06:32 2003 @@ -379,7 +379,7 @@ { struct net_local *lp = (struct net_local *)dev->priv; short length = skb->len; - unsigned char *buf = skb->data; + unsigned char *buf; if(length < ETH_ZLEN) { @@ -388,6 +388,8 @@ return 0; length = ETH_ZLEN; } + buf = skb->data; + /* Block a timer-based transmit from overlapping */ netif_stop_queue(dev); diff -Nru a/drivers/net/yellowfin.c b/drivers/net/yellowfin.c --- a/drivers/net/yellowfin.c Sun Aug 31 10:06:32 2003 +++ b/drivers/net/yellowfin.c Sun Aug 31 10:06:32 2003 @@ -867,8 +867,6 @@ /* Calculate the next Tx descriptor entry. */ entry = yp->cur_tx % TX_RING_SIZE; - yp->tx_skbuff[entry] = skb; - if (gx_fix) { /* Note: only works for paddable protocols e.g. IP. */ int cacheline_end = ((unsigned long)skb->data + skb->len) % 32; /* Fix GX chipset errata. */ @@ -885,6 +883,8 @@ return 0; } } + yp->tx_skbuff[entry] = skb; + #ifdef NO_TXSTATS yp->tx_ring[entry].addr = cpu_to_le32(pci_map_single(yp->pci_dev, skb->data, len, PCI_DMA_TODEVICE)); From dwmw2@redhat.com Sun Aug 31 07:56:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 31 Aug 2003 07:57:06 -0700 (PDT) Received: from imladris.demon.co.uk (imladris.demon.co.uk [193.237.130.41]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7VEuVWZ025898 for ; Sun, 31 Aug 2003 07:56:32 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=localhost) by imladris.demon.co.uk with esmtp (Exim 4.22) id 19tTcz-0000lm-QC for netdev@oss.sgi.com; Sun, 31 Aug 2003 15:56:29 +0100 Subject: Missing routes cause BUG() in icmpv6_xmit_lock(). From: David Woodhouse To: netdev@oss.sgi.com Content-Type: text/plain Organization: Red Hat UK Ltd. Message-Id: <1062341789.2785.11.camel@imladris.demon.co.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 (1.4.4-3.dwmw2.2) Date: Sun, 31 Aug 2003 15:56:29 +0100 Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: dwmw2@redhat.com X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-archive-position: 5440 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dwmw2@redhat.com Precedence: bulk X-list: netdev Kernel is Red Hat 2.4.21-20.1.2024.2.1.nptlsmp from the Severn beta. Triggered as follows: Configure 6to4 IPv6 address 2002:X:Y::1 on the ISDN dialup. Enable IPv6 forwarding on all interfaces Configure radvd to advertise 2002:X:Y:1234::/64 on internal eth0 device Observe radvd doesn't add any routes for the 2002:X:Y:1234::/64 subnet. Bring up an internal machine on eth0. Observe it receive an IPv6 address of the form 2002:X:Y:1234:..... Attempt to ping6 a machine in the outside world from the internal host. Observe that reply packets from the outside world to the internal address are routed straight back _out_ the 6to4 tunnel again, in the absence of sane routes -- with associated bitching... redirect: no link_local addr for dev Dead loop on virtual device tun6to4, fix it urgently! Attempt to ping6 the router 2002:X:Y::1 from internal host. Observe panic: http://www.linux.org.uk/~dwmw2/dcp_1575.jpg Should initscripts set up an unreachable route for 2002:X:Y::/48 when setting up a 6to4 tunnel? Should radvd set up routes to subnets of that network when advertising them internally according to its configuration? Certainly the kernel should do something other than panicking :) -- dwmw2 From Ronnie_vaisman@radwin.com Sun Aug 31 09:49:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 31 Aug 2003 09:50:11 -0700 (PDT) Received: from mx100.qos.net.il (mx100.qos.net.il [80.74.96.6]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7VGnYWZ010507 for ; Sun, 31 Aug 2003 09:49:35 -0700 Received: from check_mail.radwin.ltd.com (access.radwin.com [80.74.102.194]) by mx100.qos.net.il (8.11.6/8.11.6) with ESMTP id h7VGhNw05725 for ; Sun, 31 Aug 2003 19:43:23 +0300 Received: by check_mail.radwin.ltd.com with XWall v3.27 ; Sun, 31 Aug 2003 19:51:31 +0200 From: Ronnie Vaisman To: "netdev@oss.sgi.com" Subject: HI I am new to this list. Is this an active list? Date: Sun, 31 Aug 2003 19:46:48 +0200 X-Assembled-By: XWall v3.27 X-Mailer: Internet Mail Service (5.5.2653.19) Message-ID: <116CA223EAAED2119F050090272E3D7F063F88B5@EXCHANGE> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h7VGnYWZ010507 X-archive-position: 5441 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Ronnie_vaisman@radwin.com Precedence: bulk X-list: netdev HI I am new to this list. Is this an active list? Regards, Ronnie Vaisman RadWin LTD. 34 Habarzel st., Tel Aviv 69710 Israel +972-3-645-5403 (Direct) +972-3-765-7535(Fax) email Ronnie_Vaisman@radwin.com web ************************************************************************************************** Privacy Notice: The information contained in this transmittal, including any attachments hereto, are confidential and privileged, and intended solely for the specified addressee(s). If you are not the intended addressee, or if you receive this message by error, please notify the sender and delete this information from your computer. Moreover, the recipient(s) may not disclose, forward, or copy this e-mail or attachments, or any portion thereof, or permit the use of this information, by anyone not entitled to it, or in a way that may be damaging to the sender. ************************************************************************************************** From acme@conectiva.com.br Sun Aug 31 10:35:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 31 Aug 2003 10:36:10 -0700 (PDT) Received: from oops.kerneljanitors.org (1-124.ctame701-2.telepar.net.br [200.181.138.124]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7VHZZWZ026333 for ; Sun, 31 Aug 2003 10:35:36 -0700 Received: by oops.kerneljanitors.org (Postfix, from userid 523) id CDB6AC5DB; Sun, 31 Aug 2003 14:35:30 -0300 (BRT) Date: Sun, 31 Aug 2003 14:35:30 -0300 From: Arnaldo Carvalho de Melo To: Stephen Hemminger Cc: Arnaldo Carvalho de Melo , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] ipx - set socket owner field Message-ID: <20030831173530.GF29218@conectiva.com.br> References: <20030829113704.548a9af4.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030829113704.548a9af4.shemminger@osdl.org> X-Url: http://advogato.org/person/acme Organization: Conectiva S.A. User-Agent: Mutt/1.5.4i X-archive-position: 5442 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Em Fri, Aug 29, 2003 at 11:37:04AM -0700, Stephen Hemminger escreveu: > All sockets created by a protocol need to have owner field set > to prevent problems with orphaned sockets during module unload. > > Patch for 2.6.0-test4 > > diff -Nru a/net/ipx/af_ipx.c b/net/ipx/af_ipx.c > --- a/net/ipx/af_ipx.c Fri Aug 29 11:20:48 2003 > +++ b/net/ipx/af_ipx.c Fri Aug 29 11:20:48 2003 > @@ -1365,6 +1365,7 @@ > atomic_read(&ipx_sock_nr)); > #endif > sock_init_data(sock, sk); > + sk_set_owner(sk, THIS_MODULE); > sk->sk_no_check = 1; /* Checksum off by default */ > rc = 0; > out: Thanks Stephen, I'm having problems with my home network for the last week or so, so have been pretty much unresponsive, will be looking over all this and the appletalk test (yes, I haven't forgotten that one) as soon as possible. - Arnaldo From vnuorval@tcs.hut.fi Sun Aug 31 16:37:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 31 Aug 2003 16:38:21 -0700 (PDT) Received: from smtp-1.hut.fi (root@smtp-1.hut.fi [130.233.228.91]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7VNbjWZ022409 for ; Sun, 31 Aug 2003 16:37:46 -0700 Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by smtp-1.hut.fi (8.12.9/8.12.9) with ESMTP id h7VNbeQe013666; Mon, 1 Sep 2003 02:37:40 +0300 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 6EB958001A5; Mon, 1 Sep 2003 02:37:40 +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-6.4) with ESMTP id h7VNbe9s026270; Mon, 1 Sep 2003 02:37:40 +0300 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7VNbekA026266; Mon, 1 Sep 2003 02:37:40 +0300 Date: Mon, 1 Sep 2003 02:37:40 +0300 (EEST) From: Ville Nuorvala To: davem@redhat.com, Cc: netdev@oss.sgi.com Subject: [PATCH] IPv6: (2/5) Use free_netdev() as destructor in ip6_tunnel.c In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-1.hut.fi) X-DCC-HUTCC-Metrics: smtp-1.hut.fi 1165; Body=4 Fuz1=4 Fuz2=4 X-archive-position: 5444 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Hi, this patch sets free_netdev() as the destructor for ip6_tnl dev. Please apply! Thanks, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From vnuorval@tcs.hut.fi Sun Aug 31 16:35:09 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 31 Aug 2003 16:35:44 -0700 (PDT) Received: from smtp-1.hut.fi (root@smtp-1.hut.fi [130.233.228.91]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7VNZ8WZ021740 for ; Sun, 31 Aug 2003 16:35:09 -0700 Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by smtp-1.hut.fi (8.12.9/8.12.9) with ESMTP id h7VNYvQe012434; Mon, 1 Sep 2003 02:34:58 +0300 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id A3D8E8001A5; Mon, 1 Sep 2003 02:34:57 +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-6.4) with ESMTP id h7VNYv9s026260; Mon, 1 Sep 2003 02:34:57 +0300 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7VNYtiG026256; Mon, 1 Sep 2003 02:34:55 +0300 Date: Mon, 1 Sep 2003 02:34:55 +0300 (EEST) From: Ville Nuorvala To: davem@redhat.com, Cc: netdev@oss.sgi.com Subject: [PATCH] IPv6: (1/5) Fix bugs in ip6_tunnel.c ICMP error handler Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-377318441-713958419-1062372895=:26242" X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-1.hut.fi) X-DCC-HUTCC-Metrics: smtp-1.hut.fi 1165; Body=4 Fuz1=4 Fuz2=4 X-archive-position: 5443 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---377318441-713958419-1062372895=:26242 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, this patch fixes two byte order bugs in ip6ip6_err(). Please apply! Thanks, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 ---377318441-713958419-1062372895=:26242 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="ip6_tnl_icmp_err.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="ip6_tnl_icmp_err.patch" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBwYXRjaCBmb3IgdGhl IGZvbGxvd2luZyBwcm9qZWN0Og0KIyBQcm9qZWN0IE5hbWU6IExpbnV4IGtl cm5lbCB0cmVlDQojIFRoaXMgcGF0Y2ggZm9ybWF0IGlzIGludGVuZGVkIGZv ciBHTlUgcGF0Y2ggY29tbWFuZCB2ZXJzaW9uIDIuNSBvciBoaWdoZXIuDQoj IFRoaXMgcGF0Y2ggaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBkZWx0YXM6DQoj CSAgICAgICAgICAgQ2hhbmdlU2V0CTEuMTI3Ni4xLjE1IC0+IDEuMTI3Ni4y OC4xDQojCW5ldC9pcHY2L2lwNl90dW5uZWwuYwkxLjYgICAgIC0+IDEuNyAg ICANCiMNCiMgVGhlIGZvbGxvd2luZyBpcyB0aGUgQml0S2VlcGVyIENoYW5n ZVNldCBMb2cNCiMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCiMgMDMvMDkvMDEJdm51b3J2YWxAZHNsLWhraWd3MWE4 Yi5kaWFsLmluZXQuZmkJMS4xMjc2LjI4LjENCiMgRml4IGJ5dGUgb3JkZXIg b2YgaW5mbyBwYXJhbWV0ZXIgaW4gaXA2aXA2X2VycigpDQojIC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQojDQpkaWZm IC1OcnUgYS9uZXQvaXB2Ni9pcDZfdHVubmVsLmMgYi9uZXQvaXB2Ni9pcDZf dHVubmVsLmMNCi0tLSBhL25ldC9pcHY2L2lwNl90dW5uZWwuYwlNb24gU2Vw ICAxIDAyOjAyOjU5IDIwMDMNCisrKyBiL25ldC9pcHY2L2lwNl90dW5uZWwu YwlNb24gU2VwICAxIDAyOjAyOjU5IDIwMDMNCkBAIC00MjEsNyArNDIxLDcg QEANCiAJCX0NCiAJCXRlbGkgPSBwYXJzZV90bHZfdG5sX2VuY19saW0oc2ti LCBza2ItPmRhdGEpOw0KIA0KLQkJaWYgKHRlbGkgJiYgdGVsaSA9PSBpbmZv IC0gMikgew0KKwkJaWYgKHRlbGkgJiYgdGVsaSA9PSBudG9obChpbmZvKSAt IDIpIHsNCiAJCQl0ZWwgPSAoc3RydWN0IGlwdjZfdGx2X3RubF9lbmNfbGlt ICopICZza2ItPmRhdGFbdGVsaV07DQogCQkJaWYgKHRlbC0+ZW5jYXBfbGlt aXQgPT0gMCkgew0KIAkJCQlpZiAobmV0X3JhdGVsaW1pdCgpKQ0KQEAgLTQz NCwxMCArNDM0LDkgQEANCiAJCX0NCiAJCWJyZWFrOw0KIAljYXNlIElDTVBW Nl9QS1RfVE9PQklHOg0KLQkJbXR1ID0gaW5mbyAtIG9mZnNldDsNCi0JCWlm IChtdHUgPD0gSVBWNl9NSU5fTVRVKSB7DQorCQltdHUgPSBudG9obChpbmZv KSAtIG9mZnNldDsNCisJCWlmIChtdHUgPCBJUFY2X01JTl9NVFUpDQogCQkJ bXR1ID0gSVBWNl9NSU5fTVRVOw0KLQkJfQ0KIAkJdC0+ZGV2LT5tdHUgPSBt dHU7DQogDQogCQlpZiAoKGxlbiA9IHNpemVvZiAoKmlwdjZoKSArIGlwdjZo LT5wYXlsb2FkX2xlbikgPiBtdHUpIHsNCg== ---377318441-713958419-1062372895=:26242-- From vnuorval@tcs.hut.fi Sun Aug 31 16:46:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 31 Aug 2003 16:47:27 -0700 (PDT) Received: from smtp-4.hut.fi (root@smtp-4.hut.fi [130.233.228.94]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7VNkpWZ023518 for ; Sun, 31 Aug 2003 16:46:52 -0700 Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by smtp-4.hut.fi (8.12.9/8.12.9) with ESMTP id h7VNkkgL029760; Mon, 1 Sep 2003 02:46:46 +0300 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 085E88001A5; Mon, 1 Sep 2003 02:46:46 +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-6.4) with ESMTP id h7VNkj9s026296; Mon, 1 Sep 2003 02:46:45 +0300 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7VNkj5K026292; Mon, 1 Sep 2003 02:46:45 +0300 Date: Mon, 1 Sep 2003 02:46:45 +0300 (EEST) From: Ville Nuorvala To: davem@redhat.com, Cc: netdev@oss.sgi.com Subject: Re: [PATCH] IPv6: (2/5) Use free_netdev() as destructor in ip6_tunnel.c In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-377318441-1258061687-1062373605=:26242" X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-4.hut.fi) X-DCC-HUTCC-Metrics: smtp-4.hut.fi 1165; Body=4 Fuz1=4 Fuz2=4 X-archive-position: 5445 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---377318441-1258061687-1062373605=:26242 Content-Type: TEXT/PLAIN; charset=US-ASCII Oops, forgot to attach the patch in the original mail... Sorry about that, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 ---377318441-1258061687-1062373605=:26242 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="ip6_tnl_free_netdev.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="ip6_tnl_free_netdev.patch" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBwYXRjaCBmb3IgdGhl IGZvbGxvd2luZyBwcm9qZWN0Og0KIyBQcm9qZWN0IE5hbWU6IExpbnV4IGtl cm5lbCB0cmVlDQojIFRoaXMgcGF0Y2ggZm9ybWF0IGlzIGludGVuZGVkIGZv ciBHTlUgcGF0Y2ggY29tbWFuZCB2ZXJzaW9uIDIuNSBvciBoaWdoZXIuDQoj IFRoaXMgcGF0Y2ggaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBkZWx0YXM6DQoj CSAgICAgICAgICAgQ2hhbmdlU2V0CTEuMTI3Ni4yOC4xIC0+IDEuMTI3Ni4y OC4yDQojCW5ldC9pcHY2L2lwNl90dW5uZWwuYwkxLjcgICAgIC0+IDEuOCAg ICANCiMNCiMgVGhlIGZvbGxvd2luZyBpcyB0aGUgQml0S2VlcGVyIENoYW5n ZVNldCBMb2cNCiMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCiMgMDMvMDkvMDEJdm51b3J2YWxAZHNsLWhraWd3MWE4 Yi5kaWFsLmluZXQuZmkJMS4xMjc2LjI4LjINCiMgVXNlIGZyZWVfbmV0ZGV2 IGFzIGlwNl90dW5uZWwgZGV2aWNlIGRlc3RydWN0b3INCiMgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiMNCmRpZmYg LU5ydSBhL25ldC9pcHY2L2lwNl90dW5uZWwuYyBiL25ldC9pcHY2L2lwNl90 dW5uZWwuYw0KLS0tIGEvbmV0L2lwdjYvaXA2X3R1bm5lbC5jCU1vbiBTZXAg IDEgMDE6NTc6MzcgMjAwMw0KKysrIGIvbmV0L2lwdjYvaXA2X3R1bm5lbC5j CU1vbiBTZXAgIDEgMDE6NTc6MzcgMjAwMw0KQEAgLTEwODIsNyArMTA4Miw3 IEBADQogew0KIAlTRVRfTU9EVUxFX09XTkVSKGRldik7DQogCWRldi0+dW5p bml0ID0gaXA2aXA2X3RubF9kZXZfdW5pbml0Ow0KLQlkZXYtPmRlc3RydWN0 b3IgPSAodm9pZCAoKikoc3RydWN0IG5ldF9kZXZpY2UgKikpa2ZyZWU7DQor CWRldi0+ZGVzdHJ1Y3RvciA9IGZyZWVfbmV0ZGV2Ow0KIAlkZXYtPmhhcmRf c3RhcnRfeG1pdCA9IGlwNmlwNl90bmxfeG1pdDsNCiAJZGV2LT5nZXRfc3Rh dHMgPSBpcDZpcDZfdG5sX2dldF9zdGF0czsNCiAJZGV2LT5kb19pb2N0bCA9 IGlwNmlwNl90bmxfaW9jdGw7DQo= ---377318441-1258061687-1062373605=:26242-- From vnuorval@tcs.hut.fi Sun Aug 31 16:49:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 31 Aug 2003 16:49:36 -0700 (PDT) Received: from smtp-2.hut.fi (root@smtp-2.hut.fi [130.233.228.92]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7VNn0WZ023917 for ; Sun, 31 Aug 2003 16:49:02 -0700 Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by smtp-2.hut.fi (8.12.9/8.12.9) with ESMTP id h7VNmt5t028298; Mon, 1 Sep 2003 02:48:55 +0300 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 67B798001A5; Mon, 1 Sep 2003 02:48:55 +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-6.4) with ESMTP id h7VNmt9s026305; Mon, 1 Sep 2003 02:48:55 +0300 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7VNmtiK026301; Mon, 1 Sep 2003 02:48:55 +0300 Date: Mon, 1 Sep 2003 02:48:55 +0300 (EEST) From: Ville Nuorvala To: davem@redhat.com, Cc: netdev@oss.sgi.com Subject: [PATCH] IPv6: (3/5) Set dev->dev_addr and dev->broadcast in ip6_tnls In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-377318441-847397231-1062373440=:26242" Content-ID: X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-2.hut.fi) X-DCC-HUTCC-Metrics: smtp-2.hut.fi 1165; Body=4 Fuz1=4 Fuz2=4 X-archive-position: 5446 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---377318441-847397231-1062373440=:26242 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Hi, I just only recently noticed MAX_ADDR_LEN had beed increased to 32. This means the IPv6 addresses can now be copied into the dev->dev_addr and dev->broadcast fields, just like the IPv4 addresses are for the other tunnel drivers. Please apply! Thanks, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 ---377318441-847397231-1062373440=:26242 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="ip6_tnl_dev_addr.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="ip6_tnl_dev_addr.patch" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBwYXRjaCBmb3IgdGhl IGZvbGxvd2luZyBwcm9qZWN0Og0KIyBQcm9qZWN0IE5hbWU6IExpbnV4IGtl cm5lbCB0cmVlDQojIFRoaXMgcGF0Y2ggZm9ybWF0IGlzIGludGVuZGVkIGZv ciBHTlUgcGF0Y2ggY29tbWFuZCB2ZXJzaW9uIDIuNSBvciBoaWdoZXIuDQoj IFRoaXMgcGF0Y2ggaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBkZWx0YXM6DQoj CSAgICAgICAgICAgQ2hhbmdlU2V0CTEuMTI3Ni4yOC4yIC0+IDEuMTI3Ni4y OC4zDQojCW5ldC9pcHY2L2lwNl90dW5uZWwuYwkxLjggICAgIC0+IDEuOSAg ICANCiMNCiMgVGhlIGZvbGxvd2luZyBpcyB0aGUgQml0S2VlcGVyIENoYW5n ZVNldCBMb2cNCiMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCiMgMDMvMDkvMDEJdm51b3J2YWxAZHNsLWhraWd3MWE4 Yi5kaWFsLmluZXQuZmkJMS4xMjc2LjI4LjMNCiMgQ29weSB0dW5uZWwgYWRk cmVzc2VzIHRvIGRldi0+ZGV2X2FkZHIgYW5kIGRldi0+YnJvYWRjYXN0IGxp a2UgaW4gdGhlDQojIG90aGVyIHR1bm5lbCBkcml2ZXJzLg0KIyAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIw0KZGlm ZiAtTnJ1IGEvbmV0L2lwdjYvaXA2X3R1bm5lbC5jIGIvbmV0L2lwdjYvaXA2 X3R1bm5lbC5jDQotLS0gYS9uZXQvaXB2Ni9pcDZfdHVubmVsLmMJTW9uIFNl cCAgMSAwMTo1Nzo1OCAyMDAzDQorKysgYi9uZXQvaXB2Ni9pcDZfdHVubmVs LmMJTW9uIFNlcCAgMSAwMTo1Nzo1OCAyMDAzDQpAQCAtODUxLDYgKzg1MSwx MCBAQA0KIAlzdHJ1Y3QgbmV0X2RldmljZSAqZGV2ID0gdC0+ZGV2Ow0KIAlz dHJ1Y3QgaXA2X3RubF9wYXJtICpwID0gJnQtPnBhcm1zOw0KIAlzdHJ1Y3Qg Zmxvd2kgKmZsOw0KKw0KKwltZW1jcHkoJmRldi0+ZGV2X2FkZHIsICZwLT5s YWRkciwgc2l6ZW9mKHN0cnVjdCBpbjZfYWRkcikpOw0KKwltZW1jcHkoJmRl di0+YnJvYWRjYXN0LCAmcC0+cmFkZHIsIHNpemVvZihzdHJ1Y3QgaW42X2Fk ZHIpKTsNCisNCiAJLyogU2V0IHVwIGZsb3dpIHRlbXBsYXRlICovDQogCWZs ID0gJnQtPmZsOw0KIAlpcHY2X2FkZHJfY29weSgmZmwtPmZsNl9zcmMsICZw LT5sYWRkcik7DQpAQCAtMTA5MywxMCArMTA5Nyw3IEBADQogCWRldi0+bXR1 ID0gRVRIX0RBVEFfTEVOIC0gc2l6ZW9mIChzdHJ1Y3QgaXB2Nmhkcik7DQog CWRldi0+ZmxhZ3MgfD0gSUZGX05PQVJQOw0KIAlkZXYtPmlmbGluayA9IDA7 DQotCS8qIEhtbS4uLiBNQVhfQUREUl9MRU4gaXMgOCwgc28gdGhlIGlwdjYg YWRkcmVzc2VzIGNhbid0IGJlDQotCSAgIGNvcGllZCB0byBkZXYtPmRldl9h ZGRyIGFuZCBkZXYtPmJyb2FkY2FzdCwgbGlrZSB0aGUgaXB2NA0KLQkgICBh ZGRyZXNzZXMgd2VyZSBpbiBpcGlwLmMsIGlwX2dyZS5jIGFuZCBzaXQuYy4g Ki8NCi0JZGV2LT5hZGRyX2xlbiA9IDA7DQorCWRldi0+YWRkcl9sZW4gPSBz aXplb2Yoc3RydWN0IGluNl9hZGRyKTsNCiB9DQogDQogDQo= ---377318441-847397231-1062373440=:26242-- From vnuorval@tcs.hut.fi Sun Aug 31 16:57:13 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 31 Aug 2003 16:57:46 -0700 (PDT) Received: from smtp-1.hut.fi (root@smtp-1.hut.fi [130.233.228.91]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h7VNvBWZ024698 for ; Sun, 31 Aug 2003 16:57:12 -0700 Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by smtp-1.hut.fi (8.12.9/8.12.9) with ESMTP id h7VNv4Qe020752; Mon, 1 Sep 2003 02:57:04 +0300 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 626118001A5; Mon, 1 Sep 2003 02:57:04 +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-6.4) with ESMTP id h7VNv49s026323; Mon, 1 Sep 2003 02:57:04 +0300 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7VNv3er026319; Mon, 1 Sep 2003 02:57:04 +0300 Date: Mon, 1 Sep 2003 02:57:03 +0300 (EEST) From: Ville Nuorvala To: davem@redhat.com, Cc: netdev@oss.sgi.com Subject: [PATCH] IPv6: (4/5) Remove sockets from ip6_tunnel.c In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-377318441-303137126-1062374223=:26242" X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-1.hut.fi) X-DCC-HUTCC-Metrics: smtp-1.hut.fi 1165; Body=3 Fuz1=4 Fuz2=3 X-archive-position: 5447 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---377318441-303137126-1062374223=:26242 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, this patch removes all sockets from ip6_tunnel.c. It also allows nested IPv6 encapsulations through different devices in the IPv6 tunnel entry-point node, since the old restrictions caused by the sockets don't apply any more. Please apply the patch! Thanks, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 ---377318441-303137126-1062374223=:26242 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="ip6_tnl_no_sock.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="ip6_tnl_no_sock.patch" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBwYXRjaCBmb3IgdGhl IGZvbGxvd2luZyBwcm9qZWN0Og0KIyBQcm9qZWN0IE5hbWU6IExpbnV4IGtl cm5lbCB0cmVlDQojIFRoaXMgcGF0Y2ggZm9ybWF0IGlzIGludGVuZGVkIGZv ciBHTlUgcGF0Y2ggY29tbWFuZCB2ZXJzaW9uIDIuNSBvciBoaWdoZXIuDQoj IFRoaXMgcGF0Y2ggaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBkZWx0YXM6DQoj CSAgICAgICAgICAgQ2hhbmdlU2V0CTEuMTI3Ni4yOC4zIC0+IDEuMTI3Ni4y OC40DQojCW5ldC9pcHY2L2lwNl90dW5uZWwuYwkxLjkgICAgIC0+IDEuMTAg ICANCiMJaW5jbHVkZS9uZXQvaXA2X3R1bm5lbC5oCTEuMSAgICAgLT4gMS4y ICAgIA0KIwluZXQvaXB2Ni9pcHY2X3N5bXMuYwkxLjE3ICAgIC0+IDEuMTgg ICANCiMNCiMgVGhlIGZvbGxvd2luZyBpcyB0aGUgQml0S2VlcGVyIENoYW5n ZVNldCBMb2cNCiMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCiMgMDMvMDkvMDEJdm51b3J2YWxAZHNsLWhraWd3MWE4 Yi5kaWFsLmluZXQuZmkJMS4xMjc2LjI4LjQNCiMgU2luY2UgdGhlIElQdjYt aW4tSVB2NiB0dW5uZWxzIGRvbid0IG5lZWQgc29ja2V0cyBhbnltb3JlLCBu ZXN0ZWQgDQojIElQdjYgZW5jYXBzdWxhdGlvbnMgdGhyb3VnaCBkaWZmZXJl bnQgdHVubmVsIGRldmljZXMgb24gdGhlIHNhbWUgbm9kZQ0KIyBhcmUgbm93 IHBvc3NpYmxlLg0KIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KIw0KZGlmZiAtTnJ1IGEvaW5jbHVkZS9uZXQvaXA2 X3R1bm5lbC5oIGIvaW5jbHVkZS9uZXQvaXA2X3R1bm5lbC5oDQotLS0gYS9p bmNsdWRlL25ldC9pcDZfdHVubmVsLmgJTW9uIFNlcCAgMSAwMTo1ODoyMyAy MDAzDQorKysgYi9pbmNsdWRlL25ldC9pcDZfdHVubmVsLmgJTW9uIFNlcCAg MSAwMTo1ODoyMyAyMDAzDQpAQCAtMjUsNiArMjUsOCBAQA0KIAlpbnQgcmVj dXJzaW9uOwkJLyogZGVwdGggb2YgaGFyZF9zdGFydF94bWl0IHJlY3Vyc2lv biAqLw0KIAlzdHJ1Y3QgaXA2X3RubF9wYXJtIHBhcm1zOwkvKiB0dW5uZWwg Y29uZmlndXJhdGlvbiBwYXJhbXRlcnMgKi8NCiAJc3RydWN0IGZsb3dpIGZs OwkvKiBmbG93aSB0ZW1wbGF0ZSBmb3IgeG1pdCAqLw0KKwlzdHJ1Y3QgZHN0 X2VudHJ5ICpkc3RfY2FjaGU7ICAgIC8qIGNhY2hlZCBkc3QgKi8NCisJdTMy IGRzdF9jb29raWU7DQogfTsNCiANCiAvKiBUdW5uZWwgZW5jYXBzdWxhdGlv biBsaW1pdCBkZXN0aW5hdGlvbiBzdWItb3B0aW9uICovDQpkaWZmIC1OcnUg YS9uZXQvaXB2Ni9pcDZfdHVubmVsLmMgYi9uZXQvaXB2Ni9pcDZfdHVubmVs LmMNCi0tLSBhL25ldC9pcHY2L2lwNl90dW5uZWwuYwlNb24gU2VwICAxIDAx OjU4OjIzIDIwMDMNCisrKyBiL25ldC9pcHY2L2lwNl90dW5uZWwuYwlNb24g U2VwICAxIDAxOjU4OjIzIDIwMDMNCkBAIC0yMyw3ICsyMyw2IEBADQogI2lu Y2x1ZGUgPGxpbnV4L21vZHVsZS5oPg0KICNpbmNsdWRlIDxsaW51eC9lcnJu by5oPg0KICNpbmNsdWRlIDxsaW51eC90eXBlcy5oPg0KLSNpbmNsdWRlIDxs aW51eC9zb2NrZXQuaD4NCiAjaW5jbHVkZSA8bGludXgvc29ja2lvcy5oPg0K ICNpbmNsdWRlIDxsaW51eC9pZi5oPg0KICNpbmNsdWRlIDxsaW51eC9pbi5o Pg0KQEAgLTM3LDEyICszNiwxMiBAQA0KICNpbmNsdWRlIDxsaW51eC9pbml0 Lmg+DQogI2luY2x1ZGUgPGxpbnV4L3JvdXRlLmg+DQogI2luY2x1ZGUgPGxp bnV4L3J0bmV0bGluay5oPg0KKyNpbmNsdWRlIDxsaW51eC9uZXRmaWx0ZXJf aXB2Ni5oPg0KIA0KICNpbmNsdWRlIDxhc20vdWFjY2Vzcy5oPg0KICNpbmNs dWRlIDxhc20vYXRvbWljLmg+DQogDQogI2luY2x1ZGUgPG5ldC9pcC5oPg0K LSNpbmNsdWRlIDxuZXQvc29jay5oPg0KICNpbmNsdWRlIDxuZXQvaXB2Ni5o Pg0KICNpbmNsdWRlIDxuZXQvcHJvdG9jb2wuaD4NCiAjaW5jbHVkZSA8bmV0 L2lwNl9yb3V0ZS5oPg0KQEAgLTYzLDIyICs2Miw2IEBADQogDQogI2RlZmlu ZSBJUFY2X1RDTEFTU19NQVNLIChJUFY2X0ZMT1dJTkZPX01BU0sgJiB+SVBW Nl9GTE9XTEFCRUxfTUFTSykNCiANCi0vKiBzb2NrZXQocykgdXNlZCBieSBp cDZpcDZfdG5sX3htaXQoKSBmb3IgcmVzZW5kaW5nIHBhY2tldHMgKi8NCi1z dGF0aWMgc3RydWN0IHNvY2tldCAqX19pcDZfc29ja2V0W05SX0NQVVNdOw0K LSNkZWZpbmUgaXA2X3NvY2tldCBfX2lwNl9zb2NrZXRbc21wX3Byb2Nlc3Nv cl9pZCgpXQ0KLQ0KLXN0YXRpYyB2b2lkIGlwNl94bWl0X2xvY2sodm9pZCkN Ci17DQotCWxvY2FsX2JoX2Rpc2FibGUoKTsNCi0JaWYgKHVubGlrZWx5KCFz cGluX3RyeWxvY2soJmlwNl9zb2NrZXQtPnNrLT5za19sb2NrLnNsb2NrKSkp DQotCQlCVUcoKTsNCi19DQotDQotc3RhdGljIHZvaWQgaXA2X3htaXRfdW5s b2NrKHZvaWQpDQotew0KLQlzcGluX3VubG9ja19iaCgmaXA2X3NvY2tldC0+ c2stPnNrX2xvY2suc2xvY2spOw0KLX0NCi0NCiAjZGVmaW5lIEhBU0hfU0la RSAgMzINCiANCiAjZGVmaW5lIEhBU0goYWRkcikgKCgoYWRkciktPnM2X2Fk ZHIzMlswXSBeIChhZGRyKS0+czZfYWRkcjMyWzFdIF4gXA0KQEAgLTEwMSw2 ICs4NCwzMyBAQA0KIC8qIGxvY2sgZm9yIHRoZSB0dW5uZWwgbGlzdHMgKi8N CiBzdGF0aWMgcndsb2NrX3QgaXA2aXA2X2xvY2sgPSBSV19MT0NLX1VOTE9D S0VEOw0KIA0KK3N0YXRpYyBpbmxpbmUgc3RydWN0IGRzdF9lbnRyeSAqaXA2 X3RubF9kc3RfY2hlY2soc3RydWN0IGlwNl90bmwgKnQpDQorew0KKwlzdHJ1 Y3QgZHN0X2VudHJ5ICpkc3QgPSB0LT5kc3RfY2FjaGU7DQorDQorCWlmIChk c3QgJiYgZHN0LT5vYnNvbGV0ZSAmJiANCisJICAgIGRzdC0+b3BzLT5jaGVj ayhkc3QsIHQtPmRzdF9jb29raWUpID09IE5VTEwpIHsNCisJCXQtPmRzdF9j YWNoZSA9IE5VTEw7DQorCQlyZXR1cm4gTlVMTDsNCisJfQ0KKw0KKwlyZXR1 cm4gZHN0Ow0KK30NCisNCitzdGF0aWMgaW5saW5lIHZvaWQgaXA2X3RubF9k c3RfcmVzZXQoc3RydWN0IGlwNl90bmwgKnQpDQorew0KKwlkc3RfcmVsZWFz ZSh0LT5kc3RfY2FjaGUpOw0KKwl0LT5kc3RfY2FjaGUgPSBOVUxMOw0KK30N CisNCitzdGF0aWMgaW5saW5lIHZvaWQgaXA2X3RubF9kc3Rfc3RvcmUoc3Ry dWN0IGlwNl90bmwgKnQsIHN0cnVjdCBkc3RfZW50cnkgKmRzdCkNCit7DQor CXN0cnVjdCBydDZfaW5mbyAqcnQgPSAoc3RydWN0IHJ0Nl9pbmZvICopIGRz dDsNCisJdC0+ZHN0X2Nvb2tpZSA9IHJ0LT5ydDZpX25vZGUgPyBydC0+cnQ2 aV9ub2RlLT5mbl9zZXJudW0gOiAwOw0KKwlkc3RfcmVsZWFzZSh0LT5kc3Rf Y2FjaGUpOw0KKwl0LT5kc3RfY2FjaGUgPSBkc3Q7DQorfQ0KKw0KIC8qKg0K ICAqIGlwNmlwNl90bmxfbG9va3VwIC0gZmV0Y2ggdHVubmVsIG1hdGNoaW5n IHRoZSBlbmQtcG9pbnQgYWRkcmVzc2VzDQogICogICBAcmVtb3RlOiB0aGUg YWRkcmVzcyBvZiB0aGUgdHVubmVsIGV4aXQtcG9pbnQgDQpAQCAtMjk0LDEz ICszMDQsMTYgQEANCiBzdGF0aWMgdm9pZA0KIGlwNmlwNl90bmxfZGV2X3Vu aW5pdChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2KQ0KIHsNCisJc3RydWN0IGlw Nl90bmwgKnQgPSBkZXYtPnByaXY7DQorDQogCWlmIChkZXYgPT0gaXA2aXA2 X2ZiX3RubF9kZXYpIHsNCiAJCXdyaXRlX2xvY2tfYmgoJmlwNmlwNl9sb2Nr KTsNCiAJCXRubHNfd2NbMF0gPSBOVUxMOw0KIAkJd3JpdGVfdW5sb2NrX2Jo KCZpcDZpcDZfbG9jayk7DQogCX0gZWxzZSB7DQotCQlpcDZpcDZfdG5sX3Vu bGluaygoc3RydWN0IGlwNl90bmwgKikgZGV2LT5wcml2KTsNCisJCWlwNmlw Nl90bmxfdW5saW5rKHQpOw0KIAl9DQorCWlwNl90bmxfZHN0X3Jlc2V0KHQp Ow0KIAlkZXZfcHV0KGRldik7DQogfQ0KIA0KQEAgLTUyMiwxMTIgKzUzNSwz NCBAQA0KIAlyZXR1cm4gMDsNCiB9DQogDQotLyoqDQotICogdHhvcHRfbGVu IC0gZ2V0IG5lY2Vzc2FyeSBzaXplIGZvciBuZXcgJnN0cnVjdCBpcHY2X3R4 b3B0aW9ucw0KLSAqICAgQG9yaWdfb3B0OiBvbGQgb3B0aW9ucw0KLSAqDQot ICogUmV0dXJuOg0KLSAqICAgU2l6ZSBvZiBvbGQgb25lIHBsdXMgc2l6ZSBv ZiB0dW5uZWwgZW5jYXBzdWxhdGlvbiBsaW1pdCBvcHRpb24NCi0gKiovDQot DQotc3RhdGljIGlubGluZSBpbnQNCi10eG9wdF9sZW4oc3RydWN0IGlwdjZf dHhvcHRpb25zICpvcmlnX29wdCkNCi17DQotCWludCBsZW4gPSBzaXplb2Yg KCpvcmlnX29wdCkgKyA4Ow0KLQ0KLQlpZiAob3JpZ19vcHQgJiYgb3JpZ19v cHQtPmRzdDBvcHQpDQotCQlsZW4gKz0gaXB2Nl9vcHRsZW4ob3JpZ19vcHQt PmRzdDBvcHQpOw0KLQlyZXR1cm4gbGVuOw0KLX0NCi0NCi0vKioNCi0gKiBt ZXJnZV9vcHRpb25zIC0gYWRkIGVuY2Fwc3VsYXRpb24gbGltaXQgdG8gb3Jp Z2luYWwgb3B0aW9ucw0KLSAqICAgQGVuY2FwX2xpbWl0OiBudW1iZXIgb2Yg YWxsb3dlZCBlbmNhcHN1bGF0aW9uIGxpbWl0cw0KLSAqICAgQG9yaWdfb3B0 OiBvcmlnaW5hbCBvcHRpb25zDQotICogDQotICogUmV0dXJuOg0KLSAqICAg UG9pbnRlciB0byBuZXcgJnN0cnVjdCBpcHY2X3R4b3B0aW9ucyBjb250YWlu aW5nIHRoZSB0dW5uZWwNCi0gKiAgIGVuY2Fwc3VsYXRpb24gbGltaXQNCi0g KiovDQotDQotc3RhdGljIHN0cnVjdCBpcHY2X3R4b3B0aW9ucyAqDQotbWVy Z2Vfb3B0aW9ucyhzdHJ1Y3Qgc29jayAqc2ssIF9fdTggZW5jYXBfbGltaXQs DQotCSAgICAgIHN0cnVjdCBpcHY2X3R4b3B0aW9ucyAqb3JpZ19vcHQpDQor c3RhdGljIGlubGluZSBzdHJ1Y3QgaXB2Nl90eG9wdGlvbnMgKmNyZWF0ZV90 ZWwoX191OCBlbmNhcF9saW1pdCkNCiB7DQogCXN0cnVjdCBpcHY2X3Rsdl90 bmxfZW5jX2xpbSAqdGVsOw0KIAlzdHJ1Y3QgaXB2Nl90eG9wdGlvbnMgKm9w dDsNCiAJX191OCAqcmF3Ow0KLQlfX3U4IHBhZF90byA9IDg7DQotCWludCBv cHRfbGVuID0gdHhvcHRfbGVuKG9yaWdfb3B0KTsNCiANCi0JaWYgKCEob3B0 ID0gc29ja19rbWFsbG9jKHNrLCBvcHRfbGVuLCBHRlBfQVRPTUlDKSkpIHsN CisJaW50IG9wdF9sZW4gPSBzaXplb2YoKm9wdCkgKyA4Ow0KKw0KKwlpZiAo IShvcHQgPSBrbWFsbG9jKG9wdF9sZW4sIEdGUF9BVE9NSUMpKSkgew0KIAkJ cmV0dXJuIE5VTEw7DQogCX0NCi0NCiAJbWVtc2V0KG9wdCwgMCwgb3B0X2xl bik7DQogCW9wdC0+dG90X2xlbiA9IG9wdF9sZW47DQogCW9wdC0+ZHN0MG9w dCA9IChzdHJ1Y3QgaXB2Nl9vcHRfaGRyICopIChvcHQgKyAxKTsNCiAJb3B0 LT5vcHRfbmZsZW4gPSA4Ow0KIA0KLQlyYXcgPSAoX191OCAqKSBvcHQtPmRz dDBvcHQ7DQotDQogCXRlbCA9IChzdHJ1Y3QgaXB2Nl90bHZfdG5sX2VuY19s aW0gKikgKG9wdC0+ZHN0MG9wdCArIDEpOw0KIAl0ZWwtPnR5cGUgPSBJUFY2 X1RMVl9UTkxfRU5DQVBfTElNSVQ7DQogCXRlbC0+bGVuZ3RoID0gMTsNCiAJ dGVsLT5lbmNhcF9saW1pdCA9IGVuY2FwX2xpbWl0Ow0KIA0KLQlpZiAob3Jp Z19vcHQpIHsNCi0JCV9fdTggKm9yaWdfcmF3Ow0KLQ0KLQkJb3B0LT5ob3Bv cHQgPSBvcmlnX29wdC0+aG9wb3B0Ow0KLQ0KLQkJLyogS2VlcCB0aGUgb3Jp Z2luYWwgZGVzdGluYXRpb24gb3B0aW9ucyBwcm9wZXJseQ0KLQkJICAgYWxp Z25lZCBhbmQgbWVyZ2UgcG9zc2libGUgb2xkIHBhZGRpbmdzIHRvIHRoZQ0K LQkJICAgbmV3IHBhZGRpbmcgb3B0aW9uICovDQotCQlpZiAoKG9yaWdfcmF3 ID0gKF9fdTggKikgb3JpZ19vcHQtPmRzdDBvcHQpICE9IE5VTEwpIHsNCi0J CQlfX3U4IHR5cGU7DQotCQkJaW50IGkgPSBzaXplb2YgKHN0cnVjdCBpcHY2 X29wdF9oZHIpOw0KLQkJCXBhZF90byArPSBzaXplb2YgKHN0cnVjdCBpcHY2 X29wdF9oZHIpOw0KLQkJCXdoaWxlIChpIDwgaXB2Nl9vcHRsZW4ob3JpZ19v cHQtPmRzdDBvcHQpKSB7DQotCQkJCXR5cGUgPSBvcmlnX3Jhd1tpKytdOw0K LQkJCQlpZiAodHlwZSA9PSBJUFY2X1RMVl9QQUQwKQ0KLQkJCQkJcGFkX3Rv Kys7DQotCQkJCWVsc2UgaWYgKHR5cGUgPT0gSVBWNl9UTFZfUEFETikgew0K LQkJCQkJaW50IGxlbiA9IG9yaWdfcmF3W2krK107DQotCQkJCQlpICs9IGxl bjsNCi0JCQkJCXBhZF90byArPSBsZW4gKyAyOw0KLQkJCQl9IGVsc2Ugew0K LQkJCQkJYnJlYWs7DQotCQkJCX0NCi0JCQl9DQotCQkJb3B0LT5kc3Qwb3B0 LT5oZHJsZW4gPSBvcmlnX29wdC0+ZHN0MG9wdC0+aGRybGVuICsgMTsNCi0J CQltZW1jcHkocmF3ICsgcGFkX3RvLCBvcmlnX3JhdyArIHBhZF90byAtIDgs DQotCQkJICAgICAgIG9wdF9sZW4gLSBzaXplb2YgKCpvcHQpIC0gcGFkX3Rv KTsNCi0JCX0NCi0JCW9wdC0+c3JjcnQgPSBvcmlnX29wdC0+c3JjcnQ7DQot CQlvcHQtPm9wdF9uZmxlbiArPSBvcmlnX29wdC0+b3B0X25mbGVuOw0KLQ0K LQkJb3B0LT5kc3Qxb3B0ID0gb3JpZ19vcHQtPmRzdDFvcHQ7DQotCQlvcHQt PmF1dGggPSBvcmlnX29wdC0+YXV0aDsNCi0JCW9wdC0+b3B0X2ZsZW4gPSBv cmlnX29wdC0+b3B0X2ZsZW47DQotCX0NCisJcmF3ID0gKF9fdTggKikgb3B0 LT5kc3Qwb3B0Ow0KIAlyYXdbNV0gPSBJUFY2X1RMVl9QQUROOw0KLQ0KLQkv KiBzdWJ0cmFjdCBsZW5ndGhzIG9mIGRlc3RpbmF0aW9uIHN1Ym9wdGlvbiBo ZWFkZXIsDQotCSAgIHR1bm5lbCBlbmNhcHN1bGF0aW9uIGxpbWl0IGFuZCBw YWQgTiBoZWFkZXIgKi8NCi0JcmF3WzZdID0gcGFkX3RvIC0gNzsNCisJcmF3 WzZdID0gMTsNCiANCiAJcmV0dXJuIG9wdDsNCiB9DQogDQotc3RhdGljIGlu dCANCi1pcDZpcDZfZ2V0ZnJhZyh2b2lkICpmcm9tLCBjaGFyICp0bywgaW50 IG9mZnNldCwgaW50IGxlbiwgaW50IG9kZCwgDQotCQlzdHJ1Y3Qgc2tfYnVm ZiAqc2tiKQ0KLXsNCi0JbWVtY3B5KHRvLCAoY2hhciAqKSBmcm9tICsgb2Zm c2V0LCBsZW4pOw0KLQlyZXR1cm4gMDsNCi19DQotDQogLyoqDQogICogaXA2 aXA2X3RubF9hZGRyX2NvbmZsaWN0IC0gY29tcGFyZSBwYWNrZXQgYWRkcmVz c2VzIHRvIHR1bm5lbCdzIG93bg0KICAqICAgQHQ6IHRoZSBvdXRnb2luZyB0 dW5uZWwgZGV2aWNlDQpAQCAtNjU1LDcgKzU5MCw3IEBADQogICoNCiAgKiBE ZXNjcmlwdGlvbjoNCiAgKiAgIEJ1aWxkIG5ldyBoZWFkZXIgYW5kIGRvIHNv bWUgc2FuaXR5IGNoZWNrcyBvbiB0aGUgcGFja2V0IGJlZm9yZSBzZW5kaW5n DQotICogICBpdCB0byBpcDZfYnVpbGRfeG1pdCgpLg0KKyAqICAgaXQuDQog ICoNCiAgKiBSZXR1cm46IA0KICAqICAgMA0KQEAgLTY2NiwxOCArNjAxLDE3 IEBADQogCXN0cnVjdCBpcDZfdG5sICp0ID0gKHN0cnVjdCBpcDZfdG5sICop IGRldi0+cHJpdjsNCiAJc3RydWN0IG5ldF9kZXZpY2Vfc3RhdHMgKnN0YXRz ID0gJnQtPnN0YXQ7DQogCXN0cnVjdCBpcHY2aGRyICppcHY2aCA9IHNrYi0+ bmguaXB2Nmg7DQotCXN0cnVjdCBpcHY2X3R4b3B0aW9ucyAqb3JpZ19vcHQg PSBOVUxMOw0KIAlzdHJ1Y3QgaXB2Nl90eG9wdGlvbnMgKm9wdCA9IE5VTEw7 DQogCWludCBlbmNhcF9saW1pdCA9IC0xOw0KIAlfX3UxNiBvZmZzZXQ7DQog CXN0cnVjdCBmbG93aSBmbDsNCi0Jc3RydWN0IGlwNl9mbG93bGFiZWwgKmZs X2xibCA9IE5VTEw7DQotCWludCBlcnIgPSAwOw0KIAlzdHJ1Y3QgZHN0X2Vu dHJ5ICpkc3Q7DQotCWludCBsaW5rX2ZhaWx1cmUgPSAwOw0KLQlzdHJ1Y3Qg c29jayAqc2sgPSBpcDZfc29ja2V0LT5zazsNCi0Jc3RydWN0IGlwdjZfcGlu Zm8gKm5wID0gaW5ldDZfc2soc2spOw0KKwlzdHJ1Y3QgbmV0X2RldmljZSAq dGRldjsNCiAJaW50IG10dTsNCisJaW50IG1heF9oZWFkcm9vbSA9IHNpemVv ZihzdHJ1Y3QgaXB2Nmhkcik7DQorCXU4IHByb3RvOw0KKwlpbnQgZXJyOw0K KwlpbnQgcGt0X2xlbjsNCiANCiAJaWYgKHQtPnJlY3Vyc2lvbisrKSB7DQog CQlzdGF0cy0+Y29sbGlzaW9ucysrOw0KQEAgLTcwMCw1OCArNjM0LDM5IEBA DQogCX0gZWxzZSBpZiAoISh0LT5wYXJtcy5mbGFncyAmIElQNl9UTkxfRl9J R05fRU5DQVBfTElNSVQpKSB7DQogCQllbmNhcF9saW1pdCA9IHQtPnBhcm1z LmVuY2FwX2xpbWl0Ow0KIAl9DQotCWlwNl94bWl0X2xvY2soKTsNCi0NCiAJ bWVtY3B5KCZmbCwgJnQtPmZsLCBzaXplb2YgKGZsKSk7DQorCXByb3RvID0g ZmwucHJvdG87DQogDQogCWlmICgodC0+cGFybXMuZmxhZ3MgJiBJUDZfVE5M X0ZfVVNFX09SSUdfVENMQVNTKSkNCiAJCWZsLmZsNl9mbG93bGFiZWwgfD0g KCooX191MzIgKikgaXB2NmggJiBJUFY2X1RDTEFTU19NQVNLKTsNCiAJaWYg KCh0LT5wYXJtcy5mbGFncyAmIElQNl9UTkxfRl9VU0VfT1JJR19GTE9XTEFC RUwpKQ0KIAkJZmwuZmw2X2Zsb3dsYWJlbCB8PSAoKihfX3UzMiAqKSBpcHY2 aCAmIElQVjZfRkxPV0xBQkVMX01BU0spOw0KIA0KLQlpZiAoZmwuZmw2X2Zs b3dsYWJlbCkgew0KLQkJZmxfbGJsID0gZmw2X3NvY2tfbG9va3VwKHNrLCBm bC5mbDZfZmxvd2xhYmVsKTsNCi0JCWlmIChmbF9sYmwpDQotCQkJb3JpZ19v cHQgPSBmbF9sYmwtPm9wdDsNCi0JfQ0KLQlpZiAoZW5jYXBfbGltaXQgPj0g MCkgew0KLQkJaWYgKCEob3B0ID0gbWVyZ2Vfb3B0aW9ucyhzaywgZW5jYXBf bGltaXQsIG9yaWdfb3B0KSkpIHsNCi0JCQlnb3RvIHR4X2Vycl9mcmVlX2Zs X2xibDsNCi0JCX0NCi0JfSBlbHNlIHsNCi0JCW9wdCA9IG9yaWdfb3B0Ow0K LQl9DQotCWRzdCA9IF9fc2tfZHN0X2NoZWNrKHNrLCBucC0+ZHN0X2Nvb2tp ZSk7DQorCWlmIChlbmNhcF9saW1pdCA+PSAwICYmIChvcHQgPSBjcmVhdGVf dGVsKGVuY2FwX2xpbWl0KSkgPT0gTlVMTCkNCisJCWdvdG8gdHhfZXJyOw0K IA0KLQlpZiAoZHN0KSB7DQotCQlpZiAobnAtPmRhZGRyX2NhY2hlID09IE5V TEwgfHwNCi0JCSAgICBpcHY2X2FkZHJfY21wKCZmbC5mbDZfZHN0LCBucC0+ ZGFkZHJfY2FjaGUpIHx8DQotCQkgICAgKGZsLm9pZiAmJiBmbC5vaWYgIT0g ZHN0LT5kZXYtPmlmaW5kZXgpKSB7DQotCQkJZHN0ID0gTlVMTDsNCi0JCX0N Ci0JfQ0KLQlpZiAoZHN0ID09IE5VTEwpIHsNCi0JCWRzdCA9IGlwNl9yb3V0 ZV9vdXRwdXQoc2ssICZmbCk7DQotCQlpZiAoZHN0LT5lcnJvcikgew0KLQkJ CXN0YXRzLT50eF9jYXJyaWVyX2Vycm9ycysrOw0KLQkJCWxpbmtfZmFpbHVy ZSA9IDE7DQotCQkJZ290byB0eF9lcnJfZHN0X3JlbGVhc2U7DQotCQl9DQot CQkvKiBsb2NhbCByb3V0aW5nIGxvb3AgKi8NCi0JCWlmIChkc3QtPmRldiA9 PSBkZXYpIHsNCi0JCQlzdGF0cy0+Y29sbGlzaW9ucysrOw0KLQkJCWlmIChu ZXRfcmF0ZWxpbWl0KCkpDQotCQkJCXByaW50ayhLRVJOX1dBUk5JTkcgDQot CQkJCSAgICAgICAiJXM6IExvY2FsIHJvdXRpbmcgbG9vcCBkZXRlY3RlZCFc biIsDQotCQkJCSAgICAgICB0LT5wYXJtcy5uYW1lKTsNCi0JCQlnb3RvIHR4 X2Vycl9kc3RfcmVsZWFzZTsNCi0JCX0NCi0JCWlwdjZfYWRkcl9jb3B5KCZu cC0+ZGFkZHIsICZmbC5mbDZfZHN0KTsNCi0JCWlwdjZfYWRkcl9jb3B5KCZu cC0+c2FkZHIsICZmbC5mbDZfc3JjKTsNCisJaWYgKChkc3QgPSBpcDZfdG5s X2RzdF9jaGVjayh0KSkgIT0gTlVMTCkNCisJCWRzdF9ob2xkKGRzdCk7DQor CWVsc2UNCisJCWRzdCA9IGlwNl9yb3V0ZV9vdXRwdXQoTlVMTCwgJmZsKTsN CisNCisJaWYgKGRzdC0+ZXJyb3IgfHwgeGZybV9sb29rdXAoJmRzdCwgJmZs LCBOVUxMLCAwKSA8IDApDQorCQlnb3RvIHR4X2Vycl9saW5rX2ZhaWx1cmU7 DQorDQorCXRkZXYgPSBkc3QtPmRldjsNCisNCisJaWYgKHRkZXYgPT0gZGV2 KSB7DQorCQlzdGF0cy0+Y29sbGlzaW9ucysrOw0KKwkJaWYgKG5ldF9yYXRl bGltaXQoKSkNCisJCQlwcmludGsoS0VSTl9XQVJOSU5HIA0KKwkJCSAgICAg ICAiJXM6IExvY2FsIHJvdXRpbmcgbG9vcCBkZXRlY3RlZCFcbiIsDQorCQkJ ICAgICAgIHQtPnBhcm1zLm5hbWUpOw0KKwkJZ290byB0eF9lcnJfZHN0X3Jl bGVhc2U7DQogCX0NCiAJbXR1ID0gZHN0X3BtdHUoZHN0KSAtIHNpemVvZiAo KmlwdjZoKTsNCiAJaWYgKG9wdCkgew0KLQkJbXR1IC09IChvcHQtPm9wdF9u ZmxlbiArIG9wdC0+b3B0X2ZsZW4pOw0KKwkJbWF4X2hlYWRyb29tICs9IDg7 DQorCQltdHUgLT0gODsNCiAJfQ0KIAlpZiAobXR1IDwgSVBWNl9NSU5fTVRV KQ0KIAkJbXR1ID0gSVBWNl9NSU5fTVRVOw0KQEAgLTc2NCw0MSArNjc5LDcx IEBADQogCQlpY21wdjZfc2VuZChza2IsIElDTVBWNl9QS1RfVE9PQklHLCAw LCBtdHUsIGRldik7DQogCQlnb3RvIHR4X2Vycl9kc3RfcmVsZWFzZTsNCiAJ fQ0KLQllcnIgPSBpcDZfYXBwZW5kX2RhdGEoc2ssIGlwNmlwNl9nZXRmcmFn LCBza2ItPm5oLnJhdywgc2tiLT5sZW4sIDAsDQotCQkJICAgICAgdC0+cGFy bXMuaG9wX2xpbWl0LCBvcHQsICZmbCwgDQotCQkJICAgICAgKHN0cnVjdCBy dDZfaW5mbyAqKWRzdCwgTVNHX0RPTlRXQUlUKTsNCisJc2tiLT5oLnJhdyA9 IHNrYi0+bmgucmF3Ow0KIA0KLQlpZiAoZXJyKSB7DQotCQlpcDZfZmx1c2hf cGVuZGluZ19mcmFtZXMoc2spOw0KLQl9IGVsc2Ugew0KLQkJZXJyID0gaXA2 X3B1c2hfcGVuZGluZ19mcmFtZXMoc2spOw0KLQkJZXJyID0gKGVyciA8IDAg PyBlcnIgOiAwKTsNCisJLyoNCisJICogT2theSwgbm93IHNlZSBpZiB3ZSBj YW4gc3R1ZmYgaXQgaW4gdGhlIGJ1ZmZlciBhcy1pcy4NCisJICovDQorCW1h eF9oZWFkcm9vbSArPSBMTF9SRVNFUlZFRF9TUEFDRSh0ZGV2KTsNCisJDQor CWlmIChza2JfaGVhZHJvb20oc2tiKSA8IG1heF9oZWFkcm9vbSB8fCANCisJ ICAgIHNrYl9jbG9uZWQoc2tiKSB8fCBza2Jfc2hhcmVkKHNrYikpIHsNCisJ CXN0cnVjdCBza19idWZmICpuZXdfc2tiOw0KKwkJDQorCQlpZiAoIShuZXdf c2tiID0gc2tiX3JlYWxsb2NfaGVhZHJvb20oc2tiLCBtYXhfaGVhZHJvb20p KSkNCisJCQlnb3RvIHR4X2Vycl9kc3RfcmVsZWFzZTsNCisNCisJCWlmIChz a2ItPnNrKQ0KKwkJCXNrYl9zZXRfb3duZXJfdyhuZXdfc2tiLCBza2ItPnNr KTsNCisJCWtmcmVlX3NrYihza2IpOw0KKwkJc2tiID0gbmV3X3NrYjsNCiAJ fQ0KLQlpZiAoIWVycikgew0KLQkJc3RhdHMtPnR4X2J5dGVzICs9IHNrYi0+ bGVuOw0KKwlkc3RfcmVsZWFzZShza2ItPmRzdCk7DQorCXNrYi0+ZHN0ID0g ZHN0X2Nsb25lKGRzdCk7DQorDQorCWlmIChvcHQpDQorCQlpcHY2X3B1c2hf bmZyYWdfb3B0cyhza2IsIG9wdCwgJnByb3RvLCBOVUxMKTsNCisNCisJc2ti LT5uaC5yYXcgPSBza2JfcHVzaChza2IsIHNpemVvZihzdHJ1Y3QgaXB2Nmhk cikpOw0KKwlpcHY2aCA9IHNrYi0+bmguaXB2Nmg7DQorCSoodTMyKilpcHY2 aCA9IGZsLmZsNl9mbG93bGFiZWwgfCBodG9ubCgweDYwMDAwMDAwKTsNCisJ aXB2NmgtPnBheWxvYWRfbGVuID0gaHRvbnMoc2tiLT5sZW4gLSBzaXplb2Yo c3RydWN0IGlwdjZoZHIpKTsNCisJaXB2NmgtPmhvcF9saW1pdCA9IHQtPnBh cm1zLmhvcF9saW1pdDsNCisJaXB2NmgtPm5leHRoZHIgPSBwcm90bzsNCisJ aXB2Nl9hZGRyX2NvcHkoJmlwdjZoLT5zYWRkciwgJmZsLmZsNl9zcmMpOw0K KwlpcHY2X2FkZHJfY29weSgmaXB2NmgtPmRhZGRyLCAmZmwuZmw2X2RzdCk7 DQorI2lmZGVmIENPTkZJR19ORVRGSUxURVINCisJbmZfY29ubnRyYWNrX3B1 dChza2ItPm5mY3QpOw0KKwlza2ItPm5mY3QgPSBOVUxMOw0KKyNpZmRlZiBD T05GSUdfTkVURklMVEVSX0RFQlVHDQorCXNrYi0+bmZfZGVidWcgPSAwOw0K KyNlbmRpZg0KKyNlbmRpZg0KKwlwa3RfbGVuID0gc2tiLT5sZW47DQorCWVy ciA9IE5GX0hPT0soUEZfSU5FVDYsIE5GX0lQNl9MT0NBTF9PVVQsIHNrYiwg TlVMTCwgDQorCQkgICAgICBza2ItPmRzdC0+ZGV2LCBkc3Rfb3V0cHV0KTsN CisNCisJaWYgKGVyciA9PSBORVRfWE1JVF9TVUNDRVNTIHx8IGVyciA9PSBO RVRfWE1JVF9DTikgew0KKwkJc3RhdHMtPnR4X2J5dGVzICs9IHBrdF9sZW47 DQogCQlzdGF0cy0+dHhfcGFja2V0cysrOw0KIAl9IGVsc2Ugew0KIAkJc3Rh dHMtPnR4X2Vycm9ycysrOw0KIAkJc3RhdHMtPnR4X2Fib3J0ZWRfZXJyb3Jz Kys7DQogCX0NCi0JaWYgKG9wdCAmJiBvcHQgIT0gb3JpZ19vcHQpDQotCQlz b2NrX2tmcmVlX3Moc2ssIG9wdCwgb3B0LT50b3RfbGVuKTsNCisJaXA2X3Ru bF9kc3Rfc3RvcmUodCwgZHN0KTsNCisNCisJaWYgKG9wdCkNCisJCWtmcmVl KG9wdCk7DQogDQotCWZsNl9zb2NrX3JlbGVhc2UoZmxfbGJsKTsNCi0JaXA2 X2RzdF9zdG9yZShzaywgZHN0LCAmbnAtPmRhZGRyKTsNCi0JaXA2X3htaXRf dW5sb2NrKCk7DQotCWtmcmVlX3NrYihza2IpOw0KIAl0LT5yZWN1cnNpb24t LTsNCiAJcmV0dXJuIDA7DQordHhfZXJyX2xpbmtfZmFpbHVyZToNCisJc3Rh dHMtPnR4X2NhcnJpZXJfZXJyb3JzKys7DQorCWRzdF9saW5rX2ZhaWx1cmUo c2tiKTsNCiB0eF9lcnJfZHN0X3JlbGVhc2U6DQogCWRzdF9yZWxlYXNlKGRz dCk7DQotCWlmIChvcHQgJiYgb3B0ICE9IG9yaWdfb3B0KQ0KLQkJc29ja19r ZnJlZV9zKHNrLCBvcHQsIG9wdC0+dG90X2xlbik7DQotdHhfZXJyX2ZyZWVf ZmxfbGJsOg0KLQlmbDZfc29ja19yZWxlYXNlKGZsX2xibCk7DQotCWlwNl94 bWl0X3VubG9jaygpOw0KLQlpZiAobGlua19mYWlsdXJlKQ0KLQkJZHN0X2xp bmtfZmFpbHVyZShza2IpOw0KKwlpZiAob3B0KQ0KKwkJa2ZyZWUob3B0KTsN CiB0eF9lcnI6DQogCXN0YXRzLT50eF9lcnJvcnMrKzsNCiAJc3RhdHMtPnR4 X2Ryb3BwZWQrKzsNCkBAIC04NTAsMTMgKzc5NSwxMiBAQA0KIHsNCiAJc3Ry dWN0IG5ldF9kZXZpY2UgKmRldiA9IHQtPmRldjsNCiAJc3RydWN0IGlwNl90 bmxfcGFybSAqcCA9ICZ0LT5wYXJtczsNCi0Jc3RydWN0IGZsb3dpICpmbDsN CisJc3RydWN0IGZsb3dpICpmbCA9ICZ0LT5mbDsNCiANCiAJbWVtY3B5KCZk ZXYtPmRldl9hZGRyLCAmcC0+bGFkZHIsIHNpemVvZihzdHJ1Y3QgaW42X2Fk ZHIpKTsNCiAJbWVtY3B5KCZkZXYtPmJyb2FkY2FzdCwgJnAtPnJhZGRyLCBz aXplb2Yoc3RydWN0IGluNl9hZGRyKSk7DQogDQogCS8qIFNldCB1cCBmbG93 aSB0ZW1wbGF0ZSAqLw0KLQlmbCA9ICZ0LT5mbDsNCiAJaXB2Nl9hZGRyX2Nv cHkoJmZsLT5mbDZfc3JjLCAmcC0+bGFkZHIpOw0KIAlpcHY2X2FkZHJfY29w eSgmZmwtPmZsNl9kc3QsICZwLT5yYWRkcik7DQogCWZsLT5vaWYgPSBwLT5s aW5rOw0KQEAgLTg4MSwxMCArODI1LDcgQEANCiAJCWlmIChydCA9PSBOVUxM KQ0KIAkJCXJldHVybjsNCiANCi0JCS8qIGFzIGxvbmcgYXMgdHVubmVscyB1 c2UgdGhlIHNhbWUgc29ja2V0IGZvciB0cmFuc21pc3Npb24sDQotCQkgICBs b2NhbGx5IG5lc3RlZCB0dW5uZWxzIHdvbid0IHdvcmsgKi8NCi0JCQ0KLQkJ aWYgKHJ0LT5ydDZpX2RldiAmJiBydC0+cnQ2aV9kZXYtPnR5cGUgIT0gQVJQ SFJEX1RVTk5FTDYpIHsNCisJCWlmIChydC0+cnQ2aV9kZXYpIHsNCiAJCQlk ZXYtPmlmbGluayA9IHJ0LT5ydDZpX2Rldi0+aWZpbmRleDsNCiANCiAJCQlk ZXYtPmhhcmRfaGVhZGVyX2xlbiA9IHJ0LT5ydDZpX2Rldi0+aGFyZF9oZWFk ZXJfbGVuICsNCkBAIC0xMTM5LDcgKzEwODAsNyBAQA0KIGludCBpcDZpcDZf ZmJfdG5sX2Rldl9pbml0KHN0cnVjdCBuZXRfZGV2aWNlICpkZXYpDQogew0K IAlzdHJ1Y3QgaXA2X3RubCAqdCA9IGRldi0+cHJpdjsNCi0JaXA2aXA2X3Ru bF9kZXZfaW5pdF9nZW4oZGV2KTsgDQorCWlwNmlwNl90bmxfZGV2X2luaXRf Z2VuKGRldik7DQogCWRldl9ob2xkKGRldik7DQogCXRubHNfd2NbMF0gPSB0 Ow0KIAlyZXR1cm4gMDsNCkBAIC0xMTU5LDYxICsxMTAwLDI4IEBADQogDQog aW50IF9faW5pdCBpcDZfdHVubmVsX2luaXQodm9pZCkNCiB7DQotCWludCBp LCBqLCBlcnI7DQotCXN0cnVjdCBzb2NrICpzazsNCi0Jc3RydWN0IGlwdjZf cGluZm8gKm5wOw0KLQ0KLQlmb3IgKGkgPSAwOyBpIDwgTlJfQ1BVUzsgaSsr KSB7DQotCQlpZiAoIWNwdV9wb3NzaWJsZShpKSkNCi0JCQljb250aW51ZTsN Ci0NCi0JCWVyciA9IHNvY2tfY3JlYXRlKFBGX0lORVQ2LCBTT0NLX1JBVywg SVBQUk9UT19JUFY2LCANCi0JCQkJICAmX19pcDZfc29ja2V0W2ldKTsNCi0J CWlmIChlcnIgPCAwKSB7DQotCQkJcHJpbnRrKEtFUk5fRVJSIA0KLQkJCSAg ICAgICAiRmFpbGVkIHRvIGNyZWF0ZSB0aGUgSVB2NiB0dW5uZWwgc29ja2V0 ICINCi0JCQkgICAgICAgIihlcnIgJWQpLlxuIiwgDQotCQkJICAgICAgIGVy cik7DQotCQkJZ290byBmYWlsOw0KLQkJfQ0KLQkJc2sgPSBfX2lwNl9zb2Nr ZXRbaV0tPnNrOw0KLQkJc2stPnNrX2FsbG9jYXRpb24gPSBHRlBfQVRPTUlD Ow0KLQ0KLQkJbnAgPSBpbmV0Nl9zayhzayk7DQotCQlucC0+aG9wX2xpbWl0 ID0gMjU1Ow0KLQkJbnAtPm1jX2xvb3AgPSAwOw0KKwlpbnQgIGVycjsNCiAN Ci0JCXNrLT5za19wcm90LT51bmhhc2goc2spOw0KLQl9DQogCWlmICgoZXJy ID0gaW5ldDZfYWRkX3Byb3RvY29sKCZpcDZpcDZfcHJvdG9jb2wsIElQUFJP VE9fSVBWNikpIDwgMCkgew0KIAkJcHJpbnRrKEtFUk5fRVJSICJGYWlsZWQg dG8gcmVnaXN0ZXIgSVB2NiBwcm90b2NvbFxuIik7DQotCQlnb3RvIGZhaWw7 DQorCQlyZXR1cm4gZXJyOw0KIAl9DQotDQotCQ0KIAlpcDZpcDZfZmJfdG5s X2RldiA9IGFsbG9jX25ldGRldihzaXplb2Yoc3RydWN0IGlwNl90bmwpLCAi aXA2dG5sMCIsDQogCQkJCQkgaXA2aXA2X3RubF9kZXZfc2V0dXApOw0KIA0K IAlpZiAoIWlwNmlwNl9mYl90bmxfZGV2KSB7DQogCQllcnIgPSAtRU5PTUVN Ow0KLQkJZ290byB0bmxfZmFpbDsNCisJCWdvdG8gZmFpbDsNCiAJfQ0KIAlp cDZpcDZfZmJfdG5sX2Rldi0+aW5pdCA9IGlwNmlwNl9mYl90bmxfZGV2X2lu aXQ7DQogDQogCWlmICgoZXJyID0gcmVnaXN0ZXJfbmV0ZGV2KGlwNmlwNl9m Yl90bmxfZGV2KSkpIHsNCiAJCWtmcmVlKGlwNmlwNl9mYl90bmxfZGV2KTsN Ci0JCWdvdG8gdG5sX2ZhaWw7DQorCQlnb3RvIGZhaWw7DQogCX0NCiAJcmV0 dXJuIDA7DQotdG5sX2ZhaWw6DQotCWluZXQ2X2RlbF9wcm90b2NvbCgmaXA2 aXA2X3Byb3RvY29sLCBJUFBST1RPX0lQVjYpOw0KIGZhaWw6DQotCWZvciAo aiA9IDA7IGogPCBpOyBqKyspIHsNCi0JCWlmICghY3B1X3Bvc3NpYmxlKGop KQ0KLQkJCWNvbnRpbnVlOw0KLQkJc29ja19yZWxlYXNlKF9faXA2X3NvY2tl dFtqXSk7DQotCQlfX2lwNl9zb2NrZXRbal0gPSBOVUxMOw0KLQl9DQorCWlu ZXQ2X2RlbF9wcm90b2NvbCgmaXA2aXA2X3Byb3RvY29sLCBJUFBST1RPX0lQ VjYpOw0KIAlyZXR1cm4gZXJyOw0KIH0NCiANCkBAIC0xMjIzLDE4ICsxMTMx LDggQEANCiANCiB2b2lkIGlwNl90dW5uZWxfY2xlYW51cCh2b2lkKQ0KIHsN Ci0JaW50IGk7DQotDQogCXVucmVnaXN0ZXJfbmV0ZGV2KGlwNmlwNl9mYl90 bmxfZGV2KTsNCi0NCiAJaW5ldDZfZGVsX3Byb3RvY29sKCZpcDZpcDZfcHJv dG9jb2wsIElQUFJPVE9fSVBWNik7DQotDQotCWZvciAoaSA9IDA7IGkgPCBO Ul9DUFVTOyBpKyspIHsNCi0JCWlmICghY3B1X3Bvc3NpYmxlKGkpKQ0KLQkJ CWNvbnRpbnVlOw0KLQkJc29ja19yZWxlYXNlKF9faXA2X3NvY2tldFtpXSk7 DQotCQlfX2lwNl9zb2NrZXRbaV0gPSBOVUxMOw0KLQl9DQogfQ0KIA0KICNp ZmRlZiBNT0RVTEUNCmRpZmYgLU5ydSBhL25ldC9pcHY2L2lwdjZfc3ltcy5j IGIvbmV0L2lwdjYvaXB2Nl9zeW1zLmMNCi0tLSBhL25ldC9pcHY2L2lwdjZf c3ltcy5jCU1vbiBTZXAgIDEgMDE6NTg6MjMgMjAwMw0KKysrIGIvbmV0L2lw djYvaXB2Nl9zeW1zLmMJTW9uIFNlcCAgMSAwMTo1ODoyMyAyMDAzDQpAQCAt NDUsMyArNDUsNCBAQA0KIEVYUE9SVF9TWU1CT0woaXA2X2FwcGVuZF9kYXRh KTsNCiBFWFBPUlRfU1lNQk9MKGlwNl9mbHVzaF9wZW5kaW5nX2ZyYW1lcyk7 DQogRVhQT1JUX1NZTUJPTChpcDZfcHVzaF9wZW5kaW5nX2ZyYW1lcyk7DQor RVhQT1JUX1NZTUJPTChpcHY2X3B1c2hfbmZyYWdfb3B0cyk7DQo= ---377318441-303137126-1062374223=:26242-- From vnuorval@tcs.hut.fi Sun Aug 31 17:12:09 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 31 Aug 2003 17:12:41 -0700 (PDT) Received: from smtp-3.hut.fi (root@smtp-3.hut.fi [130.233.228.93]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h810C7WZ027612 for ; Sun, 31 Aug 2003 17:12:08 -0700 Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by smtp-3.hut.fi (8.12.9/8.12.9) with ESMTP id h810BwAF008241; Mon, 1 Sep 2003 03:11:59 +0300 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 7E4308001A5; Mon, 1 Sep 2003 03:11:58 +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-6.4) with ESMTP id h810Bw9s026366; Mon, 1 Sep 2003 03:11:58 +0300 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.4) with ESMTP id h810Bwei026362; Mon, 1 Sep 2003 03:11:58 +0300 Date: Mon, 1 Sep 2003 03:11:58 +0300 (EEST) From: Ville Nuorvala To: davem@redhat.com, Cc: netdev@oss.sgi.com Subject: [PATCH] IPv6: (5/5) Allow IPv6 tunnels without own IPv6 address In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-377318441-279846508-1062375118=:26242" X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-3.hut.fi) X-DCC-HUTCC-Metrics: smtp-3.hut.fi 1165; Body=4 Fuz1=4 Fuz2=4 X-archive-position: 5448 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---377318441-279846508-1062375118=:26242 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, unless (link-local) protocols like DHCPv6 or MLD are run over the virtual link formed by IPv6 tunnels, the net_devices representing the tunnels don't necessarily need to have an IPv6 address configured specifically to them. The inet6_dev structure of the device must however be configured for neighbor discovery to work properly, even for IFF_NOARP devices like ip6_tnls. This patch fixes that issue. Please apply! Thanks, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 ---377318441-279846508-1062375118=:26242 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="ip6_tnl_addrconf.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="ip6_tnl_addrconf.patch" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBwYXRjaCBmb3IgdGhl IGZvbGxvd2luZyBwcm9qZWN0Og0KIyBQcm9qZWN0IE5hbWU6IExpbnV4IGtl cm5lbCB0cmVlDQojIFRoaXMgcGF0Y2ggZm9ybWF0IGlzIGludGVuZGVkIGZv ciBHTlUgcGF0Y2ggY29tbWFuZCB2ZXJzaW9uIDIuNSBvciBoaWdoZXIuDQoj IFRoaXMgcGF0Y2ggaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBkZWx0YXM6DQoj CSAgICAgICAgICAgQ2hhbmdlU2V0CTEuMTI3Ni4yOC40IC0+IDEuMTI3Ni4y OC41DQojCSBuZXQvaXB2Ni9hZGRyY29uZi5jCTEuNjMgICAgLT4gMS42NCAg IA0KIw0KIyBUaGUgZm9sbG93aW5nIGlzIHRoZSBCaXRLZWVwZXIgQ2hhbmdl U2V0IExvZw0KIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KIyAwMy8wOS8wMQl2bnVvcnZhbEBkc2wtaGtpZ3cxYThi LmRpYWwuaW5ldC5maQkxLjEyNzYuMjguNQ0KIyBBbGxvdyBhbiBJUHY2LUlQ djYgdHVubmVsIGRldmljZSB0byBzZW5kIHBhY2tldHMgd2l0aG91dCBjb25m aWd1cmluZw0KIyBhIHNlcGFyYXRlIElQdjYgYWRkcmVzcyB0byBpdC4NCiMg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CiMNCmRpZmYgLU5ydSBhL25ldC9pcHY2L2FkZHJjb25mLmMgYi9uZXQvaXB2 Ni9hZGRyY29uZi5jDQotLS0gYS9uZXQvaXB2Ni9hZGRyY29uZi5jCU1vbiBT ZXAgIDEgMDE6NTg6NDUgMjAwMw0KKysrIGIvbmV0L2lwdjYvYWRkcmNvbmYu YwlNb24gU2VwICAxIDAxOjU4OjQ1IDIwMDMNCkBAIC0xODE5LDYgKzE4MTks MjAgQEANCiB9DQogDQogDQorI2lmIGRlZmluZWQoQ09ORklHX0lQVjZfVFVO TkVMKSB8fCBkZWZpbmVkKENPTkZJR19JUFY2X1RVTk5FTF9NT0RVTEUpDQor c3RhdGljIHZvaWQgYWRkcmNvbmZfaXA2X3RubF9jb25maWcoc3RydWN0IG5l dF9kZXZpY2UgKmRldikNCit7DQorCXN0cnVjdCBpbmV0Nl9kZXYgKmlkZXY7 DQorDQorCUFTU0VSVF9SVE5MKCk7DQorDQorCWlmICgoaWRldiA9IGlwdjZf ZmluZF9pZGV2KGRldikpID09IE5VTEwpIHsNCisJCXByaW50ayhLRVJOX0RF QlVHICJpbml0IGlwNi1pcDY6IGZpbmRfZGV2IGZhaWxlZFxuIik7DQorCQly ZXR1cm47DQorCX0NCit9DQorI2VuZGlmDQorDQogaW50IGFkZHJjb25mX25v dGlmeShzdHJ1Y3Qgbm90aWZpZXJfYmxvY2sgKnRoaXMsIHVuc2lnbmVkIGxv bmcgZXZlbnQsIA0KIAkJICAgIHZvaWQgKiBkYXRhKQ0KIHsNCkBAIC0xODMx LDcgKzE4NDUsMTEgQEANCiAJCWNhc2UgQVJQSFJEX1NJVDoNCiAJCQlhZGRy Y29uZl9zaXRfY29uZmlnKGRldik7DQogCQkJYnJlYWs7DQotDQorI2lmIGRl ZmluZWQoQ09ORklHX0lQVjZfVFVOTkVMKSB8fCBkZWZpbmVkKENPTkZJR19J UFY2X1RVTk5FTF9NT0RVTEUpDQorCQljYXNlIEFSUEhSRF9UVU5ORUw2Og0K KwkJCWFkZHJjb25mX2lwNl90bmxfY29uZmlnKGRldik7DQorCQkJYnJlYWs7 DQorI2VuZGlmDQogCQljYXNlIEFSUEhSRF9MT09QQkFDSzoNCiAJCQlpbml0 X2xvb3BiYWNrKGRldik7DQogCQkJYnJlYWs7DQo= ---377318441-279846508-1062375118=:26242-- From jgarzik@pobox.com Sun Aug 31 18:18:54 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 31 Aug 2003 18:19:26 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h811IqWZ012653 for ; Sun, 31 Aug 2003 18:18:53 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:33807 helo=pobox.com) by www.linux.org.uk with esmtp (Exim 4.22) id 19tdLH-0007AC-RL for netdev@oss.sgi.com; Mon, 01 Sep 2003 02:18:51 +0100 Message-ID: <3F529E71.20402@pobox.com> Date: Sun, 31 Aug 2003 21:18:41 -0400 From: Jeff Garzik Organization: none User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: Maillist netdev Subject: So you thought sis190 was evil... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 5449 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 It looks like the objectionable sis190 code was copied almost wholesale from r8169... virt_to_bus, static descriptors, lack of cpu_to_leXX, and all. From yoshfuji@linux-ipv6.org Sun Aug 31 19:23:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 31 Aug 2003 19:24:09 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.5) with SMTP id h812NZWZ021915 for ; Sun, 31 Aug 2003 19:23:36 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h812O91M014248; Mon, 1 Sep 2003 11:24:09 +0900 Date: Mon, 01 Sep 2003 11:24:09 +0900 (JST) Message-Id: <20030901.112409.61391981.yoshfuji@linux-ipv6.org> To: vnuorval@tcs.hut.fi Cc: davem@redhat.com, usagi-core@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [PATCH] IPv6: (5/5) Allow IPv6 tunnels without own IPv6 address From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 5450 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article (at Mon, 1 Sep 2003 03:11:58 +0300 (EEST)), Ville Nuorvala says: > unless (link-local) protocols like DHCPv6 or MLD are run over the virtual > link formed by IPv6 tunnels, the net_devices representing the tunnels > don't necessarily need to have an IPv6 address configured specifically to > them. Wrong. All interfaces have a link-local address. (RFC2462) --yoshfuji From davem@pizda.ninka.net Sun Aug 31 22:54:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 31 Aug 2003 22:54:34 -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.5) with SMTP id h815rxWZ003067 for ; Sun, 31 Aug 2003 22:54:00 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id WAA07288; Sun, 31 Aug 2003 22:44:54 -0700 Date: Sun, 31 Aug 2003 22:44:54 -0700 From: "David S. Miller" To: David Woodhouse Cc: netdev@oss.sgi.com Subject: Re: Missing routes cause BUG() in icmpv6_xmit_lock(). Message-Id: <20030831224454.349a6a53.davem@redhat.com> In-Reply-To: <1062341789.2785.11.camel@imladris.demon.co.uk> References: <1062341789.2785.11.camel@imladris.demon.co.uk> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5451 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sun, 31 Aug 2003 15:56:29 +0100 David Woodhouse wrote: > Attempt to ping6 the router 2002:X:Y::1 from internal host. > Observe panic: http://www.linux.org.uk/~dwmw2/dcp_1575.jpg The per-cpu ICMP6 socket locking is optimized assuming that we'll never reenter the ICMP6 packet sending code on the same processor, this link failure path is causing that to happen. Good thing the BUG() is there, else you'd get a lockup in this case instead which would take us longer to hunt down :-) I'll see what I can do about this one.