From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail144.messagelabs.com (mail144.messagelabs.com [216.82.254.51]) by kanga.kvack.org (Postfix) with SMTP id A2BF36B0078 for ; Mon, 18 Jan 2010 09:35:25 -0500 (EST) Date: Mon, 18 Jan 2010 16:35:16 +0200 From: Gleb Natapov Subject: Re: [PATCH v6] add MAP_UNLOCKED mmap flag Message-ID: <20100118143516.GK30698@redhat.com> References: <20100118133755.GG30698@redhat.com> <84144f021001180609r4d7fbbd0p972d5bc0e227d09a@mail.gmail.com> <20100118141938.GI30698@redhat.com> <20100118143232.0a0c4b4d@lxorguk.ukuu.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100118143232.0a0c4b4d@lxorguk.ukuu.org.uk> Sender: owner-linux-mm@kvack.org To: Alan Cox Cc: Pekka Enberg , linux-mm@kvack.org, kosaki.motohiro@jp.fujitsu.com, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, akpm@linux-foundation.org, andrew.c.morrow@gmail.com, "Paul E. McKenney" List-ID: On Mon, Jan 18, 2010 at 02:32:32PM +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. > Libraries can do many other bad things. They can do mlockall(0) today too and this is not the reason to ditch mlockall(). I don't expect libc will do that though. -- 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: email@kvack.org