[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1467946591.1273.45.camel@edumazet-glaptop3.roam.corp.google.com>
Date: Fri, 08 Jul 2016 04:56:31 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: Masashi Honma <masashi.honma@...il.com>
Cc: netdev@...r.kernel.org, netfilter-devel@...r.kernel.org,
linux-wireless@...r.kernel.org, linux-rdma@...r.kernel.org,
linux-audit@...hat.com, cluster-devel@...hat.com,
davem@...emloft.net, johannes@...solutions.net,
pablo@...filter.org, kaber@...sh.net, kadlec@...ckhole.kfki.hu,
dledford@...hat.com, sean.hefty@...el.com,
hal.rosenstock@...il.com, paul@...l-moore.com, eparis@...hat.com,
zbr@...emap.net, pshelar@...ira.com, ccaulfie@...hat.com,
teigland@...hat.com, bsingharora@...il.com
Subject: Re: [RFC 5/7] net: Add allocation flag to rtnl_unicast()
On Wed, 2016-07-06 at 09:28 +0900, Masashi Honma wrote:
> Signed-off-by: Masashi Honma <masashi.honma@...il.com>
> ---
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index a1f6b7b..2b0b994 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -628,7 +628,7 @@ static int inet6_netconf_get_devconf(struct sk_buff *in_skb,
> kfree_skb(skb);
> goto errout;
> }
> - err = rtnl_unicast(skb, net, NETLINK_CB(in_skb).portid);
> + err = rtnl_unicast(skb, net, NETLINK_CB(in_skb).portid, GFP_ATOMIC);
> errout:
> return err;
> }
> @@ -4824,7 +4824,7 @@ static int inet6_rtm_getaddr(struct sk_buff *in_skb, struct nlmsghdr *nlh)
> kfree_skb(skb);
> goto errout_ifa;
> }
> - err = rtnl_unicast(skb, net, NETLINK_CB(in_skb).portid);
> + err = rtnl_unicast(skb, net, NETLINK_CB(in_skb).portid, GFP_KERNEL);
> errout_ifa:
> in6_ifa_put(ifa);
> errout:
Managing to mix GFP_ATOMIC and GFP_KERNEL almost randomly as you did in
this patch is definitely not good.
Further more, RTNL is a mutex, held in control path, designed to allow
schedules and waiting for memory under pressure.
We do not want to encourage GFP_ATOMIC usage in control path.
Your patch series gives the wrong signal to developers.
I will send a patch against net/ipv4/devinet.c so that we remove
GFP_ATOMIC usage there.
Powered by blists - more mailing lists