>Nothing that complex needs to be done.  Simply keep a context in the pcb
>and use PRU_RCVD.  When you receive SADB_DUMP, set a flag indicating a
>dump requested.  If so_rcv.sb_mb == NULL, then place the first record 
>into
>the so_rcv, and set a flag indicating dump in progress (clear dump
>requested) and that you are at record #1.  If so_rcv.sb_mb != NULL,
>wait until the usrreq is called with PRU_RCVD and sb_mb == NULL, then
>set the dump-in-progress flag and put the first record into so_rcv and
>set context to record #1.  The next time PRU_RCVD is called, check
>dump-in-progress and grab the next record and advance the record 
>counter.
>If no record, clear the dump-in-progress flag.


I fear this will'd break the existing apps, which depend on the
SADB_DUMP responses to a given SADB_DUMP request being implicitly
atomic; and that the responses are never being interleaved with other
messages (such as a kernel-generated ACQUIRE).  For an example, see
the loop in racoon/pfkey.c:pfkey_dump_sadb().

Deleting an SA partway through the walk could also cause duplication
of SAs; which may be problematic. The other downsides are obvious
(naive counter approach make SADB_DUMP dump O(n^2); or checking all
PK_KEY sockets for partially-complete SADB_DUMPs, and updating cursors
accordingly).  At some point we might as well just copy the whole
sadb, hand it back piecemeal via PRU_RCVD, and serialize all processes
doing dump requests to limit the memory footprint.

Right now I need more coffee (or more sleep).  I'll look at your new
suggestion over the weekend, and see how far I can get with it.