On Mon, Dec 9, 2024 at 7:59 AM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > On Mon, Dec 09, 2024 at 07:33:00AM +0100, Mateusz Guzik wrote: > > Is there a problem retaining the lock acquire if things fail? > > > > As in maybe loop 2-3 times, but eventually take the lock to guarantee forward > > progress. > > > > I don't think there is a *real* workload where this would be a problem, > > but with core counts seen today one may be able to purposefuly introduce > > stalls when running this. > > By renaming the poor sucker back and forth in a tight loop? Would be hard > to trigger on anything short of ramfs... > > Hell knows - if anything, I was thinking about a variant that would > *not* loop at all, but take seq as an argument and return whether it > had been successful. That could be adapted to build such thing - > with "pass ->d_seq sampled value (always even) *or* call it with > the name stabilized in some other way (e.g. ->d_lock, rename_lock or > ->s_vfs_rename_mutex held) and pass 1 as argument to suppress checks" > for calling conventions. > > The thing is, when its done to a chain of ancestors of some dentry, > with rename_lock retries around the entire thing, running into ->d_seq > change pretty much guarantees that you'll need to retry the whole thing > anyway. I'm not caught up on the lists, I presume this came up with grabbing the name on execve? Indeed a variant which grabs a seq argument would work nice here, possibly with a dedicated wrapper handling the locking for standalone consumers. The VFS layer is rather inconsistent on the locking front -- as in some places try a seq-protected op once and resort to locking/erroring out, others keep looping not having forward progress guarantee at least in principle. How much of a problem it is nor is not presumably depends on the particular case. But my point is if the indefinite looping (however realistic or hypothetical) can be trivially avoided, it should be. -- Mateusz Guzik <mjguzik gmail.com>
