From [1]: XFS is telling the allocator not to track this allocation with lockdep, and that is getting passed down through the allocator which has not passed it to lockdep (correct behaviour!), but then KASAN is trying to track the allocation and that needs to do a memory allocation. __stack_depot_save() is passed the gfp mask from the allocation context so it has __GFP_NOLOCKDEP right there, but it does: if (unlikely(can_alloc && !smp_load_acquire(&next_slab_inited))) { /* * Zero out zone modifiers, as we don't have specific zone * requirements. Keep the flags related to allocation in atomic * contexts and I/O. */ alloc_flags &= ~GFP_ZONEMASK; >>>>>>> alloc_flags &= (GFP_ATOMIC | GFP_KERNEL); alloc_flags |= __GFP_NOWARN; page = alloc_pages(alloc_flags, STACK_ALLOC_ORDER); It masks masks out anything other than GFP_ATOMIC and GFP_KERNEL related flags. This drops __GFP_NOLOCKDEP on the floor, hence lockdep tracks an allocation in a context we've explicitly said not to track. Hence lockdep (correctly!) explodes later when the false positive "lock inode in reclaim context" situation triggers. This is a KASAN bug. It should not be dropping __GFP_NOLOCKDEP from the allocation context flags. [1] https://lore.kernel.org/linux-xfs/20230119045253.GI360264@dread.disaster.area/