public inbox for [email protected]
 help / color / mirror / Atom feed
From: Jens Axboe <[email protected]>
To: Hillf Danton <[email protected]>,
	syzbot <[email protected]>
Cc: [email protected], [email protected],
	[email protected], [email protected]
Subject: Re: possible deadlock in io_poll_double_wake (2)
Date: Wed, 3 Mar 2021 06:39:00 -0700	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On 3/2/21 11:52 PM, Hillf Danton wrote:
> Tue, 02 Mar 2021 10:59:05 -0800
>> Hello,
>>
>> syzbot has tested the proposed patch but the reproducer is still triggering an issue:
>> possible deadlock in io_poll_double_wake
>>
>> ============================================
>> WARNING: possible recursive locking detected
>> 5.12.0-rc1-syzkaller #0 Not tainted
>> --------------------------------------------
>> syz-executor.4/10454 is trying to acquire lock:
>> ffff8880343cc130 (&runtime->sleep){..-.}-{2:2}, at: spin_lock include/linux/spinlock.h:354 [inline]
>> ffff8880343cc130 (&runtime->sleep){..-.}-{2:2}, at: io_poll_double_wake+0x25f/0x6a0 fs/io_uring.c:4925
>>
>> but task is already holding lock:
>> ffff888034e3b130 (&runtime->sleep){..-.}-{2:2}, at: __wake_up_common_lock+0xb4/0x130 kernel/sched/wait.c:137
>>
>> other info that might help us debug this:
>>  Possible unsafe locking scenario:
>>
>>        CPU0
>>        ----
>>   lock(&runtime->sleep);
>>   lock(&runtime->sleep);
>>
>>  *** DEADLOCK ***
>>
>>  May be due to missing lock nesting notation
>>
>> 4 locks held by syz-executor.4/10454:
>>  #0: ffff888018cc8128 (&ctx->uring_lock){+.+.}-{3:3}, at: __do_sys_io_uring_enter+0x1146/0x2200 fs/io_uring.c:9113
>>  #1: ffff888021692440 (&runtime->oss.params_lock){+.+.}-{3:3}, at: snd_pcm_oss_change_params sound/core/oss/pcm_oss.c:1087 [inline]
>>  #1: ffff888021692440 (&runtime->oss.params_lock){+.+.}-{3:3}, at: snd_pcm_oss_make_ready+0xc7/0x1b0 sound/core/oss/pcm_oss.c:1149
>>  #2: ffff888020273908 (&group->lock){..-.}-{2:2}, at: _snd_pcm_stream_lock_irqsave+0x9f/0xd0 sound/core/pcm_native.c:170
>>  #3: ffff888034e3b130 (&runtime->sleep){..-.}-{2:2}, at: __wake_up_common_lock+0xb4/0x130 kernel/sched/wait.c:137
>>
>> stack backtrace:
>> CPU: 0 PID: 10454 Comm: syz-executor.4 Not tainted 5.12.0-rc1-syzkaller #0
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
>> Call Trace:
>>  <IRQ>
>>  __dump_stack lib/dump_stack.c:79 [inline]
>>  dump_stack+0xfa/0x151 lib/dump_stack.c:120
>>  print_deadlock_bug kernel/locking/lockdep.c:2829 [inline]
>>  check_deadlock kernel/locking/lockdep.c:2872 [inline]
>>  validate_chain kernel/locking/lockdep.c:3661 [inline]
>>  __lock_acquire.cold+0x14c/0x3b4 kernel/locking/lockdep.c:4900
>>  lock_acquire kernel/locking/lockdep.c:5510 [inline]
>>  lock_acquire+0x1ab/0x730 kernel/locking/lockdep.c:5475
>>  __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
>>  _raw_spin_lock+0x2a/0x40 kernel/locking/spinlock.c:151
>>  spin_lock include/linux/spinlock.h:354 [inline]
>>  io_poll_double_wake+0x25f/0x6a0 fs/io_uring.c:4925
>>  __wake_up_common+0x147/0x650 kernel/sched/wait.c:108
>>  __wake_up_common_lock+0xd0/0x130 kernel/sched/wait.c:138
>>  snd_pcm_update_state+0x46a/0x540 sound/core/pcm_lib.c:203
>>  snd_pcm_update_hw_ptr0+0xa75/0x1a50 sound/core/pcm_lib.c:464
>>  snd_pcm_period_elapsed+0x160/0x250 sound/core/pcm_lib.c:1805
>>  dummy_hrtimer_callback+0x94/0x1b0 sound/drivers/dummy.c:378
>>  __run_hrtimer kernel/time/hrtimer.c:1519 [inline]
>>  __hrtimer_run_queues+0x609/0xe40 kernel/time/hrtimer.c:1583
>>  hrtimer_run_softirq+0x17b/0x360 kernel/time/hrtimer.c:1600
>>  __do_softirq+0x29b/0x9f6 kernel/softirq.c:345
>>  invoke_softirq kernel/softirq.c:221 [inline]
>>  __irq_exit_rcu kernel/softirq.c:422 [inline]
>>  irq_exit_rcu+0x134/0x200 kernel/softirq.c:434
>>  sysvec_apic_timer_interrupt+0x93/0xc0 arch/x86/kernel/apic/apic.c:1100
>>  </IRQ>
>>  asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:632
>> RIP: 0010:unwind_next_frame+0xde0/0x2000 arch/x86/kernel/unwind_orc.c:611
>> Code: 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 0f b6 04 02 84 c0 74 08 3c 03 0f 8e 83 0f 00 00 41 3b 2f 0f 84 c1 05 00 00 <bf> 01 00 00 00 e8 16 95 1b 00 b8 01 00 00 00 65 8b 15 ca a8 cf 7e
>> RSP: 0018:ffffc9000b447168 EFLAGS: 00000287
>> RAX: ffffc9000b448001 RBX: 1ffff92001688e35 RCX: 1ffff92001688e01
>> RDX: ffffc9000b447ae8 RSI: ffffc9000b447ab0 RDI: ffffc9000b447250
>> RBP: ffffc9000b447ae0 R08: ffffffff8dac0810 R09: 0000000000000001
>> R10: 0000000000084087 R11: 0000000000000001 R12: ffffc9000b440000
>> R13: ffffc9000b447275 R14: ffffc9000b447290 R15: ffffc9000b447240
>>  arch_stack_walk+0x7d/0xe0 arch/x86/kernel/stacktrace.c:25
>>  stack_trace_save+0x8c/0xc0 kernel/stacktrace.c:121
>>  kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38
>>  kasan_set_track+0x1c/0x30 mm/kasan/common.c:46
>>  kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:357
>>  ____kasan_slab_free mm/kasan/common.c:360 [inline]
>>  ____kasan_slab_free mm/kasan/common.c:325 [inline]
>>  __kasan_slab_free+0xf5/0x130 mm/kasan/common.c:367
>>  kasan_slab_free include/linux/kasan.h:199 [inline]
>>  slab_free_hook mm/slub.c:1562 [inline]
>>  slab_free_freelist_hook+0x72/0x1b0 mm/slub.c:1600
>>  slab_free mm/slub.c:3161 [inline]
>>  kfree+0xe5/0x7b0 mm/slub.c:4213
>>  snd_pcm_hw_param_near.constprop.0+0x7b0/0x8f0 sound/core/oss/pcm_oss.c:438
>>  snd_pcm_oss_change_params_locked+0x18c6/0x39a0 sound/core/oss/pcm_oss.c:936
>>  snd_pcm_oss_change_params sound/core/oss/pcm_oss.c:1090 [inline]
>>  snd_pcm_oss_make_ready+0xe7/0x1b0 sound/core/oss/pcm_oss.c:1149
>>  snd_pcm_oss_set_trigger.isra.0+0x30f/0x6e0 sound/core/oss/pcm_oss.c:2057
>>  snd_pcm_oss_poll+0x661/0xb10 sound/core/oss/pcm_oss.c:2841
>>  vfs_poll include/linux/poll.h:90 [inline]
>>  __io_arm_poll_handler+0x354/0xa20 fs/io_uring.c:5073
>>  io_arm_poll_handler fs/io_uring.c:5142 [inline]
>>  __io_queue_sqe+0x6ef/0xc40 fs/io_uring.c:6213
>>  io_queue_sqe+0x60d/0xf60 fs/io_uring.c:6259
>>  io_submit_sqe fs/io_uring.c:6423 [inline]
>>  io_submit_sqes+0x519a/0x6320 fs/io_uring.c:6537
>>  __do_sys_io_uring_enter+0x1152/0x2200 fs/io_uring.c:9114
>>  do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
>>  entry_SYSCALL_64_after_hwframe+0x44/0xae
>> RIP: 0033:0x465ef9
>> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
>> RSP: 002b:00007f818e00e188 EFLAGS: 00000246 ORIG_RAX: 00000000000001aa
>> RAX: ffffffffffffffda RBX: 000000000056c008 RCX: 0000000000465ef9
>> RDX: 0000000000000000 RSI: 0000000000002039 RDI: 0000000000000004
>> RBP: 00000000004bcd1c R08: 0000000000000000 R09: 0000000000000000
>> R10: 0000000000000000 R11: 0000000000000246 R12: 000000000056c008
>> R13: 0000000000a9fb1f R14: 00007f818e00e300 R15: 0000000000022000
>>
>>
>> Tested on:
>>
>> commit:         c9387501 sound: name fiddling
>> git tree:       git://git.kernel.dk/linux-block syzbot-test
>> console output: https://syzkaller.appspot.com/x/log.txt?x=16a51856d00000
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=fa0e4e0c3e0cf6e0
>> dashboard link: https://syzkaller.appspot.com/bug?extid=28abd693db9e92c160d8
>> compiler:       
>>
> 
> Walk around recursive lock before adding fix to io_poll_get_single().
> 
> --- x/fs/io_uring.c
> +++ y/fs/io_uring.c
> @@ -4945,6 +4945,7 @@ static int io_poll_double_wake(struct wa
>  			       int sync, void *key)
>  {
>  	struct io_kiocb *req = wait->private;
> +	struct io_poll_iocb *self = container_of(wait, struct io_poll_iocb, wait); 
>  	struct io_poll_iocb *poll = io_poll_get_single(req);
>  	__poll_t mask = key_to_poll(key);
>  
> @@ -4954,7 +4955,7 @@ static int io_poll_double_wake(struct wa
>  
>  	list_del_init(&wait->entry);
>  
> -	if (poll && poll->head) {
> +	if (poll && poll->head && poll->head != self->head) {
>  		bool done;
>  
>  		spin_lock(&poll->head->lock);

The trace and the recent test shows that they are different, this
case is already caught when we arm the double poll handling:

https://git.kernel.dk/cgit/linux-block/commit/?h=io_uring-5.12&id=9e27652c987541aa7cc062e59343e321fff539ae

I don't think there's a real issue here, I'm just poking to see why
syzbot/lockdep thinks there is.

-- 
Jens Axboe


      parent reply	other threads:[~2021-03-04  0:24 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-29  2:28 possible deadlock in io_poll_double_wake (2) syzbot
2021-02-28  0:42 ` syzbot
2021-02-28 23:08   ` Jens Axboe
2021-03-01  2:08     ` 回复: " Zhang, Qiang
2021-03-01  2:48       ` Jens Axboe
2021-03-01  4:18     ` syzbot
2021-03-01 15:27       ` Jens Axboe
2021-03-01 15:55         ` syzbot
2021-03-02 17:20       ` Jens Axboe
2021-03-02 18:59         ` syzbot
2021-03-03  4:01           ` Jens Axboe
2021-03-03 11:36             ` syzbot
2021-03-03 12:15         ` 回复: " Zhang, Qiang
2021-03-03 12:45           ` Zhang, Qiang
     [not found]         ` <[email protected]>
2021-03-03 13:39           ` Jens Axboe [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox