summaryrefslogtreecommitdiffstats
path: root/mm/mincore.c
diff options
context:
space:
mode:
authorHugh Dickins <hughd@google.com>2010-07-30 10:58:26 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2010-07-30 18:56:09 -0700
commitde51257aa301652876ab6e8f13ea4eadbe4a3846 (patch)
tree388ee39bed1d7e362438d047b57399a28e2617f8 /mm/mincore.c
parent51c20fcced5badee0e2021c6c89f44aa3cbd72aa (diff)
downloadlinux-de51257aa301652876ab6e8f13ea4eadbe4a3846.tar.bz2
mm: fix ia64 crash when gcore reads gate area
Debian's ia64 autobuilders have been seeing kernel freeze or reboot when running the gdb testsuite (Debian bug 588574): dannf bisected to 2.6.32 62eede62dafb4a6633eae7ffbeb34c60dba5e7b1 "mm: ZERO_PAGE without PTE_SPECIAL"; and reproduced it with gdb's gcore on a simple target. I'd missed updating the gate_vma handling in __get_user_pages(): that happens to use vm_normal_page() (nowadays failing on the zero page), yet reported success even when it failed to get a page - boom when access_process_vm() tried to copy that to its intermediate buffer. Fix this, resisting cleanups: in particular, leave it for now reporting success when not asked to get any pages - very probably safe to change, but let's not risk it without testing exposure. Why did ia64 crash with 16kB pages, but succeed with 64kB pages? Because setup_gate() pads each 64kB of its gate area with zero pages. Reported-by: Andreas Barth <aba@not.so.argh.org> Bisected-by: dann frazier <dannf@debian.org> Signed-off-by: Hugh Dickins <hughd@google.com> Tested-by: dann frazier <dannf@dannf.org> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'mm/mincore.c')
0 files changed, 0 insertions, 0 deletions