[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A438AC8.3010907@trash.net>
Date: Thu, 25 Jun 2009 16:33:44 +0200
From: Patrick McHardy <kaber@...sh.net>
To: jdb@...x.dk
CC: Christoph Lameter <cl@...ux-foundation.org>, linux-mm@...ck.org,
"David S. Miller" <davem@...emloft.net>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
dougthompson@...ssion.com, bluesmoke-devel@...ts.sourceforge.net,
axboe@...nel.dk, christine.caulfield@...glemail.com,
Trond.Myklebust@...app.com, linux-wireless@...r.kernel.org,
johannes@...solutions.net, yoshfuji@...ux-ipv6.org,
shemminger@...ux-foundation.org, linux-nfs@...r.kernel.org,
bfields@...ldses.org, neilb@...e.de, linux-ext4@...r.kernel.org,
tytso@....edu, adilger@....com, netfilter-devel@...r.kernel.org
Subject: Re: [PATCH v3 10/10] nf_conntrack: Use rcu_barrier()
Jesper Dangaard Brouer wrote:
> RCU barriers, rcu_barrier(), is inserted two places.
>
> In nf_conntrack_expect.c nf_conntrack_expect_fini() before the
> kmem_cache_destroy(). Firstly to make sure the callback to the
> nf_ct_expect_free_rcu() code is still around. Secondly because I'm
> unsure about the consequence of having in flight
> nf_ct_expect_free_rcu/kmem_cache_free() calls while doing a
> kmem_cache_destroy() slab destroy.
>
> And in nf_conntrack_extend.c nf_ct_extend_unregister(), inorder to
> wait for completion of callbacks to __nf_ct_ext_free_rcu(), which is
> invoked by __nf_ct_ext_add(). It might be more efficient to call
> rcu_barrier() in nf_conntrack_core.c nf_conntrack_cleanup_net(), but
> thats make it more difficult to read the code (as the callback code
> in located in nf_conntrack_extend.c).
Applied, thanks Jesper.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" 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