Re: Q: behaviour of mlockall(MCL_FUTURE) and VM_GROWSDOWN segments

[Andrea Arcangeli]

On Sat, Jan 12, 2002 at 01:33:24AM +0100, Andi Kleen wrote:
> Andrew Morton <[e-mail]> writes:
> 
> > So in this case, the behaviour I would prefer is MCL_FUTURE for
> > all vma's *except* the stack.   Stack pages should be locked
> > only when they are faulted in.   Hard call.
> 
> There is just one problem: linuxthread stacks are just ordinary mappings
> and they are in no way special to the kernel; they aren't VM_GROWSDOWN. 
> You would need to add a way to the kernel first to tag the linux thread 
> stacks in a way that is recognizable to mlockall and then do that 
> from linuxthreads. 
> 
> I think for the normal stack - real VM_GROWSDOWN segments - mlockall
> already does the right thing.

it doesn't (of course depends "what's the right thing"), and that's why
Manfred is asking after I asked him if he was really sure the API was
the right one, but as said to him, something is wrong with the kernel
too somehow, either we remove mark_page_present from find_extend_vma, or
we add it to the page fault handler too.

What the current kernel is doing with page faults, is to fault in only
the touched pages, not the pages in between as well, this isn't a
security concern because the faulted in pages won't be swapped out, but
it may matter for some RT app, OTOH the RT apps would better memset the
whole stack they need before assuming they won't get page faults, first
of all because of all other kernels out there (this is what I mean with
a matter of API).

I guess it is cleaner if a VM_LOCKED vma has all its pages allocated
between vm_start and vm_end, so I guess adding the mark_page_present in
do_page_fault as suggested by Manfred is ok.

Andrea