public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: "tiantao (H)" <tiantao6@huawei.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>,
	Tian Tao <tiantao6@hisilicon.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Barry Song <song.bao.hua@hisilicon.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Jonathan Cameron <jonathan.cameron@huawei.com>
Subject: Re: [PATCH 1/2] topology: use bin_attribute to avoid buff overflow
Date: Wed, 2 Jun 2021 11:06:21 +0200	[thread overview]
Message-ID: <YLdKDXYKm7jqorGa@kroah.com> (raw)
In-Reply-To: <f84f92f5-8462-0556-e457-4e302e1e8cb6@huawei.com>

On Wed, Jun 02, 2021 at 05:00:16PM +0800, tiantao (H) wrote:
> 
> 在 2021/6/2 16:48, Andy Shevchenko 写道:
> > On Wed, Jun 2, 2021 at 9:45 AM tiantao (H) <tiantao6@huawei.com> wrote:
> > > 在 2021/6/2 14:18, Greg KH 写道:
> > > > On Wed, Jun 02, 2021 at 02:14:49PM +0800, tiantao (H) wrote:
> > > > > 在 2021/6/1 12:58, Greg KH 写道:
> > > > > > On Tue, Jun 01, 2021 at 10:56:49AM +0800, Tian Tao wrote:
> > ...
> > 
> > > > > > >     /**
> > > > > > > + * bitmap_print_to_buf - convert bitmap to list or hex format ASCII string
> > > > > > > + * @list: indicates whether the bitmap must be list
> > > > > > > + * @buf: page aligned buffer into which string is placed
> > > > > > > + * @maskp: pointer to bitmap to convert
> > > > > > > + * @nmaskbits: size of bitmap, in bits
> > > > > > > + * @off: offset in buf
> > > > > > > + * @count: count that already output
> > > > > > > + *
> > > > > > > + * the role of bitmap_print_to_buf and bitmap_print_to_pagebuf is
> > > > > > > + * the same, the difference is that the second parameter of
> > > > > > > + * bitmap_print_to_buf can be more than one pagesize.
> > > > > > > + */
> > > > > > > +int bitmap_print_to_buf(bool list, char *buf, const unsigned long *maskp,
> > > > > > > +                  int nmaskbits, loff_t off, size_t count)
> > > > > > > +{
> > > > > > > +  int len, size;
> > > > > > > +  void *data;
> > > > > > > +  char *fmt = list ? "%*pbl\n" : "%*pb\n";
> > > > > > > +
> > > > > > > +  len = snprintf(NULL, 0, fmt, nmaskbits, maskp);
> > > > > > > +
> > > > > > > +  data = kvmalloc(len+1, GFP_KERNEL);
> > > > > > > +  if (!data)
> > > > > > > +          return -ENOMEM;
> > > > > > > +
> > > > > > > +  size = scnprintf(data, len+1, fmt, nmaskbits, maskp);
> > > > > > > +  size = memory_read_from_buffer(buf, count, &off, data, size);
> > > > > > > +  kvfree(data);
> > > > > > > +
> > > > > > > +  return size;
> > > > > > Why is this so different from bitmap_print_to_pagebuf()?  Can't you just
> > > > > > use this function as the "real" function and then change
> > > > > > bitmap_print_to_pagebuf() to call it with a size of PAGE_SIZE?
> > > > > Do you mean do following change, is that correct? :-)
> > > > Maybe, it is whitespace corrupted, and it still feels like this function
> > > > is much bigger than it needs to be given the function it is replacing is
> > > > only a simple sprintf() call.
> > > > 
> > > > > +int bitmap_print_to_buf(bool list, char *buf, const unsigned long *maskp,
> > > > > +                       int nmaskbits, loff_t off, size_t count)
> > > > > +{
> > > > > +       int len, size;
> > > > > +       void *data;
> > > > > +       const char *fmt = list ? "%*pbl\n" : "%*pb\n";
> > > > > +
> > > > > +       if (off == LLONG_MAX && count == PAGE_SIZE - offset_in_page(buf))
> > > > > +               return scnprintf(buf, count, fmt, nmaskbits, maskp);
> > > > > +
> > > > > +       len = snprintf(NULL, 0, fmt, nmaskbits, maskp);
> > > > > +
> > > > > +       data = kvmalloc(len+1, GFP_KERNEL);
> > > > Why do you need to allocate more memory?  And why kvmalloc()?
> > > Because the memory here will exceed a pagesize and we don't know the
> > > exact size, we have to call
> > > 
> > > snprintf first to get the actual size. kvmalloc() is used because when
> > > physical memory is tight, kmalloc
> > > 
> > > may fail, but vmalloc will succeed. It is not so bad that the memory is
> > > not requested here.
> > To me it sounds like the function is overengineered / lacks thought
> > through / optimization.
> > Can you provide a few examples that require the above algorithm?
> 
> so you think we should use kmalloc instead of kvmalloc ?

What size bitmap would trigger a vmalloc() call to be forced here?

thanks,

greg k-h

  reply	other threads:[~2021-06-02  9:06 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-01  2:56 [PATCH 0/2] use bin_attribute to avoid buff overflow Tian Tao
2021-06-01  2:56 ` [PATCH 1/2] topology: " Tian Tao
2021-06-01  4:58   ` Greg KH
2021-06-01  7:04     ` Song Bao Hua (Barry Song)
2021-06-01  7:13       ` Greg KH
2021-06-02  6:14     ` tiantao (H)
2021-06-02  6:18       ` Greg KH
2021-06-02  6:28         ` tiantao (H)
2021-06-02  8:48           ` Andy Shevchenko
2021-06-02  9:00             ` tiantao (H)
2021-06-02  9:06               ` Greg KH [this message]
2021-06-02  9:20                 ` Song Bao Hua (Barry Song)
2021-06-02  9:35                   ` Greg KH
2021-06-01  2:56 ` [PATCH 2/2] drivers/base/node.c: " Tian Tao
2021-06-01  5:01   ` Greg KH

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=YLdKDXYKm7jqorGa@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=song.bao.hua@hisilicon.com \
    --cc=tiantao6@hisilicon.com \
    --cc=tiantao6@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox