From: sashiko-bot@kernel.org
To: "Wandun Chen" <chenwandun1@gmail.com>
Cc: robh@kernel.org, devicetree@vger.kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v6 01/10] mm: memblock: add missing HugeTLB flag name
Date: Wed, 02 Sep 2026 07:43:15 +0000 [thread overview]
Message-ID: <20260902074316.5DD551F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260902073116.802752-2-chenwandun1@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The patch adds 'RSV_HUGETLB' to the memblock debugfs flagname array, but the string is unreachable dead code. `memblock_debug_show()` iterates through the flags and breaks after printing the first matched (lowest) bit. Since `MEMBLOCK_RSRV_HUGETLB` (bit 7) is exclusively set alongside the lower-bit `MEMBLOCK_RSRV_KERN` (bit 5) flag, the loop always prints 'RSV_KERN' and breaks before reaching 'RSV_HUGETLB'.
--
commit 9e889d960694e60cb0ceee31e8dfe809d10a4085
Author: Meijing Zhao <zhaomeijing@lixiang.com>
mm: memblock: add missing HugeTLB flag name
This commit adds the missing "RSV_HUGETLB" entry to the memblock flagname
array so that debugfs can report the flag by name.
Link: https://lore.kernel.org/lkml/20260821020910.3428585-2-zhaomeijing100@gmail.com/
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 9ce86349a29fa..f2952d725c10b 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
[ ... ]
> @@ -2886,6 +2886,7 @@ static const char * const flagname[] = {
> [ilog2(MEMBLOCK_RSRV_NOINIT)] = "RSV_NIT",
> [ilog2(MEMBLOCK_RSRV_KERN)] = "RSV_KERN",
> [ilog2(MEMBLOCK_KHO_SCRATCH)] = "KHO_SCRATCH",
> + [ilog2(MEMBLOCK_RSRV_HUGETLB)] = "RSV_HUGETLB",
> };
>
> static int memblock_debug_show(struct seq_file *m, void *private)
[Severity: Medium]
Will this new string ever be printed?
Looking at memblock_debug_show(), it iterates through the flags from lowest
to highest bit and breaks after the first match:
mm/memblock.c:memblock_debug_show() {
...
for (j = 0; j < count; j++) {
if (reg->flags & (1U << j)) {
seq_printf(m, "%s\n", flagname[j]);
break;
}
}
...
}
And in memblock_alloc_hugetlb(), MEMBLOCK_RSRV_HUGETLB is allocated logically
ORed with MEMBLOCK_RSRV_KERN:
mm/memblock.c:memblock_alloc_hugetlb() {
...
if (__memblock_reserve(addr, size, nid,
MEMBLOCK_RSRV_KERN | MEMBLOCK_RSRV_HUGETLB))
...
}
Since MEMBLOCK_RSRV_KERN (bit 5) is lower than MEMBLOCK_RSRV_HUGETLB (bit 7),
does this mean the loop will always print "RSV_KERN" and break before reaching
"RSV_HUGETLB", making this addition effectively dead code?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260902073116.802752-1-chenwandun1@gmail.com?part=1
next prev parent reply other threads:[~2026-09-02 7:43 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 7:31 [PATCH v6 00/10] kdump: reduce vmcore size and capture time Wandun Chen
2026-09-02 7:31 ` Wandun Chen
2026-09-02 7:31 ` [PATCH v6 01/10] mm: memblock: add missing HugeTLB flag name Wandun Chen
2026-09-02 7:31 ` Wandun Chen
2026-09-02 7:43 ` sashiko-bot [this message]
2026-09-02 7:31 ` [PATCH v6 02/10] riscv: build crash_mem ranges from memblock instead of resource tree Wandun Chen
2026-09-02 7:31 ` Wandun Chen
2026-09-02 7:31 ` [PATCH v6 03/10] crash_core: fold duplicated memblock arch hooks into the weak default Wandun Chen
2026-09-02 7:31 ` Wandun Chen
2026-09-02 7:31 ` [PATCH v6 04/10] crash_core: serialize crash header preparation against hotplug Wandun Chen
2026-09-02 7:31 ` Wandun Chen
2026-09-02 7:31 ` [PATCH v6 05/10] crash_core: replace for_each_mem_range() with for_each_mem_region() Wandun Chen
2026-09-02 7:31 ` Wandun Chen
2026-09-02 7:31 ` [PATCH v6 06/10] memblock: introduce MEMBLOCK_NODUMP flag Wandun Chen
2026-09-02 7:31 ` Wandun Chen
2026-09-02 7:31 ` [PATCH v6 07/10] of: reserved_mem: add dumpable flag to opt-in vmcore Wandun Chen
2026-09-02 7:31 ` Wandun Chen
2026-09-02 7:31 ` [PATCH v6 08/10] of: reserved_mem: mark /reserved-memory entries with MEMBLOCK_NODUMP Wandun Chen
2026-09-02 7:31 ` Wandun Chen
2026-09-03 7:32 ` Marek Szyprowski
2026-09-03 7:32 ` Marek Szyprowski
2026-09-02 7:31 ` [PATCH v6 09/10] of: reserved_mem: mark /memreserve/ entries as MEMBLOCK_NODUMP Wandun Chen
2026-09-02 7:31 ` Wandun Chen
2026-09-02 9:02 ` sashiko-bot
2026-09-03 7:32 ` Marek Szyprowski
2026-09-03 7:32 ` Marek Szyprowski
2026-09-02 7:31 ` [PATCH v6 10/10] crash_core: skip MEMBLOCK_NODUMP regions when building vmcore ELF header Wandun Chen
2026-09-02 7:31 ` Wandun Chen
2026-09-02 8:53 ` [PATCH v6 00/10] kdump: reduce vmcore size and capture time Baoquan He
2026-09-02 8:53 ` Baoquan He
2026-09-03 7:05 ` Wandun
2026-09-03 7:05 ` Wandun
2026-09-03 7:31 ` Baoquan He
2026-09-03 7:31 ` Baoquan He
2026-09-03 7:43 ` Wandun
2026-09-03 7:43 ` Wandun
2026-09-03 9:38 ` Baoquan He
2026-09-03 9:38 ` Baoquan He
2026-09-04 11:08 ` Chen Wandun
2026-09-04 11:08 ` Chen Wandun
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=20260902074316.5DD551F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=chenwandun1@gmail.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--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.