linux-kernel - Re: [PATCH v6] add MAP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1263829474.4283.617.camel@laptop>
Date:	Mon, 18 Jan 2010 16:44:34 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Avi Kivity <avi@...hat.com>, Gleb Natapov <gleb@...hat.com>,
	Pekka Enberg <penberg@...helsinki.fi>, linux-mm@...ck.org,
	kosaki.motohiro@...fujitsu.com, linux-kernel@...r.kernel.org,
	linux-api@...r.kernel.org, akpm@...ux-foundation.org,
	andrew.c.morrow@...il.com,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [PATCH v6] add MAP_UNLOCKED mmap flag

On Mon, 2010-01-18 at 15:41 +0000, Alan Cox wrote:
> On Mon, 18 Jan 2010 16:24:07 +0100
> Peter Zijlstra <peterz@...radead.org> wrote:
> 
> > On Mon, 2010-01-18 at 17:19 +0200, Avi Kivity wrote:
> > > > I would not advice that, just mlock() the text and data you need for the
> > > > real-time thread. mlockall() is a really blunt instrument.
> > > >    
> > > 
> > > May not be feasible due to libraries. 
> > 
> > Esp for the real-time case I could advise not to use those libraries
> > then, since they're clearly not designed for that use case.
> 
> In "hard" real time cases an awful lot of libraries have things like
> memory allocations in them and don't care about stack growth which can
> cause faults and sleeps. The memory allocator if you are running threaded
> was not real time priority aware either last time I checked so the
> standard libraries are not going to give the behaviour you want unless
> you have a proper RT environment, and even then it may be a bit iffy here
> and there.

I'm quite aware of that, which is why we recommend people to
pre-allocate, mlock() and pre-fault everything in advance and make sure
the RT thread doesn't touch any data/text outside of that and uses a
limited set of system calls.

You can also do that for stacks using pthread_attr_setstack().



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/