From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Moyer Subject: Re: io_cancel return value change Date: Mon, 18 Aug 2014 14:25:20 -0400 Message-ID: References: <20140818144917.GB2590@kvack.org> <20140818181538.GD2590@kvack.org> Mime-Version: 1.0 Content-Type: text/plain Cc: Kent , Zach , linux-fsdevel@vger.kernel.org, linux-aio@kvack.org To: Benjamin LaHaise Return-path: Received: from mx1.redhat.com ([209.132.183.28]:5989 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751676AbaHRSZ2 (ORCPT ); Mon, 18 Aug 2014 14:25:28 -0400 In-Reply-To: <20140818181538.GD2590@kvack.org> (Benjamin LaHaise's message of "Mon, 18 Aug 2014 14:15:38 -0400") Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Benjamin LaHaise writes: > 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. Sorry, Ben, Zach just pointed out what I was so obviously missing. From the changelog: This gets rid of the unused io_event argument to kiocb_cancel() and kiocb->ki_cancel(), and changes io_cancel() to return -EINPROGRESS if kiocb->ki_cancel() returned success. Somehow I managed to skip right over that change to return -EINPROGRESS. *facepalm* Cheers, Jeff