Hello,
Observed below deadlock with quota enabled on f2fs during low memory situation.
I think during f2fs_quota_enable -> which is doing read_cache_page with __GFP_FS
flag set, due to low memory this is causing shrinker to get invoked
and thus going into a deadlock due to mutex lock in dquota. Commit details
in next patch contains the call stack.
Since I did not had the quota enabled on f2fs configuration, I could not test
this on my setup yet.
Could the community kindly review and let me know if the patch
is correct or not ?
Ritesh Harjani (1):
f2fs: Set GF_NOFS in read_cache_page_gfp while doing f2fs_quota_read
fs/f2fs/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
Quota code itself is serializing the operations by taking mutex_lock.
It seems a below deadlock can happen if GF_NOFS is not used in
f2fs_quota_read
__switch_to+0x88
__schedule+0x5b0
schedule+0x78
schedule_preempt_disabled+0x20
__mutex_lock_slowpath+0xdc //mutex owner is itself
mutex_lock+0x2c
dquot_commit+0x30 //mutex_lock(&dqopt->dqio_mutex);
dqput+0xe0
__dquot_drop+0x80
dquot_drop+0x48
f2fs_evict_inode+0x218
evict+0xa8
dispose_list+0x3c
prune_icache_sb+0x58
super_cache_scan+0xf4
do_shrink_slab+0x208
shrink_slab.part.40+0xac
shrink_zone+0x1b0
do_try_to_free_pages+0x25c
try_to_free_pages+0x164
__alloc_pages_nodemask+0x534
do_read_cache_page+0x6c
read_cache_page+0x14
f2fs_quota_read+0xa4
read_blk+0x54
find_tree_dqentry+0xe4
find_tree_dqentry+0xb8
find_tree_dqentry+0xb8
find_tree_dqentry+0xb8
qtree_read_dquot+0x68
v2_read_dquot+0x24
dquot_acquire+0x5c // mutex_lock(&dqopt->dqio_mutex);
dqget+0x238
__dquot_initialize+0xd4
dquot_initialize+0x10
dquot_file_open+0x34
f2fs_file_open+0x6c
do_dentry_open+0x1e4
vfs_open+0x6c
path_openat+0xa20
do_filp_open+0x4c
do_sys_open+0x178
Signed-off-by: Ritesh Harjani <[email protected]>
---
fs/f2fs/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 708155d..3a9a924 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -1382,7 +1382,7 @@ static ssize_t f2fs_quota_read(struct super_block *sb, int type, char *data,
while (toread > 0) {
tocopy = min_t(unsigned long, sb->s_blocksize - offset, toread);
repeat:
- page = read_mapping_page(mapping, blkidx, NULL);
+ page = read_cache_page_gfp(mapping, blkidx, GFP_NOFS);
if (IS_ERR(page)) {
if (PTR_ERR(page) == -ENOMEM) {
congestion_wait(BLK_RW_ASYNC, HZ/50);
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
On 2018/3/16 21:23, Ritesh Harjani wrote:
> Quota code itself is serializing the operations by taking mutex_lock.
> It seems a below deadlock can happen if GF_NOFS is not used in
> f2fs_quota_read
>
> __switch_to+0x88
> __schedule+0x5b0
> schedule+0x78
> schedule_preempt_disabled+0x20
> __mutex_lock_slowpath+0xdc //mutex owner is itself
> mutex_lock+0x2c
> dquot_commit+0x30 //mutex_lock(&dqopt->dqio_mutex);
> dqput+0xe0
> __dquot_drop+0x80
> dquot_drop+0x48
> f2fs_evict_inode+0x218
> evict+0xa8
> dispose_list+0x3c
> prune_icache_sb+0x58
> super_cache_scan+0xf4
> do_shrink_slab+0x208
> shrink_slab.part.40+0xac
> shrink_zone+0x1b0
> do_try_to_free_pages+0x25c
> try_to_free_pages+0x164
> __alloc_pages_nodemask+0x534
> do_read_cache_page+0x6c
> read_cache_page+0x14
> f2fs_quota_read+0xa4
> read_blk+0x54
> find_tree_dqentry+0xe4
> find_tree_dqentry+0xb8
> find_tree_dqentry+0xb8
> find_tree_dqentry+0xb8
> qtree_read_dquot+0x68
> v2_read_dquot+0x24
> dquot_acquire+0x5c // mutex_lock(&dqopt->dqio_mutex);
> dqget+0x238
> __dquot_initialize+0xd4
> dquot_initialize+0x10
> dquot_file_open+0x34
> f2fs_file_open+0x6c
> do_dentry_open+0x1e4
> vfs_open+0x6c
> path_openat+0xa20
> do_filp_open+0x4c
> do_sys_open+0x178
>
> Signed-off-by: Ritesh Harjani <[email protected]>
Reviewed-by: Chao Yu <[email protected]>
Thanks,