All of lore.kernel.org
 help / color / mirror / Atom feed
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>

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.