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: 63+ 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-11 15:43 ` Krzysztof Kozlowski
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.