]> pilppa.com Git - linux-2.6-omap-h63xx.git/commit
Fix sys_remap_file_pages BUG at highmem.c:15!
authorHugh Dickins <hugh@veritas.com>
Thu, 4 Oct 2007 15:56:06 +0000 (16:56 +0100)
committerLinus Torvalds <torvalds@woody.linux-foundation.org>
Thu, 4 Oct 2007 17:13:09 +0000 (10:13 -0700)
commit16abfa086096895d438b19198e408ee96da7b508
tree1d82091f35f069d7b2a7636b5f488987671bdade
parent804b3f9a16e446cb023417faec58b6506c834052
Fix sys_remap_file_pages BUG at highmem.c:15!

Gurudas Pai reports kernel BUG at arch/i386/mm/highmem.c:15! below
sys_remap_file_pages, while running Oracle database test on x86 in 6GB
RAM: kunmap thinks we're in_interrupt because the preempt count has
wrapped.

That's because __do_fault expected to unmap page_table, but one of its
two callers do_nonlinear_fault already unmapped it: let do_linear_fault
unmap it first too, and then there's no need to pass the page_table arg
down.

Why have we been so slow to notice this? Probably through forgetting
that the mapping_cap_account_dirty test means that sys_remap_file_pages
nowadays only goes the full nonlinear vma route on a few memory-backed
filesystems like ramfs, tmpfs and hugetlbfs.

[ It also depends on CONFIG_HIGHPTE, so it becomes even harder to
  trigger in practice. Many who have need of large memory have probably
  migrated to x86-64..

  Problem introduced by commit d0217ac04ca6591841e5665f518e38064f4e65bd
  ("mm: fault feedback #1")                -- Linus ]

Signed-off-by: Hugh Dickins <hugh@veritas.com>
Cc: gurudas pai <gurudas.pai@oracle.com>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
mm/memory.c