Messages in this thread | | | Date | Sat, 12 Jan 2002 16:33:32 +0100 | From | Andrea Arcangeli <> | Subject | Re: Q: behaviour of mlockall(MCL_FUTURE) and VM_GROWSDOWN segments |
| |
On Sat, Jan 12, 2002 at 01:33:24AM +0100, Andi Kleen wrote: > Andrew Morton <akpm@zip.com.au> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |