[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20230302202826.776286-1-mcgrof@kernel.org>
Date: Thu, 2 Mar 2023 12:28:15 -0800
From: Luis Chamberlain <mcgrof@...nel.org>
To: ebiederm@...ssion.com, keescook@...omium.org, yzaikin@...gle.com,
john.johansen@...onical.com, paul@...l-moore.com,
jmorris@...ei.org, serge@...lyn.com, luto@...capital.net,
wad@...omium.org, dverkamp@...omium.org, paulmck@...nel.org,
baihaowen@...zu.com, frederic@...nel.org, jeffxu@...gle.com,
ebiggers@...nel.org, tytso@....edu, guoren@...nel.org
Cc: j.granados@...sung.com, zhangpeng362@...wei.com,
tangmeng@...ontech.com, willy@...radead.org, nixiaoming@...wei.com,
sujiaxun@...ontech.com, patches@...ts.linux.dev,
linux-fsdevel@...r.kernel.org, apparmor@...ts.ubuntu.com,
linux-security-module@...r.kernel.org, linux-csky@...r.kernel.org,
linux-kernel@...r.kernel.org, Luis Chamberlain <mcgrof@...nel.org>
Subject: [PATCH 00/11] sysctl: deprecate register_sysctl_paths()
As we trim down the insane kernel/sysctl.c large array and move
sysctls out we're looking to optimize the way we do syctl registrations
so we deal with just flat entries so to make the registration code
much easier to maintain and so it does not recurse. In dealing with
some of these things it reminded us that we will eventually get to the
point of just passing in the ARRAY_SIZE() we want, to get there we
should strive to move away from the older callers that do need the
recursion. Turns out tons of users don't need the recursion already
so we can start converting those over.
register_sysctl_paths() can do recursion when its users have sysctl
entries with directories and and then subdirectories with other entries.
This *typically* was the use case in the large sysctl array in
kernel/sysctl.c but as we trim that down we're phasing out the users
that have subdirectories. This means that the code path that can do
recursion is being mitigated over time and the code can be simplified
as well.
There are however many existing users of register_sysctl_paths() which
don't need to deal with subdirectories, and register_sysctl() and the
init version register_sysctl_init() (used when you don't care for the
initial return value / need to de-register) can create subdirectories
for you if you have no entries in between. So just convert these
users to the simpler APIs and deprecate out register_sysctl_paths().
The next step after this is to to start deprecating slowly the callers
of register_sysctl_table(). I'll send a out second batch for those that
apply on top of this.
Unless folks have an issue, I can offer to take these in the sysctl-next
tree as we sweep these out, but I'm happy for folks to take these into
their tree as well if they want. The only possible conflict would be
timing, ie, if the final patch which removes the API call. That patch
could also just wait another or two cycles later.
Luis Chamberlain (11):
proc_sysctl: update docs for __register_sysctl_table()
proc_sysctl: move helper which creates required subdirectories
sysctl: clarify register_sysctl_init() base directory order
apparmor: simplify sysctls with register_sysctl_init()
loadpin: simplify sysctls use with register_sysctl()
yama: simplfy sysctls with register_sysctl()
seccomp: simplify sysctls with register_sysctl_init()
kernel: pid_namespace: simplify sysctls with register_sysctl()
fs-verity: simplify sysctls with register_sysctl()
csky: simplify alignment sysctl registration
proc_sysctl: deprecate register_sysctl_paths()
arch/csky/abiv1/alignment.c | 15 +-----
fs/proc/proc_sysctl.c | 95 +++++++++++++++++++------------------
fs/verity/signature.c | 9 +---
include/linux/sysctl.h | 11 -----
kernel/pid_namespace.c | 3 +-
kernel/pid_sysctl.h | 3 +-
kernel/seccomp.c | 15 +-----
security/apparmor/lsm.c | 8 +---
security/loadpin/loadpin.c | 8 +---
security/yama/yama_lsm.c | 8 +---
10 files changed, 56 insertions(+), 119 deletions(-)
--
2.39.1
Powered by blists - more mailing lists