> From: Philip Guenther <guent...@gmail.com> > Date: Thu, 20 May 2021 23:32:17 -0900 > > On Wed, May 19, 2021 at 5:19 AM Mark Kettenis <mark.kette...@xs4all.nl> > wrote: > > > Date: Tue, 18 May 2021 13:24:42 +0200 > > From: Martin Pieuchot <m...@openbsd.org> > > ... > > > There's only a couple of 'volatile' usages in sys/sys. These > annotations > > do not explicitly indicate which piece of code requires it. Maybe it > would > > be clearer to use a cast or a macro where necessary. This might help > us > > understand why and where "volatile" is needed. > > There are the READ_ONCE() and WRITE_ONCE() macros. I'm not a big fan > of those (since they add clutter) but they do take care of dependency > ordering issues that exist in the alpha memory model. Must admit that > I only vaguely understand that issue, but I think it involves ordered > access to two atomic variables which doesn't seem to be the case. > > On non-alpha systems, READ_ONCE() and WRITE_ONCE() just do a volatile > pointer cast. > > READ/WRITE_ONCE() are 99% about keeping the compiler from deciding to > rearrange code such that the indicated variable is read/written more than > once. To point to Linus posts from 2008/2009, when it was still ACCESS_ONCE > (): > https://yarchive.net/comp/linux/ACCESS_ONCE.html
But that pretty much overlaps with the requirements for atomic access and the current Linux kernel uses them for that purpose extensively. > ISTR a paper by Ousterhout describing this same problem to the C standard > committee(?) in the early 90's, which kinda opened the "memory model" > rathole. > > If the variable is actually being protected by a lock then these are indeed > noise/pessimization; it's the lock-less accesses where the compiler can pull > a rabbit from its hat and stab you with it. And volatile is the stab-proof vest that might protect you from that. But more on that in the reply to your next mail...
