The "void *raw_addr" is left uninitialized when else path is
followed raising below warning.

mptcp_connect.c:1262:11: warning: variable 'raw_addr' is used
      uninitialized whenever 'if' condition is false
      [-Wsometimes-uninitialized]

so the fix is to assign *raw_addr to NULL to suppress the warning.

Signed-off-by: Ankit Khushwaha <ankitkhushwaha.linux@gmail.com>
---
compiler used: clang version 21.1.5 (Fedora 21.1.5-1.fc43).
compilation cmd used:
	make -C tools/testing/selftests/net/mptcp CC=clang V=1 -j8

this maybe also be false positive. But somehow clang - 21.1.5
triggering this.

---
 tools/testing/selftests/net/mptcp/mptcp_connect.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/net/mptcp/mptcp_connect.c b/tools/testing/selftests/net/mptcp/mptcp_connect.c
index 404a77bf366a..cdb81e0d08ad 100644
--- a/tools/testing/selftests/net/mptcp/mptcp_connect.c
+++ b/tools/testing/selftests/net/mptcp/mptcp_connect.c
@@ -1248,8 +1248,8 @@ void xdisconnect(int fd)
 {
 	socklen_t addrlen = sizeof(struct sockaddr_storage);
 	struct sockaddr_storage addr, empty;
+	void *raw_addr = NULL;
 	int msec_sleep = 10;
-	void *raw_addr;
 	int i, cmdlen;
 	char cmd[128];

--
2.52.0

Hi Ankit,

Thank you for your modifications, that's great!

Our CI did some validations and here is its report:

- KVM Validation: normal (except selftest_mptcp_join): Success! ✅
- KVM Validation: normal (only selftest_mptcp_join): Success! ✅
- KVM Validation: debug (except selftest_mptcp_join): Success! ✅
- KVM Validation: debug (only selftest_mptcp_join): Success! ✅
- KVM Validation: btf-normal (only bpftest_all): Success! ✅
- KVM Validation: btf-debug (only bpftest_all): Success! ✅
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/19711500234

Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/9a580f7b5893
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=1027947


If there are some issues, you can reproduce them using the same environment as
the one used by the CI thanks to a docker image, e.g.:

    $ cd [kernel source code]
    $ docker run -v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \
        --pull always mptcp/mptcp-upstream-virtme-docker:latest \
        auto-normal

For more details:

    https://github.com/multipath-tcp/mptcp-upstream-virtme-docker


Please note that despite all the efforts that have been already done to have a
stable tests suite when executed on a public CI like here, it is possible some
reported issues are not due to your modifications. Still, do not hesitate to
help us improve that ;-)

Cheers,
MPTCP GH Action bot
Bot operated by Matthieu Baerts (NGI0 Core)

Hi Ankit,

On 26/11/2025 17:30, Ankit Khushwaha wrote:
> The "void *raw_addr" is left uninitialized when else path is
> followed raising below warning.
> 
> mptcp_connect.c:1262:11: warning: variable 'raw_addr' is used
>       uninitialized whenever 'if' condition is false
>       [-Wsometimes-uninitialized]
> 
> so the fix is to assign *raw_addr to NULL to suppress the warning.

Thank you for having shared this patch!
> Signed-off-by: Ankit Khushwaha <ankitkhushwaha.linux@gmail.com>
> ---
> compiler used: clang version 21.1.5 (Fedora 21.1.5-1.fc43).
> compilation cmd used:
> 	make -C tools/testing/selftests/net/mptcp CC=clang V=1 -j8
> 
> this maybe also be false positive. But somehow clang - 21.1.5
> triggering this.

I confirm this, I can reproduce the warning with Clang 21.

It is indeed a false positive, because the code does that:


  if (addr.ss_family == AF_INET)
          raw_addr = &(((struct sockaddr_in *)&addr)->sin_addr);
  else if (addr.ss_family == AF_INET6)
          raw_addr = &(((struct sockaddr_in6 *)&addr)->sin6_addr);
  else
          xerror("bad family");


"xerror()" calls "exit(1)", so "raw_addr" is never used uninitialized.

I'm not sure why Clang 21 reports that now, and not before, but well,
the modification you did in the selftests doesn't hurt:

Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>


@Net maintainers: this patch can be applied in 'net' directly.


@Antik: next time, please specify the target (net/net-next) in the
subject, see [1]. No need to send a new version (except if the Net
maintainers prefer), this patch can be applied on top of "net" without
conflicts.

[1] https://docs.kernel.org/process/maintainer-netdev.html

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.