From: Greg KH <gregkh@suse.de>
To: linux-kernel@vger.kernel.org, stable@kernel.org
Cc: stable-review@kernel.org, torvalds@linux-foundation.org,
akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk
Subject: [6/6] mm: fix up some user-visible effects of the stack guard page
Date: Wed, 18 Aug 2010 08:02:00 -0700 [thread overview]
Message-ID: <20100818150557.612304949@clark.site> (raw)
In-Reply-To: <20100818150615.GA4752@kroah.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2403 bytes --]
2.6.27-stable review patch. If anyone has any objections, please let us know.
------------------
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' : '-',
next prev parent reply other threads:[~2010-08-18 15:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-18 15:06 [0/6] 2.6.27.52 stable review [try 3] Greg KH
2010-08-18 15:01 ` [1/6] mm: keep a guard page below a grow-down stack segment Greg KH
2010-08-18 15:01 ` [2/6] mm: fix missing page table unmap for stack guard page failure case Greg KH
2010-08-18 15:01 ` [3/6] x86: dont send SIGBUS for kernel page faults Greg KH
2010-08-18 15:01 ` [4/6] mm: pass correct mm when growing stack Greg KH
2010-08-18 15:01 ` [5/6] mm: fix page table unmap for stack guard page properly Greg KH
2010-08-18 15:02 ` Greg KH [this message]
2010-08-19 1:18 ` [0/6] 2.6.27.52 stable review [try 3] Gabor Z. Papp
2010-08-19 14:24 ` [stable] " Greg KH
2010-08-23 22:44 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100818150557.612304949@clark.site \
--to=gregkh@suse.de \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=stable-review@kernel.org \
--cc=stable@kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.