kernel/linux.git/fs/proc/proc_sysctl.c, branch v6.1.168

fix proc_sys_compare() handling of in-lookup dentries

2025-07-17T16:32:05+00:00

[ Upstream commit b969f9614885c20f903e1d1f9445611daf161d6d ] There's one case where ->d_compare() can be called for an in-lookup dentry; usually that's nothing special from ->d_compare() point of view, but... proc_sys_compare() is weird. The thing is, /proc/sys subdirectories can look differently for different processes. Up to and including having the same name resolve to different dentries - all of them hashed. The way it's done is ->d_compare() refusing to admit a match unless this dentry is supposed to be visible to this caller. The information needed to discriminate between them is stored in inode; it is set during proc_sys_lookup() and until it's done d_splice_alias() we really can't tell who should that dentry be visible for. Normally there's no negative dentries in /proc/sys; we can run into a dying dentry in RCU dcache lookup, but those can be safely rejected. However, ->d_compare() is also called for in-lookup dentries, before they get positive - or hashed, for that matter. In case of match we will wait until dentry leaves in-lookup state and repeat ->d_compare() afterwards. In other words, the right behaviour is to treat the name match as sufficient for in-lookup dentries; if dentry is not for us, we'll see that when we recheck once proc_sys_lookup() is done with it. While we are at it, fix the misspelled READ_ONCE and WRITE_ONCE there. Fixes: d9171b934526 ("parallel lookups machinery, part 4 (and last)") Reported-by: NeilBrown Reviewed-by: Christian Brauner Reviewed-by: NeilBrown Signed-off-by: Al Viro Signed-off-by: Sasha Levin

sysctl: always initialize i_uid/i_gid

2024-08-11T10:35:51+00:00

[ Upstream commit 98ca62ba9e2be5863c7d069f84f7166b45a5b2f4 ] Always initialize i_uid/i_gid inside the sysfs core so set_ownership() can safely skip setting them. Commit 5ec27ec735ba ("fs/proc/proc_sysctl.c: fix the default values of i_uid/i_gid on /proc/sys inodes.") added defaults for i_uid/i_gid when set_ownership() was not implemented. It also missed adjusting net_ctl_set_ownership() to use the same default values in case the computation of a better value failed. Fixes: 5ec27ec735ba ("fs/proc/proc_sysctl.c: fix the default values of i_uid/i_gid on /proc/sys inodes.") Cc: stable@vger.kernel.org Signed-off-by: Thomas Weißschuh Signed-off-by: Joel Granados Signed-off-by: Sasha Levin

sysctl: treewide: drop unused argument ctl_table_root::set_ownership(table)

2024-08-11T10:35:51+00:00

[ Upstream commit 520713a93d550406dae14d49cdb8778d70cecdfd ] Remove the 'table' argument from set_ownership as it is never used. This change is a step towards putting "struct ctl_table" into .rodata and eventually having sysctl core only use "const struct ctl_table". The patch was created with the following coccinelle script: @@ identifier func, head, table, uid, gid; @@ void func( struct ctl_table_header *head, - struct ctl_table *table, kuid_t *uid, kgid_t *gid) { ... } No additional occurrences of 'set_ownership' were found after doing a tree-wide search. Reviewed-by: Joel Granados Signed-off-by: Thomas Weißschuh Signed-off-by: Joel Granados Stable-dep-of: 98ca62ba9e2b ("sysctl: always initialize i_uid/i_gid") Signed-off-by: Sasha Levin

watchdog: move softlockup_panic back to early_param

2023-11-28T17:07:09+00:00

