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

[Hangbin Liu]

Hi Jiayuan,
On Mon, Nov 02, 2026 at 10:23:30AM +0800, Jiayuan Chen wrote:
> 
> On 11/2/26 9:55 AM, Hangbin Liu wrote:
> > Hi Jiayuan,
> > On Sun, Nov 01, 2026 at 02:12:03PM +0800, Jiayuan Chen wrote:
> >> net.core.message_cost and net.core.message_burst feed the interval and
> >> burst of net_ratelimit_state, but neither rejects negative values:
> >> message_burst uses plain proc_dointvec, and message_cost uses
> >> proc_dointvec_jiffies, which happily stores -1 second as -HZ jiffies.
> >>
> >> Since commit a940d145cc38 ("ratelimit: Warn if ->interval or ->burst are
> >> negative"), ___ratelimit() splats on such values, so the next
> >> net_ratelimit() caller warns, e.g. a martian source log:
> >>
> >>   Negative interval (-250) or burst (10): Uninitialized ratelimit_state structure?
> >>   WARNING: lib/ratelimit.c:43 at ___ratelimit+0x56e/0x960, CPU#1: ping/3218
> >>   RIP: 0010:___ratelimit+0x578/0x960
> >>   Call Trace:
> >>    <IRQ>
> >>    net_ratelimit+0x1c/0x30
> >>    ip_handle_martian_source+0x1bb/0x340
> >>    ip_route_input_slow+0x1057/0x3650
> >>    ip_route_input_noref+0x104/0x260
> >>    arp_process+0x109b/0x2510
> >>    arp_rcv+0x381/0x460
> >>    __netif_receive_skb_one_core+0x173/0x1c0
> >>    __netif_receive_skb+0x21/0x150
> >>    process_backlog+0x37e/0x1200
> >>    __napi_poll.constprop.0+0xa5/0x5e0
> >>    net_rx_action+0x4c0/0xf70
> >>    handle_softirqs+0x204/0x9b0
> >>    __do_softirq+0x10/0x18
> >>    do_softirq.part.0+0x49/0xd0
> >>    </IRQ>
> >>
> >> Negative values never meant anything here: 0 already expresses both
> >> "no limit" (interval) and "suppress everything" (burst).
> > Will this limit breaks the UAPI on old kernels that supports negative values?
> 
> All commits in this series restrict config values, and every one of them
> changes the old behavior to some degree; the question is whether the

The other patches fix shift-out-of-bounds or incorrect behaviors.
> 
> change is reasonable.
> 
> 
> For this one, negative values never did anything that 0 doesn't, and
> since a940d145cc38 setting one already triggers the WARN_ONCE().

While this one doesn't improve anything other than the WARN_ONCE.
The previous kernel works good with negative values.

> 
> 
> > As the comment in ___ratelimit() says:
> >
> >         /*
> >          * Zero interval says never limit, otherwise, non-positive burst
> >          * says always limit.
> >          */
> >
> > If all others agree to set the limit in this patch. I think the comment
> 
> 
> The comment and the WARN_ONCE() are about ratelimit_state in general, not
> net only. There are still other ways to set a negative value,
> printk_ratelimit for example, so updating them is not this net patch's
> job.

printk_ratelimit is not recommend anymore.

/*
 * Please don't use printk_ratelimit(), because it shares ratelimiting state
 * with all other unrelated printk_ratelimit() callsites.  Instead use
 * printk_ratelimited() or plain old __ratelimit().
 */
extern int __printk_ratelimit(const char *func);
#define printk_ratelimit() __printk_ratelimit(__func__)

> 
> > and the WARN_ONCE() , and the admin-guide/sysctl/net.rst all need to be updated.
> 
> 
> 
> net.rst never documented a range or even the unit for these two, which is
> why I didn't touch it. No strong preference though.

I think a doc need to be updated if you set a range limit.

Thanks
Hangbin