bridge_pfil: m_pullup failed

[Cédric Berger]

Gergo Szakal wrote:

Matthew Dillon wrote:
    My guess is that they were bogus packets generated from a particular
    source, either accidently or intentionally corrupted packets.
Think you should mark this irreproducible or so, if there are no such 
messages within a few days.
Sorry for the suggestion, but could it be bad hardware?

I'm saying that because of the pfr_update_stats problem
that you also have. This assertion mean the following:
1) you've a block rule with table.

 table foo { 127/8 10/8 127/12 192.168 }
 block on $ext_if from <foo>
2) a packet like 10.0.0.1 arrive on ext_if.

3) PF select the block rule, and drop the packet

4) PF call pfr_update_stats, to increase the packet
   counter of the selected block, in that case 10/8.
5) For some reason, the packet does NOT fine any
   matching block, as if 10/8 has been removed from
   the table between step 3 and 4.
There could be 4 reasons to that actually:

a) Bug in PF. but other people should see that too.
   Are there other people still seeing that?
b) Race condition: incorrect locking in PF port to DFly
   causing table changes to occur in the midst of pf_test().
   But you say that you didn't change table content anyway.
c) Memory corruption due to bad hardware.

d) Memory corruption due to unrelated OS bug.

Cedric