ESP does not account for the IV size when calling pskb_may_pull() to ensure everything it accesses directly is within the linear part of a potential fragment. This results in a BUG() being triggered when the both the IPv4 and IPv6 ESP stack is fed with an skb where the first fragment ends between the end of the esp header and the end of the IV. This bug was found by Dirk Nehring <dnehring@gmx.net> . Signed-off-by: Thomas Graf <tgraf@suug.ch> Index: net-2.6/net/ipv4/esp4.c =========...

Vlastislav SUCHARDA <vsucharda@aplis.cz> : (back to list as it may be of general interest) Try http://userweb.kernel.org/~romieu/r8169/2.6.18/stable-4/to-2.6.24/ It contains a patch for the r8169 driver which should apply to your 2.6.18.4 based kernel and turn its r8169 driver into something closer to 2.6.24. The kit contains a stack of incremental patches too if you are curious. I have fixed some rejects, checked that everything compiles at each step but the patch is otherwise unteste...

Dave, Here is another quick round of patches intended for 2.6.26. Included are libertas and iwlwifi updates, including the long-awaited LED support for the iwlwifi drivers. Also included is the fix for the ieee80211_get_channel symbol conflict currently in the net-2.6.26 tree. Please let me know if there are problems! Thanks, John --- Individual patches are available here: http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6.26/ --- The following changes since...

A week ago I updated one of my servers to 2.6.25-rc6 and today looking through logs I've found these: [380219.823434] ------------[ cut here ]------------ [380219.823450] WARNING: at net/ipv4/tcp_input.c:2510 tcp_ack+0xc7e/0x177d() [380219.823463] Pid: 0, comm: swapper Not tainted 2.6.25-rc6-dirty #1 [380219.823477] [<c0118cee>] warn_on_slowpath+0x3b/0x4a [380219.823494] [<c0205f66>] boomerang_rx+0x346/0x371 [380219.823517] [<c0206fa2>] boomerang_interrupt+0x288/0x2c0 [380219....

Then try to lower gc_elasticity, to 3, or even 2 echo 3 >/proc/sys/net/ipv4/route/gc_elasticity --

Very interesting... you can see 101588 dst are *delayed* in dst_garbage, but apparently never freed. Something is wrong, but the count seems stable. Must be some kind of event, admin driven or something... might be the "ip route flush cache" that is schedlued around 600 seconds of machine alive, then secret_interval seconds later... Typically, when a "ip route flush cache" is done (manually or triggered by secret_interval timer), refcounted>0 entries are put into dst_garbage. Then whe...

could you check the patch sent yesterday by Pavel under the name [PATCH][ICMP]: Dst entry leak in icmp_send host re-lookup code (v2). It can fit the case, massive DST leakage is possible here. Regards, Den --

The PowerPC 440GX Taishan board fails to reset EMAC3 (reset timeout error) if there's no link. Because of that it fails to find PHY chip. The older ibm_emac driver had a workaround for that: the EMAC_CLK_INTERNAL/EMAC_CLK_EXTERNAL macros, which toggle the Ethernet Clock Select bit in the SDR0_MFR register. This patch does the same for "ibm,emac-440gx" compatible chips. The workaround forces clock on -all- EMACs, so we select clock under global emac_phy_map_lock. Signed-off-by: Valentine Barshak <...

Move the "&& skb->ip_summed == CHECKSUM_PARTIAL" part out of emac_has_feature parameters. Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com> --- drivers/net/ibm_newemac/core.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff -pruN linux-2.6.orig/drivers/net/ibm_newemac/core.c linux-2.6/drivers/net/ibm_newemac/core.c --- linux-2.6.orig/drivers/net/ibm_newemac/core.c 2008-02-21 16:45:36.000000000 +0300 +++ linux-2.6/drivers/net/ibm_newemac/core.c 2008-02-...

linux-2.6/drivers/net/fec.c: In function 'fec_enet_module_init': linux-2.6/drivers/net/fec.c:2627: warning: unused variable 'j' linux-2.6/drivers/net/fec.c: At top level: linux-2.6/drivers/net/fec.c:2136: warning: 'mii_link_interrupt' defined but not used Signed-off-by: Sebastian Siewior <bigeasy@linutronix.de> --- a/drivers/net/fec.c +++ b/drivers/net/fec.c @@ -67,6 +67,11 @@ #define FEC_MAX_PORTS 1 #endif +#if defined(CONFIG_M523x) || defined(CONFIG_M527x) || defined(CONFIG_M528x) |...

Hello, Dave! Here is a small set of changes to simplify udp_proc_register. It seems to difficult for me. Let's simplify it a bit. Regards, Den --

No need to create seq_operations for each instance of 'netstat'. Signed-off-by: Denis V. Lunev <den@openvz.org> --- include/net/udp.h | 3 +-- net/ipv4/udp.c | 14 ++++++++------ net/ipv4/udplite.c | 4 +++- net/ipv6/udp.c | 4 +++- net/ipv6/udplite.c | 4 +++- 5 files changed, 18 insertions(+), 11 deletions(-) diff --git a/include/net/udp.h b/include/net/udp.h index 77af7d4..0079d17 100644 --- a/include/net/udp.h +++ b/include/net/udp.h @@ -189,8 +189,8 @@ str...

