Re: [PATCH] fs: touch up predicts in putname()

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

On Wed, Oct 29, 2025 at 02:49:52PM +0100, Mateusz Guzik wrote:
> 1. we already expect the refcount is 1.
> 2. path creation predicts name == iname
> 
> I verified this straightens out the asm, no functional changes.

FWIW, I think I know how to get rid of atomic there.  Doesn't
invalidate your patch...

Look:

0) get rid of audit_reusename() and aname->uptr (I have that series,
massaging it for posting at the moment).  Basically, don't have
getname et.al. called in retry loops - there are few places doing
that, and they are not hard to fix.

1) provide getname_alien(), differing from plain getname() only
in the lack of audit_getname() call.

2) have io_uring use it for references that might be handled in
a worker thread.

3) provide something like

struct filename *take_filename(struct filename **p)
{
	struct filename *res = no_free_ptr(*p);
	audit_getname(res);
	return res;
}

and have places like io_mkdirat() switch from
        ret = do_mkdirat(mkd->dfd, mkd->filename, mkd->mode);
	 
	req->flags &= ~REQ_F_NEED_CLEANUP;
to
	ret = do_mkdirat(mkd->dfd, take_filename(&mkd->filename), mkd->mode);

Voila - no need for atomic.  Prior to audit_getname() it's going to be 1;
after that only the thread that has called audit_getname() is going to see
the address of the object (and all accesses are going to be process-synchronous).
IOW, it becomes a plain int refcount.  Sure, we still want that prediction there,
but the atomicity cost is no more...

I'll post the ->uptr removal series tonight or tomorrow; figuring out the right
calling conventions for getname_alien() is the main obstacle for (1--3) ATM...