From owner-freebsd-current Thu May 10 9:40:59 2001 Delivered-To: freebsd-current@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 1FEC837B423 for ; Thu, 10 May 2001 09:40:52 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f4AGegf06384; Thu, 10 May 2001 12:40:43 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Thu, 10 May 2001 12:40:42 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Garrett Wollman Cc: freebsd-current@FreeBSD.ORG Subject: Re: pgm to kill 4.3 via vm In-Reply-To: <200105092117.RAA74500@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 9 May 2001, Garrett Wollman wrote: > < said: > > > I followed everything here fine until you asserted that the debugger > > shouldn't need any locks. > > When the debugger is running, everything else should have been > forcibly halted. The process and signal-related structures may be inconsistent if the debugger disregards existing locks held over those structures. It does not matter if code is currently still executing, it matters that preemption can occur. The choices appear to be: 1) Disregard locks and risk corruption 2) Fail if a lock is held Note that in either case (1) or case (2), the debugger may need special code paths to implement services such as psignal() to indicate that locking is either not needed, or that it should fail rather than block/spin/... Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message