* Re: stty blocks forever when the line is already opened (and the tx buffer can't be flushed) [not found] <CACQ1gAjNSTyXLVXp7zrdda2eFfA=aQ4tp_PAMRK+Syh-Va8zaw@mail.gmail.com> @ 2016-01-26 16:19 ` Richard Genoud 2016-01-26 17:13 ` Peter Hurley 0 siblings, 1 reply; 5+ messages in thread From: Richard Genoud @ 2016-01-26 16:19 UTC (permalink / raw) To: Jiri Slaby; +Cc: Greg Kroah-Hartman, Peter Hurley, linux-kernel@vger.kernel.org [ sorry for the noise, I forgot to Cc the lkml ] Hi, I've found a case were calling stty -F /dev/ttyS1 clocal blocks forever. And I don't know if it's a very old bug or if it's meant to be like that. Here is how to reproduce the lock : NB: there's NO modem on ttyS1 stty -F /dev/ttyS1 clocal cread crtscts cat < /dev/ttyS1 #on another terminal : echo "dummy" > /dev/ttyS1 # This call doesn't block stty -F /dev/ttyS1 -crtscts # this blocks forever on ioctl(TCSETSW ) looking at tty_port_close_start(), it's pretty clear that nothing is flushed until the last user, so it explains why the "echo dummy" returns directly, despite the crtscts flags. And in tty_mode_ioctl(), there are the lines: case TCSETSW: return set_termios(real_tty, p, TERMIOS_WAIT | TERMIOS_OLD); That explain why the stty blocks. But this behavior seems really strange. ... Or it's meant to be like that ? Regards, Richard NB: This is actually a real life use case with mgetty, a modem losing its power and another process trying to speak to the modem. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: stty blocks forever when the line is already opened (and the tx buffer can't be flushed) 2016-01-26 16:19 ` stty blocks forever when the line is already opened (and the tx buffer can't be flushed) Richard Genoud @ 2016-01-26 17:13 ` Peter Hurley 2016-01-27 9:14 ` Richard Genoud 0 siblings, 1 reply; 5+ messages in thread From: Peter Hurley @ 2016-01-26 17:13 UTC (permalink / raw) To: Richard Genoud, Jiri Slaby Cc: Greg Kroah-Hartman, linux-kernel@vger.kernel.org Hi Richard, On 01/26/2016 08:19 AM, Richard Genoud wrote: > [ sorry for the noise, I forgot to Cc the lkml ] > > Hi, > I've found a case were calling > stty -F /dev/ttyS1 clocal > blocks forever. > And I don't know if it's a very old bug or if it's meant to be like that. > > Here is how to reproduce the lock : > NB: there's NO modem on ttyS1 > stty -F /dev/ttyS1 clocal cread crtscts > cat < /dev/ttyS1 > > #on another terminal : > echo "dummy" > /dev/ttyS1 # This call doesn't block > > stty -F /dev/ttyS1 -crtscts # this blocks forever on ioctl(TCSETSW ) > > > looking at tty_port_close_start(), it's pretty clear that nothing is > flushed until the last user, so it explains why the "echo dummy" > returns directly, despite the crtscts flags. > And in tty_mode_ioctl(), there are the lines: > case TCSETSW: > return set_termios(real_tty, p, TERMIOS_WAIT | TERMIOS_OLD); > That explain why the stty blocks. > > But this behavior seems really strange. > ... Or it's meant to be like that ? Yeah, meant to be like that. When mgetty writes the login prompt but h/w flow control is enabled and nothing's connected, the output is buffered. Since stty uses tcsetattr(TCSADRAIN), the attempt to turn off h/w flow control blocks, waiting for output to empty. In this situation, stopping mgetty will allow the other process to unblock and advance. Hmmm, I could add a -f,--force flag to stty so it uses tcsetattr(TCSANOW)... Regards, Peter Hurley > Regards, > Richard > > NB: This is actually a real life use case with mgetty, a modem losing > its power and another process trying to speak to the modem. > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: stty blocks forever when the line is already opened (and the tx buffer can't be flushed) 2016-01-26 17:13 ` Peter Hurley @ 2016-01-27 9:14 ` Richard Genoud 2016-01-27 10:26 ` Richard Genoud 0 siblings, 1 reply; 5+ messages in thread From: Richard Genoud @ 2016-01-27 9:14 UTC (permalink / raw) To: Peter Hurley; +Cc: Jiri Slaby, Greg Kroah-Hartman, linux-kernel@vger.kernel.org 2016-01-26 18:13 GMT+01:00 Peter Hurley <peter@hurleysoftware.com>: > Hi Richard, > > On 01/26/2016 08:19 AM, Richard Genoud wrote: >> [ sorry for the noise, I forgot to Cc the lkml ] >> >> Hi, >> I've found a case were calling >> stty -F /dev/ttyS1 clocal >> blocks forever. >> And I don't know if it's a very old bug or if it's meant to be like that. >> >> Here is how to reproduce the lock : >> NB: there's NO modem on ttyS1 >> stty -F /dev/ttyS1 clocal cread crtscts >> cat < /dev/ttyS1 >> >> #on another terminal : >> echo "dummy" > /dev/ttyS1 # This call doesn't block >> >> stty -F /dev/ttyS1 -crtscts # this blocks forever on ioctl(TCSETSW ) >> >> >> looking at tty_port_close_start(), it's pretty clear that nothing is >> flushed until the last user, so it explains why the "echo dummy" >> returns directly, despite the crtscts flags. >> And in tty_mode_ioctl(), there are the lines: >> case TCSETSW: >> return set_termios(real_tty, p, TERMIOS_WAIT | TERMIOS_OLD); >> That explain why the stty blocks. >> >> But this behavior seems really strange. >> ... Or it's meant to be like that ? > > Yeah, meant to be like that. > > When mgetty writes the login prompt but h/w flow control is enabled > and nothing's connected, the output is buffered. > > Since stty uses tcsetattr(TCSADRAIN), the attempt to turn off h/w flow > control blocks, waiting for output to empty. Damn ! I forgot about the TCSADRAIN/FLUSH/NOW flags > In this situation, stopping mgetty will allow the other process > to unblock and advance. > > Hmmm, I could add a -f,--force flag to stty so it uses tcsetattr(TCSANOW)... Yes, I think such a flag will make sense. Thank for your enlightenment ! Richard. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: stty blocks forever when the line is already opened (and the tx buffer can't be flushed) 2016-01-27 9:14 ` Richard Genoud @ 2016-01-27 10:26 ` Richard Genoud 2016-01-27 23:33 ` Peter Hurley 0 siblings, 1 reply; 5+ messages in thread From: Richard Genoud @ 2016-01-27 10:26 UTC (permalink / raw) To: Peter Hurley; +Cc: Jiri Slaby, Greg Kroah-Hartman, linux-kernel@vger.kernel.org 2016-01-27 10:14 GMT+01:00 Richard Genoud <richard.genoud@gmail.com>: > 2016-01-26 18:13 GMT+01:00 Peter Hurley <peter@hurleysoftware.com>: >> Hi Richard, >> >> On 01/26/2016 08:19 AM, Richard Genoud wrote: >>> [ sorry for the noise, I forgot to Cc the lkml ] >>> >>> Hi, >>> I've found a case were calling >>> stty -F /dev/ttyS1 clocal >>> blocks forever. >>> And I don't know if it's a very old bug or if it's meant to be like that. >>> >>> Here is how to reproduce the lock : >>> NB: there's NO modem on ttyS1 >>> stty -F /dev/ttyS1 clocal cread crtscts >>> cat < /dev/ttyS1 >>> >>> #on another terminal : >>> echo "dummy" > /dev/ttyS1 # This call doesn't block >>> >>> stty -F /dev/ttyS1 -crtscts # this blocks forever on ioctl(TCSETSW ) >>> >>> >>> looking at tty_port_close_start(), it's pretty clear that nothing is >>> flushed until the last user, so it explains why the "echo dummy" >>> returns directly, despite the crtscts flags. >>> And in tty_mode_ioctl(), there are the lines: >>> case TCSETSW: >>> return set_termios(real_tty, p, TERMIOS_WAIT | TERMIOS_OLD); >>> That explain why the stty blocks. >>> >>> But this behavior seems really strange. >>> ... Or it's meant to be like that ? >> >> Yeah, meant to be like that. >> >> When mgetty writes the login prompt but h/w flow control is enabled >> and nothing's connected, the output is buffered. >> >> Since stty uses tcsetattr(TCSADRAIN), the attempt to turn off h/w flow >> control blocks, waiting for output to empty. > Damn ! I forgot about the TCSADRAIN/FLUSH/NOW flags > >> In this situation, stopping mgetty will allow the other process >> to unblock and advance. >> >> Hmmm, I could add a -f,--force flag to stty so it uses tcsetattr(TCSANOW)... > Yes, I think such a flag will make sense. In fact, a similar flag exist in the very last version of coreutils (8.25) http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=cb7d8b90a213c0186a8c8ba66da959e1f5930e78 :) ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: stty blocks forever when the line is already opened (and the tx buffer can't be flushed) 2016-01-27 10:26 ` Richard Genoud @ 2016-01-27 23:33 ` Peter Hurley 0 siblings, 0 replies; 5+ messages in thread From: Peter Hurley @ 2016-01-27 23:33 UTC (permalink / raw) To: Richard Genoud Cc: Jiri Slaby, Greg Kroah-Hartman, linux-kernel@vger.kernel.org On 01/27/2016 02:26 AM, Richard Genoud wrote: > 2016-01-27 10:14 GMT+01:00 Richard Genoud <richard.genoud@gmail.com>: >> 2016-01-26 18:13 GMT+01:00 Peter Hurley <peter@hurleysoftware.com>: >>> Hi Richard, >>> >>> On 01/26/2016 08:19 AM, Richard Genoud wrote: >>>> [ sorry for the noise, I forgot to Cc the lkml ] >>>> >>>> Hi, >>>> I've found a case were calling >>>> stty -F /dev/ttyS1 clocal >>>> blocks forever. >>>> And I don't know if it's a very old bug or if it's meant to be like that. >>>> >>>> Here is how to reproduce the lock : >>>> NB: there's NO modem on ttyS1 >>>> stty -F /dev/ttyS1 clocal cread crtscts >>>> cat < /dev/ttyS1 >>>> >>>> #on another terminal : >>>> echo "dummy" > /dev/ttyS1 # This call doesn't block >>>> >>>> stty -F /dev/ttyS1 -crtscts # this blocks forever on ioctl(TCSETSW ) >>>> >>>> >>>> looking at tty_port_close_start(), it's pretty clear that nothing is >>>> flushed until the last user, so it explains why the "echo dummy" >>>> returns directly, despite the crtscts flags. >>>> And in tty_mode_ioctl(), there are the lines: >>>> case TCSETSW: >>>> return set_termios(real_tty, p, TERMIOS_WAIT | TERMIOS_OLD); >>>> That explain why the stty blocks. >>>> >>>> But this behavior seems really strange. >>>> ... Or it's meant to be like that ? >>> >>> Yeah, meant to be like that. >>> >>> When mgetty writes the login prompt but h/w flow control is enabled >>> and nothing's connected, the output is buffered. >>> >>> Since stty uses tcsetattr(TCSADRAIN), the attempt to turn off h/w flow >>> control blocks, waiting for output to empty. >> Damn ! I forgot about the TCSADRAIN/FLUSH/NOW flags >> >>> In this situation, stopping mgetty will allow the other process >>> to unblock and advance. >>> >>> Hmmm, I could add a -f,--force flag to stty so it uses tcsetattr(TCSANOW)... >> Yes, I think such a flag will make sense. > In fact, a similar flag exist in the very last version of coreutils (8.25) > http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=cb7d8b90a213c0186a8c8ba66da959e1f5930e78 > :) > Thanks for saving me the time doing it myself. Regards, Peter Hurley ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-01-27 23:33 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CACQ1gAjNSTyXLVXp7zrdda2eFfA=aQ4tp_PAMRK+Syh-Va8zaw@mail.gmail.com>
2016-01-26 16:19 ` stty blocks forever when the line is already opened (and the tx buffer can't be flushed) Richard Genoud
2016-01-26 17:13 ` Peter Hurley
2016-01-27 9:14 ` Richard Genoud
2016-01-27 10:26 ` Richard Genoud
2016-01-27 23:33 ` Peter Hurley
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).