* is it safe to call spin_lock_bh() from within a soft IRQ? @ 2011-05-26 1:57 ` Jeff Haran 2011-05-26 3:45 ` Mulyadi Santosa 0 siblings, 1 reply; 2+ messages in thread From: Jeff Haran @ 2011-05-26 1:57 UTC (permalink / raw) To: kernelnewbies 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. ^ permalink raw reply [flat|nested] 2+ messages in thread
* is it safe to call spin_lock_bh() from within a soft IRQ? 2011-05-26 1:57 ` is it safe to call spin_lock_bh() from within a soft IRQ? Jeff Haran @ 2011-05-26 3:45 ` Mulyadi Santosa 0 siblings, 0 replies; 2+ messages in thread From: Mulyadi Santosa @ 2011-05-26 3:45 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2011-05-26 3:45 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <AcwbRcmWZS6kjw/RSSeBdYQPJk9zKQ==>
2011-05-26 1:57 ` is it safe to call spin_lock_bh() from within a soft IRQ? Jeff Haran
2011-05-26 3:45 ` Mulyadi Santosa
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).