Asymmetric br_mdb_notify calls when handling IGMPv3 joins/leaves

Hi,

While testing the IGMP support in Linux I have observed that under certain
circumstances I can get an inconsistent state between the bridge mdb and
our Address Translation Unit (ATU). The root cause seems to be that the
bridge can issue more than one RTM_NEWMDB notification while handling a
single IGMP join (for a one port and group). When a later IGMP leave
is received for the same port and group it will not lead to more than one
RTM_DELMDB. The dsa layer however expects mdb notifications about added
and deleted entries to be symmetrical, ie. one DSA_NOTIFIER_MDB_DEL
received for a port should be preceded by no more than one
DSA_NOTIFIER_MDB_ADD for that port. If the notifications received are not
symmetrical, the reference counter for `struct dsa_mac_addr` might never
reach zero and the group will never be considered deleted in the
dsa layer.

The reason for the asymmetry in the bridge layer seems to be that
br_ip4_multicast_igmp3_report will potentially issue two RTM_NEWMDB
notifications when an IGMP join is received on an interface - one when
adding the group (via br_ip4_multicast_add_group) and then another one at
the end of the loop. An IGMP leave will only lead to one RTM_DELMDB (via
br_ip4_multicast_leave_group). I believe the same problem might exist
in br_ip6_multicast_mld2_report but I haven't tested that.

I don't feel that I grasp the logic in br_ip4_multicast_igmp3_report well
enough to be able to come up with a clean patch myself, does anyone else
have any idea? Am I right in my assumption that the bridge is at fault and
that the dsa layer should expect "symmetrical" adds and deletes?

Tested with a recent (e29edc4) net-next build.

Regards,
Jacques de Laval