On Thu, 1 Feb 2024 08:07:15 +0900
Masami Hiramatsu (Google) wrote:
> > Then tracefs could be nicely converted over to kernfs, and eventfs would be
> > its own entity.
>
> If so, maybe we can just make symlinks to the 'id' and 'format' from events
> under tracefs? :)
I don't think that will
On Wed, 31 Jan 2024 13:00:39 -0500
Steven Rostedt wrote:
> On Tue, 30 Jan 2024 11:03:55 -0800
> Linus Torvalds wrote:
>
> > It would probably be cleaner to make eventfs its own filesystem, or at
> > least set its own dentry ops when looking up eventfs files. But as it
> > is, only eventfs
On Tue, 30 Jan 2024 11:03:55 -0800
Linus Torvalds wrote:
> It would probably be cleaner to make eventfs its own filesystem, or at
> least set its own dentry ops when looking up eventfs files. But as it
> is, only eventfs dentries use d_fsdata, so we don't really need to split
> these things up
On Tue, Jan 30, 2024 at 07:39:55PM -0800, Linus Torvalds wrote:
> Why don't we, btw? It would be so much better if we did the
> d_release() from __d_free(). We have all that smarts in fs/dcache.c to
> decide if we need to RCU-delay it or not, and then we don't let
> filesystems use it.
Because
On Tue, 30 Jan 2024 at 18:46, Al Viro wrote:
>
> What's to stop ->d_revalidate() from being called in parallel with
> __dentry_kill()?
Oh, you're right.
For some reason I thought we did the d_release() _after_ the RCU grace
period, but we don't.
Why don't we, btw? It would be so much better if
On Tue, Jan 30, 2024 at 06:37:49PM -0800, Linus Torvalds wrote:
> On Tue, 30 Jan 2024 at 17:12, Al Viro wrote:
> >
> > > + *
> > > + * Note that d_revalidate is called potentially under RCU,
> > > + * so it can't take the eventfs mutex etc. It's fine - if
> > > + * we open a file just as it's
On Tue, 30 Jan 2024 at 17:12, Al Viro wrote:
>
> > + *
> > + * Note that d_revalidate is called potentially under RCU,
> > + * so it can't take the eventfs mutex etc. It's fine - if
> > + * we open a file just as it's marked dead, things will
> > + * still work just fine, and just see the old
On Tue, Jan 30, 2024 at 11:03:55AM -0800, Linus Torvalds wrote:
> +void eventfs_d_release(struct dentry *dentry)
> {
> - struct eventfs_inode *ei;
> -
> - mutex_lock(_mutex);
> - ei = dentry->d_fsdata;
> - if (ei) {
> - dentry->d_fsdata = NULL;
> -
On Tue, 30 Jan 2024 at 13:25, Steven Rostedt wrote:
>
> I actually find the dentry's sticking around when their ref counts go to
> zero a feature. Tracing applications will open and close the eventfs files
> many times. If the dentry were to be deleted on every close, it would need
> to be create
On Tue, 30 Jan 2024 11:03:55 -0800
Linus Torvalds wrote:
> Another thing that might be worth doing is to make all eventfs lookups
> mark their dentries as not worth caching. We could do that with
> d_delete(), but the DCACHE_DONTCACHE flag would likely be even better.
>
> As it is, the
In order for the dentries to stay up-to-date with the eventfs changes,
just add a 'd_revalidate' function that checks the 'is_freed' bit.
Also, clean up the dentry release to actually use d_release() rather
than the slightly odd d_iput() function. We don't care about the inode,
all we want to do
11 matches
Mail list logo
