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
