Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 8 Jun 2023 17:04:04 +0100
From:   Mark Brown <broonie@kernel.org>
To:     Mark Rutland <mark.rutland@arm.com>
Cc:     Catalin Marinas <catalin.marinas@arm.com>,
        Will Deacon <will@kernel.org>,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        Anders Roxell <anders.roxell@linaro.org>,
        Naresh Kamboju <naresh.kamboju@linaro.org>
Subject: Re: [PATCH] arm64/fpsimd: Exit streaming mode when flushing tasks
Message-ID: <f207f395-2fce-45da-a2ba-fba322fd226a@sirena.org.uk>
References: <20230607-arm64-flush-svcr-v1-1-7821a6199e0a@kernel.org>
 <ZIH4/kLTkvIN34FL@FVFF77S0Q05N>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="+qV82rKrOrzP4fh4"
Content-Disposition: inline
In-Reply-To: <ZIH4/kLTkvIN34FL@FVFF77S0Q05N>
Precedence: bulk


--+qV82rKrOrzP4fh4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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.

--+qV82rKrOrzP4fh4
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmSB+/MACgkQJNaLcl1U
h9D30Qf9HNaYiNl8I7Jcf99d1m8KO85jAobhM+72SBTN8edbhJglkTc2mRy9i9gC
e7DwDnjgOvmYLziVhkhuDm+CnAserbwhmvpWWUS42+SKNL3Hl4MRKxvh5T+kYRk2
bblrSpGEA6S763mejnHcG2LkvYZvSuUhh59TdE2aRjqLuxykZhbrphFZK7N8NMYx
2kIf2eZGn1C/y8DqssVBkj9a6rFyTI2oDSqFkLBvcuapRlqUbQLQHpqPPl3FhWu3
kFRd0Xp91uzxc9OosBtRsCM6eqGy/1wF7TiL5UxabwOiEjSL71F6J+LMRtj+77HH
LeiuDhu2wzXKYMeN5mxXwl/K51X15Q==
=2Lv0
-----END PGP SIGNATURE-----

--+qV82rKrOrzP4fh4--