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]]);

In this series:
- Patch 1 prevents a build error later.
- Patch 2 adds CONFIG_SYSCTL_MODULE_ALIASES.
- Patch 3 adds MODULE_SYSCTL_TABLE().
- Patches 4-5 add register_sysctl() wrapper and update some callers.
- Patches 6-10 add register_net_sysctl[_sz]() wrappers and update some callers.
- Patches 11-13 add file2alias support.

Not all maintainers/reviewers (specially for the many changes in net/) are
in To/Cc in respect of their time, as this RFC probably needs more general
and earlier feedback before settling on specific changes for their review.
All lists are included for visibility, though.

Example
=======

To put it all together, 'mpls_router.ko' (used above) from 'net/mpls/af_mpls.c':
        
- Tables:

        static const struct ctl_table mpls_table[] = {
                {
                        .procname       = "platform_labels",
                ...
                        .procname       = "ip_ttl_propagate",
                ...
                        .procname       = "default_ttl",
                },
        };
        
        static const struct ctl_table mpls_dev_table[] = {
                {
                        .procname       = "input",
                ...
                },
        };

- Registration:

        net->mpls.ctl = register_net_sysctl_sz(net, "net/mpls", table,
                                               table_size, mpls_table);

        #define path_template "net/mpls/conf/%s"
        ...
        mdev->sysctl = register_net_sysctl_sz(net, path, table, table_size,
                                              mpls_dev_table, path_template);

- Symbols:

        $ objdump -t net/mpls/mpls_router.ko \
          | grep '__mod_device_table__.*__sysctl__'
        0000000000000900 l     O .data  0000000000000018
                __mod_device_table__kmod_mpls_router__sysctl__mpls_table.177
        0000000000000940 l     O .data  0000000000000018
                __mod_device_table__kmod_mpls_router__sysctl__mpls_dev_table.174

- file2alias:

        $ grep '^MODULE_ALIAS("sysctl:' net/mpls/mpls_router.mod.c
        MODULE_ALIAS("sysctl:*/net/mpls/platform_labels");
        MODULE_ALIAS("sysctl:*/net/mpls/ip_ttl_propagate");
        MODULE_ALIAS("sysctl:*/net/mpls/default_ttl");
        MODULE_ALIAS("sysctl:*/net/mpls/conf/*/input");

- modinfo:

        $ 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

Testing
=======

Configurations:
- allmodconfig with the option enabled (check for 'MODULE_ALIAS("sysctl:' lines)
- allmodconfig with the option disabled (check for code errors)
- allyesconfig with the option enabled (check for include errors)

Architectures (test different bitness, endianness, and ELF handling)
- x86_64, i386
- arm, arm64
- arc
- alpha
- loongarch
- m68k
- mips(64)(el)
- parisc(64)
- powerpc(64(le))
- riscv
- sparc64
- s390

The resulting '.mod.c' files of allmodconfig with the option enabled was checked
for consistency across all architectures, and that the new aliases lines are the
difference to allmodconfig with the option disabled.

Disabling
=========

- Per-call:

  Use 'register_sysctl_sz()' or '__register_net_sysctl_sz()' directly.

- Per-file:

  Use '#define SYSCTL_MODULE_ALIASES_DISABLE'.

- System-wide:

  Maybe something along these lines:

        # cat /etc/modprobe.d/no-sysctl.conf
        alias sysctl:* no-sysctl
        install no-sysctl /bin/false

        # modinfo -F name sysctl:/proc/net/mpls/default_ttl
        mpls_router

        # modprobe sysctl:/proc/net/mpls/default_ttl
        modprobe: ERROR: Error running install command '/bin/false' for module no_sysctl: retcode 1
        modprobe: ERROR: could not insert 'no_sysctl': Invalid argument

P.S.
====

I wrote proof-of-concept patches for procps sysctl and systemd-sysctl some time
ago, which worked as expected, i.e., successfully set sysctl tunables which did
not exist in /proc/sys, by running 'modprobe sysctl:/proc/sys/...' and retrying.

Should this series eventually be merged, the patches will be submitted upstream
as well, for userspace to start consuming it.

Signed-off-by: Mauricio Faria de Oliveira <mfo@igalia.com>

Changes in v3:
- All issues were reported by sashiko-bot@kernel.org.
- Tested allmodconfig with option enabled on x86_64.
- Patch 2:
  - Fix typo ('s/options/option/').
- Patch 3:
  - Fix usage of __UNIQUE_ID().
  - Add __must_be_array() in MODULE_SYSCTL_TABLE().
- Patch 4:
  - Remove trailing backslash in register_sysctl().
