netdev - Re: [PATCH net-next 2/3] netlink: Convert netlink_lookup() to use RCU protected hash table

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <53DBB049.30902@redhat.com>
Date:	Fri, 01 Aug 2014 17:20:41 +0200
From:	Nikolay Aleksandrov <nikolay@...hat.com>
To:	Thomas Graf <tgraf@...g.ch>
CC:	davem@...emloft.net, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, kaber@...sh.net,
	paulmck@...ux.vnet.ibm.com, josh@...htriplett.org,
	challa@...ronetworks.com, walpole@...pdx.edu, dev@...nvswitch.org,
	tklauser@...tanz.ch, netfilter-devel@...r.kernel.org
Subject: Re: [PATCH net-next 2/3] netlink: Convert netlink_lookup() to use
 RCU protected hash table

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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html