When doing a rekey for a CHILD_SA, the use counters get reset. An inactivity
job is queued for a time unrelated to the rekey time, so it might happen
that the inactivity job gets executed just after rekeying. If this happens,
inactivity is detected even if we had traffic on the rekeyed CHILD_SA just
before rekeying.
This change implies that inactivity checks can't handle inactivity timeouts
for rekeyed CHILD_SAs, and therefore requires that inactivity timeout is shorter
than the rekey time to have any effect.
This avoids race conditions between calls to cancel() and jobs that like
to be rescheduled. If jobs were able to reschedule themselves it would
theoretically be possible that two worker threads have the same job
assigned (the one currently executing the job and the one executing the
same but rescheduled job if it already is time to execute it), this means
that cancel() could be called twice for that job.
Creating a new job based on the current one and reschedule that is also
OK, but rescheduling itself is more efficient for jobs that need to be
executed often.
Jobs are now destroyed by the processor, but they are allowed to
reschedule themselves. That is, parts of the reschedule functionality
already provided by callback_job_t is moved to the processor. Not yet
fully supported is JOB_REQUEUE_DIRECT and canceling jobs.
Note: job_t.destroy() is now called not only for queued jobs but also
after execution or cancellation of jobs. job_t.status can be used to
decide what to do in said method.
Martin Willi