Messages in this thread | | | Subject | RE: [PATCH] tty: Fix tcdrain hang due to tty chars_in_buffer errors | Date | Fri, 17 Jul 2009 12:36:22 -0400 | From | "Harris, Jeff" <> |
| |
That was my other thought, but there are other kernel drivers which do report errors from chars_in_buffer. A grep of the code shows ipw_chars_in_buffer in drivers/char/pcmcia/ipwireless/tty.c, hvc_chars_in_buffer in hvc_console.c, ntty_chars_in_buffer in nozomi.c, if_chars_in_buffer in isdn/gigaset/interface.c, etc. Do they all need to be updated?
Should the return type be unsigned int to make the behavior more explicit? The signed type may be interpreted along the lines of a read or write call which returns a count or a negative value to indicate a failure.
Jeff
-----Original Message----- From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk] Sent: Friday, July 17, 2009 12:01 PM To: Harris, Jeff Cc: alan@linux.intel.com; vapier@gentoo.org; adobriyan@gmail.com; linux-kernel@vger.kernel.org; Harris, Jeff Subject: Re: [PATCH] tty: Fix tcdrain hang due to tty chars_in_buffer errors
On Fri, 17 Jul 2009 11:07:54 -0400 Jeff Harris <jeff_harris@kentrox.com> wrote:
> If a tty driver's chars_in_buffer callback reports an error, the wait loop in
chars_in_buffer cannot report an error. It reports how many characters are in the buffer.
> A process calling tcdrain will block indefinitely if it calls tcdrain when the > device is disconnected.
Fix your chars_in_buffer. On a disconnect its quite reasonable to return 0, as they are not buffered any more.
Alan
| |