From: Tobias Waldekranz <tobias@waldekranz.com>
To: Jiri Pirko <jiri@resnulli.us>
Cc: davem@davemloft.net, kuba@kernel.org, olteanv@gmail.com,
atenart@kernel.org, roopa@nvidia.com, razor@blackwall.org,
bridge@lists.linux.dev, netdev@vger.kernel.org,
ivecera@redhat.com
Subject: Re: [PATCH v3 net] net: bridge: switchdev: Skip MDB replays of pending events
Date: Fri, 02 Feb 2024 08:09:46 +0100 [thread overview]
Message-ID: <875xz7tk91.fsf@waldekranz.com> (raw)
In-Reply-To: <ZbvFwVSQI1M_2WZo@nanopsycho>
On tor, feb 01, 2024 at 17:24, Jiri Pirko <jiri@resnulli.us> wrote:
> Thu, Feb 01, 2024 at 05:10:45PM CET, tobias@waldekranz.com wrote:
>>Before this change, generation of the list of events MDB to replay
>>would race against the IGMP/MLD snooping logic, which could concurrently
>>enqueue events to the switchdev deferred queue, leading to duplicate
>>events being sent to drivers. As a consequence of this, drivers which
>>reference count memberships (at least DSA), would be left with orphan
>>groups in their hardware database when the bridge was destroyed.
>>
>>Avoid this by grabbing the write-side lock of the MDB while generating
>>the replay list, making sure that no deferred version of a replay
>>event is already enqueued to the switchdev deferred queue, before
>>adding it to the replay list.
>>
>>An easy way to reproduce this issue, on an mv88e6xxx system, was to
>>create a snooping bridge, and immediately add a port to it:
>>
>> root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \
>> > ip link set dev x3 up master br0
>> root@infix-06-0b-00:~$ ip link del dev br0
>> root@infix-06-0b-00:~$ mvls atu
>> ADDRESS FID STATE Q F 0 1 2 3 4 5 6 7 8 9 a
>> DEV:0 Marvell 88E6393X
>> 33:33:00:00:00:6a 1 static - - 0 . . . . . . . . . .
>> 33:33:ff:87:e4:3f 1 static - - 0 . . . . . . . . . .
>> ff:ff:ff:ff:ff:ff 1 static - - 0 1 2 3 4 5 6 7 8 9 a
>> root@infix-06-0b-00:~$
>>
>>The two IPv6 groups remain in the hardware database because the
>>port (x3) is notified of the host's membership twice: once via the
>>original event and once via a replay. Since only a single delete
>>notification is sent, the count remains at 1 when the bridge is
>>destroyed.
>>
>>Fixes: 4f2673b3a2b6 ("net: bridge: add helper to replay port and host-joined mdb entries")
>>Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
>
> Could you please maintain 24 hours period between sending another patch
> version?
>
> https://www.kernel.org/doc/html/v6.7/process/maintainer-netdev.html#tl-dr
Sorry, I will avoid that going forward.
next prev parent reply other threads:[~2024-02-02 7:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-01 16:10 [PATCH v3 net] net: bridge: switchdev: Skip MDB replays of pending events Tobias Waldekranz
2024-02-01 16:24 ` Jiri Pirko
2024-02-02 7:09 ` Tobias Waldekranz [this message]
2024-02-05 11:41 ` Vladimir Oltean
2024-02-06 14:54 ` Tobias Waldekranz
2024-02-06 19:31 ` Vladimir Oltean
2024-02-06 21:58 ` Tobias Waldekranz
2024-02-07 16:36 ` Vladimir Oltean
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=875xz7tk91.fsf@waldekranz.com \
--to=tobias@waldekranz.com \
--cc=atenart@kernel.org \
--cc=bridge@lists.linux.dev \
--cc=davem@davemloft.net \
--cc=ivecera@redhat.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=razor@blackwall.org \
--cc=roopa@nvidia.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.