On 09-May-01 Dima Dorfman wrote:
> [ -stable dropped from cc list ]
> John Baldwin <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> -- 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to