From cca36e2eecec2b8fc869a50ffd3bd0adeed92b8b Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Fri, 3 Jan 2014 08:10:49 -0300 Subject: [PATCH] [media] Revert "[media] videobuf_vm_{open,close} race fixes" This reverts commit a242f426108c284049a69710f871cc9f11b13e61. That commit actually caused deadlocks, rather then fixing them. If ext_lock is set to NULL (otherwise videobuf_queue_lock doesn't do anything), then you get this deadlock: The driver's mmap function calls videobuf_mmap_mapper which calls videobuf_queue_lock on q. videobuf_mmap_mapper calls __videobuf_mmap_mapper, __videobuf_mmap_mapper calls videobuf_vm_open and videobuf_vm_open calls videobuf_queue_lock on q (introduced by above patch): deadlocked. This affects drivers using dma-contig and dma-vmalloc. Only dma-sg is not affected since it doesn't call videobuf_vm_open from __videobuf_mmap_mapper. Most drivers these days have a non-NULL ext_lock. Those that still use NULL there are all fairly obscure drivers, which is why this hasn't been seen earlier. Since everything worked perfectly fine for many years I prefer to just revert this patch rather than trying to fix it. videobuf is quite fragile and I rather not touch it too much. Work is (slowly) progressing to move everything over to vb2 or at the very least use non-NULL ext_lock in videobuf. Signed-off-by: Hans Verkuil Cc: # for v3.11 and up Cc: Al Viro Reported-by: Pete Eberlein Signed-off-by: Mauro Carvalho Chehab --- Reading git-format-patch failed