From: Stefan Richter Date: Sun, 26 Oct 2008 11:02:03 +0000 (+0100) Subject: ieee1394: dv1394: fix possible deadlock in multithreaded clients X-Git-Tag: firefly_0821_release~16915^2 X-Git-Url: http://demsky.eecs.uci.edu/git/?a=commitdiff_plain;h=8449fc3ae58bf8ee5acbd2280754cde67b5db128;p=firefly-linux-kernel-4.4.55.git 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 Signed-off-by: Stefan Richter --- diff --git a/drivers/ieee1394/dv1394.c b/drivers/ieee1394/dv1394.c index df70f51279d8..53329972c7db 100644 --- a/drivers/ieee1394/dv1394.c +++ b/drivers/ieee1394/dv1394.c @@ -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);