On Sun, 7 Sept 2025 at 17:06, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> >
> > 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)...
I would expect that you *only* do this for the functions where the
name isn't stable (ie it's called without the parent locked).
So rmdir/mknod/link/etc would continue to just pass the dentry,
because the name is stable and filesystems using dentry->d_name is
perfectly fine.
Only the cases where we pass a dentry otherwise, would we do that
separate 'struct qname' - and so then the name would *not* be
'dentry->d_name', but a copy. Exactly like d_revalidate.
Of course, d_revalidate() already *had* that separate copy (created
for the lookup), and when that isn't true you would need to waste time
and effort in creating it.
Ie we'd end up using take_dentry_name_snapshot().
Would that be horribly bad?
Don't a lot of routines already have the parent locked - all the
normal functions where we actually _modify_ the directory - so the
name is stable. No?
Then, the other thing we could do is just mark "struct qstr d_name" as
'const' in struct dentry, and then the (very very few) places that
actually modify the name will have to use an alias to do the
modification.
Wouldn't that deal with at least a majority of the worries of people
playing games?
This is where you go "Oh, Linus, you sweet summer child", and shake
your head. You've been walking through the call-chains, I haven't.
Linus