- Patch 6:
  - Fix missing __register_net_sysctl_sz() in !CONFIG_SYSCTL.
- Patch 13:
  - Fix potential out-of-bounds read in do_sysctl_entry().
  - Add check for entry size of zero.
- Link to v2: https://lore.kernel.org/r/20260818-sysctl-module-aliases-v2-0-d5a69dae5798@igalia.com

Changes in v2:
- This is based on the series submitted 4 years ago,
  with Originally-by: tags added in related patches.
- Link to v1: https://lore.kernel.org/linux-fsdevel/20220722022416.137548-1-mfo@canonical.com/

---
Mauricio Faria de Oliveira (13):
      keys, pidns, fs/verity, riscv/vector: reorder '#include <linux/sysctl.h>'
      proc: add config option SYSCTL_MODULE_ALIASES
      sysctl, mod_devicetable: add macro MODULE_SYSCTL_TABLE
      sysctl: add register_sysctl() wrapper for MODULE_SYSCTL_TABLE
      sysctl, parport: update register_sysctl() callers with template arguments
      sysctl, net: add register_net_sysctl{_sz}() wrappers for MODULE_SYSCTL_TABLE
      sysctl, net: update register_net_sysctl{_sz}() callers with template arguments
      sysctl, net: update register_net_sysctl_sz(ARRAY_SIZE(table_tmpl)) with template arguments
      sysctl, ipv6: update register_net_sysctl{_sz}() callers with template arguments
      sysctl, net: update register_net_sysctl_sz() edge case
      sysctl: unrandomize struct ctl_table.procname
      modpost: move addend_*_rel() calls into addend_rel()
      modpost: handle MODULE_SYSCTL_TABLE symbols

 arch/riscv/kernel/vector.c              |   1 +
 drivers/net/vrf.c                       |   3 +-
 drivers/parport/procfs.c                |  26 +++-
 fs/proc/Kconfig                         |  13 ++
 fs/verity/init.c                        |   1 +
 include/linux/key.h                     |   1 -
 include/linux/mod_devicetable.h         |   7 +
 include/linux/pid_namespace.h           |   1 +
 include/linux/sysctl.h                  | 110 ++++++++++++++-
 include/net/ipv6.h                      |   6 +-
 include/net/net_namespace.h             |  47 ++++++-
 net/bridge/br_netfilter_hooks.c         |   3 +-
 net/core/neighbour.c                    |  11 +-
 net/core/sysctl_net_core.c              |   3 +-
 net/ieee802154/6lowpan/reassembly.c     |   2 +-
 net/ipv4/devinet.c                      |  12 +-
 net/ipv4/ip_fragment.c                  |   3 +-
 net/ipv4/route.c                        |   3 +-
 net/ipv4/sysctl_net_ipv4.c              |   2 +-
 net/ipv4/xfrm4_policy.c                 |   3 +-
 net/ipv6/addrconf.c                     |   7 +-
 net/ipv6/icmp.c                         |   6 +-
 net/ipv6/netfilter/nf_conntrack_reasm.c |   4 +-
 net/ipv6/reassembly.c                   |   3 +-
 net/ipv6/route.c                        |  10 +-
 net/ipv6/sysctl_net_ipv6.c              |  13 +-
 net/ipv6/xfrm6_policy.c                 |   3 +-
 net/mpls/af_mpls.c                      |   9 +-
 net/mptcp/ctrl.c                        |   3 +-
 net/netfilter/ipvs/ip_vs_ctl.c          |   4 +-
 net/netfilter/ipvs/ip_vs_lblc.c         |   3 +-
 net/netfilter/ipvs/ip_vs_lblcr.c        |   3 +-
 net/netfilter/nf_conntrack_standalone.c |   5 +-
 net/netfilter/nf_log.c                  |   9 +-
 net/rds/tcp.c                           |   4 +-
 net/sctp/sysctl.c                       |   3 +-
 net/smc/smc_sysctl.c                    |   2 +-
 net/sysctl_net.c                        |  10 +-
 net/unix/sysctl_net_unix.c              |   3 +-
 net/vmw_vsock/af_vsock.c                |   4 +-
 net/xfrm/xfrm_sysctl.c                  |   2 +-
 scripts/mod/devicetable-offsets.c       |   6 +
 scripts/mod/file2alias.c                | 237 ++++++++++++++++++++++++++++++++
 scripts/mod/modpost.c                   |  46 ++++---
 scripts/mod/modpost.h                   |  25 ++++
 45 files changed, 575 insertions(+), 107 deletions(-)
