linux-kernel - Re: [patch V2 00/17] init: Enable might_sleep() and smp_processor

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: <20170517105807.GF14654@leverpostej>
Date:   Wed, 17 May 2017 11:58:08 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [patch V2 00/17] init: Enable might_sleep() and
 smp_processor_id() debugging early

Hi,

On Tue, May 16, 2017 at 08:42:31PM +0200, Thomas Gleixner wrote:
> We recentlty discovered a call path which takes a mutex from the low level
> secondary CPU bringup code and wondered why this was not caught by
> might_sleep().
> 
> The reason is that both debug facilities depend on system_state ==
> SYSTEM_RUNNING, which is set after init memory is freed.
> 
> That means that SMP bootup and builtin driver initialization are not
> covered by these checks at all.
> 
> The patch series addresses this by adding an intermediate state which
> enables both debug features right when scheduling starts, i.e. the boot CPU
> idle task schedules the first time.

Thanks again for attacking this.

I gave this a spin atop of v4.12-rc1 on an ARM Juno platform. It picks
up the mutex issue, and I see no other new warnings. With a fix [1] for
the mutex issue appplied, I see no warnings.

Feel free to add my Tested-by for the arm64 and common bits.

Thanks,
Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-May/506558.html