From owner-freebsd-current Wed May 9 10:47:58 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 D948837B424; Wed, 9 May 2001 10:47:54 -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 f49Hlnf90676; Wed, 9 May 2001 13:47:49 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 9 May 2001 13:47:49 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: John Baldwin Cc: tlambert2@mindspring.com, Dennis Glatting , Kris Kennaway , freebsd-stable@frebsd.org, freebsd-current@FreeBSD.org, Dag-Erling Smorgrav Subject: Re: pgm to kill 4.3 via vm In-Reply-To: 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, John Baldwin wrote: > I am more worried about the fact that you can deadlock the debugger. > What does the debugger do if another process hold the proc lock on the > process you want to kill? Cute, eh? The debugger is an extra special > environment. Most of the time you've panic'ed when you are in there > (but then the panicstr tests that skip lock operations save you from > that). Also, in the debugger you know that no other threads are > running. This is why 'show pcpu' can list spin locks on other cpu's > safely, for example. I'm not sure if a ddb 'kill' command shouldn't be > better implemented using a 'trylock' and refusing to send the signal if > it can't get the lock so it can avoid doing really bad things. I > suppose it wouldn't deadlock but would switch to the other task and > start running. Of course, this would be most disastrous if the current > task we just dropped to the debugger in holds a spin lock. :( It sounds like what people really want is a kernel supervisor running on a vty, perhaps ttyv8 or something, which is a kernel process and not a user process, and is less prone to failure than a root shell, and hence less likely to get deadlocked on vnodes, etc, etc, which would offer some simple management primitives in the form of "signal process to death", "call boot(0)", etc. This kernel process would obey locking requirements for its operations, but would have no services that could potentially be blocked on a vnode lock, would always be in memory, etc, making highly available. However, it sounds like the trylock solution for ddb is a lot better than ignoring the lock and introducing nastiness that way. 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