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. _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
