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 -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
