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:	Tue, 29 Mar 2016 11:44:54 +0200
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:

> On Fri, Mar 25, 2016 at 09:48:47AM +0100, Ingo Molnar wrote:
> > 
> > * 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.
> 
> That involve converting thread_info::flags to atomic_t and given how much the type varies
> across architectures:

Ah, yes - I did a similar analysis originally and then promptly forgot about it!

Harmonizing thread_info::flags does not look easy, given how much assembly code 
accesses this field.

So I suspect your original series of introducing the atomic_t interface while 
reverting back to the scheduler-specific auto-typing hack is fine after all.

> also given how much it is accessed (and that happens a lot in ASM as well). This 
> conversion deserves quite a whole project on its own.
> 
> It might be possible to do it incrementally though.

So I don't even know where to begin with that:

 - some 64-bit architectures want 32-bit flags
 - some 64-bit architectures want 64-bit flags
 - some 64-bit architectures may genuinely want more than 32 flags
 - some 64-bit architectures may want 64-bit word just because it's the fastest

... there's not a single natural data type on the C side that I can see this could 
be converted to :-/

Thanks,

	Ingo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