date:20050906

Re: [PATCH] sunrpc: add endian annotations

2005-09-06 Thread Alexey Dobriyan

On Mon, Sep 05, 2005 at 09:48:57PM +0100, [EMAIL PROTECTED] wrote:
 On Mon, Sep 05, 2005 at 10:55:58PM +0400, Alexey Dobriyan wrote:
  * add svc_getnl(), svc_putnl() in spirit of svc_getu32(), svc_putu32().
They return and accept __be32 instead of __u32, respectively.
  * convert to svc_getnl(), svc_putnl().
 
 Umm...  I'm not particulary happy with the names.  nl for net long?

Yes. Like htonl().

  -   svc_putu32(rqstp-rq_res.head, htonl(RPC_AUTH_GSS));
  +   svc_putnl(rqstp-rq_res.head, htonl(RPC_AUTH_GSS));
 
 ... and this is another problem - this sort of things is _way_ too frequent,
 so I really wonder if we should have a separate helper for - if it's inlined,
 there would be no problem with constants.  I.e. have a helper that would
 take host-order integer and shove htonl() of it into buffer.

OK. Ditto for svc_getnl().

-
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

Netconsole violates dev-hard_start_xmit synch rules

2005-09-06 Thread Eugene Surovegin

According to Documentation/networking/netdevices.txt 
dev-hard_start_xmit must be called with interrupts *enabled*.

Unfortunately, current netconsole code always calls netpoll with local 
interrupts disabled:

  write_msg (local_irq_save)
netpoll_send_udp
  netpoll_send_skb
np-dev-hard_start_xmit.

I'm not sure this can cause any problems, but quick grep has showed 
that some drivers indeed rely on the documented behavior.

Also, it'd be nice if netpoll author updated netdevices.txt with info 
about dev-poll_controller sync rules :) (in fact, I stumbled upon 
this inconsistency when I was trying to figure out locking for 
dev-poll_controller implementation in my driver).

-- 
Eugene
-
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: RTL8169 freezes under load

2005-09-06 Thread Francois Romieu

Kyle Brantley [EMAIL PROTECTED] :
[...]
 I recently bought three rtl8169 gigabit cards, along with a gigabit
 switch. Trouble is, the computers keep freezing up once the NIC comes
 under and decent amount of load. Let me lay this out for you a bit:
 
 Computer A:
 -Dual AMD 2600+ MP
 -rtl8169 under *64-bit PCI slot*
 -2.6.12 (vanilla)

It should be fine.

 Computer B:
 -Intel P4 2.4GHz
 -rtl8169 under 32-bit PCI slot
 -2.6.10 (vanilla)

Please upgrade this one.

[...]
 I've googled around (quite a bit), and found many many different patches
 for the 8169 driver.

The patches are regularly pushed in mainline. Don't panic.

[...]
 Any help would be appreciated.

Upgrading the kernel in the 2.6.10 box should fix a known issue.

Be sure to enable the magic sysrq in your new compilation.

If it is not enough, you may have found something new:
- please open a PR at http://bugzilla.kernel.org
- send:
  o 'lspci -vx'
  o complete dmesg after log (check that the very first lines do not
disappear),
  o lsmod
  o cat /proc/interrupts before f*ckup
  o ifconfig output
- do the keyboard led still answer after the lockup ?
- is NFS implied in your configuration ?
  If not can you reproduce the issue with torrent or ftp alone ?

--
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: Possible neighbour reference leak in net/ipv4/xfrm4_policy.c

2005-09-06 Thread Patrick McHardy


Ben Greear wrote:

/* Copy neighbout for reachability confirmation */
dst_prev-neighbour= neigh_clone(rt-u.dst.neighbour)

This code in the method xfrm4_bundle_create appears to over-write
the dst_prev-neighbour member without ever checking to see if it
needed to release the old neighbour pointer...

If there is some reason dst_prev-neighbour is always NULL, please
let me know.  Otherwise, I think it's a leak.


dst_prev is newly allocated in the loop a couple of lines above.
-
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 5194] New: IPSec related OOps in 2.6.13

2005-09-06 Thread Andrew Morton



Begin forwarded message:

Date: Tue, 6 Sep 2005 03:49:57 -0700
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 5194] New: IPSec related OOps in 2.6.13


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

   Summary: IPSec related OOps in 2.6.13
Kernel Version: 2.6.13
Status: NEW
  Severity: high
 Owner: [EMAIL PROTECTED]
 Submitter: [EMAIL PROTECTED]


Most recent kernel where this bug did not occur: 2.6.12
Distribution: Slackware

Software Environment:

Linux gate 2.6.13 #1 Sat Sep 3 11:32:13 CEST 2005 i686 unknown

Gnu C  3.3.5
Gnu make   3.80
binutils   2.15.92.0.2
util-linux 2.11z
mount  2.11z
module-init-tools  3.1
e2fsprogs  1.35
reiserfsprogs  line
reiser4progs   line
Linux C Library2.3.5
Dynamic linker (ldd)   2.3.5
Linux C++ Library  5.0.7
Procps 3.1.8
Net-tools  1.60
Kbd1.08
Sh-utils   2.0
Modules Loaded

Problem Description:

Oops:  [#1]
PREEMPT
Modules linked in:
CPU:0
EIP:0060:[c01f562c]Not tainted VLI
EFLAGS: 00010216   (2.6.13)
EIP is at sha1_update+0x7c/0x160
eax: dce92e6c   ebx: 0014   ecx: 0005   edx: 0104
esi: 907529d5   edi: dce92eb4   ebp: 907529d5   esp: c04c5c98
ds: 007b   es: 007b   ss: 0068
Process swapper (pid: 0, threadinfo=c04c5000 task=c03eeb80)
Stack: dce92e74 dbe09db4 c04c5ca4     
          
          
Call Trace:
 [c01f39e0] update+0x80/0xb0
 [c01f4106] crypto_hmac_update+0x26/0x40
 [c036d370] skb_icv_walk+0xf0/0x200
 [c01f4071] crypto_hmac_init+0xd1/0x140
 [c0348a23] esp_hmac_digest+0x93/0xf0
 [c01f40e0] crypto_hmac_update+0x0/0x40
 [c01f3644] cbc_encrypt+0x54/0x60
 [c0347ecb] esp_output+0x38b/0x4a0
 [c0366e1a] xfrm4_output+0x7a/0x1a0
 [c031537b] ip_forward+0x17b/0x2e0
 [c03154e0] ip_forward_finish+0x0/0x60
 [c0313a96] ip_rcv+0x266/0x520
 [c0313f30] ip_rcv_finish+0x0/0x2d0
 [c02e5918] netif_receive_skb+0x198/0x240
 [c02e5a3f] process_backlog+0x7f/0x100
 [c02e5b4e] net_rx_action+0x8e/0x1c0
 [c011f7cd] __do_softirq+0x8d/0xa0
 [c0105493] do_softirq+0x63/0x70
 ===
 [c011f8a8] irq_exit+0x38/0x40
 [c0105359] do_IRQ+0x59/0x80
 [c01035fe] common_interrupt+0x1a/0x20
 [c0241d07] acpi_processor_idle+0x123/0x299
 [c01009d8] cpu_idle+0x48/0x60
 [c044b7b7] start_kernel+0x157/0x180
 [c044b390] unknown_bootoption+0x0/0x1b0
Code: 0f 86 f9 00 00 00 8b 84 24 60 01 00 00 bb 40 00 00 00 29 f3 81 fb ff 01 00
00 8d 7c 06 1c 0f 87 c4 00 00 00 89 d9 89 ee
c1 e9 02 f3 a5 89 d9 83 e1 03 74 02 f3 a4 8b 84 24 60 01 00 00 8b b4 24
 0Kernel panic - not syncing: Fatal exception in interrupt


Steps to reproduce:
Setup IPsec  wait. Sometimes 30m, sometimes 5h.

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
-
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 8/8] orinoco: New driver - spectrum_cs.

2005-09-06 Thread Christoph Hellwig

 +#ifdef  __IN_PCMCIA_PACKAGE__
 +#include pcmcia/k_compat.h
 +#endif /* __IN_PCMCIA_PACKAGE__ */

this doesn't make sense for a 2.6 driver.

 +/*
 + * If SPECTRUM_FW_INCLUDED is defined, the firmware is hardcoded into
 + * the driver.  Use get_symbol_fw script to generate spectrum_fw.h and
 + * copy it to the same directory as spectrum_cs.c.
 + *
 + * If SPECTRUM_FW_INCLUDED is not defined, the firmware is loaded at the
 + * runtime using hotplug.  Use the same get_symbol_fw script to generate
 + * files symbol_sp24t_prim_fw symbol_sp24t_sec_fw, copy them to the
 + * hotplug firmware directory (typically /usr/lib/hotplug/firmware) and
 + * make sure that you have hotplug installed and enabled in the kernel.
 + */
 +/* #define SPECTRUM_FW_INCLUDED 1 */
 +
 +#ifdef SPECTRUM_FW_INCLUDED
 +/* Header with the firmware */
 +#include spectrum_fw.h
 +#else/* !SPECTRUM_FW_INCLUDED */

While I see the point of this for the standalone orinoco driver package
it doesn't make sense for the version in the kernel tree.

 +#define CS_CHECK(fn, ret) \
 +  do { last_fn = (fn); if ((last_ret = (ret)) != 0) goto cs_failed; } while 
 (0)

I don't think this macro abuse helps anyone..

-
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: Fw: [Bugme-new] [Bug 5194] New: IPSec related OOps in 2.6.13

2005-09-06 Thread Herbert Xu

On Tue, Sep 06, 2005 at 04:08:56AM -0700, Andrew Morton wrote:
 
 Problem Description:
 
 Oops:  [#1]
 PREEMPT
 Modules linked in:
 CPU:0
 EIP:0060:[c01f562c]Not tainted VLI
 EFLAGS: 00010216   (2.6.13)
 EIP is at sha1_update+0x7c/0x160

Thanks for the report.  Matt LaPlante had exactly the same problem
a couple of days ago.  I've tracked down now to my broken crypto
cipher wrapper functions which will step over a page boundary if
it's not aligned correctly.


[CRYPTO] Fix boundary check in standard multi-block cipher processors

The boundary check in the standard multi-block cipher processors are
broken when nbytes is not a multiple of bsize.  In those cases it will
always process an extra block.

This patch corrects the check so that it processes at most nbytes of data.

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/crypto/cipher.c b/crypto/cipher.c
--- a/crypto/cipher.c
+++ b/crypto/cipher.c
@@ -191,6 +191,8 @@ static unsigned int cbc_process_encrypt(
u8 *iv = desc-info;
unsigned int done = 0;
 
+   nbytes -= bsize;
+
do {
xor(iv, src);
fn(crypto_tfm_ctx(tfm), dst, iv);
@@ -198,7 +200,7 @@ static unsigned int cbc_process_encrypt(
 
src += bsize;
dst += bsize;
-   } while ((done += bsize)  nbytes);
+   } while ((done += bsize) = nbytes);
 
return done;
 }
@@ -219,6 +221,8 @@ static unsigned int cbc_process_decrypt(
u8 *iv = desc-info;
unsigned int done = 0;
 
+   nbytes -= bsize;
+
do {
u8 *tmp_dst = *dst_p;
 
@@ -230,7 +234,7 @@ static unsigned int cbc_process_decrypt(
 
src += bsize;
dst += bsize;
-   } while ((done += bsize)  nbytes);
+   } while ((done += bsize) = nbytes);
 
return done;
 }
@@ -243,12 +247,14 @@ static unsigned int ecb_process(const st
void (*fn)(void *, u8 *, const u8 *) = desc-crfn;
unsigned int done = 0;
 
+   nbytes -= bsize;
+
do {
fn(crypto_tfm_ctx(tfm), dst, src);
 
src += bsize;
dst += bsize;
-   } while ((done += bsize)  nbytes);
+   } while ((done += bsize) = nbytes);
 
return done;
 }

