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 3FFDBC48BF6 for ; Thu, 29 Feb 2024 15:51:16 +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:References:In-Reply-To: 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: List-Owner; bh=I8nZ1bZ9r55OFGPGAclWSfB8uBtDD1kiY0QETpN73O8=; b=RxabrWnbIXReeS 0gU+UPLxzTuKZMF8RLaaybGn4xZ0+LGkCdJVYyf+w7m0hI7e+flE9ib20u4FGwWBIS6KgbzZw9bs7 v1k433Pdl4GCFkSN8tFsYBSzbiGO/sfnaCml3MT6rpXn7c8Ti1wMZzhZTUgDxXgxZ9gCLxM+tHS3k tUg47HJCYOf4DbG5hpzL91iQeZtXtstPmjpOT6JQbGg/EPJP00QAMnTB8Guo4FRyAGhP8My+en3oC unSgMZ31vfKUuTSmBGXaqJ3ig5IF0n7g5IQKi+rwSBoOPae8QlnUX1N/3yq+Hx9oNceV9ZORrUZdU +ZWCpu1OzWMv6GBcf04w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rfigS-0000000E89l-3e8H; Thu, 29 Feb 2024 15:50:56 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rfig2-0000000E7vh-39Yl for linux-arm-kernel@lists.infradead.org; Thu, 29 Feb 2024 15:50:33 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 327C7CE1ACF; Thu, 29 Feb 2024 15:50:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B0CA4C433B1; Thu, 29 Feb 2024 15:50:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709221827; bh=6BgAatx297f53qjeaozbUH9QQCAVrbUuVPn8wwTue4c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ilikQ2LvAQrOkuAYAuR1KzCDGRUuAc47kxqls35QSKY1k3f+XL9+zvlIJe7iPws5v BV2KVt15pkTd/D+rFtfgsgxzC+oNL0YEyaK8SewRSd3pEXPRCLoKhaAY70JdpyzUiQ Y0sUZ9dXQDnT6mEYRBoNlo0X9zDgY37VK/VGb0iSAY/XxVrUascCg/9fVIiQ77/Q3k 5/f5+tGOL2xXY/RJgHXhD7RMhyji9pTtkNOx3FQoF5Iax1sYCmcUi1dw4xEc9k6Kbf 9Pr1gyH1LZ909mPtqx6F1E9gF1v/AnHrWS8GNVHlvpm3A9Cm+3hXN4TnKVwCAWzh0r 9aRQdXema9wFA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Mark Brown , Doug Anderson , Will Deacon , Sasha Levin , catalin.marinas@arm.com, oleg@redhat.com, mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org Subject: [PATCH AUTOSEL 6.6 21/21] arm64/sve: Lower the maximum allocation for the SVE ptrace regset Date: Thu, 29 Feb 2024 10:49:41 -0500 Message-ID: <20240229154946.2850012-21-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240229154946.2850012-1-sashal@kernel.org> References: <20240229154946.2850012-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.6.18 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240229_075031_379836_26C3C837 X-CRM114-Status: GOOD ( 19.85 ) 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 From: Mark Brown [ Upstream commit 2813926261e436d33bc74486b51cce60b76edf78 ] Doug Anderson observed that ChromeOS crashes are being reported which include failing allocations of order 7 during core dumps due to ptrace allocating storage for regsets: chrome: page allocation failure: order:7, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=urgent,mems_allowed=0 ... regset_get_alloc+0x1c/0x28 elf_core_dump+0x3d8/0xd8c do_coredump+0xeb8/0x1378 with further investigation showing that this is: [ 66.957385] DOUG: Allocating 279584 bytes which is the maximum size of the SVE regset. As Doug observes it is not entirely surprising that such a large allocation of contiguous memory might fail on a long running system. The SVE regset is currently sized to hold SVE registers with a VQ of SVE_VQ_MAX which is 512, substantially more than the architectural maximum of 16 which we might see even in a system emulating the limits of the architecture. Since we don't expose the size we tell the regset core externally let's define ARCH_SVE_VQ_MAX with the actual architectural maximum and use that for the regset, we'll still overallocate most of the time but much less so which will be helpful even if the core is fixed to not require contiguous allocations. Specify ARCH_SVE_VQ_MAX in terms of the maximum value that can be written into ZCR_ELx.LEN (where this is set in the hardware). For consistency update the maximum SME vector length to be specified in the same style while we are at it. We could also teach the ptrace core about runtime discoverable regset sizes but that would be a more invasive change and this is being observed in practical systems. Reported-by: Doug Anderson Signed-off-by: Mark Brown Tested-by: Douglas Anderson Link: https://lore.kernel.org/r/20240213-arm64-sve-ptrace-regset-size-v2-1-c7600ca74b9b@kernel.org Signed-off-by: Will Deacon Signed-off-by: Sasha Levin --- arch/arm64/include/asm/fpsimd.h | 12 ++++++------ arch/arm64/kernel/ptrace.c | 3 ++- 2 files changed, 8 insertions(+), 7 deletions(-) diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h index 8df46f186c64b..9bc2b0c9a4fee 100644 --- a/arch/arm64/include/asm/fpsimd.h +++ b/arch/arm64/include/asm/fpsimd.h @@ -36,13 +36,13 @@ * 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. + * the architecture. Using this length to allocate worst size buffers + * results in excessively large allocations, and this effect is even + * more pronounced for SME due to ZA. Define more suitable VLs for + * these situations. */ -#define SME_VQ_MAX 16 +#define ARCH_SVE_VQ_MAX ((ZCR_ELx_LEN_MASK >> ZCR_ELx_LEN_SHIFT) + 1) +#define SME_VQ_MAX ((SMCR_ELx_LEN_MASK >> SMCR_ELx_LEN_SHIFT) + 1) struct task_struct; diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c index b3f64144b5cd9..c94c0f8c9a737 100644 --- a/arch/arm64/kernel/ptrace.c +++ b/arch/arm64/kernel/ptrace.c @@ -1499,7 +1499,8 @@ static const struct user_regset aarch64_regsets[] = { #ifdef CONFIG_ARM64_SVE [REGSET_SVE] = { /* Scalable Vector Extension */ .core_note_type = NT_ARM_SVE, - .n = DIV_ROUND_UP(SVE_PT_SIZE(SVE_VQ_MAX, SVE_PT_REGS_SVE), + .n = DIV_ROUND_UP(SVE_PT_SIZE(ARCH_SVE_VQ_MAX, + SVE_PT_REGS_SVE), SVE_VQ_BYTES), .size = SVE_VQ_BYTES, .align = SVE_VQ_BYTES, -- 2.43.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel