On Wed, 2016-07-06 at 09:28 +0900, Masashi Honma wrote: > Signed-off-by: Masashi Honma <masashi.ho...@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.
