linux/fs/proc/proc_sysctl.c, branch v6.16

fix proc_sys_compare() handling of in-lookup dentries

2025-07-04T00:59:09Z

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

Pass parent directory inode and expected name to ->d_revalidate()

2025-01-28T00:25:23Z

->d_revalidate() often needs to access dentry parent and name; that has to be done carefully, since the locking environment varies from caller to caller. We are not guaranteed that dentry in question will not be moved right under us - not unless the filesystem is such that nothing on it ever gets renamed. It can be dealt with, but that results in boilerplate code that isn't even needed - the callers normally have just found the dentry via dcache lookup and want to verify that it's in the right place; they already have the values of ->d_parent and ->d_name stable. There is a couple of exceptions (overlayfs and, to less extent, ecryptfs), but for the majority of calls that song and dance is not needed at all. It's easier to make ecryptfs and overlayfs find and pass those values if there's a ->d_revalidate() instance to be called, rather than doing that in the instances. This commit only changes the calling conventions; making use of supplied values is left to followups. NOTE: some instances need more than just the parent - things like CIFS may need to build an entire path from filesystem root, so they need more precautions than the usual boilerplate. This series doesn't do anything to that need - these filesystems have to keep their locking mechanisms (rename_lock loops, use of dentry_path_raw(), private rwsem a-la v9fs). One thing to keep in mind when using name is that name->name will normally point into the pathname being resolved; the filename in question occupies name->len bytes starting at name->name, and there is NUL somewhere after it, but it the next byte might very well be '/' rather than '\0'. Do not ignore name->len. Reviewed-by: Jeff Layton Reviewed-by: Gabriel Krisman Bertazi Signed-off-by: Al Viro

sysctl: Reduce dput(child) calls in proc_sys_fill_cache()

2024-10-31T10:39:55Z

Replace two dput(child) calls with one that occurs immediately before the IS_ERR evaluation. This transformation can be performed because dput() gets called regardless of the value returned by IS_ERR(res). This issue was transformed by using a script for the semantic patch language like the following. @extended_adjustment@ expression e, f != { mutex_unlock }, x, y; @@ +f(e); if (...) { <+... when != \( e = x \| y(..., &e, ...) \) - f(e); ...+> } -f(e); Signed-off-by: Markus Elfring Reviewed-by: Joel Granados Signed-off-by: Joel Granados

sysctl: Convert locking comments to lockdep assertions

2024-10-10T19:01:17Z

The assertions work as well as the comment to inform developers about locking expectations. Additionally they are validated by lockdep at runtime, making sure the expectations are met. Signed-off-by: Thomas Weißschuh Signed-off-by: Joel Granados

sysctl: make internal ctl_tables const

2024-10-09T11:39:11Z

Now that the sysctl core can handle registration of "const struct ctl_table" constify the sysctl internal tables. Signed-off-by: Thomas Weißschuh Signed-off-by: Joel Granados

sysctl: allow registration of const struct ctl_table

2024-10-09T11:39:11Z

Putting structure, especially those containing function pointers, into read-only memory makes the safer and easier to reason about. Change the sysctl registration APIs to allow registration of "const struct ctl_table". Signed-off-by: Thomas Weißschuh Acked-by: Kees Cook Reviewed-by: Kees Cook # security/* Signed-off-by: Joel Granados

sysctl: move internal interfaces to const struct ctl_table

2024-10-09T11:39:11Z

As a preparation to make all the core sysctl code work with const struct ctl_table switch over the internal function to use the const variant. Some pointers to "struct ctl_table" need to stay non-const as they are newly allocated and modified before registration. Signed-off-by: Thomas Weißschuh Signed-off-by: Joel Granados

sysctl: avoid spurious permanent empty tables

2024-09-02T08:37:37Z

The test if a table is a permanently empty one, inspects the address of the registered ctl_table argument. However as sysctl_mount_point is an empty array and does not occupy and space it can end up sharing an address with another object in memory. If that other object itself is a "struct ctl_table" then registering that table will fail as it's incorrectly recognized as permanently empty. Avoid this issue by adding a dummy element to the array so that is not empty anymore. Explicitly register the table with zero elements as otherwise the dummy element would be recognized as a sentinel element which would lead to a runtime warning from the sysctl core. While the issue seems not being encountered at this time, this seems mostly to be due to luck. Also a future change, constifying sysctl_mount_point and root_table, can reliably trigger this issue on clang 18. Given that empty arrays are non-standard in the first place it seems prudent to avoid them if possible. Fixes: 4a7b29f65094 ("sysctl: move sysctl type to ctl_table_header") Fixes: a35dd3a786f5 ("sysctl: drop now unnecessary out-of-bounds check") Cc: stable@vger.kernel.org Signed-off-by: Thomas Weißschuh Closes: https://lore.kernel.org/oe-lkp/202408051453.f638857e-lkp@intel.com Signed-off-by: Joel Granados

sysctl: Warn on an empty procname element

2024-06-13T08:50:52Z

Add a pr_err warning in case a ctl_table is registered with a sentinel element containing a NULL procname. Signed-off-by: Joel Granados

sysctl: Remove ctl_table sentinel code comments

2024-06-13T08:50:52Z

Remove the mention of a "zero terminated entry" from the __register_sysctl_table function doc. Signed-off-by: Joel Granados