Open bugs

[Natalie Protasevich]

Hello,

The bugs listed are over a month old, and haven't been addressed yet.
It would be appreciated if corresponding maintainers identify whether
the bugs have been fixed, or need to be worked on, and take
appropriate action.

In most cases, reporters are standing by and ready to provide
information and necessary testing.
Thanks!


Memory Management===

swapping in 2.6.24-rc5-git3
http://bugzilla.kernel.org/show_bug.cgi?id=9592
Date: 12/07/2007
Regression
Summary:
# /proc/sys/vm# cat swappiness
0
but scp-ing 2GB file causes many processes are swapped out due to
increase of the file cache size.
Was looked at by Jan Kara [EMAIL PROTECTED]; KAMEZAWA Hiroyuki
[EMAIL PROTECTED] - commented


I/O-Storage

SATA DVD drive  UDF filesystem problem
http://bugzilla.kernel.org/show_bug.cgi?id=9668
12/31/2007
Summary: I mount dvd discs (udf) with piix and ide_cd modules without
problem (on hw decribed higher).
Then I put NEC drive to new mainboard (ICH9 + jmicron SATA/PATA chips)
and use ahci (jmicron) + sr_mod modules.


SCSI==

Problems on booting
http://bugzilla.kernel.org/show_bug.cgi?id=9621
Date: 12/22/2007
Regression
Summary: The boot stops / hangs on hardware detection of SCSI.  I have
an InitioINI-9X00U/UW
When I have an usb key sticked in /dev/sba, and run lilo then, then it
dont boot but give L99 99 99 99 ... error


Resetting RAID attached to a FC Switch causes kernel panic and crash
http://bugzilla.kernel.org/show_bug.cgi?id=9598
12/18/2007
Hardware Environment:SunFire X4200 - 2 x dual core AMD Opteron CPUs,
8GB Ram, Qlogic FC adapter.
Summary: Resetting the RAID box causes the X4200 to crash.

3ware 9650SE -8LPML not recognized by 3w-9xxx driver
http://bugzilla.kernel.org/show_bug.cgi?id=8908
08/19/2007
Problem Description: The 3w-9xxx kernel driver for 3ware 9xxx SATA
RAID Controller series did not recognize the 3ware 9650SE-8LPML SATA
RAID Controller.


Plarform===

kexec buffer error
http://bugzilla.kernel.org/show_bug.cgi?id=9693
Date: 01/04/2008
Regression
Summary: Close of /boot/kernel-2.6.24-rc6-git11 failed: : buffer error
kexec load failed, error = 1


2+ wake-ups/second in 2.6.24
http://bugzilla.kernel.org/show_bug.cgi?id=9489
Date: 12/02/2007
Summary: something is causing the system to go into a state where
the cpu throws us right out of the C-state the kernel asks for
Discussed: Arjan van de Ven, Mark Lord


VIDEO/FB==

No text consoles with FRAMEBUFFER_CONSOLE_DETECT_PRIMARY
http://bugzilla.kernel.org/show_bug.cgi?id=9310
11/05/2007 still there
Regression
Summary: After initial boot messages all output to console stops. The
last visible messages are:
checking if image is initramfs...6Switched to high resolution mode on CPU 1
Switched to high resolution mode on CPU 0
After that, nothing until XOrg starts up and graphical login/desktop
on VT7are displayed normal.


DVB===

DVB-T Pluto2: SUSPEND/RESUME methods are missing for this driver
04/05/2007 - still present in 2.6.24
http://bugzilla.kernel.org/show_bug.cgi?id=8304
Summary: After SWSUPS resume, pluto2 card is not started properly, led
getts not green and card is unable load tda firmware
Hardware Environment: Acer TravelMate
No one looked at it yet.

Several Pluto bug:

DVB-T Pluto2  PCI: When playing in dmesg I often getts: pluto2
:03:00.0: overflow irq (10)
Date: 11/08/2006 still there
http://bugzilla.kernel.org/show_bug.cgi?id=7473
Hardware Environment: Acer TravelMate


