aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/util/trace-event-scripting.c
diff options
context:
space:
mode:
authorHans Verkuil <[email protected]>2014-01-03 08:10:49 -0300
committerMauro Carvalho Chehab <[email protected]>2014-02-04 06:29:46 -0200
commitcca36e2eecec2b8fc869a50ffd3bd0adeed92b8b (patch)
tree88a5b83d47de51a8af1877241dbc753a5ad665ea /tools/perf/util/trace-event-scripting.c
parent50c88544d225baadd6de1c4365d4ed16cc942a37 (diff)
[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 <[email protected]> Cc: <[email protected]> # for v3.11 and up Cc: Al Viro <[email protected]> Reported-by: Pete Eberlein <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Diffstat (limited to 'tools/perf/util/trace-event-scripting.c')
0 files changed, 0 insertions, 0 deletions