All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yury Norov <yury.norov@gmail.com>
To: Barry Song <song.bao.hua@hisilicon.com>
Cc: gregkh@linuxfoundation.org, andriy.shevchenko@linux.intel.com,
	linux-kernel@vger.kernel.org, linux@rasmusvillemoes.dk,
	rafael@kernel.org, akpm@linux-foundation.org,
	rdunlap@infradead.org, agordeev@linux.ibm.com,
	sbrivio@redhat.com, jianpeng.ma@intel.com,
	valentin.schneider@arm.com, peterz@infradead.org,
	bristot@redhat.com, guodong.xu@linaro.org,
	tangchengchang@huawei.com, prime.zeng@hisilicon.com,
	yangyicong@huawei.com, tim.c.chen@linux.intel.com,
	tiantao6@hisilicon.com, Jonathan.Cameron@huawei.com,
	linuxarm@huawei.com
Subject: Re: [PATCH v4 1/4] lib: bitmap: introduce bitmap_print_to_buf
Date: Thu, 17 Jun 2021 13:54:02 -0700	[thread overview]
Message-ID: <YMu2amhrdGZHJ5mY@yury-ThinkPad> (raw)
In-Reply-To: <20210617101910.13228-2-song.bao.hua@hisilicon.com>

On Thu, Jun 17, 2021 at 10:19:07PM +1200, Barry Song wrote:
> From: Tian Tao <tiantao6@hisilicon.com>
> 
> New API bitmap_print_to_buf() with bin_attribute to avoid maskp
> exceeding PAGE_SIZE. bitmap_print_to_pagebuf() is a special case
> of bitmap_print_to_buf(), so in bitmap_print_to_pagebuf() call
> bitmap_print_to_buf().
> 
> Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> Cc: Stefano Brivio <sbrivio@redhat.com>
> Cc: Alexander Gordeev <agordeev@linux.ibm.com>
> Cc: "Ma, Jianpeng" <jianpeng.ma@intel.com>
> Cc: Yury Norov <yury.norov@gmail.com>
> Cc: Valentin Schneider <valentin.schneider@arm.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Daniel Bristot de Oliveira <bristot@redhat.com>
> ---
>  include/linux/bitmap.h  |  2 ++
>  include/linux/cpumask.h | 21 +++++++++++++++++++++
>  lib/bitmap.c            | 37 +++++++++++++++++++++++++++++++++++--
>  3 files changed, 58 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
> index a36cfcec4e77..0de6effa2797 100644
> --- a/include/linux/bitmap.h
> +++ b/include/linux/bitmap.h
> @@ -226,6 +226,8 @@ void bitmap_copy_le(unsigned long *dst, const unsigned long *src, unsigned int n
>  unsigned int bitmap_ord_to_pos(const unsigned long *bitmap, unsigned int ord, unsigned int nbits);
>  int bitmap_print_to_pagebuf(bool list, char *buf,
>  				   const unsigned long *maskp, int nmaskbits);
> +int bitmap_print_to_buf(bool list, char *buf, const unsigned long *maskp,
> +			int nmaskbits, loff_t off, size_t count);
>  
>  #define BITMAP_FIRST_WORD_MASK(start) (~0UL << ((start) & (BITS_PER_LONG - 1)))
>  #define BITMAP_LAST_WORD_MASK(nbits) (~0UL >> (-(nbits) & (BITS_PER_LONG - 1)))
> diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
> index bfc4690de4f4..1bef69e4b950 100644
> --- a/include/linux/cpumask.h
> +++ b/include/linux/cpumask.h
> @@ -983,6 +983,27 @@ cpumap_print_to_pagebuf(bool list, char *buf, const struct cpumask *mask)
>  				      nr_cpu_ids);
>  }
>  
> +/**
> + * cpumap_print_to_buf  - copies the cpumask into the buffer either
> + *      as comma-separated list of cpus or hex values of cpumask
> + * @list: indicates whether the cpumap must be list
> + * @mask: the cpumask to copy
> + * @buf: the buffer to copy into
> + * @off: in the string from which we are copying, We copy to @buf + off
> + * @count: the maximum number of bytes to print
> + *
> + * The role of cpumap_print_to_buf() and cpumap_print_to_pagebuf() is
> + * the same, the difference is that buf of bitmap_print_to_buf()
> + * can be more than one pagesize.
> + */
> +static inline ssize_t
> +cpumap_print_to_buf(bool list, char *buf, const struct cpumask *mask,
> +		    loff_t off, size_t count)
> +{
> +	return bitmap_print_to_buf(list, buf, cpumask_bits(mask),
> +				   nr_cpu_ids, off, count);
> +}
> +
>  #if NR_CPUS <= BITS_PER_LONG
>  #define CPU_MASK_ALL							\
>  (cpumask_t) { {								\
> diff --git a/lib/bitmap.c b/lib/bitmap.c
> index 74ceb02f45e3..ed7ef6e2edca 100644
> --- a/lib/bitmap.c
> +++ b/lib/bitmap.c
> @@ -461,6 +461,40 @@ int bitmap_parse_user(const char __user *ubuf,
>  }
>  EXPORT_SYMBOL(bitmap_parse_user);
>  
> +/**
> + * bitmap_print_to_buf - convert bitmap to list or hex format ASCII string
> + * @list: indicates whether the bitmap must be list
> + * @buf: the kernel space buffer to read to
> + * @maskp: pointer to bitmap to convert
> + * @nmaskbits: size of bitmap, in bits
> + * @off: offset in data buffer below

Below there's a @count parameter. Maybe above?

> + * @count: the maximum number of bytes to print
> + *
> + * The role of bitmap_print_to_buf() and bitmap_print_to_pagebuf() is
> + * the same, the difference is that buf of bitmap_print_to_buf()
> + * can be more than one pagesize.

You're introducing a function that duplicates an existing function.
I can understand it only if there is important performance and/or
security consideration. Otherwise, I'd recommend you to extend
bitmap_print_to_pagebuf() with one more parameter.

> + */
> +int bitmap_print_to_buf(bool list, char *buf, const unsigned long *maskp,
> +			int nmaskbits, loff_t off, size_t count)
> +{
> +	const char *fmt = list ? "%*pbl\n" : "%*pb\n";
> +	ssize_t size;
> +	void *data;
> +
> +	if (off == LLONG_MAX && count == PAGE_SIZE - offset_in_page(buf))
> +		return scnprintf(buf, count, fmt, nmaskbits, maskp);

Agree with Greg. This requires explanation.

> +
> +	data = kasprintf(GFP_KERNEL, fmt, nmaskbits, maskp);
> +	if (!data)
> +		return -ENOMEM;

So here:
 - you make user of your function to guess about how much memory he needs
   to provide to the function;
 - then kasprintf() allocates enough memory for you automatically;
 - then you copy the data to potentially insufficient buffer;
 - and then free a valid 'data' buffer provided by kasprintf(), even if
   the following memory_read_from_buffer() fails;
 - goto 'So here'. 

It doesn't look like a good design.

kasprintf() does everything you need. Why don't you use it directly in
your driver?

> +
> +	size = memory_read_from_buffer(buf, count, &off, data, strlen(data) + 1);

strlen() is O(n), just as memory_read_from_buffer(). In this line you introduce
a 2*O(n) operation. Consider strncpy().

> +	kfree(data);
> +
> +	return size;
> +}
> +EXPORT_SYMBOL(bitmap_print_to_buf);
> +
>  /**
>   * bitmap_print_to_pagebuf - convert bitmap to list or hex format ASCII string
>   * @list: indicates whether the bitmap must be list
> @@ -482,8 +516,7 @@ int bitmap_print_to_pagebuf(bool list, char *buf, const unsigned long *maskp,
>  {
>  	ptrdiff_t len = PAGE_SIZE - offset_in_page(buf);
>  
> -	return list ? scnprintf(buf, len, "%*pbl\n", nmaskbits, maskp) :
> -		      scnprintf(buf, len, "%*pb\n", nmaskbits, maskp);
> +	return bitmap_print_to_buf(list, buf, maskp, nmaskbits, LLONG_MAX, len);
>  }
>  EXPORT_SYMBOL(bitmap_print_to_pagebuf);
>  
> -- 
> 2.25.1

  parent reply	other threads:[~2021-06-17 20:54 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-17 10:19 [PATCH v4 0/4] use bin_attribute to avoid cpumap buff overflow Barry Song
2021-06-17 10:19 ` [PATCH v4 1/4] lib: bitmap: introduce bitmap_print_to_buf Barry Song
2021-06-17 10:47   ` Greg KH
2021-06-18  2:14     ` Song Bao Hua (Barry Song)
2021-06-17 20:54   ` Yury Norov [this message]
2021-07-01 11:59     ` Song Bao Hua (Barry Song)
2021-06-17 10:19 ` [PATCH v4 2/4] topology: use bin_attribute to avoid buff overflow Barry Song
2021-06-17 10:54   ` Greg KH
2021-06-17 11:06     ` Song Bao Hua (Barry Song)
2021-06-17 10:55   ` Greg KH
2021-06-17 11:03     ` Song Bao Hua (Barry Song)
2021-06-17 10:19 ` [PATCH v4 3/4] drivers/base/node.c: " Barry Song
2021-06-17 10:55   ` Greg KH
2021-06-17 10:19 ` [PATCH v4 4/4] lib: test_bitmap: add bitmap_print_to_buf test cases Barry Song
2021-06-17 21:17 ` [PATCH v4 0/4] use bin_attribute to avoid cpumap buff overflow Yury Norov
2021-06-17 23:48   ` Song Bao Hua (Barry Song)

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=YMu2amhrdGZHJ5mY@yury-ThinkPad \
    --to=yury.norov@gmail.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=agordeev@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bristot@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=guodong.xu@linaro.org \
    --cc=jianpeng.ma@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=linuxarm@huawei.com \
    --cc=peterz@infradead.org \
    --cc=prime.zeng@hisilicon.com \
    --cc=rafael@kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=sbrivio@redhat.com \
    --cc=song.bao.hua@hisilicon.com \
    --cc=tangchengchang@huawei.com \
    --cc=tiantao6@hisilicon.com \
    --cc=tim.c.chen@linux.intel.com \
    --cc=valentin.schneider@arm.com \
    --cc=yangyicong@huawei.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.