Re: linux-next: Tree for Dec 11
From: Guenter Roeck
Date: Tue Dec 11 2018 - 17:37:39 EST
On Tue, Dec 11, 2018 at 11:04:37AM -0700, Nathan Chancellor wrote:
> On Tue, Dec 11, 2018 at 09:38:51AM -0800, Guenter Roeck wrote:
> > On Tue, Dec 11, 2018 at 06:26:27PM +1100, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Changes since 20181210:
> > >
> > > The arm64 tree gained a conflict against Linus' tree.
> > >
> > > The f2fs tree gained a conflict against the fscrypt tree.
> > >
> > > The ubifs tree gained a conflict against the fscrypt tree.
> > >
> > > The rdma tree still had its build failure so I used the version from
> > > next-20181203.
> > >
> > > The tip tree gained a conflict against the hwmon-staging tree.
> > >
> > > The gpio tree lost its build failure.
> > >
> > > The akpm-current tree lost its build failure but gained conflist against
> > > the arm64 tree.
> > >
> > > Non-merge commits (relative to Linus' tree): 7744
> > > 8462 files changed, 365061 insertions(+), 211977 deletions(-)
> > >
> >
> > Build results:
> > total: 152 pass: 150 fail: 2
> > Failed builds:
> > arm:allmodconfig
> > arm64:allmodconfig
> > Qemu test results:
> > total: 337 pass: 137 fail: 200
> >
> > Build failures:
> >
> > arm:
> >
> > In file included from drivers/media/pci/ddbridge/ddbridge.h:22:0,
> > from drivers/media/pci/ddbridge/ddbridge-ci.c:19:
> > arch/arm/include/asm/irq.h:35:50: error: unknown type name 'cpumask_t'
> >
>
> Just FYI, I noticed this one yesterday on next-20181210 and sent a patch:
> https://lore.kernel.org/linux-media/20181210233514.3069-1-natechancellor@xxxxxxxxx/
>
Excellent, thanks!
> > arm64:
> >
> > arch/arm64/kernel/entry-ftrace.o:(_kprobe_blacklist+0x0): dangerous relocation:
> > unsupported relocation
> >
> > The latter is with gcc 7.3.0. I'll build and try with gcc 7.4.0 and
> > the most recent binutils later.
> >
A build with gcc 7.4.0 has exactly the same problem.
> > Most of the failing qemu tests fail with something like
> >
> > Starting init: /sbin/init exists but couldn't execute it (error -95)
> >
> > Others (such as aarch64) crash silently.
> >
> > Has anyone reported this already, or do I need to run bisect ?
> >
Turns out this is due to "fsverity: Move verity status check to
fsverity_file_open", and the author should be aware of the problem.
Guenter