On Mon, 08 Sep 2025, Al Viro wrote: > On Mon, Sep 08, 2025 at 02:50:10PM +1000, NeilBrown wrote: > > On Mon, 08 Sep 2025, Al Viro wrote: > > > That way xfs hits will be down to that claim_stability() and the obscenity in > > > trace.h - until the users of the latter get wrapped into something that would > > > take snapshots and pass those instead of messing with ->d_name. Considering > > > the fun quoted above, not having to repeat that digging is something I'd > > > count as a win... > > > > > > > What would you think of providing an accessor function and insisting > > everyone use it - and have some sort of lockdep_assert_held() to that > > function so that developers who test their code will see these problem? > > > > Then a simple grep can find any unapproved uses. > > Really? Consider ->link(). Both arguments *are* stable, but the reasons > are not just different - they don't even intersect. Might the locking rules be too complex? Are they even documented? As you know I want to change directory locking so that a ->d_flags bit locks a dentry in much the same way that locking the parent directory currently does. I had wondered why vfs_link() locks the inode being linked and thought it was only to protect ->i_nlink. If it is needed to protect against rename too, that could usefully be documented - or we could use the same ->d_flags bit to ensure that lock. I guess I'm a bit concerned that your goal here is to transition from "lots of auditing" to "much less auditing" and I would rather it was "no auditing needed" - one day you won't want to (or be able to) audit any more. Fudging some type-state with C may well be useful but I suspect it is at most part of a solution. Simplification, documentation, run-time checks might also be important parts. As the type-state flag-day is a big thing, maybe it shouldn't be first. Thanks, NeilBrown
