Re: stable-rc/linux-5.4.y bisection: baseline.login on qemu_arm-virt-gicv2-uefi

[Mike Rapoport <rppt@linux.ibm.com>]

On Tue, Apr 19, 2022 at 02:31:59PM +0100, Mark Brown wrote:
> On Sun, Apr 17, 2022 at 02:32:03PM -0700, KernelCI bot wrote:
> 
> The KernelCI bisection bot found that commit 6026d4032dbbe3 ("arm:
> extend pfn_valid to take into account freed memory map alignment")
> triggered a regression in v5.4.x on 32 bit ARM with a qemu platform
> booting UEFI firmware.  We try to dereference an invalid pointer parsing
> the DMI tables:
> 
> <1>[    0.084476] 8<--- cut here ---
> <1>[    0.084595] Unable to handle kernel paging request at virtual address dfb76000
> <1>[    0.084938] pgd = (ptrval)
> <1>[    0.085038] [dfb76000] *pgd=5f7fe801, *pte=00000000, *ppte=00000000
> 
> ...
> 
> <4>[    0.093923] [<c0ed6ce8>] (memcpy) from [<c16a06f8>] (dmi_setup+0x60/0x418)
> <4>[    0.094204] [<c16a06f8>] (dmi_setup) from [<c16a38d4>] (arm_dmi_init+0x8/0x10)
> <4>[    0.094408] [<c16a38d4>] (arm_dmi_init) from [<c0302e9c>] (do_one_initcall+0x50/0x228)
> <4>[    0.094619] [<c0302e9c>] (do_one_initcall) from [<c16011e4>] (kernel_init_freeable+0x15c/0x1f8)
> <4>[    0.094841] [<c16011e4>] (kernel_init_freeable) from [<c0f028cc>] (kernel_init+0x8/0x10c)
> <4>[    0.095057] [<c0f028cc>] (kernel_init) from [<c03010e8>] (ret_from_fork+0x14/0x2c)
> 
> This particular bisect is from GICv2 but GICv3 shows the same issue, and
> it persists in the latest stable -rc:
> 
>     https://linux.kernelci.org/test/job/stable-rc/branch/linux-5.4.y/kernel/v5.4.189-64-gab55553793398/plan/baseline/

I don't know how exactly kernel-ci runs qemu with UEFI, I've tried this:

$QEMU -serial stdio -M virt-2.11,gic-version=2 -cpu cortex-a15 -m 1G \
-drive file=$QEMU_EFI,if=pflash,format=raw,unit=0,readonly=on \
-drive file=flash1.img,if=pflash,format=raw,unit=1,readonly=off \
-kernel $kernel \
-append "console=ttyAMA0" 

with stable-rc/linux-5.4.y and I've got as far as to failure to mount
rootfs and the crash in dmu_setup() didn't reproduce for me.

My understanding is that with HEAD pointing to 6026d4032dbbe3 crash happens
because ioremap uses pfn_valid() to check if a PFN is in RAM which is fixed
by c97579584fa8 ("arm: ioremap: don't abuse pfn_valid() to check if pfn is
in RAM") that comes on top of 6026d4032dbbe3.

No clues why ab55553793398 fails, though... 

-- 
Sincerely yours,
Mike.