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.
