From owner-freebsd-current Thu May 10 8:54:14 2001 Delivered-To: freebsd-current@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 7C74D37B422; Thu, 10 May 2001 08:54:10 -0700 (PDT) (envelope-from john@baldwin.cx) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f4AFrFG84547; Thu, 10 May 2001 08:53:18 -0700 (PDT) (envelope-from john@baldwin.cx) 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: <20010509235953.B15453E0B@bazooka.unixfreak.org> Date: Thu, 10 May 2001 08:52:20 -0700 (PDT) From: John Baldwin To: Dima Dorfman Subject: Re: pgm to kill 4.3 via vm Cc: Dag-Erling Smorgrav , freebsd-current@FreeBSD.org, Kris Kennaway , Robert Watson , John Baldwin Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 09-May-01 Dima Dorfman wrote: > [ -stable dropped from cc list ] > > John Baldwin writes: >> >> On 09-May-01 Robert Watson wrote: >> > >> > On Tue, 8 May 2001, John Baldwin wrote: >> > >> >> That's easy enough. Well, it used to be at least. You can use 'ps' to >> >> find the address of the struct proc (first pointer in the display) and >> >> then do 'call psignal(addr, 9)' to send SIGKILL to the process. Then >> >> hit 'c' to continue and voila, the process dies. I think that may panic >> >> now due to proc lock not being held (though the debugger shouldn't need >> >> any locks in theory.) Perhaps mtx_assert() should honor db_active and >> >> not panic if it is set. >> > >> > I followed everything here fine until you asserted that the debugger >> > shouldn't need any locks. I guess I don't see why that is, at least in >> > terms of not corrupting structures. From a practical perspective, the >> > debugger is like any other interupt-driven preemptive code-path: if you >> > want to modify a structure, you need to synchronize appropriately to avoid >> > corrupting the structure. This may not be something you really want to do >> > in a debugger, so in that sense perhaps you *shouldn't* grab a lock in the >> > debugger, but to perform the described action safely, you *should* grab a >> > lock so as not to corrupt fields of the proc structure (i.e., if you broke >> > into the debugger during a non-atomic flags update). Violating system >> > invariants is something you should be allowed to do in a debugger, but >> > this sounded like it was a feature people were looking from to recover >> > from unhappy behavior, not to introduce it :-). >> >> 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 > > I think this makes sense. How should this be implemented, though? > pfind() locks the process before returning (as you well know). Not > using pfind() will work, but that breaks the abstraction. Is that > something to worry about? There's also no PROC_TRYLOCK macro, but > that's not hard to fix. For the per-process tracing I didn't use pfind but just walked the allproc list myself. Using that in combo with a trylock might be your best bet. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message