linux-kernel - Re: [PATCH linux-next] RFC: torture: add pr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 14 Jun 2022 22:15:21 -0700
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     zhouzhouyi@...il.com
Cc:     john.ogness@...utronix.de, pmladek@...e.com, dave@...olabs.net,
        josh@...htriplett.org, linux-kernel@...r.kernel.org,
        rcu@...r.kernel.org
Subject: Re: [PATCH linux-next] RFC: torture: add pr_flush to flush the
 results to console

On Wed, Jun 15, 2022 at 08:37:33AM +0800, zhouzhouyi@...il.com wrote:
> From: Zhouyi Zhou <zhouzhouyi@...il.com>
> 
> currently tools/testing/selftests/rcutorture/bin/torture.sh reports
> false positve because of kthread printing.
> 
> Commit "printk: add functions to prefer direct printing" (2bb2b7b57f812)
> have added functions to prefer direct printing activated for the primary
> import messages.
> 
> Meanwhile adding printk_prefer_direct_enter/exit to
> torture_cleanup_begin/end still can't eliminate the false positives
> for a hundred percent.
> 
> This patch add pr_flush to torture_cleanup_end because the latter
> is sleepable.
> 
> Reported-by: Zhouyi Zhou <zhouzhouyi@...il.com>
> Signed-off-by: Zhouyi Zhou <zhouzhouyi@...il.com>
> Tested-by: Zhouyi Zhou <zhouzhouyi@...il.com> 

Just the one Signed-off-by suffices.  ;-)

> ---
>  kernel/torture.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/kernel/torture.c b/kernel/torture.c
> index 789aeb0e1159..b51e42463a67 100644
> --- a/kernel/torture.c
> +++ b/kernel/torture.c
> @@ -878,6 +878,7 @@ void torture_cleanup_end(void)
>  	mutex_lock(&fullstop_mutex);
>  	torture_type = NULL;
>  	mutex_unlock(&fullstop_mutex);
> +	pr_flush(1000, true);

But in this case, the kernel keeps on running, correct?  So won't the
output appear over time?  All of printk()'s kthreads are still running
after all.

Or do you have a use case that requires that the output appear sooner
than it does?  If so, please let me know what that is.

							Thanx, Paul

>  }
>  EXPORT_SYMBOL_GPL(torture_cleanup_end);
>  
> -- 
> 2.25.1
>