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
