[lkml]   [2004]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] Documentation/preempt-locking.txt clarification

* Andrew Morton <> 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:07    [W:0.048 / U:0.612 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site