Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 28 Sep 2020 10:06:13 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     Joe Perches <joe@perches.com>
Cc:     Chengming Zhou <zhouchengming@bytedance.com>,
        linux-kernel@vger.kernel.org, pmladek@suse.com,
        sergey.senozhatsky@gmail.com, rostedt@goodmis.org,
        mingo@redhat.com, juri.lelli@redhat.com,
        vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
        bsegall@google.com, mgorman@suse.de, songmuchun@bytedance.com
Subject: Re: [PATCH 2/2] sched: mark PRINTK_DEFERRED_CONTEXT_MASK in
 __schedule()
Message-ID: <20200928080613.GB2651@hirez.programming.kicks-ass.net>
References: <20200927161130.33172-1-zhouchengming@bytedance.com>
 <20200927161130.33172-2-zhouchengming@bytedance.com>
 <20200928073202.GA2611@hirez.programming.kicks-ass.net>
 <0e8e87e25c90339fe790252626855cbb47bc2c08.camel@perches.com>
 <20200928080022.GD2611@hirez.programming.kicks-ass.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200928080022.GD2611@hirez.programming.kicks-ass.net>
Precedence: bulk

On Mon, Sep 28, 2020 at 10:00:22AM +0200, Peter Zijlstra wrote:
> On Mon, Sep 28, 2020 at 12:52:44AM -0700, Joe Perches wrote:
> > On Mon, 2020-09-28 at 09:32 +0200, Peter Zijlstra wrote:
> > > On Mon, Sep 28, 2020 at 12:11:30AM +0800, Chengming Zhou wrote:
> > > > The WARN_ON/WARN_ON_ONCE with rq lock held in __schedule() should be
> > > > deferred by marking the PRINTK_DEFERRED_CONTEXT_MASK, or will cause
> > > > deadlock on rq lock in the printk path.
> > []
> > > NAK printk_deferred is an abomination, kill that.
> > 
> > Didn't you introduce it?
> > Should you be complaining to yourself?
> 
> Yeah. I should've hacked around it then I suppose. Still, no reason to
> proliferate that crap. Afaik the new printk should be able to deal with
> this at some point.
> 
> The thing we're not going to do it add a cache-miss to schedule just
> because.

Also, using deferred for WARN/BUG is fundamentally wrong, you want that
splat _NOW_, there might not be a later.