All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans Verkuil <hverkuil@xs4all.nl>
To: Pete Eberlein <pete@sensoray.com>
Cc: linux-media <linux-media@vger.kernel.org>,
	viro@ZenIV.linux.org.uk, mchehab@redhat.com
Subject: Re: videobuf mmap deadlock
Date: Mon, 11 Nov 2013 13:29:07 +0100	[thread overview]
Message-ID: <5280CD93.2020800@xs4all.nl> (raw)
In-Reply-To: <5273F8F2.5070901@sensoray.com>

Hi Pete,

On 11/01/2013 07:54 PM, Pete Eberlein wrote:
> The patch "videobuf_vm_{open,close} race fixes" 
> https://linuxtv.org/patch/18365/ introduced a deadlock in 3.11.
> 
> My driver uses videobuf_vmalloc initialized with ext_lock set to NULL.

Which driver are we talking about?

> My driver's mmap function calls videobuf_mmap_mapper
> videobuf_mmap_mapper calls videobuf_queue_lock on q
> videobuf_mmap_mapper calls  __videobuf_mmap_mapper
>   __videobuf_mmap_mapper calls videobuf_vm_open
> videobuf_vm_open calls videobuf_queue_lock on q (introduced by above patch)
> deadlocked
> 
> This is not an issue if ext_lock is non-NULL, since videobuf_queue_lock 
> is a no-op in that case.
> 
> Did I do something wrong, or is this a valid regression?

I think this is a valid regression. Using an atomic_t for the count is a better
solution IMHO. Anyone up for writing a patch?

Locking in videobuf is very messy and I recommend moving to videobuf2 which is
much more reliable and much easier to understand as well.

Regards,

	Hans

      reply	other threads:[~2013-11-11 12:29 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-01 18:54 videobuf mmap deadlock Pete Eberlein
2013-11-11 12:29 ` Hans Verkuil [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5280CD93.2020800@xs4all.nl \
    --to=hverkuil@xs4all.nl \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@redhat.com \
    --cc=pete@sensoray.com \
    --cc=viro@ZenIV.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.