Received: by 2002:a05:7412:8598:b0:f9:33c2:5753 with SMTP id n24csp114752rdh; Mon, 18 Dec 2023 13:22:17 -0800 (PST) X-Google-Smtp-Source: AGHT+IFDJkFNsTWO2k2vWQTiu03gI8x5+crFcMbOOqvbTWFKyouVBFxoDfXYtIpMKzkzWgrW8eqA X-Received: by 2002:a05:6214:29ce:b0:67a:a721:caf8 with SMTP id gh14-20020a05621429ce00b0067aa721caf8mr21333398qvb.89.1702934537024; Mon, 18 Dec 2023 13:22:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702934537; cv=none; d=google.com; s=arc-20160816; b=vpMi2ivBTGvveM8XFDCUdgOf5q6gcFHG4rFkNSgeEhtiaRAw+j7/VwzLQiQiQcCevN ZVIPHTAIloLQBdjK7ai6zpdiOmnP54oKm8LkJLccdk3FExb08182oxz0fLxRIaFUnuuw az1KN0Hll/CNyJ41nT9hLTKXiXilfmkUi6LC7qkn88Y307YkE0v1uePyrA9w+kODM8/7 dcU1vXJSzycu1SIORttl5eE6RbDk5OUlzeLecKgNNJy0hM1wt5QC0HNnrXWPNrLMlvBw LauEu3ZopH7JvYX2Bnq8QN/1UFkAksxbIyaoCN7RNVDR2aESUUa+rClQy+rxrRok6Im5 ZYEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:in-reply-to:content-transfer-encoding:content-disposition :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:message-id:subject:cc:to:from:date:dkim-signature; bh=VC+L7rFKG6X8C4ZiU4wNQCGzHwKND4zyyzshhUNrvTo=; fh=7Zd5+Siv/rvkSbJi+3EebOZRGOHTEHFoqb4SKq8ECiI=; b=NvT7Uh8rJ/z0D28NnnTbq4mPMPEhrIQ1IDIlMfnPmWDMSD79HaO8Ub/VXw8NzXHTf3 T4KgDG0kMoa+q8y7FG0r8UZmOxlPfA58FqGWo8eZ45q9OlXgaS0Gfin9jVqjTrYci/uG ZZsU4oZhRPum9VJgsMJAHMz2Zy4ix49wpliE6D9JhwuMiSG+PR4RoaXJA82CAGDNIqDj 8KO9B1PvKSpC6uXqNSyfmWMMMTKdYg9To+y1Py9VWEjkxIkUuHsyTBUwtXU+WyQ1IGcT j/GKtgivwP6OY6jN5Bdua0ET90Fi5ZeOudJAE5wnFCrnZwklKOW0A2KAqr5FPn0fYJgU NReA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=RwnBpBPE; spf=pass (google.com: domain of linux-kernel+bounces-4405-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-4405-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id h1-20020a0cf201000000b0067f0802b3c1si11209519qvk.603.2023.12.18.13.22.16 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Dec 2023 13:22:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-4405-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=RwnBpBPE; spf=pass (google.com: domain of linux-kernel+bounces-4405-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-4405-linux.lists.archive=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 ny.mirrors.kernel.org (Postfix) with ESMTPS id 84E981C21A26 for ; Mon, 18 Dec 2023 21:22:16 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 980EA740AB; Mon, 18 Dec 2023 21:22:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="RwnBpBPE" X-Original-To: linux-kernel@vger.kernel.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 5EE527349B; Mon, 18 Dec 2023 21:22:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Sender:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description; bh=VC+L7rFKG6X8C4ZiU4wNQCGzHwKND4zyyzshhUNrvTo=; b=RwnBpBPEKSObuehHd52kglOds7 qRfWT1wCChbj2oeUHWIWeqzisKj1mREJxbjq2QEsBC2yr5XUaU4f8Vdj6ZiLTCAm1cxrHwtpTKI9l zaJgt0I7Ma2n+WA+1BRtSgVuHkO109xFu242d+OS0gajDklSLZWo6CEyyDcsT9broqoorbK/8loIP 6O9K7Q2nlyIu5BsDDGvxfLkPH0mCpY2fou3I2RTC3GBehV90FzFJAIUyOXbWQt0TrQ9KTeD232vYa /188RCbwPKHr2eBMwNhaHRTjRiaio+4sKm6JcPlXAMxvP2HE/Q+L/aoTNsW89BEKsTX+Vh7cwGO7t VU/1yU7A==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.96 #2 (Red Hat Linux)) id 1rFL3d-00C7Bt-0W; Mon, 18 Dec 2023 21:21:49 +0000 Date: Mon, 18 Dec 2023 13:21:49 -0800 From: Luis Chamberlain To: Thomas =?iso-8859-1?Q?Wei=DFschuh?= Cc: Joel Granados , Dan Carpenter , Julia Lawall , Kees Cook , "Gustavo A. R. Silva" , Iurii Zaikin , Greg Kroah-Hartman , 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: References: <20231204-const-sysctl-v2-0-7a5060b11447@weissschuh.net> <20231207104357.kndqvzkhxqkwkkjo@localhost> <20231208095926.aavsjrtqbb5rygmb@localhost> <8509a36b-ac23-4fcd-b797-f8915662d5e1@t-8ch.de> <20231212090930.y4omk62wenxgo5by@localhost> <20231217120201.z4gr3ksjd4ai2nlk@localhost> <908dc370-7cf6-4b2b-b7c9-066779bc48eb@t-8ch.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <908dc370-7cf6-4b2b-b7c9-066779bc48eb@t-8ch.de> Sender: Luis Chamberlain So we can split this up concentually in two: * constificaiton of the table handlers * constification of the table struct itself On Sun, Dec 17, 2023 at 11:10:15PM +0100, Thomas Wei?schuh wrote: > The handlers can already be made const as shown in this series, The series did already produce issues with some builds, and so Julia's point is confirmed that the series only proves hanlders which you did build and for which 0-day has coverage for. The challenge here was to see if we could draw up a test case that would prove this without build tests, and what occurred to me was coccinelle or smatch. > > 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. > > Tables that are modified, but *not* through the handler, would crop > during the constification of the table structs. > Which should be a second step. Instead of "croping up" at build time again, I wonder if we can do better with coccinelle / smatch. Joel, and yes, what you described is what I was suggesting, that is to avoid having to add a non-const handler a first step, instead we modify those callers which do require to modify the table by first a deregistration and later a registration. In fact to make this even easier a new call would be nice so to aslo be able to git grep when this is done in the kernel. But if what you suggest is true that there are no registrations which later modify the table, we don't need that. It is the uncertainty that we might have that this is a true statment that I wanted to challenge to see if we could do better. Can we avoid this being a stupid regression later by doing code analysis with coccinelle / smatch? The template of the above endeavor seems useful not only to this use case but to any place in the kernel where this previously has been done before, and hence my suggestion that this seems like a sensible thing to think over to see if we could generalize. Luis