On Wed, 21 Sep 2016, Matt Fleming wrote:
> On Wed, 21 Sep, at 05:58:27PM, Petr Mladek wrote:
> >
> > I am not sure how the above call chain is realistic. But adding
> > WARN_ON() into the scheduler paths is risky in general.
>
> It's not clear to me why this should be the case. WARN_ON() calls have
> existed in the scheduler paths since forever.
Everything which end up in printk within a rq->lock held section has been
have been prone to deadlocks for a very long time. Guess why
printk_deferred (the former printk_sched) exists.
Thanks,
tglx
