From: sashiko-bot@kernel.org
To: "Mukesh Ojha" <mukesh.ojha@oss.qualcomm.com>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v3 14/26] mm/init-mm: Annotate static information into meminspect
Date: Wed, 08 Jul 2026 07:23:47 +0000 [thread overview]
Message-ID: <20260708072347.ED88D1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260708-meminspect-v3-v3-14-7aa5a0a74d5c@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Registering `swapper_pg_dir` with a size of `sizeof(void *)` restricts the generated crash dump to only the first 8 bytes of the root page directory.
- [Medium] Linker boundaries (`_text`, `_sinittext`, etc.) are registered with an arbitrary 8-byte size, which incorrectly dumps tiny fragments of executable code rather than exporting the symbol addresses.
- [Low] Taking the address of `swapper_pg_dir` causes a fatal compilation error on architectures where it is defined as an rvalue macro.
--
--- Patch [14]: [PATCH v3 14/26] mm/init-mm: Annotate static information into meminspect ---
commit a168e74f97589c651c261ad981c839eec643f005
Author: Eugen Hristev <ehristev@kernel.org>
mm/init-mm: Annotate static information into meminspect
This commit annotates vital static information such as init_mm, swapper_pg_dir,
and various linker boundary symbols into the meminspect inspection table. The
information is stored in a dedicated section for inspection.
> diff --git a/mm/init-mm.c b/mm/init-mm.c
> index 3e792aad76261..cf53058410b17 100644
> --- a/mm/init-mm.c
> +++ b/mm/init-mm.c
[ ... ]
> @@ -19,6 +21,13 @@
>
> const struct vm_operations_struct vma_dummy_vm_ops;
>
> +MEMINSPECT_AREA_ENTRY(_sinittext, sizeof(void *));
> +MEMINSPECT_AREA_ENTRY(_einittext, sizeof(void *));
> +MEMINSPECT_AREA_ENTRY(_end, sizeof(void *));
> +MEMINSPECT_AREA_ENTRY(_text, sizeof(void *));
> +MEMINSPECT_AREA_ENTRY(_stext, sizeof(void *));
> +MEMINSPECT_AREA_ENTRY(_etext, sizeof(void *));
[Severity: Medium]
Are linker boundaries like _text intended to be registered as 8-byte
memory areas?
By registering these linker boundary addresses (e.g., _text) as memory areas
of size sizeof(void *), the kernel will include arbitrary 8-byte chunks of
memory from these addresses as PT_LOAD segments in the crash dump. This wastes
space and creates nonsensical micro-segments.
[ ... ]
> @@ -50,6 +59,9 @@ struct mm_struct init_mm = {
> INIT_MM_CONTEXT(init_mm)
> };
>
> +MEMINSPECT_SIMPLE_ENTRY(init_mm);
> +MEMINSPECT_AREA_ENTRY(swapper_pg_dir, sizeof(void *));
[Severity: High]
Does registering swapper_pg_dir with a size of sizeof(void *) restrict the
generated crash dump to only the first 8 bytes of the root page directory?
By passing sizeof(void *) instead of the actual page directory size (e.g.,
PAGE_SIZE or PTRS_PER_PGD * sizeof(pgd_t)), the dump will only contain the
first entry of the root page table. This breaks virtual-to-physical address
translation for vmalloc or kernel modules in post-mortem analysis tools like
crash.
[Severity: Low]
Will this break the build on architectures where swapper_pg_dir is defined
as an rvalue macro?
The MEMINSPECT_AREA_ENTRY macro takes the address of the provided symbol using
&(sym). On several noMMU architectures, swapper_pg_dir is defined as an rvalue
macro (e.g., ((pgd_t *) 0) or NULL). Taking the address of an rvalue results
in a compiler error.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260708-meminspect-v3-v3-0-7aa5a0a74d5c@oss.qualcomm.com?part=14
next prev parent reply other threads:[~2026-07-08 7:23 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-08 5:31 [PATCH v3 00/26] Introduce meminspect Mukesh Ojha
2026-07-08 5:31 ` [PATCH v3 01/26] kernel: " Mukesh Ojha
2026-07-08 7:21 ` sashiko-bot
2026-07-08 7:38 ` Lorenzo Stoakes
2026-07-08 13:33 ` Mukesh Ojha
2026-07-08 5:31 ` [PATCH v3 02/26] init/version: Annotate static information into meminspect Mukesh Ojha
2026-07-08 7:21 ` sashiko-bot
2026-07-08 5:31 ` [PATCH v3 03/26] mm/percpu: " Mukesh Ojha
2026-07-08 5:31 ` [PATCH v3 04/26] cpu: " Mukesh Ojha
2026-07-08 5:31 ` [PATCH v3 05/26] genirq/irqdesc: " Mukesh Ojha
2026-07-08 7:20 ` sashiko-bot
2026-07-08 7:46 ` Lorenzo Stoakes
2026-07-08 5:31 ` [PATCH v3 06/26] timers: " Mukesh Ojha
2026-07-08 5:31 ` [PATCH v3 07/26] timekeeping: Register tk_data " Mukesh Ojha
2026-07-08 7:18 ` sashiko-bot
2026-07-08 5:31 ` [PATCH v3 08/26] kernel/fork: Annotate static information " Mukesh Ojha
2026-07-08 7:16 ` sashiko-bot
2026-07-08 5:31 ` [PATCH v3 09/26] mm/page_alloc: " Mukesh Ojha
2026-07-08 5:31 ` [PATCH v3 10/26] mm/show_mem: " Mukesh Ojha
2026-07-08 5:31 ` [PATCH v3 11/26] mm/swapfile: " Mukesh Ojha
2026-07-08 7:47 ` Lorenzo Stoakes
2026-07-08 19:05 ` Mukesh Ojha
2026-07-09 14:53 ` Lorenzo Stoakes
2026-07-10 4:09 ` Christoph Hellwig
2026-07-08 5:31 ` [PATCH v3 12/26] kernel/vmcore_info: Register dynamic " Mukesh Ojha
2026-07-08 7:25 ` sashiko-bot
2026-07-08 5:31 ` [PATCH v3 13/26] kernel/configs: " Mukesh Ojha
2026-07-08 7:20 ` sashiko-bot
2026-07-08 5:31 ` [PATCH v3 14/26] mm/init-mm: Annotate static " Mukesh Ojha
2026-07-08 7:23 ` sashiko-bot [this message]
2026-07-08 7:52 ` Lorenzo Stoakes
2026-07-08 5:31 ` [PATCH v3 15/26] panic: " Mukesh Ojha
2026-07-08 5:31 ` [PATCH v3 16/26] kallsyms: " Mukesh Ojha
2026-07-08 7:23 ` sashiko-bot
2026-07-08 5:31 ` [PATCH v3 17/26] mm/mm_init: " Mukesh Ojha
2026-07-08 5:31 ` [PATCH v3 18/26] sched/core: Annotate runqueues " Mukesh Ojha
2026-07-08 7:22 ` sashiko-bot
2026-07-08 5:31 ` [PATCH v3 19/26] mm/numa: Register node data information " Mukesh Ojha
2026-07-08 7:29 ` sashiko-bot
2026-07-08 7:55 ` Lorenzo Stoakes
2026-07-08 5:31 ` [PATCH v3 20/26] mm/sparse: Register " Mukesh Ojha
2026-07-08 7:27 ` sashiko-bot
2026-07-08 5:32 ` [PATCH v3 21/26] printk: " Mukesh Ojha
2026-07-08 7:24 ` sashiko-bot
2026-07-08 7:59 ` Lorenzo Stoakes
2026-07-08 18:53 ` Mukesh Ojha
2026-07-09 8:16 ` Petr Mladek
2026-07-08 5:32 ` [PATCH v3 22/26] remoteproc: qcom: Move minidump data structures into its own header Mukesh Ojha
2026-07-08 7:23 ` sashiko-bot
2026-07-08 5:32 ` [PATCH v3 23/26] soc: qcom: Add minidump backend driver Mukesh Ojha
2026-07-08 7:26 ` sashiko-bot
2026-07-08 5:32 ` [PATCH v3 24/26] soc: qcom: smem: Add minidump platform device Mukesh Ojha
2026-07-08 5:32 ` [PATCH v3 25/26] dt-bindings: reserved-memory: Add Google Kinfo Pixel reserved memory Mukesh Ojha
2026-07-08 7:08 ` [PATCH v3 26/26] meminspect: Add debug kinfo compatible driver Mukesh Ojha
2026-07-08 7:37 ` sashiko-bot
2026-07-08 8:06 ` Lorenzo Stoakes
2026-07-08 18:46 ` Mukesh Ojha
2026-07-09 13:24 ` Petr Pavlu
2026-07-08 7:11 ` [PATCH v3 00/26] Introduce meminspect Lorenzo Stoakes
2026-07-08 8:18 ` Lorenzo Stoakes
2026-07-09 20:42 ` Mukesh Ojha
2026-07-10 1:51 ` Liam R. Howlett
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=20260708072347.ED88D1F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=mukesh.ojha@oss.qualcomm.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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