From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 3F00F1F75BD; Tue, 3 Dec 2024 15:32:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733239949; cv=none; b=Rk/wTLOB3QebPZQtP7mN22qsCQRehvBJhlbD9NqdLoF/iHd8P6lJ19xjtcBuNR5U5dIvaBFxiovPNdrXWUUc4W3QRwNTsHeK22pAChmnIvOZT7HPfwXEVy+jQJx/ma/X3+tGP73eAlK7fo9JZyqBn79deEZ2atBDZWnkolJpUXM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733239949; c=relaxed/simple; bh=Gu+nl35448vAkGNYug2TUYI8gJBL+zCPISsT0TEt9eg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=elvDllwH+KJQqRUULRa3oj5d0nhtB1mjOY8lnB0V2G1hXRD0BKvqbmp0wbZmPj9buk71izu/2AHAC3zWv14cd4o4s5OGhwqo4BeRLC8Oe6haR2Xv5B6XGv2PKVji2CTes7kAX4MPU7FNGVSD9jYZKS8DwNjtkKWS+N4OO4Ls/D0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0213AFEC; Tue, 3 Dec 2024 07:32:54 -0800 (PST) Received: from e133380.arm.com (e133380.arm.com [10.1.197.37]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DE9793F71E; Tue, 3 Dec 2024 07:32:24 -0800 (PST) Date: Tue, 3 Dec 2024 15:32:22 +0000 From: Dave Martin To: Mark Brown Cc: Catalin Marinas , Will Deacon , Mark Rutland , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH 1/6] arm64/sme: Flush foreign register state in do_sme_acc() Message-ID: References: <20241203-arm64-sme-reenable-v1-0-d853479d1b77@kernel.org> <20241203-arm64-sme-reenable-v1-1-d853479d1b77@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241203-arm64-sme-reenable-v1-1-d853479d1b77@kernel.org> On Tue, Dec 03, 2024 at 12:45:53PM +0000, Mark Brown wrote: > When do_sme_acc() runs with foreign FP state it does not do any updates of > the task structure, relying on the next return to userspace to reload the > register state appropriately, but leaves the task's last loaded CPU > untouched. This means that if the task returns to userspace on the last > CPU it ran on then the checks in fpsimd_bind_task_to_cpu() will incorrectly > determine that the register state on the CPU is current and suppress reload > of the floating point register state before returning to userspace. This > will result in spurious warnings due to SME access traps occuring for the > task after TIF_SME is set. > > Call fpsimd_flush_task_state() to invalidate the last loaded CPU > recorded in the task, forcing detection of the task as foreign. > > Fixes: 8bd7f91c03d8 ("arm64/sme: Implement traps and syscall handling for SME") > Reported-by: Mark Rutlamd > Signed-off-by: Mark Brown > Cc: stable@vger.kernel.org > --- > arch/arm64/kernel/fpsimd.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c > index 8c4c1a2186cc510a7826d15ec36225857c07ed71..eca0b6a2fc6fa25d8c850a5b9e109b4d58809f54 100644 > --- a/arch/arm64/kernel/fpsimd.c > +++ b/arch/arm64/kernel/fpsimd.c > @@ -1460,6 +1460,8 @@ void do_sme_acc(unsigned long esr, struct pt_regs *regs) > sme_set_vq(vq_minus_one); > > fpsimd_bind_task_to_cpu(); > + } else { > + fpsimd_flush_task_state(current); TIF_FOREIGN_FPSTATE is (or was) a cache of the task<->CPU binding that you're clobbering here. So, this fpsimd_flush_task_state() should have no effect unless TIF_FOREIGN_FPSTATE is already wrong? I'm wondering if the apparent need for this means that there is an undiagnosed bug elsewhere. (My understanding is based on FPSIMD/SVE; I'm less familiar with the SME changes, so I may be missing something important here.) [...] Cheers ---Dave