From owner-freebsd-current Tue Jul 2 19:40:21 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2658F37B405 for ; Tue, 2 Jul 2002 19:40:11 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78B7E43E3D for ; Tue, 2 Jul 2002 19:40:07 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc03.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020703024006.FNNT903.sccrmhc03.attbi.com@InterJet.elischer.org>; Wed, 3 Jul 2002 02:40:06 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id TAA00100; Tue, 2 Jul 2002 19:30:55 -0700 (PDT) Date: Tue, 2 Jul 2002 19:30:54 -0700 (PDT) From: Julian Elischer To: Andrew Gallatin Cc: freebsd-current@freebsd.org Subject: Re: KSE signal problems still In-Reply-To: <15650.23048.273299.232384@grasshopper.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 2 Jul 2002, Andrew Gallatin wrote: > > Julian Elischer writes: > > try this: > > > > in tdsignal, (kern_sig.c) > > take a lock on schedlock and release it again, just around the call to > > forward-signal() > > > > forward_signal(c4445540) at forward_signal+0x1a > > tdsignal(c4445540,2,2) at tdsignal+0x182 > > psignal(c443d558,2) at psignal+0x3c8 > > > > hopefully this will not be called with the schedlock already locked > > > > Following your suggestion, the appended patch appears to work. > > However, it does seem a bit silly, as we end up dropping > and-reaquiring the sched lock quite a few times: That's why I just asked you to test the concept.. If I know that just aquiring it here is ok, (I presume you tried doing some work like this) that tells me that this code isn't called from some odd place, with the sched lock already set. (that and code inspection of course..) Now we know it works we can try optimise it.. I'm going home now for dinner, so if you feel like checking this or something mor optimal in, be my guest :-) > > mtx_unlock_spin(&sched_lock); > if (td->td_state == TDS_RUNQ || > td->td_state == TDS_RUNNING) { > signotify(td->td_proc); /* grabs & releases sched_lock*/ > #ifdef SMP > if (td->td_state == TDS_RUNNING && td != curthread) { > mtx_lock_spin(&sched_lock); > forward_signal(td); > mtx_unlock_spin(&sched_lock); > } > #endif > } > goto out; > > > > Wouldn't it be cleaner if there was a signotify_locked () that > assumed you had the sched_lock held (and was called by signotify)? > > Drew > > > > > Index: kern_sig.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/kern_sig.c,v > retrieving revision 1.171 > diff -u -r1.171 kern_sig.c > --- kern_sig.c 29 Jun 2002 17:26:18 -0000 1.171 > +++ kern_sig.c 3 Jul 2002 01:48:35 -0000 > @@ -1543,8 +1543,11 @@ > td->td_state == TDS_RUNNING) { > signotify(td->td_proc); > #ifdef SMP > - if (td->td_state == TDS_RUNNING && td != curthread) > + if (td->td_state == TDS_RUNNING && td != curthread) { > + mtx_lock_spin(&sched_lock); > forward_signal(td); > + mtx_unlock_spin(&sched_lock); > + } > #endif > } > goto out; > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message