Messages in this thread | | | Date | Fri, 17 Aug 2007 14:44:48 +0530 (IST) | From | Satyam Sharma <> | Subject | Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures |
| |
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?
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)
> > And we have driver / subsystem maintainers such as Stefan > > coming up and admitting that often a lot of code that's written to use > > atomic_read() does assume the read will not be elided by the compiler. ^^^^^^^^^^^^^
(so it's about compiler barrier expectations only, though I fully agree that those who're using atomic_t as if it were some magic thing that lets them write lockless code are sorrily mistaken.)
> So these are broken on i386 and x86-64?
Possibly, but the point is not about existing bugs, as mentioned above.
Some such bugs have been found nonetheless -- reminds me, can somebody please apply http://www.gossamer-threads.com/lists/linux/kernel/810674 ?
Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |