From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966689AbcAZQTp (ORCPT ); Tue, 26 Jan 2016 11:19:45 -0500 Received: from mail-lb0-f176.google.com ([209.85.217.176]:36015 "EHLO mail-lb0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965442AbcAZQTl (ORCPT ); Tue, 26 Jan 2016 11:19:41 -0500 MIME-Version: 1.0 In-Reply-To: References: From: Richard Genoud Date: Tue, 26 Jan 2016 17:19:20 +0100 Message-ID: Subject: Re: stty blocks forever when the line is already opened (and the tx buffer can't be flushed) To: Jiri Slaby Cc: Greg Kroah-Hartman , Peter Hurley , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: 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.