Re: [PATCH 0/24] make atomic_read() behave consistently across allarchitectures

[Nick Piggin]

Satyam Sharma wrote:
> On Fri, 17 Aug 2007, Nick Piggin wrote:
>
>
> > Satyam Sharma wrote:
> > [...]
> >
> > > Granted, the above IS buggy code. But, the stated objective is to avoid
> > > heisenbugs.
>
>     ^^^^^^^^^^
>
>
> > Anyway, why are you making up code snippets that are buggy in other
> > ways in order to support this assertion being made that lots of kernel
> > code supposedly depends on volatile semantics. Just reference the
> > actual code.
>
>
> Because the point is *not* about existing bugs in kernel code. At some
> point Chris Snook (who started this thread) did write that "If I knew
> of the existing bugs in the kernel, I would be sending patches for them,
> not this series" or something to that effect.
>
> The point is about *author expecations*. If people do expect atomic_read()
> (or a variant thereof) to have volatile semantics, why not give them such
> a variant?

Because they should be thinking about them in terms of barriers, over
which the compiler / CPU is not to reorder accesses or cache memory
operations, rather than "special" "volatile" accesses. Linux's whole
memory ordering and locking model is completely geared around the
former.


> And by the way, the point is *also* about the fact that cpu_relax(), as
> of today, implies a full memory clobber, which is not what a lot of such
> loops want. (due to stuff mentioned elsewhere, summarized in that summary)

That's not the point, because as I also mentioned, the logical extention
to Linux's barrier API to handle this is the order(x) macro. Again, not
special volatile accessors.
-
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/