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

[Wen Yang <wen.yang@linux.dev>]

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@linux.dev wrote:
>>> From: Wen Yang <wen.yang@linux.dev>
>>>
>>> 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@intel.com/
>>>
>>> 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@kernel.org> to the "To:" and
> add linux-fsdevel@vger.kernel.org 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