Re: [PATCH] net: macvlan: fix multicast delivery to bridge ports with shared source MAC

[Jakub Kicinski]

On Wed, 25 Feb 2026 19:00:24 +0900 Kibaek Yoo wrote:
> When a macvlan interface in bridge mode shares its MAC address with an
> external source (e.g., VRRP virtual MAC), incoming multicast frames
> from that external source are incorrectly identified as locally
> originated. macvlan_hash_lookup() matches the source MAC to a local
> macvlan, causing macvlan_multicast_rx() to skip delivery to bridge
> ports under the assumption they already received the frame during
> transmission.
> 
> This assumption fails for protocols like VRRP where multiple hosts
> legitimately share the same virtual MAC address. The local macvlan
> never transmitted the frame, so bridge ports never saw it, yet the
> multicast is not delivered to them.
> 
> Fix this by passing NULL as the source device and including
> MACVLAN_MODE_BRIDGE in the mode mask for the else branch of

The change looks fine, AFAICT. But please rephrase the commit message
to avoid making it sound like a fix. The VRRP use case is rather odd
and it was simply not supported earlier. Now you're adding support 
with the tradeoff you note below. We don't want AI-based backporting
bots to pull this into LTS.

Please try to add a test case for your use case in selftests.

> macvlan_multicast_rx(). This ensures all VEPA and bridge mode macvlan
> interfaces receive incoming multicast regardless of source MAC
> matching. The trade-off is that looped-back locally-originated
> multicasts may be delivered to bridge ports a second time, but
> multicast consumers already handle duplicate frames.
-- 
pw-bot: cr