Infinite recursion with CONFIG_DEBUG_PREEMPT=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_PREEMPT:

#0  0xffffffff82450e35 in kmsan_get_metadata (address=0xffffffff93db3210 <oops_in_progress>, is_origin=false) at mm/kmsan/shadow.c:66
#1  0xffffffff82450ce5 in kmsan_get_shadow_origin_ptr (address=0xffffffff93db3210 <oops_in_progress>, size=4, store=false) at mm/kmsan/shadow.c:97
#2  0xffffffff8244e5b4 in get_shadow_origin_ptr (addr=0xffffffff93db3210 <oops_in_progress>, size=4, store=false) at mm/kmsan/instrumentation.c:38
#3  __msan_metadata_ptr_for_load_4 (addr=0xffffffff93db3210 <oops_in_progress>) at mm/kmsan/instrumentation.c:93
#4  0xffffffff816c4943 in preempt_count_add (val=1) at kernel/sched/core.c:5865
#5  0xffffffff82450fbf in kmsan_virt_addr_valid (addr=0xffffffff93db3210 <oops_in_progress>, addr@entry=0x13db3210) at ./arch/x86/include/asm/kmsan.h:93
...
#234 __msan_metadata_ptr_for_load_4 (addr=0xffffffff93db3210 <oops_in_progress>) at mm/kmsan/instrumentation.c:93
#235 0xffffffff816c4943 in preempt_count_add (val=1) at kernel/sched/core.c:5865
#236 0xffffffff82450fbf in kmsan_virt_addr_valid (addr=0xffffffff911add80 <slab_mutex>, addr@entry=0x111add80) at ./arch/x86/include/asm/kmsan.h:93
#237 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff911add80 <slab_mutex>) at mm/kmsan/shadow.c:75
#238 0xffffffff82450ec0 in kmsan_get_metadata (address=0xffffffff911add80 <slab_mutex>, is_origin=false) at mm/kmsan/shadow.c:141
#239 0xffffffff8244e77d in is_bad_asm_addr (size=8, is_store=true, addr=<optimized out>) at mm/kmsan/instrumentation.c:27
#240 __msan_instrument_asm_store (addr=<optimized out>, size=8) at mm/kmsan/instrumentation.c:122
#241 0xffffffff8f8d1e48 in arch_atomic64_try_cmpxchg (v=0xffffffff911add80 <slab_mutex>, new=-1862092992, old=<optimized out>) at ./arch/x86/include/asm/atomic64_64.h:101
#242 raw_atomic64_try_cmpxchg_acquire (v=0xffffffff911add80 <slab_mutex>, new=-1862092992, old=<optimized out>) at ./include/linux/atomic/atomic-arch-fallback.h:4296
#243 raw_atomic_long_try_cmpxchg_acquire (v=0xffffffff911add80 <slab_mutex>, new=-1862092992, old=<optimized out>) at ./include/linux/atomic/atomic-long.h:1482
#244 atomic_long_try_cmpxchg_acquire (v=0xffffffff911add80 <slab_mutex>, new=-1862092992, old=<optimized out>) at ./include/linux/atomic/atomic-instrumented.h:4458
#245 __mutex_trylock_fast (lock=0xffffffff911add80 <slab_mutex>) at kernel/locking/mutex.c:171
#246 mutex_lock (lock=0xffffffff911add80 <slab_mutex>) at kernel/locking/mutex.c:285
#247 0xffffffff8217627e in kmem_cache_create_usercopy (name=0xffffffff90a7e2dd "mm_struct", size=1360, align=0, flags=16656, useroffset=0, usersize=0, ctor=0x0 <fixed_percpu_data>) at mm/slab_common.c:297
#248 0xffffffff918711aa in mm_cache_init () at kernel/fork.c:3157
#249 0xffffffff918b321d in mm_core_init () at mm/mm_init.c:2760
#250 0xffffffff917cade1 in start_kernel () at init/main.c:962
#251 0xffffffff917faa9e in x86_64_start_reservations (real_mode_data=0x14120 <exception_stacks+28960> <error: Cannot access memory at address 0x14120>) at arch/x86/kernel/head64.c:507
#252 0xffffffff917fa988 in x86_64_start_kernel (real_mode_data=0x14120 <exception_stacks+28960> <error: Cannot access memory at address 0x14120>) at arch/x86/kernel/head64.c:488
#253 0xffffffff81406085 in secondary_startup_64 () at arch/x86/kernel/head_64.S:420
#254 0x0000000000000000 in ?? ()