Re: [PATCH v3 00/20] arm64: entry: migrate more code to C

From: Marc Zyngier <maz@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com,
	james.morse@arm.com, joey.gouly@arm.com, will@kernel.org
Subject: Re: [PATCH v3 00/20] arm64: entry: migrate more code to C
Date: Thu, 27 May 2021 16:31:38 +0100	[thread overview]
Message-ID: <87tumory5h.wl-maz@kernel.org> (raw)
In-Reply-To: <20210525183302.56293-1-mark.rutland@arm.com>

On Tue, 25 May 2021 19:32:42 +0100,
Mark Rutland <mark.rutland@arm.com> wrote:
> 
> This series (based on v5.13-rc2) migrates most of the remaining
> exception triage assembly to C. All the exception vectors are given C
> handlers, so that we can defer all decision making to C code, and the
> assembly code can be made simpler and more uniform. At the same time,
> I've tried to consolidate all the entry sequencing (e.g. reading
> exception registers and calling accounting code) in entry-common.c so
> that this is easier to maintain.
> 
> I was recently informed that `noinstr` wasn't protecting entry sequences
> from KCOV instrumentation, so I've refactored things so that we can
> avoid this by preventing KCOV instrumentation for the entirety of
> entry-common.c. I've done likewise for the low-level idle sequences
> which have the same problems with instrumentation when RCU isn't
> watching, etc.
> 
> I've stopped short of converting the ret_to_user / work_pending loop.
> Converting this cleanly will probably need something like the wrappers
> generated by SYSCALL_DEFINE() to handle the common entry/exit logic, and
> this is easier to build once all the handlers have been converted to C.
> Similar is true for portions of kernel_entry and kernel_exit that could
> be converted to C.
> 
> It should also be possible to generate the vectors and their associated
> assembly handlers in one go by placing these in separate sections and
> using .pushsection and .popsection. I've held off doing this for now as
> this probably requires some changes to the linker script, and regardless
> it should be easier to make that change atop this series.
> 
> So far this has seen some light boot testing, and a day's worth of fuzzing
> under Syzkaller, which I intend to leave to soak for a while.
> 
> I've pushed the series to my arm64/entry/rework branch on kernel.org:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/entry/rework
>   git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git arm64/entry/rework
> 
> I've tagged this version as arm64-entry-rework-20210525.
> 
> Since v1 [1]
> * Rebase to v5.13-rc2
> * Fold NMI entry/exit sequencing into entry-common.c
> * Make NMI entry/exit helpers private to entry-comomn.c
> * Prevent KCOV instrumentation of entry-common.c
> * Prevent KCOV instrumentation of idle code
> 
> Since v2 [2]:
> * Correct commit message description in patch 2
> * Use `el0t` prefix for EL0 handlers for consistency with `el1h` and `el1t`
> * Remove `user_exit_irqoff` macro
> * Remove leftover bad_mode() prototype
> * Add patch to replace el1_inv() with a direct call to __panic_unhandled()
> * Accumulate Reviewed-by tags
> * Typo fixes
> 
> [1] https://lore.kernel.org/r/20210510155621.52811-1-mark.rutland@arm.com
> [2] https://lore.kernel.org/r/20210519123902.2452-1-mark.rutland@arm.com

I've been through the patches and couldn't spot anything wrong,
although I had to apply the patches and look at the final result.
I also tested it lightly on a few odd machines, and nothing caught
fire. So FWIW:

Acked-by: Marc Zyngier <maz@kernel.org>

	M.

-- 
Without deviation from the norm, progress is not possible.

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