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:   Sun, 24 Oct 2021 22:46:16 +0800
From:   "Li, Zhijian" <lizhijian@...fujitsu.com>
To:     <paulmck@...nel.org>
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 2021/10/23 7:15, Paul E. McKenney wrote:
> 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?

Nothing special, so let's change 1024 or (800 + 64 ),which is sufficent as well ?


>
>>   	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?

I missed that, i will take a look at it

Thanks

Zhijian


>
> 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
>>
>>
>>
>


Powered by blists - more mailing lists