Re: [PATCH bpf-next 2/7] bpf: add bpf_skc_to_mptcp_sock_proto

[Mat Martineau <mathew.j.martineau@linux.intel.com>]

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