From: Maarten Lankhorst <maarten.lankhorst@canonical.com>
To: Ben Skeggs <skeggsb@gmail.com>
Cc: Marcin Slusarz <marcin.slusarz@gmail.com>,
Peter Hurley <peter@hurleysoftware.com>,
nouveau@lists.freedesktop.org,
Linux Kernel <linux-kernel@vger.kernel.org>,
dri-devel@lists.freedesktop.org,
Daniel J Blueman <daniel@quora.org>,
Ben Skeggs <bskeggs@redhat.com>,
Arend van Spriel <arend@broadcom.com>
Subject: Re: [PATCH] drm/nouveau: add lockdep annotations
Date: Thu, 07 Feb 2013 17:19:11 +0100 [thread overview]
Message-ID: <5113D3FF.6060009@canonical.com> (raw)
In-Reply-To: <20130205205255.GA10051@localhost.bne.redhat.com>
Hey,
Op 05-02-13 21:52, Ben Skeggs schreef:
> On Mon, Feb 04, 2013 at 10:59:28PM +0100, Maarten Lankhorst wrote:
>> Op 04-02-13 22:30, Marcin Slusarz schreef:
>>> 1) Lockdep thinks all nouveau subdevs belong to the same class and can be
>>> locked in arbitrary order, which is not true (at least in general case).
>>> Tell it to distinguish subdevs by (o)class type.
>> Apart from this specific case, is there any other reason why we require being able to nest 2 subdev locks?
> I think I tend to prefer Marcin's fix for this actually. The subdev's
> are completely separate classes of objects and as interaction between
> them increases (PM will be very much like this), we may very well
> require holding multiple subdev mutexes at once.
>
> Ben.
Depends, I think for this specific example I think my cleanup is better.
For the generic case you could use nested mutexes, which will give you a
different lockdep class when you need it. It's probably better to have those
cases where you do need to nest locking annotated:
mutex_lock_nested(&mutex, SINGLE_DEPTH_NESTING);
See also Documentation/lockdep-design.txt
~Maarten
prev parent reply other threads:[~2013-02-07 16:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-03 15:09 3.8-rc6: nouveau lockdep recursive lock acquisition Daniel J Blueman
2013-02-04 21:30 ` [PATCH] drm/nouveau: add lockdep annotations Marcin Slusarz
2013-02-04 21:59 ` Maarten Lankhorst
2013-02-04 23:24 ` Peter Hurley
2013-02-05 20:52 ` Ben Skeggs
2013-02-07 16:19 ` Maarten Lankhorst [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=5113D3FF.6060009@canonical.com \
--to=maarten.lankhorst@canonical.com \
--cc=arend@broadcom.com \
--cc=bskeggs@redhat.com \
--cc=daniel@quora.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcin.slusarz@gmail.com \
--cc=nouveau@lists.freedesktop.org \
--cc=peter@hurleysoftware.com \
--cc=skeggsb@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).