Received: by 2002:ab2:6857:0:b0:1ef:ffd0:ce49 with SMTP id l23csp2551905lqp; Mon, 25 Mar 2024 02:16:37 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCW8Qhaett3OvDQR3Ezmm9n5TGVPaTMuRChnEAdg9beRj/hp2DR38WmaF0362s9tXGQ6bqSFP3A0u8f0M4kUrwfzxQw3/+wEe7Uo7o6H+Q== X-Google-Smtp-Source: AGHT+IHfQ6f2tXyVdQZ8FIZrBWnaevSO31q3qFKn2sy573zBBZmdzhsAgADyTnuhzActVLSvInGK X-Received: by 2002:a17:906:80d2:b0:a47:a340:c9b6 with SMTP id a18-20020a17090680d200b00a47a340c9b6mr2348744ejx.28.1711358197089; Mon, 25 Mar 2024 02:16:37 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1711358197; cv=pass; d=google.com; s=arc-20160816; b=M4/BaCb8AGWO6Y//QctEcfSLhQ6zacCAvLxsUn8RL6sUhbCHavTdiD9HAJhKSuWkO7 kxAkzmxCSacKXsMoZ7OABnAV3JxCEJCEydLsBP4NrzabQ7wE6ENCBWi4FxgJRCw1LhfB yv7Y/p37YgN5XQGa4MWY0/u/z4J+Bj060ENhhRxdysTFsBjjlAEuGLjqPmoyN+5exSG0 Gt0AknBGuzDzhIvr/pugdXk4ksysnugEeJpnRZyWWaQFhecZLSGbEYPe7Ij4ErvlgO+d KXZGFowBnDXeHxbcd+BUEg+2rH7nNTxfg08TfOMsptL1HNCyzXzXE+sm/Zj2u/lVYMEH bB8g== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=A14A9UPBLWULkI3YBsdr/YGaSXwg2y3zJug6PEDrGDY=; fh=fBUNdTgsMsO9EHZwELzbwnACVCEgNjzGqxC46QMhe10=; b=KNMjG9vIvE1JE7dxvfgcZK5eJcY6yO3itlE2RwS2qOIUzME2sA7ehpWaLLwULOHXac YlfxEjU4AwYZYlrNL9OUjx0wCXVS4vaDUAqKZMCHL7BnVldkfwDgsqGlutKb3QgGpnO2 LKxC6gxXBhCgKCdn39aQEFIC6Hnth32zU+fTp0Yb8hwe29TYSu+clh5c704/toVVxo/E +FA8fDT3HjrGz3Bxhgp6cSrNlTB1Pd/UNjd9G66sLIWBh/uWw/7WE0dgZApMlXm9v8j5 FIDfYaxn3sGTtDexFHTWcS60RIhh2oULAop4hgqCTrb59IIHlO84nV3cTjPzjHPFVjLv oPMQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ouIozN6v; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-115759-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-115759-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id x26-20020a1709064a9a00b00a47529dfa85si1184147eju.550.2024.03.25.02.16.37 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Mar 2024 02:16:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-115759-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ouIozN6v; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-115759-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-115759-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id CF1ED1F38567 for ; Mon, 25 Mar 2024 09:16:36 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A3CAA36ACF5; Mon, 25 Mar 2024 03:00:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ouIozN6v" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 927721448E8; Sun, 24 Mar 2024 23:12:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711321957; cv=none; b=nfeo4AKOyxmPEwHR4WJ7KGlRFhCeMGECO5Kb0+lUUVzR/MHVgMJE0yaDKcH9D7ATzAz08OkD2sgmG4fLUqngZy4iy9/Au50SHFUOSVzAyiXV16jq9IdJsvCMDoDVu+ku/CF5HbScLIsV4L0ymXsgfLSSaDvbZ2s1Lk8Yok4g0xM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711321957; c=relaxed/simple; bh=ie+Tc0KhPh5wwb6RKvdIyC9JkGOdmJhObcTYVygG/wU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=EdmHseCIykqZ2fpGQ1nz9zAYawE7lVoTjfzYCm8HEdUN8N2e2cF5geRjGUgw9Qq8UfxMA7Y0daihAV9NLUprNqYroSc7Fh2+C9wyHQznsOdc0qqwZXxCjp/apVPtI/15VyFzMt0BY4G8P/J3Jm2UXy/7neW8c21W6//1olby0DY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ouIozN6v; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id BAB0EC433C7; Sun, 24 Mar 2024 23:12:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711321956; bh=ie+Tc0KhPh5wwb6RKvdIyC9JkGOdmJhObcTYVygG/wU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ouIozN6vuspw4VkPPT1lixBqwkhi7Rov7aM6cFsEcc4owrZ8xRLbKltr5iWzZzx9o bFFm6xN0eYG6b60B3wrS1F6luas7LB4zy0KwbacmadmQocuqNTHNtEY1NxcXp+sYIk ko6d/mZS25wCb92Jhyd49zBclm/0VtkxxYdF/TpTBpUrVSwaMOdL53BLwJzJ9hLn3c 2hBFAXrfo99Jq3amoLYK7g3xtFlafF6UHYMxDs9j0fXS0oAUkhY850JgCx8U8HQgdk 3w8eFSxfH3MkkbRdjBEnmm2mV+Qu00gulsqcVCocGfPbjLcFnd2UBAdGwJ2k6PZb6v AI9i7F8SSSgJg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Mark Brown , Doug Anderson , Will Deacon , Sasha Levin Subject: [PATCH 6.1 028/451] arm64/sve: Lower the maximum allocation for the SVE ptrace regset Date: Sun, 24 Mar 2024 19:05:04 -0400 Message-ID: <20240324231207.1351418-29-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324231207.1351418-1-sashal@kernel.org> References: <20240324231207.1351418-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit 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 da18413712c04..930b0e6c94622 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 e1f6366b7ccdf..d02dd2be17b3b 100644 --- a/arch/arm64/kernel/ptrace.c +++ b/arch/arm64/kernel/ptrace.c @@ -1450,7 +1450,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