Re: io_cancel return value change

[Benjamin LaHaise <bcrl@kvack.org>]

On Mon, Aug 18, 2014 at 01:33:05PM -0400, Jeff Moyer wrote:
> Benjamin LaHaise <bcrl@kvack.org> writes:
> 
> >> At the very least, you need to also include man page updates for this.
> >> Honestly, though, we should not have let this patch set go in as is.  If
> >
> > Yes, the man page needs to be updated, but this change in the API is 
> > backwards compatible.  The existing man page says that it returns 0 on 
> > sucess and returns an io_event -- anything other than a 0 return implies 
> > that a completion event will be returned later.  Cancellation has never 
> > provided a 100% guarantee that it will succeed without providing a 
> > completion event.
> 
> The man page states:
> 
>     If the AIO context is found, the event will be canceled and then
>     copied into the memory pointed to by result without being placed
>     into the completion queue.
> 
> That sounds pretty definitive to me.

Cancellation is inherently racy.  It is and always has been possible for 
an attempt at cancellation to fail, or for the attempt at cancellation to 
suceed in the bigger picture yet have the io_cancel() call fail (and cause 
an event to be delivered).  Applications always have and always will have 
to handle an io_cancel() call potentially failing with the kernel delivering 
a completion event.  You have to read the io_cancel() man page with that 
understanding in place.

> I have no doubt it works, Ben.  :)  My main concern is a change to the
> kernel<->user ABI.

As I said above: an application always has and always will have to handle 
the case where an io_cancel() returns failure.  An application that does 
handle an error return from io_cancel() is broken, as the condition can 
occur when the cancel races with the kernel calling aio_complete().

> I was not ignoring that at all.  We don't provide backwards
> compatibility for kernel modules, and the modules in-tree are changed
> when interfaces change.  I'm really only concerned about whether we
> think it matters that the kernel<->user ABI was changed.

And this change is ABI compatible.  Applications aren't being made to handle 
any failures they haven't already had to cope with.  If an application can't 
handle a transient io_cancel() failure, then the app is buggy and needs to 
be fixed since that condition can already occur when the cancel races with 
completion.

		-ben

> I think at some level we're talking past each other.  Hopefully I've
> clarified my questions.
> 
> Cheers,
> Jeff

-- 
"Thought is the essence of where you are now."

--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org.  For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>