Re: [PATCH] cleanup ieee80211_crypto.c

2005-09-06 Thread Christoph Hellwig

On Mon, Sep 05, 2005 at 12:48:45PM -0400, Jeff Garzik wrote:
 I understand removing the NULL pointers, but .name is actually a string
 NULL.. Leaving it to be NULL is not a very good idea. This NULL
 algorithm was designed for cases where there is default algorithm for
 encryption and encryption needs to be disabled for a specific station.
 In other words, userspace programs will be asking for an algorithm
 called NULL.
 
 
 Yeah, I missed that.  Jeff, can you fix that before applying or should
 I resend?
 
 Please resend updated patch.


Index: linux-2.6/net/ieee80211/ieee80211_crypt.c
===
--- linux-2.6.orig/net/ieee80211/ieee80211_crypt.c  2005-09-05 
14:38:19.0 +0200
+++ linux-2.6/net/ieee80211/ieee80211_crypt.c   2005-09-06 14:14:01.0 
+0200
@@ -11,16 +11,14 @@
  *
  */
 
-#include linux/config.h
-#include linux/version.h
 #include linux/module.h
 #include linux/init.h
 #include linux/slab.h
-#include asm/string.h
-#include asm/errno.h
-
+#include linux/string.h
+#include linux/errno.h
 #include net/ieee80211.h
 
+
 MODULE_AUTHOR(Jouni Malinen);
 MODULE_DESCRIPTION(HostAP crypto);
 MODULE_LICENSE(GPL);
@@ -30,28 +28,19 @@
struct ieee80211_crypto_ops *ops;
 };
 
