spin_lock and scheduler confusion

[Dave Hylands]

Hi Rajat,

On Thu, Jan 6, 2011 at 11:35 PM, Rajat Sharma <fs.rajat at gmail.com> 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 at gmail.com> 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 at netscout.com> wrote:
>>>
>>> Hi,
>>>
>>> > -----Original Message-----
>>> > From: kernelnewbies-bounces at kernelnewbies.org [mailto:kernelnewbies-
>>> > bounces at kernelnewbies.org] On Behalf Of Dave Hylands
>>> > Sent: Friday, January 07, 2011 10:59 AM
>>> > To: Viral Mehta
>>> > Cc: kernelnewbies at kernelnewbies.org
>>> > Subject: Re: spin_lock and scheduler confusion
>>> >
>>> > Hi Viral,
>>> >
>>> > On Wed, Jan 5, 2011 at 2:23 PM, Viral Mehta
>>> > <Viral.Mehta at lntinfotech.com> 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 at kernelnewbies.org
>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>
>