linux-kernel - Re: tcsetattr(fd, TCSAFLUSH) on an O

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>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20071129001236.4ac069bd@the-village.bc.nu>
Date:	Thu, 29 Nov 2007 00:12:36 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Jeff Dike <jdike@...toit.com>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: tcsetattr(fd, TCSAFLUSH) on an O_ASYNC pts device always fails

On Tue, 27 Nov 2007 13:53:21 -0500
Jeff Dike <jdike@...toit.com> wrote:

> tcsetattr(fd, TCSAFLUSH) will always return -EINTR on a pts device
> when O_ASYNC has been set.  This is demonstrated by the test program
> below - just compile and follow the instructions.  You'll get an
> infinite stream of SIGIOs and -EINTRs.

Cute. This appears to be entirely standards compliant but I agree its not
sane or expected behaviour.

> static void pty_unthrottle(struct tty_struct * tty)
> {
> 	...
> 	tty_wakeup(o_tty);
> 	set_bit(TTY_THROTTLED, &tty->flags);
> }

My first thought would be to only do the tty_wakeup if there is data
pending.

> I'd love to get rid of the set_bit(TTY_THROTTLED, &tty->flags) in
> pty_unthrottle, but it's protected by this comment:
> 
> /* For PTY's, the TTY_THROTTLED
>  * flag is always set, to force the line discipline to always call the
>  * unthrottle routine when there are fewer than TTY_THRESHOLD_UNTHROTTLE 
>  * characters in the queue.  This is necessary since each time this
>  * happens, we need to wake up any sleeping processes that could be
>  * (1) trying to send data to the pty, or (2) waiting in wait_until_sent()
>  * for the pty buffer to be drained.
>  */
> 
> Failing that, there should be a relevant state change in the device
> before it will deliver a SIGIO.  I just have no idea where to put it.

Unfortunately neither am I. If the wakeup can be deferred if there is no
data pending then I think that will do the trick ?
-
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/