On Sun, Sep 07, 2025 at 02:51:18PM -0700, Linus Torvalds wrote: > On Sun, 7 Sept 2025 at 13:32, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > > > I would like to discuss a flagday change to calling conventions > > of ->create()/->unlink()/->rename()/etc. - all directory methods. > > It would have no impact on the code generation, it would involve > > quite a bit of localized churn and it would allow to deal with catching > > ->d_name races on compiler level. > > Can you make this more concrete by actually sending an example patch. > > Well, two patches: first the patch for the "claim_stability" helper > type and functions, and then a separate patch for converting _one_ of > the users (eg 'symlink'). > > Because I have a hard time visualizing just how noisy the result would > be (and whether it would be legible end result). Will do... BTW, for a non-obvious example of the things that show up in process: ceph_wait_on_conflict_unlink() is actually guaranteed that its argument is stable. The way it copies ->d_name locally (with a good reason - there's a loop using that for comparisons, so it's a valid optimization) would otherwise be seriously racy. > And I do wonder if it might not be simpler to have a model where > filesystems always get a stable dentry name - either because we hold > the parent lock on a VFS level (fairly common, I think), or because we > pass a separate copy to the filesystem > > You did that with the d_revalidate() callback, and I think that was a > clear success. Can we extend on *that* pattern, perhaps? Umm... For one thing, there's something wrong with passing two arguments that always differ by constant offset (and type, of course)... More serious reason is that in quite a few cases we want both dentry and stable name accessible for a helper called from those (ceph_wait_on_conflict_unlink(), for example). And for those we either have to pass both dentry and const struct qstr * or we still have to trace their call chains every time we do that audit. Passing struct stable_dentry instead avoids that...
