aboutsummaryrefslogtreecommitdiffstats
path: root/include/linux/ksm.h
diff options
context:
space:
mode:
authorOmar Sandoval <osandov@fb.com>2018-06-07 17:07:02 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2018-06-07 17:34:35 -0700
commit93781325da6e07af57a21f111d1f2b9f128fa397 (patch)
tree35542710adcf686003dadb55d3e6ae20036a3d36 /include/linux/ksm.h
parentmm: shmem: make stat.st_blksize return huge page size if THP is on (diff)
downloadlinux-dev-93781325da6e07af57a21f111d1f2b9f128fa397.tar.xz
linux-dev-93781325da6e07af57a21f111d1f2b9f128fa397.zip
lockdep: fix fs_reclaim annotation
While revisiting my Btrfs swapfile series [1], I introduced a situation in which reclaim would lock i_rwsem, and even though the swapon() path clearly made GFP_KERNEL allocations while holding i_rwsem, I got no complaints from lockdep. It turns out that the rework of the fs_reclaim annotation was broken: if the current task has PF_MEMALLOC set, we don't acquire the dummy fs_reclaim lock, but when reclaiming we always check this _after_ we've just set the PF_MEMALLOC flag. In most cases, we can fix this by moving the fs_reclaim_{acquire,release}() outside of the memalloc_noreclaim_{save,restore}(), althought kswapd is slightly different. After applying this, I got the expected lockdep splats. 1: https://lwn.net/Articles/625412/ Link: http://lkml.kernel.org/r/9f8aa70652a98e98d7c4de0fc96a4addcee13efe.1523778026.git.osandov@fb.com Fixes: d92a8cfcb37e ("locking/lockdep: Rework FS_RECLAIM annotation") Signed-off-by: Omar Sandoval <osandov@fb.com> Reviewed-by: Andrew Morton <akpm@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'include/linux/ksm.h')
0 files changed, 0 insertions, 0 deletions