On 7/18/23 5:50?PM, Dave Chinner wrote:
>> @@ -167,6 +172,25 @@ void iomap_dio_bio_end_io(struct bio *bio)
>> } else if ((dio->flags & IOMAP_DIO_INLINE_COMP) && in_task()) {
>> WRITE_ONCE(dio->iocb->private, NULL);
>> iomap_dio_complete_work(&dio->aio.work);
>> + } else if ((dio->flags & IOMAP_DIO_INLINE_COMP) &&
>> + (iocb->ki_flags & IOCB_DIO_DEFER)) {
>> + /* only polled IO cares about private cleared */
>> + iocb->private = dio;
>> + iocb->dio_complete = iomap_dio_deferred_complete;
>> + /*
>> + * Invoke ->ki_complete() directly. We've assigned
>> + * out dio_complete callback handler, and since the
>> + * issuer set IOCB_DIO_DEFER, we know their
>> + * ki_complete handler will notice ->dio_complete
>> + * being set and will defer calling that handler
>> + * until it can be done from a safe task context.
>> + *
>> + * Note that the 'res' being passed in here is
>> + * not important for this case. The actual completion
>> + * value of the request will be gotten from dio_complete
>> + * when that is run by the issuer.
>> + */
>> + iocb->ki_complete(iocb, 0);
>> } else {
>> struct inode *inode = file_inode(iocb->ki_filp);
>>
>
> Hmmm. No problems with the change, but all the special cases is
> making the completion function a bit of a mess.
>
> Given that all read DIOs use inline completions, we can largely
> simplify the completion down to just looking at
> dio->wait_for_completion and IOMAP_DIO_COMPLETE_INLINE, and not
> caring about what type of IO is being completed at all.
>
> Hence I think that at the end of this series, the completion
> function should look something like this:
I took inspiration from this as I think it's a good idea, and did a few
cleanups and introduced things like the above as we go. It's in v3 I
just posted.
--
Jens Axboe
