Per discussion in [0] I'm looking for ways to refactor this code to make
ASI easier to deal with. But, while looking, I found some little things
that seem like just straightforward cleanups without any real
refactoring needed. So let's start there.

This applies to tip/master.

I'm having some infra issues so this hasn't been through Sashiko review
yet. I've tested it on QEMU. 

[0] https://lore.kernel.org/all/20250924-b4-asi-page-alloc-v1-0-2d861768041f@google.com/T/#t

Signed-off-by: Brendan Jackman <jackmanb@google.com>
---
Changes in v2:
- Simplified patchset, instead of trying to fix confusing code only to
  delete it in a subsequent patch, just delete it in the first place.
- Fixed add_pfn_range_mapped() args. (This bug causes a KASAN build to
  crash during boot).
- Link to v1: https://lore.kernel.org/r/20251003-x86-init-cleanup-v1-0-f2b7994c2ad6@google.com

---
Brendan Jackman (3):
      x86/mm: drop unused return from init_memory_mapping()
      x86/mm: simplify calculation of max_pfn_mapped
      x86/mm: drop unused returns from direct map setup functions

 arch/x86/include/asm/pgtable.h |  3 +-
 arch/x86/mm/init.c             | 19 ++++-----
 arch/x86/mm/init_32.c          |  5 +--
 arch/x86/mm/init_64.c          | 96 +++++++++++++++---------------------------
 arch/x86/mm/mm_internal.h      | 11 ++---
 5 files changed, 48 insertions(+), 86 deletions(-)
---
base-commit: 32b8f4c4b8650a879d15ca10f2462d1072e49381
change-id: 20251003-x86-init-cleanup-0ad754910bac

Best regards,
-- 
Brendan Jackman <jackmanb@google.com>

Oh, and these seems low-ish risk. But let's plan on it being material
for the next -rc1. I'd also appreciate as always if you could dig up
another person or two to review them. Both of our employers pay a kernel
developer or two and I'm sure at least one or two of them want to be
helpful.

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