All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joey Gouly <joey.gouly@arm.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com,
	james.morse@arm.com, maz@kernel.org, will@kernel.org, nd@arm.com
Subject: Re: [PATCH v2 02/19] arm64: entry: unmask IRQ+FIQ after EL0 handling
Date: Tue, 25 May 2021 17:45:24 +0100	[thread overview]
Message-ID: <20210525164524.GP35816@e124191.cambridge.arm.com> (raw)
In-Reply-To: <20210519123902.2452-3-mark.rutland@arm.com>

On Wed, May 19, 2021 at 01:38:45PM +0100, Mark Rutland wrote:
> For non-fatal exceptions taken from EL0, we expect that at some point
> during exception handling it is possible to return to a regular process
> context with all exceptions unmasked (e.g. as we do in
> do_notify_resume()), and we generally aim to unmask exceptions wherever
> possible.
> 
> While handling SError and debug exceptions from EL0, we need to leave
> some exceptions masked during handling. Handling SError requires us to
> mask SError (which also requires masking IRQ+FIQ), and handing debug
> exceptions requires us to mask debug (which also requires masking
> SError+IRQ+FIQ).
> 
> Once do_serror() or do_debug_exception() has returned, we no longer need
> to mask exceptions, and can unmask them all, which is what we did prior
> to commit:
> 
>   9034f6251572a474 ("arm64: Do not enable IRQs for ct_user_exit")
> 
> ... where we had to mask IRQs as for context_tracking_user_exit()
> expected IRQs to be masked.
> 
> Since then, we realised that our context tracking wasn't entirely
> correct, and reworked the entry code to fix this. As of commit:
> 
>   23529049c6842382 ("arm64: entry: fix non-NMI user<->kernel transitions")
> 
> ... we consistently call context_tracking_user_exit() later as part of
> ret_to_user. Prior to this we can transiently unmask exceptions (e.g. as
> part of do_notify_resume), and we always mask all exceptions prior to
> calling context_tracking_user_exit().
> 
> Thus, there's no longer a reason to leave IRQs or FIQs masked at the end
> of el0_dbg() or el0_error(), so let's bring these into line with other
> EL0 exceptions handlers and unmask all exceptions after the handler is
> finished.
> 

We discussed some changes to the commit message offline, otherwise:

Reviewed-by: Joey Gouly <joey.gouly@arm.com>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-05-25 17:03 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-19 12:38 [PATCH v2 00/19] arm64: entry: migrate more code to C Mark Rutland
2021-05-19 12:38 ` [PATCH v2 01/19] arm64: remove redundant local_daif_mask() in bad_mode() Mark Rutland
2021-05-21 10:39   ` Joey Gouly
2021-05-19 12:38 ` [PATCH v2 02/19] arm64: entry: unmask IRQ+FIQ after EL0 handling Mark Rutland
2021-05-25 16:45   ` Joey Gouly [this message]
2021-05-19 12:38 ` [PATCH v2 03/19] arm64: entry: convert SError handlers to C Mark Rutland
2021-05-25 13:38   ` Joey Gouly
2021-05-19 12:38 ` [PATCH v2 04/19] arm64: entry: move arm64_preempt_schedule_irq to entry-common.c Mark Rutland
2021-05-21 11:00   ` Joey Gouly
2021-05-19 12:38 ` [PATCH v2 05/19] arm64: entry: move preempt logic to C Mark Rutland
2021-05-25 12:50   ` Joey Gouly
2021-05-19 12:38 ` [PATCH v2 06/19] arm64: entry: add a call_on_irq_stack helper Mark Rutland
2021-05-19 14:46   ` Mark Rutland
2021-05-19 12:38 ` [PATCH v2 07/19] arm64: entry: convert IRQ+FIQ handlers to C Mark Rutland
2021-05-21 13:19   ` Joey Gouly
2021-05-21 15:23     ` Mark Rutland
2021-05-19 12:38 ` [PATCH v2 08/19] arm64: entry: organise entry handlers consistently Mark Rutland
2021-05-21 16:04   ` Joey Gouly
2021-05-19 12:38 ` [PATCH v2 09/19] arm64: entry: organise entry vectors consistently Mark Rutland
2021-05-21 16:07   ` Joey Gouly
2021-05-19 12:38 ` [PATCH v2 10/19] arm64: entry: consolidate EL1 exception returns Mark Rutland
2021-05-21 16:22   ` Joey Gouly
2021-05-19 12:38 ` [PATCH v2 11/19] arm64: entry: move bad_mode() to entry-common.c Mark Rutland
2021-05-21 16:46   ` Joey Gouly
2021-05-19 12:38 ` [PATCH v2 12/19] arm64: entry: improve bad_mode() Mark Rutland
2021-05-21 17:02   ` Joey Gouly
2021-05-21 17:10     ` Mark Rutland
2021-05-19 12:38 ` [PATCH v2 13/19] arm64: entry: template the entry asm functions Mark Rutland
2021-05-21 17:16   ` Joey Gouly
2021-05-19 12:38 ` [PATCH v2 14/19] arm64: entry: handle all vectors with C Mark Rutland
2021-05-21 15:59   ` Joey Gouly
2021-05-21 16:41     ` Mark Rutland
2021-05-19 12:38 ` [PATCH v2 15/19] arm64: entry: split bad stack entry Mark Rutland
2021-05-25 11:25   ` Joey Gouly
2021-05-19 12:38 ` [PATCH v2 16/19] arm64: entry: split SDEI entry Mark Rutland
2021-05-25 11:49   ` Joey Gouly
2021-05-19 12:39 ` [PATCH v2 17/19] arm64: entry: make NMI entry/exit functions static Mark Rutland
2021-05-21 17:21   ` Joey Gouly
2021-05-19 12:39 ` [PATCH v2 18/19] arm64: entry: don't instrument entry code with KCOV Mark Rutland
2021-05-19 12:39 ` [PATCH v2 19/19] arm64: idle: don't instrument idle " Mark Rutland

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=20210525164524.GP35816@e124191.cambridge.arm.com \
    --to=joey.gouly@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=james.morse@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=nd@arm.com \
    --cc=will@kernel.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.