linux-kernel - Re: samples/kdbus/kdbus-workers.c and cross compiling MIPS

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: <1438326061.29353.9.camel@ellerman.id.au>
Date:	Fri, 31 Jul 2015 17:01:01 +1000
From:	Michael Ellerman <mpe@...erman.id.au>
To:	David Herrmann <dh.herrmann@...il.com>
Cc:	Paul Gortmaker <paul.gortmaker@...driver.com>,
	David Herrmann <dh.herrmann@...glemail.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Daniel Mack <daniel@...que.org>,
	Djalal Harouni <tixxdz@...ndz.org>, linux-mips@...ux-mips.org,
	linux-kernel <linux-kernel@...r.kernel.org>,
	"linux-next@...r.kernel.org" <linux-next@...r.kernel.org>
Subject: Re: samples/kdbus/kdbus-workers.c and cross compiling MIPS

On Thu, 2015-07-30 at 16:23 +0200, David Herrmann wrote:
> Hi
> 
> On Thu, Jul 30, 2015 at 3:50 PM, Paul Gortmaker
> <paul.gortmaker@...driver.com> wrote:
> > On 2015-07-29 12:31 PM, David Herrmann wrote:
> >> Hi
> >>
> >> On Wed, Jul 29, 2015 at 6:19 PM, Paul Gortmaker
> >> <paul.gortmaker@...driver.com> wrote:
> >>> Hi David,
> >>>
> >>> Does it make sense to build this sample when cross compiling?
> >>>
> >>> The reason I ask is that it has been breaking the linux-next build of
> >>> allmodconfig for a while now, with:
> >>>
> >>>   HOSTCC  samples/kdbus/kdbus-workers
> >>> samples/kdbus/kdbus-workers.c: In function ‘prime_new’:
> >>> samples/kdbus/kdbus-workers.c:934:18: error: ‘__NR_memfd_create’ undeclared (first use in this function)
> >>>   p->fd = syscall(__NR_memfd_create, "prime-area", MFD_CLOEXEC);
> >>>                   ^
> >>> samples/kdbus/kdbus-workers.c:934:18: note: each undeclared identifier is reported only once for each function it appears in
> >>> scripts/Makefile.host:91: recipe for target 'samples/kdbus/kdbus-workers' failed
> >>> make[2]: *** [samples/kdbus/kdbus-workers] Error 1
> >>
> >> mips does have this syscall, so I assume the problem is out-of-date
> >> kernel headers. You can fix this by running:
> >>
> >>     $ make headers_install
> >
> > No, let me try and clarify. Please note the emphasis on cross compiling
> > and automated build coverage, i.e. there is no place for manual steps.
> 
> User-space samples in ./samples/ are compiled with HOSTCC, which is
> the compiler for the _local_ machine. Regardless of cross-compiling
> the same local compiler is used. So I cannot understand why this is
> even remotely related to cross compiling. Please elaborate.
> Please note that this is HOSTCC running, so it does *NOT* require the
> toolchain for your cross-compiled architecture.

Right. Our cross toolchain wouldn't build it anyway, as it has no libc.

> Also, please tell me why your system has "linux/memfd.h" available,
> but __NR_memfd_create is undefined?

Because it's building with the HOSTCC (x86_64), against the MIPS kernel
headers. And the MIPS kernel headers are structured in such a way that on a
non-mips build they don't define the syscall numbers.

The reason we have the MIPS headers installed is because CONFIG_HEADERS_CHECK
is turned on (because allmodconfig).

So that just basically makes no sense to me.

It's obviously possible that some samples build with that configuration, but
building against another arch'es kernel headers just seems like it's asking for
trouble. Even if we can build the samples, they will never run correctly.

So I suggest we should just disable SAMPLES if we're cross compiling, full stop.

cheers


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