From: Hans Verkuil Date: Fri, 3 Jan 2014 11:10:49 +0000 (-0300) Subject: [media] Revert "[media] videobuf_vm_{open,close} race fixes" X-Git-Tag: v3.14-rc2~14^2~10 X-Git-Url: http://git.openpandora.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=cca36e2eecec2b8fc869a50ffd3bd0adeed92b8b;p=pandora-kernel.git [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-diff-tree failed