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 <kris...@collabora.com>
> > 
> > Reviewed-by: Theodore Ts'o <ty...@mit.edu>
> > 
> > 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.


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Reply via email to