Hi, Linus didn't particularly love the iov_iter->truncated addition and how it was used, and it was hard to disagree with that. Instead of relying on tracking ->truncated, add a few pieces of state so we can safely handle partial or errored read/write attempts (that we want to retry). Then we can get rid of the iov_iter addition, and at the same time handle cases that weren't handled correctly before. I've run this through vectored read/write with io_uring on the commonly problematic cases (dm and low depth SCSI device) which trigger these conditions often, and it seems to pass muster. I've also hacked in faked randomly short reads and that helped find on issue with double accounting. But it did validate the state handling otherwise. For a discussion on this topic, see the thread here: https://lore.kernel.org/linux-fsdevel/CAHk-=wiacKV4Gh-MYjteU0LwNBSGpWrK-Ov25HdqB1ewinrFPg@xxxxxxxxxxxxxx/ You can find these patches here: https://git.kernel.dk/cgit/linux-block/log/?h=iov_iter.3 Changes since v2: - Add comments on io_read() on the flow - Fix issue with rw->bytes_done being incremented too early and hence double accounting if we enter that bottom do {} while loop in io_read() - Restore iter at the bottom of do {} while loop in io_read() Changes since v1: - Drop 'did_bytes' from iov_iter_restore(). Only two cases in io_uring used it, and one of them had to be changed with v2. Better to just make the subsequent iov_iter_advance() explicit at that point. - Cleanup and sanitize the io_uring side, and ensure it's sane around worker retries. No more digging into iov_iter_state from io_uring, we use it just for save/restore purposes. -- Jens Axboe
