Re: [PATCH net v2 1/2] iov_iter: export iov_iter_restore

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [High] Exporting iov_iter_restore() and using it for generic transports is unsafe, as it fundamentally lacks support for modern iterators (ITER_FOLIOQ, ITER_XARRAY) and corrupts state.

Pre-existing issues:
- [High] iov_iter_restore() contains a parenthesis error in its WARN_ON_ONCE condition, causing it to spuriously emit a kernel warning when called with an ITER_KVEC iterator.
--

commit 169d794e6c649159c82a4c128f4edf768368df54
Author: Octavian Purdila <tavip@google.com>

iov_iter: export iov_iter_restore

Export iov_iter_restore so that it can be used by modules.

This is needed by the virtio vsock transport (which can be built as a
module) to restore the msg_iter state when transmission fails.

> diff --git a/lib/iov_iter.c b/lib/iov_iter.c
> --- a/lib/iov_iter.c
> +++ b/lib/iov_iter.c
> @@ -1469,28 +1469,29 @@ void iov_iter_restore(struct iov_iter *i, struct iov_iter_state *state)
>  {
>  	if (WARN_ON_ONCE(!iov_iter_is_bvec(i) && !iter_is_iovec(i) &&
>  			 !iter_is_ubuf(i)) && !iov_iter_is_kvec(i))
>  		return;

[Severity: High]
This is a pre-existing issue, but does the WARN_ON_ONCE condition have a
misplaced closing parenthesis?

If an ITER_KVEC is passed, the first three checks evaluate to true, so
WARN_ON_ONCE(true) is executed, triggering a spurious stack trace dump. The
function proceeds correctly because the overall condition evaluates to false,
but exporting this makes the bug accessible to generic users.

[ ... ]

>  	if (iov_iter_is_bvec(i))
>  		i->bvec -= state->nr_segs - i->nr_segs;
>  	else
>  		i->__iov -= state->nr_segs - i->nr_segs;
>  	i->nr_segs = state->nr_segs;
>  }
> +EXPORT_SYMBOL(iov_iter_restore);

[Severity: High]
Is it safe to export iov_iter_restore for generic socket transports?

The struct iov_iter_state lacks the fields necessary to track list traversal
or state for complex iterators, such as the folioq pointer in ITER_FOLIOQ.
Because of this, iov_iter_restore() silently returns without doing anything
for these types.

If a generic transport receives an ITER_FOLIOQ or ITER_XARRAY iterator, the
state will not be reverted on failure, which could lead to data corruption or
desynchronization upon retry. Should transports save and restore the full
struct iov_iter by value instead, or use iov_iter_revert()?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260613000953.467473-1-tavip@google.com?part=1