[PATCH v3 02/20] arm64: entry: unmask IRQ+FIQ after EL0 handling
Will Deacon
will at kernel.org
Fri Jun 4 09:47:17 PDT 2021
On Tue, May 25, 2021 at 07:32:44PM +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 replaced the call to context_tracking_user_exit() with a call to
> user_exit_irqoff() as part of enter_from_user_mode(), which occurs
> earlier, before the we run the body of the handler and unmask exceptions
before the we run
> in DAIF.
>
> When we return to userspace, we go via ret_to_user(), which masks
> exceptions in DAIF prior to calling user_enter_irqoff() as part of
> exit_to_user_mode().
>
> Thus, there's no longer a reason to leave IRQs or FIQs masked at the end
> of the EL) debug or error handlers, as neither the user exit context
EL)
> tracking nor the user entry context tracking requires this. Let's bring
> these into line with other EL0 exceptions handlers and ensure that IRQ
exceptions handlers
Will
More information about the linux-arm-kernel
mailing list