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(-)
next 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.