Hi Dave,

quoted

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
[off-list ref] wrote:

Hi,
________________________________________
From: Dave Hylands [dhylands at gmail.com]
Subject: Re: spin_lock and scheduler confusion

quoted

quoted

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.

quoted

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