On Sun, Oct 18, 2015 at 1:07 AM, Florian Westphal <fw@xxxxxxxxx> wrote: > Ani Sinha <ani@xxxxxxxxxx> wrote: >> Coming back to this crash, I see something interesting in the >> conntrack code in linux 3.4.109 (a supported kernel version). I see >> that the hash table manipulations are protected by a spinlock. Also >> lookups/reads are protected by RCU. However allocation and >> deallocation of conntrack objects happen outside of both the locks. >> It seems to me that a conntrack object can be deallocated and a new >> object can be allocated and initialized within the same RCU grace >> period, while the hash table is being read. > > Yes. We need to use SLAB_DESTROY_BY_RCU instead of kfree_rcu because > there could be hundreds of thousands of alloc/free pairs within a short > time period. > >> It looks like a bug to me. > > No, as long as readers detect object reuse. > >> > Looking upstream, I see a couple of patches which fixes race condition >> > around the use of the conntrack hash table with RCU (lock free read) >> > primitives : >> > >> > commit c6825c0976fa7893692e0e43b09740b419b23c09 >> > Author: Andrey Vagin <avagin@xxxxxxxxxx> >> > Date: Wed Jan 29 19:34:14 2014 +0100 >> > netfilter: nf_conntrack: fix RCU race in nf_conntrack_find_get >> > >> > and a followup patch : >> > >> > commit e53376bef2cd97d3e3f61fdc677fb8da7d03d0da >> > Author: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> >> > Date: Mon Feb 3 20:01:53 2014 +0100 >> > netfilter: nf_conntrack: don't release a conntrack with non-zero refcnt >> > > > These for instance fix such bugs. So since both these patches were not backported to 3.4 series and since now we have evidence of a crash that points to issues which the patches fix, should we consider backporting the above patches to 3.4? -- 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
