Devicetree
 help / color / mirror / Atom feed
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

  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