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> > 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> 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.
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
pending = !!(callout_stop(&timeout_task->c) > 0);
How this cannot happen?
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"