[PATCH] tty: Add driver unthrottle in ioctl(...,TCFLSH,..).

[PATCH] tty: Add driver unthrottle in ioctl(...,TCFLSH,..).

[Ilya Zykov]

Revert 'tty: fix "IRQ45: nobody cared"'

This revert commit 7b292b4bf9a9d6098440d85616d6ca4c608b8304

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.

About 'tty: fix "IRQ45: nobody cared"':
We don't call tty_unthrottle() if release last filp - ('tty->count == 0')
In other case it must be safely. Maybe we have bug in other place.

Signed-off-by: Ilya Zykov <ilya@ilyx.ru>
---

diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 26f0d0e..a783d0e 100644

--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -184,6 +184,7 @@ static void reset_buffer_flags(struct tty_struct *tty)
        tty->canon_head = tty->canon_data = tty->erasing = 0;
        memset(&tty->read_flags, 0, sizeof tty->read_flags);
        n_tty_set_room(tty);
+       check_unthrottle(tty);
 }
 
 /**
@@ -1585,7 +1586,6 @@ static int n_tty_open(struct tty_struct *tty)
                        return -ENOMEM;
        }
        reset_buffer_flags(tty);
-       tty_unthrottle(tty);
        tty->column = 0;
        n_tty_set_termios(tty, NULL);
        tty->minimum_to_wake = 1;

Re: [PATCH] tty: Add driver unthrottle in ioctl(...,TCFLSH,..).

[Alan Cox]

> 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

Re: [PATCH] tty: Add driver unthrottle in ioctl(...,TCFLSH,..).

[Ilya Zykov]

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)

Re: [PATCH] tty: Add driver unthrottle in ioctl(...,TCFLSH,..).

[Ilya Zykov]

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
>

Maybe we don't need call reset_buffer_flags() then execute tty_release() 
and (tty->count != 0)? Why in this case we reset buffers?

Re: [PATCH] tty: Add driver unthrottle in ioctl(...,TCFLSH,..).

[andrew mcgregor]

>>> On 11/22/2012 at 10:39 AM, in message <50AD4A01.7060500@ilyx.ru>, Ilya Zykov
<ilya@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

Re: [PATCH] tty: Add driver unthrottle in ioctl(...,TCFLSH,..).

[Ilya Zykov]

On 22.11.2012 4:47, andrew mcgregor wrote:
>
>
>>>> On 11/22/2012 at 10:39 AM, in message <50AD4A01.7060500@ilyx.ru>, Ilya Zykov
> <ilya@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).

Re: [PATCH] tty: Add driver unthrottle in ioctl(...,TCFLSH,..).

[andrew mcgregor]

>>> On 11/22/2012 at 05:29 PM, in message <50ADAA26.7080103@ilyx.ru>, Ilya Zykov
<ilya@ilyx.ru> wrote: 
> On 22.11.2012 4:47, andrew mcgregor wrote:
> >
> >
> >>>> On 11/22/2012 at 10:39 AM, in message <50AD4A01.7060500@ilyx.ru>, Ilya Zykov
> > <ilya@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.3e586e16@bob.linux.org.uk>, Alan Cox <alan@linux.intel.com> wrote:
> On Wed, 01 Jun 2011 10:34:07 +1200
> "andrew mcgregor" <andrew.mcgregor@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 <greg@kroah.com> as well.
>
> Alan

Signed-off-by: Andrew McGregor <andrew.mcgregor@alliedtelesis.co.nz>
Signed-off-by: Greg Kroah-Hartman <gregkh@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

Re: [PATCH] tty: Add driver unthrottle in ioctl(...,TCFLSH,..).

[Ilya Zykov]

On 22.11.2012 8:29, Ilya Zykov wrote:
> On 22.11.2012 4:47, andrew mcgregor wrote:
>>
>>
>>>>> On 11/22/2012 at 10:39 AM, in message <50AD4A01.7060500@ilyx.ru>,
>>>>> Ilya Zykov
>> <ilya@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).
>
>

Particularly, many drivers and 'serial_core.c' use tty_ldisc_flush() in
own close() function. tty_ldisc_flush() call reset_buffer_flags() 
indirectly.
I think is wrong way use tty_ldisc_flush() in driver's close() function, 
because tty layer 'tty_release()' call  tty_ldisc_release() after 
decremented (tty->count), and clear all buffers.
We don't care about this in driver. And call ldisc's function.

Re: [PATCH] tty: Add driver unthrottle in ioctl(...,TCFLSH,..).

[Ilya Zykov]

On 22.11.2012 10:03, Ilya Zykov wrote:
> On 22.11.2012 8:29, Ilya Zykov wrote:
>> On 22.11.2012 4:47, andrew mcgregor wrote:
>>>
>>>
>>>>>> On 11/22/2012 at 10:39 AM, in message <50AD4A01.7060500@ilyx.ru>,
>>>>>> Ilya Zykov
>>> <ilya@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).
>>
>>
>
> Particularly, many drivers and 'serial_core.c' use tty_ldisc_flush() in
> own close() function. tty_ldisc_flush() call reset_buffer_flags()
> indirectly.
> I think is wrong way use tty_ldisc_flush() in driver's close() function,
> because tty layer 'tty_release()' call  tty_ldisc_release() after
> decremented (tty->count), and clear all buffers.
> We don't care about this in driver. And call ldisc's function.
>
>
Sorry, last phrase not correct.
We don't NEED care about this in driver. And call ldisc's function.

Re: [PATCH] tty: Add driver unthrottle in ioctl(...,TCFLSH,..).

[Ilya Zykov]

On 22.11.2012 9:25, andrew mcgregor wrote:
>
>
>>>> On 11/22/2012 at 05:29 PM, in message <50ADAA26.7080103@ilyx.ru>, Ilya Zykov
> <ilya@ilyx.ru> wrote:
>> On 22.11.2012 4:47, andrew mcgregor wrote:
>>>
>>>
>>>>>> On 11/22/2012 at 10:39 AM, in message <50AD4A01.7060500@ilyx.ru>, Ilya Zykov
>>> <ilya@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.3e586e16@bob.linux.org.uk>, Alan Cox <alan@linux.intel.com> wrote:
>> On Wed, 01 Jun 2011 10:34:07 +1200
>> "andrew mcgregor" <andrew.mcgregor@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 <greg@kroah.com> as well.
>>
>> Alan
>
> Signed-off-by: Andrew McGregor <andrew.mcgregor@alliedtelesis.co.nz>
> Signed-off-by: Greg Kroah-Hartman <gregkh@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;

[PATCH] tty: Add driver unthrottle in ioctl(...,TCFLSH,..).

[Ilya Zykov]

Regression 'tty: fix "IRQ45: nobody cared"'
Regression commit 7b292b4bf9a9d6098440d85616d6ca4c608b8304

  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.

Signed-off-by: Ilya Zykov <ilya@ilyx.ru>
---
 drivers/tty/tty_ioctl.c |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/tty_ioctl.c b/drivers/tty/tty_ioctl.c
index 8481b29..cc0fc52 100644
--- a/drivers/tty/tty_ioctl.c
+++ b/drivers/tty/tty_ioctl.c
@@ -1096,12 +1096,16 @@ int tty_perform_flush(struct tty_struct *tty, unsigned long arg)
 	ld = tty_ldisc_ref_wait(tty);
 	switch (arg) {
 	case TCIFLUSH:
-		if (ld && ld->ops->flush_buffer)
+		if (ld && ld->ops->flush_buffer) {
 			ld->ops->flush_buffer(tty);
+			tty_unthrottle(tty);
+		}
 		break;
 	case TCIOFLUSH:
-		if (ld && ld->ops->flush_buffer)
+		if (ld && ld->ops->flush_buffer) {
 			ld->ops->flush_buffer(tty);
+			tty_unthrottle(tty);
+		}
 		/* fall through */
 	case TCOFLUSH:
 		tty_driver_flush_buffer(tty);