Re: [lkp] [x86/mtrr] edfe63ec97: kernel BUG at arch/x86/mm/physaddr.c:79!

[Toshi Kani]

On Fri, 2016-04-01 at 11:05 +0800, kernel test robot wrote:
> FYI, we noticed the below changes on
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/mm
> commit edfe63ec97ed8d4496225f7ba54c9ce4207c5431 ("x86/mtrr: Fix Xorg
> crashes in Qemu sessions")
> 
> 
> [ÂÂÂ10.429879] hgafb: HGA card not detected.
> [ÂÂÂ10.430521] hgafb: probe of hgafb.0 failed with error -22
> [ÂÂÂ10.434199] ------------[ cut here ]------------
> [ÂÂÂ10.434889] kernel BUG at arch/x86/mm/physaddr.c:79!
> [ÂÂÂ10.435784] invalid opcode: 0000 [#1] DEBUG_PAGEALLOCÂ
> [ÂÂÂ10.436627] CPU: 0 PID: 117 Comm: v86d Not tainted 4.6.0-rc1-00015-
> gedfe63e #1
> [ÂÂÂ10.437696] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS Debian-1.8.2-1 04/01/2014
> [ÂÂÂ10.438929] task: cf91d900 ti: cf8fa000 task.ti: cf8fa000
> [ÂÂÂ10.439664] EIP: 0060:[<c1033290>] EFLAGS: 00010206 CPU: 0
> [ÂÂÂ10.440409] EIP is at __phys_addr+0x80/0x90
> [ÂÂÂ10.441022] EAX: 13fe0000 EBX: 13fe0000 ECX: 00000000 EDX: 13fe0000
> [ÂÂÂ10.441975] ESI: 00000000 EDI: 00000000 EBP: cf8fbe4c ESP: cf8fbe48
> [ÂÂÂ10.442804]ÂÂDS: 007b ES: 007b FS: 0000 GS: 00e0 SS: 0068
> [ÂÂÂ10.443534] CR0: 80050033 CR2: 08063e48 CR3: 0f9f8f20 CR4: 000006b0
> [ÂÂÂ10.444362] Stack:
> [ÂÂÂ10.444772]ÂÂcf9e4dfc cf8fbe60 c1031eef 00000001 00001000 00000000
> cf8fbea8 c15952d1
> [ÂÂÂ10.446322]ÂÂcf9e4dfc d3a23518 c10fce12 024080c0 024080c0 d2b05c80
> 00000000 00000000
> [ÂÂÂ10.447870]ÂÂd15da220 cf9e4dd8 00001000 00001000 00000000 cf9ed790
> b7752000 cf9ed788
> [ÂÂÂ10.449424] Call Trace:
> [ÂÂÂ10.449877]ÂÂ[<c1031eef>] phys_mem_access_prot_allowed+0xaf/0xf0
> [ÂÂÂ10.450670]ÂÂ[<c15952d1>] mmap_mem+0xa1/0x170
> [ÂÂÂ10.451308]ÂÂ[<c10fce12>] ? mmap_region+0x242/0x510
> [ÂÂÂ10.451993]ÂÂ[<c10fce9a>] mmap_region+0x2ca/0x510
> [ÂÂÂ10.452657]ÂÂ[<c10fd30d>] do_mmap+0x22d/0x300
> [ÂÂÂ10.453313]ÂÂ[<c10e7d74>] vm_mmap_pgoff+0x54/0x80
> [ÂÂÂ10.453985]ÂÂ[<c10fb211>] SyS_mmap_pgoff+0xa1/0x100
> [ÂÂÂ10.454665]ÂÂ[<c10013c3>] do_int80_syscall_32+0x63/0x150
> [ÂÂÂ10.455396]ÂÂ[<c1b2684e>] entry_INT80_32+0x36/0x36

In short, this is a bug in previously (and unintentionally) deadcode.Â

After commit edfe63ec97, PAT is now set to disable properly when MTRRs are
disabled. ÂThis led the following deadcode to resurrect on x86/32.

phys_mem_access_prot_allowed()
Â:
#ifdef CONFIG_X86_32
ÂÂÂÂÂÂÂÂ/*
ÂÂÂÂÂÂÂÂÂ* On the PPro and successors, the MTRRs are used to set
ÂÂÂÂÂÂÂÂÂ* memory types for physical addresses outside main memory,
ÂÂÂÂÂÂÂÂÂ* so blindly setting UC or PWT on those pages is wrong.
ÂÂÂÂÂÂÂÂÂ* For Pentiums and earlier, the surround logic should disable
ÂÂÂÂÂÂÂÂÂ* caching for the high addresses through the KEN pin, but
ÂÂÂÂÂÂÂÂÂ* we maintain the tradition of paranoia in this code.
ÂÂÂÂÂÂÂÂÂ*/
ÂÂÂÂÂÂÂÂif (!pat_enabled() &&
ÂÂÂÂÂÂÂÂÂÂÂÂ!(boot_cpu_has(X86_FEATURE_MTRR) ||
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂboot_cpu_has(X86_FEATURE_K6_MTRR) ||
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂboot_cpu_has(X86_FEATURE_CYRIX_ARR) ||
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂboot_cpu_has(X86_FEATURE_CENTAUR_MCR)) &&
ÂÂÂÂÂÂÂÂÂÂÂÂ(pfn << PAGE_SHIFT) >= __pa(high_memory)) {
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂpcm = _PAGE_CACHE_MODE_UC;
ÂÂÂÂÂÂÂÂ}
#endif

When the system does not have much memory, 'high_memory' points to the
maximum memory address + 1, which is empty. ÂWhen CONFIG_DEBUG_VIRTUAL is
also set, __pa() callsÂ__phys_addr(), which in turn
callsÂslow_virt_to_phys() for high_memory. ÂBecause high_memory does not
point to a valid memory address, this address is not mapped. ÂHence,
BUG_ON.

This can be fixed by changing it to either __pa(high_memory-1)
orÂ__pa_nodebug(high_memory). ÂSince the code does not expect a valid
virtual address for high_memory, I think using __pa_nodebug() is
appropriate here. ÂI am going to send a patch with this change.

Note, the code should not use high_memory for this check. ÂI have a
separate patch for the /dev/mem driver to check if a target address is
backed by any memory (Ingo, any update on this one?). ÂI consider it as
enhancement, so I am not going to replace the high_memory check for this
bug fix, though.
https://lkml.org/lkml/2016/2/9/935
https://lkml.org/lkml/2016/2/17/493

Thanks,
-Toshi