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