Re: [RFC] a possible way of reducing the PITA of ->d_name audits

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

On Mon, Sep 08, 2025 at 10:05:57AM +0100, Al Viro wrote:

> > Fudging some type-state with C may well be useful but I suspect it is at
> > most part of a solution.  Simplification, documentation, run-time checks
> > might also be important parts.  As the type-state flag-day is a big
> > thing, maybe it shouldn't be first.
> 
> All of that requires being able to answer questions about what's there in
> the existing filesystems.  Which is pretty much the same problem as
> those audits, obviously.  And static annotations are way easier to
> reason about.

Speaking of annoyances, d_exact_alias() is gone, and good riddance, but there's
another fun issue in the same area - environment for d_splice_alias() call *and*
for one of those d_drop()-just-in-case.

The call tree is still the same:
_nfs4_open_and_get_state()
	<- _nfs4_do_open()
		<- nfs4_do_open()
			<- nfs4_atomic_open()
				== nfs_rpc_ops:open_context
					<- nfs_atomic_open()
						== ->atomic_open
					<- nfs4_file_open()
						== ->open
			<- nfs4_proc_create()
				== nfs_rpc_ops:create
					<- nfs_do_create()
						<- nfs_create()
							== ->create
						<- nfs_atomic_open_v23(), with O_CREAT
							== ->atomic_open
							# won't reach nfs4 stuff?

->create() and ->atomic_open() have the parent held at least shared;
->open() does not, but the chunk in question is hit only if dentry
is negative, which won't happen in case of ->open().

Additional complication comes from the possibility for _nfs4_open_and_get_state()
to fail after that d_splice_alias().  In that case we have _nfs4_do_open()
return an error; its caller is inside a do-while loop in nfs4_do_open() and
I think we can't end up going around the loop after such late failure (the
only error possible after that is -EACCES/-NFS4ERR_ACCESS and that's not one
of those that can lead to more iterations.

	However, looking at that late failure, that's the only call of
nfs4_opendata_access(), and that function seems to expect the possibility
of state->inode being a directory; can that really happen?

	Because if it can, we have a problem:
                alias = d_splice_alias(igrab(state->inode), dentry);
                /* d_splice_alias() can't fail here - it's a non-directory */
                if (alias) {
                        dput(ctx->dentry);
                        ctx->dentry = dentry = alias;
                }
very much *can* fail if it's reached with state->inode being a directory -
we can get ERR_PTR() out of that d_splice_alias() and that will oops at

        if (d_inode(dentry) == state->inode)
                nfs_inode_attach_open_context(ctx);
shortly afterwards (incidentally, what is that check about?  It can only
fail in case of nfs4_file_open(); should we have open(2) succeed in such
situation?)

Sigh...