From: Peter Hurley <peter@hurleysoftware.com>
To: Julio Guerra <julio@farjump.io>
Cc: linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [BUG] drivers/tty: read() on a noncanonical blocking tty randomly fails when VMIN > received >= buf
Date: Wed, 4 May 2016 17:50:56 -0700 [thread overview]
Message-ID: <572A98F0.3040306@hurleysoftware.com> (raw)
In-Reply-To: <3319f492-9b1b-d006-e903-7de761a87a53@farjump.io>
On 05/04/2016 04:27 PM, Julio Guerra wrote:
>>> When a tty (here a slave pty) is set in noncanonical input and blocking read modes, a read() randomly blocks when:
>>> "VMIN > kernel received >= user buffer size > 0".
>>>
>>> The standard says that read() should block until VMIN bytes are received [1][2]. Whether this is an implementation defined case not really specified by POSIX or not, it should not behave randomly (otherwise it really should be documented in termios manpage).
>>
>> This is not a bug.
>>
>> From the termios(3) man page:
>>
>> * MIN > 0; TIME == 0: read(2) blocks until the lesser of MIN bytes or the number of bytes requested are avail‐
>> able, and returns the lesser of these two values.
>>
>
> This does not appear in my man...
>
> Anyway, how do you explain the random behavior then?
A long standing bug in this read mode allows the asynchronous input
processing thread to race with the read() thread and become confused
about how much data remains.
I fixed this in 4.6; when I run your test on 4.6, it consistently
returns the full user buffer.
Regards,
Peter Hurley
next prev parent reply other threads:[~2016-05-05 0:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-04 23:00 [BUG] drivers/tty: read() on a noncanonical blocking tty randomly fails when VMIN > received >= buf Julio Guerra
2016-05-04 23:07 ` Peter Hurley
2016-05-04 23:27 ` Julio Guerra
2016-05-05 0:50 ` Peter Hurley [this message]
2016-05-05 10:08 ` One Thousand Gnomes
2016-05-05 15:28 ` 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=572A98F0.3040306@hurleysoftware.com \
--to=peter@hurleysoftware.com \
--cc=julio@farjump.io \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.