From: Pradeep P V K <ppvk@codeaurora.org>
To: miklos@szeredi.hu
Cc: linux-fsdevel@vger.kernel.org, stummala@codeaurora.org,
sayalil@codeaurora.org, Pradeep P V K <ppvk@codeaurora.org>
Subject: [PATCH V1] fuse: Remove __GFP_FS flag to avoid allocator recursing
Date: Mon, 14 Sep 2020 19:26:15 +0530 [thread overview]
Message-ID: <1600091775-10639-1-git-send-email-ppvk@codeaurora.org> (raw)
Found a deadlock between kswapd, writeback thread and fuse process
Here are the sequence of events with callstacks on the deadlock.
process#1 process#2 process#3
__switch_to+0x150 __switch_to+0x150 try_to_free_pages
__schedule+0x984 __schedule+0x984
memalloc_noreclaim_restore
schedule+0x70 schedule+0x70 __perform_reclaim
bit_wait+0x14 __fuse_request_send+0x154
__alloc_pages_direct_reclaim
__wait_on_bit+0x70 fuse_simple_request+0x174
inode_wait_for_writeback+0xa0
__alloc_pages_slowpath
fuse_flush_times+0x10c
evict+0xa4 fuse_write_inode+0x5c __alloc_pages_nodemask
iput+0x248 __writeback_single_inode+0x3d4
dentry_unlink_inode+0xd8 __alloc_pages_node
writeback_sb_inodes+0x4a0
__dentry_kill+0x160 __writeback_inodes_wb+0xac
shrink_dentry_list+0x170 alloc_pages_node
wb_writeback+0x26c fuse_copy_fill
prune_dcache_sb+0x54 wb_workfn+0x2c0 fuse_copy_one
super_cache_scan+0x114 process_one_work+0x278 fuse_read_single_forget
do_shrink_slab+0x24c worker_thread+0x26c fuse_read_forget
shrink_slab+0xa8 kthread+0x118 fuse_dev_do_read
shrink_node+0x118 fuse_dev_splice_read
kswapd+0x92c do_splice_to
do_splice
Process#1(kswapd) held an inode lock and initaited a writeback to free
the pages, as the inode superblock is fuse, process#2 forms a fuse
request. Process#3 (Fuse daemon threads) while serving process#2 request,
it requires memory(pages) and as the system is already running in low
memory it ends up in calling try_to_ free_pages(), which might now call
kswapd again, which is already stuck with an inode lock held. Thus forms
a deadlock.
So, remove __GFP_FS flag to avoid allocator recursing into the
filesystem that might already held locks.
Signed-off-by: Pradeep P V K <ppvk@codeaurora.org>
---
fs/fuse/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
index 02b3c36..2859024 100644
--- a/fs/fuse/dev.c
+++ b/fs/fuse/dev.c
@@ -708,7 +708,7 @@ static int fuse_copy_fill(struct fuse_copy_state *cs)
if (cs->nr_segs >= cs->pipe->max_usage)
return -EIO;
- page = alloc_page(GFP_HIGHUSER);
+ page = alloc_page(GFP_NOFS | __GFP_HARDWALL | __GFP_HIGHMEM);
if (!page)
return -ENOMEM;
--
2.7.4
next reply other threads:[~2020-09-14 13:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-14 13:56 Pradeep P V K [this message]
2020-09-14 14:07 ` [PATCH V1] fuse: Remove __GFP_FS flag to avoid allocator recursing Matthew Wilcox
2020-09-15 14:34 ` ppvk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1600091775-10639-1-git-send-email-ppvk@codeaurora.org \
--to=ppvk@codeaurora.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=sayalil@codeaurora.org \
--cc=stummala@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.