All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Nikolay Aleksandrov <razor@blackwall.org>
Cc: Simon Horman <horms@kernel.org>, 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, 27 Mar 2026 17:19:17 -0700	[thread overview]
Message-ID: <20260327171917.7575d715@kernel.org> (raw)
In-Reply-To: <f7fea291-bde9-4f95-8a59-1b209407ee27@blackwall.org>

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..

  reply	other threads:[~2026-03-28  0:19 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 [this message]
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
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=20260327171917.7575d715@kernel.org \
    --to=kuba@kernel.org \
    --cc=bestswngs@gmail.com \
    --cc=bridge@lists.linux.dev \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --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.