Re: [PATCH 3/7] lib/iov_iter: fix misplaced parenthesis in iov_iter_restore() kvec check

[Christian Brauner]

On Fri, Mar 13, 2026 at 06:10:34PM +0000, Josh Law wrote:
> When restoring a kvec-backed iterator after a short write in a kernel
> socket sendmsg path (e.g. an NFS client resending an RPC call), the
> WARN_ON_ONCE guard fires a spurious warning on every first call.
> 
> The closing parenthesis of WARN_ON_ONCE is after !iter_is_ubuf(i),
> leaving !iov_iter_is_kvec(i) as a separate && operand outside the
> macro:
> 
>   WARN_ON_ONCE(!bvec && !iovec && !ubuf) && !kvec
> 
> For kvec iterators this evaluates as WARN_ON_ONCE(true) && false — the
> warning fires but the return is skipped, so execution proceeds correctly.
> The warning is the only visible symptom, but it is confusing and may
> mask real issues.
> 
> Found through code review of the operator precedence in the condition
> expression and confirmed by tracing the macro expansion.
> 
> Move the closing parenthesis to include the kvec check inside
> WARN_ON_ONCE so the warning only fires for genuinely unsupported
> iterator types.
> 
> Signed-off-by: Josh Law <objecting@xxxxxxxxxxxxx>
> ---
>  lib/iov_iter.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/iov_iter.c b/lib/iov_iter.c
> index 325669b103ed..6a7959bfc849 100644
> --- a/lib/iov_iter.c
> +++ b/lib/iov_iter.c
> @@ -1471,7 +1471,7 @@ EXPORT_SYMBOL_GPL(import_ubuf);
>  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))
> +			 !iter_is_ubuf(i) && !iov_iter_is_kvec(i)))
>  		return;
>  	i->iov_offset = state->iov_offset;
>  	i->count = state->count;

Look... the placement is intentional as is easily identifiable by
looking at the history of the commits. This clearly is AI generated
and you don't have the capacity at the moment to meaningfully argue or
present the technical changes you are proposing - if you are an actual
person at all. As such I see no reason to engage with this.