vm: fix mlock() on stack guard page
authorLinus Torvalds <torvalds@linux-foundation.org>
Tue, 12 Apr 2011 21:15:51 +0000 (14:15 -0700)
committerBrad Figg <brad.figg@canonical.com>
Wed, 27 Apr 2011 18:41:51 +0000 (11:41 -0700)
commitfba541000ac9fe2dcc8fb3123196d860b79bb94d
tree54c5af51322d739925a60a98375805fc07b73e2c
parent5e15b1821de636117f21d0933c133641a1ed3d62
vm: fix mlock() on stack guard page

BugLink: http://bugs.launchpad.net/bugs/769042

commit 95042f9eb78a8d9a17455e2ef263f2f310ecef15 upstream.

Commit 53a7706d5ed8 ("mlock: do not hold mmap_sem for extended periods
of time") changed mlock() to care about the exact number of pages that
__get_user_pages() had brought it.  Before, it would only care about
errors.

And that doesn't work, because we also handled one page specially in
__mlock_vma_pages_range(), namely the stack guard page.  So when that
case was handled, the number of pages that the function returned was off
by one.  In particular, it could be zero, and then the caller would end
up not making any progress at all.

Rather than try to fix up that off-by-one error for the mlock case
specially, this just moves the logic to handle the stack guard page
into__get_user_pages() itself, thus making all the counts come out
right automatically.

Reported-by: Robert Święcki <robert@swiecki.net>
Cc: Hugh Dickins <hughd@google.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
mm/memory.c
mm/mlock.c