Hi Rajat, On Thu, Jan 6, 2011 at 11:35 PM, Rajat Sharma <fs.rajat@xxxxxxxxx> wrote: > As I remember timer interrupt as well is an NMI so, it is possible (although > not advised) to call schedule function while holding spinlock on same core. > > spin_lock_irqsave(); > schedule(); > spin_lock_irqrestore(); You're not supposed to call schedule with interrupts disbled. If you follow the code though schedule, you'll see that it calls schedule_debug, which in turns checks to see if its being called from an atomic context and if it is, it will cause the BUG: scheduling while atomic: message along with a stack dump. > > however if you have debugging options turned on like CONFIG_DEBUG_SPINLOCK, > you may likely get kernel warning for 'scheduling in atomic context'. > > Then what can happen if this core is allowed to switched to new process? > Consider the case where new process as well tries to aquire same spin_lock() > which new process can not aquire and start spinning for the lock for ever > :). Likewise, other cores will also get locked down. > > However stil you can detect softlockup through NMI watchdog. > > Rajat > > On Fri, Jan 7, 2011 at 12:32 PM, Tirtha Ghosh <gtirtha@xxxxxxxxx> wrote: >> >> NMI has greater priority over spinlock, cause this is non maskable and NMI >> watchdog can be used for debugging spinlock deadlocks >> (CONFIG_DEBUG_SPINLOCK). >> >> So we will hit NMI watchdog even if spinlock is acquired. >> >> >> >> On Fri, Jan 7, 2011 at 11:57 AM, Tayade, Nilesh >> <Nilesh.Tayade@xxxxxxxxxxxx> wrote: >>> >>> Hi, >>> >>> > -----Original Message----- >>> > From: kernelnewbies-bounces@xxxxxxxxxxxxxxxxx [mailto:kernelnewbies- >>> > bounces@xxxxxxxxxxxxxxxxx] On Behalf Of Dave Hylands >>> > Sent: Friday, January 07, 2011 10:59 AM >>> > To: Viral Mehta >>> > Cc: kernelnewbies@xxxxxxxxxxxxxxxxx >>> > Subject: Re: spin_lock and scheduler confusion >>> > >>> > Hi Viral, >>> > >>> > On Wed, Jan 5, 2011 at 2:23 PM, Viral Mehta >>> > <Viral.Mehta@xxxxxxxxxxxxxxx> wrote: >>> > > >>> > > Hi , >>> > > >>> > > I need your help to solve below confusion. >>> > > >>> [...] >>> > >>> > Note that you can't sleep while you hold a spinlock. You're not >>> > allowed to perform any type of blocking operations. If you're holding >>> > the spinlock for any significant length of time, then you're using the >>> > wrong design. >>> > >>> > > spin_lock_irqrestore(); >>> > > 3. One of the CPU core tries to execute this code and so acquires the >>> > lock. >>> > > 4. Now, second core is also goes to execute same piece of code and so >>> > will >>> [...] >>> > >>> > Not while it's holding the spinlock or waiting for the spinlock. >>> > >>> > > Ever if timeslice is over for the current task ? >>> > >>> > The time tick interrupt is what determines when the timeslice is over. >>> > Since you have interrupts disabled, the timer interrupt can't happen. >>> > >>> > > What if scheduler code is running on CPU core-3 and sees that >>> > > timeslice for task running on CPU core-2 has expired ? >>> > >>> > Each core only considers the timeslices for its own core. >>> > >>> > > I guess timeslice expire case is not as same as preemption. Or may be >>> > I am >>> > > terribly wrong. >>> > >>> > You shouldn't be holding a spinlock for periods of time approaching >>> > the length of a timeslice. The timer interrupt is what determines the >>> > end of a timeslice. No timer interrupt, no end of a timeslice. >>> > Preemption is also triggered by the timer interrupt, or by releasing a >>> > resource that a higher priority task is waiting for. >>> >>> May be my understanding is incorrect, but wouldn't we hit the NMI >>> watchdog here(assuming we are running on x86/x86_64)? >>> We have a system lockup for long time. >>> http://lxr.linux.no/#linux+v2.6.37/Documentation/nmi_watchdog.txt >>> >>> Could someone please clarify? >>> > >>> > Dave Hylands >>> >>> -- >>> Thanks, >>> Nilesh >>> >>> _______________________________________________ >>> Kernelnewbies mailing list >>> Kernelnewbies@xxxxxxxxxxxxxxxxx >>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> >> >> _______________________________________________ >> Kernelnewbies mailing list >> Kernelnewbies@xxxxxxxxxxxxxxxxx >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> > > _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
