From: Mark Rutland <mark.rutland@arm.com>
To: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
linux-arm-kernel@lists.infradead.org, ardb@kernel.org,
broonie@kernel.org, maz@kernel.org
Subject: Re: [PATCH v2 00/13] arm64: Preparatory FPSIMD/SVE/SME fixes
Date: Wed, 30 Apr 2025 14:24:48 +0100 [thread overview]
Message-ID: <aBIkoNmrf02PyYds@J2N7QTR9R3> (raw)
In-Reply-To: <20250429194600.GA26883@willie-the-truck>
On Tue, Apr 29, 2025 at 08:46:01PM +0100, Will Deacon wrote:
> On Wed, Apr 09, 2025 at 06:17:09PM +0100, Catalin Marinas wrote:
> > On Wed, 09 Apr 2025 17:39:57 +0100, Mark Rutland wrote:
> > > These patches fix a number of problems in the FPSIMD/SVE/SME code, as a
> > > step towards re-enabling SME support. Additional fixes/changes will be
> > > necessary before we can re-enable SME support. I intend to follow up
> > > with more patches in the near future.
> > >
> > > I'm hoping these patches as-is are largely uncontroversial, though I'm
> > > afraid they've only seen light/targeted testing so far, so any testing
> > > would be much appreciated.
> > >
> > > [...]
> >
> > I added these patches to for-next/sme-fixes (and for-kernelci) for wider
> > exposure. Not queued for upstream yet, I need to review and discuss with
> > Will whether we target 6.15 or 6.16.
>
> FYI: I see the following warning from 'allnoconfig' with these patches
> applied:
>
>
> arch/arm64/kernel/fpsimd.c:676:13: warning: unused function 'sve_to_fpsimd' [-Wunused-function]
> 676 | static void sve_to_fpsimd(struct task_struct *task)
> | ^~~~~~~~~~~~~
> 1 warning generated.
Argh, sorry about this.
That's a side-effect of fpsimd_signal_preserve_current_state() being
removed in commit:
929fa99b1215966f ("arm64/fpsimd: signal: Always save+flush state early")
... since fpsimd_signal_preserve_current_state() was always defined and
would (conditionally) call sve_to_fpsimd().
> It's easy enough to move that inside the CONFIG_ARM64_SVE guards, but
> it's a little strange that fpsimd_to_sve() is more widely referenced
> and harder to move.
Yeah, this is a bit messy. I think no matter how we clean things up
we'll end up with a reference to fpsimd_to_sve() via do_sve_acc(). We
want do_sve_acc() to be defined regardless of CONFIG_ARM64_SVE so that
we get consistent trap/SIGILL behaviour when either CONFIG_ARM64_SVE=n
or SVE isn't supported by all PEs, and I don't think we want to move the
bulk of that logic under ifdeffery.
The simplest fix for now would be to mark fpsimd_to_sve() and
sve_to_fpsimd() as 'static inline' or '__maybe_unused', and the former
would be more consistent with the rest of the file.
I'll spin a fix shortly.
Mark.
prev parent reply other threads:[~2025-04-30 13:30 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-09 16:39 [PATCH v2 00/13] arm64: Preparatory FPSIMD/SVE/SME fixes Mark Rutland
2025-04-09 16:39 ` [PATCH v2 01/13] arm64/fpsimd: Avoid RES0 bits in the SME trap handler Mark Rutland
2025-04-09 16:39 ` [PATCH v2 02/13] arm64/fpsimd: Remove unused fpsimd_force_sync_to_sve() Mark Rutland
2025-04-09 17:32 ` Mark Brown
2025-04-09 16:40 ` [PATCH v2 03/13] arm64/fpsimd: Remove redundant SVE trap manipulation Mark Rutland
2025-04-09 16:40 ` [PATCH v2 04/13] arm64/fpsimd: Remove opportunistic freeing of SME state Mark Rutland
2025-04-09 16:40 ` [PATCH v2 05/13] arm64/fpsimd: Discard stale CPU state when handling SME traps Mark Rutland
2025-04-09 16:40 ` [PATCH v2 06/13] arm64/fpsimd: Don't corrupt FPMR when streaming mode changes Mark Rutland
2025-04-09 16:40 ` [PATCH v2 07/13] arm64/fpsimd: Avoid clobbering kernel FPSIMD state with SMSTOP Mark Rutland
2025-04-09 16:40 ` [PATCH v2 08/13] arm64/fpsimd: Reset FPMR upon exec() Mark Rutland
2025-04-09 16:40 ` [PATCH v2 09/13] arm64/fpsimd: Fix merging of FPSIMD state during signal return Mark Rutland
2025-04-09 16:40 ` [PATCH v2 10/13] arm64/fpsimd: Add fpsimd_save_and_flush_current_state() Mark Rutland
2025-04-09 16:40 ` [PATCH v2 11/13] arm64/fpsimd: signal32: Always save+flush state early Mark Rutland
2025-04-09 16:40 ` [PATCH v2 12/13] arm64/fpsimd: signal: " Mark Rutland
2025-04-09 16:40 ` [PATCH v2 13/13] arm64/fpsimd: signal: Simplify preserve_tpidr2_context() Mark Rutland
2025-04-09 17:17 ` [PATCH v2 00/13] arm64: Preparatory FPSIMD/SVE/SME fixes Catalin Marinas
2025-04-29 19:46 ` Will Deacon
2025-04-30 13:24 ` Mark Rutland [this message]
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=aBIkoNmrf02PyYds@J2N7QTR9R3 \
--to=mark.rutland@arm.com \
--cc=ardb@kernel.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox