Received-SPF: pass (google.com: domain of linux-kernel+bounces-110151-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Thu, 21 Mar 2024 15:28:48 +0100
From: Joel Granados <j.granados@samsung.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
CC: <wenyang.linux@foxmail.com>, Luis Chamberlain <mcgrof@kernel.org>, Kees
	Cook <keescook@chromium.org>, Christian Brauner <brauner@kernel.org>,
	<davem@davemloft.net>, David Ahern <dsahern@kernel.org>, Eric Dumazet
	<edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni
	<pabeni@redhat.com>, Shuah Khan <skhan@linuxfoundation.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 8/8] ucounts: delete these duplicate static variables
 ue_zero and ue_int_max
Message-ID: <20240321142848.qh4jsp5j2ict2ar3@joelS2.panther.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512";
	protocol="application/pgp-signature"; boundary="lwua24korejtob7w"
Content-Disposition: inline
In-Reply-To: <875xyczpzm.fsf@email.froward.int.ebiederm.org>
CMS-TYPE: 201P
References: <20240225040538.845899-1-wenyang.linux@foxmail.com>
	<tencent_AA60553AD4DF41859328E9CACC367EFDCF08@qq.com>
	<CGME20240225123015eucas1p2e13b3b1eb009f5d30e662fee25515b1d@eucas1p2.samsung.com>
	<875xyczpzm.fsf@email.froward.int.ebiederm.org>

--lwua24korejtob7w
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Feb 25, 2024 at 06:29:33AM -0600, Eric W. Biederman wrote:
> wenyang.linux@foxmail.com writes:
>=20
> > From: Wen Yang <wenyang.linux@foxmail.com>
> >
> > Since these static variables (ue_zero and ue_int_max) are only used for
> > boundary checks and will not be changed, remove it and use the ones in
> > our shared const array.
>=20
> What happened to the plans to kill the shared const array?
I agree with removing sysctl_vals. I wanted to get more info but was not
able to find much in lore.kernel.org. I was wondering if the push
towards removing it had been discussed in the lists? Or was it more like
a conference hallway discussion?

Best
>=20
> You can still save a lot more by turning .extra1 and .extra2
> into longs instead of keeping them as pointers and needing
> constants to be pointed at somewhere.
>=20
> As I recall the last version of this actually broke the code,
> (but not on little endian).
>=20
> This one if the constants are properly named looks better
> than that, but I don't see any reason why you want shared
> constants for such a handful of things.  Especially when
> it has proven to be error prone in the past.
>=20
> The only people I can see who find a significant benefit by
> consolidating all of the constants into one place are people who know
> how to stomp kernel memory.
>=20
> Eric
>=20

--=20

Joel Granados

--lwua24korejtob7w
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQGzBAABCgAdFiEErkcJVyXmMSXOyyeQupfNUreWQU8FAmX8RB8ACgkQupfNUreW
QU9fSgwAlbWex7MGOQ7kR1UgahM25aVbA4W6xidoG8TRcCy2hWHTfvVx88Jv8c9n
nxUe00W5BJwV6cgalwrqD0X/YOCsJQfH1TvWqdJB25LzqmrQdm/PKaHAWu5j7jAt
k8RTQdGh/X9PNwuf1P+yatuemBkHbJmAfDYt+bHf+8+rmz+iJn5MPFiysRfy3u7w
SLkHLg1xZqydT++WXQ6ZnDY0L5InVGxo/ZjpYuG27zxQdCa/ngt7fp0tVAzJB9+K
u9DnMtR3c8SRRpB/ClmeZuDma7ayom+hVG5Gyjxocm9mnwuZ2wYssgKhOPnx3ufC
M21PiqKgxdcgNmo+ma2E/biEn3WDwGFi1q1LzZUsEwp4CIbpcWg5+Gq4wFEn8MgZ
GgDPIyNHN91Kp3ZcdTqH54/iv+S3zdMzQc0C4SEo1EJHGT+0iSPvM7/Fog90kqbK
mhFOrh6B6kMIEyyiUa40UVeXzWHDhAMribxCihfE2tno4x2RRrdEOxOXcXmoFwJ+
M/lAdy8p
=F3Hy
-----END PGP SIGNATURE-----

--lwua24korejtob7w--