From: Karl Mehltretter <kmehltretter@gmail.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
stable@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Ryan Roberts <ryan.roberts@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 6.6.y] arm64: mm: clear extra idmap level before use
Date: Mon, 31 Aug 2026 13:00:34 +0200 [thread overview]
Message-ID: <apVbNN_gtowKWVhR@gmail.com> (raw)
In-Reply-To: <7f744f2a-409b-454f-bdb9-fccb5031640d@app.fastmail.com>
On Mon, Aug 31, 2026 at 08:15:52AM +0100, Ard Biesheuvel wrote:
>
>
> On Mon, 31 Aug 2026, at 07:54, Greg Kroah-Hartman wrote:
> > On Mon, Aug 31, 2026 at 07:42:47AM +0200, Karl Mehltretter wrote:
> >> The 6.6.y adaptation of commit 0e9df1c905d8 ("arm64: mm: Don't remap
> >> pgtables for allocate vs populate") removes the clearing performed by
> >> early_pgtable_alloc(). Its replacement clears allocations made by the
> >> generic page-table walkers, but 6.6's create_idmap() still allocates an
> >> extra root level directly when a sub-48-bit VA kernel is loaded
> >> sufficiently high in physical memory.
> >>
> >> memblock_phys_alloc_range() does not zero the returned memory. The direct
> >> caller therefore publishes an uncleared root page and passes it to
> >> __create_pgd_mapping(). A stale nonzero entry can trip the bad-descriptor
> >> BUG_ON or be followed as a page-table descriptor, preventing the kernel
> >> from booting.
> >>
> >> Clear the direct allocation through its linear alias before publishing it.
> >> init_clear_pgtable() also supplies the barrier required before the table
> >> descriptor becomes visible.
> >>
> >> Mainline is not affected because commit e6128a8e523c ("arm64: mm: Use
> >> 48-bit virtual addressing for the permanent ID map") removed the dynamic
> >> extra level before page-table initialization moved out of the allocator.
> >
> > Why can't we take that change instead?
> >
>
> Nope. That relies on a massive refactoring of the arm64 startup code.
>
> Can we just revert 0e9df1c905d8 (aka 54322d95309d) instead?
>
Yes, that fixes the issue too.
The commit was patch 3/3 of the following speedup series:
https://lore.kernel.org/r/20240412131908.433043-1-ryan.roberts@arm.com
Patches 1 and 2 accounted for most of the speedup.
I'll wait a bit to give the others a chance to comment.
I can send the revert as v2, or my original patch as v2 with the
missing "Assisted-by: LLM" and "Signed-off-by:" trailers.
Thanks,
Karl
next prev parent reply other threads:[~2026-08-31 11:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-31 5:42 [PATCH 6.6.y] arm64: mm: clear extra idmap level before use Karl Mehltretter
2026-08-31 5:54 ` Greg Kroah-Hartman
2026-08-31 6:15 ` Ard Biesheuvel
2026-08-31 11:00 ` Karl Mehltretter [this message]
2026-08-31 11:47 ` Greg Kroah-Hartman
2026-08-31 15:29 ` [PATCH 6.6.y v2] Revert "arm64: mm: Don't remap pgtables for allocate vs populate" Karl Mehltretter
2026-09-01 1:21 ` Sasha Levin
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=apVbNN_gtowKWVhR@gmail.com \
--to=kmehltretter@gmail.com \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=ryan.roberts@arm.com \
--cc=stable@vger.kernel.org \
--cc=will@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 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.