date:20070308

Re: [Bugme-new] [Bug 8132] New: pptp server lockup in ppp_asynctty_receive()

2007-03-08 Thread Jarek Poplawski

On 06-03-2007 00:13, Andrew Morton wrote:
 On Mon, 5 Mar 2007 14:26:30 -0800
 [EMAIL PROTECTED] wrote:
 
 http://bugzilla.kernel.org/show_bug.cgi?id=8132

Summary: pptp server lockup in ppp_asynctty_receive()
 Kernel Version:  2.6.20
 Status: NEW
   Severity: high
  Owner: [EMAIL PROTECTED]
  Submitter: [EMAIL PROTECTED]
 CC: [EMAIL PROTECTED]


 Already several kernel releases i've expirienced different lockups of  vpn 
 (pptp) server.
 There is more then 200  ppp connections sometimes.
 With kernel debug i was able to retrive next information:

Could this be done with:
CONFIG_PROVE_LOCKING = y
CONFIG_4KSTACKS = n 

and, if possible, to send the first full lockdep error
message with some lines before it? It would be nice to
try to be more exact when hand writing, too.

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

We have FUSE, could we have NUSE ?

2007-03-08 Thread Matti Aarnio

(somebody should invent a better name for this)

We do have a support of file-system engine in userspace process.
Could we have a socket interfaced network protocol engine in userspace ?

I would like to place things like AX.25 service into userspace, but have
application codes to use kernel socket API (and even ABI) as if the service
is in the kernel.

Required bandwidth for many of these protocols is quite small, therefore
having those within the kernel is unnecessary.  (Not to mention that quite
many system integrators choose not to turn them on...)


The aim of NUSE from applications point of view would be to be
indistinguishable from kernel implemented services.

What would this require from the service hook side ?
  - Socket read and write can be trivialishly done
like a pipe in between processes
  - Somehow pass ancilliary data for:
 - socket, socketpair
 - connect, bind
 - accept
 - listen
 - getpeername, getsockname
 - sendto, send
 - recvfrom, revc
 - setsockopt, getsockopt
  - poll / epoll ?

Death of the protocol engine process must also destroy all existing
sockets of the served protocol type, and refuse to generate any new
sockets of the type.


The first protocol that I have in mind to implement on top of this service
does not need very much of local sockets.
(It is called STANAG-5066 - radio data communication on HF frequencies.
Specification is written by NATO, thus STANAG, but my use plans for it
are more along the AX.25 ham-radio things.)


/Matti Aarnio
-
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: 2.6.21-rc2-mm2: drivers/net/wireless/libertas/debugfs.c addr bogosity

2007-03-08 Thread Adrian Bunk

On Wed, Mar 07, 2007 at 03:00:57PM -0800, Andrew Morton wrote:
 On Wed, 7 Mar 2007 23:41:16 +0100
 Adrian Bunk [EMAIL PROTECTED] wrote:
 
  On Tue, Mar 06, 2007 at 12:44:08AM -0800, Andrew Morton wrote:
  ...
   Changes since 2.6.20-rc2-mm1:
  ...
git-netdev-all.patch
  ...
git trees
  ...
  
  drivers/net/wireless/libertas/debugfs.c contains:
#define item_addr(n) ((u32) ((wlan_adapter *)0)-n)
  
  This is wrong on 64bit architectures.
 
 Is OK - it is simply yet another reimplementation of offsetof().  Hint.

Thanks for the correction - it seems C pointers and me will never become 
close friends...

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed

-
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][SCTP] Re: lockdep: inconsistent lock state ipv6_add_addr/sctp_v6_copy_addrlist (2.6.21-rc1)

2007-03-08 Thread Herbert Xu

Jarek Poplawski [EMAIL PROTECTED] wrote:
 On 25-02-2007 10:08, Simon Arlott wrote:
 This happens on every boot if more information is needed:
 
 [   37.393715] =
 [   37.393830] [ INFO: inconsistent lock state ]
 [   37.393881] 2.6.21-rc1-git #146
 [   37.393929] -
 [   37.393979] inconsistent {softirq-on-R} - {in-softirq-W} usage.
 [   37.394040] hotplug/1072 [HC0[0]:SC1[2]:HE1:SE0] takes:
 [   37.394092]  (ndev-lock){-+-?}, at: [b04a7944] 
 ipv6_add_addr+0x164/0x1e0
 [   37.394308] {softirq-on-R} state was registered at:
 [   37.394359]   [b013fc42] __lock_acquire+0x622/0xbb0
 [   37.394515]   [b0140652] lock_acquire+0x62/0x80
 [   37.394678]   [b0511c65] _read_lock+0x35/0x50
 [   37.394834]   [b050e200] sctp_v6_copy_addrlist+0x30/0xc0
 ...
 
 [SCTP] ipv6: inconsistent lock state ipv6_add_addr/sctp_v6_copy_addrlist
 
 lockdep found that dev-lock taken from softirq in ipv6_add_addr
 is also taken in sctp_v6_copy_addrlist with softirqs enabled, so
 lockup is possible.

Who's calling ipv6_add_addr from softirq context? That's got to be
wrong because ipv6_add_addr requires the RTNL.

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
-
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][SCTP] Re: lockdep: inconsistent lock state ipv6_add_addr/sctp_v6_copy_addrlist (2.6.21-rc1)

2007-03-08 Thread Herbert Xu

On Thu, Mar 08, 2007 at 10:00:23PM +1100, Herbert Xu wrote:
 
 Who's calling ipv6_add_addr from softirq context? That's got to be
 wrong because ipv6_add_addr requires the RTNL.

Nevermind, I was thinking of ipv6_add_dev.

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
-
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][SCTP] Re: lockdep: inconsistent lock state ipv6_add_addr/sctp_v6_copy_addrlist (2.6.21-rc1)

2007-03-08 Thread Jarek Poplawski

On Thu, Mar 08, 2007 at 10:02:30PM +1100, Herbert Xu wrote:
 On Thu, Mar 08, 2007 at 10:00:23PM +1100, Herbert Xu wrote:
  
  Who's calling ipv6_add_addr from softirq context? That's got to be
  wrong because ipv6_add_addr requires the RTNL.
 
 Nevermind, I was thinking of ipv6_add_dev.

Anyway - maybe I forgot to say - the full error message
available on linux-kernel.

Cheers,
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 1/3] NetXen: Make driver use multiple PCI functions

2007-03-08 Thread Mithlesh Thukral

On Tuesday 06 March 2007 16:50, Jeff Garzik wrote:
 Linsys Contractor Mithlesh Thukral wrote:
  NetXen: Make driver use multiple PCI functions.
  This patch will make NetXen driver work with multiple PCI functions. This
  will make the usage of memory resources as well as interrupts more
  independent among different functions which results in better throughput.
  This change has been done after the multiport capable firmware related
  changes are already there in the NetXen's driver in Linux.
 
  Signed-off by: Mithlesh Thukral [EMAIL PROTECTED]
 
  ---
 
   drivers/net/netxen/netxen_nic.h  |  126 ++---
   drivers/net/netxen/netxen_nic_ethtool.c  |   80 +--
   drivers/net/netxen/netxen_nic_hdr.h  |8
   drivers/net/netxen/netxen_nic_hw.c   |  213 ++--
   drivers/net/netxen/netxen_nic_hw.h   |   18
   drivers/net/netxen/netxen_nic_init.c |  115 +---
   drivers/net/netxen/netxen_nic_isr.c  |   80 +--
   drivers/net/netxen/netxen_nic_main.c |  523 ++---
   drivers/net/netxen/netxen_nic_niu.c  |   27 -
   drivers/net/netxen/netxen_nic_phan_reg.h |  125 -
   10 files changed, 631 insertions(+), 684 deletions(-)

 applied 1-3 to #upstream (2.6.22)
hi Gurus,

Please bear with my poor understanding about the kernel development process. I 
have the following query:

1. We have sent these 3 patches which are have lined up for 2.6.22 kernel (as 
mentioned above).
2. The tree which is in netdev#upstream doesnt have these 3 above mentioned 
patches.
I need to send some patches now. My query is :

1. If i send the patches with respect to current netdev#upstream and if they 
are accepted, will the 3 patches which are applied for #upstream(2.6.22) 
not break (i mean not apply cleanly).
OR
I should send the patches with respect to current netdev#upstream tree + above 
3 patches, so that these 3 patches apply cleanly when 2.6.22 development 
cycle begins.

Please advice me how to proceed on this.

Thanks,
Mithlesh Thukral
-
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

[NET] ibmtr: Drain rich supply of modpost warnings.

2007-03-08 Thread Ralf Baechle

Building ibmtr as a module produces a spectacular pile of modpost warnings:

