Re: [PATCH 3/9 v7] V4L: document the new VIDIOC_CREATE_BUFS and VIDIOC_PREPARE_BUF ioctl()s

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Guennadi,

Thank you for the patch.

As discussed over jabber, we're suffering from an AB-BA deadlock that this 
patch could make worse.

The mmap code path takes mm->mmap_sem in the kernel' mmap handler before 
calling the driver's mmap handler. The driver will then lock the queue mutex 
before calling vb2_mmap (or let the core lock the vdev mutex).

In the VIDIOC_QBUF code path, the driver will first lock the queue mutex (or 
let the core lock the vdev mutex) and call vb2_qbuf. This will then take mm-
>mmap_sem to call get_user_pages for USERPTR buffers. The two locks are taken 
in different orders depending on the code paths, resulting in a possible AB-BA 
deadlock.

mmap'ing USERPTR buffers doesn't make sense, so application will likely not 
experience any deadlock. However, if VIDIOC_CREATE_BUFS allows mixing MMAP and 
USERPTR buffers, we could suddenly see a rise of deadlock issues resulting 
from valid use cases.

This problem needs to be fixed anyway, as a rogue application can currently 
produce a kernel deadlock. The fix can probably be pretty simple if we decide 
not to support mixing MMAP and USERPTR buffers, but it might become more 
complex if we need to support that.

I'm interested in hearing what others think about this.

-- 
Regards,

Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux