lkml.org 
[lkml]   [2005]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 2.6.10-mm2] Use the new preemption code [2/3] Resend

    * Thomas Gleixner <tglx@linutronix.de> wrote:

    > > Are you sure ARM suffers from this race condition? It sets preempt count
    > > before enabling IRQs and doesn't use preempt_schedule().
    >
    > There is no race for arm, but using the preempt_schedule() interface
    > is the approach which Ingo suggested for common usage, but his x86
    > implementation was racy, so I fixed this first before modifying arm to
    > use the interface. Ingo pointed out that he will change it to
    > preempt_schedule_irq, but I'm not religious about the name.

    i wouldnt raise this issue if it was the name only, but there's more to
    preempt_schedule_irq() than its name: it gets called with irqs off and
    the scheduler returns with irqs off and with a guarantee that there is
    no (irq-generated) pending preemption request for this task right now.
    I.e. the checks for need_resched can be skipped, and interrupts dont
    have to be disabled to do a safe return-to-usermode (as done on some
    architectures).

    as far as i can see do_preempt_schedule() doesnt have these properties:
    what it guarantees is that it avoids the preemption recursion via the
    lowlevel code doing the PREEMPT_ACTIVE setting.

    lets agree upon a single, common approach. I went for splitting up
    preempt_schedule() into two variants: the 'synchronous' one (called
    preempt_schedule()) is only called from syscall level and has no
    repeat-preemption and hence stack-recursion worries. The 'asynchronous'
    one (called preempt_schedule_irq()) is called from asynchronous contexts
    (hardirq events) and is fully ready to deal with all the reentrancy
    situations that may occur. It's careful about not re-enabling
    interrupts, etc.

    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/

    \
     
     \ /
      Last update: 2005-03-22 14:09    [W:0.023 / U:59.596 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site