linux-mips
[Top] [All Lists]

Re: unkillable process due to setup_frame() failure

To: "Maciej W. Rozycki" <macro@linux-mips.org>
Subject: Re: unkillable process due to setup_frame() failure
From: Ralf Baechle <ralf@linux-mips.org>
Date: Wed, 7 Sep 2005 14:47:17 +0100
Cc: Atsushi Nemoto <anemo@mba.ocn.ne.jp>, linux-mips@linux-mips.org
In-reply-to: <Pine.LNX.4.61L.0509071011560.4591@blysk.ds.pg.gda.pl>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20050907.014234.108739386.anemo@mba.ocn.ne.jp> <20050906184118.GC3102@linux-mips.org> <Pine.LNX.4.61L.0509071011560.4591@blysk.ds.pg.gda.pl>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.4.2.1i
On Wed, Sep 07, 2005 at 10:14:16AM +0100, Maciej W. Rozycki wrote:

> > > So, the process can not be kill by SIGKILL.  In 2.6.12, 'sigkill
> > > priority fix' was applied to __dequeue_signal(), but it does not help
> > > while the SIGTRAP is queued to tsk->pending but SIGKILL (by kill
> > > command) is queued to tsk->signal->shared_pending.
> > 
> > The behaviour of not advancing the EPC beyond the faulting instruction is
> > part of the problem - but I believe that was the usual behaviour for
> > MIPS UNIXoid operating systems.
> 
>  Well, SIGKILL should always work and frankly I can't see a reason to 
> return back to user space in the affected context in the first place.  
> What's left in EPC shouldn't matter.

I said it's part of the problem - not that it should be changed.  The
behaviour as far as I can say is also standard for MIPS unixoid operating
systems.  That said, I definately prefer the approach of Atushi's suggested
fix #2.  The other question is why we try to continue if delivering a
signal failed and we already know that repeated attempts would fail again.

  Ralf

<Prev in Thread] Current Thread [Next in Thread>