Looking at some test results provided in IRC, the first approach maybe is not sufficient. I currently only handle the case when the vma gets split by the current call to mlock_fixup(). But once a split is done locking within this vma again would likely be considered as touching the guard page. The only real way to prevent this would require to find out whether there is a vma for an address before the requested start, whether this ends at the beginning of the current vma and whether that vma is a stack vma, too. This would require another call to find_vma() which is slow. Upstream changed the vma code to have a double linked list instead of a single chain and by that preventing another call to find_vma() when setting up the guard page. But I am not sure we really want to backport this change. There might be another solution, which is to simply rip out the special handling in mlock. This however allows to potentially call mlock with an address space that includes the guard page and by that would cause the stack to grow with mlock. This normally should not happen as the guard page is hidden from the address range in proc. Still it might leave a way for evil code.
I am currently compiling a version 2 of test kernels which remove the guard page handling. And I would go and implement the guard page checking which uses find_vma(). Even being slower this sounds like a safer option than backporting the double linked list change. -- linux 2.6.24-28.75 breaks xen flavours (xen kernel bug: 'kernel BUG at /build/buildd/linux-2.6.24/debian/build/custom-source-xen/mm/memory.c:2704') https://bugs.launchpad.net/bugs/620994 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
