Remove iov_iter_advance() for iter_write

[rincebrain]

Motivation and Context

#12041

Description

Someone in #12041 credibly said they thought this problem might be a flip side to #11378. So I tried it.

How Has This Been Tested?

The xfs_io testcase in #12041 no longer reproduces with this patch.
(I tried comparing ZTS before and after the patch, but after the second test case with unmodified git master hung forever, I gave up and decided I'd let the buildbots deal with it.)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[jonathonf]

Testing applied against zfs-2.0.5-staging, can confirm no more "Attempted to advance past end of bvec iter" message.

[behlendorf]

It seems like this should have gone with #11378.

Yes, yes it should have. @siebenmann's #12041 (comment) does a nice job explaining the issue and that the code is incorrectly advancing the iov_iter twice. The copy_from_iter() call performed during the write, zfs_write() -> zfs_uiocopy() -> zfs_uiomove_iter() -> copy_from_iter(), will advance the uio_iter the correct amount. This behavior is mentioned in some handy lwn documentation which describes the interfaces:

https://lwn.net/Articles/625077/

Note that these calls will "advance" the iterator through the buffer to correspond to the amount of data transferred. In other words, the iov_offset, count, nr_segs, and iov fields of the iterator will all be changed as needed. So two calls to copy_from_iter() will copy two successive areas from user space. Among other things, this means that the code owning the iterator must remember the base address for the iovec array, since the iov value in the iov_iter structure may change.

So I agree the right thing to do here is to just remove this unneeded iov advance, as was already done for the read case.

[behlendorf]

The code change itself looks good, but I'd suggest we update the commit message to make it clear that the advance isn't needed because it's handled by copy_from_iter().

[rincebrain]

There; is something like that what you had in mind?

[behlendorf]

That works for me.