Brian Behlendorf ede0bdffb6 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().
2010-06-28 16:02:57 -07:00
2010-06-28 16:02:57 -07:00
2010-06-28 16:02:57 -07:00
2010-05-17 15:18:00 -07:00
2010-05-17 15:18:00 -07:00
2010-05-17 15:18:00 -07:00
2010-05-17 15:18:00 -07:00
2010-05-17 15:18:00 -07:00
2010-05-17 15:18:00 -07:00
2010-06-11 15:57:25 -07:00
Description
freebsd with flexible iflib nic queues
2.6 GiB
Languages
C 60.1%
C++ 26.1%
Roff 4.9%
Shell 3%
Assembly 1.7%
Other 3.7%