summaryrefslogtreecommitdiff
path: root/sound/mips
diff options
context:
space:
mode:
authorYu Zhao <yuzhao@google.com>2021-07-01 04:49:48 +0300
committerLinus Torvalds <torvalds@linux-foundation.org>2021-07-01 06:47:28 +0300
commit2d2b8d2b67713da5de333a8849342503a9f21c60 (patch)
tree927354b2ae89b6814e6abb59de6f5f0b27945c97 /sound/mips
parent4a8f021ba0a220a95d4251ea3f199ef693f1249b (diff)
downloadlinux-2d2b8d2b67713da5de333a8849342503a9f21c60.tar.xz
mm/vmscan.c: fix potential deadlock in reclaim_pages()
Theoretically without the protect from memalloc_noreclaim_save() and memalloc_noreclaim_restore(), reclaim_pages() can go into the block I/O layer recursively and deadlock. Querying 'reclaim_pages' in our kernel crash databases didn't yield any results. So the deadlock seems unlikely to happen. A possible explanation is that the only user of reclaim_pages(), i.e., MADV_PAGEOUT, is usually called before memory pressure builds up, e.g., on Android and Chrome OS. Under such a condition, allocations in the block I/O layer can be fulfilled without diverting to direct reclaim and therefore the recursion is avoided. Link: https://lkml.kernel.org/r/20210622074642.785473-1-yuzhao@google.com Link: https://lkml.kernel.org/r/20210614194727.2684053-1-yuzhao@google.com Signed-off-by: Yu Zhao <yuzhao@google.com> Cc: Minchan Kim <minchan@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'sound/mips')
0 files changed, 0 insertions, 0 deletions