From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 568653D954A for ; Mon, 27 Jul 2026 19:56:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785182166; cv=none; b=mSD8GKCwXnwjBuHa6Z4qo1DzwgHiUWPn9uGVSS94Fg56rdFlrr+NMP5TbBKZ5rkd5jHmSU156T+uHdR/iMxpa2Uniqqr4XbRqeFKk44MUHWmiAUTBiSZB+fyLkJKvfumJcHBOlVlag/s0/KO/iT7LeYiq+bKf20dt3l1L1EAxnI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785182166; c=relaxed/simple; bh=95e6AzBw7fypG9UQfmvET4YjkH3prvCcQUdkqJvnh1M=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=PUiR69wHlg8M5BeCA7rZHYuvmnM7ChYjJi1vWNtB2PVb2IdmNV5cQy3UHUDILUJPQIKFORF/h62lGQbFC5v9tomxQ9SJoSUj+DVhbcJUmOOYx8tbzj3vmCp9k0c3mh0xaWIdAcwZT6hMxVXQ+DfUsgtywGNkn1WQNIJW+etcysM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gTVAzr3y; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="gTVAzr3y" Received: by smtp.kernel.org (Postfix) with UTF8SMTPSA id 9F99D1F000E9; Mon, 27 Jul 2026 19:56:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785182161; bh=g9X9PrHDkDnYiMPeGxh8PPONUuE19EW2oIy+atm3pxA=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=gTVAzr3yS2zl9sSu02DdyHoIwSmnEIhzOLC5wJEW0syWsW+aKx0U5sK7RzLncX8bI CbLsa6Jyufn0WYHEtyc16khlaHAAdo7p1JwnqL7nIPiSWufQy6agnFZtPRI9bKkr4G hwWtX4iFKi4yJMjYykLD3k1hl92zAZhyRMZqx82IOTwZYnkn52gmth0WOsynZRNqta E6pmMMxLNJX95928+OXiodrQ0nJiOiyJJ/lsHnEJ6Hjz249HhHjlS+wzpE/qMSkMPn XLB6HuCnG5FvfFMbaLtOr7ugX2kaA2igSvGToU/qE6862F/KC8rLlQBw06BxYCs3Vi 6HAIK97IDLIaQ== Date: Mon, 27 Jul 2026 21:51:20 +0200 From: Nicolas Schier To: Oleg Nesterov Cc: Alexey Gladkov , Andrew Morton , "Eric W. Biederman" , Nathan Chancellor , Geert Uytterhoeven , Maxime Coquelin , Alexandre Torgue , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , Balbir Singh , Yang Yang , Peter Zijlstra , Juri Lelli , Vincent Guittot , Kees Cook , Joel Granados , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Shuah Khan , "Jason A. Donenfeld" , linux-kernel@vger.kernel.org Subject: Re: [PATCH -mm v2 1/1] sysctl: remove CONFIG_PROC_SYSCTL, it just mirrors CONFIG_SYSCTL Message-ID: References: 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 Mon, Jul 27, 2026 at 04:47:22PM +0200, Oleg Nesterov wrote: > CONFIG_SYSCTL used to make sense as a separate hidden bool before commit > 61a47c1ad3a4 ("sysctl: Remove the sysctl system call"); it was selected > by both CONFIG_SYSCTL_SYSCALL and CONFIG_PROC_SYSCTL. > > Today CONFIG_PROC_SYSCTL is the only selector, so the two are always > equal. Kill the hidden bool, rename the PROC_SYSCTL prompt to SYSCTL, > and s/CONFIG_PROC_SYSCTL/CONFIG_SYSCTL/ tree-wide. > > Signed-off-by: Oleg Nesterov > --- [...] > diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig > index 6ae966c561e7..24f5a36f45df 100644 > --- a/fs/proc/Kconfig > +++ b/fs/proc/Kconfig > @@ -80,10 +80,9 @@ config PROC_VMCORE_DEVICE_RAM > > Relevant architectures should select NEED_PROC_VMCORE_DEVICE_RAM. > > -config PROC_SYSCTL > +config SYSCTL > bool "Sysctl support (/proc/sys)" if EXPERT > depends on PROC_FS > - select SYSCTL > default y > help > The sysctl interface provides a means of dynamically changing Please be aware that renaming of Kconfig symbols may not be welcomed due to unwanted effects for users and for bisecting, cp. last paragraph of https://docs.kernel.org/process/handling-regressions.html#handling-regressions and the original thread. Personally, I do understand that it makes sense to clean this up, here. As the default was and stays 'y' this should affect only "few" users, but still I am feeling ambigious about it. Sorry for missing to point to that at the RFC. Kind regards, Nicolas