Re: [PATCH v6] add MAP_UNLOCKED mmap flag
From: Gleb Natapov
Date: Mon Jan 18 2010 - 10:02:47 EST
On Mon, Jan 18, 2010 at 03:49:58PM +0100, Peter Zijlstra wrote:
> On Mon, 2010-01-18 at 14:32 +0000, Alan Cox wrote:
> > > this kind of control. As of use of mlockall(MCL_FUTURE) how can I make
> > > sure that all memory allocated behind my application's back (by dynamic
> > > linker, libraries, stack) will be locked otherwise?
> > If you add this flag you can't do that anyway - some library will
> > helpfully start up using it and then you are completely stuffed or will
> > be back in two or three years adding MLOCKALL_ALWAYS.
> Agreed, mlockall() is a very bad interface and should not be used for a
> plethora of reasons, this being one of them.
There are valid uses for mlockall() and even if the interface is bad there
is no alternative right now, so why not fix one of it problems?
> The thing is, if you cant trust your library to do sane things, then
> don't use it.
Agreed, the are things that sane library should never do: exit() or output
debug info to stdio or meddle with memory mlock/munlock behind application's
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/