From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
To: Yuyang Huang <sigefriedhyy@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>,
David Ahern <dsahern@kernel.org>,
Donald Hunter <donald.hunter@gmail.com>,
Eric Dumazet <edumazet@google.com>,
Ido Schimmel <idosch@nvidia.com>,
Jakub Kicinski <kuba@kernel.org>,
Kuniyuki Iwashima <kuniyu@google.com>,
Nikolaos Gkarlis <nickgarlis@gmail.com>,
Paolo Abeni <pabeni@redhat.com>,
Sabrina Dubroca <sd@queasysnail.net>,
Shuah Khan <shuah@kernel.org>, Simon Horman <horms@kernel.org>,
Stanislav Fomichev <sdf.kernel@gmail.com>,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
netdev@vger.kernel.org
Subject: Re: [PATCH net-next v2 1/3] rtnetlink: add AF_PACKET multicast dumps
Date: Wed, 9 Sep 2026 10:44:41 +0200 [thread overview]
Message-ID: <175b6b01-2f8e-4b77-8504-6f26d9f8df98@6wind.com> (raw)
In-Reply-To: <20260909013401.14408-2-sigefriedhyy@gmail.com>
Le 09/09/2026 à 03:33, Yuyang Huang a écrit :
> RTM_GETMULTICAST dumps IPv4 and IPv6 multicast group memberships, but
> the device multicast list (dev->mc) is only available through
> /proc/net/dev_mcast, so "ip maddr show" still has to parse procfs for
> its link-layer entries.
>
> Handle RTM_GETMULTICAST dumps with ifa_family set to AF_PACKET and
> report every entry of dev->mc in the existing ifaddrmsg format:
>
> - IFA_MULTICAST carries the raw link-layer address
> - IFA_MC_USERS carries the entry reference count
> - IFA_F_PERMANENT marks entries added with SIOCADDMULTI
> (netdev_hw_addr::global_use, "static" in "ip maddr")
The global flag is also set for addresses added via dev_mc_add_excl(), ie by
some drivers.
> - ifa_scope is RT_SCOPE_LINK
>
> This covers every column of /proc/net/dev_mcast. AF_PACKET is the
> family iproute2 already uses for link-layer addresses ("ip -0"), and
> AF_UNSPEC keeps its "all families" meaning from RTM_GETADDR.
>
> The default FDB dump also walks dev->mc, but only for Ethernet devices
> without an ndo_fdb_dump of their own, so bridge, vxlan or macvlan
> devices never show their multicast filter there, and it has no users
> count or SIOCADDMULTI bit. Extending it would change "bridge fdb show"
> output and add NDA_* attributes, while this dump needs no new uAPI.
>
> There are no legacy users of AF_PACKET requests, so they are always
> validated: prefixlen, flags and scope must be zero, no attributes are
> accepted, and a non-zero ifa_index restricts the dump to that device.
> The dump runs under RCU and netif_addr_lock_bh() and does not need
> RTNL.
>
> Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com>
> ---
> net/core/rtnetlink.c | 129 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 129 insertions(+)
>
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index 81c5a6104dea..b2febdb6915e 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -4566,6 +4566,133 @@ static int rtnl_dump_all(struct sk_buff *skb, struct netlink_callback *cb)
> return skb->len ? : ret;
> }
>
> +static int rtnl_fill_mcaddr(struct sk_buff *skb, const struct net_device *dev,
> + const struct netdev_hw_addr *ha, u32 portid,
> + u32 seq, unsigned int flags)
> +{
> + struct ifaddrmsg *ifm;
> + struct nlmsghdr *nlh;
> +
> + nlh = nlmsg_put(skb, portid, seq, RTM_GETMULTICAST, sizeof(*ifm),
> + flags);
> + if (!nlh)
> + return -EMSGSIZE;
> +
> + ifm = nlmsg_data(nlh);
> + ifm->ifa_family = AF_PACKET;
> + ifm->ifa_prefixlen = 0;
> + ifm->ifa_flags = ha->global_use ? IFA_F_PERMANENT : 0;
I wonder if adding a new attribute IFA_F_GLOBAL would not make the API more
understandable.
> + ifm->ifa_scope = RT_SCOPE_LINK;
> + ifm->ifa_index = dev->ifindex;
> +
> + if (nla_put(skb, IFA_MULTICAST, dev->addr_len, ha->addr) ||
> + nla_put_u32(skb, IFA_MC_USERS, ha->refcount)) {
> + nlmsg_cancel(skb, nlh);
> + return -EMSGSIZE;
> + }
> +
> + nlmsg_end(skb, nlh);
> + return 0;
> +}
> +
> +static int rtnl_dump_mcaddr_dev(struct net_device *dev, struct sk_buff *skb,
> + struct netlink_callback *cb, int *s_addr_idx,
> + unsigned int flags)
> +{
> + struct netdev_hw_addr *ha;
> + int addr_idx = 0;
> + int err = 0;
> +
> + netif_addr_lock_bh(dev);
> + netdev_for_each_mc_addr(ha, dev) {
> + if (addr_idx < *s_addr_idx) {
> + addr_idx++;
> + continue;
> + }
> + err = rtnl_fill_mcaddr(skb, dev, ha, NETLINK_CB(cb->skb).portid,
> + cb->nlh->nlmsg_seq, flags);
> + if (err < 0)
> + break;
> + addr_idx++;
> + }
> + netif_addr_unlock_bh(dev);
> +
> + *s_addr_idx = err < 0 ? addr_idx : 0;
> +
> + return err;
> +}
> +
> +static int rtnl_valid_dump_mcaddr_req(const struct nlmsghdr *nlh,
> + struct netlink_ext_ack *extack,
> + int *pifindex)
> +{
> + struct ifaddrmsg *ifm;
> +
> + ifm = nlmsg_payload(nlh, sizeof(*ifm));
> + if (!ifm) {
> + NL_SET_ERR_MSG(extack,
> + "Invalid header for multicast dump request");
> + return -EINVAL;
> + }
> +
> + if (ifm->ifa_prefixlen || ifm->ifa_flags || ifm->ifa_scope) {
> + NL_SET_ERR_MSG(extack,
> + "Invalid values in multicast dump header");
> + return -EINVAL;
> + }
> +
> + if (nlmsg_attrlen(nlh, sizeof(*ifm))) {
> + NL_SET_ERR_MSG(extack,
> + "Invalid data after multicast dump header");
> + return -EINVAL;
> + }
> +
> + *pifindex = ifm->ifa_index;
> +
> + return 0;
> +}
> +
> +static int rtnl_dump_mcaddr(struct sk_buff *skb, struct netlink_callback *cb)
> +{
> + struct net *net = sock_net(skb->sk);
For consistency with ipv4/ipv6, it would be nice to handle IFA_TARGET_NETNSID.
> + unsigned int flags = NLM_F_MULTI;
> + struct {
> + unsigned long ifindex;
> + int addr_idx;
> + } *ctx = (void *)cb->ctx;
> + struct net_device *dev;
> + int ifindex;
> + int err;
> +
> + err = rtnl_valid_dump_mcaddr_req(cb->nlh, cb->extack, &ifindex);
> + if (err < 0)
> + return err;
> +
> + rcu_read_lock();
> +
> + if (ifindex) {
> + cb->answer_flags |= NLM_F_DUMP_FILTERED;
> + flags |= NLM_F_DUMP_FILTERED;
> + dev = dev_get_by_index_rcu(net, ifindex);
> + if (!dev) {
> + err = -ENODEV;
> + goto out;
> + }
> + err = rtnl_dump_mcaddr_dev(dev, skb, cb, &ctx->addr_idx, flags);
> + goto out;
> + }
> +
> + for_each_netdev_dump(net, dev, ctx->ifindex) {
> + err = rtnl_dump_mcaddr_dev(dev, skb, cb, &ctx->addr_idx,
> + flags);
> + if (err < 0)
> + break;
> + }
> +out:
> + rcu_read_unlock();
> + return err;
> +}
> +
> struct sk_buff *rtmsg_ifinfo_build_skb(int type, struct net_device *dev,
> unsigned int change,
> u32 event, gfp_t flags, int *new_nsid,
> @@ -7251,6 +7378,8 @@ static const struct rtnl_msg_handler rtnetlink_rtnl_msg_handlers[] __initconst =
> {.msgtype = RTM_SETSTATS, .doit = rtnl_stats_set},
> {.msgtype = RTM_NEWLINKPROP, .doit = rtnl_newlinkprop},
> {.msgtype = RTM_DELLINKPROP, .doit = rtnl_dellinkprop},
> + {.protocol = PF_PACKET, .msgtype = RTM_GETMULTICAST,
> + .dumpit = rtnl_dump_mcaddr, .flags = RTNL_FLAG_DUMP_UNLOCKED},
> {.protocol = PF_BRIDGE, .msgtype = RTM_GETLINK,
> .dumpit = rtnl_bridge_getlink},
> {.protocol = PF_BRIDGE, .msgtype = RTM_DELLINK,
next prev parent reply other threads:[~2026-09-09 8:44 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-09 1:33 [PATCH net-next v2 0/3] rtnetlink: dump link-layer multicast addresses Yuyang Huang
2026-09-09 1:33 ` [PATCH net-next v2 1/3] rtnetlink: add AF_PACKET multicast dumps Yuyang Huang
2026-09-09 8:44 ` Nicolas Dichtel [this message]
2026-09-09 11:15 ` Yuyang Huang
2026-09-10 1:48 ` netdev-bot+sashiko
2026-09-10 3:21 ` Yuyang Huang
2026-09-09 1:34 ` [PATCH net-next v2 2/3] netlink: specs: rt-addr: document " Yuyang Huang
2026-09-10 1:48 ` netdev-bot+sashiko
2026-09-10 3:29 ` Yuyang Huang
2026-09-09 1:34 ` [PATCH net-next v2 3/3] selftests: net: test " Yuyang Huang
2026-09-10 1:48 ` netdev-bot+sashiko
2026-09-10 3:31 ` Yuyang Huang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=175b6b01-2f8e-4b77-8504-6f26d9f8df98@6wind.com \
--to=nicolas.dichtel@6wind.com \
--cc=davem@davemloft.net \
--cc=donald.hunter@gmail.com \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=idosch@nvidia.com \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nickgarlis@gmail.com \
--cc=pabeni@redhat.com \
--cc=sd@queasysnail.net \
--cc=sdf.kernel@gmail.com \
--cc=shuah@kernel.org \
--cc=sigefriedhyy@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®