Re: [RFC] mlock/stack guard interaction fixup

From: Peter Zijlstra <peterz@infradead.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>,
	Greg KH <gregkh@suse.de>, Ian Campbell <ijc@hellion.org.uk>,
	linux-kernel@vger.kernel.org, stable@kernel.org,
	stable-review@kernel.org, akpm@linux-foundation.org,
	alan@lxorguk.ukuu.org.uk, Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: [RFC] mlock/stack guard interaction fixup
Date: Mon, 23 Aug 2010 19:59:45 +0200	[thread overview]
Message-ID: <1282586385.2605.2119.camel@laptop> (raw)
In-Reply-To: <AANLkTi=+O8wKZV6XT5wGJbfZdgC9kxTxvtEZMD+M+pZn@mail.gmail.com>

On Mon, 2010-08-23 at 10:34 -0700, Linus Torvalds wrote:
> I suspect that if you use mlock for _any_ other reason than protecting
> a particular very sensitive piece of information, you should use
> mlockall(MCL_FUTURE). IOW, if you use mlock because you have realtime
> issues, there is no excuse to ever use anything else, imho. And even
> then, I guarantee that things like copy-on-write is going to be
> "interesting".
> 
> I realize that people hate mlockall() (and particularly MCL_FUTURE),
> and yes, it's a bloated thing that you can't reasonably use on a large
> process. But dammit, if you have RT issues, you shouldn't _have_ some
> big bloated process. You should have a small statically linked server
> that is RT, and nothing else. 

Us real-time people have been telling people to not use mlockall() at
all.

While small !glibc statically linked RT components using shared memory
interfaces to !RT apps could work its not how people actually write
their apps. They write big monolithic threaded apps where some threads
are RT.

[ in part because there doesn't seem to be a usable !glibc
libpthread/librt implementation out there, in part because people use
crap like Java-RT ]