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 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.