From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Hellstrom Subject: Re: [PATCH 06/16] drm: Protect the master management with a drm_device::master_mutex v2 Date: Fri, 28 Mar 2014 10:45:17 +0100 Message-ID: <533544AD.80506@vmware.com> References: <1395951799-3666-1-git-send-email-thellstrom@vmware.com> <1395951799-3666-3-git-send-email-thellstrom@vmware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from smtp-outbound-1.vmware.com (smtp-outbound-1.vmware.com [208.91.2.12]) by gabe.freedesktop.org (Postfix) with ESMTP id 8288E6EC24 for ; Fri, 28 Mar 2014 02:45:20 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: David Herrmann Cc: "dri-devel@lists.freedesktop.org" List-Id: dri-devel@lists.freedesktop.org On 03/28/2014 01:19 AM, David Herrmann wrote: > Hi > > > > I also don't quite understand why you move the struct_mutex locking > into drm_master_destroy() instead of requiring callers to lock it as > before? I mean, the whole function is protected by the lock.. Before, struct_mutex was required outside of drm_master_put(), because the argument to drm_master_put was also protected by struct_mutex. Now that's no longer the case and I chose to move the locking into the destructor, avoiding a number of unnecessary struct_mutex locks (the master destructor is called more seldom than master_put()). Also in general I believe one should avoid locking around unreferencing if possible, because it leads to ugly constructs (and even static code analyzers complaining) if the lock has to be temporarily released in the destructor to avoid locking order violations. But in the end I guess that's really a matter of taste. /Thomas