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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251031201753.GD2441659@ZenIV>
Date: Fri, 31 Oct 2025 20:17:53 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Mateusz Guzik <mjguzik@...il.com>
Cc: brauner@...nel.org, jack@...e.cz, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] fs: touch up predicts in putname()

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...