Re: crashme on ARM - unkillable processes

[Russell King <rmk+lkml@arm.linux.org.uk>]

On Sun, Nov 09, 2003 at 09:43:27AM -0800, Linus Torvalds wrote:
> 
> On Sun, 9 Nov 2003, Russell King wrote:
> > 
> > Looking at next_signal(), the kernel treats signals 1-8 as having higher
> > priority than signal 9.  Since we only ever dequeue one signal on return
> > to user space, we always find the SIGILL before SIGKILL, and the kill
> > signal remains indefinitely queued.
> 
> Interesting. I wonder why it shows up only now. We've run crashme as a 
> sanity-test before, and I don't think this is a new thing..

Ok, I've been doing a bit more digging to work out what's going on.

The code which crashme generated corrupted the user stack pointer.  We
then tried to deliver a signal, found the user stack pointer invalid,
and tried to deliver a SEGV to the process via force_sig().  Unfortunately,
this signal never made it through for the reasons described previously.
(We dequeued the ILL, found we couldn't setup the stack frame, force_sig,
returned to userspace, generated another undefined instruction exception
on the same instruction, etc.)

So, not only is userspace not able to kill off processes with SIGKILL,
but the system can't kill off a process with a seriously corrupt stack.

Should the signal code be using something more forceful than force_sig()
(ie, something which is guaranteed to work) when the stack is corrupted ?

> This is definitely a bug. I'd be inclined to just special-case SIGKILL in 
> next_signal(). Better ideas?

>From the above, I think the problem is a little larger than just SIGKILL.

I think this problem happens on ARM because when we return to user space
after being unable to deliver a signal, we try to re-execute the illegal
instruction.  I believe on x86 this does not occur - it returns to the
next instruction.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core