linux-kernel - Re: [PATCH Resend] Expose do_timer CPU via sysctl to userspace as R/W

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]

Date:	Wed, 19 Feb 2014 17:42:07 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	henrik@...tad.us
cc:	LKML <linux-kernel@...r.kernel.org>,
	Henrik Austad <haustad@...co.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	John Stultz <john.stultz@...aro.org>
Subject: Re: [PATCH Resend] Expose do_timer CPU via sysctl to userspace as
 R/W

On Wed, 19 Feb 2014, henrik@...tad.us wrote:
> From: Henrik Austad <haustad@...co.com>
> 
> Looks like this got dropped by vger a few days ago, resending.
> 
> This allows everybody in a system to read which core is currently
> running do_timer() as well as letting root change this.
> 
> A few things to keep in mind
> 
> - This is intended as a debug-feature, except for testing whether or not
>   the target CPU is present or not, the logic will not care -one- bit if
>   moving the do_timer to that particular CPU is a good idea.

Well at least it must check that the cpu is online and neither in
nohz idle nor nohz full mode.

And we probably want to have that in sysfs with two files:

    timekeeping/current_cpu
    timekeeping/forced_cpu

The latter contains -1 when the system boots and if you write to it,
the duty gets hard assigned to that core, which in turn makes it
blocked from NOHZ idle and NOHZ full modes. If the core goes offline,
then the value must got back to -1. Writing -1 to it undoes the hard
assignment.

> - It introduces more ifdeffery in the kernel.

There is no reason to do that.

Thanks,

	tglx
--
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/