Received-SPF: pass (google.com: domain of linux-kernel+bounces-2840-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Sun, 17 Dec 2023 13:02:01 +0100
From: Joel Granados <j.granados@samsung.com>
To: Luis Chamberlain <mcgrof@kernel.org>
CC: Dan Carpenter <dan.carpenter@linaro.org>, Julia Lawall
	<julia.lawall@inria.fr>, Kees Cook <keescook@chromium.org>, Thomas
	=?utf-8?Q?Wei=C3=9Fschuh?= <linux@weissschuh.net>, "Gustavo A. R. Silva"
	<gustavoars@kernel.org>, Iurii Zaikin <yzaikin@google.com>, Greg
	Kroah-Hartman <gregkh@linuxfoundation.org>,
	<linux-hardening@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH v2 00/18] sysctl: constify sysctl ctl_tables
Message-ID: <20231217120201.z4gr3ksjd4ai2nlk@localhost>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512";
	protocol="application/pgp-signature"; boundary="mrjpp4nfvufc32be"
Content-Disposition: inline
In-Reply-To: <ZXligolK0ekZ+Zuf@bombadil.infradead.org>
CMS-TYPE: 201P
References: <CGME20231204075237eucas1p27966f7e7da014b5992d3eef89a8fde25@eucas1p2.samsung.com>
	<20231204-const-sysctl-v2-0-7a5060b11447@weissschuh.net>
	<20231207104357.kndqvzkhxqkwkkjo@localhost>
	<fa911908-a14d-4746-a58e-caa7e1d4b8d4@t-8ch.de>
	<20231208095926.aavsjrtqbb5rygmb@localhost>
	<8509a36b-ac23-4fcd-b797-f8915662d5e1@t-8ch.de>
	<20231212090930.y4omk62wenxgo5by@localhost>
	<ZXligolK0ekZ+Zuf@bombadil.infradead.org>

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

Catching up with mail....

On Tue, Dec 12, 2023 at 11:51:30PM -0800, Luis Chamberlain wrote:
> On Tue, Dec 12, 2023 at 10:09:30AM +0100, Joel Granados wrote:
> > My idea was to do something similar to your originl RFC, where you have
> > an temporary proc_handler something like proc_hdlr_const (we would need
> > to work on the name) and move each subsystem to the new handler while
> > the others stay with the non-const one. At the end, the old proc_handler
> > function name would disapear and would be completely replaced by the new
> > proc_hdlr_const.
> >
> > This is of course extra work and might not be worth it if you don't get
> > negative feedback related to tree-wide changes. Therefore I stick to my
> > previous suggestion. Send the big tree-wide patches and only explore
> > this option if someone screams.
>
> I think we can do better, can't we just increase confidence in that we
> don't *need* muttable ctl_cables with something like smatch or
> coccinelle so that we can just make them const?
>
> Seems like a noble endeavor for us to generalize.
>
> Then we just breeze through by first fixing those that *are* using
> mutable tables by having it just de-register and then re-register
So let me see if I understand your {de,re}-register idea:
When we have a situation (like in the networking code) where a ctl_table
is being used in an unmuttable way, we do your {de,re}-register trick.

The trick consists in unregistering an old ctl_table and reregistering
with a whole new const changed table. In this way, whatever we register
is always const.

Once we address all the places where this happens, then we just change
the handler to const and we are done.

Is that correct?

If that is indeed what you are proposing, you might not even need the
un-register step as all the mutability that I have seen occurs before
the register. So maybe instead of re-registering it, you can so a copy
(of the changed ctl_table) to a const pointer and then pass that along
to the register function.

Can't think of anything else off the top of my head. Would have to
actually see the code to evaluate further I think.

> new tables if they need to be changed, and then a new series is sent
> once we fix all those muttable tables.
>=20
>   Luis

best

--=20

Joel Granados

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

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

iQGzBAABCgAdFiEErkcJVyXmMSXOyyeQupfNUreWQU8FAmV+4ycACgkQupfNUreW
QU9waAv7Bij7q2r+fK7GyD40a3pScuLmF3v3KHlHLzaG9jYC5dY+vvpSIDkJtHyx
VZId3JgPoMl2dSB4Nj0FoRoA/f2SJRex0kLUWU8Xj15+cvfWJ2IreNfDOJRhN0gu
MGFiae6AvEFELn0Z9yMiRnx0bgyUFvaKl7VZCw+9iYKjcMGhEZpagCrmuzUrEkZr
WrhjyUNjJtSL472JDq3nha46nmfSjNV/Yi+MvTBI5acVKUiDtKAc1PBHZp2anyeC
ohVni43geKFEMUBLquqG6H8xmP61Sg+3ByUVvH4jzpI9ys7UAYv27T2fuFexGdoc
qgQz5Z3cMWiulftWlrnpmyrNOL/dsM75k8jAAvdQi9o1Rw0Yi3tG04C0M1nxYEnj
mySmxuSFhfhxDSLhKJfVHLtVIQKbT9lZa2zns6Js3U7YlfCeWUKb5W/vku7JQPoI
sO6NGrTs8mcAvu/oErQf9K1UBxRc6cn6an+P2wyScjGpvq+36EUZ1GCZQv8uJiUz
NyiBFfLp
=d63B
-----END PGP SIGNATURE-----

--mrjpp4nfvufc32be--