From patchwork Tue Feb 13 18:24:38 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Brown X-Patchwork-Id: 200550 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:bc8a:b0:106:860b:bbdd with SMTP id dn10csp727822dyb; Tue, 13 Feb 2024 10:26:05 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCW0A3XpTn2dkk5/91dcRwz6IzA952Da6g1hWaExZqHiodGgv4LTMIbWt2EhOBlDpJux/yw5NdHbfpvy1EYjSFOueB1R0Q== X-Google-Smtp-Source: AGHT+IE9citMP+MWkkmxIkSG7iObxwmM1xtke1+mckxic0pNbifeqy42ed4MdJas/edmy0y15hKt X-Received: by 2002:a17:906:a451:b0:a37:2bb1:7517 with SMTP id cb17-20020a170906a45100b00a372bb17517mr171139ejb.45.1707848765263; Tue, 13 Feb 2024 10:26:05 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707848765; cv=pass; d=google.com; s=arc-20160816; b=q02IW60hliM+3rBrp0sp9s0qLE+qZQvjMHrTBnKQueSw6tTEb5vyeAHsbHBwDq7blN 6gCIItME4WB874JIN6rtdlx62ZOSwkewV90U1OKKDjBGhvESl6CtwrSApPC5DhNBvoVc TLUq/0YuiBH2XF1iQAkIa+6mYOFWqUzm8FDkLQJ5uyniCsEmoYo5VlpzZ6/cJatoO5Zu RCieXOKYiO1Tizjd6fkEzxTkU87qckTdBFmGzP9w11KtlGf0i/AIotAMUOD7VsahW31k /fJl+XIEZft1WCShIvldPhiNpcbtYr1MQKq/vWCCsIBE3ejegVef2n8xBb44vD6eZ8aY VRIQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:message-id:content-transfer-encoding:mime-version :list-unsubscribe:list-subscribe:list-id:precedence:subject:date :from:dkim-signature; bh=fwH81C77J8ycA7/bPT5WF0Y2JF7gZBFh0KVVCsW+ZM0=; fh=w//zh0zp7vwgvQLv/MrYz5AIp7dATtRwUOj/W5TY6JA=; b=0aM9PCyY52MBV1UlaBZp/ggFGzlVsz708a9ywYabzKnlIiWZPGxOXXEBF5f+Ju0Q8b geTK1n/qsV4wJPB9C48NU357by3Vm/fyHOJrmGkt3j5kStRNtas5ZdB/tMcRDASMjrtI xdQULkPWQ5M4aW8ECbfuA3RQIQvA7ftO7rGQ29qVC4M9GknXQtCI9iI9tca4xHqgqGgA Fr3+JaPZkhO9pL5zHSXyo18qYgk0oAngaMw/R6Y6LFmLFvhSAUS39IaHENMlxqJjvhQL hXooylP6oR7oq9yobvpd3VYYGJK3LBaysPGpyu4x9EQPEqlZgpnkIAPUdD6wLuntZKdM tOfg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=HC9BhcIQ; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-64076-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-64076-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org X-Forwarded-Encrypted: i=2; AJvYcCVRCXf1NWjYAXROjtnTYiALxfiyWda+6egDf9vaxR/bpqW29YP2sobeyd9t83gGo0uNxHFRE92vo/ssUs6jghCeHve6Yg== Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id re18-20020a170906d8d200b00a37a7edf748si1484376ejb.1009.2024.02.13.10.26.05 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Feb 2024 10:26:05 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-64076-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=HC9BhcIQ; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-64076-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-64076-ouuuleilei=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 B0B441F2172A for ; Tue, 13 Feb 2024 18:26:04 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 86ED460BBE; Tue, 13 Feb 2024 18:24:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HC9BhcIQ" 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 8C4B76088C for ; Tue, 13 Feb 2024 18:24:44 +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=1707848684; cv=none; b=cWWPxT201/W52RPtEaX/b1UfkAP1aP2WYeVU/1H02HE2+Eyc4kD7Sfpt13SPtgPvn9NfZj0C3Xx4oldqnc/XP3eNoV5ILVjr6aMSGERHVg5dNgLcbMPPYWRvXN+apI/X0DIncs0CvovjiiAT95gMwhGpFECKuDgeFvn8yyKBj5A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707848684; c=relaxed/simple; bh=I5zIgI+QjhRatSLfoEbbhZ6aVR0T34jHoAcGOwHYwms=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:To:Cc; b=Z9Gxm8TWblX8cNnmL8PEnCbL9T6lRw0HxvyOq4cSn+Jo5KACX0hPRtrj726psAK4cFCl40vgZuP55aVwlIktP3x8Zckxyeu9y+EV7fNKUKsl4mfKwy/3oBccTFk2dpMHOn0+Ew0gmc9zWHmSDTFBa57ZzCeP6VcmXAAVLeKc+qs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HC9BhcIQ; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 448DFC43390; Tue, 13 Feb 2024 18:24:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1707848684; bh=I5zIgI+QjhRatSLfoEbbhZ6aVR0T34jHoAcGOwHYwms=; h=From:Date:Subject:To:Cc:From; b=HC9BhcIQ+NObwtf5QsVwZyOrTCF+0RQYLbPCWl0k9nK7j7t1qrSVZFxsRE8C2f6OS V3f/Zg84eOx4aCvJov0C5MVIfkY7puH4t/vHlN0LMwuWhNjiLfa7cD/6VG87rHz9sA Qf3PS0At/k2vVwP1bQQE/1T0JstsiU8bQuFaDj9sj3GnB/LAmPm5tN+cFRLX/MrEyv xiOwTazzt73c0aYEctze2VCyEoSDoXEs6Sp17QUpMFMf9kWa/JZ26bIYFfIDPc32rt FlunKZo+2u6/xnHFHQU/m3NDxU41KfZOzyVLqPaPKd06h6iE1tBPVtUKgMSLDdVpYW h1EGSyDiiAU1Q== From: Mark Brown Date: Tue, 13 Feb 2024 18:24:38 +0000 Subject: [PATCH v2] arm64/sve: Lower the maximum allocation for the SVE ptrace regset Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-Id: <20240213-arm64-sve-ptrace-regset-size-v2-1-c7600ca74b9b@kernel.org> X-B4-Tracking: v=1; b=H4sIAOWzy2UC/33NQQ6CMBCF4auQWTuGFkKoK+9hWBR8QqMCmSGNS ri71cStm0n+WXxvJYUEKB2ylQQxaJjGFHaXUTf4sQeHc2qyuS3zdNjLvSpZI3hexHdgQa9YWMM LbE2bO1u7ysFQImbBJTy+/KlJPQRdJnl+16L5fH9w8R+Ohg3brmi9KeqqdTheISNu+0l6arZte wOGU3DsyQAAAA== To: Will Deacon , Catalin Marinas Cc: Dave Martin , Oleg Nesterov , Al Viro , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Doug Anderson , Mark Brown X-Mailer: b4 0.13-dev-a684c X-Developer-Signature: v=1; a=openpgp-sha256; l=4370; i=broonie@kernel.org; h=from:subject:message-id; bh=I5zIgI+QjhRatSLfoEbbhZ6aVR0T34jHoAcGOwHYwms=; b=owEBbQGS/pANAwAKASTWi3JdVIfQAcsmYgBly7PpI4cciiXeYNP+EEVt3Y4INFoiOrI/rWmsp/ke 3UYsdwKJATMEAAEKAB0WIQSt5miqZ1cYtZ/in+ok1otyXVSH0AUCZcuz6QAKCRAk1otyXVSH0ELxB/ 4/7F5im0GANZp1+aO+MD+khEacxi3g7TQuULUlLOSRa1Bojd1b3COou7f4YXUN0PfA2Nms6UDEGtse z0+0djdKCZS0xxNiE66INGT3SPlZh1evAmLNIvEgTT6FR02VAoUNj1XP8q2tF3x/eBqtUvtCt4oQjd 95JbNESua5OhDTwmbZ070bPLFi8LMylPmQLDy8xPyl0EVM6M+KykV4jnFDfXUJdycE43Ej6sEJy2J0 OmLwCoRvrSzdNxk5M5/NNRpx9XjC77PdNpBbFLP6WfmN7Ik+5ZhX0F+Xjftj/wmm3MVNIAR02LAAOL KGimltgZ7MekxKVaCrCD6dd2SL+ZQF X-Developer-Key: i=broonie@kernel.org; a=openpgp; fpr=3F2568AAC26998F9E813A1C5C3F436CA30F5D8EB X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1790809226731288196 X-GMAIL-MSGID: 1790809226731288196 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 --- We should probably also use the actual architectural limit for the bitmasks we use in the VL enumeration code, though that's both a little bit more involved and less immediately a problem. --- Changes in v2: - Specify the value using the size of the bitfield it goes into. - Link to v1: https://lore.kernel.org/r/20240203-arm64-sve-ptrace-regset-size-v1-1-2c3ba1386b9e@kernel.org --- arch/arm64/include/asm/fpsimd.h | 12 ++++++------ arch/arm64/kernel/ptrace.c | 3 ++- 2 files changed, 8 insertions(+), 7 deletions(-) --- base-commit: 41bccc98fb7931d63d03f326a746ac4d429c1dd3 change-id: 20240202-arm64-sve-ptrace-regset-size-21b0928969e1 Best regards, diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h index 50e5f25d3024..481d94416d69 100644 --- a/arch/arm64/include/asm/fpsimd.h +++ b/arch/arm64/include/asm/fpsimd.h @@ -62,13 +62,13 @@ static inline void cpacr_restore(unsigned long cpacr) * 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 dc6cf0e37194..e3bef38fc2e2 100644 --- a/arch/arm64/kernel/ptrace.c +++ b/arch/arm64/kernel/ptrace.c @@ -1500,7 +1500,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,