Le 08/09/2026 à 04:56, Yuyang Huang a écrit : >> These addresses could be listed with 'bridge fdb' (RTM_GETNEIGH on >> AF_BRIDGE). >> Instead of having a new message to get the missing info (users), maybe it >> would >> be better to update the current API. > > I looked at the FDB dump based on the suggestion and I don't think > that path works well. The missing users count is not the only problem: > > It doesn't list dev->mc for every device. Only ndo_dflt_fdb_dump() > walks dev->mc, and rtnl_fdb_dump() calls it only for Ethernet devices > that have no ndo_fdb_dump of their own. So bridge, vxlan, macvlan and > IPoIB devices never show their multicast filter in "bridge fdb show", > while /proc/net/dev_mcast lists them. Fixing that means calling the > default dump for those devices too, which adds new entries to > "bridge fdb show" output on every one of them. > > User space can't reliably tell the entries apart either. "ip maddr" > would keep NTF_SELF entries with a multicast lladdr, but it seems vxlan's own > FDB entries seems also carry NTF_SELF, so a multicast MAC added there as a > forwarding rule (bridge fdb add ... dev vxlan0 dst ...) would show up > as a device multicast address, while the real dev->mc of that vxlan > device is missing. And since a dump can't be limited to self entries, > on a host with bridges "ip maddr show" would receive the whole learned > FDB of every port and drop it. > > It would still need a new uAPI. All self entries are NUD_PERMANENT, so > the users count and the SIOCADDMULTI (static) bit would be new NDA_* > attributes. On the other hand, this series adds no new attributes; > IFA_MULTICAST, IFA_MC_USERS and IFA_F_PERMANENT already exist for the > IPv4 and IPv6 dumps. > > Covering this with RTM_GETNEIGH would need the default dump for > devices with their own ndo_fdb_dump, a way to tell filter entries from > a device's own > NTF_SELF FDB entries, a self-only request filter, and new NDA_* > attributes for users and the static bit. That is more new uAPI than > this series for the same result. > > Therefore, I feel that my original proposal seems cleaner and causes > less chrun. But feel free to let me know if I have any > misunderstanding on the suggestion. Ok, I agree, it seems easier to have another entry point.
> >> FWIW, AF_PACKET seems strange to me. Isn't AF_UNSPEC (like for interface, cf >> rtnl_fill_ifinfo) more appropriate? > > For address dumps AF_UNSPEC already means "all families" (RTM_GETADDR > goes through rtnl_dump_all()), so I'd rather keep it available for > RTM_GETMULTICAST. AF_PACKET is what iproute2 already uses for the link > family: "ip -0" sets preferred_family = AF_PACKET and sends it in > RTM_GETLINK, and ipmaddr.c has always tagged the /proc/net/dev_mcast > entries as AF_PACKET. I hadn't looked at iproute2. It uses AF_PACKET for link-layer addresses, so that seems OK too. Nicolas
