On Wed, 20 Jan 1999, Manfred Spraul wrote:
> I currently try to understand the schedule() function, and I don't
> understand why release_kernel_lock() calls release_irqlock() and __sti().
>
> * #define release_kernel_lock(task, cpu) \
> * do { \
> * if (task->lock_depth >= 0) \
> * spin_unlock(&kernel_flag); \
> * release_irqlock(cpu); \
> * __sti(); \
> * } while (0)
>
> release_kernel_lock()
> - is only called from schedule()
> - schedule() ignores all calls if in_interrupt() returns true.
it does not ignore it, it oopses ...
> Is this call to release_irqlock() required, or is this call there for
> historic reasons?
> Is there someone who calls schedule() after cli()?
while it's considered to be unsafe, it still happens (happened) casually.
The most common cause is using one of the copy_*_user() functions with
IRQs disabled in some rare codepath, they usually do not cause a
reschedule. To prooceed blindly without dropping an (erroneous) irq lock
is a sure way to get a deadlock sooner or later. You are right we should
print a warning message.
-- mingo
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
