Re: [RFC][PATCH -v2 1/4] locking/drm/i915: Kill mutex trickery

[Andreas Mohr <andi@lisas.de>]

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