[BUG] perf top: --stdio causes continuous refresh

[BUG] perf top: --stdio causes continuous refresh

[Stephane Eranian]

Hi,

If you run perf top on 3.14 but you force --stdio mode, perf top
goes crazy and constantly refreshes the output.

It does that with many older versions of the perf as well on 3.14.
It runs fine with newt mode.

Works fine with my 3.11 kernel. So something must be broken
with 3.14.

Can you reproduce the problem as well?

Re: [BUG] perf top: --stdio causes continuous refresh

[Stephane Eranian]

On Wed, Feb 5, 2014 at 10:25 PM, Stephane Eranian <eranian@google.com> wrote:
> Hi,
>
> If you run perf top on 3.14 but you force --stdio mode, perf top
> goes crazy and constantly refreshes the output.
>
> It does that with many older versions of the perf as well on 3.14.
> It runs fine with newt mode.
>
> Works fine with my 3.11 kernel. So something must be broken
> with 3.14.
>
Or more likely, there is something broken in perf which gets exposed
by 3.14.

Re: [BUG] perf top: --stdio causes continuous refresh

[Arnaldo Carvalho de Melo]

Em Wed, Feb 05, 2014 at 10:25:09PM +0100, Stephane Eranian escreveu:
> If you run perf top on 3.14 but you force --stdio mode, perf top
> goes crazy and constantly refreshes the output.
> 
> It does that with many older versions of the perf as well on 3.14.
> It runs fine with newt mode.
> 
> Works fine with my 3.11 kernel. So something must be broken
> with 3.14.
 
> Can you reproduce the problem as well?

Not so far, using my perf/urgent branch:

[root@ssdandy ~]# perf --version
perf version 3.13.g1da187

Also it honours --delay, i.e.

# perf top --delay 5 --stdio

it will wait 5 seconds between refreshes, etc.

Checking out v3.14-rc1 now.

- Arnaldo

Re: [BUG] perf top: --stdio causes continuous refresh

[Stephane Eranian]

On Thu, Feb 6, 2014 at 2:56 PM, Arnaldo Carvalho de Melo
<acme@redhat.com> wrote:
> Em Wed, Feb 05, 2014 at 10:25:09PM +0100, Stephane Eranian escreveu:
>> If you run perf top on 3.14 but you force --stdio mode, perf top
>> goes crazy and constantly refreshes the output.
>>
>> It does that with many older versions of the perf as well on 3.14.
>> It runs fine with newt mode.
>>
>> Works fine with my 3.11 kernel. So something must be broken
>> with 3.14.
>
>> Can you reproduce the problem as well?
>
> Not so far, using my perf/urgent branch:
>
I am using tip.git. Or try 3.11, 3.10.


> [root@ssdandy ~]# perf --version
> perf version 3.13.g1da187
>
> Also it honours --delay, i.e.
>
> # perf top --delay 5 --stdio
>
> it will wait 5 seconds between refreshes, etc.
>
> Checking out v3.14-rc1 now.
>
> - Arnaldo

Re: [BUG] perf top: --stdio causes continuous refresh

[Arnaldo Carvalho de Melo]

Em Thu, Feb 06, 2014 at 02:58:01PM +0100, Stephane Eranian escreveu:
> On Thu, Feb 6, 2014 at 2:56 PM, Arnaldo Carvalho de Melo
> <acme@redhat.com> wrote:
> > Em Wed, Feb 05, 2014 at 10:25:09PM +0100, Stephane Eranian escreveu:
> >> If you run perf top on 3.14 but you force --stdio mode, perf top
> >> goes crazy and constantly refreshes the output.

> >> It does that with many older versions of the perf as well on 3.14.
> >> It runs fine with newt mode.

> >> Works fine with my 3.11 kernel. So something must be broken
> >> with 3.14.

> >> Can you reproduce the problem as well?

> > Not so far, using my perf/urgent branch:

> I am using tip.git. Or try 3.11, 3.10.

Tried torvalds/master, no problem, looking at what the top's screen
refresh thread does we can see:

