lkml.org 
[lkml]   [2019]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Plain accesses and data races in the Linux Kernel Memory Model
    On Tue, 15 Jan 2019, Dmitry Vyukov wrote:

    > On Tue, Jan 15, 2019 at 12:54 AM Paul E. McKenney <paulmck@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

    \
     
     \ /
      Last update: 2019-01-15 16:04    [W:2.560 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site