linux-kernel - Re: [PATCH v5] tools/mm: Add script to display page state for a given PID and VADDR

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <875xhhagp8.fsf@oracle.com>
Date: Fri, 30 May 2025 15:15:15 -0700
From: Stephen Brennan <stephen.s.brennan@...cle.com>
To: SeongJae Park <sj@...nel.org>, Ye Liu <ye.liu@...ux.dev>
Cc: SeongJae Park <sj@...nel.org>, 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

SeongJae Park <sj@...nel.org> writes:
> On Fri, 30 May 2025 13:58:55 +0800 Ye Liu <ye.liu@...ux.dev> wrote:
>
>> From: Ye Liu <liuye@...inos.cn>
>>
>> Introduces a new drgn script, `show_page_info.py`, which allows users
>> to analyze the state of a page given a process ID (PID) and a virtual
>> address (VADDR). This can help kernel developers or debuggers easily
>> inspect page-related information in a live kernel or vmcore.
>>
>> The script extracts information such as the page flags, mapping, and
>> other metadata relevant to diagnosing memory issues.
>>
>> Output example:
>> sudo ./show_page_info.py 1 0x7fc988181000
>> PID: 1 Comm: systemd mm: 0xffff8d22c4089700
>> RAW: 0017ffffc000416c fffff939062ff708 fffff939062ffe08 ffff8d23062a12a8
>> RAW: 0000000000000000 ffff8d2323438f60 0000002500000007 ffff8d23203ff500
>> Page Address:    0xfffff93905664e00
>> Page Flags:      PG_referenced|PG_uptodate|PG_lru|PG_head|PG_active|
>>                  PG_private|PG_reported|PG_has_hwpoisoned
>> Page Size:       4096
>> Page PFN:        0x159938
>> Page Physical:   0x159938000
>> Page Virtual:    0xffff8d2319938000
>> Page Refcount:   37
>> Page Mapcount:   7
>> Page Index:      0x0
>> Page Memcg Data: 0xffff8d23203ff500
>> Memcg Name:      init.scope
>> Memcg Path:      /sys/fs/cgroup/memory/init.scope
>
> 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.

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). I'll look into adding this.

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.

Stephen