linux-kernel - Re: [Suggestion] kernel/rcutorture.c: about using scnprintf() instead of sprintf().

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, 15 Oct 2013 17:03:16 +0800
From:	Chen Gang <gang.chen@...anux.com>
To:	paulmck@...ux.vnet.ibm.com
CC:	josh@...edesktop.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [Suggestion] kernel/rcutorture.c: about using scnprintf() instead
 of sprintf().

On 10/15/2013 04:31 PM, Paul E. McKenney wrote:
> On Tue, Oct 15, 2013 at 09:40:40AM +0800, Chen Gang wrote:
>> > Hmm... Can it really work on 1024 CPUs? sorry I don't know. But in fact,
>> > that is not about this patch (it is just one of case which may cause
>> > issues).
>> > 
>> > This patch is only about "use truncation instead of memory overflow, and
>> > make sure the modification without negative effect". So in my opinion,
>> > current test case is enough for this requirement.
> Yes, the patch is about "use truncation instead of memory overflow",
> but the truncation would also be a problem on large systems.  Is it
> possible to prevent memory from overflow in the first place?
> 

Yes of cause it can, but in my opinion, for a test module, truncating
information is acceptable, but memory overflow is not acceptable.

In fact, every information truncation case, can be "prevented memory
from overflow in the first place".  It depends on whether we have enough
interest to do that.


>> > We have to face the efficiency: it is only a test module, if the tester
>> > (assume he/she is a programmer, too) notices about the truncation, they
>> > can simply extend the maximize length to avoid truncation.
> True.  But you can make a change that is just as simple that allows you
> to test what would happen on a 1024-CPU system even though your own
> system has only 2 CPUs.  Can you see what that change is?

In fact, from modifying code, we can virtual most of cases, if current
test case is enough, we need not do that (leave it for guys who have
real 1024-CPUs).


Thanks.
-- 
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/