From: Johannes Stezenbach <js@sig21.net>
To: Peter Hurley <peter@hurleysoftware.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jslaby@suse.cz>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/6] n_tty: Always wake up read()/poll() if new input
Date: Sun, 13 Dec 2015 15:49:22 +0100 [thread overview]
Message-ID: <20151213144922.GA10204@sig21.net> (raw)
In-Reply-To: <1449958599-5533-2-git-send-email-peter@hurleysoftware.com>
Hi Peter,
On Sat, Dec 12, 2015 at 02:16:34PM -0800, Peter Hurley wrote:
> A read() in non-canonical mode when VMIN > 0 and VTIME == 0 does not
> complete until at least VMIN chars have been read (or the user buffer is
> full). In this infrequent read mode, n_tty_read() attempts to reduce
> wakeups by computing the amount of data still necessary to complete the
> read (minimum_to_wake) and only waking the read()/poll() when that much
> unread data has been processed. This is the only read mode for which
> new data does not necessarily generate a wakeup.
>
> However, this optimization is broken and commonly leads to hung reads
> even though the necessary amount of data has been received. Since the
> optimization is of marginal value anyway, just remove the whole
> thing. This also remedies a race between a concurrent poll() and
> read() in this mode, where the poll() can reset the minimum_to_wake
> of the read() (and vice versa).
...
> @@ -1632,7 +1631,7 @@ static void __receive_buf(struct tty_struct *tty, const unsigned char *cp,
> /* publish read_head to consumer */
> smp_store_release(&ldata->commit_head, ldata->read_head);
>
> - if ((read_cnt(ldata) >= ldata->minimum_to_wake) || L_EXTPROC(tty)) {
> + if (read_cnt(ldata)) {
> kill_fasync(&tty->fasync, SIGIO, POLL_IN);
> wake_up_interruptible_poll(&tty->read_wait, POLLIN);
> }
Your patch looks fine, I just want to mention that there was
some undocumented behaviour for async IO to take VMIN
into account for deciding when to send SIGIO, but it was
implemented incorrectly because minimum_to_wake was
only updated in read() and poll(), not directly by the
tcsetattr() ioctl. I think your change does the right
thing to fix this case, too. I had to debug some
proprietary code which dynamically changed VMIN based on
expected message size and thus sometimes wasn't woken up,
in the end we decided to keep VMIN=1 to solve it.
Thanks,
Johannes
next prev parent reply other threads:[~2015-12-13 14:49 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-12 22:16 [PATCH 0/6] More n_tty fixes Peter Hurley
2015-12-12 22:16 ` [PATCH 1/6] n_tty: Always wake up read()/poll() if new input Peter Hurley
2015-12-13 14:49 ` Johannes Stezenbach [this message]
2015-12-13 19:53 ` Peter Hurley
2015-12-12 22:16 ` [PATCH 2/6] tty, n_tty: Remove fasync() ldisc notification Peter Hurley
2015-12-12 22:16 ` [PATCH 3/6] tty: Add fasync() hung up file operation Peter Hurley
2015-12-12 22:16 ` [PATCH 4/6] tty: Fix ioctl(FIOASYNC) on hungup file Peter Hurley
2015-12-12 22:16 ` [PATCH 5/6] n_tty: Fix stuck write wakeup Peter Hurley
2015-12-13 15:18 ` Johannes Stezenbach
2015-12-13 18:38 ` Peter Hurley
2015-12-13 19:27 ` Johannes Stezenbach
2015-12-12 22:16 ` [PATCH 6/6] n_tty: Remove tty count checks from unthrottle Peter Hurley
2016-01-10 5:45 ` [PATCH v2 0/7] More n_tty fixes Peter Hurley
2016-01-10 5:45 ` [PATCH v2 1/7] n_tty: Always wake up read()/poll() if new input Peter Hurley
2016-01-10 5:45 ` [PATCH v2 2/7] tty, n_tty: Remove fasync() ldisc notification Peter Hurley
2016-01-10 5:45 ` [PATCH v2 3/7] tty: Add fasync() hung up file operation Peter Hurley
2016-01-10 5:45 ` [PATCH v2 4/7] tty: Fix ioctl(FIOASYNC) on hungup file Peter Hurley
2016-01-10 5:45 ` [PATCH v2 5/7] n_tty: Fix stuck write wakeup Peter Hurley
2016-01-10 5:45 ` [PATCH v2 6/7] n_tty: Remove tty count checks from unthrottle Peter Hurley
2016-01-10 5:45 ` [PATCH v2 7/7] tty: n_tty: fix SIGIO for output Peter Hurley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151213144922.GA10204@sig21.net \
--to=js@sig21.net \
--cc=gregkh@linuxfoundation.org \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=peter@hurleysoftware.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox