Re: [RFC PATCH v4 0/2] sysctl: refactor ctl_table initialization

[Joel Granados]

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>
> > 
> > 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.
> LGTM: Clear motivation.
> 
> > 
> > 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.
> I think this paragraph is redundant; I would remove it. And just add
> "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

I think that after you address the last round of feedback, the series
will be ready for a broader audience.

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.

Thx again for taking this

Best

-- 

Joel Granados

Attachment: signature.asc
Description: PGP signature