]> granicus.if.org Git - spl/commit
Treat mutex->owner as volatile
authorBrian Behlendorf <behlendorf1@llnl.gov>
Mon, 28 Jun 2010 19:48:20 +0000 (12:48 -0700)
committerBrian Behlendorf <behlendorf1@llnl.gov>
Mon, 28 Jun 2010 23:02:57 +0000 (16:02 -0700)
commitede0bdffb6d36915ad610b0bdf7d790f858f448c
tree7a80fd37c7527a3beea9e93584db8a2e7685ee78
parent616df2dd8bf76e6eb73b546d75e4c4291e104ecf
Treat mutex->owner as volatile

When HAVE_MUTEX_OWNER is defined and we are directly accessing
mutex->owner treat is as volative with the ACCESS_ONCE() helper.
Without this you may get a stale cached value when accessing it
from different cpus.  This can result in incorrect behavior from
mutex_owned() and mutex_owner().  This is not a problem for the
!HAVE_MUTEX_OWNER case because in this case all the accesses
are covered by a spin lock which similarly gaurentees we will
not be accessing stale data.

Secondly, check CONFIG_SMP before allowing access to mutex->owner.
I see that for non-SMP setups the kernel does not track the owner
so we cannot rely on it.

Thirdly, check CONFIG_MUTEX_DEBUG when this is defined and the
HAVE_MUTEX_OWNER is defined surprisingly the mutex->owner will
not be cleared on mutex_exit().  When this is the case the SPL
needs to make sure to do it to ensure MUTEX_HELD() behaves as
expected or you will certainly assert in mutex_destroy().

Finally, improve the mutex regression tests.  For mutex_owned() we
now minimally check that it behaves correctly when checked from the
owner thread or the non-owner thread.  This subtle behaviour has bit
me before and I'd like to catch it early next time if it reappears.

As for mutex_owned() regression test additonally verify that
mutex->owner is always cleared on mutex_exit().
include/sys/mutex.h
module/splat/splat-mutex.c