public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Jonathan Cameron <Jonathan.Cameron@huawei.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 16:00:29 +0300	[thread overview]
Message-ID: <YLjSbSeFBygxl799@smile.fi.intel.com> (raw)
In-Reply-To: <20210603133919.00004603@Huawei.com>

On Thu, Jun 03, 2021 at 01:39:19PM +0100, Jonathan Cameron wrote:
> 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?

There is no hint, as you noticed the documentation of the function is a bit
confusing.

> /**
>  * 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?

Thanks for double checking and explaining.

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

Just test cases is what we are missing. Then we can play around with different
input to see if it's all correct.

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2021-06-03 13:00 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
2021-06-03 13:00           ` Andy Shevchenko [this message]
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=YLjSbSeFBygxl799@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=agordeev@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --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