[root@ssdandy ~]# trace -t 3562 -e \!write
     0.000 ( 0.000 ms):  ... [continued]: poll()) = 0 Timeout
  2031.522 (2002.480 ms): poll(ufds: 0x7fbb91596bb0, nfds: 1, timeout_msecs: 2000               ) = 0 Timeout
  4064.346 (2002.456 ms): poll(ufds: 0x7fbb91596bb0, nfds: 1, timeout_msecs: 2000               ) = 0 Timeout
^C[root@ssdandy ~]# 

I.e. waiting the default of:

                .delay_secs          = 2,

2 seconds between refreshes.

Checking out tip.tip, or are you suggesting to try an old perf binary, from
3.11 or 3.10 on top of a newer kernel?

- Arnaldo

Re: [BUG] perf top: --stdio causes continuous refresh

[Arnaldo Carvalho de Melo]

Em Thu, Feb 06, 2014 at 12:07:05PM -0200, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Feb 06, 2014 at 02:58:01PM +0100, Stephane Eranian escreveu:
> > On Thu, Feb 6, 2014 at 2:56 PM, Arnaldo Carvalho de Melo
> > <acme@redhat.com> wrote:
> > > Em Wed, Feb 05, 2014 at 10:25:09PM +0100, Stephane Eranian escreveu:
> > >> If you run perf top on 3.14 but you force --stdio mode, perf top
> > >> goes crazy and constantly refreshes the output.
> 
> > >> It does that with many older versions of the perf as well on 3.14.
> > >> It runs fine with newt mode.
> 
> > >> Works fine with my 3.11 kernel. So something must be broken
> > >> with 3.14.
> 
> > >> Can you reproduce the problem as well?
> 
> > > Not so far, using my perf/urgent branch:
> 
> > I am using tip.git. Or try 3.11, 3.10.

But my tests are on top of:

[acme@ssdandy linux]$ uname -r
3.11.4-101.fc18.x86_64

I thought it was a 3.14ish one, building one to try there...

- Arnaldo

Re: [BUG] perf top: --stdio causes continuous refresh

[Stephane Eranian]

On Thu, Feb 6, 2014 at 3:09 PM, Arnaldo Carvalho de Melo
<acme@redhat.com> wrote:
> Em Thu, Feb 06, 2014 at 12:07:05PM -0200, Arnaldo Carvalho de Melo escreveu:
>> Em Thu, Feb 06, 2014 at 02:58:01PM +0100, Stephane Eranian escreveu:
>> > On Thu, Feb 6, 2014 at 2:56 PM, Arnaldo Carvalho de Melo
>> > <acme@redhat.com> wrote:
>> > > Em Wed, Feb 05, 2014 at 10:25:09PM +0100, Stephane Eranian escreveu:
>> > >> If you run perf top on 3.14 but you force --stdio mode, perf top
>> > >> goes crazy and constantly refreshes the output.
>>
>> > >> It does that with many older versions of the perf as well on 3.14.
>> > >> It runs fine with newt mode.
>>
>> > >> Works fine with my 3.11 kernel. So something must be broken
>> > >> with 3.14.
>>
>> > >> Can you reproduce the problem as well?
>>
>> > > Not so far, using my perf/urgent branch:
>>
>> > I am using tip.git. Or try 3.11, 3.10.
>
> But my tests are on top of:
>
> [acme@ssdandy linux]$ uname -r
> 3.11.4-101.fc18.x86_64
>
> I thought it was a 3.14ish one, building one to try there...
>
The kernel must be 3.14-rcX, the tool can be any version.

> - Arnaldo

Re: [BUG] perf top: --stdio causes continuous refresh

[David Ahern]

