Received-SPF: pass (google.com: domain of linux-kernel+bounces-50266-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Fri, 2 Feb 2024 17:48:25 +0000
From: Mark Brown <broonie@kernel.org>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Doug Anderson <dianders@chromium.org>,
	Christian Brauner <brauner@kernel.org>,
	Eric Biederman <ebiederm@xmission.com>, Jan Kara <jack@suse.cz>,
	Kees Cook <keescook@chromium.org>, 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>
 <CAD=FV=X5dpMyCGg4Xn+ApRwmiLB5zB0LTMCoSfW_X6eAsfQy8w@mail.gmail.com>
 <20240202030438.GV2087318@ZenIV>
 <CAD=FV=Wbq7R9AirvxnW1aWoEnp2fWQrwBsxsDB46xbfTLHCZ4w@mail.gmail.com>
 <20240202034925.GW2087318@ZenIV>
Precedence: bulk
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>


--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--