On 11/10/2011 04:00 PM, Jeff Haran wrote: >> -----Original Message----- >> From: kernelnewbies-bounces@xxxxxxxxxxxxxxxxx [mailto:kernelnewbies- >> bounces@xxxxxxxxxxxxxxxxx] On Behalf Of Kai Meyer >> Sent: Thursday, November 10, 2011 1:55 PM >> To: kernelnewbies@xxxxxxxxxxxxxxxxx >> Subject: Re: Spinlocks and interrupts >> >> 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 >>> > Kai, you might want to try bottom posting. It is the standard on these > lists. It makes it easier for others to follow the thread. > > I know of no kernel call that you can make to test for current execution > context. There are the in_irq(), in_interrupt() and in_softirq() macros > in hardirq.h, but when I've looked at the code that implements them I've > come to the conclusion that they sometimes will lie. in_softirq() > returns non-zero if you are in a software IRQ. Fair enough. But based on > my reading in the past it's looked to me like it will also return > non-zero if you've disabled bottom halves from process context with say > a call to spin_lock_bh(). > > It would be nice if there were some way of asking the kernel what > context you are in, for debugging if for no other reason, but if it's > there I haven't found it. > > I'd love to be proven wrong here, BTW. If others know better, please > enlighten me. > > Jeff Haran > > > > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies@xxxxxxxxxxxxxxxxx > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies I try to remember to bottom post on message lists, but obviously I've been negligent :) Perhaps I'll just add some calls to msleep() at various places to help me identify when portions of my code are in an atomic context, just to help me learn what's going on. -Kai Meyer _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
