re: Modules loading modules?

[matthew green <mrg%eterna.com.au@localhost>]

> 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.