summaryrefslogtreecommitdiffstats
path: root/drivers/media/video/videobuf2-dma-sg.c
AgeCommit message (Collapse)Author
2011-12-30[media] media: vb2: fix potential deadlock in mmap vs. get_userptr handlingMarek Szyprowski
To get direct access to userspace memory pages vb2 allocator needs to gather read access on mmap semaphore in the current process. The same semaphore is taken before calling mmap operation, while both mmap and qbuf are called by the driver or v4l2 core with driver's lock held. To avoid a AB-BA deadlock (mmap_sem then driver's lock in mmap and driver's lock then mmap_sem in qbuf) the videobuf2 core release driver's lock, takes mmap_sem and then takes again driver's lock. get_userptr methods are now called with all needed locks already taken to avoid further lock magic inside memory allocator's code. Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> CC: Pawel Osciak <pawel@osciak.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-09-03[media] videobuf2: Do not unconditionally map S/G buffers into kernel spaceJonathan Corbet
The one in-tree videobuf2-dma-sg driver (mmp-camera) has no need for a kernel-space mapping of the buffers; one suspects that most other drivers would not either. The videobuf2-dma-sg module does the right thing if buf->vaddr == NULL - it maps the buffer on demand if somebody needs it. So let's not map the buffer at allocation time; that will save a little CPU time and a lot of address space in the vmalloc range. Signed-off-by: Jonathan Corbet <corbet@lwn.net> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-27[media] media: Convert vmalloc/memset to vzallocJoe Perches
Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-06-30[media] media: vb2: add __GFP_NOWARN to dma-sg allocatorMarek Szyprowski
Add __GFP_NOWARN parameter to videobuf2 dma-sg allocator to prevent kernel warning and stack dump if there is not enough memory available. Videobuf2 and drivers should correctly handle no memory case, so there is no need for stack dump and extensive log. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-03-22[media] v4l2: vb2-dma-sg: fix potential security holeAndrzej Pietrasiewicz
Memory allocated by alloc_page() function might contain some potentially important data from other system processes. The patch adds a flag to zero the allocated page before giving it to videobuf2 (and then to userspace). Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-03-22[media] v4l2: vb2-dma-sg: fix memory leakAndrzej Pietrasiewicz
This patch fixes two minor memory leaks in videobuf2-dma-sg module. They might happen only in case some other operations (like memory allocation) failed. Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-03-21[media] v4l: videobuf2: add DMA scatter/gather allocatorAndrzej Pietrasiewicz
Add an implementation of DMA scatter/gather allocator and handling routines for videobuf2. For mmap operation mode it is implemented on top of alloc_page + sg_set_page/_free_page. For userptr operation mode it is implemented on top of get_user_pages + sg_set_page/put_page. Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> CC: Pawel Osciak <pawel@osciak.com> Reviewed-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>