linux-kernel - Re: linux-next: Tree for Jun 21

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, 21 Jun 2016 19:06:07 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Chris Metcalf <cmetcalf@...lanox.com>
Cc:	Sudip Mukherjee <sudipm.mukherjee@...il.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 11:26:19AM -0400, Chris Metcalf wrote:
> On 6/21/2016 10:14 AM, Peter Zijlstra wrote:
> >On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote:
> >>>I'm not sure who builds the toolchains, but tilepro is in upstream gcc/binutils/etc
> >>>so should be easy enough to include.  There's also a cross-toolchain for x64 I put
> >>>up a while ago [1] that you could grab if you wanted to try it.
> >>I usually build my own set -- and just did. But tilepro was not
> >>included. Lemme go do so.
> >binutils-2_26-branch builds for tilepro-linux
> >gcc-6-branch does _not_ build for tilepro-linux
> 
> I figured I would take a stab at diagnosing this myself, and it looks like the
> toolchain build assumes that the kernel headers have already been installed
> and therefore we have <asm/unistd.h> available.  This actually seems like
> a reasonable prerequisite for building the toolchain.  I'm guessing you
> don't?  Should you?  Or perhaps the compiler shouldn't make that assumption?

I can build:

ls -la /opt/cross/bin/*-gcc | wc -l
27

compilers without installing kernel headers.

> This has been true since gcc 4.x when tilepro support was first added.
> 
> In any case if you replace the #include <asm/unistd.h> with
> 
> #define __NR_FAST_cmpxchg    -1
> #define __NR_FAST_atomic_update    -2
> #define __NR_FAST_cmpxchg64    -3
> 
> that should also probably fix it, though I haven't tested it.  It probably
> wouldn't be crazy to just put those #defines directly in tilepro's atomic.h,
> since it's not like those fast system call numbers will ever change.

OK, I'll go test that right after I've got the kid in bed .. I'll let
you know.