From owner-freebsd-smp Fri Jun 23 8:56:45 2000 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 2FCBD37BA73 for ; Fri, 23 Jun 2000 08:56:41 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id IAA10465; Fri, 23 Jun 2000 08:56:35 -0700 (PDT) (envelope-from dillon) Date: Fri, 23 Jun 2000 08:56:35 -0700 (PDT) From: Matthew Dillon Message-Id: <200006231556.IAA10465@apollo.backplane.com> To: Bruce Evans Cc: Jason Evans , Greg Lehey , Warner Losh , The Hermit Hacker , freebsd-smp@FreeBSD.ORG Subject: Re: SP Patchset #1 up References: Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :> :> I don't follow. Why do I have a deadlock? This is SchedMutex I'm :> talking about here, not GiantMutex. : :mtx_enter_sched_quick() is mtx_enter(&SchedMutex, MTX_SPIN). : :| /* :| * mtx_enter() :| * ... :| * WARNING: DO NOT PUT KERNEL PRINTFS IN THE SPIN CODE!, you may :| * create a recursion. :| */ : :This warning gives another reason why ddb can't call locking functions. :Putting a breakpoint at a locking functions or wandering into a locking :function while single stepping will cause console i/o. A break point is a one-time deal. That'l work just fine. If the SchedMutex is already held then getting it again isn't going to hurt. If it isn't held then getting it the first time isn't going to hurt. The warning is there to avoid this situation: printf -> mtx_enter -> causes printf -> mtx_enter -> causes printf -> mtx_enter If we clear the break point prior to entering SchedMutex, then we don't have a recursion problem. :| static __inline void :| mtx_enter(struct mtx *mtp, int type) :| { :| u_int32_t newv; :| :| newv = (u_int32_t)curproc | MTF_HELD; :| if ((mtp->mtx_lock & ~MTF_CONTESTED) == newv) { : :Here is another reason why ddb can't call locking functions. curproc :may be in the middle of being switched when a debugger trap occurs, so :ddb can't call anything that depends on it being valid. SchedMutex may :be invalid for the same reason. SchedMutex is never invalid. No mutex is ever 'invalid'... they are locked in an atomic cmpexg. Either SchedMutex is held when the break point occurs, or it isn't. : :| ++mtp->mtx_recurse; /* bump recursion */ : :I'm not sure if this code is reached. If it is, then we don't have :deadlock but we have the same bugs as for spltty() -- recursion is not :prevented recursion although some console i/o routines don't support it. :Many levels of recursion are possible: : : printf in process context : --> interrupt ... printf in interrupt context : --> higher priority interrupt ... printf in interrupt context : ... even higher priority interrupts : --> debugger trap ... debugger printf : --> fatal trap for bug in printf ... bogus printfs (should longjmp) : --> double fault for bug in fatal trap handler ... final printfs I don't see the issue here. interrupts cannot nest SchedMutex - look at the interrupt code. At the moment interrupt can nest other interrupts only insofar as the new interrupt occuring before the old interrupt has obtained the giant mutex. :If switching from a high priority interrupt task to a low priority one is :allowed, then the first few levels don't need to be supported. I don't follow. The SchedMutex recursion count is saved and restored when a switch occurs. : :| } else { :| if (atomic_cmpexg_int(&mtp->mtx_lock, 0, newv) != 0) { :| if (type & MTX_SPIN) { :| _mtx_enter_spin(mtp, newv); : :If this code is reached, then it should spin for ever, since other tasks :should not run, even if there is another CPU for it to run on. If you place a debugger trap at a point where SchedMutex is held, guess which cpu the debugger takes the trap on? The one holding SchedMutex. Thus no problem... the debug trap will simply bump the recursion count of SchedMutex temporarily. :| } else { :| _mtx_enter_blocking(mtp, newv); :| } :| } :| mtp->mtx_type = type; /* set the type after obtaining */ :| } :| } : :Bruce The only thing we have to worry about insofar as debugger traps go is to be sure to clear the debug point prior to entering the SchedMutex within the debugger trap. I think this is trivial. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message