Andrew Morton | 1 Jan 2007 05:46

Re: [Bugme-new] [Bug 7757] New: ip_conntrack:table full, dropping connection after kernel update

On Sun, 31 Dec 2006 19:03:34 -0800
bugme-daemon <at> bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=7757
> 
>            Summary: ip_conntrack:table full, dropping connection after
>                     kernel update
>     Kernel Version: 2.6.19.1
>             Status: NEW
>           Severity: normal
>              Owner: shemminger <at> osdl.org
>          Submitter: joelol75 <at> verizon.net
> 
> 
> Most recent kernel where this bug did *NOT* occur:2.6.10
> Distribution:Kubuntu
> Hardware Environment:AMD64X2, Geforce6100 North, NForce 430 South, forcedeth driver
> Software Environment:
> Problem Description:dmesg shows above/dead network.  netstat shows piles of
> FIN_WAIT1 connections, using same /proc/sys/net/ipv4 settings
> 
> Steps to reproduce: Update Edgy 2.6.17-10 kernel with vanilla &.1 patch. Turned
> on DMA engine, and nv_sata with k7 (32 bit kernel) optimizations (only changes).
>  Used GTK-gnutella or any p2p that really wrings out the ip stack.  A few hours
> later bandwidth slows to a crawl and only currently open connections are alive.   
> 
> Bring down the network and bringing it back up to clear the tables doesn't
> remove the fin_wait1's.  Any workarounds or maybe a new setting that I
> overlooked that the kernel needs would be greatly appc'd.
> 
(Continue reading)

Daniel Marjamäki | 1 Jan 2007 08:47
Picon

Re: [PATCH] net/core/flow.c: compare data with memcmp

Hello!

So you mean that in this particular case it's faster with a handcoded
comparison than memcmp? Because both key1 and key2 are located at
word-aligned addresses?
That's fascinating.

Best regards,
Daniel

2006/12/31, David Miller <davem <at> davemloft.net>:
> From: "Daniel_Marjamäki" <daniel.marjamaki <at> gmail.com>
> Date: Sun, 31 Dec 2006 17:37:05 +0100
>
> > From: Daniel Marjamäki
> > This has been tested by me.
> > Signed-off-by: Daniel Marjamäki <daniel.marjamaki <at> gmail.com>
>
> Please do not do this.
>
> memcmp() cannot assume the alignment of the source and
> destination buffers and thus will run more slowly than
> that open-coded comparison.
>
> That code was done like that on purpose because it is
> one of the most critical paths in the networking flow
> cache lookup which runs for every IPSEC packet going
> throught the system.
>
-
(Continue reading)

Komuro | 1 Jan 2007 18:18
Favicon

Re: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer


> 
> Can you reproduce it with other ftp client and/or server?

I tried the proftpd-1.3.0a-1.fc6(kernel version is 2.6.19).
The ftp stop problem does not happen.

Therefore, this problem is reproduced when
client's kernel-version is 2.6.20-rc1 or later
and server is vsftpd.
Server's kernel-version is not related with this problem.

The ftp-stop-problem happens on client's PC.

Please advise.

Best Regards
Komuro

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

David Miller | 1 Jan 2007 09:49
Favicon

Re: [PATCH] net/core/flow.c: compare data with memcmp

From: "Daniel_Marjamäki" <daniel.marjamaki <at> gmail.com>
Date: Mon, 1 Jan 2007 08:47:48 +0100

> So you mean that in this particular case it's faster with a handcoded
> comparison than memcmp? Because both key1 and key2 are located at
> word-aligned addresses?
> That's fascinating.

Essentially, yes.

However, I wonder.  GCC should be able to see this also, and
if it expands the memset() inline the code emitted should be
very similar.

It is something to investigate on a few cpu types, for sure.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Daniel Marjamäki | 1 Jan 2007 10:16
Picon

Re: [PATCH] net/core/flow.c: compare data with memcmp

Hello!

I have done a little testing on my own. My results is that memcpy is
many times faster even with aligned data.

I am testing in an ordinary console program. I am including the code below.
If I'm doing something wrong, please tell me so.

As you can see I am not using the same datadeclarations as the kernel
but I'm testing the algorithm here not the data. By testing various
data and types of data I can make sure the algorithm behaves correctly
in all situations.
The datamember 'd' in flowi is not part of the comparison, but by
changing it into an 'unsigned int' it becomes part of the comparison.

const int NUM_REP = 0x7FFFFFFF;

typedef unsigned int flow_compare_t;

struct flowi {
	unsigned int a,b,c;
	unsigned char d;
};

/* I hear what you're saying, use memcmp.  But memcmp cannot make
 * important assumptions that we can here, such as alignment and
 * constant size.
 */
