Date: Thu, 27 Aug 2015 18:28:03 +0200 From: Julien Charbon <jch@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, John Baldwin <jhb@freebsd.org> Subject: Re: svn commit: r286880 - head/sys/kern Message-ID: <55DF3A93.8080507@freebsd.org> In-Reply-To: <20150827104946.GH2072@kib.kiev.ua> References: <201508181015.t7IAFAex055889@repo.freebsd.org> <55DD69E5.4090904@selasky.org> <55DD74EB.30601@selasky.org> <55DE01F7.8040508@freebsd.org> <20150827104946.GH2072@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SVS6NPqis9EGM4UjCbJLup9A4J7fHAD6T Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Konstantin, On 27/08/15 12:49, Konstantin Belousov wrote: > On Wed, Aug 26, 2015 at 08:14:15PM +0200, Julien Charbon wrote: >> As I said, I am not opposed to back out this change, callout(9) API i= n >> mpsafe mode is a already complex/subtle API, it won't change too much >> the current complexity. >> >> Let say that if nobody screams until Friday 8/28, I will put back >> r284245 and revert this change _and_ I will make this case clear in th= e >> man page. >=20 > [Replying to a random message in the whole set of conversations] >=20 > There is one more case, besides TCP timers, which is equially, of not > more, critical and sensitive WRT to the callout_stop(). Look at the > sys/kern/subr_sleepqueue.c:sleepq_check_timeout(). Stray return of > the false result from callout_stop() causes creation of the non-killabl= e > processes: the callout fired, we missed the wakeup and went to sleep > by manually doing the context switch. Such thread cannot be woken up. >=20 > I suspect that your fix is a better approach than my attempt to look > at something similar at PR 200992 (may be not). This change (r286880) won't improve the PR 200992: r286880 only addresses a case where callout_stop() returns 1 instead of 0. Thus the only thing that can do r286880 to PR 200992: - Don't change anything the issues - Worsen the issue Sorry to kill your hope of a simple and elegant fix for PR 200992. -- Julien --SVS6NPqis9EGM4UjCbJLup9A4J7fHAD6T Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJV3zqZAAoJEKVlQ5Je6dhx8VIIAOHAgwFW0zb381yUbXDkyPmV EldTc+OgznnnB3MblbC0kyxBOI+rxgo1S0cOldzMNtiK+Cf2YYQDsRp6rwgu8aVg CgGsGAMXAsA3BCJvHzjb57JOOBRMVJ5Q5+qjpRykzOkDeaX9UXiF6m/XmKx79DMM 5+mDWz6GlJlnTRZN/iZrQAR2PdBR0ebpw2egSE+EXPmcwa5DApRY06hvSbTUNfYs XVblS7HYmCGzQw5Dz2VsSDoBXV3jrbYrrSZepIA/s9SB+ez0XbfKBQT8XAYXJg6g OJSn+0Ef+jgFRcGC+4h9RMUAga2MJH+EwjAr+l+Mq2OwI8Q5LKpQenkPC75z1B4= =HDgT -----END PGP SIGNATURE----- --SVS6NPqis9EGM4UjCbJLup9A4J7fHAD6T--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55DF3A93.8080507>