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 <[email protected]>
---
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;
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?
> 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
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 <[email protected]>,
>>>>> Ilya Zykov
>> <[email protected]> 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.
On 22.11.2012 9:25, andrew mcgregor wrote:
>
>
>>>> On 11/22/2012 at 05:29 PM, in message <[email protected]>, Ilya Zykov
> <[email protected]> wrote:
>> On 22.11.2012 4:47, andrew mcgregor wrote:
>>>
>>>
>>>>>> On 11/22/2012 at 10:39 AM, in message <[email protected]>, Ilya Zykov
>>> <[email protected]> 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 <[email protected]>, Alan Cox <[email protected]> wrote:
>> On Wed, 01 Jun 2011 10:34:07 +1200
>> "andrew mcgregor" <[email protected]> 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 <[email protected]> as well.
>>
>> Alan
>
> Signed-off-by: Andrew McGregor <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> 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;
On 22.11.2012 4:47, andrew mcgregor wrote:
>
>
>>>> On 11/22/2012 at 10:39 AM, in message <[email protected]>, Ilya Zykov
> <[email protected]> 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).
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)
>>> On 11/22/2012 at 10:39 AM, in message <[email protected]>, Ilya Zykov
<[email protected]> 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
>>> On 11/22/2012 at 05:29 PM, in message <[email protected]>, Ilya Zykov
<[email protected]> wrote:
> On 22.11.2012 4:47, andrew mcgregor wrote:
> >
> >
> >>>> On 11/22/2012 at 10:39 AM, in message <[email protected]>, Ilya Zykov
> > <[email protected]> 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 <[email protected]>, Alan Cox <[email protected]> wrote:
> On Wed, 01 Jun 2011 10:34:07 +1200
> "andrew mcgregor" <[email protected]> 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 <[email protected]> as well.
>
> Alan
Signed-off-by: Andrew McGregor <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
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
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 <[email protected]>,
>>>>>> Ilya Zykov
>>> <[email protected]> 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.