Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 9be29369 authored by Laurent Pinchart's avatar Laurent Pinchart Committed by Mauro Carvalho Chehab
Browse files

[media] media: omap3isp: video: Don't call vb2 mmap with queue lock held



videobuf2 has long been subject to AB-BA style deadlocks due to the
queue lock and mmap_sem being taken in different orders for the mmap
operation. The problem has been fixed by making this operation callable
without taking the queue lock, using an mmap_lock internal to videobuf2.

The omap3isp driver still calls the mmap operation with the queue lock
held, resulting in a potential deadlock. As the operation can now be
called without locking the queue, fix it.

Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: default avatarSakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
parent bf104c23
Loading
Loading
Loading
Loading
+1 −7
Original line number Diff line number Diff line
@@ -1326,14 +1326,8 @@ static unsigned int isp_video_poll(struct file *file, poll_table *wait)
static int isp_video_mmap(struct file *file, struct vm_area_struct *vma)
{
	struct isp_video_fh *vfh = to_isp_video_fh(file->private_data);
	struct isp_video *video = video_drvdata(file);
	int ret;

	mutex_lock(&video->queue_lock);
	ret = vb2_mmap(&vfh->queue, vma);
	mutex_unlock(&video->queue_lock);

	return ret;
	return vb2_mmap(&vfh->queue, vma);
}

static struct v4l2_file_operations isp_video_fops = {