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 12:01 PM, Linus Torvalds
    <torvalds@linux-foundation.org> wrote:
    >
    >  - However, while using the *smallest* possible access may generate
    > correct code, it often generates really *crappy* code. Which is
    > exactly the bug that I reported in
    >
    >   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48696

    Btw, as I also pointed out in that (old) bugzilla entry, gcc can do
    pretty much whatever it damn well pleases with loads from a bitfield.

    You can narrow them, you can make them wider, you can paint them pink.

    Widening the loads can still be a performance problem, and technically
    it's a really bad idea for any nearby "volatile"s too, but in practice
    things will *work*.

    Writes are much more critical. If you overwrite a field that is no
    longer in the bitfield, you can no longer depend on "nobody cares
    about bitfield accesses", because by definition you are clearly now
    stepping on non-bitfield things.

    You do realize that even in user space, and even before C11, people
    have things like "sig_atomic_t" etc. So even if you don't like the
    notion of "volatile", here's *another* example of this being real gcc
    bug:

    struct mydata {
    sig_atomic_t seen_signal;
    unsigned flags:1;
    };

    and now do the same test-program, realizing that "sig_atomic_t" is
    normally the exact same thing as "int".

    Now, thing about what happens if you have a signal handler that comes
    in and does

    mydata.seen_signal = 1;

    and happens to interrupt the code that changes "mydata.flags" in just
    the right spot.

    That's right: the bitfield update will possibly *clear* that
    "signal-safe" flag again, and gcc just created buggy asm code from
    correct C code.

    Guys, if you don't admit that this is a bug, I don't know what to say.

    IT IS A GCC BUG.

    Don't try to make it into something bigger and related to C++11/C11.
    Don't try to talk about "memory models". Just admit that it is a bug
    to do a 64-bit write to a 32-bit bitfield, and fix it!

    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 21:21    [W:4.066 / U:0.112 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site