Re: [RFC] mlock/stack guard interaction fixup

[Peter Zijlstra]

On Mon, 2010-08-23 at 18:18 +0100, Ian Jackson wrote:
> Peter Zijlstra writes ("Re: [RFC] mlock/stack guard interaction fixup"):
> > On Mon, 2010-08-23 at 16:42 +0100, ijackson@xxxxxxxxxxxxxxxxxxxxxx
> > wrote:
> > > mlocking the stack is entirely sensible and normal for a real-time
> > > program.  Most such programs use mlockall but there is no particular
> > > reason why a program that has some more specific requirements should
> > > use mlock to lock only a part of the stack.  (Perhaps it has only one
> > > real-time thread?) 
> > 
> > RT apps should pre-allocate and mlock their stack in advance (and
> > pre-fault too for the paranoid).
> 
> Are you allowed to mlock a stack page which has not yet been faulted
> in ?  What effect does it have ?  I wasn't able to find a convincing
> de jure answer to this question.

mlock() seems to call make_pages_present(), so its a moot point.

> But you seem, like me, to be disagreeing with Linus's assertion that
> calling mlock() on the stack is something no sane programs does ?

I think the case that Linus called daft is splitting the stack vma
through mlock/mprotect, which is indeed something rarely done.

> > mlockall is a very bad interface and should really not be used.
> 
> You are directly contradicting the advice in SuS, to which I just gave
> a reference.  You're free to do so of course but it might be worth
> explaining in a bit more detail why the advice in SuS is wrong.

Because a real RT program will have a significant !RT part, and calling
mlock on everything is a massive resource waste.

Furthermore, mlockall gives the false impression that everything is good
to go for RT, disregarding pretty much everything that makes a RT app.

There's lots more to RT than sched_setscheduler() and
mlockall(MCL_FUTURE).

If a library is RT suited, it will already mlock() all relevant memory
allocations (or provide an option to do so, or strictly work on
externally allocated memory, which the user will then have mlock()'ed).


--
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/