From: Breno Leitao <leitao@debian.org>
To: Changyuan Lyu <changyuanl@google.com>, rppt@kernel.org
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
anthony.yznaga@oracle.com, arnd@arndb.de, ashish.kalra@amd.com,
benh@kernel.crashing.org, bp@alien8.de, catalin.marinas@arm.com,
corbet@lwn.net, dave.hansen@linux.intel.com,
devicetree@vger.kernel.org, dwmw2@infradead.org,
ebiederm@xmission.com, graf@amazon.com, hpa@zytor.com,
jgowans@amazon.com, kexec@lists.infradead.org, krzk@kernel.org,
linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
linux-mm@kvack.org, luto@kernel.org, mark.rutland@arm.com,
mingo@redhat.com, pasha.tatashin@soleen.com,
pbonzini@redhat.com, peterz@infradead.org, ptyadav@amazon.de,
robh@kernel.org, rostedt@goodmis.org, rppt@kernel.org,
saravanak@google.com, skinsburskii@linux.microsoft.com,
tglx@linutronix.de, thomas.lendacky@amd.com, will@kernel.org,
x86@kernel.org
Subject: Re: [PATCH v8 01/17] memblock: add MEMBLOCK_RSRV_KERN flag
Date: Fri, 10 Oct 2025 02:33:59 -0700 [thread overview]
Message-ID: <ef6wfr72set5wa5el3wbbu4yd5tnc4p2rhtjpb5kpmncv3xs5d@i3c5v3ciioi3> (raw)
In-Reply-To: <20250509074635.3187114-2-changyuanl@google.com>
Hello Chanyuan, Mike,
On Fri, May 09, 2025 at 12:46:19AM -0700, Changyuan Lyu wrote:
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -492,7 +492,7 @@ static int __init_memblock memblock_double_array(struct memblock_type *type,
> * needn't do it
> */
> if (!use_slab)
> - BUG_ON(memblock_reserve(addr, new_alloc_size));
> + BUG_ON(memblock_reserve_kern(addr, new_alloc_size));
>
> /* Update slab flag */
> *in_slab = use_slab;
> @@ -642,7 +642,7 @@ static int __init_memblock memblock_add_range(struct memblock_type *type,
> #ifdef CONFIG_NUMA
> WARN_ON(nid != memblock_get_region_node(rgn));
> #endif
> - WARN_ON(flags != rgn->flags);
> + WARN_ON(flags != MEMBLOCK_NONE && flags != rgn->flags);
I am hitting some sporadic warnings at early boot on a production kernel
(6.16). Unfortunately this issue is not easily reproduce for me to test on
upstream.
09:14:44 BIOS-provided physical RAM map:
09:14:44 BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
09:14:44 BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved
09:14:44 BIOS-e820: [mem 0x0000000000100000-0x0000000064cb7fff] usable
09:14:44 BIOS-e820: [mem 0x0000000064cb8000-0x0000000064dc3fff] reserved
09:14:44 BIOS-e820: [mem 0x0000000064dc4000-0x0000000065b13fff] usable
09:14:44 BIOS-e820: [mem 0x0000000065b14000-0x0000000065b61fff] reserved
09:14:44 BIOS-e820: [mem 0x0000000065b62000-0x0000000065ed0fff] usable
09:14:44 BIOS-e820: [mem 0x0000000065ed1000-0x0000000065f2bfff] reserved
09:14:44 BIOS-e820: [mem 0x0000000065f2c000-0x0000000066621fff] usable
09:14:44 BIOS-e820: [mem 0x0000000066622000-0x0000000066630fff] reserved
09:14:44 BIOS-e820: [mem 0x0000000066631000-0x0000000068107fff] usable
09:14:44 BIOS-e820: [mem 0x0000000068108000-0x000000006819dfff] ACPI data
09:14:44 BIOS-e820: [mem 0x000000006819e000-0x000000006a48cfff] usable
09:14:44 BIOS-e820: [mem 0x000000006a48d000-0x000000006c58cfff] reserved
09:14:44 BIOS-e820: [mem 0x000000006c58d000-0x000000006c5dcfff] ACPI data
09:14:44 BIOS-e820: [mem 0x000000006c5dd000-0x000000006cfdcfff] ACPI NVS
09:14:44 BIOS-e820: [mem 0x000000006cfdd000-0x000000006e9fcfff] reserved
09:14:44 BIOS-e820: [mem 0x000000006e9fd000-0x000000006fffffff] usable
09:14:44 BIOS-e820: [mem 0x0000000070000000-0x000000008fffffff] reserved
09:14:44 BIOS-e820: [mem 0x00000000fd000000-0x00000000fe7fffff] reserved
09:14:44 BIOS-e820: [mem 0x00000000fed20000-0x00000000fed44fff] reserved
09:14:44 BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
09:14:44 BIOS-e820: [mem 0x0000000100000000-0x000000107fff655f] usable
09:14:44 BIOS-e820: [mem 0x000000107fff6560-0x000000107fff656f] type 128
09:14:44 BIOS-e820: [mem 0x000000107fff6570-0x000000107fffffff] usable
09:14:44 random: crng init done
09:14:44 ------------[ cut here ]------------
09:14:44 WARNING: CPU: 0 PID: 0 at mm/memblock.c:668 memblock_add_range (mm/memblock.c:668)
09:14:44 Modules linked in:
09:14:44 Tainted: [S]=CPU_OUT_OF_SPEC
09:14:44 RIP: 0010:memblock_add_range (mm/memblock.c:668)
09:14:44 Code: 28 80 3c 01 00 0f 84 04 fd ff ff 4c 89 ef e8 6c 77 09 00 e9 f7 fc ff ff 0f 0b 83 7c 24 1c 00 0f 85 9c fd ff ff e9 c5 fd ff ff <0f> 0b e9 be fd ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 0f 8c 6b fd
All code
========
0: 28 80 3c 01 00 0f sub %al,0xf00013c(%rax)
6: 84 04 fd ff ff 4c 89 test %al,-0x76b30001(,%rdi,8)
d: ef out %eax,(%dx)
e: e8 6c 77 09 00 call 0x9777f
13: e9 f7 fc ff ff jmp 0xfffffffffffffd0f
18: 0f 0b ud2
1a: 83 7c 24 1c 00 cmpl $0x0,0x1c(%rsp)
1f: 0f 85 9c fd ff ff jne 0xfffffffffffffdc1
25: e9 c5 fd ff ff jmp 0xfffffffffffffdef
2a:* 0f 0b ud2 <-- trapping instruction
2c: e9 be fd ff ff jmp 0xfffffffffffffdef
31: 44 89 f1 mov %r14d,%ecx
34: 80 e1 07 and $0x7,%cl
37: 80 c1 03 add $0x3,%cl
3a: 38 c1 cmp %al,%cl
3c: 0f .byte 0xf
3d: 8c 6b fd mov %gs,-0x3(%rbx)
Code starting with the faulting instruction
===========================================
0: 0f 0b ud2
2: e9 be fd ff ff jmp 0xfffffffffffffdc5
7: 44 89 f1 mov %r14d,%ecx
a: 80 e1 07 and $0x7,%cl
d: 80 c1 03 add $0x3,%cl
10: 38 c1 cmp %al,%cl
12: 0f .byte 0xf
13: 8c 6b fd mov %gs,-0x3(%rbx)
09:14:44 RSP: 0000:ffffffff85e07d48 EFLAGS: 00010083 ORIG_RAX: 0000000000000000
09:14:44 RAX: 0000000000000020 RBX: 0000000000001c00 RCX: dffffc0000000000
09:14:44 RDX: 000000000009f000 RSI: 000000000009d000 RDI: ffffffff8685ebf8
09:14:44 RBP: 0000000000000002 R08: 0000000000000020 R09: 0000000000000000
09:14:44 R10: ffffffffff200570 R11: fffffbffffe400b2 R12: 000000000009d000
09:14:44 R13: 0000000000100000 R14: ffffffff8edf5ce4 R15: ffffffff8edf5ce0
09:14:44 FS: 0000000000000000(0000) GS:0000000000000000(0000) knlGS:0000000000000000
09:14:44 CR2: ffff888059e2dff8 CR3: 000000005bc1d000 CR4: 00000000000000b0
09:14:44 Call Trace:
09:14:44 <TASK>
09:14:44 ? __memblock_reserve (mm/memblock.c:936)
09:14:44 ? add_early_ima_buffer (arch/x86/kernel/setup.c:413)
09:14:44 ? parse_setup_data (arch/x86/kernel/setup.c:500)
09:14:44 ? setup_arch (arch/x86/kernel/setup.c:245 arch/x86/kernel/setup.c:958)
09:14:44 ? start_kernel (init/main.c:922)
09:14:44 ? x86_64_start_reservations (arch/x86/kernel/ebda.c:57)
09:14:44 ? x86_64_start_kernel (arch/x86/kernel/head64.c:231)
09:14:44 ? common_startup_64 (arch/x86/kernel/head_64.S:419)
09:14:44 </TASK>
....
Memory: 49640988K/66772816K available (54946K kernel code, 19058K rwdata, 22636K rodata, 2940K init, 120968K bss, 10650188K reserved, 6291456K cma-reserved)
So, there is a memory override, and I am curious about it. Do you think it
would be useful to expand this warning to dump more information about the
issue? (only compiled tested)
if (flags != MEMBLOCK_NONE && flags != rgn->flags) {
pr_warn("memblock: Flag mismatch at region [%pa-%pa]\n",
&rgn->base, &rend);
pr_warn(" Existing region flags: %#x\n", rgn->flags);
pr_warn(" New range flags: %#x\n", flags);
pr_warn(" New range: [%pa-%pa]\n", &base, &end);
WARN_ON_ONCE(1);
}
Thanks
--breno
next prev parent reply other threads:[~2025-10-10 9:34 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-09 7:46 [PATCH v8 00/17] kexec: introduce Kexec HandOver (KHO) Changyuan Lyu
2025-05-09 7:46 ` [PATCH v8 01/17] memblock: add MEMBLOCK_RSRV_KERN flag Changyuan Lyu
2025-10-10 9:33 ` Breno Leitao [this message]
2025-10-13 14:59 ` Pratyush Yadav
2025-10-13 16:40 ` Pratyush Yadav
2025-10-14 8:34 ` Breno Leitao
2025-10-14 13:10 ` Pratyush Yadav
2025-11-05 10:18 ` Breno Leitao
2025-11-06 8:24 ` Mike Rapoport
2025-05-09 7:46 ` [PATCH v8 02/17] memblock: Add support for scratch memory Changyuan Lyu
2025-05-09 7:46 ` [PATCH v8 03/17] memblock: introduce memmap_init_kho_scratch() Changyuan Lyu
2025-05-09 7:46 ` [PATCH v8 04/17] kexec: add Kexec HandOver (KHO) generation helpers Changyuan Lyu
2025-05-09 7:46 ` [PATCH v8 05/17] kexec: add KHO parsing support Changyuan Lyu
2025-05-09 7:46 ` [PATCH v8 06/17] kexec: enable KHO support for memory preservation Changyuan Lyu
2025-05-09 7:46 ` [PATCH v8 07/17] kexec: add KHO support to kexec file loads Changyuan Lyu
2025-05-09 7:46 ` [PATCH v8 08/17] kexec: add config option for KHO Changyuan Lyu
2025-05-09 7:46 ` [PATCH v8 09/17] arm64: add KHO support Changyuan Lyu
2025-05-09 7:46 ` [PATCH v8 10/17] x86/setup: use memblock_reserve_kern for memory used by kernel Changyuan Lyu
2025-05-09 7:46 ` [PATCH v8 11/17] x86/kexec: add support for passing kexec handover (KHO) data Changyuan Lyu
2025-05-09 7:46 ` [PATCH v8 12/17] x86/e820: temporarily enable KHO scratch for memory below 1M Changyuan Lyu
2025-11-24 19:24 ` Usama Arif
2025-11-25 0:56 ` H. Peter Anvin
2025-11-25 12:23 ` Pratyush Yadav
2025-11-25 13:53 ` Mike Rapoport
2025-11-25 13:15 ` Pratyush Yadav
2025-11-25 13:50 ` Mike Rapoport
2025-11-25 18:47 ` Usama Arif
2025-11-26 6:14 ` Mike Rapoport
2025-11-26 7:25 ` Usama Arif
2025-11-25 14:31 ` Usama Arif
2025-11-25 14:39 ` Pratyush Yadav
2025-05-09 7:46 ` [PATCH v8 13/17] x86/boot: make sure KASLR does not step over KHO preserved memory Changyuan Lyu
2025-05-09 7:46 ` [PATCH v8 14/17] x86/Kconfig: enable kexec handover for 64 bits Changyuan Lyu
2025-05-09 7:46 ` [PATCH v8 15/17] memblock: add KHO support for reserve_mem Changyuan Lyu
2025-05-09 7:46 ` [PATCH v8 16/17] Documentation: add documentation for KHO Changyuan Lyu
2025-05-09 7:46 ` [PATCH v8 17/17] Documentation: KHO: Add memblock bindings Changyuan Lyu
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=ef6wfr72set5wa5el3wbbu4yd5tnc4p2rhtjpb5kpmncv3xs5d@i3c5v3ciioi3 \
--to=leitao@debian.org \
--cc=akpm@linux-foundation.org \
--cc=anthony.yznaga@oracle.com \
--cc=arnd@arndb.de \
--cc=ashish.kalra@amd.com \
--cc=benh@kernel.crashing.org \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=changyuanl@google.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=devicetree@vger.kernel.org \
--cc=dwmw2@infradead.org \
--cc=ebiederm@xmission.com \
--cc=graf@amazon.com \
--cc=hpa@zytor.com \
--cc=jgowans@amazon.com \
--cc=kexec@lists.infradead.org \
--cc=krzk@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=pasha.tatashin@soleen.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=ptyadav@amazon.de \
--cc=robh@kernel.org \
--cc=rostedt@goodmis.org \
--cc=rppt@kernel.org \
--cc=saravanak@google.com \
--cc=skinsburskii@linux.microsoft.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=will@kernel.org \
--cc=x86@kernel.org \
/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