Date: Tue, 3 Nov 2015 13:10:01 -0800 From: David Wolfskill <david@catwhisker.org> To: "Alexander V. Chernikov" <melifaro@freebsd.org>, "ipfw@freebsd.org" <ipfw@freebsd.org>, "current@freebsd.org" <current@freebsd.org>, "net@freebsd.org" <net@freebsd.org> Subject: Re: panic: refcount inconsistency: found: 0 total: 1 Message-ID: <20151103211001.GT21127@albert.catwhisker.org> In-Reply-To: <20151103163952.GP21127@albert.catwhisker.org> References: <20151103140436.GJ21127@albert.catwhisker.org> <693401446563735@web30h.yandex.ru> <20151103163952.GP21127@albert.catwhisker.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--lpUp1egui7PDlNtH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Nov 03, 2015 at 08:39:52AM -0800, David Wolfskill wrote:
> On Tue, Nov 03, 2015 at 06:15:35PM +0300, Alexander V. Chernikov wrote:
> > ...
> > > I tried booting it, and during the transition to multi-user mode,
> > > once ipfw was being invoked, I got the above-cited panic. Circumventi=
on
> > > was to leave it disconnected from a network (turn off the WiFi
> > > switch, in my case), so we don't get a chance to use the network.
> > It is most probably related with r290334. Would you mind reverting it a=
nd checking if ipfw works correctly ?
> > ....
>=20
> ... [Reverting r290334 gets things working again -- dhw]
>=20
> at a *guess*, we'll need a bit more effort to keep "found" and
> "ci->object_opcodes" in sync, at least by the time the KASSERT on
> src/sys/netpfil/ipfw/ip_fw_table.c:3395 looks at the values.
> ...
So... looking at the code a bit (and bearing in mind that I still am
unfamiliar with said code, and I hack more than I "write" code)...
here's the original bit of src/sys/netpfil/ipfw/ip_fw_table.c in
question, with the modification from r290334 shown:
=2E..
/*
* Finds and bumps refcount for objects referenced by given @rule.
* Auto-creates non-existing tables.
* Fills in @oib array with userland/kernel indexes.
*
* Returns 0 on success.
*/
static int
ref_rule_objects(struct ip_fw_chain *ch, struct ip_fw *rule,
struct rule_check_info *ci, struct obj_idx *oib, struct tid_info
*ti)
{
=2E..
if (error !=3D 0) {
/* Unref everything we have already done */
unref_oib_objects(ch, rule->cmd, oib, pidx);
IPFW_UH_WUNLOCK(ch);
return (error);
}
IPFW_UH_WUNLOCK(ch);
found =3D pidx - oib;
KASSERT(found =3D=3D ci->object_opcodes,
("refcount inconsistency: found: %d total: %d",
found, ci->object_opcodes));
=20
/* Perform auto-creation for non-existing objects */
if (numnew !=3D 0)
error =3D create_objects_compat(ch, rule->cmd, oib, pidx, t=
i);
=20
+ /* Calculate real number of dynamic objects */
+ ci->object_opcodes =3D (uint16_t)(pidx - oib);
+
return (error);
}
=2E..
The added code to "Calculate real number of dynamic objects" is
apparently setting ci->object_opcodes to the same value that "found" was
just set to (pidx - oib -- cast to uint16_t in the case of the added
code).
But that appears to come a bit late for the KASSERT.
Moving the KASSERT relative to the added code (so the KASSERT comes
after) would be an option, but I'm not sure it makes sense to
actually do the KASSERT unless we have some reason to believe that
the difference between pidx and oib might change in the interval
represented by a couple lines of code AND we have not coded to
handle that situation any more "gracefully" than to panic.
So... with the change from r290334, what's the point of the KASSERT?
Peace,
david
--=20
David H. Wolfskill david@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous coward=
s.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
--lpUp1egui7PDlNtH
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQJ8BAEBCgBmBQJWOSKpXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4
QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7M3QP/RwN2RNOPwqO6jVxTs4fJa5e
Z+53TPcDIL1EAtGS9/s5ENOduCEFFbDH/4rBg7HhP7mtRtpucWINRcel8/XF/ydU
hRy+NAr/IncpTU/wWuq+af0FpwPiBWERSK92mneWoihrgpGyeDAYRhYftbkg9OkE
OKlVYvXnZt6KPciC1ib6JZXvKKrQMKROHrjNmjnMUQe+q1ZuqvuW5oikTB8yesJa
1zQqUMDFdenIrzVv/9nINbCjAZtVNhdbsSfg2OfEnv6WpZE12DJkIKKlNvOH8w5n
cfrfLeaAvHHif/CUUb8NO15E8D0GdXmDkAUUKi82BEldB337o6lbxWOffBlAym2L
iY2Z0FUiUgCo04FMMlARKBu1ipuWMUSB6H4D15r28bdCXQWiprpT7fSZiBTph5jv
fJnu/mkxTEZfsste7JfJJkGPG8EOEY2QhnYeDkdyvrDvXcDUHeuSySPHcea3SW1B
t7w2gvjONqmInQ/pD3pF1N5BD8pNKPu6qIfFujNrl/TDBdsihjYNcZIn4VwfM5KU
gocdPXhusTjbzO/BkWXqs1SddcZtrQHnY6WZKmKK5tusQuhujOlmy+NJlx6ZjU8A
fY07aYdRouIbu2MUPbrCeeyNY/axh3NTPZXnA8U3goUbHtGMqijTUxBhiWYzNOPG
VEg8C/HMAia4t4HrsEGV
=B1g6
-----END PGP SIGNATURE-----
--lpUp1egui7PDlNtH--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151103211001.GT21127>