Re: witness oddity

John Baldwin writes:
 > On Friday 10 September 2004 02:18 pm, Andrew Gallatin wrote:
 > > John-Mark Gurney writes:
 > >  > Andrew Gallatin wrote this message on Fri, Sep 10, 2004 at 13:18 -0400:
 > >  > > If I call copyout() holding one of my mutexes, it will always complain
 > >  > > about a LOR, even if the mutex is freshly initiated:
 > >  >
 > >  > Calling copyout while holding a mutex is not allowed...  If the page
 > >  > isn't in memory, it could take many seconds for the page to be swapped
 > >  > back in during which time your mutex will continue to be held.
 > >
 > > Thanks.. but that's not really what I asked.
 > >
 > > I want to know how witness detects a particular just-created mutex as
 > > being in a deadlock with the vm map lock.
 > >
 > > Again, is it because the vm lock is an sx lock?  Is there an implicit
 > > rule that you can't take an sx lock while holding a mutex (just like
 > > you can't take Giant, or sleep?)
 > 
 > Yes.  An sx lock is allowed to be held across a sleep, so if you block on an 
 > sx lock, the owner of the lock you are waiting on might be asleep.  If that 

Do you agree that the message that Witness emits ("lock order
reversal") for this problem is, while technically accurate, is at
least a little confusing?  Before I thought to try the
mtx_init()/mtx_lock/()/copyout() trick, I spent quite a while scanning
my code, looking for some way the VM system could call into it and
acquire that lock.  There aren't any.

Does witness know at the time that it emits the warning that its a
"class" type of reversal, rather than a reversal based on previous
observations?  If so, would it be possible to emit a warning saying
something like "Holding a sleep mutex while acquiring an sx lock is
probited by law" (maybe add " violators will be shot" for grins ;)

Thanks,

Drew