* why spin_lock_bh() in match routine?
@ 2005-06-30 17:49 Damon Gray
2005-07-01 23:33 ` Tobias DiPasquale
0 siblings, 1 reply; 2+ messages in thread
From: Damon Gray @ 2005-06-30 17:49 UTC (permalink / raw)
To: netfilter-devel
If I'm not mistaken, and I possibly am, the match section of a netfilter
module is run in softirq context, and the same softirq (not tasklet) can
run on a *different* CPU but not the same CPU twice. So why is it being
suggested here that we need to disable bottom halves for match targets.
Seems to me you will be safe with spin_lock() in match() and possibly need
spin_lock_bh() in at least destroy() and maybe in checkentry(). Am I
missing some?
-Damon-
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: why spin_lock_bh() in match routine?
2005-06-30 17:49 why spin_lock_bh() in match routine? Damon Gray
@ 2005-07-01 23:33 ` Tobias DiPasquale
0 siblings, 0 replies; 2+ messages in thread
From: Tobias DiPasquale @ 2005-07-01 23:33 UTC (permalink / raw)
To: Damon Gray; +Cc: netfilter-devel
On 6/30/05, Damon Gray <dgray@internap.com> wrote:
> If I'm not mistaken, and I possibly am, the match section of a netfilter
> module is run in softirq context, and the same softirq (not tasklet) can
> run on a *different* CPU but not the same CPU twice. So why is it being
> suggested here that we need to disable bottom halves for match targets.
> Seems to me you will be safe with spin_lock() in match() and possibly need
> spin_lock_bh() in at least destroy() and maybe in checkentry(). Am I
> missing some?
You wouldn't need to disable BH's in the match() function itself, but
rather in other contexts where the protected data may be accessed.
This serves to prevent the softirq in the process of running the
match() function, from pre-empting another context and deadlocking by
attempting to acquire a lock that is already held.
An example of this kind of mistake would be to use
spin_lock()/unlock() in the match() function to access/modify a
variable x and to ALSO use spin_lock()/unlock() (i.e. NOT disabling
BH's) in a proc file read function to access the same variable x. A
softirq could preempt the proc read function after the lock has been
acquired and cause a deadlock b/c the match() function would be unable
to acquire the lock held by the proc read function and the proc read
function is unable to return to the CPU because it was preempted by a
function that will never return.
--
[ Tobias DiPasquale ]
0x636f6465736c696e67657240676d61696c2e636f6d
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2005-07-01 23:33 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-06-30 17:49 why spin_lock_bh() in match routine? Damon Gray
2005-07-01 23:33 ` Tobias DiPasquale
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.