All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Timo Teräs" <timo.teras@iki.fi>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH 1/4] flow: virtualize flow cache entry methods
Date: Sun, 04 Apr 2010 09:07:12 +0300	[thread overview]
Message-ID: <4BB82C90.70809@iki.fi> (raw)
In-Reply-To: <20100404055830.GA9484@gondor.apana.org.au>

Herbert Xu wrote:
> On Sun, Apr 04, 2010 at 08:50:41AM +0300, Timo Teräs wrote:
>> For the common case:
>>
>> 1. Policy deleted; policy->walk.dead set, policy->genid incremented
>> 2. NETDEV_DOWN hook called, calls flow_cache_flush()
>> 3. flow_cache_flush enumerates all policy and bundle refs
>>   in it's cache
>> 4. for each bundle xfrm_bundle_check_fce() is called, which
>>   calls stale_bundle()
>> 5. all bundles using stale policy, fail that check because
>>     xdst->policy_genid != xdst->pols[0]->genid
>>   (checked in xfrm_bundle_ok)
>> 6. flow cache calls entry's ->delete which is dst_free for bundles
>> 7. flow_cache_flush() returns
> 
> Ah, you're doing it in 2/4.  Can we please have each patch be
> a self-contained unit? It should be possible to apply 1/4 and
> have a resulting kernel that works properly without having to
> apply the rest of your patches.

With 1/4 only, the bundle deletion is not touched. In that case
the policy GC deletes explicitly the bundles. The bundles get
deleted immediately, and only the struct xfrm_policy might get
held up allocated longer.

The code flow would be:
 1. xfrm_policy_kill() queues to GC
 2. xfrm_policy_gc_kill() called from xfrm_policy_gc_task()
    frees all bundles in that policy
 3. xfrm_policy_gc_kill() releases it's reference
 4. ... time passes (flush, randomization, or flow hit occurs)
 5. flow cache releases it's final reference, calls
    xfrm_policy_destroy() which only frees the xfrm_policy memory

  reply	other threads:[~2010-04-04  6:07 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-01 12:52 [PATCH 0/4] caching bundles, iteration 3 Timo Teras
2010-04-01 12:52 ` [PATCH 1/4] flow: virtualize flow cache entry methods Timo Teras
2010-04-01 13:05   ` Eric Dumazet
2010-04-01 13:07     ` Timo Teräs
2010-04-03  3:38   ` Herbert Xu
2010-04-03  8:36     ` Herbert Xu
2010-04-03 13:50       ` Timo Teräs
2010-04-03 14:17         ` Herbert Xu
2010-04-03 14:26           ` Timo Teräs
2010-04-03 15:53             ` Herbert Xu
2010-04-03 20:19               ` Timo Teräs
2010-04-04  2:06                 ` Herbert Xu
2010-04-04  5:50                   ` Timo Teräs
2010-04-04  5:58                     ` Herbert Xu
2010-04-04  6:07                       ` Timo Teräs [this message]
2010-04-04  6:19                         ` Herbert Xu
2010-04-04  6:28                           ` Timo Teräs
2010-04-04  8:35                             ` Herbert Xu
2010-04-04 10:42   ` Herbert Xu
2010-04-04 10:50     ` Timo Teräs
2010-04-04 11:00       ` Herbert Xu
2010-04-04 11:06         ` Timo Teräs
2010-04-04 11:26           ` Herbert Xu
2010-04-04 11:31             ` Herbert Xu
2010-04-04 12:09               ` Timo Teräs
2010-04-01 12:52 ` [PATCH 2/4] xfrm: cache bundles instead of policies for outgoing flows Timo Teras
2010-04-01 12:52 ` [PATCH 3/4] xfrm: remove policy garbage collection Timo Teras
2010-04-01 12:52 ` [PATCH 4/4] flow: delayed deletion of flow cache entries Timo Teras
2010-04-02  3:00 ` [PATCH 0/4] caching bundles, iteration 3 David Miller
2010-04-02 13:12   ` Herbert Xu
  -- strict thread matches above, loose matches on Subject: below --
2010-04-05  7:00 [PATCH 0/4] caching bundles, iteration 4 Timo Teras
2010-04-05  7:00 ` [PATCH 1/4] flow: virtualize flow cache entry methods Timo Teras
2010-04-05  8:33   ` Herbert Xu
2010-04-05  8:36     ` Timo Teräs
2010-04-05  8:44       ` Herbert Xu
2010-04-05  8:49         ` Herbert Xu
2010-04-05  8:53           ` Timo Teräs
2010-04-05  9:12             ` Herbert Xu
2010-04-05 17:01               ` Timo Teras
2010-04-06 12:34                 ` Herbert Xu
2010-04-06 13:26                   ` Timo Teräs
2010-04-07  9:15                     ` David Miller
2010-04-07 10:30 [PATCH 0/4] caching bundles, iteration 5 Timo Teras
2010-04-07 10:30 ` [PATCH 1/4] flow: virtualize flow cache entry methods Timo Teras

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=4BB82C90.70809@iki.fi \
    --to=timo.teras@iki.fi \
    --cc=herbert@gondor.apana.org.au \
    --cc=netdev@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.