* possible deadlock in console_unlock
@ 2018-06-06 13:17 syzbot
2018-06-07 4:44 ` syzbot
` (2 more replies)
0 siblings, 3 replies; 22+ messages in thread
From: syzbot @ 2018-06-06 13:17 UTC (permalink / raw)
To: linux-kernel, pmladek, rostedt, sergey.senozhatsky, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: af6c5d5e01ad Merge branch 'for-4.18' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=173d93ef800000
kernel config: https://syzkaller.appspot.com/x/.config?x=12ff770540994680
dashboard link: https://syzkaller.appspot.com/bug?extid=43e93968b964e369db0b
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
userspace arch: i386
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=16e00bb7800000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+43e93968b964e369db0b@syzkaller.appspotmail.com
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
======================================================
WARNING: possible circular locking dependency detected
4.17.0+ #111 Not tainted
------------------------------------------------------
syz-executor0/4774 is trying to acquire lock:
(ptrval) (console_owner){-...}, at: log_next
kernel/printk/printk.c:496 [inline]
(ptrval) (console_owner){-...}, at: console_unlock+0x583/0x1100
kernel/printk/printk.c:2382
but task is already holding lock:
(ptrval) (&(&port->lock)->rlock){-.-.}, at: pty_write+0xf9/0x1f0
drivers/tty/pty.c:119
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&(&port->lock)->rlock){-.-.}:
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:152
tty_port_tty_get+0x20/0x80 drivers/tty/tty_port.c:288
tty_port_default_wakeup+0x15/0x40 drivers/tty/tty_port.c:47
tty_port_tty_wakeup+0x5d/0x70 drivers/tty/tty_port.c:390
uart_write_wakeup+0x44/0x60 drivers/tty/serial/serial_core.c:103
serial8250_tx_chars+0x4be/0xb60
drivers/tty/serial/8250/8250_port.c:1808
serial8250_handle_irq.part.25+0x1ee/0x280
drivers/tty/serial/8250/8250_port.c:1881
serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1867
[inline]
serial8250_default_handle_irq+0xc8/0x150
drivers/tty/serial/8250/8250_port.c:1897
serial8250_interrupt+0xfa/0x1d0
drivers/tty/serial/8250/8250_core.c:125
__handle_irq_event_percpu+0x1c0/0xad0 kernel/irq/handle.c:149
handle_irq_event_percpu+0x98/0x1c0 kernel/irq/handle.c:189
handle_irq_event+0xa7/0x135 kernel/irq/handle.c:206
handle_edge_irq+0x20f/0x870 kernel/irq/chip.c:791
generic_handle_irq_desc include/linux/irqdesc.h:159 [inline]
handle_irq+0x18c/0x2e7 arch/x86/kernel/irq_64.c:77
do_IRQ+0x78/0x190 arch/x86/kernel/irq.c:245
ret_from_intr+0x0/0x1e
native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:54
arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline]
default_idle+0xc2/0x440 arch/x86/kernel/process.c:500
arch_cpu_idle+0x10/0x20 arch/x86/kernel/process.c:491
default_idle_call+0x6d/0x90 kernel/sched/idle.c:93
cpuidle_idle_call kernel/sched/idle.c:153 [inline]
do_idle+0x395/0x560 kernel/sched/idle.c:262
cpu_startup_entry+0x104/0x120 kernel/sched/idle.c:368
start_secondary+0x42b/0x5c0 arch/x86/kernel/smpboot.c:265
secondary_startup_64+0xa5/0xb0 arch/x86/kernel/head_64.S:242
-> #1 (&port_lock_key){-.-.}:
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:152
serial8250_console_write+0x8d5/0xb00
drivers/tty/serial/8250/8250_port.c:3230
univ8250_console_write+0x5f/0x70
drivers/tty/serial/8250/8250_core.c:590
call_console_drivers kernel/printk/printk.c:1718 [inline]
console_unlock+0xac2/0x1100 kernel/printk/printk.c:2395
vprintk_emit+0x6ad/0xdd0 kernel/printk/printk.c:1907
vprintk_default+0x28/0x30 kernel/printk/printk.c:1947
vprintk_func+0x7a/0xe7 kernel/printk/printk_safe.c:379
printk+0x9e/0xba kernel/printk/printk.c:1980
register_console+0x7e7/0xc00 kernel/printk/printk.c:2714
univ8250_console_init+0x3f/0x4b
drivers/tty/serial/8250/8250_core.c:685
console_init+0x6d9/0xa38 kernel/printk/printk.c:2798
start_kernel+0x608/0x92d init/main.c:661
x86_64_start_reservations+0x29/0x2b arch/x86/kernel/head64.c:452
x86_64_start_kernel+0x76/0x79 arch/x86/kernel/head64.c:433
secondary_startup_64+0xa5/0xb0 arch/x86/kernel/head_64.S:242
-> #0 (console_owner){-...}:
lock_acquire+0x1dc/0x520 kernel/locking/lockdep.c:3924
console_lock_spinning_enable kernel/printk/printk.c:1581 [inline]
console_unlock+0x5ef/0x1100 kernel/printk/printk.c:2392
vprintk_emit+0x6ad/0xdd0 kernel/printk/printk.c:1907
vprintk_default+0x28/0x30 kernel/printk/printk.c:1947
vprintk_func+0x7a/0xe7 kernel/printk/printk_safe.c:379
printk+0x9e/0xba kernel/printk/printk.c:1980
fail_dump lib/fault-inject.c:44 [inline]
should_fail+0x97a/0xbcd lib/fault-inject.c:149
__should_failslab+0x124/0x180 mm/failslab.c:32
should_failslab+0x9/0x14 mm/slab_common.c:1522
slab_pre_alloc_hook mm/slab.h:423 [inline]
slab_alloc mm/slab.c:3378 [inline]
__do_kmalloc mm/slab.c:3716 [inline]
__kmalloc+0x63/0x760 mm/slab.c:3727
kmalloc include/linux/slab.h:517 [inline]
tty_buffer_alloc drivers/tty/tty_buffer.c:170 [inline]
__tty_buffer_request_room+0x2d2/0x7f0 drivers/tty/tty_buffer.c:268
tty_insert_flip_string_fixed_flag+0x8d/0x1f0
drivers/tty/tty_buffer.c:313
tty_insert_flip_string include/linux/tty_flip.h:37 [inline]
pty_write+0x12c/0x1f0 drivers/tty/pty.c:121
tty_put_char+0x129/0x150 drivers/tty/tty_io.c:2865
__process_echoes+0x4d9/0x8d0 drivers/tty/n_tty.c:703
process_echoes+0xfc/0x170 drivers/tty/n_tty.c:781
n_tty_set_termios+0xb56/0xe80 drivers/tty/n_tty.c:1837
tty_set_termios+0x7a0/0xac0 drivers/tty/tty_ioctl.c:341
set_termios+0x41e/0x7d0 drivers/tty/tty_ioctl.c:414
tty_mode_ioctl+0x871/0xb50 drivers/tty/tty_ioctl.c:781
n_tty_ioctl_helper+0x54/0x3b0 drivers/tty/tty_ioctl.c:940
n_tty_ioctl+0x54/0x320 drivers/tty/n_tty.c:2441
tty_ioctl+0x5e1/0x1870 drivers/tty/tty_io.c:2655
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:500 [inline]
do_vfs_ioctl+0x1cf/0x16f0 fs/ioctl.c:684
__do_compat_sys_ioctl fs/compat_ioctl.c:1483 [inline]
__se_compat_sys_ioctl fs/compat_ioctl.c:1407 [inline]
__ia32_compat_sys_ioctl+0x43e/0x640 fs/compat_ioctl.c:1407
do_syscall_32_irqs_on arch/x86/entry/common.c:323 [inline]
do_fast_syscall_32+0x345/0xf9b arch/x86/entry/common.c:394
entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
other info that might help us debug this:
Chain exists of:
console_owner --> &port_lock_key --> &(&port->lock)->rlock
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&(&port->lock)->rlock);
lock(&port_lock_key);
lock(&(&port->lock)->rlock);
lock(console_owner);
*** DEADLOCK ***
6 locks held by syz-executor0/4774:
#0: (ptrval) (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: (ptrval) (&o_tty->termios_rwsem/1){++++}, at:
tty_set_termios+0xfd/0xac0 drivers/tty/tty_ioctl.c:328
#2: (ptrval) (&tty->ldisc_sem){++++}, at: tty_ldisc_ref+0x22/0x90
drivers/tty/tty_ldisc.c:284
#3: (ptrval) (&ldata->output_lock){+.+.}, at:
process_echoes+0xb6/0x170 drivers/tty/n_tty.c:779
#4: (ptrval) (&(&port->lock)->rlock){-.-.}, at:
pty_write+0xf9/0x1f0 drivers/tty/pty.c:119
#5: (ptrval) (console_lock){+.+.}, at: console_trylock_spinning
kernel/printk/printk.c:1643 [inline]
#5: (ptrval) (console_lock){+.+.}, at: vprintk_emit+0x694/0xdd0
kernel/printk/printk.c:1906
stack backtrace:
CPU: 1 PID: 4774 Comm: syz-executor0 Not tainted 4.17.0+ #111
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
print_circular_bug.isra.36.cold.56+0x1bd/0x27d
kernel/locking/lockdep.c:1227
check_prev_add kernel/locking/lockdep.c:1867 [inline]
check_prevs_add kernel/locking/lockdep.c:1980 [inline]
validate_chain kernel/locking/lockdep.c:2421 [inline]
__lock_acquire+0x343e/0x5140 kernel/locking/lockdep.c:3435
lock_acquire+0x1dc/0x520 kernel/locking/lockdep.c:3924
console_lock_spinning_enable kernel/printk/printk.c:1581 [inline]
console_unlock+0x5ef/0x1100 kernel/printk/printk.c:2392
vprintk_emit+0x6ad/0xdd0 kernel/printk/printk.c:1907
vprintk_default+0x28/0x30 kernel/printk/printk.c:1947
vprintk_func+0x7a/0xe7 kernel/printk/printk_safe.c:379
printk+0x9e/0xba kernel/printk/printk.c:1980
fail_dump lib/fault-inject.c:44 [inline]
should_fail+0x97a/0xbcd lib/fault-inject.c:149
__should_failslab+0x124/0x180 mm/failslab.c:32
should_failslab+0x9/0x14 mm/slab_common.c:1522
slab_pre_alloc_hook mm/slab.h:423 [inline]
slab_alloc mm/slab.c:3378 [inline]
__do_kmalloc mm/slab.c:3716 [inline]
__kmalloc+0x63/0x760 mm/slab.c:3727
kmalloc include/linux/slab.h:517 [inline]
tty_buffer_alloc drivers/tty/tty_buffer.c:170 [inline]
__tty_buffer_request_room+0x2d2/0x7f0 drivers/tty/tty_buffer.c:268
tty_insert_flip_string_fixed_flag+0x8d/0x1f0 drivers/tty/tty_buffer.c:313
tty_insert_flip_string include/linux/tty_flip.h:37 [inline]
pty_write+0x12c/0x1f0 drivers/tty/pty.c:121
tty_put_char+0x129/0x150 drivers/tty/tty_io.c:2865
__process_echoes+0x4d9/0x8d0 drivers/tty/n_tty.c:703
process_echoes+0xfc/0x170 drivers/tty/n_tty.c:781
n_tty_set_termios+0xb56/0xe80 drivers/tty/n_tty.c:1837
tty_set_termios+0x7a0/0xac0 drivers/tty/tty_ioctl.c:341
set_termios+0x41e/0x7d0 drivers/tty/tty_ioctl.c:414
tty_mode_ioctl+0x871/0xb50 drivers/tty/tty_ioctl.c:781
n_tty_ioctl_helper+0x54/0x3b0 drivers/tty/tty_ioctl.c:940
n_tty_ioctl+0x54/0x320 drivers/tty/n_tty.c:2441
tty_ioctl+0x5e1/0x1870 drivers/tty/tty_io.c:2655
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:500 [inline]
do_vfs_ioctl+0x1cf/0x16f0 fs/ioctl.c:684
__do_compat_sys_ioctl fs/compat_ioctl.c:1483 [inline]
__se_compat_sys_ioctl fs/compat_ioctl.c:1407 [inline]
__ia32_compat_sys_ioctl+0x43e/0x640 fs/compat_ioctl.c:1407
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: possible deadlock in console_unlock
2018-06-06 13:17 possible deadlock in console_unlock syzbot
@ 2018-06-07 4:44 ` syzbot
2018-06-07 5:10 ` Sergey Senozhatsky
2019-11-25 2:41 ` syzbot
2 siblings, 0 replies; 22+ messages in thread
From: syzbot @ 2018-06-07 4:44 UTC (permalink / raw)
To: linux-kernel, pmladek, rostedt, sergey.senozhatsky, syzkaller-bugs
syzbot has found a reproducer for the following crash on:
HEAD commit: 0ad39cb3d70f Merge tag 'kconfig-v4.18' of git://git.kernel..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1158868f800000
kernel config: https://syzkaller.appspot.com/x/.config?x=b9a1f3aa8b8ddd16
dashboard link: https://syzkaller.appspot.com/bug?extid=43e93968b964e369db0b
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=14c89b9f800000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=167f596f800000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+43e93968b964e369db0b@syzkaller.appspotmail.com
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f3350380d80 R14: 0000000000000004 R15: 6d74702f7665642f
CPU: 1 PID: 4456 Comm: syz-executor589 Not tainted 4.17.0+ #87
======================================================
WARNING: possible circular locking dependency detected
4.17.0+ #87 Not tainted
------------------------------------------------------
syz-executor589/4455 is trying to acquire lock:
(ptrval) (console_owner){-...}, at: log_next
kernel/printk/printk.c:496 [inline]
(ptrval) (console_owner){-...}, at: console_unlock+0x583/0x1100
kernel/printk/printk.c:2382
but task is already holding lock:
(ptrval) (&(&port->lock)->rlock){-.-.}, at: pty_write+0xf9/0x1f0
drivers/tty/pty.c:119
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&(&port->lock)->rlock){-.-.}:
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:152
tty_port_tty_get+0x20/0x80 drivers/tty/tty_port.c:288
tty_port_default_wakeup+0x15/0x40 drivers/tty/tty_port.c:47
tty_port_tty_wakeup+0x5d/0x70 drivers/tty/tty_port.c:390
uart_write_wakeup+0x44/0x60 drivers/tty/serial/serial_core.c:103
serial8250_tx_chars+0x4be/0xb60
drivers/tty/serial/8250/8250_port.c:1808
serial8250_handle_irq.part.25+0x1ee/0x280
drivers/tty/serial/8250/8250_port.c:1881
serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1867
[inline]
serial8250_default_handle_irq+0xc8/0x150
drivers/tty/serial/8250/8250_port.c:1897
serial8250_interrupt+0xfa/0x1d0
drivers/tty/serial/8250/8250_core.c:125
__handle_irq_event_percpu+0x1c0/0xad0 kernel/irq/handle.c:149
handle_irq_event_percpu+0x98/0x1c0 kernel/irq/handle.c:189
handle_irq_event+0xa7/0x135 kernel/irq/handle.c:206
handle_edge_irq+0x20f/0x870 kernel/irq/chip.c:791
generic_handle_irq_desc include/linux/irqdesc.h:159 [inline]
handle_irq+0x18c/0x2e7 arch/x86/kernel/irq_64.c:77
do_IRQ+0x78/0x190 arch/x86/kernel/irq.c:245
ret_from_intr+0x0/0x1e
arch_local_irq_restore arch/x86/include/asm/paravirt.h:783 [inline]
__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:160
[inline]
_raw_spin_unlock_irqrestore+0xa1/0xc0 kernel/locking/spinlock.c:184
spin_unlock_irqrestore include/linux/spinlock.h:365 [inline]
uart_write+0x3df/0x620 drivers/tty/serial/serial_core.c:591
process_output_block drivers/tty/n_tty.c:579 [inline]
n_tty_write+0x6b9/0x1180 drivers/tty/n_tty.c:2308
do_tty_write drivers/tty/tty_io.c:958 [inline]
tty_write+0x3f1/0x880 drivers/tty/tty_io.c:1042
redirected_tty_write+0xaf/0xc0 drivers/tty/tty_io.c:1063
__vfs_write+0x10b/0x960 fs/read_write.c:485
vfs_write+0x1f8/0x560 fs/read_write.c:549
ksys_write+0xf9/0x250 fs/read_write.c:598
__do_sys_write fs/read_write.c:610 [inline]
__se_sys_write fs/read_write.c:607 [inline]
__x64_sys_write+0x73/0xb0 fs/read_write.c:607
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #1 (&port_lock_key){-.-.}:
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:152
serial8250_console_write+0x8d5/0xb00
drivers/tty/serial/8250/8250_port.c:3230
univ8250_console_write+0x5f/0x70
drivers/tty/serial/8250/8250_core.c:590
call_console_drivers kernel/printk/printk.c:1718 [inline]
console_unlock+0xac2/0x1100 kernel/printk/printk.c:2395
vprintk_emit+0x6ad/0xdd0 kernel/printk/printk.c:1907
vprintk_default+0x28/0x30 kernel/printk/printk.c:1947
vprintk_func+0x7a/0xe7 kernel/printk/printk_safe.c:379
printk+0x9e/0xba kernel/printk/printk.c:1980
register_console+0x7e7/0xc00 kernel/printk/printk.c:2714
univ8250_console_init+0x3f/0x4b
drivers/tty/serial/8250/8250_core.c:685
console_init+0x6d9/0xa38 kernel/printk/printk.c:2798
start_kernel+0x608/0x92d init/main.c:661
x86_64_start_reservations+0x29/0x2b arch/x86/kernel/head64.c:452
x86_64_start_kernel+0x76/0x79 arch/x86/kernel/head64.c:433
secondary_startup_64+0xa5/0xb0 arch/x86/kernel/head_64.S:242
-> #0 (console_owner){-...}:
lock_acquire+0x1dc/0x520 kernel/locking/lockdep.c:3924
console_lock_spinning_enable kernel/printk/printk.c:1581 [inline]
console_unlock+0x5ef/0x1100 kernel/printk/printk.c:2392
vprintk_emit+0x6ad/0xdd0 kernel/printk/printk.c:1907
vprintk_default+0x28/0x30 kernel/printk/printk.c:1947
vprintk_func+0x7a/0xe7 kernel/printk/printk_safe.c:379
printk+0x9e/0xba kernel/printk/printk.c:1980
fail_dump lib/fault-inject.c:44 [inline]
should_fail+0x97a/0xbcd lib/fault-inject.c:149
__should_failslab+0x124/0x180 mm/failslab.c:32
should_failslab+0x9/0x14 mm/slab_common.c:1522
slab_pre_alloc_hook mm/slab.h:423 [inline]
slab_alloc mm/slab.c:3378 [inline]
__do_kmalloc mm/slab.c:3716 [inline]
__kmalloc+0x63/0x760 mm/slab.c:3727
kmalloc include/linux/slab.h:517 [inline]
tty_buffer_alloc drivers/tty/tty_buffer.c:170 [inline]
__tty_buffer_request_room+0x2d2/0x7f0 drivers/tty/tty_buffer.c:268
tty_insert_flip_string_fixed_flag+0x8d/0x1f0
drivers/tty/tty_buffer.c:313
tty_insert_flip_string include/linux/tty_flip.h:37 [inline]
pty_write+0x12c/0x1f0 drivers/tty/pty.c:121
n_tty_write+0xc41/0x1180 drivers/tty/n_tty.c:2331
do_tty_write drivers/tty/tty_io.c:958 [inline]
tty_write+0x3f1/0x880 drivers/tty/tty_io.c:1042
do_loop_readv_writev fs/read_write.c:703 [inline]
do_iter_write+0x491/0x5f0 fs/read_write.c:961
vfs_writev+0x1c7/0x330 fs/read_write.c:1004
do_writev+0x112/0x2f0 fs/read_write.c:1039
__do_sys_writev fs/read_write.c:1112 [inline]
__se_sys_writev fs/read_write.c:1109 [inline]
__x64_sys_writev+0x75/0xb0 fs/read_write.c:1109
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
other info that might help us debug this:
Chain exists of:
console_owner --> &port_lock_key --> &(&port->lock)->rlock
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&(&port->lock)->rlock);
lock(&port_lock_key);
lock(&(&port->lock)->rlock);
lock(console_owner);
*** DEADLOCK ***
6 locks held by syz-executor589/4455:
#0: (ptrval) (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: (ptrval) (&tty->atomic_write_lock){+.+.}, at:
tty_write_lock+0x57/0x90 drivers/tty/tty_io.c:887
#2: (ptrval) (&tty->termios_rwsem){++++}, at:
n_tty_write+0x25a/0x1180 drivers/tty/n_tty.c:2291
#3: (ptrval) (&ldata->output_lock){+.+.}, at:
n_tty_write+0xc05/0x1180 drivers/tty/n_tty.c:2330
#4: (ptrval) (&(&port->lock)->rlock){-.-.}, at:
pty_write+0xf9/0x1f0 drivers/tty/pty.c:119
#5: (ptrval) (console_lock){+.+.}, at: console_trylock_spinning
kernel/printk/printk.c:1643 [inline]
#5: (ptrval) (console_lock){+.+.}, at: vprintk_emit+0x694/0xdd0
kernel/printk/printk.c:1906
stack backtrace:
CPU: 0 PID: 4455 Comm: syz-executor589 Not tainted 4.17.0+ #87
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
print_circular_bug.isra.36.cold.56+0x1bd/0x27d
kernel/locking/lockdep.c:1227
check_prev_add kernel/locking/lockdep.c:1867 [inline]
check_prevs_add kernel/locking/lockdep.c:1980 [inline]
validate_chain kernel/locking/lockdep.c:2421 [inline]
__lock_acquire+0x343e/0x5140 kernel/locking/lockdep.c:3435
lock_acquire+0x1dc/0x520 kernel/locking/lockdep.c:3924
console_lock_spinning_enable kernel/printk/printk.c:1581 [inline]
console_unlock+0x5ef/0x1100 kernel/printk/printk.c:2392
vprintk_emit+0x6ad/0xdd0 kernel/printk/printk.c:1907
vprintk_default+0x28/0x30 kernel/printk/printk.c:1947
vprintk_func+0x7a/0xe7 kernel/printk/printk_safe.c:379
printk+0x9e/0xba kernel/printk/printk.c:1980
fail_dump lib/fault-inject.c:44 [inline]
should_fail+0x97a/0xbcd lib/fault-inject.c:149
__should_failslab+0x124/0x180 mm/failslab.c:32
should_failslab+0x9/0x14 mm/slab_common.c:1522
slab_pre_alloc_hook mm/slab.h:423 [inline]
slab_alloc mm/slab.c:3378 [inline]
__do_kmalloc mm/slab.c:3716 [inline]
__kmalloc+0x63/0x760 mm/slab.c:3727
kmalloc include/linux/slab.h:517 [inline]
tty_buffer_alloc drivers/tty/tty_buffer.c:170 [inline]
__tty_buffer_request_room+0x2d2/0x7f0 drivers/tty/tty_buffer.c:268
tty_insert_flip_string_fixed_flag+0x8d/0x1f0 drivers/tty/tty_buffer.c:313
tty_insert_flip_string include/linux/tty_flip.h:37 [inline]
pty_write+0x12c/0x1f0 drivers/tty/pty.c:121
n_tty_write+0xc41/0x1180 drivers/tty/n_tty.c:2331
do_tty_write drivers/tty/tty_io.c:958 [inline]
tty_write+0x3f1/0x880 drivers/tty/tty_io.c:1042
do_loop_readv_writev fs/read_write.c:703 [inline]
do_iter_write+0x491/0x5f0 fs/read_write.c:961
vfs_writev+0x1c7/0x330 fs/read_write.c:1004
do_writev+0x112/0x2f0 fs/read_write.c:1039
__do_sys_writev fs/read_write.c:1112 [inline]
__se_sys_writev fs/read_write.c:1109 [inline]
__x64_sys_writev+0x75/0xb0 fs/read_write.c:1109
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x445959
Code: e8 9c bc 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 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 0f 83 8b 12 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f3350380d78 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 00000000006dbc3c RCX: 0000000000445959
RDX: 0000000000000001 RSI: 0000000020000600 RDI: 0000000000000003
RBP: 00000000006dbc38 R08: 0000000000000001 R09: 0000000000000031
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f3350380d80 R14: 0000000000000004 R15: 6d74702f7665642f
FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
fail_dump lib/fault-inject.c:51 [inline]
should_fail.cold.4+0xa/0x1a lib/fault-inject.c:149
__should_failslab+0x124/0x180 mm/failslab.c:32
should_failslab+0x9/0x14 mm/slab_common.c:1522
slab_pre_alloc_hook mm/slab.h:423 [inline]
slab_alloc mm/slab.c:3378 [inline]
__do_kmalloc mm/slab.c:3716 [inline]
__kmalloc+0x63/0x760 mm/slab.c:3727
kmalloc include/linux/slab.h:517 [inline]
tty_buffer_alloc drivers/tty/tty_buffer.c:170 [inline]
__tty_buffer_request_room+0x2d2/0x7f0 drivers/tty/tty_buffer.c:268
tty_insert_flip_string_fixed_flag+0x8d/0x1f0 drivers/tty/tty_buffer.c:313
tty_insert_flip_string include/linux/tty_flip.h:37 [inline]
pty_write+0x12c/0x1f0 drivers/tty/pty.c:121
n_tty_write+0xc41/0x1180 drivers/tty/n_tty.c:2331
do_tty_write drivers/tty/tty_io.c:958 [inline]
tty_write+0x3f1/0x880 drivers/tty/tty_io.c:1042
do_loop_readv_writev fs/read_write.c:703 [inline]
do_iter_write+0x491/0x5f0 fs/read_write.c:961
vfs_writev+0x1c7/0x330 fs/read_write.c:1004
do_writev+0x112/0x2f0 fs/read_write.c:1039
__do_sys_writev fs/read_write.c:1112 [inline]
__se_sys_writev fs/read_write.c:1109 [inline]
__x64_sys_writev+0x75/0xb0 fs/read_write.c:1109
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x445959
Code: e8 9c bc 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 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 0f 83 8b 12 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f335035fd78 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 00000000006dbc54 RCX: 0000000000445959
RDX: 0000000000000001 RSI: 0000000020000600 RDI: 0000000000000005
RBP: 00000000006dbc50 R08: 0000000000000001 R09: 0000000000000031
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f335035fd80 R14: 0000000000000006 R15: 6d74702f7665642f
CPU: 0 PID: 4457 Comm: syz-executor589 Not tainted 4.17.0+ #87
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
fail_dump lib/fault-inject.c:51 [inline]
should_fail.cold.4+0xa/0x1a lib/fault-inject.c:149
FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
__should_failslab+0x124/0x180 mm/failslab.c:32
should_failslab+0x9/0x14 mm/slab_common.c:1522
slab_pre_alloc_hook mm/slab.h:423 [inline]
slab_alloc mm/slab.c:3378 [inline]
__do_kmalloc mm/slab.c:3716 [inline]
__kmalloc+0x63/0x760 mm/slab.c:3727
kmalloc include/linux/slab.h:517 [inline]
tty_buffer_alloc drivers/tty/tty_buffer.c:170 [inline]
__tty_buffer_request_room+0x2d2/0x7f0 drivers/tty/tty_buffer.c:268
tty_insert_flip_string_fixed_flag+0x8d/0x1f0 drivers/tty/tty_buffer.c:313
tty_insert_flip_string include/linux/tty_flip.h:37 [inline]
pty_write+0x12c/0x1f0 drivers/tty/pty.c:121
n_tty_write+0xc41/0x1180 drivers/tty/n_tty.c:2331
do_tty_write drivers/tty/tty_io.c:958 [inline]
tty_write+0x3f1/0x880 drivers/tty/tty_io.c:1042
do_loop_readv_writev fs/read_write.c:703 [inline]
do_iter_write+0x491/0x5f0 fs/read_write.c:961
vfs_writev+0x1c7/0x330 fs/read_write.c:1004
do_writev+0x112/0x2f0 fs/read_write.c:1039
__do_sys_writev fs/read_write.c:1112 [inline]
__se_sys_writev fs/read_write.c:1109 [inline]
__x64_sys_writev+0x75/0xb0 fs/read_write.c:1109
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x445959
Code: e8 9c bc 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 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 0f 83 8b 12 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f335033ed78 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 00000000006dbc6c RCX: 0000000000445959
RDX: 0000000000000001 RSI: 0000000020000600 RDI: 0000000000000007
RBP: 00000000006dbc68 R08: 0000000000000001 R09: 0000000000000031
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f335033ed80 R14: 0000000000000008 R15: 6d74702f7665642f
CPU: 1 PID: 4458 Comm: syz-executor589 Not tainted 4.17.0+ #87
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
fail_dump lib/fault-inject.c:51 [inline]
should_fail.cold.4+0xa/0x1a lib/fault-inject.c:149
FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
__should_failslab+0x124/0x180 mm/failslab.c:32
should_failslab+0x9/0x14 mm/slab_common.c:1522
slab_pre_alloc_hook mm/slab.h:423 [inline]
slab_alloc mm/slab.c:3378 [inline]
__do_kmalloc mm/slab.c:3716 [inline]
__kmalloc+0x63/0x760 mm/slab.c:3727
kmalloc include/linux/slab.h:517 [inline]
tty_buffer_alloc drivers/tty/tty_buffer.c:170 [inline]
__tty_buffer_request_room+0x2d2/0x7f0 drivers/tty/tty_buffer.c:268
tty_insert_flip_string_fixed_flag+0x8d/0x1f0 drivers/tty/tty_buffer.c:313
tty_insert_flip_string include/linux/tty_flip.h:37 [inline]
pty_write+0x12c/0x1f0 drivers/tty/pty.c:121
n_tty_write+0xc41/0x1180 drivers/tty/n_tty.c:2331
do_tty_write drivers/tty/tty_io.c:958 [inline]
tty_write+0x3f1/0x880 drivers/tty/tty_io.c:1042
do_loop_readv_writev fs/read_write.c:703 [inline]
do_iter_write+0x491/0x5f0 fs/read_write.c:961
vfs_writev+0x1c7/0x330 fs/read_write.c:1004
do_writev+0x112/0x2f0 fs/read_write.c:1039
__do_sys_writev fs/read_write.c:1112 [inline]
__se_sys_writev fs/read_write.c:1109 [inline]
__x64_sys_writev+0x75/0xb0 fs/read_write.c:1109
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x445959
Code: e8 9c bc 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 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 0f 83 8b 12 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f335031dd78 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 00000000006dbc84 RCX: 0000000000445959
RDX: 0000000000000001 RSI: 0000000020000600 RDI: 0000000000000009
RBP: 00000000006dbc80 R08: 0000000000000001 R09: 0000000000000031
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f335031dd80 R14: 000000000000000a R15: 6d74702f7665642f
CPU: 0 PID: 4459 Comm: syz-executor589 Not tainted 4.17.0+ #87
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
fail_dump lib/fault-inject.c:51 [inline]
should_fail.cold.4+0xa/0x1a lib/fault-inject.c:149
FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
__should_failslab+0x124/0x180 mm/failslab.c:32
should_failslab+0x9/0x14 mm/slab_common.c:1522
slab_pre_alloc_hook mm/slab.h:423 [inline]
slab_alloc mm/slab.c:3378 [inline]
__do_kmalloc mm/slab.c:3716 [inline]
__kmalloc+0x63/0x760 mm/slab.c:3727
kmalloc include/linux/slab.h:517 [inline]
tty_buffer_alloc drivers/tty/tty_buffer.c:170 [inline]
__tty_buffer_request_room+0x2d2/0x7f0 drivers/tty/tty_buffer.c:268
tty_insert_flip_string_fixed_flag+0x8d/0x1f0 drivers/tty/tty_buffer.c:313
tty_insert_flip_string include/linux/tty_flip.h:37 [inline]
pty_write+0x12c/0x1f0 drivers/tty/pty.c:121
n_tty_write+0xc41/0x1180 drivers/tty/n_tty.c:2331
do_tty_write drivers/tty/tty_io.c:958 [inline]
tty_write+0x3f1/0x880 drivers/tty/tty_io.c:1042
do_loop_readv_writev fs/read_write.c:703 [inline]
do_iter_write+0x491/0x5f0 fs/read_write.c:961
vfs_writev+0x1c7/0x330 fs/read_write.c:1004
do_writev+0x112/0x2f0 fs/read_write.c:1039
__do_sys_writev fs/read_write.c:1112 [inline]
__se_sys_writev fs/read_write.c:1109 [inline]
__x64_sys_writev+0x75/0xb0 fs/read_write.c:1109
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x445959
Code: e8 9c bc 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 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 0f 83 8b 12 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f33502fcd78 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 00000000006dbc9c RCX: 0000000000445959
RDX: 0000000000000001 RSI: 0000000020000600 RDI: 000000000000000b
RBP: 00000000006dbc98 R08: 0000000000000001 R09: 0000000000000031
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f33502fcd80 R14: 000000000000000c R15: 6d74702f7665642f
CPU: 1 PID: 4460 Comm: syz-executor589 Not tainted 4.17.0+ #87
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
fail_dump lib/fault-inject.c:51 [inline]
should_fail.cold.4+0xa/0x1a lib/fault-inject.c:149
FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
__should_failslab+0x124/0x180 mm/failslab.c:32
should_failslab+0x9/0x14 mm/slab_common.c:1522
slab_pre_alloc_hook mm/slab.h:423 [inline]
slab_alloc mm/slab.c:3378 [inline]
__do_kmalloc mm/slab.c:3716 [inline]
__kmalloc+0x63/0x760 mm/slab.c:3727
kmalloc include/linux/slab.h:517 [inline]
tty_buffer_alloc drivers/tty/tty_buffer.c:170 [inline]
__tty_buffer_request_room+0x2d2/0x7f0 drivers/tty/tty_buffer.c:268
tty_insert_flip_string_fixed_flag+0x8d/0x1f0 drivers/tty/tty_buffer.c:313
tty_insert_flip_string include/linux/tty_flip.h:37 [inline]
pty_write+0x12c/0x1f0 drivers/tty/pty.c:121
n_tty_write+0xc41/0x1180 drivers/tty/n_tty.c:2331
do_tty_write drivers/tty/tty_io.c:958 [inline]
tty_write+0x3f1/0x880 drivers/tty/tty_io.c:1042
do_loop_readv_writev fs/read_write.c:703 [inline]
do_iter_write+0x491/0x5f0 fs/read_write.c:961
vfs_writev+0x1c7/0x330 fs/read_write.c:1004
do_writev+0x112/0x2f0 fs/read_write.c:1039
__do_sys_writev fs/read_write.c:1112 [inline]
__se_sys_writev fs/read_write.c:1109 [inline]
__x64_sys_writev+0x75/0xb0 fs/read_write.c:1109
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x445959
Code: e8 9c bc 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 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 0f 83 8b 12 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f33502dbd78 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 00000000006dbcb4 RCX: 0000000000445959
RDX: 0000000000000001 RSI: 0000000020000600 RDI: 000000000000000d
RBP: 00000000006dbcb0 R08: 0000000000000001 R09: 0000000000000031
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f33502dbd80 R14: 000000000000000e R15: 6d74702f7665642f
CPU: 0 PID: 4461 Comm: syz-executor589 Not tainted 4.17.0+ #87
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
fail_dump lib/fault-inject.c:51 [inline]
should_fail.cold.4+0xa/0x1a lib/fault-inject.c:149
FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
__should_failslab+0x124/0x180 mm/failslab.c:32
should_failslab+0x9/0x14 mm/slab_common.c:1522
slab_pre_alloc_hook mm/slab.h:423 [inline]
slab_alloc mm/slab.c:3378 [inline]
__do_kmalloc mm/slab.c:3716 [inline]
__kmalloc+0x63/0x760 mm/slab.c:3727
kmalloc include/linux/slab.h:517 [inline]
tty_buffer_alloc drivers/tty/tty_buffer.c:170 [inline]
__tty_buffer_request_room+0x2d2/0x7f0 drivers/tty/tty_buffer.c:268
tty_insert_flip_string_fixed_flag+0x8d/0x1f0 drivers/tty/tty_buffer.c:313
tty_insert_flip_string include/linux/tty_flip.h:37 [inline]
pty_write+0x12c/0x1f0 drivers/tty/pty.c:121
n_tty_write+0xc41/0x1180 drivers/tty/n_tty.c:2331
do_tty_write drivers/tty/tty_io.c:958 [inline]
tty_write+0x3f1/0x880 drivers/tty/tty_io.c:1042
do_loop_readv_writev fs/read_write.c:703 [inline]
do_iter_write+0x491/0x5f0 fs/read_write.c:961
vfs_writev+0x1c7/0x330 fs/read_write.c:1004
do_writev+0x112/0x2f0 fs/read_write.c:1039
__do_sys_writev fs/read_write.c:1112 [inline]
__se_sys_writev fs/read_write.c:1109 [inline]
__x64_sys_writev+0x75/0xb0 fs/read_write.c:1109
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x445959
Code: e8 9c bc 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 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 0f 83 8b 12 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f33502bad78 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 00000000006dbccc RCX: 0000000000445959
RDX: 0000000000000001 RSI: 0000000020000600 RDI: 000000000000000f
RBP: 00000000006dbcc8 R08: 0000000000000001 R09: 0000000000000031
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f33502bad80 R14: 0000000000000010 R15: 6d74702f7665642f
CPU: 1 PID: 4462 Comm: syz-executor589 Not tainted 4.17.0+ #87
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
fail_dump lib/fault-inject.c:51 [inline]
should_fail.cold.4+0xa/0x1a lib/fault-inject.c:149
FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
__should_failslab+0x124/0x180 mm/failslab.c:32
should_failslab+0x9/0x14 mm/slab_common.c:1522
slab_pre_alloc_hook mm/slab.h:423 [inline]
slab_alloc mm/slab.c:3378 [inline]
__do_kmalloc mm/slab.c:3716 [inline]
__kmalloc+0x63/0x760 mm/slab.c:3727
kmalloc include/linux/slab.h:517 [inline]
tty_buffer_alloc drivers/tty/tty_buffer.c:170 [inline]
__tty_buffer_request_room+0x2d2/0x7f0 drivers/tty/tty_buffer.c:268
tty_insert_flip_string_fixed_flag+0x8d/0x1f0 drivers/tty/tty_buffer.c:313
tty_insert_flip_string include/linux/tty_flip.h:37 [inline]
pty_write+0x12c/0x1f0 drivers/tty/pty.c:121
n_tty_write+0xc41/0x1180 drivers/tty/n_tty.c:2331
do_tty_write drivers/tty/tty_io.c:958 [inline]
tty_write+0x3f1/0x880 drivers/tty/tty_io.c:1042
do_loop_readv_writev fs/read_write.c:703 [inline]
do_iter_write+0x491/0x5f0 fs/read_write.c:961
vfs_writev+0x1c7/0x330 fs/read_write.c:1004
do_writev+0x112/0x2f0 fs/read_write.c:1039
__do_sys_writev fs/read_write.c:1112 [inline]
__se_sys_writev fs/read_write.c:1109 [inline]
__x64_sys_writev+0x75/0xb0 fs/read_write.c:1109
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x445959
Code: e8 9c bc 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 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 0f 83 8b 12 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f3350299d78 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 00000000006dbce4 RCX: 0000000000445959
RDX: 0000000000000001 RSI: 0000000020000600 RDI: 0000000000000011
RBP: 00000000006dbce0 R08: 0000000000000001 R09: 0000000000000031
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f3350299d80 R14: 0000000000000012 R15: 6d74702f7665642f
CPU: 0 PID: 4463 Comm: syz-executor589 Not tainted 4.17.0+ #87
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
fail_dump lib/fault-inject.c:51 [inline]
should_fail.cold.4+0xa/0x1a lib/fault-inject.c:149
FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
__should_failslab+0x124/0x180 mm/failslab.c:32
should_failslab+0x9/0x14 mm/slab_common.c:1522
slab_pre_alloc_hook mm/slab.h:423 [inline]
slab_alloc mm/slab.c:3378 [inline]
__do_kmalloc mm/slab.c:3716 [inline]
__kmalloc+0x63/0x760 mm/slab.c:3727
kmalloc include/linux/slab.h:517 [inline]
tty_buffer_alloc drivers/tty/tty_buffer.c:170 [inline]
__tty_buffer_request_room+0x2d2/0x7f0 drivers/tty/tty_buffer.c:268
tty_insert_flip_string_fixed_flag+0x8d/0x1f0 drivers/tty/tty_buffer.c:313
tty_insert_flip_string include/linux/tty_flip.h:37 [inline]
pty_write+0x12c/0x1f0 drivers/tty/pty.c:121
n_tty_write+0xc41/0x1180 drivers/tty/n_tty.c:2331
do_tty_write drivers/tty/tty_io.c:958 [inline]
tty_write+0x3f1/0x880 drivers/tty/tty_io.c:1042
do_loop_readv_writev fs/read_write.c:703 [inline]
do_iter_write+0x491/0x5f0 fs/read_write.c:961
vfs_writev+0x1c7/0x330 fs/read_write.c:1004
do_writev+0x112/0x2f0 fs/read_write.c:1039
__do_sys_writev fs/read_write.c:1112 [inline]
__se_sys_writev fs/read_write.c:1109 [inline]
__x64_sys_writev+0x75/0xb0 fs/read_write.c:1109
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x445959
Code: e8 9c bc 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 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 0f 83 8b 12 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f3350278d78 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 00000000006dbcfc RCX: 0000000000445959
RDX: 0000000000000001 RSI: 0000000020000600 RDI: 0000000000000013
RBP: 00000000006dbcf8 R08: 0000000000000001 R09: 0000000000000031
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f3350278d80 R14: 0000000000000014 R15: 6d74702f7665642f
CPU: 1 PID: 4464 Comm: syz-executor589 Not tainted 4.17.0+ #87
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
fail_dump lib/fault-inject.c:51 [inline]
should_fail.cold.4+0xa/0x1a lib/fault-inject.c:149
FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
__should_failslab+0x124/0x180 mm/failslab.c:32
should_failslab+0x9/0x14 mm/slab_common.c:1522
slab_pre_alloc_hook mm/slab.h:423 [inline]
slab_alloc mm/slab.c:3378 [inline]
__do_kmalloc mm/slab.c:3716 [inline]
__kmalloc+0x63/0x760 mm/slab.c:3727
kmalloc include/linux/slab.h:517 [inline]
tty_buffer_alloc drivers/tty/tty_buffer.c:170 [inline]
__tty_buffer_request_room+0x2d2/0x7f0 drivers/tty/tty_buffer.c:268
tty_insert_flip_string_fixed_flag+0x8d/0x1f0 drivers/tty/tty_buffer.c:313
tty_insert_flip_string include/linux/tty_flip.h:37 [inline]
pty_write+0x12c/0x1f0 drivers/tty/pty.c:121
n_tty_write+0xc41/0x1180 drivers/tty/n_tty.c:2331
do_tty_write drivers/tty/tty_io.c:958 [inline]
tty_write+0x3f1/0x880 drivers/tty/tty_io.c:1042
do_loop_readv_writev fs/read_write.c:703 [inline]
do_iter_write+0x491/0x5f0 fs/read_write.c:961
vfs_writev+0x1c7/0x330 fs/read_write.c:1004
do_writev+0x112/0x2f0 fs/read_write.c:1039
__do_sys_writev fs/read_write.c:1112 [inline]
__se_sys_writev fs/read_write.c:1109 [inline]
__x64_sys_writev+0x75/0xb0 fs/read_write.c:1109
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x445959
Code: e8 9c bc 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 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 0f 83 8b 12 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f3350257d78 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 00000000006dbd14 RCX: 0000000000445959
RDX: 0000000000000001 RSI: 0000000020000600 RDI: 0000000000000015
RBP: 00000000006dbd10 R08: 0000000000000001 R09: 0000000000000031
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f3350257d80 R14: 0000000000000016 R15: 6d74702f7665642f
CPU: 0 PID: 4465 Comm: syz-executor589 Not tainted 4.17.0+ #87
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
fail_dump lib/fault-inject.c:51 [inline]
should_fail.cold.4+0xa/0x1a lib/fault-inject.c:149
FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
__should_failslab+0x124/0x180 mm/failslab.c:32
should_failslab+0x9/0x14 mm/slab_common.c:1522
slab_pre_alloc_hook mm/slab.h:423 [inline]
slab_alloc mm/slab.c:3378 [inline]
__do_kmalloc mm/slab.c:3716 [inline]
__kmalloc+0x63/0x760 mm/slab.c:3727
kmalloc include/linux/slab.h:517 [inline]
tty_buffer_alloc drivers/tty/tty_buffer.c:170 [inline]
__tty_buffer_request_room+0x2d2/0x7f0 drivers/tty/tty_buffer.c:268
tty_insert_flip_string_fixed_flag+0x8d/0x1f0 drivers/tty/tty_buffer.c:313
tty_insert_flip_string include/linux/tty_flip.h:37 [inline]
pty_write+0x12c/0x1f0 drivers/tty/pty.c:121
n_tty_write+0xc41/0x1180 drivers/tty/n_tty.c:2331
do_tty_write drivers/tty/tty_io.c:958 [inline]
tty_write+0x3f1/0x880 drivers/tty/tty_io.c:1042
do_loop_readv_writev fs/read_write.c:703 [inline]
do_iter_write+0x491/0x5f0 fs/read_write.c:961
vfs_writev+0x1c7/0x330 fs/read_write.c:1004
do_writev+0x112/0x2f0 fs/read_write.c:1039
__do_sys_writev fs/read_write.c:1112 [inline]
__se_sys_writev fs/read_write.c:1109 [inline]
__x64_sys_writev+0x75/0xb0 fs/read_write.c:1109
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x445959
Code: e8 9c bc 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 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 0f 83 8b 12 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f3350236d78 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 00000000006dbd2c RCX: 0000000000445959
RDX: 0000000000000001 RSI: 0000000020000600 RDI: 0000000000000017
RBP: 00000000006dbd28 R08: 0000000000000001 R09: 0000000000000031
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f3350236d80 R14: 0000000000000018 R15: 6d74702f7665642f
CPU: 1 PID: 4466 Comm: syz-executor589 Not tainted 4.17.0+ #87
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
fail_dump lib/fault-inject.c:51 [inline]
should_fail.cold.4+0xa/0x1a lib/fault-inject.c:149
FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
__should_failslab+0x124/0x180 mm/failslab.c:32
should_failslab+0x9/0x14 mm/slab_common.c:1522
slab_pre_alloc_hook mm/slab.h:423 [inline]
slab_alloc mm/slab.c:3378 [inline]
__do_kmalloc mm/slab.c:3716 [inline]
__kmalloc+0x63/0x760 mm/slab.c:3727
kmalloc include/linux/slab.h:517 [inline]
tty_buffer_alloc drivers/tty/tty_buffer.c:170 [inline]
__tty_buffer_request_room+0x2d2/0x7f0 drivers/tty/tty_buffer.c:268
tty_insert_flip_string_fixed_flag+0x8d/0x1f0 drivers/tty/tty_buffer.c:313
tty_insert_flip_string include/linux/tty_flip.h:37 [inline]
pty_write+0x12c/0x1f0 drivers/tty/pty.c:121
n_tty_write+0xc41/0x1180 drivers/tty/n_tty.c:2331
do_tty_write drivers/tty/tty_io.c:958 [inline]
tty_write+0x3f1/0x880 drivers/tty/tty_io.c:1042
do_loop_readv_writev fs/read_write.c:703 [inline]
do_iter_write+0x491/0x5f0 fs/read_write.c:961
vfs_writev+0x1c7/0x330 fs/read_write.c:1004
do_writev+0x112/0x2f0 fs/read_write.c:1039
__do_sys_writev fs/read_write.c:1112 [inline]
__se_sys_writev fs/read_write.c:1109 [inline]
__x64_sys_writev+0x75/0xb0 fs/read_write.c:1109
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x445959
Code: e8 9c bc 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 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 0f 83 8b 12 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f3350215d78 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 00000000006dbd44 RCX: 0000000000445959
RDX: 0000000000000001 RSI: 0000000020000600 RDI: 0000000000000019
RBP: 00000000006dbd40 R08: 0000000000000001 R09: 0000000000000031
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f3350215d80 R14: 000000000000001a R15: 6d74702f7665642f
CPU: 0 PID: 4467 Comm: syz-executor589 Not tainted 4.17.0+ #87
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
fail_dump lib/fault-inject.c:51 [inline]
should_fail.cold.4+0xa/0x1a lib/fault-inject.c:149
FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
__should_failslab+0x124/0x180 mm/failslab.c:32
should_failslab+0x9/0x14 mm/slab_common.c:1522
slab_pre_alloc_hook mm/slab.h:423 [inline]
slab_alloc mm/slab.c:3378 [inline]
__do_kmalloc mm/slab.c:3716 [inline]
__kmalloc+0x63/0x760 mm/slab.c:3727
kmalloc include/linux/slab.h:517 [inline]
tty_buffer_alloc drivers/tty/tty_buffer.c:170 [inline]
__tty_buffer_request_room+0x2d2/0x7f0 drivers/tty/tty_buffer.c:268
tty_insert_flip_string_fixed_flag+0x8d/0x1f0 drivers/tty/tty_buffer.c:313
tty_insert_flip_string include/linux/tty_flip.h:37 [inline]
pty_write+0x12c/0x1f0 drivers/tty/pty.c:121
n_tty_write+0xc41/0x1180 drivers/tty/n_tty.c:2331
do_tty_write drivers/tty/tty_io.c:958 [inline]
tty_write+0x3f1/0x880 drivers/tty/tty_io.c:1042
do_loop_readv_writev fs/read_write.c:703 [inline]
do_iter_write+0x491/0x5f0 fs/read_write.c:961
vfs_writev+0x1c7/0x330 fs/read_write.c:1004
do_writev+0x112/0x2f0 fs/read_write.c:1039
__do_sys_writev fs/read_write.c:1112 [inline]
__se_sys_writev fs/read_write.c:1109 [inline]
__x64_sys_writev+0x75/0xb0 fs/read_write.c:1109
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x445959
Code: e8 9c bc 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 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 0f 83 8b 12 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f33501f4d78 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 00000000006dbd5c RCX: 0000000000445959
RDX: 0000000000000001 RSI: 0000000020000600 RDI: 000000000000001b
RBP: 00000000006dbd58 R08: 0000000000000001 R09: 0000000000000031
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f33501f4d80 R14: 000000000000001c R15: 6d74702f7665642f
CPU: 1 PID: 4468 Comm: syz-executor589 Not tainted 4.17.0+ #87
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
fail_dump lib/fault-inject.c:51 [inline]
should_fail.cold.4+0xa/0x1a lib/fault-inject.c:149
__should_failslab+0x124/0x180 mm/failslab.c:32
should_failslab+0x9/0x14 mm/slab_common.c:1522
slab_pre_alloc_hook mm/slab.h:423 [inline]
slab_alloc mm/slab.c:3378 [inline]
__do_kmalloc mm/slab.c:3716 [inline]
__kmalloc+0x63/0x760 mm/slab.c:3727
kmalloc include/linux/slab.h:517 [inline]
tty_buffer_alloc drivers/tty/tty_buffer.c:170 [inline]
__tty_buffer_request_room+0x2d2/0x7f0 drivers/tty/tty_buffer.c:268
tty_insert_flip_string_fixed_flag+0x8d/0x1f0 drivers/tty/tty_buffer.c:313
tty_insert_flip_string include/linux/tty_flip.h:37 [inline]
pty_write+0x12c/0x1f0 drivers/tty/pty.c:121
n_tty_write+0xc41/0x1180 drivers/tty/n_tty.c:2331
do_tty_write drivers/tty/tty_io.c:958 [inline]
tty_write+0x3f1/0x880 drivers/tty/tty_io.c:1042
do_loop_readv_writev fs/read_write.c:703 [inline]
do_iter_write+0x491/0x5f0 fs/read_write.c:961
vfs_writev+0x1c7/0x330 fs/read_write.c:1004
do_writev+0x112/0x2f0 fs/read_write.c:1039
__do_sys_writev fs/read_write.c:1112 [inline]
__se_sys_writev fs/read_write.c:1109 [inline]
__x64_sys_writev+0x75/0xb0 fs/read_write.c:1109
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x445959
Code: e8 9c bc 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 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 0f 83 8b 12 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f33501d3d78 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 00000000006dbd74 RCX: 0000000000445959
RDX: 0000000000000001 RSI: 0000000020000600 RDI: 000000000000001d
RBP: 00000000006dbd70 R08: 0000000000000001 R09: 0000000000000031
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f33501d3d80 R14: 000000000000001e R15: 6d74702f7665642f
random: crng init done
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: possible deadlock in console_unlock
2018-06-06 13:17 possible deadlock in console_unlock syzbot
2018-06-07 4:44 ` syzbot
@ 2018-06-07 5:10 ` Sergey Senozhatsky
2018-06-07 11:00 ` Petr Mladek
2019-11-25 2:41 ` syzbot
2 siblings, 1 reply; 22+ messages in thread
From: Sergey Senozhatsky @ 2018-06-07 5:10 UTC (permalink / raw)
To: syzbot
Cc: linux-kernel, pmladek, rostedt, sergey.senozhatsky,
syzkaller-bugs, Greg Kroah-Hartman, Jiri Slaby, linux-serial,
Andrew Morton
Cc-ing more people
Link: lkml.kernel.org/r/00000000000087008b056df8fbb3@google.com
On (06/06/18 06:17), syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: af6c5d5e01ad Merge branch 'for-4.18' of git://git.kernel.o..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=173d93ef800000
> kernel config: https://syzkaller.appspot.com/x/.config?x=12ff770540994680
> dashboard link: https://syzkaller.appspot.com/bug?extid=43e93968b964e369db0b
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> userspace arch: i386
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=16e00bb7800000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+43e93968b964e369db0b@syzkaller.appspotmail.com
Thanks a ton!
So tty ioctl is known to be printk-deadlock prone and we don't know
how to handle this in printk, as of now.
ioctl
tty_ioctl
tty_port->lock
printk
call_console_driver
console_driver
uart_port->lock
The problem is that call_console_driver->console_driver also can do
this thing
uart_port->lock
tty_wakeup
tty_port->lock
So we can have the following:
ioctl
tty_ioctl
tty_port->lock
printk
call_console_driver
console_driver
uart_port->lock
tty_wakeup
tty_port->lock << deadlock
But lockdep is complaining about another scenario:
> the existing dependency chain (in reverse order) is:
>
> -> #2 (&(&port->lock)->rlock){-.-.}:
> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
> _raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:152
> tty_port_tty_get+0x20/0x80 drivers/tty/tty_port.c:288
> tty_port_default_wakeup+0x15/0x40 drivers/tty/tty_port.c:47
> tty_port_tty_wakeup+0x5d/0x70 drivers/tty/tty_port.c:390
> uart_write_wakeup+0x44/0x60 drivers/tty/serial/serial_core.c:103
> serial8250_tx_chars+0x4be/0xb60
> drivers/tty/serial/8250/8250_port.c:1808
> serial8250_handle_irq.part.25+0x1ee/0x280
> drivers/tty/serial/8250/8250_port.c:1881
> serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1867
> [inline]
> serial8250_default_handle_irq+0xc8/0x150
> drivers/tty/serial/8250/8250_port.c:1897
> serial8250_interrupt+0xfa/0x1d0
> drivers/tty/serial/8250/8250_core.c:125
> __handle_irq_event_percpu+0x1c0/0xad0 kernel/irq/handle.c:149
> handle_irq_event_percpu+0x98/0x1c0 kernel/irq/handle.c:189
> handle_irq_event+0xa7/0x135 kernel/irq/handle.c:206
> handle_edge_irq+0x20f/0x870 kernel/irq/chip.c:791
> generic_handle_irq_desc include/linux/irqdesc.h:159 [inline]
> handle_irq+0x18c/0x2e7 arch/x86/kernel/irq_64.c:77
> do_IRQ+0x78/0x190 arch/x86/kernel/irq.c:245
> ret_from_intr+0x0/0x1e
> native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:54
> arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline]
> default_idle+0xc2/0x440 arch/x86/kernel/process.c:500
> arch_cpu_idle+0x10/0x20 arch/x86/kernel/process.c:491
> default_idle_call+0x6d/0x90 kernel/sched/idle.c:93
> cpuidle_idle_call kernel/sched/idle.c:153 [inline]
> do_idle+0x395/0x560 kernel/sched/idle.c:262
> cpu_startup_entry+0x104/0x120 kernel/sched/idle.c:368
> start_secondary+0x42b/0x5c0 arch/x86/kernel/smpboot.c:265
> secondary_startup_64+0xa5/0xb0 arch/x86/kernel/head_64.S:242
So this one is IRQ ==> uart_port->lock ==> tty_port->lock
> -> #1 (&port_lock_key){-.-.}:
> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
> _raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:152
> serial8250_console_write+0x8d5/0xb00
> drivers/tty/serial/8250/8250_port.c:3230
> univ8250_console_write+0x5f/0x70
> drivers/tty/serial/8250/8250_core.c:590
> call_console_drivers kernel/printk/printk.c:1718 [inline]
> console_unlock+0xac2/0x1100 kernel/printk/printk.c:2395
> vprintk_emit+0x6ad/0xdd0 kernel/printk/printk.c:1907
> vprintk_default+0x28/0x30 kernel/printk/printk.c:1947
> vprintk_func+0x7a/0xe7 kernel/printk/printk_safe.c:379
> printk+0x9e/0xba kernel/printk/printk.c:1980
> register_console+0x7e7/0xc00 kernel/printk/printk.c:2714
> univ8250_console_init+0x3f/0x4b
> drivers/tty/serial/8250/8250_core.c:685
> console_init+0x6d9/0xa38 kernel/printk/printk.c:2798
> start_kernel+0x608/0x92d init/main.c:661
> x86_64_start_reservations+0x29/0x2b arch/x86/kernel/head64.c:452
> x86_64_start_kernel+0x76/0x79 arch/x86/kernel/head64.c:433
> secondary_startup_64+0xa5/0xb0 arch/x86/kernel/head_64.S:242
This one is console_owner/console_sem ==> uart_port->lock
> -> #0 (console_owner){-...}:
> lock_acquire+0x1dc/0x520 kernel/locking/lockdep.c:3924
> console_lock_spinning_enable kernel/printk/printk.c:1581 [inline]
> console_unlock+0x5ef/0x1100 kernel/printk/printk.c:2392
> vprintk_emit+0x6ad/0xdd0 kernel/printk/printk.c:1907
> vprintk_default+0x28/0x30 kernel/printk/printk.c:1947
> vprintk_func+0x7a/0xe7 kernel/printk/printk_safe.c:379
> printk+0x9e/0xba kernel/printk/printk.c:1980
> fail_dump lib/fault-inject.c:44 [inline]
> should_fail+0x97a/0xbcd lib/fault-inject.c:149
> __should_failslab+0x124/0x180 mm/failslab.c:32
> should_failslab+0x9/0x14 mm/slab_common.c:1522
> slab_pre_alloc_hook mm/slab.h:423 [inline]
> slab_alloc mm/slab.c:3378 [inline]
> __do_kmalloc mm/slab.c:3716 [inline]
> __kmalloc+0x63/0x760 mm/slab.c:3727
> kmalloc include/linux/slab.h:517 [inline]
> tty_buffer_alloc drivers/tty/tty_buffer.c:170 [inline]
> __tty_buffer_request_room+0x2d2/0x7f0 drivers/tty/tty_buffer.c:268
> tty_insert_flip_string_fixed_flag+0x8d/0x1f0
> drivers/tty/tty_buffer.c:313
> tty_insert_flip_string include/linux/tty_flip.h:37 [inline]
> pty_write+0x12c/0x1f0 drivers/tty/pty.c:121
> tty_put_char+0x129/0x150 drivers/tty/tty_io.c:2865
> __process_echoes+0x4d9/0x8d0 drivers/tty/n_tty.c:703
> process_echoes+0xfc/0x170 drivers/tty/n_tty.c:781
> n_tty_set_termios+0xb56/0xe80 drivers/tty/n_tty.c:1837
> tty_set_termios+0x7a0/0xac0 drivers/tty/tty_ioctl.c:341
> set_termios+0x41e/0x7d0 drivers/tty/tty_ioctl.c:414
> tty_mode_ioctl+0x871/0xb50 drivers/tty/tty_ioctl.c:781
> n_tty_ioctl_helper+0x54/0x3b0 drivers/tty/tty_ioctl.c:940
> n_tty_ioctl+0x54/0x320 drivers/tty/n_tty.c:2441
> tty_ioctl+0x5e1/0x1870 drivers/tty/tty_io.c:2655
> vfs_ioctl fs/ioctl.c:46 [inline]
> file_ioctl fs/ioctl.c:500 [inline]
> do_vfs_ioctl+0x1cf/0x16f0 fs/ioctl.c:684
> __do_compat_sys_ioctl fs/compat_ioctl.c:1483 [inline]
> __se_compat_sys_ioctl fs/compat_ioctl.c:1407 [inline]
> __ia32_compat_sys_ioctl+0x43e/0x640 fs/compat_ioctl.c:1407
> do_syscall_32_irqs_on arch/x86/entry/common.c:323 [inline]
> do_fast_syscall_32+0x345/0xf9b arch/x86/entry/common.c:394
> entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
This one is tty IOCTL ==> tty_port->lock ==> console_owner/console_sem ==> uart_port->lock
> Possible unsafe locking scenario:
>
> CPU0 CPU1
> ---- ----
> lock(&(&port->lock)->rlock);
> lock(&port_lock_key);
> lock(&(&port->lock)->rlock);
> lock(console_owner);
IOW
tty ioctl
tty_port->lock IRQ
printk uart_port->lock
console_owner
uart_port->lock tty_port->rlock
The simplest thing to do [not necessarily the right one, tho]
would be to break the IOCTL ==> tty_port->lock ==> printk ==> uart_port->lock
chain.
E.g. by adding __GFP_NOWARN
---
drivers/tty/tty_buffer.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index c996b6859c5e..71958ef6a831 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -167,7 +167,8 @@ static struct tty_buffer *tty_buffer_alloc(struct tty_port *port, size_t size)
have queued and recycle that ? */
if (atomic_read(&port->buf.mem_used) > port->buf.mem_limit)
return NULL;
- p = kmalloc(sizeof(struct tty_buffer) + 2 * size, GFP_ATOMIC);
+ p = kmalloc(sizeof(struct tty_buffer) + 2 * size,
+ GFP_ATOMIC | __GFP_NOWARN);
if (p == NULL)
return NULL;
---
Another way could be - switch to printk_safe mode around that
kmalloc():
__printk_safe_enter();
kmalloc(sizeof(struct tty_buffer) + 2 * size, GFP_ATOMIC);
__printk_safe_exit();
This will redirect all printk()-s from kmalloc() to a special per-CPU
buffer, which will be flushed later from a safe context (irq work).
Or, may be, we even can switch to printk_safe mode every time we grab
tty_port lock.
#define tty_port_lock_irqsave(l,f) \
do { \
spin_lock_irqsave((l), f); \
__printk_safe_enter(); \
} while (0)
#define tty_port_unlock_irqrestore(l,f) \
do { \
__printk_safe_exit(); \
spin_lock_irqrestore((l),f); \
} while (0)
This will require some "automatic" replacement of all port->lock
operation in drivers/tty/*.
Perhaps something like this should be done for uart_port->lock
as well. Because, technically, we can have the following
IRQ
uart_port->lock
tty_wakeup
printk
call_console_drivers
console_driver
uart_port->lock << deadlock
Which is totally possible.
E.g. tty_port_default_wakeup()->tty_port_tty_get()->refcount_inc()->WARN_ONCE()
Any opinions?
-ss
^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: possible deadlock in console_unlock
2018-06-07 5:10 ` Sergey Senozhatsky
@ 2018-06-07 11:00 ` Petr Mladek
2018-06-07 11:40 ` Tetsuo Handa
2018-06-07 14:01 ` Sergey Senozhatsky
0 siblings, 2 replies; 22+ messages in thread
From: Petr Mladek @ 2018-06-07 11:00 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: syzbot, linux-kernel, rostedt, sergey.senozhatsky,
syzkaller-bugs, Greg Kroah-Hartman, Jiri Slaby, linux-serial,
Andrew Morton
On Thu 2018-06-07 14:10:19, Sergey Senozhatsky wrote:
> Cc-ing more people
> Link: lkml.kernel.org/r/00000000000087008b056df8fbb3@google.com
>
> On (06/06/18 06:17), syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: af6c5d5e01ad Merge branch 'for-4.18' of git://git.kernel.o..
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=173d93ef800000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=12ff770540994680
> > dashboard link: https://syzkaller.appspot.com/bug?extid=43e93968b964e369db0b
> > compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> > userspace arch: i386
> > syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=16e00bb7800000
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+43e93968b964e369db0b@syzkaller.appspotmail.com
>
> IOW
>
> tty ioctl
> tty_port->lock IRQ
> printk uart_port->lock
> console_owner
> uart_port->lock tty_port->rlock
Great analyze!
> The simplest thing to do [not necessarily the right one, tho]
> would be to break the IOCTL ==> tty_port->lock ==> printk ==> uart_port->lock
> chain.
>
> E.g. by adding __GFP_NOWARN
>
> ---
>
> drivers/tty/tty_buffer.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
> index c996b6859c5e..71958ef6a831 100644
> --- a/drivers/tty/tty_buffer.c
> +++ b/drivers/tty/tty_buffer.c
> @@ -167,7 +167,8 @@ static struct tty_buffer *tty_buffer_alloc(struct tty_port *port, size_t size)
> have queued and recycle that ? */
> if (atomic_read(&port->buf.mem_used) > port->buf.mem_limit)
> return NULL;
> - p = kmalloc(sizeof(struct tty_buffer) + 2 * size, GFP_ATOMIC);
> + p = kmalloc(sizeof(struct tty_buffer) + 2 * size,
> + GFP_ATOMIC | __GFP_NOWARN);
> if (p == NULL)
> return NULL;
>
> ---
This looks like the most simple solution for this particular problem.
I am just afraid that there are many other locations like this.
> Another way could be - switch to printk_safe mode around that
> kmalloc():
>
> __printk_safe_enter();
> kmalloc(sizeof(struct tty_buffer) + 2 * size, GFP_ATOMIC);
> __printk_safe_exit();
>
> Or, may be, we even can switch to printk_safe mode every time we grab
> tty_port lock.
> Perhaps something like this should be done for uart_port->lock
> as well. Because, technically, we can have the following
Yeah, we would need this basically around any lock that can be taken
from console write() callbacks. Well, this would be needed even
around locks that might be in a chain with a lock used in these
callbacks (as shown by this report).
BTW: printk_safe context might be too strict. In fact,
printk_deferred() would be enough. We might think about
introducing also printk_deferred context.
Best Regards,
Petr
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: possible deadlock in console_unlock
2018-06-07 11:00 ` Petr Mladek
@ 2018-06-07 11:40 ` Tetsuo Handa
2018-06-07 14:03 ` Sergey Senozhatsky
2018-06-07 14:01 ` Sergey Senozhatsky
1 sibling, 1 reply; 22+ messages in thread
From: Tetsuo Handa @ 2018-06-07 11:40 UTC (permalink / raw)
To: Petr Mladek, Sergey Senozhatsky
Cc: syzbot, linux-kernel, rostedt, sergey.senozhatsky,
syzkaller-bugs, Greg Kroah-Hartman, Jiri Slaby, linux-serial,
Andrew Morton
On 2018/06/07 20:00, Petr Mladek wrote:
>> ---
>>
>> drivers/tty/tty_buffer.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
>> index c996b6859c5e..71958ef6a831 100644
>> --- a/drivers/tty/tty_buffer.c
>> +++ b/drivers/tty/tty_buffer.c
>> @@ -167,7 +167,8 @@ static struct tty_buffer *tty_buffer_alloc(struct tty_port *port, size_t size)
>> have queued and recycle that ? */
>> if (atomic_read(&port->buf.mem_used) > port->buf.mem_limit)
>> return NULL;
>> - p = kmalloc(sizeof(struct tty_buffer) + 2 * size, GFP_ATOMIC);
>> + p = kmalloc(sizeof(struct tty_buffer) + 2 * size,
>> + GFP_ATOMIC | __GFP_NOWARN);
>> if (p == NULL)
>> return NULL;
>>
>> ---
>
> This looks like the most simple solution for this particular problem.
> I am just afraid that there are many other locations like this.
>
I haven't tried the reproducer with that change. But isn't __GFP_NOWARN
ignored by fail_dump() (and thus printk() from fault injection still occurs)?
By the way, this reproducer is tricky. It needs to run like ./a.out
followed by "while :; do fg; done" because it always stops by a signal.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: possible deadlock in console_unlock
2018-06-07 11:00 ` Petr Mladek
2018-06-07 11:40 ` Tetsuo Handa
@ 2018-06-07 14:01 ` Sergey Senozhatsky
2018-06-08 8:18 ` Petr Mladek
1 sibling, 1 reply; 22+ messages in thread
From: Sergey Senozhatsky @ 2018-06-07 14:01 UTC (permalink / raw)
To: Petr Mladek
Cc: Sergey Senozhatsky, syzbot, linux-kernel, rostedt,
sergey.senozhatsky, syzkaller-bugs, Greg Kroah-Hartman,
Jiri Slaby, linux-serial, Andrew Morton
On (06/07/18 13:00), Petr Mladek wrote:
> > IOW
> >
> > tty ioctl
> > tty_port->lock IRQ
> > printk uart_port->lock
> > console_owner
> > uart_port->lock tty_port->rlock
>
> Great analyze!
Thanks!
> I am just afraid that there are many other locations like this.
Yep, agree. That's why I suggested the printk_safe context for
most critically important locks.
> > Another way could be - switch to printk_safe mode around that
> > kmalloc():
> >
> > __printk_safe_enter();
> > kmalloc(sizeof(struct tty_buffer) + 2 * size, GFP_ATOMIC);
> > __printk_safe_exit();
> >
> > Or, may be, we even can switch to printk_safe mode every time we grab
> > tty_port lock.
>
> > Perhaps something like this should be done for uart_port->lock
> > as well. Because, technically, we can have the following
>
> Yeah, we would need this basically around any lock that can be taken
> from console write() callbacks. Well, this would be needed even
> around locks that might be in a chain with a lock used in these
> callbacks (as shown by this report).
Yep. So the plan for now is to wrap the tty_port->lock. Pretty much
an automatic conversion.
Then to convert [may be some for now on] uart_port->lock. Once again,
pretty much can be done a script.
Afterwards just sit down and be humbl^W^W wait for new reports. Then
move those newly discovered unsafe locks under printk_safe context.
Basically, the same macros as we use for logbuf lock in printk.c
A bit of a lazy approach. Can't think of anything better.
I think it's finally the time to start dealing with these
"external" locks, it's been a while.
> BTW: printk_safe context might be too strict. In fact,
> printk_deferred() would be enough. We might think about
> introducing also printk_deferred context.
Could be.
The good thing about printk_safe is that printk_safe sections can nest.
I suspect there might be locks/printk_safe sections nesting at some
point. In any case, switching to a new flavor of printk_safe will be
pretty easy - just replace printk_safe_enter() with printk_foo_enter()
and the same for printk_save_exit().
I'll wait for some time, to see what people will say.
I guess we also need to check if Linus is OK with the proposed solution.
-ss
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: possible deadlock in console_unlock
2018-06-07 11:40 ` Tetsuo Handa
@ 2018-06-07 14:03 ` Sergey Senozhatsky
0 siblings, 0 replies; 22+ messages in thread
From: Sergey Senozhatsky @ 2018-06-07 14:03 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Petr Mladek, Sergey Senozhatsky, syzbot, linux-kernel, rostedt,
sergey.senozhatsky, syzkaller-bugs, Greg Kroah-Hartman,
Jiri Slaby, linux-serial, Andrew Morton
On (06/07/18 20:40), Tetsuo Handa wrote:
> >> diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
> >> index c996b6859c5e..71958ef6a831 100644
> >> --- a/drivers/tty/tty_buffer.c
> >> +++ b/drivers/tty/tty_buffer.c
> >> @@ -167,7 +167,8 @@ static struct tty_buffer *tty_buffer_alloc(struct tty_port *port, size_t size)
> >> have queued and recycle that ? */
> >> if (atomic_read(&port->buf.mem_used) > port->buf.mem_limit)
> >> return NULL;
> >> - p = kmalloc(sizeof(struct tty_buffer) + 2 * size, GFP_ATOMIC);
> >> + p = kmalloc(sizeof(struct tty_buffer) + 2 * size,
> >> + GFP_ATOMIC | __GFP_NOWARN);
> >> if (p == NULL)
> >> return NULL;
> >>
> >> ---
> >
> > This looks like the most simple solution for this particular problem.
> > I am just afraid that there are many other locations like this.
> >
> I haven't tried the reproducer with that change. But isn't __GFP_NOWARN
> ignored by fail_dump() (and thus printk() from fault injection still occurs)?
Thanks for the info. Need to check it [I didn't know that GFP_NOWARN
meant GFP_WARN_ME_SOMETIMES]. If this is the case then we have just one
option left - printk_safe contexts for TTY/UART locks.
-ss
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: possible deadlock in console_unlock
2018-06-07 14:01 ` Sergey Senozhatsky
@ 2018-06-08 8:18 ` Petr Mladek
2018-06-15 8:38 ` Sergey Senozhatsky
0 siblings, 1 reply; 22+ messages in thread
From: Petr Mladek @ 2018-06-08 8:18 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Sergey Senozhatsky, syzbot, linux-kernel, rostedt,
syzkaller-bugs, Greg Kroah-Hartman, Jiri Slaby, linux-serial,
Andrew Morton
On Thu 2018-06-07 23:01:00, Sergey Senozhatsky wrote:
> On (06/07/18 13:00), Petr Mladek wrote:
> > > Another way could be - switch to printk_safe mode around that
> > > kmalloc():
> > >
> > > __printk_safe_enter();
> > > kmalloc(sizeof(struct tty_buffer) + 2 * size, GFP_ATOMIC);
> > > __printk_safe_exit();
> > >
> > > Or, may be, we even can switch to printk_safe mode every time we grab
> > > tty_port lock.
> >
> > > Perhaps something like this should be done for uart_port->lock
> > > as well. Because, technically, we can have the following
> >
> > Yeah, we would need this basically around any lock that can be taken
> > from console write() callbacks. Well, this would be needed even
> > around locks that might be in a chain with a lock used in these
> > callbacks (as shown by this report).
>
> Yep. So the plan for now is to wrap the tty_port->lock. Pretty much
> an automatic conversion.
>
> Then to convert [may be some for now on] uart_port->lock. Once again,
> pretty much can be done a script.
>
> Afterwards just sit down and be humbl^W^W wait for new reports. Then
> move those newly discovered unsafe locks under printk_safe context.
>
> Basically, the same macros as we use for logbuf lock in printk.c
>
> A bit of a lazy approach. Can't think of anything better.
Same here.
> I think it's finally the time to start dealing with these
> "external" locks, it's been a while.
>
> > BTW: printk_safe context might be too strict. In fact,
> > printk_deferred() would be enough. We might think about
> > introducing also printk_deferred context.
>
> Could be.
> The good thing about printk_safe is that printk_safe sections can nest.
> I suspect there might be locks/printk_safe sections nesting at some
> point. In any case, switching to a new flavor of printk_safe will be
> pretty easy - just replace printk_safe_enter() with printk_foo_enter()
> and the same for printk_save_exit().
We could allow nesting. It is just a matter of how many bits we
reserve for it in printk_context variable.
In each case, I would like to keep the printk_safe context usage
at minimum. It has its own problems caused by limited per-cpu buffers
and the need to flush them. It is basically needed only to prevent
deadlocks related to logbuf_lock.
Best Regards,
Petr
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: possible deadlock in console_unlock
2018-06-08 8:18 ` Petr Mladek
@ 2018-06-15 8:38 ` Sergey Senozhatsky
2018-06-19 8:04 ` Petr Mladek
0 siblings, 1 reply; 22+ messages in thread
From: Sergey Senozhatsky @ 2018-06-15 8:38 UTC (permalink / raw)
To: Petr Mladek
Cc: Sergey Senozhatsky, Sergey Senozhatsky, syzbot, linux-kernel,
rostedt, syzkaller-bugs, Greg Kroah-Hartman, Jiri Slaby,
linux-serial, Andrew Morton
On (06/08/18 10:18), Petr Mladek wrote:
[..]
> > Could be.
> > The good thing about printk_safe is that printk_safe sections can nest.
> > I suspect there might be locks/printk_safe sections nesting at some
> > point. In any case, switching to a new flavor of printk_safe will be
> > pretty easy - just replace printk_safe_enter() with printk_foo_enter()
> > and the same for printk_save_exit().
>
> We could allow nesting. It is just a matter of how many bits we
> reserve for it in printk_context variable.
[..]
> In each case, I would like to keep the printk_safe context usage
> at minimum. It has its own problems caused by limited per-cpu buffers
> and the need to flush them.
May be. Every new printk_safe flavour comes with increasing memory
usage. We already have a bunch of pages pinned [and mostly unused]
to every CPU for printk_nmi and printk_safe. I'm a little unsure if
we have enough reasons to pin yet another bunch of pages to every
CPU. After all printk_safe is not used very commonly, so all in all
I think we should be fine with printk_safe buffers for the time being.
We always can introduce new printk_safe mode later.
> It is basically needed only to prevent deadlocks related to logbuf_lock.
I wouldn't say that we need printk_safe for logbuf_lock only.
printk_safe helps us to avoid deadlocks on:
- logbuf_lock spin_lock
- console_sem ->lock spin_lock
- console_owner spin_lock
- scheduler ->pi_lock spin_lock
- and probably something else.
-ss
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: possible deadlock in console_unlock
2018-06-15 8:38 ` Sergey Senozhatsky
@ 2018-06-19 8:04 ` Petr Mladek
2018-06-19 8:08 ` Sergey Senozhatsky
0 siblings, 1 reply; 22+ messages in thread
From: Petr Mladek @ 2018-06-19 8:04 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Sergey Senozhatsky, syzbot, linux-kernel, rostedt,
syzkaller-bugs, Greg Kroah-Hartman, Jiri Slaby, linux-serial,
Andrew Morton
On Fri 2018-06-15 17:38:04, Sergey Senozhatsky wrote:
> On (06/08/18 10:18), Petr Mladek wrote:
> [..]
> > > Could be.
> > > The good thing about printk_safe is that printk_safe sections can nest.
> > > I suspect there might be locks/printk_safe sections nesting at some
> > > point. In any case, switching to a new flavor of printk_safe will be
> > > pretty easy - just replace printk_safe_enter() with printk_foo_enter()
> > > and the same for printk_save_exit().
> >
> > We could allow nesting. It is just a matter of how many bits we
> > reserve for it in printk_context variable.
> [..]
> > In each case, I would like to keep the printk_safe context usage
> > at minimum. It has its own problems caused by limited per-cpu buffers
> > and the need to flush them.
>
> May be. Every new printk_safe flavour comes with increasing memory
> usage.
This must be a misunderstanding. My intention was to introduce
printk_deferred() context. Where any printk() called in this
context would behave like printk_deferred(). It does not need
any extra buffers.
IMHO, this problem is similar to the problems that we solve
in scheduler and timer code. The cure might be the same.
I just suggest to introduce a context to make our life easier.
> > It is basically needed only to prevent deadlocks related to logbuf_lock.
>
> I wouldn't say that we need printk_safe for logbuf_lock only.
> printk_safe helps us to avoid deadlocks on:
>
> - logbuf_lock spin_lock
logbuf_lock is already guarded by printk_safe context everywhere.
> - console_sem ->lock spin_lock
> - console_owner spin_lock
> - scheduler ->pi_lock spin_lock
> - and probably something else.
printk_deferred should be enough for others. Or do I miss anything?
Best Regards,
Petr
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: possible deadlock in console_unlock
2018-06-19 8:04 ` Petr Mladek
@ 2018-06-19 8:08 ` Sergey Senozhatsky
2019-02-20 10:52 ` Tetsuo Handa
0 siblings, 1 reply; 22+ messages in thread
From: Sergey Senozhatsky @ 2018-06-19 8:08 UTC (permalink / raw)
To: Petr Mladek
Cc: Sergey Senozhatsky, Sergey Senozhatsky, syzbot, linux-kernel,
rostedt, syzkaller-bugs, Greg Kroah-Hartman, Jiri Slaby,
linux-serial, Andrew Morton
On (06/19/18 10:04), Petr Mladek wrote:
> > >
> > > We could allow nesting. It is just a matter of how many bits we
> > > reserve for it in printk_context variable.
> > [..]
> > > In each case, I would like to keep the printk_safe context usage
> > > at minimum. It has its own problems caused by limited per-cpu buffers
> > > and the need to flush them.
> >
> > May be. Every new printk_safe flavour comes with increasing memory
> > usage.
>
> This must be a misunderstanding. My intention was to introduce
> printk_deferred() context. Where any printk() called in this
> context would behave like printk_deferred(). It does not need
> any extra buffers.
Ah, got it. Yes, this can work.
-ss
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: possible deadlock in console_unlock
2018-06-19 8:08 ` Sergey Senozhatsky
@ 2019-02-20 10:52 ` Tetsuo Handa
0 siblings, 0 replies; 22+ messages in thread
From: Tetsuo Handa @ 2019-02-20 10:52 UTC (permalink / raw)
To: Sergey Senozhatsky, Petr Mladek
Cc: Sergey Senozhatsky, syzbot, linux-kernel, rostedt,
syzkaller-bugs, Greg Kroah-Hartman, Jiri Slaby, linux-serial,
Andrew Morton
FTR, this topic seems to be moved to
https://lkml.kernel.org/r/ebc01f4f-5b1d-4f8a-1d0d-463d5218ee45@huawei.com .
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: possible deadlock in console_unlock
2018-06-06 13:17 possible deadlock in console_unlock syzbot
2018-06-07 4:44 ` syzbot
2018-06-07 5:10 ` Sergey Senozhatsky
@ 2019-11-25 2:41 ` syzbot
2 siblings, 0 replies; 22+ messages in thread
From: syzbot @ 2019-11-25 2:41 UTC (permalink / raw)
To: akpm, gregkh, jslaby, linux-kernel, linux-serial, penguin-kernel,
pmladek, rostedt, sergey.senozhatsky.work, sergey.senozhatsky,
syzkaller-bugs, threeearcat
syzbot has bisected this bug to:
commit b6da31b2c07c46f2dcad1d86caa835227a16d9ff
Author: DaeRyong Jeong <threeearcat@gmail.com>
Date: Mon Apr 30 15:27:04 2018 +0000
tty: Fix data race in tty_insert_flip_string_fixed_flag
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=12d9bc0ee00000
start commit: 0ad39cb3 Merge tag 'kconfig-v4.18' of git://git.kernel.org..
git tree: upstream
final crash: https://syzkaller.appspot.com/x/report.txt?x=11d9bc0ee00000
console output: https://syzkaller.appspot.com/x/log.txt?x=16d9bc0ee00000
kernel config: https://syzkaller.appspot.com/x/.config?x=b9a1f3aa8b8ddd16
dashboard link: https://syzkaller.appspot.com/bug?extid=43e93968b964e369db0b
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14c89b9f800000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=167f596f800000
Reported-by: syzbot+43e93968b964e369db0b@syzkaller.appspotmail.com
Fixes: b6da31b2c07c ("tty: Fix data race in
tty_insert_flip_string_fixed_flag")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: possible deadlock in console_unlock
2019-02-19 1:32 ` Sergey Senozhatsky
@ 2019-02-19 2:48 ` Yao HongBo
0 siblings, 0 replies; 22+ messages in thread
From: Yao HongBo @ 2019-02-19 2:48 UTC (permalink / raw)
To: Sergey Senozhatsky; +Cc: Sergey Senozhatsky, linuxarm, linux-kernel
On 2/19/2019 9:32 AM, Sergey Senozhatsky wrote:
> On (02/18/19 22:07), Yao HongBo wrote:
>>>> I have tried GFP_NOWARN, but the problem still exists.
>>>> Only print_safe contexts for tty locks can solve the problem.
>>>> My test scenario is falt-injection.
>>>
>>> Oh, I see. Yes, fault-injection is special.
>>>
>>> I suspect that this patch series can be helpful then
>>> https://lore.kernel.org/lkml/20181016050428.17966-1-sergey.senozhatsky@gmail.com/T/#u
>>
>> hi, sergey.
>
> Hello,
>
>> I merged this patch series on linux-4.19.18, but it didn't work for the fault-injection cases.
>
> Thanks!
>
>> The failure seems to be the same as before.
>
> OK... So tty_port lock must switch to printk_safe, after all...
> I had it in one of the previous versions of the patchset which you
> have tested, but people were strictly against new locking rules
> in TTY, so I dropped that part. Need to think what we can do here.
>
> BTW,
> we are now looking at a completely new printk implementation; which
> would not use printk_safe at all:
> https://lore.kernel.org/lkml/20190212143003.48446-1-john.ogness@linutronix.de/T/#u
Ok, i understand it.
Anyway, thank you for your help.
Best regards,
Hongbo.
> -ss
>
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: possible deadlock in console_unlock
2019-02-18 14:07 ` Yao HongBo
@ 2019-02-19 1:32 ` Sergey Senozhatsky
2019-02-19 2:48 ` Yao HongBo
0 siblings, 1 reply; 22+ messages in thread
From: Sergey Senozhatsky @ 2019-02-19 1:32 UTC (permalink / raw)
To: Yao HongBo; +Cc: Sergey Senozhatsky, Sergey Senozhatsky, linuxarm, linux-kernel
On (02/18/19 22:07), Yao HongBo wrote:
> >> I have tried GFP_NOWARN, but the problem still exists.
> >> Only print_safe contexts for tty locks can solve the problem.
> >> My test scenario is falt-injection.
> >
> > Oh, I see. Yes, fault-injection is special.
> >
> > I suspect that this patch series can be helpful then
> > https://lore.kernel.org/lkml/20181016050428.17966-1-sergey.senozhatsky@gmail.com/T/#u
>
> hi, sergey.
Hello,
> I merged this patch series on linux-4.19.18, but it didn't work for the fault-injection cases.
Thanks!
> The failure seems to be the same as before.
OK... So tty_port lock must switch to printk_safe, after all...
I had it in one of the previous versions of the patchset which you
have tested, but people were strictly against new locking rules
in TTY, so I dropped that part. Need to think what we can do here.
BTW,
we are now looking at a completely new printk implementation; which
would not use printk_safe at all:
https://lore.kernel.org/lkml/20190212143003.48446-1-john.ogness@linutronix.de/T/#u
-ss
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: possible deadlock in console_unlock
2019-02-18 5:46 ` Sergey Senozhatsky
2019-02-18 12:09 ` Yao HongBo
@ 2019-02-18 14:07 ` Yao HongBo
2019-02-19 1:32 ` Sergey Senozhatsky
1 sibling, 1 reply; 22+ messages in thread
From: Yao HongBo @ 2019-02-18 14:07 UTC (permalink / raw)
To: Sergey Senozhatsky; +Cc: Sergey Senozhatsky, linuxarm, linux-kernel
On 2/18/2019 1:46 PM, Sergey Senozhatsky wrote:
> Hi,
>
> On (02/16/19 15:59), Yao HongBo wrote:
>>> GFP_NOWARN is probably the best option for now. Yes, it, maybe,
>>> will not work for fault-injection cases; but printk_safe approach
>>> is harder to push for, especially given that printk_safe maybe will
>>> not even exist in the future.
>>
>> I have tried GFP_NOWARN, but the problem still exists.
>> Only print_safe contexts for tty locks can solve the problem.
>> My test scenario is falt-injection.
>
> Oh, I see. Yes, fault-injection is special.
>
> I suspect that this patch series can be helpful then
> https://lore.kernel.org/lkml/20181016050428.17966-1-sergey.senozhatsky@gmail.com/T/#u
hi, sergey.
I merged this patch series on linux-4.19.18, but it didn't work for the fault-injection cases.
The failure seems to be the same as before.
deadlock log:
-------
[ 193.213385] FAULT_INJECTION: forcing a failure.
[ 193.213385] name failslab, interval 1, probability 0, space 0, times 1
[ 193.216518] CPU: 1 PID: 6317 Comm: syz-executor0 Not tainted 4.19.18-514.55.6.9.x86_64+ #5
[ 193.217383] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
[ 193.217383] Call Trace:
[ 193.217383] dump_stack+0xca/0x13e
[ 193.217383] should_fail+0x607/0x700
[ 193.217383] ? fault_create_debugfs_attr+0x1d0/0x1d0
[ 193.217383] ? __lock_is_held+0xbc/0x160
[ 193.225711] __should_failslab+0x110/0x180
[ 193.225711] should_failslab+0xa/0x20
[ 193.225711] __kmalloc+0x6e/0x350
[ 193.225711] ? tty_write+0x65e/0x8a0
[ 193.225711] tty_write+0x65e/0x8a0
[ 193.225711] ? process_echoes+0x140/0x140
[ 193.225711] ? rw_verify_area+0xe2/0x2b0
[ 193.225711] do_iter_write+0x3dc/0x580
[ 193.233550] vfs_writev+0x16c/0x300
[ 193.233550] ? vfs_iter_write+0xa0/0xa0
[ 193.233550] ? lock_downgrade+0x5e0/0x5e0
[ 193.233550] ? __lock_is_held+0xbc/0x160
[ 193.233550] ? __fget+0x336/0x540
[ 193.238589] ? do_dup2+0x3d0/0x3d0
[ 193.239291] ? __mutex_unlock_slowpath+0xe1/0x690
[ 193.239291] ? do_writev+0xd1/0x230
[ 193.239291] do_writev+0xd1/0x230
[ 193.239291] ? vfs_writev+0x300/0x300
[ 193.239291] ? trace_hardirqs_on_thunk+0x1a/0x1c
[ 193.239291] ? trace_hardirqs_off_caller+0x40/0x190
[ 193.239291] ? do_syscall_64+0x3b/0x580
[ 193.239291] do_syscall_64+0xc8/0x580
[ 193.239291] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 193.239291] RIP: 0033:0x462589
[ 193.239291] Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 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
[ 193.239291] RSP: 002b:00007f2a92dbcc58 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
[ 193.239291] RAX: ffffffffffffffda RBX: 000000000072bf00 RCX: 0000000000462589
[ 193.239291] RDX: 0000000000000001 RSI: 0000000020000040 RDI: 0000000000000003
[ 193.239291] RBP: 00007f2a92dbcc70 R08: 0000000000000000 R09: 0000000000000000
[ 193.239291] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f2a92dbd6bc
[ 193.239291] R13: 00000000004c222e R14: 0000000000702110 R15: 0000000000000004
[ 193.266429] FAULT_INJECTION: forcing a failure.
[ 193.266429] name failslab, interval 1, probability 0, space 0, times 0
[ 193.266767] CPU: 0 PID: 6340 Comm: syz-executor13 Not tainted 4.19.18-514.55.6.9.x86_64+ #5
[ 193.266767] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
[ 193.266767] Call Trace:
[ 193.266767] dump_stack+0xca/0x13e
[ 193.266767] should_fail+0x607/0x700
[ 193.266767] ? n_tty_write+0x96a/0xd90
[ 193.266767] ? fault_create_debugfs_attr+0x1d0/0x1d0
[ 193.266767] ? mark_held_locks+0x120/0x120
[ 193.266767] __should_failslab+0x110/0x180
[ 193.266767] should_failslab+0xa/0x20
[ 193.266767] __kmalloc+0x6e/0x350
[ 193.266767] ? __tty_buffer_request_room+0x1cf/0x5e0
[ 193.266767] __tty_buffer_request_room+0x1cf/0x5e0
[ 193.266767] tty_insert_flip_string_fixed_flag+0x8f/0x220
[ 193.266767] pty_write+0x104/0x1d0
[ 193.266767] n_tty_write+0x9a3/0xd90
[ 193.266767] ? process_echoes+0x140/0x140
[ 193.266767] ? do_wait_intr_irq+0x2a0/0x2a0
[ 193.266767] ? __might_fault+0x17c/0x1c0
[ 193.266767] tty_write+0x451/0x8a0
[ 193.266767] ? process_echoes+0x140/0x140
[ 193.266767] do_iter_write+0x3dc/0x580
[ 193.266767] vfs_writev+0x16c/0x300
[ 193.266767] ? vfs_iter_write+0xa0/0xa0
[ 193.266767] ? lock_downgrade+0x5e0/0x5e0
[ 193.266767] ? __lock_is_held+0xbc/0x160
[ 193.266767] ? __fget+0x336/0x540
[ 193.266767] ? do_dup2+0x3d0/0x3d0
[ 193.266767] ? __mutex_unlock_slowpath+0xe1/0x690
[ 193.266767] ? do_writev+0xd1/0x230
[ 193.266767] do_writev+0xd1/0x230
[ 193.266767] ? vfs_writev+0x300/0x300
[ 193.266767] ? trace_hardirqs_on_thunk+0x1a/0x1c
[ 193.266767] ? trace_hardirqs_off_caller+0x40/0x190
[ 193.266767] ? do_syscall_64+0x3b/0x580
[ 193.266767] do_syscall_64+0xc8/0x580
[ 193.266767] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 193.266767] RIP: 0033:0x462589
[ 193.266767] Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 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
[ 193.266767] RSP: 002b:00007f008dcc9c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
[ 193.266767] RAX: ffffffffffffffda RBX: 000000000072bf00 RCX: 0000000000462589
[ 193.266767] RDX: 0000000000000001 RSI: 0000000020000040 RDI: 0000000000000003
[ 193.266767] RBP: 00007f008dcc9c70 R08: 0000000000000000 R09: 0000000000000000
[ 193.266767] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f008dcca6bc
[ 193.266767] R13: 00000000004c222e R14: 0000000000702110 R15: 0000000000000004
[ 193.266767]
[ 193.266767] ======================================================
[ 193.266767] WARNING: possible circular locking dependency detected
[ 193.266767] 4.19.18-514.55.6.9.x86_64+ #5 Not tainted
[ 193.266767] ------------------------------------------------------
[ 193.266767] syz-executor13/6340 is trying to acquire lock:
[ 193.266767] 0000000026c0d2ca (console_owner){-.-.}, at: console_unlock+0x36d/0xb30
[ 193.266767]
[ 193.266767] but task is already holding lock:
[ 193.266767] 00000000f655eadd (&(&port->lock)->rlock){-.-.}, at: pty_write+0xd2/0x1d0
[ 193.266767]
[ 193.266767] which lock already depends on the new lock.
[ 193.266767]
[ 193.266767]
[ 193.266767] the existing dependency chain (in reverse order) is:
[ 193.266767]
[ 193.266767] -> #2 (&(&port->lock)->rlock){-.-.}:
[ 193.266767] tty_port_tty_get+0x20/0x80
[ 193.266767] tty_port_default_wakeup+0x16/0x40
[ 193.266767] serial8250_tx_chars+0x4dc/0xa80
[ 193.266767] serial8250_handle_irq.part.12+0x16b/0x270
[ 193.266767] serial8250_default_handle_irq+0xf8/0x120
[ 193.266767] serial8250_interrupt+0xfe/0x250
[ 193.266767] __handle_irq_event_percpu+0xf5/0x730
[ 193.266767] handle_irq_event_percpu+0x7b/0x170
[ 193.266767] handle_irq_event+0xa6/0x140
[ 193.266767] handle_edge_irq+0x1eb/0xa90
[ 193.266767] handle_irq+0x3e/0x50
[ 193.266767] do_IRQ+0x92/0x200
[ 193.266767] ret_from_intr+0x0/0x22
[ 193.266767] native_safe_halt+0x2/0x10
[ 193.266767] default_idle+0x24/0x2b0
[ 193.266767] do_idle+0x2ca/0x420
[ 193.266767] cpu_startup_entry+0xcb/0xe0
[ 193.266767] start_secondary+0x421/0x570
[ 193.266767] secondary_startup_64+0xa4/0xb0
[ 193.266767]
[ 193.266767] -> #1 (&port_lock_key){-.-.}:
[ 193.266767] serial8250_console_write+0x663/0x810
[ 193.266767] console_unlock+0x66a/0xb30
[ 193.266767] vprintk_emit+0x181/0x570
[ 193.266767] vprintk_default+0x68/0xe0
[ 193.266767] vprintk_func+0x57/0xf0
[ 193.266767] printk+0xb7/0xe2
[ 193.266767] register_console+0x752/0xc60
[ 193.266767] univ8250_console_init+0x31/0x3a
[ 193.266767] console_init+0x3ad/0x567
[ 193.266767] start_kernel+0x4c3/0x7e1
[ 193.266767] secondary_startup_64+0xa4/0xb0
[ 193.266767]
[ 193.266767] -> #0 (console_owner){-.-.}:
[ 193.266767] console_unlock+0x3d9/0xb30
[ 193.266767] vprintk_emit+0x181/0x570
[ 193.266767] vprintk_default+0x68/0xe0
[ 193.266767] vprintk_func+0x57/0xf0
[ 193.266767] printk+0xb7/0xe2
[ 193.266767] should_fail+0x5d3/0x700
[ 193.266767] __should_failslab+0x110/0x180
[ 193.266767] should_failslab+0xa/0x20
[ 193.266767] __kmalloc+0x6e/0x350
[ 193.266767] __tty_buffer_request_room+0x1cf/0x5e0
[ 193.266767] tty_insert_flip_string_fixed_flag+0x8f/0x220
[ 193.266767] pty_write+0x104/0x1d0
[ 193.266767] n_tty_write+0x9a3/0xd90
[ 193.266767] tty_write+0x451/0x8a0
[ 193.266767] do_iter_write+0x3dc/0x580
[ 193.266767] vfs_writev+0x16c/0x300
[ 193.266767] do_writev+0xd1/0x230
[ 193.266767] do_syscall_64+0xc8/0x580
[ 193.266767] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 193.266767]
[ 193.266767] other info that might help us debug this:
[ 193.266767]
[ 193.266767] Chain exists of:
[ 193.266767] console_owner --> &port_lock_key --> &(&port->lock)->rlock
[ 193.266767]
[ 193.266767] Possible unsafe locking scenario:
[ 193.266767]
[ 193.266767] CPU0 CPU1
[ 193.266767] ---- ----
[ 193.266767] lock(&(&port->lock)->rlock);
[ 193.266767] lock(&port_lock_key);
[ 193.266767] lock(&(&port->lock)->rlock);
[ 193.266767] lock(console_owner);
[ 193.266767]
[ 193.266767] *** DEADLOCK ***
> but first we need to figure out if printk_safe will
> stay in the kernel (this will take some time).
>
> -ss
>
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: possible deadlock in console_unlock
2019-02-18 5:46 ` Sergey Senozhatsky
@ 2019-02-18 12:09 ` Yao HongBo
2019-02-18 14:07 ` Yao HongBo
1 sibling, 0 replies; 22+ messages in thread
From: Yao HongBo @ 2019-02-18 12:09 UTC (permalink / raw)
To: Sergey Senozhatsky; +Cc: Sergey Senozhatsky, linuxarm, linux-kernel
On 2/18/2019 1:46 PM, Sergey Senozhatsky wrote:
> Hi,
>
> On (02/16/19 15:59), Yao HongBo wrote:
>>> GFP_NOWARN is probably the best option for now. Yes, it, maybe,
>>> will not work for fault-injection cases; but printk_safe approach
>>> is harder to push for, especially given that printk_safe maybe will
>>> not even exist in the future.
>>
>> I have tried GFP_NOWARN, but the problem still exists.
>> Only print_safe contexts for tty locks can solve the problem.
>> My test scenario is falt-injection.
>
> Oh, I see. Yes, fault-injection is special.
>
> I suspect that this patch series can be helpful then
> https://lore.kernel.org/lkml/20181016050428.17966-1-sergey.senozhatsky@gmail.com/T/#u
ok, i'll try it.
Thanks.
> but first we need to figure out if printk_safe will
> stay in the kernel (this will take some time).
>
> -ss
>
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: possible deadlock in console_unlock
2019-02-16 7:59 ` Yao HongBo
@ 2019-02-18 5:46 ` Sergey Senozhatsky
2019-02-18 12:09 ` Yao HongBo
2019-02-18 14:07 ` Yao HongBo
0 siblings, 2 replies; 22+ messages in thread
From: Sergey Senozhatsky @ 2019-02-18 5:46 UTC (permalink / raw)
To: Yao HongBo; +Cc: Sergey Senozhatsky, linuxarm, linux-kernel
Hi,
On (02/16/19 15:59), Yao HongBo wrote:
> > GFP_NOWARN is probably the best option for now. Yes, it, maybe,
> > will not work for fault-injection cases; but printk_safe approach
> > is harder to push for, especially given that printk_safe maybe will
> > not even exist in the future.
>
> I have tried GFP_NOWARN, but the problem still exists.
> Only print_safe contexts for tty locks can solve the problem.
> My test scenario is falt-injection.
Oh, I see. Yes, fault-injection is special.
I suspect that this patch series can be helpful then
https://lore.kernel.org/lkml/20181016050428.17966-1-sergey.senozhatsky@gmail.com/T/#u
but first we need to figure out if printk_safe will
stay in the kernel (this will take some time).
-ss
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: possible deadlock in console_unlock
2019-02-16 7:46 ` Sergey Senozhatsky
@ 2019-02-16 7:59 ` Yao HongBo
2019-02-18 5:46 ` Sergey Senozhatsky
0 siblings, 1 reply; 22+ messages in thread
From: Yao HongBo @ 2019-02-16 7:59 UTC (permalink / raw)
To: Sergey Senozhatsky; +Cc: linuxarm, linux-kernel
On 2/16/2019 3:46 PM, Sergey Senozhatsky wrote:
> On (02/16/19 16:21), Sergey Senozhatsky wrote:
>> On (02/16/19 14:36), Yao HongBo wrote:
>>> hi, sergey:
>>>
>>> As shown in that link, https://lkml.org/lkml/2018/6/6/397
>>>
>>> On the linux kernel 5.0-rc6, Syzkaller also hit 'possible deadlock in console_unlock'
>>> bug for several times in my environment.
>>>
>>> This solution fixes things for me. Do you have a plan to submit patches to
>>> solve this problem.
>>>
>>> diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
>>> __printk_safe_enter();
>>> kmalloc(sizeof(struct tty_buffer) + 2 * size, GFP_ATOMIC);
>>> __printk_safe_exit();
>>
>> I would probably try the following:
>
> Yao HongBo, could you please post the lockdep splat?
>
> GFP_NOWARN is probably the best option for now. Yes, it, maybe,
> will not work for fault-injection cases; but printk_safe approach
> is harder to push for, especially given that printk_safe maybe will
> not even exist in the future.
I have tried GFP_NOWARN, but the problem still exists.
Only print_safe contexts for tty locks can solve the problem.
My test scenario is falt-injection.
deadlock report is shown as below:
RBP: 00007f1cf76cbc70 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f1cf76cc6bc
R13: 00000000004c473d R14: 0000000000701f18 R15: 0000000000000005
======================================================
WARNING: possible circular locking dependency detected
4.19.18-514.55.6.9.x86_64+ #1 Not tainted
------------------------------------------------------
syz-executor0/23291 is trying to acquire lock:
00000000d73d87c0 (console_owner){-.-.}, at: log_next kernel/printk/printk.c:495 [inline]
00000000d73d87c0 (console_owner){-.-.}, at: console_unlock+0x36d/0xb30 kernel/printk/printk.c:2397
but task is already holding lock:
00000000dfbab914 (&(&port->lock)->rlock){-.-.}, at: pty_write+0xd2/0x1d0 drivers/tty/pty.c:119
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&(&port->lock)->rlock){-.-.}:
tty_port_tty_get+0x20/0x80 drivers/tty/tty_port.c:288
tty_port_default_wakeup+0x16/0x40 drivers/tty/tty_port.c:47
serial8250_tx_chars+0x4dc/0xa80 drivers/tty/serial/8250/8250_port.c:1806
serial8250_handle_irq.part.12+0x198/0x220 drivers/tty/serial/8250/8250_port.c:1879
serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1899 [inline]
serial8250_default_handle_irq+0xf8/0x120 drivers/tty/serial/8250/8250_port.c:1895
serial8250_interrupt+0xfe/0x250 drivers/tty/serial/8250/8250_core.c:125
__handle_irq_event_percpu+0xf5/0x730 kernel/irq/handle.c:149
handle_irq_event_percpu+0x7b/0x170 kernel/irq/handle.c:189
handle_irq_event+0xa6/0x140 kernel/irq/handle.c:206
handle_edge_irq+0x1eb/0xa90 kernel/irq/chip.c:791
generic_handle_irq_desc include/linux/irqdesc.h:154 [inline]
handle_irq+0x3e/0x50 arch/x86/kernel/irq_64.c:78
do_IRQ+0x92/0x200 arch/x86/kernel/irq.c:246
ret_from_intr+0x0/0x22
native_safe_halt+0x2/0x10 arch/x86/include/asm/irqflags.h:57
arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline]
default_idle+0x24/0x2b0 arch/x86/kernel/process.c:561
cpuidle_idle_call kernel/sched/idle.c:153 [inline]
do_idle+0x2ca/0x420 kernel/sched/idle.c:262
cpu_startup_entry+0xcb/0xe0 kernel/sched/idle.c:368
start_secondary+0x421/0x570 arch/x86/kernel/smpboot.c:271
secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243
-> #1 (&port_lock_key){-.-.}:
serial8250_console_write+0x68a/0x820 drivers/tty/serial/8250/8250_port.c:3247
call_console_drivers kernel/printk/printk.c:1729 [inline]
console_unlock+0x66a/0xb30 kernel/printk/printk.c:2410
vprintk_emit+0x181/0x570 kernel/printk/printk.c:1927
vprintk_default+0x68/0xe0 kernel/printk/printk.c:1968
vprintk_func+0x57/0xf0 kernel/printk/printk_safe.c:398
printk+0xb7/0xe2 kernel/printk/printk.c:2001
register_console+0x752/0xc60 kernel/printk/printk.c:2725
univ8250_console_init+0x31/0x3a drivers/tty/serial/8250/8250_core.c:685
console_init+0x3ad/0x567 kernel/printk/printk.c:2811
start_kernel+0x4c3/0x7e1 init/main.c:661
secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243
-> #0 (console_owner){-.-.}:
console_lock_spinning_enable kernel/printk/printk.c:1592 [inline]
console_unlock+0x3d9/0xb30 kernel/printk/printk.c:2407
vprintk_emit+0x181/0x570 kernel/printk/printk.c:1927
vprintk_default+0x68/0xe0 kernel/printk/printk.c:1968
vprintk_func+0x57/0xf0 kernel/printk/printk_safe.c:398
printk+0xb7/0xe2 kernel/printk/printk.c:2001
fail_dump lib/fault-inject.c:44 [inline]
should_fail+0x5d3/0x700 lib/fault-inject.c:149
__should_failslab+0x110/0x180 mm/failslab.c:32
should_failslab+0xa/0x20 mm/slab_common.c:1557
slab_pre_alloc_hook mm/slab.h:423 [inline]
slab_alloc_node mm/slub.c:2632 [inline]
slab_alloc mm/slub.c:2714 [inline]
__kmalloc+0x6e/0x350 mm/slub.c:3747
kmalloc include/linux/slab.h:518 [inline]
tty_buffer_alloc drivers/tty/tty_buffer.c:170 [inline]
__tty_buffer_request_room+0x1cf/0x5e0 drivers/tty/tty_buffer.c:268
tty_insert_flip_string_fixed_flag+0x8f/0x220 drivers/tty/tty_buffer.c:313
tty_insert_flip_string include/linux/tty_flip.h:37 [inline]
pty_write+0x104/0x1d0 drivers/tty/pty.c:121
n_tty_write+0x9a3/0xd90 drivers/tty/n_tty.c:2354
do_tty_write drivers/tty/tty_io.c:958 [inline]
tty_write+0x451/0x8a0 drivers/tty/tty_io.c:1042
__vfs_write+0xef/0x6a0 fs/read_write.c:485
vfs_write+0x184/0x4c0 fs/read_write.c:549
ksys_write+0xc6/0x1a0 fs/read_write.c:598
do_syscall_64+0xc8/0x580 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
other info that might help us debug this:
Chain exists of:
console_owner --> &port_lock_key --> &(&port->lock)->rlock
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&(&port->lock)->rlock);
lock(&port_lock_key);
lock(&(&port->lock)->rlock);
lock(console_owner);
*** DEADLOCK ***
> -ss
>
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: possible deadlock in console_unlock
2019-02-16 7:21 ` Sergey Senozhatsky
@ 2019-02-16 7:46 ` Sergey Senozhatsky
2019-02-16 7:59 ` Yao HongBo
0 siblings, 1 reply; 22+ messages in thread
From: Sergey Senozhatsky @ 2019-02-16 7:46 UTC (permalink / raw)
To: Sergey Senozhatsky; +Cc: Yao HongBo, linuxarm, linux-kernel
On (02/16/19 16:21), Sergey Senozhatsky wrote:
> On (02/16/19 14:36), Yao HongBo wrote:
> > hi, sergey:
> >
> > As shown in that link, https://lkml.org/lkml/2018/6/6/397
> >
> > On the linux kernel 5.0-rc6, Syzkaller also hit 'possible deadlock in console_unlock'
> > bug for several times in my environment.
> >
> > This solution fixes things for me. Do you have a plan to submit patches to
> > solve this problem.
> >
> > diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
> > __printk_safe_enter();
> > kmalloc(sizeof(struct tty_buffer) + 2 * size, GFP_ATOMIC);
> > __printk_safe_exit();
>
> I would probably try the following:
Yao HongBo, could you please post the lockdep splat?
GFP_NOWARN is probably the best option for now. Yes, it, maybe,
will not work for fault-injection cases; but printk_safe approach
is harder to push for, especially given that printk_safe maybe will
not even exist in the future.
-ss
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: possible deadlock in console_unlock
2019-02-16 6:36 Yao HongBo
@ 2019-02-16 7:21 ` Sergey Senozhatsky
2019-02-16 7:46 ` Sergey Senozhatsky
0 siblings, 1 reply; 22+ messages in thread
From: Sergey Senozhatsky @ 2019-02-16 7:21 UTC (permalink / raw)
To: Yao HongBo; +Cc: sergey.senozhatsky, linuxarm, linux-kernel
On (02/16/19 14:36), Yao HongBo wrote:
> hi, sergey:
>
> As shown in that link, https://lkml.org/lkml/2018/6/6/397
>
> On the linux kernel 5.0-rc6, Syzkaller also hit 'possible deadlock in console_unlock'
> bug for several times in my environment.
>
> This solution fixes things for me. Do you have a plan to submit patches to
> solve this problem.
>
> diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
> __printk_safe_enter();
> kmalloc(sizeof(struct tty_buffer) + 2 * size, GFP_ATOMIC);
> __printk_safe_exit();
I would probably try the following:
---
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index ec145a59f199..058d004dcbaa 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -172,7 +172,8 @@ static struct tty_buffer *tty_buffer_alloc(struct tty_port *port, size_t size)
have queued and recycle that ? */
if (atomic_read(&port->buf.mem_used) > port->buf.mem_limit)
return NULL;
- p = kmalloc(sizeof(struct tty_buffer) + 2 * size, GFP_ATOMIC);
+ p = kmalloc(sizeof(struct tty_buffer) + 2 * size,
+ GFP_ATOMIC | __GFP_NOWARN);
if (p == NULL)
return NULL;
^ permalink raw reply related [flat|nested] 22+ messages in thread
* possible deadlock in console_unlock
@ 2019-02-16 6:36 Yao HongBo
2019-02-16 7:21 ` Sergey Senozhatsky
0 siblings, 1 reply; 22+ messages in thread
From: Yao HongBo @ 2019-02-16 6:36 UTC (permalink / raw)
To: sergey.senozhatsky, linuxarm, linux-kernel
hi, sergey:
As shown in that link, https://lkml.org/lkml/2018/6/6/397
On the linux kernel 5.0-rc6, Syzkaller also hit 'possible deadlock in console_unlock'
bug for several times in my environment.
This solution fixes things for me. Do you have a plan to submit patches to
solve this problem.
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
__printk_safe_enter();
kmalloc(sizeof(struct tty_buffer) + 2 * size, GFP_ATOMIC);
__printk_safe_exit();
Best regards,
Hongbo
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2019-11-25 2:41 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-06 13:17 possible deadlock in console_unlock syzbot
2018-06-07 4:44 ` syzbot
2018-06-07 5:10 ` Sergey Senozhatsky
2018-06-07 11:00 ` Petr Mladek
2018-06-07 11:40 ` Tetsuo Handa
2018-06-07 14:03 ` Sergey Senozhatsky
2018-06-07 14:01 ` Sergey Senozhatsky
2018-06-08 8:18 ` Petr Mladek
2018-06-15 8:38 ` Sergey Senozhatsky
2018-06-19 8:04 ` Petr Mladek
2018-06-19 8:08 ` Sergey Senozhatsky
2019-02-20 10:52 ` Tetsuo Handa
2019-11-25 2:41 ` syzbot
2019-02-16 6:36 Yao HongBo
2019-02-16 7:21 ` Sergey Senozhatsky
2019-02-16 7:46 ` Sergey Senozhatsky
2019-02-16 7:59 ` Yao HongBo
2019-02-18 5:46 ` Sergey Senozhatsky
2019-02-18 12:09 ` Yao HongBo
2019-02-18 14:07 ` Yao HongBo
2019-02-19 1:32 ` Sergey Senozhatsky
2019-02-19 2:48 ` Yao HongBo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).