]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
.27 patch
authorGreg Kroah-Hartman <gregkh@suse.de>
Wed, 18 Aug 2010 14:57:50 +0000 (07:57 -0700)
committerGreg Kroah-Hartman <gregkh@suse.de>
Wed, 18 Aug 2010 14:57:50 +0000 (07:57 -0700)
review-2.6.27/mm-fix-up-some-user-visible-effects-of-the-stack-guard-page.patch [new file with mode: 0644]
review-2.6.27/series

diff --git a/review-2.6.27/mm-fix-up-some-user-visible-effects-of-the-stack-guard-page.patch b/review-2.6.27/mm-fix-up-some-user-visible-effects-of-the-stack-guard-page.patch
new file mode 100644 (file)
index 0000000..9c8c3a5
--- /dev/null
@@ -0,0 +1,74 @@
+From d7824370e26325c881b665350ce64fb0a4fde24a Mon Sep 17 00:00:00 2001
+From: Linus Torvalds <torvalds@linux-foundation.org>
+Date: Sun, 15 Aug 2010 11:35:52 -0700
+Subject: mm: fix up some user-visible effects of the stack guard page
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Linus Torvalds <torvalds@linux-foundation.org>
+
+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/<pid>/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/<pid>/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 <francois.valenduc@tvcablenet.be
+Reported-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ fs/proc/task_mmu.c |    8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/fs/proc/task_mmu.c
++++ b/fs/proc/task_mmu.c
+@@ -205,6 +205,7 @@ static void show_map_vma(struct seq_file
+       struct file *file = vma->vm_file;
+       int flags = vma->vm_flags;
+       unsigned long ino = 0;
++      unsigned long start;
+       dev_t dev = 0;
+       int len;
+@@ -214,8 +215,13 @@ static void show_map_vma(struct seq_file
+               ino = inode->i_ino;
+       }
++      /* We don't show the stack guard page in /proc/maps */
++      start = vma->vm_start;
++      if (vma->vm_flags & VM_GROWSDOWN)
++              start += PAGE_SIZE;
++
+       seq_printf(m, "%08lx-%08lx %c%c%c%c %08llx %02x:%02x %lu %n",
+-                      vma->vm_start,
++                      start,
+                       vma->vm_end,
+                       flags & VM_READ ? 'r' : '-',
+                       flags & VM_WRITE ? 'w' : '-',
index cc279ed03efc2c025d9c4f185863aa7969308765..c94c06ff9e8f44593dd35c08c2ac6abd39e05a57 100644 (file)
@@ -3,3 +3,4 @@ mm-fix-missing-page-table-unmap-for-stack-guard-page-failure-case.patch
 x86-don-t-send-sigbus-for-kernel-page-faults.patch
 mm-pass-correct-mm-when-growing-stack.patch
 mm-fix-page-table-unmap-for-stack-guard-page-properly.patch
+mm-fix-up-some-user-visible-effects-of-the-stack-guard-page.patch