From owner-freebsd-net@freebsd.org Fri Jul 15 13:29:48 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A94FCB98AC5; Fri, 15 Jul 2016 13:29:48 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6BC621B7A; Fri, 15 Jul 2016 13:29:47 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 8FB591FE024; Fri, 15 Jul 2016 15:29:45 +0200 (CEST) Subject: Re: callout_drain either broken or man page needs updating To: Gleb Smirnoff , Matthew Macy References: <155eca8bae0.d811ff9b567670.7363072028299444677@nextbsd.org> <087a20a1-2b8b-2050-c75f-78aac964b457@selasky.org> <155ecfa7c59.b552d7c5570767.4742594321655958557@nextbsd.org> <20160715084303.GD1076@FreeBSD.org> Cc: "freebsd-current@freebsd.org" , "freebsd-net@freebsd.org" From: Hans Petter Selasky Message-ID: Date: Fri, 15 Jul 2016 15:33:40 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160715084303.GD1076@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 13:29:48 -0000 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