All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stanislav Fomichev <stfomichev@gmail.com>
To: Jiayuan Chen <jiayuan.chen@linux.dev>
Cc: netdev@vger.kernel.org, Jiayuan Chen <jiayuan.chen@shopee.com>,
	syzbot+2b3391f44313b3983e91@syzkaller.appspotmail.com,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Simon Horman <horms@kernel.org>,
	Sabrina Dubroca <sd@queasysnail.net>,
	Stanislav Fomichev <sdf@fomichev.me>,
	Kuniyuki Iwashima <kuniyu@google.com>,
	Samiullah Khawaja <skhawaja@google.com>,
	Ahmed Zaki <ahmed.zaki@intel.com>,
	Alexander Lobakin <aleksander.lobakin@intel.com>,
	Willem de Bruijn <willemb@google.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v1] net: defer __dev_set_promiscuity() to avoid sleeping in atomic context
Date: Tue, 17 Feb 2026 17:10:36 -0800	[thread overview]
Message-ID: <aZURjBHTHRvjP7Ee@mini-arch> (raw)
In-Reply-To: <20260214033859.43857-1-jiayuan.chen@linux.dev>

On 02/14, Jiayuan Chen wrote:
> From: Jiayuan Chen <jiayuan.chen@shopee.com>
> 
> __dev_set_rx_mode() is called with addr_list_lock (spinlock) held from
> many places in dev_addr_lists.c. When a device lacks IFF_UNICAST_FLT,
> __dev_set_rx_mode() calls __dev_set_promiscuity() which propagates
> through dev_change_rx_flags -> ndo_change_rx_flags -> dev_set_promiscuity
> on lower devices. Since commit 78cd408356fe ("net: add missing instance
> lock to dev_set_promiscuity"), dev_set_promiscuity() acquires the netdev
> instance lock (mutex) via netdev_lock_ops(). This leads to a
> "sleeping function called from invalid context" / "Invalid wait context"
> bug when the lower device has request_ops_lock or queue_mgmt_ops set.
> 
> The call chain is:
> 
>   dev_uc_add(bridge0)                      # e.g. from macsec_dev_open
>     netif_addr_lock_bh(bridge0)            # <- spinlock, BH disabled
>     __dev_set_rx_mode(bridge0)             # bridge has no IFF_UNICAST_FLT
>       __dev_set_promiscuity(bridge0)
>         ndo_change_rx_flags(bridge0)
>           br_manage_promisc -> dev_set_promiscuity(team0)
>             ndo_change_rx_flags(team0)
>               team_change_rx_flags -> dev_set_promiscuity(dummy0)
>                 netdev_lock_ops(dummy0)    # <- mutex! dummy has
>                                            #    request_ops_lock=true
> 
> This is not limited to bridge/team/dummy. Any combination of stacking
> devices (bridge, bond, macvlan, vlan, macsec, team, dsa, netvsc) over
> devices with instance lock (dummy, mlx5, bnxt, gve) can trigger this.
> 
> Fix this by deferring __dev_set_promiscuity() to after the spinlock is
> released:
> 
> 1. Change __dev_set_rx_mode() to return a promiscuity increment value
>    (+1, 0, -1) instead of calling __dev_set_promiscuity() directly.
>    The uc_promisc flag is still updated under the lock for correctness.
> 
> 2. Change dev_set_rx_mode() to call __dev_set_promiscuity() after
>    releasing addr_list_lock, based on the returned increment.
> 
> 3. Change all callers in dev_addr_lists.c to release their spinlock
>    first, then call dev_set_rx_mode() which handles both the rx mode
>    update and the deferred promiscuity change safely.

[..]

> Reproducer:
> 
>   ip link add dummy0 type dummy
>   ip link add team0 type team
>   ip link set dummy0 master team0
>   ip link set team0 up
>   ip link add bridge0 type bridge vlan_filtering 1
>   ip link set bridge0 up
>   ip link set team0 master bridge0
>   ip link add macsec0 link bridge0 type macsec
>   ip link set macsec0 up   # triggers the bug

Can you add it as a selftest under selftests/drivers/net/team/?

  reply	other threads:[~2026-02-18  1:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-14  3:38 [PATCH net v1] net: defer __dev_set_promiscuity() to avoid sleeping in atomic context Jiayuan Chen
2026-02-18  1:10 ` Stanislav Fomichev [this message]
2026-02-19  1:40   ` Jakub Kicinski
2026-02-19 18:59     ` Stanislav Fomichev
2026-02-19 20:12       ` Jakub Kicinski
2026-02-20  0:30         ` Stanislav Fomichev
2026-02-20  1:10           ` Jakub Kicinski
2026-02-20  5:21         ` I Viswanath
2026-02-21  1:15           ` Stanislav Fomichev
2026-02-20 20:45             ` I Viswanath
2026-02-21  6:23               ` Stanislav Fomichev
2026-02-21  1:22             ` Jakub Kicinski
2026-02-21  6:22               ` Stanislav Fomichev

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=aZURjBHTHRvjP7Ee@mini-arch \
    --to=stfomichev@gmail.com \
    --cc=ahmed.zaki@intel.com \
    --cc=aleksander.lobakin@intel.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=jiayuan.chen@linux.dev \
    --cc=jiayuan.chen@shopee.com \
    --cc=kuba@kernel.org \
    --cc=kuniyu@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sd@queasysnail.net \
    --cc=sdf@fomichev.me \
    --cc=skhawaja@google.com \
    --cc=syzbot+2b3391f44313b3983e91@syzkaller.appspotmail.com \
    --cc=willemb@google.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.