All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Sander Eikelenboom <linux@eikelenboom.it>,
	Mauro Carvalho Chehab <mchehab@infradead.org>,
	linux-media@vger.kernel.org, hans.verkuil@cisco.com
Subject: Re: [ 3960.758784] 1 lock held by motion/7776: [ 3960.758788]  #0: (&queue->mutex){......}, at: [<ffffffff815c62d2>] uvc_queue_enable+0x32/0xc0
Date: Mon, 07 May 2012 15:28:36 +0200	[thread overview]
Message-ID: <4FA7CE04.10004@redhat.com> (raw)
In-Reply-To: <201205071344.59861.hverkuil@xs4all.nl>

Hi,

On 05/07/2012 01:44 PM, Hans Verkuil wrote:
> On Monday 07 May 2012 13:06:01 Laurent Pinchart wrote:
>> Hi Sanser,
>>
>> On Sunday 06 May 2012 16:54:40 Sander Eikelenboom wrote:
>>> Hello Laurent / Mauro,
>>>
>>> I have updated to latest 3.4-rc5-tip, running multiple video grabbers.
>>> I don't see anything specific to uvcvideo anymore, but i do get the possible
>>> circular locking dependency below.
>>
>> Thanks for the report.
>>
>> We indeed have a serious issue there (CC'ing Hans Verkuil).
>>
>> Hans, serializing both ioctl handling an mmap with a single device lock as we
>> currently do in V4L2 is prone to AB-BA deadlocks (uvcvideo shouldn't be
>> affected as it has no device-wide lock).
>>
>> If we want to keep a device-wide lock we need to take it after the mm-
>>> mmap_sem lock in all code paths, as there's no way we can change the lock
>> ordering for mmap(). The copy_from_user/copy_to_user issue could be solved by
>> moving locking from v4l2_ioctl to __video_do_ioctl (device-wide locks would
>> then require using video_ioctl2), but I'm not sure whether that will play
>> nicely with the QBUF implementation in videobuf2 (which already includes a
>> workaround for this particular AB-BA deadlock issue).
>
> I've seen the same thing. It was on my TODO list of things to look into. I think
> mmap shouldn't take the device wide lock at all. But it will mean reviewing
> affected drivers before I can remove it.
>
> To be honest, I wasn't sure whether or not to take the device lock for mmap when
> I first wrote that code.
>
> If you look at irc I had a discussion today with HdG about adding flags to
> selectively disable locks for fops. It may be an idea to implement this soon so
> we can start updating drivers one-by-one.

I've a patch almost ready for this, when I'm happy with it I'll send of a new
version of the (ever growing) gspca use control framework patchset both me and
the other Hans have been working on, which will include this patch.

Regards,

Hans

  parent reply	other threads:[~2012-05-07 13:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-28 20:02 [ 3960.758784] 1 lock held by motion/7776: [ 3960.758788] #0: (&queue->mutex){......}, at: [<ffffffff815c62d2>] uvc_queue_enable+0x32/0xc0 Sander Eikelenboom
2012-04-29 23:05 ` Laurent Pinchart
2012-05-06 14:54   ` Sander Eikelenboom
2012-05-07 11:06     ` Laurent Pinchart
2012-05-07 11:44       ` Hans Verkuil
2012-05-07 11:47         ` Laurent Pinchart
2012-05-07 11:52           ` Hans Verkuil
2012-05-07 13:28         ` Hans de Goede [this message]
2012-06-27 21:15           ` Sander Eikelenboom

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=4FA7CE04.10004@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=hans.verkuil@cisco.com \
    --cc=hverkuil@xs4all.nl \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=linux@eikelenboom.it \
    --cc=mchehab@infradead.org \
    /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.