From: Al Viro <viro@zeniv.linux.org.uk>
To: NeilBrown <neilb@suse.de>
Cc: Chuck Lever <chuck.lever@oracle.com>,
Christian Brauner <brauner@kernel.org>,
Jens Axboe <axboe@kernel.dk>, Oleg Nesterov <oleg@redhat.com>,
Jeff Layton <jlayton@kernel.org>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-nfs@vger.kernel.org
Subject: Re: [PATCH 1/3] nfsd: use __fput_sync() to avoid delayed closing of files.
Date: Mon, 11 Dec 2023 23:21:35 +0000 [thread overview]
Message-ID: <20231211232135.GF1674809@ZenIV> (raw)
In-Reply-To: <20231211231330.GE1674809@ZenIV>
On Mon, Dec 11, 2023 at 11:13:30PM +0000, Al Viro wrote:
> dentry_kill() means ->d_release(), ->d_iput() and anything final iput()
> could do. Including e.g. anything that might be done by afs_silly_iput(),
> with its "send REMOVE to server, wait for completion". No, that's not
> a deadlock per se, but it can stall you a bit more than you would
> probably consider tolerable... Sure, you could argue that AFS ought to
> make that thing asynchronous, but...
>
> Anyway, it won't be "safe to use in most contexts". ->mmap_lock alone
> is enough for that, and that's just the one I remember to have given
> us a lot of headache. And that's without bringing the "nfsd won't
> touch those files" cases - make it generally accessible and you get
> to audit all locks that might be taken when we close a socket, etc.
PS: put it that way - I can buy "nfsd is doing that only to regular
files and not on an arbitrary filesystem, at that; having the thread
wait on that sucker is not going to cause too much trouble"; I do *not*
buy turning it into a thing usable outside of a very narrow set of
circumstances.
next prev parent reply other threads:[~2023-12-11 23:21 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-08 3:27 [PATCH 0/3] nfsd: fully close all files in the nfsd threads NeilBrown
2023-12-08 3:27 ` [PATCH 1/3] nfsd: use __fput_sync() to avoid delayed closing of files NeilBrown
2023-12-08 15:01 ` Chuck Lever
2023-12-10 22:47 ` NeilBrown
2023-12-11 19:01 ` Chuck Lever
2023-12-11 22:04 ` NeilBrown
2023-12-12 16:17 ` Chuck Lever
2023-12-11 19:11 ` Al Viro
2023-12-11 22:23 ` NeilBrown
2023-12-11 23:13 ` Al Viro
2023-12-11 23:21 ` Al Viro [this message]
2023-12-13 0:28 ` NeilBrown
2023-12-15 18:27 ` David Laight
2023-12-15 19:35 ` Chuck Lever III
2023-12-15 22:36 ` NeilBrown
2023-12-15 18:28 ` David Laight
2023-12-16 1:50 ` Dave Chinner
2023-12-08 3:27 ` [PATCH 2/3] nfsd: Don't leave work of closing files to a work queue NeilBrown
2023-12-08 3:27 ` [PATCH 3/3] VFS: don't export flush_delayed_fput() NeilBrown
2023-12-08 11:40 ` [PATCH 0/3] nfsd: fully close all files in the nfsd threads Jeff Layton
2023-12-08 14:33 ` Jens Axboe
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=20231211232135.GF1674809@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=oleg@redhat.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 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.