linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Ye Liu <ye.liu@linux.dev>
To: Stephen Brennan <stephen.s.brennan@oracle.com>,
	akpm@linux-foundation.org
Cc: linux-debuggers@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, linux-toolchains@vger.kernel.org,
	osandov@osandov.com, paulmck@kernel.org,
	sweettea-kernel@dorminy.me, liuye@kylinos.cn, fweimer@redhat.com,
	sj@kernel.org
Subject: Re: [PATCH v4] tools/mm: Add script to display page state for a given PID and VADDR
Date: Fri, 30 May 2025 11:09:12 +0800	[thread overview]
Message-ID: <1f8af317-2fff-4a1f-ad0e-9d9c6c15f3a1@linux.dev> (raw)
In-Reply-To: <87iklkadzy.fsf@oracle.com>

[-- Attachment #1: Type: text/plain, Size: 14083 bytes --]


在 2025/5/29 00:36, Stephen Brennan 写道:
> Hi Ye,
>
> I just wanted to leave a code review related to the drgn/Python elements
> of this patch. I'm no mm expert, and most of the things I'm flagging
> here are small changes that I don't think are critical.
>
> Ye Liu <ye.liu@linux.dev> writes:
>> From: Ye Liu <liuye@kylinos.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 0x7fb3eb1b2000
>> PID: 1 Comm: systemd mm: 0xffff8d27279f9cc0
>> Raw: 0017ffffc000416c fffff31105a61b08 fffff31105a63608 ffff8d27121326a8
>> Raw: 0000000000000000 ffff8d271b9dcc40 0000002500000007 ffff8d2711f12700
>> User Virtual Address: 0x7fb3eb1b2000
>> Page Address:         0xfffff31106356a00
>> Page Flags:           PG_referenced|PG_uptodate|PG_lru|PG_head|PG_active|
>>                       PG_private|PG_reported|PG_has_hwpoisoned
>> Page Size:            4096
>> Page PFN:             0x18d5a8
>> Page Physical:        0x18d5a8000
>> Page Virtual:         0xffff8d274d5a8000
>> Page Refcount:        37
>> Page Mapcount:        7
>> Page Index:           0x0
>> Page Memcg Data:      0xffff8d2711f12700
>> Memcg Name:           init.scope
>> Memcg Path:           /sys/fs/cgroup/memory/init.scope
>> Page Mapping:         0xffff8d27121326a8
>> Page Anon/File:       File
>> Page VMA:             0xffff8d26cac47600
>> VMA Start:            0x7fb3eb1b2000
>> VMA End:              0x7fb3eb1b6000
>> This page is part of a compound page.
>> This page is the head page of a compound page.
>> Head Page:            0xfffff31106356a00
>> Compound Order:       2
>> Number of Pages:      4
>>
>> Signed-off-by: Ye Liu <liuye@kylinos.cn>
>>
>> Changes in v4:
>> - Add error and exception handling.
>> - Adjust the way to obtain PAGE_SIZE.
>> - Fix the acquisition of memcg.
>> - Link to v3:https://lore.kernel.org/all/20250423014850.344501-1-ye.liu@linux.dev/
>>
>> Changes in v3:
>> - Adjust display style.
>> - Link to v2:https://lore.kernel.org/all/20250421080748.114750-1-ye.liu@linux.dev/
>>
>> Changes in v2:
>> - Move the show_page_info.py file to tools/mm.
>> - Link to v1: https://lore.kernel.org/all/20250415075024.248232-1-ye.liu@linux.dev/
>> ---
>>  MAINTAINERS                |   5 ++
>>  tools/mm/show_page_info.py | 152 +++++++++++++++++++++++++++++++++++++
>>  2 files changed, 157 insertions(+)
>>  create mode 100755 tools/mm/show_page_info.py
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 0cb9e55021cb..3cbd46bf1eab 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -18726,6 +18726,11 @@ F:	Documentation/mm/page_table_check.rst
>>  F:	include/linux/page_table_check.h
>>  F:	mm/page_table_check.c
>>  
>> +PAGE STATE DEBUG SCRIPT
>> +M:	Ye Liu <liuye@kylinos.cn>
>> +S:	Maintained
>> +F:	tools/mm/show_page_info.py
>> +
>>  PANASONIC LAPTOP ACPI EXTRAS DRIVER
>>  M:	Kenneth Chan <kenneth.t.chan@gmail.com>
>>  L:	platform-driver-x86@vger.kernel.org
>> diff --git a/tools/mm/show_page_info.py b/tools/mm/show_page_info.py
>> new file mode 100755
>> index 000000000000..5c46501e24f4
>> --- /dev/null
>> +++ b/tools/mm/show_page_info.py
>> @@ -0,0 +1,152 @@
>> +#!/usr/bin/env drgn
>> +# SPDX-License-Identifier: GPL-2.0-only
>> +# Copyright (C) 2025 Ye Liu <liuye@kylinos.cn>
>> +
>> +import argparse
>> +from drgn import Object, FaultError
>> +from drgn.helpers.linux import find_task, follow_page, page_size
>> +from drgn.helpers.linux.mm import (
>> +    decode_page_flags, page_to_pfn, page_to_phys, page_to_virt, vma_find,
>> +    PageSlab, PageCompound, PageHead, PageTail, compound_head, compound_order, compound_nr
>> +)
>> +from drgn.helpers.linux.cgroup import cgroup_name, cgroup_path
> Anything in "drgn.helpers.linux.*" can be imported from
> "drgn.helpers.linux" instead, which would help if any helper moved
> around from one module to another. I've recently started preferring
> that, but I don't know if it's a huge improvement. EG:
>
> from drgn.helpers.linux import (
>     PageCompound, PageHead, PageSlab, PageTail, cgroup_name,
>     cgroup_path, compound_head, compound_nr, compound_order,
>     decode_page_flags, find_task, follow_page, page_size, page_to_pfn,
>     page_to_phys, page_to_virt, vma_find,
> )
>
> Again, not sure it improves anything :)
Thanks for the suggestion! After considering the trade-offs, I prefer
keeping the current imports for clarity:
Readability: Explicit module paths (e.g., mm/, cgroup/) make helper
origins clearer.
Debugging: Functional grouping helps when analyzing code.
Both styles work, but the current approach aligns better with drgn’s
documentation and our workflow. Happy to revisit if needs change.

>> +DESC = """
>> +This is a drgn script to show the page state.
>> +For more info on drgn, visit https://github.com/osandov/drgn.
>> +"""
>> +
>> +MEMCG_DATA_OBJEXTS = 1 << 0
>> +MEMCG_DATA_KMEM = 1 << 1
>> +__NR_MEMCG_DATA_FLAGS = 1 << 2
> These are available as enums since commit 87944e2992bd2 ("mm: Introduce
> page memcg flags"). So you can access them without redeclaring their
> values like this:
>
> prog.constant("MEMCG_DATA_OBJEXTS")
>
> You can still save them as globals for efficiency.
Got it. I'll use prog.constant("MEMCG_DATA_OBJEXTS") directly.
>> +def format_page_data(data):
>> +    """Format raw page data into a readable hex dump."""
>> +    try:
>> +        chunks = [data[i:i+8] for i in range(0, len(data), 8)]
>> +        hex_chunks = ["".join(f"{b:02x}" for b in chunk[::-1]) for chunk in chunks]
>> +        lines = [" ".join(hex_chunks[i:i+4]) for i in range(0, len(hex_chunks), 4)]
>> +        return "\n".join(f"Raw: {line}" for line in lines)
>> +    except Exception as e:
>> +        return f"Error formatting page data: {e}"
> I'm thinking this would show big-endian addresses backwards, and on
> 32-bit architectures it would group the data into 8-byte words, when I
> think it would probably be more valuable to show them in the native word
> size.
>
> You could resolve the endianness issue by using Program.read_word() to
> read each individual word of memory in the correct byte order, and use
> Program.platform.flags to distinguish a 32-bit architecture so that you
> can compute each address. In fact, check print_annotated_memory() in
> drgn which has very similar logic:
>
> https://github.com/osandov/drgn/blob/main/drgn/helpers/common/memory.py
>
I'll refer to print_annotated_memory() and use Program.read_word() to
handle endianness and native word size properly.

>> +def get_memcg_info(page):
>> +    """Retrieve memory cgroup information for a page."""
>> +    try:
>> +        memcg_data = page.memcg_data.value_()
>> +        if memcg_data & MEMCG_DATA_OBJEXTS:
>> +            slabobj_ext = Object(prog, "struct slabobj_ext *", address=memcg_data & ~(__NR_MEMCG_DATA_FLAGS - 1))
> A slightly shorter and more idiomatic way to do it would be using the
> cast() function:
>
> slabobj_ext = cast("struct slabobj_ext *", memcg_data & ~(__NR_MEMCG_DATA_FLAGS - 1))
>
I'll use cast() for cleaner pointer conversion.
>> +            memcg_value = slabobj_ext.objcg.memcg.value_()
>> +        elif memcg_data & MEMCG_DATA_KMEM:
>> +            objcg = Object(prog, "struct obj_cgroup *", address=memcg_data & ~(__NR_MEMCG_DATA_FLAGS - 1))
>> +            memcg_value = objcg.memcg.value_()
>> +        else:
>> +            memcg_value = memcg_data & ~(__NR_MEMCG_DATA_FLAGS - 1)
>> +
>> +        if memcg_value == 0:
>> +            return "none", "/sys/fs/cgroup/memory/"
>> +
>> +        memcg = Object(prog, "struct mem_cgroup *", address=memcg_value)
>> +        cgrp = memcg.css.cgroup
>> +        return cgroup_name(cgrp).decode(), f"/sys/fs/cgroup/memory{cgroup_path(cgrp).decode()}"
>> +    except FaultError as e:
>> +        return "unknown", f"Error retrieving memcg info: {e}"
>> +    except Exception as e:
>> +        return "unknown", f"Unexpected error: {e}"
>> +
>> +def show_page_state(page, addr, mm, pid, task):
>> +    """Display detailed information about a page."""
>> +    try:
>> +        print(f'PID: {pid} Comm: {task.comm.string_().decode()} mm: {hex(mm)}')
>> +        try:
>> +            print(format_page_data(prog.read(page.value_(), 64)))
> Rather than hard-code the size of struct page, you can use sizeof(page).
> And in fact, all drgn Objects have a .bytes_() that will just give you
> the bytes of the object directly, which would even avoid the sizeof().
I didn't find the .bytes_() method. Can you give an example?
I used prog.type("struct page").size instead.             

> Though in this case, I'd argue for just passing the page into
> format_page_data() and letting it use Program.read_word() to read each
> word in the correct endianness, like I said above.
>
>> +        except FaultError as e:
>> +            print(f"Error reading page data: {e}")
>> +
>> +        fields = {
>> +            "User Virtual Address": hex(addr),
>> +            "Page Address": hex(page.value_()),
>> +            "Page Flags": decode_page_flags(page),
>> +            "Page Size": prog["PAGE_SIZE"].value_(),
>> +            "Page PFN": hex(page_to_pfn(page).value_()),
>> +            "Page Physical": hex(page_to_phys(page).value_()),
>> +            "Page Virtual": hex(page_to_virt(page).value_()),
>> +            "Page Refcount": page._refcount.counter.value_(),
>> +            "Page Mapcount": page._mapcount.counter.value_(),
>> +            "Page Index": hex(page.__folio_index.value_()),
>> +            "Page Memcg Data": hex(page.memcg_data.value_()),
>> +        }
>> +
>> +        memcg_name, memcg_path = get_memcg_info(page)
>> +        fields["Memcg Name"] = memcg_name
>> +        fields["Memcg Path"] = memcg_path
>> +        fields["Page Mapping"] = hex(page.mapping.value_())
>> +        fields["Page Anon/File"] = "Anon" if page.mapping.value_() & 0x1 else "File"
>> +
>> +        try:
>> +            vma = vma_find(mm, addr)
>> +            fields["Page VMA"] = hex(vma.value_())
>> +            fields["VMA Start"] = hex(vma.vm_start.value_())
>> +            fields["VMA End"] = hex(vma.vm_end.value_())
>> +        except FaultError as e:
>> +            fields["Page VMA"] = "Unavailable"
>> +            fields["VMA Start"] = "Unavailable"
>> +            fields["VMA End"] = "Unavailable"
>> +            print(f"Error retrieving VMA information: {e}")
>> +
>> +        # Calculate the maximum field name length for alignment
>> +        max_field_len = max(len(field) for field in fields)
>> +
>> +        # Print aligned fields
>> +        for field, value in fields.items():
>> +            print(f"{field}:".ljust(max_field_len + 2) + f"{value}")
>> +
>> +        # Additional information about the page
>> +        if PageSlab(page):
>> +            print("This page belongs to the slab allocator.")
>> +
>> +        if PageCompound(page):
>> +            print("This page is part of a compound page.")
>> +            if PageHead(page):
>> +                print("This page is the head page of a compound page.")
>> +            if PageTail(page):
>> +                print("This page is the tail page of a compound page.")
>> +            print(f"{'Head Page:'.ljust(max_field_len + 2)}{hex(compound_head(page).value_())}")
>> +            print(f"{'Compound Order:'.ljust(max_field_len + 2)}{compound_order(page).value_()}")
>> +            print(f"{'Number of Pages:'.ljust(max_field_len + 2)}{compound_nr(page).value_()}")
>> +        else:
>> +            print("This page is not part of a compound page.")
>> +    except FaultError as e:
>> +        print(f"Error accessing page state: {e}")
>> +    except Exception as e:
>> +        print(f"Unexpected error: {e}")
>> +
>> +def main():
>> +    """Main function to parse arguments and display page state."""
>> +    parser = argparse.ArgumentParser(description=DESC, formatter_class=argparse.RawTextHelpFormatter)
>> +    parser.add_argument('pid', metavar='PID', type=int, help='Target process ID (PID)')
>> +    parser.add_argument('vaddr', metavar='VADDR', type=str, help='Target virtual address in hexadecimal format (e.g., 0x7fff1234abcd)')
>> +    args = parser.parse_args()
>> +
>> +    try:
>> +        vaddr = int(args.vaddr, 16)
>> +    except ValueError:
>> +        print(f"Error: Invalid virtual address format: {args.vaddr}")
>> +        return
> I find it quite useful to replace things like this with:
>
>     sys.exit(f"Error: Invalid virtual address format: {args.vaddr}")
>
> Which will result in the script exiting with a non-zero exit code, and
> it will print the message to stderr, rather than stdout. All while being
> one line shorter, for the code golfers :)
Agree, I can replace it in the main() function, but in other places,
I prefer the script to continue running instead of exiting."