-
-struct ieee80211_crypto {
-   struct list_head algs;
-   spinlock_t lock;
-};
-
-static struct ieee80211_crypto *hcrypt;
+static LIST_HEAD(ieee80211_crypto_algs);
+static DEFINE_SPINLOCK(ieee80211_crypto_lock);
 
 void ieee80211_crypt_deinit_entries(struct ieee80211_device *ieee,
   int force)
 {
-   struct list_head *ptr, *n;
-   struct ieee80211_crypt_data *entry;
-
-   for (ptr = ieee-crypt_deinit_list.next, n = ptr-next;
-ptr != ieee-crypt_deinit_list; ptr = n, n = ptr-next) {
-   entry = list_entry(ptr, struct ieee80211_crypt_data, list);
+   struct ieee80211_crypt_data *entry, *next;
 
+   list_for_each_entry_safe(entry, next, ieee-crypt_deinit_list, list) {
if (atomic_read(entry-refcnt) != 0  !force)
continue;
 
-   list_del(ptr);
+   list_del(entry-list);
 
if (entry-ops) {
entry-ops-deinit(entry-priv);
@@ -108,9 +97,6 @@
unsigned long flags;
struct ieee80211_crypto_alg *alg;
 
-   if (hcrypt == NULL)
-   return -1;
-
alg = kmalloc(sizeof(*alg), GFP_KERNEL);
if (alg == NULL)
return -ENOMEM;
@@ -118,9 +104,9 @@
memset(alg, 0, sizeof(*alg));
alg-ops = ops;
 
-   spin_lock_irqsave(hcrypt-lock, flags);
-   list_add(alg-list, hcrypt-algs);
-   spin_unlock_irqrestore(hcrypt-lock, flags);
+   spin_lock_irqsave(ieee80211_crypto_lock, flags);
+   list_add(alg-list, ieee80211_crypto_algs);
+   spin_unlock_irqrestore(ieee80211_crypto_lock, flags);
 
printk(KERN_DEBUG ieee80211_crypt: registered algorithm '%s'\n,
   ops-name);
@@ -130,121 +116,71 @@
 
 int ieee80211_unregister_crypto_ops(struct ieee80211_crypto_ops *ops)
 {
+   struct ieee80211_crypto_alg *alg;
unsigned long flags;
-   struct list_head *ptr;
-   struct ieee80211_crypto_alg *del_alg = NULL;
 
-   if (hcrypt == NULL)
-   return -1;
-
-   spin_lock_irqsave(hcrypt-lock, flags);
-   for (ptr = hcrypt-algs.next; ptr != hcrypt-algs; ptr = ptr-next) {
-   struct ieee80211_crypto_alg *alg =
-   (struct ieee80211_crypto_alg *) ptr;
-   if (alg-ops == ops) {
-   list_del(alg-list);
-   del_alg = alg;
-   break;
-   }
-   }
-   spin_unlock_irqrestore(hcrypt-lock, flags);
-
-   if (del_alg) {
-   printk(KERN_DEBUG ieee80211_crypt: unregistered algorithm 
-  '%s'\n, ops-name);
-   kfree(del_alg);
-   }
-
-   return del_alg ? 0 : -1;
+   spin_lock_irqsave(ieee80211_crypto_lock, flags);
+   list_for_each_entry(alg, ieee80211_crypto_algs, list) {
+   if (alg-ops == ops)
+   goto found;
+   }
+   spin_unlock_irqrestore(ieee80211_crypto_lock, flags);
+   return -EINVAL;
+
+ found:
+   printk(KERN_DEBUG ieee80211_crypt: unregistered algorithm 
+  '%s'\n, ops-name);
+   list_del(alg-list);
+   spin_unlock_irqrestore(ieee80211_crypto_lock, flags);
+   kfree(alg);
+   return 0;
 }
 
 
 struct ieee80211_crypto_ops * ieee80211_get_crypto_ops(const char *name)
 {
+   struct ieee80211_crypto_alg *alg;
unsigned long flags;
-   struct list_head *ptr;
-   struct ieee80211_crypto_alg *found_alg = NULL;
 
-   if (hcrypt == NULL)
-   return NULL;
-
-   spin_lock_irqsave(hcrypt-lock, flags);
-   for (ptr = hcrypt-algs.next; ptr != hcrypt-algs; ptr = ptr-next) {
-

Re: RTL8169 freezes under load

2005-09-06 Thread Kyle Brantley

Francois Romieu wrote:

Kyle Brantley [EMAIL PROTECTED] :
[...]
  

I recently bought three rtl8169 gigabit cards, along with a gigabit
switch. Trouble is, the computers keep freezing up once the NIC comes
under and decent amount of load. Let me lay this out for you a bit:

Computer A:
-Dual AMD 2600+ MP
-rtl8169 under *64-bit PCI slot*
-2.6.12 (vanilla)



It should be fine.

  

Good to know.

Computer B:
-Intel P4 2.4GHz
-rtl8169 under 32-bit PCI slot
-2.6.10 (vanilla)



  

Please upgrade this one.
  

Will do asap.

[...]
  

I've googled around (quite a bit), and found many many different patches
for the 8169 driver.



The patches are regularly pushed in mainline. Don't panic.

[...]
  

Any help would be appreciated.



Upgrading the kernel in the 2.6.10 box should fix a known issue.

Be sure to enable the magic sysrq in your new compilation.

If it is not enough, you may have found something new:
- please open a PR at http://bugzilla.kernel.org
- send:
  o 'lspci -vx'
  o complete dmesg after log (check that the very first lines do not
disappear),
  o lsmod
  o cat /proc/interrupts before f*ckup
  o ifconfig output
- do the keyboard led still answer after the lockup ?
- is NFS implied in your configuration ?
  If not can you reproduce the issue with torrent or ftp alone ?

--
Ueimor

  

-Keyboards LEDs are also locked. Fun stuff, huh?
-NFS is under use, sorry, I should have specified that. /srv (and
/usr/portage) are NFS mounted on computer A from computer B.
-Yes, I can easily reproduce this issue. It involves:
-Start a big transfer.
-In the case of a torrent, wait a few minutes (no more than 20).
-In the case of a FTP transfer over LAN, wait a few seconds (no more
than 40).

One thing I left out in my first mail: B is my router/server, yet when A
is torrenting, B does NOT lock up. Also note that B is running 2.6.10,
and A is on 2.6.12.

I'll get back to you in a few hours (once I'm back from school and have
tested this with a new kernel(s)).
-
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: ieee80211 patches

2005-09-06 Thread Jiri Benc

On Thu, 01 Sep 2005 19:16:05 +0100, Pedro Ramalhais wrote:
   Of
  course you may sometimes want to force reassociation manually - and
  there should be some call available for this. (Maybe setting BSSID while
  the card is running should force reassociation?)
 
 That's the kind of hackish solution that brings confusion. We should
 separate things: wireless configuration and wireless association. This
 way you won't have to do those hackish approaches and special cases.
 What i mean is that if you want to associate, tell the card to do so,
 don't send -1 as the channel or send 0 as the essid_len, or resend the
 previously configured essid.

I probably didn't explain well what I thought, sorry. Imagine following
situation: we have an AP with BSSID1 and another one with BSSID2, both
in the same ESS. When you set just the ESSID, somebody (kernel or
daemon, I'm still not decided on this) tell the driver to associate to
one of the APs - e.g. to BSSID1. When conditions change, the driver is
told to reassociate (to BSSID2). And so on. When you manually set BSSID2
(while we are associated to BSSID1), it surely means that the user wants
to reassociate to BSSID2 - there is nothing hackish in that.

But you're right anyway.


-- 
Jiri Benc
SUSE Labs
-
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: Fw: [Bugme-new] [Bug 5194] New: IPSec related OOps in 2.6.13

2005-09-06 Thread Krzysztof Oledzki




On Tue, 6 Sep 2005, Herbert Xu wrote:


On Tue, Sep 06, 2005 at 04:08:56AM -0700, Andrew Morton wrote:


Problem Description:

Oops:  [#1]
PREEMPT
Modules linked in:
CPU:0
EIP:0060:[c01f562c]Not tainted VLI
EFLAGS: 00010216   (2.6.13)
EIP is at sha1_update+0x7c/0x160


Thanks for the report.  Matt LaPlante had exactly the same problem
a couple of days ago.  I've tracked down now to my broken crypto
cipher wrapper functions which will step over a page boundary if
it's not aligned correctly.


[CRYPTO] Fix boundary check in standard multi-block cipher processors


Thanks. Patched my kernel, recompiled and waiting. So far it is OK,

Should this patch be merged into 2.6.13.1?

Best regards,

Krzysztof Olędzki

Modifying Cryptography Code

2005-09-06 Thread Alaa Dalghan


Hello everyone,
I need to modify some CRYPTOGRAPHY code in Linux Kernel to get a specific 
VPN behavior, but I don't know where to start.


The situation is the following:

I have a VPN gateway (Linux kernel 2.6.10 with Openswan 2.3.1 installed). I 
have only installed the user land tools from openswan package in order to 
use the native ipsec stack in the kernel.
I have 30 laptops equipped with Windows XP configured to launch secure 
tunnels towards the VPN gateway (so I have 30 tunnels). The laptops can 
communicate securely VIA the gateway and everything works fine but..


the problem is the following:

Each packet sent from a given client to the other get processed 4 times 
(encryption at the sender, decryption at the gateway, encryption at the 
gateway, decryption at the receiver). This is the normal behavior but it 
imposes too much processing overhead on the linux VPN gateway. The required 
behavior is that the VPN gateway just RELAYS encrypted data (ESP envelopes) 
without decrypting them. This is impossible in the current ipsec 
implementation sincethe end of a tunnel HAS ALWAYS to be decrypted.


Note that this required behavior can be achieved by launching a tunnel from 
each client to every other client making the VPN gateway 
transparent..BUT..this would mean 900 tunnels!! instead of 30, so it is not 
the answer.


What I am looking for is the portion of the C code in the kernel where the 
Decryption function is called to decrypt a received packet. When I find this 
statement, maybe i can make it conditionnal such as:  If the destination is 
me then Decrypt  else DO NOT!


I hope that someone can help me with finding this portion of the code and 
modify it. By the way I searched in the kernel file esp4.c but can't seem 
to find what I want.





  
--WinXP(1)

 |
Openswan 
boxWinXP(2)

 |
  
--WinXP(3)

 |
 |
 |
 |
  
-WinXP(30)


_
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

more ipsec crashes in 2.6.13

2005-09-06 Thread Olaf Hering


This happens after:

ssh [EMAIL PROTECTED] rcipsec restart
ssh [EMAIL PROTECTED] rcipsec restart

ssh [EMAIL PROTECTED] ping -i 0.01 -s 4096 g167.suse.de

The patch 'p' which was posted by Herbert today doesnt fix it.

put_page gets NULL.


Welcome to SUSE LINUX 10.0 (PPC) - Kernel 2.6.13-ppc64-vanilla (hvc0).


cube login: cpu 0x1: Vector: 300 (Data Access) at [c0004d7daff0]
pc: c00a76fc: .put_page+0xc/0x120
lr: c0333a30: .skb_release_data+0xd0/0xf0
sp: c0004d7db270
   msr: 80009032
   dar: bdf20d2efc7304a2
 dsisr: 4000
  current = 0xc252e7e0
  paca= 0xc04e7800
pid   = 6160, comm = ping
enter ? for help
[c0004d7db2f0] c0333a30 .skb_release_data+0xd0/0xf0
[c0004d7db380] c0339e24 .__skb_linearize+0x124/0x1d0
[c0004d7db420] c033c334 .dev_queue_xmit+0x264/0x380
[c0004d7db4c0] c036e20c .ip_finish_output+0x18c/0x380
[c0004d7db560] c036cba0 .ip_fragment+0x640/0x8d0
[c0004d7db640] c036d308 .ip_push_pending_frames+0x4d8/0x590
[c0004d7db700] c0390e3c .raw_sendmsg+0x67c/0x850
[c0004d7db830] c039cadc .inet_sendmsg+0x6c/0xb0
[c0004d7db8d0] c032b3ac .sock_sendmsg+0x16c/0x1c0
[c0004d7dbae0] c032c454 .sys_sendmsg+0x204/0x340
[c0004d7dbd10] c034eba4 .compat_sys_sendmsg+0x14/0x30
[c0004d7dbd90] c034f530 .compat_sys_socketcall+0x290/0x2b0
[c0004d7dbe30] c000d600 syscall_exit+0x0/0x18
--- Exception: c01 (System Call) at 07f518f8
SP (ffb458a0) is in userspace
1:mon 
-
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: more ipsec crashes in 2.6.13

2005-09-06 Thread Olaf Hering

 On Tue, Sep 06, Olaf Hering wrote:

 put_page gets NULL.

dar: bdf20d2efc7304a2

No, it is garbage.
-
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

AES 256 support not announced by IPSec framework?

2005-09-06 Thread Ingo Oeser

Hi there,

I'm just asking myself, why is AES-256 not announced by the IPsec framework?
The kernel crypto-API seems to support a keysize of 256.
Or is the blocksize (of 256 bits) meant by AES-256?

I'm a bit lost on this one.


Regards

Ingo Oeser

-
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] sunrpc: add endian annotations

2005-09-06 Thread viro

On Tue, Sep 06, 2005 at 12:21:05PM +0400, Alexey Dobriyan wrote:
 * usual s/u32/__be32/.
 * add svc_getnl():
   Take network-endian value from buffer, convert to host-endian
   one and return it.
 * add svc_putnl():
   Take host-endian value, convert to network-endian one and put
   it into a buffer.
 * convert to svc_getnl(), svc_putnl().

ACK, but since we have it inlined anyway I would suggest switching most
of remaining svc_putu32() to svc_putnl().  Stuff like svc_putu32(xdr_one)
can become svc_putnl(1) and cc will handle that just fine.

I'm still not too happy about the names, though - almost to the point
where I'd seriously consider something like svc_encode_u32()/svc_decode_u32().
At least that would be more in line with the rest of XDR-related marshalling
code...

Dunno.  If Trond ACKs that, I'll take this as-is and add the conversion
mentioned above as a separate patch on top of that.  It would be great if
somebody came up with better names...
-
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: Possible neighbour reference leak in net/ipv4/xfrm4_policy.c

2005-09-06 Thread Patrick McHardy


Ben Greear wrote:

Patrick McHardy wrote:


dst_prev is newly allocated in the loop a couple of lines above.



Ok, that makes sense now.

I also did not find a single neigh_put in the entire xfrm4_policy.c file.

Should include/net/xfrm.h's method:  xfrm_dst_destroy release the
neighbour?


Not necessary, xfrm_dst_destroy is called from dst_destroy, which
takes care of releasing the neighbour 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: Possible neighbour reference leak in net/ipv4/xfrm4_policy.c

2005-09-06 Thread Ben Greear


Patrick McHardy wrote:

Ben Greear wrote:


Patrick McHardy wrote:


dst_prev is newly allocated in the loop a couple of lines above.




Ok, that makes sense now.

I also did not find a single neigh_put in the entire xfrm4_policy.c file.

Should include/net/xfrm.h's method:  xfrm_dst_destroy release the
neighbour?



Not necessary, xfrm_dst_destroy is called from dst_destroy, which
takes care of releasing the neighbour entry.


Ok, sorry for the confusion.

Thanks,
Ben

--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc  http://www.candelatech.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

[AX.25] Make ax2asc thread-proof

2005-09-06 Thread Ralf Baechle

Ax2asc was still using a static buffer for all invocations which isn't
exactly SMP-safe.  Change ax2asc to take an additional result buffer as
the argument.  Change all callers to provide such a buffer.

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

 include/net/ax25.h |2 +-
 net/ax25/af_ax25.c |7 ---
 net/ax25/ax25_addr.c   |3 +--
 net/ax25/ax25_route.c  |7 +--
 net/ax25/ax25_uid.c|4 +++-
 net/netrom/af_netrom.c |7 ---
 net/netrom/nr_route.c  |8 +---
 net/rose/af_rose.c |6 --
 net/rose/rose_route.c  |   14 +-
 net/rose/rose_subr.c   |5 +++--
 10 files changed, 39 insertions(+), 24 deletions(-)

Index: linux-cvs/include/net/ax25.h
===
--- linux-cvs.orig/include/net/ax25.h
+++ linux-cvs/include/net/ax25.h
@@ -278,7 +278,7 @@ extern struct sock *ax25_make_new(struct
 
 /* ax25_addr.c */
 extern ax25_address null_ax25_address;
-extern char *ax2asc(ax25_address *);
+extern char *ax2asc(char *buf, ax25_address *);
 extern ax25_address *asc2ax(char *);
 extern int  ax25cmp(ax25_address *, ax25_address *);
 extern int  ax25digicmp(ax25_digi *, ax25_digi *);
Index: linux-cvs/net/ax25/af_ax25.c
===
--- linux-cvs.orig/net/ax25/af_ax25.c
+++ linux-cvs/net/ax25/af_ax25.c
@@ -1863,6 +1863,7 @@ static void ax25_info_stop(struct seq_fi
 static int ax25_info_show(struct seq_file *seq, void *v)
 {
ax25_cb *ax25 = v;
+   char buf[11];
int k;
 
 
@@ -1874,13 +1875,13 @@ static int ax25_info_show(struct seq_fil
seq_printf(seq, %8.8lx %s %s%s ,
   (long) ax25,
   ax25-ax25_dev == NULL? ??? : ax25-ax25_dev-dev-name,
-  ax2asc(ax25-source_addr),
+  ax2asc(buf, ax25-source_addr),
   ax25-iamdigi? *:);
-   seq_printf(seq, %s, ax2asc(ax25-dest_addr));
+   seq_printf(seq, %s, ax2asc(buf, ax25-dest_addr));
 
for (k=0; (ax25-digipeat != NULL)  (k  ax25-digipeat-ndigi); k++) 
{
seq_printf(seq, ,%s%s,
-  ax2asc(ax25-digipeat-calls[k]),
+  ax2asc(buf, ax25-digipeat-calls[k]),
   ax25-digipeat-repeated[k]? *:);
}
 
Index: linux-cvs/net/ax25/ax25_addr.c
===
--- linux-cvs.orig/net/ax25/ax25_addr.c
+++ linux-cvs/net/ax25/ax25_addr.c
@@ -36,9 +36,8 @@ ax25_address null_ax25_address = {{0x40,
 /*
  * ax25 - ascii conversion
  */
-char *ax2asc(ax25_address *a)
+char *ax2asc(char *buf, ax25_address *a)
 {
-   static char buf[11];
char c, *s;
int n;
 
Index: linux-cvs/net/ax25/ax25_route.c
===
--- linux-cvs.orig/net/ax25/ax25_route.c
+++ linux-cvs/net/ax25/ax25_route.c
@@ -284,6 +284,8 @@ static void ax25_rt_seq_stop(struct seq_
 
 static int ax25_rt_seq_show(struct seq_file *seq, void *v)
 {
+   char buf[11];
+
if (v == SEQ_START_TOKEN)
seq_puts(seq, callsign  dev  mode digipeaters\n);
else {
@@ -294,7 +296,7 @@ static int ax25_rt_seq_show(struct seq_f
if (ax25cmp(ax25_rt-callsign, null_ax25_address) == 0)
callsign = default;
else
-   callsign = ax2asc(ax25_rt-callsign);
+   callsign = ax2asc(buf, ax25_rt-callsign);
 
seq_printf(seq, %-9s %-4s,
callsign,
@@ -314,7 +316,8 @@ static int ax25_rt_seq_show(struct seq_f
 
if (ax25_rt-digipeat != NULL)
for (i = 0; i  ax25_rt-digipeat-ndigi; i++)
-   seq_printf(seq,  %s, 
ax2asc(ax25_rt-digipeat-calls[i]));
+   seq_printf(seq,  %s,
+ax2asc(buf, ax25_rt-digipeat-calls[i]));
 
seq_puts(seq, \n);
}
Index: linux-cvs/net/ax25/ax25_uid.c
===
--- linux-cvs.orig/net/ax25/ax25_uid.c
+++ linux-cvs/net/ax25/ax25_uid.c
@@ -168,12 +168,14 @@ static void ax25_uid_seq_stop(struct seq
 
 static int ax25_uid_seq_show(struct seq_file *seq, void *v)
 {
+   char buf[11];
+
if (v == SEQ_START_TOKEN)
seq_printf(seq, Policy: %d\n, ax25_uid_policy);
else {
struct ax25_uid_assoc *pt = v;
 
-   seq_printf(seq, %6d %s\n, pt-uid, ax2asc(pt-call));
+   seq_printf(seq, %6d %s\n, pt-uid, ax2asc(buf, pt-call));
}
return 0;
 }
Index: linux-cvs/net/netrom/af_netrom.c
===
--- linux-cvs.orig/net/netrom/af_netrom.c
+++ linux-cvs/net/netrom/af_netrom.c
@@ -1265,6 +1265,7 @@ static int nr_info_show(struct seq_file

IPW2100 Kconfig

2005-09-06 Thread Alejandro Bonilla

Hi,

I checked the IPW2100 in the current git from linux-2.6 and the 
menuconfig
help (Kconfig) says you need to put the firmware in /etc/firmware, it should
be /lib/firmware.

Who should I send the patch to? Or can someone simply change that?

Thanks,

.Alejandro

-
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] wrong firmware location in IPW2100 Kconfig entry (Was: IPW2100 Kconfig)

2005-09-06 Thread Jesper Juhl

On Tuesday 06 September 2005 20:32, Alejandro Bonilla wrote:
 Hi,
 
   I checked the IPW2100 in the current git from linux-2.6 and the 
 menuconfig
 help (Kconfig) says you need to put the firmware in /etc/firmware, it should
 be /lib/firmware.
 
 Who should I send the patch to? Or can someone simply change that?
 

Firmware should go into /lib/firmware, not /etc/firmware.

Found by Alejandro Bonilla.


Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---

 drivers/net/wireless/Kconfig |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.13-mm1-orig/drivers/net/wireless/Kconfig  2005-09-02 
23:59:51.0 +0200
+++ linux-2.6.13-mm1/drivers/net/wireless/Kconfig   2005-09-06 
20:39:45.0 +0200
@@ -152,7 +152,7 @@
  In order to use this driver, you will need a firmware image for it.
   You can obtain the firmware from
  http://ipw2100.sf.net/.  Once you have the firmware image, you 
- will need to place it in /etc/firmware.
+ will need to place it in /lib/firmware.
 
   You will also very likely need the Wireless Tools in order to
   configure your card:


-
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] wrong firmware location in IPW2100 Kconfig entry (Was: IPW2100 Kconfig)

2005-09-06 Thread Alejandro Bonilla

  Who should I send the patch to? Or can someone simply change that?

Jesper,

Thanks. I also had a question. To whom is this patch sent to? Netdev or 
LK?
How does one determine?

.Alejandro


 Firmware should go into /lib/firmware, not /etc/firmware.

 Found by Alejandro Bonilla.


 Signed-off-by: Jesper Juhl [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: Question on neighbour reference count in neigh_create

2005-09-06 Thread David S. Miller

From: Ben Greear [EMAIL PROTECTED]
Date: Mon, 05 Sep 2005 23:50:45 -0700

 In net/core/neighbour.c, method neigh_alloc, the
 ref-count is set to one near the bottom of the method.

 I notice in neigh_create, for instance, the ref-count is
 increased again as the neighbour is put into the table's
 hash list, so that should account for that reference..

 What is holding that first reference set in neigh_alloc?

Whoever calls neigh_create(), in your case it's probably
the routing cache via arp_bind_neighbour().

-
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: Question on neighbour reference count in neigh_create

2005-09-06 Thread Ben Greear

David S. Miller wrote:

From: Ben Greear [EMAIL PROTECTED]
Date: Mon, 05 Sep 2005 23:50:45 -0700

In net/core/neighbour.c, method neigh_alloc, the
ref-count is set to one near the bottom of the method.

I notice in neigh_create, for instance, the ref-count is
increased again as the neighbour is put into the table's
hash list, so that should account for that reference..

What is holding that first reference set in neigh_alloc?

Whoever calls neigh_create(), in your case it's probably
the routing cache via arp_bind_neighbour().

The neigh_create method grabs a reference with
neigh_hold for the caller.  The initial reference set in
neigh_alloc seems to be associated with the reference in
the neighbour table hash.  So, by the time we return from
neigh_create, the neighbour struct has two references.

It might be logically cleaner to grab the ref for the neigh-table in
neigh_create instead of neigh_alloc, but there doesn't actually
seem to be a problem with the current code.

Thanks,
Ben

--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc  http://www.candelatech.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

neighbour.c and NUD_IN_TIMER

2005-09-06 Thread Ben Greear


If my debugging code is correct, I've tracked down the
leaked neighbour structure as being referenced here:

if (!(neigh-nud_state  (NUD_STALE | NUD_INCOMPLETE))) {
if (neigh-parms-mcast_probes + neigh-parms-app_probes) {
atomic_set(neigh-probes, neigh-parms-ucast_probes);
neigh-nud_state = NUD_INCOMPLETE;
*** neigh_hold(neigh, NDRK_NEIGH_TIMER);
neigh-timer.expires = now + 1;
add_timer(neigh-timer);


From looking at this code:

static int neigh_del_timer(struct neighbour *n)
{
if ((n-nud_state  NUD_IN_TIMER) 
del_timer(n-timer)) {
neigh_release(n, NDRK_NEIGH_TIMER);
return 1;
}
return 0;
}

Shouldn't we always do something similar to neigh-nud_state |= NUD_IN_TIMER
before calling the add_timer() method?


Thanks,
Ben

--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc  http://www.candelatech.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] skb_get/set_timestamp use const

2005-09-06 Thread Stephen Hemminger

The new timestamp get/set routines should have const attribute
on parameters (helps to indicate direction).

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


Index: skge-2.6.13/include/linux/skbuff.h
===
--- skge-2.6.13.orig/include/linux/skbuff.h
+++ skge-2.6.13/include/linux/skbuff.h
@@ -1251,7 +1251,7 @@ extern void skb_add_mtu(int mtu);
  * This function converts the offset back to a struct timeval and stores
  * it in stamp.
  */
-static inline void skb_get_timestamp(struct sk_buff *skb, struct timeval 
*stamp)
+static inline void skb_get_timestamp(const struct sk_buff *skb, struct timeval 
*stamp)
 {
stamp-tv_sec  = skb-tstamp.off_sec;
stamp-tv_usec = skb-tstamp.off_usec;
@@ -1270,7 +1270,7 @@ static inline void skb_get_timestamp(str
  * This function converts a struct timeval to an offset and stores
  * it in the skb.
  */
-static inline void skb_set_timestamp(struct sk_buff *skb, struct timeval 
*stamp)
+static inline void skb_set_timestamp(struct sk_buff *skb, const struct timeval 
*stamp)
 {
skb-tstamp.off_sec  = stamp-tv_sec - skb_tv_base.tv_sec;
skb-tstamp.off_usec = stamp-tv_usec - skb_tv_base.tv_usec;
-
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.6.13 2/2] 3c59x: add option for using memory-mapped PCI I/O resources

2005-09-06 Thread Andrew Morton

Christoph Hellwig [EMAIL PROTECTED] wrote:

 On Tue, Sep 06, 2005 at 04:44:00PM -0400, John W. Linville wrote:
  Add module option to enable 3c59x driver to use memory-mapped PCI I/O
  resources.  This may improve performance for those devices so equipped.
  
  Add use_mmio=1 to the 3c59x module options in order to enable this
  functionality.
 
 I'm not sure a module option makes sense for this setting, except maybe
 as a debugging aid.  You should rather have a flag in the PCI IDs private
 data that can be used to enable mmio for those cards that support it.

I guess it's OK for the initial testing.  Plus we should make the new
feature default to on during initial public testing.  I'll make that
change.

-
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] skb_get/set_timestamp use const

2005-09-06 Thread Arnaldo Carvalho de Melo

On 9/6/05, Stephen Hemminger [EMAIL PROTECTED] wrote:
 The new timestamp get/set routines should have const attribute
 on parameters (helps to indicate direction).
 
 Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]

Signed-off-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]

I'm using these routines now on DCCP to get a better estimate of the
elapsed time, i.e. the time a packet stays in queues, backlogs, etc,
that needs to be reported to the peer and when doing a skb_delay()
function noticed the lack of 'const' as well, thanks.

- Arnaldo
-
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: neighbour.c and NUD_IN_TIMER (netdev unregister problem fixed!?!)

2005-09-06 Thread Ben Greear


Ben Greear wrote:

If my debugging code is correct, I've tracked down the
leaked neighbour structure as being referenced here:

if (!(neigh-nud_state  (NUD_STALE | NUD_INCOMPLETE))) {
if (neigh-parms-mcast_probes + neigh-parms-app_probes) {
atomic_set(neigh-probes, neigh-parms-ucast_probes);
neigh-nud_state = NUD_INCOMPLETE;
***neigh_hold(neigh, NDRK_NEIGH_TIMER);
neigh-timer.expires = now + 1;
add_timer(neigh-timer);


 From looking at this code:

static int neigh_del_timer(struct neighbour *n)
{
if ((n-nud_state  NUD_IN_TIMER) 
del_timer(n-timer)) {
neigh_release(n, NDRK_NEIGH_TIMER);
return 1;
}
return 0;
}

Shouldn't we always do something similar to neigh-nud_state |= 
NUD_IN_TIMER

before calling the add_timer() method?


I added the neigh-nud_state |= NUD_IN_TIMER;
logic to neighbour.c, and I have not been able to reproduce
the problem removing network interfaces.  So, I think that
was the problem!

The full patch, including neighbour ref counting debugging
is available for review here:

http://www.candelatech.com/oss/neigh_ref.patch

This patch builds on top of my earlier netdev ref counting debugging
patch, and still needs some additional cleanup.  It also uses the same
malloc-using logic that the netdev code uses.

I'm also attaching a patch that just fixes the problem,
with no debugging info.  (Compiled but not tested by
itself.)

Signed-off-by Ben Greear [EMAIL PROTECTED]


--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc  http://www.candelatech.com

diff --git a/net/core/neighbour.c b/net/core/neighbour.c
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -1,4 +1,4 @@
-/*
+/* -*- linux-c -*-
  *	Generic address resolution entity
  *
  *	Authors:
@@ -853,6 +853,7 @@ int __neigh_event_send(struct neighbour 
 			neigh-nud_state = NUD_INCOMPLETE;
 			neigh_hold(neigh);
 			neigh-timer.expires = now + 1;
+			neigh-nud_state |= NUD_IN_TIMER;
 			add_timer(neigh-timer);
 		} else {
 			neigh-nud_state = NUD_FAILED;
@@ -867,6 +868,7 @@ int __neigh_event_send(struct neighbour 
 		neigh_hold(neigh);
 		neigh-nud_state = NUD_DELAY;
 		neigh-timer.expires = jiffies + neigh-parms-delay_probe_time;
+ 		neigh-nud_state |= NUD_IN_TIMER;
 		add_timer(neigh-timer);
 	}
 
@@ -1016,6 +1018,7 @@ int neigh_update(struct neighbour *neigh
 			neigh-timer.expires = jiffies + 
 		((new  NUD_REACHABLE) ? 
 		 neigh-parms-reachable_time : 0);
+			neigh-nud_state |= NUD_IN_TIMER;
 			add_timer(neigh-timer);
 		}
 		neigh-nud_state = new;

Re: [PATCH] make use of -private_data in sockfd_lookup

2005-09-06 Thread David S. Miller

From: Eric Dumazet [EMAIL PROTECTED]
Date: Tue, 06 Sep 2005 01:51:16 +0200

 Avoid touching file-f_dentry on sockets, since file-private_data directly 
 gives us the socket pointer.

 Signed-off-by: Eric Dumazet [EMAIL PROTECTED]

Applied, thanks Eric.
-
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] make sure l_linger is unsigned to avoid negative timeouts

2005-09-06 Thread David S. Miller

From: Eric Dumazet [EMAIL PROTECTED]
Date: Tue, 06 Sep 2005 16:11:19 +0200

 I dont know if it's safe to change l_linger to 'unsigned int' in the include 
 file (It might be defined as int in ABI specs)

 So I believe this patch is needed :

 Signed-off-by: Eric Dumazet [EMAIL PROTECTED]

Good catch Eric.  I also think it's best to just add the cast, so I've
applied your patch.  Thanks a lot.
-
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.6.13 2/2] 3c59x: add option for using memory-mapped PCI I/O resources

2005-09-06 Thread Andrew Morton

John W. Linville [EMAIL PROTECTED] wrote:

 I fully intend to have have a flag in the private data set based on
  the PCI ID when I accumulate some data on which devices support this
  and which don't.  So far I've only got a short list...  Do you think
  such a flag should be based on which ones work, or which ones break?

The ones which are known to work.

Bear in mind that this is an old, messy and relatively stable driver which
handles a huge number of different NICs.   Caution is the rule here.
-
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: Netconsole violates dev-hard_start_xmit synch rules

2005-09-06 Thread Eugene Surovegin

On Tue, Sep 06, 2005 at 03:36:27PM -0700, David S. Miller wrote:
 From: Eugene Surovegin [EMAIL PROTECTED]
 Date: Tue, 6 Sep 2005 15:04:17 -0700

  David, correct me if I'm wrong, but I think there is a major problem
  with current netconsole/netpoll approach.

 You're preaching to the choir.  I think the whole netpoll
 implementation is fundamentally flawed, and the locking problems we
 keep bumping into are merely a symptom.

David, thanks for confirming this. I was worried I was missing 
something obvious.

-- 
Eugene

-
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: Netconsole violates dev-hard_start_xmit synch rules

2005-09-06 Thread David S. Miller

From: Matt Mackall [EMAIL PROTECTED]
Date: Tue, 6 Sep 2005 15:32:50 -0700

 Unfortunately, netpoll fundamentally requires everything to work with
 interrupts off. This can't be changed. It could be called from the
 context of an oops, or worse, by the kgdb stub at a breakpoint. If
 drivers require interrupts enabled for hard_start_xmit, they simply
 can't work with netpoll.

I really sense that nepoll needs to fundamentally change to
defer all of it's actions to software interrupt context.

Yes, you lose some reliability in cases I've described in other
postings to this thread, but the locking problems all vanish
and you no longer need to disable interrupts illegally when
calling these core driver functions.

It is illegal not just from a latency perspective, drivers
really do want inerrupts enabled during -hard_start_xmit()
just to _function_ correctly.  Some spin on jiffies increasing
for example, and that's perfectly fine and needs to work
properly.

Mentioning the latency of the serial console, in support of
netpoll's interrupt disabling, is quite a straw man.
-
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: neighbour.c and NUD_IN_TIMER (netdev unregister problem fixed!?!)

2005-09-06 Thread David S. Miller

From: Ben Greear [EMAIL PROTECTED]
Date: Tue, 06 Sep 2005 14:37:26 -0700

 I'm also attaching a patch that just fixes the problem,
 with no debugging info.  (Compiled but not tested by
 itself.)
 
 Signed-off-by Ben Greear [EMAIL PROTECTED]

Thanks for tracking this down, I'll review it more deeply
later because it's weird that a bug like this one would
persist for so long :-)
-
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] skb_get/set_timestamp use const

2005-09-06 Thread David S. Miller

From: Stephen Hemminger [EMAIL PROTECTED]
Date: Tue, 6 Sep 2005 14:01:17 -0700

 The new timestamp get/set routines should have const attribute
 on parameters (helps to indicate direction).
 
 Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]

Applied, thanks Stephen.

-
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: Netconsole violates dev-hard_start_xmit synch rules

2005-09-06 Thread Matt Mackall

On Tue, Sep 06, 2005 at 03:36:27PM -0700, David S. Miller wrote:
 From: Eugene Surovegin [EMAIL PROTECTED]
 Date: Tue, 6 Sep 2005 15:04:17 -0700

  David, correct me if I'm wrong, but I think there is a major problem
  with current netconsole/netpoll approach.

 You're preaching to the choir.  I think the whole netpoll
 implementation is fundamentally flawed, and the locking problems we
 keep bumping into are merely a symptom.

 People want this thing so badly, that I keep letting them continue to
 patch this thing into quasi-working, even though it's foundations are
 what are so problematic.

Well I agree in some ways and disagree in others.

 It's never going to work %100 reliably, I think, here's why:

 The core issue, and conflict, is that the desire is to have the
 responses be immediate and come at the moment the event occurs.
 Because the situation may be so dire that deferring into a more
 appropriate software IRQ context may not be possible, and thus we'd
 lose the log message or event.

In the case of kgdb-over-ethernet or netdump or several others,
deferring to an IRQ context doesn't even make sense.

 So we try to spit out netconsole messages in hw IRQ context and stuff
 like that, as you stated.  The tg3 driver is susceptible to the
 problem you mention, as is bnx2, because they use purely software
 interrupt spinlocking, and thus their timers will deadlock if any hw
 IRQ context netpoll operations occur.

I'm not aware of the tg3 problem, please describe it in more detail.

 There is a way to fix all of this, deferring all netpoll operations to
 software IRQ context, but you sacrifice reliability when the system is
 in such a bad state that software IRQs are not occuring any more
 or are deadlocked.

At that point, why bother? Just use syslogd. Or more likely, use a
serial cable, which will actually work reliably.

Where I disagree is this: what netpoll is trying to do is not
fundamentally unreasonable. There's nothing magical about interrupts
that should make it impossible to drive network hardware in polled
mode with interrupts disabled. 

Instead, the problem is that the network stack has evolved in a
direction that made a bunch of fairly reasonable assumptions that
netpoll has now broken.

-- 
Mathematics is the supreme nostalgia of our time.
-
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] ip: reassembly trim not clearing CHECKSUM_HW

2005-09-06 Thread David S. Miller

From: Stephen Hemminger [EMAIL PROTECTED]
Date: Tue, 6 Sep 2005 13:26:15 -0700

 This was found by inspection while looking for checksum problems
 with the skge driver that sets CHECKSUM_HW. It did not fix the
 problem, but it looks like it is needed.

 If IP reassembly is trimming an overlapping fragment, it
 should reset (or adjust) the hardware checksum flag on the skb.

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

Applied and submitted to -stable.

... maybe ipv6 has the same bug?
-
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: Netconsole violates dev-hard_start_xmit synch rules

2005-09-06 Thread Matt Mackall

On Tue, Sep 06, 2005 at 03:42:07PM -0700, David S. Miller wrote:
 Mentioning the latency of the serial console, in support of
 netpoll's interrupt disabling, is quite a straw man.

No, it's exactly to the point: latency is a secondary concern when
we're printing an oops or other diagnostic. Otherwise it would be
unacceptable in the serial console as well, where the problem is
orders of magnitude worse.

-- 
Mathematics is the supreme nostalgia of our time.
-
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.6.13 2/2] 3c59x: add option for using memory-mapped PCI I/O resources

2005-09-06 Thread Andrew Morton

John W. Linville [EMAIL PROTECTED] wrote:

 On Tue, Sep 06, 2005 at 03:15:46PM -0700, Andrew Morton wrote:
  John W. Linville [EMAIL PROTECTED] wrote:
  
   I fully intend to have have a flag in the private data set based on
the PCI ID when I accumulate some data on which devices support this
and which don't.  So far I've only got a short list...  Do you think
such a flag should be based on which ones work, or which ones break?
  
  The ones which are known to work.
  
  Bear in mind that this is an old, messy and relatively stable driver which
  handles a huge number of different NICs.   Caution is the rule here.
 
 I definitely agree.  That is another part of why I defaulted to use_mmio=0.
 
 I'll post PCI ID based patches as I determine supported cards.
 

What I'd suggest you do is to look at enabling the feature for, say,
IS_CYCLONE and IS_TORNADO NICs.  Do that as a separate -mm patch, make sure
that an explicit `use_mmio=0' will still turn it off.

So in the style of that driver, something like:

static int use_mmio[MAX_UNITS] = { [ 0 .. MAX_UNITS-1 ] = -1, };

Then:

if (module parm given)
use_mmio[unit] = 1 or 0

...

/* Determine the default if the user didn't override us */
if (use_mmio[unit] == -1  (IS_CYCLONE || IS_TORNADO))
use_mmio[unit] = 1;

priv-use_mmio = use_mmio[unit];(maybe)



if (priv-use_mmio == 1)
do mmio stuff


There's a bit to be done here, so I'll drop your initial set of patches.

btw, Donald Becker's 3c59x.c has done mmio for ages.  Suggest you take a
look in there. http://www.scyld.com/vortex.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: neighbour.c and NUD_IN_TIMER

2005-09-06 Thread YOSHIFUJI Hideaki / 吉藤英明

In article [EMAIL PROTECTED] (at Tue, 06 Sep 2005 13:05:16 -0700), Ben Greear 
[EMAIL PROTECTED] says:

   neigh-nud_state = NUD_INCOMPLETE;
 ***   neigh_hold(neigh, NDRK_NEIGH_TIMER);
   neigh-timer.expires = now + 1;
   add_timer(neigh-timer);
:
 Shouldn't we always do something similar to neigh-nud_state |= NUD_IN_TIMER
 before calling the add_timer() method?

NUD_IN_TIMER has a bit of NUD_INCOMPLETE.

--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: more ipsec crashes in 2.6.13

2005-09-06 Thread Olaf Hering

 On Tue, Sep 06, Olaf Hering wrote:

 
 This happens after:
 
 ssh [EMAIL PROTECTED] rcipsec restart
 ssh [EMAIL PROTECTED] rcipsec restart
 
 ssh [EMAIL PROTECTED] ping -i 0.01 -s 4096 g167.suse.de
 
 The patch 'p' which was posted by Herbert today doesnt fix it.
 
 put_page gets NULL.
 
 
 Welcome to SUSE LINUX 10.0 (PPC) - Kernel 2.6.13-ppc64-vanilla (hvc0).
 
 
 cube login: cpu 0x1: Vector: 300 (Data Access) at [c0004d7daff0]
 pc: c00a76fc: .put_page+0xc/0x120
 lr: c0333a30: .skb_release_data+0xd0/0xf0
 sp: c0004d7db270
msr: 80009032
dar: bdf20d2efc7304a2

This patch from patch-2.6.13-rc2-git3 causes the crash.

tree abe25ec0577bd95128adb3f38609a09f0a3e2469
parent 8279dd748f9704b811e528b31304e2fab026abc5 
author Herbert Xu [EMAIL PROTECTED] Thu, 07 Jul 2005 03:51:31 -0700
committer David S. Miller [EMAIL PROTECTED] Thu, 07 Jul 2005 03:51:31 -0700

[CRYPTO] Add plumbing for multi-block operations

-
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: Fw: [Bugme-new] [Bug 5194] New: IPSec related OOps in 2.6.13

2005-09-06 Thread Matt LaPlante

Patch worked like a charm here, no more kernel panics! Excellent work, many
thanks for the quick fix...more people should have such a work ethic.

Cheers,
Matt

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:linux-kernel-
 [EMAIL PROTECTED] On Behalf Of Herbert Xu
 Sent: Tuesday, September 06, 2005 8:20 AM
 To: Andrew Morton
 Cc: netdev@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]
 bugs.osdl.org; Matt LaPlante; Linux Kernel Mailing List; David S. Miller
 Subject: Re: Fw: [Bugme-new] [Bug 5194] New: IPSec related OOps in 2.6.13
 
 On Tue, Sep 06, 2005 at 04:08:56AM -0700, Andrew Morton wrote:
 
  Problem Description:
 
  Oops:  [#1]
  PREEMPT
  Modules linked in:
  CPU:0
  EIP:0060:[c01f562c]Not tainted VLI
  EFLAGS: 00010216   (2.6.13)
  EIP is at sha1_update+0x7c/0x160
 
 Thanks for the report.  Matt LaPlante had exactly the same problem
 a couple of days ago.  I've tracked down now to my broken crypto
 cipher wrapper functions which will step over a page boundary if
 it's not aligned correctly.
 
 
 [CRYPTO] Fix boundary check in standard multi-block cipher processors
 
 The boundary check in the standard multi-block cipher processors are
 broken when nbytes is not a multiple of bsize.  In those cases it will
 always process an extra block.
 
 This patch corrects the check so that it processes at most nbytes of data.
 
 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


-
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: Netconsole violates dev-hard_start_xmit synch rules

2005-09-06 Thread Matt Mackall

On Tue, Sep 06, 2005 at 04:01:24PM -0700, David S. Miller wrote:
 So you cannot call into these drivers with HW interrupts disabled or
 even worse from HW interrupt context.  These drivers use locking
 strategies which are perfectly legal and work until you add netpoll.

And again, I agree.

What I disagree with is the claim that it's netpoll that's broken.
Again, I claim that netpoll is not doing something fundamentally
unreasonable. Driving hardware by polling with interrupts disabled is
nothing magic, it's just something the network stack to date has not
been designed to cope with.

So we can either:

a) have a netpoll that's crippled to softirq-only
b) live with some amount of localized brain damage here
c) attempt to make the stack more netpoll-accomodating

Option a) is a non-starter. It's scarcely better than syslogd for
logging purposes, and completely useless for things like
kgdb-over-ethernet and the like.

Option b) is what we have now. It's ugly as hell, agreed, but it does
work for quite a few scenarios where nothing else suffices.

Option c) is obviously a big project but maybe we can get from here to
there. One possible step in that direction would be exposing a
standard driver lock that netpoll can see and switching drivers that
have trouble (bnx2 and tg3 for starters) over to using it.

-- 
Mathematics is the supreme nostalgia of our time.
-
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: Netconsole violates dev-hard_start_xmit synch rules

2005-09-06 Thread Eugene Surovegin

On Tue, Sep 06, 2005 at 06:03:38PM -0700, Matt Mackall wrote:
 On Tue, Sep 06, 2005 at 04:01:24PM -0700, David S. Miller wrote:
  So you cannot call into these drivers with HW interrupts disabled or
  even worse from HW interrupt context.  These drivers use locking
  strategies which are perfectly legal and work until you add netpoll.
 
 And again, I agree.
 
 What I disagree with is the claim that it's netpoll that's broken.
 Again, I claim that netpoll is not doing something fundamentally
 unreasonable. Driving hardware by polling with interrupts disabled is
 nothing magic, it's just something the network stack to date has not
 been designed to cope with.

Well, it's not driving hw in polling mode with hw IRQs disabled 
(in fact, NAPI does exactly this), it's _calling_ driver entry 
points from illegal context. IMHO this is not the same.
 
 So we can either:
 
 a) have a netpoll that's crippled to softirq-only
 b) live with some amount of localized brain damage here
 c) attempt to make the stack more netpoll-accomodating

or a') make this a per-driver feature (e.g. NETIF_F_NETPOLL_CHALENGED) 

In this case, even if driver cannot handle being called from IRQ 
context, netconsole still can be used, although in a little more 
limited fashion, but being safe and not causing lock ups, which, as 
far as I understand you, it was designed to help debugging in the 
first place :).

-- 
Eugene

-
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/1] ipw2100: remove by-hand function entry/exit debugging

2005-09-06 Thread Jeff Garzik

[EMAIL PROTECTED] wrote:

From: Pavel Machek [EMAIL PROTECTED]

This removes debug prints from entry/exit of functions.  Such level of
debugging should probably be done by gdb or similar.

Signed-off-by: Pavel Machek [EMAIL PROTECTED]
Cc: Jeff Garzik [EMAIL PROTECTED]
Cc: James P. Ketrenos [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]

NAK.  Rationale:  maintainer's choice.  Pavel doesn't get to choose the 
debugger of choice for the driver maintainer.

I do this entry/exit stuff in my net and SATA drivers; printk is my 
primary method of debugging.

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: Netconsole violates dev-hard_start_xmit synch rules

2005-09-06 Thread Matt Mackall

On Tue, Sep 06, 2005 at 06:37:40PM -0700, Eugene Surovegin wrote:
 On Tue, Sep 06, 2005 at 06:03:38PM -0700, Matt Mackall wrote:
  On Tue, Sep 06, 2005 at 04:01:24PM -0700, David S. Miller wrote:
   So you cannot call into these drivers with HW interrupts disabled or
   even worse from HW interrupt context.  These drivers use locking
   strategies which are perfectly legal and work until you add netpoll.
  
  And again, I agree.
  
  What I disagree with is the claim that it's netpoll that's broken.
  Again, I claim that netpoll is not doing something fundamentally
  unreasonable. Driving hardware by polling with interrupts disabled is
  nothing magic, it's just something the network stack to date has not
  been designed to cope with.
 
 Well, it's not driving hw in polling mode with hw IRQs disabled 
 (in fact, NAPI does exactly this), it's _calling_ driver entry 
 points from illegal context. IMHO this is not the same.

The only reasonable way for core code to manipulate hardware is
calling driver interfaces, so I think you're splitting hairs.

  So we can either:
  
  a) have a netpoll that's crippled to softirq-only
  b) live with some amount of localized brain damage here
  c) attempt to make the stack more netpoll-accomodating
 
 or a') make this a per-driver feature (e.g. NETIF_F_NETPOLL_CHALENGED) 

 In this case, even if driver cannot handle being called from IRQ 
 context, netconsole still can be used, although in a little more 
 limited fashion, but being safe and not causing lock ups, which, as 
 far as I understand you, it was designed to help debugging in the 
 first place :).

Again, there's basically no point to this at all. It won't catch an
appreciable number of diagnostics that are not already caught by
syslog and it won't work with kgdb-over-ethernet, netdump, etc.

-- 
Mathematics is the supreme nostalgia of our time.
-
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: more ipsec crashes in 2.6.13

2005-09-06 Thread Herbert Xu

Olaf Hering [EMAIL PROTECTED] wrote:
 
 The patch 'p' which was posted by Herbert today doesnt fix it.

Can you please double check? That bug would cause exactly what
you're seeing here since it'll clobber the skb's shared section
which contains the nr_frags.

Thanks,
-- 
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: AES 256 support not announced by IPSec framework?

2005-09-06 Thread Herbert Xu

Ingo Oeser [EMAIL PROTECTED] wrote:
 
 I'm just asking myself, why is AES-256 not announced by the IPsec framework?

It should work.  Which user-space IPsec daemon are you using?
-- 
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: more ipsec crashes in 2.6.13

2005-09-06 Thread David S. Miller

From: Olaf Hering [EMAIL PROTECTED]
Date: Wed, 7 Sep 2005 01:56:11 +0200

 This patch from patch-2.6.13-rc2-git3 causes the crash.

 tree abe25ec0577bd95128adb3f38609a09f0a3e2469
 parent 8279dd748f9704b811e528b31304e2fab026abc5 
 author Herbert Xu [EMAIL PROTECTED] Thu, 07 Jul 2005 03:51:31 -0700
 committer David S. Miller [EMAIL PROTECTED] Thu, 07 Jul 2005 03:51:31 -0700

 [CRYPTO] Add plumbing for multi-block operations

So, does Herbert's patch posted today fix the bug or not?
-
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: proto_unregister sleeps while atomic

2005-09-06 Thread David S. Miller

From: Patrick McHardy [EMAIL PROTECTED]
Date: Wed, 07 Sep 2005 01:42:48 +0200

 The only other user of proto_list besides proto_register, which
 doesn't care, are the seqfs functions. They use the slab pointer,
 but in a harmless way:

 proto-slab == NULL ? no : yes,

 Anyway, I've moved it up to the top.

Ok thanks, patch 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 1/1] ipw2100: remove by-hand function entry/exit debugging

2005-09-06 Thread Jeff Garzik

David S. Miller wrote:

From: Jeff Garzik [EMAIL PROTECTED]
Date: Tue, 06 Sep 2005 21:51:21 -0400

NAK.  Rationale: maintainer's choice.  Pavel doesn't get to choose
the debugger of choice for the driver maintainer.

If it makes the driver unreadable and thus harder to maintain,
I think such changes should seriously be considered.

Most of the DEBUG_INFO macro usage is fine, but those enter
and exit ones are just pure noise and should be removed.

I find them useful in my own drivers; they are definitely not pure noise.

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: neighbour.c and NUD_IN_TIMER (netdev unregister problem fixed!?!)

2005-09-06 Thread David S. Miller

From: Ben Greear [EMAIL PROTECTED]
Date: Tue, 06 Sep 2005 16:03:36 -0700

 At any rate, I'll be happy to see this fix go in unless someone
 finds a problem with it!

As Yoshifuji showed, NUD_INCOMPLETE is a part of the
bitmask NUD_IN_TIMER, as is NUD_DELAY and a few others.

So it is actually an error to force all of those bits to
get set, and there is no bug being fixed by your change
since one of the NUD_IN_TIMER is known to be set at all
of those add_timer() call sites.

Back to the drawing board. :-)

-
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: neighbour.c and NUD_IN_TIMER

2005-09-06 Thread David S. Miller

From: YOSHIFUJI Hideaki [EMAIL PROTECTED]
Date: Wed, 07 Sep 2005 08:36:41 +0900 (JST)

 In article [EMAIL PROTECTED] (at Tue, 06 Sep 2005 13:05:16 -0700), Ben 
 Greear [EMAIL PROTECTED] says:

  neigh-nud_state = NUD_INCOMPLETE;
  *** neigh_hold(neigh, NDRK_NEIGH_TIMER);
  neigh-timer.expires = now + 1;
  add_timer(neigh-timer);
 :
  Shouldn't we always do something similar to neigh-nud_state |= NUD_IN_TIMER
  before calling the add_timer() method?

 NUD_IN_TIMER has a bit of NUD_INCOMPLETE.

Right, so this isn't the bug and Ben's patch wasn't fixing
anything.  Ho hum...

-
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: Netconsole violates dev-hard_start_xmit synch rules

2005-09-06 Thread Matt Mackall

On Tue, Sep 06, 2005 at 07:37:45PM -0700, David S. Miller wrote:
 From: Matt Mackall [EMAIL PROTECTED]
 Date: Tue, 6 Sep 2005 18:03:38 -0700

  Option c) is obviously a big project but maybe we can get from here to
  there. One possible step in that direction would be exposing a
  standard driver lock that netpoll can see and switching drivers that
  have trouble (bnx2 and tg3 for starters) over to using it.

 If this means moving them over to hw IRQ locking, this I totally
 cannot agree with.  It's a non-starter.

 I worked way too hard to eliminate all of the hw IRQ locking from the
 tg3 driver.  There is no way we'll have it undone for something like
 netpoll.

My proposal is for drivers to expose enough internal state in a
consistent fashion so that netpoll can avoid lock recursion deadlocks.
I don't particularly care how.

 And as I stated, you absolutely cannot call some drivers
 -hard_start_xmit() routine with hw IRQs disabled.  It's just not
 possible at all.  I even tried this myself last year in order to deal
 with a seperate locking issue, and it failed miserably.  To reiterate:

   Drivers need to be able to let things like jiffies
   advance in their -hard_start_xmit() routine.  Thus
   disabling HW interrupts during -hard_start_xmit()'s
   execution cannot ever be allowed.

That's sounds like a per-driver limitation, albeit likely a very hard
one to work around.

 All of this points to the fact that network stuff needs to be done
 within software IRQ context.

 I also do not agree with your assertion that netpoll cannot be useful
 if run from software IRQ context.  Someone trying to implement block
 device based core dumping would run into the same exact issue in the
 SCSI layer, which runs command completion from sw IRQs and whose
 locking totally depends upon it.

...And that's been tried and does indeed lose most of the time. Which
is why it's been abandoned.

Think upon the kgdb-over-ethernet case, please. The kernel hits a
breakpoint, the kgdb stub stops everything, sends a packet to the
debugging client, waits for a packet back.. This simply can't work if
we delay send/receive to the next softirq processing.

-- 
Mathematics is the supreme nostalgia of our time.
-
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: ieee80211 patches

2005-09-06 Thread Jeff Garzik


James Ketrenos wrote:

Jeff Garzik wrote:



Jiri Benc wrote:



Our patches against latest ieee80211 branch can be found at
http://kernel.org/pub/linux/kernel/people/jbenc/


Thanks for your patience.

To answer Pavel's question from the other email:

I was hoping that Intel would resend their patches, rediffed to the
latest ieee80211 branch.  I didn't want to apply all these cleanups,
which would then force Intel to rediff _yet again_.



When it rains it pours it seems... we finally had the time to split up
the commit Jiri originally asked us to split up; in doing so we rebased
the commit series against netdev-2.6#ieee80211 as of Aug 15th (commit
1b5cca3a88b7682d538d129c25f0e3092613a243)

When we rebased, the first commit was a run scripts/Lindent and trimmed
all trailing whitespace on include/net/ieee80211*.h and
net/ieee80211/*.c.  This makes the first patch in the series large, but
it is purely a Lindent patch.  Running it as the first step in the
rebase helped resolve any conflicts later (if you're interested in the
'clean-rebase' script it will apply non Lindent'd patches back into a
Lindented tree without Lindent caused conflicts).

Anyway, our rebasing from ieee80211 up to the latest development tip is
done across 29 commits, with a series size of 225k.

We have an updated GIT overlay of the rebased ieee80211 at
rsync://bughost.org/repos/ieee80211-rebase/.git/.  If you just want to
pull the objects/ tree, you can walk it via the commit
69b08411732dfc5a028ef19fc6c79b84302c4c30.  NOTE:  The GIT overlay
referenced here is not a full archive.  It only contains the objects
required to move from the parent (netdev-2.6#ieee80211) to the master. 
Once pulled you can use many of the git commands, but others (like

checkout) will likely fail.

We are willing to keep a ieee80211 GIT tree up to date w/ everyone's
patches that you can just periodically pull from if you'd like.  We
already have to maintain a separate tree anyway to enable updates and
snapshots for the ipw2{1,2}00 project users.  This is partially what is
causing us pain right now; any set of patches we apply may later end up
being conflicts when we try and merge back with netdev -- which means
the merge rarely occurs.  At the same time, we can't always wait for a
patch to be incorporated into netdev-2.6#ieee80211 before we make it
available to users.

Anyway, here is the shortlist of the changes we have for ieee80211,
available from the above rsync location.

(As a side note, we're working on a similar set for the ipw2{1,2}00
drivers that catch them up to being compatible with this version of
ieee80211, etc.  That series is 52 patches, breaking in at just over 1M.)


It seems like some of this overlaps changes already in upstream.  What's 
the best way to start this process?  I would prefer to receive patches 
rather than 'git pull' at the present time.


Should I Lindent the files first?
Would you rather just start sending those 50+ patches?

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: Netconsole violates dev-hard_start_xmit synch rules

2005-09-06 Thread David S. Miller

From: Matt Mackall [EMAIL PROTECTED]
Date: Tue, 6 Sep 2005 20:08:10 -0700

 Think upon the kgdb-over-ethernet case, please. The kernel hits a
 breakpoint, the kgdb stub stops everything, sends a packet to the
 debugging client, waits for a packet back.. This simply can't work if
 we delay send/receive to the next softirq processing.

Networking is asynchronous, kgdb-over-ethernet wants synchronous
processing from an asynchronous subsystem.  It is therefore no
surprise that these two sets of requirements are at odds with each
other and it simply isn't going to work very well.
-
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: Netconsole violates dev-hard_start_xmit synch rules

2005-09-06 Thread Matt Mackall

On Tue, Sep 06, 2005 at 07:32:38PM -0700, Eugene Surovegin wrote:
 On Tue, Sep 06, 2005 at 07:19:21PM -0700, Matt Mackall wrote:
   or a') make this a per-driver feature (e.g. NETIF_F_NETPOLL_CHALENGED) 
  
   In this case, even if driver cannot handle being called from IRQ 
   context, netconsole still can be used, although in a little more 
   limited fashion, but being safe and not causing lock ups, which, as 
   far as I understand you, it was designed to help debugging in the 
   first place :).
  
  Again, there's basically no point to this at all. It won't catch an
  appreciable number of diagnostics that are not already caught by
  syslog and it won't work with kgdb-over-ethernet, netdump, etc.
 
 Well, you're simplifying here. There are small embedded systems which 
 don't have syslogd, serial cable connected. For such systems even 
 softirq driven netpoll is useful.

I'm fairly familiar with the requirements of embedded systems, thanks.
If you're not getting significantly more functionality than the
syslogd in, say, busybox (about 4k), then why put it in the kernel?
 
 Anyway, it's much more easier for me to just say to my driver users 
 that netpoll is broken and isn't supported because of this, than 
 arguing here. For some reason, I have a wrong impression, that you 
 would want *more* users of your stuff.

Which would I rather have:

netconsole never catches my oopses, it's useless. 

netconsole didn't work with my driver, so I tried another card and it
works great.

-- 
Mathematics is the supreme nostalgia of our time.
-
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: neighbour.c and NUD_IN_TIMER (netdev unregister problem fixed!?!)

2005-09-06 Thread Ben Greear

David S. Miller wrote:

From: Ben Greear [EMAIL PROTECTED]
Date: Tue, 06 Sep 2005 16:03:36 -0700

At any rate, I'll be happy to see this fix go in unless someone
finds a problem with it!

As Yoshifuji showed, NUD_INCOMPLETE is a part of the
bitmask NUD_IN_TIMER, as is NUD_DELAY and a few others.

So it is actually an error to force all of those bits to
get set, and there is no bug being fixed by your change
since one of the NUD_IN_TIMER is known to be set at all
of those add_timer() call sites.

Bugger...

How about this call site?  The check is for new  NUD_IN_TIMER,
but there is no guarantee (that I can see) that neigh-nud_timer
has any of the NUD_IN_TIMER bits set.  The one place earlier
that sets neigh-nud_timer to new uses goto to exit the
method...

if (new != old) {
neigh_del_timer(neigh);
if (new  NUD_IN_TIMER) {
neigh_hold(neigh);
neigh-timer.expires = jiffies +
((new  NUD_REACHABLE) ?
 neigh-parms-reachable_time : 
0);
// BEN HACK
// neigh-nud_state |= NUD_IN_TIMER;

add_timer(neigh-timer);
}
neigh-nud_state = new;
}

--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc  http://www.candelatech.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

Re: neighbour.c and NUD_IN_TIMER (netdev unregister problem fixed!?!)

2005-09-06 Thread Ben Greear

Ben Greear wrote:

David S. Miller wrote:

From: Ben Greear [EMAIL PROTECTED]
Date: Tue, 06 Sep 2005 16:03:36 -0700

At any rate, I'll be happy to see this fix go in unless someone
finds a problem with it!

As Yoshifuji showed, NUD_INCOMPLETE is a part of the
bitmask NUD_IN_TIMER, as is NUD_DELAY and a few others.

So it is actually an error to force all of those bits to
get set, and there is no bug being fixed by your change
since one of the NUD_IN_TIMER is known to be set at all
of those add_timer() call sites.

Bugger...

How about this call site?  The check is for new  NUD_IN_TIMER,
but there is no guarantee (that I can see) that neigh-nud_timer
has any of the NUD_IN_TIMER bits set.  The one place earlier
that sets neigh-nud_timer to new uses goto to exit the
method...

if (new != old) {
neigh_del_timer(neigh);
if (new  NUD_IN_TIMER) {
neigh_hold(neigh);
neigh-timer.expires = jiffies +
((new  NUD_REACHABLE) ?
 neigh-parms-reachable_time : 0);
// BEN HACK
// neigh-nud_state |= NUD_IN_TIMER;

add_timer(neigh-timer);
}
neigh-nud_state = new;
}

Er..nevermind..the next line down does it!

Will dig some more.

Ben

--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc  http://www.candelatech.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

Re: Netconsole violates dev-hard_start_xmit synch rules

2005-09-06 Thread Matt Mackall

On Tue, Sep 06, 2005 at 08:19:34PM -0700, David S. Miller wrote:
 From: Matt Mackall [EMAIL PROTECTED]
 Date: Tue, 6 Sep 2005 20:08:10 -0700

  Think upon the kgdb-over-ethernet case, please. The kernel hits a
  breakpoint, the kgdb stub stops everything, sends a packet to the
  debugging client, waits for a packet back.. This simply can't work if
  we delay send/receive to the next softirq processing.

 Networking is asynchronous, kgdb-over-ethernet wants synchronous
 processing from an asynchronous subsystem.  It is therefore no
 surprise that these two sets of requirements are at odds with each
 other and it simply isn't going to work very well.

Serial is also asynchronous. And yet we have robust polling support
for typical serial hardware that works great for both console and
remote debugging support. Why? Because delivering kernel messages
synchronously has been a requirement for the serial console since day
one.

Kgdboe simply wants the asynchronous subsystem to get out of the
way. For most cards, it works just fine.

-- 
Mathematics is the supreme nostalgia of our time.
-
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: neighbour.c and NUD_IN_TIMER (netdev unregister problem fixed!?!)

2005-09-06 Thread David S. Miller

From: Ben Greear [EMAIL PROTECTED]
Date: Tue, 06 Sep 2005 20:24:38 -0700

 How about this call site?  The check is for new  NUD_IN_TIMER,
 but there is no guarantee (that I can see) that neigh-nud_timer
 has any of the NUD_IN_TIMER bits set.  The one place earlier
 that sets neigh-nud_timer to new uses goto to exit the
 method...

We assign new to neigh-nud_state right after the add_timer() call.
-
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: Netconsole violates dev-hard_start_xmit synch rules

2005-09-06 Thread Eugene Surovegin

On Tue, Sep 06, 2005 at 08:22:25PM -0700, Matt Mackall wrote:
 Which would I rather have:
 
 netconsole never catches my oopses, it's useless. 
 
 netconsole didn't work with my driver, so I tried another card and it
 works great.

Well, not all world which uses Linux is PC with PCI slots. In fact, 
there are much more non-PC devices (where you have SoC with built-in 
Ethernet) with Linux than PCs with Linux.

-- 
Eugene


-
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: Netconsole violates dev-hard_start_xmit synch rules

2005-09-06 Thread David S. Miller

From: Matt Mackall [EMAIL PROTECTED]
Date: Tue, 6 Sep 2005 20:35:32 -0700

 Kgdboe simply wants the asynchronous subsystem to get out of the
 way. For most cards, it works just fine.

It wants to impose a locking model restriction which never ever
existed in the past.

As I said, I myself even tried to add the disabled hw IRQ during
-hard_start_xmit() condition and it failed spectacularly and had to
be reverted from Linus's tree the very next day.  You simply cannot do
it.

You'll need to find a way to do netpoll without disabling hw IRQs
during these driver methods.  Then netpoll would be universally
usable, as it would even work with drivers which are software tunnels
and which feed packets back into the networking stack once they
encapsulate, which currently netpoll cannot handle.
-
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: Netconsole violates dev-hard_start_xmit synch rules

2005-09-06 Thread Matt Mackall

On Tue, Sep 06, 2005 at 08:37:36PM -0700, Eugene Surovegin wrote:
 On Tue, Sep 06, 2005 at 08:22:25PM -0700, Matt Mackall wrote:
  Which would I rather have:
  
  netconsole never catches my oopses, it's useless. 
  
  netconsole didn't work with my driver, so I tried another card and it
  works great.
 
 Well, not all world which uses Linux is PC with PCI slots. In fact, 
 there are much more non-PC devices (where you have SoC with built-in 
 Ethernet) with Linux than PCs with Linux.

Let me try that again:

Which would I rather have:

netconsole never catches my oopses, it's useless. 
 
netconsole didn't work with my driver, but it works with other
drivers just fine.

-- 
Mathematics is the supreme nostalgia of our time.
-
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] sock_sendfile(), generic_file_sendpage() or world without copy_from_user().

2005-09-06 Thread David S. Miller

From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Fri, 2 Sep 2005 18:00:55 +0400

 sock_sendfile() and generic_file_sendpage() were implemented
 and presented in the attached patch.
 Such methods allows to use sendfile() for any file descriptor - file
 descriptor usage, especially usefull it is in the case socket - file,
 when there are no copy_from_user() cases when writing the data.

I do not understand the socket sendfile() implementation, you
seem to just be looping back the data to recvmsg().  How does
this work?
-
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: Netconsole violates dev-hard_start_xmit synch rules

2005-09-06 Thread Eugene Surovegin

On Tue, Sep 06, 2005 at 08:49:35PM -0700, Matt Mackall wrote:
 On Tue, Sep 06, 2005 at 08:37:36PM -0700, Eugene Surovegin wrote:
  On Tue, Sep 06, 2005 at 08:22:25PM -0700, Matt Mackall wrote:
   Which would I rather have:
   
   netconsole never catches my oopses, it's useless. 
   
   netconsole didn't work with my driver, so I tried another card and it
   works great.
  
  Well, not all world which uses Linux is PC with PCI slots. In fact, 
  there are much more non-PC devices (where you have SoC with built-in 
  Ethernet) with Linux than PCs with Linux.
 
 Let me try that again:
 
 Which would I rather have:
 
 netconsole never catches my oopses, it's useless. 
  
 netconsole didn't work with my driver, but it works with other
 drivers just fine.

I'd rather have netconsole which works partially with my driver as 
well.

I don't quite understand, you _already_ have deferred processing in 
netpoll (btw, how good this will work with kgdboe?). If some drivers 
cannot handle *additional* restriction (nowhere documented, btw), ok, 
let's have a fallback mode for them, which you _already_ have.

It's amazing, frankly, you insist that this feature works just fine, 
but fail to realize that this might be just luck (or maybe even not 
true, and hidden bugs are just waiting to be discovered), and some 
future change in any of these drivers may change this situation, 
because, as I said, additional restrictions aren't even documented, 
and driver writer is free to use 
Documentation/networking/netdevices.txt as a guide.

-- 
Eugene

-
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: ieee80211 patches

2005-09-06 Thread James Ketrenos

Jeff Garzik wrote:

 It seems like some of this overlaps changes already in upstream. 
 What's the best way to start this process?  I would prefer to receive
 patches rather than 'git pull' at the present time.

Understood.

 Should I Lindent the files first?

Probably cleanest that way.  I've been passing the net/ieee80211/*.c and
include/net/ieee80211*.h files through the following script:

#!/usr/bin/env bash
scripts/Lindent $@
for file in $@; do
sed -i -e s:\ *\$::g -e s:\t*\$::g $file;
done

I don't know if Lindent strips trailing whitespace, so I stuck the sed
in there for good measure.

 Would you rather just start sending those 50+ patches?

I can pull netdev-2.6#ieee80211 once you have a Lindent'd version and I
can then (hopefully) run my rebase scripts, weeding out dups, and can
then send the patches out.

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] WE-19 for kernel 2.6.13

2005-09-06 Thread Jeff Garzik


Jean Tourrilhes wrote:

@@ -69,11 +69,12 @@
 
 /* INCLUDES */
 
-/* To minimise problems in user space, I might remove those headers

- * at some point. Jean II */
-#include linux/types.h /* for caddr_t et al*/
-#include linux/socket.h/* for struct sockaddr et al
*/
-#include linux/if.h/* for IFNAMSIZ and co... */
+/* Do not put any header in this file, this creates a mess when
+ * exported to user space. Most users have included all the
+ * relevant headers anyway... Jean II */
+/*#include linux/types.h*/ /* for caddr_t et al
*/
+/*#include linux/socket.h*//* for struct sockaddr et al
*/
+/*#include linux/if.h*//* for IFNAMSIZ and co... */



I have reverted this patch, because

* it broke too many drivers

* we don't really care about userspace #include use in include/linux

-
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] optimize pskb_trim_rcsum

2005-09-06 Thread Stephen Hemminger

Since packets almost never contain extra garbage at the end, it is
worthwhile to optimize for that case.

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

Index: csum/include/linux/skbuff.h
===
--- csum.orig/include/linux/skbuff.h2005-08-16 19:59:15.0 -0700
+++ csum/include/linux/skbuff.h 2005-09-06 20:59:42.0 -0700
@@ -1157,7 +1157,7 @@
 
 static inline int pskb_trim_rcsum(struct sk_buff *skb, unsigned int len)
 {
-   if (len = skb-len)
+   if (likely(len = skb-len))
return 0;
if (skb-ip_summed == CHECKSUM_HW)
skb-ip_summed = CHECKSUM_NONE;
-
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] udp: trim forgets about CHECKSUM_HW

2005-09-06 Thread Stephen Hemminger

A UDP packet may contain extra data that needs to be trimmed off.
But when doing so, UDP forgets to fixup the skb checksum if CHECKSUM_HW
is being used.

I think this explains the case of a NFS receive using skge driver
causing 'udp hw checksum failures' when interacting with a crufty
settop box.

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


Index: csum/net/ipv4/udp.c
===
--- csum.orig/net/ipv4/udp.c2005-09-06 20:38:48.0 -0700
+++ csum/net/ipv4/udp.c 2005-09-06 20:40:11.0 -0700
@@ -1140,7 +1140,7 @@
if (ulen  len || ulen  sizeof(*uh))
goto short_packet;
 
-   if (pskb_trim(skb, ulen))
+   if (pskb_trim_rcsum(skb, ulen))
goto short_packet;
 
if (udp_checksum_init(skb, uh, ulen, saddr, daddr)  0)
-
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] ipv6: need to use pskb_trim_rcsum

2005-09-06 Thread Stephen Hemminger

Several places in IPV6 need to use pskb_trim_rcsum to handle
the case of skb's received on devices that set CHECKSUM_HW

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

Index: csum/net/ipv6/exthdrs.c
===
--- csum.orig/net/ipv6/exthdrs.c2005-07-28 21:53:09.0 -0700
+++ csum/net/ipv6/exthdrs.c 2005-09-06 20:57:04.0 -0700
@@ -455,15 +455,11 @@
return 0;
}
 
-   if (pkt_len  skb-len - sizeof(struct ipv6hdr)) {
+   if (pskb_trim_rcsum(skb, pkt_len + sizeof(struct ipv6hdr))) {
IP6_INC_STATS_BH(IPSTATS_MIB_INTRUNCATEDPKTS);
goto drop;
}
-   if (pkt_len + sizeof(struct ipv6hdr)  skb-len) {
-   __pskb_trim(skb, pkt_len + sizeof(struct ipv6hdr));
-   if (skb-ip_summed == CHECKSUM_HW)
-   skb-ip_summed = CHECKSUM_NONE;
-   }
+
return 1;
 
 drop:
Index: csum/net/ipv6/reassembly.c
===
--- csum.orig/net/ipv6/reassembly.c 2005-07-28 21:53:09.0 -0700
+++ csum/net/ipv6/reassembly.c  2005-09-06 20:57:32.0 -0700
@@ -479,12 +479,9 @@
/* Point into the IP datagram 'data' part. */
if (!pskb_pull(skb, (u8 *) (fhdr + 1) - skb-data))
goto err;
-   if (end-offset  skb-len) {
-   if (pskb_trim(skb, end - offset))
-   goto err;
-   if (skb-ip_summed != CHECKSUM_UNNECESSARY)
-   skb-ip_summed = CHECKSUM_NONE;
-   }
+
+   if (pskb_trim_rcsum(skb, end - offset))
+   goto err;
 
/* Find out which fragments are in front and at the back of us
 * in the chain of fragments so far.  We must know where to put
Index: csum/net/ipv6/udp.c
===
--- csum.orig/net/ipv6/udp.c2005-07-28 21:53:09.0 -0700
+++ csum/net/ipv6/udp.c 2005-09-06 20:57:52.0 -0700
@@ -482,13 +482,8 @@
goto discard;
}
 
-   if (ulen  skb-len) {
-   if (__pskb_trim(skb, ulen))
-   goto discard;
-   saddr = skb-nh.ipv6h-saddr;
-   daddr = skb-nh.ipv6h-daddr;
-   uh = skb-h.uh;
-   }
+   if (pskb_trim_rcsum(skb, ulen))
+   goto discard;
 
if (skb-ip_summed==CHECKSUM_HW) {
skb-ip_summed = CHECKSUM_UNNECESSARY;
-
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

[git patches] net driver update

2005-09-06 Thread Jeff Garzik

[just sent this to Andrew/Linus]

Please pull from 'upstream' branch of
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git

to obtain the various updates described below:


 drivers/net/Kconfig   |7 
 drivers/net/Makefile  |2 
 drivers/net/ac3200.c  |2 
 drivers/net/atarilance.c  |2 
 drivers/net/dm9000.c  |2 
 drivers/net/forcedeth.c   |4 
 drivers/net/iseries_veth.c|1 
 drivers/net/s2io-regs.h   |   13 
 drivers/net/s2io.c|   98 -
 drivers/net/s2io.h|5 
 drivers/net/spider_net.c  | 2334 ++
 drivers/net/spider_net.h  |  469 ++
 drivers/net/spider_net_ethtool.c  |  126 +
 drivers/net/sun3lance.c   |2 
 drivers/net/wireless/airo.c   |   43 
 drivers/net/wireless/atmel.c  |   17 
 drivers/net/wireless/ipw2200.c| 2264 ++---
 drivers/net/wireless/ipw2200.h|  408 ++---
 drivers/net/wireless/netwave_cs.c |7 
 drivers/net/wireless/prism54/isl_ioctl.c  |3 
 drivers/net/wireless/prism54/islpci_dev.c |3 
 drivers/net/wireless/ray_cs.c |  858 +--
 drivers/net/wireless/ray_cs.h |7 
 drivers/net/wireless/wl3501.h |1 
 drivers/net/wireless/wl3501_cs.c  |7 
 drivers/s390/net/claw.c   |   20 
 include/linux/pci_ids.h   |1 
 include/linux/wireless.h  |   38 
 include/net/iw_handler.h  |  123 +
 net/core/wireless.c   |   58 
 net/ieee80211/ieee80211_crypt.c   |   27 
 net/ieee80211/ieee80211_crypt_ccmp.c  |   47 
 net/ieee80211/ieee80211_crypt_tkip.c  |  131 -
 net/ieee80211/ieee80211_crypt_wep.c   |   30 
 net/ieee80211/ieee80211_module.c  |   40 
 net/ieee80211/ieee80211_rx.c  |  310 ++-
 net/ieee80211/ieee80211_tx.c  |   66 
 net/ieee80211/ieee80211_wx.c  |   73 
 38 files changed, 5350 insertions(+), 2299 deletions(-)



Al Viro:
  lvalues abuse in lance

Frank Pavlic:
  s390: claw driver fixes

Jean Tourrilhes:
  WE-19 for kernel 2.6.13
  ray_cs : WE-17 support
  iw263_netwave_we17.diff
  atmel_cs : WE-17 support
  wl3501_cs : WE-17 support
  prism54 : WE-17 support
  airo : WE-19 support

Jeff Garzik:
  [wireless] build fixes after merging WE-19
  [wireless ieee80211,ipw2200] Lindent source code


 NOTE: As explained in the full cset description, this Lindent
 will help us sync up Intel, and as a side effect make the code
 look better.


Jens Osterkamp:
  net: add driver for the NIC on Cell Blades
  net: update the spider_net driver
  net: fix bonding with spider_net

Michael Ellerman:
  iseries_veth: Update copyright notice

[EMAIL PROTECTED]:
  S2io: Hardware and miscellaneous fixes

[EMAIL PROTECTED]:
  iomem annotations (ac3200.c)
  missed s/u32/pm_message_t/ (dm9000)
  __user annotations (forcedeth.c)



[patch snipped]

-
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] sock_sendfile(), generic_file_sendpage() or world without copy_from_user().

2005-09-06 Thread Evgeniy Polyakov

On Tue, Sep 06, 2005 at 08:57:57PM -0700, David S. Miller ([EMAIL PROTECTED]) 
wrote:
 From: Evgeniy Polyakov [EMAIL PROTECTED]
 Date: Fri, 2 Sep 2005 18:00:55 +0400

  sock_sendfile() and generic_file_sendpage() were implemented
  and presented in the attached patch.
  Such methods allows to use sendfile() for any file descriptor - file
  descriptor usage, especially usefull it is in the case socket - file,
  when there are no copy_from_user() cases when writing the data.

 I do not understand the socket sendfile() implementation, you
 seem to just be looping back the data to recvmsg().  How does
 this work?

It does recvmsg(), but main purpose was to not copy this into userspace, 
when destination is file descriptor/socket.
It does memcpy() unfortunately, but eliminating such a copy will require
completely new system call, like recvfile(), which will first prepare a
page,  and then doing network receiving into it.

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

74 matches

Mail list logo