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/
