pfr_commit_ktable calls functions that can result in the current
ktable being destroyed, which makes it unsafe in a SLIST_FOREACH.

I haven't had a chance to identify which path is taken in this case
which results in this happening, but I have instrumented this loop
and pfr_destroy_ktable and confirmed that a path exists that 
results in pfr_destroy_ktable being called on the active slist 
member with flushaddr set to 1 - resulting in a pool_put and
then a panic when it is reused.

Protect against this by not using SLIST_FOREACH, just like in 
my previous patch.

Chris Pascoe
2004/06/16

Index: pf_table.c
===================================================================
RCS file: /cvs/src/sys/net/pf_table.c,v
retrieving revision 1.56
diff -u -r1.56 pf_table.c
--- pf_table.c	11 Jun 2004 05:21:20 -0000	1.56
+++ pf_table.c	16 Jun 2004 11:23:15 -0000
@@ -1564,7 +1564,7 @@
 pfr_ina_commit(struct pfr_table *trs, u_int32_t ticket, int *nadd,
     int *nchange, int flags)
 {
-	struct pfr_ktable	*p;
+	struct pfr_ktable	*p, *q;
 	struct pfr_ktableworkq	 workq;
 	struct pf_ruleset	*rs;
 	int			 s, xadd = 0, xchange = 0;
@@ -1590,8 +1590,10 @@
 	if (!(flags & PFR_FLAG_DUMMY)) {
 		if (flags & PFR_FLAG_ATOMIC)
 			s = splsoftnet();
-		SLIST_FOREACH(p, &workq, pfrkt_workq)
+		for (p = SLIST_FIRST(&workq); p != NULL; p = q) {
+			q = SLIST_NEXT(p, pfrkt_workq);
 			pfr_commit_ktable(p, tzero);
+		}
 		if (flags & PFR_FLAG_ATOMIC)
 			splx(s);
 		rs->topen = 0;