Date: Wed, 09 May 2001 16:59:53 -0700 From: Dima Dorfman <dima@unixfreak.org> To: John Baldwin <jhb@FreeBSD.org> Cc: Robert Watson <rwatson@FreeBSD.org>, Kris Kennaway <kris@obsecurity.org>, freebsd-current@FreeBSD.org, Dag-Erling Smorgrav <des@ofug.org> Subject: Re: pgm to kill 4.3 via vm Message-ID: <20010509235953.B15453E0B@bazooka.unixfreak.org> In-Reply-To: <XFMail.010509092102.jhb@FreeBSD.org>; from jhb@FreeBSD.org on "Wed, 09 May 2001 09:21:02 -0700 (PDT)"
next in thread | previous in thread | raw e-mail | index | archive | help
[ -stable dropped from cc list ] John Baldwin <jhb@FreeBSD.org> 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. Thanks, Dima Dorfman dima@unixfreak.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010509235953.B15453E0B>