All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stanislav Fomichev <stfomichev@gmail.com>
To: Jay Vosburgh <jv@jvosburgh.net>
Cc: Jakub Kicinski <kuba@kernel.org>,
	netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com,
	pabeni@redhat.com, jiri@resnulli.us, andrew+netdev@lunn.ch,
	sdf@fomichev.me, linux-kernel@vger.kernel.org,
	syzbot+53485086a41dbb43270a@syzkaller.appspotmail.com
Subject: Re: [PATCH net] team: grab team lock during team_change_rx_flags
Date: Thu, 15 May 2025 11:26:21 -0700	[thread overview]
Message-ID: <aCYxzeCgsNI3AKSH@mini-arch> (raw)
In-Reply-To: <47315.1747327157@vermin>

On 05/15, Jay Vosburgh wrote:
> Stanislav Fomichev <stfomichev@gmail.com> wrote:
> 
> >On 05/15, Stanislav Fomichev wrote:
> >> On 05/15, Jakub Kicinski wrote:
> >> > On Wed, 14 May 2025 15:03:19 -0700 Stanislav Fomichev wrote:
> >> > > --- a/drivers/net/team/team_core.c
> >> > > +++ b/drivers/net/team/team_core.c
> >> > > @@ -1778,8 +1778,8 @@ static void team_change_rx_flags(struct net_device *dev, int change)
> >> > >  	struct team_port *port;
> >> > >  	int inc;
> >> > >  
> >> > > -	rcu_read_lock();
> >> > > -	list_for_each_entry_rcu(port, &team->port_list, list) {
> >> > > +	mutex_lock(&team->lock);
> >> > > +	list_for_each_entry(port, &team->port_list, list) {
> >> > 
> >> > I'm not sure if change_rx_flags is allowed to sleep.
> >> > Could you try to test it on a bond with a child without IFF_UNICAST_FLT,
> >> > add an extra unicast address to the bond and remove it?
> >> > That should flip promisc on and off IIUC.
> >> 
> >> I see, looks like you're concerned about addr_list_lock spin lock in
> >> dev_set_rx_mode? (or other callers of __dev_set_rx_mode) Let me try
> >> to reproduce with your example, but seems like it's an issue, yes
> >> and we have a lot of ndo_change_rx_flags callbacks that are sleepable :-(
> >
> >Hmm, both bond and team set IFF_UNICAST_FLT, so it seems adding/removing uc
> >address on the bonding device should not flip promisc. But still will
> >verify for real.
> 
> 	I think Jakub is saying that adding a unicast address to the
> bond would change promisc on the underlying device that's part of the
> bond (a not-IFF_UNICAST_FLT interface), not on the bond itself.  The
> question is whether that change of promisc in turn generates a sleeping
> function warning.
> 
> 	FWIW, I think an easy way to add a unicast MAC to a bond is to
> configure a VLAN above the bond, then change the MAC address of the VLAN
> interface (so it doesn't match the bond's).

This seems to work (using teaming instead of bonding, but should not matter):

  ip link add name dummy1 type dummy
  ip link add name team0 type team
  #ip link set team0 down # hit team_port_add vs team_set_rx_mode
  ip link set dev dummy1 master team0 # promisc enabled here

  ip link set dummy1 up
  ip link set team0 up # or here (if was down previously)

  ip link add link team0 name team0.100 type vlan id 100
  ip link set dev team0.100 address 00:00:00:00:00:02
  ip link set team0.100 up

But mostly because promisc is enabled via team_port_add->dev_uc_sync_multiple
(when team is up when adding a port) or via
do_setlink->netif_change_flags->ndo_set_rx_mode->team_set_rx_mode (when
upping team). The subsequent calls to __dev_set_rx_mode are noops
because the device is already in promisc. IOW, I don't see how we can
reach team_change_rx_flags from here.

  reply	other threads:[~2025-05-15 18:26 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-14 22:03 [PATCH net] team: grab team lock during team_change_rx_flags Stanislav Fomichev
2025-05-15 14:56 ` Jakub Kicinski
2025-05-15 15:40   ` Stanislav Fomichev
2025-05-15 16:21     ` Stanislav Fomichev
2025-05-15 16:39       ` Jay Vosburgh
2025-05-15 18:26         ` Stanislav Fomichev [this message]
2025-05-16 23:00 ` patchwork-bot+netdevbpf

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=aCYxzeCgsNI3AKSH@mini-arch \
    --to=stfomichev@gmail.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=jiri@resnulli.us \
    --cc=jv@jvosburgh.net \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sdf@fomichev.me \
    --cc=syzbot+53485086a41dbb43270a@syzkaller.appspotmail.com \
    /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.