Date: Fri, 15 Jul 2016 15:33:40 +0200 From: Hans Petter Selasky <hps@selasky.org> To: Gleb Smirnoff <glebius@FreeBSD.org>, Matthew Macy <mmacy@nextbsd.org> Cc: "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: <ec468dba-dce4-5989-0882-6337ad466721@selasky.org> In-Reply-To: <20160715084303.GD1076@FreeBSD.org> References: <155eca8bae0.d811ff9b567670.7363072028299444677@nextbsd.org> <087a20a1-2b8b-2050-c75f-78aac964b457@selasky.org> <155ecfa7c59.b552d7c5570767.4742594321655958557@nextbsd.org> <20160715084303.GD1076@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 07/15/16 10:43, Gleb Smirnoff wrote:
> 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.
>
Hi,
Can you explain this a bit more Gleb? Can't user-space tools like
"route" delete LLE entries at _any_ time?
From what I can see, there is nothing preventing
"nd6_llinfo_settimer_locked()" running concurrently with
"nd6_llinfo_timer()". Even though the delay is in the hz range, this
doesn't prevent the race I'm pointing at.
And what about the pending check in "kern/subr_taskqueue.c"?
Won't it be off-by one in case the callout is scheduled when it is being
serviced?
pending = !!(callout_stop(&timeout_task->c) > 0);
How this cannot happen?
--HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ec468dba-dce4-5989-0882-6337ad466721>