Re: [PATCH v20 03/12] block: add copy offload support

[Christoph Hellwig <hch@lst.de>]

On Tue, Jun 04, 2024 at 10:50:26AM +0000, Nitesh Shetty wrote:
>>> +	if (!cio)
>>> +		return -ENOMEM;
>>> +	atomic_set(&cio->refcount, 1);
>>> +	cio->waiter = current;
>>> +	cio->endio = endio;
>>> +	cio->private = private;
>>
>> For the main use this could be allocated on-stack.  Is there any good
>> reason to not let callers that really want an async version to implement
>> the async behavior themselves using suitable helpers?
>>
> We cannot do on-stack allocation of cio as we use it in endio handler.
> cio will be used to track partial IO completion as well.
> Callers requiring async implementation would need to manage all this
> bookkeeping themselves, leading to duplication of code. We felt it is
> better to do it here onetime.
> Do you see it any differently ?

We don't really to these async variants for other in-kernel I/O,
so unless we have a really good reason I'd not do here.  The usual
approach is to just have a submission helper for async in-kernel
special bios types, and the let the caller handle the rest.