Re: kern/38273: "lockdebug_barrier: spin lock held" from ld_ataraid_start_raid0()

["Greg A. Woods" <woods%planix.com@localhost>]

The following reply was made to PR kern/38273; it has been noted by GNATS.

From: "Greg A. Woods" <woods%planix.com@localhost>
To: NetBSD GNATS <gnats-bugs%NetBSD.org@localhost>
Cc: NetBSD Kernel Bug People <kern-bug-people%netbsd.org@localhost>
Subject: Re: kern/38273: "lockdebug_barrier: spin lock held" from 
ld_ataraid_start_raid0()
Date: Fri, 25 Apr 2008 13:13:42 -0400

 I've been trying my hand at looking deeper at this problem but I'm
 having a difficult time figuring out which lock is which, and at this
 point I'm not even sure if the mutex_vector_enter() in the stack
 backtrace is the same as mutex_enter() in the source or not.
 
 The first line in ldstart() is:
 
        mutex_enter(&sc->sc_mutex);
 
 Then a little bit later, before any mutex_exit(&sc->sc_mutex) there's a
 call, through the sc_start function pointer, to the ld_ataraid_start_raid0()
 routine.
 
 The only locking I can see that ld_ataraid_start_raid0() does is:
 
                        mutex_enter(&cbp->cb_buf.b_vp->v_interlock);
 
 Is that the same lock as is used in ldstart(), i.e. the sc_mutex?
 
 Interestingly I see that before and after calling biodone(), ldstart()
 releases and then re-acquires the sc_mutex (if I'm interpreting this
 right):
 
                                mutex_exit(&sc->sc_mutex);
                                biodone(bp);
                                mutex_enter(&sc->sc_mutex);
 
 Should the same be done before calling the sc_start function?
 
 Or should ld_ataraid_start_raid0() not be doing any locking at all?
 
 -- 
                                                Greg A. Woods
                                                Planix, Inc.
 
 <woods%planix.com@localhost>     +1 416 489-5852 x122     
http://www.planix.com/