---
base-commit: 2697ef8943c9985c14708a6429e21812693857b2
change-id: 20260818-sysctl-module-aliases-2f5801b1eb71

Best regards,
-- 
Mauricio Faria de Oliveira <mfo@igalia.com>

On Wed, Aug 19, 2026 at 03:16:13PM -0300, Mauricio Faria de Oliveira wrote:
> 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?

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?

> 
> In this series:
> - Patch 1 prevents a build error later.
> - Patch 2 adds CONFIG_SYSCTL_MODULE_ALIASES.
> - Patch 3 adds MODULE_SYSCTL_TABLE().
> - Patches 4-5 add register_sysctl() wrapper and update some callers.
> - Patches 6-10 add register_net_sysctl[_sz]() wrappers and update some callers.
> - Patches 11-13 add file2alias support.
> 
> Not all maintainers/reviewers (specially for the many changes in net/) are
> in To/Cc in respect of their time, as this RFC probably needs more general
> and earlier feedback before settling on specific changes for their review.
> All lists are included for visibility, though.
> 
> Example
> =======
> 
> To put it all together, 'mpls_router.ko' (used above) from 'net/mpls/af_mpls.c':
>         
> - Tables:
> 
>         static const struct ctl_table mpls_table[] = {
>                 {
>                         .procname       = "platform_labels",
>                 ...
>                         .procname       = "ip_ttl_propagate",
>                 ...
>                         .procname       = "default_ttl",
>                 },
>         };
<... snip ...>
> 
> - Per-file:
> 
>   Use '#define SYSCTL_MODULE_ALIASES_DISABLE'.
> 
> - System-wide:
> 
>   Maybe something along these lines:
> 
>         # cat /etc/modprobe.d/no-sysctl.conf
>         alias sysctl:* no-sysctl
>         install no-sysctl /bin/false
> 
>         # modinfo -F name sysctl:/proc/net/mpls/default_ttl
>         mpls_router
> 
>         # modprobe sysctl:/proc/net/mpls/default_ttl
>         modprobe: ERROR: Error running install command '/bin/false' for module no_sysctl: retcode 1
>         modprobe: ERROR: could not insert 'no_sysctl': Invalid argument
> 
> P.S.
> ====
> 
> I wrote proof-of-concept patches for procps sysctl and systemd-sysctl some time
> ago, which worked as expected, i.e., successfully set sysctl tunables which did
> not exist in /proc/sys, by running 'modprobe sysctl:/proc/sys/...' and retrying.

Do you have links to this? To the old one, not necessarily a new
version.

