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(a)gmail.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.