Re: [syzbot] [dri?] WARNING in __ww_mutex_wound

[Hillf Danton <hdanton@sina.com>]

On Wed, 30 Jul 2025 15:20:39 +0530 K Prateek Nayak wrote:
> On 7/30/2025 1:57 PM, Maarten Lankhorst wrote:
> > Hey,
> > 
> > This warning is introduced in linux-next as a4f0b6fef4b0 ("locking/mutex: Add p->blocked_on wrappers for correctness checks")
> > Adding relevant people from that commit.
> > 
> > Kind regards,
> > ~Maarten
> > 
> > Den 2025-07-29 kl. 23:59, skrev syzbot:
> >> Hello,
> >>
> >> syzbot found the following issue on:
> >>
> >> HEAD commit:    d086c886ceb9 Add linux-next specific files for 20250718
> >> git tree:       linux-next
> >> console output: https://syzkaller.appspot.com/x/log.txt?x=161204a2580000
> >> kernel config:  https://syzkaller.appspot.com/x/.config?x=69896dd7b8c4e81e
> >> dashboard link: https://syzkaller.appspot.com/bug?extid=602c4720aed62576cd79
> >> compiler:       Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
> >> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=16fff4f0580000
> >> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=111204a2580000
> >>
> >> Downloadable assets:
> >> disk image: https://storage.googleapis.com/syzbot-assets/54504fbc2437/disk-d086c886.raw.xz
> >> vmlinux: https://storage.googleapis.com/syzbot-assets/b427b00abffe/vmlinux-d086c886.xz
> >> kernel image: https://storage.googleapis.com/syzbot-assets/5a87731b006b/bzImage-d086c886.xz
> >>
> >> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> >> Reported-by: syzbot+602c4720aed62576cd79@syzkaller.appspotmail.com
> >>
> >> ------------[ cut here ]------------
> >> WARNING: ./include/linux/sched.h:2173 at __clear_task_blocked_on include/linux/sched.h:2173 [inline], CPU#1: syz.1.8698/395
> >> WARNING: ./include/linux/sched.h:2173 at __ww_mutex_wound+0x21a/0x2b0 kernel/locking/ww_mutex.h:346, CPU#1: syz.1.8698/395
> >> Modules linked in:
> >> CPU: 1 UID: 0 PID: 395 Comm: syz.1.8698 Not tainted 6.16.0-rc6-next-20250718-syzkaller #0 PREEMPT(full) 
> >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025
> >> RIP: 0010:__clear_task_blocked_on include/linux/sched.h:2173 [inline]
> >> RIP: 0010:__ww_mutex_wound+0x21a/0x2b0 kernel/locking/ww_mutex.h:346
> 
> When wounding the lock owner, could it be possible that the lock
> owner is blocked on a different nested lock? Lock owner implies it
> is not blocked on the current lock we are trying to wound right?
> 
> I remember John mentioning seeing circular chains in find_proxy_task()
> which required this but looking at this call-chain I'm wondering if
> only the __ww_mutex_check_waiters() (or some other path) requires
> __clear_task_blocked_on() for that case.
> 
It is buggy to read and clear owner->blocked_on without
owner->blocked_on->wait_lock held, no?