All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: linux-fsdevel@vger.kernel.org
Cc: v9fs@lists.linux.dev, Miklos Szeredi <miklos@szeredi.hu>,
	Andreas Gruenbacher <agruenba@redhat.com>,
	linux-nfs@vger.kernel.org, Hans de Goede <hansg@kernel.org>,
	linux-cifs@vger.kernel.org
Subject: [PATCHES] finish_no_open() calling conventions change
Date: Thu, 18 Sep 2025 00:24:16 +0100	[thread overview]
Message-ID: <20250917232416.GG39973@ZenIV> (raw)

	finish_no_open() dentry argument has the same conventions as
->lookup() return value - NULL for "use the dentry we expected to open",
pointer to dentry - "consume a reference to this preexisting alias".
What it does not accept is the third variant of ->lookup() - ERR_PTR(err).
Making finish_no_open() accept that as well (returning err in that case)
simplifies life in ->atomic_open(), especially since the "got a preexisting
alias" is exactly the case when we end up with a positive dentry.

	Branch (-rc5-based) is in
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.finish_no_open
Individual patches in followups.

	Please, review - if there's no objections, to -next it goes.

	Shortlog:
allow finish_no_open(file, ERR_PTR(-E...))
9p: simplify v9fs_vfs_atomic_open()
9p: simplify v9fs_vfs_atomic_open_dotl()
simplify cifs_atomic_open()
simplify vboxsf_dir_atomic_open()
simplify nfs_atomic_open_v23()
simplify fuse_atomic_open()
simplify gfs2_atomic_open()
slightly simplify nfs_atomic_open()

	Diffstat:
 fs/9p/vfs_inode.c      | 34 ++++++++++++----------------------
 fs/9p/vfs_inode_dotl.c | 15 +++++----------
 fs/fuse/dir.c          | 21 +++++++--------------
 fs/gfs2/inode.c        | 26 +++++++++-----------------
 fs/nfs/dir.c           | 18 +++++-------------
 fs/open.c              | 10 ++++++----
 fs/smb/client/dir.c    |  8 +-------
 fs/vboxsf/dir.c        | 25 +++++++++----------------
 8 files changed, 54 insertions(+), 103 deletions(-)

             reply	other threads:[~2025-09-17 23:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-17 23:24 Al Viro [this message]
2025-09-17 23:27 ` [PATCH 1/9] allow finish_no_open(file, ERR_PTR(-E...)) Al Viro
2025-09-17 23:27   ` [PATCH 2/9] 9p: simplify v9fs_vfs_atomic_open() Al Viro
2025-09-17 23:27   ` [PATCH 3/9] 9p: simplify v9fs_vfs_atomic_open_dotl() Al Viro
2025-09-17 23:27   ` [PATCH 4/9] simplify cifs_atomic_open() Al Viro
2025-09-17 23:27   ` [PATCH 5/9] simplify vboxsf_dir_atomic_open() Al Viro
2025-09-18  7:34     ` Hans de Goede
2025-09-17 23:27   ` [PATCH 6/9] simplify nfs_atomic_open_v23() Al Viro
2025-09-17 23:27   ` [PATCH 7/9] simplify fuse_atomic_open() Al Viro
2025-09-19  9:16     ` Miklos Szeredi
2025-09-17 23:27   ` [PATCH 8/9] simplify gfs2_atomic_open() Al Viro
2025-09-17 23:27   ` [PATCH 9/9] slightly simplify nfs_atomic_open() Al Viro

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=20250917232416.GG39973@ZenIV \
    --to=viro@zeniv.linux.org.uk \
    --cc=agruenba@redhat.com \
    --cc=hansg@kernel.org \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=v9fs@lists.linux.dev \
    /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.