[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f207f395-2fce-45da-a2ba-fba322fd226a@sirena.org.uk>
Date: Thu, 8 Jun 2023 17:04:04 +0100
From: Mark Brown <broonie@...nel.org>
To: Mark Rutland <mark.rutland@....com>
Cc: Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Anders Roxell <anders.roxell@...aro.org>,
Naresh Kamboju <naresh.kamboju@...aro.org>
Subject: Re: [PATCH] arm64/fpsimd: Exit streaming mode when flushing tasks
On Thu, Jun 08, 2023 at 04:51:26PM +0100, Mark Rutland wrote:
> On Wed, Jun 07, 2023 at 09:30:51PM +0100, Mark Brown wrote:
> > fpsimd_flush_thread_vl(ARM64_VEC_SME);
> > current->thread.svcr = 0;
> > + sme_smstop_sm();
> I don't think we should blindly do this if we never expect to get here in that
> state; this is just going to mask bugs and make them harder to debug going
> forwards.
> If we need this, it'd be better to have something like:
> if (WARN_ON_ONCE(sme_is_in_streaming_mode()))
> sme_smstop_sm();
> ... so that we can identify this case and fix it.
No, being here in streaming mode is valid so that check would be wrong -
if there is an issue the issue would be that we're expecting that any
further use of the register state would involve reloading from memory
but there would be some path where we end up doing something that uses
the in register state again rather than reloading. The change ensures
that the saved and register states are in sync so that can't go wrong,
meaning we don't need to go confirm if there's such a path.
Though now I look again we should do a full SMSTOP since a similar
concern applies to ZA.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists