On 08/01/2014 05:15 PM, Thomas Graf wrote: > On 08/01/14 at 04:51pm, Nikolay Aleksandrov wrote: >> Hmm, in both the rhashtable_insert() and rhashtable_remove() calls in the >> netlink code you're using GFP_ATOMIC flags but if rhashtable_expand/shring gets >> called even though the allocation will be with GFP_ATOMIC, they still call >> synchronize_rcu() which may block. Now I'm not familiar with the netlink code, >> but I think that in general the flags are useless for GFP_ATOMIC because of the >> calls to synchronize_rcu() in expand/shrink which can block anyway. >> Just a thought, I may be missing something of course. > > I don't think you are missing anything. The GFP_ATOMIC flag was > inherited from how the bucket table was allocated prior to the > convertion to the new hash table but you are right, it can't be > needed since the table protection was converted to a mutex. > Using GFP_KERNEL will have a better chance of succeeding. > Right, I was wondering why it was atomic in the first place and couldn't find a good reason from the code :-) But that explains it. Cheers, Nik -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
