On Thu, Mar 1, 2018 at 5:45 AM, Joerg Sonnenberger <jo...@bec.de> 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 <jo...@bec.de> 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