Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 8 May 2001 23:31:51 -0400 (EDT)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        Dag-Erling Smorgrav <des@ofug.org>, freebsd-current@FreeBSD.org, freebsd-stable@frebsd.org, Kris Kennaway <kris@obsecurity.org>, Dennis Glatting <dennis.glatting@software-munitions.com>, tlambert2@mindspring.com
Subject:   Re: pgm to kill 4.3 via vm
Message-ID:  <Pine.NEB.3.96L.1010508232842.11741p-100000@fledge.watson.org>
In-Reply-To: <XFMail.010508164650.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

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 :-).

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010508232842.11741p-100000>