[PATCH 6.12.y 0/2] Fix ioremap of addresses above 4 GiB on x86-32 PAE

[PATCH 6.12.y 0/2] Fix ioremap of addresses above 4 GiB on x86-32 PAE

[Radek Marciňa]

From: Radek Marciňa <github.unusual340@8alias.com>

Both patches are stable-only. In these trees the x86 PAGE_MASK is an
unsigned long, so "phys_addr &= PAGE_MASK" on a 64-bit physical address
clears bits 32-63. __ioremap_caller() and __early_ioremap() both do
this and map the low 32-bit alias of anything above 4 GiB.

Mainline is not affected since v6.13, where commit efe8419ae78d ("vdso:
Introduce vdso/page.h") and commit d4a65302dd84 ("vdso: Change
PAGE_MASK to signed on all 32-bit architectures") made PAGE_MASK signed
on 32-bit. Neither was marked for stable. They cannot go to 6.6.y and
older, which lack CONFIG_PAGE_SHIFT (added in v6.9). They do apply to
6.12.y, but together with the i915 build fix in commit 8fd236b00fc1
("drm: i915: Change fault type to unsigned long") they change PAGE_MASK
on every 32-bit architecture, the kind of change that caused the arm32
regression d4a65302dd84 itself fixes. So these patches cast at the two
affected sites instead.

Please apply to 6.12.y, 6.6.y, 6.1.y, 5.15.y and 5.10.y; the series
applies unchanged to all five. 6.18.y and later have the upstream
change.

Reproducer for 1/2: i386_defconfig plus CONFIG_HIGHMEM64G=y,
CONFIG_VIRTIO_PCI=y and CONFIG_HW_RANDOM_VIRTIO=y, booted with

  qemu-system-x86_64 -M q35 -accel kvm -cpu host,host-phys-bits-limit=44 \
    -m 5G -object memory-backend-ram,id=big,size=4G,share=on \
    -device ivshmem-plain,memdev=big -device virtio-rng-pci \
    -nic none -nographic -no-reboot \
    -kernel arch/x86/boot/bzImage -append "console=ttyS0 panic=-1"

The extra options get the virtio BARs above 4 GiB with SeaBIOS 1.16.2,
1.16.3 and 1.17.0. Since 1.16.3 SeaBIOS places 64-bit BARs high when
the guest has RAM above 4 GiB, which on q35 starts at -m 2816M; before
that only when the 32-bit window overflows, which the 4 GiB ivshmem BAR
forces. host-phys-bits-limit=44 keeps SeaBIOS 1.16.3 from placing them
beyond the 44 bits a PAE kernel can address.

On 6.12.115 the virtio BAR 4 at 0xe0100000000 gets mapped at physical
0x0-0x3fff (per /proc/vmallocinfo), the device ends up FAILED and the
log shows

  virtio_rng virtio0: probe with driver virtio_rng failed with error -2

With 1/2 applied the mapping is at 0xe0100000000, the device reaches
DRIVER_OK and /dev/hwrng returns data.

Nothing in a QEMU boot early-maps memory above 4 GiB on i386, so 2/2
was tested with a throwaway late_initcall that calls
early_memremap(0x100000123, 16) and prints slow_virt_to_phys() of the
result: 0x123 on 6.12.115, 0x100000123 with 2/2 applied.

Unmodified v7.3 in the same setup (CONFIG_X86_PAE=y in place of
CONFIG_HIGHMEM64G=y, which no longer exists) gets both mappings right.

Built with GCC 16.2.1, run on QEMU 11.1.2 with KVM.

Radek Marciňa (2):
  x86/ioremap: Sign-extend PAGE_MASK when aligning the physical address
  mm/early_ioremap: Sign-extend PAGE_MASK when aligning the physical
    address

 arch/x86/mm/ioremap.c | 2 +-
 mm/early_ioremap.c    | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.56.0

[PATCH 6.12.y 1/2] x86/ioremap: Sign-extend PAGE_MASK when aligning the physical address

[Radek Marciňa]

From: Radek Marciňa <github.unusual340@8alias.com>

[ Stable-only fix: mainline is not affected since v6.13, see below. ]

On x86-32 with PAE, resource_size_t is 64-bit but PAGE_MASK is an
unsigned long, so in __ioremap_caller()

	phys_addr &= PAGE_MASK;

clears bits 32-63 and ioremap() of anything above 4 GiB maps the alias
at the low 32 bits instead. The RAM check runs earlier on the original
address, so the alias is mapped even when it is system RAM, and the
caller's MMIO writes land there.

Commit ffa71f33a820 ("x86, ioremap: Fix incorrect physical address
handling in PAE mode") fixed this by masking with PHYSICAL_PAGE_MASK,
which casts PAGE_MASK to signed long. Commit 4dbd6a3e90e0 ("x86/ioremap:
Fix page aligned size calculation in __ioremap_caller()") reintroduced
the plain PAGE_MASK to compute the size before the high bits are masked
off. Cast it the same way here.

Mainline lost the bug when commit efe8419ae78d ("vdso: Introduce
vdso/page.h") and commit d4a65302dd84 ("vdso: Change PAGE_MASK to
signed on all 32-bit architectures") made PAGE_MASK signed on 32-bit.
Those rework PAGE_MASK for every architecture, so they are not
backported.

Fixes: 4dbd6a3e90e0 ("x86/ioremap: Fix page aligned size calculation in __ioremap_caller()")
Assisted-by: LLM
Signed-off-by: Radek Marciňa <github.unusual340@8alias.com>
---
 arch/x86/mm/ioremap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 8d29163568a7..14529884671e 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -223,7 +223,7 @@ __ioremap_caller(resource_size_t phys_addr, unsigned long size,
 	 * Mappings have to be page-aligned
 	 */
 	offset = phys_addr & ~PAGE_MASK;
-	phys_addr &= PAGE_MASK;
+	phys_addr &= (signed long)PAGE_MASK;
 	size = PAGE_ALIGN(last_addr+1) - phys_addr;
 
 	/*
-- 
2.56.0

[PATCH 6.12.y 2/2] mm/early_ioremap: Sign-extend PAGE_MASK when aligning the physical address

[Radek Marciňa]

From: Radek Marciňa <github.unusual340@8alias.com>

[ Stable-only fix: mainline is not affected since v6.13, see below. ]

On 32-bit kernels with a 64-bit phys_addr_t and an unsigned long
PAGE_MASK, which in this tree is x86-32 with PAE, __early_ioremap()

	phys_addr &= PAGE_MASK;

clears bits 32-63, so early_ioremap() and early_memremap() of anything
above 4 GiB map the alias at the low 32 bits instead. Cast PAGE_MASK
to signed long so it sign-extends.

Mainline lost the bug when commit efe8419ae78d ("vdso: Introduce
vdso/page.h") and commit d4a65302dd84 ("vdso: Change PAGE_MASK to
signed on all 32-bit architectures") made PAGE_MASK signed on 32-bit.
Those rework PAGE_MASK for every architecture, so they are not
backported.

Fixes: 9e5c33d7aeee ("mm: create generic early_ioremap() support")
Assisted-by: LLM
Signed-off-by: Radek Marciňa <github.unusual340@8alias.com>
---
 mm/early_ioremap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/early_ioremap.c b/mm/early_ioremap.c
index ce06b2884789..ba0acdb72396 100644
--- a/mm/early_ioremap.c
+++ b/mm/early_ioremap.c
@@ -129,7 +129,7 @@ __early_ioremap(resource_size_t phys_addr, unsigned long size, pgprot_t prot)
 	 * Mappings have to be page-aligned
 	 */
 	offset = offset_in_page(phys_addr);
-	phys_addr &= PAGE_MASK;
+	phys_addr &= (signed long)PAGE_MASK;
 	size = PAGE_ALIGN(last_addr + 1) - phys_addr;
 
 	/*
-- 
2.56.0

Re: [PATCH 6.12.y 2/2] mm/early_ioremap: Sign-extend PAGE_MASK when aligning the physical address

[Greg KH]

On Sat, Oct 31, 2026 at 03:45:21PM +0000, Radek Marciňa wrote:
> Signed-off-by: Radek Marciňa <github.unusual340@8alias.com>

Sorry, but this isn't going to work for the obvious reason, so we can't
take these as-is.

greg k-h

Re: [PATCH 6.12.y 2/2] mm/early_ioremap: Sign-extend PAGE_MASK when aligning the physical address

[Radek Marciňa]

On Sat, 2026-10-31 at 21:25 +0100, Greg KH wrote:
> On Sat, Oct 31, 2026 at 03:45:21PM +0000, Radek Marciňa wrote:
> > Signed-off-by: Radek Marciňa <github.unusual340@8alias.com>
> 
> Sorry, but this isn't going to work for the obvious reason, so we
> can't take these as-is.

Thanks for a quick reply. I do have a public GitHub identity which
dates back to 2019 (https://github.com/marcinar).

Here's a recent PR using the same name and email (see the raw patch),
this proves that I control the account.
https://github.com/simple-login/app/pull/2866
https://github.com/simple-login/app/commit/f1eb1fcf36d1fd92a3c2057aab3faf1a5fae1e31.patch


Here's a PR from 2020 that was merged and has my full name (see the raw
patch), this proves that I didn't change the name or rewrote history.
https://github.com/ChargeTimeEU/Java-OCA-OCPP/pull/120
https://github.com/ChargeTimeEU/Java-OCA-OCPP/commit/9e8f2c09ee34a085103d3d6d46856606b05e9a8d.patch

Hopefully, this is enough. But if not, is there a way to contact you
(or someone else) privately about this?