From owner-freebsd-current@freebsd.org Sun Aug 30 19:10:13 2015 Return-Path: Delivered-To: freebsd-current@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 ACB9F9C4068 for ; Sun, 30 Aug 2015 19:10:13 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id F2F1D8E2 for ; Sun, 30 Aug 2015 19:10:12 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA13218; Sun, 30 Aug 2015 22:10:11 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1ZW7zW-0002dc-Ns; Sun, 30 Aug 2015 22:10:10 +0300 Subject: Re: panic: Stray timeout To: Konstantin Belousov References: <55E2DA91.6080206@FreeBSD.org> <20150830161603.GI2072@kib.kiev.ua> Cc: FreeBSD Current From: Andriy Gapon Message-ID: <55E354DA.9030302@FreeBSD.org> Date: Sun, 30 Aug 2015 22:09:14 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150830161603.GI2072@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2015 19:10:13 -0000 On 30/08/2015 19:16, Konstantin Belousov wrote: > This is strange, I do not think that could be a right explanation of this > issue. The taskqueue callout is initialized with the mutex, which means > that the callout_stop() caller > - must own the mutex; > - is synchronous with the callout. > In other words, callout cannot be running when taskqueue_cancel_timeout() > calls callout_stop(), it only can be dequeued but the callout function > is not yet called. If callout_stop() is performed meantime, between > dropping callout_cpu lock, and locking the mutex, it must be not run. Thank you for the explanation. I am not familiar with the code and I misinterpreted the manual page and thought that callout_stop() might be unable to stop the callout even if it was initialized with the mutex. I see my mistake now. -- Andriy Gapon