Re: [LTP] cve/icmp_rate_limit01: Lower icmp_msgs_per_sec for debug kernel reliability

[linuxtestproject.agent@gmail.com]

Hi Brian,

On Wed, 22 Jul 2026, Brian Grech wrote:
> cve/icmp_rate_limit01: Lower icmp_msgs_per_sec for debug kernel reliability

> On debug kernels with CONFIG_PROVE_LOCKING or PREEMPT_RT, each socket
> operation (bind, sendto) takes ~3-4ms instead of <0.5ms on a normal
> kernel. At the default icmp_msgs_per_sec=1000, the token bucket refills
> ~371 tokens during the 371ms it takes to send 100 packets, so rate
> limiting never engages and all batches return identical error counts,
> causing a false TFAIL.

Checking net/ipv4/icmp.c (net_init_ipv4_early() /
icmp_sk_init()), the kernel default for icmp_msgs_per_sec has been
10000, not 1000, since the sysctl was introduced -- 1000 is actually
the default of the unrelated icmp_ratelimit sysctl (a millisecond
delay, not a rate). Is the "1000" default and the derived "~371
tokens in 371ms" figure meant to reference icmp_msgs_per_sec, or was
this confused with icmp_ratelimit? The direction of the fix still
holds either way, but the justification as written doesn't match the
real default.

> Lower icmp_msgs_per_sec to 10 in both the global save_restore and the
> child network namespace. At 10/sec the bucket cannot meaningfully refill
> during the send loop regardless of kernel speed, while the 2s inter-batch
> sleep still allows full credit recovery (10 * 2 = 20 = burst).

Two things don't line up here:

icmp_msgs_burst is set to 50 by this same test
(`{PATH_IPV4_ICMP_MSGS_BURST, "50", TST_SR_TBROK}`), not 20, so "20 =
burst" doesn't hold regardless of rate.

Also, icmp_global_allow() caps the elapsed interval used for the
refill calculation: `delta = min_t(u32, now - oldstamp, HZ);`, so at
most one second's worth of credit (10 tokens at this rate) is ever
added on a single check, no matter how long the real elapsed time
was. After the 2s sleep, the achievable refill is capped at 10, not
20.

Neither burst (50) nor the achievable refill (10) match the "10 * 2
= 20 = burst" statement. This likely doesn't break the practical
effect of the fix -- less refill only makes rate limiting engage
more reliably -- but is the reasoning here intentional, or should the
comment be corrected to reflect the actual kernel behavior?

Verdict - Needs revision

---
Note:

The agent can sometimes produce false positives although often its
findings are genuine. If you find issues with the review, please
comment this email or ignore the suggestions.

Regards,
LTP AI Reviewer

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp