Thanks for your review. interval=1 works fine even in the case when we use netem to delay the consumer. I'll correct the fix tag and send a v2.
On Fri, Mar 27, 2026 at 5:19 PM Jakub Kicinski <[email protected]> wrote: > > On Fri, 27 Mar 2026 13:46:39 +0200 Nikolay Aleksandrov wrote: > > On 27/03/2026 13:34, Simon Horman wrote: > > > On Wed, Mar 25, 2026 at 08:24:38PM -0700, Xiang Mei wrote: > > >> br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied > > >> interval value from netlink without validation. When interval is 0, > > >> usecs_to_jiffies(0) yields 0, causing the delayed work > > >> (br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule > > >> itself with zero delay. This creates a tight loop on system_percpu_wq > > >> that allocates and transmits MRP test frames at maximum rate, exhausting > > >> all system memory and causing a kernel panic via OOM deadlock. > > > > > > I would suspect the primary outcome of this problem is high CPU > > > consumption > > > rather than memory exhaustion. Is there a reason to expect that > > > the transmitted fames can't be consumed as fast as they are created? > > > > +1 > > More so with CAP_NET_ADMIN you can cause all sorts of OOM and high-cpu usage > > conditions. This is a configuration error and OOM doesn't lead to panic > > unless > > instructed to. I don't think this is worth changing at all. > > Then again if there's no practical use for 0 we should consider > the risk of getting this sort of submission over and over again? > Dunno..
