mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: linux-kernel@vger.kernel.org, ralf@linux-mips.org,
	macro@linux-mips.org, akpm@osdl.org, roland@redhat.com,
	dev@sw.ru, Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: [PATCH] more sigkill priority fix
Date: Mon, 19 Sep 2005 10:24:23 +0200	[thread overview]
Message-ID: <20050919082423.GB15034@osiris.boeblingen.de.ibm.com> (raw)
In-Reply-To: <20050917.011715.41182516.anemo@mba.ocn.ne.jp>

> anemo> On Linux/MIPS, a simple test program can create unkillable
> anemo> process.  The "sigkill priority fix" was introduced in 2.6.12,
> anemo> but it does not effective for signals sent by force_sig() in
> anemo> kernel.  For detailed behavior and testcase, please look at
> anemo> this thread in linux-mips ML:
> 
> This is fixed by another way in 2.6.14-rc1 for i386 (Thanks, Roland).
> The changelog line is:
> 
> >    [PATCH] i386: Don't miss pending signals returning to user mode after signal processing
> >    Signed-off-by: Roland McGrath <roland@redhat.com>
> 
> And now similar fix for mips is already in Linux/MIPS CVS tree too.
> 
> --- linux-mips/arch/mips/kernel/entry.S	2005-03-04 22:17:29.000000000 +0900
> +++ linux/arch/mips/kernel/entry.S	2005-09-16 01:04:52.365022536 +0900
> @@ -105,7 +105,7 @@
>  	move	a0, sp
>  	li	a1, 0
>  	jal	do_notify_resume	# a2 already loaded
> -	j	restore_all
> +	j	resume_userspace
>  
>  FEXPORT(syscall_exit_work_partial)
>  	SAVE_STATIC
> 
> 
> I suppose the original problem on s390 (reported by Heiko Carstens)
> could be fixed same way.  Then 'sigkill priority fix' would be
> reverted safely.

If I understand the two arch changes correctly then this means that before
going back to userspace always _all_ pending signals will be delivered.
Of course this would fix the original problem and the 'sigkill priority fix'
could be reverted, if all architectures would implement this behaviour.
Is this the way the kernel is supposed to handle signals now?
Just wondering, since this changes signal handling quite significantly from
what it was before.

Heiko

  reply	other threads:[~2005-09-19  8:24 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-07 16:24 Atsushi Nemoto
2005-09-16 16:17 ` Atsushi Nemoto
2005-09-19  8:24   ` Heiko Carstens [this message]
2005-09-19  8:46     ` Roland McGrath
2005-09-19  8:57       ` Martin Schwidefsky
2005-09-19  9:08         ` Roland McGrath

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050919082423.GB15034@osiris.boeblingen.de.ibm.com \
    --to=heiko.carstens@de.ibm.com \
    --cc=akpm@osdl.org \
    --cc=anemo@mba.ocn.ne.jp \
    --cc=dev@sw.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=macro@linux-mips.org \
    --cc=ralf@linux-mips.org \
    --cc=roland@redhat.com \
    --cc=schwidefsky@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®