Message-ID: <CADXeF1GEzTO4BuVnci0Vvorah+vCcrTZR9EE3ohQrN_TKnfL0A@mail.gmail.com>
Date: Tue, 19 Nov 2024 18:21:38 +0900
From: Yuyang Huang <yuyanghuang@...gle.com>
To: Hangbin Liu <liuhangbin@...il.com>
Cc: "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, 
	David Ahern <dsahern@...nel.org>, roopa@...ulusnetworks.com, jiri@...nulli.us, 
	stephen@...workplumber.org, jimictw@...gle.com, prohr@...gle.com, 
	nicolas.dichtel@...nd.com, andrew@...n.ch, netdev@...r.kernel.org, 
	Maciej Żenczykowski <maze@...gle.com>, 
	Lorenzo Colitti <lorenzo@...gle.com>, Patrick Ruddy <pruddy@...tta.att-mail.com>
Subject: Re: [PATCH net-next, v2] netlink: add IGMP/MLD join/leave notifications

Hi Hangbin

Thanks for the review feedback.

>Why the IPv4 scope use RT_SCOPE_LINK,

I'm unsure if I'm setting the IPv4 rt scope correctly.

I read the following document for rtm_scope:

```
/* rtm_scope

   Really it is not scope, but sort of distance to the destination.
   NOWHERE are reserved for not existing destinations, HOST is our
   local addresses, LINK are destinations, located on directly attached
   link and UNIVERSE is everywhere in the Universe.

   Intermediate values are also possible f.e. interior routes
   could be assigned a value between UNIVERSE and LINK.
*/
```

I believe RT_SCOPE_LINK is the closest match to the use case. IGMP
packets have a TTL of 1, so they are not forwarded to other networks.

I saw the RT_SCOPE_LINK was chosen in the original patch so I followed
the same pattern.

Link: https://lore.kernel.org/r/20180906091056.21109-1-pruddy@vyatta.att-mail.com

Please kindly advise here if we have more proper logic.

>And IPv6 use RT_SCOPE_UNIVERSE by default?

Since IPv6 provides the `static inline int ipv6_addr_scope(const
struct in6_addr *addr)` helper function, we should utilize it to
correctly determine the address scope. We have the logic like follows
in addrconf.c to determine the rt_scope.

```
static inline int rt_scope(int ifa_scope)
{
    if (ifa_scope & IFA_HOST)
       return RT_SCOPE_HOST;
    else if (ifa_scope & IFA_LINK)
        return RT_SCOPE_LINK;
    else if (ifa_scope & IFA_SITE)
        return RT_SCOPE_SITE;
    else
        return RT_SCOPE_UNIVERSE;
}

```

However, I found the addrconf.c:inet6_fill_ifmcaddr() is using the
following logic so I am trying to make the notification logic
consistent with dump logic.

Maybe we should update `inet6_fill_ifmcaddr()` to use
`ipv6_addr_scope()` to determine the scope properly?

```
static int inet6_fill_ifmcaddr(struct sk_buff *skb,
                  const struct ifmcaddr6 *ifmca,
                  struct inet6_fill_args *args)
{
    int ifindex = ifmca->idev->dev->ifindex;
    u8 scope = RT_SCOPE_UNIVERSE;
    struct nlmsghdr *nlh;
    if (ipv6_addr_scope(&ifmca->mca_addr) & IFA_SITE)
        scope = RT_SCOPE_SITE;
```


In general, I am not sure if the scope information is truly necessary
for IPv4 and IPv6 multicast notifications. In my experience, only the
address itself is needed.  The `ip maddr` command also omits scope.
Perhaps I'm missing some use cases where scope is essential.

>Not sure if we really need this WARN_ON. Wait for others comments.

I try to follow the existing code pattern in addrconf.c; for example:

```
err = inet6_fill_ifaddr(skb, ifa, &fillargs);
if (err < 0) {
    /* -EMSGSIZE implies BUG in inet6_ifaddr_msgsize() */
    WARN_ON(err == -EMSGSIZE);
    kfree_skb(skb);
    goto errout_ifa;
}
```

Thanks,
Yuyang

On Tue, Nov 19, 2024 at 4:39 PM Hangbin Liu <liuhangbin@...il.com> wrote:
>
> Hi Yuyang,
> On Sun, Nov 17, 2024 at 11:11:37PM +0900, Yuyang Huang wrote:
> > +static int inet_fill_ifmcaddr(struct sk_buff *skb, struct net_device *dev,
> > +                           __be32 addr, int event)
> > +{
> > +     struct ifaddrmsg *ifm;
> > +     struct nlmsghdr *nlh;
> > +
> > +     nlh = nlmsg_put(skb, 0, 0, event, sizeof(struct ifaddrmsg), 0);
> > +     if (!nlh)
> > +             return -EMSGSIZE;
> > +
> > +     ifm = nlmsg_data(nlh);
> > +     ifm->ifa_family = AF_INET;
> > +     ifm->ifa_prefixlen = 32;
> > +     ifm->ifa_flags = IFA_F_PERMANENT;
> > +     ifm->ifa_scope = RT_SCOPE_LINK;
>
> Why the IPv4 scope use RT_SCOPE_LINK,
>
> > +static int inet6_fill_ifmcaddr(struct sk_buff *skb, struct net_device *dev,
> > +                            const struct in6_addr *addr, int event)
> > +{
> > +     struct ifaddrmsg *ifm;
> > +     struct nlmsghdr *nlh;
> > +     u8 scope;
> > +
> > +     scope = RT_SCOPE_UNIVERSE;
> > +     if (ipv6_addr_scope(addr) & IFA_SITE)
> > +             scope = RT_SCOPE_SITE;
>
> And IPv6 use RT_SCOPE_UNIVERSE by default?
>
> > +
> > +     nlh = nlmsg_put(skb, 0, 0, event, sizeof(struct ifaddrmsg), 0);
> > +     if (!nlh)
> > +             return -EMSGSIZE;
> > +
> > +     ifm = nlmsg_data(nlh);
> > +     ifm->ifa_family = AF_INET6;
> > +     ifm->ifa_prefixlen = 128;
> > +     ifm->ifa_flags = IFA_F_PERMANENT;
> > +     ifm->ifa_scope = scope;
> > +     ifm->ifa_index = dev->ifindex;
> > +
> > +static void inet6_ifmcaddr_notify(struct net_device *dev,
> > +                               const struct in6_addr *addr, int event)
> > +{
> > +     struct net *net = dev_net(dev);
> > +     struct sk_buff *skb;
> > +     int err = -ENOBUFS;
> > +
> > +     skb = nlmsg_new(NLMSG_ALIGN(sizeof(struct ifaddrmsg))
> > +                     + nla_total_size(16), GFP_ATOMIC);
> > +     if (!skb)
> > +             goto error;
> > +
> > +     err = inet6_fill_ifmcaddr(skb, dev, addr, event);
> > +     if (err < 0) {
> > +             WARN_ON(err == -EMSGSIZE);
>
> Not sure if we really need this WARN_ON. Wait for others comments.
>
> Thanks
> Hangbin

Powered by blists - more mailing lists