Received-SPF: pass (google.com: domain of linux-kernel+bounces-55560-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <20231220211640.2023645-1-dianders@chromium.org>
 <ZcIGKU8sxti38Kok@alley> <87ttmlan1d.fsf@jogness.linutronix.de>
In-Reply-To: <87ttmlan1d.fsf@jogness.linutronix.de>
From: Doug Anderson <dianders@chromium.org>
Date: Tue, 6 Feb 2024 11:31:24 -0800
Message-ID: <CAD=FV=UBOiuJ=e0t0UTr0P7rCf6CnpD8RmEVz3wc8pfjvRqj8Q@mail.gmail.com>
Subject: Re: [PATCH 0/4] watchdog: Better handling of concurrent lockups
To: John Ogness <john.ogness@linutronix.de>
Cc: Petr Mladek <pmladek@suse.com>, Andrew Morton <akpm@linux-foundation.org>, 
	Li Zhe <lizhe.67@bytedance.com>, Pingfan Liu <kernelfans@gmail.com>, 
	Lecopzer Chen <lecopzer.chen@mediatek.com>, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Tue, Feb 6, 2024 at 2:46=E2=80=AFAM John Ogness <john.ogness@linutronix.=
de> wrote:
>
> On 2024-02-06, Petr Mladek <pmladek@suse.com> wrote:
> > I have just got an idea how to make printk_cpu_sync_get_irqsave()
> > less error prone for deadlock on the panic() CPU. The idea is
> > to ignore the lock or give up locking after a timeout on
> > the panic CPU.
>
> This idea is out of scope for this series. But it is something we should
> think about. The issue has always been a possible problem in panic().

One thing to be at least a little cognizant of is how this interacts
with the 10 second timeout in nmi_trigger_cpumask_backtrace(), which
we can hit twice in some of the lockup reports since we first trace
the locked CPU and then the rest. Ideally we don't hit that timeout
lots, except that on arm64 if you don't have pseudo-NMI turned on then
it's actually pretty easy to hit the timeout when you've got a
hard-locked CPU. Probably that 10 second timeout should be
shortened...

-Doug