From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>,
Prabhakar Lad <prabhakar.csengg@gmail.com>,
LMML <linux-media@vger.kernel.org>,
DLOS <davinci-linux-open-source@linux.davincidsp.com>,
LKML <linux-kernel@vger.kernel.org>,
Hans Verkuil <hans.verkuil@cisco.com>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [PATCH v2] media: davinci: vpif: align the buffers size to page page size boundary
Date: Thu, 18 Apr 2013 08:35:47 -0300 [thread overview]
Message-ID: <20130418083547.41f975f8@redhat.com> (raw)
In-Reply-To: <20130418082121.0221e59e@redhat.com>
Em Thu, 18 Apr 2013 08:21:21 -0300
Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:
> Em Thu, 18 Apr 2013 10:17:14 +0530
> Prabhakar Lad <prabhakar.csengg@gmail.com> escreveu:
>
> > Hi Marek,
> >
> > On Tue, Apr 16, 2013 at 4:48 PM, Laurent Pinchart
> > <laurent.pinchart@ideasonboard.com> wrote:
> > > Hi Prabhakar,
>
> ...
>
> > >> *nbuffers = config_params.min_numbuffers;
> > >>
> > >> *nplanes = 1;
> > >> + size = PAGE_ALIGN(size);
> > >
> > > I wonder if that's the best fix.
> > > The queue_setup operation is supposed to return the size required by the
> > > driver for each plane. Depending on the hardware requirements, that size might
> > > not be a multiple of the page size.
> > >
> > > As we can't mmap() a fraction of a page, the allocated plane size needs to be
> > > rounded up to the next page boundary to allow mmap() support. The dma-contig
> > > and dma-sg allocators already do so in their alloc operation, but the vmalloc
> > > allocator doesn't.
> > >
> > > The recent "media: vb2: add length check for mmap" patch verifies that the
> > > mmap() size requested by userspace doesn't exceed the buffer size. As the
> > > mmap() size is rounded up to the next page boundary the check will fail for
> > > buffer sizes that are not multiple of the page size.
> > >
> > > Your fix will not result in overallocation (as the allocator already rounds
> > > the size up), but will prevent the driver from importing a buffer large enough
> > > for the hardware but not rounded up to the page size.
> > >
> > > A better fix might be to round up the buffer size in the buffer size check at
> > > mmap() time, and fix the vmalloc allocator to round up the size. That the
> > > allocator, not drivers, is responsible for buffer size alignment should be
> > > documented in videobuf2-core.h.
>
> > >
> > Do you plan to post a patch fixing it as per Laurent's suggestion ?
>
> I agree with Laurent: page size roundup should be done at VB2 core code,
> for memory allocated there, and not at driver's level. Yet, looking at
> VB2 code, it already does page size align at __setup_offsets(), but it
> doesn't do if for the size field; just for the offset.
>
> The adjusted size should be stored at the VB2 size field, and the check for
> buffer overflow, added on changeset 068a0df76023926af958a336a78bef60468d2033
> should be kept.
>
> IMO, it also makes sense to enforce that the USERPTR memory is multiple of the
> page size, as otherwise the DMA transfer may overwrite some area that is
> outside the allocated range. So, the size from USERPTR should be round down.
>
> That change, however, will break userspace, as it uses the picture sizeimage
> to allocate the buffers. So, sizeimage needs to be PAGE_SIZE roundup before
> passing it to userspace.
>
> Instead of modifying all drivers, the better seems to patch v4l_g_fmt() and
> v4l_try_fmt() to return a roundup value for sizeimage. As usual, uvcvideo
> requires a separate patch, because it doesn't use vidio_ioctl2.
Hmm... PAGE_SIZE alignment is not needed on all places. It is needed only when
DMA is done directly into the buffer, e. g. videobuf2-dma-contig and
videobuf2-dma-sg.
It means that we'll need an extra function for the VB2 memory allocation drivers
to do do the memory-dependent roundups, and a new ancillary function at VB2 core
for the VB2 clients to call to round sizeimage if needed.
Regards,
Mauro
next prev parent reply other threads:[~2013-04-18 11:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-16 10:54 [PATCH v2] media: davinci: vpif: align the buffers size to page page size boundary Prabhakar lad
2013-04-16 10:56 ` Prabhakar Lad
2013-04-16 11:18 ` Laurent Pinchart
2013-04-18 4:47 ` Prabhakar Lad
2013-04-18 11:21 ` Mauro Carvalho Chehab
2013-04-18 11:35 ` Mauro Carvalho Chehab [this message]
2013-04-18 13:22 ` Laurent Pinchart
2013-04-18 14:08 ` Mauro Carvalho Chehab
2013-04-18 14:18 ` Laurent Pinchart
2013-04-16 11:39 ` Sergei Shtylyov
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=20130418083547.41f975f8@redhat.com \
--to=mchehab@redhat.com \
--cc=davinci-linux-open-source@linux.davincidsp.com \
--cc=hans.verkuil@cisco.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=prabhakar.csengg@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;
as well as URLs for NNTP newsgroup(s).