linux-kernel - Re: [PATCH 2/2] refscale: prevent buffer to 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]

Message-ID: <20211022231555.GG880162@paulmck-ThinkPad-P17-Gen-1>
Date:   Fri, 22 Oct 2021 16:15:55 -0700
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Li Zhijian <lizhijian@...fujitsu.com>
Cc:     dave@...olabs.net, josh@...htriplett.org, rostedt@...dmis.org,
        mathieu.desnoyers@...icios.com, jiangshanlai@...il.com,
        joel@...lfernandes.org, rcu@...r.kernel.org,
        linux-kernel@...r.kernel.org, Philip Li <philip.li@...el.com>,
        kernel test robot <lkp@...el.com>
Subject: Re: [PATCH 2/2] refscale: prevent buffer to pr_alert() being too long

On Fri, Oct 22, 2021 at 06:51:11PM +0800, Li Zhijian wrote:
> 0Day/LKP observed that the refscale results become incompleted
> when a larger nruns(such as 300) is specified.
> It seems that printk() can accept < 1024 buffer at once.
> Print the buffer if its length exceeds 800 simply.
> 
> CC: Philip Li <philip.li@...el.com>
> Reported-by: kernel test robot <lkp@...el.com>
> Signed-off-by: Li Zhijian <lizhijian@...fujitsu.com>

Good catch!  A couple of questions below.

						Thanx, Paul

> ---
>  kernel/rcu/refscale.c | 23 +++++++++++++----------
>  1 file changed, 13 insertions(+), 10 deletions(-)
> 
> diff --git a/kernel/rcu/refscale.c b/kernel/rcu/refscale.c
> index 2cbe2a2ba387..b1b9052010fd 100644
> --- a/kernel/rcu/refscale.c
> +++ b/kernel/rcu/refscale.c
> @@ -604,7 +604,7 @@ static u64 process_durations(int n)
>  	char *buf;
>  	u64 sum = 0;
>  
> -	buf = kmalloc(128 + nreaders * 32, GFP_KERNEL);
> +	buf = kmalloc(64 * 20, GFP_KERNEL);

This allocation (and the one below) is 1280 bytes rather than
1024 bytes.  Why the extra couple hundred bytes?

>  	if (!buf)
>  		return 0;
>  	buf[0] = 0;
> @@ -617,13 +617,15 @@ static u64 process_durations(int n)
>  
>  		if (i % 5 == 0)
>  			strcat(buf, "\n");
> +		if (strlen(buf) > 800) {
> +			pr_alert("%s", buf);

Does the tools/testing/selftests/rcutorture/bin/kvm-recheck-refscale.sh
script also require changes to handle the partial lines?

Same for the later comparison against 800.

> +			buf[0] = 0;
> +		}
>  		strcat(buf, buf1);
>  
>  		sum += rt->last_duration_ns;
>  	}
> -	strcat(buf, "\n");
> -
> -	SCALEOUT("%s\n", buf);
> +	pr_alert("%s\n", buf);
>  
>  	kfree(buf);
>  	return sum;
> @@ -648,7 +650,7 @@ static int main_func(void *arg)
>  
>  	VERBOSE_SCALEOUT("main_func task started");
>  	result_avg = kzalloc(nruns * sizeof(*result_avg), GFP_KERNEL);
> -	buf = kzalloc(64 + nruns * 32, GFP_KERNEL);
> +	buf = kzalloc(64 * 20, GFP_KERNEL);
>  	if (!result_avg || !buf) {
>  		VERBOSE_SCALEOUT_ERRSTRING("out of memory");
>  		errexit = true;
> @@ -701,10 +703,7 @@ static int main_func(void *arg)
>  	if (errexit)
>  		goto err;
>  
> -	buf[0] = 0;
> -	strcat(buf, "\n");
> -	strcat(buf, "Runs\tTime(ns)\n");
> -
> +	pr_alert("Runs\tTime(ns)\n");
>  	for (exp = 0; exp < nruns; exp++) {
>  		u64 avg;
>  		u32 rem;
> @@ -712,9 +711,13 @@ static int main_func(void *arg)
>  		avg = div_u64_rem(result_avg[exp], 1000, &rem);
>  		sprintf(buf1, "%d\t%llu.%03u\n", exp + 1, avg, rem);
>  		strcat(buf, buf1);
> +		if (strlen(buf) > 800) {
> +			pr_alert("%s", buf);
> +			buf[0] = 0;
> +		}
>  	}
>  
> -	SCALEOUT("%s", buf);
> +	pr_alert("%s", buf);
>  
>  err:
>  	// This will shutdown everything including us.
> -- 
> 2.33.0
> 
> 
>