Messages in this thread | | | Date | Wed, 10 Nov 2004 11:59:51 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH] Documentation/preempt-locking.txt clarification |
| |
* Andrew Morton <akpm@osdl.org> 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.
Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |