I've read through this, and see no issue...

+1

On 06/05/09 16:07, Rich.Brown at Sun.COM wrote:
> I'm sponsoring the following fast-track for Bob Mastors.
>
> This case is an update to PSARC 2007/456 Vnode Specific Data and adds
> a new field to the vnode structure (in sys/vnode.h): v_vsd_lock.
>
> The case seeks Minor binding which matches the binding of the original
> case.  The timer expires on June 12, 2009.
>
>
> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
> This information is Copyright 2009 Sun Microsystems
> 1. Introduction
>     1.1. Project/Component Working Name:
>        VSD locking update
>     1.2. Name of Document Author/Supplier:
>        Author:  Bob Mastors
>     1.3  Date of This Document:
>       05 June, 2009
> 4. Technical Description
>
> PSARC 2007/456 Vnode Specific Data was created to easily associate
> project specific data with a vnode.  The current implementation
> requires consumers of vsd_get() and vsd_set() to hold the vnode v_lock
> mutex across the calls.  However, vsd_set() may go to sleep on
> kmem_alloc().  This could cause the system to deadlock if the vnode had
> dirty pages that needed to be written.  This problem is described by:
>
>   6839233 VSD usage of v_lock could cause deadlock
>
> The solution adds a new mutex to vnode_t:
>
>     kmutex_t    v_vsd_lock;    /* protects v_vsd field */
>
> Consumers of vsd_get() and vsd_set() would hold v_vsd_lock across the
> calls instead of v_lock.  There are no lock ordering issues since the
> locks are independent and there is no reason to hold both simultaneously.
>
> Currently, the only ON consumer of vsd_get() and vsd_set() is NFS.
>
>     Exported Interfaces
>
>     Interface Name | Classification | Comments
>     =================================================================
>                    |                |
>     v_vsd_lock     | Consolidation  | New mutex in the vnode structure
>                    | Private        | to protect v_vsd field
>
> 6. Resources and Schedule
>     6.4. Steering Committee requested information
>       6.4.1. Consolidation C-team Name:
>               ON
>     6.5. ARC review type: FastTrack
>     6.6. ARC Exposure: open
>
>   


-- 
---------------------------------------------------------------------
Rick Matthews                           email: Rick.Matthews at sun.com
Sun Microsystems, Inc.                  phone:+1(651) 554-1518
1270 Eagan Industrial Road              phone(internal): 54418
Suite 160                               fax:  +1(651) 554-1540
Eagan, MN 55121-1231 USA                main: +1(651) 554-1500          
---------------------------------------------------------------------


Reply via email to