Re: [RFC PATCH] vfs: dodge strlen() in vfs_readlink() when ->i_link is populated

[Mateusz Guzik <mjguzik@gmail.com>]

On Mon, Nov 18, 2024 at 4:44 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Mon, Nov 18, 2024 at 03:51:34PM +0100, Mateusz Guzik wrote:
>
> > This is only 1.5% because of other weird slowdowns which don't need to
> > be there, notably putname using atomics. If the other crap was already
> > fixed it would be closer to 5%.
>
> Describe your plans re putname(), please.  Because we are pretty much
> certain to step on each other's toes here in the coming cycle.

I don't have immediate plans for putname, but I posted a total hack
some time ago in relation to it:
https://lore.kernel.org/all/20240604132448.101183-1-mjguzik@gmail.com/

along with this:
> The race is only possible with io_uring which has a dedicated entry
> point, thus a getname variant which takes it into account could store
> the need to use atomics as a flag in struct filename. To that end
> getname could take a boolean indicating this, fronted with some inlines
> and the current entry point renamed to __getname_flags to hide it.

> Option B is to add a routine which "upgrades" to atomics after getname
> returns, but that's a littly fishy vs audit_reusename.

> At the end of the day all spots which modify the ref could branch on the
> atomics flag.

I ended up not getting this done because there was something real off
about name caching for audit, I don't remember the details but I was
not confident the code is correct as is.

Anyhow, someone else sorting this out is most welcome.

Apart from the few things I posted I have no immediate plans to mess
with anything vfs (I do have some plans to reduce the cost of memcg
though).

-- 
Mateusz Guzik <mjguzik gmail.com>