Best
> 
> Should this series eventually be merged, the patches will be submitted upstream
> as well, for userspace to start consuming it.
> 
> Signed-off-by: Mauricio Faria de Oliveira <mfo@igalia.com>
> 
> Changes in v3:
> - All issues were reported by sashiko-bot@kernel.org.
> - Tested allmodconfig with option enabled on x86_64.
> - Patch 2:
>   - Fix typo ('s/options/option/').
> - Patch 3:
>   - Fix usage of __UNIQUE_ID().
>   - Add __must_be_array() in MODULE_SYSCTL_TABLE().
> - Patch 4:
>   - Remove trailing backslash in register_sysctl().
> - Patch 6:
>   - Fix missing __register_net_sysctl_sz() in !CONFIG_SYSCTL.
> - Patch 13:
>   - Fix potential out-of-bounds read in do_sysctl_entry().
>   - Add check for entry size of zero.
> - Link to v2: https://lore.kernel.org/r/20260818-sysctl-module-aliases-v2-0-d5a69dae5798@igalia.com
> 
> Changes in v2:
> - This is based on the series submitted 4 years ago,
>   with Originally-by: tags added in related patches.
> - Link to v1: https://lore.kernel.org/linux-fsdevel/20220722022416.137548-1-mfo@canonical.com/
> 
> ---
> Mauricio Faria de Oliveira (13):
>       keys, pidns, fs/verity, riscv/vector: reorder '#include <linux/sysctl.h>'
>       proc: add config option SYSCTL_MODULE_ALIASES
>       sysctl, mod_devicetable: add macro MODULE_SYSCTL_TABLE
>       sysctl: add register_sysctl() wrapper for MODULE_SYSCTL_TABLE
>       sysctl, parport: update register_sysctl() callers with template arguments
>       sysctl, net: add register_net_sysctl{_sz}() wrappers for MODULE_SYSCTL_TABLE
>       sysctl, net: update register_net_sysctl{_sz}() callers with template arguments
>       sysctl, net: update register_net_sysctl_sz(ARRAY_SIZE(table_tmpl)) with template arguments
>       sysctl, ipv6: update register_net_sysctl{_sz}() callers with template arguments
>       sysctl, net: update register_net_sysctl_sz() edge case
>       sysctl: unrandomize struct ctl_table.procname
>       modpost: move addend_*_rel() calls into addend_rel()
>       modpost: handle MODULE_SYSCTL_TABLE symbols
> 
>  arch/riscv/kernel/vector.c              |   1 +
>  drivers/net/vrf.c                       |   3 +-
>  drivers/parport/procfs.c                |  26 +++-
>  fs/proc/Kconfig                         |  13 ++
>  fs/verity/init.c                        |   1 +
>  include/linux/key.h                     |   1 -
>  include/linux/mod_devicetable.h         |   7 +
>  include/linux/pid_namespace.h           |   1 +
>  include/linux/sysctl.h                  | 110 ++++++++++++++-
>  include/net/ipv6.h                      |   6 +-
>  include/net/net_namespace.h             |  47 ++++++-
>  net/bridge/br_netfilter_hooks.c         |   3 +-
>  net/core/neighbour.c                    |  11 +-
>  net/core/sysctl_net_core.c              |   3 +-
>  net/ieee802154/6lowpan/reassembly.c     |   2 +-
>  net/ipv4/devinet.c                      |  12 +-
>  net/ipv4/ip_fragment.c                  |   3 +-
>  net/ipv4/route.c                        |   3 +-
>  net/ipv4/sysctl_net_ipv4.c              |   2 +-
>  net/ipv4/xfrm4_policy.c                 |   3 +-
>  net/ipv6/addrconf.c                     |   7 +-
>  net/ipv6/icmp.c                         |   6 +-
>  net/ipv6/netfilter/nf_conntrack_reasm.c |   4 +-
>  net/ipv6/reassembly.c                   |   3 +-
>  net/ipv6/route.c                        |  10 +-
>  net/ipv6/sysctl_net_ipv6.c              |  13 +-
>  net/ipv6/xfrm6_policy.c                 |   3 +-
>  net/mpls/af_mpls.c                      |   9 +-
>  net/mptcp/ctrl.c                        |   3 +-
>  net/netfilter/ipvs/ip_vs_ctl.c          |   4 +-
>  net/netfilter/ipvs/ip_vs_lblc.c         |   3 +-
>  net/netfilter/ipvs/ip_vs_lblcr.c        |   3 +-
>  net/netfilter/nf_conntrack_standalone.c |   5 +-
>  net/netfilter/nf_log.c                  |   9 +-
>  net/rds/tcp.c                           |   4 +-
>  net/sctp/sysctl.c                       |   3 +-
>  net/smc/smc_sysctl.c                    |   2 +-
>  net/sysctl_net.c                        |  10 +-
>  net/unix/sysctl_net_unix.c              |   3 +-
>  net/vmw_vsock/af_vsock.c                |   4 +-
>  net/xfrm/xfrm_sysctl.c                  |   2 +-
>  scripts/mod/devicetable-offsets.c       |   6 +
>  scripts/mod/file2alias.c                | 237 ++++++++++++++++++++++++++++++++
>  scripts/mod/modpost.c                   |  46 ++++---
>  scripts/mod/modpost.h                   |  25 ++++
>  45 files changed, 575 insertions(+), 107 deletions(-)
> ---
> base-commit: 2697ef8943c9985c14708a6429e21812693857b2
> change-id: 20260818-sysctl-module-aliases-2f5801b1eb71
> 
> Best regards,
> -- 
> Mauricio Faria de Oliveira <mfo@igalia.com>
> 

On 2026-08-20 09:51, Joel Granados wrote:
> On Wed, Aug 19, 2026 at 03:16:13PM -0300, Mauricio Faria de Oliveira wrote:
>> 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.

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.

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.

> 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 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?

[snip]

>> P.S.
>> ====
>> 
>> I wrote proof-of-concept patches for procps sysctl and systemd-sysctl some time
>> ago, which worked as expected, i.e., successfully set sysctl tunables which did
>> not exist in /proc/sys, by running 'modprobe sysctl:/proc/sys/...' and retrying.
> 
> Do you have links to this? To the old one, not necessarily a new
> version.

Sure, please see [2] and [3]. I did a quick rebase/refresh, but both
seem to work:

procps sysctl:

    $ strace -e execve -f -s 64 ./src/sysctl --modprobe=1 -w net.test=1
