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:   Sat, 22 Aug 2020 19:49:28 -0400
From:   Steven Rostedt <rostedt@goodmis.org>
To:     peterz@infradead.org
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        Joerg Vehlow <lkml@jv-coder.de>,
        Thomas Gleixner <tglx@linutronix.de>,
        Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
        Huang Ying <ying.huang@intel.com>,
        linux-kernel@vger.kernel.org,
        Joerg Vehlow <joerg.vehlow@aox-tech.de>, dave@stgolabs.net
Subject: Re: [BUG RT] dump-capture kernel not executed for panic in
 interrupt context
Message-ID: <20200822194928.54ee4cb5@oasis.local.home>
In-Reply-To: <20200822123252.GQ1362448@hirez.programming.kicks-ass.net>
References: <2c243f59-6d10-7abb-bab4-e7b1796cd54f@jv-coder.de>
        <20200528084614.0c949e8d@gandalf.local.home>
        <cbbf7926-148e-7acb-dc03-3f055d73364b@jv-coder.de>
        <20200727163655.8c94c8e245637b62311f5053@linux-foundation.org>
        <c6b095af-fc92-420f-303f-d2efd9f28873@jv-coder.de>
        <20200821110848.6c3183d1@oasis.local.home>
        <20200821134753.9547695c9b782275be3c95b5@linux-foundation.org>
        <20200821170334.73b52fdd@oasis.local.home>
        <20200822123252.GQ1362448@hirez.programming.kicks-ass.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sat, 22 Aug 2020 14:32:52 +0200
peterz@infradead.org wrote:

> On Fri, Aug 21, 2020 at 05:03:34PM -0400, Steven Rostedt wrote:
> 
> > > Sigh.  Is it too hard to make mutex_trylock() usable from interrupt
> > > context?  
> > 
> > 
> > That's a question for Thomas and Peter Z.  
> 
> You should really know that too, the TL;DR answer is it's fundamentally
> buggered, can't work.

I knew there was an issue but I couldn't remember the reasoning, and
figured you could easily answer it without having to look back at the
code.

> 
> The problem is that RT relies on being able to PI boost the mutex owner.
> 
> ISTR we had a thread about all this last year or so, let me see if I can
> find that.
> 
> Here goes:
> 
>   https://lkml.kernel.org/r/20191218135047.GS2844@hirez.programming.kicks-ass.net

From this email:

> The problem happens when that owner is the idle task, this can happen
> when the irq/softirq hits the idle task, in that case the contending
> mutex_lock() will try and PI boost the idle task, and that is a big
> no-no.

What's wrong with priority boosting the idle task? It's not obvious,
and I can't find comments in the code saying it would be bad.

I looked around the code to see if I could find "why this is bad" but
couldn't find it. There's lots of places that say "Do not use
mutex_trylock in interrupt context, the implementation is not safe to
do so" but I can't find where it says "why" it is not safe to do so.

The idle task is not mentioned at all in rtmutex.c and not mentioned in
kernel/locking except for some comments about RCU in lockdep.

I see that in the idle code the prio_change method does a BUG(), but
there's no comment to say why it does so.

The commit that added that BUG, doesn't explain why it can't happen:

a8941d7ec8167 ("sched: Simplify the idle scheduling class")

I may have once known the rationale behind all this, but it's been a
long time since I worked on the PI code, and it's out of my cache.


-- Steve