[Swan-dev] Leaks when killing states during crypto; time to drop WIRE_*?

[Andrew Cagney]

On 5 December 2017 at 12:29, D. Hugh Redelmeier <hugh at mimosa.com> wrote:

> Clearly the main thread needs the MD most of the time.  But probably
> not during "suspension" of a state.  That's when the worker could have
> ownership.  I'm guessing that the only worker-access needed is for
> encryption/authentication of the packet itself.

Yes, the state transition code uses MD (as a parameter).  It doesn't
need to be stuffing it in st_suspended_md or conversely having state
stuffed into md.st.

> The original design of the continuation mechanism is that failure and
> success took the same path.  This seems surprising but it really cut
> down combinatorial explosion.
>
> It would be good if abort (death or assassination) used the same path.
> Then it is always the continuation that manages resources.
>
> When I added the continuation mechanism to pluto almost 20 years ago,
> the idea of continuation was not mainstream.  It has been hard for
> programmers to get their head around.  But in 2017 it ought to be in
> every programmer's toolkit.  Of course C doesn't help at all.
>
> We really need to cultivate simplicity.  One major part of that is
> cutting down code paths.  Especially untested ones.  Error-handling is
> generally the least exercised.
>
> The continuation mechanism could be replaced.  The obvious way would
> be to add substates (really: finer-grained states) to the state
> mechanism.  Currently state transitions are triggered by incoming
> packets.  Except for the anomaly of the initiator's first packet,
> every State Transition Function is invoked for an input packet aimed
> at that state.  Timeouts and whack commands can have effects on states
> too but don't invoke STFs.  We could add triggering for worker
> completion.  Everything currently held in any continuation would have
> to be stuck in struct state or reachable from it.  I'm guessing that
> the result might be easier to understand but it would be a lot of
> work.

My thoughts here depend on the day of the week.

My current hunch is to get pluto's responsiveness up, we'll be trying
to off-load more and more work.  That would mean that pretty much
every state transition will consist of:
       state->in-progress->new-state
while strictly speaking this should be implemented as separate states,
adding all the extra states will get so tedious and redundant that
we'll end up accepting the status quo.

However, one thing that I do think should go is that extra code path
handling STF_INLINE.  When there are no threads, use the event loop to
offload the work.

Andrew