Messages in this thread |  | | Date | Tue, 17 Feb 2015 17:35:10 -0500 | From | Peter Hurley <> | Subject | Re: [PATCH] n_tty_read: check for hanging tty while waiting for input |
| |
Hi Aristeu,
On 02/17/2015 04:50 PM, Aristeu Rozanski wrote: > Hi Peter, > On Tue, Feb 17, 2015 at 04:28:30PM -0500, Peter Hurley wrote: >> On 02/17/2015 04:06 PM, Aristeu Rozanski wrote: >>> If the console has a canonical reader and the respective tty hangs up, >>> it'll waste a wake up and will never release the last ldisc reference so >>> the hangup process can finish: >> >> This behavior is by-design; /dev/console cannot be hung-up. > > hangup is issued on the tty that happens to be the console. In this > case, ttyS0.
I realize that. But hanging up the tty that is /dev/console only affects open descriptors that are not /dev/console.
So readers using the /dev/ttyS0 file descriptor will see a hungup fops, but readers using /dev/console will not, and /dev/ttyS0 will _not_ be closed or released because of the still-open descriptor on /dev/console.
>> What process is sleeping on /dev/console read() and what is its controlling >> tty? I ask because console teardown usually happens when SIGHUP is >> received by the process group. > > ttyS0 is the controller tty.
Ok, so the process sleeping on /dev/console read() should have received SIGHUP, which would wake the process and cause it to exit the n_tty_read() loop, thus dropping the ldisc reference it holds. Did it ignore the signal or perhaps the signal is masked?
Of course, there is no requirement for the process sleeping on /dev/console to respond to SIGHUP, in which case, the hangup simply fails to make forward progress because of the open /dev/console descriptor.
Regards, Peter Hurley
|  |