On Friday 19 October 2007 13:28, Herbert Xu wrote:
> Nick Piggin <[email protected]> wrote:
> >> First of all let's agree on some basic assumptions:
> >>
> >> * A pair of spin lock/unlock subsumes the effect of a full mb.
> >
> > Not unless you mean a pair of spin lock/unlock as in
> > 2 spin lock/unlock pairs (4 operations).
> >
> > *X = 10;
> > spin_lock(&lock);
> > /* *Y speculatively loaded here */
> > /* store to *X leaves CPU store queue here */
> > spin_unlock(&lock);
> > y = *Y;
>
> Good point.
>
> Although in this case we're still safe because in the worst
> cases:
>
> CPU0 CPU1
> irq_sync = 1
> synchronize_irq
> spin lock
> load IRQ_INPROGRESS
> irq_sync sync is visible
> spin unlock
> spin lock
> load irq_sync
> while (IRQ_INPROGRESS)
> wait
> return
> set IRQ_INPROGRESS
> spin unlock
> tg3_msi
> ack IRQ
> if (irq_sync)
> return
> spin lock
> clear IRQ_INPROGRESS
> spin unlock
>
> ------------------------------------------------------------
>
> CPU0 CPU1
> spin lock
> load irq_sync
> irq_sync = 1
> synchronize_irq
> set IRQ_INPROGRESS
> spin unlock
> spin lock
> load IRQ_INPROGRESS
> irq_sync sync is visible
> spin unlock
> while (IRQ_INPROGRESS)
> wait
> tg3_msi
> ack IRQ
> if (irq_sync)
> return
> do work
> spin lock
> clear IRQ_INPROGRESS
> spin unlock
> return
>
> So because we're using the same lock on both sides, it does
> do the right thing even without the memory barrier.
Yeah, if you've got the lock on both sides there, then I
agree it will be correct.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
