All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: NeilBrown <neilb@suse.de>
Cc: Christian Brauner <brauner@kernel.org>,
	Trond Myklebust <trondmy@kernel.org>,
	Anna Schumaker <anna@kernel.org>,
	linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3} Change ->mkdir() and vfs_mkdir() to return a dentry
Date: Fri, 14 Feb 2025 06:33:06 +0000	[thread overview]
Message-ID: <20250214063306.GD1977892@ZenIV> (raw)
In-Reply-To: <20250214061355.GC1977892@ZenIV>

On Fri, Feb 14, 2025 at 06:13:55AM +0000, Al Viro wrote:
> On Fri, Feb 14, 2025 at 06:00:39AM +0000, Al Viro wrote:
> 
> > 3) I'm pretty sure that NFS is *not* the only filesystem that returns
> > unhashed negative in some success cases; will need to go over the instances
> > to verify that, though.
> 
> Definitely so: in cifs_mkdir() we have
>         if ((server->ops->posix_mkdir) && (tcon->posix_extensions)) {
>                 rc = server->ops->posix_mkdir(xid, inode, mode, tcon, full_path,
>                                               cifs_sb);
>                 d_drop(direntry); /* for time being always refresh inode info */
>                 goto mkdir_out;
>         }
> There might be other cases.  hostfs is definitely like that, I'm pretty
> sure that kernfs is as well...

kernfs is actually playing fast and loose with the calling conventions there;
it does not bother with unhashing and relies upon its ->d_revalidate()
noticing and unhashing the sucker.

Another variant that would work (and follow the calling conventions)
is to have ->lookup() that leaves negatives unhashed and ->mkdir()
not bothering to hash or instantiate.

It really needs a review instance by instance.

And yes, it does look like ->lookup()-like calling conventions end up better,
especially if we make an instance return d_splice_alias() result...

  reply	other threads:[~2025-02-14  6:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-14  5:16 [PATCH 0/3} Change ->mkdir() and vfs_mkdir() to return a dentry NeilBrown
2025-02-14  5:16 ` [PATCH 1/3] Change inode_operations.mkdir to return struct dentry * NeilBrown
2025-02-15  8:09   ` kernel test robot
2025-02-17 15:58   ` kernel test robot
2025-02-14  5:16 ` [PATCH 2/3] nfs: change mkdir inode_operation to return alternate dentry if needed NeilBrown
2025-02-14  5:16 ` [PATCH 3/3] VFS: Change vfs_mkdir() to return the dentry NeilBrown
2025-02-15  4:10   ` kernel test robot
2025-02-15  6:36   ` kernel test robot
2025-02-14  6:00 ` [PATCH 0/3} Change ->mkdir() and vfs_mkdir() to return a dentry Al Viro
2025-02-14  6:13   ` Al Viro
2025-02-14  6:33     ` Al Viro [this message]
2025-02-17  3:53   ` NeilBrown

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=20250214063306.GD1977892@ZenIV \
    --to=viro@zeniv.linux.org.uk \
    --cc=anna@kernel.org \
    --cc=brauner@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=trondmy@kernel.org \
    /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.