Re: PROBLEM: FUSE_NOTIFY_INVAL_ENTRY leaves stale negative dentry after c9ba789dad15

On Thu, 04 Jun 2026, Miklos Szeredi wrote:
> On Thu, 4 Jun 2026 at 11:43, NeilBrown <[email protected]> wrote:
> 
> > My guess is you refer to the need for retry-on-error.
> > I need that design so that locking can be pushed closer to the
> > filesystem and ultimately, in some cases, removed.
> 
> Aha, but this is filesystem code, we don't need or want to move it
> closer to the filesystem, it's already there.
> 
> > It is a lot like the reason that we often use cmp-xchg loops instead of
> > holding a spinlock while performing a simple operation.  The code is
> > more complex but it scales better.
> 
> Okay, so this is about making VFS more scalable?  Can't we just leave
> filesystem code alone in that case?

yes and no...

Some things in filesystems do need to change - particularly some uses of
d_drop() and all of d_rehash(), though they don't apply here.
And as I am changing what inode_lock() protects for directories I
needed to review all uses.  As I was providing new interfaces I wanted
to be sure those interfaces were capable of handling all use-cases, so
my goal was to convert all uses of inode_lock() on directories.

However I did take that too far here.  As you helpfully point out, I
don't need to change this code at all.  It only involves fuse code
taking locks on a fuse filesystem, and this usage isn't problematic for
the new scheme (as it would be if, for example, d_alloc_parallel() was
called while the directory was locked).

So I now see that I don't need to make any changes here - thanks for
helping me see that.

Thanks for fixing the mess I made.

NeilBrown
(with apologies for the long delay in replying).