[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170928120532.cjidduvjj5xygaid@hirez.programming.kicks-ass.net>
Date: Thu, 28 Sep 2017 14:05:32 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: "Levin, Alexander (Sasha Levin)" <alexander.levin@...izon.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
Sasha Levin <levinsasha928@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...e.hu>,
"linux-kernel@...r.kernel.org List" <linux-kernel@...r.kernel.org>,
"pmladek@...e.com" <pmladek@...e.com>,
"sergey.senozhatsky@...il.com" <sergey.senozhatsky@...il.com>,
"rostedt@...dmis.org" <rostedt@...dmis.org>
Subject: Re: sched: serial port lockdep warning when offlining CPUs
(please linewrap normal text at 72 chars)
On Thu, Sep 28, 2017 at 11:45:30AM +0000, Levin, Alexander (Sasha Levin) wrote:
> Okay, that seems to have delt with the callbacks supressed issue.
>
> I also seem to be hitting it as a result of the scheduler triggering a
> WARN, where print_stack_trace(), for example, just uses printk().
>
> Now I'm not sure what's your approach here, do we keep converting
> printk to printk_deferred one by one until we whacked every mole?
Nah.. WARN's _should_ not trigger. If they do we fix that.
Getting a lockdep splat after a WARN is something I can live with.
And you really don't want that deferred nonsense for WARNs, because that
means you'll risk not over getting the output.
Powered by blists - more mailing lists