History log of /linux-master/drivers/media/common/videobuf2/videobuf2-memops.c
Revision Date Author Comments
# e2fc6edd 28-Nov-2022 Hans Verkuil <hverkuil-cisco@xs4all.nl>

media: videobuf2: revert "get_userptr: buffers are always writable"

Commit 707947247e95 ("media: videobuf2-vmalloc: get_userptr: buffers are
always writable") caused problems in a corner case (passing read-only
shmem memory as a userptr). So revert this patch.

The original problem for which that commit was originally made is
something that I could not reproduce after reverting it. So just go
back to the way it was for many years, and if problems arise in
the future, then another approach should be taken to resolve it.

This patch is based on a patch from Hirokazu.

Fixes: 707947247e95 ("media: videobuf2-vmalloc: get_userptr: buffers are always writable")
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Acked-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>


# 04769cb1 27-Nov-2020 Daniel Vetter <daniel.vetter@ffwll.ch>

mm/frame-vector: Use FOLL_LONGTERM

This is used by media/videbuf2 for persistent dma mappings, not just
for a single dma operation and then freed again, so needs
FOLL_LONGTERM.

Unfortunately current pup_locked doesn't support FOLL_LONGTERM due to
locking issues. Rework the code to pull the pup path out from the
mmap_sem critical section as suggested by Jason.

By relying entirely on the vma checks in pin_user_pages and follow_pfn
(for vm_flags and vma_is_fsdax) we can also streamline the code a lot.

Note that pin_user_pages_fast is a safe replacement despite the
seeming lack of checking for vma->vm_flasg & (VM_IO | VM_PFNMAP). Such
ptes are marked with pte_mkspecial (which pup_fast rejects in the
fastpath), and only architectures supporting that support the
pin_user_pages_fast fastpath.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Pawel Osciak <pawel@osciak.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Tomasz Figa <tfiga@chromium.org>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: John Hubbard <jhubbard@nvidia.com>
Cc: Jérôme Glisse <jglisse@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: linux-mm@kvack.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-media@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20201127164131.2244124-6-daniel.vetter@ffwll.ch


# 70794724 04-Apr-2019 Hans Verkuil <hverkuil@xs4all.nl>

media: videobuf2-vmalloc: get_userptr: buffers are always writable

In vb2_vmalloc_get_userptr() the framevector is created with the
'write' argument set to false when vb2_create_framevec() is called
for OUTPUT buffers. So the pages are marked as read-only.

However, userspace will write to these buffers since it will fill
in the data to output. Since get_userptr is only called if the userptr
of the queued buffer has changed since the last time that same buffer
was queued, this will fail when the buffer contents is updated and the
buffer is queued again.

E.g., userspace fills buffer 1 with the output video and queues it.
The first time get_userptr is called and the pages are grabbed and
pinned in memory and marked read-only. The second time buffer 1 is
filled with different video data and queued again. Since the userptr
hasn't changed the get_userptr() callback isn't called again. Since
the pages were marked as read-only the new contents isn't updated.

Just always call vb2_create_framevec() with FOLL_WRITE to always
allow writing to the buffers.

Using USERPTR streaming with OUTPUT devices is almost never done. And
when it is done it is via v4l2-compliance and a driver like vim2m. But
since v4l2-compliance doesn't actually inspect the capture buffer and
compare it to the original output buffer, this issue was never noticed.

But the vicodec driver actually needs to parse the bitstream in the
OUTPUT buffers and any errors there will be immediately noticed. So
this time v4l2-compliance failed the USERPTR streaming test.

Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>


# 4b129dc9 18-Feb-2019 Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: common: fix several typos

Use codespell to fix lots of typos over frontends.

Manually verified to avoid false-positives.

Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>


# 7952be9b 08-Jan-2018 Hans Verkuil <hverkuil@xs4all.nl>

media: drivers/media/common/videobuf2: rename from videobuf

This directory contains the videobuf2 framework, so name the
directory accordingly.

The name 'videobuf' typically refers to the old and deprecated
videobuf version 1 framework so that was confusing.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>