On 2/6/14, 8:24 AM, Stephane Eranian wrote:
> On Thu, Feb 6, 2014 at 3:09 PM, Arnaldo Carvalho de Melo
> <acme@redhat.com> wrote:
>> Em Thu, Feb 06, 2014 at 12:07:05PM -0200, Arnaldo Carvalho de Melo escreveu:
>>> Em Thu, Feb 06, 2014 at 02:58:01PM +0100, Stephane Eranian escreveu:
>>>> On Thu, Feb 6, 2014 at 2:56 PM, Arnaldo Carvalho de Melo
>>>> <acme@redhat.com> wrote:
>>>>> Em Wed, Feb 05, 2014 at 10:25:09PM +0100, Stephane Eranian escreveu:
>>>>>> If you run perf top on 3.14 but you force --stdio mode, perf top
>>>>>> goes crazy and constantly refreshes the output.
>>>
>>>>>> It does that with many older versions of the perf as well on 3.14.
>>>>>> It runs fine with newt mode.
>>>
>>>>>> Works fine with my 3.11 kernel. So something must be broken
>>>>>> with 3.14.
>>>
>>>>>> Can you reproduce the problem as well?
>>>
>>>>> Not so far, using my perf/urgent branch:
>>>
>>>> I am using tip.git. Or try 3.11, 3.10.
>>
>> But my tests are on top of:
>>
>> [acme@ssdandy linux]$ uname -r
>> 3.11.4-101.fc18.x86_64
>>
>> I thought it was a 3.14ish one, building one to try there...
>>
> The kernel must be 3.14-rcX, the tool can be any version.


I don't have time to do a git bisect, but I can narrow the window to 
3.13-rc6 and 3.14-rc1. Just happened to update a server yesterday. 
perf-top --stdio runs fine on the former and shows the problem on the 
latter.

David

Re: [BUG] perf top: --stdio causes continuous refresh

[Arnaldo Carvalho de Melo]

Em Thu, Feb 06, 2014 at 10:48:19AM -0700, David Ahern escreveu:
> On 2/6/14, 8:24 AM, Stephane Eranian wrote:
> >On Thu, Feb 6, 2014 at 3:09 PM, Arnaldo Carvalho de Melo
> >>>>I am using tip.git. Or try 3.11, 3.10.
> >>
> >>But my tests are on top of:
> >>
> >>[acme@ssdandy linux]$ uname -r
> >>3.11.4-101.fc18.x86_64
> >>
> >>I thought it was a 3.14ish one, building one to try there...
> >>
> >The kernel must be 3.14-rcX, the tool can be any version.
> 
> 
> I don't have time to do a git bisect, but I can narrow the window to
> 3.13-rc6 and 3.14-rc1. Just happened to update a server yesterday.
> perf-top --stdio runs fine on the former and shows the problem on
> the latter.

