• Hans Verkuil's avatar
    [media] Revert "[media] videobuf_vm_{open,close} race fixes" · cca36e2e
    Hans Verkuil authored
    This reverts commit a242f426.
    
    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: default avatarHans Verkuil <hans.verkuil@cisco.com>
    Cc: <stable@vger.kernel.org>      # for v3.11 and up
    Cc: Al Viro <viro@ZenIV.linux.org.uk>
    Reported-by: default avatarPete Eberlein <pete@sensoray.com>
    Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
    cca36e2e
videobuf-dma-sg.c 15.3 KB