* Recursive deactivation of local bottom halves
@ 2011-01-25 13:05 Emil Langrock
2011-01-25 13:42 ` Thomas Gleixner
2011-01-26 6:20 ` WANG Cong
0 siblings, 2 replies; 3+ messages in thread
From: Emil Langrock @ 2011-01-25 13:05 UTC (permalink / raw)
To: linux-kernel
Cc: Ingo Molnar, Thomas Gleixner, Peter Zijlstra, Andrew Morton,
Venkatesh Pallipadi
Hi,
I wanted or more or less had to do following:
...
spin_lock_bh(lock1);
....
spin_lock_bh(lock2);
...
spin_unlock_bh(lock2);
....
spin_unlock_bh(lock1);
....
Now some weird behavior were noticed by a second person and he fixed it by
removing the _bh from the inner spinlocks. I checked what the difference is
and here is the previous example without the common spin_lock behaviour:
...
local_bh_disable();
....
local_bh_disable();
...
local_bh_enable();
....
local_bh_enable();
....
According to http://people.netfilter.org/rusty/unreliable-guides/kernel-
hacking/routines-softirqs.html it makes no difference how often I use the pair
local_bh_disable/local_bh_enable inside local_bh_disable/local_bh_enable. So
was this changed?
I also couldn't find any indication in the kernel/softirq.c in the
local_bh_enable functionality that the counting in local_bh_disable makes any
difference.
Can somebody tell me if that is legal or not (on smp and uniprocessor)? And
maybe can show me the related source code why is it may or may not be legal?
Kind regards,
Emil
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Recursive deactivation of local bottom halves
2011-01-25 13:05 Recursive deactivation of local bottom halves Emil Langrock
@ 2011-01-25 13:42 ` Thomas Gleixner
2011-01-26 6:20 ` WANG Cong
1 sibling, 0 replies; 3+ messages in thread
From: Thomas Gleixner @ 2011-01-25 13:42 UTC (permalink / raw)
To: Emil Langrock
Cc: linux-kernel, Ingo Molnar, Peter Zijlstra, Andrew Morton,
Venkatesh Pallipadi
On Tue, 25 Jan 2011, Emil Langrock wrote:
> I wanted or more or less had to do following:
>
> ...
> spin_lock_bh(lock1);
> ....
> spin_lock_bh(lock2);
> ...
> spin_unlock_bh(lock2);
> ....
> spin_unlock_bh(lock1);
> ....
>
> Now some weird behavior were noticed by a second person and he fixed it by
> removing the _bh from the inner spinlocks. I checked what the difference is
You're not telling us what kind of weird behaviour was observed and
why the "fix" made it go away. You neither showed the real code and
the "fix", so there is no way to tell what problem you're facing. What
I can tell w/o using a crystal ball is that the "fix" stinks.
> According to http://people.netfilter.org/rusty/unreliable-guides/kernel-
> hacking/routines-softirqs.html it makes no difference how often I use the pair
> local_bh_disable/local_bh_enable inside local_bh_disable/local_bh_enable. So
> was this changed?
Nope.
> Can somebody tell me if that is legal or not (on smp and uniprocessor)? And
> maybe can show me the related source code why is it may or may not be legal?
IANAL, so I can't tell you for sure whether it's legal or not. Though
I'd say it's legal in your jurisdiction. :)
There is no restriction on nesting local_bh_disable/enable as long as
you don't overflow the field width, which is 8 bits and therefor
supports 255 nest levels.
Thanks,
tglx
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Recursive deactivation of local bottom halves
2011-01-25 13:05 Recursive deactivation of local bottom halves Emil Langrock
2011-01-25 13:42 ` Thomas Gleixner
@ 2011-01-26 6:20 ` WANG Cong
1 sibling, 0 replies; 3+ messages in thread
From: WANG Cong @ 2011-01-26 6:20 UTC (permalink / raw)
To: linux-kernel
On Tue, 25 Jan 2011 14:05:14 +0100, Emil Langrock wrote:
...
> ...
> local_bh_disable();
> ....
> local_bh_disable();
> ...
> local_bh_enable();
> ....
> local_bh_enable();
> ....
...
>
> Can somebody tell me if that is legal or not (on smp and uniprocessor)?
> And maybe can show me the related source code why is it may or may not
> be legal?
>
>From what you show to us, it is legal, as long as local_bh_disable()/
local_bh_enable() are always paired, it is fine to call them nestedly.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-01-26 6:20 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-01-25 13:05 Recursive deactivation of local bottom halves Emil Langrock
2011-01-25 13:42 ` Thomas Gleixner
2011-01-26 6:20 ` WANG Cong
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).