Humm,

                /*
                 * Either timeout expired or we got an EINTR due to
                 * SIGWINCH, refresh screen in both cases.
                 */
                switch (poll(&stdin_poll, 1, delay_msecs)) {

And poll is returning 1:

   951.068 ( 0.002 ms): poll(ufds: 0x7ff660befbb0, nfds: 1, timeout_msecs: 2000) = 1

Checking...

- Arnaldo

Re: [BUG] perf top: --stdio causes continuous refresh

[Arnaldo Carvalho de Melo]

Em Thu, Feb 06, 2014 at 05:21:31PM -0200, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Feb 06, 2014 at 10:48:19AM -0700, David Ahern escreveu:
> > On 2/6/14, 8:24 AM, Stephane Eranian wrote:
> > >On Thu, Feb 6, 2014 at 3:09 PM, Arnaldo Carvalho de Melo
> > >>>>I am using tip.git. Or try 3.11, 3.10.

> > >>But my tests are on top of:

> > >>[acme@ssdandy linux]$ uname -r
> > >>3.11.4-101.fc18.x86_64

> > >>I thought it was a 3.14ish one, building one to try there...

> > >The kernel must be 3.14-rcX, the tool can be any version.

> > I don't have time to do a git bisect, but I can narrow the window to
> > 3.13-rc6 and 3.14-rc1. Just happened to update a server yesterday.
> > perf-top --stdio runs fine on the former and shows the problem on
> > the latter.
> 
> Humm,
> 
>                 /*
>                  * Either timeout expired or we got an EINTR due to
>                  * SIGWINCH, refresh screen in both cases.
>                  */
>                 switch (poll(&stdin_poll, 1, delay_msecs)) {
 
> And poll is returning 1:
 
>    951.068 ( 0.002 ms): poll(ufds: 0x7ff660befbb0, nfds: 1, timeout_msecs: 2000) = 1

We go to the getc(stdin) and it returns EOF :-\

- Arnaldo

Re: [BUG] perf top: --stdio causes continuous refresh

[Stephane Eranian]

On Thu, Feb 6, 2014 at 8:28 PM, Arnaldo Carvalho de Melo
<acme@redhat.com> wrote:
> Em Thu, Feb 06, 2014 at 05:21:31PM -0200, Arnaldo Carvalho de Melo escreveu:
>> Em Thu, Feb 06, 2014 at 10:48:19AM -0700, David Ahern escreveu:
>> > On 2/6/14, 8:24 AM, Stephane Eranian wrote:
>> > >On Thu, Feb 6, 2014 at 3:09 PM, Arnaldo Carvalho de Melo
>> > >>>>I am using tip.git. Or try 3.11, 3.10.
>
>> > >>But my tests are on top of:
>
>> > >>[acme@ssdandy linux]$ uname -r
>> > >>3.11.4-101.fc18.x86_64
>
>> > >>I thought it was a 3.14ish one, building one to try there...
>
>> > >The kernel must be 3.14-rcX, the tool can be any version.
>
>> > I don't have time to do a git bisect, but I can narrow the window to
>> > 3.13-rc6 and 3.14-rc1. Just happened to update a server yesterday.
>> > perf-top --stdio runs fine on the former and shows the problem on
>> > the latter.
>>
>> Humm,
>>
>>                 /*
>>                  * Either timeout expired or we got an EINTR due to
>>                  * SIGWINCH, refresh screen in both cases.
>>                  */
>>                 switch (poll(&stdin_poll, 1, delay_msecs)) {
>
>> And poll is returning 1:
>
>>    951.068 ( 0.002 ms): poll(ufds: 0x7ff660befbb0, nfds: 1, timeout_msecs: 2000) = 1
>
> We go to the getc(stdin) and it returns EOF :-\
>
Doesn't poll() return 0 if timeout, and 1 if descriptor in this case?
So you're saying you get 1 and getc() returns nothing to read.
Does stdin get closed somehow?

Re: [BUG] perf top: --stdio causes continuous refresh

[Arnaldo Carvalho de Melo]

Em Thu, Feb 06, 2014 at 10:48:19AM -0700, David Ahern escreveu:
> On 2/6/14, 8:24 AM, Stephane Eranian wrote:
> >On Thu, Feb 6, 2014 at 3:09 PM, Arnaldo Carvalho de Melo
> ><acme@redhat.com> wrote:
> >>Em Thu, Feb 06, 2014 at 12:07:05PM -0200, Arnaldo Carvalho de Melo escreveu:
> >>>Em Thu, Feb 06, 2014 at 02:58:01PM +0100, Stephane Eranian escreveu:
> >>>>On Thu, Feb 6, 2014 at 2:56 PM, Arnaldo Carvalho de Melo
> >>>><acme@redhat.com> wrote:
> >>>>>Em Wed, Feb 05, 2014 at 10:25:09PM +0100, Stephane Eranian escreveu:
> >>>>>>If you run perf top on 3.14 but you force --stdio mode, perf top
> >>>>>>goes crazy and constantly refreshes the output.

> >>>>>>It does that with many older versions of the perf as well on 3.14.
> >>>>>>It runs fine with newt mode.

> >>>>>>Works fine with my 3.11 kernel. So something must be broken
> >>>>>>with 3.14.

> >>>>>>Can you reproduce the problem as well?

> >>>>>Not so far, using my perf/urgent branch:

> >>>>I am using tip.git. Or try 3.11, 3.10.

> >>But my tests are on top of:

> >>[acme@ssdandy linux]$ uname -r
> >>3.11.4-101.fc18.x86_64

> >>I thought it was a 3.14ish one, building one to try there...
> >>
> >The kernel must be 3.14-rcX, the tool can be any version.
> 
> I don't have time to do a git bisect, but I can narrow the window to
> 3.13-rc6 and 3.14-rc1. Just happened to update a server yesterday.
> perf-top --stdio runs fine on the former and shows the problem on
> the latter.

Bisected it down to:

eb3e4668bd9e0bbda592e830e889f137e44ec9e4 is the first bad commit
commit eb3e4668bd9e0bbda592e830e889f137e44ec9e4
Author: Peter Hurley <peter@hurleysoftware.com>
Date:   Mon Dec 2 14:24:42 2013 -0500

    n_tty: Un-inline slow-path n_tty_receive_char()
    
    Commit e60d27c4d8b33ba20896b76b6558f061bc6460ff,
    n_tty: Factor LNEXT processing from per-char i/o path,
    mistakenly inlined the non-inline alias, n_tty_receive_char(),
    for the inline function, n_tty_receive_char_inline().
    
    As n_tty_receive_char() is intended for slow-path char
    processing only, un-inline it.
    
    Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

:040000 040000 80215819e331ff95d80aa7c8a6a05f8c74d1fdb6 41a856dfeb6769e47c7689c92d91db497dfcc8cf M	drivers
[acme@fedora20 linux]$

In a hurry now, will continue later, trying to understand what is the problem
introduced by the above cset...

Need to revert just this one to confirm that it is the culprit, etc.

- Arnaldo

Re: [BUG] perf top: --stdio causes continuous refresh

[Peter Hurley]

Hi Arnaldo,

On 02/10/2014 04:03 PM, Arnaldo Carvalho de Melo wrote:
> Em Thu, Feb 06, 2014 at 10:48:19AM -0700, David Ahern escreveu:
>> On 2/6/14, 8:24 AM, Stephane Eranian wrote:
>>> On Thu, Feb 6, 2014 at 3:09 PM, Arnaldo Carvalho de Melo
>>> <acme@redhat.com> wrote:
>>>> Em Thu, Feb 06, 2014 at 12:07:05PM -0200, Arnaldo Carvalho de Melo escreveu:
>>>>> Em Thu, Feb 06, 2014 at 02:58:01PM +0100, Stephane Eranian escreveu:
>>>>>> On Thu, Feb 6, 2014 at 2:56 PM, Arnaldo Carvalho de Melo
>>>>>> <acme@redhat.com> wrote:
>>>>>>> Em Wed, Feb 05, 2014 at 10:25:09PM +0100, Stephane Eranian escreveu:
>>>>>>>> If you run perf top on 3.14 but you force --stdio mode, perf top
>>>>>>>> goes crazy and constantly refreshes the output.
>
>>>>>>>> It does that with many older versions of the perf as well on 3.14.
>>>>>>>> It runs fine with newt mode.
>
>>>>>>>> Works fine with my 3.11 kernel. So something must be broken
>>>>>>>> with 3.14.
>
>>>>>>>> Can you reproduce the problem as well?
>
>>>>>>> Not so far, using my perf/urgent branch:
>
>>>>>> I am using tip.git. Or try 3.11, 3.10.
>
>>>> But my tests are on top of:
>
>>>> [acme@ssdandy linux]$ uname -r
>>>> 3.11.4-101.fc18.x86_64
>
>>>> I thought it was a 3.14ish one, building one to try there...
>>>>
>>> The kernel must be 3.14-rcX, the tool can be any version.
>>
>> I don't have time to do a git bisect, but I can narrow the window to
>> 3.13-rc6 and 3.14-rc1. Just happened to update a server yesterday.
>> perf-top --stdio runs fine on the former and shows the problem on
>> the latter.
>
> Bisected it down to:
>
> eb3e4668bd9e0bbda592e830e889f137e44ec9e4 is the first bad commit
> commit eb3e4668bd9e0bbda592e830e889f137e44ec9e4
> Author: Peter Hurley <peter@hurleysoftware.com>
> Date:   Mon Dec 2 14:24:42 2013 -0500
>
>      n_tty: Un-inline slow-path n_tty_receive_char()
>
>      Commit e60d27c4d8b33ba20896b76b6558f061bc6460ff,
>      n_tty: Factor LNEXT processing from per-char i/o path,
>      mistakenly inlined the non-inline alias, n_tty_receive_char(),
>      for the inline function, n_tty_receive_char_inline().
>
>      As n_tty_receive_char() is intended for slow-path char
>      processing only, un-inline it.
>
>      Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
>      Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> :040000 040000 80215819e331ff95d80aa7c8a6a05f8c74d1fdb6 41a856dfeb6769e47c7689c92d91db497dfcc8cf M	drivers
> [acme@fedora20 linux]$
>
> In a hurry now, will continue later, trying to understand what is the problem
> introduced by the above cset...
>
> Need to revert just this one to confirm that it is the culprit, etc.

Thanks for the report and bisect. Seems unlikely this commit is the
cause, but very likely to be some change I made since 3.13, since
I can repro on 3.14-rc1 but not on 3.13.2 -stable. I can also repro
this on 3.12 + the patch stack from me for 3.13 and 3.14.

I'm looking into this now.

Regards,
Peter Hurley

Re: [BUG] perf top: --stdio causes continuous refresh

[Arnaldo Carvalho de Melo]

Em Mon, Feb 10, 2014 at 09:15:42PM -0500, Peter Hurley escreveu:
> >Bisected it down to:

> >eb3e4668bd9e0bbda592e830e889f137e44ec9e4 is the first bad commit
> >Author: Peter Hurley <peter@hurleysoftware.com>
> >Date:   Mon Dec 2 14:24:42 2013 -0500

> >     n_tty: Un-inline slow-path n_tty_receive_char()

> >In a hurry now, will continue later, trying to understand what is the problem
> >introduced by the above cset...

> >Need to revert just this one to confirm that it is the culprit, etc.

> Thanks for the report and bisect. Seems unlikely this commit is the
> cause, but very likely to be some change I made since 3.13, since
> I can repro on 3.14-rc1 but not on 3.13.2 -stable. I can also repro
> this on 3.12 + the patch stack from me for 3.13 and 3.14.

> I'm looking into this now.

I just reverted just this cset and the problem persisted, so I'll wait
for you on this one :-)

- Arnaldo

Re: [BUG] perf top: --stdio causes continuous refresh

[Peter Hurley]

On 02/11/2014 07:14 AM, Arnaldo Carvalho de Melo wrote:
> Em Mon, Feb 10, 2014 at 09:15:42PM -0500, Peter Hurley escreveu:
>>> Bisected it down to:
>
>>> eb3e4668bd9e0bbda592e830e889f137e44ec9e4 is the first bad commit
>>> Author: Peter Hurley <peter@hurleysoftware.com>
>>> Date:   Mon Dec 2 14:24:42 2013 -0500
>
>>>      n_tty: Un-inline slow-path n_tty_receive_char()
>
>>> In a hurry now, will continue later, trying to understand what is the problem
>>> introduced by the above cset...
>
>>> Need to revert just this one to confirm that it is the culprit, etc.
>
>> Thanks for the report and bisect. Seems unlikely this commit is the
>> cause, but very likely to be some change I made since 3.13, since
>> I can repro on 3.14-rc1 but not on 3.13.2 -stable. I can also repro
>> this on 3.12 + the patch stack from me for 3.13 and 3.14.
>
>> I'm looking into this now.
>
> I just reverted just this cset and the problem persisted, so I'll wait
> for you on this one :-)

I did the same with the same result. So I'm re-bisecting on one machine
and tracing on another.

Regards,
Peter Hurley

[PATCH] n_tty: Fix poll() when TIME_CHAR and MIN_CHAR == 0

[Peter Hurley]

On 02/11/2014 07:14 AM, Arnaldo Carvalho de Melo wrote:
> Em Mon, Feb 10, 2014 at 09:15:42PM -0500, Peter Hurley escreveu:
>>> Bisected it down to:
>
>>> eb3e4668bd9e0bbda592e830e889f137e44ec9e4 is the first bad commit
>>> Author: Peter Hurley <peter@hurleysoftware.com>
>>> Date:   Mon Dec 2 14:24:42 2013 -0500
>
>>>      n_tty: Un-inline slow-path n_tty_receive_char()
>
>>> In a hurry now, will continue later, trying to understand what is the problem
>>> introduced by the above cset...
>
>>> Need to revert just this one to confirm that it is the culprit, etc.
>
>> Thanks for the report and bisect. Seems unlikely this commit is the
>> cause, but very likely to be some change I made since 3.13, since
>> I can repro on 3.14-rc1 but not on 3.13.2 -stable. I can also repro
>> this on 3.12 + the patch stack from me for 3.13 and 3.14.
>
>> I'm looking into this now.
>
> I just reverted just this cset and the problem persisted, so I'll wait
> for you on this one :-) 

