Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 17 Apr 2002 13:27:48 -0400 (EDT)
From:      John Baldwin <jhb@FreeBSD.org>
To:        Robert Watson <rwatson@FreeBSD.org>
Cc:        Perforce Change Reviews <perforce@freebsd.org>
Subject:   RE: PERFORCE change 9913 for review
Message-ID:  <XFMail.20020417132748.jhb@FreeBSD.org>
In-Reply-To: <200204171559.g3HFxnJ05061@freefall.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On 17-Apr-2002 Robert Watson wrote:
> http://people.freebsd.org/~peter/p4db/chv.cgi?CH=9913
> 
> Change 9913 by rwatson@rwatson_tislabs on 2002/04/17 08:59:13
> 
>       Remove use of an SX lock to protect the MAC policy chain.  Instead,
>       use a mutex to protect the list in addition to a busy count.
>       Read-only consumers of the list (such as policy evaluation entry
>       points) will lock the mutex, increment the busy count, and release
>       the lock, prevent long-term holding of a lock and interference
>       with lock orders (as well as permitting recursion).  When done,
>       they'll grab the lock, decrement the busy count, and release it.
>       Exclusive consumers, such as those registering and unregistering
>       policies, grab the mutex, check that the busy count is zero,
>       and return EBUSY if it is.  They then hold the mutex for the
>       duration of the list modification, as well as the entry points for
>       module initialization and shutdown.  It may be eventually we need
>       two classes of busy to avoid that.
>       
>       Note: no waiting occurs if the list is busy and exclusive access
>       is required.  This means that kldloading a module can fail with
>       EBUSY if a policy check is occurring simultaneously.  As Giant
>       gets pushed down, this will become an issue.  Eventually, a CV
>       should be used to wake up consumers waiting on exclusive access
>       so that this does not occur.
>       
>       This commit gets rid of the various lock order warnings concerning
>       the MAC policy lock.

So basically you just reinvented sx locks but they don't get checked for lock
order reversals.  If possible, I think you should go back to using sx locks but
find out where the reversal is occuring and fix that.

You can use a sx_try_xlock() to handle the EBUSY case.

-- 

John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe p4-projects" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20020417132748.jhb>