commit 8b793bcda61f6c3ed4f5b2ded7530ef6749580cb upstream. Setting softlockup_panic from do_sysctl_args() causes it to take effect later in boot. The lockup detector is enabled before SMP is brought online, but do_sysctl_args runs afterwards. If a user wants to set softlockup_panic on boot and have it trigger should a softlockup occur during onlining of the non-boot processors, they could do this prior to commit f117955a2255 ("kernel/watchdog.c: convert {soft/hard}lockup boot parameters to sysctl aliases"). However, after this commit the value of softlockup_panic is set too late to be of help for this type of problem. Restore the prior behavior. Signed-off-by: Krister Johansen Cc: stable@vger.kernel.org Fixes: f117955a2255 ("kernel/watchdog.c: convert {soft/hard}lockup boot parameters to sysctl aliases") Signed-off-by: Luis Chamberlain Signed-off-by: Greg Kroah-Hartman

proc: sysctl: prevent aliased sysctls from getting passed to init

2023-11-28T17:07:08+00:00

commit 8001f49394e353f035306a45bcf504f06fca6355 upstream. The code that checks for unknown boot options is unaware of the sysctl alias facility, which maps bootparams to sysctl values. If a user sets an old value that has a valid alias, a message about an invalid parameter will be printed during boot, and the parameter will get passed to init. Fix by checking for the existence of aliased parameters in the unknown boot parameter code. If an alias exists, don't return an error or pass the value to init. Signed-off-by: Krister Johansen Cc: stable@vger.kernel.org Fixes: 0a477e1ae21b ("kernel/sysctl: support handling command line aliases") Signed-off-by: Luis Chamberlain Signed-off-by: Greg Kroah-Hartman

sysctl: clarify register_sysctl_init() base directory order

2023-05-17T09:53:46+00:00

commit 228b09de936395ddd740df3522ea35ae934830d8 upstream. Relatively new docs which I added which hinted the base directories needed to be created before is wrong, remove that incorrect comment. This has been hinted before by Eric twice already [0] [1], I had just not verified that until now. Now that I've verified that updates the docs to relax the context described. [0] https://lkml.kernel.org/r/875ys0azt8.fsf@email.froward.int.ebiederm.org [1] https://lkml.kernel.org/r/87ftbiud6s.fsf@x220.int.ebiederm.org Cc: stable@vger.kernel.org # v5.17 Cc: Christian Brauner Cc: Kefeng Wang Suggested-by: Eric W. Biederman Signed-off-by: Luis Chamberlain Signed-off-by: Greg Kroah-Hartman

proc_sysctl: enhance documentation

2023-05-17T09:53:45+00:00

commit 1dc8689e4cc651e21566e10206a84c4006e81fb1 upstream. Expand documentation to clarify: o that paths don't need to exist for the new API callers o clarify that we *require* callers to keep the memory of the table around during the lifetime of the sysctls o annotate routines we are trying to deprecate and later remove Cc: stable@vger.kernel.org # v5.17 Cc: Christian Brauner Cc: Kefeng Wang Signed-off-by: Luis Chamberlain Signed-off-by: Greg Kroah-Hartman

proc_sysctl: update docs for __register_sysctl_table()

2023-05-17T09:53:45+00:00

commit 67ff32289acad9ed338cd9f2351b44939e55163e upstream. Update the docs for __register_sysctl_table() to make it clear no child entries can be passed. When the child is true these are non-leaf entries on the ctl table and sysctl treats these as directories. The point to __register_sysctl_table() is to deal only with directories not part of the ctl table where thay may riside, to be simple and avoid recursion. While at it, hint towards using long on extra1 and extra2 later. Cc: stable@vger.kernel.org # v5.17 Cc: Christian Brauner Cc: Kefeng Wang Signed-off-by: Luis Chamberlain Signed-off-by: Greg Kroah-Hartman

kernel/sysctl.c: move sysctl_vals and sysctl_long_vals to sysctl.c

2022-09-08T23:56:45+00:00

sysctl_vals and sysctl_long_vals are declared even if sysctl is disabled. Move its definition to sysctl.c to make sure their integrity in any case. Signed-off-by: Liu Shixin Signed-off-by: Luis Chamberlain

proc: remove initialization assignment

2022-09-08T23:39:36+00:00

The allocation address of the core_parent pointer variable is first executed in the function, no initialization assignment is required. Signed-off-by: Li zeming Signed-off-by: Luis Chamberlain