new patch for KDB command "kill"

[Zhang, Sonic]

Hi,

	OK, I fixed the first 2 problems you mentioned.

	As for the way to send signal in KDB, I have some concerns. If I use send_sig_info() in KDB, there are 2 possible dead locks within the code scale under send_sig_info(). Both are in file kernel/signal.c.

	One is what you mentioned:
	spin_lock_irqsave(&t->sigmask_lock, flags);

	The other is:
#ifdef CONFIG_SMP
	/*
	 * If the task is running on a different CPU 
	 * force a reschedule on the other CPU to make
	 * it notice the new signal quickly.
	 *
	 * The code below is a tad loose and might occasionally
	 * kick the wrong CPU if we catch the process in the
	 * process of changing - but no harm is done by that
	 * other than doing an extra (lightweight) IPI interrupt.
	 */
	spin_lock(&runqueue_lock);
	if (task_has_cpu(t) && t->processor != smp_processor_id())
		smp_send_reschedule(t->processor);
	spin_unlock(&runqueue_lock);
#endif /* CONFIG_SMP */	

	In order to skip these unnecessary lock code, I write the signal handling code myself. 
	I attached 2 patches, one uses send_sig_info(), the other keeps my own handling.

	Thanks.

	Sonic Zhang


-----Original Message-----
From: Keith Owens [mailto:kaos at sgi.com]
Sent: 2003?4?3? 16:16
To: Zhang, Sonic
Cc: KDB (E-mail)
Subject: Re: new patch for KDB command "kill" 


On Thu, 3 Apr 2003 09:21:22 +0800, 
"Zhang, Sonic" <sonic.zhang at intel.com> wrote:
>	The attachment is the patch for KDB command "kill".
>	usage:
>	kill <-signal> <pid>

You need to check the argument count in kdb_kill, otherwise kill with
no arguments will kill kdb :).

The test for valid numbers is wrong, you do not test endp against the
argument, you test is *endp is NUL.  See simple_strtol in kdb_md().
kdbgetularg() uses a different test because it has to handle
expressions.

Instead of coding all the signal handling yourself, can you use
kernel/signal.c:send_sig_info()?  send_sig_info handles all the cases
for stopped processes, run queues etc., using that routine means that
kdb is not sensitive to changes in signal code.  Do trylock on
t->sigmask_lock in kdb to see if you can get the process mask lock
before calling send_sig_info(), to avoid deadlock.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdb-kill-v4.0-2.4.20-common-2.patch
Type: application/octet-stream
Size: 2862 bytes
Desc: kdb-kill-v4.0-2.4.20-common-2.patch
Url : http://oss.sgi.com/pipermail/kdb/attachments/20030404/27676163/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdb-kill-v4.0-2.4.20-common-2-myhandling.patch
Type: application/octet-stream
Size: 4128 bytes
Desc: kdb-kill-v4.0-2.4.20-common-2-myhandling.patch
Url : http://oss.sgi.com/pipermail/kdb/attachments/20030404/27676163/attachment-0001.obj