On Mon, Oct 19, 2015 at 1:33 PM, Florian Westphal <fw@xxxxxxxxx> wrote: > Ani Sinha <ani@xxxxxxxxxx> wrote: >> On Sun, Oct 18, 2015 at 2:40 PM, Florian Westphal <fw@xxxxxxxxx> wrote: >> > Ani Sinha <ani@xxxxxxxxxx> wrote: >> >> Indeed. So it seems to me that we have run into one another such case. >> >> In patch c6825c0976fa7893692, I see we have added an additional check (along with comparing tuple and zone) to verify that if the conntrack is confirmed. >> >> >> >> + return nf_ct_tuple_equal(tuple, &h->tuple) && >> >> + nf_ct_zone(ct) == zone && >> >> + nf_ct_is_confirmed(ct); >> >> >> >> This is necessary since it's possible that a conntrack can be recreated with the same zone. >> >> Unfortunately, we leave a hole open in __nf_conntrack_confirm() because this routine _is_ responsible >> >> for confirming the conntrack. We cannot use the same logic here. >> > >> > Hmm, why? >> > >> > I don't understand why we need to change __nf_conntrack_confirm(), can >> > you elaborate? >> >> ok, let's take a step back. The fundamental question I am trying to >> find answer to is that whether it is possible for another thread to >> deallocate and then reallocate and initialize the conntrack object >> while running concurrently during __nf_conntrack_confirm() . > > Not unless something is broken. With or without e53376bef2cd97d3e3f61fdc6 ? > >> crash), we do not have the patch >> >> e53376bef2cd97d3e3f61fdc6 >> >> applied. This patch bumps the refcount before adding the connrack >> entry into the unconfirmed list. > > Yes, that patch fixes such bug. > >> + /* Now it is inserted into the unconfirmed list, bump refcount */ >> + nf_conntrack_get(&ct->ct_general); >> >> and if we assume the invariant that nf_conntrack_free() is never >> called when refcount is !=0, then this would seem to indicate that the >> above patch should fix the crash I mentioned in the thread. > > nf_conntrack_free must only be invoked after refcount becomes zero, right. > >> One curious piece of hunk is : >> >> + /* A freed object has refcnt == 0, that's >> + * the golden rule for SLAB_DESTROY_BY_RCU >> + */ >> + NF_CT_ASSERT(atomic_read(&ct->ct_general.use) == 0); >> + >> First, this assertion only puts a warning log at best when it fails. >> Second, if this assertion is false, at some point we will get into a >> kernel crash as the one I mentioned. So this assertion effectively >> does nothing other than perhaps help in debugging. > > Right. -- 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
