From: Christian Brauner <brauner@kernel.org>
To: NeilBrown <neilb@suse.de>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>, Jan Kara <jack@suse.cz>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3 RFC v2] change ->mkdir() and vfs_mkdir() to return a dentry
Date: Mon, 17 Feb 2025 11:47:08 +0100 [thread overview]
Message-ID: <20250217-gummihammer-kryptisch-548d0dab31a3@brauner> (raw)
In-Reply-To: <20250217053727.3368579-1-neilb@suse.de>
On Mon, Feb 17, 2025 at 04:30:02PM +1100, NeilBrown wrote:
> Here is a second attempt at this change. Guided by Al I have handled
> other file systems which don't return a hashed positive dentry on success.
>
> It is not always possible to provide a reliable answer. One example is
> that cifs might find, after successfully creating a directory, that the
> name now leads to a non-directory (due to a race with another client).
> So callers of vfs_mkdir() need to cope with successful mkdir but no
> usable dentry. There is nothing they can do to recover and must
> continue gracefully. This failre mode is detected by the returned
> dentry being unhashed.
>
> ORIGINAL DESCRIPTION - updated to reflect changes.
>
> This is a small set of patches which are needed before we can make the
> locking on directory operations more fine grained. I think they are
> useful even if we don't go that direction.
>
> Some callers of vfs_mkdir() need to operate on the resulting directory
> but cannot be guaranteed that the dentry will be hashed and positive on
> success - another dentry might have been used.
>
> This patch changes ->mkdir to return a dentry, changes several
Thanks for doing that.
> filesystems to return the correct dentry, and changes vfs_mkdir() to
> return that dentry, only performing a lookup as a last resort.
>
> I have not Cc: the developers of all the individual filesystems NFS. I
> or kernel-test-robot have build-tested all the changes. If anyone sees
> this on fs-devel and wants to provide a pre-emptive ack I will collect
> those and avoid further posting for those fs.
Once I'll merge this into async.dir it'll show up in fs-next which means
it'll get additional xfstest testing.
prev parent reply other threads:[~2025-02-17 10:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-17 5:30 [PATCH 0/3 RFC v2] change ->mkdir() and vfs_mkdir() to return a dentry NeilBrown
2025-02-17 5:30 ` [PATCH 1/3] Change inode_operations.mkdir to return struct dentry * NeilBrown
2025-02-18 12:20 ` Jan Kara
2025-02-18 22:37 ` NeilBrown
2025-02-18 13:13 ` Jeff Layton
2025-02-19 13:19 ` Christian Brauner
2025-02-17 5:30 ` [PATCH 2/3] nfs: change mkdir inode_operation to return alternate dentry if needed NeilBrown
2025-02-18 13:25 ` Jeff Layton
2025-02-17 5:30 ` [PATCH 3/3] VFS: Change vfs_mkdir() to return the dentry NeilBrown
2025-02-18 13:43 ` Jeff Layton
2025-02-19 0:33 ` NeilBrown
2025-02-17 10:47 ` Christian Brauner [this message]
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=20250217-gummihammer-kryptisch-548d0dab31a3@brauner \
--to=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@suse.de \
--cc=viro@zeniv.linux.org.uk \
/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