2>&1 | grep modprobe

    [pid 505958] execve("/bin/sh", ["sh", "-c", "--", "modprobe
sysctl:/proc/sys/net/test >/dev/null 2>&1"], 0x7ffc12efff80 /* 63 vars
*/) = 0

systemd-sysctl:

$ cat /etc/sysctl.d/net-test.conf
net.test = 1

    $ sudo strace -e execve -f -s 64 ./build/systemd-sysctl
--modprobe=true /etc/sysctl.d/net-test.conf  2>&1 | grep modprobe

[pid 505777] execve("/usr/sbin/modprobe", ["modprobe",
"sysctl:*/net/test"], 0x7ffd473d1418 /* 20 vars */) = 0

Thanks,

[1]
https://lore.kernel.org/linux-fsdevel/CAK7LNAR=7zgOiqTD9okXfZXroFH1yagMFsRuq0G-z6OfSUPLQg@mail.gmail.com/
[2] https://github.com/mfoliveira/procps/commits/sysctl-module-aliases/
[3] https://github.com/mfoliveira/systemd/commits/sysctl-module-aliases/

> 
> Best
>> 
>> Should this series eventually be merged, the patches will be submitted upstream
>> as well, for userspace to start consuming it.
>> 
>> Signed-off-by: Mauricio Faria de Oliveira <mfo@igalia.com>
>> 
>> Changes in v3:
>> - All issues were reported by sashiko-bot@kernel.org.
>> - Tested allmodconfig with option enabled on x86_64.
>> - Patch 2:
>>   - Fix typo ('s/options/option/').
>> - Patch 3:
>>   - Fix usage of __UNIQUE_ID().
>>   - Add __must_be_array() in MODULE_SYSCTL_TABLE().
>> - Patch 4:
>>   - Remove trailing backslash in register_sysctl().
>> - Patch 6:
>>   - Fix missing __register_net_sysctl_sz() in !CONFIG_SYSCTL.
>> - Patch 13:
>>   - Fix potential out-of-bounds read in do_sysctl_entry().
>>   - Add check for entry size of zero.
>> - Link to v2: https://lore.kernel.org/r/20260818-sysctl-module-aliases-v2-0-d5a69dae5798@igalia.com
>> 
>> Changes in v2:
>> - This is based on the series submitted 4 years ago,
>>   with Originally-by: tags added in related patches.
>> - Link to v1: https://lore.kernel.org/linux-fsdevel/20220722022416.137548-1-mfo@canonical.com/
>> 
>> ---
>> Mauricio Faria de Oliveira (13):
>>       keys, pidns, fs/verity, riscv/vector: reorder '#include <linux/sysctl.h>'
>>       proc: add config option SYSCTL_MODULE_ALIASES
>>       sysctl, mod_devicetable: add macro MODULE_SYSCTL_TABLE
>>       sysctl: add register_sysctl() wrapper for MODULE_SYSCTL_TABLE
>>       sysctl, parport: update register_sysctl() callers with template arguments
>>       sysctl, net: add register_net_sysctl{_sz}() wrappers for MODULE_SYSCTL_TABLE
>>       sysctl, net: update register_net_sysctl{_sz}() callers with template arguments
>>       sysctl, net: update register_net_sysctl_sz(ARRAY_SIZE(table_tmpl)) with template arguments
>>       sysctl, ipv6: update register_net_sysctl{_sz}() callers with template arguments
>>       sysctl, net: update register_net_sysctl_sz() edge case
>>       sysctl: unrandomize struct ctl_table.procname
>>       modpost: move addend_*_rel() calls into addend_rel()
>>       modpost: handle MODULE_SYSCTL_TABLE symbols
>> 
>>  arch/riscv/kernel/vector.c              |   1 +
>>  drivers/net/vrf.c                       |   3 +-
>>  drivers/parport/procfs.c                |  26 +++-
>>  fs/proc/Kconfig                         |  13 ++
>>  fs/verity/init.c                        |   1 +
>>  include/linux/key.h                     |   1 -
>>  include/linux/mod_devicetable.h         |   7 +
>>  include/linux/pid_namespace.h           |   1 +
>>  include/linux/sysctl.h                  | 110 ++++++++++++++-
>>  include/net/ipv6.h                      |   6 +-
>>  include/net/net_namespace.h             |  47 ++++++-
>>  net/bridge/br_netfilter_hooks.c         |   3 +-
>>  net/core/neighbour.c                    |  11 +-
>>  net/core/sysctl_net_core.c              |   3 +-
>>  net/ieee802154/6lowpan/reassembly.c     |   2 +-
>>  net/ipv4/devinet.c                      |  12 +-
>>  net/ipv4/ip_fragment.c                  |   3 +-
>>  net/ipv4/route.c                        |   3 +-
>>  net/ipv4/sysctl_net_ipv4.c              |   2 +-
>>  net/ipv4/xfrm4_policy.c                 |   3 +-
>>  net/ipv6/addrconf.c                     |   7 +-
>>  net/ipv6/icmp.c                         |   6 +-
>>  net/ipv6/netfilter/nf_conntrack_reasm.c |   4 +-
>>  net/ipv6/reassembly.c                   |   3 +-
>>  net/ipv6/route.c                        |  10 +-
>>  net/ipv6/sysctl_net_ipv6.c              |  13 +-
>>  net/ipv6/xfrm6_policy.c                 |   3 +-
>>  net/mpls/af_mpls.c                      |   9 +-
>>  net/mptcp/ctrl.c                        |   3 +-
>>  net/netfilter/ipvs/ip_vs_ctl.c          |   4 +-
>>  net/netfilter/ipvs/ip_vs_lblc.c         |   3 +-
>>  net/netfilter/ipvs/ip_vs_lblcr.c        |   3 +-
>>  net/netfilter/nf_conntrack_standalone.c |   5 +-
>>  net/netfilter/nf_log.c                  |   9 +-
>>  net/rds/tcp.c                           |   4 +-
>>  net/sctp/sysctl.c                       |   3 +-
>>  net/smc/smc_sysctl.c                    |   2 +-
>>  net/sysctl_net.c                        |  10 +-
>>  net/unix/sysctl_net_unix.c              |   3 +-
>>  net/vmw_vsock/af_vsock.c                |   4 +-
>>  net/xfrm/xfrm_sysctl.c                  |   2 +-
>>  scripts/mod/devicetable-offsets.c       |   6 +
>>  scripts/mod/file2alias.c                | 237 ++++++++++++++++++++++++++++++++
>>  scripts/mod/modpost.c                   |  46 ++++---
>>  scripts/mod/modpost.h                   |  25 ++++
>>  45 files changed, 575 insertions(+), 107 deletions(-)
>> ---
>> base-commit: 2697ef8943c9985c14708a6429e21812693857b2
>> change-id: 20260818-sysctl-module-aliases-2f5801b1eb71
>> 
>> Best regards,
>> -- 
>> Mauricio Faria de Oliveira <mfo@igalia.com>
>>

-- 
Mauricio

On Thu, Aug 20, 2026 at 06:22:13PM -0300, Mauricio Faria de Oliveira wrote:
> On 2026-08-20 09:51, Joel Granados wrote:
> > On Wed, Aug 19, 2026 at 03:16:13PM -0300, Mauricio Faria de Oliveira wrote:
> >> 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)?

