public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: "tiantao (H)" <tiantao6@huawei.com>,
	Tian Tao <tiantao6@hisilicon.com>, <gregkh@linuxfoundation.org>,
	<rafael@kernel.org>, <akpm@linux-foundation.org>,
	<linux-kernel@vger.kernel.org>, <song.bao.hua@hisilicon.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	"Stefano Brivio" <sbrivio@redhat.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	"Ma, Jianpeng" <jianpeng.ma@intel.com>,
	Yury Norov <yury.norov@gmail.com>,
	Valentin Schneider <valentin.schneider@arm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Daniel Bristot de Oliveira <bristot@redhat.com>
Subject: Re: [PATCH v3 1/3] lib: bitmap: introduce bitmap_print_to_buf
Date: Thu, 3 Jun 2021 13:39:19 +0100	[thread overview]
Message-ID: <20210603133919.00004603@Huawei.com> (raw)
In-Reply-To: <YLi41Iz5fJ4cUErt@smile.fi.intel.com>

On Thu, 3 Jun 2021 14:11:16 +0300
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

> On Thu, Jun 03, 2021 at 06:33:25PM +0800, tiantao (H) wrote:
> > 在 2021/6/3 17:50, Andy Shevchenko 写道:  
> > > On Thu, Jun 03, 2021 at 05:22:40PM +0800, Tian Tao wrote:  
> > > > 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().  
> 
> ...
> 
> > > > + * @count: the maximum number of bytes to print  
> 
> > > > +	size = memory_read_from_buffer(buf, count, &off, data, strlen(data) + 1);  
> > > Are you sure you have put parameters in the correct order?  
> > 
> > yes, I already test it.
> > 
> > ssize_t memory_read_from_buffer(void *to, size_t count, loff_t *ppos,
> >                                 const void *from, size_t available)  
> 
> Have you read the meaning of count and available?
> Please, double check that they are filled with correct values.

Ok, I don't get this one either so can you give us more of a hint?

/**
 * memory_read_from_buffer - copy data from the buffer
 * @to: the kernel space buffer to read to
 * @count: the maximum number of bytes to read
 * @ppos: the current position in the buffer
 * @from: the buffer to read from
 * @available: the size of the buffer
 *
 * The memory_read_from_buffer() function reads up to @count bytes from the
 * buffer @from at offset @ppos into the kernel space address starting at @to.
 *
 * On success, the number of bytes read is returned and the offset @ppos is
 * advanced by this number, or negative value is returned on error.
 **/

These docs do end up rather confusing by using the term buffer for multiple things
but taking what is passed in.

Count is the maximum in the sense of how many bytes we are requesting are read
which indeed should be count here as that reflects what userspace asked for.

Avail is the size of the buffer we are reading from.  Now that's slightly
ambiguous in the docs in the sense of 'buffer' could mean the to buffer or
the from buffer.  However, I'd assume count is definitely <= size of the space
after address to in the to buffer, so I would assume that means available
is the size of the from buffer.  Here that is strlen() + 1, so looks fine.

This interpretation also lines up with the implementation.

So what are we missing?

Jonathan

> 
> > > I guess you have to provide the test case(s).  
> 


  reply	other threads:[~2021-06-03 12:39 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-03  9:22 [PATCH v3 0/3] use bin_attribute to avoid buff overflow Tian Tao
2021-06-03  9:22 ` [PATCH v3 1/3] lib: bitmap: introduce bitmap_print_to_buf Tian Tao
2021-06-03  9:50   ` Andy Shevchenko
2021-06-03 10:33     ` tiantao (H)
2021-06-03 10:49       ` Greg KH
     [not found]         ` <0a43ca2a-7563-0bd6-fd1f-3fef208d71ef@huawei.com>
2021-06-03 11:37           ` Greg KH
2021-06-03 11:38             ` Greg KH
2021-06-03 11:11       ` Andy Shevchenko
2021-06-03 12:39         ` Jonathan Cameron [this message]
2021-06-03 13:00           ` Andy Shevchenko
2021-06-03  9:22 ` [PATCH v3 2/3] topology: use bin_attribute to avoid buff overflow Tian Tao
2021-06-03  9:22 ` [PATCH v3 3/3] drivers/base/node.c: " Tian Tao
2021-06-03  9:53   ` Andy Shevchenko
2021-06-03 10:31     ` tiantao (H)
2021-06-03 11:09       ` Andy Shevchenko
2021-06-03  9:49 ` [PATCH v3 0/3] " Jonathan Cameron

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=20210603133919.00004603@Huawei.com \
    --to=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=jianpeng.ma@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=sbrivio@redhat.com \
    --cc=song.bao.hua@hisilicon.com \
    --cc=tiantao6@hisilicon.com \
    --cc=tiantao6@huawei.com \
    --cc=valentin.schneider@arm.com \
    --cc=yury.norov@gmail.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