Re: [PATCH 1/24] make atomic_read() behave consistently on alpha

[Segher Boessenkool]

> > The compiler is within its rights to read a 32-bit quantity 16 bits at
> > at time, even on a 32-bit machine.  I would be glad to help pummel any
> > compiler writer that pulls such a dirty trick, but the C standard 
> > really
> > does permit this.
>
> Yes, but we don't write code for these compilers.  There are countless 
> pieces of kernel code which would break in this condition, and there 
> doesn't seem to be any interest in fixing this.

"Other things are broken too".  Great argument :-)

> Sequence points enforce read-after-write ordering, not 
> write-after-write.

Sequence points order *all* side effects; sequence points exist in the
domain of the abstract sequential model of the C language only.  The
compiler translates that to machine code that is equivalent to that C
code under the "as-if" rule; but this is still in that abstract model,
which doesn't include things such as SMP, visibility by I/O devices,
store queues, etc. etc.

> We flush writes with reads for MMIO because of this effect as well as 
> the CPU/bus effects.

You cannot flush all MMIO writes with reads; this is a PCI-specific
thing.  And even then, you need more than just the read itself: you
have to make sure the read completed and returned data.

> > In short, please retain atomic_set()'s volatility, especially on those
> > architectures that declared the atomic_t's counter to be volatile.
>
> Like i386 and x86_64?  These used to have volatile in the atomic_t 
> declaration.  We removed it, and the sky did not fall.

And this proves what?  Lots of stuff "works" by accident.


Segher

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/