From owner-freebsd-net@freebsd.org  Thu Dec 10 15:33:22 2015
Return-Path: <owner-freebsd-net@freebsd.org>
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 C5D589D7E93;
 Thu, 10 Dec 2015 15:33:22 +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 8C9541294;
 Thu, 10 Dec 2015 15:33:21 +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 2C6B01FE023;
 Thu, 10 Dec 2015 16:33:20 +0100 (CET)
Subject: Re: panic in arptimer in r289937
To: Randall Stewart <rrs@netflix.com>
References: <CAJ-VmonvVyTNuYv_as41yPCFdfR5T3FE45DP9MKAc-eyzXzPUg@mail.gmail.com>
 <2739461446298483@web2h.yandex.ru>
 <CAJ-Vmo=JjHonDqOYK+JDaf9581dRU5_KoaSTnY27JnzQm0v56w@mail.gmail.com>
 <1733241446303675@web19h.yandex.ru> <5661EAAF.1010906@selasky.org>
 <5661EF10.8060300@selasky.org>
 <96B619F6-489C-4931-B306-1E1DE03F09B4@netflix.com>
Cc: "Alexander V. Chernikov" <melifaro@freebsd.org>,
 Adrian Chadd <adrian@freebsd.org>, freebsd-net <freebsd-net@freebsd.org>,
 freebsd-current <freebsd-current@freebsd.org>
From: Hans Petter Selasky <hps@selasky.org>
Message-ID: <56699BAD.9090208@selasky.org>
Date: Thu, 10 Dec 2015 16:35:09 +0100
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101
 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <96B619F6-489C-4931-B306-1E1DE03F09B4@netflix.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
 <mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
 <mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Dec 2015 15:33:22 -0000

On 12/10/15 16:25, Randall Stewart wrote:
> For callout_stop/drain you get
>
> -1 == Callout as already gone off or is not running (usually the latter) else the caller iks
>            not using locking properly or did not lock and check the active() value (which would have returned not active so no stop
>            would have been needed);
> 0 == we could not stop the callout, it was in process..
> 1 == it was stopped successfully
>
>
> For callout_reset() you get
>
> 0 == it was started
> 1 == it was restarted.
>
> There is no -1 since it is either started or restarted never left in a not-running state...
>

Hi,

Correct, though if the return values would be the same, it might 
simplify the callout API and manual page a bit:

/* return values for all callout_xxx() functions */
#define CALLOUT_RET_DRAINING    0 /* callout cannot be stopped, need 
drain */
#define CALLOUT_RET_CANCELLED   1 /* callout was successfully stopped */
#define CALLOUT_RET_STOPPED     -1 /* callout was already stopped */

Then callout_reset() would return -1, if it was started from the stopped 
state.

--HPS