netdev - Re: [PATCH net-next, v4] netlink: support dumping IPv4 multicast addresses

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADXeF1FQH-odRgvUg=uBVwKkVkZ2YP+uNYt6WwU0Q4cxLxW3rA@mail.gmail.com>
Date: Fri, 10 Jan 2025 01:10:47 +0900
From: Yuyang Huang <yuyanghuang@...gle.com>
To: David Ahern <dsahern@...nel.org>
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>, 
	roopa@...ulusnetworks.com, jiri@...nulli.us, stephen@...workplumber.org, 
	jimictw@...gle.com, prohr@...gle.com, liuhangbin@...il.com, 
	nicolas.dichtel@...nd.com, andrew@...n.ch, netdev@...r.kernel.org, 
	Maciej Żenczykowski <maze@...gle.com>, 
	Lorenzo Colitti <lorenzo@...gle.com>
Subject: Re: [PATCH net-next, v4] netlink: support dumping IPv4 multicast addresses

>You don't have to wait for iproute2 changes to be merged.
>Push them somewhere we can pull from, and when you post v5
>(with the self-test) just add a link to that iproute2 git repo
>to the cover letter.
>We'll pull your changes to the iproute2 used by the CI image.

Thanks for the suggestion, I will include the iproute2 based self-test
in v5 patch.

Thanks
Yuyang

On Fri, Jan 10, 2025 at 1:09 AM Yuyang Huang <yuyanghuang@...gle.com> wrote:
>
> >my comment meant that this `type` should be removed and the wrappers
> >below just call the intended function. No need for the extra layers.
>
> This patch was trying to follow the similar pattern in addrconf.c. We
> have a similar addr_type_t based dispatching mechanism to handle the
> dumping of ANYCAST, MULTICAST, and UNICAST addresses.
>
> inet6_dump_ifaddr()/inet6_dump_ifmcaddr()/inet6_dump_ifacaddr() ->
> inet6_dump_addr() -> in6_dump_addrs()
>
> The dispatching switch statement resides within in6_dump_addrs(), and
> those dump functions share the common code path in inet6_dump_addr().
>
> Thanks,
> Yuyang
>
>
> On Fri, Jan 10, 2025 at 12:52 AM Yuyang Huang <yuyanghuang@...gle.com> wrote:
> >
> > >my comment meant that this `type` should be removed and the wrappers
> > >below just call the intended function. No need for the extra layers.
> >
> > Sorry, I still do not fully understand the suggestions.
> >
> > In the current inet_dump_ifaddr() function, there are two places where
> > in_dev_dump_addr() is called.
> >
> > For example, we have the following code snippet.
> >
> > >if (!in_dev)
> > >goto done;
> > >err = in_dev_dump_addr(in_dev, skb, cb, &ctx->ip_idx,
> > >       &fillargs);
> > >goto done;
> > >}
> >
> > Do you suggest we do the following way?
> >
> > > If (type == UNICAST_ADDR)
> > >    err = in_dev_dump_ifaddr(in_dev, skb, cb, &ctx->ip_idx,
> > >                                             &fillargs);
> > > else if (type == MULTICAST_ADDR)
> > >    in_dev_dump_ifmcaddr(in_dev, skb, cb, s_ip_idx,
> > >                                         &fillargs);
> >
> > The current functional call stack is as follows:
> >
> > inet_dump_ifaddr()/inet_dump_ifmcaddr() -> inet_dump_addr() ->
> > in_dev_dump_ifaddr()/in_dev_dump_ifmcaddr().
> >
> > The ifaddr and ifmcaddr dump code paths share common logic inside
> > inet_dump_addr(). If we don't do the dispatching in
> > in_dev_dump_addr(), we have to do the dispatching in inet_dump_addr()
> > instead, and the dispatching logic will be duplicated twice. I don't
> > think this will simplify the code.
> >
> > Or do you suggest I should pass a function pointer for
> > in_dev_dump_ifaddr()/in_dev_dump_ifmcaddr() into inet_dump_addr()?
> >
> > Thanks,
> >
> > Yuyang
> >
> > On Fri, Jan 10, 2025 at 12:33 AM David Ahern <dsahern@...nel.org> wrote:
> > >
> > > On 1/9/25 12:22 AM, Yuyang Huang wrote:
> > > > @@ -1889,15 +1935,16 @@ static u32 inet_base_seq(const struct net *net)
> > > >       return res;
> > > >  }
> > > >
> > > > -static int inet_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
> > > > +static int inet_dump_addr(struct sk_buff *skb, struct netlink_callback *cb,
> > > > +                       enum addr_type_t type)
> > > >  {
> > > >       const struct nlmsghdr *nlh = cb->nlh;
> > > >       struct inet_fill_args fillargs = {
> > > >               .portid = NETLINK_CB(cb->skb).portid,
> > > >               .seq = nlh->nlmsg_seq,
> > > > -             .event = RTM_NEWADDR,
> > > >               .flags = NLM_F_MULTI,
> > > >               .netnsid = -1,
> > > > +             .type = type,
> > >
> > > my comment meant that this `type` should be removed and the wrappers
> > > below just call the intended function. No need for the extra layers.
> > >
> > > >       };
> > > >       struct net *net = sock_net(skb->sk);
> > > >       struct net *tgt_net = net;
> > > > @@ -1949,6 +1996,20 @@ static int inet_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
> > > >       return err;
> > > >  }
> > > >
> > > > +static int inet_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
> > > > +{
> > > > +     enum addr_type_t type = UNICAST_ADDR;
> > > > +
> > > > +     return inet_dump_addr(skb, cb, type);
> > > > +}
> > > > +
> > > > +static int inet_dump_ifmcaddr(struct sk_buff *skb, struct netlink_callback *cb)
> > > > +{
> > > > +     enum addr_type_t type = MULTICAST_ADDR;
> > > > +
> > > > +     return inet_dump_addr(skb, cb, type);
> > > > +}
> > > > +
> > > >  static void rtmsg_ifa(int event, struct in_ifaddr *ifa, struct nlmsghdr *nlh,
> > > >                     u32 portid)
> > > >  {
> > >