callout_stop() return value

[Konstantin Belousov]

On Wed, May 02, 2018 at 11:42:37AM -0400, Mark Johnston wrote:
> On Wed, May 02, 2018 at 09:34:57AM -0600, Ian Lepore wrote:
> > On Wed, 2018-05-02 at 11:20 -0400, Mark Johnston wrote:
> > > Hi,
> > > 
> > > We have a few pieces of code that follow a pattern: a thread
> > > allocates a
> > > resource and schedules a callout. The callout handler releases the
> > > resource and never reschedules itself. In the common case, a thread
> > > will cancel the callout before it executes. To know whether it must
> > > release the resource associated with the callout, this thread must
> > > know
> > > whether the pending callout was cancelled.
> > > 
> > 
> > It seems to me a better solution would be to track the state / lifetime
> > of the resource separately rather than trying to infer the state of the
> > resource from the state of the callout as viewed through a semi-opaque
> > interface.
> > 
> > If the original thread that schedules the callout keeps enough
> > information about the resource to free it after cancelling, then it is
> > already maintaining some kind of sideband info about the resource, even
> > if it's just a pointer to be freed. Couldn't the callout routine
> > manipulate this resource tracking info (null out the pointer or set a
> > bool or whatever), then after cancelling you don't really care whether
> > the callout ran or not, you just examine the pointer/bool/whatever and
> > free or not based on that.
> 
> I'd considered that. It's not quite as elegant a solution as you
> suggest, since in my case the resource is embedded in an opaque
> structure, so I need to add an extra field beside the callout to track
> state that's already tracked by the callout subsystem. That plus the
> fact that we have multiple instances of this bug make me want to fix it
> in a general way, though I recognize that the callout API is already
> overly complicated.

I gave up on trying to get this fixed.  r302350 was not the first time
the return value was broken.

I had to do r303426 exactly for this reason.