Re: Embedding a vnode type to its interlock mutex type

From: John Baldwin (jhb_at_FreeBSD.org)
Date: 08/18/03

  • Next message: Technical Review Board: "[TRB] timer0 frequency change code removal"
    Date: Mon, 18 Aug 2003 14:38:31 -0400 (EDT)
    To: Bruce M Simpson <bms@spc.org>
    
    

    On 18-Aug-2003 Bruce M Simpson wrote:
    > On Mon, Aug 18, 2003 at 04:13:26PM +0900, Seigo Tanimura wrote:
    >> In short: A vnode should embed its type name (VREG, VCHR, etc.) in the
    >> type of the interlock mutex to avoid a false LOR alarm by Witness.
    >
    > I think I may have run into something similar with VM mutexes, but need
    > to sit down and perform more in-depth testing to be sure about this.
    >
    > It does appear as though WITNESS only checks the name of the mutex, not
    > the address of the mutex, which would presumably be a suitable key to
    > differentiate them uniquely.

    This is intentional. Assume I have a lock A and two processes P1 and
    P2 each with a mutex. Now assume the following code paths:

    foo(P)
    {
            ...
            lock(A);
            lock(P->p_mtx);
            ...
    }

    bar(P)
    {
            ...
            lock(P->p_mtx);
            lock(A)
            ...
    }

    And assume the following is executed:

            foo(P1)
            bar(P2)

    Should that be a lock order reversal? I think it should be, because
    bar() might be called on P1 later or foo() on P2. If you only use
    lock addresses, then witness will not catch that reversal. Witness
    intentionally defines orders between groups of locks. Note that
    you can provide witness with a different name besides the individual
    mutex name via the 3rd argument to mtx_init(). See the MTX_NETWORK_LOCK
    for example which is used as the class for all network driver locks.

    -- 
    John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
    "Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
    

  • Next message: Technical Review Board: "[TRB] timer0 frequency change code removal"

    Relevant Pages

    • Re: options WITNESS and locks
      ... Using the WITNESS kernel I cannot load my driver with any MTX_SPIN mutex. ... lock spin mutex does not match earlier (sleep ... It means that somewhere you are treating a mutex with that name as a sleep ...
      (freebsd-questions)
    • Re: Problem remains with FreeBSD 6.0-RC1 as seen in RELENG_5
      ... I've seen one report of a lock order reversal along these ... He'll need witness for 'show alllocks' but that will require having the ... 'hptlock' spin mutex added to witness' spin lock order. ... >> ACPI embedded controller ...
      (freebsd-current)
    • Re: options WITNESS and locks
      ... Using the WITNESS kernel I cannot load my driver with any MTX_SPIN mutex. ... lock spin mutex does not match earlier ... It means that somewhere you are treating a mutex with that name as a sleep mutex and in other places as a spin mutex. ...
      (freebsd-questions)
    • Re: -CURRENT spontaneously rebooting when using X
      ... mutex and now another thread wants that mutex. ... Try turning on witness as it will tell you when the first thread goes to sleep. ... one or the other has fixed my problem somehow. ... When I'm feeling brave enough I'll turn off witness again and see if the problem returns; I'll report back if it does... ...
      (freebsd-current)
    • Re: Embedding a vnode type to its interlock mutex type
      ... > type of the interlock mutex to avoid a false LOR alarm by Witness. ... It does appear as though WITNESS only checks the name of the mutex, ...
      (freebsd-arch)