[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.094 / U:8.808 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site