Re: possible deadlock in tty_unthrottle
From: Jiri Slaby
Date: Thu Feb 27 2020 - 06:40:17 EST
On 27. 02. 20, 12:36, Hillf Danton wrote:
>
> On Thu, 27 Feb 2020 00:39:12 -0800
>> syzbot found the following crash on:
>>
>> HEAD commit: f8788d86 Linux 5.6-rc3
>> git tree: upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=1102d22de00000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=5d2e033af114153f
>> dashboard link: https://syzkaller.appspot.com/bug?extid=26183d9746e62da329b8
>> compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
>>
>> Unfortunately, I don't have any reproducer for this crash yet.
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+26183d9746e62da329b8@xxxxxxxxxxxxxxxxxxxxxxxxx
>>
>> ======================================================
>> WARNING: possible circular locking dependency detected
>> 5.6.0-rc3-syzkaller #0 Not tainted
>> ------------------------------------------------------
>> syz-executor.4/20336 is trying to acquire lock:
>> ffff8880a2e952a0 (&tty->termios_rwsem){++++}, at: tty_unthrottle+0x22/0x100 drivers/tty/tty_ioctl.c:136
>>
>> but task is already holding lock:
>> ffffffff89462e70 (sel_lock){+.+.}, at: paste_selection+0x118/0x470 drivers/tty/vt/selection.c:374
>>
>> which lock already depends on the new lock.
>>
>>
>> the existing dependency chain (in reverse order) is:
>>
>> -> #2 (sel_lock){+.+.}:
>> lock_acquire+0x154/0x250 kernel/locking/lockdep.c:4484
>> __mutex_lock_common+0x16e/0x2f30 kernel/locking/mutex.c:956
>> __mutex_lock kernel/locking/mutex.c:1103 [inline]
>> mutex_lock_nested+0x1b/0x30 kernel/locking/mutex.c:1118
>> set_selection_kernel+0x3b8/0x18a0 drivers/tty/vt/selection.c:217
>> set_selection_user+0x63/0x80 drivers/tty/vt/selection.c:181
>> tioclinux+0x103/0x530 drivers/tty/vt/vt.c:3050
>> vt_ioctl+0x3f1/0x3a30 drivers/tty/vt/vt_ioctl.c:364
>> tty_ioctl+0xee6/0x15c0 drivers/tty/tty_io.c:2660
>> vfs_ioctl fs/ioctl.c:47 [inline]
>> ksys_ioctl fs/ioctl.c:763 [inline]
>> __do_sys_ioctl fs/ioctl.c:772 [inline]
>> __se_sys_ioctl+0x113/0x190 fs/ioctl.c:770
>> __x64_sys_ioctl+0x7b/0x90 fs/ioctl.c:770
>> do_syscall_64+0xf7/0x1c0 arch/x86/entry/common.c:294
>> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>>
>> -> #1 (console_lock){+.+.}:
>> lock_acquire+0x154/0x250 kernel/locking/lockdep.c:4484
>> console_lock+0x46/0x70 kernel/printk/printk.c:2289
>> con_flush_chars+0x50/0x650 drivers/tty/vt/vt.c:3223
>> n_tty_write+0xeae/0x1200 drivers/tty/n_tty.c:2350
>> do_tty_write drivers/tty/tty_io.c:962 [inline]
>> tty_write+0x5a1/0x950 drivers/tty/tty_io.c:1046
>> __vfs_write+0xb8/0x740 fs/read_write.c:494
>> vfs_write+0x270/0x580 fs/read_write.c:558
>> ksys_write+0x117/0x220 fs/read_write.c:611
>> __do_sys_write fs/read_write.c:623 [inline]
>> __se_sys_write fs/read_write.c:620 [inline]
>> __x64_sys_write+0x7b/0x90 fs/read_write.c:620
>> do_syscall_64+0xf7/0x1c0 arch/x86/entry/common.c:294
>> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>>
>> -> #0 (&tty->termios_rwsem){++++}:
>> check_prev_add kernel/locking/lockdep.c:2475 [inline]
>> check_prevs_add kernel/locking/lockdep.c:2580 [inline]
>> validate_chain+0x1507/0x7be0 kernel/locking/lockdep.c:2970
>> __lock_acquire+0xc5a/0x1bc0 kernel/locking/lockdep.c:3954
>> lock_acquire+0x154/0x250 kernel/locking/lockdep.c:4484
>> down_write+0x57/0x140 kernel/locking/rwsem.c:1534
>> tty_unthrottle+0x22/0x100 drivers/tty/tty_ioctl.c:136
>> mkiss_receive_buf+0x12aa/0x1340 drivers/net/hamradio/mkiss.c:902
>> tty_ldisc_receive_buf+0x12f/0x170 drivers/tty/tty_buffer.c:465
>> paste_selection+0x346/0x470 drivers/tty/vt/selection.c:389
>> tioclinux+0x121/0x530 drivers/tty/vt/vt.c:3055
>> vt_ioctl+0x3f1/0x3a30 drivers/tty/vt/vt_ioctl.c:364
>> tty_ioctl+0xee6/0x15c0 drivers/tty/tty_io.c:2660
>> vfs_ioctl fs/ioctl.c:47 [inline]
>> ksys_ioctl fs/ioctl.c:763 [inline]
>> __do_sys_ioctl fs/ioctl.c:772 [inline]
>> __se_sys_ioctl+0x113/0x190 fs/ioctl.c:770
>> __x64_sys_ioctl+0x7b/0x90 fs/ioctl.c:770
>> do_syscall_64+0xf7/0x1c0 arch/x86/entry/common.c:294
>> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>>
>> other info that might help us debug this:
>>
>> Chain exists of:
>> &tty->termios_rwsem --> console_lock --> sel_lock
>>
>> Possible unsafe locking scenario:
>>
>> CPU0 CPU1
>> ---- ----
>> lock(sel_lock);
>> lock(console_lock);
>> lock(sel_lock);
>> lock(&tty->termios_rwsem);
>>
>> *** DEADLOCK ***
>>
>> 3 locks held by syz-executor.4/20336:
>> #0: ffff8880a2e95090 (&tty->ldisc_sem){++++}, at: tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:267
>> #1: ffff888097ac10a8 (&buf->lock){+.+.}, at: tty_buffer_lock_exclusive+0x33/0x40 drivers/tty/tty_buffer.c:61
>> #2: ffffffff89462e70 (sel_lock){+.+.}, at: paste_selection+0x118/0x470 drivers/tty/vt/selection.c:374
>>
> The sel_lock was introduced in
> 07e6124a1a46 ("vt: selection, close sel_buffer race")
>
> and with it in position can we cut one lock for setting selection?
Ouch -- I will look into it. (But not until tomorrow.)
Thanks.
> --- a/drivers/tty/vt/vt.c
> +++ b/drivers/tty/vt/vt.c
> @@ -3015,8 +3015,6 @@ static struct console vt_console_driver
> *
> * There are some functions which can sleep for arbitrary periods
> * (paste_selection) but we don't need the lock there anyway.
> - *
> - * set_selection_user has locking, and definitely needs it
> */
>
> int tioclinux(struct tty_struct *tty, unsigned long arg)
> @@ -3035,10 +3033,8 @@ int tioclinux(struct tty_struct *tty, un
> switch (type)
> {
> case TIOCL_SETSEL:
> - console_lock();
> ret = set_selection_user((struct tiocl_selection
> __user *)(p+1), tty);
> - console_unlock();
> break;
> case TIOCL_PASTESEL:
> ret = paste_selection(tty);
>
--
js
suse labs