andrew.cagney at gmail.com
Wed Feb 19 18:23:46 UTC 2020
On Wed, 19 Feb 2020 at 12:41, Paul Wouters <paul at nohats.ca> wrote:
> On Wed, 19 Feb 2020, Andrew Cagney wrote:
> > I've looked a bit at offloading everything. The first thing to rear
> > its ugly head is, of course, reorienting the connection. ARRRRHG!
> Yeah, I think that is going to be the way forward.
> Why is re-orienting a problem? Can we skip re-orienting connections that
> have an associated state? (eg are "in use")
It might help. I just find the connection code scary:
- things seem a little too gung-ho when it comes to dereferencing
.st_connection and scribbling on the connection structure
(the most recent case I found was kernel*.c using struct connection .ipsec_mode)
- re-orienting involves creating and deleting connection instances and
that involves lots of global structures - BFL
So anything that straightens up our story for when/where/what a
connection / state can be accessed.
On the other hand, there is hope:
- the combination of unpacking message details into 'md' (for instance
notify payload contents) and then letting the crypto helper access MD
seems to work well
- (in theory) the crypto helpers can log to whack; they just aren't
allowed to use the global whack handle (which I'm trying to kill it)
We might want to start small - IKE SA INIT responder but even there
we've code instantiating and then scribbling on the connection. My pet
idea is to not bother instantiating a connection instance (but that
too is likely hairy).
More information about the Swan-dev