netdev - [PATCH RFC 0/2] caching bundles instead of policies

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 25 Mar 2010 11:24:49 +0200
From:	Timo Teras <timo.teras@....fi>
To:	netdev@...r.kernel.org
Cc:	Herbert Xu <herbert@...dor.apana.org.au>,
	Timo Teras <timo.teras@....fi>
Subject: [PATCH RFC 0/2] caching bundles instead of policies

This is not yet intended for commit (see below), but rather a
snapshot of what I'm working with currently. And to get some feedback
on the direction where I'm going.

The first patch changes flow cache reference counting fundamentally.
It no longer assumes that the cached objects are GC'd later, but instead
calls the virtualized delete method to delete (or drop it's reference).
This does now mean that ->delete() call can be slowish. The plan is to
add ->check() which is called when ever the cache is flushed, add all
deleted entries to GC list, and have the main flush routine delete the
GC list entries.

I wanted to suggest this because:
 - xfrm_policy_put() is currently never guaranteed to be fast, instead
   it can always result to slow path. Only the flow cache wanted to have
   fast free when bh is disabled, and this was made possible with the
   policy GC ensuring that cache is flushed before policies are freed.
 - now that we can cache bundles or policies, it makes sense to have
   more selective flushing; otherwise we lose some of the speed ups.
   This also means that flushing gets faster, and is needed very rarely
   (sensible points are GC'ing bundles and when interface goes down)
 - now we don't have to do two periodic/delayed GC's: one for bundles,
   and one for policies. instead we can have central code for that in
   the flow cache. this also means that the flow cache hash is the
   owner of bundle, and when the flow cache entry is expired the bundle
   is dst_free()'d (which we would want to do anyway). no need to keep
   bundles in separate global (or policy specific) list

Does this sound acceptable approach?

What the current patch set is missing:
 - delayed deletion of flow cache objects
 - doing check() on flush for each object
 - removing the policy GC
 - some of the other flow cache improvements from my original patch

Also, we might want to cache dummy bundles in xfrm_check_policy().
The reason is that if we matched sub policy originally, we always have
to do O(n) search for the main policy.

Timo Teras (2):
  flow: virtualize get and entry deletion methods
  xfrm: cache bundles instead of policies for outgoing flows

 include/net/flow.h      |   17 +-
 include/net/xfrm.h      |   12 +-
 net/core/flow.c         |  102 ++++---
 net/ipv4/xfrm4_policy.c |   22 --
 net/ipv6/xfrm6_policy.c |   31 --
 net/xfrm/xfrm_policy.c  |  755 +++++++++++++++++++++++++----------------------
 6 files changed, 471 insertions(+), 468 deletions(-)

--
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