[parisc-linux] Re: [parisc-linux-cvs] linux-2.6 jejb

[James Bottomley]

On Sat, 2004-08-21 at 03:27, Grant Grundler wrote:
> I consider 2 and 3 the same thing basically.
> Maybe on other arches this distinction matters?
> (as noted below, I think I'm still missing something here...I need
> to re-read the thread in January two or three more times)

But the compiler doesn't...that's the point.

> mb() now has "memory" reference.
> This prevents gcc from reordering the memory accesses across the mb().
> 
> The comment is incorrect for newer gcc if I understand this all corectly.
> The "memory" is what prevents gcc from re-ordering instructions.

No, no.

volatile prevents gcc from doing instruction reordering across the asm
statement.

The "memory" clobber tells gcc that all cached memory references have to
be dropped after the asm code is executed.

> > I don't think anything needs to be done to our ldcw since it's already
> > operating on volatile data for the spinlock.  I could be persuaded that
> > the only mb() we actually need in the spin_lock is the one at the end.
> 
> acquire/release semantics as implemented by ia64 are probably
> the minimal set. I think we need to prevent gcc from re-ordering memory
> access before the acquire (lock) as well.

true, but ldcw is not our lock.  It's a statement executed as part of
our lock, that's why it's currently OK as is.

> > Actually, the bug was showing up with 3.0.4 compiled kernels as well.
> 
> oh! I wonder how parisc ever worked some days...

Well, the bug is very subtle, and it's minimised by the fact that
local_irq_save/restore *is* an instruction barrier and memory clobber,
so the only issue is non-irq spinlocks.

And even for them, gcc doesn't make spurious memory loads, so some code
has to occur immediately prior to the spinlock to cause gcc to load a
value from memory that it will later reuse after the spinlock.

James