summaryrefslogtreecommitdiff
path: root/include/uapi/linux
diff options
context:
space:
mode:
authorKibaek Yoo <psykibaek@gmail.com>2026-02-28 16:16:12 +0900
committerJakub Kicinski <kuba@kernel.org>2026-03-03 18:08:13 -0800
commitb52363f706e53101d9f8c5ba5e3854d6be8f122c (patch)
tree40f248fe6f4bec6ae8bd9ed776db8a57de859372 /include/uapi/linux
parentd6ca199568c53ece99aeeae1022d04f2fd8cde7f (diff)
downloadlwn-b52363f706e53101d9f8c5ba5e3854d6be8f122c.tar.gz
lwn-b52363f706e53101d9f8c5ba5e3854d6be8f122c.zip
net: macvlan: support multicast rx for bridge ports with shared source MAC
Macvlan bridge mode currently does not handle the case where an external source shares its MAC address with a local macvlan interface. When such a frame arrives, macvlan_hash_lookup() matches the source MAC to the local macvlan, and macvlan_multicast_rx() assumes bridge ports already received the frame during local transmission. Since the frame actually originated externally, bridge ports never saw it. This situation arises with protocols like VRRP, where multiple hosts use the same virtual MAC address. Support this by passing NULL as the source device and including MACVLAN_MODE_BRIDGE in the mode mask for the else branch of 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. Signed-off-by: Kibaek Yoo <psykibaek@gmail.com> Link: https://patch.msgid.link/20260228071613.4360-1-psykibaek@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'include/uapi/linux')
0 files changed, 0 insertions, 0 deletions