On Sat, Mar 25, 2023 at 09:33:10AM -0400, Theodore Ts'o wrote: > On Thu, Mar 23, 2023 at 10:33:20AM -0400, Theodore Ts'o wrote: > > On Wed, Jun 22, 2022 at 03:45:57PM -0400, Gabriel Krisman Bertazi wrote: > > > Negative dentries support on case-insensitive ext4/f2fs will require > > > access to the name under lookup to ensure it matches the dentry. This > > > adds an optional new flavor of cached dentry revalidation hook to expose > > > this extra parameter. > > > > > > I'm fine with extending d_revalidate instead of adding a new hook, if > > > it is considered cleaner and the approach is accepted. I wrote a new > > > hook to simplify reviewing. > > > > > > Signed-off-by: Gabriel Krisman Bertazi <krisman@xxxxxxxxxxxxx> > > > > Reviewed-by: Theodore Ts'o <tytso@xxxxxxx> > > > > Al, could you take a look and see if you have any objections? > > Ping, Al, any objsections if I take Gabriel's patch series via the > ext4 tree? The really subtle part is ->d_name stability in there. We probably are OK as it is with the current tree (at least I hope so), but it really needs to be documented - the proof of correctness is not straightforward and it's going to be brittle; it's not obvious that this memcmp() relies upon the parent being locked in all cases when we get to calling it. And if that ever becomes not true, we have a hard-to-debug source of occasional oopsen ;-/ It can be done without reliance on locking - take a look at the vicinity of dentry_cmp() in fs/dcache.c for example of such, but it's very much not a blind memcmp(). And I suspect that it would be an overkill here. In any case, that needs to be discussed in commit message and clearly spelled out. Otherwise it's a trouble waiting to happen.
