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

From: Andrew Doran <ad@netbsd.org>
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
Cc: mrg@eterna.com.au, gnats-bugs@NetBSD.org
Subject: Re: PR/32962
Date: Thu, 2 Nov 2006 18:06:53 +0000

 Hi,
 
 On Fri, Nov 03, 2006 at 01:06:40AM +0900, YAMAMOTO Takashi wrote:
 
 > > --- kern/kern_lwp.c	1 Nov 2006 10:17:58 -0000	1.48
 > > +++ kern/kern_lwp.c	1 Nov 2006 19:06:26 -0000
 > 
 > i don't think this makes differences.
 
 The only things I would count on the sched_lock to protect reliably at the
 moment are the run queues. We need the kernel_lock to do sleep or wakeup.
 
 > > --- kern/kern_sig.c	1 Nov 2006 10:17:58 -0000	1.235
 > > +++ kern/kern_sig.c	1 Nov 2006 19:06:28 -0000
 >
 > does it mean protecting signal states by kernel_lock?
 
 Yup, we can't run it unlocked. There are other problems with the signal
 code, e.g. some parts are not interrupt safe.
  
 > > --- kern/kern_synch.c	1 Nov 2006 10:17:58 -0000	1.171
 > > +++ kern/kern_synch.c	1 Nov 2006 19:06:29 -0000
 >
 > why do you want to keep spl at splsched?
 
 At this point, the LWP is on a sleep queue but is in the LSONPROC state.
 Lowering the SPL may allow device interrupts in, which may cause wakeup() to
 be called. If the wakeup() happens against the same sleep queue, this will
 trigger a DIAGNOSTIC asssertion because the LWP is on the queue, but is
 marked as ONPROC. We need the kernel lock held to stop other CPUs from
 calling wakeup() and triggering the same problem in the MP case.
 
 > [mi_switch]
 > 
 > is it necessary?
 > the code in question was out of kernel_lock even before the recent changes.
 
 Definitely. There is a substantial amount of work on the newlock2 branch
 aimed at addressing the above problems. 
 
 Thanks,
 Andrew