Re: linux-next: Tree for Dec 11

[Guenter Roeck <linux@roeck-us.net>]

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@gmail.com/
> 
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