public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Tejun Heo <tj@kernel.org>, Pawel Moll <Pawel.Moll@arm.com>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>
Subject: Re: [PATCH v2] bitmap: remove explicit newline handling using scnprintf format string
Date: Thu, 30 Apr 2015 09:23:06 +0100	[thread overview]
Message-ID: <5541E66A.4010709@arm.com> (raw)
In-Reply-To: <20150429154837.d9bb4415f05418496da22b19@linux-foundation.org>



On 29/04/15 23:48, Andrew Morton wrote:
> On Tue, 28 Apr 2015 16:36:41 +0100 Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>> bitmap_print_to_pagebuf uses scnprintf to copy the cpumask/list to page
>> buffer. It handles the newline and trailing null character explicitly.
>
> bitmap_print_to_pagebuf() is horrid :(  That automagic "assume caller
> passed us an offset into a PAGE_SIZE area".
>

Agreed.

>> It's unnecessary and also partially duplicated as scnprintf already adds
>> trailing null character. The newline can be passed through format string
>> to scnprintf. This patch does that simplification.
>>
>> However theoritically there's one behavior difference: when the buffer
>> is too small, the original code would still output '\n' at the end while
>> the new code(with this patch) would just continue to print the formatted
>> string. Since this function is dealing with only page buffers, it's
>> highly unlikely to hit that corner case.
>>
>> This patch will help in auditing the users of bitmap_print_to_pagebuf
>> to verify that the buffer passed is large enough and get rid of it
>> completely by replacing them with direct scnprintf()
>
> Yes, bitmap_print_to_pagebuf() should be eliminated.  Make the callers
> keep track of how much room they have in their buffer.
>

Yes that's what Tejun also mentioned in earlier mail. This patch is just
to audit all the callers and check if something breaks before we
replace this with scnprintf() at the call sites.

>> --- a/lib/bitmap.c
>> +++ b/lib/bitmap.c
>> @@ -462,19 +462,18 @@ EXPORT_SYMBOL(bitmap_parse_user);
>>    * Output format is a comma-separated list of decimal numbers and
>>    * ranges if list is specified or hex digits grouped into comma-separated
>>    * sets of 8 digits/set. Returns the number of characters written to buf.
>> + * It is assumed that the buffer passed is atleast PAGE_SIZE and easily
>> + * accommodate nmaskbits.
>
> Well kind-of.
>
> How does this look?
>

Looks good to me.

Regards,
Sudeep

> --- a/lib/bitmap.c~bitmap-remove-explicit-newline-handling-using-scnprintf-format-string-fix
> +++ a/lib/bitmap.c
> @@ -462,8 +462,10 @@ EXPORT_SYMBOL(bitmap_parse_user);
>    * Output format is a comma-separated list of decimal numbers and
>    * ranges if list is specified or hex digits grouped into comma-separated
>    * sets of 8 digits/set. Returns the number of characters written to buf.
> - * It is assumed that the buffer passed is atleast PAGE_SIZE and easily
> - * accommodate nmaskbits.
> + *
> + * It is assumed that @buf is a pointer into a PAGE_SIZE area and that
> + * sufficient storage remains at @buf to accommodate the
> + * bitmap_print_to_pagebuf() output.
>    */
>   int bitmap_print_to_pagebuf(bool list, char *buf, const unsigned long *maskp,
>   			    int nmaskbits)
>

      reply	other threads:[~2015-04-30  8:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-27  9:46 [PATCH] bitmap: remove explicit newline handling using scnprintf format string Sudeep Holla
2015-04-27 16:14 ` Tejun Heo
2015-04-27 16:26   ` Sudeep Holla
2015-04-27 16:30     ` Tejun Heo
2015-04-27 16:39       ` Sudeep Holla
2015-04-27 16:40         ` Tejun Heo
2015-04-28 15:36 ` [PATCH v2] " Sudeep Holla
2015-04-29 22:48   ` Andrew Morton
2015-04-30  8:23     ` Sudeep Holla [this message]

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=5541E66A.4010709@arm.com \
    --to=sudeep.holla@arm.com \
    --cc=Pawel.Moll@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=tj@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox