Messages in this thread | | | Date | Wed, 3 Mar 2004 21:38:23 -0800 | From | Andrew Morton <> | Subject | Re: 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/
| |