summaryrefslogtreecommitdiffstats
path: root/usr.bin/diff/diff.c
diff options
context:
space:
mode:
authorhenning <henning@openbsd.org>2003-06-27 11:38:23 +0000
committerhenning <henning@openbsd.org>2003-06-27 11:38:23 +0000
commit3670ecce04673ec40a1912dfe7d3590260e58a5c (patch)
tree3b735676b0b1d8e1166f6039ae3fc70b5873b309 /usr.bin/diff/diff.c
parentno more kerberos IV, PR3335 (diff)
downloadwireguard-openbsd-3670ecce04673ec40a1912dfe7d3590260e58a5c.tar.xz
wireguard-openbsd-3670ecce04673ec40a1912dfe7d3590260e58a5c.zip
move down pf_tag_unref() calls in pf_rm_rule() to after the check wetehr there
are still states for the given rule existant. based on a very nice analysis from cedric@, that is so completely right that I have nothing to add: in pf_rm_rule(), the pf_tag_unref() calls are done *before* the if (rule->states > 0 || rule->entries.tqe_prev != NULL) test. That mean that the two pf_tag_unref() calls could occur *twice* for a given rule: first when the rule is removed from the ruleset and (if the rule was kept around because of a state) a second time when the state refcount drops to zero and the rule gets really deleted. Unless I'm mistaken, that breaks the refcounting. ...and cedric was not mistaken. and, as daniel pointed out: The breakage this causes is so subtle, I doubt anyone noticed it before, if it did occur. consensus on this between cedric, dhartmei and myself
Diffstat (limited to 'usr.bin/diff/diff.c')
0 files changed, 0 insertions, 0 deletions