Subject: Re: Problems with PF_KEY SADB_DUMP
To: Matt Thomas <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 09/19/2003 19:03:46
>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
>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
>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.