linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Benjamin Gray <bgray@linux.ibm.com>, linuxppc-dev@lists.ozlabs.org
Cc: Benjamin Gray <bgray@linux.ibm.com>, ruscur@russell.cc
Subject: Re: [PATCH] powerpc/dexcr: Move HASHCHK trap handler
Date: Thu, 14 Sep 2023 23:55:18 +1000	[thread overview]
Message-ID: <87o7i47tbt.fsf@mail.lhotse> (raw)
In-Reply-To: <20230825014910.488822-1-bgray@linux.ibm.com>

Benjamin Gray <bgray@linux.ibm.com> writes:
> To determine if a trap was caused by a HASHCHK instruction, we inspect
> the user instruction that triggered the trap. However this may sleep
> if the page needs to be faulted in.

It would be good to include the output from the might_sleep() check that
failed.

And I think this was found by syzkaller? If so we should say so.

cheers

> Move the HASHCHK handler logic to after we allow IRQs, which is fine
> because we are only interested in HASHCHK if it's a user space trap.
>
> Fixes: 5bcba4e6c13f ("powerpc/dexcr: Handle hashchk exception")
> Signed-off-by: Benjamin Gray <bgray@linux.ibm.com>
> ---
>  arch/powerpc/kernel/traps.c | 56 ++++++++++++++++++++++++-------------
>  1 file changed, 36 insertions(+), 20 deletions(-)
>
> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> index f5ce282dc4b8..32b5e841ea97 100644
> --- a/arch/powerpc/kernel/traps.c
> +++ b/arch/powerpc/kernel/traps.c
> @@ -1512,23 +1512,11 @@ static void do_program_check(struct pt_regs *regs)
>  			return;
>  		}
>  
> -		if (cpu_has_feature(CPU_FTR_DEXCR_NPHIE) && user_mode(regs)) {
> -			ppc_inst_t insn;
> -
> -			if (get_user_instr(insn, (void __user *)regs->nip)) {
> -				_exception(SIGSEGV, regs, SEGV_MAPERR, regs->nip);
> -				return;
> -			}
> -
> -			if (ppc_inst_primary_opcode(insn) == 31 &&
> -			    get_xop(ppc_inst_val(insn)) == OP_31_XOP_HASHCHK) {
> -				_exception(SIGILL, regs, ILL_ILLOPN, regs->nip);
> -				return;
> -			}
> +		/* User mode considers other cases after enabling IRQs */
> +		if (!user_mode(regs)) {
> +			_exception(SIGTRAP, regs, TRAP_BRKPT, regs->nip);
> +			return;
>  		}
> -
> -		_exception(SIGTRAP, regs, TRAP_BRKPT, regs->nip);
> -		return;
>  	}
>  #ifdef CONFIG_PPC_TRANSACTIONAL_MEM
>  	if (reason & REASON_TM) {
> @@ -1561,16 +1549,44 @@ static void do_program_check(struct pt_regs *regs)
>  
>  	/*
>  	 * If we took the program check in the kernel skip down to sending a
> -	 * SIGILL. The subsequent cases all relate to emulating instructions
> -	 * which we should only do for userspace. We also do not want to enable
> -	 * interrupts for kernel faults because that might lead to further
> -	 * faults, and loose the context of the original exception.
> +	 * SIGILL. The subsequent cases all relate to user space, such as
> +	 * emulating instructions which we should only do for user space. We
> +	 * also do not want to enable interrupts for kernel faults because that
> +	 * might lead to further faults, and loose the context of the original
> +	 * exception.
>  	 */
>  	if (!user_mode(regs))
>  		goto sigill;
>  
>  	interrupt_cond_local_irq_enable(regs);
>  
> +	/*
> +	 * (reason & REASON_TRAP) is mostly handled before enabling IRQs,
> +	 * except get_user_instr() can sleep so we cannot reliably inspect the
> +	 * current instruction in that context. Now that we know we are
> +	 * handling a user space trap and can sleep, we can check if the trap
> +	 * was a hashchk failure.
> +	 */
> +	if (reason & REASON_TRAP) {
> +		if (cpu_has_feature(CPU_FTR_DEXCR_NPHIE)) {
> +			ppc_inst_t insn;
> +
> +			if (get_user_instr(insn, (void __user *)regs->nip)) {
> +				_exception(SIGSEGV, regs, SEGV_MAPERR, regs->nip);
> +				return;
> +			}
> +
> +			if (ppc_inst_primary_opcode(insn) == 31 &&
> +			    get_xop(ppc_inst_val(insn)) == OP_31_XOP_HASHCHK) {
> +				_exception(SIGILL, regs, ILL_ILLOPN, regs->nip);
> +				return;
> +			}
> +		}
> +
> +		_exception(SIGTRAP, regs, TRAP_BRKPT, regs->nip);
> +		return;
> +	}
> +
>  	/* (reason & REASON_ILLEGAL) would be the obvious thing here,
>  	 * but there seems to be a hardware bug on the 405GP (RevD)
>  	 * that means ESR is sometimes set incorrectly - either to
> -- 
> 2.41.0

  reply	other threads:[~2023-09-14 13:56 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-25  1:49 [PATCH] powerpc/dexcr: Move HASHCHK trap handler Benjamin Gray
2023-09-14 13:55 ` Michael Ellerman [this message]
2023-09-21  9:24 ` Michael Ellerman

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=87o7i47tbt.fsf@mail.lhotse \
    --to=mpe@ellerman.id.au \
    --cc=bgray@linux.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=ruscur@russell.cc \
    /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;
as well as URLs for NNTP newsgroup(s).