From: "Darrick J. Wong" <djwong@kernel.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-fsdevel@vger.kernel.org, joannelkoong@gmail.com,
linux-xfs@vger.kernel.org, bernd@bsbernd.com, John@groves.net
Subject: Re: [PATCH 01/11] fuse: fix livelock in synchronous file put from fuseblk workers
Date: Fri, 30 May 2025 18:08:44 -0700 [thread overview]
Message-ID: <20250531010844.GF8328@frogsfrogsfrogs> (raw)
In-Reply-To: <CAJfpegsn2eBjy27rncxYBQ1heoiA1tme8oExF-d_C9DoFq34ow@mail.gmail.com>
On Thu, May 29, 2025 at 01:08:25PM +0200, Miklos Szeredi wrote:
> On Thu, 22 May 2025 at 02:02, Darrick J. Wong <djwong@kernel.org> wrote:
>
> > Fix this by only using synchronous fputs for fuseblk servers if the
> > process doesn't have PF_LOCAL_THROTTLE. Hopefully the fuseblk server
> > had the good sense to call PR_SET_IO_FLUSHER to mark itself as a
> > filesystem server.
>
> The bug is valid.
>
> I just wonder if we really need to check against the task flag instead
> of always sending release async, which would simplify things.
>
> The sync release originates from commit 5a18ec176c93 ("fuse: fix hang
> of single threaded fuseblk filesystem"), but then commit baebccbe997d
> ("fuse: hold inode instead of path after release") made that obsolete.
>
> Anybody sees a reason why sync release for fuseblk is a good idea?
The best reason that I can think of is that normally the process that
owns the fd (and hence is releasing it) should be made to wait for
the release, because normally we want processes that generate file
activity to pay those costs. It's just this weird case where the fd
already got closed but aio is still going in the background.
(yeah, everyone hates aio ;))
Also: is it a bug that the kernel only sends FUSE_DESTROY on umount for
fuseblk filesystems? I'd have thought that you'd want to make umount
block until the fuse server is totally done. OTOH I guess I could see
an argument for not waiting for potentially hung servers, etc.
--D
> Thanks,
> Miklos
next prev parent reply other threads:[~2025-05-31 1:08 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20250521235837.GB9688@frogsfrogsfrogs>
2025-05-22 0:01 ` [PATCHSET RFC[RAP]] fuse: allow servers to use iomap for better file IO performance Darrick J. Wong
2025-05-22 0:02 ` [PATCH 01/11] fuse: fix livelock in synchronous file put from fuseblk workers Darrick J. Wong
2025-05-29 11:08 ` Miklos Szeredi
2025-05-31 1:08 ` Darrick J. Wong [this message]
2025-06-06 13:54 ` Miklos Szeredi
2025-06-09 18:13 ` Darrick J. Wong
2025-06-09 20:29 ` Darrick J. Wong
2025-05-22 0:02 ` [PATCH 02/11] iomap: exit early when iomap_iter is called with zero length Darrick J. Wong
2025-05-22 0:03 ` [PATCH 03/11] fuse: implement the basic iomap mechanisms Darrick J. Wong
2025-05-29 22:15 ` Joanne Koong
2025-05-29 23:15 ` Joanne Koong
2025-06-03 0:13 ` Darrick J. Wong
2025-05-22 0:03 ` [PATCH 04/11] fuse: add a notification to add new iomap devices Darrick J. Wong
2025-05-22 16:46 ` Amir Goldstein
2025-05-22 17:11 ` Darrick J. Wong
2025-05-22 0:03 ` [PATCH 05/11] fuse: send FUSE_DESTROY to userspace when tearing down an iomap connection Darrick J. Wong
2025-05-22 0:04 ` [PATCH 06/11] fuse: implement basic iomap reporting such as FIEMAP and SEEK_{DATA,HOLE} Darrick J. Wong
2025-05-22 0:04 ` [PATCH 07/11] fuse: implement direct IO with iomap Darrick J. Wong
2025-05-22 0:04 ` [PATCH 08/11] fuse: implement buffered " Darrick J. Wong
2025-05-22 0:04 ` [PATCH 09/11] fuse: implement large folios for iomap pagecache files Darrick J. Wong
2025-05-22 0:05 ` [PATCH 10/11] fuse: use an unrestricted backing device with iomap pagecache io Darrick J. Wong
2025-05-22 0:05 ` [PATCH 11/11] fuse: advertise support for iomap Darrick J. Wong
2025-05-22 0:21 ` [PATCHSET RFC[RAP]] fuse: allow servers to use iomap for better file IO performance Darrick J. Wong
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=20250531010844.GF8328@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=John@groves.net \
--cc=bernd@bsbernd.com \
--cc=joannelkoong@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
/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