Re: [PATCH] Documentation/preempt-locking.txt clarification

From: Ingo Molnar
Date: Wed Nov 10 2004 - 05:01:10 EST

* Andrew Morton <akpm@xxxxxxxx> wrote:

> I think the statement is in fact false. Ingo, what's your take on
> this paragraph, from preempt-locking.txt?
> An additional concern is proper usage of local_irq_disable and
> local_irq_save. These may be used to protect from preemption,
> however, on exit, if preemption may be enabled, a test to see if
> preemption is required should be done. If these are called from the
> spin_lock and read/write lock macros, the right thing is done. They
> may also be called within a spin-lock protected region, however, if
> they are ever called outside of this context, a test for preemption
> should be made. Do note that calls from interrupt context or bottom
> half/ tasklets are also protected by preemption locks and so may use
> the versions which do not check preemption.

seems mostly correct. The issue is that if a wakeup is done from within
an irqs-off critical section (perfectly possible - a simple printk can
trigger a wakeup) then the current task may be marked for rescheduling
but cannot do it just yet. So when interrupts are re-enabled again
(outside of a critical section) a manual preempt_check_resched() is
necessary in the generic case, or else we miss the reschedule.

In special cases, if no wakeup may happen from within the irqs-off
section then the manual preemption can be skipped, because asynchronous
reschedules (e.g. on SMP) always come in the form of interrupts. I'd
wager that in fact these 'special cases' are in the majority, but
there's no guarantee.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at