Hello,
On Fri, Jun 09, 2017 at 01:11:01PM +0200, Alexander Bluhm wrote: > 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@ > I still would like to ask Hrvoje to give it a try first. I believe the fix should work, but I could not try it as I don't have working pfsync set up available for testing. thanks and regards sasha > > > > 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<--------
