linux-brain/include/media/videobuf2-memops.h

41 lines
1.1 KiB
C
Raw Normal View History

/*
* videobuf2-memops.h - generic memory handling routines for videobuf2
*
* Copyright (C) 2010 Samsung Electronics
*
* Author: Pawel Osciak <pawel@osciak.com>
* Marek Szyprowski <m.szyprowski@samsung.com>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation.
*/
#ifndef _MEDIA_VIDEOBUF2_MEMOPS_H
#define _MEDIA_VIDEOBUF2_MEMOPS_H
#include <media/videobuf2-v4l2.h>
#include <linux/mm.h>
#include <linux/refcount.h>
/**
* struct vb2_vmarea_handler - common vma refcount tracking handler.
*
* @refcount: pointer to &refcount_t entry in the buffer.
* @put: callback to function that decreases buffer refcount.
* @arg: argument for @put callback.
*/
struct vb2_vmarea_handler {
refcount_t *refcount;
void (*put)(void *arg);
void *arg;
};
extern const struct vm_operations_struct vb2_common_vm_ops;
struct frame_vector *vb2_create_framevec(unsigned long start,
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>
2019-04-04 22:15:00 +09:00
unsigned long length);
void vb2_destroy_framevec(struct frame_vector *vec);
#endif