From owner-freebsd-audit Mon Nov 26 9:43:43 2001 Delivered-To: freebsd-audit@freebsd.org Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by hub.freebsd.org (Postfix) with ESMTP id 03DDB37B416 for ; Mon, 26 Nov 2001 09:43:32 -0800 (PST) Received: (qmail 28850 invoked from network); 26 Nov 2001 17:43:31 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 26 Nov 2001 17:43:31 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20011126163445.24CC43EC8@bazooka.trit.org> Date: Mon, 26 Nov 2001 09:43:30 -0800 (PST) From: John Baldwin To: Dima Dorfman Subject: RE: DDB 'kill' command Cc: audit@freebsd.org Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 26-Nov-01 Dima Dorfman wrote: > The attached patch implements a 'kill' command in DDB. Previously, it > was possible to do `call psignal(xxx,yyy)` and have it DTRT. (This > was very useful when you accidently got your system so deep in the > hole that spawning kill(1) takes forever and even then possibly > doesn't succeed.) However, psignal() doesn't respect locking by > itself, so trying that now leads to all kinds of badness. This patch > basically wraps the psignal() call in a 'kill' command that respects > all necessary locks. > > Actually, it isn't very clear exactly which locks it should respect. > The debugger is a special case in this way. This patch uses the > PROC_TRYLOCK macro; if it fails, the command bails out. Thus, it > can't use pfind()--the latter automatically does a PROC_LOCK--so it > has to walk the allproc list manually. It does *not* attempt to get a > shared lock on the allproc list. There is similar code in db_trace.c, > and it doesn't call sx_slock(), either; I asked jhb about this a while > ago, and all he said was that it is intentional. > > Please review. Looks fine. The lack of locks and using a trylock is indeed intentional since you can't block in the debugger. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message