Message-ID: <20240128213249.605a7ade@rorschach.local.home>
Date: Sun, 28 Jan 2024 21:32:49 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Masami Hiramatsu <mhiramat@...nel.org>, Mathieu Desnoyers
 <mathieu.desnoyers@...icios.com>, LKML <linux-kernel@...r.kernel.org>,
 Linux Trace Devel <linux-trace-devel@...r.kernel.org>, Christian Brauner
 <brauner@...nel.org>, Ajay Kaher <ajay.kaher@...adcom.com>, Geert
 Uytterhoeven <geert@...ux-m68k.org>, linux-fsdevel
 <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH] eventfs: Have inodes have unique inode numbers

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

> On Sun, 28 Jan 2024 at 17:00, Linus Torvalds
> <torvalds@...ux-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

Powered by blists - more mailing lists