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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0355AC4828F for ; Fri, 2 Feb 2024 17:48:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6AEA26B007B; Fri, 2 Feb 2024 12:48:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 638176B007E; Fri, 2 Feb 2024 12:48:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 526896B0080; Fri, 2 Feb 2024 12:48:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 3FA0A6B007B for ; Fri, 2 Feb 2024 12:48:39 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 157B21201D8 for ; Fri, 2 Feb 2024 17:48:39 +0000 (UTC) X-FDA: 81747598758.16.730747C Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf16.hostedemail.com (Postfix) with ESMTP id 9FBE1180007 for ; Fri, 2 Feb 2024 17:48:36 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=AWj0HPXm; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf16.hostedemail.com: domain of broonie@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=broonie@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706896117; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=v380Bup1Uf0kaJYogd+3OpU3Dw7E+DOUKyrBZK43KJk=; b=YA7zBET7U0BjHBd07p5rRRyPzIp6gXy+6scWk6IGQG6OZcyVeDYZnUAKVk4UKTYkCuncGz +6++elNfzzX2AdbzMzIVq079utaPzpZQ8AR608gdRqXwv6vplkjemmf4fQ/BG/zHdlCd7N j/SySwn5ZhKydl9E/bHrOtmmiKKfZz4= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=AWj0HPXm; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf16.hostedemail.com: domain of broonie@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=broonie@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706896117; a=rsa-sha256; cv=none; b=DwLMMU9zR5K/SuyhBfGas37t1/fNniUM1f1duttarhhyjEHerGkbbjGnxL1DNQ04mmdZkK 7t8QKtR6r4PQxWYZsvK56V1ZcYXuVwy+FHsmsIwO17sVntson//fcgLozUFbkK9FwXh8ay IXlk5x5CfiilRdJf9AZ2+OVsrQ9+uRs= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 17B9DCE2C74; Fri, 2 Feb 2024 17:48:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 73EBFC433F1; Fri, 2 Feb 2024 17:48:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1706896112; bh=QpwSwu16ZmhG3hCvCC9uXld1IgQWhFd5Z10yeUzElMA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=AWj0HPXmrt/RfP3e/bBCyi/CwoT2sLMwh1t9Mwp7mYWQLG6QbL6QR2pZkPpN/OTPj GM+KJvEkmbKM4Yg5Ne/xLIyIAXO+CUdJUQum19+cd8DIdgLMOWnjawLCx7xxZXMO/X lBlYDXXYQNyz/1ZhyeJX7Btkh/XRLnEX2xQLNLTCtu6JuvVp8uZN97SHbCkltZ3qoi QRZW1SyH/2LcN3wqS6Kjh7TEfnz5pDGew+k5F5AZXIq2dZ/2wh1E0wY5KdMGufjbg/ c0G7+IzzLWZ58BIBZqadSATnFZpe6FiV0ampe6uSl7bEBei1Xdr15xf29fjR9m+8RP jqgCYp1pX2Erw== Date: Fri, 2 Feb 2024 17:48:25 +0000 From: Mark Brown To: Al Viro Cc: Doug Anderson , Christian Brauner , Eric Biederman , Jan Kara , Kees Cook , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] regset: use vmalloc() for regset_get_alloc() Message-ID: <79f9ede9-4af0-48e2-9145-67796031420d@sirena.org.uk> References: <20240201171159.1.Id9ad163b60d21c9e56c2d686b0cc9083a8ba7924@changeid> <20240202012249.GU2087318@ZenIV> <20240202030438.GV2087318@ZenIV> <20240202034925.GW2087318@ZenIV> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="N65f3aqAGEWc/mks" Content-Disposition: inline In-Reply-To: <20240202034925.GW2087318@ZenIV> X-Cookie: I'm shaving!! I'M SHAVING!! X-Rspamd-Queue-Id: 9FBE1180007 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: rnc3ffj46o4tiebb49w6sau4r39u9h43 X-HE-Tag: 1706896116-938962 X-HE-Meta: U2FsdGVkX1/5puP6S5hxLhURqlfHqO1L4VtH0gXS6OpVnVwjN9ZVJQRxMPXwGOnfXkDWTwTuZWog2KVj+HsVsr3cm4UF+z2IlBLH6GQKHGJIiBhWZdGdSWde6N7OHonHo/Lj89FPmmhn9e0OKBsa/PyMrWPlNG54o3ePmn+8WCenOcSQ/q45YxrEKJLz5KhTEixlJmNToQhrGkalp7bLNl1TQNYsvViNKGYxk/qpcWzKJhvcM6fUCgVeIwkBujDHwd69Z5j0gbalabAhEd6pw+qMk3UmwkQFPttFxdmJLGT/OkJlTsAp1oyrL/CIexDDjoO12t/j2FEES3DMfVOtKsrmIY3SmXjjStOa0BUAK9UvKzQrBWW2od7bCaj4hSFK9TCziQWO/xQw7wBmUM7DbIJb4BaiNl9BpWNzDPstbhFp6UeERXFAIMCFtqygp+2j8YJVA6x55tqRIXb9hJQyykaXG27FsSv5DlgF8+6QF0ffZkQVH3iyI+3hIv4GI2ZXjLSKcb79jAE6fjiRek+P1Dvq/NxUbzSJzAyQxwxgsdAeJYcGevgNFOorA+Pb5pzznrAEy9WXQKatTdTYfgYJo/E72GWos/XT82uJTISH7HKwzl9trP8FrRU7Mu9W1+7w+381OcuvFhtPU87x+szBG1Tf1d+If1xv+BRFB4oA9trm6RW0HVErPaeRDAgZlVy2VC1nyj8QGVI0IEqAEO2w33uUd32UytaoHxoB5Pq5P3rf2l0vXRBM4DEWb/GmNn220G/qiJ3UGzZBmqu1yG8n/vd1Yd8CENtfRadBhH3MrFxYPodXAWFEP9gZC4ySJSLhh5YbWkpa1hkf7UyE/n5iUkKkp61NQmBRyO/j2sMzoNd+GNoPZwWgAmMmFq3YpuOEGnF1m8KDZdmuwN53UlXCUVuPxSMUYN6XtN40RUefllxD4kVn+eC+bXBprlqeYepuubB4VQlMXvf/Bil/1q9 tToL/Hfk kBa2krCGNmV5Fs6TV+Ls5zl5iiiCuam2gqXo0ME61o6069QGHkRVOn4n62gcXtBdmqH1k6RQtM1WNDU69M4gyTYvpwiWXkoiUnw8/a1Yx5A+hm223PT/lXKvu+GN0DF/O7ic9OL1Zy9zBGtmTcYbq8E87xnDvasL1FuI7mTHe7snu3U1W7IoewoBrct5KMunH7iLz6OIyU35sIsLPsy20AeTVtn8Kwp8y9/PrtkSmtiVi6921UQMx2GG8n3eC8V4DIchJvfq7y1OY8WeVadnFIsbscnHpyXYtBPE5DCDos8OD69BEjPMOinS2bjP/QtBpDsn3UixiYxwLaHz/5etOLkNvpEwmmA3bsHBN X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: --N65f3aqAGEWc/mks Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 02, 2024 at 03:49:25AM +0000, Al Viro wrote: > On Thu, Feb 01, 2024 at 07:15:48PM -0800, Doug Anderson wrote: > > [ 45.875574] DOUG: Allocating 279584 bytes, n=3D17474, size=3D16, > > core_note_type=3D1029 > 0x405, NT_ARM_SVE > [REGSET_SVE] =3D { /* Scalable Vector Extension */ > .core_note_type =3D NT_ARM_SVE, > .n =3D DIV_ROUND_UP(SVE_PT_SIZE(SVE_VQ_MAX, SVE_PT_REGS_S= VE), > SVE_VQ_BYTES), > .size =3D SVE_VQ_BYTES, > IDGI. Wasn't SVE up to 32 * 2Kbit, i.e. 8Kbyte max? Any ARM folks aroun= d? > Sure, I understand that it's variable-sized and we want to allocate enough > for the worst case, but can we really get about 280Kb there? Context swi= tches > would be really unpleasant on such boxen... The architecture itself is limited to 2048 bit vector lengths, and practical implementations have thus far not exceeded 512 bits with the overwhelming majority of systems being 128 bit. 2048 is commonly seen in emulation though. As well as the 32 Z registers we have 16 P registers of VQ*2 bytes plus one more register FFR the same size as the P registers and a header describing the VL and specific format of the data, all in this regset. The Linux ABI defines the maximum vector length much larger than the architecture allows and that define does flow into the kernel code, I believe this was based on consideration of bits 8:4 of ZCR_ELx[1] which look like they're earmarked for potential future expansion should 2048 bits ever prove to be insufficient. We should really do something like what we did for SME and define down what ptrace uses to the actual architectural maximum since no system will ever see any more than that, that'd still result in large allocations but less impressively and wastefully so. I'll go and look at doing a patch for that just now. Unfortunately SVE_VQ_MAX is in the uapi headers, we've already stopped using it in the test programs due to the overallocation. [1] https://developer.arm.com/documentation/ddi0601/2023-12/AArch64-Registe= rs/ZCR-EL1--SVE-Control-Register--EL1-?lang=3Den > > [ 45.884809] DOUG: Allocating 8768 bytes, n=3D548, size=3D16, core_no= te_type=3D1035 > > [ 45.893958] DOUG: Allocating 65552 bytes, n=3D4097, size=3D16, > > core_note_type=3D1036 > 0x40c, NT_ARM_ZA. > /* > * 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 =3D DIV_ROUND_UP(ZA_PT_SIZE(SME_VQ_MAX), SVE_VQ_BYTES), > .size =3D SVE_VQ_BYTES, Yup, and SME_VQ_MAX is defined to the actual architectural maximum of 2048 largely due to issues with the size of the allocation for ptrace. There are not yet any physical implementations of SME so I can't comment on the actual vector lengths we'll observe in the immediate future. =20 I see there's a comment update needed there for s/SVE/SME/ too. --N65f3aqAGEWc/mks Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmW9KugACgkQJNaLcl1U h9CjxQf/UQKcjZqgFzxfc+v+5GPIfo/ob9NZKDjsECvRqxpjjCxPSJ/H5+UwwL/k SPCFe8qPbJ634EiLguRLFPZU9Fiww9TOjGWtEZM3idw8sa1CodifoxeXqpbBJrub kcL/9WZzb8b4vPY9/R0Xidhgdno4oe1ydjMUVtkW0hO2nhcMOh6ngQpFTbnkK9BY 4FnukNzD7HS1yc70NsEuhFtpxdYgDLF1i/mT8eprrczGsJl7wv725uPrMehkokjL XDvCTLne3fMviZnc4ZOlyv3amgW2j7RNIs37Mg58pdg9vnii4qR2WARj9AivdQ7I OEuGvjf/5YuC5eJ00EppTA6MDv/wfg== =yRim -----END PGP SIGNATURE----- --N65f3aqAGEWc/mks--