lkml.org 
[lkml]   [2012]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: Memory corruption due to word sharing
    On Wed, Feb 1, 2012 at 9:08 AM, Torvald Riegel <triegel@redhat.com> wrote:
    >
    > What do the kernel folks think about the C11 memory model?  If you can
    > spot any issues in there, the GCC community would certainly like to
    > know.

    I don't think this is about memory models except very tangentially.

    Gcc currently accesses fields in a way that affects *independent*
    fields, without checking their memory models at all.

    Even original C already has one memory model: "volatile" data is seen
    outside the virtual C machine. And Jiri reports that even that
    *original* memory model is being violated. We're taling about the one
    from about 40 years ago.

    So no amount of memory model will ever matter, if gcc can't even get
    the 40-year old one right.

    Also, the C11 memory model really isn't going to make any difference
    to this. Again, because this happens even if we have explicit locking
    for the different fields. So they aren't "atomic" or anything like
    that, because we do our own (and sufficient) locking. But once the
    compiler starts to randomly touch data that just happens to be
    adjacent to other data, any memory model about those individual pieces
    is going to be entirely immaterial anyway.

    Finally: I do not believe for a second that we can actually use the
    C11 memory model in the kernel and say "that's sufficient for our
    needs". We will continue to have to do things that are "outside the
    specs" for the very simple reason that the kernel isn't just some
    random application that happens to use pthreads. We do end up doing
    much more aggressive threading, with models that C11 simply doesn't
    cover.

    _Atomic simply isn't going to make any difference to us. Sure, we
    might use it in a couple of places (where we have sometimes tried to
    use volatile casts, for example), but it would be totally irrelevant
    in this case exactly because *neither* field is really atomic - they
    are both protected, it's just that they are *separately* protected, so
    accessing one does *not* mean that you can access the other, even if
    they are next to each other.

    Linus
    --
    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/

    \
     
     \ /
      Last update: 2012-02-01 18:33    [W:0.031 / U:0.140 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site