linux-kernel - Re: [PATCH 0/3] nohz: Convert tick dependency mask to atomic

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: <20160325084847.GA15235@gmail.com>
Date:	Fri, 25 Mar 2016 09:48:47 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 0/3] nohz: Convert tick dependency mask to atomic_t


* Frederic Weisbecker <fweisbec@...il.com> wrote:

> As per Linus suggestion, lets convert the tick dependency mask to
> atomic_t. Introduce atomic_fetch_or() and confine fetch_or() back to
> scheduler guts.
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
> 	timers/nohz
> 
> HEAD: 7b7e5da5733f58668181077ec394a718e08c392c
> 
> Thanks,
> 	Frederic
> ---
> 
> Frederic Weisbecker (3):
>       atomic: Introduce atomic_fetch_or
>       nohz: Convert tick dependency mask to atomic_t
>       Revert "atomic: Export fetch_or()"
> 
> 
>  include/linux/atomic.h   | 34 +++++++++++++--------------
>  include/linux/sched.h    |  4 ++--
>  kernel/sched/core.c      | 18 ++++++++++++++
>  kernel/time/tick-sched.c | 61 ++++++++++++++++++++++++------------------------
>  kernel/time/tick-sched.h |  2 +-
>  5 files changed, 68 insertions(+), 51 deletions(-)

Could you please also convert the sched/core.c usage, so that we can get rid of 
the private fetch_or() definition? Please also double check that it does not 
result in worse code generation.

Thanks,

	Ingo