linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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!

             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).