Re: callout_drain either broken or man page needs updating

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