Re: [PATCH] eventfs: Have inodes have unique inode numbers

Steven Rostedt
2024-01-29T02:32:52Z

On Sun, 28 Jan 2024 17:42:30 -0800
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Sun, 28 Jan 2024 at 17:00, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > mkdir dummy
> > cd dummy
> > echo "Hello" > hello
> > ( sleep 10; cat ) < hello &
> > rm hello
> > cd ..
> > rmdir dummy
>
> Note that it's worth repeating that simple_recursive_removal()
> wouldn't change any of the above. It only unhashes things and makes
> them *look* gone, doing things like clearing i_nlink etc.

I know, but I already cover the above case. And that case is not what
simple_recursive_removal() is covering.

I'm worried about what can be opened after a deletion. Not what has
already been opened. The simple_recrusive_removal() is the way to clear
the dcache on those files and directories that are being removed so
that no new references can happen on them.

So, I removed the simple_recursive_removal() from the code to see what
happened. Interesting, the opposite occurred.

# cd /sys/kernel/tracing
# echo 'p:sched schedule' > kprobe_events
# ls events/kprobes
enable filter sched
# ls events/kprobes/sched
enable filter format hist hist_debug id inject trigger
# cat events/kprobes/sched/enable
0

# echo 'p:timer read_current_timer' >> kprobe_events
# ls events/kprobes
enable filter sched timer

Now delete just one kprobe (keeping the kprobes directory around)

# echo '-:sched schedule' >> kprobe_events
# ls events/kprobes/
enable filter timer

Now recreate that kprobe

# echo 'p:sched schedule' >> kprobe_events
# ls events/kprobes
enable filter sched timer

# ls events/kprobes/sched/
ls: reading directory 'events/kprobes/sched/': Invalid argument

I have no access to the directory that was deleted and recreated.

>
> But those VFS data structures would still exist, and the files that
> had them open would still continue to be open.
>
> So if you thought that simple_recursive_removal() would make the above
> kind of thing not able to happen, and that eventfs wouldn't have to
> deal with dentries that point to event_inodes that are dead, you were
> always wrong.

No but I want to shrink the dentries after the directory is removed.

Perhaps something else is the error here.

>
> simple_recursive_removal() is mostly just lipstick on a pig. It does
> cause the cached dentries that have no active use be removed earlier,
> so it has that "memory pressure" kind of effect, but it has no real
> fundamental semantic effect.

I was using it to "flush" the cache on that directory. Nothing more.

>
> Of course, for a filesystem where the dentry tree *is* the underlying
> data (ie the 'tmpfs' kind, but also things like debugfs or ipathfs,
> for example), then things are different.

Note, tracefs was built on debugfs. Only the "events" directory is
"different". The rest of /sys/kernel/tracing behaves exactly like
debugfs.

>
> There the dentries are the primary thing, and not just a cache in
> front of the backing store.
>
> But you didn't want that, and those days are long gone as far as
> tracefs is concerned.

Well, as long as eventfs is ;-)

-- Steve