Infinite recursion with CONFIG_DEBUG_VIRTUAL=y

[ramosian-glider]

As reported by Kirill Shutemov at https://groups.google.com/g/kasan-dev/c/ZBiGzZL36-I, there's an infinite recursion if the user enables CONFIG_DEBUG_VIRTUAL:

(gdb) bt
#0  write_comp_data (type=7, ip=18446744071584513251, arg1=<optimized out>, arg2=<optimized out>) at kernel/kcov.c:236
#1  __sanitizer_cov_trace_const_cmp8 (arg1=18446744071562067967, arg2=18446744071738765328) at kernel/kcov.c:311
#2  0xffffffff81567ce3 in __phys_addr (x=18446744071738765328) at arch/x86/mm/physaddr.c:20
#3  0xffffffff8245464a in virt_to_page_or_null (vaddr=0xffffffff7fffffff, vaddr@entry=0xffffffff8a883010 <phys_base>) at mm/kmsan/shadow.c:76
#4  0xffffffff824544c0 in kmsan_get_metadata (address=0xffffffff8a883010 <phys_base>, is_origin=false) at mm/kmsan/shadow.c:141
#5  0xffffffff824542e5 in kmsan_get_shadow_origin_ptr (address=0xffffffff8a883010 <phys_base>, size=8, store=false) at mm/kmsan/shadow.c:97
#6  0xffffffff82451c64 in get_shadow_origin_ptr (addr=0xffffffff7fffffff, size=8, store=false) at mm/kmsan/instrumentation.c:38
#7  __msan_metadata_ptr_for_load_8 (addr=0xffffffff7fffffff) at mm/kmsan/instrumentation.c:94
#8  0xffffffff81567dd8 in __phys_addr (x=<optimized out>) at arch/x86/mm/physaddr.c:21
#9  0xffffffff8245464a in virt_to_page_or_null (vaddr=0xffffffff7fffffff, vaddr@entry=0xffffffff8a883010 <phys_base>) at mm/kmsan/shadow.c:76
#10 0xffffffff824544c0 in kmsan_get_metadata (address=0xffffffff8a883010 <phys_base>, is_origin=false) at mm/kmsan/shadow.c:141
#11 0xffffffff824542e5 in kmsan_get_shadow_origin_ptr (address=0xffffffff8a883010 <phys_base>, size=8, store=false) at mm/kmsan/shadow.c:97
#12 0xffffffff82451c64 in get_shadow_origin_ptr (addr=0xffffffff7fffffff, size=8, store=false) at mm/kmsan/instrumentation.c:38
#13 __msan_metadata_ptr_for_load_8 (addr=0xffffffff7fffffff) at mm/kmsan/instrumentation.c:94
#14 0xffffffff81567dd8 in __phys_addr (x=<optimized out>) at arch/x86/mm/physaddr.c:21
#15 0xffffffff8245464a in virt_to_page_or_null (vaddr=0xffffffff7fffffff, vaddr@entry=0xffffffff8a9c7ec0 <slab_mutex>) at mm/kmsan/shadow.c:76
#16 0xffffffff824544c0 in kmsan_get_metadata (address=0xffffffff8a9c7ec0 <slab_mutex>, is_origin=false) at mm/kmsan/shadow.c:141
#17 0xffffffff82451d8d in is_bad_asm_addr (size=8, is_store=true, addr=<optimized out>) at mm/kmsan/instrumentation.c:27
#18 __msan_instrument_asm_store (addr=<optimized out>, size=8) at mm/kmsan/instrumentation.c:122
#19 0xffffffff898404b8 in arch_atomic64_try_cmpxchg (v=0xffffffff8a9c7ec0 <slab_mutex>, new=-1971054592, old=<optimized out>) at ./arch/x86/include/asm/atomic64_64.h:101
#20 raw_atomic64_try_cmpxchg_acquire (v=0xffffffff8a9c7ec0 <slab_mutex>, new=-1971054592, old=<optimized out>) at ./include/linux/atomic/atomic-arch-fallback.h:4296
#21 raw_atomic_long_try_cmpxchg_acquire (v=0xffffffff8a9c7ec0 <slab_mutex>, new=-1971054592, old=<optimized out>) at ./include/linux/atomic/atomic-long.h:1482
#22 atomic_long_try_cmpxchg_acquire (v=0xffffffff8a9c7ec0 <slab_mutex>, new=-1971054592, old=<optimized out>) at ./include/linux/atomic/atomic-instrumented.h:4458
#23 __mutex_trylock_fast (lock=0xffffffff8a9c7ec0 <slab_mutex>) at kernel/locking/mutex.c:171
#24 mutex_lock (lock=0xffffffff8a9c7ec0 <slab_mutex>) at kernel/locking/mutex.c:285
#25 0xffffffff8217ebfe in kmem_cache_create_usercopy (name=0xffffffff8a470d4f "mm_struct", size=1616, align=0, flags=16656, useroffset=0, usersize=0, ctor=0x0 <fixed_percpu_data>) at mm/slab_common.c:297
#26 0xffffffff8ae5e3fa in mm_cache_init () at kernel/fork.c:3157
#27 0xffffffff8ae9fe82 in mm_core_init () at mm/mm_init.c:2760
#28 0xffffffff8adb8de1 in start_kernel () at init/main.c:962
#29 0xffffffff8ade894e in x86_64_start_reservations (real_mode_data=0x13f50 <exception_stacks+28496> <error: Cannot access memory at address 0x13f50>) at arch/x86/kernel/head64.c:507
#30 0xffffffff8ade8838 in x86_64_start_kernel (real_mode_data=0x13f50 <exception_stacks+28496> <error: Cannot access memory at address 0x13f50>) at arch/x86/kernel/head64.c:488
#31 0xffffffff8142ff25 in secondary_startup_64 () at arch/x86/kernel/head_64.S:420
#32 0x0000000000000000 in ?? ()

[ramosian-glider]

The following patch seems to help:

diff --git a/arch/x86/mm/Makefile b/arch/x86/mm/Makefile
index 8d3a00e5c528e..d3b27a383127d 100644
--- a/arch/x86/mm/Makefile
+++ b/arch/x86/mm/Makefile
@@ -17,6 +17,7 @@ KCSAN_SANITIZE := n
 # Avoid recursion by not calling KMSAN hooks for CEA code.
 KMSAN_SANITIZE_cpu_entry_area.o := n
 KMSAN_SANITIZE_mem_encrypt_identity.o := n
+KMSAN_SANITIZE_physaddr.o := n
 
 ifdef CONFIG_FUNCTION_TRACER
 CFLAGS_REMOVE_mem_encrypt.o            = -pg

[ramosian-glider]

If so, we could probably kill the duplicate code in arch/x86/include/asm/kmsan.h...