[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20250531004548.170935-1-sj@kernel.org>
Date: Fri, 30 May 2025 17:45:48 -0700
From: SeongJae Park <sj@...nel.org>
To: Stephen Brennan <stephen.s.brennan@...cle.com>
Cc: SeongJae Park <sj@...nel.org>,
Ye Liu <ye.liu@...ux.dev>,
akpm@...ux-foundation.org,
linux-debuggers@...r.kernel.org,
linux-kernel@...r.kernel.org,
linux-mm@...ck.org,
linux-toolchains@...r.kernel.org,
osandov@...ndov.com,
paulmck@...nel.org,
sweettea-kernel@...miny.me,
liuye@...inos.cn,
fweimer@...hat.com
Subject: Re: [PATCH v5] tools/mm: Add script to display page state for a given PID and VADDR
On Fri, 30 May 2025 15:15:15 -0700 Stephen Brennan <stephen.s.brennan@...cle.com> wrote:
> SeongJae Park <sj@...nel.org> writes:
> > On Fri, 30 May 2025 13:58:55 +0800 Ye Liu <ye.liu@...ux.dev> wrote:
[...]
> > As reported to the previous version, I show below on my test.
> >
> > Memcg Name: unknown
> > Memcg Path: Unexpected error: 'struct kernfs_node' has no member 'parent'
> >
> > I know you explained it is an issue of drgn version on my setup, as a reply to
> > my previous report. But, could you please make the output more easy to
> > understand the problem? No strong opinion, though.
>
> This is an interesting issue.
>
> The cgroup helpers in drgn were broken by the name change of
> kernfs_node.parent to kernfs_node.__parent in Linux 6.15. This was fixed
> in drgn promptly, and the fix is included in drgn's 0.0.31 release. If
> you use that, the error should go away. In essence, 0.0.31 was the first
> drgn version to support Linux 6.15.
FYI, I'm using drgn package on Debian 12, which says
$ drgn --version
drgn 0.0.30+82.ge2b60e4b (using Python 3.11.2, elfutils 0.188, without libkdumpfile)
Also I run a kernel built from damon/next[1], which is based on 6.15-rc6.
>
> However, there's no general way to catch any drgn error and determine
> that that drgn doesn't support your kernel version (yet). The code could
> be updated for this specific issue, but it wouldn't really fix the
> general problem. I think drgn needs to include an (INFORMATIONAL ONLY)
> set of kernel versions that it has been tested on. Then, you could use
> that in a script to print a warning (or add it to your general purpose
> error handling).
Sounds like a nice plan!
> I'll look into adding this.
Thank you! I'm not urgent or having a real problem with this at the moment,
though. So, please take your time and fun!
>
> This is itself a corner case for committing drgn scripts in the kernel.
> Omar does a really excellent job with running tests on the -rc's and
> finding broken helpers promptly -- usually well ahead of the kernel
> release. But even then, there can be a delay from the fix to the next
> drgn release. The more that you rely on drgn's helpers for a script that
> you distribute in the kernel, the more likely that it will periodically
> break, and the in-tree version wouldn't work until the newer drgn
> version is released.
>
> I don't have a solution for *that*, but it's something to consider when
> deciding whether to include a script in drgn's contrib/ directory, versus
> in the kernel.
Makes sense, thank you for sharing your wise thoughts. This is very helpful to
me.
[1] https://origin.kernel.org/doc/html/latest/mm/damon/maintainer-profile.html#scm-trees
Thanks,
SJ
[...]
Powered by blists - more mailing lists