All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Florian Westphal <fw@strlen.de>, netfilter-devel@vger.kernel.org
Subject: Re: [PATCH nf-next 2/6] netfilter: conntrack: get rid of conntrack timer
Date: Fri, 19 Aug 2016 18:04:46 +0200	[thread overview]
Message-ID: <20160819160446.GC11049@breakpoint.cc> (raw)
In-Reply-To: <1471620263.29842.107.camel@edumazet-glaptop3.roam.corp.google.com>

Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Fri, 2016-08-19 at 17:16 +0200, Florian Westphal wrote:
> 
> > Hmm, ____nf_conntrack_find caller needs to hold rcu_read_lock,
> > in case object is free'd SLAB_DESTROY_BY_RCU should delay actual release
> > of the page.
> 
> Well, point is that SLAB_DESTROY_BY_RCU means that we have no grace
> period, and object can be immediately reused and recycled.
> 
> @next pointer can definitely be overwritten.

I see.  Isn't that detected by the nulls magic (to restart
lookup if entry was moved to other chain due to overwritten next pointer)?

I don't see a hlist_nulls_for_each_entry_rcu_safe variant like we have
for normal lists (list_for_each_entry_safe), do I need to add one?
Currently we have this:

rcu_read_lock()
____nf_conntrack_find
hlist_nulls_for_each_entry_rcu ...

 if (nf_ct_is_expired(ct)) { // lazy test, ct can be reused here
	 nf_ct_gc_expired(ct);
	 continue;
 }

nf_ct_gc_expired() does this:

static void nf_ct_gc_expired(struct nf_conn *ct)
{
        if (!atomic_inc_not_zero(&ct->ct_general.use))
                return;

        if (nf_ct_should_gc(ct))
                nf_ct_kill(ct);

        nf_ct_put(ct);

So we only nf_ct_kill when we have a reference
and we know ct is in hash (check is in nf_ct_should_gc()).

So once we put, the object can be released but the
next pointer is not altered.

In case ct object is reused right after this last
nf_ct_put it could be re-inserted already, e.g. into
dying list or back into hash table -- but is this a problem?

'dead' (non-recycled) element is cought by atomic_inc_not_zero
in nf_ct_gc_expired, about-to-inserted (not in hash) is detected
by nf_ct_should_gc() (it checks confirmed bit in ct->status),
already-inserted (in hashtable) would lead us to 'magically'
move to a different hash chain in hlist_nulls_for_each_entry_rcu.

But we would then hit the wrong nulls list terminator and restart
the traversal.

Does that make sense?

  reply	other threads:[~2016-08-19 16:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-19 11:36 [PATCH nf-next 0/6] conntrack: get rid of per-object timer Florian Westphal
2016-08-19 11:36 ` [PATCH nf-next 1/6] netfilter: don't rely on DYING bit to detect when destroy event was sent Florian Westphal
2016-08-19 11:36 ` [PATCH nf-next 2/6] netfilter: conntrack: get rid of conntrack timer Florian Westphal
2016-08-19 14:37   ` Eric Dumazet
2016-08-19 15:16     ` Florian Westphal
2016-08-19 15:24       ` Eric Dumazet
2016-08-19 16:04         ` Florian Westphal [this message]
2016-08-22  4:13           ` Eric Dumazet
2016-08-22  8:53             ` Florian Westphal
2016-08-19 11:36 ` [PATCH nf-next 3/6] netfilter: evict stale entries on netlink dumps Florian Westphal
2016-08-19 11:36 ` [PATCH nf-next 4/6] netfilter: conntrack: add gc worker to remove timed-out entries Florian Westphal
2016-08-19 14:41   ` Eric Dumazet
2016-08-19 15:22     ` Florian Westphal
2016-08-19 11:36 ` [PATCH nf-next 5/6] netfilter: conntrack: resched gc again if eviction rate is high Florian Westphal
2016-08-19 11:36 ` [PATCH nf-next 6/6] netfilter: remove __nf_ct_kill_acct helper Florian Westphal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160819160446.GC11049@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=eric.dumazet@gmail.com \
    --cc=netfilter-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.