From: Simon Horman <horms@kernel.org>
To: Nikolay Aleksandrov <razor@blackwall.org>
Cc: Xiang Mei <xmei5@asu.edu>,
netdev@vger.kernel.org, bridge@lists.linux.dev,
idosch@nvidia.com, davem@davemloft.net, edumazet@google.com,
pabeni@redhat.com, bestswngs@gmail.com
Subject: Re: [PATCH net] bridge: mrp: reject zero test interval to avoid OOM panic
Date: Fri, 3 Apr 2026 09:34:15 +0100 [thread overview]
Message-ID: <20260403083415.GC11973@horms.kernel.org> (raw)
In-Reply-To: <f7fea291-bde9-4f95-8a59-1b209407ee27@blackwall.org>
On Fri, Mar 27, 2026 at 01:46:39PM +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.
Right, I was getting to think that too.
...
next prev parent reply other threads:[~2026-04-03 8:34 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-26 3:24 [PATCH net] bridge: mrp: reject zero test interval to avoid OOM panic Xiang Mei
2026-03-26 3:42 ` Xiang Mei
2026-03-27 11:34 ` Simon Horman
2026-03-27 11:46 ` Nikolay Aleksandrov
2026-03-28 0:19 ` Jakub Kicinski
2026-03-28 6:18 ` Nikolay Aleksandrov
2026-03-28 6:23 ` Xiang Mei
2026-03-28 6:19 ` Xiang Mei
2026-03-28 6:38 ` Nikolay Aleksandrov
2026-04-03 8:34 ` Simon Horman [this message]
2026-04-04 0:31 ` Xiang Mei
2026-03-28 6:06 ` Xiang Mei
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260403083415.GC11973@horms.kernel.org \
--to=horms@kernel.org \
--cc=bestswngs@gmail.com \
--cc=bridge@lists.linux.dev \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=idosch@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=razor@blackwall.org \
--cc=xmei5@asu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.