From: "Brendan Jackman" <brendan.jackman@linux.dev>
To: "Brendan Jackman" <jackmanb@google.com>,
"Ingo Molnar" <mingo@redhat.com>,
"Borislav Petkov" <bp@alien8.de>,
"Dave Hansen" <dave.hansen@linux.intel.com>, <x86@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
"Andy Lutomirski" <luto@kernel.org>,
"Peter Zijlstra" <peterz@infradead.org>,
"Thomas Gleixner" <tglx@kernel.org>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 0/3] x86/mm: some cleanups for pagetable setup code
Date: Wed, 27 May 2026 12:40:34 +0000 [thread overview]
Message-ID: <DITGSSHSBTVI.2R7LUA9N63LNI@linux.dev> (raw)
In-Reply-To: <20260503-x86-init-cleanup-v2-0-bb690bd2477c@google.com>
Hi folks,
Can someone take a look at this?
Sashiko claims to have pointed out some pre-existing issues [0]:
- No synchronisation for pfn_mapped. Maybe this could be fixed by
spraying some get_online_mems() or something? Fixing this individual
bug in isolation seems a bit pointless though, whenever I look into
data structures that get modified during hotplug I get the feeling the
synchronisation needs a pretty wide overhaul. Maybe someone else feels
differently...
- Points out that phys_p4d_init() operates on a single P4D table but
doesn't seem to check that the addresses it's operating on are within
a single PGD.
I'm pretty sure I noticed this before but assumed it was impossible
for the range to span multiple PGDs here. But now I look more
carefully I see that's not true and I think Sashiko is right here.
It also points out that the paddr >= paddr_end check looks
unreachable, which sounds plausible but I haven't thought it through
properly.
Happy to fix the latter as an additional patch but I think the rest of
this is ready for review regardless.
[0]: https://sashiko.dev/#/patchset/20260503-x86-init-cleanup-v2-0-bb690bd2477c%40google.com
Cheers,
Brendan
next prev parent reply other threads:[~2026-05-27 12:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-03 13:04 [PATCH v2 0/3] x86/mm: some cleanups for pagetable setup code Brendan Jackman
2026-05-03 13:04 ` [PATCH v2 1/3] x86/mm: drop unused return from init_memory_mapping() Brendan Jackman
2026-06-02 21:30 ` Dave Hansen
2026-05-03 13:04 ` [PATCH v2 2/3] x86/mm: simplify calculation of max_pfn_mapped Brendan Jackman
2026-06-02 21:39 ` Dave Hansen
2026-06-03 10:20 ` Brendan Jackman
2026-05-03 13:04 ` [PATCH v2 3/3] x86/mm: drop unused returns from direct map setup functions Brendan Jackman
2026-06-02 21:40 ` Dave Hansen
2026-05-27 12:40 ` Brendan Jackman [this message]
2026-06-02 21:53 ` [PATCH v2 0/3] x86/mm: some cleanups for pagetable setup code Dave Hansen
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=DITGSSHSBTVI.2R7LUA9N63LNI@linux.dev \
--to=brendan.jackman@linux.dev \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jackmanb@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@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 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.