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 8957BC02188 for ; Mon, 27 Jan 2025 14:56:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D68776B014B; Mon, 27 Jan 2025 09:56:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D24736B014C; Mon, 27 Jan 2025 09:56:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BDFDA2800D1; Mon, 27 Jan 2025 09:56:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 9E0016B014A for ; Mon, 27 Jan 2025 09:56:18 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 3F339140137 for ; Mon, 27 Jan 2025 14:56:18 +0000 (UTC) X-FDA: 83053532436.21.69CF095 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) by imf26.hostedemail.com (Postfix) with ESMTP id 08E85140017; Mon, 27 Jan 2025 14:56:14 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=WVed1oKV; spf=pass (imf26.hostedemail.com: domain of jani.nikula@intel.com designates 192.198.163.9 as permitted sender) smtp.mailfrom=jani.nikula@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737989776; 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=feVXBXQ+By9WArNNSb/bibglGnzo06lZJuKLaLgAuos=; b=emvgPq9mRSibkdyNuWfKFbK6Wi0B/m+0KE78fYxMRLthuj6BDTxGmnlUL8HCRVXP6rZEwu 1oQNz8pdLs8CNiZEHG4sEGrbfmcRaTdYX7v/VB5+P0Yxtlt0NwRdUQumgnC1m/JIJ23dTk 6rN23Y0323MxbLrTmzZoCymuLBTN33I= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=WVed1oKV; spf=pass (imf26.hostedemail.com: domain of jani.nikula@intel.com designates 192.198.163.9 as permitted sender) smtp.mailfrom=jani.nikula@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737989776; a=rsa-sha256; cv=none; b=jHY/P319RPoKPE7Vqu2Wql0a7qY7o7kbhFCVvciMo1zezkbFwgMG6j9pKmP8NXJPslDSk9 yWp8WdcndBNGx3vC6BSRNjhvVwrHhAC4V4s9WkwGg+yl4i2pEHz/wY7evdAs/Gz6Wfjn8n 12sp0bENOZkvDGldt3E+yMrC4vDsfvY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1737989775; x=1769525775; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=jgZ2GO8S3cXCdWyE6ZvOdFoqm0rhCqZC3ICQKad44uQ=; b=WVed1oKVFkzK/oETPO0J8VpsIwi4ypJTg0lX+AcJEgqH+erXdJNaC/zx vwuxJ5EvFrKw8crBjfrH3OrZkmYyiIBfNFMF7HidrQkt6uq0J8zqSAp/C 45ZUNEiKIjk56k4gUxBaq3cmZw4dCPXjJfc0nYZR7zJGhVo2kmA6NEUXR 0KWBG3Cls9htsZqhlU+aXWYz+V2nSgl8rO7BSXBFLVrHPboFTM4jos7U7 sXSVvlfFUG6DsyEBbPRooxxmuhyYGXhs3SfVRgtB3m5OhDLEzWHgORxHb nG6Ys7jT0v1Ol5wgE5vgBrxk+WOrx/f94U1RMMbUu5Eo/yUWua9d7E6Dh w==; X-CSE-ConnectionGUID: sp1llEoyRN++BbSzpL9JEg== X-CSE-MsgGUID: qRnNj5ZnTwO141RyBh+A+Q== X-IronPort-AV: E=McAfee;i="6700,10204,11328"; a="49104683" X-IronPort-AV: E=Sophos;i="6.13,238,1732608000"; d="scan'208";a="49104683" Received: from orviesa005.jf.intel.com ([10.64.159.145]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jan 2025 06:56:13 -0800 X-CSE-ConnectionGUID: Z9Coz29cQ6uqfPwc/L4sHg== X-CSE-MsgGUID: XE2pskZGQO2Q6A9y4rThjA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,224,1728975600"; d="scan'208";a="113598177" Received: from bergbenj-mobl1.ger.corp.intel.com (HELO localhost) ([10.245.246.14]) by orviesa005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jan 2025 06:56:01 -0800 From: Jani Nikula To: Joel Granados , Ard Biesheuvel Cc: Alexander Gordeev , Thomas =?utf-8?Q?Wei=C3=9F?= =?utf-8?Q?schuh?= , 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" , Corey Minyard Subject: Re: Re: Re: [PATCH v2] treewide: const qualify ctl_tables where applicable In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20250110-jag-ctl_table_const-v2-1-0000e1663144@kernel.org> Date: Mon, 27 Jan 2025 16:55:58 +0200 Message-ID: <87jzag9ugx.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 08E85140017 X-Stat-Signature: my3xhamowdh41za75by18utku7f5b9st X-HE-Tag: 1737989774-125515 X-HE-Meta: U2FsdGVkX18pm08t/PkqhGkzJSzJ3eRvzrBbyKb6OgTiD8PaOjMc6lm4Ycr3PIzvPDggUEz4sA5JeqznYCiYrYHk89qsv7ddhM+nWtKgNCRGfO+qU98T0rD6IRaJSdfCCMKOEoG1Z0PTSuVEaVkjQ2ANsVRA9w3oaXN2WWQ1a1sbWUzA9ojO2L352HNJ3vS5QeOSeFBLZPw8gmpM5i5p5FRCYhpirWM39qlbPofGT+ZshnyIbfShuDbKDiZ8YNiC33E2vDDZE1bgagvGR2yStppOCXbGhD2HfY4nBphzEe4zY1ZTPbMR6qgS0HKNP/iCAnkJFK3+KNGqs6U8YJB6LSD9lfk3tSJyUwXVsQ7IR17kr3y3UFjo7LX90LYLfmLixLaYK4mkD/edoIse1F9o8izPyrhfUAIai4wx9TMV4BPLYdMZd7DL7/ZG3GPbWNCT8HOWU81okjGwhbmP2vkdxDBLGZ4knE549XxOY2/DvdvjrLSQl7DdrhcA1jWEZQRPlwNvmwYg2ICZrPI1tvEk+5hKp/5MMikqOGkYB8Hy3vxAc3AXp+fh+uoLCV4oneu1WeTVGLg5Yuzpp9A4BIgx264+fZqQFGjxSr+DdAeFLm8zhRXlwNIuHwn5gVLsBa0Rs+X1SrE10sitAF05U4b9Rr3Rmyxs+q0WwT/Pu63+GHocU1t1V0hYglnIQ45RUFalDxxaervPKB2ytzuNYXUonpIiawEuqOklqgCHjh9llkeFO/EYV0RLU0RzeXowOQ5tZXJzMtm13SA+iSHoPLgy6fwJ4i76i+s5I8/MgxoNS+LqZpgfCQmb2mm2EIh7HdUNazX107ApEyJqfEj+GTVSvibJ6EZuCM2h83tUoOjsfU0o+cOgPMrGs9GxCTNBJG9e3S6Qvb2g8Vc9er8FG7bQzfJg3W7g2K3F4yBPZjVY365/E0JmaGLH/ied7wTTgTAo/a5uP5X6xKU5v0/Rdxx tQh2HITl JqKNm/edbeRJ6yod1jfMFIdcqaKbOT1+4/0Xywyt/WS/3XhHxXRziUqGr8fdmIb5JXQNc/LFVyQHPEU7bGCBsNZAI/scK7UTuis77tqGZsQmtztC6KNkcnPG6Hn7z4hU6nfPKeWTHvE6g5CZtWrXlwVEKCee5bMvbNwr0biqapRaCNJu5oXP7XP1ZbFNNHSnePWT1XmgOHwSF/njCmj4wQt21LLGH4ZWQ4ol4u11MgzUNqMr71e0+NLRnNg56+x7CO3EfB/ww64qcHjwfhhA5MtNhZrct0uzloFpHlm+3K+PBwsA= 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 Mon, 27 Jan 2025, Joel Granados wrote: > 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? You could have static const within functions too. You get the rodata protection and function local scope, best of both worlds? BR, Jani. -- Jani Nikula, Intel