[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <54B44B10.7000009@gmail.com>
Date: Mon, 12 Jan 2015 14:30:40 -0800
From: John Fastabend <john.fastabend@...il.com>
To: tgraf <tgraf@...g.ch>
CC: netdev <netdev@...r.kernel.org>
Subject: nft_hash rhashtable question
Hi Thomas,
I'm looking at the rhashtable usage.
But as I read the nft_hash_destroy() its not clear to me how
rht_for_each_entry_safe() and nft_hash_elem_destroy() keep everything
in sync.
Here is the code in question,
> static void nft_hash_destroy(const struct nft_set *set)
> {
> struct rhashtable *priv = nft_set_priv(set);
> const struct bucket_table *tbl;
> struct nft_hash_elem *he;
> struct rhash_head *pos, *next;
> unsigned int i;
>
> /* Stop an eventual async resizing */
> priv->being_destroyed = true;
> mutex_lock(&priv->mutex); <-- get the lock so we have single updater
>
> tbl = rht_dereference(priv->tbl, priv);
> for (i = 0; i < tbl->size; i++) {
> rht_for_each_entry_safe(he, pos, next, tbl, i, node)
> nft_hash_elem_destroy(set, he); <-- does a kfree on he?
> }
> mutex_unlock(&priv->mutex); <-- release the lock
>
> rhashtable_destroy(priv);
> }
Is it really safe to kfree 'he' without waiting a grace
period for any rcu readers to drop the reference?
I'm considering what happens if nft_hash_destroy runs in
parallel with nft_hash_lookup?
Thanks,
John
--
John Fastabend Intel Corporation
--
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
Powered by blists - more mailing lists