From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757710AbcHZD1J convert rfc822-to-8bit (ORCPT ); Thu, 25 Aug 2016 23:27:09 -0400 Received: from rhlx01.hs-esslingen.de ([129.143.116.10]:38694 "EHLO rhlx01.hs-esslingen.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757261AbcHZD1F (ORCPT ); Thu, 25 Aug 2016 23:27:05 -0400 Date: Fri, 26 Aug 2016 05:25:09 +0200 From: Andreas Mohr To: Waiman Long Cc: Daniel Vetter , Peter Zijlstra , linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCH -v2 1/4] locking/drm/i915: Kill mutex trickery Message-ID: <20160826032509.GA29502@rhlx01.hs-esslingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 8BIT X-Priority: none User-Agent: Mutt/1.6.2 (2016-07-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, [no properly binding reference via In-Reply-To: available thus manually re-creating, sorry] > > But initerim I guess we could set our own owner field and check that > > to keep the duct-tape from getting off completely. > > -Daniel > > Another alternative is to provide a standard mutex API that returns the > owner of the lock if there is a real need for this capability. Peeking > into lock internal is not a good practice. >>From personal experience here I would suggest that the core issue here is that this would create an inherently race-window-tainted API, which clearly is something to be avoided: The point is that the lock *owner* value is *volatile* whenever it is *not* our own context instance that is currently holding the lock while querying this API (i.e., thus not guaranteeing that the owner value will *not* be changed interim!), since in such a situation (not-privately-locked case!!) lock ownership may change at any point from under our just-observed result value. Returning such inherently racy information from a publicly offered mutex API is, errrrr, not so good, to put it rather mildly. So, it seems the most we could provide which would offer a reliable, non-racy API protocol is something like: static bool mutex_is_locked_by_us(struct mutex *mutex) since during execution of this processing it would be guaranteed that: - either we do have the lock, thus *we* *RELIABLY* are and will be "the owner" - or we simply do not have it, thus *we* *RELIABLY* are and will be "not the owner" [but note that in that case this mutex API implementation code would have a potentially unholy dependency on task stuff such as "current", but which it probably already has anyway] HTH, Andreas Mohr