From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751042AbdE3Uxi (ORCPT ); Tue, 30 May 2017 16:53:38 -0400 Received: from pandora.armlinux.org.uk ([78.32.30.218]:54904 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750811AbdE3Uxg (ORCPT ); Tue, 30 May 2017 16:53:36 -0400 Date: Tue, 30 May 2017 21:53:30 +0100 From: Russell King - ARM Linux To: linux-kernel@vger.kernel.org, Greg KH Subject: 4.12-rc3: tty lockdep splat Message-ID: <20170530205330.GW22219@n2100.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Reproducing this bug is rather easy: ssh in to a target machine running 4.12-rc3 with lockdep enabled, wait for the shell prompt, and hit ^C. Works every time for me. ====================================================== WARNING: possible circular locking dependency detected 4.12.0-rc3+ #213 Not tainted ------------------------------------------------------ kworker/u4:0/1089 is trying to acquire lock: (&buf->lock){+.+...}, at: [] tty_buffer_flush+0x44/0xc8 but task is already holding lock: (&o_tty->termios_rwsem/1){++++..}, at: [] isig+0x40/0xb4 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&o_tty->termios_rwsem/1){++++..}: down_read+0x40/0x88 n_tty_write+0x98/0x488 tty_write+0x19c/0x2a4 __vfs_write+0x34/0x11c vfs_write+0xac/0x16c SyS_write+0x44/0x90 ret_fast_syscall+0x0/0x1c -> #1 (&tty->atomic_write_lock){+.+.+.}: __mutex_lock+0x58/0x930 mutex_lock_nested+0x24/0x2c tty_port_default_receive_buf+0x44/0x80 flush_to_ldisc+0xac/0xc4 process_one_work+0x19c/0x40c worker_thread+0x30/0x4c8 kthread+0x124/0x15c ret_from_fork+0x14/0x24 -> #0 (&buf->lock){+.+...}: lock_acquire+0x74/0x94 __mutex_lock+0x58/0x930 mutex_lock_nested+0x24/0x2c tty_buffer_flush+0x44/0xc8 pty_flush_buffer+0x28/0x6c tty_driver_flush_buffer+0x20/0x24 isig+0x7c/0xb4 n_tty_receive_signal_char+0x20/0x68 n_tty_receive_char_special+0x834/0xa24 n_tty_receive_buf_common+0x7a0/0x9d4 n_tty_receive_buf2+0x1c/0x24 tty_ldisc_receive_buf+0x28/0x64 tty_port_default_receive_buf+0x58/0x80 flush_to_ldisc+0xac/0xc4 process_one_work+0x19c/0x40c worker_thread+0x30/0x4c8 kthread+0x124/0x15c ret_from_fork+0x14/0x24 other info that might help us debug this: Chain exists of: &buf->lock --> &tty->atomic_write_lock --> &o_tty->termios_rwsem/1 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&o_tty->termios_rwsem/1); lock(&tty->atomic_write_lock); lock(&o_tty->termios_rwsem/1); lock(&buf->lock); *** DEADLOCK *** 6 locks held by kworker/u4:0/1089: #0: ("events_unbound"){.+.+.+}, at: [] process_one_work+0x128/0x40c #1: ((&buf->work)){+.+...}, at: [] process_one_work+0x128/0x40c #2: (&port->buf.lock/1){+.+...}, at: [] flush_to_ldisc+0x24/0xc4 #3: (&tty->ldisc_sem){++++.+}, at: [] tty_ldisc_ref+0x1c/0x50 #4: (&tty->atomic_write_lock){+.+.+.}, at: [] tty_port_default_receive_buf+0x44/0x80 #5: (&o_tty->termios_rwsem/1){++++..}, at: [] isig+0x40/0xb4 stack backtrace: CPU: 0 PID: 1089 Comm: kworker/u4:0 Not tainted 4.12.0-rc3+ #213 Hardware name: Marvell Armada 380/385 (Device Tree) Workqueue: events_unbound flush_to_ldisc Backtrace: [] (dump_backtrace) from [] (show_stack+0x18/0x1c) r6:60000093 r5:ffffffff r4:00000000 r3:00040c00 [] (show_stack) from [] (dump_stack+0xa4/0xdc) [] (dump_stack) from [] (print_circular_bug+0x28c/0x2e0) r6:c0b56bc4 r5:c0b6dc74 r4:c0b4b944 r3:c099c4c0 [] (print_circular_bug) from [] (__lock_acquire+0x1620/0x1830) r10:00000000 r8:00000006 r7:ed9fe968 r6:c09cb054 r5:ed9fe400 r4:c1207d5c [] (__lock_acquire) from [] (lock_acquire+0x74/0x94) r10:00000002 r9:ede48400 r8:c1207d5c r7:00000001 r6:00000001 r5:60000013 r4:00000000 [] (lock_acquire) from [] (__mutex_lock+0x58/0x930) r7:ede83a24 r6:00000000 r5:00000000 r4:ede83a24 [] (__mutex_lock) from [] (mutex_lock_nested+0x24/0x2c) r10:ede48800 r9:ede48400 r8:00000000 r7:ede83a24 r6:ede83a68 r5:ede48400 r4:ede83a00 [] (mutex_lock_nested) from [] (tty_buffer_flush+0x44/0xc8) [] (tty_buffer_flush) from [] (pty_flush_buffer+0x28/0x6c) r10:00000002 r8:f10da29c r7:ede48530 r6:00000000 r5:ede48400 r4:ede48800 [] (pty_flush_buffer) from [] (tty_driver_flush_buffer+0x20/0x24) r6:00000000 r5:f10d8000 r4:ede48400 r3:c038a2f0 [] (tty_driver_flush_buffer) from [] (isig+0x7c/0xb4) [] (isig) from [] (n_tty_receive_signal_char+0x20/0x68) r10:00000000 r8:00000000 r7:00000000 r6:00000003 r5:00000003 r4:ede48400 [] (n_tty_receive_signal_char) from [] (n_tty_receive_char_special+0x834/0xa24) r5:f10d8000 r4:ede48400 [] (n_tty_receive_char_special) from [] (n_tty_receive_buf_common+0x7a0/0x9d4) r10:00000000 r9:ede48400 r8:00000000 r7:00000000 r6:edf18c1f r5:00000001 r4:edf18c1e [] (n_tty_receive_buf_common) from [] (n_tty_receive_buf2+0x1c/0x24) r10:00000001 r9:00000000 r8:edf18c1e r7:00000000 r6:00000001 r5:c09d5238 r4:00000001 [] (n_tty_receive_buf2) from [] (tty_ldisc_receive_buf+0x28/0x64) [] (tty_ldisc_receive_buf) from [] (tty_port_default_receive_buf+0x58/0x80) r5:ed995fc0 r4:ede48464 [] (tty_port_default_receive_buf) from [] (flush_to_ldisc+0xac/0xc4) r8:ef005000 r7:ede83c24 r6:ede83c00 r5:ede83c04 r4:edf18c00 r3:00000001 [] (flush_to_ldisc) from [] (process_one_work+0x19c/0x40c) r7:ed923f08 r6:ef008000 r5:ede83c04 r4:edf99100 [] (process_one_work) from [] (worker_thread+0x30/0x4c8) r10:c09ab900 r9:ef008000 r8:ef008000 r7:00000088 r6:edf99118 r5:ef008034 r4:edf99100 [] (worker_thread) from [] (kthread+0x124/0x15c) r10:c0049f54 r9:ef383e4c r8:edf99100 r7:edf990b8 r6:ed88d140 r5:00000000 r4:edf99080 [] (kthread) from [] (ret_from_fork+0x14/0x24) r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c0050ae4 r4:ed88d140 r3:ed922000 -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.