lkml.org 
[lkml]   [2007]   [Oct]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] synchronize_irq needs a barrier
    From
    Date

    >
    > repeat:
    > /* Optimistic, no-locking loop */
    > while (desc->status & IRQ_INPROGRESS)
    > cpu_relax();
    >
    > /* Ok, that indicated we're done: double-check carefully */
    > spin_lock_irqsave(&desc->lock, flags);
    > status = desc->status;
    > spin_unlock_irqrestore(&desc->lock, flags);
    >
    > /* Oops, that failed? */
    > if (status & IRQ_INPROGRESS)
    > goto repeat;
    >
    > Hmm?

    Paulus and I convinced ourselves that this would work. If we call our
    variable that gets set before synchronize_irq and read in the IRQ
    handler "foo", we get to:

    - writing foo can travel down at most to just before the unlock in the
    code above

    - reading foo can travel up out of the IRQ handler at most just after
    the lock in the code that sets IRQ_INPROGRESS.

    The whole lock/set IRQ_INPROGRESS/unlock path can then only happen
    before the locked section above, in which case we see and wait nicely
    and all is good, or after, in which case the store to foo will be
    visible to the IRQ handler as it will be ordered with the unlock in the
    code above.

    Pfiew !

    So Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

    Thanks !

    Ben.


    -
    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: 2007-10-19 06:15    [W:0.022 / U:29.432 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site