Re: [PATCH v4 1/2] fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio

[Jens Axboe <axboe@kernel.dk>]

On 3/5/24 1:43 PM, Bart Van Assche wrote:
> On 3/4/24 12:21, Jens Axboe wrote:
>> On 3/4/24 12:43 PM, Bart Van Assche wrote:
>>> As far as I know no Linux user space interface for submitting I/O
>>> supports cancellation of read or write requests other than the AIO
>>> io_cancel() system call.
>>
>> Not true, see previous reply (on both points in this email). The kernel
>> in general does not support cancelation of regular file/storage IO that
>> has submitted. That includes aio. There are many reasons for this.
>>
>> For anything but that, you can most certainly cancel inflight IO with
>> io_uring, be it to a socket, pipe, whatever.
>>
>> The problem here isn't that only aio supports cancelations, it's that
>> the code to do so is a bad hack.
> 
> What I meant is that the AIO code is the only code I know of that
> supports cancelling I/O from user space after the I/O has been submitted
> to the driver that will process the I/O request (e.g. a USB driver). Is

Right, we never offered that in general in the kernel. Like I said, it's
just a hack what is there for that.

> my understanding correct that io_uring cancellation involves setting the
> IO_WQ_WORK_CANCEL flag and also that that flag is ignored by
> io_wq_submit_work() after io_assign_file() has been called?

No, that's only for requests that go via io-wq, which is generally not
the fast path and most workloads will never see that.

For anything else, cancelation can very much happen at any time.

> The AIO code
> supports cancelling I/O after call_read_iter() or call_write_iter() has
> been called.

...for the above hacky case, and that's it, not as a generic thing.

-- 
Jens Axboe