Re: [PATCH net 5/5] net: restrict message_cost and message_burst to non-negative values

[Jiayuan Chen <jiayuan.chen@linux.dev>]

On 10/23/26 8:55 PM, Fernando Fernandez Mancera wrote:
[...]
>>>   #ifdef CONFIG_BPF_JIT
>>>   static int proc_dointvec_minmax_bpf_enable(const struct ctl_table 
>>> *table, int write,
>>>                          void *buffer, size_t *lenp,
>>> @@ -544,14 +560,15 @@ static struct ctl_table net_core_table[] = {
>>>           .data        = &net_ratelimit_state.interval,
>>>           .maxlen        = sizeof(int),
>>>           .mode        = 0644,
>>> -        .proc_handler    = proc_dointvec_jiffies,
>>> +        .proc_handler    = proc_do_message_cost,
>>>       },
>>>       {
>>>           .procname    = "message_burst",
>>>           .data        = &net_ratelimit_state.burst,
>>>           .maxlen        = sizeof(int),
>>>           .mode        = 0644,
>>> -        .proc_handler    = proc_dointvec,
>>> +        .proc_handler    = proc_dointvec_minmax,
>>> +        .extra1        = SYSCTL_ZERO,
>>>       },
>>>   #ifdef CONFIG_RPS
>>>       {
>>> -- 
>>> 2.43.0
>>>
>>
>> I would prefer something like this [1] (not tested and not compiled).
>> This is more in line with the patterns inside the jiffies.c file. I put
>> SYSCTL_ZERO there, but I have a doubt if you actually need SYSCTL_ONE.
>>

Thanks Joel and Fernando, good to hear this.

I actually had almost the same proc_dointvec_jiffies_minmax() locally at 
first,

but then thought "this touches sysctl core, better not" and went with 
the local handler
instead.

Glad I was wrong about that :)


>> If the interval variable can be zero, then leave it as SYSCTL_ZERO, but
>> if it cant be zero and can be one the use SYSCTL_ONE
>>
>
> FWIW, I also like this solution and indeed we can convert other users 
> in the future.
>
> About SYSCTL_ZERO, I believe it is the right choice. AFAIU, it just 
> disables limiting.
>

Agreed on SYSCTL_ZERO. interval == 0 is the documented "never limit"
case in ___ratelimit(), so it has to stay allowed.


> Thanks,
> Fernando.
>