From: Arnd Bergmann <[email protected]>

[ Upstream commit e25dbf561e03c0c5e36228e3b8b784392819ce85 ]

The gcc-16.0.1 snapshot produces a false-positive warning that turns
into a build failure with CONFIG_WERROR:

In file included from arch/x86/include/asm/string.h:6,
                 from net/vmw_vsock/vmci_transport.c:10:
In function 'vmci_transport_packet_init',
    inlined from '__vmci_transport_send_control_pkt.constprop' at 
net/vmw_vsock/vmci_transport.c:198:2:
arch/x86/include/asm/string_32.h:150:25: error: argument 2 null where non-null 
expected because argument 3 is nonzero [-Werror=nonnull]
  150 | #define memcpy(t, f, n) __builtin_memcpy(t, f, n)
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~
net/vmw_vsock/vmci_transport.c:164:17: note: in expansion of macro 'memcpy'
  164 |                 memcpy(&pkt->u.wait, wait, sizeof(pkt->u.wait));
      |                 ^~~~~~
arch/x86/include/asm/string_32.h:150:25: note: in a call to built-in function 
'__builtin_memcpy'
net/vmw_vsock/vmci_transport.c:164:17: note: in expansion of macro 'memcpy'
  164 |                 memcpy(&pkt->u.wait, wait, sizeof(pkt->u.wait));
      |                 ^~~~~~

This seems relatively harmless, and it so far the only instance of this
warning I have found. The __vmci_transport_send_control_pkt function
is called either with wait=NULL or with one of the type values that
pass 'wait' into memcpy() here, but not from the same caller.

Replacing the memcpy with a struct assignment is otherwise the same
but avoids the warning.

Signed-off-by: Arnd Bergmann <[email protected]>
Reviewed-by: Bobby Eshleman <[email protected]>
Reviewed-by: Stefano Garzarella <[email protected]>
Reviewed-by: Bryan Tan <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---

LLM Generated explanations, may be completely bogus:

## Analysis

### Commit Message Analysis

This commit addresses a **false-positive compiler warning** with
gcc-16.0.1 that becomes a **build failure** when `CONFIG_WERROR` is
enabled. The fix replaces a `memcpy()` call with a direct struct
assignment, which is semantically equivalent but avoids triggering the
`-Wnonnull` warning.

### Code Change Analysis

The change is extremely minimal — a single line change:
```c
- memcpy(&pkt->u.wait, wait, sizeof(pkt->u.wait));
+ pkt->u.wait = *wait;
```

This is a purely mechanical transformation. A struct assignment and a
`memcpy` of the same struct size produce identical behavior. The
compiler generates equivalent code. The only difference is that the
struct assignment form doesn't trigger gcc-16's `-Wnonnull` analysis,
which was producing a false positive by analyzing the `memcpy` call
without considering that the `wait` parameter is only NULL for packet
types that don't reach this code path.

### Classification: Build Fix

This is a **build fix** — one of the explicitly allowed categories for
stable backports. With `CONFIG_WERROR` enabled (which is the default in
many distribution kernel configs and increasingly common), this warning
becomes a hard build error. Users building with gcc-16 and
`CONFIG_WERROR` would be unable to compile the kernel.

### Risk Assessment

- **Risk: Extremely low.** The change is a 1:1 semantic equivalent.
  `pkt->u.wait = *wait` does exactly what `memcpy(&pkt->u.wait, wait,
  sizeof(pkt->u.wait))` does — it copies the struct contents. There is
  zero behavioral change.
- **Scope: One line in one file.** Maximally contained.
- **Testing: Well-reviewed.** Has three `Reviewed-by` tags from relevant
  maintainers (Bobby Eshleman, Stefano Garzarella, Bryan Tan).

### Dependency Check

This commit has no dependencies on other patches. The code being
modified (`vmci_transport_packet_init`) has existed for a long time in
the stable trees.

### User Impact

- Users building the kernel with gcc-16 and `CONFIG_WERROR` will hit a
  build failure without this fix.
- gcc-16 is a snapshot/development compiler now, but will become the
  standard gcc version in distributions. As distributions adopt gcc-16,
  this will become a real issue for stable kernel users.
- Build fixes are critical for the usability of stable kernels.

### Stability Assessment

- The change is trivially correct — struct assignment and memcpy of a
  struct are equivalent.
- Multiple experienced reviewers have confirmed correctness.
- Zero risk of runtime regression.

### Conclusion

This is a textbook stable backport candidate: a minimal, zero-risk build
fix that prevents compilation failure with newer compiler versions. It
falls squarely into the "build fixes that prevent compilation" exception
category. The change is semantically identical to the original code and
has been well-reviewed.

**YES**

 net/vmw_vsock/vmci_transport.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/vmw_vsock/vmci_transport.c b/net/vmw_vsock/vmci_transport.c
index 7eccd6708d664..aca3132689cf1 100644
--- a/net/vmw_vsock/vmci_transport.c
+++ b/net/vmw_vsock/vmci_transport.c
@@ -161,7 +161,7 @@ vmci_transport_packet_init(struct vmci_transport_packet 
*pkt,
 
        case VMCI_TRANSPORT_PACKET_TYPE_WAITING_READ:
        case VMCI_TRANSPORT_PACKET_TYPE_WAITING_WRITE:
-               memcpy(&pkt->u.wait, wait, sizeof(pkt->u.wait));
+               pkt->u.wait = *wait;
                break;
 
        case VMCI_TRANSPORT_PACKET_TYPE_REQUEST2:
-- 
2.51.0


Reply via email to