[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080617.003832.130616157.davem@davemloft.net>
Date: Tue, 17 Jun 2008 00:38:32 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: mingo@...e.hu
Cc: kuznet@....inr.ac.ru, vgusev@...nvz.org, mcmanus@...ksong.com,
xemul@...nvz.org, netdev@...r.kernel.org,
ilpo.jarvinen@...sinki.fi, linux-kernel@...r.kernel.org
Subject: Re: [TCP]: TCP_DEFER_ACCEPT causes leak sockets
From: Ingo Molnar <mingo@...e.hu>
Date: Tue, 17 Jun 2008 09:26:58 +0200
> So since there's no clear bug pattern and no sure reproducability on my
> side i'd suggest we track this problem separately and "do nothing" right
> now. I've excluded this warning from my 'is the freshly booted kernel
> buggy' list of conditions of -tip testing so it's not holding me up.
I'm going to push the revert through just to be safe and I think it's
a good idea to do so because all of those defer accept changes should
be resubmitted as a group for 2.6.27
> and i can apply any test-patch if that would be helpful - if it does a
> WARN_ON() i'll notice it. (pure extra debug printks with no stack trace
> are much harder to notice in automated tests)
I don't have time to work on your bug, sorry. Someone else will
have to step forward and help you with it.
FWIW I don't think your TX timeout problem has anything to do with
packet ordering. The TX element of the network device is totally
stateless, but it's hanging under some set of circumstances to the
point where we timeout and reset the hardware to get it going again.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists