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 <[email protected]> wrote:

> SeongJae Park <[email protected]> writes:
> > On Fri, 30 May 2025 13:58:55 +0800 Ye Liu <[email protected]> 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

[...]