Received: by 2002:a05:7412:8d10:b0:f3:1519:9f41 with SMTP id bj16csp6802981rdb; Fri, 15 Dec 2023 08:41:20 -0800 (PST) X-Google-Smtp-Source: AGHT+IHTalos8C3y0FRmcIRCFXpu30RQQr7GEhKGZVuDH5htwtVnYlXu2ecSP0ooLuDdc+Z47gbI X-Received: by 2002:a05:6830:1d51:b0:6d9:f0b7:9e7c with SMTP id p17-20020a0568301d5100b006d9f0b79e7cmr10975197oth.33.1702658479989; Fri, 15 Dec 2023 08:41:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702658479; cv=none; d=google.com; s=arc-20160816; b=j0MprW1rdZ+BkV1aSfY5DK+XtrEM7DJWyQ5P5i/vK7e/yCd3fP3o5Hvg66zzu+VF42 gsQf7tFBNjO0pe+a/jK1RXMjZ2nlTO0mzG6ef/636F/76klmTlw5jab51mLB87urvwGR ZpI/hhgnTzK+5B24tsMPwCGISlKhwoC+T1D/A0smmor1y5BRxVXd23uxXkpfZVKL3B18 MPfVSKwNkZchsMQoh0evSlNzJgCqwF1U0agFH0mw6O8WD6d+aaw8psW+u+wPX27/rEVb qtDL12syjyL1rTSgTlh8HM+aIiOxIRUW9vFyWz0M/buYcJgs7fnHa+pkUqVLlRKOQR72 n6Ew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=CPn+MHZcY81wVpToLZsq9+edetdssi9x2XGiDaHpm2o=; fh=ldLyiZoSMMvqwOL/cmRzuuKxpimBk5KsywWrM3n1gmM=; b=IX9BstdtNYH/HCvRRkPPLyi3FBfNT4uEVw/JWQ8qk5dqsaKjeuYi1IOU+7Xzn4Eab0 YaLq4i3EgZSmFGG3WLWW06ib4d7PToYwZIMg29M2um7BBbdBR8Y3zV69klRW0I+AxLVE 5kqjGgeIbaaMm6BEmRNcJBO4z0UFMfs527LdYGkx2k4gzv94WOLSGJlGMcM+O7rr+PSy eCjmmE9E5HP7nmI+U/+T+LUJMleJ1WrzahwPHCvrIVmgWV05qK33SEsu2/y3+94m8X5I rgdXOXu2jgJmWFPU09qwk6C+uE6WYV9MlIn2R18TGPRYeOU29r8PO33jPc0b89i8J0ML bLAw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@weissschuh.net header.s=mail header.b=d837zuSZ; spf=pass (google.com: domain of linux-kernel+bounces-1317-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-1317-linux.lists.archive=gmail.com@vger.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 y23-20020ab077d7000000b007cb421f6d8bsi214473uar.200.2023.12.15.08.41.19 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Dec 2023 08:41:19 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-1317-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=@weissschuh.net header.s=mail header.b=d837zuSZ; spf=pass (google.com: domain of linux-kernel+bounces-1317-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-1317-linux.lists.archive=gmail.com@vger.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 B40081C23353 for ; Fri, 15 Dec 2023 16:41:19 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id DF9073EA73; Fri, 15 Dec 2023 16:41:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=weissschuh.net header.i=@weissschuh.net header.b="d837zuSZ" X-Original-To: linux-kernel@vger.kernel.org Received: from todd.t-8ch.de (todd.t-8ch.de [159.69.126.157]) (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 51D473DBBF; Fri, 15 Dec 2023 16:41:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=weissschuh.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=weissschuh.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=weissschuh.net; s=mail; t=1702658460; bh=0ax0RyEqWr1bicQX9ceD1II9EiZ3PVvN4J7hKz475aU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=d837zuSZbanA9sG8zz8oXkyu/FNP8MtTSoBYUW669y4cWsvJqWSmsXy9sc5u1ZJEY 98cmcsH4JpNWiiUTfbC0bUrJKPIrrUXK4XnzZkHkaSZD9c3DQgufYYavwsOLkt2Ol/ mD0qkN+fZCXekLFJyAPWof4ZP29tAZHsTSjMIzW4= Date: Fri, 15 Dec 2023 17:40:59 +0100 From: Thomas =?utf-8?Q?Wei=C3=9Fschuh?= To: Luis Chamberlain 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: <46d68741-0ac8-47cc-a28f-bf43575e68a1@t-8ch.de> 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> 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=us-ascii Content-Disposition: inline In-Reply-To: On 2023-12-12 23:51:30-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? The fact that the code compiles should be enough, no? Any funky casting that would trick the compiler to accept it would probably also confuse any other tool. > 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 > new tables if they need to be changed, and then a new series is sent > once we fix all those muttable tables. Ack. But I think the actual constification should really only be started after the first series for the infrastructure is in. Thomas