All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave.Martin@arm.com (Dave Martin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: signal: don't force known signals to SIGKILL
Date: Tue, 17 Apr 2018 15:46:31 +0100	[thread overview]
Message-ID: <20180417144630.GG16308@e103592.cambridge.arm.com> (raw)
In-Reply-To: <20180416154501.56872-1-mark.rutland@arm.com>

On Mon, Apr 16, 2018 at 04:45:01PM +0100, Mark Rutland wrote:
> Since commit:
> 
>   a7e6f1ca90354a31 ("arm64: signal: Force SIGKILL for unknown signals in force_signal_inject")
> 
> ... any signal which is not SIGKILL will be upgraded to a SIGKILL be
> force_signal_inject(). This includes signals we do expect, such as
> SIGILL triggered by do_undefinstr().
> 
> Fix the check to use a logical AND rather than a logical OR, permitting
> signals whose layout is SIL_FAULT.
> 
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Fixes: a7e6f1ca90354a31 ("arm64: signal: Force SIGKILL for unknown signals in force_signal_inject")
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Dave Martin <dave.martin@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> ---
>  arch/arm64/kernel/traps.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> index ba964da31a25..1cb2749a72bf 100644
> --- a/arch/arm64/kernel/traps.c
> +++ b/arch/arm64/kernel/traps.c
> @@ -366,7 +366,7 @@ void force_signal_inject(int signal, int code, unsigned long address)
>  	}
>  
>  	/* Force signals we don't understand to SIGKILL */

Is it worth updating the comment here?

What's the rationale for this check?

IIRC the purpose of this is to ensure that any siginfo delivered to
userspace through this path is initialised correctly: so, either the
signal must be a SIL_FAULT signal (since that's what the subsequent code
initialises for) or SIGKILL (since userspace can't inspect the siginfo
post-mortem, so the initialisation doesn't matter in that case).


Maybe moving this check before the switch() would make the logic
clearer.  Not sure though.

> -	if (WARN_ON(signal != SIGKILL ||
> +	if (WARN_ON(signal != SIGKILL &&
>  		    siginfo_layout(signal, code) != SIL_FAULT)) {
>  		signal = SIGKILL;
>  	}

[...]

Cheers
---Dave

  reply	other threads:[~2018-04-17 14:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-16 15:45 [PATCH] arm64: signal: don't force known signals to SIGKILL Mark Rutland
2018-04-17 14:46 ` Dave Martin [this message]
2018-04-18 11:36   ` Mark Rutland
2018-04-18 13:33     ` Dave Martin
2018-04-18 13:44       ` Mark Rutland
2018-04-18 14:14 ` Catalin Marinas

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=20180417144630.GG16308@e103592.cambridge.arm.com \
    --to=dave.martin@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.