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:

quoted

quoted

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
back.

--
			Gleb.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>