Re: Let callout_reset return if it reschedules a pending callout

[Ryota Ozaki <ozaki-r%netbsd.org@localhost>]

On Thu, Mar 1, 2018 at 5:45 AM, Joerg Sonnenberger <joerg%bec.de@localhost> wrote:
> On Thu, Mar 01, 2018 at 01:58:29AM +0900, Ryota Ozaki wrote:
>> On Wed, Feb 28, 2018 at 10:11 PM, Joerg Sonnenberger <joerg%bec.de@localhost> wrote:
>> > On Wed, Feb 28, 2018 at 05:47:13PM +0900, Ryota Ozaki wrote:
>> >> The feature is useful when you have a reference to an object that is
>> >> passed to a callout. In this case you need to take care of a
>> >> reference leak on callout_reset (and other APIs); it silently
>> >> reschedules (IOW cancels) a pending callout and leaks a reference.
>> >> Unfortunately callout_reset doesn't tell us the reschedule.
>> >
>> > Can we look at this part first before discussing any API changes?
>> > Why can't you store the reference next to callout instance itself?
>>
>> Oh, my explanation was quite confusing... I meant that the object
>> has a reference counter and the counter is incremented to indicate
>> that it is referred by a callout. obj_ref and obj_unref can be
>> thought as obj->refcnt++ and obj->refcnt-- respectively.
>
> Just consider the object reference owned by the callout struct. You
> change the reference count when the callout is destroyed or if the
> callout is reassigned, not because it is executed.

Oh, there is a limitation I didn't mention yet; we can't use callout_halt
to stop the callout when we try to destroy an obj because of the issue of
softnet_lock vs. callout_halt(*).

(*) http://mail-index.netbsd.org/tech-net/2018/01/12/msg006612.html

We can use only callout_stop that doesn't ensure if a callout stops
or not. It requires that we track the activity of the callout, which
is what a refcount does.

  ozaki-r