[lkml]   [2013]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
Subject[ 039/184] mm: fix invalidate_complete_page2() lock ordering
2.6.32-longterm review patch.  If anyone has any objections, please let me know.


From: Hugh Dickins <>

commit ec4d9f626d5908b6052c2973f37992f1db52e967 upstream.

In fuzzing with trinity, lockdep protested "possible irq lock inversion
dependency detected" when isolate_lru_page() reenabled interrupts while
still holding the supposedly irq-safe tree_lock:


isolate_lru_page() is correct to enable interrupts unconditionally:
invalidate_complete_page2() is incorrect to call clear_page_mlock() while
holding tree_lock, which is supposed to nest inside lru_lock.

Both truncate_complete_page() and invalidate_complete_page() call
clear_page_mlock() before taking tree_lock to remove page from radix_tree.
I guess invalidate_complete_page2() preferred to test PageDirty (again)
under tree_lock before committing to the munlock; but since the page has
already been unmapped, its state is already somewhat inconsistent, and no
worse if clear_page_mlock() moved up.

Reported-by: Sasha Levin <>
Deciphered-by: Andrew Morton <>
Signed-off-by: Hugh Dickins <>
Acked-by: Mel Gorman <>
Cc: Rik van Riel <>
Cc: Johannes Weiner <>
Cc: Michel Lespinasse <>
Cc: Ying Han <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Willy Tarreau <>
mm/truncate.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/truncate.c b/mm/truncate.c
index 258bda7..b41d26d 100644
--- a/mm/truncate.c
+++ b/mm/truncate.c
@@ -376,11 +376,12 @@ invalidate_complete_page2(struct address_space *mapping, struct page *page)
if (page_has_private(page) && !try_to_release_page(page, GFP_KERNEL))
return 0;

+ clear_page_mlock(page);
if (PageDirty(page))
goto failed;

- clear_page_mlock(page);

 \ /
  Last update: 2013-06-05 04:21    [W:0.696 / U:2.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site