| To: | laforge@xxxxxxxxxxxxx |
|---|---|
| Subject: | Re: [PATCH 2.6] fix deadlock with ip_queue and tcp local input path |
| From: | "David S. Miller" <davem@xxxxxxxxxxxxx> |
| Date: | Thu, 26 May 2005 14:01:57 -0700 (PDT) |
| Cc: | netfilter-devel@xxxxxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx |
| In-reply-to: | <20050526205831.GL13114@sunbeam.de.gnumonks.org> |
| References: | <20050526142420.GD13114@sunbeam.de.gnumonks.org> <20050526.135229.111208218.davem@davemloft.net> <20050526205831.GL13114@sunbeam.de.gnumonks.org> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
From: Harald Welte <laforge@xxxxxxxxxxxxx> Subject: Re: [PATCH 2.6] fix deadlock with ip_queue and tcp local input path Date: Thu, 26 May 2005 22:58:31 +0200 > On Thu, May 26, 2005 at 01:52:29PM -0700, David S. Miller wrote: > > > > Dave: Please don't apply yet, I want to receive feedback from the > > > netfilter developers first. I'm just Cc'ing netdev in case somebody > > > wants an intermediate fix to fix the problem. > > > > OK. > > Do you have any feedback on why or how bh_lock_sock() might be called in > the problem I've described? I think it has to be a different skb for > the same socket. When we hit a listening socket, and hung off of that listening socket we find a child socket, we bh_lock_sock() the child socket then process the SKB against it instead of the listening socket. Is this the kind of scenerio you are concerned about? |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH 2.6] fix deadlock with ip_queue and tcp local input path, Harald Welte |
|---|---|
| Next by Date: | Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4, Herbert Xu |
| Previous by Thread: | Re: [PATCH 2.6] fix deadlock with ip_queue and tcp local input path, Harald Welte |
| Next by Thread: | Re: [PATCH 2.6] fix deadlock with ip_queue and tcp local input path, Herbert Xu |
| Indexes: | [Date] [Thread] [Top] [All Lists] |