/mm/

=86e3baf6a6a2b8c145f17dad7df7c6af2d6cc293'>root/mm
diff options
context:
space:
mode:
authorQi Zheng <zhengqi.arch@bytedance.com>2023-02-02 18:56:12 +0800
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2023-02-22 12:59:46 +0100
commit86e3baf6a6a2b8c145f17dad7df7c6af2d6cc293 (patch)
tree9de4aabe984c92181635cdd7bc6de3c69db2bc62 /mm
parentb184caaf62aa4ee6a5932eee555e630f34880616 (diff)
downloadlinux-86e3baf6a6a2b8c145f17dad7df7c6af2d6cc293.tar.gz
mm: shrinkers: fix deadlock in shrinker debugfs
commit badc28d4924bfed73efc93f716a0c3aa3afbdf6f upstream. The debugfs_remove_recursive() is invoked by unregister_shrinker(), which is holding the write lock of shrinker_rwsem. It will waits for the handler of debugfs file complete. The handler also needs to hold the read lock of shrinker_rwsem to do something. So it may cause the following deadlock: CPU0 CPU1 debugfs_file_get() shrinker_debugfs_count_show()/shrinker_debugfs_scan_write() unregister_shrinker() --> down_write(&shrinker_rwsem); debugfs_remove_recursive() // wait for (A) --> wait_for_completion(); // wait for (B) --> down_read_killable(&shrinker_rwsem) debugfs_file_put() -- (A) up_write() -- (B) The down_read_killable() can be killed, so that the above deadlock can be recovered. But it still requires an extra kill action, otherwise it will block all subsequent shrinker-related operations, so it's better to fix it. [akpm@linux-foundation.org: fix CONFIG_SHRINKER_DEBUG=n stub] Link: https://lkml.kernel.org/r/20230202105612.64641-1-zhengqi.arch@bytedance.com Fixes: 5035ebc644ae ("mm: shrinkers: introduce debugfs interface for memory shrinkers") Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com> Reviewed-by: Roman Gushchin <roman.gushchin@linux.dev> Cc: Kent Overstreet <kent.overstreet@gmail.com> Cc: Muchun Song <songmuchun@bytedance.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'mm')
-rw-r--r--