Re: [PATCH RFC v3 00/13] sysctl: add module aliases

On Thu, Aug 20, 2026 at 06:22:13PM -0300, Mauricio Faria de Oliveira wrote:

On 2026-08-20 09:51, Joel Granados wrote:

quoted

On Wed, Aug 19, 2026 at 03:16:13PM -0300, Mauricio Faria de Oliveira wrote:

quoted

This series adds 'sysctl:' aliases to modules that register sysctl tables; e.g.:

        $ modinfo ./mpls_router.ko  | grep sysctl:
        alias:          sysctl:*/net/mpls/conf/*/input
        alias:          sysctl:*/net/mpls/default_ttl
        alias:          sysctl:*/net/mpls/ip_ttl_propagate
        alias:          sysctl:*/net/mpls/platform_labels

It provides a trivial way to map /proc/sys files to modules (not trivial today),
and for userspace to handle nonexistent /proc/sys files (e.g., procps's sysctl
and systemd-sysctl applying tunables) with "modprobe sysctl:<...>" and a retry.

This is done almost automatically with register_sysctl(), register_net_sysctl()
and friends as wrappers of MODULE_SYSCTL_TABLE (similar to MODULE_DEVICE_TABLE),
which emits symbols for file2alias/modpost to find and parse the sysctl tables.

The big exception to 'almost' are sysctl tables and paths allocated or defined
at runtime (e.g., per-namespace or per-device), as all information is required
at build-time. Fortunately, such tables and paths are often based on 'templates'
which are static and can be used.

This is done by plumbing the template table/path as optional arguments (macros
with default values as default_gfp()), so not to create functions for all cases:

        register_sysctl(path, table [, table_tmpl [, path_tmpl]]);
        register_net_sysctl(net, path, table [, table_tmpl[, path_tmpl]]);
        register_net_sysctl_sz(net, path, table, size [, table_tmpl[, path_tmpl]]);

The "what" is described but I'm missing more clarity on the "why". Why
does this need to be trivial? Where is it that you will know the sysctl
file path of a module and not the module name or alias?

Thanks for looking at this.

The problem this feature addresses is sysctl settings not applied
because modules aren't yet loaded when systemd-sysctl/procps's sysctl
runs on boot, and the usage of /etc/modules as a workaround.

Sorry for insisting, but is it not possible to set the sysctls after the
modules have been loaded? Why is the order to first set the sysctl and
then load the module?

This can be addressed with a way for sysctl tools to load the module for
a non-existent sysctl file path.
For that, the mapping between a sysctl file path (known) and its module
(unknown) needs to be trivial.

This touches on my question. How is the file path known and the module
not known? The module is the one providing the paths, not the other way
around. Why choose to just work with sysctl path lists and not include
the modules that go with them?

It may not seem serious at first, but I've seen this consume significant
engineering time and impact production systems, in a previous technical
support job.
An example: cloud deployments with non-scalable network routing
performance due to nf_conntrack_max not applied after reboot or an
upgrade because the component which turned out to help with the
/etc/modules workaround had its placement changed from network router
nodes.

This is more understandable to me. The issue is that you loose the
relationship between sysctl paths and modules on updates. Are there
other cases where the module would not be loaded?

And doesn't it create another problem where you will load modules that
you don't expect (on the update)?

quoted

Additionally, sysctls are not module specific; they are a way to
read/write kernel variables. Putting a module specific aspect in the
function arguments (that needs to be ignored in non-module cases) seems
wrong. Why not use the module subsys to add sysctl alias instead of the
sysctl subsys?

Fair point. The current design has 2 reasons:

1) Use the 'path' argument (raised in [1]), only available in the
register sysctl functions.
2) Use a more implicit/transparent approach, instead of more
explicit/declarative approach. 

I get that the data is there and you would be able to do it, but it
still seems misplaced. Additionally, are you planning to move all the
modules to this scheme? If not, does that mean that some modules would
work and some wouldn't? And how would you make sure that modules would
use the correct call moving forward?

I guess that a different design could use MODULE_SYSCTL_TABLE() as
MODULE_DEVICE_TABLE(), declared per table instead of wrapped into
register sysctl functions.
However, it seems to require moving the value of the path argument (or
its template) into the macro and still referencing it in the function
(or its instantiation of the template), which adds obfuscation, to all
callers. 

What do you think?

It might be that having it inside the module subsys is more work, but I
believe that there is the right place to have it. I still don't see that
adding a module specific arg to the sysctl register is a good thing.


Best