Re: [PATCH v3 0/5] sysctl: add typed field descriptors

[Alexey Gladkov]

On Thu, Oct 22, 2026 at 04:04:39PM +0200, Joel Granados wrote:
> On Mon, Oct 12, 2026 at 03:43:03PM +0200, Alexey Gladkov wrote:
> > On Sat, Sep 26, 2026 at 06:22:07PM +0200, Alexey Gladkov wrote:
> > > Hi,
> > > 
> > > Some sysctl users copy an otherwise static ctl_table for each namespace or
> > > device, then replace data and limit pointers before registration. Besides
> > > the per-instance allocation, these fixups often depend on table indices:
> > > reordering an entry without updating the fixup can silently bind it to the
> > > wrong data or limits.
> > > 
> > > This series lets such users describe a table once with static, read-only
> > > sysctl_field entries. Each field names a data type and an offset into an
> > > object selected by a sysctl_context at registration time. The offset
> > > helpers check the member type at build time. Limits and custom handlers
> > > remain optional properties of a field; the field type does not encode a
> > > choice of handler or whether limits are present. A subsystem that needs
> > > more than a namespace can embed sysctl_context in its own registration
> > > context.
> > > 
> > > The sysctl core keeps the context with the table header and materializes
> > > a ctl_table entry when an existing handler, permission check or BPF hook
> > > needs one. Legacy ctl_table registrations retain their own path, and
> > > subsystems can convert tables independently. The IPC, mqueue and ucount
> > > conversions here remove table copies without changing their backing data.
> > > 
> > > Changes since v2:
> > > 
> > > - Drop sysctl_uint_vals, as requested by Joel. Existing limit constants
> > >   suffice for these conversions.
> > > - Drop the *_MINMAX field types. A field's type now describes its data,
> > >   while optional min/max pointers supply bounds to the selected handler.
> > > - Keep __register_sysctl_table() and __register_sysctl_fields() as separate
> > >   registration paths, sharing only allocation and tree insertion helpers.
> > > - Address the sashiko findings: avoid calling mode_fn under sysctl_lock,
> > >   validate the effective maxlen against the context object, and reject
> > >   NO_DATA fields paired with standard handlers that require data.
> > > 
> > > This is the first part of the conversion. Network sysctls and other
> > > subsystem-specific users will follow in separate series for review by
> > > their maintainers.
> > > 
> > > 
> > > Alexey Gladkov (5):
> > >   proc: sysctl: address table entries by index
> > >   sysctl: add typed field descriptors
> > >   sysctl: ipc: use typed fields for IPC namespace sysctls
> > >   sysctl: mq: use typed fields for IPC namespace sysctls
> > >   sysctl: use typed fields for ucount limits
> > 
> > Gentle reminder about the patchset.
> Thx for persisting and sorry for the late reply.
> 
> The more I look at this, the more I am convinced that the first problem
> that we should address is having a .data, .extra1 and .extra2 as void
> pointers. Once that is out of the way, then we can focus on getting rid
> of the kmemdup of the ctl_tables.
> 
> Motivation
> ==========
> 
> Here are the motivational points for this series:
> 1. Remove the per-instance allocation thereby reducing the memory
>    footprint
>   * This one is relevant for instances with lots of NSs.
> 
> 2. Remove the possibility of mistakenly associating one variable with a
>    different sysctl name (because of un-synced changes)
>   * This one is the least important for me. Keeping it synced is a
>     little scary but something that I would be willing to live with.
> 
> 3. Type checking .data, .extra1 and .extra2. "unambiguous pointer" that
>    answers what it is.
>   * I think if we are serious about type checking, we need to fix the
>     existing (potentially uneeded) void pointers (.data, extra{1,2}).
>     Which is not an easy as there are callers that (mis)use these in
>     different ways. This has been discussed before (in [1,2,3] among
>     others)
> 
> 4. Don't bleed caller structs/types/logic into sysctl.
>   * This one is mine and is the reason I really don't want it done in
>     the manner that you propose. IMO, having network (or other callers
>     logic) inside sysctl makes no sense.
> 
> I'll come back to these series after having yet another look at the void
> pointers in ctl_table.

In that case, I'll step back with my patches for now.

Thanks for review.

> Best
> 
> [1] https://lore.kernel.org/all/87zgpte9o4.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> [2] https://lore.kernel.org/all/875xyczpzm.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> [3] https://lore.kernel.org/all/cover.1739115369.git.wen.yang@xxxxxxxxx
> 
> 



-- 
Rgrds, legion