My bisection pointed to:

eafbe67f84761d787802e5113d895a316b6292fe is the first bad commit
commit eafbe67f84761d787802e5113d895a316b6292fe
Author: Peter Hurley <peter@hurleysoftware.com>
Date:   Mon Dec 2 14:24:45 2013 -0500

    n_tty: Refactor input_available_p() by call site

Apologies for the breakage; the patch below should fix it.

Regards,
Peter Hurley

--- >% ---
From: Peter Hurley <peter@hurleysoftware.com>
Date: Tue, 11 Feb 2014 10:10:07 -0500
Subject: [PATCH] n_tty: Fix poll() when TIME_CHAR and MIN_CHAR == 0

Commit eafbe67f84761d787802e5113d895a316b6292fe,
  n_tty: Refactor input_available_p() by call site
broke poll() when TIME_CHAR(tty) and MIN_CHAR(tty) are both 0.

When TIME_CHAR and MIN_CHAR are both 0, input is available if the
read_cnt is 1 (not 0).

Reported-by: Stephane Eranian <eranian@google.com>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
---
 drivers/tty/n_tty.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index cb8017a..2747a3b 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -1896,7 +1896,7 @@ err:
 static inline int input_available_p(struct tty_struct *tty, int poll)
 {
 	struct n_tty_data *ldata = tty->disc_data;
-	int amt = poll && !TIME_CHAR(tty) ? MIN_CHAR(tty) : 1;
+	int amt = poll && !TIME_CHAR(tty) && MIN_CHAR(tty) ? MIN_CHAR(tty) : 1;
 
 	if (ldata->icanon && !L_EXTPROC(tty)) {
 		if (ldata->canon_head != ldata->read_tail)
-- 
1.8.1.2

Re: [PATCH] n_tty: Fix poll() when TIME_CHAR and MIN_CHAR == 0

[David Ahern]

On 2/11/14, 9:49 AM, Peter Hurley wrote:
> From: Peter Hurley <peter@hurleysoftware.com>
> Date: Tue, 11 Feb 2014 10:10:07 -0500
> Subject: [PATCH] n_tty: Fix poll() when TIME_CHAR and MIN_CHAR == 0
>
> Commit eafbe67f84761d787802e5113d895a316b6292fe,
>    n_tty: Refactor input_available_p() by call site
> broke poll() when TIME_CHAR(tty) and MIN_CHAR(tty) are both 0.
>
> When TIME_CHAR and MIN_CHAR are both 0, input is available if the
> read_cnt is 1 (not 0).
>
> Reported-by: Stephane Eranian <eranian@google.com>
> Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
> ---
>   drivers/tty/n_tty.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
> index cb8017a..2747a3b 100644
> --- a/drivers/tty/n_tty.c
> +++ b/drivers/tty/n_tty.c
> @@ -1896,7 +1896,7 @@ err:
>   static inline int input_available_p(struct tty_struct *tty, int poll)
>   {
>   	struct n_tty_data *ldata = tty->disc_data;
> -	int amt = poll && !TIME_CHAR(tty) ? MIN_CHAR(tty) : 1;
> +	int amt = poll && !TIME_CHAR(tty) && MIN_CHAR(tty) ? MIN_CHAR(tty) : 1;
>
>   	if (ldata->icanon && !L_EXTPROC(tty)) {
>   		if (ldata->canon_head != ldata->read_tail)
>

Worked for me.

Tested-by: David Ahern <dsahern@gmail.com>

Re: [PATCH] n_tty: Fix poll() when TIME_CHAR and MIN_CHAR == 0

[Eric Dumazet]

On Tue, 2014-02-11 at 11:49 -0500, Peter Hurley wrote:

> From: Peter Hurley <peter@hurleysoftware.com>
> Date: Tue, 11 Feb 2014 10:10:07 -0500
> Subject: [PATCH] n_tty: Fix poll() when TIME_CHAR and MIN_CHAR == 0
> 
> Commit eafbe67f84761d787802e5113d895a316b6292fe,
>   n_tty: Refactor input_available_p() by call site
> broke poll() when TIME_CHAR(tty) and MIN_CHAR(tty) are both 0.
> 
> When TIME_CHAR and MIN_CHAR are both 0, input is available if the
> read_cnt is 1 (not 0).
> 
> Reported-by: Stephane Eranian <eranian@google.com>
> Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
> ---
>  drivers/tty/n_tty.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
> index cb8017a..2747a3b 100644
> --- a/drivers/tty/n_tty.c
> +++ b/drivers/tty/n_tty.c
> @@ -1896,7 +1896,7 @@ err:
>  static inline int input_available_p(struct tty_struct *tty, int poll)
>  {
>  	struct n_tty_data *ldata = tty->disc_data;
> -	int amt = poll && !TIME_CHAR(tty) ? MIN_CHAR(tty) : 1;
> +	int amt = poll && !TIME_CHAR(tty) && MIN_CHAR(tty) ? MIN_CHAR(tty) : 1;
>  
>  	if (ldata->icanon && !L_EXTPROC(tty)) {
>  		if (ldata->canon_head != ldata->read_tail)

Reported-by: Eric Dumazet <edumazet@google.com>
Tested-by: Eric Dumazet <edumazet@google.com>

Thanks guys

Re: [PATCH] n_tty: Fix poll() when TIME_CHAR and MIN_CHAR == 0

[Arnaldo Carvalho de Melo]

> Commit eafbe67f84761d787802e5113d895a316b6292fe,
>   n_tty: Refactor input_available_p() by call site
> broke poll() when TIME_CHAR(tty) and MIN_CHAR(tty) are both 0.
> 
> When TIME_CHAR and MIN_CHAR are both 0, input is available if the
> read_cnt is 1 (not 0).
> 
> Reported-by: Stephane Eranian <eranian@google.com>
> Signed-off-by: Peter Hurley <peter@hurleysoftware.com>

Thanks,

Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>

- Arnaldo

> ---
>  drivers/tty/n_tty.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
> index cb8017a..2747a3b 100644
> --- a/drivers/tty/n_tty.c
> +++ b/drivers/tty/n_tty.c
> @@ -1896,7 +1896,7 @@ err:
>  static inline int input_available_p(struct tty_struct *tty, int poll)
>  {
>  	struct n_tty_data *ldata = tty->disc_data;
> -	int amt = poll && !TIME_CHAR(tty) ? MIN_CHAR(tty) : 1;
> +	int amt = poll && !TIME_CHAR(tty) && MIN_CHAR(tty) ? MIN_CHAR(tty) : 1;
>  
>  	if (ldata->icanon && !L_EXTPROC(tty)) {
>  		if (ldata->canon_head != ldata->read_tail)
> -- 
> 1.8.1.2