Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1702091415140.3604@nanos>
Date: Thu, 9 Feb 2017 14:41:43 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Dave Jones <davej@...emonkey.org.uk>
cc: Linus Torvalds <torvalds@...ux-foundation.org>, 
    Kees Cook <keescook@...omium.org>, Xing Gao <xgao01@...il.wm.edu>, 
    Jessica Frazelle <me@...sfraz.com>, John Stultz <john.stultz@...aro.org>, 
    "Eric W. Biederman" <ebiederm@...ssion.com>, 
    Jonathan Corbet <corbet@....net>, Tejun Heo <tj@...nel.org>, 
    Lai Jiangshan <jiangshanlai@...il.com>, Petr Mladek <pmladek@...e.com>, 
    Andrew Morton <akpm@...ux-foundation.org>, Oleg Nesterov <oleg@...hat.com>, 
    Nicolas Iooss <nicolas.iooss_linux@....org>, 
    Nicolas Pitre <nicolas.pitre@...aro.org>, 
    Richard Cochran <richardcochran@...il.com>, 
    "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>, 
    Michal Marek <mmarek@...e.com>, Josh Poimboeuf <jpoimboe@...hat.com>, 
    Dmitry Vyukov <dvyukov@...gle.com>, Olof Johansson <olof@...om.net>, 
    Shuah Khan <shuah@...nel.org>, 
    "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>, 
    Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, 
    "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, 
    Arjan van de Ven <arjan@...ux.intel.com>
Subject: Re: [PATCH v2] time: Remove CONFIG_TIMER_STATS

On Wed, 8 Feb 2017, Dave Jones wrote:

> On Wed, Feb 08, 2017 at 11:54:30AM -0800, Linus Torvalds wrote:
>  > On Wed, Feb 8, 2017 at 11:26 AM, Kees Cook <keescook@...omium.org> wrote:
>  > >
>  > > Given that the tracer can give the same information, this patch entirely
>  > > removes CONFIG_TIMER_STATS.
>  > >
>  > > Suggested-by: Thomas Gleixner <tglx@...utronix.de>
>  > > Signed-off-by: Kees Cook <keescook@...omium.org>
>  > > Acked-by: John Stultz <john.stultz@...aro.org>
>  > 
>  > Looks good to me. Let's wait for the 4.11 merge window though. I'm
>  > assuming I'll get this through the tip timer tree..
> 
> >From a quick look at the source, powertop uses this file, and appears to
> handle it gracefully if it fails to open, but it will lose functionality
> to determine if a timer is deferred.

The lookup happens when evaluating a timer_expire_entry tracing event.

With current kernels the same information can be retrieved from the
timer_start tracing event (flags field). And that's way more sensible than
scanning timer_stats because when the trace is evaluated there is no
guarantee at all that the timer is still queued and exposed there. That
should be trivial to fix in powertop.

Thanks,

	tglx


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.