From nobody Thu Apr 9 17:54:12 2026 Received: from m16.mail.163.com (m16.mail.163.com [220.197.31.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1EE07364EA5; Tue, 3 Mar 2026 01:51:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.2 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772502689; cv=none; b=PnbOXGj/ISLk9ooxzgiRnVXXRkPsndlp78frH8Si9+E6b2/3qQcdt00mPtcBnMqAJN9qGYS9PtdeYepMbCAaGQbbMfDCZIgSVlXh55NtyuScpYRd9aiGOQoaLWEoJcWcAvCjL2HV5XstX1s8IcmRP9MgKXUf7kl6oNGUNmPH3Pw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772502689; c=relaxed/simple; bh=SrM78CwYmsi7NLly+zHTpsqAUqXmMmeX6ryp1zEhTfs=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=piNN1MLID+4fcETca/qZ41jZX6Tl1Oae5IldEmG9hKB8Qv72pzuJFgp+du1XCgYskjrEgqSV2GgPhsaKeKH6yulphi9UlQPXwecKp6cRMonkTkkq8NWHoZ14cwvG+ZM9Bx3A9Hoc6IIdZ8lPET9GOgrAVZmSJE5cdQdgPJZK0FA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=SETiF0PA; arc=none smtp.client-ip=220.197.31.2 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="SETiF0PA" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=XG FqIj6YZfW1vO9tfInL0Hqq+SBbiSTcDvtPlDVfVTs=; b=SETiF0PA/7QxTWYq+f oNxEix/ogwG70x+0DjA2gJJUyw+R1UV2kYeG8wuoTeesDv37nMmDK1+av9nosAEA DvNmLOzXfRULeisJCMScXD2zAP8LER0gxFCLb8Xk7JRwOb8PVgssdrsk74QQoJfv foBsqVPE1cqAvON/x8oK2GkoY= Received: from pek-lpg-core6.wrs.com (unknown []) by gzga-smtp-mtada-g1-3 (Coremail) with SMTP id _____wCnhCODPqZp1ezIOw--.34317S3; Tue, 03 Mar 2026 09:51:00 +0800 (CST) From: Rahul Sharma To: gregkh@linuxfoundation.org, stable@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Mark Rutland , Catalin Marinas , Marc Zyngier , Mark Brown , Will Deacon , Rahul Sharma Subject: [PATCH 6.12.y 1/2] arm64/fpsimd: signal: Mandate SVE payload for streaming-mode state Date: Tue, 3 Mar 2026 09:50:46 +0800 Message-Id: <20260303015047.2014999-2-black.hawk@163.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260303015047.2014999-1-black.hawk@163.com> References: <20260303015047.2014999-1-black.hawk@163.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: _____wCnhCODPqZp1ezIOw--.34317S3 X-Coremail-Antispam: 1Uf129KBjvJXoWxCry8AF4DtFyxJF18Wr4Uurg_yoW5ZFWrpr W7Kw1Yyr1UGF1fAa90vF4F9a95W34ft3W5WF93Ga48ZrW5JrZ8urnYyayqqryUGr93GryY qFyjqr40gayDt37anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0pR-AwxUUUUU= X-CM-SenderInfo: 5eoduy4okd4yi6rwjhhfrp/xtbC+QW0TmmmPoU7cgAA37 Content-Type: text/plain; charset="utf-8" From: Mark Rutland [ Upstream commit b465ace42620970e840c7aeb2c44a6e3b1002fec ] Non-streaming SVE state may be preserved without an SVE payload, in which case the SVE context only has a header with VL=3D=3D0, and all state can be restored from the FPSIMD context. Streaming SVE state is always preserved with an SVE payload, where the SVE context header has VL!=3D0, and the SVE_SIG_FLAG_SM flag is set. The kernel never preserves an SVE context where SVE_SIG_FLAG_SM is set without an SVE payload. However, restore_sve_fpsimd_context() doesn't forbid restoring such a context, and will handle this case by clearing PSTATE.SM and restoring the FPSIMD context into non-streaming mode, which isn't consistent with the SVE_SIG_FLAG_SM flag. Forbid this case, and mandate an SVE payload when the SVE_SIG_FLAG_SM flag is set. This avoids an awkward ABI quirk and reduces the risk that later rework to this code permits configuring a task with PSTATE.SM=3D=3D1 and fp_type=3D=3DFP_STATE_FPSIMD. I've marked this as a fix given that we never intended to support this case, and we don't want anyone to start relying upon the old behaviour once we re-enable SME. Fixes: 85ed24dad290 ("arm64/sme: Implement streaming SVE signal handling") Signed-off-by: Mark Rutland Cc: Catalin Marinas Cc: Marc Zyngier Cc: Mark Brown Cc: Will Deacon Reviewed-by: Mark Brown Link: https://lore.kernel.org/r/20250508132644.1395904-4-mark.rutland@arm.c= om Signed-off-by: Will Deacon Signed-off-by: Rahul Sharma --- arch/arm64/kernel/signal.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c index f7b05267a76b..2ff6af928426 100644 --- a/arch/arm64/kernel/signal.c +++ b/arch/arm64/kernel/signal.c @@ -391,6 +391,7 @@ static int restore_sve_fpsimd_context(struct user_ctxs = *user) unsigned int vl, vq; struct user_fpsimd_state fpsimd; u16 user_vl, flags; + bool sm; =20 if (user->sve_size < sizeof(*user->sve)) return -EINVAL; @@ -400,7 +401,8 @@ static int restore_sve_fpsimd_context(struct user_ctxs = *user) if (err) return err; =20 - if (flags & SVE_SIG_FLAG_SM) { + sm =3D flags & SVE_SIG_FLAG_SM; + if (sm) { if (!system_supports_sme()) return -EINVAL; =20 @@ -420,7 +422,16 @@ static int restore_sve_fpsimd_context(struct user_ctxs= *user) if (user_vl !=3D vl) return -EINVAL; =20 - if (user->sve_size =3D=3D sizeof(*user->sve)) { + /* + * Non-streaming SVE state may be preserved without an SVE payload, in + * which case the SVE context only has a header with VL=3D=3D0, and all + * state can be restored from the FPSIMD context. + * + * Streaming SVE state is always preserved with an SVE payload. For + * consistency and robustness, reject restoring streaming SVE state + * without an SVE payload. + */ + if (!sm && user->sve_size =3D=3D sizeof(*user->sve)) { clear_thread_flag(TIF_SVE); current->thread.svcr &=3D ~SVCR_SM_MASK; current->thread.fp_type =3D FP_STATE_FPSIMD; --=20 2.34.1