On Tue, 17 May 2022, Alexei Starovoitov wrote: > On Mon, May 16, 2022 at 10:26 PM Geliang Tang wrote: >> >> Martin KaFai Lau 于2022年5月17日周二 09:07写道： >>> >>> On Fri, May 13, 2022 at 03:48:21PM -0700, Mat Martineau wrote: >>> [ ... ] >>> >>>> diff --git a/include/net/mptcp.h b/include/net/mptcp.h >>>> index 8b1afd6f5cc4..2ba09de955c7 100644 >>>> --- a/include/net/mptcp.h >>>> +++ b/include/net/mptcp.h >>>> @@ -284,4 +284,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_SYSCALL) >>>> +struct mptcp_sock *bpf_mptcp_sock_from_subflow(struct sock *sk); >>> Can this be inline ? >> >> This function can't be inline since it uses struct mptcp_subflow_context. >> >> mptcp_subflow_context is defined in net/mptcp/protocol.h, and we don't >> want to export it to user space in net/mptcp/protocol.h. > > The above function can be made static inline in a header file. > That doesn't automatically expose it to user space. > True, it's not a question of userspace exposure. But making this one function inline involves a bunch of churn in the (non-BPF) mptcp headers that I'd rather avoid. The definitions in protocol.h are there because they aren't relevant outside of the mptcp subsystem code. Does making this one function inline benefit BPF, specifically, in a meaningful way? If not, I'd like to leave it as-is. -- Mat Martineau Intel