[PATCH net-next v5 0/4] rtnetlink: dump link-layer multicast addresses

Yuyang Huang posted 4 patches 1 week, 4 days ago
There is a newer version of this series
Documentation/netlink/specs/rt-addr.yaml |  17 ++-
include/uapi/linux/if_addr.h             |   1 +
net/core/rtnetlink.c                     | 174 +++++++++++++++++++++++
tools/testing/selftests/net/rtnetlink.py |  75 +++++++++-
4 files changed, 261 insertions(+), 6 deletions(-)
[PATCH net-next v5 0/4] rtnetlink: dump link-layer multicast addresses
Posted by Yuyang Huang 1 week, 4 days ago
"ip maddr show" prints three kinds of entries: link-layer, IPv4 and
IPv6. The IPv4 and IPv6 ones can be read over netlink today: IPv6 has
had RTM_GETMULTICAST for a long time and IPv4 got it in eb4e17a1d915
("netlink: support dumping IPv4 multicast addresses"), with IFA_MC_USERS
added later so the user count no longer has to come from procfs.

The link-layer list is the missing piece. dev->mc, the addresses
programmed into the device filter, is only exported via
/proc/net/dev_mcast, so iproute2 still carries a procfs parser just for
that. This series closes the gap so that "ip maddr show" can be served
from rtnetlink alone.

Patch 1 fixes the type of target-netnsid in the rt-addr spec. Patch 2
handles RTM_GETMULTICAST dumps with ifa_family set to AF_PACKET and
walks dev->mc under netif_addr_lock_bh(), no RTNL. The reply reuses
the ifaddrmsg format of the IPv4 and IPv6 dumps: IFA_MULTICAST carries
the raw link-layer address, IFA_MC_USERS the reference count, and a new
IFA_F_GLOBAL flag in IFA_FLAGS marks entries added explicitly, which is
the "static" column /proc/net/dev_mcast has and "ip maddr" prints. A
non-zero ifa_index limits the dump to one device and IFA_TARGET_NETNSID
selects another netns, like the IPv4 and IPv6 dumps.

Patch 3 updates the rt-addr spec and patch 4 adds a selftest that
checks the filter, the user count, the global flag and target-netnsid.

Nothing changes for other families. AF_PACKET dumps returned
-EOPNOTSUPP before, so iproute2 can keep the procfs fallback for older
kernels. I have the iproute2 side ready and will post it once this is
in; with it, "ip maddr show" does not open /proc/net at all.

Changes in v5:
- Filter the target-netnsid selftest dump by ifa-index, a new netns
  also contains the fallback tunnel devices

Changes in v4:
- Reset the resume offset when the device the dump stopped at is gone
- Use a tracked netns reference (put_net_track)
- Say ifa-family must be set in the spec doc, drop the AF_UNSPEC remark
- Close the netlink socket and guard the checks in the selftest
- Drop the Fixes tag

Changes in v3:
- Report the static bit as a new IFA_F_GLOBAL flag in IFA_FLAGS
  instead of IFA_F_PERMANENT
- Support IFA_TARGET_NETNSID and test it
- Describe global_use accurately, it is also set by dev_mc_add_excl()
- Fix the target-netnsid type in the rt-addr spec, as its own patch

Changes in v2:
- Always validate the request header, not only with strict checking
- Use a single "with" statement in the selftest (ruff)

Yuyang Huang (4):
  netlink: specs: rt-addr: fix the type of target-netnsid
  rtnetlink: add AF_PACKET multicast dumps
  netlink: specs: rt-addr: document AF_PACKET multicast dumps
  selftests: net: test AF_PACKET multicast dumps

 Documentation/netlink/specs/rt-addr.yaml |  17 ++-
 include/uapi/linux/if_addr.h             |   1 +
 net/core/rtnetlink.c                     | 174 +++++++++++++++++++++++
 tools/testing/selftests/net/rtnetlink.py |  75 +++++++++-
 4 files changed, 261 insertions(+), 6 deletions(-)

