lkml.org 
[lkml]   [2004]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.4.23aa2 (bugfixes and important VM improvements for the high end)
Andrea Arcangeli <andrea@suse.de> 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
mprotect.

-
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: 2005-03-22 14:01    [W:0.072 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site