lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140210210358.GD3202@infradead.org>
Date:	Mon, 10 Feb 2014 19:03:58 -0200
From:	Arnaldo Carvalho de Melo <acme@...hat.com>
To:	David Ahern <dsahern@...il.com>
Cc:	Stephane Eranian <eranian@...gle.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	"mingo@...e.hu" <mingo@...e.hu>, Jiri Olsa <jolsa@...hat.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Peter Hurley <peter@...leysoftware.com>
Subject: Re: [BUG] perf top: --stdio causes continuous refresh

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@...hat.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@...hat.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@...andy 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@...leysoftware.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@...leysoftware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>

:040000 040000 80215819e331ff95d80aa7c8a6a05f8c74d1fdb6 41a856dfeb6769e47c7689c92d91db497dfcc8cf M	drivers
[acme@...ora20 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