On Fri, Jun 09, 2017 at 10:55:46AM +0200, Alexandr Nedvedicky wrote: > would it make sense to commit a poor man's solution below, before pfsync(4) > will get to shape? The idea is to grab PF_LOCK, just before we pass the data > to PF for further processing.
Whatever helps to make progress with pf is fine. We should not delay unlocking pf until someone steps in and refactors pfsync. OK bluhm@ > > regards > sasha > > --------8<---------------8<---------------8<------------------8<-------- > --- src/sys/net/if_pfsync.c Fri Jun 09 09:40:12 2017 +0200 > > +++ src/sys/net/if_pfsync.c Fri Jun 09 10:49:44 2017 +0200 > > @@ -657,6 +657,7 @@ pfsync_input(struct mbuf **mp, int *offp > > struct pfsync_header *ph; > struct pfsync_subheader subh; > int offset, noff, len, count, mlen, flags = 0; > > + int e; > > pfsyncstat_inc(pfsyncs_ipackets); > > @@ -733,8 +734,11 @@ pfsync_input(struct mbuf **mp, int *offp > > return IPPROTO_DONE; > } > > - if (pfsync_acts[subh.action].in(n->m_data + noff, > > - mlen, count, flags) != 0) > + PF_LOCK(); > + e = pfsync_acts[subh.action].in(n->m_data + noff, mlen, > count, > + flags); > + PF_UNLOCK(); > + if (e != 0) > goto done; > > offset += mlen * count; > --------8<---------------8<---------------8<------------------8<--------
