Re: [PATCH] eventfs: Process deletion of dentry more thoroughly

[Steven Rostedt]

On Wed, 1 Nov 2023 00:16:59 -0400
Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:

> On Wed, 1 Nov 2023 02:25:53 +0000
> Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> 
> > Umm...  Is there any reason not to use simple_recursive_removal() there?  
> 
> Hmm, I may be able to (I'm still a newbie with understanding of the vfs).
> 
> I did it this way thinking that a dentry may exist in the children but not
> at a higher level, but I don't think that can be the case. This creates
> dentries and inodes dynamically when they are referenced. The eventfs_inode
> maps to each directory (the files of a directory are created from the
> information from the eventfs_inode).

OK, as I tried to use the simple_recursive_remove() and I failed miserably!

I think I know why. What happened was the last child would get one extra
"dput" than it needed. That's because dentry's exist without any reference
on them and they don't disappear until a reclaim happens. What I mean is,
when a file is "open()'d" a dentry is created on the fly so that the user
can access the file. When it is "close()'d" the dentry count goes to zero.

Then on memory reclaim, the dentries may be removed. If another open
happens, the dentry is created again, or the one that is still cached can
be reinstated.

It looks like the simple_recursive_remove() expects all dentries to have at
least a 1 when entering, which is not the case here.

But!

Now what I could do is to do a dget() when removing the eventfs_inodes (ei)
on any dentry that is attached to them.

/me goes and tries that...

OK, that actually seems to work. With the assumption that there will never
be dentry without a parent I think I can go this approach.

Thanks!

-- Steve