Date: Fri, 15 Jul 2016 01:43:03 -0700 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Matthew Macy <mmacy@nextbsd.org> Cc: Hans Petter Selasky <hps@selasky.org>, "freebsd-current@freebsd.org" <freebsd-current@freebsd.org>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: callout_drain either broken or man page needs updating Message-ID: <20160715084303.GD1076@FreeBSD.org> In-Reply-To: <155ecfa7c59.b552d7c5570767.4742594321655958557@nextbsd.org> References: <155eca8bae0.d811ff9b567670.7363072028299444677@nextbsd.org> <087a20a1-2b8b-2050-c75f-78aac964b457@selasky.org> <155ecfa7c59.b552d7c5570767.4742594321655958557@nextbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 14, 2016 at 10:14:46PM -0700, Matthew Macy wrote: M> > On 07/15/16 05:45, Matthew Macy wrote: M> > > glebius last commit needs some further re-work. M> > M> > Glebius commit needs to be backed out, at least the API change that M> > changes the return value when calling callout_stop() when the callout is M> > scheduled and being serviced. Simply because there is code out there, M> > like Mattew and others have discovered that is "refcounting" on the M> > callout_reset() and expecting that a subsequent callout_stop() will M> > return 1 to "unref". M> M> Yes. This is the cause of the "refcnt 0 on LLE at boot..." regression. No it isn't. The regression is caused by unintentional change of return value for never scheduled callout. The fix is now being tested, see PR 210884. The piece of ND6 code that Hans quotes isn't affected by change of return value for scheduled+running callout, since ND6 doesn't create callouts in this tricky state. -- Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160715084303.GD1076>