[Bug 216973] New: stackdepot: do not drop __GFP_NOLOCKDEP

[bugzill...@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=216973

Bug ID: 216973
Summary: stackdepot: do not drop __GFP_NOLOCKDEP
Product: Memory Management
Version: 2.5
Kernel Version: upstream
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Sanitizers
Assignee: mm_san...@kernel-bugs.kernel.org
Reporter: andre...@gmail.com
CC: kasa...@googlegroups.com
Regression: No

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/20230119045...@dread.disaster.area/

--
You may reply to this email to add a comment.

You are receiving this mail because:
You are on the CC list for the bug.