Re: [Bug #14015] pty regressed again, breaking expect and gcc's testsuite

Linus Torvalds
2009-09-04T01:52:16Z

On Fri, 4 Sep 2009, OGAWA Hirofumi wrote:
>
> Yes. However, pty_write() checks tty_buffer instead of receive_room. So
> I thought, the change of write side is mainly buffer size (receive_room
> size + tty_buffer size).

The problem has never been the write side. That side works - just with
extra buffering.

> It will stop after filling tty_buffer, not receive_room.

Yes.

> And (I hope) the read side guarantees to consume both buffers. If it is
> right, I guessed the change is timing issues with more larger buffer
> size.

That's the change. The read side only consumes the buffers it _sees_. And
it doesn't look at the buffers that the write side has written, only at
the 'received' buffers. That's why we had to add that 'tty_flush_to_ldisc'
so that the buffers that got written were properly moved to the receive
side.

And that's the part that I suspect is broken - ie tty_flush_to_ldisc
doesn't always guarantee that it moves all the written stuff to the
receive side.

Before, this wasn't an issue, because the writer always filled up the
receive buffers directly, so there was never any flushing issues.

> Another possibility in my guess is the change of pty_flush_buffer() and
> pty_chars_in_buffer(). I'm not sure at all though, especially, I'm
> suspecting pty_flush_buffer() may change the behaviors.

I don't think 'pty_flush_buffer()' is ever called in any normal
circumstances. Afaik, it's only called for a TIOCFLUSH ioctl (or whatever
it's called) when the user asks for all the contents to be thrown away.

> FWIW, meanwhile, I'll just try to see the root-cause of this as
> another/fallback solution.

Absolutely. If you can find some other possibility, that would be great.
I'm not really sure how that 'receive_room == 0' case would ever happen in
practice, so my patch was really based on the assumption that the bug is
in the flushing code.

The bug could easily be elsewhere.

Linus