Panic from ipfw_alloc_rule() after r334769 -> r334832

[Mateusz Guzik]

weird, my grep-fu failed me hardcore i guess.

Will fix shortly.

On Fri, Jun 8, 2018 at 5:40 PM, Jonathan T. Looney <jtl at freebsd.org> wrote:

> On Fri, Jun 8, 2018 at 10:52 AM, Jonathan T. Looney <jtl at freebsd.org>
> wrote:
> >
> > On Fri, Jun 8, 2018 at 9:38 AM, David Wolfskill <david at catwhisker.org>
> wrote:
> > >
> > > Sorry for lack of much analysis; am at BSDCan.  jtl@ suggested that a
> > > sequence of changes involving memory allocation and ipfw counters is
> > > likely to be at issue.
> >
> > Just to be clear, I speculated that this seemed like it could be caused
> by r334824.
> >
> > And, screen_1.jpg does indeed seem to point at that commit.
>
> Yes, it is clear that this is hitting r334824.
>
> V_ipfw_cntr_zone is defined with UMA_ZONE_PCPU.
>
> ipfw_alloc_rule() allocates from V_ipfw_cntr_zone with M_ZERO.
>
> That clearly violates the assertion added in r334824, as well as the
> assumption behind the commit: "Nothing in the tree uses it..."
>
> It seems like something will need to be changed here to resolve the
> mismatch in assumptions/expectations... :-/
>
> If anyone is hitting this bug and needs to get a working system in the
> meantime, you'll need to revert the following commits which implemented (or
> updated) this change:
>
> r334830
> r334829
> r334824
>
> Jonathan
>



-- 
Mateusz Guzik <mjguzik gmail.com>