linux-kernel - Re: ARM Juno r1 + CONFIG_PROVE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2bf88cd2-9c4f-11dc-4b70-f717de891cff@samsung.com>
Date:   Fri, 11 Oct 2019 15:02:42 +0200
From:   Marek Szyprowski <m.szyprowski@...sung.com>
To:     James Morse <james.morse@....com>,
        Sudeep Holla <sudeep.holla@....com>
Cc:     Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        Liviu Dudau <liviu.dudau@....com>,
        LKML <linux-kernel@...r.kernel.org>,
        Will Deacon <will@...nel.org>,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: ARM Juno r1 + CONFIG_PROVE_LOCKING=y => boot failure

Hi James,

On 11.10.2019 12:38, James Morse wrote:
> Hi guys,
>
> On 11/10/2019 11:05, Sudeep Holla wrote:
>> On Fri, Oct 11, 2019 at 11:26:04AM +0200, Marek Szyprowski wrote:
>>> Recently I've got access to ARM Juno R1 board and did some tests with
>>> current mainline kernel on it. I'm a bit surprised that enabling
>>> CONFIG_PROVE_LOCKING causes a boot failure on this board. After enabling
>>> this Kconfig option, I get no single message from the kernel, although I
>>> have earlycon enabled.
>> I don't have Juno R1 but I tried defconfig + CONFIG_PROVE_LOCKING and
>> it boots fine.
> I just tried this on my r1, v5.4-rc1 with this configuration worked just fine.
>
> My cmdline is:
> | root=/dev/sda6 loglevel=9 earlycon=pl011,0x7ff80000 hugepagesz=2M hugepages=512
> | crashkernel=1G console=ttyAMA0 resume=/dev/sda2 no_console_suspend efi=debug
>
That is a bit strange. Here is a boot log from v5.4-rc1 with pure 
defconfig: https://paste.debian.net/1105851/

The bisect lead me to the commit 
c3bc8fd637a9623f5c507bd18f9677effbddf584 ("tracing: Centralize 
preemptirq tracepoints and unify their usage"), which appeared in 
v4.19-rc1. It cannot be easily reverted, but kernel built from earlier 
versions boots fine here with PROVE_LOCKING enabled. I wonder what I do 
in a different way than You...

>>> I've did my test with default defconfig and current linux-next,
>>> v5.4-rc1, v5.3 and v4.19. In all cases the result is the same. I'm
>>> booting kernel using a precompiled uboot from Linaro release and TFTP
>>> download.
>> OK, I use UEFI+GRUB but I don't think that should cause any issue.
> ... same ... this uboot binary looks like the main difference.
> Is it using u-boots UEFI support? Is it possible to turn that off?
>
> It may that lockdep is just perturbing the size of the binary. It adds an extra 4MB for me.

The size of the kernel binary doesn't matter. I've successfully booted 
larger images, than the once compiled with PROVE_LOCKING enabled.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland