Fuzzers and static checkers might not detect when mptcp_sk() is used
with a non mptcp_sock structure.
This is similar to the parent commit, where it is easy to use mptcp_sk()
with a TCP sock, e.g. with a subflow sk.
So a new simple check is done when CONFIG_DEBUG_NET is enabled.
mptcp_sk() is then used as an inlined function, like before commit
403a40f2304d ("mptcp: preserve const qualifier in mptcp_sk()").
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
net/mptcp/protocol.h | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index eefd1397106d..c10c778cd773 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -348,7 +348,16 @@ static inline void msk_owned_by_me(const struct mptcp_sock *msk)
sock_owned_by_me((const struct sock *)msk);
}
+#ifdef CONFIG_DEBUG_NET
+static inline struct mptcp_sock *mptcp_sk(const struct sock *sk)
+{
+ WARN_ON(sk->sk_protocol != IPPROTO_MPTCP);
+
+ return (struct mptcp_sock *)sk;
+}
+#else
#define mptcp_sk(ptr) container_of_const(ptr, struct mptcp_sock, sk.icsk_inet.sk)
+#endif
/* the msk socket don't use the backlog, also account for the bulk
* free memory
--
2.43.0
Hi Matthieu, Thank you for your modifications, that's great! Our CI (GitHub Action) did some validations and here is its report: - KVM Validation: normal: - Success! ✅: - Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/7728700216 Initiator: Patchew Applier Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/399e99c4147f 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 Matthieu, Thank you for your modifications, that's great! Our CI (Cirrus) did some validations with a debug kernel and here is its report: - {"code":404,"message": - "Can't find artifacts containing file conclusion.txt"}: - Task: https://cirrus-ci.com/task/4603007531220992 - Summary: https://api.cirrus-ci.com/v1/artifact/task/4603007531220992/summary/summary.txt - {"code":404,"message": - "Can't find artifacts containing file conclusion.txt"}: - Task: https://cirrus-ci.com/task/5728907438063616 - Summary: https://api.cirrus-ci.com/v1/artifact/task/5728907438063616/summary/summary.txt Initiator: Patchew Applier Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/399e99c4147f 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-debug 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)
© 2016 - 2024 Red Hat, Inc.