It may happen that pfsync holds the last reference on a state. In this

case keys had already been freed. If encountering such state, then
just release last reference.

Not sure this can happen as a runtime race, but can be reproduced by
the following scenario:

- enable pfsync
- disable pfsync
- wait some time
- enable pfsync
This commit is contained in:
Gleb Smirnoff 2012-11-07 07:30:40 +00:00
parent 0f5e7edc14
commit d75efebeab

View File

@ -1545,6 +1545,16 @@ pfsync_sendout(int schedswi)
KASSERT(st->sync_state == q,
("%s: st->sync_state == q",
__func__));
if (st->timeout == PFTM_UNLINKED) {
/*
* This happens if pfsync was once
* stopped, and then re-enabled
* after long time. Theoretically
* may happen at usual runtime, too.
*/
pf_release_state(st);
continue;
}
/*
* XXXGL: some of write methods do unlocked reads
* of state data :(