* 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: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 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 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
* 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
* 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
* 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 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: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-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-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 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-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
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).