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

[Andrea Arcangeli]

On Sat, Jan 12, 2002 at 04:54:43PM +0100, Andi Kleen wrote:
> On Sat, Jan 12, 2002 at 04:33:32PM +0100, Andrea Arcangeli wrote:
> > it doesn't (of course depends "what's the right thing"), and that's why
> 
> I think it does. Allocating all possible in future allocated pages
> is just not possible for VM_GROWSDOWN, because the stack has really 
> no suitable limit (other than rlimits, which are far too big to
> mlock them) 

the user asked for VM_LOCKED vma, if he asks for that and he faults too
low on the stack with big holes in between that's his mistake. And
anyways ptrace just faults in all the intermediate pages just now, so
it is definitely possible (we provide different userspace API from
ptrace/map_user_kiobuf and page-fault at the moment).

> 
> BTW expand_stack seems to have a small bug: it adds to mm->locked_vm
> the complete offset from last vm_start; if it covers more than one page
> the locked_vm value will be too large. 
> 
> > 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).
> 
> For the stack they can get minor faults anyways when they allocate new
> stack space below ESP. There is no good way to fix that from the kernel; the 

the only case here is when the app knows how much stack it will need to
use, without faulting in the holes, it will have to memset the whole
region of stack the it wants to be atomic. If instead the kernel also
fault-in the holes (like map_user_kiobuf/ptrace/get_user_pages just does
in 2.4) the app will only need to touch the lowest virtual address of
stack it needs as atomic.

I don't see any real problem either ways, it must be simply a well
defined API.

Then the user will know if he can touch one byte and the kernel fills
the holes automatically, or if he has to do the whole memset.

> application has to preallocate its memory on stack. I think it's reasonable
> if it does the same for holes on the stack. 
> 
> -Andi
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [e-mail]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Andrea