Hi,

On 25 August 2015 at 05:55, kernelci.org bot <bot@kernelci.org> wrote:

next boot: 179 boots: 37 failed, 136 passed with 4 offline, 2 conflicts (next-20150825)

Full Boot Summary: http://kernelci.org/boot/all/job/next/kernel/next-20150825/

Full Build Summary: http://kernelci.org/build/next/kernel/next-20150825/

Tree: next

Branch: local/master

Git Describe: next-20150825

Git Commit: 512450361ea46ed5a8c5d81f507fef094181ab91

Git URL: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

Tested: 56 unique boards, 15 SoC families, 22 builds out of 132

Boot Failures Detected: http://kernelci.org/boot/?next-20150825&fail

arm:

multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y:

am335x-boneblack: 1 failed lab

at91-sama5d3_xplained: 1 failed lab

exynos4412-odroidx2: 1 failed lab

exynos5250-arndale: 1 failed lab

exynos5250-snow: 1 failed lab

exynos5420-arndale-octa: 1 failed lab

exynos5422-odroidxu3: 2 failed labs

exynos5800-peach-pi: 1 failed lab

hip04-d01: 1 failed lab

imx6q-cm-fx6: 1 failed lab

imx6q-sabrelite: 1 failed lab

imx6q-wandboard: 1 failed lab

omap3-beagle-xm: 1 failed lab

omap4-panda: 1 failed lab

omap4-panda-es: 1 failed lab

qcom-apq8064-ifc6410: 1 failed lab

qcom-apq8084-ifc6540: 1 failed lab

sun7i-a20-bananapi: 1 failed lab

sun7i-a20-cubietruck: 1 failed lab

sun9i-a80-cubieboard4: 1 failed lab

sun9i-a80-optimus: 1 failed lab

tegra124-jetson-tk1: 2 failed labs

vexpress-v2p-ca15-tc1: 1 failed lab

vexpress-v2p-ca15_a7: 1 failed lab

vexpress-v2p-ca9: 1 failed lab

zynq-parallella: 1 failed lab

I bisected these CONFIG_THUMB2_KERNEL boot failures:

0db805aa8c96f0eac0cb5bc6688999212fb5f5d3 is the first bad commit
commit 0db805aa8c96f0eac0cb5bc6688999212fb5f5d3
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Wed Aug 19 20:40:41 2015 +0100

    ARM: software-based priviledged-no-access support
    
    Provide a software-based implementation of the priviledged no access
    support found in ARMv8.1.
    
    Userspace pages are mapped using a different domain number from the
    kernel and IO mappings.  If we switch the user domain to "no access"
    when we enter the kernel, we can prevent the kernel from touching
    userspace.
    
    However, the kernel needs to be able to access userspace via the
    various user accessor functions.  With the wrapping in the previous
    patch, we can temporarily enable access when the kernel needs user
    access, and re-disable it afterwards.
    
    This allows us to trap non-intended accesses to userspace, eg, caused
    by an inadvertent dereference of the LIST_POISON* values, which, with
    appropriate user mappings setup, can be made to succeed.  This in turn
    can allow use-after-free bugs to be further exploited than would
    otherwise be possible.
    
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>