On Mon, 25 Apr 2022, Daniel Borkmann wrote:
On 4/21/22 12:24 AM, Mat Martineau wrote:
[...]
diff --git a/include/net/mptcp.h b/include/net/mptcp.h
index 0a3b0fb04a3b..5b3a6f783182 100644
--- a/include/net/mptcp.h
+++ b/include/net/mptcp.h
@@ -283,4 +283,10 @@ static inline int mptcpv6_init(void) { return 0; }
static inline void mptcpv6_handle_mapped(struct sock *sk, bool mapped) {
}
#endif
+#if defined(CONFIG_MPTCP) && defined(CONFIG_BPF_JIT) &&
defined(CONFIG_BPF_SYSCALL)
+struct mptcp_sock *bpf_mptcp_sock_from_subflow(struct sock *sk);
+#else
+static inline struct mptcp_sock *bpf_mptcp_sock_from_subflow(struct sock
*sk) { return NULL; }
+#endif
+
Where is this relevant to JIT specifically?
That's carried over from the build conditions for bpf_tcp_ca.c in
net/ipv4/Makefile:
ifeq ($(CONFIG_BPF_JIT),y)
obj-$(CONFIG_BPF_SYSCALL) += bpf_tcp_ca.o
endif
Looks like the reasoning for that (in the CA code) is the use of
bpf_struct_ops in bpf_tcp_ca.c
While this patch series for MPTCP does not use bpf_struct_ops, and JIT is
not necessary for bpf_mptcp_sock_from_subflow(), the upcoming MPTCP
scheduler-in-BPF patches do use bpf_struct_ops. So that dependency found
its way in to this series - but now that you point it out,
bpf_mptcp_sock_from_subflow() shouldn't be limited by CONFIG_BPF_JIT and
we can separately check for the JIT dependency for the scheduler code.
Will fix that in v2.
--
Mat Martineau
Intel
