From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 19222C433EF for ; Thu, 5 May 2022 22:16:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-Id:Date:Subject:Cc :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=6u9ivTTlTmFFb0pAzceZxrfAPnNT+7xs3qOWk98o+CQ=; b=ZxS67bSFgZZ5Jv cPKUDwuNVygFK9F+uQXVaDkNRQ1sh+Aa7CmZpZ6F4zuZWW6Tj2NnMcGXFk/PYdVMzO8hq8lKA5Tzx s4A10KGSybo3P9GP6ppAXfoVnLg84OLKRTxSRZbDe7fSw7YTYTN3Ya3ut7Kx92U+sXWSzsj7h6hHw CBWn3Vyr5SJB4iYKQRDCksJTMDWL1VJ4jXpL6BwFtX6DzxjFaZJDeQQwhXCmGvqYNY8MjyfeS3duV U0xr3Mbp1X1vjoKI7f3pkTcEeSoPxqZ+srAJkUxxOpMPOjrI4XxopdqV947SjkbrIDjLbgSzS+HQP l1VniwQG/HhiWL8zgXQQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nmjlA-000NW5-4J; Thu, 05 May 2022 22:15:44 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nmjl7-000NVF-5G for linux-arm-kernel@lists.infradead.org; Thu, 05 May 2022 22:15:42 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E921561F31; Thu, 5 May 2022 22:15:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DD857C385A4; Thu, 5 May 2022 22:15:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651788937; bh=4JUC1i65YPtR8fv2nnApZ9fi/FG4znBcYEQVea2W240=; h=From:To:Cc:Subject:Date:From; b=r9yr96bxgKAD8k87wY2ZgSQTUxoyEq5DmXrwwqNxk6aPvZCEBfppSvptp1cxpSw9Y peEZqjlytRBarwONVxFAlnuCtLfG+ArImA6tFRugQvv/Znn+Xd40DDiXAKr4a3DDAX rxdalygOX9QrH3planSdlE6v1rIWfMMyeX1Ba/xf1JptYI7osp2Lh054VB9EWLkHCZ HwMfa7SlNwAgibZOyrF6eWULiZZXuqNfv6h+hG/qtkVmvCoad5/R5Pq6/0UXV1+BgO n9j3WYYYMFlkNDgG8u7+2OFKFneEPS7TUp8iKJZvQepwJjoXlBTUeT/ujMGz/bSEUl d6DvHFaaAUEuA== From: Mark Brown To: Catalin Marinas , Will Deacon Cc: linux-arm-kernel@lists.infradead.org, Naresh Kamboju , Mark Brown , Qian Cai Subject: [PATCH] arm64/sme: More sensibly define the size for the ZA register set Date: Thu, 5 May 2022 23:15:17 +0100 Message-Id: <20220505221517.1642014-1-broonie@kernel.org> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=3949; h=from:subject; bh=4JUC1i65YPtR8fv2nnApZ9fi/FG4znBcYEQVea2W240=; b=owEBbQGS/pANAwAKASTWi3JdVIfQAcsmYgBidEwQWuTbeqH4+ZBhve7VTe+zbJ2fgXIRvYrA5myZ IigM1kaJATMEAAEKAB0WIQSt5miqZ1cYtZ/in+ok1otyXVSH0AUCYnRMEAAKCRAk1otyXVSH0M18B/ 9rE54O374AbdHybzB+GRIAY5Lx//IwAhlXd152KbPWWuw/Xo2cl+bbkGeMX5TTIIeBCGqqkUmb/tqc 85bipiFiZAF3ABGYenl8hi0C5Fo+uxPNGGDugTSNeS4YJvGb9Js/vdLPqByak46Ds4HIFW6drG+k+p DOhYBaTzWzuMDW2aTuMKOjfIwEXyZvyctszqlqCuCe4gEkMxcrCHimT9umTkbHZySnR4yEDD6GHvqv qzEwJeQ2v+DHwWqzdHkJzpQZClDUh4NZKyWPH72SkQ0MNFYgz3dsH3cSGDn4LUulWip2GXfFDgz08f 7FFCDIJaygP5jwbo8KUn3IO7EWnYiS X-Developer-Key: i=broonie@kernel.org; a=openpgp; fpr=3F2568AAC26998F9E813A1C5C3F436CA30F5D8EB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220505_151541_317727_A069135C X-CRM114-Status: GOOD ( 22.49 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Since the vector length configuration mechanism is identical between SVE and SME we share large elements of the code including the definition for the maximum vector length. Unfortunately when we were defining the ABI for SVE we included not only the actual maximum vector length of 2048 bits but also the value possible if all the bits reserved in the architecture for expansion of the LEN field were used, 16384 bits. This starts creating problems if we try to allocate anything for the ZA matrix based on the maximum possible vector length, as we do for the regset used with ptrace during the process of generating a core dump. While the maximum potential size for ZA with the current architecture is a reasonably managable 64K with the higher reserved limit ZA would be 64M which leads to entirely reasonable complaints from the memory management code when we try to allocate a buffer of that size. Avoid these issues by defining the actual maximum vector length for the architecture and using it for the SME regsets. Also use the full ZA_PT_SIZE() with the header rather than just the actual register payload when specifying the size, fixing support for the largest vector lengths now that we have this new, lower define. With the SVE maximum this did not cause problems due to the extra headroom we had. While we're at it add a comment clarifying why even though ZA is a single register we tell the regset code that it is a multi-register regset. Reported-by: Qian Cai Signed-off-by: Mark Brown --- arch/arm64/include/asm/fpsimd.h | 12 ++++++++++++ arch/arm64/kernel/ptrace.c | 12 ++++++++++-- 2 files changed, 22 insertions(+), 2 deletions(-) diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h index 6fd879fe02da..aa11dbec0d70 100644 --- a/arch/arm64/include/asm/fpsimd.h +++ b/arch/arm64/include/asm/fpsimd.h @@ -32,6 +32,18 @@ #define VFP_STATE_SIZE ((32 * 8) + 4) #endif +/* + * When we defined the maximum SVE vector length we defined the ABI so + * that the maximum vector length included all the reserved for future + * expansion bits in ZCR rather than those just currently defined by + * the architecture. While SME follows a similar pattern the fact that + * it includes a square matrix means that any allocations that attempt + * to cover the maximum potential vector length (such as happen with + * the regset used for ptrace) end up being extremely large. Define + * the much lower actual limit for use in such situations. + */ +#define SME_VQ_MAX 16 + struct task_struct; extern void fpsimd_save_state(struct user_fpsimd_state *state); diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c index 78085a32df83..140f5a8cc7c4 100644 --- a/arch/arm64/kernel/ptrace.c +++ b/arch/arm64/kernel/ptrace.c @@ -1438,7 +1438,7 @@ static const struct user_regset aarch64_regsets[] = { #ifdef CONFIG_ARM64_SME [REGSET_SSVE] = { /* Streaming mode SVE */ .core_note_type = NT_ARM_SSVE, - .n = DIV_ROUND_UP(SVE_PT_SIZE(SVE_VQ_MAX, SVE_PT_REGS_SVE), + .n = DIV_ROUND_UP(SVE_PT_SIZE(SME_VQ_MAX, SVE_PT_REGS_SVE), SVE_VQ_BYTES), .size = SVE_VQ_BYTES, .align = SVE_VQ_BYTES, @@ -1447,7 +1447,15 @@ static const struct user_regset aarch64_regsets[] = { }, [REGSET_ZA] = { /* SME ZA */ .core_note_type = NT_ARM_ZA, - .n = DIV_ROUND_UP(ZA_PT_ZA_SIZE(SVE_VQ_MAX), SVE_VQ_BYTES), + /* + * ZA is a single register but it's variably sized and + * the ptrace core requires that the size of any data + * be an exact multiple of the configured register + * size so report as though we had SVE_VQ_BYTES + * registers. These values aren't exposed to + * userspace. + */ + .n = DIV_ROUND_UP(ZA_PT_SIZE(SME_VQ_MAX), SVE_VQ_BYTES), .size = SVE_VQ_BYTES, .align = SVE_VQ_BYTES, .regset_get = za_get, -- 2.30.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel