Re: [RFC PATCH v4 0/2] sysctl: refactor ctl_table initialization
From: Wen Yang
Date: Wed Mar 25 2026 - 14:31:45 EST
On 3/19/26 22:32, Joel Granados wrote:
On Thu, Mar 19, 2026 at 03:12:04PM +0100, Joel Granados wrote:
Hey Wen
Comments inline
On Wed, Mar 18, 2026 at 01:36:13AM +0800, wen.yang@xxxxxxxxx wrote:
From: Wen Yang <wen.yang@xxxxxxxxx>LGTM: Clear motivation.
The main motivation for this series is to avoid treewide patch series.
Historically, changes to how struct ctl_table entries are initialized
(e.g. removing the child field, const-qualifying ctl_table) required
touching hundreds of files across all subsystems. Such series require
the attention of many maintainers, sometimes need to be pulled into
mainline in a special way, and create lots of unnecessary churn.
I think this paragraph is redundant; I would remove it. And just add
By introducing a family of CTLTBL_ENTRY_XXX() helper macros in
<linux/sysctl.h>, any future structural changes to struct ctl_table can
be handled in one place — the macro definition — without requiring a
treewide sweep of all callers. Individual subsystem maintainers can also
migrate their sysctl tables to use the macros at their own pace.
"This will all go away with the CTLTBL_ENTRY_XXX helper macros" as the
last sentence in the first paragraph.
Migration strategy
==================
You touched on this when you mentioned that the maintainers can migrate
to the new macro at their pace. In my experience this will never happen
if you give the responsibility to the subsys maintainers (They are busy
with other matters). I think the more successful strategy is to lead the
conversion from sysctl.
Based on discussion and suggestions from:
[1] https://sysctl-dev-rtd.readthedocs.io/en/latest/notes/ctltable_entry_macro.html#table-entry-macro
[2] https://lore.kernel.org/all/psot4oeauxi3yyj2w4ajm3tfgtcsvao4rhv5sgd5s6ymmjgojk@p3vrj3qluban/
This series:
1. Introduces the CTLTBL_ENTRY_XXX() macros in include/linux/sysctl.h,
allowing callers to initialize struct ctl_table entries indirectly
via the macro instead of assigning each field directly. The macros
use _Generic() for automatic type detection and proc_handler
selection, provide smart defaults (auto address-of, auto maxlen via
sizeof), and include compile-time validation of name, mode, and
handler.
2. Converts kernel/sysctl-test.c to use the new macros as a
demonstration, replacing direct struct ctl_table field assignments
with CTLTBL_ENTRY_XXX() calls. Four new tests are added to cover the
previously untested variants (CTLTBL_ENTRY_V, VN, VNM, VNMH), bringing
the total to 16 passing tests.
---
Changes in v4:
- Fix Wpointer-type-mismatch warnings detected by lkp:
https://lore.kernel.org/oe-kbuild-all/202603050724.SZxrEyyu-lkp@xxxxxxxxx/
Changes in v3:
- replace the unique macro with "capital letter approach"
- reduce the name further
https://lore.kernel.org/all/rn4rsazh7kxf5byq65vw2phyqgzvwm3scczu3l5h2r4aqit2r6@znlpb24z2zuo/
Changes in v2:
- add lvalue check, handler type check, etc.
https://lore.kernel.org/all/xptwb3uwbzposd4xf7khj52ifv4tchcjdgllhv7aabi6d7wgef@2msurl564v53/
Wen Yang (2):
sysctl: introduce CTLTBL_ENTRY_XXX() helper macros
sysctl: convert kernel/sysctl-test.c to use CTLTBL_ENTRY_XXX()
include/linux/sysctl.h | 294 +++++++++++++++++++++++++++++++++++++++++
kernel/sysctl-test.c | 240 +++++++++++++++++++--------------
kernel/sysctl.c | 2 +
3 files changed, 437 insertions(+), 99 deletions(-)
--
2.25.1
Best
--
Joel Granados
For your next version I would keep it as an RFC but include a more
targeted audience. Add the Kees Cook <kees@xxxxxxxxxx> to the "To:" and
add linux-fsdevel@xxxxxxxxxxxxxxx to the "Cc". This will hopefully get
some feedback and we can take it from there. I can nudge the new RFC if
it does not get any initial traction.
Thank you for your kind instruction.
We will revise it based on your suggestions and send v5 soon.
--
Best wishes,
Wen