diff options
author | Hans Verkuil <[email protected]> | 2014-01-03 08:10:49 -0300 |
---|---|---|
committer | Mauro Carvalho Chehab <[email protected]> | 2014-02-04 06:29:46 -0200 |
commit | cca36e2eecec2b8fc869a50ffd3bd0adeed92b8b (patch) | |
tree | 88a5b83d47de51a8af1877241dbc753a5ad665ea /tools/perf/util/trace-event-scripting.c | |
parent | 50c88544d225baadd6de1c4365d4ed16cc942a37 (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