commit 59a8e9b92790ba035dbb3acaec00721b0cfeb32e Author: Greg Kroah-Hartman Date: Fri Aug 20 11:25:26 2010 -0700 Linux 2.6.27.52 commit 75f7ffb7d45d9464926cb1f7d819bc295d497f74 Author: Linus Torvalds Date: Sun Aug 15 11:35:52 2010 -0700 mm: fix up some user-visible effects of the stack guard page commit d7824370e26325c881b665350ce64fb0a4fde24a upstream. This commit makes the stack guard page somewhat less visible to user space. It does this by: - not showing the guard page in /proc//maps It looks like lvm-tools will actually read /proc/self/maps to figure out where all its mappings are, and effectively do a specialized "mlockall()" in user space. By not showing the guard page as part of the mapping (by just adding PAGE_SIZE to the start for grows-up pages), lvm-tools ends up not being aware of it. - by also teaching the _real_ mlock() functionality not to try to lock the guard page. That would just expand the mapping down to create a new guard page, so there really is no point in trying to lock it in place. It would perhaps be nice to show the guard page specially in /proc//maps (or at least mark grow-down segments some way), but let's not open ourselves up to more breakage by user space from programs that depends on the exact deails of the 'maps' file. Special thanks to Henrique de Moraes Holschuh for diving into lvm-tools source code to see what was going on with the whole new warning. [Note, for .27, only the /proc change is done, mlock is not modified here. - gregkh] Reported-and-tested-by: François Valenduc Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit dd0e56723390426af45e74d6ae1850c7f473a193 Author: Linus Torvalds Date: Sat Aug 14 11:44:56 2010 -0700 mm: fix page table unmap for stack guard page properly commit 11ac552477e32835cb6970bf0a70c210807f5673 upstream. We do in fact need to unmap the page table _before_ doing the whole stack guard page logic, because if it is needed (mainly 32-bit x86 with PAE and CONFIG_HIGHPTE, but other architectures may use it too) then it will do a kmap_atomic/kunmap_atomic. And those kmaps will create an atomic region that we cannot do allocations in. However, the whole stack expand code will need to do anon_vma_prepare() and vma_lock_anon_vma() and they cannot do that in an atomic region. Now, a better model might actually be to do the anon_vma_prepare() when _creating_ a VM_GROWSDOWN segment, and not have to worry about any of this at page fault time. But in the meantime, this is the straightforward fix for the issue. See https://bugzilla.kernel.org/show_bug.cgi?id=16588 for details. Reported-by: Wylda Reported-by: Sedat Dilek Reported-by: Mike Pagano Reported-by: François Valenduc Tested-by: Ed Tomlinson Cc: Pekka Enberg Cc: Greg KH Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 01ee2e1e3041f41722ef3ae49e95f04086dbd320 Author: Hugh Dickins Date: Thu Apr 16 21:58:12 2009 +0100 mm: pass correct mm when growing stack commit 05fa199d45c54a9bda7aa3ae6537253d6f097aa9 upstream. Tetsuo Handa reports seeing the WARN_ON(current->mm == NULL) in security_vm_enough_memory(), when do_execve() is touching the target mm's stack, to set up its args and environment. Yes, a UMH_NO_WAIT or UMH_WAIT_PROC call_usermodehelper() spawns an mm-less kernel thread to do the exec. And in any case, that vm_enough_memory check when growing stack ought to be done on the target mm, not on the execer's mm (though apart from the warning, it only makes a slight tweak to OVERCOMMIT_NEVER behaviour). Reported-by: Tetsuo Handa Signed-off-by: Hugh Dickins Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a980300e27c138836e2cc515e53f83e4d1a0505b Author: Greg Kroah-Hartman Date: Fri Aug 13 13:46:26 2010 -0700 x86: don't send SIGBUS for kernel page faults Based on commit 96054569190bdec375fe824e48ca1f4e3b53dd36 upstream, authored by Linus Torvalds. This is my backport to the .27 kernel tree, hopefully preserving the same functionality. Original commit message: It's wrong for several reasons, but the most direct one is that the fault may be for the stack accesses to set up a previous SIGBUS. When we have a kernel exception, the kernel exception handler does all the fixups, not some user-level signal handler. Even apart from the nested SIGBUS issue, it's also wrong to give out kernel fault addresses in the signal handler info block, or to send a SIGBUS when a system call already returns EFAULT. Cc: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b522544929b78f2a2a304b1b7c907f28c6f5dcdb Author: Linus Torvalds Date: Fri Aug 13 09:24:04 2010 -0700 mm: fix missing page table unmap for stack guard page failure case commit 5528f9132cf65d4d892bcbc5684c61e7822b21e9 upstream. .. which didn't show up in my tests because it's a no-op on x86-64 and most other architectures. But we enter the function with the last-level page table mapped, and should unmap it at exit. Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7a9f6ef422319833b02c26aa57b51f837c372f16 Author: Linus Torvalds Date: Thu Aug 12 17:54:33 2010 -0700 mm: keep a guard page below a grow-down stack segment commit 320b2b8de12698082609ebbc1a17165727f4c893 upstream. This is a rather minimally invasive patch to solve the problem of the user stack growing into a memory mapped area below it. Whenever we fill the first page of the stack segment, expand the segment down by one page. Now, admittedly some odd application might _want_ the stack to grow down into the preceding memory mapping, and so we may at some point need to make this a process tunable (some people might also want to have more than a single page of guarding), but let's try the minimal approach first. Tested with trivial application that maps a single page just below the stack, and then starts recursing. Without this, we will get a SIGSEGV _after_ the stack has smashed the mapping. With this patch, we'll get a nice SIGBUS just as the stack touches the page just above the mapping. Requested-by: Keith Packard Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman