[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20230915181110.1cbf1ff0@gandalf.local.home>
Date: Fri, 15 Sep 2023 18:11:10 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Ajay Kaher <akaher@...are.com>
Subject: Re: [GIT PULL] tracing: Add eventfs file to help with debugging any
more issues
On Fri, 15 Sep 2023 18:01:18 -0400
Steven Rostedt <rostedt@...dmis.org> wrote:
> > To me, if that's really a major issue, that just says "ok, this
> > eventfs abstraction was mis-designed, and hid data that the main
> > developer actually wants".
Just to clarify the objective of the show_event_dentries file was the
heisenberg effect.
Just doing a 'ls' in the eventfs will create the dentries.
I'm interested in knowing that the dentries do not exist before the 'ls',
so I look at that file to make sure they are not there.
Then I do an 'ls' where I see all the files.
I then look at the file again to make sure the ref counts are correct.
I then run a memory pressure test, and look at the file to make sure that
the dentries are all cleaned up.
For kicks I'll do another 'ls' and see all the files again.
You may be correct that once I did the above, the code could be considered
working. My fear is that something might change in vfs that causes it to
break, and this file could be useful in catching that.
But if it never breaks, then the file becomes useless, which I guess is
what you are saying.
I'll keep the code around locally, and if vfs ever changes and breaks this
code where this file helps in solving it, I'll then do another pull request
to put this file upstream ;-)
-- Steve
Powered by blists - more mailing lists