Re: bridge_pfil: m_pullup failed

[Cédric Berger <cedric@xxxxxxxxx>]

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