Greetings.
I'm working with an x86 system connected to a RTU via a 232 port.
A simple test we run nightly - opens and closes this serial port -
sending some simple commands to a daemon monitoring the serial line.
After up-version from 3.5.x to 3.8.y-stable we found regular lockups of
the serial port.
This was root caused to the waggling of the DCD signal on the serial line.
This results in getty => login => /bin/bash as showing in the "DW" state
(hung) - forever, when interrogated with "ps". In other words after
logging in via the serial port and closing a kermit/minicom session -
where the DCD line happens to be de-asserted to the target box, the
login task gets indefinitely hung.
do_tty_hangup() is being called by uart_handle_dcd_change() which
triggers the bug and locks the task and consequently never releases the
serial port.
Switching on mutex debugging - shows the printout below.
Both the hung task and the mutex debug trace go away once
852e4a8152b427c3f318bb0e1b5e938d64dcdc32 by Sebastian Andrzej Siewior is
applied from upstream.
Suggest application to stable, ASAP.
[ 254.101367] [ INFO: possible circular locking dependency detected ]
[ 254.101367] 3.8.7+ #77 Tainted: G W
[ 254.101367] -------------------------------------------------------
[ 254.101367] kworker/0:0/4 is trying to acquire lock:
[ 254.101367] (&tty->legacy_mutex){+.+.+.}, at: [<c12b4d83>]
tty_lock_nested+0x33/0x70
[ 254.101367]
[ 254.101367] but task is already holding lock:
[ 254.101367] ((&tty->hangup_work)){+.+...}, at: [<c10405f2>]
process_one_work+0x122/0x430
[ 254.101367]
[ 254.101367] which lock already depends on the new lock.
[ 254.101367]
[ 254.101367]
[ 254.101367] the existing dependency chain (in reverse order) is:
[ 254.101367]
[ 254.101367] -> #2 ((&tty->hangup_work)){+.+...}:
[ 254.101367] [<c1063013>] lock_acquire+0x63/0x80
[ 254.101367] [<c1041aa8>] flush_work+0x38/0x220
[ 254.101367] [<c11bba81>] tty_ldisc_flush_works+0x11/0x30
[ 254.101367] [<c11bc5bc>] tty_ldisc_release+0x1c/0x70
[ 254.101367] [<c11b5dcc>] tty_release+0x37c/0x480
[ 254.101367] [<c10bab88>] __fput+0xd8/0x200
[ 254.101367] [<c10bacb8>] ____fput+0x8/0x10
[ 254.101367] [<c1043b41>] task_work_run+0x71/0xb0
[ 254.101367] [<c1002b2f>] do_notify_resume+0x3f/0x70
[ 254.101367] [<c12b5048>] work_notifysig+0x29/0x31
[ 254.101367]
[ 254.101367] -> #1 (&tty->legacy_mutex/1){+.+...}:
[ 254.101367] [<c1063013>] lock_acquire+0x63/0x80
[ 254.101367] [<c12b2c0e>] mutex_lock_nested+0x5e/0x290
[ 254.101367] [<c12b4d83>] tty_lock_nested+0x33/0x70
[ 254.101367] [<c12b4e21>] tty_lock_pair+0x51/0x60
[ 254.101367] [<c11b5b48>] tty_release+0xf8/0x480
[ 254.101367] [<c10bab88>] __fput+0xd8/0x200
[ 254.101367] [<c10bacb8>] ____fput+0x8/0x10
[ 254.101367] [<c1043b41>] task_work_run+0x71/0xb0
[ 254.101367] [<c1002b2f>] do_notify_resume+0x3f/0x70
[ 254.101367] [<c12b5048>] work_notifysig+0x29/0x31
[ 254.101367]
[ 254.101367] -> #0 (&tty->legacy_mutex){+.+.+.}:
[ 254.101367] [<c1062a06>] __lock_acquire+0x1566/0x1730
[ 254.101367] [<c1063013>] lock_acquire+0x63/0x80
[ 254.101367] [<c12b2c0e>] mutex_lock_nested+0x5e/0x290
[ 254.101367] [<c12b4d83>] tty_lock_nested+0x33/0x70
[ 254.101367] [<c12b4dca>] tty_lock+0xa/0x10
[ 254.101367] [<c11b49ef>] __tty_hangup+0x4f/0x370
[ 254.101367] [<c11b4d1d>] do_tty_hangup+0xd/0x10
[ 254.101367] [<c104065c>] process_one_work+0x18c/0x430
[ 254.101367] [<c1042341>] worker_thread+0x111/0x380
[ 254.101367] [<c104676e>] kthread+0x8e/0xa0
[ 254.101367] [<c12b55fb>] ret_from_kernel_thread+0x1b/0x30
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html