From: Jaegeuk Kim <jaegeuk@kernel.org>
To: Rokudo Yan <wu-yan@tcl.com>
Cc: tang.ding@tcl.com, linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] f2fs: avoid deadlock in gc thread under low memory
Date: Wed, 13 Apr 2022 10:00:53 -0700 [thread overview]
Message-ID: <YlcBxSA5qYN4z1ia@google.com> (raw)
In-Reply-To: <20220413084432.1312900-1-wu-yan@tcl.com>
On 04/13, Rokudo Yan wrote:
> There is a potential deadlock in gc thread may happen
> under low memory as below:
>
> gc_thread_func
> -f2fs_gc
> -do_garbage_collect
> -gc_data_segment
> -move_data_block
> -set_page_writeback(fio.encrypted_page);
> -f2fs_submit_page_write
> as f2fs_submit_page_write try to do io merge when possible, so the
> encrypted_page is marked PG_writeback but may not submit to block
> layer immediately, if system enter low memory when gc thread try
> to move next data block, it may do direct reclaim and enter fs layer
> as below:
> -move_data_block
> -f2fs_grab_cache_page(index=?, for_write=false)
> -grab_cache_page
> -find_or_create_page
> -pagecache_get_page
> -__page_cache_alloc -- __GFP_FS is set
> -alloc_pages_node
> -__alloc_pages
> -__alloc_pages_slowpath
> -__alloc_pages_direct_reclaim
> -__perform_reclaim
> -try_to_free_pages
> -do_try_to_free_pages
> -shrink_zones
> -mem_cgroup_soft_limit_reclaim
> -mem_cgroup_soft_reclaim
> -mem_cgroup_shrink_node
> -shrink_node_memcg
> -shrink_list
> -shrink_inactive_list
> -shrink_page_list
> -wait_on_page_writeback -- the page is marked
> writeback during previous move_data_block call
>
> the gc thread wait for the encrypted_page writeback complete,
> but as gc thread held sbi->gc_lock, the writeback & sync thread
> may blocked waiting for sbi->gc_lock, so the bio contain the
> encrypted_page may nerver submit to block layer and complete the
> writeback, which cause deadlock. To avoid this deadlock condition,
> we mark the gc thread with PF_MEMALLOC_NOFS flag, then it will nerver
> enter fs layer when try to alloc cache page during move_data_block.
>
> Signed-off-by: Rokudo Yan <wu-yan@tcl.com>
> ---
> fs/f2fs/gc.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
> index e020804f7b07..cc71f77b98c8 100644
> --- a/fs/f2fs/gc.c
> +++ b/fs/f2fs/gc.c
> @@ -38,6 +38,12 @@ static int gc_thread_func(void *data)
>
> wait_ms = gc_th->min_sleep_time;
>
> + /*
> + * Make sure that no allocations from gc thread will ever
> + * recurse to the fs layer to avoid deadlock as it will
> + * hold sbi->gc_lock during garbage collection
> + */
> + memalloc_nofs_save();
I think this cannot cover all the f2fs_gc() call cases. Can we just avoid by:
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -1233,7 +1233,7 @@ static int move_data_block(struct inode *inode, block_t bidx,
CURSEG_ALL_DATA_ATGC : CURSEG_COLD_DATA;
/* do not read out */
- page = f2fs_grab_cache_page(inode->i_mapping, bidx, false);
+ page = f2fs_grab_cache_page(inode->i_mapping, bidx, true);
if (!page)
return -ENOMEM;
Thanks,
> set_freezable();
> do {
> bool sync_mode, foreground = false;
> --
> 2.25.1
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2022-04-13 17:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-13 8:44 [f2fs-dev] [PATCH] f2fs: avoid deadlock in gc thread under low memory Rokudo Yan
2022-04-13 9:46 ` Michal Hocko via Linux-f2fs-devel
2022-04-13 11:20 ` Wu Yan
2022-04-13 11:35 ` Michal Hocko via Linux-f2fs-devel
2022-04-13 17:00 ` Jaegeuk Kim [this message]
2022-04-14 1:54 ` Wu Yan
2022-04-14 2:18 ` Jaegeuk Kim
2022-04-14 2:27 ` Wu Yan
2022-04-14 2:42 ` Jaegeuk Kim
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=YlcBxSA5qYN4z1ia@google.com \
--to=jaegeuk@kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=tang.ding@tcl.com \
--cc=wu-yan@tcl.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).