Hi Arnd,
On Thursday 19 May 2016 02:37 PM, Arnd Bergmann wrote:
> On Thursday 19 May 2016 00:45:16 Olof's autobuilder wrote:
>> Errors:
>>
>> arm64.allmodconfig:
>> samples/seccomp/bpf-fancy.c:13:27: fatal error: linux/seccomp.h: No such
>> file or directory
>> samples/seccomp/dropper.c:20:27: fatal error: linux/seccomp.h: No such file
>> or directory
>> samples/seccomp/bpf-helper.h:20:50: fatal error: linux/seccomp.h: No such
>> file or directory
>> samples/seccomp/bpf-direct.c:21:27: fatal error: linux/seccomp.h: No such
>> file or directory
>
> This one is interesting: the same header dependency seems to be present for
> samples/bpf,
> but only samples/seccomp fails. Can you check if both are attempted to be
> built?
>
> samples/bpf/README.rst says about this:
>
> |Kernel headers
> |--------------
> |
> |There are usually dependencies to header files of the current kernel.
> |To avoid installing devel kernel headers system wide, as a normal
> |user, simply call::
> |
> | make headers_install
> |
> |This will creates a local "usr/include" directory in the git/build top
> |level directory, that the make system automatically pickup first.
>
> which I assume would fix the problem, but it would be better if Kbuild was
> smart enough
> to do this implicitly when building these samples.
>
>> powerpc.pasemi_defconfig:
>> arch/powerpc/kernel/ptrace.c:380:24: error: index 32 denotes an offset
>> greater than size of 'u64[32][1] {aka long long unsigned int[32][1]}'
>> [-Werror=array-bounds]
>> arch/powerpc/kernel/ptrace.c:408:24: error: index 32 denotes an offset
>> greater than size of 'u64[32][1] {aka long long unsigned int[32][1]}'
>> [-Werror=array-bounds]
>
> I don't see a good way to avoid the warning other than dropping the
>
> BUILD_BUG_ON(offsetof(struct thread_fp_state, fpscr) !=
> offsetof(struct thread_fp_state, fpr[32][0]));
>
> statements in the powerpc ptrace implementation. It doesn't seem too
> important to check for though.
>
>
>> Warnings:
>
>> 2 drivers/net/wireless/intel/iwlegacy/3945.c:1022:5: warning: suggest
>> explicit braces to avoid ambiguous 'else' [-Wparentheses]
>
> I had not seen this before, sent a patch now.
>
>> 3 drivers/pinctrl/stm32/pinctrl-stm32.c:797:17: warning: too many
>> arguments for format [-Wformat-extra-args]
>
> sent a fix yesterday, got an ack but it wasn't applied yet. I'm sure Linus
> Walleij
> will take care of it soon.
>
>> 6 mm/page_alloc.c:3651:6: warning: 'compact_result' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
>
> I'm surprised this one is still there, I sent a patch but Michal Hocko came
> up with
> a better fix on May 12, which was not applied yet.
>
> Michael, can you resend this one to Andrew? I suspect he missed it as it was
> sent as a reply to mine.
>
>> 2 drivers/xen/balloon.c:154:13: warning: 'release_memory_resource'
>> declared 'static' but never defined [-Wunused-function]
>
> I sent a patch on May 11, subject "xen: remove incorrect forward declaration"
> and
> Stefano Stabellini reviewed it. Ross Lagerwall did the same patch a day
> earlier,
> but neither of them has made it into linux-next so far. According to Ross,
> this
> one should be backported to v4.4.
>
>> 3 fs/xfs/xfs_aops.c:97:16: warning: unused variable 'blockmask'
>> [-Wunused-variable]
>
> I sent a patch on April 16, but got no reply. Resending it now.
>
>> 2 arch/arm/mach-lpc32xx/include/mach/irqs.h:115:0: warning: "NR_IRQS"
>> redefined
>
> I missed this one, as I have some other patches for lp32xx in my randconfig
> fixup tree that hides it.
>
> I've created a fix now and applied it to the arm-soc fixes branch.
>
>> 1 drivers/soc/mediatek/mtk-pmic-wrap.c:1062:16: warning: large integer
>> implicitly truncated to unsigned type [-Woverflow]
>> 1 drivers/soc/mediatek/mtk-pmic-wrap.c:1074:16: warning: large integer
>> implicitly truncated to unsigned type [-Woverflow]
>> 1 drivers/soc/mediatek/mtk-pmic-wrap.c:1086:16: warning: large integer
>> implicitly truncated to unsigned type [-Woverflow]
>
> I sent out a patch on May 12 for this, got no reply. I've applied my own patch
> now on the arm-soc fixes branch.
>
>> 1 drivers/phy/phy-exynos-mipi-video.c:238:13: warning: 'val' may be
>> used uninitialized in this function [-Wmaybe-uninitialized]
>
> I sent a patch on May 11, it was reviewed by Krzysztof Kozlowski, but not yet
> applied.
Is it okay if I send this during the -rc cycle?
Thanks
Kishon
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
