Re: 2.4.23aa2 (bugfixes and important VM improvements for the highend)

[Andrew Morton]

Andrea Arcangeli <andrea@xxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/