linux-kernel - Re: Question about barriers for ARM on tools/perf/

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] [day] [month] [year] [list]

Message-ID: <20150508181844.GN7862@kernel.org>
Date:	Fri, 8 May 2015 15:18:44 -0300
From:	Arnaldo Carvalho de Melo <acme@...nel.org>
To:	Will Deacon <will.deacon@....com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>,
	David Ahern <dsahern@...il.com>, Jiri Olsa <jolsa@...hat.com>,
	Namhyung Kim <namhyung@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Question about barriers for ARM on tools/perf/

Em Fri, May 08, 2015 at 05:45:35PM +0100, Will Deacon escreveu:
> On Fri, May 08, 2015 at 04:27:59PM +0100, Peter Zijlstra wrote:
> > On Fri, May 08, 2015 at 11:57:01AM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Fri, May 08, 2015 at 03:48:20PM +0100, Will Deacon escreveu:

> > > > Do you know what the objection to the intrinsics was? I believe that
> > > > the __sync versions are deprecated in favour of the C11-like __atomic
> > > > flavours, so if that was all the objection was about then we could use
> > > > one or the other depending on what the compiler supports.
 
> > > Peter? Ingo?

> > I cannot remember, the __sync things should mostly work I suppose, and
> > if you wrap then in the normal atomic interface we don't have to learn
> > yet another API.
 
> Yeah, I think that's a good idea.

I'll use what I have, that is what I posted, i.e. something that was
tested. As we test it further, then we can either lift more stuff from
the kernel or add more compiler-foo.h stuff like we have in the kernel.
 
> > That said, I've successfully lifted this kernel code into userspace in
> > the past.
> 
> Lifting a copy isn't too bad, it's using the same file that worries me.

So that is how I'll proceed, lifting a copy of just what I need, lifting
more as the need arises, and fallbacking to gcc intrinsics for
architectures where the implementations drag too much stuff.

Over time, as the need arises, maybe to support some older compiler or
some problematic toolchain, lifting more from the kernel may be desired
and should be considered.

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