All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chen Gang <gang.chen@asianux.com>
To: paulmck@linux.vnet.ibm.com
Cc: josh@freedesktop.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] kernel/rcutorture.c: use scnprintf() instead of sprintf()
Date: Tue, 15 Oct 2013 20:32:41 +0800	[thread overview]
Message-ID: <525D35E9.3000604@asianux.com> (raw)
In-Reply-To: <20131015082613.GG5790@linux.vnet.ibm.com>

On 10/15/2013 04:26 PM, Paul E. McKenney wrote:
> On Tue, Oct 15, 2013 at 09:51:42AM +0800, Chen Gang wrote:
>>> One simple way: using snprintf() instead of scnprintf() in the related
>>> printing functions. Then call them with "buffer == NULL" to get buffer
>>> size, next allocate it and call it again ...
>>
>> Oh, this simple way assumes the printing contents will not be changed
>> during the 2 calls.
> 
> Indeed.  But can you make use of nr_cpu_ids, which is set at boot time
> to the the maximum number of CPUs that the particular booting system
> will ever be able to contain?  Keep in mind that you know the maximum
> number of digits that an unsigned long will print in 32-bit and 64-bit
> systems.
> 

Yeah, that is a way for it. It seems you (related maintainer) like
additional fix for it.

Hmm... I will try within this week (although I don't think it is quite
necessary to me).

:-)

>>> Hmm... it is only a test module, is it worth enough to try to make it
>>> avoid truncation? If some members (quite few members) find truncation,
>>> they can simply extend maximize buffer to avoid it when testing.
>>>
>>> But if we do not fix this bug, when memory overflow, the OS may not stop
>>> immediately, then it will/may lead the testers to face various amazing
>>> things (which is not quite easy to find root cause).
> 
> It might cause strange symptoms, but it is not bad practice to try
> it anyway, especially when the code is unfamiliar.  After all, if the
> strange systems appear on memory overflow, but do not appear if there
> is no memory overflow, you have a pretty good idea what the cause .
> Besides, there might be some other mechanism to prevent the problem.
> Of course, there is no such mechanism in this particular case, but in
> general it is more efficient to find that out quickly then to spend time
> designing a solution that is not needed.

Excuse me, my English is not quite well, I am not quite understand your
meaning.

I guess your meaning is: "after find a simple/acceptable solution, we
can think of more, it may be more efficient".

If what I guess is correct, It is OK to me -- since at least, it is not
an 'urgent' thing (for 'important' thing, your idea is more efficient,
although for 'urgent' thing, it is not).


Thanks.
-- 
Chen Gang

  reply	other threads:[~2013-10-15 12:33 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-08  8:32 [Suggestion] kernel/rcutorture.c: about using scnprintf() instead of sprintf() Chen Gang
2013-10-13 11:05 ` Paul E. McKenney
2013-10-14  1:41   ` Chen Gang
2013-10-14  2:22     ` Chen Gang
2013-10-14 11:24       ` Paul E. McKenney
2013-10-15  1:40         ` Chen Gang
2013-10-15  8:31           ` Paul E. McKenney
2013-10-15  9:03             ` Chen Gang
2013-10-14  8:38   ` [PATCH] kernel/rcutorture.c: use " Chen Gang
2013-10-14 11:28     ` Paul E. McKenney
2013-10-15  0:54       ` Chen Gang
2013-10-15  1:51         ` Chen Gang
2013-10-15  8:26           ` Paul E. McKenney
2013-10-15 12:32             ` Chen Gang [this message]
2013-10-15 14:47               ` Paul E. McKenney
2013-10-16  2:07                 ` Chen Gang
2013-10-17  1:06                   ` Chen Gang
2013-10-21  5:51                     ` [PATCH] kernel/rcutorture.c: be sure of enough memory for result printing Chen Gang
2013-10-21  6:18                       ` Chen Gang
2013-10-21  9:35                         ` Chen Gang
2013-10-27 14:43                           ` Chen Gang
2013-11-04  9:42                             ` Chen Gang
2013-11-06 20:38                       ` Paul E. McKenney
2013-11-07  2:30                         ` [PATCH v2] " Chen Gang
2013-11-07 20:59                           ` Paul E. McKenney
2013-11-08  0:58                             ` Chen Gang

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=525D35E9.3000604@asianux.com \
    --to=gang.chen@asianux.com \
    --cc=josh@freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    /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.