lkml.org 
[lkml]   [2008]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
Subject[Bug 11823][PATCH] ieee1394: dv1394: fix possible deadlock in multithreaded clients
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 | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)

Index: linux/drivers/ieee1394/dv1394.c
===================================================================
--- linux.orig/drivers/ieee1394/dv1394.c
+++ linux/drivers/ieee1394/dv1394.c
@@ -1270,8 +1270,14 @@ static int dv1394_mmap(struct file *file
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);
--
Stefan Richter
-=====-==--- =-=- ==-=-
http://arcgraph.de/sr/


\
 
 \ /
  Last update: 2008-10-26 12:11    [W:0.021 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site