Re: [PATCH] tty: Fix pty master read() after slave closes

From: Mikael Pettersson
Date: Sat Sep 28 2013 - 13:37:28 EST


Peter Hurley writes:
> On 09/27/2013 01:27 PM, Peter Hurley wrote:
> > Commit f95499c3030fe1bfad57745f2db1959c5b43dca8,
> > n_tty: Don't wait for buffer work in read() loop
> > creates a race window which can cause a pty master read()
> > to miss the last pty slave write(s) and return -EIO instead,
> > thus signalling the pty slave is closed. This can happen when
> > the pty slave is written and immediately closed but before the
> > tty buffer i/o loop receives the new input; the pty master
> > read() is scheduled, sees its read buffer is empty and the
> > pty slave has been closed, and exits.
> >
> > Because tty_flush_to_ldisc() has significant performance impact
> > for parallel i/o, rather than revert the commit, special case this
> > condition (ie., when the read buffer is empty and the 'other' pty
> > has been closed) and, only then, wait for buffer work to complete
> > before re-testing if the read buffer is still empty.
> >
> > As before, subsequent pty master reads return any available data
> > until no more data is available, and then returns -EIO to
> > indicate the pty slave has closed.
> >
> > Reported-by: Mikael Pettersson <mikpelinux@xxxxxxxxx>
> > Signed-off-by: Peter Hurley <peter@xxxxxxxxxxxxxxxxxx>
>
> I tested this patch with the gcc ada ACATS testsuite and got this
> summary so all seems ok with this patch.
>
> === acats Summary ===
> # of expected passes 805
> # of unexpected failures 0
>
> ...
>
> === acats Summary ===
> # of expected passes 772
> # of unexpected failures 0
>
> ...
>
> === acats Summary ===
> # of expected passes 743
> # of unexpected failures 0
>
> Mikael,
>
> I'd appreciate if you could re-test with this patch and
> confirm the issue is fixed.

I did a big pile of gcc bootstrap + regression test runs today with
this patch, and everything looks good. Thus:

Tested-by: Mikael Pettersson <mikpelinux@xxxxxxxxx>

Thanks,

/Mikael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/