static int flow_key_compare(struct flowi *key1, struct flowi *key2)
{
(Continue reading)

Jan Kiszka | 1 Jan 2007 21:19
Picon

[PATCH] d80211: Reinit keys on mode change

Switching the interface mode with some encryption keys set and then later
touching any key, triggers an oops because ieee80211_if_reinit fails to
NULL'ify the related pointers after free'ing the key on mode change. Long
explanation, simple fix below.

Signed-off-by: Jan Kiszka <jan.kiszka <at> web.de>

[Sorry, yet another rt2x00 CVS patch...]

---
 ieee80211/ieee80211_iface.c |    1 +
 1 file changed, 1 insertion(+)

Index: rt2x00/ieee80211/ieee80211_iface.c
===================================================================
--- rt2x00.orig/ieee80211/ieee80211_iface.c
+++ rt2x00/ieee80211/ieee80211_iface.c
 <at>  <at>  -231,6 +231,7  <at>  <at>  void ieee80211_if_reinit(struct net_devi
 					    local->keys[i], 0);
 #endif
 		ieee80211_key_free(sdata->keys[i]);
+		sdata->keys[i] = NULL;
 	}

 	/* Shouldn't be necessary but won't hurt */

Jan Kiszka | 1 Jan 2007 21:19
Picon

[PATCH] d80211: Fix inconsistent sta_lock usage

Hacking a bit on rt2x00 to make it work in master and ad-hoc mode, lockdep
popped up on some hostapd ioctls, pointing out remaining inconsistencies
related to sta_lock:

1. sta_lock holders must always be protected against softirq
2. bss_tim_set/clear must not be called with sta_lock held, rather an
   unprotected variant
3. ieee80211_ioctl_remove_sta is not already holding the lock when calling
   sta_info_free

As I was not sure if sta_info_remove_aid_ptr needs lock protection or
not, I played safe and moved it always under the lock. Please correct me
if this is overkill.

Signed-off-by: Jan Kiszka <jan.kiszka <at> web.de>

[Sorry, patch is against rt2x00 CVS. I'm lacking time and bandwidth to pull
the d80211 git repos and rebase.]

---
 ieee80211/ieee80211_i.h     |   24 ++++++++++++++++++------
 ieee80211/ieee80211_ioctl.c |    4 +++-
 ieee80211/sta_info.c        |    2 +-
 3 files changed, 22 insertions(+), 8 deletions(-)

Index: rt2x00/ieee80211/ieee80211_ioctl.c
===================================================================
--- rt2x00.orig/ieee80211/ieee80211_ioctl.c
+++ rt2x00/ieee80211/ieee80211_ioctl.c
 <at>  <at>  -286,7 +286,9  <at>  <at>  static int ieee80211_ioctl_add_sta(struc
(Continue reading)

Mariusz Kozlowski | 2 Jan 2007 00:55
Picon

[PATCH] net: ifb error path loop fix

Hello,

	On error we should start freeing resources at [i-1] not [i-2].

Signed-off-by: Mariusz Kozlowski <m.kozlowski <at> tuxland.pl>

 drivers/net/ifb.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff -upr linux-2.6.20-rc2-mm1-a/drivers/net/ifb.c linux-2.6.20-rc2-mm1-b/drivers/net/ifb.c
--- linux-2.6.20-rc2-mm1-a/drivers/net/ifb.c	2006-12-24 05:00:32.000000000 +0100
+++ linux-2.6.20-rc2-mm1-b/drivers/net/ifb.c	2007-01-02 00:25:34.000000000 +0100
 <at>  <at>  -271,8 +271,7  <at>  <at>  static int __init ifb_init_module(void)
 	for (i = 0; i < numifbs && !err; i++)
 		err = ifb_init_one(i);
 	if (err) {
-		i--;
-		while (--i >= 0)
+		while (i--)
 			ifb_free_one(i);
 	}

--

-- 
Regards,

	Mariusz Kozlowski
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Herbert Xu | 2 Jan 2007 03:23
Picon
Picon

Re: [git patches] net driver fixes

Jeff Garzik <jeff <at> garzik.org> wrote:
> 
>      e1000: Do not truncate TSO TCP header with 82544 workaround

This change obsoletes the following change.

>      e1000: disable TSO on the 82544 with slab debugging

So the slab debugging patch should be reverted.

Thanks,
--

-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert <at> gondor.apana.org.au>
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 majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

David Miller | 2 Jan 2007 04:39
Favicon

Re: [patch] ifb double-counts packets

From: dean gaudet <dean <at> arctic.org>
Date: Sat, 23 Dec 2006 13:58:24 -0800 (PST)

> On Sat, 23 Dec 2006, jamal wrote:
> 
> > On Sat, 2006-23-12 at 02:35 -0800, dean gaudet wrote:
> > > it seems that ifb counts packets twice... both at xmit time and also in 
> > > the tasklet.  i'm not sure which one of the two to drop, but here's a 
> > > patch for dropping the counting at xmit time.
> > 
> > Good catch but not quite right. The correct way to do it is to increment
> > the rx_ counters instead of tx_ right at the top of  ifb_xmit().
> > 
> > Do you wanna resubmit your patch with these chmages and hopefully tested
> > for your situation?
> 
> heh yeah that makes more sense :)
> 
> -dean
> 
> Signed-off-by: dean gaudet <dean <at> arctic.org>

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


Gmane