From: John Ogness <john.ogness@linutronix.de>
To: paulmck@kernel.org
Cc: rcu@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-team@fb.com, rostedt@goodmis.org
Subject: Re: [PATCH rcu 11/12] torture: Flush printk() buffers before powering off
Date: Tue, 21 Jun 2022 22:58:27 +0206 [thread overview]
Message-ID: <87ilotagdw.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <20220621181335.GJ1790663@paulmck-ThinkPad-P17-Gen-1>
On 2022-06-21, "Paul E. McKenney" <paulmck@kernel.org> wrote:
> The patch below will cause rcutorture to implicitly test this
> functionality, unless told otherwise, for example, by using the
> --bootargs "torture.printk_shutdown_bug_workaround" kvm.sh
> argument.
>
> Thoughts?
I feel like this is dirtying the torture.* bootarg namespace a
bit. Also, I am not sure how useful it is as a dynamic option. I assume
that users would generally avoid using it, so its very existence might
just be more noise in the documentation and code. It is an unusual
feature:
"In case some bug shows up, here is a flag to avoid it."
I personally would just drop the patch and rely on a correctly
functional kernel. But I am also not an rcutorture user. If _you_ think
that such a flag is useful, feel free to include the patch.
> commit 204bf1e2a5a2fb68c15b4b64793ad0896db6f705
> Author: Paul E. McKenney <paulmck@kernel.org>
> Date: Tue Jun 21 11:02:25 2022 -0700
>
> torture: Optionally flush printk() buffers before powering off
>
> The rcutorture test suite produces quite a bit of console output at
> the end of a test. This means that the new-in-2022 printk() kthreads
> are likely to be in the process of flushing output at the time of the
> torture_shutdown() function's call to kernel_power_off(). Normally,
> rcutorture relies on printk() to flush any pending output upon shutdown,
> the better to detect bugs in this area, for example, the one introduced
> by 8e274732115f ("printk: extend console_lock for per-console locking").
> However, once such a bug is detected and reported, it is necessary to
> test the rest of the system, without noise from the already-reported bug.
>
> This commit therefore adds a torture.printk_shutdown_bug_workaround
> kernel parameter, which causes torture_shutdown() to invoke pr_flush(),
> and print an informative message on the console, immediately before
> invoking kernel_power_off(). When this kernel parameter is not specified,
> it is up to printk() to flush its own buffers.
>
> Suggested-by: John Ogness <john.ogness@linutronix.de>
> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Reviewed-by: John Ogness <john.ogness@linutronix.de>
next prev parent reply other threads:[~2022-06-21 21:05 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-20 22:58 [PATCH rcu 0/12] Torture-test updates for v5.20 Paul E. McKenney
2022-06-20 22:58 ` [PATCH rcu 01/12] torture: Make kvm-remote.sh announce which system is being waited on Paul E. McKenney
2022-06-20 22:58 ` [PATCH rcu 02/12] rcu/torture: Change order of warning and trace dump Paul E. McKenney
2022-06-20 22:58 ` [PATCH rcu 03/12] rcutorture: Simplify rcu_torture_read_exit_child() loop Paul E. McKenney
2022-06-20 22:58 ` [PATCH rcu 04/12] rcutorture: Fix memory leak in rcu_test_debug_objects() Paul E. McKenney
2022-06-20 22:58 ` [PATCH rcu 05/12] torture: Adjust to again produce debugging information Paul E. McKenney
2022-06-20 22:58 ` [PATCH rcu 06/12] rcutorture: Make failure indication note reader-batch overflow Paul E. McKenney
2022-06-20 22:58 ` [PATCH rcu 07/12] rcu/rcuscale: Fix smp_processor_id()-in-preemptible warnings Paul E. McKenney
2022-06-20 22:58 ` [PATCH rcu 08/12] torture: Create kvm-check-branches.sh output in proper location Paul E. McKenney
2022-06-20 22:58 ` [PATCH rcu 09/12] rcutorture: Fix ksoftirqd boosting timing and iteration Paul E. McKenney
2022-06-20 22:58 ` [PATCH rcu 10/12] rcutorture: Handle failure of memory allocation functions Paul E. McKenney
2022-06-20 22:58 ` [PATCH rcu 11/12] torture: Flush printk() buffers before powering off Paul E. McKenney
2022-06-20 23:23 ` John Ogness
2022-06-20 23:28 ` Paul E. McKenney
2022-06-21 8:09 ` John Ogness
2022-06-21 18:13 ` Paul E. McKenney
2022-06-21 20:52 ` John Ogness [this message]
2022-06-21 21:01 ` Paul E. McKenney
2022-06-20 22:58 ` [PATCH rcu 12/12] refscale: Convert test_lock spinlock to raw_spinlock Paul E. McKenney
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=87ilotagdw.fsf@jogness.linutronix.de \
--to=john.ogness@linutronix.de \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
/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