]> pilppa.com Git - linux-2.6-omap-h63xx.git/commitdiff
ieee1394: dv1394: fix possible deadlock in multithreaded clients
authorStefan Richter <stefanr@s5r6.in-berlin.de>
Sun, 26 Oct 2008 11:02:03 +0000 (12:02 +0100)
committerStefan Richter <stefanr@s5r6.in-berlin.de>
Fri, 31 Oct 2008 07:48:26 +0000 (08:48 +0100)
Fix a possible though highly unlikely deadlock:

Thread A:                  Thread B:
 - acquire mmap_sem         - dv1394_ioctl/read/write()
 - dv1394_mmap()            - acquire video->mtx
 - acquire video->mtx       - copy_to/from_user(), possible page fault:
                              acquire mmap_sem

The simplest fix is to use mutex_trylock() instead of mutex_lock() in
dv1394_mmap().  This changes the behavior under contention in a way
which is visible to userspace clients.  However, my guess is that no
clients exist which use mmap vs. ioctl/read/write on the dv1394
character device file interface in concurrent threads.

Reported-by: Johannes Weiner <hannes@saeurebad.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
drivers/ieee1394/dv1394.c

index df70f51279d85db8d21b1731c9d7b3b96ca8e668..53329972c7dba580df1b8bd830c8cf8a85545b47 100644 (file)
@@ -1270,8 +1270,14 @@ static int dv1394_mmap(struct file *file, struct vm_area_struct *vma)
        struct video_card *video = file_to_video_card(file);
        int retval = -EINVAL;
 
-       /* serialize mmap */
-       mutex_lock(&video->mtx);
+       /*
+        * We cannot use the blocking variant mutex_lock here because .mmap
+        * is called with mmap_sem held, while .ioctl, .read, .write acquire
+        * video->mtx and subsequently call copy_to/from_user which will
+        * grab mmap_sem in case of a page fault.
+        */
+       if (!mutex_trylock(&video->mtx))
+               return -EAGAIN;
 
        if ( ! video_card_initialized(video) ) {
                retval = do_dv1394_init_default(video);