On Mon, Aug 18, 2014 at 01:33:05PM -0400, Jeff Moyer wrote: > Benjamin LaHaise <bcrl@xxxxxxxxx> 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 from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
