spin_lock and scheduler confusion

[Rajat Sharma]

Hi Dave,

> > 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:

Please refer to my first mail in this thread, I have already mentioned
about scheduling while atomic in my first mail:

> however if you have debugging options turned on like CONFIG_DEBUG_SPINLOCK, you may likely get kernel warning for 'scheduling > in atomic context'.

And also its just a warning print with stack dump but not the panic()
or BUG(), so system is still responsive. Its anyways not a good
practice, but what I was trying to highlight is what can happen if we
call schedule() function while holding spin_lock_irqsave. To kill the
curiosity, I tried out following module:

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/spinlock.h>
#include <linux/sched.h>

MODULE_LICENSE("GPL");

static DEFINE_SPINLOCK(sleepy_lock);

static int __init sleepy_init(void)
{
	unsigned long flags;

	printk("SLEEPTEST: loading sleepytest\n");

	spin_lock_irqsave(&sleepy_lock, flags);
	schedule();
	spin_unlock_irqrestore(&sleepy_lock, flags);

	return 0;
}

static void __exit sleepy_exit(void)
{
	printk("SLEEPTEST: unloading sleepytest\n");
}

module_init(sleepy_init);
module_exit(sleepy_exit);

And on my system, module silently prints messages without any atomic
schedule warning:

[ 6850.499940] SLEEPTEST: loading sleepytest
[ 6871.822539] SLEEPTEST: unloading sleepytest

I am not sure what config option turns on __schedule_bug(), but I
didn't see this message on my system:

CONFIG_SCHED_DEBUG=y
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set

Please try this module and let us know if you can hit schedule_bug().

Rajat

On Fri, Jan 7, 2011 at 11:16 PM, Viral Mehta
<Viral.Mehta at lntinfotech.com> wrote:
> Hi,
> ________________________________________
> From: Dave Hylands [dhylands at gmail.com]
> Subject: Re: spin_lock and scheduler confusion
>
>>> 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.
>
> thanks,
> it is much clear now.
>
>>Dave Hylands
>
> Thanks,
> Viral
>
> http://groups.google.com/group/fundamental-discussion?hl=en
>
> The contents of this e-mail and any attachment(s) may contain confidential or privileged information for the intended recipient(s). Unintended recipients are prohibited from taking action on the basis of information in this e-mail and  using or disseminating the information,  and must notify the sender and delete it from their system. L&T Infotech will not accept responsibility or liability for the accuracy or completeness of, or the presence of any virus or disabling code in this e-mail"
>
> ______________________________________________________________________
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>