Re: ->atomic_open() fun (was Re: [RFC] a possible way of reducing the PITA of ->d_name audits)

[Al Viro <viro@zeniv.linux.org.uk>]

On Fri, Sep 12, 2025 at 06:49:07AM +0100, Al Viro wrote:
> On Wed, Sep 10, 2025 at 08:24:23AM +0100, Al Viro wrote:
> 
> > Note that these unwrap_dentry() are very likely to move into helpers - if some
> > function is always called with unwrapped_dentry(something) as an argument,
> > great, that's probably a candidate for struct stable_dentry.
> > 
> > I'll hold onto the current variant for now...
> 
> BTW, fun fallout from that experiment once I've got to ->atomic_open() - things
> get nicer if we teach finish_no_open() to accept ERR_PTR() for dentry:

See git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git #work.finish_no_open
Patches in followups.

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