Date: Fri, 8 Jul 2016 21:27:00 -0400 From: Alexander Kabaev <kabaev@gmail.com> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r302350 - in head: share/man/man9 sys/kern sys/sys Message-ID: <20160708212700.23c870ef@kan> In-Reply-To: <201607051847.u65IlIYf000901@repo.freebsd.org> References: <201607051847.u65IlIYf000901@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/jur74YpWMTnfvmTEPLvJtsk Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 5 Jul 2016 18:47:18 +0000 (UTC) Gleb Smirnoff <glebius@FreeBSD.org> wrote: > Author: glebius > Date: Tue Jul 5 18:47:17 2016 > New Revision: 302350 > URL: https://svnweb.freebsd.org/changeset/base/302350 >=20 > Log: > The paradigm of a callout is that it has three consequent states: > not scheduled -> scheduled -> running -> not scheduled. The API and > the manual page assume that, some comments in the code assume that, > and looks like some contributors to the code also did. The problem is > that this paradigm isn't true. A callout can be scheduled and running > at the same time, which makes API description ambigouous. In such > case callout_stop() family of functions/macros should return 1 and 0 > at the same time, since it successfully unscheduled future callout > but the current one is running. Before this change we returned 1 in > such a case, with an exception that if running callout was migrating > we returned 0, unless CS_MIGRBLOCK was specified. > =20 > With this change, we now return 0 in case if future callout was > unscheduled, but another one is still in action, indicating to API > users that resources are not yet safe to be freed. > =20 > However, the sleepqueue code relies on getting 1 return code in > that case, and there already was CS_MIGRBLOCK flag, that covered one > of the edge cases. In the new return path we will also use this flag, > to keep sleepqueue safe.=20 > Since the flag CS_MIGRBLOCK doesn't block migration and now isn't > limited to migration edge case, rename it to CS_EXECUTING. > =20 > This change fixes panics on a high loaded TCP server. > =20 > Reviewed by: jch, hselasky, rrs, kib > Approved by: re (gjb) > Differential Revision: https://reviews.freebsd.org/D7042 >=20 Hi, this change also breaks ARP reliably in my nfsroot setup for multiple MIPS board. The cause is following: before this change, the sequence of calls: callout_init(&la->lle_timer, 1); ret =3D callout_stop(&ls->lle_timer); would result in ret =3D=3D -1 after the change, same sequence causes callout_stop to return 1. This does not bode well for lle entries that were allocated, but for which callout_reset was never called, because we have several constructs in the source tree that do something like if (callout_stop(&lle->lle_timer) > 0) LLE_REMREF(lle); This results in panics as described in: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210884 --=20 Alexander Kabaev --Sig_/jur74YpWMTnfvmTEPLvJtsk Content-Type: application/pgp-signature Content-Description: Цифровая подпись OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXgFLlXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDNUY3RDk5NTk5QjY0MUUxM0M1MTU2OTEw NzEzMjI5OTkyNzkyRTdFAAoJEAcTIpmSeS5+5RMQAMkElhWV+PiSKMvWfiUuLjUi XsNW30X8Pnp+/9BPM7uRfyVE2G9I4ZLjMuWk/AVvvPdGCMEgVxoyY9omhF4MsdW0 hh5DtTF53XxnK2hWjO9n/aAxOGm5aEOX5amb1/VGhZYIuyxWbq0FdM+voh2dYBTZ 5UPq5MnJ1JyluTdzX8nlIXLpj2/ho4bdvi4PVCCrVVp3KNyQ5MHPnso7E9557rEP JjTw/r1VhuZQVo+bEZADFem1XBUlw2hl8XSNze9rC73Yv5Mzog3KTvXCDYNnKNvX nHkLFEzi+5wHGwnRl1M30/RSjj9IxKbAJ9Q+k+EqPPCsIuh/r+GPQX5fJkAPuXrt SbXsQpRDAB0FL8uPz/U41TXqAJZZ5NM1PAytyrJieyLY3yey/Qf48enkx8fh3XFD nEcCsBNqaMrIlP7lEkRtCpUy3Vl6rWtpuXbXlBZGs0votvioWsV/BE1jJCgku6mT 1ArH6wy3P7EtTHD6qS/V0h4LQZKzaqp5GiwU3T/K9GFTcez6SmsJuS/o2hsAqou5 hXhZU0iZBf0yeN8dQxiCvZeidROxqWy9W7R6K0Yhc06XOIOMKSs+W8dbQW2XdKfV N91znJ1DnY1aLTfLUbK7HK708Kr8p/nFiYd9nWnhvt8ZsWgFSzNtK7UlcTBSnzd5 NWwPikMro836MdHzZF1V =MWjQ -----END PGP SIGNATURE----- --Sig_/jur74YpWMTnfvmTEPLvJtsk--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160708212700.23c870ef>