[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADXeF1E16ffcJ2tsYDHWr5OX=9B9u0_t3QoKus=RnuQw_e_0EQ@mail.gmail.com>
Date: Fri, 20 Dec 2024 00:34:51 +0900
From: Yuyang Huang <yuyanghuang@...gle.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: "David S. Miller" <davem@...emloft.net>, 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, liuhangbin@...il.com,
nicolas.dichtel@...nd.com, andrew@...n.ch, pruddy@...tta.att-mail.com,
netdev@...r.kernel.org, Maciej Żenczykowski <maze@...gle.com>,
Lorenzo Colitti <lorenzo@...gle.com>
Subject: Re: [PATCH net-next] netlink: correct nlmsg size for multicast notifications
>Same remark for inet_ifmcaddr_notify()
Moreover, for both IPv4 and IPv6, when a device is up, the kernel
joins the all-hosts multicast addresses (224.0.0.1/ff02::1). I guess
this logic also does not run in process context?
Thanks,
Yuyang
On Fri, Dec 20, 2024 at 12:27 AM Yuyang Huang <yuyanghuang@...gle.com> wrote:
>
> >Also GFP_ATOMIC should probably be replaced by GFP_KERNEL.
>
> >All inet6_ifmcaddr_notify() callers are in process context, hold RTNL,
> >thus can sleep under memory pressure.
>
> I might not have enough background knowledge here, but why does
> holding RTNL imply that the callers are in process context?
>
> Link: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/net/ipv6/addrconf.c#n2241
>
> In addrconf.c, the logic joins the solicited-node multicast group and
> calls into mcast.c logic, which eventually triggers the notification.
> I guess this code path is not in process context when the kernel does
> SLAAC?
>
> Thanks,
> Yuyang
>
> On Thu, Dec 19, 2024 at 11:31 PM Yuyang Huang <yuyanghuang@...gle.com> wrote:
> >
> > Hi Eric
> >
> > Thanks for the prompt review feedback. I will adjust all the comments
> > in the v2 patch.
> >
> > >inet6_fill_ifmcaddr() got an EXPORT_SYMBOL() for no good reason,
> > please remove it.
> >
> > I made the same mistake in Link:
> > https://lore.kernel.org/netdev/20241218090057.76899-1-yuyanghuang@google.com/T/
> >
> > I will fix that patch as well.
> >
> > Thanks,
> > Yuyang
> >
> > Thanks,
> > Yuyang
> >
> >
> > On Thu, Dec 19, 2024 at 10:47 PM Eric Dumazet <edumazet@...gle.com> wrote:
> > >
> > > On Thu, Dec 19, 2024 at 2:42 PM Eric Dumazet <edumazet@...gle.com> wrote:
> > > >
> > > > On Thu, Dec 19, 2024 at 2:27 PM Yuyang Huang <yuyanghuang@...gle.com> wrote:
> > > > >
> > > > > Corrected the netlink message size calculation for multicast group
> > > > > join/leave notifications. The previous calculation did not account for
> > > > > the inclusion of both IPv4/IPv6 addresses and ifa_cacheinfo in the
> > > > > payload. This fix ensures that the allocated message size is
> > > > > sufficient to hold all necessary information.
> > > > >
> > > > > Fixes: 2c2b61d2138f ("netlink: add IGMP/MLD join/leave notifications")
> > > > > Cc: Maciej Żenczykowski <maze@...gle.com>
> > > > > Cc: Lorenzo Colitti <lorenzo@...gle.com>
> > > > > Signed-off-by: Yuyang Huang <yuyanghuang@...gle.com>
> > > > > ---
> > > > > net/ipv4/igmp.c | 4 +++-
> > > > > net/ipv6/mcast.c | 4 +++-
> > > > > 2 files changed, 6 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
> > > > > index 8a370ef37d3f..4e2f1497f320 100644
> > > > > --- a/net/ipv4/igmp.c
> > > > > +++ b/net/ipv4/igmp.c
> > > > > @@ -1473,7 +1473,9 @@ static void inet_ifmcaddr_notify(struct net_device *dev,
> > > > > int err = -ENOMEM;
> > > > >
> > > > > skb = nlmsg_new(NLMSG_ALIGN(sizeof(struct ifaddrmsg)) +
> > > > > - nla_total_size(sizeof(__be32)), GFP_ATOMIC);
> > > > > + nla_total_size(sizeof(__be32)) +
> > > > > + nla_total_size(sizeof(struct ifa_cacheinfo)),
> > > > > + GFP_ATOMIC);
> > > > > if (!skb)
> > > > > goto error;
> > > > >
> > > > > diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
> > > > > index 587831c148de..b7430f15d1fc 100644
> > > > > --- a/net/ipv6/mcast.c
> > > > > +++ b/net/ipv6/mcast.c
> > > > > @@ -920,7 +920,9 @@ static void inet6_ifmcaddr_notify(struct net_device *dev,
> > > > > int err = -ENOMEM;
> > > > >
> > > > > skb = nlmsg_new(NLMSG_ALIGN(sizeof(struct ifaddrmsg)) +
> > > > > - nla_total_size(16), GFP_ATOMIC);
> > > > > + nla_total_size(16) +
> > > >
> > > > While we are at it , can you use nla_total_size(sizeof(struct in6_addr))
> > > >
> > > > inet6_fill_ifmcaddr() got an EXPORT_SYMBOL() for no good reason,
> > > > please remove it.
> > > > Squash the following in v2, thanks !
> > > >
> > > > diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> > > > index 2e2684886953d55140cd3d4a1e024b5218331a49..4da409bc45777f60fd37bdee541c61165a51d22c
> > > > 100644
> > > > --- a/net/ipv6/addrconf.c
> > > > +++ b/net/ipv6/addrconf.c
> > > > @@ -5239,7 +5239,6 @@ int inet6_fill_ifmcaddr(struct sk_buff *skb,
> > > > nlmsg_end(skb, nlh);
> > > > return 0;
> > > > }
> > > > -EXPORT_SYMBOL(inet6_fill_ifmcaddr);
> > > >
> > > > static int inet6_fill_ifacaddr(struct sk_buff *skb,
> > > > const struct ifacaddr6 *ifaca,
> > >
> > > Also GFP_ATOMIC should probably be replaced by GFP_KERNEL.
> > >
> > > All inet6_ifmcaddr_notify() callers are in process context, hold RTNL,
> > > thus can sleep under memory pressure.
> > >
> > > Same remark for inet_ifmcaddr_notify()
Powered by blists - more mailing lists