Date: Fri, 8 Jun 2018 11:40:37 -0400 From: "Jonathan T. Looney" <jtl@freebsd.org> To: David Wolfskill <david@catwhisker.org>, FreeBSD Current <current@freebsd.org>, Mateusz Guzik <mjg@freebsd.org> Subject: Re: Panic from ipfw_alloc_rule() after r334769 -> r334832 Message-ID: <CADrOrmvMKmN8JhjUgSZdb1tZT7YhrXN0ELC3ODCiOb0AM5giDA@mail.gmail.com> In-Reply-To: <CADrOrmuaVhk1nnxV74mj-%2BmhRmGUBcPE7Xw3h52=z7itvuAcMQ@mail.gmail.com> References: <20180608133836.GM1389@albert.catwhisker.org> <CADrOrmuaVhk1nnxV74mj-%2BmhRmGUBcPE7Xw3h52=z7itvuAcMQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jun 8, 2018 at 10:52 AM, Jonathan T. Looney <jtl@freebsd.org> wrote: > > On Fri, Jun 8, 2018 at 9:38 AM, David Wolfskill <david@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADrOrmvMKmN8JhjUgSZdb1tZT7YhrXN0ELC3ODCiOb0AM5giDA>