The most recent verion of this patch set was recently posted, and it
uses the cv_wait() mechanism suggested by Adam Hamsik.
This discussion is still very intresting, but perhaps we could start a
new thread (or at least change the subject line)? :)
On Tue, 3 Aug 2010, matthew green wrote:
On Mon Aug 02 2010 at 16:30:03 +1000, matthew green wrote:
this is an incomplete reading of the manual page, and you can not
use mutex_owned() the way you are trying to (regardless of what
pooka posted.) you can't even using it in various forms of assertions
safely. from the man page:
It should not be used to make locking decisions at run time, or to
verify that a lock is not held.
That's the mantra, yes.
ie, you can not even KASSERT(!mutex_owned()).
Strictly speaking you can in a case where you have two locks always
are taken as l1,l2 and released as l2,l1 provided you're not dealing
with a spin mutex. Does it make any sense? no (l2 is useless).
Is it possible? yes.
what is not possible is to safely to what the manual says. you will
not have the right thing happen. i've seen this when i've been
working on the sparc64 pmap.
Now, on to sensible stuff. I'm quite certain that warning was written
to make people avoid writing bad code without understanding locking --
if you need to used mutex_owned() to decide if you should lock a normal
mutex, your code is broken. The other less likely possibility is that
someone plans to change mutex_owned in the future.
Further data point: the same warning is in rw_held, yet it was used to
implement recursive locking in vlockmgr until its very recent demise.
Ignoring man page mantras and focusing on how the code works, I do not
see anything wrong with Paul's use of mutex_owned().
this just does not match my actual experience in the kernel. i had
weird pmap-style problems and asserts firing wrongly while i did not
obey the rules in the manual directly.
.mrg.
-------------------------------------------------------------------------
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer | | pgoyette at netbsd.org |
-------------------------------------------------------------------------