-- 
2.43.0
Re: [PATCH net-next v5 0/4] rtnetlink: dump link-layer multicast addresses
Posted by Jakub Kicinski 1 week, 1 day ago
On Mon, 14 Sep 2026 10:45:35 +0900 Yuyang Huang wrote:
> "ip maddr show" prints three kinds of entries: link-layer, IPv4 and
> IPv6. The IPv4 and IPv6 ones can be read over netlink today: IPv6 has
> had RTM_GETMULTICAST for a long time and IPv4 got it in eb4e17a1d915
> ("netlink: support dumping IPv4 multicast addresses"), with IFA_MC_USERS
> added later so the user count no longer has to come from procfs.

You compare the situation to IP but for L2 the UC addresses
are not exposed via RTM_GETADDR. Are you going to add it?

> The link-layer list is the missing piece. dev->mc, the addresses
> programmed into the device filter, is only exported via
> /proc/net/dev_mcast, so iproute2 still carries a procfs parser just for
> that. This series closes the gap so that "ip maddr show" can be served
> from rtnetlink alone.

Is that the only justification? To avoid reading proc?
Are you planning to extend this interface with new features?

> Patch 1 fixes the type of target-netnsid in the rt-addr spec. Patch 2
> handles RTM_GETMULTICAST dumps with ifa_family set to AF_PACKET and
> walks dev->mc under netif_addr_lock_bh(), no RTNL. The reply reuses
> the ifaddrmsg format of the IPv4 and IPv6 dumps: IFA_MULTICAST carries
> the raw link-layer address, IFA_MC_USERS the reference count, and a new
> IFA_F_GLOBAL flag in IFA_FLAGS marks entries added explicitly, which is
> the "static" column /proc/net/dev_mcast has and "ip maddr" prints. A
> non-zero ifa_index limits the dump to one device and IFA_TARGET_NETNSID
> selects another netns, like the IPv4 and IPv6 dumps.
> 
> Patch 3 updates the rt-addr spec and patch 4 adds a selftest that
> checks the filter, the user count, the global flag and target-netnsid.
> 
> Nothing changes for other families. AF_PACKET dumps returned
> -EOPNOTSUPP before, so iproute2 can keep the procfs fallback for older
> kernels. I have the iproute2 side ready and will post it once this is
> in; with it, "ip maddr show" does not open /proc/net at all.
Re: [PATCH net-next v5 0/4] rtnetlink: dump link-layer multicast addresses
Posted by Yuyang Huang 6 days, 9 hours ago
On Thu, Sep 17, 2026 at 10:47 AM Jakub Kicinski <kuba@kernel.org> wrote:

> You compare the situation to IP but for L2 the UC addresses
> are not exposed via RTM_GETADDR. Are you going to add it?

I'm not sure exposing dev->uc via RTM_GETADDR is useful: I haven't
found a use case, and iproute2 does not dump it today either ("ip
addr" only shows IFLA_ADDRESS). If you think
it is worth having for consistency, I'm happy to do it as a follow-up.

> Is that the only justification? To avoid reading proc?
> Are you planning to extend this interface with new features?

For more background:  we have some hardware offload control logic in
userspace that
needs the L2 and L3 multicast state of devices. L3 already comes
over netlink; dev->mc is the last piece read from procfs, so we have to
maintain two copies of the code, one for netlink and one for procfs,
and parsing procfs has none of the benefits netlink gives (e.g. per
interface filtering).

The same split exists in iproute2, where "ip maddr" parses
/proc/net/dev_mcast for the link-layer entries. I already updated
iproute2 to get rid of the procfs parsing for IPv4/IPv6 multicast; L2
multicast is the final piece, and I have something working locally.
Once this patchset is merged, I plan to send the iproute2 patchset.

Thanks,

Yuyang