From: Jeff Moyer <jmoyer@redhat.com>
To: Kent <kmo@daterainc.com>, Ben <bcrl@kvack.org>
Cc: Zach <zab@redhat.com>, linux-fsdevel@vger.kernel.org
Subject: io_cancel return value change
Date: Fri, 15 Aug 2014 15:27:53 -0400 [thread overview]
Message-ID: <x4938cxsgcm.fsf@segfault.boston.devel.redhat.com> (raw)
Hi, Kent,
Sorry to bring this up long after your patches have gone in--I am
remiss. In the following commit, you changed what was returned by the
io_cancel system call:
commit bec68faaf3ba74ed0dcd5dc3a881b30aec542973
Author: Kent Overstreet <koverstreet@google.com>
Date: Mon May 13 14:45:08 2013 -0700
aio: io_cancel() no longer returns the io_event
Originally, io_event() was documented to return the io_event if
cancellation succeeded - the io_event wouldn't be delivered via the ring
buffer like it normally would.
But this isn't what the implementation was actually doing; the only
driver implementing cancellation, the usb gadget code, never returned an
io_event in its cancel function. And aio_complete() was recently changed
to no longer suppress event delivery if the kiocb had been cancelled.
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.
Also tweak the refcounting in kiocb_cancel() to make more sense.
You made a passing reference to previous aio_complete changes as well
that I can't easily track down (it wasn't mentioned in the commit log
that I can tell, and it isn't obvious to me by looking through the patch
set).
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
any software actually wrote code to handle cancellation, this change
would surely cause confusion. That said, I think you got away with this
for two reasons:
1) no drivers implements a cancellation routine (except the crazy usb
gadgetfs thing)
2) userspace code may not even call io_cancel (who knows?), and if they
do, well, see point 1.
My preference would be for this behavior change to be reverted. You
could make a case for keeping the change and updating the
documentation. I'm not convinced 100% one way or the other. So what do
you (and others) think?
Cheers,
Jeff
p.s. I did do a quick google search, and the only caller of io_cancel I
could find was a test harness. But, that's certainly not proof that
nobody does it!
next reply other threads:[~2014-08-15 19:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-15 19:27 Jeff Moyer [this message]
2014-08-18 14:49 ` io_cancel return value change Benjamin LaHaise
2014-08-18 17:33 ` Jeff Moyer
2014-08-18 18:15 ` Benjamin LaHaise
2014-08-18 18:25 ` Jeff Moyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=x4938cxsgcm.fsf@segfault.boston.devel.redhat.com \
--to=jmoyer@redhat.com \
--cc=bcrl@kvack.org \
--cc=kmo@daterainc.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=zab@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).