On Fri, Mar 7, 2025 at 5:42 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > On Fri, Mar 07, 2025 at 05:11:55PM +0100, Mateusz Guzik wrote: > > Atomics are only needed for a combination of io_uring and audit. > > > > Regular file access (even with audit) gets around fine without them. > > > > With this patch 'struct filename' starts with being refcounted using > > regular ops. > > > > In order to avoid API explosion in the getname*() family, a dedicated > > routine is added to switch the obj to use atomics. > > > > This leaves the room for merely issuing getname(), not issuing the > > switch and still trying to manipulate the refcount from another thread. > > > > Catching such cases is facilitated by CONFIG_DEBUG_VFS-dependent > > tracking of who created the given filename object and having refname() > > and putname() detect if another thread is trying to modify them. > > Not a good way to handle that, IMO. > > Atomics do hurt there, but they are only plastering over the real > problem - names formed in one thread, inserted into audit context > there and operation involving them happening in a different thread. > > Refcounting avoids an instant memory corruption, but the real PITA > is in audit users of that stuff. > > IMO we should *NOT* grab an audit names slot at getname() time - > that ought to be done explicitly at later points. > > The obstacle is that currently there still are several retry loop > with getname() done in it; I've most of that dealt with, need to > finish that series. > > And yes, refcount becomes non-atomic as the result. Well yes, it was audit which caused the appearance of atomics in the first place. I was looking for an easy way out. If you have something which gets rid of the underlying problem and it is going to land in the foreseeable future, I wont be defending this approach. -- Mateusz Guzik <mjguzik gmail.com>
