[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151018080702.GA14564@breakpoint.cc>
Date: Sun, 18 Oct 2015 10:07:02 +0200
From: Florian Westphal <fw@...len.de>
To: Ani Sinha <ani@...sta.com>
Cc: Patrick McHardy <kaber@...sh.net>,
"David S. Miller" <davem@...emloft.net>,
netfilter-devel@...r.kernel.org, netfilter@...r.kernel.org,
coreteam@...filter.org,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: linux 3.4.43 : kernel crash at __nf_conntrack_confirm
Ani Sinha <ani@...sta.com> 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@...nvz.org>
> > 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@...filter.org>
> > 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.
--
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