On Mon, Nov 04, 2024 at 12:11:22PM +0100, Vlastimil Babka wrote: > On 11/3/24 11:46, syzbot wrote: > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit: f9f24ca362a4 Add linux-next specific files for 20241031 > > git tree: linux-next > > console output: https://syzkaller.appspot.com/x/log.txt?x=1648155f980000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=328572ed4d152be9 > > dashboard link: https://syzkaller.appspot.com/bug?extid=39f85d612b7c20d8db48 > > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40 > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16806e87980000 > > > > Downloadable assets: > > disk image: https://storage.googleapis.com/syzbot-assets/eb84549dd6b3/disk-f9f24ca3.raw.xz > > vmlinux: https://storage.googleapis.com/syzbot-assets/beb29bdfa297/vmlinux-f9f24ca3.xz > > kernel image: https://storage.googleapis.com/syzbot-assets/8881fe3245ad/bzImage-f9f24ca3.xz > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > Reported-by: syzbot+39f85d612b7c20d8db48@xxxxxxxxxxxxxxxxxxxxxxxxx > > > > ============================= > > [ BUG: Invalid wait context ] > > 6.12.0-rc5-next-20241031-syzkaller #0 Not tainted > > ----------------------------- (reading some lockdep source...) > > syz.0.49/6178 is trying to lock: > > ffff88813fffc298 (&zone->lock){-.-.}-{3:3}, at: rmqueue_bulk mm/page_alloc.c:2328 [inline] > > ffff88813fffc298 (&zone->lock){-.-.}-{3:3}, at: __rmqueue_pcplist+0x4c6/0x2b70 mm/page_alloc.c:3022 Trying to acquire in LD_WAIT_CONFIG context... > > other info that might help us debug this: > > context-{2:2} ... but current task only allowed to have LD_WAIT_SPIN or below. Which implies via task_wait_context() that we are in a hard IRQ handler and also !curr->hardirq_threaded && !curr->irq_config. So we're not allowed to acquire this spinlock here because presumably in RT you can't do spin_lock_irqsave() in a hard IRQ? That does seem to suggest maybe we shouldn't be allocating here at all... and it is stackdepot doing it which probably shouldn't as you say Vlastimil. > > Seems like another fallout of > 560af5dc839e ("lockdep: Enable PROVE_RAW_LOCK_NESTING with PROVE_LOCKING") Snap was just looking at that :) Found [0] which seems to be a similar kind of situation where this change is finding new bugs. [0]:https://lore.kernel.org/all/41619255-cdc2-4573-a360-7794fc3614f7@paulmck-laptop/ > > > 4 locks held by syz.0.49/6178: > > #0: ffff888031745be0 (&mm->mmap_lock){++++}-{4:4}, at: mmap_read_lock include/linux/mmap_lock.h:189 [inline] > > #0: ffff888031745be0 (&mm->mmap_lock){++++}-{4:4}, at: exit_mmap+0x165/0xcb0 mm/mmap.c:1677 > > #1: ffffffff8e939f20 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:337 [inline] > > #1: ffffffff8e939f20 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:849 [inline] > > #1: ffffffff8e939f20 (rcu_read_lock){....}-{1:3}, at: __pte_offset_map+0x82/0x380 mm/pgtable-generic.c:287 > > #2: ffff88803007c978 (ptlock_ptr(ptdesc)#2){+.+.}-{3:3}, at: spin_lock include/linux/spinlock.h:351 [inline] > > #2: ffff88803007c978 (ptlock_ptr(ptdesc)#2){+.+.}-{3:3}, at: __pte_offset_map_lock+0x1ba/0x300 mm/pgtable-generic.c:402 > > #3: ffff8880b8744618 (&pcp->lock){+.+.}-{3:3}, at: spin_trylock include/linux/spinlock.h:361 [inline] > > #3: ffff8880b8744618 (&pcp->lock){+.+.}-{3:3}, at: rmqueue_pcplist mm/page_alloc.c:3051 [inline] > > #3: ffff8880b8744618 (&pcp->lock){+.+.}-{3:3}, at: rmqueue mm/page_alloc.c:3095 [inline] > > #3: ffff8880b8744618 (&pcp->lock){+.+.}-{3:3}, at: get_page_from_freelist+0x7e2/0x3870 mm/page_alloc.c:3492 > > stack backtrace: > > CPU: 1 UID: 0 PID: 6178 Comm: syz.0.49 Not tainted 6.12.0-rc5-next-20241031-syzkaller #0 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 > > Call Trace: > > <IRQ> > > __dump_stack lib/dump_stack.c:94 [inline] > > dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 > > print_lock_invalid_wait_context kernel/locking/lockdep.c:4826 [inline] > > check_wait_context kernel/locking/lockdep.c:4898 [inline] > > __lock_acquire+0x15a8/0x2100 kernel/locking/lockdep.c:5176 > > lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 > > __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] > > _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 > > rmqueue_bulk mm/page_alloc.c:2328 [inline] > > __rmqueue_pcplist+0x4c6/0x2b70 mm/page_alloc.c:3022 > > rmqueue_pcplist mm/page_alloc.c:3064 [inline] > > rmqueue mm/page_alloc.c:3095 [inline] > > get_page_from_freelist+0x895/0x3870 mm/page_alloc.c:3492 > > __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4771 > > alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265 > > stack_depot_save_flags+0x666/0x830 lib/stackdepot.c:627 > > save_stack+0x109/0x1f0 mm/page_owner.c:157 > > __set_page_owner+0x92/0x800 mm/page_owner.c:320 > > set_page_owner include/linux/page_owner.h:32 [inline] > > post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1541 > > prep_new_page mm/page_alloc.c:1549 [inline] > > get_page_from_freelist+0x3725/0x3870 mm/page_alloc.c:3495 > > __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4771 > > alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265 > > stack_depot_save_flags+0x666/0x830 lib/stackdepot.c:627 > > kasan_save_stack+0x4f/0x60 mm/kasan/common.c:48 > > __kasan_record_aux_stack+0xac/0xc0 mm/kasan/generic.c:544 > > task_work_add+0xd9/0x490 kernel/task_work.c:77 > > It seems the decision if stack depot is allowed to allocate here depends on > TWAF_NO_ALLOC added only recently. So does it mean it doesn't work as intended? Yup kasan_record_aux_stack() sets STACK_DEPOT_FLAG_CAN_ALLOC specifically, and: if (flags & TWAF_NO_ALLOC) kasan_record_aux_stack_noalloc(work); else kasan_record_aux_stack(work); So TWAF_NO_ALLOC not being set if that was expected to be here.
