Re: Panic from ipfw_alloc_rule() after r334769 -> r334832

From: Jonathan T. Looney <jtl_at_freebsd.org>
Date: Fri, 8 Jun 2018 11:40:37 -0400
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_at_ 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
Received on Fri Jun 08 2018 - 13:40:46 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:16 UTC