> 
> > 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

On 2026-09-04 10:41, Joel Granados wrote:
> On Thu, Aug 20, 2026 at 06:22:13PM -0300, Mauricio Faria de Oliveira wrote:
>> On 2026-08-20 09:51, Joel Granados wrote:
>> > On Wed, Aug 19, 2026 at 03:16:13PM -0300, Mauricio Faria de Oliveira wrote:
>> >> 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?

No worries, and thanks for getting back to this.

Yes, the former is possible and usually how that happens, but it is not
guaranteed, thus the latter might happen -- unintentionally.

For example, a sysctl setting can be configured in /etc/sysctl.d/*.conf,
which is manually tested and confirmed to apply it correctly. However,
that might have worked only because its module was inadvertently loaded
earlier (e.g., for something else by the sysadmin, or by something else
in the system). The next time the system boots, the module is not
automatically loaded, thus the sysctl setting fails to be applied when
the (previously working) /etc/sysctl.d/*.conf is parsed.

Also, a sysctl setting may, or may not, be tied to a module; it can be
built-in. This can change with kernel configuration, e.g., distro.

So, another example: a sysadmin learns of a sysctl setting in
documentation tested with another distro, which has it built-in. It
fails to apply on this distro, which has it in a module, because the
module isn't loaded. (Now the sysadmin is left to figure that out, and
then which kernel module provides the sysctl setting.) 

Note that both examples can be combined. (And the poor sysadmin is, in a
reboot happening days/weeks/months later, left to also figure out that
the sysctl setting is not applied, and whatever effect that caused,
because that particular module was not loaded on boot, and should be
added to /etc/modules).

>> 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?

The sysctl tools and configuration files only know about the file path,
not the module. The sysctl tools know the file path when parsing the
configuration files, converting a 'dir.file = value' line into opening
/proc/sys/dir/value and writing value into it.

The format of configuration files only include file paths and values,
but not modules, per sysctl.conf(5) and sysctl.d(5). This is reasonable,
as there may, or may not, be a module for the sysctl setting (i.e.,
module vs. built-in).

Maybe I misunderstand the context for your questions; please let me
know.
Also, could you please clarify what you mean by 'include the modules
that go with them' [sysctl path files] ?

>> 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?

In general, there is no guarantee that a module is loaded by the time a
sysctl setting is about to be applied -- during system boot or even
later.

The example for system boot is covered previously. An example for
'later' / after system boot: on network device testing which includes
module unload/reload and sysctl settings for network performance, one
might unload the module, and mistakenly first apply sysctl settings then
reload the module, thus loosing the performance tuning on that one
testing round.

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

Sorry, not sure I understand the meaning of 'update' correctly, but yes,
if there is a hard-coded module load (e.g., /etc/modules or in scripts),
that happens. However, AFAICT, loading unexpected modules is less of a
problem than not loading required modules, or may not be a problem.

With an auto-load mechanism in place, hard-coding/force-load is not
required, and neither problem (loading unexpected modules due to
hard-coding, and not loading required modules due to lack of
hard-coding) would happen, IIUIC.

>> > 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?

This scheme currently covers all modules, AFAIK, as it is wrapped in the
functions that register sysctl tables.

On moving forward: usage of such functions in a way that breaks a
requirement of this series (e.g., failing to specify the template
table/path parameter(s), or not having constant initializers) hits a
build error, as the requirements are actually from the compiler.

>> 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.

Ok, cool. I can work on a different design.

Please just let me know whether you are OK with the remaining (above),
and I'll be happy to tackle this.

Thanks again,

> 
> 
> Best

-- 
Mauricio

On Fri, Sep 04, 2026 at 02:45:23PM -0300, Mauricio Faria de Oliveira wrote:
> On 2026-09-04 10:41, Joel Granados wrote:
> > On Thu, Aug 20, 2026 at 06:22:13PM -0300, Mauricio Faria de Oliveira wrote:
> >> On 2026-08-20 09:51, Joel Granados wrote:
> >> > On Wed, Aug 19, 2026 at 03:16:13PM -0300, Mauricio Faria de Oliveira wrote:
> >> >> This series adds 'sysctl:' aliases to modules that register sysctl tables; e.g.:
<... snip ...>
> > use the correct call moving forward?
> 
> This scheme currently covers all modules, AFAIK, as it is wrapped in the
> functions that register sysctl tables.
> 
> On moving forward: usage of such functions in a way that breaks a
> requirement of this series (e.g., failing to specify the template
> table/path parameter(s), or not having constant initializers) hits a
> build error, as the requirements are actually from the compiler.
> 
> >> 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.
> 
> Ok, cool. I can work on a different design.
> 
> Please just let me know whether you are OK with the remaining (above),
> and I'll be happy to tackle this.

What is "the remaining"?

Best

On 2026-09-09 11:07, Joel Granados wrote:
> On Fri, Sep 04, 2026 at 02:45:23PM -0300, Mauricio Faria de Oliveira wrote:
>> On 2026-09-04 10:41, Joel Granados wrote:
>> > On Thu, Aug 20, 2026 at 06:22:13PM -0300, Mauricio Faria de Oliveira wrote:
>> >> On 2026-08-20 09:51, Joel Granados wrote:
>> >> > On Wed, Aug 19, 2026 at 03:16:13PM -0300, Mauricio Faria de Oliveira wrote:
>> >> >> This series adds 'sysctl:' aliases to modules that register sysctl tables; e.g.:
> <... snip ...>
>> > use the correct call moving forward?
>> 
>> This scheme currently covers all modules, AFAIK, as it is wrapped in the
>> functions that register sysctl tables.
>> 
>> On moving forward: usage of such functions in a way that breaks a
>> requirement of this series (e.g., failing to specify the template
>> table/path parameter(s), or not having constant initializers) hits a
>> build error, as the requirements are actually from the compiler.
>> 
>> >> 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.
>> 
>> Ok, cool. I can work on a different design.
>> 
>> Please just let me know whether you are OK with the remaining (above),
>> and I'll be happy to tackle this.
> 
> What is "the remaining"?

I meant the rest of the email, addressing the points/questions you
raised.

cheers,

> 
> Best

-- 
Mauricio

On Wed, Sep 09, 2026 at 02:29:30PM -0300, Mauricio Faria de Oliveira wrote:
> On 2026-09-09 11:07, Joel Granados wrote:
> > On Fri, Sep 04, 2026 at 02:45:23PM -0300, Mauricio Faria de Oliveira wrote:
> >> On 2026-09-04 10:41, Joel Granados wrote:
> >> > On Thu, Aug 20, 2026 at 06:22:13PM -0300, Mauricio Faria de Oliveira wrote:
> >> >> On 2026-08-20 09:51, Joel Granados wrote:
> >> >> > On Wed, Aug 19, 2026 at 03:16:13PM -0300, Mauricio Faria de Oliveira wrote:
> >> >> >> This series adds 'sysctl:' aliases to modules that register sysctl tables; e.g.:
> > <... snip ...>
> >> > use the correct call moving forward?
> >> 
> >> This scheme currently covers all modules, AFAIK, as it is wrapped in the
> >> functions that register sysctl tables.
> >> 
> >> On moving forward: usage of such functions in a way that breaks a
> >> requirement of this series (e.g., failing to specify the template
> >> table/path parameter(s), or not having constant initializers) hits a
> >> build error, as the requirements are actually from the compiler.
> >> 
> >> >> 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.
> >> 
> >> Ok, cool. I can work on a different design.
> >> 
> >> Please just let me know whether you are OK with the remaining (above),
> >> and I'll be happy to tackle this.
> > 
> > What is "the remaining"?
> 
> I meant the rest of the email, addressing the points/questions you
> raised.

* The dependency on a sysctl path to load a module still is
  backwards to me. It should be: I need feature A, I load modules
  M{1,2,3} for A and I set sysctl S{1,2,3...}. Not sure why sysctl tools
  do it the other way around.

* The fact that the invariance is in the sysctl path and not the module
  identifier maybe points to a deeper issue. 

* I still believe that this is better placed outside the sysctl
  subsys as it does not cater solely to module loading.

Best

On 2026-09-10 04:29, Joel Granados wrote:
> On Wed, Sep 09, 2026 at 02:29:30PM -0300, Mauricio Faria de Oliveira wrote:
>> On 2026-09-09 11:07, Joel Granados wrote:
>> > On Fri, Sep 04, 2026 at 02:45:23PM -0300, Mauricio Faria de Oliveira wrote:
>> >> On 2026-09-04 10:41, Joel Granados wrote:
>> >> > On Thu, Aug 20, 2026 at 06:22:13PM -0300, Mauricio Faria de Oliveira wrote:
>> >> >> On 2026-08-20 09:51, Joel Granados wrote:
>> >> >> > On Wed, Aug 19, 2026 at 03:16:13PM -0300, Mauricio Faria de Oliveira wrote:
>> >> >> >> This series adds 'sysctl:' aliases to modules that register sysctl tables; e.g.:
>> > <... snip ...>
>> >> > use the correct call moving forward?
>> >>
>> >> This scheme currently covers all modules, AFAIK, as it is wrapped in the
>> >> functions that register sysctl tables.
>> >>
>> >> On moving forward: usage of such functions in a way that breaks a
>> >> requirement of this series (e.g., failing to specify the template
>> >> table/path parameter(s), or not having constant initializers) hits a
>> >> build error, as the requirements are actually from the compiler.
>> >>
>> >> >> 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.
>> >>
>> >> Ok, cool. I can work on a different design.
>> >>
>> >> Please just let me know whether you are OK with the remaining (above),
>> >> and I'll be happy to tackle this.
>> >
>> > What is "the remaining"?
>> 
>> I meant the rest of the email, addressing the points/questions you
>> raised.
> 
> * The dependency on a sysctl path to load a module still is
>   backwards to me. It should be: I need feature A, I load modules
>   M{1,2,3} for A and I set sysctl S{1,2,3...}. Not sure why sysctl tools
>   do it the other way around.

Right, but note:
- the feature may, or may not, be built as a module (unknown to sysctl
tool).
- there is no simple way to identify which module provides a sysctl,
today.

Let's compare this with device-id module aliases: userspace doesn't know
whether a driver is built-in or a module, but it can load the module, if
any, based on the device-id, not the module name.

> * The fact that the invariance is in the sysctl path and not the module
>   identifier maybe points to a deeper issue.

It does seem that the invariance in the sysctl path is correct, as that
doesn't change with the variable of whether the code is built-in or a
module.

A similar comparison with device-id module aliases applies, IIUIC.

> * I still believe that this is better placed outside the sysctl
>   subsys as it does not cater solely to module loading.

Understood; your point about a module-specific argument in sysctl
register functions precisely confirmed that this approach is misplaced.

I'll try a different design, more similar to MODULE_DEVICE_TABLE().
Maybe the only requirement from sysctl is for struct
ctl_table.procname's offset to be zero (for file2alias). And apparently
something with the path string in a table declaration macro. We'll see.

Thanks again for reviewing and providing constructive feedback. That's
very appreciated.

> 
> Best

-- 
Mauricio