On Thu, 03 Jul 2008, Zhu Yi wrote: > On Wed, 2008-07-02 at 22:53 -0300, Henrique de Moraes Holschuh wrote: > > Hmm, it could cause deadlocks I think. task context takes lock. > > interrupt context tries to run, needs lock, keeps spinning forever > > waiting for it, and if we are not SMP, task context never has a chance > > to release the lock, so we get a deadlock. Is this correct? > > Never heard of spin_lock_irqsave()? Studying it now... I did say I was not the right person for the job because I am still learning all the locks we have :-) > > If it is, we better make the atomic path lock-free. Argh. This means > > rfkill->state (the only thing we care about in the atomic path) would > > have to become an atomic variable, and the code changed to cope with > > its value being "volatile", so that it can be used in a lockless > > fashion. > > Yup, if protecting rfkill->state is the only intention, a spinlock is > too heavy. set|clear_bit is enough if organizing the state into bitmaps. > BTW, read/write 32-bits aligned on x86 is already atomic. I know rfkill->state is already atomic on x86, and I think it is also atomic on every other platform Linux supports (I need to check this, since I am not sure). However, explicitly making it atomic_t is a damn heavy hint to anyone using rfkill about how to deal with rfkill->state, and that can be a big advantage. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
