Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CALAqxLU2OTBk1gmiZgoQ2ZzF6eOuOyCGEUNqXXuq+koZ1mYceA@mail.gmail.com>
Date: Wed, 8 Feb 2017 10:09:39 -0800
From: John Stultz <john.stultz@...aro.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Kees Cook <keescook@...omium.org>, Xing Gao <xgao01@...il.wm.edu>, 
	Jessica Frazelle <me@...sfraz.com>, "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>, linux-doc@...r.kernel.org, 
	lkml <linux-kernel@...r.kernel.org>, kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH] time: Remove CONFIG_TIMER_STATS

On Wed, Feb 8, 2017 at 2:24 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
> On Tue, 7 Feb 2017, John Stultz wrote:
>> On Tue, Feb 7, 2017 at 3:40 PM, Kees Cook <keescook@...omium.org> wrote:
>> > Currently CONFIG_TIMER_STATS exposes process information across namespaces:
>> >
>> > kernel/time/timer_list.c print_timer():
>> >
>> >         SEQ_printf(m, ", %s/%d", tmp, timer->start_pid);
>> >
>> > /proc/timer_list:
>> >
>> >  #11: <0000000000000000>, hrtimer_wakeup, S:01, do_nanosleep, cron/2570
>> >
>> > 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>
>>
>> I don't have an issue with this, but I worry this would break some
>> tooling out there. Should it be marked as deprecated first?
>>
>> Or maybe just pulling the band-aid off is the best way?
>
> I think we should just kill it.
>
> No tools can really rely on the behaviour of that file because it depends
> on CONFIG_TIMER_STATS and the information available there is just a random
> snapshot of queued timers at a given point of time, which is in no way
> usefull.

Fair enough.

Acked-by: John Stultz <john.stultz@...aro.org>

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.