is it safe to call spin_lock_bh() from within a soft IRQ?

is it safe to call spin_lock_bh() from within a soft IRQ?

[Jeff Haran]

My understanding is that if you have a critical data structure that is
accessed in both process context and soft IRQ context on an SMP system,
you can serialize access to it by using a spin lock.

I also understand that to acquire such a spin lock from process context,
you should use spin_lock_bh() because that will disable bottom halves on
that CPU and thus prevent a dead lock that could otherwise occur if your
process context code took the lock and then a software IRQ was run which
attempt to acquire the same lock.

What I have yet to find in the available documentation is whether in
this scenario it would be safe to call spin_lock_bh() to acquire the
lock from code that executes in soft IRQ context.

I suspect such a practice is not advisable because it's not strictly
necessary. Calling spin_lock() from the soft IRQ context code and
calling spin_lock_bh() from the process context code would be most
efficient because there is no need to disable bottom halves if you are
already executing in soft IRQ context.

But the inefficiency issue aside, can calling spin_lock_bh() from soft
IRQ context cause other more serious problems like lock ups, data
corruption, etc?

The reason for the question is I am working on a kernel module that
needs to take the same lock from both process and soft IRQ context and
for the sake of modularity and simplicity I'd like to be able to use the
same wrapper function to take the spin lock regardless of what context
the code calling that function is executing in and am, at least for now,
willing to accept a slight loss of performance due to disabling bottom
halves when doing so is not strictly necessary.

A corollary question would relate to taking read-write locks. Is it safe
to call read_lock_bh() or write_lock_bh() from a soft IRQ?

Thanks.

is it safe to call spin_lock_bh() from within a soft IRQ?

[Mulyadi Santosa]

Hi...

On 26/05/2011, Jeff Haran <jharan@bytemobile.com> wrote:
> What I have yet to find in the available documentation is whether in
> this scenario it would be safe to call spin_lock_bh() to acquire the
> lock from code that executes in soft IRQ context.

lxr tells me that eventually spin_lock_bh() will call:
static inline void __raw_spin_lock_bh(raw_spinlock_t *lock)
{
        local_bh_disable();
        preempt_disable();
        spin_acquire(&lock->dep_map, 0, 0, _RET_IP_);
        LOCK_CONTENDED(lock, do_raw_spin_trylock, do_raw_spin_lock);
}

seems nothing dangerous if you do it inside soft IRQ, but the question
is "do you absolutely need such locking?"

because , again, lock contention is soft irq IMHO is a big no. You
will likely put all the soft IRQs in queue, thus it might decrease
interactivity, perfomance, throughput and so on. Not to mention, to
some degree, process switching is delayed too.

So unless you could do microbenchmarking and absolutely sure the
effect is negligible, I suggest don't do it.

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com