From: Pratyush Yadav <pratyush@kernel.org>
To: Pratyush Yadav <pratyush@kernel.org>
Cc: Breno Leitao <leitao@debian.org>,
Changyuan Lyu <changyuanl@google.com>,
rppt@kernel.org, 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, robh@kernel.org, rostedt@goodmis.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: Mon, 13 Oct 2025 18:40:09 +0200 [thread overview]
Message-ID: <mafs0h5w2lpqu.fsf@kernel.org> (raw)
In-Reply-To: <mafs0wm4yluej.fsf@kernel.org> (Pratyush Yadav's message of "Mon, 13 Oct 2025 16:59:32 +0200")
On Mon, Oct 13 2025, Pratyush Yadav wrote:
> On Fri, Oct 10 2025, Breno Leitao wrote:
>
>> 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
>
> Yeah, it seems IMA is reserving a region that overlaps a region reserved
> by something else that doesn't use memblock_reserve_kern().
>
>> 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);
>> }
>
> I suppose this would be useful. I think enabling memblock debug prints
> would also be helpful (using the "memblock=debug" commandline parameter)
> if it doesn't impact your production environment too much.
Actually, I think "memblock=debug" is going to be the more useful thing
since it would also show what function allocated the overlapping range
and the flags it was allocated with.
On my qemu VM with KVM, this results in around 70 prints from memblock.
So it adds a bit of extra prints but nothing that should be too
disrupting I think. Plus, only at boot so the worst thing you get is
slightly slower boot times.
--
Regards,
Pratyush Yadav
next prev parent reply other threads:[~2025-10-13 16:40 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
2025-10-13 14:59 ` Pratyush Yadav
2025-10-13 16:40 ` Pratyush Yadav [this message]
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=mafs0h5w2lpqu.fsf@kernel.org \
--to=pratyush@kernel.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=leitao@debian.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=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