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@objecting.org>
---
 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;
-- 
2.34.1

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@objecting.org>
> ---
>  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.

On 23 March 2026 12:39:10 GMT, Christian Brauner <brauner@kernel.org> wrote:
>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@objecting.org>
>> ---
>>  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.



1: i am a real human
2: For code written by AI, i use Assisted-by: , i wrote the commit description with ai (thats why its so long)


Sorry for wasting your time

V/R


Josh Law