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:
parent
0f5e7edc14
commit
d75efebeab
@ -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 :(
|
||||
|
Loading…
x
Reference in New Issue
Block a user