From owner-freebsd-current@freebsd.org Fri Jun 8 15:54:06 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 767B4101E6E3 for ; Fri, 8 Jun 2018 15:54:06 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id F3BEF688B7 for ; Fri, 8 Jun 2018 15:54:05 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id B7632101E6E1; Fri, 8 Jun 2018 15:54:05 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94FC4101E6E0 for ; Fri, 8 Jun 2018 15:54:05 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 14C98688B4; Fri, 8 Jun 2018 15:54:05 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-qt0-x22d.google.com with SMTP id s9-v6so13898908qtg.2; Fri, 08 Jun 2018 08:54:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g9Qz3QfzRZtxVfTmBYik00YuD5SsnCbQaxeH84wg0pA=; b=mAktZHmnSVJZJuBw4BqAYRPu8HAdU8fFei0zSzTrU7JggRCcqktvlJedyMFEwc40T6 n4KE/t1iyb3npF8jkFu8UJ1LH4eP0GF+AI6rsOhq6pTgJr6+yfs3lJiQL/am+hS4k8zi S+LcJ1s4bmwQ1F3GMRmyGdM4vVqn1f/pCi3imm1NJYNk8bOYUwkwBeanhHz7JGDYSxTB pjW6Kx2OfIFANjthuPXoJJMMsXFCd6MDFyMq2Rn2PcnhkrIHi7sulhYD5C0D1FwiZ62P oy0LooKYgNfTbTRYif2fYi7/Mrt4Q+y5u0VURIcURtBHmvgQRuKNNz7OvpZMpqJ0qwnJ wWmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=g9Qz3QfzRZtxVfTmBYik00YuD5SsnCbQaxeH84wg0pA=; b=Ljcs3U13BZD/mKfXOnSVRuu7v2YP74VC2KfhidMMSTSLM73hsajJ5ibdCTMUwu4/sz 8JbYWWbOIVpjL9LnSc3xlXbNXdL+81kOk6t3c38DPDVFeH0WRlFUlLmE+hS6+e1xXxJW d7ILv/8c5zOKzrajaGZ0C858pykiLysCM1S7Ds2AuEE6Szfj7DDb+iD78KNcExH66E3G oOaocAf3D7DxrMTmup1HIQWEu+CKp6pc67oGV+H9tpvTk5fcRm2ma+6gL/op0UqVB3+p ItM4VtOmdDjJHVh6Ot2AMerpnF61F3sj1DQFeN1Xjx0KyixNv6Co0cats4/WSiiSj79E ByQQ== X-Gm-Message-State: APt69E38g0WMSvLxSKmeKRSNRSaM3gyIm910otpJ85AhKEfTgR9yh6vb 6VHGShl8rhkrYTIR9ZB0GMkyHotTG5lqtCLfXyC3wQ== X-Google-Smtp-Source: ADUXVKInzDKrdA9mla+PH1VxPYAZW4Pgyc/GzllBxv4+WnY70ekf9a6WgrsOO+b2QaJSPy83kBZKQUaWhQzf3YPhWjg= X-Received: by 2002:ac8:358a:: with SMTP id k10-v6mr6286346qtb.248.1528473244501; Fri, 08 Jun 2018 08:54:04 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:1c4e:0:0:0:0:0 with HTTP; Fri, 8 Jun 2018 08:54:03 -0700 (PDT) In-Reply-To: References: <20180608133836.GM1389@albert.catwhisker.org> From: Mateusz Guzik Date: Fri, 8 Jun 2018 17:54:03 +0200 Message-ID: Subject: Re: Panic from ipfw_alloc_rule() after r334769 -> r334832 To: "Jonathan T. Looney" Cc: David Wolfskill , FreeBSD Current , Mateusz Guzik Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 15:54:06 -0000 weird, my grep-fu failed me hardcore i guess. Will fix shortly. On Fri, Jun 8, 2018 at 5:40 PM, Jonathan T. Looney wrote: > On Fri, Jun 8, 2018 at 10:52 AM, Jonathan T. Looney > wrote: > > > > On Fri, Jun 8, 2018 at 9:38 AM, David Wolfskill > 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