bridge_pfil: m_pullup failed

Cédric Berger cedric at berger.to
Fri Nov 3 11:16:08 PST 2006


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





More information about the Bugs mailing list