Hi! On 20:53 Wed 18 Aug , Daniel Baluta wrote: > Hello, > On Wed, Aug 18, 2010 at 8:07 PM, Parmenides <mobile.parmenides@xxxxxxxxx> wrote: > > Hi, > > > > For a critical section protected by a spin lock, kernel preemption is > > disabled explicitly, probably to make the critical section atomic. > > But, suppose that an interrupt occures in this critical section, > > allowing interrupts can wreck the atomicity. So, why don't we disable > > interrupts as a critical section is executing? > > Remember that you always must protect the data, and not the code. > > If your data is never accessed from interrupt handlers, then spin_lock > is just enough. No, it is not. On singe CPU systems spin_lock is optimised away, so you need to disable interrupts to get atomic behaviour. On multi processor systems, spin_lock will spin until the lock is freed. If this is done with interrupts disabled, the process which holds the lock might not be able to run at all, causing hard lockup. > If instead, you access your data, both from interrupt and > process context than you should use spin_lock_irqsave ([1]). You should *always* use spin_lock_irqsave, except you know that you already are running with interrupts disabled. In this case do not not need to disable them again and spin_lock is enough. -Michi -- programing a layer 3+4 network protocol for mesh networks see http://michaelblizek.twilightparadox.com -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
