[PATCH 03/14] arm64/fpsimd: Remove redundant clearing of TIF_SVE

[Mark Brown]

On Fri, Apr 04, 2025 at 06:44:24PM +0100, Mark Rutland wrote:

> TIF_SVE implies that sve_state has been allocated. Barring specific
> transient periods (e.g. during changes to SVE/SME vector lengths), it is
> not valid for a task to have TIF_SVE set while sve_state is NULL.

> This was not taken into account in commit:

>   7559b7d7d651d397 ("arm64/sve: Better handle failure to allocate SVE register storage")

> As of that commit, sve_set_common() and restore_sve_fpsimd_context()
> clear TIF_SVE if sve_alloc() fails to allocate memory. In these cases
> TIF_SVE cannot legitimately have been set to begin with, and clearing
> TIF_SVE only serves to complicate the code. No other code paths clear
> TIF_SVE if sve_alloc() fails to allocate memory.

The OOM handling is all rather unfortunate, it's inconsistent and
there's definite issues.

In the case of sve_set_common() we might be changing the vector length,
in which case vec_set_vector_length() will have attempted to reallocate
the SVE state buffer.  It does not check that the buffer was allocated
so won't return an error, and the sve_alloc() we do in sve_set_common()
to flush the prior state would then actually try to do an allocation
rather than flushing and so could potentially fail.  We should handle
this in vec_set_vector_length() and/or sve_alloc() itself though which
would mean that this change would be fine.

In the case of restore_sve_fpsimd_context() we don't support vector
length changes via sigreturn so there's no issue, if the user is
enabling SVE for the first time we won't set TIF_SVE until later.

> Remove the unnecessary and confusing clearing of TIF_SVE, and remove the
> similarly unnecessary and confusing update of the saved fp_type.

The update to the saved fp_type should go into the called functions too,
if we ended up in a situation where we don't have a SVE state buffer we
should ensure we don't try to load from it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20250404/0aaa2bf1/attachment.sig>