Re: witness oddity

From: Andrew Gallatin (gallatin_at_cs.duke.edu)
Date: 09/10/04

  • Next message: Julian Elischer: "Re: setrunqueue() panic" 
    Date: Fri, 10 Sep 2004 15:32:05 -0400 (EDT)
To: John Baldwin <jhb@FreeBSD.org>

    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

    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: Julian Elischer: "Re: setrunqueue() panic"

    Relevant Pages

    • Re: How to wait for multiple threads simultaneously?
      ... A 'condition variable' is the userland-equivalent of a sleep channel ... wait queue to be not worth the effort. ... It simply requires that the lock function not ... because a 'POSIX spin lock' would not ...
      (comp.os.linux.development.apps)
    • Re: Locking etc. (Long, boring, redundant, newbie questions)
      ... What is really meant is that depending on the type of mutex a thread is trying to acquire, the thread will either spin or it will sleep waiting for the lock to become available. ...
      (freebsd-hackers)
    • Re: How to do proper locking
      ... >> refcount reads and no refcount writes. ... Yes, you are right, but the problem is, that for most callback systems in the ... worries about having to exit a lock before returning. ... call any function that can sleep, without worrying about exiting any locks. ...
      (freebsd-hackers)
    • Locking etc. (Long, boring, redundant, newbie questions)
      ... sleep waiting for the lock to become available. ... mutex protects. ... if we spin for so long ...
      (freebsd-hackers)
    • Re: msleep() on recursivly locked mutexes
      ... mtx_drop_recurse(struct mtx *mtx) ... Further the idea that holding a mutex "except for when we sleep" is a generally bright idea is also a bit odd to me.. ... while you slept. ... It seems to me that if someone else held that lock for some purpose when you slept, ...
      (freebsd-hackers)