Re: [PATCH 30/32] aio: add delayed cancel support

Christoph Hellwig [off-list ref] writes:

On Wed, Jan 10, 2018 at 06:26:39PM -0500, Jeff Moyer wrote:

quoted

quoted

quoted

The upcoming aio poll support would like to be able to complete the
iocb inline from the cancellation context, but that would cause
a lock order reversal.  Add support for optionally moving the cancelation
outside the context lock to avoid this reversal.

Signed-off-by: Christoph Hellwig <hch@lst.de>

Acked-by: Jeff Moyer <redacted>

Actually, let's move these two defines:

#define AIO_IOCB_DELAYED_CANCEL (1 << 0)
#define AIO_IOCB_CANCELLED      (1 << 1)

to include/linux/aio.h so that drivers outside of fs/aio.c can make use
of them.

struct aio_kiocb is private to aio.c, so just exposing them won't
do anything useful.  If we really need these elsewhere we'll need
to come up with a proper interface.

Duh, good point.  My main concern is that things like usb gadget will
have to deal with races between cancellation and completion on their
own.  It would be nice if we had infrastructure for them to use.  I'll
have a look through that code to see if there's something we could or
should be doing.

Cheers,
Jeff

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

On Thu, Jan 11, 2018 at 10:27:05AM -0500, Jeff Moyer wrote:

Duh, good point.  My main concern is that things like usb gadget will
have to deal with races between cancellation and completion on their
own.  It would be nice if we had infrastructure for them to use.  I'll
have a look through that code to see if there's something we could or
should be doing.

The current cancel interface is a bit of a mess, as it assumes the
kiocb is embedded into an aio_kiocb.  I think it would need a major
rework in general, but I'll need to fix a couple other aio issues
first.