Alright, to summarize, for my benefit mostly, I'm writing a block device driver, which has 2 entry points into my code that will reach this critical section. It's either the make request function for the block device, or the resulting bio->bi_end_io function. I do some waiting with msleep() (for now) from the make request function entry point, so I'm confident that entry point is not in an atomic context. I also only end up requesting the critical section to call kmalloc from this context, which is why I never ran into the scheduling while atomic issue before. I'm fairly certain the critical section executes in thread context not interrupt context from either entry point. I'm certain that the spinlock_t is only ever used in one function (a I posted a simplified version of the critical section earlier). It seems that the critical section is often called in an atomic context. The spin_lock function sounds like it will only cause a second call to spin_lock to spin if it is called on a separate core. But, since I'm certain the critical section is never called from interrupt context, only thread context, the fact that pre-emption is disabled on the core should provide the protection I need with out having to disable IRQs. Disabling IRQs would prevent an interrupt from occurring while the lock is acquired. I would like to avoid disabling interrupts if I don't need to. So it sounds like spin_lock/spin_unlock is the correct choice? In addition, I'd like to be more confident in my assumptions above. Can I test for atomic context? For instance, I know that you can call irqs_disabled(), is there a similar is_atomic() function I can call? I would like to put a few calls in different places to learn what sort of context I'm. -Kai Meyer On 11/10/2011 12:19 PM, Jeff Haran wrote: >> -----Original Message----- >> From: kernelnewbies-bounces+jharan=bytemobile.com@xxxxxxxxxxxxxxxxx >> [mailto:kernelnewbies- >> bounces+jharan=bytemobile.com@xxxxxxxxxxxxxxxxx] On Behalf Of Dave >> Hylands >> Sent: Thursday, November 10, 2011 11:07 AM >> To: Kai Meyer >> Cc: kernelnewbies@xxxxxxxxxxxxxxxxx >> Subject: Re: Spinlocks and interrupts >> >> Hi Kai, >> >> On Thu, Nov 10, 2011 at 10:14 AM, Kai Meyer<kai@xxxxxxxxxx> wrote: >>> I think I get it. I'm hitting the scheduling while atomic because > I'm >>> calling my function from a struct bio's endio function, which is >>> probably running with a lock held somewhere else, and then my mutex >>> sleeps, while the spin_lock functions do not sleep. >> Actually, just holding a lock doesn't create an atomic context. > I believe on kernels with kernel pre-emption enabled the act of taking > the lock disables pre-emption. If it didn't work this way you could end > up taking the lock in one process context and while the lock was held > get pre-empted. Then another process tries to take the lock and you dead > lock. > > Jeff Haran > > > > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies@xxxxxxxxxxxxxxxxx > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
