All of lore.kernel.org
 help / color / mirror / Atom feed
* [BUG] Netfilter ipt_owner deadlock
@ 2004-05-17  7:02 Harald Welte
  2004-05-17 21:55 ` Patrick McHardy
  0 siblings, 1 reply; 2+ messages in thread
From: Harald Welte @ 2004-05-17  7:02 UTC (permalink / raw)
  To: Netfilter Development Mailinglist


[-- Attachment #1.1: Type: text/plain, Size: 373 bytes --]


-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #1.2: Type: message/rfc822, Size: 3022 bytes --]

From: Christophe Saout <christophe@saout.de>
To: linux-net@vger.kernel.org
Subject: [BUG] Netfilter ipt_owner deadlock
Date: Fri, 14 May 2004 17:19:05 +0200
Message-ID: <1084547945.16207.5.camel@leto.cs.pocnet.net>

Hi,

there's a nasty problem with the ipt_owner netfilter code:

It does a spin_lock(&files->file_lock), sometimes from softirq context.
This can lead to deadlocks on SMP systems. The lock must not be taken
from softirq context because the rest of the kernel doesn't use
spin_lock_bh.

On a UP machine (that had an SMP compiled kernel) the machine repeatedly
locked up after approx. five minutes. SysRQ shows backtraces like fput
-> timer interrupt -> softirq -> ipv4 -> netfilter -> ipt_owner -> hang.

I don't see a clean solution for this (except for changing all the
spin_locks to spin_lock_bhs which I think is way too aggressive).

Any ideas?


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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [BUG] Netfilter ipt_owner deadlock
  2004-05-17  7:02 [BUG] Netfilter ipt_owner deadlock Harald Welte
@ 2004-05-17 21:55 ` Patrick McHardy
  0 siblings, 0 replies; 2+ messages in thread
From: Patrick McHardy @ 2004-05-17 21:55 UTC (permalink / raw)
  To: Harald Welte; +Cc: Netfilter Development Mailinglist

Unfortunately I also can't think of a solution except
for marking it broken on SMP ;(

Regards
Patrick

Harald Welte wrote:
> 
> ------------------------------------------------------------------------
> 
> Subject:
> [BUG] Netfilter ipt_owner deadlock
> From:
> Christophe Saout <christophe@saout.de>
> Date:
> Fri, 14 May 2004 17:19:05 +0200
> To:
> linux-net@vger.kernel.org
> 
> To:
> linux-net@vger.kernel.org
> 
> 
> Hi,
> 
> there's a nasty problem with the ipt_owner netfilter code:
> 
> It does a spin_lock(&files->file_lock), sometimes from softirq context.
> This can lead to deadlocks on SMP systems. The lock must not be taken
> from softirq context because the rest of the kernel doesn't use
> spin_lock_bh.
> 
> On a UP machine (that had an SMP compiled kernel) the machine repeatedly
> locked up after approx. five minutes. SysRQ shows backtraces like fput
> -> timer interrupt -> softirq -> ipv4 -> netfilter -> ipt_owner -> hang.
> 
> I don't see a clean solution for this (except for changing all the
> spin_locks to spin_lock_bhs which I think is way too aggressive).
> 
> Any ideas?
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-net" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2004-05-17 21:55 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-05-17  7:02 [BUG] Netfilter ipt_owner deadlock Harald Welte
2004-05-17 21:55 ` Patrick McHardy

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.