udp_proc_register/udp_proc_unregister are called with a static pointer only. Signed-off-by: Denis V. Lunev <den@openvz.org> --- net/ipv4/udp.c | 4 ---- 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c index 6d740ad..c05f45b 100644 --- a/net/ipv4/udp.c +++ b/net/ipv4/udp.c @@ -1631,8 +1631,6 @@ int udp_proc_register(struct net *net, struct udp_seq_afinfo *afinfo) struct proc_dir_entry *p; int rc = 0; - if (!afinfo) - return -EIN...

Move it to udp_seq_afinfo->seq_fops as should be. Signed-off-by: Denis V. Lunev <den@openvz.org> --- include/net/udp.h | 1 - net/ipv4/udp.c | 5 +++-- net/ipv4/udplite.c | 4 +++- net/ipv6/udp.c | 4 +++- net/ipv6/udplite.c | 4 +++- 5 files changed, 12 insertions(+), 6 deletions(-) diff --git a/include/net/udp.h b/include/net/udp.h index 5cf0e59..24a41fa 100644 --- a/include/net/udp.h +++ b/include/net/udp.h @@ -185,7 +185,6 @@ DECLARE_SNMP_STAT(struct ud...

Hi. A little while ago I posted a patch to fix the communication problem when bonding was used in active-backup mode with arp monitoring on Xen guest OS. http://marc.info/?l=linux-netdev&m=119362063924723&w=2 I have rebased the patch to the latest 2.6.25-rc7 kernel. I've confirmed that active-backup mode works fine with arp monitoring with this patch. Thanks. -- Tsutomu fujii --- a/drivers/net/bonding/bond_main.c 2008-03-26 10:38:14.000000000 +0900 +++ b/drivers/net/bonding...

Allyesconfig (v2.6.24-mm1): ~500 files changed ... 869 funcs, 198 +, 111003 -, diff: -110805 --- skb_put skb_put | +104 Without number of debug related CONFIGs (v2.6.25-rc2-mm1): -60744 855 funcs, 861 +, 61605 -, diff: -60744 --- skb_put skb_put | +57 Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> --- include/linux/skbuff.h | 21 +-------------------- net/core/skbuff.c | 21 +++++++++++++++++++++ 2 files change...

From: Joe Perches <joe@perches.com> I severely doubt this, the bulk of the overhead of skb_put() is the atomic operation, not whether the instructions get executed inline or not. Please run some tests before making claims like this. I might give you some slack in this area if you've been doing networking performance tuning for 10+ years but you haven't. --

Allyesconfig (v2.6.24-mm1): -23668 392 funcs, 104 +, 23772 -, diff: -23668 --- dev_alloc_skb Without many debug CONFIGs (v2.6.25-rc2-mm1): -12178 382 funcs, 157 +, 12335 -, diff: -12178 --- dev_alloc_skb dev_alloc_skb | +37 Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> --- include/linux/skbuff.h | 17 +---------------- net/core/skbuff.c | 18 ++++++++++++++++++ 2 files changed, 19 insertions(+), 16 deletions(-) diff --git a/include/linux/skb...

Allyesconfig (v2.6.24-mm1): -21593 356 funcs, 2418 +, 24011 -, diff: -21593 --- skb_push Without many debug related CONFIGs (v2.6.25-rc2-mm1): -13890 341 funcs, 189 +, 14079 -, diff: -13890 --- skb_push skb_push | +46 Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> --- include/linux/skbuff.h | 19 +------------------ net/core/skbuff.c | 19 +++++++++++++++++++ 2 files changed, 20 insertions(+), 18 deletions(-) diff --git a/include/linux/s...

Allyesconfig (v2.6.24-mm1): -10976 209 funcs, 123 +, 11099 -, diff: -10976 --- skb_trim Without number of debug related CONFIGs (v2.6.25-rc2-mm1): -7360 192 funcs, 131 +, 7491 -, diff: -7360 --- skb_trim skb_trim | +42 Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> --- include/linux/skbuff.h | 16 +--------------- net/core/skbuff.c | 16 ++++++++++++++++ 2 files changed, 17 insertions(+), 15 deletions(-) diff --git a/include/linux/skbuff.h b...

This patch is a revive of the patch I posted half a year ago. In that time Thomas Graf (who was acting as maintainer of genetlink module) accepted the idea, but suggested to do it using RCU lists. Since I did not have and experience with RCU lists, we agreed, he will implement it himself. Since that time, he neither did it, nor replied to my recent emails and I guess he is no longer active. I am asking, whomever maintains genetlink right now, for including this patch. (Currently, this is patch to...

Why do you believe that the socket is hashed? That socket is only allocated and referenced. It's should not be in any hash tables since we hold a global reference on it. -vlad --

Ahhh... ;-) struct proto sctp_prot = { ... .hash = sctp_hash, ... } static void sctp_hash(struct sock *sk) { /* STUB */ } SCTP currently does't do any hashing on the sockets. It hashes SCTP structures that live under the socket. Regards -vlad --

That's fine. My one concern is that someone may erroneously interpret that SCTP sockets are derived from inet_connection_sock, but I can live with that. -vlad --

Under CONFIG_DCA the compilation is broken since the commit bd0362dde080cef377d99fa5beb5c25308c29c73 (ixgbe: Add optional DCA infrastructure). IXGBE_SUCCESS is not defined anywhere, replace it with 0. Signed-off-by: Denis V. Lunev <den@openvz.org> --- drivers/net/ixgbe/ixgbe_main.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c index 7ad2993..cb371a8 100644 --- a/drivers/net/ixgbe/ixgbe_main....