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@xxxxxxxxxxxxxxx> wrote:
> Hi,
> ________________________________________
> From: Dave Hylands [dhylands@xxxxxxxxx]
> 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@xxxxxxxxxxxxxxxxx
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
