From: Daniel Vetter <daniel@ffwll.ch>
To: Thomas Hellstrom <thellstrom@vmware.com>
Cc: pv-drivers@vmware.com, linux-graphics-maintainer@vmware.com,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 06/16] drm: Protect the master management with a drm_device::master_mutex
Date: Wed, 26 Mar 2014 23:38:40 +0100 [thread overview]
Message-ID: <20140326223840.GY26878@phenom.ffwll.local> (raw)
In-Reply-To: <53333B32.6090102@vmware.com>
On Wed, Mar 26, 2014 at 09:40:18PM +0100, Thomas Hellstrom wrote:
> On 03/26/2014 08:08 PM, David Herrmann wrote:
> > "struct_mutex" is used to serialize all entry-points into
> > the drm-device (and thus the driver) and also, often implicitly, as
> > spin-lock for "struct drm_device" data protection.
>
> No. DRM locking was added as an after-though, and is a horrendous mess.
> Nobody really knows what's protecting what, and that has caused a lot of
> grief in the past. Probably most so for the Intel driver that relied
> (relies?) on the struct_mutex to protect everything. The
> drm_global_mutex is used to serialize the non-lock-audited entry points
> into the drm device. The struct_mutex is used for data protection of
> most core drm structures and serializing here and there. Modern drivers
> have no locks held when entering their ioctls. Also we should not
> confuse mutexes and spinlocks in this context, as they have very
> different semantics.
As the guy who gets to live the locking mess called dev->struct_mutex I
holeheartedly welcome any efforts to split out clear subparts away from
it. I actually had this very idea of adding a master-data related mutex on
my todo. I'll try to review this later if I get around, but definitely
Acked!
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
next prev parent reply other threads:[~2014-03-26 22:38 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-25 13:18 [PATCH 00/16] vmwgfx render-node support Thomas Hellstrom
2014-03-25 13:18 ` [PATCH 01/16] drm: Have the crtc code only reference master from legacy nodes v2 Thomas Hellstrom
2014-03-25 13:18 ` [PATCH 02/16] drm: Break out ioctl permission check to a separate function v2 Thomas Hellstrom
2014-03-25 13:18 ` [PATCH 03/16] drm: Make control nodes master-less v3 Thomas Hellstrom
2014-03-26 18:55 ` David Herrmann
2014-03-25 13:18 ` [PATCH 04/16] drm: Improve on minor type helpers v2 Thomas Hellstrom
2014-03-26 18:54 ` David Herrmann
2014-03-25 13:18 ` [PATCH 05/16] drm: Remove the minor master list Thomas Hellstrom
2014-03-25 13:18 ` [PATCH 06/16] drm: Protect the master management with a drm_device::master_mutex Thomas Hellstrom
2014-03-26 19:08 ` David Herrmann
2014-03-26 20:40 ` Thomas Hellstrom
2014-03-26 22:38 ` Daniel Vetter [this message]
2014-03-27 23:44 ` David Herrmann
2014-03-25 13:18 ` [PATCH 07/16] drm: Add a function to get the ioctl flags Thomas Hellstrom
2014-03-25 13:19 ` [PATCH 08/16] drm/vmwgfx: Use a per-device semaphore for reservation protection Thomas Hellstrom
2014-03-25 13:19 ` [PATCH 09/16] drm/vmwgfx: Reinstate and tighten security around legacy master model Thomas Hellstrom
2014-03-25 13:19 ` [PATCH 10/16] drm/vmwgfx: Drop authentication requirement on UNREF ioctls Thomas Hellstrom
2014-03-25 13:19 ` [PATCH 11/16] drm/vmwgfx: Allow prime fds in the surface reference ioctls Thomas Hellstrom
2014-03-25 13:19 ` [PATCH 12/16] drm/vmwgfx: Tighten security around surface sharing Thomas Hellstrom
2014-03-25 13:19 ` [PATCH 13/16] drm/ttm: Add a ttm_ref_object_exists function Thomas Hellstrom
2014-03-25 13:19 ` [PATCH 14/16] drm/vmwgfx: Tighten the security around buffer maps Thomas Hellstrom
2014-03-25 13:19 ` [PATCH 15/16] drm/vmwgfx: Enable render nodes Thomas Hellstrom
2014-03-25 13:19 ` [PATCH 16/16] drm/vmwgfx: Bump driver minor and date Thomas Hellstrom
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=20140326223840.GY26878@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-graphics-maintainer@vmware.com \
--cc=pv-drivers@vmware.com \
--cc=thellstrom@vmware.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