> The actual logic looks excellent, and most of my suggestions are just
> that: suggestions. Sorry for putting this review on v4, I should have
> sat down and done this sooner.

Thank you for the above suggestions. These revisions will be incorporated in V5.

Thanks,
Ye                                                                              

> Regards,
> Stephen
>
>> +    try:
>> +        task = find_task(args.pid)
>> +        mm = task.mm
>> +        page = follow_page(mm, vaddr)
>> +
>> +        if page:
>> +            show_page_state(page, vaddr, mm, args.pid, task)
>> +        else:
>> +            print(f"Address {hex(vaddr)} is not mapped.")
>> +    except FaultError as e:
>> +        print(f"Error accessing task or memory: {e}")
>> +    except Exception as e:
>> +        print(f"Unexpected error: {e}")
>> +
>> +if __name__ == "__main__":
>> +    main()
>> -- 
>> 2.25.1

[-- Attachment #2: Type: text/html, Size: 17899 bytes --]

  reply	other threads:[~2025-05-30  3:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-28  9:15 [PATCH v4] tools/mm: Add script to display page state for a given PID and VADDR Ye Liu
2025-05-28 16:36 ` Stephen Brennan
2025-05-30  3:09   ` Ye Liu [this message]
2025-05-30  3:29     ` Stephen Brennan
2025-05-28 23:42 ` SeongJae Park
2025-05-30  3:18   ` Ye Liu
2025-05-30 20:18     ` SeongJae Park

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1f8af317-2fff-4a1f-ad0e-9d9c6c15f3a1@linux.dev \
    --to=ye.liu@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=fweimer@redhat.com \
    --cc=linux-debuggers@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-toolchains@vger.kernel.org \
    --cc=liuye@kylinos.cn \
    --cc=osandov@osandov.com \
    --cc=paulmck@kernel.org \
    --cc=sj@kernel.org \
    --cc=stephen.s.brennan@oracle.com \
    --cc=sweettea-kernel@dorminy.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).