DVB-T Pluto2: Getting tons of card hung up :( messages when card is
removed from pcmcia slot
Date: 11/08/2006 - still there
http://bugzilla.kernel.org/show_bug.cgi?id=7472


DVB-T Pluto2: Unable to change MUX
Date: 11/08/2006
http://bugzilla.kernel.org/show_bug.cgi?id=7471


KNC1 DVB-C cam module not working on driver load
Date: 1/15/2007 - still there
http://bugzilla.kernel.org/show_bug.cgi?id=7825
Error:
DVB: registering new adapter (KNC1 DVB-C)
adapter failed MAC signature check
encoded MAC from EEPROM was
ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff
KNC1-0: MAC addr = 00:09:d6:6d:5a:f0
TDA10021: i2c-addr = 0x0c, id = 0x7c
DVB: registering frontend 0 (Philips TDA10021 DVB-C)...
budget-av: ci interface initialised.
budget-av: cam inserted A
dvb_ca adaptor 0: PC card did not respond :(


build #341 failed for 2.6.24-rc6-g1842c7f in
linux/./drivers/media/dvb/ttpci/budget-av.c
01/01/2008
http://bugzilla.kernel.org/show_bug.cgi?id=9671
Still there in 2.6.24.. has it been fixed?


DVB-USB UMT-010 driver has certain oops when installed
01/09/2008
http://bugzilla.kernel.org/show_bug.cgi?id=9720
In the umt-010 driver the struct umt_properties sets the number of
URBs for transfer to 20.
But in dvb-usb.h MAX_NO_URBS_FOR_DATA_STREAM is set to 10. This causes
an oops 

[PATCH] trivial: fix alignment of IP-Config output

[Uwe Kleine-König]

make the intended lines aligned in the output (not in the code)

Signed-off-by: Uwe Kleine-König [EMAIL PROTECTED]
---
 net/ipv4/ipconfig.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index a52b585..10013cc 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -1390,7 +1390,7 @@ static int __init ip_auto_config(void)
 * Clue in the operator.
 */
printk(IP-Config: Complete:);
-   printk(\n  device=%s, ic_dev-name);
+   printk(\n device=%s, ic_dev-name);
printk(, addr=%u.%u.%u.%u, NIPQUAD(ic_myaddr));
printk(, mask=%u.%u.%u.%u, NIPQUAD(ic_netmask));
printk(, gw=%u.%u.%u.%u, NIPQUAD(ic_gateway));
-- 
1.5.4

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH][AX25] ax25_route: make ax25_route_lock BH safe

[Jann Traschewski]

Applied on 2.6.24.2 and up without any problems/warnings since 12 hours.
Thanks,
Jann

 -Ursprüngliche Nachricht-
 Von: Jarek Poplawski [mailto:[EMAIL PROTECTED] 
 Gesendet: Montag, 11. Februar 2008 13:43
 An: David Miller
 Cc: Jann Traschewski; Bernard Pidoux F6BVP; Ralf Baechle 
 DL5RB; netdev@vger.kernel.org
 Betreff: [PATCH][AX25] ax25_route: make ax25_route_lock BH safe
 
 
 Subject: [AX25] ax25_route: make ax25_route_lock BH safe
 
  =
  [ INFO: inconsistent lock state ]
  2.6.24-dg8ngn-p02 #1
  -
  inconsistent {softirq-on-W} - {in-softirq-R} usage.
  linuxnet/3046 [HC0[0]:SC1[2]:HE1:SE0] takes:
   (ax25_route_lock){--.+}, at: [f8a0cfb7] ax25_get_route+0x18/0xb7 
  [ax25] {softirq-on-W} state was registered at:
 ...
 
 This lockdep report shows that ax25_route_lock is taken for 
 reading in softirq context, and for writing in process 
 context with BHs enabled.
 So, to make this safe, all write_locks in ax25_route.c are 
 changed to _bh versions.
 
 
 Reported-by: Jann Traschewski [EMAIL PROTECTED],
 Signed-off-by: Jarek Poplawski [EMAIL PROTECTED]
 
 ---
 
 diff -Nurp 2.6.24-mm1-/net/ax25/ax25_route.c 
 2.6.24-mm1+/net/ax25/ax25_route.c
 --- 2.6.24-mm1-/net/ax25/ax25_route.c 2008-02-05 
 07:45:38.0 +
 +++ 2.6.24-mm1+/net/ax25/ax25_route.c 2008-02-11 
 11:58:47.0 +
 @@ -45,7 +45,7 @@ void ax25_rt_device_down(struct net_devi  {
   ax25_route *s, *t, *ax25_rt;
  
 - write_lock(ax25_route_lock);
 + write_lock_bh(ax25_route_lock);
   ax25_rt = ax25_route_list;
   while (ax25_rt != NULL) {
   s   = ax25_rt;
 @@ -68,7 +68,7 @@ void ax25_rt_device_down(struct net_devi
   }
   }
   }
 - write_unlock(ax25_route_lock);
 + write_unlock_bh(ax25_route_lock);
  }
  
  static int __must_check ax25_rt_add(struct 
 ax25_routes_struct *route) @@ -82,7 +82,7 @@ static int 
 __must_check ax25_rt_add(stru
   if (route-digi_count  AX25_MAX_DIGIS)
   return -EINVAL;
  
 - write_lock(ax25_route_lock);
 + write_lock_bh(ax25_route_lock);
  
   ax25_rt = ax25_route_list;
   while (ax25_rt != NULL) {
 @@ -92,7 +92,7 @@ static int __must_check ax25_rt_add(stru
   ax25_rt-digipeat = NULL;
   if (route-digi_count != 0) {
   if ((ax25_rt-digipeat = 
 kmalloc(sizeof(ax25_digi), GFP_ATOMIC)) == NULL) {
 - write_unlock(ax25_route_lock);
 + 
 write_unlock_bh(ax25_route_lock);
   return -ENOMEM;
   }
   ax25_rt-digipeat-lastrepeat = 
 -1; @@ -102,14 +102,14 @@ static int __must_check ax25_rt_add(stru
   
 ax25_rt-digipeat-calls[i]= route-digi_addr[i];
   }
   }
 - write_unlock(ax25_route_lock);
 + write_unlock_bh(ax25_route_lock);
   return 0;
   }
   ax25_rt = ax25_rt-next;
   }
  
   if ((ax25_rt = kmalloc(sizeof(ax25_route), GFP_ATOMIC)) 
 == NULL) {
 - write_unlock(ax25_route_lock);
 + write_unlock_bh(ax25_route_lock);
   return -ENOMEM;
   }
  
 @@ -120,7 +120,7 @@ static int __must_check ax25_rt_add(stru
   ax25_rt-ip_mode  = ' ';
   if (route-digi_count != 0) {
   if ((ax25_rt-digipeat = 
 kmalloc(sizeof(ax25_digi), GFP_ATOMIC)) == NULL) {
 - write_unlock(ax25_route_lock);
 + write_unlock_bh(ax25_route_lock);
   kfree(ax25_rt);
   return -ENOMEM;
   }
 @@ -133,7 +133,7 @@ static int __must_check ax25_rt_add(stru
   }
   ax25_rt-next   = ax25_route_list;
   ax25_route_list = ax25_rt;
 - write_unlock(ax25_route_lock);
 + write_unlock_bh(ax25_route_lock);
  
   return 0;
  }
 @@ -152,7 +152,7 @@ static int ax25_rt_del(struct ax25_route
   if ((ax25_dev = ax25_addr_ax25dev(route-port_addr)) == NULL)
   return -EINVAL;
  
 - write_lock(ax25_route_lock);
 + write_lock_bh(ax25_route_lock);
  
   ax25_rt = ax25_route_list;
   while (ax25_rt != NULL) {
 @@ -174,7 +174,7 @@ static int ax25_rt_del(struct ax25_route
   }
   }
   }
 - write_unlock(ax25_route_lock);
 + write_unlock_bh(ax25_route_lock);
  
   return 0;
  }
 @@ -188,7 +188,7 @@ static int ax25_rt_opt(struct ax25_route
   if ((ax25_dev = 
 ax25_addr_ax25dev(rt_option-port_addr)) == NULL)
   return -EINVAL;
  
 - write_lock(ax25_route_lock);
 + write_lock_bh(ax25_route_lock);
  
   ax25_rt = ax25_route_list;
   while (ax25_rt != NULL) {
 @@ -216,7 +216,7 @@ static int 

Re: [PATCH] fib_trie: rcu_assign_pointer warning fix

[Jarek Poplawski]

On 12-02-2008 02:16, David Miller wrote:
 From: Stephen Hemminger [EMAIL PROTECTED]
 Date: Mon, 11 Feb 2008 16:59:54 -0800
 
 linux-kernel added to CC:, any change to generic kernel infrastructure
 should be posted there
 
 Eliminate warnings when rcu_assign_pointer is used with unsigned long.
 It is reasonable to use RCU with non-pointer values so allow it for general
 use.  Add a comment to explain the if test.

 Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
 ---
  include/linux/rcupdate.h |   13 +++--
  1 files changed, 7 insertions(+), 6 deletions(-)

 diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
 index 37a642c..c44ac87 100644
 --- a/include/linux/rcupdate.h
 +++ b/include/linux/rcupdate.h
 @@ -172,14 +172,15 @@ struct rcu_head {
   * structure after the pointer assignment.  More importantly, this
   * call documents which pointers will be dereferenced by RCU read-side
   * code.
 + *
 + * If value is the NULL (constant 0), then no barrier is needed.
   */
  
 -#define rcu_assign_pointer(p, v) \
 -({ \
 -if (!__builtin_constant_p(v) || \
 -((v) != NULL)) \
 -smp_wmb(); \
 -(p) = (v); \
 +#define rcu_assign_pointer(p, v)\
 +({  \
 +if (!(__builtin_constant_p(v)  v))\

...But, If value is the NULL (constant 0) we have:

if (!(1  NULL != 0)) == if (!(0)) and the barrier is used?!

 +smp_wmb();  \
 +(p) = (v);  \
  })
  
  /**


Regards,
Jarek P.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [IPV4]: Remove warning in node_set_parent.

[Denis V. Lunev]

ugly :), but

Acked-by: Denis V. Lunev [EMAIL PROTECTED]

On Mon, 2008-02-11 at 11:48 -0800, Stephen Hemminger wrote:
 On Mon, 11 Feb 2008 11:47:17 +0300
 Denis V. Lunev [EMAIL PROTECTED] wrote:
 
  net/ipv4/fib_trie.c: In function 'node_set_parent':
  net/ipv4/fib_trie.c:184: warning: assignment makes integer from pointer
  without a cast
  
  Signed-off-by: Denis V. Lunev [EMAIL PROTECTED]
  ---
   net/ipv4/fib_trie.c |7 ---
   1 files changed, 4 insertions(+), 3 deletions(-)
  
  diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
  index f5fba3f..1753cd4 100644
  --- a/net/ipv4/fib_trie.c
  +++ b/net/ipv4/fib_trie.c
  @@ -177,10 +177,11 @@ static inline struct tnode *node_parent_rcu(struct 
  node *node)
  return rcu_dereference(ret);
   }
   
  -static inline void node_set_parent(struct node *node, struct tnode *ptr)
  +static inline void node_set_parent(struct node *node, struct tnode *__ptr)
   {
  -   rcu_assign_pointer(node-parent,
  -  (unsigned long)ptr | NODE_TYPE(node));
  +   struct node *ptr;
  +   ptr = (struct node *)((unsigned long)__ptr | NODE_TYPE(node));
  +   rcu_assign_pointer(node-parent, ptr);
   }
   
   static inline struct node *tnode_get_child(struct tnode *tn, unsigned int 
  i)
 
 No, this causes new warning from assigning pointer (ptr) to integer 
 node-parent.
 
 Why not just change rcupdate.h to do the right thing.
 
 From a00f7cbf1c2f2282eced236e1e8b99b0fecd213a Mon Sep 17 00:00:00 2001
 From: Stephen Hemminger [EMAIL PROTECTED]
 Date: Mon, 11 Feb 2008 11:28:13 -0800
 Subject: [PATCH] eliminate warnings when rcu_assign_pointer is used with 
 unsigned long
 
 It is reasonable to use RCU with non-pointer values, and describe
 the optimization.
 
 Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
 ---
  include/linux/rcupdate.h |   13 +++--
  1 files changed, 7 insertions(+), 6 deletions(-)
 
 diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
 index 37a642c..c44ac87 100644
 --- a/include/linux/rcupdate.h
 +++ b/include/linux/rcupdate.h
 @@ -172,14 +172,15 @@ struct rcu_head {
   * structure after the pointer assignment.  More importantly, this
   * call documents which pointers will be dereferenced by RCU read-side
   * code.
 + *
 + * If value is the NULL (constant 0), then no barrier is needed.
   */
  
 -#define rcu_assign_pointer(p, v) \
 - ({ \
 - if (!__builtin_constant_p(v) || \
 - ((v) != NULL)) \
 - smp_wmb(); \
 - (p) = (v); \
 +#define rcu_assign_pointer(p, v) \
 + ({  \
 + if (!(__builtin_constant_p(v)  v))\
 + smp_wmb();  \
 + (p) = (v);  \
   })
  
  /**
 -- 
 1.5.3.8
 
 
 
 

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH][AX25] ax25_route: make ax25_route_lock BH safe

[Jarek Poplawski]

On Tue, Feb 12, 2008 at 09:43:26AM +0100, Jann Traschewski wrote:
 Applied on 2.6.24.2 and up without any problems/warnings since 12 hours.
 Thanks,
 Jann

Thanks Jann, too!

BTW, I hope maybe until tomorrow I'll figure out something about those
earlier two AX25 testing patches.

Regards,
Jarek P.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] 2.6.25-rc1 ml4x network driver build failure

[Kamalesh Babulal]

The 2.6.25-rc1 kernel build fails on the powerpc with the error

drivers/net/mlx4/alloc.c: In function ‘mlx4_buf_alloc’:
drivers/net/mlx4/alloc.c:162: error: implicit declaration of function ‘vmap’
drivers/net/mlx4/alloc.c:162: error: ‘VM_MAP’ undeclared (first use in this 
function)
drivers/net/mlx4/alloc.c:162: error: (Each undeclared identifier is reported 
only once
drivers/net/mlx4/alloc.c:162: error: for each function it appears in.)
drivers/net/mlx4/alloc.c:162: warning: assignment makes pointer from integer 
without a cast
drivers/net/mlx4/alloc.c: In function ‘mlx4_buf_free’:
drivers/net/mlx4/alloc.c:187: error: implicit declaration of function ‘vunmap’
make[3]: *** [drivers/net/mlx4/alloc.o] Error 1
make[2]: *** [drivers/net/mlx4] Error 2
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2

I have tested the patch for the build failure.

Signed-off-by: Kamalesh Babulal [EMAIL PROTECTED]
--
--- linux-2.6.25-rc1/drivers/net/mlx4/alloc.c   2008-02-11 03:48:14.0 
+0530
+++ linux-2.6.25-rc1/drivers/net/mlx4/~alloc.c  2008-02-12 14:43:46.0 
+0530
@@ -34,6 +34,7 @@
 #include linux/slab.h
 #include linux/bitmap.h
 #include linux/dma-mapping.h
+#include linux/vmalloc.h
 
 #include mlx4.h
 
-- 
Thanks  Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bugme-new] [Bug 9940] New: e1000e driver with 82566DM-2 controller doesn't strip crc from frames

[Andrew Morton]

On Tue, 12 Feb 2008 01:50:49 -0800 (PST) [EMAIL PROTECTED] wrote:

 http://bugzilla.kernel.org/show_bug.cgi?id=9940
 
Summary: e1000e driver with 82566DM-2 controller doesn't strip
 crc from frames
Product: Drivers
Version: 2.5
  KernelVersion: 2.6.24
   Platform: All
 OS/Version: Linux
   Tree: Mainline
 Status: NEW
   Severity: normal
   Priority: P1
  Component: Network
 AssignedTo: [EMAIL PROTECTED]
 ReportedBy: [EMAIL PROTECTED]
 
 
 Latest working kernel version: n/a
 Earliest failing kernel version: 2.6.24
 Distribution: Gentoo 2007.0
 Hardware Environment: HP Compaq dc7800p
 Software Environment: n/a
 Problem Description:
 The e1000e driver doesn't strip the ethernet frame crc is used with the
 82566DM-2 chip.
 This will result, among other things, that bridging doesn't work together with
 this chip.
 Reverting commit 140a74802894e9db57e5cd77ccff77e590ece5f3 fixes this issue but
 has performance implications.
 
 Steps to reproduce:
 Send a ping and monitor the responce with tcpdump.
 

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Bug 9750] [patch 2.6.25] dev: avoid a race that triggers assertion failure

[Matti Linnanvuori]

From: Matti Linnanvuori [EMAIL PROTECTED]

There is a race in Linux kernel file net/core/dev.c, function dev_close.
The function calls function dev_deactivate, which calls function
dev_watchdog_down that deletes the watchdog timer. However, after that, a
driver can call netif_carrier_ok, which calls function
__netdev_watchdog_up that can add the watchdog timer again. Function
unregister_netdevice calls function dev_shutdown that traps the bug
!timer_pending(dev-watchdog_timer). Moving dev_deactivate after
netif_running() has been cleared prevents function netif_carrier_on
from calling __netdev_watchdog_up and adding the watchdog timer again.

Signed-off-by: Matti Linnanvuori [EMAIL PROTECTED]

---

--- linux-2.6.25/net/core/dev.c2008-02-12 12:37:51.206833000 +0200
+++ b/net/core/dev.c2008-02-12 12:38:48.727611400 +0200
@@ -1071,8 +1071,6 @@ int dev_close(struct net_device *dev)
  */
 call_netdevice_notifiers(NETDEV_GOING_DOWN, dev);
 
-dev_deactivate(dev);
-
 clear_bit(__LINK_STATE_START, dev-state);
 
 /* Synchronize to scheduled poll. We cannot touch poll list,
@@ -1083,6 +1081,7 @@ int dev_close(struct net_device *dev)
  */
 smp_mb__after_clear_bit(); /* Commit netif_running(). */
 
+dev_deactivate(dev);
 /*
  *Call the device specific close. This cannot fail.
  *Only if device is UP





  

Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Open bugs

[Natalie Protasevich]

On Feb 12, 2008 9:57 AM, James Bottomley
[EMAIL PROTECTED] wrote:
 Added linux-scsi for the SCSI ones

 On Tue, 2008-02-12 at 00:18 -0800, Natalie Protasevich wrote:
  Hello,
 
  The bugs listed are over a month old, and haven't been addressed yet.
  It would be appreciated if corresponding maintainers identify whether
  the bugs have been fixed, or need to be worked on, and take
  appropriate action.
 
  In most cases, reporters are standing by and ready to provide
  information and necessary testing.
  Thanks!
 
  SCSI==
 
  Problems on booting
  http://bugzilla.kernel.org/show_bug.cgi?id=9621
  Date: 12/22/2007
  Regression
  Summary: The boot stops / hangs on hardware detection of SCSI.  I have
  an InitioINI-9X00U/UW
  When I have an usb key sticked in /dev/sba, and run lilo then, then it
  dont boot but give L99 99 99 99 ... error

 I think this was fixed by commit
 e2d435ea4084022ab88efa74214accb45b1f9e92

 Apparently bugzilla email is on the fritz again because this bug report
 didn't come across linux-scsi.

I just fixed that, thanks. It was incorrect assign-to party.


  Resetting RAID attached to a FC Switch causes kernel panic and crash
  http://bugzilla.kernel.org/show_bug.cgi?id=9598
  12/18/2007
  Hardware Environment:SunFire X4200 - 2 x dual core AMD Opteron CPUs,
  8GB Ram, Qlogic FC adapter.
  Summary: Resetting the RAID box causes the X4200 to crash.

 This one looks like the usual problem of remove re-add with the SCSI
 device model.

  3ware 9650SE -8LPML not recognized by 3w-9xxx driver
  http://bugzilla.kernel.org/show_bug.cgi?id=8908
  08/19/2007
  Problem Description: The 3w-9xxx kernel driver for 3ware 9xxx SATA
  RAID Controller series did not recognize the 3ware 9650SE-8LPML SATA
  RAID Controller.

 Since this one never apparently worked it's not a regression but an
 enhancement request, isn't it?

No this is not a regression. The bug list that I post is just any bugs
(mostly unattended or stalled). Sometimes those are regressions off of
the Raphael's list, when they don't get resolved for a while, or just
random regressions that haven't showed up on the hot list by
Raphael.


 However, adding this PCI ID to the driver should be fairly
 straightforward.  Does anyone know what the actual PCI IDs are?

I just asked the reporter to provide this information, thanks.


 James


--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add IPv6 support to TCP SYN cookies

[Ross Vandegrift]

On Fri, Feb 08, 2008 at 01:07:46PM +0100, Andi Kleen wrote:
 On Thu, Feb 07, 2008 at 02:44:46PM -0500, Ross Vandegrift wrote:
  On Wed, Feb 06, 2008 at 09:53:57AM +0100, Andi Kleen wrote:
  My initial test is end-to-end 1000Mbps, but I've got a few different
  packet rates.
  
   If the young/old heuristics do not work well enough anymore most
   likely we should try readding RED to the syn queue again. That used
   to be pretty effective in the early days. I don't quite remember why
   Linux didn't end up using it in fact.
  
  I'm running juno-z with 2, 4,  8 threads of syn flood to port 80.
  wireshark measures 2 threads at 350pps, 4 threads at 750pps, and 8
 
 What's the total bandwidth of the attack?

Sorry for the delay in getting back to you on this Andi.

Here's a breakdown for each attack of the pps and bandwidth:

packets/s   Mb/s

380 0.182 
715 0.343
11930.572
16460   7.896

The first three tests were done with some fixed delay inbetween syn
floods.  The last is done with all delays as small as possible.


  threads at 1200pps.  Under no SYN flood, the server handles 750 HTTP
  requests per second, measured via httping in flood mode.
 
 Thanks for the tests. Could you please do an additional experiment? 
 Use sch_em or similar to add a jittering longer latency in the connection
 (as would be realistic in a real distributed DOS). Does it make a
 difference? 

Jitter on both ends makes it worse.  Jitter only on the syn flooder
end behaves approximately the same.

If I add jitter to both the flooder and the target with:
tc qdisc add dev eth0 root netem delay 50ms 100ms distribution normal
I can kill off the host with even a single thread of syn flooding,
even with a backlog queue size of 32768.


  With a default tcp_max_syn_backlog of 1024, I can trivially prevent
  any inbound client connections with 2 threads of syn flood.
  Enabling tcp_syncookies brings the connection handling back up to 725
  fetches per second.
 
 Yes the defaults are probably too low. That's something that should
 be fixed.

Yea, with a longer queue, the server is somewhat more resiliant.  But
it's still pretty easy to overwhelm it.  syncookies is a night and day
difference.


  At these levels the CPU impact of tcp_syncookies is nothing.  I can't
 
 CPU impact of syncookies was never a concern. The problems are rather
 missing flow control and disabling of valuable TCP features.

Oh definitely - Willy raised the CPU issue in another mail, I was just
including my findings with a bigger CPU.

In general I agree with you for the TCP features, but in the cases where
we're enabling syncookies, it's the difference between bad connectivity and
no connectivity.

-- 
Ross Vandegrift
[EMAIL PROTECTED]

The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell.
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: E1000 (PCI-E) doesn't work on nforce430, MSI issue.

[Prakash Punnoor]

On the day of Tuesday 12 February 2008 Krzysztof Halasa hast written:
 Hi,

 Is it a known problem?
 Linux 2.6.24.2, ASUS M2NPV-MX mobo, nforce 430 based, two PCI-E x1
 E1000 cards, 32-bit kernel, default e1000 driver (PCI IDs disabled in
 e1000e).

 Don't work by default. pci=nomsi fixes the problem.

Probably the patch to enable msi bit on the host bridge(?) is still missing in 
mainline. I needed that patch to make msi work on my MCP51 system.

-- 
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V


signature.asc
Description: This is a digitally signed message part.

[PATCH] e1000e: Fix CRC stripping in hardware context bug

[Auke Kok]

CRC stripping was only correctly enabled for packet split recieves
which is used when receiving jumbo frames. Correctly enable SECRC
also for normal buffer packet receives.

Tested by Andy Gospodarek and Johan Andersson, see bugzilla #9940.

Signed-off-by: Auke Kok [EMAIL PROTECTED]
---

 drivers/net/e1000e/netdev.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index b9b0d32..ea4ecc3 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -1690,6 +1690,9 @@ static void e1000_setup_rctl(struct e1000_adapter 
*adapter)
else
rctl |= E1000_RCTL_LPE;
 
+   /* Enable hardware CRC frame stripping */
+   rctl |= E1000_RCTL_SECRC;
+
/* Setup buffer sizes */
rctl = ~E1000_RCTL_SZ_4096;
rctl |= E1000_RCTL_BSEX;
@@ -1755,9 +1758,6 @@ static void e1000_setup_rctl(struct e1000_adapter 
*adapter)
 
/* Enable Packet split descriptors */
rctl |= E1000_RCTL_DTYP_PS;
-   
-   /* Enable hardware CRC frame stripping */
-   rctl |= E1000_RCTL_SECRC;
 
psrctl |= adapter-rx_ps_bsize0 
E1000_PSRCTL_BSIZE0_SHIFT;

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ixgbe: Correctly obtain protocol information on transmit

[Auke Kok]

In reply to RE: [Fwd: [PATCH 2.6.25] ixgbe/igb: correctly obtain protocol
information on transmit] from Andy Gospodarek:

The driver was incorrectly looking at socket headers for
protocol information, needed for checksumming offload. Fix
this by not looking at the socket but frame headers instead.

This disregards extension headers but it's unclear that linux
generates those anyway.

Tested by Andy Gospodarek.

Signed-off-by: Auke Kok [EMAIL PROTECTED]
---

 drivers/net/ixgbe/ixgbe_main.c |   24 +---
 1 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index 540b647..23d0a4a 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -2277,11 +2277,29 @@ static bool ixgbe_tx_csum(struct ixgbe_adapter *adapter,
IXGBE_ADVTXD_DTYP_CTXT);
 
if (skb-ip_summed == CHECKSUM_PARTIAL) {
-   if (skb-protocol == htons(ETH_P_IP))
+   switch (skb-protocol) {
+   case __constant_htons(ETH_P_IP):
type_tucmd_mlhl |= IXGBE_ADVTXD_TUCMD_IPV4;
+   if (ip_hdr(skb)-protocol == IPPROTO_TCP)
+   type_tucmd_mlhl |=
+   IXGBE_ADVTXD_TUCMD_L4T_TCP;
+   break;
+
+   case __constant_htons(ETH_P_IPV6):
+   /* XXX what about other V6 headers?? */
+   if (ipv6_hdr(skb)-nexthdr == IPPROTO_TCP)
+   type_tucmd_mlhl |=
+   IXGBE_ADVTXD_TUCMD_L4T_TCP;
+   break;
 
-   if (skb-sk-sk_protocol == IPPROTO_TCP)
-   type_tucmd_mlhl |= IXGBE_ADVTXD_TUCMD_L4T_TCP;
+   default:
+   if (unlikely(net_ratelimit())) {
+   DPRINTK(PROBE, WARNING,
+partial checksum but proto=%x!\n,
+skb-protocol);
+   }
+   break;
+   }
}
 
context_desc-type_tucmd_mlhl = cpu_to_le32(type_tucmd_mlhl);

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] libertas: Remove unused exports

[Roland Dreier]

The libertas driver exports a number of symbols with no in-tree
users; remove these unused exports.  lbs_reset_device() is completely
unused, with no callers at all, so remove the function completely.

A couple of these unused exported symbols are static, which causes the
following build error on ia64 with gcc 4.2.3:

drivers/net/wireless/libertas/main.c:1375: error: __ksymtab_lbs_remove_mesh 
causes a section type conflict
drivers/net/wireless/libertas/main.c:1354: error: __ksymtab_lbs_add_mesh 
causes a section type conflict

This patch fixes this problem.  I don't have hardware, so this is not
run-tested, but I tested the build with

CONFIG_LIBERTAS=y
CONFIG_LIBERTAS_USB=m
CONFIG_LIBERTAS_CS=m
CONFIG_LIBERTAS_SDIO=m

and there were no problems with undefined symbols.

Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
Here's the patch that removes the unused exports (and a few more that
I found).

diff --git a/drivers/net/wireless/libertas/cmd.c 
b/drivers/net/wireless/libertas/cmd.c
index eab0203..b3c1acb 100644
--- a/drivers/net/wireless/libertas/cmd.c
+++ b/drivers/net/wireless/libertas/cmd.c
@@ -1040,7 +1040,6 @@ int lbs_mesh_access(struct lbs_private *priv, uint16_t 
cmd_action,
lbs_deb_leave(LBS_DEB_CMD);
return ret;
 }
-EXPORT_SYMBOL_GPL(lbs_mesh_access);
 
 int lbs_mesh_config(struct lbs_private *priv, uint16_t enable, uint16_t chan)
 {
@@ -1576,7 +1575,6 @@ done:
lbs_deb_leave_args(LBS_DEB_HOST, ret %d, ret);
return ret;
 }
-EXPORT_SYMBOL_GPL(lbs_prepare_and_send_command);
 
 /**
  *  @brief This function allocates the command buffer and link
diff --git a/drivers/net/wireless/libertas/decl.h 
b/drivers/net/wireless/libertas/decl.h
index aaacd9b..4e22341 100644
--- a/drivers/net/wireless/libertas/decl.h
+++ b/drivers/net/wireless/libertas/decl.h
@@ -69,7 +69,6 @@ struct lbs_private *lbs_add_card(void *card, struct device 
*dmdev);
 int lbs_remove_card(struct lbs_private *priv);
 int lbs_start_card(struct lbs_private *priv);
 int lbs_stop_card(struct lbs_private *priv);
-int lbs_reset_device(struct lbs_private *priv);
 void lbs_host_to_card_done(struct lbs_private *priv);
 
 int lbs_update_channel(struct lbs_private *priv);
diff --git a/drivers/net/wireless/libertas/main.c 
b/drivers/net/wireless/libertas/main.c
index 84fb49c..1eaf6af 100644
--- a/drivers/net/wireless/libertas/main.c
+++ b/drivers/net/wireless/libertas/main.c
@@ -1351,8 +1350,6 @@ done:
lbs_deb_leave_args(LBS_DEB_MESH, ret %d, ret);
return ret;
 }
-EXPORT_SYMBOL_GPL(lbs_add_mesh);
-
 
 static void lbs_remove_mesh(struct lbs_private *priv)
 {
@@ -1372,7 +1369,6 @@ static void lbs_remove_mesh(struct lbs_private *priv)
free_netdev(mesh_dev);
lbs_deb_leave(LBS_DEB_MESH);
 }
-EXPORT_SYMBOL_GPL(lbs_remove_mesh);
 
 /**
  *  @brief This function finds the CFP in
@@ -1458,20 +1454,6 @@ void lbs_interrupt(struct lbs_private *priv)
 }
 EXPORT_SYMBOL_GPL(lbs_interrupt);
 
-int lbs_reset_device(struct lbs_private *priv)
-{
-   int ret;
-
-   lbs_deb_enter(LBS_DEB_MAIN);
-   ret = lbs_prepare_and_send_command(priv, CMD_802_11_RESET,
-   CMD_ACT_HALT, 0, 0, NULL);
-   msleep_interruptible(10);
-
-   lbs_deb_leave_args(LBS_DEB_MAIN, ret %d, ret);
-   return ret;
-}
-EXPORT_SYMBOL_GPL(lbs_reset_device);
-
 static int __init lbs_init_module(void)
 {
lbs_deb_enter(LBS_DEB_MAIN);
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/4] hlist_for_each_entry_continue simplification

[Stephen Hemminger]

All the users of hlist_for_each_entry_continue had to intialize pos
before use; change API so pos is a pure temporary variable which matches
the usage of other _for_each_entry routines.

Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]

--- a/include/linux/list.h  2008-02-12 15:09:17.0 -0800
+++ b/include/linux/list.h  2008-02-12 15:09:53.0 -0800
@@ -944,7 +944,7 @@ static inline void hlist_add_after_rcu(s
  * @member:the name of the hlist_node within the struct.
  */
 #define hlist_for_each_entry_continue(tpos, pos, member)\
-   for (pos = (pos)-next;  \
+   for (pos = (tpos)-member.next;  \
 pos  ({ prefetch(pos-next); 1;})   \
({ tpos = hlist_entry(pos, typeof(*tpos), member); 1;}); \
 pos = pos-next)
@@ -999,7 +999,7 @@ static inline void hlist_add_after_rcu(s
  * @member:the name of the hlist_node within the struct.
  */
 #define hlist_for_each_entry_continue_rcu(tpos, pos, member)   \
-   for (pos = (pos)-next; \
+   for (pos = (tpos)-member.next; \
 rcu_dereference(pos)  ({ prefetch(pos-next); 1;}) \
 ({ tpos = hlist_entry(pos, typeof(*tpos), member); 1;}); \
 pos = pos-next)
--- a/include/net/sock.h2008-02-12 15:09:17.0 -0800
+++ b/include/net/sock.h2008-02-12 15:09:53.0 -0800
@@ -381,7 +381,7 @@ static __inline__ void sk_add_bind_node(
if (__sk  ({ node = (__sk)-sk_node; 1; })) \
hlist_for_each_entry_from(__sk, node, sk_node)
 #define sk_for_each_continue(__sk, node) \
-   if (__sk  ({ node = (__sk)-sk_node; 1; })) \
+   if (__sk) \
hlist_for_each_entry_continue(__sk, node, sk_node)
 #define sk_for_each_safe(__sk, node, tmp, list) \
hlist_for_each_entry_safe(__sk, node, tmp, list, sk_node)
--- a/net/ipv4/fib_hash.c   2008-02-12 15:09:17.0 -0800
+++ b/net/ipv4/fib_hash.c   2008-02-12 15:09:53.0 -0800
@@ -883,7 +883,7 @@ static struct fib_alias *fib_get_next(st
 
/* Advance FN. */
if (fn) {
-   struct hlist_node *node = fn-fn_hash;
+   struct hlist_node *node;
hlist_for_each_entry_continue(fn, node, fn_hash) {
iter-fn = fn;
 
--- a/net/xfrm/xfrm_policy.c2008-02-12 15:09:17.0 -0800
+++ b/net/xfrm/xfrm_policy.c2008-02-12 15:09:53.0 -0800
@@ -577,7 +577,7 @@ int xfrm_policy_insert(int dir, struct x
 
read_lock_bh(xfrm_policy_lock);
gc_list = NULL;
-   entry = policy-bydst;
+
hlist_for_each_entry_continue(policy, entry, bydst) {
struct dst_entry *dst;
 
--- a/net/ipv4/fib_trie.c   2008-02-12 15:09:46.0 -0800
+++ b/net/ipv4/fib_trie.c   2008-02-12 15:12:21.0 -0800
@@ -2333,7 +2333,6 @@ static void *fib_trie_seq_next(struct se
 
/* walk rest of this hash chain */
h = tb-tb_id  (FIB_TABLE_HASHSZ - 1);
-   tb_node = tb-tb_hlist;
hlist_for_each_entry_continue_rcu(tb, tb_node, tb_hlist) {
n = trie_get_first(iter, tb);
if (n)

-- 
Stephen Hemminger [EMAIL PROTECTED]

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/4] fib_trie related patches for 2.6.25

[Stephen Hemminger]

More trie cleanups with some RCU related changes as well.
Patches are against net-2.6 tree.
-- 
Stephen Hemminger [EMAIL PROTECTED]

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: E1000 (PCI-E) doesn't work on nforce430, MSI issue.

[Krzysztof Halasa]

Kok, Auke [EMAIL PROTECTED] writes:

 Don't work by default. pci=nomsi fixes the problem.

 actually does not fix anything - it just works around it by falling
 back to legacy interrupts.

Actually it does, fixes the problem by working around a bug :-)

Thanks for info.
-- 
Krzysztof Halasa
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ofa-general] [PATCH 2.6.25] RDMA/cxgb3: Fail loopback connections.

[Steve Wise]

Roland Dreier wrote:

applied, although:

  +static void is_loopback_dst(struct iw_cm_id *cm_id)
  +{
  + struct net_device *dev;
  + 
  + dev = ip_dev_find(init_net, cm_id-remote_addr.sin_addr.s_addr);
  + if (!dev)
  + return 0;
  + dev_put(dev);
  + return 1;
  +}

is there any way this could trigger when it should, like if I'm trying
to make a connection from one local device to a different local device
(which should work fine)?



As far as I can tell, if the app does a rdma_resolve_addr() on the dst 
addr (which is a local address), then the routing lookup will find the 
local interface with that dst addr, and that device will be used for the 
connect.  IE src and dst devices are the same.


Maybe if the app does an explicit bind to the addr on one device, then 
connects to the addr on the other device.  But that's not gonna work 
either, I think.  I still think it will resolve to one device and that 
device cannot do loopback...



Steve.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] rcu_assign_pointer: null check fix

[David Miller]

From: Stephen Hemminger [EMAIL PROTECTED]
Date: Tue, 12 Feb 2008 16:50:43 -0800

 Goofed on last change, should avoid barrier only on rcu_assign_pointer(p, 
 NULL)
 
 Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]

Like the original change this needs to be merged upstream outside of
the networking tree, sorry.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] hlist_for_each_entry_continue simplification

[David Miller]

From: Stephen Hemminger [EMAIL PROTECTED]
Date: Tue, 12 Feb 2008 16:50:46 -0800

 All the users of hlist_for_each_entry_continue had to intialize pos
 before use; change API so pos is a pure temporary variable which matches
 the usage of other _for_each_entry routines.
 
 Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]

linux/list.h changes need to be reviewed on linux-kernel and
merged into Linus's tree via some means other than the
networking tree.

I just got chewed out for a similar issue wrt. the rcupdate.h
changes of yesterday and thus have to remove them from my
tree.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH resend] qla3xxx: convert byte order of constant instead ofvariable

[Ron Mercer]

 

 -Original Message-
 From: Marcin Slusarz [mailto:[EMAIL PROTECTED] 
 Sent: Sunday, February 10, 2008 2:06 AM
 To: netdev@vger.kernel.org; Linux Driver
 Cc: LKML
 Subject: [PATCH resend] qla3xxx: convert byte order of 
 constant instead ofvariable
 
 convert byte order of constant instead of variable
 which can be done at compile time (vs run time)
 
 Signed-off-by: Marcin Slusarz [EMAIL PROTECTED]
 ---
  drivers/net/qla3xxx.c |6 ++
  1 files changed, 2 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c
 index a6aeb9d..b7f7b22 100644
 --- a/drivers/net/qla3xxx.c
 +++ b/drivers/net/qla3xxx.c
 @@ -2472,8 +2472,7 @@ static int ql_send_map(struct ql3_adapter *qdev,
  
   if (seg_cnt == 1) {
   /* Terminate the last segment. */
 - oal_entry-len =
 - cpu_to_le32(le32_to_cpu(oal_entry-len) | 
 OAL_LAST_ENTRY);
 + oal_entry-len |= cpu_to_le32(OAL_LAST_ENTRY);
   } else {
   oal = tx_cb-oal;
   for (completed_segs=0; completed_segsfrag_cnt; 
 completed_segs++,seg++) {
 @@ -2530,8 +2529,7 @@ static int ql_send_map(struct ql3_adapter *qdev,
 frag-size);
   }
   /* Terminate the last segment. */
 - oal_entry-len =
 - cpu_to_le32(le32_to_cpu(oal_entry-len) | 
 OAL_LAST_ENTRY);
 + oal_entry-len |= cpu_to_le32(OAL_LAST_ENTRY);
   }
  
   return NETDEV_TX_OK;
 -- 
 1.5.3.7
 
 

Thanks

Acked-by: Ron Mercer [EMAIL PROTECTED] 
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [TC U32] Fix input parsing to support more than 9 flow id'scorrectly

[Stephen Hemminger]

Waskiewicz Jr, Peter P wrote:

From: PJ Waskiewicz [EMAIL PROTECTED]

Using strtoul with a base of 16 converts flowid 10 into 0x10, 
which makes it flowid 16.  This is interpreted by the kernel 
incorrectly, and causes traffic flows above 9 to be 
classified into band 0 on multiband qdiscs.
This changes the base to 10, which will correctly parse input 
into the proper hexidecimal value.



Stephen,
We can go one of two ways I suppose.  Once is this way, since
most user input for CLASSID is base 10, or we can update documentation
to say that CLASSID input is expected to be base 16.  What do you think?

Thanks,
-PJ Waskiewicz
[EMAIL PROTECTED]

  

Sorry, can't change the api, update the documentation instead.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] fib_trie: improve output format for /proc/net/fib_trie

[Stephen Hemminger]

Andrew Morton wrote:

On Tue, 12 Feb 2008 16:50:44 -0800 Stephen Hemminger [EMAIL PROTECTED] wrote:

  

Make output format prettier (more tree like).

   local:
   --- 0.0.0.0/0
 |--- 10.111.111.0/24
 |  +-- 10.111.111.0/32 link broadcast
 |  |--- 10.111.111.254/31
 |  |  +-- 10.111.111.254/32 host local
 |  |  +-- 10.111.111.255/32 link broadcast
 |--- 127.0.0.0/8
 |  |--- 127.0.0.0/31
 |  |  +-- 127.0.0.0/32 link broadcast
 |  |  +-- 127.0.0.0/8 host local
 |  |  +-- 127.0.0.1/32 host local
 |  +-- 127.255.255.255/32 link broadcast
 |--- 192.168.1.0/24
 |  |--- 192.168.1.0/28
 |  |  +-- 192.168.1.0/32 link broadcast
 |  |  +-- 192.168.1.9/32 host local
 |  +-- 192.168.1.255/32 link broadcast
   main:
   --- 0.0.0.0/0
 |--- 0.0.0.0/4
 |  +-- 0.0.0.0/0 universe unicast
 |  +-- 10.111.111.0/24 link unicast
 +-- 169.254.0.0/16 link unicast
 +-- 192.168.1.0/24 link unicast



isn't that a non-back-compatible kernel ABI change?  It might
break pre-existing parsers?

  
Fib trie was always experimental and the output format was intended to 
be tree like
but was broken. There are no known parsers of fib trie, and I think 
Vyatta will probably

be the first distro to ship with it enabled.

aside: how lame are we to put pretty-printers in the kernel?
English-only ones, at that?  Root cause: kernel developers still
don't have a sufficiently easy way of shipping userspace tools.
Agreed, the structure of the trie doesn't come out via netlink (only the 
addresses).

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] [TC U32] Fix input parsing to support more than 9 flow id'scorrectly

[Waskiewicz Jr, Peter P]

  
 Sorry, can't change the api, update the documentation instead.

Yes, this is much more reasonable.  I'll send a patch shortly to do
that.

Thanks
-PJ Waskiewicz
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [NET]: Add per-connection option to set max TSO frame size

[Stephen Hemminger]

On Tue, 12 Feb 2008 14:01:32 -0800
PJ Waskiewicz [EMAIL PROTECTED] wrote:

 This patch adds the ability for device drivers to control the size of the
 TSO frames being sent to them, per TCP connection.  By setting the
 netdevice's max_gso_frame_size value, the socket layer will set the GSO
 frame size based on that value.  This will propogate into the TCP layer,
 and send TSO's of that size to the hardware.
 
 This can be desirable to help tune the bursty nature of TSO on a
 per-adapter basis, where one may have 1 GbE and 10 GbE devices coexisting
 in a system, one running multiqueue and the other not, etc.
 
 This can also be desirable for devices that cannot support full 64 KB
 TSO's, but still want to benefit from some level of segmentation
 offloading.
 
 Signed-off-by: Peter P Waskiewicz Jr [EMAIL PROTECTED]
 ---
 
  include/linux/netdevice.h |6 ++
  include/net/sock.h|2 ++
  net/core/dev.c|1 +
  net/core/sock.c   |6 --
  net/ipv4/tcp_output.c |4 ++--
  5 files changed, 15 insertions(+), 4 deletions(-)
 
 diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
 index 047d432..ed1cc32 100644
 --- a/include/linux/netdevice.h
 +++ b/include/linux/netdevice.h
 @@ -616,6 +616,7 @@ struct net_device
  
   /* Partially transmitted GSO packet. */
   struct sk_buff  *gso_skb;
 + int max_gso_frame_size;

should use unsigned rather than int (yes the older code is sloppy).

Also what about IPV6? 
-- 
Stephen Hemminger [EMAIL PROTECTED]


--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [IPROUTE2] Update various classifiers' help output for expected CLASSID syntax

[PJ Waskiewicz]

This updates the help output to specify that CLASSID should be hexidecimal.
This makes sure that a user entering flowid 1:10 gets his flow put into
band 15 (0x10) and knows why.

Signed-off-by: Peter P Waskiewicz Jr [EMAIL PROTECTED]
---

 doc/actions/actions-general |3 +++
 tc/f_basic.c|1 +
 tc/f_fw.c   |1 +
 tc/f_route.c|1 +
 tc/f_rsvp.c |1 +
 tc/f_u32.c  |1 +
 6 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/doc/actions/actions-general b/doc/actions/actions-general
index 6561eda..70f7cd6 100644
--- a/doc/actions/actions-general
+++ b/doc/actions/actions-general
@@ -88,6 +88,9 @@ tc filter add dev lo parent : protocol ip prio 8 u32 \
 match ip dst 127.0.0.8/32 flowid 1:12 \
 action ipt -j mark --set-mark 2
 
+NOTE: flowid 1:12 is parsed flowid 0x1:0x12.  Make sure if you want flowid
+decimal 12, then use flowid 1:c.
+
 3) A feature i call pipe
 The motivation is derived from Unix pipe mechanism but applied to packets.
 Essentially take a matching packet and pass it through 
diff --git a/tc/f_basic.c b/tc/f_basic.c
index 19a7edf..d6d7767 100644
--- a/tc/f_basic.c
+++ b/tc/f_basic.c
@@ -32,6 +32,7 @@ static void explain(void)
fprintf(stderr, \n);
fprintf(stderr, Where: SELECTOR := SAMPLE SAMPLE ...\n);
fprintf(stderr,FILTERID := X:Y:Z\n);
+   fprintf(stderr, \nNOTE: CLASSID is parsed as hexidecimal input.\n);
 }
 
 static int basic_parse_opt(struct filter_util *qu, char *handle,
diff --git a/tc/f_fw.c b/tc/f_fw.c
index 6d1490b..9f4ef6e 100644
--- a/tc/f_fw.c
+++ b/tc/f_fw.c
@@ -28,6 +28,7 @@ static void explain(void)
fprintf(stderr, Usage: ... fw [ classid CLASSID ] [ police POLICE_SPEC 
]\n);
fprintf(stderr,POLICE_SPEC := ... look at TBF\n);
fprintf(stderr,CLASSID := X:Y\n);
+   fprintf(stderr, \nNOTE: CLASSID is parsed as hexidecimal input.\n);
 }
 
 #define usage() return(-1)
diff --git a/tc/f_route.c b/tc/f_route.c
index a41b9d5..3bb963c 100644
--- a/tc/f_route.c
+++ b/tc/f_route.c
@@ -31,6 +31,7 @@ static void explain(void)
fprintf(stderr, [ flowid CLASSID ] [ police 
POLICE_SPEC ]\n);
fprintf(stderr,POLICE_SPEC := ... look at TBF\n);
fprintf(stderr,CLASSID := X:Y\n);
+   fprintf(stderr, \nNOTE: CLASSID is parsed as hexidecimal input.\n);
 }
 
 #define usage() return(-1)
diff --git a/tc/f_rsvp.c b/tc/f_rsvp.c
index 13fcf97..9019ee2 100644
--- a/tc/f_rsvp.c
+++ b/tc/f_rsvp.c
@@ -34,6 +34,7 @@ static void explain(void)
fprintf(stderr, u{8|16|32} NUMBER mask MASK at 
OFFSET}\n);
fprintf(stderr,POLICE_SPEC := ... look at TBF\n);
fprintf(stderr,FILTERID := X:Y\n);
+   fprintf(stderr, \nNOTE: CLASSID is parsed as hexidecimal input.\n);
 }
 
 #define usage() return(-1)
diff --git a/tc/f_u32.c b/tc/f_u32.c
index 91f2838..d38c536 100644
--- a/tc/f_u32.c
+++ b/tc/f_u32.c
@@ -36,6 +36,7 @@ static void explain(void)
fprintf(stderr, Where: SELECTOR := SAMPLE SAMPLE ...\n);
fprintf(stderr,SAMPLE := { ip | ip6 | udp | tcp | icmp | 
u{32|16|8} | mark } SAMPLE_ARGS [divisor DIVISOR]\n);
fprintf(stderr,FILTERID := X:Y:Z\n);
+   fprintf(stderr, \nNOTE: CLASSID is parsed at hexidecimal input.\n);
 }
 
 #define usage() return(-1)

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [NET]: Add per-connection option to set max TSO frame size

[PJ Waskiewicz]

This patch adds the ability for device drivers to control the size of the
TSO frames being sent to them, per TCP connection.  By setting the
netdevice's max_gso_frame_size value, the socket layer will set the GSO
frame size based on that value.  This will propogate into the TCP layer,
and send TSO's of that size to the hardware.

This can be desirable to help tune the bursty nature of TSO on a
per-adapter basis, where one may have 1 GbE and 10 GbE devices coexisting
in a system, one running multiqueue and the other not, etc.

This can also be desirable for devices that cannot support full 64 KB
TSO's, but still want to benefit from some level of segmentation
offloading.

Signed-off-by: Peter P Waskiewicz Jr [EMAIL PROTECTED]
---

 include/linux/netdevice.h |6 ++
 include/net/sock.h|2 ++
 net/core/dev.c|1 +
 net/core/sock.c   |6 --
 net/ipv4/tcp_output.c |4 ++--
 5 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 047d432..ed1cc32 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -616,6 +616,7 @@ struct net_device
 
/* Partially transmitted GSO packet. */
struct sk_buff  *gso_skb;
+   int max_gso_frame_size;
 
/* ingress path synchronizer */
spinlock_t  ingress_lock;
@@ -1475,6 +1476,11 @@ static inline int netif_needs_gso(struct net_device 
*dev, struct sk_buff *skb)
unlikely(skb-ip_summed != CHECKSUM_PARTIAL));
 }
 
+static inline void netif_set_max_gso_size(struct net_device *dev, int size)
+{
+   dev-max_gso_frame_size = size;
+}
+
 /* On bonding slaves other than the currently active slave, suppress
  * duplicates except for 802.3ad ETH_P_SLOW, alb non-mcast/bcast, and
  * ARP on active-backup slaves with arp_validate enabled.
diff --git a/include/net/sock.h b/include/net/sock.h
index 8a7889b..1977c05 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -151,6 +151,7 @@ struct sock_common {
   *@sk_no_check: %SO_NO_CHECK setting, wether or not checkup packets
   *@sk_route_caps: route capabilities (e.g. %NETIF_F_TSO)
   *@sk_gso_type: GSO type (e.g. %SKB_GSO_TCPV4)
+  *@sk_gso_max_size: Maximum GSO segment size to build
   *@sk_lingertime: %SO_LINGER l_linger setting
   *@sk_backlog: always used with the per-socket spinlock held
   *@sk_callback_lock: used with the callbacks in the end of this struct
@@ -236,6 +237,7 @@ struct sock {
gfp_t   sk_allocation;
int sk_route_caps;
int sk_gso_type;
+   int sk_gso_max_size;
int sk_rcvlowat;
unsigned long   sk_flags;
unsigned long   sk_lingertime;
diff --git a/net/core/dev.c b/net/core/dev.c
index 9549417..f635b29 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4022,6 +4022,7 @@ struct net_device *alloc_netdev_mq(int sizeof_priv, const 
char *name,
}
 
dev-egress_subqueue_count = queue_count;
+   dev-max_gso_frame_size = 65536;
 
dev-get_stats = internal_stats;
netpoll_netdev_init(dev);
diff --git a/net/core/sock.c b/net/core/sock.c
index 433715f..a8b0ae5 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1076,10 +1076,12 @@ void sk_setup_caps(struct sock *sk, struct dst_entry 
*dst)
if (sk-sk_route_caps  NETIF_F_GSO)
sk-sk_route_caps |= NETIF_F_GSO_SOFTWARE;
if (sk_can_gso(sk)) {
-   if (dst-header_len)
+   if (dst-header_len) {
sk-sk_route_caps = ~NETIF_F_GSO_MASK;
-   else
+   } else {
sk-sk_route_caps |= NETIF_F_SG | NETIF_F_HW_CSUM;
+   sk-sk_gso_max_size = dst-dev-max_gso_frame_size;
+   }
}
 }
 EXPORT_SYMBOL_GPL(sk_setup_caps);
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index ed750f9..8cd128d 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -998,7 +998,7 @@ unsigned int tcp_current_mss(struct sock *sk, int 
large_allowed)
xmit_size_goal = mss_now;
 
if (doing_tso) {
-   xmit_size_goal = (65535 -
+   xmit_size_goal = ((sk-sk_gso_max_size - 1) -
  inet_csk(sk)-icsk_af_ops-net_header_len -
  inet_csk(sk)-icsk_ext_hdr_len -
  tp-tcp_header_len);
@@ -1274,7 +1274,7 @@ static int tcp_tso_should_defer(struct sock *sk, struct 
sk_buff *skb)
limit = min(send_win, cong_win);
 
/* If a full-sized TSO skb can be sent, do it. */
-   if (limit = 65536)
+   if (limit = sk-sk_gso_max_size)
goto send_now;
 
if (sysctl_tcp_tso_win_divisor) {

--
To unsubscribe from this list: send the line unsubscribe 

RE: [PATCH] [TC U32] Fix input parsing to support more than 9 flow id'scorrectly

[Waskiewicz Jr, Peter P]

 From: PJ Waskiewicz [EMAIL PROTECTED]
 
 Using strtoul with a base of 16 converts flowid 10 into 0x10, 
 which makes it flowid 16.  This is interpreted by the kernel 
 incorrectly, and causes traffic flows above 9 to be 
 classified into band 0 on multiband qdiscs.
 This changes the base to 10, which will correctly parse input 
 into the proper hexidecimal value.

Stephen,
We can go one of two ways I suppose.  Once is this way, since
most user input for CLASSID is base 10, or we can update documentation
to say that CLASSID input is expected to be base 16.  What do you think?

Thanks,
-PJ Waskiewicz
[EMAIL PROTECTED]

 
 Signed-off-by: Peter P Waskiewicz Jr [EMAIL PROTECTED]
 ---
 
  tc/tc_util.c |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/tc/tc_util.c b/tc/tc_util.c index cdbae42..a277eac 100644
 --- a/tc/tc_util.c
 +++ b/tc/tc_util.c
 @@ -65,7 +65,7 @@ int get_tc_classid(__u32 *h, const char *str)
   maj = TC_H_UNSPEC;
   if (strcmp(str, none) == 0)
   goto ok;
 - maj = strtoul(str, p, 16);
 + maj = strtoul(str, p, 10);
   if (p == str) {
   maj = 0;
   if (*p != ':')
 @@ -76,7 +76,7 @@ int get_tc_classid(__u32 *h, const char *str)
   return -1;
   maj = 16;
   str = p+1;
 - min = strtoul(str, p, 16);
 + min = strtoul(str, p, 10);
   if (*p != 0)
   return -1;
   if (min = (116))
 
 --
 To unsubscribe from this list: send the line unsubscribe 
 netdev in the body of a message to [EMAIL PROTECTED] 
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [TC U32] Fix input parsing to support more than 9 flow id's correctly

[PJ Waskiewicz]

From: PJ Waskiewicz [EMAIL PROTECTED]

Using strtoul with a base of 16 converts flowid 10 into 0x10, which makes
it flowid 16.  This is interpreted by the kernel incorrectly, and causes
traffic flows above 9 to be classified into band 0 on multiband qdiscs.
This changes the base to 10, which will correctly parse input into the
proper hexidecimal value.

Signed-off-by: Peter P Waskiewicz Jr [EMAIL PROTECTED]
---

 tc/tc_util.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tc/tc_util.c b/tc/tc_util.c
index cdbae42..a277eac 100644
--- a/tc/tc_util.c
+++ b/tc/tc_util.c
@@ -65,7 +65,7 @@ int get_tc_classid(__u32 *h, const char *str)
maj = TC_H_UNSPEC;
if (strcmp(str, none) == 0)
goto ok;
-   maj = strtoul(str, p, 16);
+   maj = strtoul(str, p, 10);
if (p == str) {
maj = 0;
if (*p != ':')
@@ -76,7 +76,7 @@ int get_tc_classid(__u32 *h, const char *str)
return -1;
maj = 16;
str = p+1;
-   min = strtoul(str, p, 16);
+   min = strtoul(str, p, 10);
if (*p != 0)
return -1;
if (min = (116))

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] fib_trie: improve output format for /proc/net/fib_trie

[Andrew Morton]

On Tue, 12 Feb 2008 16:50:44 -0800 Stephen Hemminger [EMAIL PROTECTED] wrote:

 Make output format prettier (more tree like).
 
local:
--- 0.0.0.0/0
  |--- 10.111.111.0/24
  |  +-- 10.111.111.0/32 link broadcast
  |  |--- 10.111.111.254/31
  |  |  +-- 10.111.111.254/32 host local
  |  |  +-- 10.111.111.255/32 link broadcast
  |--- 127.0.0.0/8
  |  |--- 127.0.0.0/31
  |  |  +-- 127.0.0.0/32 link broadcast
  |  |  +-- 127.0.0.0/8 host local
  |  |  +-- 127.0.0.1/32 host local
  |  +-- 127.255.255.255/32 link broadcast
  |--- 192.168.1.0/24
  |  |--- 192.168.1.0/28
  |  |  +-- 192.168.1.0/32 link broadcast
  |  |  +-- 192.168.1.9/32 host local
  |  +-- 192.168.1.255/32 link broadcast
main:
--- 0.0.0.0/0
  |--- 0.0.0.0/4
  |  +-- 0.0.0.0/0 universe unicast
  |  +-- 10.111.111.0/24 link unicast
  +-- 169.254.0.0/16 link unicast
  +-- 192.168.1.0/24 link unicast

isn't that a non-back-compatible kernel ABI change?  It might
break pre-existing parsers?

aside: how lame are we to put pretty-printers in the kernel?
English-only ones, at that?  Root cause: kernel developers still
don't have a sufficiently easy way of shipping userspace tools.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH BUGFIX 25-rc1] Smack: Don't fail against Nulled sk sockets

[Ahmed S. Darwish]

Hi!,

Appropriately handle sockets with sk = NULL. This is usually the socket
case when starting kernel nfsd.

Signed-off-by: Ahmed S. Darwish [EMAIL PROTECTED]
Acked-by: Casey Schaufler [EMAIL PROTECTED]
Tested-by: Joerg Platte [EMAIL PROTECTED]
--

diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 1c11e42..eb04278 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -701,7 +701,7 @@ static int smack_inode_getsecurity(const struct inode 
*inode,
return -EOPNOTSUPP;
 
sock = SOCKET_I(ip);
-   if (sock == NULL)
+   if (sock == NULL || sock-sk == NULL)
return -EOPNOTSUPP;
 
ssp = sock-sk-sk_security;
@@ -1280,10 +1280,12 @@ static void smack_to_secattr(char *smack, struct 
netlbl_lsm_secattr *nlsp)
  */
 static int smack_netlabel(struct sock *sk)
 {
-   struct socket_smack *ssp = sk-sk_security;
+   struct socket_smack *ssp;
struct netlbl_lsm_secattr secattr;
int rc = 0;
 
+   BUG_ON(sk == NULL);
+   ssp = sk-sk_security;
netlbl_secattr_init(secattr);
smack_to_secattr(ssp-smk_out, secattr);
if (secattr.flags != NETLBL_SECATTR_NONE)
@@ -1331,7 +1333,7 @@ static int smack_inode_setsecurity(struct inode *inode, 
const char *name,
return -EOPNOTSUPP;
 
sock = SOCKET_I(inode);
-   if (sock == NULL)
+   if (sock == NULL || sock-sk == NULL)
return -EOPNOTSUPP;
 
ssp = sock-sk-sk_security;
@@ -1362,7 +1364,7 @@ static int smack_inode_setsecurity(struct inode *inode, 
const char *name,
 static int smack_socket_post_create(struct socket *sock, int family,
int type, int protocol, int kern)
 {
-   if (family != PF_INET)
+   if (family != PF_INET || sock-sk == NULL)
return 0;
/*
 * Set the outbound netlbl.


Warm regards

-- 
Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/4] rcu_assign_pointer: null check fix

[Stephen Hemminger]

Goofed on last change, should avoid barrier only on rcu_assign_pointer(p, NULL)

Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
 include/linux/rcupdate.h |   13 +++--
 1 files changed, 7 insertions(+), 6 deletions(-)

--- a/include/linux/rcupdate.h  2008-02-12 14:46:49.0 -0800
+++ b/include/linux/rcupdate.h  2008-02-12 14:56:17.0 -0800
@@ -178,7 +178,7 @@ struct rcu_head {
 
 #define rcu_assign_pointer(p, v)   \
({  \
-   if (!(__builtin_constant_p(v)  v))\
+   if (!__builtin_constant_p(v) || v)  \
smp_wmb();  \
(p) = (v);  \
})

-- 
Stephen Hemminger [EMAIL PROTECTED]

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [IRDA] irda_init() nuke useless debug printk

[David Miller]

From: maximilian attems [EMAIL PROTECTED]
Date: Tue, 12 Feb 2008 11:30:47 +0100

 irda_init()
 dmesg line is not really informative, thus remove it.
 There are better ways to know that a module is loaded.
 
 Seen on a debian config with IRDA_DEBUG enabled.
 
 Signed-off-by: maximilian attems [EMAIL PROTECTED]

Well if you look at how IRDA_DEBUG is predominantly used,
it's a function tracer, and that's exactly how it's being
used here.

Either we decide that this is OK and leave it there, or
we start moving the whole IRDA tree over to not do this.
Not something in between.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bug 9750] [patch 2.6.25] dev: avoid a race that triggers assertion failure

[David Miller]

From: Matti Linnanvuori [EMAIL PROTECTED]
Date: Tue, 12 Feb 2008 02:45:22 -0800 (PST)

 From: Matti Linnanvuori [EMAIL PROTECTED]
 
 There is a race in Linux kernel file net/core/dev.c, function dev_close.
 The function calls function dev_deactivate, which calls function
 dev_watchdog_down that deletes the watchdog timer. However, after that, a
 driver can call netif_carrier_ok, which calls function
 __netdev_watchdog_up that can add the watchdog timer again. Function
 unregister_netdevice calls function dev_shutdown that traps the bug
 !timer_pending(dev-watchdog_timer). Moving dev_deactivate after
 netif_running() has been cleared prevents function netif_carrier_on
 from calling __netdev_watchdog_up and adding the watchdog timer again.
 
 Signed-off-by: Matti Linnanvuori [EMAIL PROTECTED]

Your patch won't apply because it has been whitespace damanged
by your email client.

This is what I let you know last time you posted this patch.

Please fix this up so that your patch can be applied.

Thanks.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ofa-general] [PATCH 2.6.25] RDMA/cxgb3: Fail loopback connections.

[Roland Dreier]

applied, although:

  +static void is_loopback_dst(struct iw_cm_id *cm_id)
  +{
  +struct net_device *dev;
  +
  +dev = ip_dev_find(init_net, cm_id-remote_addr.sin_addr.s_addr);
  +if (!dev)
  +return 0;
  +dev_put(dev);
  +return 1;
  +}

is there any way this could trigger when it should, like if I'm trying
to make a connection from one local device to a different local device
(which should work fine)?

 - R.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [IPV6]: Fix IPsec datagram fragmentation

[David Miller]

From: Herbert Xu [EMAIL PROTECTED]
Date: Wed, 13 Feb 2008 11:04:37 +1100

 [IPV6]: Fix IPsec datagram fragmentation
 
 This is a long-standing bug in the IPsec IPv6 code that breaks
 when we emit a IPsec tunnel-mode datagram packet.  The problem
 is that the code the emits the packet assumes the IPv6 stack
 will fragment it later, but the IPv6 stack assumes that whoever
 is emitting the packet is going to pre-fragment the packet.
 
 In the long term we need to fix both sides, e.g., to get the
 datagram code to pre-fragment as well as to get the IPv6 stack
 to fragment locally generated tunnel-mode packet.
 
 For now this patch does the second part which should make it
 work for the IPsec host case.
 
 Signed-off-by: Herbert Xu [EMAIL PROTECTED]

Applied, and I'll queue this up to -stable as well.

Thanks!
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[IPV6]: Fix IPsec datagram fragmentation

[Herbert Xu]

Hi Dave:

[IPV6]: Fix IPsec datagram fragmentation

This is a long-standing bug in the IPsec IPv6 code that breaks
when we emit a IPsec tunnel-mode datagram packet.  The problem
is that the code the emits the packet assumes the IPv6 stack
will fragment it later, but the IPv6 stack assumes that whoever
is emitting the packet is going to pre-fragment the packet.

In the long term we need to fix both sides, e.g., to get the
datagram code to pre-fragment as well as to get the IPv6 stack
to fragment locally generated tunnel-mode packet.

For now this patch does the second part which should make it
work for the IPsec host case.

Signed-off-by: Herbert Xu [EMAIL PROTECTED]

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 9ac6ca2..4e9a2fe 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -621,7 +621,7 @@ static int ip6_fragment(struct sk_buff *skb, int 
(*output)(struct sk_buff *))
 * or if the skb it not generated by a local socket.  (This last
 * check should be redundant, but it's free.)
 */
-   if (!np || np-pmtudisc = IPV6_PMTUDISC_DO) {
+   if (skb-local_df) {
skb-dev = skb-dst-dev;
icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu, skb-dev);
IP6_INC_STATS(ip6_dst_idev(skb-dst), IPSTATS_MIB_FRAGFAILS);
@@ -1420,6 +1420,10 @@ int ip6_push_pending_frames(struct sock *sk)
tmp_skb-sk = NULL;
}
 
+   /* Allow local fragmentation. */
+   if (np-pmtudisc = IPV6_PMTUDISC_DO)
+   skb-local_df = 1;
+
ipv6_addr_copy(final_dst, fl-fl6_dst);
__skb_pull(skb, skb_network_header_len(skb));
if (opt  opt-opt_flen)
diff --git a/net/ipv6/xfrm6_output.c b/net/ipv6/xfrm6_output.c
index b34c58c..79ccfb0 100644
--- a/net/ipv6/xfrm6_output.c
+++ b/net/ipv6/xfrm6_output.c
@@ -36,7 +36,7 @@ static int xfrm6_tunnel_check_size(struct sk_buff *skb)
if (mtu  IPV6_MIN_MTU)
mtu = IPV6_MIN_MTU;
 
-   if (skb-len  mtu) {
+   if (!skb-local_df  skb-len  mtu) {
skb-dev = dst-dev;
icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu, skb-dev);
ret = -EMSGSIZE;
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: r8169 auto-negotiation problem

[Francois Romieu]

fgnijuhhu guduggurehug [EMAIL PROTECTED] :
  fgnijuhhu guduggurehug  :
  [...]
  I already posted my problem and what I did to solve it on
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461429.
 
  Have you tried anything more recent than a 2.6.18 based kernel ?
 
 No, but if changes were made to the iniatialization of the chipset
 in the current driver (mine was 2.2LK), this might do the trick.

Please try a recent kernel. Your r8169 driver is badly outdated.

[...]
 Anyway, how to best upgrade the kernel in debian (without problems,
 of course) ? The problem right now is that every apt-get upgrade
 reverts the r8169 driver to the old one...

I do not use debian but you can read:

http://www.google.com/search?q=debian+kernel+upgrade

-- 
Ueimor
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: E1000 (PCI-E) doesn't work on nforce430, MSI issue.

[Kok, Auke]

Prakash Punnoor wrote:
 On the day of Tuesday 12 February 2008 Krzysztof Halasa hast written:
 Hi,

 Is it a known problem?
 Linux 2.6.24.2, ASUS M2NPV-MX mobo, nforce 430 based, two PCI-E x1
 E1000 cards, 32-bit kernel, default e1000 driver (PCI IDs disabled in
 e1000e).

your card will work with e1000e from 2.6.25 onwards.

 Don't work by default. pci=nomsi fixes the problem.

actually does not fix anything - it just works around it by falling back to 
legacy
interrupts.

 Probably the patch to enable msi bit on the host bridge(?) is still missing 
 in 
 mainline. I needed that patch to make msi work on my MCP51 system.

and there have been many more reports. unfortunately e1000 cards are one of the
few things that actually uses MSI. It works great except for a few problematic
motherboards, and the ones mentioned in this thread fall amongst them.

Auke
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2.6.25] RDMA/cxgb3: Fail loopback connections.

[Steve Wise]

RDMA/cxgb3: Fail loopback connections.

The cxgb3 HW and driver don't support loopback RDMA connections.  So fail
any connection attempt where the destination address is local.

Signed-off-by: Steve Wise [EMAIL PROTECTED]
---

 drivers/infiniband/hw/cxgb3/iwch_cm.c |   16 
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/drivers/infiniband/hw/cxgb3/iwch_cm.c 
b/drivers/infiniband/hw/cxgb3/iwch_cm.c
index e9a08fa..5d82723 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_cm.c
+++ b/drivers/infiniband/hw/cxgb3/iwch_cm.c
@@ -1784,6 +1784,17 @@ err:
return err;
 }
 
+static void is_loopback_dst(struct iw_cm_id *cm_id)
+{
+   struct net_device *dev;
+   
+   dev = ip_dev_find(init_net, cm_id-remote_addr.sin_addr.s_addr);
+   if (!dev)
+   return 0;
+   dev_put(dev);
+   return 1;
+}
+
 int iwch_connect(struct iw_cm_id *cm_id, struct iw_cm_conn_param *conn_param)
 {
int err = 0;
@@ -1791,6 +1802,11 @@ int iwch_connect(struct iw_cm_id *cm_id, struct 
iw_cm_conn_param *conn_param)
struct iwch_ep *ep;
struct rtable *rt;
 
+   if (is_loopback_dst(cm_id)) {
+   err = -ENOSYS;
+   goto out;
+   }
+
ep = alloc_ep(sizeof(*ep), GFP_KERNEL);
if (!ep) {
printk(KERN_ERR MOD %s - cannot alloc ep.\n, __FUNCTION__);
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: An ioctl to delete an ipv6 tunnel leads to a kernel panic

[David Miller]

From: Natalie Protasevich [EMAIL PROTECTED]
Date: Mon, 11 Feb 2008 12:49:12 -0800

 Possible reason for this failure was identified and tested by the
 submitter and several other reporters that ran into the same problem.
 Can the patch be reviewed and pushed upstream if accepted (if the
 problem hasn't been addressed already)?

There are a lot of bogus patches in there, using funny
long variable names, and mainly they were meant for testing
and verification of the problem.

I see no real serious patch submissions in that bug and furthermore
the patch, if ready, should be submitted formally here to netdev not
rot in bugzilla.

Finally, what appears to be the proposal cannot be correct.  If the
fib6_add_rt2node() finds that the new route is a duplicate, we should
disconnect it from the fn-leaf and do a dst_release().  The bug
appears to be rather that we leave the route attached to the fn, not
that we drop the refrence to it.

Thank you.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] fib_trie: rcu_assign_pointer warning fix

[Jarek Poplawski]

On Tue, Feb 12, 2008 at 08:07:29AM -0800, Paul E. McKenney wrote:
...
 All programmers are blind, especially me.

Hmm... I got it my way: you - superheroes - sometimes seem to be just
like us - common people... (Probably early in the morning, before
dressing your funny costumes?) 

 You are right, Jarek.  I ran this through gcc, and the following
 comes close:
 
 #define rcu_assign_pointer(p, v) \
   ({ \
   if (!__builtin_constant_p(v) || (v)) \
   smp_wmb(); \
   (p) = (v); \
   })
 
 But I am concerned about the following case:
 
   rcu_assign_pointer(global_index, 0);
 
   . . .
 
   x = global_array[rcu_dereference(global_index)];
 
 Since arrays have a zero-th element, we would really want a memory
 barrier in this case.

It seems the above version of this macro uses the barrier for 0, but
if I miss something, or for these other: documenting reasons, then of
course you are right.

 
 So how about leaving the index-unfriendly version of rcu_assign_pointer()
 and adding an rcu_assign_index() as follows?
 
   Thanx, Paul
 
 Signed-off-by: Paul E. McKenney [EMAIL PROTECTED]
 ---
 
  rcupdate.h |   18 ++
  1 file changed, 18 insertions(+)
 
 diff -urpNa -X dontdiff linux-2.6.24/include/linux/rcupdate.h 
 linux-2.6.24-rai/include/linux/rcupdate.h
 --- linux-2.6.24/include/linux/rcupdate.h 2008-01-24 14:58:37.0 
 -0800
 +++ linux-2.6.24-rai/include/linux/rcupdate.h 2008-02-12 08:04:59.0 
 -0800
 @@ -278,6 +278,24 @@ extern struct lockdep_map rcu_lock_map;
   })
  
  /**
 + * rcu_assign_index - assign (publicize) a index of a newly
 + * initialized array elementg that will be dereferenced by RCU

---^
 + * initialized array element that will be dereferenced by RCU

Regards,
Jarek P.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH][PPPOL2TP]: Fix SMP oops in pppol2tp driver

[David Miller]

From: James Chapman [EMAIL PROTECTED]
Date: Tue, 12 Feb 2008 10:58:21 +

 Here is a trace from when we had _bh locks.

The problem is that the pppol2tp code calls sk_dst_get() in software
interrupt context and that is not allowed.

sk_dst_get() grabs sk-sk_dst_lock without any BH enabling or
disabling.

It can do that because the usage is to make all the lock
taking calls in user context, and in the packet processing
paths use __sk_dst_get().

Probably what the pppol2tp code should do is use __sk_dst_check()
instead of sk_dst_get().  You then have to be able to handle
NULL returns, just like UDP sendmsg() does, which means you'll
need to cook up a routing lookup if __sk_dst_check() gives you
NULL because the route became obsolete.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier

[Dave Hansen]

On Mon, 2008-02-11 at 17:24 +0100, Jan-Bernd Themann wrote:
 Drivers like eHEA need memory notifiers in order to 
 update their internal DMA memory map when memory is added
 to or removed from the system.
 
 Patch for eHEA memory hotplug support that uses these functions:
 http://www.spinics.net/lists/netdev/msg54484.html

This driver is broken pretty horribly.  It won't even compile for a
plain ppc64 kernel:

http://sr71.net/~dave/linux/ehea-is-broken.config

I know it's used for very specific hardware, but this is the symptom of
it not using the proper abstracted interfaces to the VM.

In file included from 
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_main.c:42:
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.h:44:14: 
warning: SECTION_SIZE_BITS is not defined
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.h:45:2: 
error: #error eHEA module cannot work if kernel sectionsize  ehea sectionsize
  CC  drivers/net/mii.o
make[4]: *** [drivers/net/ehea/ehea_main.o] Error 1
make[4]: *** Waiting for unfinished jobs
  CC  drivers/net/ixgb/ixgb_param.o
In file included from 
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:32:
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.h:44:14: 
warning: SECTION_SIZE_BITS is not defined
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.h:45:2: 
error: #error eHEA module cannot work if kernel sectionsize  ehea sectionsize
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c: In 
function 'ehea_create_busmap':
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:574: 
error: 'NR_MEM_SECTIONS' undeclared (first use in this function)
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:574: 
error: (Each undeclared identifier is reported only once
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:574: 
error: for each function it appears in.)
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:575: 
error: implicit declaration of function 'valid_section_nr'
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c: In 
function 'ehea_map_vaddr':
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:606: 
error: 'SECTION_SIZE_BITS' undeclared (first use in this function)
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c: In 
function 'ehea_reg_kernel_mr':
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:655: 
error: 'SECTION_SIZE_BITS' undeclared (first use in this function)

-- Dave

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: An ioctl to delete an ipv6 tunnel leads to a kernel panic

[Natalie Protasevich]

On Feb 12, 2008 9:49 PM, David Miller [EMAIL PROTECTED] wrote:
 From: Natalie Protasevich [EMAIL PROTECTED]
 Date: Mon, 11 Feb 2008 12:49:12 -0800

  Possible reason for this failure was identified and tested by the
  submitter and several other reporters that ran into the same problem.
  Can the patch be reviewed and pushed upstream if accepted (if the
  problem hasn't been addressed already)?

 There are a lot of bogus patches in there, using funny
 long variable names, and mainly they were meant for testing
 and verification of the problem.

 I see no real serious patch submissions in that bug and furthermore
 the patch, if ready, should be submitted formally here to netdev not
 rot in bugzilla.

 Finally, what appears to be the proposal cannot be correct.  If the
 fib6_add_rt2node() finds that the new route is a duplicate, we should
 disconnect it from the fn-leaf and do a dst_release().  The bug
 appears to be rather that we leave the route attached to the fn, not
 that we drop the refrence to it.

 Thank you.

Thanks David for looking in this. I will give this thought to the
diligent reporters, unless someone on the net team can produce a patch
for them to test.
Sometimes reporters come up with patches and I always try to make sure
the patches end up on appropriate mailing list, and I will continue
doing so :)

Regards,
--Natalie

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Open bugs

[James Bottomley]

Added linux-scsi for the SCSI ones

On Tue, 2008-02-12 at 00:18 -0800, Natalie Protasevich wrote:
 Hello,
 
 The bugs listed are over a month old, and haven't been addressed yet.
 It would be appreciated if corresponding maintainers identify whether
 the bugs have been fixed, or need to be worked on, and take
 appropriate action.
 
 In most cases, reporters are standing by and ready to provide
 information and necessary testing.
 Thanks!
 
 SCSI==
 
 Problems on booting
 http://bugzilla.kernel.org/show_bug.cgi?id=9621
 Date: 12/22/2007
 Regression
 Summary: The boot stops / hangs on hardware detection of SCSI.  I have
 an InitioINI-9X00U/UW
 When I have an usb key sticked in /dev/sba, and run lilo then, then it
 dont boot but give L99 99 99 99 ... error

I think this was fixed by commit
e2d435ea4084022ab88efa74214accb45b1f9e92

Apparently bugzilla email is on the fritz again because this bug report
didn't come across linux-scsi.

 Resetting RAID attached to a FC Switch causes kernel panic and crash
 http://bugzilla.kernel.org/show_bug.cgi?id=9598
 12/18/2007
 Hardware Environment:SunFire X4200 - 2 x dual core AMD Opteron CPUs,
 8GB Ram, Qlogic FC adapter.
 Summary: Resetting the RAID box causes the X4200 to crash.

This one looks like the usual problem of remove re-add with the SCSI
device model.

 3ware 9650SE -8LPML not recognized by 3w-9xxx driver
 http://bugzilla.kernel.org/show_bug.cgi?id=8908
 08/19/2007
 Problem Description: The 3w-9xxx kernel driver for 3ware 9xxx SATA
 RAID Controller series did not recognize the 3ware 9650SE-8LPML SATA
 RAID Controller.

Since this one never apparently worked it's not a regression but an
enhancement request, isn't it?

However, adding this PCI ID to the driver should be fairly
straightforward.  Does anyone know what the actual PCI IDs are?

James


--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

permisions for Ethetool vs rtnetlink

[Rick Jones]

I've been further enhancing the netperf omni tests to enable reporting 
stuff like uname for local/remote, the name of the probable egress 
interface (rtnetlink), and then driver information for that interface. 
I figure that such information being spat-out by netperf might be useful 
to have if one were setting-up a database of results and/or making 
regression checks and the like.


It struck me as a little odd that I can retrieve routing information for 
a destination as a mere mortal, but to retreive driver information for 
an interface I have to be priviledged.  At first glance I would think 
the sensitivity of both sets of information would be about the same?


Is the difference simply an artifact of history?

sincerely,

rick jones
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

E1000 (PCI-E) doesn't work on nforce430, MSI issue.

[Krzysztof Halasa]

Hi,

Is it a known problem?
Linux 2.6.24.2, ASUS M2NPV-MX mobo, nforce 430 based, two PCI-E x1
E1000 cards, 32-bit kernel, default e1000 driver (PCI IDs disabled in
e1000e).

Don't work by default. pci=nomsi fixes the problem.

82572EI Gigabit Ethernet Controller (Copper) (rev 06)
Subsystem: PRO/1000 PT Desktop Adapter

(8086:10b9 subsystem 8086:1083)

grep eth0 /proc/interrupts 
 20:   1945  1   IO-APIC-fasteoi   eth0

(without pci=nomsi:
221:  0  0   PCI-MSI-edge  eth0)

other devices of possible interest:
00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
00:00.1 RAM memory: nVidia Corporation C51 Memory Controller 0 (rev a2)
00:00.2 RAM memory: nVidia Corporation C51 Memory Controller 1 (rev a2)
00:00.3 RAM memory: nVidia Corporation C51 Memory Controller 5 (rev a2)
00:00.4 RAM memory: nVidia Corporation C51 Memory Controller 4 (rev a2)
00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
00:00.6 RAM memory: nVidia Corporation C51 Memory Controller 3 (rev a2)
00:00.7 RAM memory: nVidia Corporation C51 Memory Controller 2 (rev a2)
00:03.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00:04.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2)
00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3)
00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a3)
00:0a.2 RAM memory: nVidia Corporation MCP51 Memory Controller 0 (rev a3)
00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2)

Additional details on request.
-- 
Krzysztof Halasa
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [RFC] Smack: unlabeled outgoing ambient packets - v2

[Paul Moore]

On Monday 11 February 2008 7:00:33 pm Casey Schaufler wrote:
 This patch differs significantly from the previous version.
 I think that I am using the netlbl interfaces more appropriately,
 Paul, please let me know if there's a better approach.

Nope, this approach is what I was talking about.  There are some minor 
issues discussed below but they should be easy/quick to fix.

 It's inconvenient that netlbl_sock_setattr frees the domain passed.
 I see that it makes sense for SELinux with the way SELinux treats
 secctx's, but Smack is more careful about memory usage and I have
 to do what I consider a gratuitous kalloc because of this behavior.
 Would you be open to a patch to change this if it included the
 SELinux changes?

I've looked at this before from a SELinux point of view to see if I 
could get rid of this extra memory allocation/copy and there just isn't 
a clean way to do it (clean being very subjective).  The problem is 
you either have to hold the policy lock while you make the NetLabel 
call (not a good idea), move the selinux_netlbl_sock_setsid() 
functionality back into security/selinux/ss/services.c (not desired by 
the SELinux folks who like to keep the selinux/ss/ directory minimal), 
or do the allocatin in security_netlbl_sid_to_secattr() and free it in 
selinux_netlbl_sock_setsid().  Of those options, only the last is 
really possible and it's so prone to memory leakage that I'm hesitant 
to say it's better than what we currently have.  Right now you do a 
call to netlbl_secattr_init() to start, do what you want with the 
secattr, and then you call netlbl_secattr_destroy() which will clean up 
_everything_ so nothing is leaked.  It works out really well because 
all of the _secattr_init() calls are matched by _secattr_destroy() 
calls within the same function; very easy to quickly scan and ensure 
there are no problems (the memory leak for a few weeks ago was quickly 
caught by looking at the code).  I'm in no hurry to loose this handy 
little property of the secattr, although I do agree that it isn't 
optimal for SMACK at present.  On the plus side this only happens once 
per-socket and not per-packet so I don't expect the malloc/copy to be 
fatal at this point.

You've got my mind revisiting this idea so give me a while and let me 
see if I can think of something that should be palatable to everyone 
involved.  In the meantime, I think you should fixup the few little 
nits in this patch and get it merged as it is a nice improvement and 
something that I believe most SMACK users will want.

  security/smack/smack_lsm.c |   20 ++--
  security/smack/smackfs.c   |   54
 +-- 2 files changed, 49
 insertions(+), 25 deletions(-)

 diff -uprN -X linux-2.6.25-g0210-base//Documentation/dontdiff
 linux-2.6.25-g0210-base/security/smack/smackfs.c
 linux-2.6.25-g0210/security/smack/smackfs.c ---
 linux-2.6.25-g0210-base/security/smack/smackfs.c  2008-02-10
 19:30:47.0 -0800 +++
 linux-2.6.25-g0210/security/smack/smackfs.c   2008-02-11
 07:14:54.0 -0800 @@ -45,6 +45,7 @@ enum smk_inos {
   */
  static DEFINE_MUTEX(smack_list_lock);
  static DEFINE_MUTEX(smack_cipso_lock);
 +static DEFINE_MUTEX(smack_ambient_lock);

  /*
   * This is the ambient label for network traffic.
 @@ -363,6 +364,27 @@ void smk_cipso_doi(void)
  __func__, __LINE__, rc);
  }

 +/**
 + * smk_unlbl_ambient - initialize the unlabeled domain
 + */
 +void smk_unlbl_ambient(char *oldambient)
 +{
 + int rc;
 + struct netlbl_audit audit_info;

You should try and populate the 'audit_info' struct with actual info so 
the generated audit record is more useful for people who care about 
those things.  It's only two fields, 'secid' and 'loginuid', which are 
pretty self-explanatory.

 + if (oldambient != NULL) {
 + rc = netlbl_cfg_map_del(oldambient, audit_info);
 + if (rc != 0)
 + printk(KERN_WARNING %s:%d remove rc = %d\n,
 +__func__, __LINE__, rc);
 + }
 +
 + rc = netlbl_cfg_unlbl_add_map(smack_net_ambient, audit_info);
 + if (rc != 0)
 + printk(KERN_WARNING %s:%d add rc = %d\n,
 +__func__, __LINE__, rc);
 +}
 +
  /*
   * Seq_file read operations for /smack/cipso
   */
 @@ -709,7 +731,6 @@ static ssize_t smk_read_ambient(struct f
   size_t cn, loff_t *ppos)
  {
   ssize_t rc;
 - char out[SMK_LABELLEN];
   int asize;

   if (*ppos != 0)
 @@ -717,23 +738,18 @@ static ssize_t smk_read_ambient(struct f
   /*
* Being careful to avoid a problem in the case where
* smack_net_ambient gets changed in midstream.
 -  * Since smack_net_ambient is always set with a value
 -  * from the label list, including initially, and those
 -  * never get freed, the worst case is that the pointer
 -  * gets changed just after this strncpy, in which case
 -  * the value 

Re: e1000e hardware CRC stripping breaks bridging

[Kok, Auke]

Daniel Drake wrote:
 Johan Andersson reported on the Gentoo bugzilla that the hardware CRC
 stripping enabled by e1000e breaks bridging because sometimes the CRC is
 not stripped:
 https://bugs.gentoo.org/show_bug.cgi?id=209235
 
 Apparently upstream are aware but I couldn't find any mails or bug
 reports on this topic.
 
 What's the current status of this issue? Perhaps we should disable
 hardware CRC stripping for 2.6.24.x/2.6.25 until this gets fixed?

Jesse figured it out. I just send you a patch to test, can you guys give that a
try and see if it fixes the situation? Johan?

thanks,

Auke
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: e1000e hardware CRC stripping breaks bridging

[Andy Gospodarek]

On Tue, Feb 12, 2008 at 02:57:50PM +0100, Johan Andersson wrote:
 Here is the bug report:
 http://bugzilla.kernel.org/show_bug.cgi?id=9940
 
 /Johan
 
 On Tue, 2008-02-12 at 13:27 +, Daniel Drake wrote:
  Hi,
  
  Johan Andersson reported on the Gentoo bugzilla that the hardware CRC 
  stripping enabled by e1000e breaks bridging because sometimes the CRC is 
  not stripped:
  https://bugs.gentoo.org/show_bug.cgi?id=209235
  
  Apparently upstream are aware but I couldn't find any mails or bug 
  reports on this topic.
  
  What's the current status of this issue? Perhaps we should disable 
  hardware CRC stripping for 2.6.24.x/2.6.25 until this gets fixed?
  
  Thanks,
  Daniel


This patch, just needs to get reverted:

commit 140a74802894e9db57e5cd77ccff77e590ece5f3
Author: Auke Kok [EMAIL PROTECTED]
Date:   Thu Oct 25 13:57:58 2007 -0700

e1000e: Re-enable SECRC - crc stripping

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Fix comment for skb_pull_rcsum

[David Miller]

From: Urs Thuermann [EMAIL PROTECTED]
Date: 10 Feb 2008 10:48:07 +0100

 Fix comment for skb_pull_rcsum
 
 Signed-off-by: Urs Thuermann [EMAIL PROTECTED]

Applied, thanks.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC, PATCH]: Pass link level header from/to PPP interface

[David Miller]

From: Urs Thuermann [EMAIL PROTECTED]
Date: 10 Feb 2008 10:48:51 +0100

 So what is your opinion about this change?

No general objections from me.

But if libpcap and tcpdump can already identify PPP packets
then, besides consistency, what does this buy us other
than potential breakage?
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH][GENETLINK]: Relax dances with genl_lock.

[Pavel Emelyanov]

The genl_unregister_family() calls the genl_unregister_mc_groups(), 
which takes and releases the genl_lock and then locks and releases
this lock itself.

Relax this behavior, all the more so the genl_unregister_mc_groups() 
is called from genl_unregister_family() only.

I'm not sure, whether this is 2.6.25 material, but the patch looks
pretty simple. Should I hold it till 2.6.26?

Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]

---

diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index 150579a..d16929c 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -230,10 +230,8 @@ static void genl_unregister_mc_groups(struct genl_family 
*family)
 {
struct genl_multicast_group *grp, *tmp;
 
-   genl_lock();
list_for_each_entry_safe(grp, tmp, family-mcast_groups, list)
__genl_unregister_mc_group(family, grp);
-   genl_unlock();
 }
 
 /**
@@ -396,10 +394,10 @@ int genl_unregister_family(struct genl_family *family)
 {
struct genl_family *rc;
 
-   genl_unregister_mc_groups(family);
-
genl_lock();
 
+   genl_unregister_mc_groups(family);
+
list_for_each_entry(rc, genl_family_chain(family-id), family_list) {
if (family-id != rc-id || strcmp(rc-name, family-name))
continue;
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH][NETLABEL]: Fix lookup logic of netlbl_domhsh_search_def.

[David Miller]

From: Paul Moore [EMAIL PROTECTED]
Date: Tue, 12 Feb 2008 11:34:09 -0500

 On Tuesday 12 February 2008 11:27:16 am Pavel Emelyanov wrote:
  Currently, if the call to netlbl_domhsh_search succeeds the
  return result will still be NULL.
 
  Fix that, by returning the found entry (if any).
 
  Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
 
 Good catch, thanks.
 
 Acked-by: Paul Moore [EMAIL PROTECTED]

Applied, thanks everyone.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH][GENETLINK]: Relax dances with genl_lock.

[David Miller]

From: Pavel Emelyanov [EMAIL PROTECTED]
Date: Tue, 12 Feb 2008 20:16:13 +0300

 The genl_unregister_family() calls the genl_unregister_mc_groups(), 
 which takes and releases the genl_lock and then locks and releases
 this lock itself.
 
 Relax this behavior, all the more so the genl_unregister_mc_groups() 
 is called from genl_unregister_family() only.
 
 Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]

Ok, applied, thanks.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] e1000e: Fix CRC stripping in hardware context bug

[Andy Gospodarek]

On Tue, Feb 12, 2008 at 03:20:24PM -0800, Auke Kok wrote:
 CRC stripping was only correctly enabled for packet split recieves
 which is used when receiving jumbo frames. Correctly enable SECRC
 also for normal buffer packet receives.
 
 Tested by Andy Gospodarek and Johan Andersson, see bugzilla #9940.
 

This works well on my systems.

Signed-off-by: Andy Gospodarek [EMAIL PROTECTED]

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/4] fib_trie: improve output format for /proc/net/fib_trie

[Stephen Hemminger]

Make output format prettier (more tree like).

   local:
   --- 0.0.0.0/0
 |--- 10.111.111.0/24
 |  +-- 10.111.111.0/32 link broadcast
 |  |--- 10.111.111.254/31
 |  |  +-- 10.111.111.254/32 host local
 |  |  +-- 10.111.111.255/32 link broadcast
 |--- 127.0.0.0/8
 |  |--- 127.0.0.0/31
 |  |  +-- 127.0.0.0/32 link broadcast
 |  |  +-- 127.0.0.0/8 host local
 |  |  +-- 127.0.0.1/32 host local
 |  +-- 127.255.255.255/32 link broadcast
 |--- 192.168.1.0/24
 |  |--- 192.168.1.0/28
 |  |  +-- 192.168.1.0/32 link broadcast
 |  |  +-- 192.168.1.9/32 host local
 |  +-- 192.168.1.255/32 link broadcast
   main:
   --- 0.0.0.0/0
 |--- 0.0.0.0/4
 |  +-- 0.0.0.0/0 universe unicast
 |  +-- 10.111.111.0/24 link unicast
 +-- 169.254.0.0/16 link unicast
 +-- 192.168.1.0/24 link unicast
   
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
 net/ipv4/fib_trie.c |  106 ++
 1 files changed, 55 insertions(+), 51 deletions(-)

diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index 1ff446d..72338cd 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -2340,46 +2340,57 @@ static void fib_trie_seq_stop(struct seq_file *seq, 
void *v)
rcu_read_unlock();
 }
 
+/* print left side of tree */
 static void seq_indent(struct seq_file *seq, int n)
 {
-   while (n--  0) seq_puts(seq,);
-}
-
-static inline const char *rtn_scope(char *buf, size_t len, enum rt_scope_t s)
-{
-   switch (s) {
-   case RT_SCOPE_UNIVERSE: return universe;
-   case RT_SCOPE_SITE: return site;
-   case RT_SCOPE_LINK: return link;
-   case RT_SCOPE_HOST: return host;
-   case RT_SCOPE_NOWHERE:  return nowhere;
-   default:
-   snprintf(buf, len, scope=%d, s);
-   return buf;
-   }
+   while (n--  0)
+   seq_puts(seq,   |);
 }
 
 static const char *rtn_type_names[__RTN_MAX] = {
-   [RTN_UNSPEC] = UNSPEC,
-   [RTN_UNICAST] = UNICAST,
-   [RTN_LOCAL] = LOCAL,
-   [RTN_BROADCAST] = BROADCAST,
-   [RTN_ANYCAST] = ANYCAST,
-   [RTN_MULTICAST] = MULTICAST,
-   [RTN_BLACKHOLE] = BLACKHOLE,
-   [RTN_UNREACHABLE] = UNREACHABLE,
-   [RTN_PROHIBIT] = PROHIBIT,
-   [RTN_THROW] = THROW,
-   [RTN_NAT] = NAT,
-   [RTN_XRESOLVE] = XRESOLVE,
+   [RTN_UNSPEC]= unspec,
+   [RTN_UNICAST]   = unicast,
+   [RTN_LOCAL] = local,
+   [RTN_BROADCAST] = broadcast,
+   [RTN_ANYCAST]   = anycast,
+   [RTN_MULTICAST] = multicast,
+   [RTN_BLACKHOLE] = blackhole,
+   [RTN_UNREACHABLE] = unreachable,
+   [RTN_PROHIBIT]  = prohibit,
+   [RTN_THROW] = throw,
+   [RTN_NAT]   = nat,
+   [RTN_XRESOLVE]  = xresolve,
 };
 
-static inline const char *rtn_type(char *buf, size_t len, unsigned t)
-{
-   if (t  __RTN_MAX  rtn_type_names[t])
-   return rtn_type_names[t];
-   snprintf(buf, len, type %u, t);
-   return buf;
+static void fib_trie_show_alias(struct seq_file *seq, const struct fib_alias 
*fa)
+{
+   switch (fa-fa_scope) {
+   case RT_SCOPE_UNIVERSE:
+   seq_puts(seq, universe);
+   break;
+   case RT_SCOPE_SITE:
+   seq_puts(seq,  site);
+   break;
+   case RT_SCOPE_LINK:
+   seq_puts(seq,  link);
+   break;
+   case RT_SCOPE_HOST:
+   seq_puts(seq,  host);
+   break;
+   case RT_SCOPE_NOWHERE:
+   seq_puts(seq,  nowhere);
+   break;
+   default:
+   seq_printf(seq, scope:%d, fa-fa_scope);
+   }
+
+   if (fa-fa_type  __RTN_MAX  rtn_type_names[fa-fa_type])
+   seq_printf(seq,  %s, rtn_type_names[fa-fa_type]);
+   else
+   seq_printf(seq,  type:%u, fa-fa_type);
+   
+   if (fa-fa_tos)
+   seq_printf(seq,  tos:%#x, fa-fa_tos);
 }
 
 /* Pretty print the trie */
@@ -2402,10 +2413,8 @@ static int fib_trie_seq_show(struct seq_file *seq, void 
*v)
struct tnode *tn = (struct tnode *) n;
__be32 prf = htonl(mask_pfx(tn-key, tn-pos));
 
-   seq_indent(seq, iter-depth-1);
-   seq_printf(seq,   +-- %d.%d.%d.%d/%d %d %d %d\n,
-  NIPQUAD(prf), tn-pos, tn-bits, tn-full_children,
-  tn-empty_children);
+   seq_indent(seq, iter-depth - 1);
+   seq_printf(seq, --- %d.%d.%d.%d/%d\n, NIPQUAD(prf), tn-pos);
 
} else {
struct leaf *l = (struct leaf *) n;
@@ -2413,24 +2422,19 @@ static int fib_trie_seq_show(struct seq_file *seq, void 
*v)
struct hlist_node *node;
__be32 val = htonl(l-key);
 
-   seq_indent(seq, iter-depth);
-   seq_printf(seq,   |-- %d.%d.%d.%d\n, NIPQUAD(val));
-
hlist_for_each_entry_rcu(li, 

Re: [PATCH 1/3][NETLABEL]: Compilation for CONFIG_AUDIT=n case.

[David Miller]

From: Pavel Emelyanov [EMAIL PROTECTED]
Date: Thu, 07 Feb 2008 20:20:30 +0300

 The audit_log_start() will expand into an empty do { } while (0)
 construction and the audit_ctx becomes unused.
 
 The solution: push current-audit_context into audit_log_start()
 directly, since it is not required in any other place in the 
 calling function.
 
 Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]

Applied.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3][NETLABEL]: Don't produce unused variables when IPv6 is off.

[David Miller]

From: Pavel Emelyanov [EMAIL PROTECTED]
Date: Thu, 07 Feb 2008 20:24:15 +0300

 Some code declares variables on the stack, but uses them
 under #ifdef CONFIG_IPV6, so thay become unused when ipv6
 is off. Fortunately, they are used in a switch's case
 branches, so the fix is rather simple.
 
 Is it OK from coding style POV to add braces inside cases,
 or should I better avoid such style and rework the patch?
 
 Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]

Applied, thanks.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: e1000e hardware CRC stripping breaks bridging

[Johan Andersson]

Kok, Auke wrote:

Jesse figured it out. I just send you a patch to test, can you guys give that a
try and see if it fixes the situation? Johan?

thanks,

Auke
  

Yes, I will test this patch right away.

/Johan
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3][NETLABLE]: Hide netlbl_unlabel_audit_addr6 under ifdef CONFIG_IPV6.

[David Miller]

From: Pavel Emelyanov [EMAIL PROTECTED]
Date: Thu, 07 Feb 2008 20:25:52 +0300

 This one is called from under this config only, so move
 it in the same place.
 
 Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]

Applied.

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] fib_trie: rcu_assign_pointer warning fix

[Jarek Poplawski]

On Tue, Feb 12, 2008 at 08:32:18PM +0100, Jarek Poplawski wrote:
...
 It seems the above version of this macro uses the barrier for 0, but
 if I miss something, or for these other: documenting reasons,

...or __builtin_constants could be used for indexing (?!),

 then of
 course you are right.

Jarek P.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Reorder ACK/RST checking in LISTEN state

[Kris Katterjohn]

Hey everyone,

[I'm not subscribed, so please CC me on any replies]

I've attached a patch that changes the order of the ACK and RST checking 
in the LISTEN state in tcp_rcv_state_process() in tcp_input.c


Before:  If an ACK/RST packet is received, then tcp_rcv_state_process() 
would return 1 because of the ACK.  Then (following the function calls 
in tcp_ipv4.c and tcp_minisocks.c), tcp_v4_send_reset() is called--but 
since there is a RST in the packet it just returns.  After this, the 
kfree_skb() is called.  The same goes in tcp_ipv6.c as well.


But if the order of the ACK and RST checking is reversed, __kfree_skb() 
is called in tcp_rcv_state_process() because of the RST and the function 
returns 0, which skips that other useless stuff.


This is the order specified on page 65 of RFC 793 anyway.

Signed-off-by: Kris Katterjohn [EMAIL PROTECTED]

Thanks,
Kris Katterjohn
--- net/ipv4/tcp_input.c	2008-02-13 00:05:59.0 -0600
+++ net/ipv4/tcp_input.c	2008-02-13 00:10:40.0 -0600
@@ -4962,12 +4962,12 @@ int tcp_rcv_state_process(struct sock *s
 		goto discard;
 
 	case TCP_LISTEN:
-		if (th-ack)
-			return 1;
-
 		if (th-rst)
 			goto discard;
 
+		if (th-ack)
+			return 1;
+
 		if (th-syn) {
 			if (icsk-icsk_af_ops-conn_request(sk, skb)  0)
 return 1;

Re: [PATCH] [IPV6] Minor cleanup: remove unused method declaration (net/ndisc.h).

[David Miller]

From: Rami Rosen [EMAIL PROTECTED]
Date: Sun, 10 Feb 2008 18:40:13 +0200

 This patch removes unused declaration of dflt_rt_lookup() method in
 include/net/ndisc.h
 
 Signed-off-by: Rami Rosen [EMAIL PROTECTED]

Applied, thanks.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH][NETLABEL]: Fix lookup logic of netlbl_domhsh_search_def.

[Pavel Emelyanov]

Currently, if the call to netlbl_domhsh_search succeeds the
return result will still be NULL.

Fix that, by returning the found entry (if any).

Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]

---

diff --git a/net/netlabel/netlabel_domainhash.c 
b/net/netlabel/netlabel_domainhash.c
index 9a8ea01..fd46231 100644
--- a/net/netlabel/netlabel_domainhash.c
+++ b/net/netlabel/netlabel_domainhash.c
@@ -150,11 +150,11 @@ static struct netlbl_dom_map 
*netlbl_domhsh_search_def(const char *domain)
entry = netlbl_domhsh_search(domain);
if (entry == NULL) {
entry = rcu_dereference(netlbl_domhsh_def);
-   if (entry != NULL  entry-valid)
-   return entry;
+   if (entry != NULL  !entry-valid)
+   entry = NULL;
}
 
-   return NULL;
+   return entry;
 }
 
 /*
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] rtnetlink.c: send a single notification on device state changes

[David Miller]

From: Laszlo Attila Toth [EMAIL PROTECTED]
Date: Thu,  7 Feb 2008 12:57:50 +0100

 In do_setlink() a single notification is sent at the end of the function
 if any modification occured. If the address has been changed, another
 notification is sent.
 
 Both of them is required because originally only the NETDEV_CHANGEADDR
 notification was sent and although device state change implies address
 change, some programs may expect the original notification. It remains
 for compatibity.
 
 If set_operstate() is called from do_setlink(), it doesn't send
 a notification, only if it is called from rtnl_create_link() as earlier.
 
 Signed-off-by: Laszlo Attila Toth [EMAIL PROTECTED]

Looks good, applied.

Let's hope this doesn't break some stupid application
unintentionally.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [git patches] net driver updates

[Jeff Garzik]

Ben Dooks wrote:

These two where meant to be from Laurent Pinchart, they do have
the correct signed-off lines in for him and start with Patch from:. Is
there any chance of fixing the authour attribution now?


The first line of the changeset mentions it.  Other than that, nope.

Jeff


--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bug 9750] [patch 2.6.25] dev: avoid a race that triggers assertion failure

[Jeff Garzik]

Matti Linnanvuori wrote:

From: Matti Linnanvuori [EMAIL PROTECTED]

There is a race in Linux kernel file net/core/dev.c, function dev_close.
The function calls function dev_deactivate, which calls function
dev_watchdog_down that deletes the watchdog timer. However, after that, a
driver can call netif_carrier_ok, which calls function
__netdev_watchdog_up that can add the watchdog timer again. Function
unregister_netdevice calls function dev_shutdown that traps the bug
!timer_pending(dev-watchdog_timer). Moving dev_deactivate after
netif_running() has been cleared prevents function netif_carrier_on
from calling __netdev_watchdog_up and adding the watchdog timer again.

Signed-off-by: Matti Linnanvuori [EMAIL PROTECTED]

---

--- linux-2.6.25/net/core/dev.c2008-02-12 12:37:51.206833000 +0200
+++ b/net/core/dev.c2008-02-12 12:38:48.727611400 +0200
@@ -1071,8 +1071,6 @@ int dev_close(struct net_device *dev)
  */
 call_netdevice_notifiers(NETDEV_GOING_DOWN, dev);
 
-dev_deactivate(dev);

-
 clear_bit(__LINK_STATE_START, dev-state);
 
 /* Synchronize to scheduled poll. We cannot touch poll list,

@@ -1083,6 +1081,7 @@ int dev_close(struct net_device *dev)
  */
 smp_mb__after_clear_bit(); /* Commit netif_running(). */
 
+dev_deactivate(dev);

 /*
  *Call the device specific close. This cannot fail.
  *Only if device is UP


This is more for davem (he does net/* stuff)

Jeff




--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: xfrm_input() and -seq oddities

[David Miller]

From: Herbert Xu [EMAIL PROTECTED]
Date: Sun, 3 Feb 2008 11:20:19 +1100

 [IPSEC]: Fix bogus usage of u64 on input sequence number
 
 Al Viro spotted a bogus use of u64 on the input sequence number which
 is big-endian.  This patch fixes it by giving the input sequence number
 its own member in the xfrm_skb_cb structure.
 
 Signed-off-by: Herbert Xu [EMAIL PROTECTED]

Applied, thanks Herbert.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: xfrm_input() and -seq oddities

[David Miller]

From: Herbert Xu [EMAIL PROTECTED]
Date: Mon, 4 Feb 2008 09:00:27 +1100

 On Sun, Feb 03, 2008 at 11:04:44AM +, Al Viro wrote:
  IMO that at least deserves a comment near xfrm_input()...
 
 Sure.  There is already a comment about encap_type  0 in there, but
 I think you'll probably be able to explain it much better than I can
 looking in from the outside so if you have a patch... :)

Agreed on all counts ;-)
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND] [XFRM]: Speed up xfrm_policy and xfrm_state walking

[David Miller]

From: Timo_Teräs [EMAIL PROTECTED]
Date: Fri, 01 Feb 2008 16:58:04 +0200

 @@ -1780,6 +1786,7 @@ static int check_reqid(struct xfrm_policy *xp, int dir, 
 int count, void *ptr)
  
  static u32 gen_reqid(void)
  {
 + struct xfrm_policy_walk walk;
   u32 start;
   static u32 reqid = IPSEC_MANUAL_REQID_MAX;
  
 @@ -1788,9 +1795,10 @@ static u32 gen_reqid(void)
   ++reqid;
   if (reqid == 0)
   reqid = IPSEC_MANUAL_REQID_MAX+1;
 - if (xfrm_policy_walk(XFRM_POLICY_TYPE_MAIN, check_reqid,
 -  (void*)reqid) != -EEXIST)
 + xfrm_policy_walk_init(walk, XFRM_POLICY_TYPE_MAIN);
 + if (xfrm_policy_walk(walk, check_reqid, (void*)reqid) != 
 -EEXIST)
   return reqid;
 + xfrm_policy_walk_done(walk);
   } while (reqid != start);
   return 0;
  }

This will potentially leak walk-policy in the != -EEXIST case.

I think what needs to happen is we invoke xfrm_policy_walk_done()
unconditionally, then we'll potentially return reqid.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: e1000e hardware CRC stripping breaks bridging

[Johan Andersson]

Here is the bug report:
http://bugzilla.kernel.org/show_bug.cgi?id=9940

/Johan

On Tue, 2008-02-12 at 13:27 +, Daniel Drake wrote:
 Hi,
 
 Johan Andersson reported on the Gentoo bugzilla that the hardware CRC 
 stripping enabled by e1000e breaks bridging because sometimes the CRC is 
 not stripped:
 https://bugs.gentoo.org/show_bug.cgi?id=209235
 
 Apparently upstream are aware but I couldn't find any mails or bug 
 reports on this topic.
 
 What's the current status of this issue? Perhaps we should disable 
 hardware CRC stripping for 2.6.24.x/2.6.25 until this gets fixed?
 
 Thanks,
 Daniel
 --
 To unsubscribe from this list: send the line unsubscribe netdev in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

e1000e hardware CRC stripping breaks bridging

[Daniel Drake]

Hi,

Johan Andersson reported on the Gentoo bugzilla that the hardware CRC 
stripping enabled by e1000e breaks bridging because sometimes the CRC is 
not stripped:

https://bugs.gentoo.org/show_bug.cgi?id=209235

Apparently upstream are aware but I couldn't find any mails or bug 
reports on this topic.


What's the current status of this issue? Perhaps we should disable 
hardware CRC stripping for 2.6.24.x/2.6.25 until this gets fixed?


Thanks,
Daniel
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: r8169 auto-negotiation problem

[fgnijuhhu guduggurehug]

 fgnijuhhu guduggurehug  :
 [...]
 I already posted my problem and what I did to solve it on
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461429.

 Have you tried anything more recent than a 2.6.18 based kernel ?

No, but if changes were made to the iniatialization of the chipset in the 
current driver (mine was 2.2LK), this might do the trick. The problem is that 
the error is rather erratic and unreproducible.

Anyway, how to best upgrade the kernel in debian (without problems, of course)? 
The problem right now is that every apt-get upgrade reverts the r8169 driver to 
the old one...
_
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH][PPPOL2TP]: Fix SMP oops in pppol2tp driver

[Jarek Poplawski]

On Tue, Feb 12, 2008 at 10:58:21AM +, James Chapman wrote:
...
 Here is a trace from when we had _bh locks.

Very nice...

...But since it's quite long, and if you don't know all these paths
this could take some time, maybe one question: so if lockdep got these
locks right (sometimes it can be wrong when the same structures are
nested), then it seems some problem is with this place below. This
lock is taken for writing with softirqs enabled here, and IMHO it
would be interesting to test if changing this is enough for lockdep.
It seems this is in ip4_datagram_connect() during sk_dst_reset() or
sk_dst_set(). So maybe you could try with local_bh_disable/enable()
around them (or maybe some better idea)? Anyway, I'll try to learn
this more in the meantime.

Jarek P.

 Feb  5 16:26:32  to a soft-irq-unsafe lock:
 Feb  5 16:26:32  (sk-sk_dst_lock){}
 Feb  5 16:26:32  ... which became soft-irq-unsafe at:
 Feb  5 16:26:32  ...  [c014e02e] mark_held_locks+0x5e/0x80
 Feb  5 16:26:32  [c014ed92] __lock_acquire+0x6a2/0x10a0
 Feb  5 16:26:32  [c010f5b0] save_stack_trace+0x20/0x40
 Feb  5 16:26:32  [c014c524] add_lock_to_list+0x44/0xb0
 Feb  5 16:26:32  [c03dea29] __udp_lib_get_port+0x19/0x200
 Feb  5 16:26:32  [c014f735] __lock_acquire+0x1045/0x10a0
 Feb  5 16:26:32  [c014f804] lock_acquire+0x74/0xa0
 Feb  5 16:26:32  [c03db0a3] ip4_datagram_connect+0x53/0x380
 Feb  5 16:26:32  [c040418a] _write_lock+0x2a/0x40
 Feb  5 16:26:32  [c03db0a3] ip4_datagram_connect+0x53/0x380
 Feb  5 16:26:32  [c03db0a3] ip4_datagram_connect+0x53/0x380
 Feb  5 16:26:32  [c014e1c5] trace_hardirqs_on+0xc5/0x170
 Feb  5 16:26:32  [c0132317] local_bh_enable_ip+0xa7/0x120
 Feb  5 16:26:32  [c014e1c5] trace_hardirqs_on+0xc5/0x170
 Feb  5 16:26:32  [c040414f] _spin_lock_bh+0x2f/0x40
 Feb  5 16:26:32  [c03e4d55] inet_dgram_connect+0x35/0x80
 Feb  5 16:26:32  [c038ec52] sys_connect+0x82/0xd0
 Feb  5 16:26:32  [c01455df] down_read_trylock+0x4f/0x60
 Feb  5 16:26:32  [c011fe9c] do_page_fault+0xfc/0x940
 Feb  5 16:26:32  [c0404024] _spin_unlock+0x14/0x20
 Feb  5 16:26:32  [c03905f8] sys_socketcall+0x98/0x280
 Feb  5 16:26:32  [c014e1c5] trace_hardirqs_on+0xc5/0x170
 Feb  5 16:26:32  [c02a86ba] copy_to_user+0x3a/0x70
 Feb  5 16:26:32  [c0108417] restore_nocheck+0x12/0x15
 Feb  5 16:26:32  [c01083aa] syscall_call+0x7/0xb
 Feb  5 16:26:32  [] 0x
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Bug 9750] [patch 2.6.25 v2] dev: avoid a race that triggers assertion failure

[Matti Linnanvuori]

From: Matti Linnanvuori [EMAIL PROTECTED]

There is a race in Linux kernel file net/core/dev.c, function dev_close.
The function calls function dev_deactivate, which calls function
dev_watchdog_down that deletes the watchdog timer. However, after that, a
driver can call netif_carrier_ok, which calls function
__netdev_watchdog_up that can add the watchdog timer again. Function
unregister_netdevice calls function dev_shutdown that traps the bug
!timer_pending(dev-watchdog_timer). Moving dev_deactivate after
netif_running() has been cleared prevents function netif_carrier_on
from calling __netdev_watchdog_up and adding the watchdog timer again.

Signed-off-by: Matti Linnanvuori [EMAIL PROTECTED]

---





  

Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

patch
Description: Binary data

Re: [PATCH] Reorder ACK/RST checking in LISTEN state

[David Miller]

From: Kris Katterjohn [EMAIL PROTECTED]
Date: Wed, 13 Feb 2008 00:38:13 -0600

 I've attached a patch that changes the order of the ACK and RST checking 
 in the LISTEN state in tcp_rcv_state_process() in tcp_input.c
 
 Before:  If an ACK/RST packet is received, then tcp_rcv_state_process() 
 would return 1 because of the ACK.  Then (following the function calls 
 in tcp_ipv4.c and tcp_minisocks.c), tcp_v4_send_reset() is called--but 
 since there is a RST in the packet it just returns.  After this, the 
 kfree_skb() is called.  The same goes in tcp_ipv6.c as well.
 
 But if the order of the ACK and RST checking is reversed, __kfree_skb() 
 is called in tcp_rcv_state_process() because of the RST and the function 
 returns 0, which skips that other useless stuff.
 
 This is the order specified on page 65 of RFC 793 anyway.
 
 Signed-off-by: Kris Katterjohn [EMAIL PROTECTED]

This code has been like this for I don't know how many years,
the end result is the same both before and after your patch,
and the added expense of the existing code is frankly trivial.

I really don't want to apply this, it doesn't buy us anything,
sorry.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bug 9750] [patch 2.6.25 v2] dev: avoid a race that triggers assertion failure

[David Miller]

From: Matti Linnanvuori [EMAIL PROTECTED]
Date: Tue, 12 Feb 2008 23:06:41 -0800 (PST)

 There is a race in Linux kernel file net/core/dev.c, function dev_close.
 The function calls function dev_deactivate, which calls function
 dev_watchdog_down that deletes the watchdog timer. However, after that, a
 driver can call netif_carrier_ok, which calls function
 __netdev_watchdog_up that can add the watchdog timer again. Function
 unregister_netdevice calls function dev_shutdown that traps the bug
 !timer_pending(dev-watchdog_timer). Moving dev_deactivate after
 netif_running() has been cleared prevents function netif_carrier_on
 from calling __netdev_watchdog_up and adding the watchdog timer again.
 
 Signed-off-by: Matti Linnanvuori [EMAIL PROTECTED]

Patch applied, thanks.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [git patches] net driver updates

[Ben Dooks]

On Mon, Feb 11, 2008 at 12:05:16PM -0500, Jeff Garzik wrote:
 Mostly fixes, a few cleanups (generally assisting fixes), and an
 exception for PS3 wireless because it had been posted, reviewed and
 acked for a while, just not committed.

Thanks, good to get the DM9000 changes moving.
 
 Please pull from 'upstream-davem' branch of
 master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git 
 upstream-davem
 

 Ben Dooks (24):
   DM9000: Fix endian-ness of data accesses.
   DM9000: Add platform data to specify external phy

These two where meant to be from Laurent Pinchart, they do have
the correct signed-off lines in for him and start with Patch from:. Is
there any chance of fixing the authour attribution now?

-- 
Ben ([EMAIL PROTECTED], http://www.fluff.org/)

  'a smiley only costs 4 bytes'
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-2.6.25] net: Improve cache line coherency of ingress qdisc

[David Miller]

From: Neil Turton [EMAIL PROTECTED]
Date: Thu, 17 Jan 2008 11:04:44 +

 Move the ingress qdisc members of struct net_device from the transmit
 cache line to the receive cache line to avoid cache line ping-pong.
 These members are only used on the receive path.
 
 Signed-off-by: Neil Turton [EMAIL PROTECTED]

Looks reasonable, applied, thanks!
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH][PPPOL2TP]: Fix SMP oops in pppol2tp driver

[James Chapman]

David Miller wrote:

From: James Chapman [EMAIL PROTECTED]
Date: Mon, 11 Feb 2008 23:41:18 +


Jarek Poplawski wrote:

On Mon, Feb 11, 2008 at 10:19:35PM +, James Chapman wrote:
...
Below is example output from lockdep. The oops is reproducible when  
creating/deleting lots of sessions while passing data. The lock is being  
acquired for read and write in softirq contexts.


Is there a better way to fix this?

=
[ INFO: inconsistent lock state ]
2.6.24-core2 #1
-
inconsistent {in-softirq-R} - {softirq-on-W} usage.
openl2tpd/3215 [HC0[0]:SC0[0]:HE1:SE1] takes:
  (tunnel-hlist_lock){---?}, at: [f8eea157]
pppol2tp_connect+0x517/0x6d0 [pppol2tp]
{in-softirq-R} state was registered at:

IMHO, according to this, disabling bh should be enough. And if it's
like in this report: only read_lock is taken from softirqs, then this
should be necessary to change only all write_locks to write_lock_bh
(of course unless somewhere bhs are disabled already). Unless I miss
something?!
I thought so too. I tried _bh locks first and the problem still 
occurred. Maybe I'll try it again in case I messed something up.


I agree with Jarek here, I look at all the code paths that take
-hlist_lock and all of them are in user context or software
interrupts.

Please get a lockdep trace with the change to _bh intead of
hw interrupt protection so we can find out what that doesn't
work.

Thanks!


Here is a trace from when we had _bh locks.

Feb  5 16:26:32  ==
Feb  5 16:26:32  [ INFO: soft-safe - soft-unsafe lock order detected ]
Feb  5 16:26:32  2.6.24-core2 #1
Feb  5 16:26:32  --
Feb  5 16:26:32  pppd/3224 [HC0[0]:SC0[2]:HE1:SE0] is trying to acquire:
Feb  5 16:26:32  (sk-sk_dst_lock){}, at: [f8efacac] 
pppol2tp_xmit+0x23c/0x460 [pppol2tp]

Feb  5 16:26:32
Feb  5 16:26:32  and this task is already holding:
Feb  5 16:26:32  (pch-downl){-...}, at: [f8eb828e] 
ppp_push+0x44e/0x620 [ppp_generic]

Feb  5 16:26:32  which would create a new lock dependency:
Feb  5 16:26:32  (pch-downl){-...} - (sk-sk_dst_lock){}
Feb  5 16:26:32
Feb  5 16:26:32  but this new dependency connects a soft-irq-safe lock:
Feb  5 16:26:32  (pch-upl){-.-+}
Feb  5 16:26:32  ... which became soft-irq-safe at:
Feb  5 16:26:32  [c014d87f] check_usage_backwards+0x1f/0x50
Feb  5 16:26:32  [c014c479] save_trace+0x39/0xa0
Feb  5 16:26:32  [c014edaf] __lock_acquire+0x6bf/0x10a0
Feb  5 16:26:32  [c014ee8e] __lock_acquire+0x79e/0x10a0
Feb  5 16:26:32  [c014ee8e] __lock_acquire+0x79e/0x10a0
Feb  5 16:26:32  [c014f804] lock_acquire+0x74/0xa0
Feb  5 16:26:32  [f8eba092] ppp_input+0x62/0x140 [ppp_generic]
Feb  5 16:26:32  [c040425f] _read_lock_bh+0x2f/0x40
Feb  5 16:26:32  [f8eba092] ppp_input+0x62/0x140 [ppp_generic]
Feb  5 16:26:32  [f8eba092] ppp_input+0x62/0x140 [ppp_generic]
Feb  5 16:26:32  [f8ef915a] pppol2tp_recv_core+0x46a/0x960 [pppol2tp]
Feb  5 16:26:32  [f8ef967e] pppol2tp_udp_encap_recv+0x2e/0x70 [pppol2tp]
Feb  5 16:26:32  [c0403fd4] _read_unlock+0x14/0x20
Feb  5 16:26:32  [c03dd6b6] udp_queue_rcv_skb+0x106/0x2a0
Feb  5 16:26:32  [c03ddc7a] __udp4_lib_rcv+0x42a/0x7e0
Feb  5 16:26:32  [f8d5c090] ipt_hook+0x0/0x20 [iptable_filter]
Feb  5 16:26:32  [c03bc2fa] ip_local_deliver_finish+0xca/0x1c0
Feb  5 16:26:32  [c03bc25e] ip_local_deliver_finish+0x2e/0x1c0
Feb  5 16:26:32  [c03bbfcf] ip_rcv_finish+0xff/0x360
Feb  5 16:26:32  [c03bc6fc] ip_rcv+0x20c/0x2a0
Feb  5 16:26:32  [c03bbed0] ip_rcv_finish+0x0/0x360
Feb  5 16:26:32  [c039ad87] netif_receive_skb+0x317/0x4b0
Feb  5 16:26:32  [c039ab70] netif_receive_skb+0x100/0x4b0
Feb  5 16:26:32  [f8d7e27a] e1000_clean_rx_irq_ps+0x28a/0x560 [e1000]
Feb  5 16:26:32  [f8d7dff0] e1000_clean_rx_irq_ps+0x0/0x560 [e1000]
Feb  5 16:26:32  [f8d7b84d] e1000_clean+0x5d/0x290 [e1000]
Feb  5 16:26:32  [c039d580] net_rx_action+0x1a0/0x2a0
Feb  5 16:26:32  [c039d43f] net_rx_action+0x5f/0x2a0
Feb  5 16:26:32  [c0131e72] __do_softirq+0x92/0x120
Feb  5 16:26:32  [c0131f78] do_softirq+0x78/0x80
Feb  5 16:26:32  [c010b15a] do_IRQ+0x4a/0xa0
Feb  5 16:26:32  [c0127af0] finish_task_switch+0x0/0xc0
Feb  5 16:26:32  [c0108dcc] common_interrupt+0x24/0x34
Feb  5 16:26:32  [c0108dd6] common_interrupt+0x2e/0x34
Feb  5 16:26:32  [c01062d6] mwait_idle_with_hints+0x46/0x60
Feb  5 16:26:32  [c0106550] mwait_idle+0x0/0x20
Feb  5 16:26:32  [c0106694] cpu_idle+0x74/0xe0
Feb  5 16:26:32  [c0536a9a] start_kernel+0x30a/0x3a0
Feb  5 16:26:32  [c0536150] unknown_bootoption+0x0/0x1f0
Feb  5 16:26:32  [] 0x
Feb  5 16:26:32
Feb  5 16:26:32  to a soft-irq-unsafe lock:
Feb  5 16:26:32  (sk-sk_dst_lock){}
Feb  5 16:26:32  ... which became soft-irq-unsafe at:
Feb  5 16:26:32  ...  [c014e02e] mark_held_locks+0x5e/0x80
Feb  5 16:26:32  [c014ed92] __lock_acquire+0x6a2/0x10a0
Feb  5 16:26:32  [c010f5b0] save_stack_trace+0x20/0x40
Feb  5 16:26:32  [c014c524] add_lock_to_list+0x44/0xb0

Re: [PATCH][PPPOL2TP]: Fix SMP oops in pppol2tp driver

[Jarek Poplawski]

On Mon, Feb 11, 2008 at 11:42:12PM +, James Chapman wrote:
 Jarek Poplawski wrote:
 On Mon, Feb 11, 2008 at 11:49:24PM +0100, Jarek Poplawski wrote:
 On Mon, Feb 11, 2008 at 10:19:35PM +, James Chapman wrote:
 ...
 Below is example output from lockdep. The oops is reproducible when 
  creating/deleting lots of sessions while passing data. The lock is 
 being  acquired for read and write in softirq contexts.

 ...Hmmm... And according to this, changing read_locks should be
 necessary too.

 The patch changes both read and write locks.

Right! This was only errata to my earlier comment where I considered
only lockdep info and forgot about yours...

Sorry,
Jarek P.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [IRDA] irda_init() nuke useless debug printk

[maximilian attems]

irda_init()
dmesg line is not really informative, thus remove it.
There are better ways to know that a module is loaded.

Seen on a debian config with IRDA_DEBUG enabled.

Signed-off-by: maximilian attems [EMAIL PROTECTED]
---
 net/irda/irmod.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/net/irda/irmod.c b/net/irda/irmod.c
index 01554b9..73db875 100644
--- a/net/irda/irmod.c
+++ b/net/irda/irmod.c
@@ -90,8 +90,6 @@ static int __init irda_init(void)
 {
int ret = 0;
 
-   IRDA_DEBUG(0, %s()\n, __FUNCTION__);
-
/* Lower layer of the stack */
irlmp_init();
irlap_init();
-- 
1.5.4

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add IPv6 support to TCP SYN cookies

[YOSHIFUJI Hideaki / 吉藤英明]

In article [EMAIL PROTECTED] (at Thu, 07 Feb 2008 10:40:19 +0100), Eric 
Dumazet [EMAIL PROTECTED] says:

 [NET] IPV4: lower stack usage in cookie_hash() function
 
 400 bytes allocated on stack might be a litle bit too much. Using a 
 per_cpu var is more friendly.
 
 Signed-off-by: Eric Dumazet [EMAIL PROTECTED]

Applied to my inet6-2.6.26 tree.  Thanks.

--yoshfuji
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] fib_trie: rcu_assign_pointer warning fix

[Paul E. McKenney]

On Tue, Feb 12, 2008 at 08:57:14AM +, Jarek Poplawski wrote:
 On 12-02-2008 02:16, David Miller wrote:
  From: Stephen Hemminger [EMAIL PROTECTED]
  Date: Mon, 11 Feb 2008 16:59:54 -0800
  
  linux-kernel added to CC:, any change to generic kernel infrastructure
  should be posted there
  
  Eliminate warnings when rcu_assign_pointer is used with unsigned long.
  It is reasonable to use RCU with non-pointer values so allow it for general
  use.  Add a comment to explain the if test.
 
  Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
  ---
   include/linux/rcupdate.h |   13 +++--
   1 files changed, 7 insertions(+), 6 deletions(-)
 
  diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
  index 37a642c..c44ac87 100644
  --- a/include/linux/rcupdate.h
  +++ b/include/linux/rcupdate.h
  @@ -172,14 +172,15 @@ struct rcu_head {
* structure after the pointer assignment.  More importantly, this
* call documents which pointers will be dereferenced by RCU read-side
* code.
  + *
  + * If value is the NULL (constant 0), then no barrier is needed.
*/
   
  -#define rcu_assign_pointer(p, v) \
  -  ({ \
  -  if (!__builtin_constant_p(v) || \
  -  ((v) != NULL)) \
  -  smp_wmb(); \
  -  (p) = (v); \
  +#define rcu_assign_pointer(p, v)  \
  +  ({  \
  +  if (!(__builtin_constant_p(v)  v))\
 
 ...But, If value is the NULL (constant 0) we have:
 
 if (!(1  NULL != 0)) == if (!(0)) and the barrier is used?!

All programmers are blind, especially me.

You are right, Jarek.  I ran this through gcc, and the following
comes close:

#define rcu_assign_pointer(p, v) \
({ \
if (!__builtin_constant_p(v) || (v)) \
smp_wmb(); \
(p) = (v); \
})

But I am concerned about the following case:

rcu_assign_pointer(global_index, 0);

. . .

x = global_array[rcu_dereference(global_index)];

Since arrays have a zero-th element, we would really want a memory
barrier in this case.

So how about leaving the index-unfriendly version of rcu_assign_pointer()
and adding an rcu_assign_index() as follows?

Thanx, Paul

Signed-off-by: Paul E. McKenney [EMAIL PROTECTED]
---

 rcupdate.h |   18 ++
 1 file changed, 18 insertions(+)

diff -urpNa -X dontdiff linux-2.6.24/include/linux/rcupdate.h 
linux-2.6.24-rai/include/linux/rcupdate.h
--- linux-2.6.24/include/linux/rcupdate.h   2008-01-24 14:58:37.0 
-0800
+++ linux-2.6.24-rai/include/linux/rcupdate.h   2008-02-12 08:04:59.0 
-0800
@@ -278,6 +278,24 @@ extern struct lockdep_map rcu_lock_map;
})
 
 /**
+ * rcu_assign_index - assign (publicize) a index of a newly
+ * initialized array elementg that will be dereferenced by RCU
+ * read-side critical sections.  Returns the value assigned.
+ *
+ * Inserts memory barriers on architectures that require them
+ * (pretty much all of them other than x86), and also prevents
+ * the compiler from reordering the code that initializes the
+ * structure after the index assignment.  More importantly, this
+ * call documents which indexes will be dereferenced by RCU read-side
+ * code.
+ */
+
+#define rcu_assign_index(p, v) ({ \
+   smp_wmb(); \
+   (p) = (v); \
+   })
+
+/**
  * synchronize_sched - block until all CPUs have exited any non-preemptive
  * kernel code sequences.
  *
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH][NETLABEL]: Fix lookup logic of netlbl_domhsh_search_def.

[Paul Moore]

On Tuesday 12 February 2008 11:27:16 am Pavel Emelyanov wrote:
 Currently, if the call to netlbl_domhsh_search succeeds the
 return result will still be NULL.

 Fix that, by returning the found entry (if any).

 Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]

Good catch, thanks.

Acked-by: Paul Moore [EMAIL PROTECTED]

 ---

 diff --git a/net/netlabel/netlabel_domainhash.c
 b/net/netlabel/netlabel_domainhash.c index 9a8ea01..fd46231 100644
 --- a/net/netlabel/netlabel_domainhash.c
 +++ b/net/netlabel/netlabel_domainhash.c
 @@ -150,11 +150,11 @@ static struct netlbl_dom_map
 *netlbl_domhsh_search_def(const char *domain) entry =
 netlbl_domhsh_search(domain);
   if (entry == NULL) {
   entry = rcu_dereference(netlbl_domhsh_def);
 - if (entry != NULL  entry-valid)
 - return entry;
 + if (entry != NULL  !entry-valid)
 + entry = NULL;
   }

 - return NULL;
 + return entry;
  }

  /*

-- 
paul moore
linux security @ hp
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH][PPPOL2TP]: Fix SMP oops in pppol2tp driver

[Jarek Poplawski]

On Tue, Feb 12, 2008 at 10:00:03PM -0800, David Miller wrote:
 From: James Chapman [EMAIL PROTECTED]
 Date: Tue, 12 Feb 2008 10:58:21 +
 
  Here is a trace from when we had _bh locks.
 
 The problem is that the pppol2tp code calls sk_dst_get() in software
 interrupt context and that is not allowed.

Actually, this lockdep report probably warns of something else:
sk_dst_lock which is seen in process context with softirqs enabled
implicitly endangers some other (ppp_generic) locks, which depend
on ppp_generic pch-upl read_lock, which is taken in softirq context.

I can't see on this report any hardirqs dependancies, so it seems even
blocking hard interrupts, just like in this patch, shouldn't solve
this problem: if BHs were really disabled in exactly the same places,
then it seems this warning should trigger in both variants.

I studied long ago some similar problem with pppoe, and it looked like
ppp_generic needed some fix, but now I've to recall or re-learn almost
all and it needs more time... Anyway, there is a possibility, this
warning isn't so dangerous.

 sk_dst_get() grabs sk-sk_dst_lock without any BH enabling or
 disabling.
 
 It can do that because the usage is to make all the lock
 taking calls in user context, and in the packet processing
 paths use __sk_dst_get().

BTW, does it mean that ip4_datagram_connect() can be used only in user
context?

 Probably what the pppol2tp code should do is use __sk_dst_check()
 instead of sk_dst_get().  You then have to be able to handle
 NULL returns, just like UDP sendmsg() does, which means you'll
 need to cook up a routing lookup if __sk_dst_check() gives you
 NULL because the route became obsolete.

I think that without changing ppp_generic or changing ip_queue_xmit()
to something else in pppol2tp this would be really hard to avoid such
a warning (and maybe not very necessary).

Regards,
Jarek P.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html