From: "Linus Lüssing" <linus.luessing@c0d3.blue>
To: Nikolay Aleksandrov <razor@blackwall.org>
Cc: Jakub Kicinski <kuba@kernel.org>,
bridge@lists.linux.dev, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Ido Schimmel <idosch@nvidia.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
Simon Horman <horms@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Eric Dumazet <edumazet@google.com>,
"David S . Miller" <davem@davemloft.net>,
Kuniyuki Iwashima <kuniyu@google.com>,
Stanislav Fomichev <sdf@fomichev.me>,
Xiao Liang <shaw.leon@gmail.com>
Subject: Re: [PATCH 0/9] net: bridge: reduce multicast checks in fast path
Date: Wed, 3 Sep 2025 01:00:14 +0200 [thread overview]
Message-ID: <aLd2_um-oWhS23Md@sellars> (raw)
In-Reply-To: <aLdQhJoViBzxcWYE@sellars>
On Tue, Sep 02, 2025 at 10:16:04PM +0200, Linus Lüssing wrote:
> On the other hand, moving the spinlock out of / around
> __br_multicast_stop() would lead to a sleeping-while-atomic bug
> when calling timer_delete_sync() in there. And if I were to change
> these to a timer_delete() I guess there is no way to do the sync
> part after unlocking? There is no equivalent to something like the
> flush_workqueue() / drain_workqueue() for workqueues, but for
> simple timers instead, right?
I'm wondering if it would be sufficient to use timer_del() on
.ndo_stop->br_dev_stop()->br_multicast_stop().
And use timer_del_sync() only on
.ndo_uninit->br_dev_uninit()-> br_multicast_dev_del()->
br_multicast_ctx_deinit() and
br_vlan_put_master()->br_multicast_ctx_deinit().
So basically only sync / wait for timer callbacks to finish if
their context is about to be free'd, on bridge or VLAN destruction?
next prev parent reply other threads:[~2025-09-02 23:00 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-29 8:53 [PATCH 0/9] net: bridge: reduce multicast checks in fast path Linus Lüssing
2025-08-29 8:53 ` [PATCH 1/9] net: bridge: mcast: track active state, IGMP/MLD querier appearance Linus Lüssing
2025-08-29 8:53 ` [PATCH 2/9] net: bridge: mcast: track active state, foreign IGMP/MLD querier disappearance Linus Lüssing
2025-08-29 8:53 ` [PATCH 3/9] net: bridge: mcast: track active state, IPv6 address availability Linus Lüssing
2025-08-29 8:53 ` [PATCH 4/9] net: bridge: mcast: track active state, own MLD querier disappearance Linus Lüssing
2025-08-29 8:53 ` [PATCH 5/9] net: bridge: mcast: export ip{4,6}_active state to netlink Linus Lüssing
2025-08-29 8:53 ` [PATCH 6/9] net: bridge: mcast: use combined active state in fast/data path Linus Lüssing
2025-08-29 8:53 ` [PATCH 7/9] net: bridge: mcast: active state, if snooping is enabled Linus Lüssing
2025-08-29 8:53 ` [PATCH 8/9] net: bridge: mcast: track active state, bridge up/down Linus Lüssing
2025-08-29 8:53 ` [PATCH 9/9] net: bridge: mcast: add inactive state assertions Linus Lüssing
2025-08-29 15:47 ` [PATCH 0/9] net: bridge: reduce multicast checks in fast path Jakub Kicinski
2025-08-29 16:23 ` Nikolay Aleksandrov
2025-09-02 20:16 ` Linus Lüssing
2025-09-02 23:00 ` Linus Lüssing [this message]
2025-09-03 10:11 ` Nikolay Aleksandrov
2025-09-03 10:08 ` Nikolay Aleksandrov
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=aLd2_um-oWhS23Md@sellars \
--to=linus.luessing@c0d3.blue \
--cc=andrew+netdev@lunn.ch \
--cc=bridge@lists.linux.dev \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=idosch@nvidia.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=razor@blackwall.org \
--cc=sdf@fomichev.me \
--cc=shaw.leon@gmail.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.