On 09/02/14 at 11:38am, Pablo Neira Ayuso wrote:
> No need for rht_dereference() from rhashtable_destroy() since the
> existing callers don't hold the mutex when invoking this function
> from:
>
> 1) Netlink, this is called in case of memory allocation errors in the
> initialization path, no nl_sk_hash_lock is held.
> 2) Netfilter, this is called from the rcu callback, no nfnl_lock is
> held either.
>
> I think it's reasonable to assume that the caller has to make sure
> that no hash resizing may happen before releasing the bucket array.
> Therefore, the caller should be responsible for releasing this in a
> safe way, document this to make people aware of it.
>
> This resolves a rcu lockdep splat in nft_hash:
>
> ===============================
> [ INFO: suspicious RCU usage. ]
> 3.16.0+ #178 Not tainted
> -------------------------------
> lib/rhashtable.c:596 suspicious rcu_dereference_protected() usage!
>
> other info that might help us debug this:
>
> rcu_scheduler_active = 1, debug_locks = 1
> 1 lock held by ksoftirqd/2/18:
> #0: (rcu_callback){......}, at: [<ffffffff810918fd>] rcu_process_callbacks+0x27e/0x4c7
>
> stack backtrace:
> CPU: 2 PID: 18 Comm: ksoftirqd/2 Not tainted 3.16.0+ #178
> Hardware name: LENOVO 23259H1/23259H1, BIOS G2ET32WW (1.12 ) 05/30/2012
> 0000000000000001 ffff88011706bb68 ffffffff8143debc 0000000000000000
> ffff880117062610 ffff88011706bb98 ffffffff81077515 ffff8800ca041a50
> 0000000000000004 ffff8800ca386480 ffff8800ca041a00 ffff88011706bbb8
> Call Trace:
> [<ffffffff8143debc>] dump_stack+0x4e/0x68
> [<ffffffff81077515>] lockdep_rcu_suspicious+0xfa/0x103
> [<ffffffff81228b1b>] rhashtable_destroy+0x46/0x52
> [<ffffffffa06f21a7>] nft_hash_destroy+0x73/0x82 [nft_hash]
>
> Signed-off-by: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
Acked-by: Thomas Graf <tgraf@xxxxxxx>
--
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
