[lkml]   [2004]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.4.23aa2 (bugfixes and important VM improvements for the high end)
    Andrea Arcangeli <> wrote:
    > > It is a judgement call. Personally, I wouldn't ship a production kernel
    > > with this patch. People need to be aware of the tradeoff and to think and
    > > test very carefully.
    > test what? there's no way to know what soft of proprietary software
    > people will run on the thing.

    In the vast majority of cases the application was already racy. It took
    davem a very long time to convince me that this was really a bug ;)

    > Personally I wouldn't feel safe to ship a kernel with a known race
    > condition add-on. I mean, if you don't know about it and it's an
    > implementation bug you know nobody is perfect and you try to fix it if
    > it happens, but if you know about it and you don't apply it, that's
    > pretty bad if something goes wrong. Especially because it's a race,
    > even you test it, it may still happen only a long time later during
    > production. I would never trade performance for safety, if something I'd
    > try to find a more complex way to serialize against the vmas or similar.

    Well first people need to understand the problem and convince themselves
    that this really is a bug. And yes, there are surely other ways of fixing
    it up. One might be to put some sequence counter in the mm_struct and
    rerun the mprotect if it detects that someone else snuck in with a
    usercopy. Or add an rwsem to the mm_struct, take it for writing in

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:01    [W:0.021 / U:7.452 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site