linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Miklos Szeredi <miklos@szeredi.hu>
To: Kassey Li <quic_yingangl@quicinc.com>
Cc: linux-fsdevel@vger.kernel.org, quic_maow@quicinc.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fuse: fix the deadlock in race of reclaim path with kswapd
Date: Mon, 5 Sep 2022 15:28:21 +0200	[thread overview]
Message-ID: <CAJfpegs6Jbr8eF9ZNycEjfCtJNVQJECjFnOC9-v8WSXHvpWxCg@mail.gmail.com> (raw)
In-Reply-To: <20220905071744.8350-1-quic_yingangl@quicinc.com>

On Mon, 5 Sept 2022 at 09:17, Kassey Li <quic_yingangl@quicinc.com> wrote:
>
> Task A wait for writeback, while writeback Task B send request to fuse.
> Task C is expected to serve this request, here it is in direct reclaim
> path cause deadlock when system is in low memory.
>
> without __GFP_FS in Task_C break throttle_direct_reclaim with an
> HZ timeout.
>
> kswpad (Task_A):                    writeback(Task_B):
>     __switch_to+0x14c                   schedule+0x70
>     __schedule+0xb5c                    __fuse_request_send+0x154
>     schedule+0x70                       fuse_simple_request+0x184
>     bit_wait+0x18                       fuse_flush_times+0x114
>     __wait_on_bit+0x74                  fuse_write_inode+0x60
>     inode_wait_for_writeback+0xa4       __writeback_single_inode+0x3d8
>     evict+0xa8                          writeback_sb_inodes+0x4c0
>     iput+0x248                          __writeback_inodes_wb+0xb0
>     dentry_unlink_inode+0xdc            wb_writeback+0x270
>     __dentry_kill[jt]+0x110             wb_workfn+0x37c
>     shrink_dentry_list+0x17c            process_one_work+0x284
>     prune_dcache_sb+0x5c
>     super_cache_scan+0x11c
>     do_shrink_slab+0x248
>     shrink_slab+0x260
>     shrink_node+0x678
>     kswapd+0x8ec
>     kthread+0x140
>     ret_from_fork+0x10
>
> Task_C:
>     __switch_to+0x14c
>     __schedule+0xb5c
>     schedule+0x70
>     throttle_direct_reclaim
>     try_to_free_pages
>     __perform_reclaim
>     __alloc_pages_direct_reclaim
>     __alloc_pages_slowpath
>     __alloc_pages_nodemask
>     alloc_pages
>     fuse_copy_fill+0x168
>     fuse_dev_do_read+0x37c
>     fuse_dev_splice_read+0x94

Should already be fixed in v5.16 by commit 5c791fe1e2a4 ("fuse: make
sure reclaim doesn't write the inode").

Thanks,
Miklos

  reply	other threads:[~2022-09-05 13:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-05  7:17 [PATCH] fuse: fix the deadlock in race of reclaim path with kswapd Kassey Li
2022-09-05 13:28 ` Miklos Szeredi [this message]
2022-09-06  0:29   ` Kassey Li

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=CAJfpegs6Jbr8eF9ZNycEjfCtJNVQJECjFnOC9-v8WSXHvpWxCg@mail.gmail.com \
    --to=miklos@szeredi.hu \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quic_maow@quicinc.com \
    --cc=quic_yingangl@quicinc.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).