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
| ||
|
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