From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1497BC02192 for ; Mon, 27 Jan 2025 13:50:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9196F280151; Mon, 27 Jan 2025 08:50:03 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8CA30280150; Mon, 27 Jan 2025 08:50:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7A211280151; Mon, 27 Jan 2025 08:50:03 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 5CD27280148 for ; Mon, 27 Jan 2025 08:50:03 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 168B3A0183 for ; Mon, 27 Jan 2025 13:50:03 +0000 (UTC) X-FDA: 83053365486.29.8C597D5 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf07.hostedemail.com (Postfix) with ESMTP id 38EE140007; Mon, 27 Jan 2025 13:50:01 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ITreSYYk; spf=pass (imf07.hostedemail.com: domain of joel.granados@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=joel.granados@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737985801; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=epQcBRbikRChnEcLD7GohI/p/yPUxTUqgScFKmNVdcQ=; b=HNo5j4TXoKm1HTUg+A2h+SAeBEHneaN3SrRB8L06laYyaCXCcb/IReSIfTOHk1Qbb+Ypux kdl34YjDV9m5C1cuS4fwSwvM7RJRpkRWq/f8dF6CLWtZe6oH9/585NjOuNmiIK7mhsgVa8 rtLL0SqxrFT6osXfN07W/i6HYF+HZiA= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ITreSYYk; spf=pass (imf07.hostedemail.com: domain of joel.granados@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=joel.granados@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737985801; a=rsa-sha256; cv=none; b=NV66uXkXfz6VfTMKyKKXZkD2x5HIOLqskteJRTdK/54dWj8vr4NBm9r2IqeGtNul8StBLZ 69wPnkFckSu/tMqSqm7lptjMHYCO7IFtkQfyZorBM39r6//KMSw20ltnbsxlhQAAAGVaSi Mx8bfV8fv3s8lJhAWFu+2WV4a///Oaw= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 554B0A4154E; Mon, 27 Jan 2025 13:48:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 881ACC4CED2; Mon, 27 Jan 2025 13:49:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1737985800; bh=laZX1iWKmTFe6EBXe6dQ6V5dBHky9feUPubV8bbHYy0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ITreSYYkYqJo0yzT/NmeCNaU8ylN9fF82uixbVQhbAMNhn/x1ksvsdeN2BZIjx7Av 6jRzLOfnz1KOiZ8BN/+a6yzSKjX86nOzP6ewnKK12LbyYoLRgr6MitIVZMs+Q9nRjt 1O56sOuQWf9/oW9JBeL1K1Ep9SPnbGRY0gAqf1BfWdrmsV6P6rbrAzrEzJaWATIpCg PxgyGHOSh+1Dp+na/sGNdWcGsgzNCRs4/nnMHS16Kt8UOkwJO9cYsDiIOKruHAZkDs tuJVwo0MPlNeiRHuQkLVgJEWRQ8mSboCfx8PwGZonQ0+bdJkEjI8BLPDWS5oZchNDY iBi9Q4ViZ4cfA== Date: Mon, 27 Jan 2025 14:49:55 +0100 From: Joel Granados To: Ard Biesheuvel Cc: Alexander Gordeev , Thomas =?utf-8?Q?Wei=C3=9Fschuh?= , Kees Cook , Luis Chamberlain , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-crypto@vger.kernel.org, openipmi-developer@lists.sourceforge.net, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, linux-hyperv@vger.kernel.org, linux-rdma@vger.kernel.org, linux-raid@vger.kernel.org, linux-scsi@vger.kernel.org, linux-serial@vger.kernel.org, xen-devel@lists.xenproject.org, linux-aio@kvack.org, linux-fsdevel@vger.kernel.org, netfs@lists.linux.dev, codalist@coda.cs.cmu.edu, linux-mm@kvack.org, linux-nfs@vger.kernel.org, ocfs2-devel@lists.linux.dev, fsverity@lists.linux.dev, linux-xfs@vger.kernel.org, io-uring@vger.kernel.org, bpf@vger.kernel.org, kexec@lists.infradead.org, linux-trace-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, apparmor@lists.ubuntu.com, linux-security-module@vger.kernel.org, keyrings@vger.kernel.org, Song Liu , "Steven Rostedt (Google)" , "Martin K. Petersen" , "Darrick J. Wong" , Jani Nikula , Corey Minyard Subject: Re: Re: Re: [PATCH v2] treewide: const qualify ctl_tables where applicable Message-ID: References: <20250110-jag-ctl_table_const-v2-1-0000e1663144@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 38EE140007 X-Stat-Signature: hh7qrn8mmd9ujzi8ujjhk1ktc4sko37d X-HE-Tag: 1737985801-719877 X-HE-Meta: U2FsdGVkX1/PzJBhaxMzUVprKlR6LCDMWHsSOIIXRlTFVpehlPuXVk+v5WQERSBtDRkE1bRmwlFqROM5XZSe0zzBoW6S+aazlpcYVSWGUwTSmMRII5VAU7q0XO7bpe3LMNbqBZ2A2uK6FxdgtY6e5KebDN+ixoNZG1TM+bkw5pFb+74hrn5hOf1f70FmxL456jXk5xWVKhRR7Ms2+I29tDZFx+tcP+pccdKrHu7GtfIjFoTbQTg2q6GbCjc7VJMA5oSPI4+oUMPbvdAM4W2Gten74U99fVgX6+BxsLu73Kthp1hgB9Tny6CjglBkH/4MvdZ80HqYyKxSPKwUeNJA0bNPxhIGFYlt/+dqe3nyDfAS7HGBKnt/0Qw0dZTHs/jVRmzWvhUsjBZvVSQekhi9GYMhTL2/1bcsLbwiUm++AGhDU7dU9OhvHkpW9oi4eO8SShmaK48XUvn/m7cIoPiyOKmqrPUt4VcY3syxqF/cSmaPwzhlajKcaVbg2bidVmbL5W/NP6ry2QgTpNrLhEZtnrAm4tzWWFBFTc2ZnefaWuyegJuxVah7wug9it7Ec2hqASgJJLq/3vmnaxpZJtlt0KJEYUuXK6CWxCLmxq4xhscz0F3FLIAPpjEzAEdb+b/k1PDhrdyklUYEx/F4tCEbk4/n54pwM4cVtpEE936bS4BGOmTDUDuYSmJY+Q4UukAPEPvuTkFicPib4AKeseXBV0woxewkHuzD1i9maAh5cWn+cpkuwcCUESFscfFZzmGCnkrXoF36gWMWpm6oVOtFOrnHL/lybU/X863kdqPd2SxJuC0ZoXzXSN3HcWdQRqtbO9WOqN2cdikx1DyGvYqI8il2H/qMhej4SgmDojUzPRW04kY2nywAQg4x2aMA02kY0csPvXqxQA7P30Hul13ALMvhYtJv5DdQMCsGHkNwtB9pmt15T9ry0xs9uIZinJOTHdfLiNOMvheHdPsu43J 34D+FSM5 FE/EEzbFiRpVpZ0hxaAW4Y+ImznAc1eCQyl9wG0FKP7ytOBFgmREf7WQzVfzreT9CsDlWr4pfaJPxcfirKJDQeGNAF97r1UHzCzX5n4PKWj1mntUcDUx4kkhGJCdiRrjDuiX3TLuTEW+K68gCKeWV6hXV95CpTZWcERXtzXbEAJYoXUElrelYewkycdGWlhzaAwnwrpLVPUUsM3rRvW5AFU4AZoeNeS9ixNzr9u+6vgrBldOVsxcETJJp2SEelyyCN1MrSzxUT6ZK4uMaeJRqr+NnS7yaM/Ypgs7gld6pIpuAourSdiUQUdxqqxnoqA3stzttZskVRqvxN4fyXwYHv5VXzXrhP/tiPC7I3gR8sNvTuPy7pwwHFhh2XiTYTDJJcS7NjY9AthwxN5c= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Jan 22, 2025 at 01:41:35PM +0100, Ard Biesheuvel wrote: > On Wed, 22 Jan 2025 at 13:25, Joel Granados wrote: > > > > On Tue, Jan 21, 2025 at 02:40:16PM +0100, Alexander Gordeev wrote: > > > On Fri, Jan 10, 2025 at 03:16:08PM +0100, Joel Granados wrote: > > > > > > Hi Joel, > > > > > > > Add the const qualifier to all the ctl_tables in the tree except for > > > > watchdog_hardlockup_sysctl, memory_allocation_profiling_sysctls, > > > > loadpin_sysctl_table and the ones calling register_net_sysctl (./net, > > > > drivers/inifiniband dirs). These are special cases as they use a > > > > registration function with a non-const qualified ctl_table argument or > > > > modify the arrays before passing them on to the registration function. > > > > > > > > Constifying ctl_table structs will prevent the modification of > > > > proc_handler function pointers as the arrays would reside in .rodata. > > > > This is made possible after commit 78eb4ea25cd5 ("sysctl: treewide: > > > > constify the ctl_table argument of proc_handlers") constified all the > > > > proc_handlers. > > > > > > I could identify at least these occurences in s390 code as well: > > Hey Alexander > > > > Thx for bringing these to my attention. I had completely missed them as > > the spatch only deals with ctl_tables outside functions. > > > > Short answer: > > These should not be included in the current patch because they are a > > different pattern from how sysctl tables are usually used. So I will not > > include them. > > > > With that said, I think it might be interesting to look closer at them > > as they seem to be complicating the proc_handler (I have to look at them > > closer). > > > > I see that they are defining a ctl_table struct within the functions and > > just using the data (from the incoming ctl_table) to forward things down > > to proc_do{u,}intvec_* functions. This is very odd and I have only seen > > it done in order to change the incoming ctl_table (which is not what is > > being done here). > > > > I will take a closer look after the merge window and circle back with > > more info. Might take me a while as I'm not very familiar with s390 > > code; any additional information on why those are being used inside the > > functions would be helpfull. > > > > Using const data on the stack is not as useful, because the stack is > always mapped writable. > > Global data structures marked 'const' will be moved into an ELF > section that is typically mapped read-only in its entirely, and so the > data cannot be modified by writing to it directly. No such protection > is possible for the stack, and so the constness there is only enforced > at compile time. I completely agree with you. No reason to use const within those functions. But why define those ctl_tables in function to begin with. Can't you just use the ones that are defined outside the functions? Best -- Joel Granados