On Thu, Apr 20, 2017 at 9:56 AM, kernelci.org bot bot@kernelci.org wrote:
next/master build: 206 builds: 2 failed, 204 passed, 9 errors, 10 warnings
cavium_octeon_defconfig (mips) — FAIL, 8 errors, 0 warnings, 0 section mismatches
Errors: arch/mips/cavium-octeon/octeon-usb.c:256:12: error: 'union cvmx_gpio_bit_cfgx' has no member named 'cn73xx' arch/mips/cavium-octeon/octeon-usb.c:261:12: error: 'union cvmx_gpio_bit_cfgx' has no member named 'cn70xx' arch/mips/cavium-octeon/octeon-usb.c:264:33: error: implicit declaration of function 'CVMX_GPIO_XBIT_CFGX' [-Werror=implicit-function-declaration] arch/mips/cavium-octeon/octeon-usb.c:266:12: error: 'union cvmx_gpio_bit_cfgx' has no member named 'cn70xx'
Apparently caused by 23c1c9508364 ("MIPS: Octeon: Remove unused GPIO types and macros.") which was merged last week
drivers/net/ethernet/cavium/octeon/octeon_mgmt.c:707:20: error: 'CVMX_MIO_PTP_CLOCK_COMP' undeclared (first use in this function) drivers/watchdog/octeon-wdt-main.c:585:18: error: 'CVMX_MIO_BOOT_LOC_ADR' undeclared (first use in this function) drivers/watchdog/octeon-wdt-main.c:586:18: error: 'CVMX_MIO_BOOT_LOC_DAT' undeclared (first use in this function)
Same for 8ed898353e36 ("MIPS: Octeon: Remove unused MIO types and macros.")
davinci_all_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches
Section mismatches: WARNING: modpost: Found 1 section mismatch(es). WARNING: modpost: Found 1 section mismatch(es).
The 'section mismatches' detection in kernelci appears to be broken, so we don't actually see what happened. I can't reproduce it at the moment, so it's likely that this is fixed by an older patch of mine:
commit aae89d7dddb831aece31997cdc1c5014fb5a51c1 Author: Arnd Bergmann arnd@arndb.de Date: Sat Oct 10 21:19:48 2015 +0200
[WRONG] davinci_mmc: remove incorrect __exit annotation
WARNING: drivers/built-in.o(.exit.text+0x28ec): Section mismatch in reference from the function davinci_mmcsd_remove() to the function .init.text:davinci_release_dma_channels() The function __exit davinci_mmcsd_remove() references a function __init davinci_release_dma_channels(). This is often seen when error handling in the exit function uses functionality in the init path. The fix is often to remove the __init annotation of davinci_release_dma_channels() so it may be used outside an init section.
Signed-off-by: Arnd Bergmann arnd@arndb.de
diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c index 621ce47e0e4a..9758d42f19a1 100644 --- a/drivers/mmc/host/davinci_mmc.c +++ b/drivers/mmc/host/davinci_mmc.c @@ -496,7 +496,7 @@ static int mmc_davinci_start_dma_transfer(struct mmc_davinci_host *host, return ret; }
-static void __init_or_module +static void davinci_release_dma_channels(struct mmc_davinci_host *host) { if (!host->use_dma) @@ -1361,7 +1361,7 @@ static int __init davinci_mmcsd_probe(struct platform_device *pdev) return ret; }
-static int __exit davinci_mmcsd_remove(struct platform_device *pdev) +static int davinci_mmcsd_remove(struct platform_device *pdev) { struct mmc_davinci_host *host = platform_get_drvdata(pdev);
@@ -1414,7 +1414,7 @@ static struct platform_driver davinci_mmcsd_driver = { .pm = davinci_mmcsd_pm_ops, .of_match_table = davinci_mmc_dt_ids, }, - .remove = __exit_p(davinci_mmcsd_remove), + .remove = davinci_mmcsd_remove, .id_table = davinci_mmc_devtype, };
This is a very old patch and I don't remember why I never submitted it or marked it as [WRONG], and I don't see why it only now showed up in kernelci.
defconfig+CONFIG_KASAN=y (x86) — PASS, 0 errors, 5 warnings, 0 section mismatches
Warnings: drivers/tty/vt/keyboard.c:1471:1: warning: the frame size of 2344 bytes is larger than 2048 bytes [-Wframe-larger-than=] net/wireless/nl80211.c:1409:1: warning: the frame size of 2232 bytes is larger than 2048 bytes [-Wframe-larger-than=] net/wireless/nl80211.c:4469:1: warning: the frame size of 2224 bytes is larger than 2048 bytes [-Wframe-larger-than=] net/wireless/nl80211.c:5772:1: warning: the frame size of 2064 bytes is larger than 2048 bytes [-Wframe-larger-than=] net/wireless/nl80211.c:1898:1: warning: the frame size of 3784 bytes is larger than 2048 bytes [-Wframe-larger-than=]
I still have this on my radar, didn't get it done for 4.11 though.
ip27_defconfig (mips) — PASS, 0 errors, 1 warning, 0 section mismatches
Warnings: arch/mips/include/asm/uaccess.h:138:21: warning: passing argument 1 of '__access_ok' makes pointer from integer without a cast [-Wint-conversion]
I'd argue that the driver is at fault here, but the code has been unchanged since it was merged in 2009.
The warning was introduced by Al Viro's f0a955f4eeec ("mips: sanitize __access_ok()")
which enforces that callers of access_ok() must pass a pointer rather than an "unsigned long". I could not find any other code that passes anything other than a __user pointer into access_ok(), so it's probably best to just fix the driver, but there may be others that I missed.
If we want to be sure that all callers of access_ok() use proper pointers, this patch could help:
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h index 68766b276d9e..82ffd44b2908 100644 --- a/arch/x86/include/asm/uaccess.h +++ b/arch/x86/include/asm/uaccess.h @@ -38,8 +38,9 @@ * Test whether a block of memory is a valid user space address. * Returns 0 if the range is valid, nonzero otherwise. */ -static inline bool __chk_range_not_ok(unsigned long addr, unsigned long size, unsigned long limit) +static inline bool __chk_range_not_ok(void __user *uptr, unsigned long size, unsigned long limit) { + unsigned long addr = (unsigned long __force)uptr; /* * If we have used "sizeof()" for the size, * we know it won't overflow the limit (but @@ -60,7 +61,7 @@ static inline bool __chk_range_not_ok(unsigned long addr, unsigned long size, un #define __range_not_ok(addr, size, limit) \ ({ \ __chk_user_ptr(addr); \ - __chk_range_not_ok((unsigned long __force)(addr), size, limit); \ + __chk_range_not_ok(addr, size, limit); \ })
#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
I'll add this to my randconfig test tree.
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y (arm) — FAIL, 1 error, 0 warnings, 0 section mismatches
Errors: arch/arm/kernel/hyp-stub.S:128: Error: invalid immediate for address calculation (value = 0x00000004)
I have not seen this one so far, need to investigate more. A quick look points to this line
adr r7, __hyp_stub_vectors
and the symbol it refers to was recently changed in
commit bc845e4fbbbbe97bab3f1bcf688be0b5da420717 Author: Marc Zyngier marc.zyngier@arm.com Date: Mon Apr 3 19:37:53 2017 +0100
ARM: KVM: Implement HVC_RESET_VECTORS stub hypercall in the init code
In order to restore HYP mode to its original condition, KVM currently implements __kvm_hyp_reset(). As we're moving towards a hyp-stub defined API, it becomes necessary to implement HVC_RESET_VECTORS.
This patch adds the HVC_RESET_VECTORS hypercall to the KVM init code, which so far lacked any form of hypercall support.
Tested-by: Keerthy j-keerthy@ti.com Acked-by: Russell King rmk+kernel@armlinux.org.uk Acked-by: Catalin Marinas catalin.marinas@arm.com Signed-off-by: Marc Zyngier marc.zyngier@arm.com Signed-off-by: Christoffer Dall cdall@linaro.org
diff --git a/arch/arm/kernel/hyp-stub.S b/arch/arm/kernel/hyp-stub.S index e637854335aa..675c50f5cb5c 100644 --- a/arch/arm/kernel/hyp-stub.S +++ b/arch/arm/kernel/hyp-stub.S @@ -280,7 +280,7 @@ ENDPROC(__hyp_reset_vectors) #endif
.align 5 -__hyp_stub_vectors: +ENTRY(__hyp_stub_vectors) __hyp_stub_reset: W(b) . __hyp_stub_und: W(b) . __hyp_stub_svc: W(b) .
but I don't see why that would cause the build error.
Arnd