On 2016年07月08日 11:56, Eric Dumazet wrote:
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.
Thanks for comment.
I have selected GFP flags based on existing code.
I have selected GFP_ATOMIC in inet6_netconf_get_devconf() because
skb was allocated with GFP_ATOMIC.
I have used GFP_KERNEL in inet6_rtm_getaddr() by same reason.
I will send a patch against net/ipv4/devinet.c so that we remove
GFP_ATOMIC usage there.
Thanks. I will modify my patch based on your new code.