On Tue, 15 Jan 2019, Dmitry Vyukov wrote: > On Tue, Jan 15, 2019 at 12:54 AM Paul E. McKenney <paul...@linux.ibm.com> > wrote: > > > > On Mon, Jan 14, 2019 at 02:41:49PM -0500, Alan Stern wrote: > > > The patch below is my first attempt at adapting the Linux Kernel > > > Memory Model to handle plain accesses (i.e., those which aren't > > > specially marked as READ_ONCE, WRITE_ONCE, acquire, release, > > > read-modify-write, or lock accesses). This work is based on an > > > initial proposal created by Andrea Parri back in December 2017, > > > although it has grown a lot since then. > > > > Hello, Alan, > > > > Good stuff!!! > > > > I tried applying this in order to test it against the various litmus > > tests, but no joy. Could you please tell me what commit is this patch > > based on? > > > > Thanx, Paul > > > > > The adaptation involves two main aspects: recognizing the ordering > > > induced by plain accesses and detecting data races. They are handled > > > separately. In fact, the code for figuring out the ordering assumes > > > there are no data races (the idea being that if a data race is > > > present then pretty much anything could happen, so there's no point > > > worrying about it -- obviously this will have to be changed if we want > > > to cover seqlocks). > > Hi Alan, > > Is there a mailing list dedicated to this effort? Private messages > tend to lost over time, no archive, not possible to send a link or > show full history to anybody, etc.
No specific mailing list. We've been relying on LKML. > Re seqlocks, strictly saying defining races for seqlocks is not > necessary. Seqlocks can be expressed without races in C by using > relaxed atomic loads within the read critical section. We may consider > this option as well. That seems like a reasonable approach. Alan