WARNING: drivers/net/tokenring/ibmtr.o - Section mismatch: reference to 
.init.text:ibmtr_probe1 from .text between 'ibmtr_probe_card' (at offset 0x450) 
and 'ibmtr_reset_timer'
WARNING: drivers/net/tokenring/ibmtr.o - Section mismatch: reference to 
.init.text:ibmtr_probe1 from .text between 'ibmtr_probe_card' (at offset 0x454) 
and 'ibmtr_reset_timer'
WARNING: drivers/net/tokenring/ibmtr.o - Section mismatch: reference to 
.init.text:ibmtr_probe1 from .text between 'ibmtr_probe_card' (at offset 0x458) 
and 'ibmtr_reset_timer'
WARNING: drivers/net/tokenring/ibmtr.o - Section mismatch: reference to 
.init.text:ibmtr_probe1 from .text between 'ibmtr_probe_card' (at offset 0x45c) 
and 'ibmtr_reset_timer'
WARNING: drivers/net/tokenring/ibmtr.o - Section mismatch: reference to 
.init.data:ibmtr_portlist from .text between 'ibmtr_probe_card' (at offset 
0x4e8) and 'ibmtr_reset_timer'
WARNING: drivers/net/tokenring/ibmtr.o - Section mismatch: reference to 
.init.data:ibmtr_portlist from .text between 'ibmtr_probe_card' (at offset 
0x4ec) and 'ibmtr_reset_timer'
WARNING: drivers/net/tokenring/ibmtr.o - Section mismatch: reference to 
.init.data:ibmtr_portlist from .text between 'ibmtr_probe_card' (at offset 
0x4f0) and 'ibmtr_reset_timer'
WARNING: drivers/net/tokenring/ibmtr.o - Section mismatch: reference to 
.init.data:ibmtr_portlist from .text between 'ibmtr_probe_card' (at offset 
0x4f4) and 'ibmtr_reset_timer'
WARNING: drivers/net/tokenring/ibmtr.o - Section mismatch: reference to 
.init.text:find_turbo_adapters from .text between 'ibmtr_probe_card' (at offset 
0x500) and 'ibmtr_reset_timer'
WARNING: drivers/net/tokenring/ibmtr.o - Section mismatch: reference to 
.init.text:find_turbo_adapters from .text between 'ibmtr_probe_card' (at offset 
0x504) and 'ibmtr_reset_timer'
WARNING: drivers/net/tokenring/ibmtr.o - Section mismatch: reference to 
.init.text:find_turbo_adapters from .text between 'ibmtr_probe_card' (at offset 
0x508) and 'ibmtr_reset_timer'
WARNING: drivers/net/tokenring/ibmtr.o - Section mismatch: reference to 
.init.text:find_turbo_adapters from .text between 'ibmtr_probe_card' (at offset 
0x50c) and 'ibmtr_reset_timer'
WARNING: drivers/net/tokenring/ibmtr.o - Section mismatch: reference to 
.init.data:ibmtr_portlist from .text between 'ibmtr_probe_card' (at offset 
0x520) and 'ibmtr_reset_timer'
WARNING: drivers/net/tokenring/ibmtr.o - Section mismatch: reference to 
.init.data:ibmtr_portlist from .text between 'ibmtr_probe_card' (at offset 
0x524) and 'ibmtr_reset_timer'
WARNING: drivers/net/tokenring/ibmtr.o - Section mismatch: reference to 
.init.data:ibmtr_portlist from .text between 'ibmtr_probe_card' (at offset 
0x528) and 'ibmtr_reset_timer'
WARNING: drivers/net/tokenring/ibmtr.o - Section mismatch: reference to 
.init.data:ibmtr_portlist from .text between 'ibmtr_probe_card' (at offset 
0x534) and 'ibmtr_reset_timer'
WARNING: drivers/net/tokenring/ibmtr.o - Section mismatch: reference to 
.init.data: from .text between 'ibmtr_probe_card' (at offset 0x540) and 
'ibmtr_reset_timer'
WARNING: drivers/net/tokenring/ibmtr.o - Section mismatch: reference to 
.init.data: from .text between 'ibmtr_probe_card' (at offset 0x544) and 
'ibmtr_reset_timer'
WARNING: drivers/net/tokenring/ibmtr.o - Section mismatch: reference to 
.init.data: from .text between 'ibmtr_probe_card' (at offset 0x548) and 
'ibmtr_reset_timer'
WARNING: drivers/net/tokenring/ibmtr.o - Section mismatch: reference to 
.init.data: from .text between 'ibmtr_probe_card' (at offset 0x54c) and 
'ibmtr_reset_timer'
WARNING: drivers/net/tokenring/ibmtr.o - Section mismatch: reference to 
.init.text:ibmtr_probe1 from .text between 'ibmtr_probe_card' (at offset 0x558) 
and 'ibmtr_reset_timer'
WARNING: drivers/net/tokenring/ibmtr.o - Section mismatch: reference to 
.init.text:ibmtr_probe1 from .text between 'ibmtr_probe_card' (at offset 0x55c) 
and 'ibmtr_reset_timer'
WARNING: drivers/net/tokenring/ibmtr.o - Section mismatch: reference to 
.init.text:ibmtr_probe1 from .text between 'ibmtr_probe_card' (at offset 0x560) 
and 'ibmtr_reset_timer'
WARNING: drivers/net/tokenring/ibmtr.o - Section mismatch: reference to 
.init.text:ibmtr_probe1 from .text between 'ibmtr_probe_card' (at offset 0x564) 
and 'ibmtr_reset_timer'

Fix by making ibmtr_probe an __init function.

While at it, move move ibmtr_probe_card below ibmtr_probe so the protoype
for ibmtr_probe can be deleted.

Signed-off-by: Ralf Baechle [EMAIL PROTECTED]

 drivers/net/tokenring/ibmtr.c |   25 -
 1 file changed, 12 insertions(+), 13 deletions(-)

Index: linux-mips/drivers/net/tokenring/ibmtr.c
===
--- linux-mips.orig/drivers/net/tokenring/ibmtr.c
+++ linux-mips/drivers/net/tokenring/ibmtr.c
@@ -186,7 +186,6 @@ static char __devinit *adapter_def(char 
 #define TRC_INITV 0x02 /*  verbose init trace points

Re: [PATCH 1/3] NetXen: Make driver use multiple PCI functions

2007-03-08 Thread Jeff Garzik


Mithlesh Thukral wrote:
2. The tree which is in netdev#upstream doesnt have these 3 above mentioned 
patches.


There appears to be some problems with kernel.org mirroring (again).

You'll just have to trust my word that the patches were applied :)

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

[PATCH] NET : Introduce SIOCGSTAMPNS ioctl to get timestamps with nanosec resolution

2007-03-08 Thread Eric Dumazet

Hi David

This patch is for net-2.6.22 git tree.

A separate patch will follow for  SO_TIMESTAMPNS / SCM_TIMESTAMPNS support.

Thank you

[PATCH] NET : Introduce SIOCGSTAMPNS ioctl to get timestamps with nanosec 
resolution

Now network timestamps use ktime_t infrastructure, we can add a new ioctl() 
SIOCGSTAMPNS  command to get timestamps in 'struct timespec'.
User programs can thus access to nanosecond resolution.

Signed-off-by: Eric Dumazet [EMAIL PROTECTED]
CC: Stephen Hemminger [EMAIL PROTECTED]

 fs/compat_ioctl.c |   18 ++
 include/asm-alpha/sockios.h   |3 ++-
 include/asm-arm/sockios.h |3 ++-
 include/asm-arm26/sockios.h   |3 ++-
 include/asm-avr32/sockios.h   |3 ++-
 include/asm-cris/sockios.h|3 ++-
 include/asm-frv/sockios.h |3 ++-
 include/asm-h8300/sockios.h   |3 ++-
 include/asm-i386/sockios.h|3 ++-
 include/asm-ia64/sockios.h|3 ++-
 include/asm-m32r/sockios.h|3 ++-
 include/asm-m68k/sockios.h|3 ++-
 include/asm-mips/sockios.h|3 ++-
 include/asm-parisc/sockios.h  |3 ++-
 include/asm-powerpc/sockios.h |3 ++-
 include/asm-s390/sockios.h|3 ++-
 include/asm-sh/sockios.h  |3 ++-
 include/asm-sh64/sockios.h|3 ++-
 include/asm-sparc/sockios.h   |3 ++-
 include/asm-sparc64/sockios.h |3 ++-
 include/asm-v850/sockios.h|3 ++-
 include/asm-x86_64/sockios.h  |3 ++-
 include/asm-xtensa/sockios.h  |3 ++-
 include/net/compat.h  |1 +
 include/net/sock.h|1 +
 net/appletalk/ddp.c   |3 +++
 net/atm/ioctl.c   |3 +++
 net/ax25/af_ax25.c|4 
 net/compat.c  |   24 
 net/core/sock.c   |   16 
 net/econet/af_econet.c|3 +++
 net/ipv4/af_inet.c|3 +++
 net/ipv6/af_inet6.c   |3 +++
 net/netrom/af_netrom.c|6 ++
 net/packet/af_packet.c|2 ++
 net/rose/af_rose.c|3 +++
 net/wanrouter/af_wanpipe.c|3 +++
 net/x25/af_x25.c  |   12 
 38 files changed, 149 insertions(+), 22 deletions(-)
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index c81c958..e9e5965 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -266,6 +266,23 @@ static int do_siocgstamp(unsigned int fd
return err;
 }
 
+static int do_siocgstampns(unsigned int fd, unsigned int cmd, unsigned long 
arg)
+{
+   struct compat_timespec __user *up = compat_ptr(arg);
+   struct timespec kts;
+   mm_segment_t old_fs = get_fs();
+   int err;
+
+   set_fs(KERNEL_DS);
+   err = sys_ioctl(fd, cmd, (unsigned long)kts);
+   set_fs(old_fs);
+   if (!err) {
+   err = put_user(kts.tv_sec, up-tv_sec);
+   err |= __put_user(kts.tv_nsec, up-tv_nsec);
+   }
+   return err;
+}
+
 struct ifmap32 {
compat_ulong_t mem_start;
compat_ulong_t mem_end;
@@ -2437,6 +2454,7 @@ HANDLE_IOCTL(SIOCBRDELIF, dev_ifsioc)
 /* Note SIOCRTMSG is no longer, so this is safe and * the user would have seen 
just an -EINVAL anyways. */
 HANDLE_IOCTL(SIOCRTMSG, ret_einval)
 HANDLE_IOCTL(SIOCGSTAMP, do_siocgstamp)
+HANDLE_IOCTL(SIOCGSTAMPNS, do_siocgstampns)
 #endif
 #ifdef CONFIG_BLOCK
 HANDLE_IOCTL(HDIO_GETGEO, hdio_getgeo)
diff --git a/include/asm-alpha/sockios.h b/include/asm-alpha/sockios.h
index e4961a7..7932c7a 100644
--- a/include/asm-alpha/sockios.h
+++ b/include/asm-alpha/sockios.h
@@ -10,6 +10,7 @@ #define SIOCATMARK_IOR('s', 7, int)
 #define SIOCSPGRP  _IOW('s', 8, pid_t)
 #define SIOCGPGRP  _IOR('s', 9, pid_t)
 
-#define SIOCGSTAMP 0x8906  /* Get stamp - linux-specific */
+#define SIOCGSTAMP 0x8906  /* Get stamp (timeval) */
+#define SIOCGSTAMPNS   0x8907  /* Get stamp (timespec) */
 
 #endif /* _ASM_ALPHA_SOCKIOS_H */
diff --git a/include/asm-arm/sockios.h b/include/asm-arm/sockios.h
index 77c3408..a2588a2 100644
--- a/include/asm-arm/sockios.h
+++ b/include/asm-arm/sockios.h
@@ -7,6 +7,7 @@ #define SIOCSPGRP   0x8902
 #define FIOGETOWN  0x8903
 #define SIOCGPGRP  0x8904
 #define SIOCATMARK 0x8905
-#define SIOCGSTAMP 0x8906  /* Get stamp */
+#define SIOCGSTAMP 0x8906  /* Get stamp (timeval) */
+#define SIOCGSTAMPNS   0x8907  /* Get stamp (timespec) */
 
 #endif
diff --git a/include/asm-arm26/sockios.h b/include/asm-arm26/sockios.h
index 77c3408..a2588a2 100644
--- a/include/asm-arm26/sockios.h
+++ b/include/asm-arm26/sockios.h
@@ -7,6 +7,7 @@ #define SIOCSPGRP   0x8902
 #define FIOGETOWN  0x8903
 #define SIOCGPGRP  0x8904
 #define SIOCATMARK 0x8905
-#define SIOCGSTAMP 0x8906  /* Get stamp */
+#define SIOCGSTAMP 0x8906  /* Get stamp (timeval) */
+#define SIOCGSTAMPNS   0x8907  /* Get stamp (timespec) */
 
 #endif
diff --git a/include/asm-avr32/sockios.h

Re: [RFC PATCH 1/2] [TCP]: Add highest_sack seqno, points to globally highest SACK

2007-03-08 Thread Ilpo Järvinen

On Thu, 8 Mar 2007, Ilpo Järvinen wrote:

 It is maintained only in during slowpath of tcp_ack().

I think I'll change this to do the forced synchronization of the 
highest_sack to snd_una in sacktag_write_queue when tp-sacked_out is zero 
during entry, which should be much simpler than the current approach.
...and then use if (!tp-sacked_out) to select between snd_una and 
highest_sack entry in the scoreboard updater...

-- 
 i.

Re: wireless extensions vs. 64-bit architectures

2007-03-08 Thread Johannes Berg

On Tue, 2007-03-06 at 18:03 -0800, Jean Tourrilhes wrote:

   Ok, please check the patch attached. I don't have a box to
 test that on, and on my 32 bit kernel it is not even compiled, but I
 believe I got everything all right.

Don't I wish it was that easy... Granted, that does seem to fix the
issue with iw_point but that's not the only thing that's broken. Here's
the next thing, I think this only happens after applying that patch,
without it probably just craps out earlier. Same thing happens with
iwevent (and maybe other things too.)

Enabling debugging in wireless tools yields (on my 64-bit kernel with
32-bit userland):
# LD_LIBRARY_PATH=.  ./iwlist wlan0 scan
Scan result 4096
[00:18:8B:15:50:8A:35:E0:00:01:00:C0:02:E1:B8:0E:C0:00:00:00:50:8A:35:F0:00:19:8B:1B:50:8A:35:E0:00:09:00:01:50:8A:35:F0:47:6F:6C:6F:73:4E:65:74:7A:00:18:8B:01:50:8A:35:E0:49:45:45:45:20:38:30:32:2E:31:31:62:67:00:35:F0:00:0C:8B:07:50:8A:35:E0:00:00:00:03:00:10:8B:05:50:8A:35:E0:00:00:00:07:00:00:00:32:00:10:8B:2B:50:8A:35:E0:00:00:08:00:67:00:35:F0:00:70:8B:21:50:8A:35:E0:00:0F:42:40:00:00:00:32:00:1E:84:80:00:00:00:32:00:53:EC:60:00:00:00:32:00:5B:8D:80:00:00:00:32:00:89:54:40:00:00:00:32:00:A7:D8:C0:00:00:00:lots
 more zeroes
wlan0 Scan completed : 
DBG - stream-current = 0x10019008, stream-value = (nil), stream-end = 
0x1001a008
DBG - iwe-cmd = 0x8B15, iwe-len = 24

 ^ that's already bogus


DBG - event_type = 6, event_len = 16, pointer = 0x1001900c
  Cell 01 - Address: 35:E0:00:01:00:C0 
DBG - stream-current = 0x10019020, stream-value = (nil), stream-end = 
0x1001a008
DBG - iwe-cmd = 0x8B1B, iwe-len = 25
DBG - event_type = 8, event_len = 4, pointer = 0x10019024 
DBG - extra_len = 17, token_len = 20618, token = 20618, max = 33, min = 0
ESSID: [224] 
DBG - stream-current = 0x10019039, stream-value = (nil), stream-end = 
0x1001a008
DBG - iwe-cmd = 0x8B01, iwe-len = 24
DBG - event_type = 2, event_len = 16, pointer = 0x1001903d
Protocol:P�5�IEEE 802.11b 
DBG - stream-current = 0x10019051, stream-value = (nil), stream-end = 
0x1001a008
DBG - iwe-cmd = 0x8B07, iwe-len = 12 
DBG - event_type = 4, event_len = 4, pointer = 0x10019055
Segmentation fault

Ooops.

Whereas on a 32-bit machine in the same environment it is as it should
be:

Scan result 264
[00:14:8B:15:00:01:00:C0:02:E1:B8:0E:C0:02:5A:F4:9F:CF:18:C0:00:11:8B:1B:00:09:00:01:47:6F:6C:6F:73:4E:65:74:7A:00:14:8B:01:49:45:45:45:20:38:30:32:2E:31:31:62:67:00:18:C0:00:08:8B:07:00:00:00:03:00:0C:8B:05:00:00:00:07:00:00:00:32:00:08:8B:2B:00:00:08:00:00:6C:8B:21:00:0F:42:40:00:00:08:00:00:1E:84:80:00:00:08:00:00:53:EC:60:00:00:08:00:00:5B:8D:80:00:00:08:00:00:89:54:40:00:00:08:00:00:A7:D8:C0:00:00:08:00:00:B7:1B:00:00:00:08:00:01:12:A8:80:00:00:08:00:01:4F:B1:80:00:00:08:00:01:6E:36:00:00:00:08:00:02:25:51:00:00:00:08:00:02:DC:6C:00:00:00:08:00:03:37:F9:80:00:00:08:00:00:08:8C:01:64:00:00:47:00:20:8C:05:00:18:00:00:DD:16:00:50:F2:01:01:00:00:50:F2:02:01:00:00:50:F2:02:01:00:00:50:F2:02:00:1F:8C:02:00:17:00:00:20:4C:61:73:74:20:62:65:61:63:6F:6E:3A:20:32:32:30:6D:73:20:61:67:6F]
eth2  Scan completed : 
DBG - stream-current = 0x10019008, stream-value = (nil), stream-end = 
0x10019110
DBG - iwe-cmd = 0x8B15, iwe-len = 20 

 ^ look, 4 bytes less. I wonder why that is!


DBG - event_type = 6, event_len = 16, pointer = 0x1001900c
  Cell 01 - Address: 00:C0:02:E1:B8:0E 
DBG - stream-current = 0x1001901c, stream-value = (nil), stream-end = 
0x10019110
[and lots more skipped for clarity]


So there. Do you want to know why too?

Let's look at a debug info dump from my 64-bit kernel:

 196de: Abbrev Number: 33 (DW_TAG_structure_type)
  96df DW_AT_sibling : 9717
  96e3 DW_AT_name: (indirect string, offset: 0x4278): iw_event
  96e7 DW_AT_byte_size   : 24
  96e8 DW_AT_decl_file   : 225
  96e9 DW_AT_decl_line   : 1064
 296eb: Abbrev Number: 23 (DW_TAG_member)
  96ec DW_AT_name: len
  96f0 DW_AT_decl_file   : 225
  96f1 DW_AT_decl_line   : 1065
  96f3 DW_AT_type: ed
  96f7 DW_AT_data_member_location: 2 byte block: 23 0 
(DW_OP_plus_uconst: 0)
 296fa: Abbrev Number: 23 (DW_TAG_member)
  96fb DW_AT_name: cmd
  96ff DW_AT_decl_file   : 225
  9700 DW_AT_decl_line   : 1066
  9702 DW_AT_type: ed
  9706 DW_AT_data_member_location: 2 byte block: 23 2 
(DW_OP_plus_uconst: 2)
 29709: Abbrev Number: 23 (DW_TAG_member)
  970a DW_AT_name: u
  970c DW_AT_decl_file   : 225
  970d DW_AT_decl_line   : 1067
  970f DW_AT_type: 956e
  9713 DW_AT_data_member_location: 2 byte block: 23 8 
(DW_OP_plus_uconst: 8)


The same structure from the 32-bit user space program (iwlist):

 1c3a: Abbrev Number: 15 (DW_TAG_structure_type)
  c3b DW_AT_sibling : c73
  c3f DW_AT_name: (indirect string, offset: 0x32b): iw_event

[NET] 3c59x: Fix several modpost warnings

2007-03-08 Thread Ralf Baechle

WARNING: drivers/net/3c59x.o - Section mismatch: reference to .init.text: from 
.text between 'vortex_eisa_probe' (at offset 0x4580) and 'vortex_eisa_remove'
WARNING: drivers/net/3c59x.o - Section mismatch: reference to .init.text: from 
.text between 'vortex_eisa_probe' (at offset 0x4584) and 'vortex_eisa_remove'
WARNING: drivers/net/3c59x.o - Section mismatch: reference to .init.text: from 
.text between 'vortex_eisa_probe' (at offset 0x4588) and 'vortex_eisa_remove'
WARNING: drivers/net/3c59x.o - Section mismatch: reference to .init.text: from 
.text between 'vortex_eisa_probe' (at offset 0x458c) and 'vortex_eisa_remove'

Fixed by:

 o move definition of vortex_eisa_driver below the functions it references.
 o remove now unnecessary prototypes for vortex_eisa_probe and
   vortex_eisa_remove.
 o Make vortex_eisa_probe an __init function.
 o Make vortex_eisa_remove a __devexit function.
 o Wrap vortex_eisa_driver reference to vortex_eisa_remove with
   __devexit_p().

Signed-off-by: Ralf Baechle [EMAIL PROTECTED]

 drivers/net/3c59x.c |   28 +---
 1 file changed, 13 insertions(+), 15 deletions(-)

Index: linux-mips/drivers/net/3c59x.c
===
--- linux-mips.orig/drivers/net/3c59x.c
+++ linux-mips/drivers/net/3c59x.c
@@ -858,19 +858,7 @@ static struct eisa_device_id vortex_eisa
 };
 MODULE_DEVICE_TABLE(eisa, vortex_eisa_ids);
 
-static int vortex_eisa_probe(struct device *device);
-static int vortex_eisa_remove(struct device *device);
-
-static struct eisa_driver vortex_eisa_driver = {
-   .id_table = vortex_eisa_ids,
-   .driver   = {
-   .name= 3c59x,
-   .probe   = vortex_eisa_probe,
-   .remove  = vortex_eisa_remove
-   }
-};
-
-static int vortex_eisa_probe(struct device *device)
+static int __init vortex_eisa_probe(struct device *device)
 {
void __iomem *ioaddr;
struct eisa_device *edev;
@@ -893,7 +881,7 @@ static int vortex_eisa_probe(struct devi
return 0;
 }
 
-static int vortex_eisa_remove(struct device *device)
+static int __devexit vortex_eisa_remove(struct device *device)
 {
struct eisa_device *edev;
struct net_device *dev;
@@ -918,7 +906,17 @@ static int vortex_eisa_remove(struct dev
free_netdev(dev);
return 0;
 }
-#endif
+
+static struct eisa_driver vortex_eisa_driver = {
+   .id_table = vortex_eisa_ids,
+   .driver   = {
+   .name= 3c59x,
+   .probe   = vortex_eisa_probe,
+   .remove  = __devexit_p(vortex_eisa_remove)
+   }
+};
+
+#endif /* CONFIG_EISA */
 
 /* returns count found (= 0), or negative on error */
 static int __init vortex_eisa_init(void)
-
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 : Introduce SIOCGSTAMPNS ioctl to get timestamps with nanosec resolution

2007-03-08 Thread Patrick McHardy

Eric Dumazet wrote:
 --- a/include/asm-mips/sockios.h
 +++ b/include/asm-mips/sockios.h
 @@ -20,6 +20,7 @@ #define SIOCATMARK  _IOR('s', 7, int)
  #define SIOCSPGRP_IOW('s', 8, pid_t)
  #define SIOCGPGRP_IOR('s', 9, pid_t)
  
 -#define SIOCGSTAMP   0x8906  /* Get stamp - linux-specific */
 +#define SIOCGSTAMP   0x8906  /* Get stamp (timeval) */
 +#define SIOCGSTAMPNS 0x8907  /* Get stamp (timespec) */


You might want to CC linux-arch or the architecture maintainers.
Last time I changed something in this area I got complaints
because it affected syscall emulation for non-Linux binaries
or something like that.

-
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 : Introduce SIOCGSTAMPNS ioctl to get timestamps with nanosec resolution

2007-03-08 Thread Eric Dumazet

On Thursday 08 March 2007 17:28, Patrick McHardy wrote:
 Eric Dumazet wrote:
  --- a/include/asm-mips/sockios.h
  +++ b/include/asm-mips/sockios.h
  @@ -20,6 +20,7 @@ #define SIOCATMARK_IOR('s', 7, int)
   #define SIOCSPGRP  _IOW('s', 8, pid_t)
   #define SIOCGPGRP  _IOR('s', 9, pid_t)
 
  -#define SIOCGSTAMP 0x8906  /* Get stamp - linux-specific */
  +#define SIOCGSTAMP 0x8906  /* Get stamp (timeval) */
  +#define SIOCGSTAMPNS   0x8907  /* Get stamp (timespec) */

 You might want to CC linux-arch or the architecture maintainers.
 Last time I changed something in this area I got complaints
 because it affected syscall emulation for non-Linux binaries
 or something like that.

I really dont see how this change could break syscall emulation for non-Linux 
binaries. SIOCGSTAMP{NS} is linux specific.

Could you please give the context of your past problems ?

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] NET : Introduce SIOCGSTAMPNS ioctl to get timestamps with nanosec resolution

2007-03-08 Thread Patrick McHardy

Eric Dumazet wrote:
 On Thursday 08 March 2007 17:28, Patrick McHardy wrote:
--- a/include/asm-mips/sockios.h
+++ b/include/asm-mips/sockios.h
@@ -20,6 +20,7 @@ #define SIOCATMARK _IOR('s', 7, int)
 #define SIOCSPGRP   _IOW('s', 8, pid_t)
 #define SIOCGPGRP   _IOR('s', 9, pid_t)

-#define SIOCGSTAMP  0x8906  /* Get stamp - linux-specific */
+#define SIOCGSTAMP  0x8906  /* Get stamp (timeval) */
+#define SIOCGSTAMPNS0x8907  /* Get stamp (timespec) */

You might want to CC linux-arch or the architecture maintainers.
Last time I changed something in this area I got complaints
because it affected syscall emulation for non-Linux binaries
or something like that.
 
 
 I really dont see how this change could break syscall emulation for non-Linux 
 binaries. SIOCGSTAMP{NS} is linux specific.
 
 Could you please give the context of your past problems ?


It was when I added the SO_SNDBUFFORCE/SO_RCVBUFFORCE setsockopt
options. IIRC the values I chose where already used differently
for non-Linux MIPS binaries.

-
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: wireless extensions vs. 64-bit architectures

2007-03-08 Thread Johannes Berg

On Thu, 2007-03-08 at 15:39 +0100, Johannes Berg wrote:

 Now, I don't know what gcc for ia64 does and I don't have a cross
 compiler to check, but on powerpc it does this.

As expected, the same happens on x86_64 (thanks to Michael Wu for the
debug dump):

 1e13: Abbrev Number: 17 (DW_TAG_structure_type)
 DW_AT_sibling : e4c
 DW_AT_name: (indirect string, offset: 0x33d): iw_event
 DW_AT_byte_size   : 24
 DW_AT_decl_file   : 100
 DW_AT_decl_line   : 1049
 2e20: Abbrev Number: 18 (DW_TAG_member)
 DW_AT_name: len
 DW_AT_decl_file   : 100
 DW_AT_decl_line   : 1050
 DW_AT_type: 58b
 DW_AT_data_member_location: 2 byte block: 23 0 (DW_OP_plus_uconst: 0)
 2e2f: Abbrev Number: 18 (DW_TAG_member)
 DW_AT_name: cmd
 DW_AT_decl_file   : 100
 DW_AT_decl_line   : 1051
 DW_AT_type: 58b
 DW_AT_data_member_location: 2 byte block: 23 2 (DW_OP_plus_uconst: 2)
 2e3e: Abbrev Number: 18 (DW_TAG_member)
 DW_AT_name: u
 DW_AT_decl_file   : 100
 DW_AT_decl_line   : 1052
 DW_AT_type: 9bf
 DW_AT_data_member_location: 2 byte block: 23 8 (DW_OP_plus_uconst: 8)

Hence, on those machines 32-bit userspace is also broken and we have the
information leak too.

johannes


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

Re: wireless extensions vs. 64-bit architectures

2007-03-08 Thread Johannes Berg

On Thu, 2007-03-08 at 15:39 +0100, Johannes Berg wrote:

 Oh, btw, this also means that we have an information leak on 64-bit
 kernels. Those alignment bytes aren't ever cleared or anything, they
 come right from the stack since most users of this just use a struct
 iw_event on the stack which is then memcpy()ed right into the userspace
 buffer. For example those bytes 5 through 8 (50:8A:35:E0) in the first
 buffer above. This is generally considered a security problem.

Patch below might fix it. If it does, please send it on to Linus (or
akpm), stable and whoever else might be interested in backporting it
(distros? or do they cherrypick from stable?)

I'm unable to test it as I'll be away from my only 64-bit machine for at
least until the 19th or 20th.

Yeah, I know sparse warns about this on 32-bit machines... But it seems
useless to try to fix that warning.

johannes

From: Johannes Berg [EMAIL PROTECTED]
Subject: fix information leak in wireless extensions (on 64-bit architectures)

On 64-bit architectures wireless extensions leak information from the
kernel stack due to padding inside structs not being cleared before they
are copied to userspace.

This is available to unprivileged users since they can listen for
wireless events and obtain scan results.

This patch fixes it by explicitly clearing the padding.

Signed-off-by: Johannes Berg [EMAIL PROTECTED]

---
 include/net/iw_handler.h |   20 
 1 file changed, 20 insertions(+)

--- wireless-dev.orig/include/net/iw_handler.h  2007-03-08 18:17:43.384642258 
+0100
+++ wireless-dev/include/net/iw_handler.h   2007-03-08 18:28:12.704642258 
+0100
@@ -484,6 +484,9 @@ iwe_stream_add_event(char * stream, /* 
 struct iw_event *iwe,  /* Payload */
 intevent_len)  /* Real size of payload */
 {
+   /* clear padding */
+   memset((char*)iwe + 4, 0, IW_EV_LCP_LEN - 4);
+
/* Check if it's possible */
if(likely((stream + event_len)  ends)) {
iwe-len = event_len;
@@ -505,6 +508,10 @@ iwe_stream_add_point(char *stream, /* 
 char * extra)  /* More payload */
 {
int event_len = IW_EV_POINT_LEN + iwe-u.data.length;
+
+   /* clear padding */
+   memset((char*)iwe + 4, 0, IW_EV_LCP_LEN - 4);
+
/* Check if it's possible */
if(likely((stream + event_len)  ends)) {
iwe-len = event_len;
@@ -531,6 +538,9 @@ iwe_stream_add_value(char * event,  /* E
 struct iw_event *iwe,  /* Payload */
 intevent_len)  /* Real size of payload */
 {
+   /* clear padding */
+   memset((char*)iwe + 4, 0, IW_EV_LCP_LEN - 4);
+
/* Don't duplicate LCP */
event_len -= IW_EV_LCP_LEN;
 
@@ -558,6 +568,9 @@ iwe_stream_check_add_event(char *   stream
   int  event_len,  /* Size of payload */
   int *perr)   /* Error report */
 {
+   /* clear padding */
+   memset((char*)iwe + 4, 0, IW_EV_LCP_LEN - 4);
+
/* Check if it's possible, set error if not */
if(likely((stream + event_len)  ends)) {
iwe-len = event_len;
@@ -582,6 +595,10 @@ iwe_stream_check_add_point(char *  stream
   int *perr)   /* Error report */
 {
int event_len = IW_EV_POINT_LEN + iwe-u.data.length;
+
+   /* clear padding */
+   memset((char*)iwe + 4, 0, IW_EV_LCP_LEN - 4);
+
/* Check if it's possible */
if(likely((stream + event_len)  ends)) {
iwe-len = event_len;
@@ -611,6 +628,9 @@ iwe_stream_check_add_value(char *   event,
   int  event_len,  /* Size of payload */
   int *perr)   /* Error report */
 {
+   /* clear padding */
+   memset((char*)iwe + 4, 0, IW_EV_LCP_LEN - 4);
+
/* Don't duplicate LCP */
event_len -= IW_EV_LCP_LEN;
 


-
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] use ktime for packet scheduling

2007-03-08 Thread Patrick McHardy

Stephen Hemminger wrote:
 Here is the lastest version of the netem patch to use hrtimers.
 It is against the current net tree, so it will need adjusting to fit
 with new psched/ktime stuff.

Thanks, I'll add whats still needed to my patches.
-
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

Fw: [Bugme-new] [Bug 8151] New: Established connections not displayed in /proc/tcp/netstat

2007-03-08 Thread Andrew Morton

Begin forwarded message:

Date: Thu, 8 Mar 2007 07:53:57 -0800
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 8151] New: Established connections not displayed in 
/proc/tcp/netstat

http://bugzilla.kernel.org/show_bug.cgi?id=8151

   Summary: Established connections not displayed in
/proc/tcp/netstat
Kernel Version: 2.6.17-rt7-default #3 PREEMPT
Status: NEW
  Severity: normal
 Owner: [EMAIL PROTECTED]
 Submitter: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]

Most recent kernel where this bug did *NOT* occur: Unknown

Distribution: SUSE 10 Pro

Hardware Environment: Intel(R) Pentium(R) 4 CPU 2.80GHz, 32 bit, 512 Megs of RAM

Software Environment: SUSE 10, 2.6.17-rt7-default with ingo molnar RT patch

Problem Description: 

Established tcp network connections are not shown in /proc/net/tcp (not
displayed in netstat).

I began to notice this when I would use netstat to display all established
connections. There were a few connections not shown as ESTABLISHED by netstat,
yet my application did not report a connection broken with the remote device. I
logged into the remote device and observed the connection was ESTABLISHED on the
remote side. In addition, I verified the transfer of data to the remote device.
I searched through the proc file system to find out more info and it seems that
my application still held the socket file descriptor as opened. 

 LOCAL MACHINE WITH BUG

# 10.1.2.71 is IP of remote device note connection not established

local:/ # netstat -a | grep 10.1.2.71

## NOTE IP of local device

local:/ # ifconfig eth1

eth1  Link encap:Ethernet  HWaddr 00:03:2D:09:0E:6F

  inet addr:10.1.2.10  Bcast:10.1.2.255  Mask:255.255.255.0

  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

  RX packets:558434 errors:0 dropped:0 overruns:0 frame:0

  TX packets:264478 errors:0 dropped:0 overruns:0 carrier:0

  collisions:0 txqueuelen:1000

  RX bytes:37082257 (35.3 Mb)  TX bytes:19489061 (18.5 Mb)

  Interrupt:18

# ##telnet into remote machine

local:/ # telnet 10.1.2.71

Trying 10.1.2.71...

Connected to 10.1.2.71.

Escape character is '^]'.

MontaVista(R) Linux(R) Professional Edition 3.1

Linux/ppc 2.4.20_mvl31-405gp_eval

(none) login: root

Password:

Linux (none) 2.4.20_mvl31-405gp_eval #474 Tue Dec 27 16:37:25 PST 2005 ppc 
unknown

MontaVista(R) Linux(R) Professional Edition 3.1

BusyBox v0.60.3 (2004.01.09-22:55+) Built-in shell (ash)

Enter 'help' for a list of built-in commands.

 Remote machine. Note connection established on port 1400 with local 
machine

# netstat -a | grep 10.1.2.10

tcp0  0 10.1.2.71:telnet10.1.2.10:51555 ESTABLISHED

tcp0  0 10.1.2.71:1400  10.1.2.10:60380 ESTABLISHED

## Back on LOCAL machine with bug

### Note established connection to IP 10.1.2.71 on port 1400 not shown. However,
other established connections shown to other devices running the same remote
server software. 

local:/proc/2774/fd # grep 0A02010A /proc/net/tcp | more

  64: 0A02010A:EBDC 4702010A:0578 01 : 00: 
00 7477 1 d8ba1980 201 40 10 2 100

  70: 0A02010A:A547 4802010A:0578 01 : 00: 
00 7478 1 d8ba1400 201 40 10 2 100

 Display open inodes

### I grep for the inode of the established connections from above. My
application will open the sockets to the remote devices sequentially.

ml_alc10:/proc/2774/fd # ls -l | grep socket | grep 747[0-9]

lrwx--  1 root root 64 Mar  7 10:37 154 - socket:[7471]

lrwx--  1 root root 64 Mar  7 10:37 155 - socket:[7472]

lrwx--  1 root root 64 Mar  7 10:37 158 - socket:[7473]

lrwx--  1 root root 64 Mar  7 10:37 159 - socket:[7474]

lrwx--  1 root root 64 Mar  7 10:37 160 - socket:[7475]

lrwx--  1 root root 64 Mar  7 10:37 161 - socket:[7476]

lrwx--  1 root root 64 Mar  7 10:37 162 - socket:[7477]

lrwx--  1 root root 64 Mar  7 10:37 163 - socket:[7478]

lrwx--  1 root root 64 Mar  7 10:37 164 - socket:[7479]

## Check if socket inode 7479 exists in /proc/net/tcp

local:/proc/2774/fd # grep 7479 /proc/net/tcp | more

local:/proc/2774/fd # ls -l | grep 7479

lrwx--  1 root root 64 Mar  7 10:37 164 - socket:[7479]

local:/proc/2774/fd # grep 7479 /proc/net/tcp | more

local:/proc/2774/fd # 

 NOTE Very Strange behavior. The connection will intermittently be shown in
/proc/net/tcp with the same local port number and inode. This leads me to
believe that the connection persists throughout and that the kernel is failing
to accurately display all established socket connections.

Please advise on how display all ESTABLISHED connections correctly. 

Thanks.

--- You are receiving this mail because: ---
You are on the CC list for the

Re: wireless extensions vs. 64-bit architectures

2007-03-08 Thread Jean Tourrilhes

On Thu, Mar 08, 2007 at 03:39:07PM +0100, Johannes Berg wrote:
On Tue, 2007-03-06 at 18:03 -0800, Jean Tourrilhes wrote:

Ok, please check the patch attached. I don't have a box to
test that on, and on my 32 bit kernel it is not even compiled, but I
believe I got everything all right.

Don't I wish it was that easy... Granted, that does seem to fix the
issue with iw_point but that's not the only thing that's broken. Here's
the next thing, I think this only happens after applying that patch,
without it probably just craps out earlier. Same thing happens with
iwevent (and maybe other things too.)

Enabling debugging in wireless tools yields (on my 64-bit kernel with
32-bit userland):
# LD_LIBRARY_PATH=. ./iwlist wlan0 scan
Scan result 4096
[00:18:8B:15:50:8A:35:E0:00:01:00:C0:02:E1:B8:0E:C0:00:00:00:50:8A:35:F0:00:19:8B:1B:50:8A:35:E0:00:09:00:01:50:8A:35:F0:47:6F:6C:6F:73:4E:65:74:7A:00:18:8B:01:50:8A:35:E0:49:45:45:45:20:38:30:32:2E:31:31:62:67:00:35:F0:00:0C:8B:07:50:8A:35:E0:00:00:00:03:00:10:8B:05:50:8A:35:E0:00:00:00:07:00:00:00:32:00:10:8B:2B:50:8A:35:E0:00:00:08:00:67:00:35:F0:00:70:8B:21:50:8A:35:E0:00:0F:42:40:00:00:00:32:00:1E:84:80:00:00:00:32:00:53:EC:60:00:00:00:32:00:5B:8D:80:00:00:00:32:00:89:54:40:00:00:00:32:00:A7:D8:C0:00:00:00:lots
more zeroes
wlan0 Scan completed :
DBG - stream-current = 0x10019008, stream-value = (nil), stream-end =
0x1001a008
DBG - iwe-cmd = 0x8B15, iwe-len = 24

^ that's already bogus

Ok, now I get it. It's an alignement issue, the kernel align
struct to 64 bit boundary, whereas the userspace expect it to 32 bit
boundary. Pretty nasty.
A proper fix would involve forcing the alignement in the
kernel. Unfortunately, that would break 64bit-64bit configs. I think
I can build a workaround for this in iwlib.

Thanks for the detailed bug report !

Jean
-
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: wireless extensions vs. 64-bit architectures

2007-03-08 Thread Johannes Berg

On Thu, 2007-03-08 at 10:49 -0800, Jean Tourrilhes wrote:

   A proper fix would involve forcing the alignement in the
 kernel. Unfortunately, that would break 64bit-64bit configs. I think
 I can build a workaround for this in iwlib.

Not easily I think. You'd have to get something that has a well-defined
result and see whether padding is present or not. The MAC address might
be good enough (due to len being 24 instead of the expected 20) though.
Thing is that it's really hard to figure out (even at runtime) whether
the kernel and machine are 64 or 32-bits.

I'd think this is a kernel bug and 32-bit userspace should rightfully be
able to expect 32-bit aligned structs, no? Actually fixing it in the
kernel would not be trivial though.

johannes


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

Re: wireless extensions vs. 64-bit architectures

2007-03-08 Thread Jean Tourrilhes

On Thu, Mar 08, 2007 at 08:08:29PM +0100, Johannes Berg wrote:
 On Thu, 2007-03-08 at 10:49 -0800, Jean Tourrilhes wrote:
 
  A proper fix would involve forcing the alignement in the
  kernel. Unfortunately, that would break 64bit-64bit configs. I think
  I can build a workaround for this in iwlib.
 
 Not easily I think. You'd have to get something that has a well-defined
 result and see whether padding is present or not. The MAC address might
 be good enough (due to len being 24 instead of the expected 20) though.
 Thing is that it's really hard to figure out (even at runtime) whether
 the kernel and machine are 64 or 32-bits.

I'm looking into that. The good thing is that we have
redundant information, so we can check that things don't match. It's a
bit more complex because some of those take variable parameters.

 I'd think this is a kernel bug and 32-bit userspace should rightfully be
 able to expect 32-bit aligned structs, no? Actually fixing it in the
 kernel would not be trivial though.

What we could do is have every 64 bit kernel return things on
a 32 bit boundary, irrespective of userspace used. That would break
current 64 bit userspace.

 johannes

Thanks !

Jean

-
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

skge- soft lockup on CPU#0 with mtu=9000 (2.6.20.1 + web100 patch)

2007-03-08 Thread Chris Stromsoe


Within 2 or 3 minutes after issuing

ip link set bond1 mtu 9000

I get one NETDEV WATCHDOG: eth2: transmit timed out to the console, and 
then this starts to repeat:


BUG: soft lockup detected on CPU#0!
 [c0103667] show_trace_log_lvl+0x19/0x2e
 [c010368e] show_trace+0x12/0x14
 [c010377a] dump_stack+0x14/0x16
 [c0134964] softlockup_tick+0x9f/0xae
 [c0120f38] run_local_timers+0x12/0x14
 [c0120d89] update_process_times+0x3e/0x63
 [c010ceb0] smp_apic_timer_interrupt+0x6f/0x7e
 [c010337c] apic_timer_interrupt+0x28/0x30
 [d088d5b3] skge_tx_clean+0x1d/0x87 [skge]
 [d088d663] skge_tx_timeout+0x46/0x4c [skge]
 [c02b0854] dev_watchdog+0x79/0xb9
 [c0120ec9] run_timer_softirq+0x10e/0x16b
 [c011cebb] __do_softirq+0x65/0xc3
 [c0104d55] do_softirq+0x54/0xbb
 ===

Once the soft lockups start, the machine becomes unresponsive and has to 
be power cycled.


bond1 is a dual-port syskonnect sk-98xx with both ports bonded in 
active-backup mode.


kernel is 2.6.20.1 with the web100 kernel patches from http://web100.org/. 
I'm building a plain 2.6.20.1 without the patches right now and will test 
when it finishes compiling.


lspci for the card shows:

fresno:~ # lspci -vv -s 02:01.0
:02:01.0 Ethernet controller: Syskonnect (Schneider  Koch) SK-98xx Gigabit 
Ethernet Server Adapter (rev 11)
Subsystem: Syskonnect (Schneider  Koch) SK-9844 Gigabit Ethernet 
Server Adapter (SK-NET GE-SX dual link)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- 
MAbort- SERR- PERR-
Latency: 64 (5750ns min, 7750ns max), Cache Line Size: 0x08 (32 bytes)
Interrupt: pin A routed to IRQ 22
Region 0: Memory at febfc000 (32-bit, non-prefetchable) [size=16K]
Region 1: I/O ports at e800 [size=256]
Expansion ROM at febc [disabled] [size=128K]
Capabilities: [48] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [50] Vital Product Data




-Chris
-
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: wireless extensions vs. 64-bit architectures

2007-03-08 Thread Johannes Berg

On Thu, 2007-03-08 at 11:13 -0800, Jean Tourrilhes wrote:

   I'm looking into that. The good thing is that we have
 redundant information, so we can check that things don't match. It's a
 bit more complex because some of those take variable parameters.

Yeah, and it also only happens with those event streams I think. But I
haven't checked other possible places.

  I'd think this is a kernel bug and 32-bit userspace should rightfully be
  able to expect 32-bit aligned structs, no? Actually fixing it in the
  kernel would not be trivial though.
 
   What we could do is have every 64 bit kernel return things on
 a 32 bit boundary, irrespective of userspace used. That would break
 current 64 bit userspace.

Yeah, the only way to fix the bug without breaking that would be to
return different structs for the different userspaces which sounds
really complex.

johannes


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

Re: wireless extensions vs. 64-bit architectures

2007-03-08 Thread Johannes Berg

On Thu, 2007-03-08 at 10:49 -0800, Jean Tourrilhes wrote:
   A proper fix would involve forcing the alignement in the
 kernel. Unfortunately, that would break 64bit-64bit configs. I think
 I can build a workaround for this in iwlib.

Actually, other tools like network manager, wpa supplicant and possibly
more don't use iwlib afaik and are affected too, so the only real fix
seems to be possible in the kernel.

johannes


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

Re: wireless extensions vs. 64-bit architectures

2007-03-08 Thread Jouni Malinen

On Thu, Mar 08, 2007 at 08:27:22PM +0100, Johannes Berg wrote:
 On Thu, 2007-03-08 at 10:49 -0800, Jean Tourrilhes wrote:
  A proper fix would involve forcing the alignement in the
  kernel. Unfortunately, that would break 64bit-64bit configs. I think
  I can build a workaround for this in iwlib.
 
 Actually, other tools like network manager, wpa supplicant and possibly
 more don't use iwlib afaik and are affected too, so the only real fix
 seems to be possible in the kernel.

Yes, workaround in just iwlib is not enough. If the only possible
solution is user space workaround, it better be documented (and
communicated to maintainers of user space apps) well so that
all user space programs not using iwlib can be modified, too.

-- 
Jouni MalinenPGP id EFC895FA
-
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: skge- soft lockup on CPU#0 with mtu=9000 (2.6.20.1 + web100 patch)

2007-03-08 Thread Stephen Hemminger


[SKGE]: Fix deadlock in skge_tx_timeout

dev_watchdog() already holds the device lock, don't take it again in
skge_tx_clean().

Signed-off-by: Patrick McHardy [EMAIL PROTECTED]

---
commit 0b1cfafa6f6b8a168d5811d1f65cf540942c52b1
tree 4d3f252d6618adfe812e9da95cd496bb798e7c7b
parent 1ca949299260aa49eeba34ff912e2321c8b1f647
author Patrick McHardy [EMAIL PROTECTED] Sat, 24 Feb 2007 20:05:39 +0100
committer Patrick McHardy [EMAIL PROTECTED] Sat, 24 Feb 2007 20:05:39 +0100

 drivers/net/skge.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/skge.c b/drivers/net/skge.c
index e482e7f..4a948c2 100644
--- a/drivers/net/skge.c
+++ b/drivers/net/skge.c
@@ -2575,7 +2575,9 @@ static int skge_down(struct net_device *
skge_led(skge, LED_MODE_OFF);
 
netif_poll_disable(dev);
+   netif_tx_lock_bh(dev);
skge_tx_clean(dev);
+   netif_tx_unlock_bh(dev);
skge_rx_clean(skge);
 
kfree(skge-rx_ring.start);
@@ -2720,7 +2722,6 @@ static void skge_tx_clean(struct net_dev
struct skge_port *skge = netdev_priv(dev);
struct skge_element *e;
 
-   netif_tx_lock_bh(dev);
for (e = skge-tx_ring.to_clean; e != skge-tx_ring.to_use; e = 
e-next) {
struct skge_tx_desc *td = e-desc;
skge_tx_free(skge, e, td-control);
@@ -2729,7 +2730,6 @@ static void skge_tx_clean(struct net_dev
 
skge-tx_ring.to_clean = e;
netif_wake_queue(dev);
-   netif_tx_unlock_bh(dev);
 }
 
 static void skge_tx_timeout(struct net_device *dev)


--010402080104080400040104--
-
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

Re: [PATCH] Add xfrm policy change auditing to pfkey_spdget

2007-03-08 Thread Paul Moore

On Thursday, March 8 2007 11:20:15 am Eric Paris wrote:
 I lose at using git.  Sorry.  I'll be more careful to check that all of
 my changes on the current branch are committed before I run my git diff.
 Or maybe someone will convince me to use git in an all new better way.

[NOTE: I stripped a lot of addresses from this mail as I suspect it to be 
somewhat off-topic]

Perhaps not quite what you were asking for, but I've found quilt[1] to be an 
*extremely* wonderful tool for creating and manipulating patches to send 
upstream.  It doesn't replace git, you still need it to fetch/update the 
source tree, but it plays well with git (there is the stacked git project 
which aims to integrate the two bits of software but I have never tried it).

[1] http://savannah.nongnu.org/projects/quilt

-- 
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

[PATCH] sky2: turn off Rx checksum on bad hardware

2007-03-08 Thread Stephen Hemminger

On Yukon FE, occasional hardware receive checksum errors are seen.
An early indication of the problem is single bit differences in the two
checksum engines.  Use this as a detection mechanism to turn off Rx
checksumming.

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

---
 drivers/net/sky2.c |   24 +---
 1 file changed, 21 insertions(+), 3 deletions(-)

--- sky2-dev.orig/drivers/net/sky2.c2007-03-05 16:49:31.0 -0800
+++ sky2-dev/drivers/net/sky2.c 2007-03-05 16:49:45.0 -0800
@@ -2165,9 +2165,27 @@
/* fall through */
 #endif
case OP_RXCHKS:
-   skb = sky2-rx_ring[sky2-rx_next].skb;
-   skb-ip_summed = CHECKSUM_COMPLETE;
-   skb-csum = status  0x;
+   if (!sky2-rx_csum)
+   break;
+
+   /* Both checksum counters are programmed to start at
+* the same offset, so unless there is a problem they
+* should match. This failure is an early indication 
that
+* hardware receive checksumming won't work.
+*/
+   if (likely(status  16 == (status  0x))) {
+   skb = sky2-rx_ring[sky2-rx_next].skb;
+   skb-ip_summed = CHECKSUM_COMPLETE;
+   skb-csum = status  0x;
+   } else {
+   printk(KERN_NOTICE PFX %s: hardware receive 
+  checksum problem (status = %#x)\n,
+  dev-name, status);
+   sky2-rx_csum = 0;
+   sky2_write32(sky2-hw,
+Q_ADDR(rxqaddr[le-link], Q_CSR),
+BMU_DIS_RX_CHKSUM);
+   }
break;
 
case OP_TXINDEXLE:
-
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/8] net-2.6.22 spring cleaning

2007-03-08 Thread Stephen Hemminger

Tis the time of year to clean house.

--
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 4/8] wireless: use ARRAY_SIZE()

2007-03-08 Thread Stephen Hemminger

Use ARRAY_SIZE() macro now.

Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
 net/core/wireless.c |6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

--- net-2.6.22.orig/net/core/wireless.c 2007-03-07 15:16:15.0 -0800
+++ net-2.6.22/net/core/wireless.c  2007-03-07 15:16:37.0 -0800
@@ -346,8 +346,7 @@
.max_tokens = sizeof(struct iw_pmksa),
},
 };
-static const unsigned standard_ioctl_num = (sizeof(standard_ioctl) /
-   sizeof(struct 
iw_ioctl_description));
+static const unsigned standard_ioctl_num = ARRAY_SIZE(standard_ioctl);
 
 /*
  * Meta-data about all the additional standard Wireless Extension events
@@ -397,8 +396,7 @@
.max_tokens = sizeof(struct iw_pmkid_cand),
},
 };
-static const unsigned standard_event_num = (sizeof(standard_event) /
-   sizeof(struct 
iw_ioctl_description));
+static const unsigned standard_event_num = ARRAY_SIZE(standard_event);
 
 /* Size (in bytes) of the various private data types */
 static const char iw_priv_type_size[] = {

--
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 8/8] udp: deinline

2007-03-08 Thread Stephen Hemminger

A couple of functions are exported or used indirectly
so it is pointless to mark them as inline.

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

---
 net/ipv4/udp.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

--- net-2.6.22.orig/net/ipv4/udp.c  2007-03-07 14:51:07.0 -0800
+++ net-2.6.22/net/ipv4/udp.c   2007-03-07 14:51:35.0 -0800
@@ -213,13 +213,13 @@
return error;
 }
 
-__inline__ int udp_get_port(struct sock *sk, unsigned short snum,
+int udp_get_port(struct sock *sk, unsigned short snum,
int (*scmp)(const struct sock *, const struct sock *))
 {
return  __udp_lib_get_port(sk, snum, udp_hash, udp_port_rover, scmp);
 }
 
-inline int ipv4_rcv_saddr_equal(const struct sock *sk1, const struct sock *sk2)
+int ipv4_rcv_saddr_equal(const struct sock *sk1, const struct sock *sk2)
 {
struct inet_sock *inet1 = inet_sk(sk1), *inet2 = inet_sk(sk2);
 
@@ -391,7 +391,7 @@
sock_put(sk);
 }
 
-__inline__ void udp_err(struct sk_buff *skb, u32 info)
+void udp_err(struct sk_buff *skb, u32 info)
 {
return __udp4_lib_err(skb, info, udp_hash);
 }
@@ -1296,7 +1296,7 @@
return 0;
 }
 
-__inline__ int udp_rcv(struct sk_buff *skb)
+int udp_rcv(struct sk_buff *skb)
 {
return __udp4_lib_rcv(skb, udp_hash, IPPROTO_UDP);
 }

--
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 2/8] udp: ipv6 style cleanup

2007-03-08 Thread Stephen Hemminger

Fix whitespace around keywords. Eliminate unnecessary ()'s on return
statements.

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

---
 net/ipv6/udp.c |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

--- net-2.6.22.orig/net/ipv6/udp.c  2007-03-07 10:18:04.0 -0800
+++ net-2.6.22/net/ipv6/udp.c   2007-03-07 10:27:56.0 -0800
@@ -93,10 +93,10 @@
continue;
score++;
}
-   if(score == 4) {
+   if (score == 4) {
result = sk;
break;
-   } else if(score  badness) {
+   } else if (score  badness) {
result = sk;
badness = score;
}
@@ -329,7 +329,7 @@
if (!ipv6_addr_equal(np-rcv_saddr, loc_addr))
continue;
}
-   if(!inet6_mc_check(s, loc_addr, rmt_addr))
+   if (!inet6_mc_check(s, loc_addr, rmt_addr))
continue;
return s;
}
@@ -473,14 +473,14 @@
icmpv6_send(skb, ICMPV6_DEST_UNREACH, ICMPV6_PORT_UNREACH, 0, 
dev);
 
kfree_skb(skb);
-   return(0);
+   return 0;
}
 
/* deliver */
 
udpv6_queue_rcv_skb(sk, skb);
sock_put(sk);
-   return(0);
+   return 0;
 
 short_packet:
LIMIT_NETDEBUG(KERN_DEBUG UDP%sv6: short packet: %d/%u\n,
@@ -490,7 +490,7 @@
 discard:
UDP6_INC_STATS_BH(UDP_MIB_INERRORS, proto == IPPROTO_UDPLITE);
kfree_skb(skb);
-   return(0);
+   return 0;
 }
 
 static __inline__ int udpv6_rcv(struct sk_buff **pskb)

--
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 3/8] network core: whitespace cleanup

2007-03-08 Thread Stephen Hemminger

Fix whitespace around keywords. Fix indentation especially of switch
statements.

Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
 net/compat.c |   30 +-
 net/core/ethtool.c   |4 
 net/core/net-sysfs.c |4 
 net/core/pktgen.c|   16 -
 net/core/sock.c  |  710 +--
 net/core/wireless.c  |  297 ++---
 net/socket.c |2 
 7 files changed, 529 insertions(+), 534 deletions(-)

--- net-2.6.22.orig/net/core/sock.c 2007-03-08 12:48:49.0 -0800
+++ net-2.6.22/net/core/sock.c  2007-03-08 12:51:38.0 -0800
@@ -361,8 +361,8 @@
}
 #endif
 
-   if(optlensizeof(int))
-   return(-EINVAL);
+   if (optlen  sizeof(int))
+   return -EINVAL;
 
if (get_user(val, (int __user *)optval))
return -EFAULT;
@@ -371,265 +371,263 @@
 
lock_sock(sk);
 
-   switch(optname)
-   {
-   case SO_DEBUG:
-   if(val  !capable(CAP_NET_ADMIN))
-   {
-   ret = -EACCES;
-   }
-   else if (valbool)
-   sock_set_flag(sk, SOCK_DBG);
-   else
-   sock_reset_flag(sk, SOCK_DBG);
-   break;
-   case SO_REUSEADDR:
-   sk-sk_reuse = valbool;
-   break;
-   case SO_TYPE:
-   case SO_ERROR:
-   ret = -ENOPROTOOPT;
-   break;
-   case SO_DONTROUTE:
-   if (valbool)
-   sock_set_flag(sk, SOCK_LOCALROUTE);
-   else
-   sock_reset_flag(sk, SOCK_LOCALROUTE);
-   break;
-   case SO_BROADCAST:
-   sock_valbool_flag(sk, SOCK_BROADCAST, valbool);
-   break;
-   case SO_SNDBUF:
-   /* Don't error on this BSD doesn't and if you think
-  about it this is right. Otherwise apps have to
-  play 'guess the biggest size' games. RCVBUF/SNDBUF
-  are treated in BSD as hints */
+   switch(optname) {
+   case SO_DEBUG:
+   if (val  !capable(CAP_NET_ADMIN)) {
+   ret = -EACCES;
+   }
+   else if (valbool)
+   sock_set_flag(sk, SOCK_DBG);
+   else
+   sock_reset_flag(sk, SOCK_DBG);
+   break;
+   case SO_REUSEADDR:
+   sk-sk_reuse = valbool;
+   break;
+   case SO_TYPE:
+   case SO_ERROR:
+   ret = -ENOPROTOOPT;
+   break;
+   case SO_DONTROUTE:
+   if (valbool)
+   sock_set_flag(sk, SOCK_LOCALROUTE);
+   else
+   sock_reset_flag(sk, SOCK_LOCALROUTE);
+   break;
+   case SO_BROADCAST:
+   sock_valbool_flag(sk, SOCK_BROADCAST, valbool);
+   break;
+   case SO_SNDBUF:
+   /* Don't error on this BSD doesn't and if you think
+  about it this is right. Otherwise apps have to
+  play 'guess the biggest size' games. RCVBUF/SNDBUF
+  are treated in BSD as hints */
 
-   if (val  sysctl_wmem_max)
-   val = sysctl_wmem_max;
+   if (val  sysctl_wmem_max)
+   val = sysctl_wmem_max;
 set_sndbuf:
-   sk-sk_userlocks |= SOCK_SNDBUF_LOCK;
-   if ((val * 2)  SOCK_MIN_SNDBUF)
-   sk-sk_sndbuf = SOCK_MIN_SNDBUF;
-   else
-   sk-sk_sndbuf = val * 2;
+   sk-sk_userlocks |= SOCK_SNDBUF_LOCK;
+   if ((val * 2)  SOCK_MIN_SNDBUF)
+   sk-sk_sndbuf = SOCK_MIN_SNDBUF;
+   else
+   sk-sk_sndbuf = val * 2;
 
-   /*
-*  Wake up sending tasks if we
-*  upped the value.
-*/
-   sk-sk_write_space(sk);
-   break;
+   /*
+*  Wake up sending tasks if we
+*  upped the value.
+*/
+   sk-sk_write_space(sk);
+   break;
 
-   case SO_SNDBUFFORCE:
-   if (!capable(CAP_NET_ADMIN)) {
-   ret = -EPERM;
-   break;
-   }
-   goto set_sndbuf;
+   case SO_SNDBUFFORCE:
+   if (!capable(CAP_NET_ADMIN)) {
+   ret = -EPERM;
+

[PATCH 7/8] net: deinline some functions

2007-03-08 Thread Stephen Hemminger

Several functions are marked inline or forced inline, but it
would be better to let the compiler decide.

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

---
 net/core/dev.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

--- net-2.6.22.orig/net/core/dev.c  2007-03-07 13:12:17.0 -0800
+++ net-2.6.22/net/core/dev.c   2007-03-07 14:50:51.0 -0800
@@ -1676,9 +1676,9 @@
}
 }
 
-static __inline__ int deliver_skb(struct sk_buff *skb,
- struct packet_type *pt_prev,
- struct net_device *orig_dev)
+static inline int deliver_skb(struct sk_buff *skb,
+ struct packet_type *pt_prev,
+ struct net_device *orig_dev)
 {
atomic_inc(skb-users);
return pt_prev-func(skb, skb-dev, pt_prev, orig_dev);
@@ -2068,7 +2068,7 @@
  * This is invoked by the /proc filesystem handler to display a device
  * in detail.
  */
-static __inline__ struct net_device *dev_get_idx(loff_t pos)
+static struct net_device *dev_get_idx(loff_t pos)
 {
struct net_device *dev;
loff_t i;
@@ -2839,7 +2839,7 @@
 static DEFINE_SPINLOCK(net_todo_list_lock);
 static struct list_head net_todo_list = LIST_HEAD_INIT(net_todo_list);
 
-static inline void net_set_todo(struct net_device *dev)
+static void net_set_todo(struct net_device *dev)
 {
spin_lock(net_todo_list_lock);
list_add_tail(dev-todo_list, net_todo_list);

--
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 5/8] ipv4 cleanup

2007-03-08 Thread Stephen Hemminger

Add whitespace around keywords.

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

---
 net/ipv4/af_inet.c   |2 
 net/ipv4/arp.c   |2 
 net/ipv4/cipso_ipv4.c|2 
 net/ipv4/devinet.c   |4 
 net/ipv4/fib_trie.c  |   17 
 net/ipv4/ip_fragment.c   |   26 
 net/ipv4/ip_output.c |2 
 net/ipv4/ip_sockglue.c   | 1147 +--
 net/ipv4/ipconfig.c  |4 
 net/ipv4/ipmr.c  |  305 +--
 net/ipv4/xfrm4_mode_tunnel.c |2 
 net/ipv4/xfrm4_policy.c  |2 
 12 files changed, 755 insertions(+), 760 deletions(-)

--- net-2.6.22.orig/net/ipv4/af_inet.c  2007-03-07 15:09:04.0 -0800
+++ net-2.6.22/net/ipv4/af_inet.c   2007-03-07 15:11:11.0 -0800
@@ -1336,7 +1336,7 @@
 *  Initialise per-cpu ipv4 mibs
 */
 
-   if(init_ipv4_mibs())
+   if (init_ipv4_mibs())
printk(KERN_CRIT inet_init: Cannot init ipv4 mibs\n); ;
 
ipv4_proc_init();
--- net-2.6.22.orig/net/ipv4/arp.c  2007-03-07 15:09:04.0 -0800
+++ net-2.6.22/net/ipv4/arp.c   2007-03-07 15:11:11.0 -0800
@@ -1178,7 +1178,7 @@
goto out;
}
 
-   switch(cmd) {
+   switch (cmd) {
case SIOCDARP:
err = arp_req_delete(r, dev);
break;
--- net-2.6.22.orig/net/ipv4/devinet.c  2007-03-07 15:09:04.0 -0800
+++ net-2.6.22/net/ipv4/devinet.c   2007-03-07 15:11:11.0 -0800
@@ -631,7 +631,7 @@
dev_load(ifr.ifr_name);
 #endif
 
-   switch(cmd) {
+   switch (cmd) {
case SIOCGIFADDR:   /* Get interface address */
case SIOCGIFBRDADDR:/* Get the broadcast address */
case SIOCGIFDSTADDR:/* Get the destination address */
@@ -706,7 +706,7 @@
if (!ifa  cmd != SIOCSIFADDR  cmd != SIOCSIFFLAGS)
goto done;
 
-   switch(cmd) {
+   switch (cmd) {
case SIOCGIFADDR:   /* Get interface address */
sin-sin_addr.s_addr = ifa-ifa_local;
goto rarok;
--- net-2.6.22.orig/net/ipv4/fib_trie.c 2007-03-07 15:09:04.0 -0800
+++ net-2.6.22/net/ipv4/fib_trie.c  2007-03-07 15:11:11.0 -0800
@@ -350,11 +350,10 @@
 
 static inline void tnode_free(struct tnode *tn)
 {
-   if(IS_LEAF(tn)) {
+   if (IS_LEAF(tn)) {
struct leaf *l = (struct leaf *) tn;
call_rcu_bh(l-rcu, __leaf_free_rcu);
-   }
-   else
+   } else
call_rcu(tn-rcu, __tnode_free_rcu);
 }
 
@@ -553,7 +552,7 @@
 
/* Keep root node larger  */
 
-   if(!tn-parent)
+   if (!tn-parent)
inflate_threshold_use = inflate_threshold_root;
else
inflate_threshold_use = inflate_threshold;
@@ -584,7 +583,7 @@
 
/* Keep root node larger  */
 
-   if(!tn-parent)
+   if (!tn-parent)
halve_threshold_use = halve_threshold_root;
else
halve_threshold_use = halve_threshold;
@@ -2032,12 +2031,12 @@
 {
struct node *n ;
 
-   if(!t)
+   if (!t)
return NULL;
 
n = rcu_dereference(t-trie);
 
-   if(!iter)
+   if (!iter)
return NULL;
 
if (n) {
@@ -2077,7 +2076,7 @@
int i;
 
s-tnodes++;
-   if(tn-bits  MAX_STAT_DEPTH)
+   if (tn-bits  MAX_STAT_DEPTH)
s-nodesizes[tn-bits]++;
 
for (i = 0; i  (1tn-bits); i++)
@@ -2243,7 +2242,7 @@
 {
static char buf[32];
 
-   switch(s) {
+   switch (s) {
case RT_SCOPE_UNIVERSE: return universe;
case RT_SCOPE_SITE: return site;
case RT_SCOPE_LINK: return link;
--- net-2.6.22.orig/net/ipv4/ip_fragment.c  2007-03-07 15:09:04.0 
-0800
+++ net-2.6.22/net/ipv4/ip_fragment.c   2007-03-07 15:11:11.0 -0800
@@ -184,7 +184,7 @@
 {
struct ipq *qp = kmalloc(sizeof(struct ipq), GFP_ATOMIC);
 
-   if(!qp)
+   if (!qp)
return NULL;
atomic_add(sizeof(struct ipq), ip_frag_mem);
return qp;
@@ -321,11 +321,11 @@
 * promoted read lock to write lock.
 */
hlist_for_each_entry(qp, n, ipq_hash[hash], list) {
-   if(qp-id == qp_in-id  
-  qp-saddr == qp_in-saddr
-  qp-daddr == qp_in-daddr
-  qp-protocol == qp_in-protocol 
-  qp-user == qp_in-user) {
+   if (qp-id == qp_in-id 
+   qp-saddr == qp_in-saddr   
+   qp-daddr == qp_in-daddr   
+   qp-protocol == qp_in-protocol 
+   qp-user == qp_in-user) {
atomic_inc(qp-refcnt);
write_unlock(ipfrag_lock);

[PATCH 6/8] tcp: whitespace cleanup

2007-03-08 Thread Stephen Hemminger

Add whitespace around keywords.

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


---
 net/ipv4/tcp_hybla.c |2 -
 net/ipv4/tcp_input.c |   57 +++
 net/ipv4/tcp_minisocks.c |6 ++--
 net/ipv4/tcp_output.c|   34 ++--
 net/ipv4/tcp_westwood.c  |2 -
 5 files changed, 51 insertions(+), 50 deletions(-)

--- net-2.6.22.orig/net/ipv4/tcp_input.c2007-03-07 15:09:04.0 
-0800
+++ net-2.6.22/net/ipv4/tcp_input.c 2007-03-07 15:11:14.0 -0800
@@ -578,7 +578,7 @@
 * does not matter how to _calculate_ it. Seems, it was trap
 * that VJ failed to avoid. 8)
 */
-   if(m == 0)
+   if (m == 0)
m = 1;
if (tp-srtt != 0) {
m -= (tp-srtt  3);   /* m is now error in rtt est */
@@ -1758,12 +1758,11 @@
 
/* clear xmit_retransmit_queue hints
 *  if this is beyond hint */
-   if(tp-retransmit_skb_hint != NULL 
-  before(TCP_SKB_CB(skb)-seq,
- TCP_SKB_CB(tp-retransmit_skb_hint)-seq)) {
-
+   if (tp-retransmit_skb_hint != NULL 
+   before(TCP_SKB_CB(skb)-seq,
+  TCP_SKB_CB(tp-retransmit_skb_hint)-seq))
tp-retransmit_skb_hint = NULL;
-   }
+
}
}
tcp_sync_left_out(tp);
@@ -2441,7 +2440,7 @@
 
if (sacked) {
if (sacked  TCPCB_RETRANS) {
-   if(sacked  TCPCB_SACKED_RETRANS)
+   if (sacked  TCPCB_SACKED_RETRANS)
tp-retrans_out -= tcp_skb_pcount(skb);
acked |= FLAG_RETRANS_DATA_ACKED;
seq_rtt = -1;
@@ -2840,7 +2839,7 @@
ptr = (unsigned char *)(th + 1);
opt_rx-saw_tstamp = 0;
 
-   while(length0) {
+   while (length  0) {
int opcode=*ptr++;
int opsize;
 
@@ -2856,9 +2855,9 @@
return;
if (opsize  length)
return; /* don't parse partial options 
*/
-   switch(opcode) {
+   switch (opcode) {
case TCPOPT_MSS:
-   if(opsize==TCPOLEN_MSS  th-syn  
!estab) {
+   if (opsize==TCPOLEN_MSS  th-syn  
!estab) {
u16 in_mss = 
ntohs(get_unaligned((__be16 *)ptr));
if (in_mss) {
if (opt_rx-user_mss  
opt_rx-user_mss  in_mss)
@@ -2868,12 +2867,12 @@
}
break;
case TCPOPT_WINDOW:
-   if(opsize==TCPOLEN_WINDOW  th-syn  
!estab)
+   if (opsize==TCPOLEN_WINDOW  th-syn 
 !estab)
if (sysctl_tcp_window_scaling) {
__u8 snd_wscale = 
*(__u8 *) ptr;
opt_rx-wscale_ok = 1;
if (snd_wscale  14) {
-   
if(net_ratelimit())
+   if 
(net_ratelimit())

printk(KERN_INFO tcp_parse_options: Illegal window 
   
scaling value %d 14 received.\n,
   
snd_wscale);
@@ -2883,7 +2882,7 @@
}
break;
case TCPOPT_TIMESTAMP:
-   if(opsize==TCPOLEN_TIMESTAMP) {
+   if (opsize==TCPOLEN_TIMESTAMP) {
if ((estab  
opt_rx-tstamp_ok) ||
(!estab  
sysctl_tcp_timestamps)) {
opt_rx-saw_tstamp = 1;
@@ -2893,7 +2892,7 @@
}
break;
case TCPOPT_SACK_PERM:
-   if(opsize==TCPOLEN_SACK_PERM  th-syn 
 !estab) {
+   if

Re: netlink regression (since 2.6.18)

2007-03-08 Thread Stephen Hemminger

On Wed, 7 Mar 2007 14:28:30 -0800
Stephen Hemminger [EMAIL PROTECTED] wrote:

 On a Ubuntu x86_64 machine the command: 
   tc qdisc ls
 gets a RTNETLINK error. It looks like some data structure alignment
 issue got introduced between 2.6.18 and 2.6.19-rc1 and continues on. 
 Since netlink data structure layout is part of the user ABI, we need to go 
 back
 and keep compatibility.
 
 Still working out the bisect to find where the problem started.

Never mind, it turned out that NET_SCHED wasn't configured on that machine.


-- 
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: skge- soft lockup on CPU#0 with mtu=9000 (2.6.20.1 + web100 patch)

2007-03-08 Thread Chris Stromsoe


Thanks.  That fixes the soft lockup.

I've got another problem now.  The cards I'm using are dual port 
(sk-9844).  I am bonding both ports together.


The card presents as eth2 and eth3.  If I remove eth2 from the bond so 
that eth3 is the active interface, I get a hard lock (nothing prints to 
serial console, sysrq isn't responsive) and have to power cycle.


This is with plain 2.6.20.1.  I also tested using skge.[ch] from the 
current netdev git tree.



-Chris

On Thu, 8 Mar 2007, Stephen Hemminger wrote:



[SKGE]: Fix deadlock in skge_tx_timeout

dev_watchdog() already holds the device lock, don't take it again in
skge_tx_clean().

Signed-off-by: Patrick McHardy [EMAIL PROTECTED]

---
commit 0b1cfafa6f6b8a168d5811d1f65cf540942c52b1
tree 4d3f252d6618adfe812e9da95cd496bb798e7c7b
parent 1ca949299260aa49eeba34ff912e2321c8b1f647
author Patrick McHardy [EMAIL PROTECTED] Sat, 24 Feb 2007 20:05:39 +0100
committer Patrick McHardy [EMAIL PROTECTED] Sat, 24 Feb 2007 20:05:39 +0100

drivers/net/skge.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/skge.c b/drivers/net/skge.c
index e482e7f..4a948c2 100644
--- a/drivers/net/skge.c
+++ b/drivers/net/skge.c
@@ -2575,7 +2575,9 @@ static int skge_down(struct net_device *
skge_led(skge, LED_MODE_OFF);

netif_poll_disable(dev);
+   netif_tx_lock_bh(dev);
skge_tx_clean(dev);
+   netif_tx_unlock_bh(dev);
skge_rx_clean(skge);

kfree(skge-rx_ring.start);
@@ -2720,7 +2722,6 @@ static void skge_tx_clean(struct net_dev
struct skge_port *skge = netdev_priv(dev);
struct skge_element *e;

-   netif_tx_lock_bh(dev);
for (e = skge-tx_ring.to_clean; e != skge-tx_ring.to_use; e = 
e-next) {
struct skge_tx_desc *td = e-desc;
skge_tx_free(skge, e, td-control);
@@ -2729,7 +2730,6 @@ static void skge_tx_clean(struct net_dev

skge-tx_ring.to_clean = e;
netif_wake_queue(dev);
-   netif_tx_unlock_bh(dev);
}

static void skge_tx_timeout(struct net_device *dev)


--010402080104080400040104--
-
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

Re: skge- soft lockup on CPU#0 with mtu=9000 (2.6.20.1 + web100 patch)

2007-03-08 Thread Jay Vosburgh

Chris Stromsoe [EMAIL PROTECTED] wrote:

Within 2 or 3 minutes after issuing

ip link set bond1 mtu 9000

I get one NETDEV WATCHDOG: eth2: transmit timed out to the console, and
then this starts to repeat:

BUG: soft lockup detected on CPU#0!

I believe this is the same bug that is fixed by this change:

commit c4f283b1f275e5528c13c119e5cfc80cdba55d00
Author: Jay Vosburgh [EMAIL PROTECTED]
Date:   Wed Feb 28 17:03:20 2007 -0800

bonding: fix double dev_add_pack

Bonding can erroneously register the same packet_type to receive
ARPs (for use by ARP validation): once at device open time, and once via
sysfs.  Since sysfs can change the validate setting (and thus register
or unregister) at any time, a flag is needed to synchronize with device
open in order to avoid double registrations, and the simplest place is
within the packet_type structure itself.  Double unregister is not an
issue.

Bug reported by Ulrich Oelmann [EMAIL PROTECTED].

Signed-off-by: Jay Vosburgh [EMAIL PROTECTED]
Signed-off-by: Jeff Garzik [EMAIL PROTECTED]

diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index ea73ebf..68afcb5 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3423,6 +3423,9 @@ void bond_register_arp(struct bonding *b
 {
struct packet_type *pt = bond-arp_mon_pt;
 
+   if (pt-type)
+   return;
+
pt-type = htons(ETH_P_ARP);
pt-dev = NULL; /*bond-dev;XXX*/
pt-func = bond_arp_rcv;
@@ -3431,7 +3434,10 @@ void bond_register_arp(struct bonding *b
 
 void bond_unregister_arp(struct bonding *bond)
 {
-   dev_remove_pack(bond-arp_mon_pt);
+   struct packet_type *pt = bond-arp_mon_pt;
+
+   dev_remove_pack(pt);
+   pt-type = 0;
 }
 
 /* Hashing Policies -*/


-J

---
-Jay Vosburgh, IBM Linux Technology Center, [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: skge- soft lockup on CPU#0 with mtu=9000 (2.6.20.1 + web100 patch)

2007-03-08 Thread Stephen Hemminger

On Thu, 8 Mar 2007 13:31:13 -0800 (PST)
Chris Stromsoe [EMAIL PROTECTED] wrote:

 Thanks.  That fixes the soft lockup.
 
 I've got another problem now.  The cards I'm using are dual port 
 (sk-9844).  I am bonding both ports together.
 
 The card presents as eth2 and eth3.  If I remove eth2 from the bond so 
 that eth3 is the active interface, I get a hard lock (nothing prints to 
 serial console, sysrq isn't responsive) and have to power cycle.
 
 This is with plain 2.6.20.1.  I also tested using skge.[ch] from the 
 current netdev git tree.

Which form of bonding failover, there are locking issues with some
of the bonding modes. You should ask on the bonding mailing list.


-- 
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

1 2 >

1 - 100 of 106 matches

Mail list logo