Re: [RFC PATCH 00/39] sysctl: replace overloaded extra pointers with typed bounds and context
From: Wen Yang
Date: Thu Nov 12 2026 - 11:51:59 EST
On 11/11/26 19:55, Joel Granados wrote:
On Wed, Nov 11, 2026 at 01:45:15AM +0800, Wen Yang wrote:
<--- snip --->
On 11/9/26 18:07, Joel Granados wrote:
On Sat, Nov 07, 2026 at 05:05:07PM +0000, David Laight wrote:
On Sat, 7 Nov 2026 16:27:39 +0100
Joel Granados <joel.granados@xxxxxxxxxx> wrote:
On Mon, Nov 02, 2026 at 11:40:40PM +0800, Wen Yang wrote:
<--- snip --->
On 10/29/26 18:58, David Laight wrote:
On Thu, 29 Oct 2026 00:34:39 +0800
wen.yang@xxxxxxxxx wrote:
From: Wen Yang <wen.yang@xxxxxxxxx>
struct ctl_table describes an entry with data, maxlen and, until this
series, two untyped misc pointers in extra1 and extra2. Those two pointers
have accumulated at least seven unrelated jobs: a fixed bound, a bound read
through a pointer on every call, an object or namespace pointer, a small
integer cookie encoded into the pointer, a lock signal, NULL standing for
"no bound", and a value the core itself casts to unsigned int while
validating a u8 range. Nothing in the entry says which job applies, so
readers infer it from the handler, and the core gets it wrong where it
treats extra1 as an unsigned int.
for (i = 0; i < head->ctl_table_size; i++) {
entry = sysctl_entry_at(head, i);
node = &head->node[i];
...
}
Insertion/deletion would take the node directly. Readdir would retain
its RB-tree node cursor, recovering each entry through that node's header:
entry = sysctl_entry_at(node->header, node - node->header->node);
No entry - head->ctl_table, caller slot constants or per-slot wrappers.
RB-tree order remains unchanged. Old APIs and generated directory/link
tables use sizeof(struct ctl_table).
The two mechanisms have existing precedents:
/* include/linux/bsearch.h: explicit element size */
pivot = base + (num >> 1) * size;
result = cmp(key, pivot);
/* include/linux/hwmon-sysfs.h: extended descriptor */
struct sensor_device_attribute {
struct device_attribute dev_attr;
int index;
};
/* drivers/hwmon/adcxx.c: ordinary device_attribute callback */
const struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
hwmon registers &ad_input[i].dev_attr via device_create_file(); the core
passes that same base descriptor to the callback. These are precedents
for explicit-size traversal and embedded callback context separately,
not an existing strided sysctl registration API.
I agree that my fixed-slot solution adds maintenance overhead. Would
it make sense to explore this in three small steps?
1. Entry-access helpers, unchanged packed layout.
2. Header stride and compatible registration wrappers.
3. nf_log conversion and code/memory comparison.
I would appreciate your thoughts on whether this is worth pursuing.
Hey Wen
Without a series, it is hard to see how everything fits. Maybe you can
send out an RFC with just the changes to the sysctl core and one or two
examples of how it would be used in the more involved users.
The rest of the users can be "vibe coded" (so it compiles) and put into
one big commit that we will ignore for the first RFC. Just so we get a
clear idea of what you mean.
Tell me what you think
Thanks.
That makes total sense. I will prepare a focused RFC series based on
the next-20261111 structured as follows:
Patch 1: sysctl: add numeric bounds and core stride infrastructure
(ctl_table_stride in header, sysctl_entry_at(), register_*_stride())
Patch 2: sysctl: cover numeric bounds and table containers in KUnit
Patch 3: netfilter: embed logger sysctl context using stride
(demonstrates the use of container_of(), and also eliminating some wrapper functions)
Patch 4: net/ipv4: embed device sysctl context using stride
(demonstrates the use of container_of(), and also eliminating some wrapper functions)
Patch 5: scripts/coccinelle: add script to detect and convert sysctl bounds
(provides automatic conversion and proves that no extra1/extra2 fields remain)
The ctl_table_stride and type are packed as u16 in struct ctl_table_header, yielding zero size increas.
I will send out this v2 RFC shortly for review.
--
Best wishes,
Wen