use notify prune from upstream

[hbirth]

No description provided.

[bsbernd]

@yongzech Please also take a look.

[hbirth]

@yongzech your patch contained the explicit invalidation of the fuse cache ... Miklos left that out. He probably relies on some mechanism that the cache will be cleaned anyway. Was there a special reason why you invalidated the fuse cache explicitly? It actually just sets the time to 0.

[yongzech]

@yongzech your patch contained the explicit invalidation of the fuse cache ... Miklos left that out. He probably relies on some mechanism that the cache will be cleaned anyway. Was there a special reason why you invalidated the fuse cache explicitly? It actually just sets the time to 0.

d_invalidate basically calls shrink_dcache_parent, but also handle submounts

[yongzech]

We already have libfuse interface for FUSE_NOTIFY_PRUNE ?

[hbirth]

no ... but we have to start at the kernel ... the libfuse code is in a PR

[yongzech]

But this only remove the children which with ref count is zero?

[yongzech]

Same here, only when d_lockref.count is zero. But when lost a lock, we need to invalidate dcache entry

[hbirth]

we do at the moment ... that's why I left that code in

[bsbernd]

I think issue with d_invalidate is if it is currently used for for something, which is why Miklos is suggesting shrink_dcache_parent()

[yongzech]

But the problem with shrink_dcache_parent and `d_prune_aliases is that, if another node delete a file whose dcache already cached in this node, then don't invalidate dcache.

[hbirth]

@yongzech your patch contained the explicit invalidation of the fuse cache ... Miklos left that out. He probably relies on some mechanism that the cache will be cleaned anyway. Was there a special reason why you invalidated the fuse cache explicitly? It actually just sets the time to 0.

d_invalidate basically calls shrink_dcache_parent, but also handle submounts

Miklos said that he does not want to dehash the dentry ... but I think WE want exactly that ... that's why I think at the moment we need both

[bsbernd]

Well, let's say something is currently actively using the dentry while it gets invalidated - the racing process would then work with an unhashed dentry. I think the critical call is

void __d_drop(struct dentry *dentry)
{
	if (!d_unhashed(dentry)) {
		___d_drop(dentry);
		dentry->d_hash.pprev = NULL;
		write_seqcount_invalidate(&dentry->d_seq);
	}
}

And there the question is if this couldn't cause a null pointer deref at some point.

[hbirth]

@yongzech do we want FUSE_NOTIFY_PRUNE?
AFAICT we need both functionalities ... the 'nice' FUSE_NOTIFY_PRUNE, that will remove all unneeded entries, if possible and the one that dehashes the dentry and invalidates it reliably, because we lost a lock.