mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Aiqun(Maria) Yu" <quic_aiquny@quicinc.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Valentin Schneider <vschneid@redhat.com>,
	Ingo Molnar <mingo@kernel.org>, <linux-kernel@vger.kernel.org>,
	<kernel@quicinc.com>
Subject: Re: [PATCH] sched: Use printk_deferred_once() instead of WARN_ONCE()
Date: Tue, 14 Jan 2025 18:01:27 +0800	[thread overview]
Message-ID: <503bc4c9-a022-4802-bad8-c8fb82f01dc3@quicinc.com> (raw)
In-Reply-To: <20250113131654.GB8385@noisy.programming.kicks-ass.net>

On 1/13/2025 9:16 PM, Peter Zijlstra wrote:
> On Mon, Jan 13, 2025 at 02:12:43PM +0100, Peter Zijlstra wrote:
>> On Fri, Dec 27, 2024 at 05:27:10PM +0800, Maria Yu wrote:
>>> A deadlock is observed when WARN_ONCE() uses printk() inside the scheduler
>>> logic. printk_deferred_once() is a WARN_ONCE() similar special printk
>>> facility for the scheduler to avoid unnecessary deadlocks.
>>
>> No, problem is with printk. Using delayed will make it so that you'll
>> never see the output if it dies.

printk_deferred() only defers the console print, while it still ensures
that the log buffer is logged immediately and correctly.

There may be a side effect of showing fewer logs in a corner case if the
kernel crashes before the first console_unlock is called. However,
printk_deferred() will have the entire sched warn log in the printk log
buffer, and the log buffer content is a common method to check the crash
root cause. Therefore, in my opinion, in scenarios where the
console-enabled printk is likely to crash, printk_deferred() will be
more useful since the entire log information can be captured in the log
buffer.

>>
>> Only use delayed for printk()s that are expected and non fatal.
> 
> Also, if you trip WARN in scheduler, correct thing to do is fix WARN,
> not make WARN run 'better'. No WARN, no problem.

I agree that the real issue caused SCHED_WARN_ON() should be addressed.
The actual sched logic problem is also being handled separately.

However, it is still useful to use the correct method to print the
information needed for debugging. Therefore, this patch aims to fix the
debug method of SCHED_WARN_ON(). We've encountered various crash issues
that exhibited the similar deadlock problem, but with different
SCHED_WARN_ON() actually.

Anyway, we don't want SCHED_WARN_ON() to sometimes be a warning in the
log and other times cause a BUG_ON() behavior that crashes the device.

-- 
Thx and BRs,
Aiqun(Maria) Yu

      reply	other threads:[~2025-01-14 10:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-27  9:27 Maria Yu
2025-01-13 13:12 ` Peter Zijlstra
2025-01-13 13:16   ` Peter Zijlstra
2025-01-14 10:01     ` Aiqun(Maria) Yu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=503bc4c9-a022-4802-bad8-c8fb82f01dc3@quicinc.com \
    --to=quic_aiquny@quicinc.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=kernel@quicinc.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®