On 22.11.2012 9:25, andrew mcgregor wrote:
On 11/22/2012 at 05:29 PM, in message <50adaa26.7080...@ilyx.ru>, Ilya Zykov
<i...@ilyx.ru> wrote:
On 22.11.2012 4:47, andrew mcgregor wrote:
On 11/22/2012 at 10:39 AM, in message <50ad4a01.7060...@ilyx.ru>, Ilya Zykov
<i...@ilyx.ru> wrote:
On 22.11.2012 1:30, Alan Cox wrote:
Function reset_buffer_flags() also invoked during the
ioctl(...,TCFLSH,..). At the time of request we can have full buffers
and throttled driver too. If we don't unthrottle driver, we can get
forever throttled driver, because after request, we will have
empty buffers and throttled driver and there is no place to unthrottle
driver.
It simple reproduce with "pty" pair then one side sleep on tty->write_wait,
and other side do ioctl(...,TCFLSH,..). Then there is no place to do
writers wake up.
So instead of revertng it why not just fix it ? Just add an argument to
the reset_buffer_flags function to indicate if unthrottling is permitted.
Alan
Because in my opinion, unthrottling permitted always, except release
last filp (tty->count == 0)
Maybe so, but the patch was there in the first place to resolve an actual
observed bug, where a driver would lock up. So the behaviour needs
preserved.
Andrew
Maybe it was wrong driver, unfortunately, I didn't find full information
about this bug. As an example, if driver indirectly call
reset_buffer_flags() in driver's close() function it will be before
decrement last (tty->count).
Well, the driver in question was just 8250.c, so you should be able to see that
the original condition can exist.
Here's the commit message again:
tty: fix "IRQ45: nobody cared"
Unthrottling the TTY during close ends up enabling interrupts
on a device not on the active list, which will never have the
interrupts cleared. Doctor, it hurts when I do this.
On 6/2/2011 at 01:56 AM, in message <20110601145608.3e586...@bob.linux.org.uk>, Alan
Cox <a...@linux.intel.com> wrote:
On Wed, 01 Jun 2011 10:34:07 +1200
"andrew mcgregor" <andrew.mcgre...@alliedtelesis.co.nz> wrote:
The LKML message
http://kerneltrap.org/mailarchive/linux-kernel/2010/2/25/4541847from
February doesn't seem to have been resolved since. We struck the
issue, and the patch below (against 2.6.32) fixes it. Should I
supply a patch against 3.0.0rc?
I think that would be sensible. I don't actually see how you hit it as
the IRQ ought to be masked by then but it's certainly wrong for n_tty
to be calling into check_unthrottle at that point.
So yes please send a patch with a suitable Signed-off-by: line to
linux-serial and cc GregKH <g...@kroah.com> as well.
Alan
Signed-off-by: Andrew McGregor <andrew.mcgre...@alliedtelesis.co.nz>
Signed-off-by: Greg Kroah-Hartman <gre...@suse.de>
What part of this no longer applies? I'm happy enough if you can prove that
this can't happen any more, but otherwise the fix should remain.
Andrew
This patch must help for 8250.c
diff --git a/drivers/tty/serial/serial_core.c
b/drivers/tty/serial/serial_core.c
index a21dc8e..2e197c3 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1288,8 +1288,6 @@ static void uart_close(struct tty_struct *tty,
struct file *filp)
uart_shutdown(tty, state);
uart_flush_buffer(tty);
- tty_ldisc_flush(tty);
-
tty_port_tty_set(port, NULL);
spin_lock_irqsave(&port->lock, flags);
tty->closing = 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
