[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201203102802.62bc86ba@kicinski-fedora-pc1c0hjn.DHCP.thefacebook.com>
Date: Thu, 3 Dec 2020 10:28:02 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Joseph Huang <Joseph.Huang@...min.com>
Cc: Roopa Prabhu <roopa@...dia.com>,
Nikolay Aleksandrov <nikolay@...dia.com>,
"David S. Miller" <davem@...emloft.net>,
<bridge@...ts.linux-foundation.org>, <netdev@...r.kernel.org>,
<linux-kernel@...r.kernel.org>,
Linus Lüssing <linus.luessing@...3.blue>
Subject: Re: [PATCH] bridge: Fix a deadlock when enabling multicast snooping
On Tue, 1 Dec 2020 16:40:47 -0500 Joseph Huang wrote:
> When enabling multicast snooping, bridge module deadlocks on multicast_lock
> if 1) IPv6 is enabled, and 2) there is an existing querier on the same L2
> network.
>
> The deadlock was caused by the following sequence: While holding the lock,
> br_multicast_open calls br_multicast_join_snoopers, which eventually causes
> IP stack to (attempt to) send out a Listener Report (in igmp6_join_group).
> Since the destination Ethernet address is a multicast address, br_dev_xmit
> feeds the packet back to the bridge via br_multicast_rcv, which in turn
> calls br_multicast_add_group, which then deadlocks on multicast_lock.
>
> The fix is to move the call br_multicast_join_snoopers outside of the
> critical section. This works since br_multicast_join_snoopers only deals
> with IP and does not modify any multicast data structures of the bridge,
> so there's no need to hold the lock.
>
> Fixes: 4effd28c1245 ("bridge: join all-snoopers multicast address")
>
> Signed-off-by: Joseph Huang <Joseph.Huang@...min.com>
Nik, Linus - how does this one look?
Powered by blists - more mailing lists