linux-kernel - A very old issue: stalling serial ports

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <4F901FA9.90107@msgid.tls.msk.ru>
Date:	Thu, 19 Apr 2012 18:22:33 +0400
From:	Michael Tokarev <mjt@....msk.ru>
To:	Kernel Mailing List <linux-kernel@...r.kernel.org>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: A very old issue: stalling serial ports

This is something that exists since 2.4 kernel I think.

When any regular serial port is written, but no device
is connected to the port, the application which does
write becomes stuck in kernel mode somewhere, and may
be there for a very long time, unkillable.

Just a trivial

 echo foo > /dev/ttyS0

will sleep for a long time, unkillable.

This happens on close of the device.

Here's a typical call trace of this:

[  591.497867] bash            S c1218130     0  1457   1453 0x00000000
[  591.497965]  f6c725e0 00000082 c14d77c0 c1218130 00000246 c121a4ed 00000287 f65080f0
[  591.498229]  f7005b40 c145cb40 c145cb40 ec834119 00000087 c145cb40 f65080f0 c145cb40
[  591.498492]  f6feb008 00000000 c1218735 c1216302 00000000 f6feb000 00000000 f65080f0
[  591.498755] Call Trace:
[  591.498797]  [<c1218130>] ? serial8250_set_mctrl+0x60/0x70
[  591.498844]  [<c121a4ed>] ? serial8250_do_set_termios+0x2ad/0x3c0
[  591.498891]  [<c1218735>] ? serial8250_get_mctrl+0x5/0x40
[  591.498937]  [<c1216302>] ? uart_startup+0xe2/0x190
[  591.498983]  [<c105f850>] ? wake_up_bit+0x60/0x60
[  591.499028]  [<c12edf8a>] ? tty_lock+0x1a/0x33
[  591.499072]  [<c104ffe7>] ? lock_timer_base+0x27/0x50
[  591.499119]  [<c12ec856>] ? schedule_timeout+0x126/0x250
[  591.499164]  [<c10501a0>] ? del_timer+0xa0/0xa0
[  591.499210]  [<c1216fd0>] ? uart_close+0x170/0x2f0
[  591.499255]  [<c105f850>] ? wake_up_bit+0x60/0x60
[  591.499300]  [<c11feba0>] ? tty_release+0xf0/0x4e0
[  591.499345]  [<c12153d4>] ? uart_start+0x24/0x90
[  591.499391]  [<c105fb07>] ? remove_wait_queue+0x17/0x50
[  591.499436]  [<c1034bc2>] ? __wake_up+0x42/0x60
[  591.499482]  [<c10febfd>] ? fput+0xad/0x220
[  591.499526]  [<c10fb41d>] ? filp_close+0x4d/0x80

Now, depending on the kernel and/or on actual sequence of events --
I don't really know yet -- sometimes the app is stuck but is actually
killable, sometimes it "unstucks" by its own after some time (a
minute or two), sometimes it becomes unkillable forever.

To me it does not look like a feature, but I might be wrong.

Is it a rigth behavour?

Thank you!

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/