On Mon, Nov 18, 2024 at 4:44 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx/ 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>
