From: Mike Rapoport <rppt@kernel.org>
To: Pratyush Yadav <ptyadav@amazon.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Alexandre Ghiti <alexghiti@rivosinc.com>,
linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH] mm/cma: make detection of highmem_start more robust
Date: Tue, 20 May 2025 08:45:19 +0300 [thread overview]
Message-ID: <aCwW70QKGFtXVxEH@kernel.org> (raw)
In-Reply-To: <mafs0plg4tgee.fsf@amazon.de>
On Mon, May 19, 2025 at 11:55:05PM +0200, Pratyush Yadav wrote:
> Hi Mike,
>
> On Mon, May 19 2025, Mike Rapoport wrote:
>
> > From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
> >
> > Pratyush Yadav reports the following crash:
> >
> > ------------[ cut here ]------------
> > kernel BUG at arch/x86/mm/physaddr.c:23!
> > ception 0x06 IP 10:ffffffff812ebbf8 error 0 cr2 0xffff88903ffff000
> > CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.15.0-rc6+ #231 PREEMPT(undef)
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014
> > RIP: 0010:__phys_addr+0x58/0x60
> > Code: 01 48 89 c2 48 d3 ea 48 85 d2 75 05 e9 91 52 cf 00 0f 0b 48 3d ff ff ff 1f 77 0f 48 8b 05 20 54 55 01 48 01 d0 e9 78 52 cf 00 <0f> 0b 90 0f 1f 44 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90
> > RSP: 0000:ffffffff82803dd8 EFLAGS: 00010006 ORIG_RAX: 0000000000000000
> > RAX: 000000007fffffff RBX: 00000000ffffffff RCX: 0000000000000000
> > RDX: 000000007fffffff RSI: 0000000280000000 RDI: ffffffffffffffff
> > RBP: ffffffff82803e68 R08: 0000000000000000 R09: 0000000000000000
> > R10: ffffffff83153180 R11: ffffffff82803e48 R12: ffffffff83c9aed0
> > R13: 0000000000000000 R14: 0000001040000000 R15: 0000000000000000
> > FS: 0000000000000000(0000) GS:0000000000000000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: ffff88903ffff000 CR3: 0000000002838000 CR4: 00000000000000b0
> > Call Trace:
> > <TASK>
> > ? __cma_declare_contiguous_nid+0x6e/0x340
> > ? cma_declare_contiguous_nid+0x33/0x70
> > ? dma_contiguous_reserve_area+0x2f/0x70
> > ? setup_arch+0x6f1/0x870
> > ? start_kernel+0x52/0x4b0
> > ? x86_64_start_reservations+0x29/0x30
> > ? x86_64_start_kernel+0x7c/0x80
> > ? common_startup_64+0x13e/0x141
> >
> > The reason is that __cma_declare_contiguous_nid() does:
> >
> > highmem_start = __pa(high_memory - 1) + 1;
> >
> > If dma_contiguous_reserve_area() (or any other CMA declaration) is
> > called before free_area_init(), high_memory is uninitialized. Without
> > CONFIG_DEBUG_VIRTUAL, it will likely work but use the wrong value for
> > highmem_start.
> >
> > The issue occurs because commit e120d1bc12da ("arch, mm: set high_memory in
> > free_area_init()") moved initialization of high_memory after the call to
> > dma_contiguous_reserve() -> __cma_declare_contiguous_nid() on several
> > architectures.
> >
> > In the case CONFIG_HIGHMEM is enabled, some architectures that actually
> > support HIGHMEM (arm, powerpc and x86) have initialization of high_memory
> > before a possible call to __cma_declare_contiguous_nid() and some
> > initialized high_memory late anyway (arc, csky, microblase, mips, sparc,
> > xtensa) even before the commit e120d1bc12da so they are fine with using
> > uninitialized value of high_memory.
>
> I don't know if they are fine or they haven't realized this is a bug
> yet.
For those that initialized high_memory in their mem_init() it would have
been a bug quite some time.
> Either way, this patch fixes the crash for me on x86_64, restores how it
> should behave, and doesn't seem to make anything worse, so:
>
> Tested-by: Pratyush Yadav <ptyadav@amazon.de>
Thanks!
> Thanks for fixing this!
>
> --
> Regards,
> Pratyush Yadav
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2025-05-20 5:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-19 17:18 [PATCH] mm/cma: make detection of highmem_start more robust Mike Rapoport
2025-05-19 21:55 ` Pratyush Yadav
2025-05-20 5:45 ` Mike Rapoport [this message]
2025-05-22 13:31 ` Pratyush Yadav
2025-05-20 8:30 ` Oscar Salvador
2025-05-20 9:14 ` David Hildenbrand
2025-05-20 15:06 ` Mike Rapoport
2025-05-20 15:08 ` David Hildenbrand
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=aCwW70QKGFtXVxEH@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alexghiti@rivosinc.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ptyadav@amazon.de \
/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.