From: Mat Martineau <mathew.j.martineau@linux.intel.com>
To: Matthieu Baerts <matthieu.baerts@tessares.net>
Cc: Jiri Olsa <olsajiri@gmail.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
netdev@vger.kernel.org, bpf@vger.kernel.org,
Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
Yonghong Song <yhs@fb.com>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@chromium.org>,
Geliang Tang <geliang.tang@suse.com>,
mptcp@lists.linux.dev
Subject: Re: [PATCH bpf-next] mptcp: Add struct mptcp_sock definition when CONFIG_MPTCP is disabled
Date: Tue, 12 Jul 2022 10:05:47 -0700 (PDT) [thread overview]
Message-ID: <d8cecd5-64b-5e5f-3fa-93dbbef3c2@linux.intel.com> (raw)
In-Reply-To: <23fa8509-5b2d-6263-1543-443c9c896348@tessares.net>
[-- Attachment #1: Type: text/plain, Size: 2973 bytes --]
On Tue, 12 Jul 2022, Matthieu Baerts wrote:
> Hi Jiri,
>
> On 12/07/2022 14:12, Jiri Olsa wrote:
>> On Tue, Jul 12, 2022 at 11:06:38AM +0200, Matthieu Baerts wrote:
>>> Hi Jiri, Mat,
>>>
>>> On 11/07/2022 23:21, Mat Martineau wrote:
>>>> On Mon, 11 Jul 2022, Jiri Olsa wrote:
>>>>
>>>>> The btf_sock_ids array needs struct mptcp_sock BTF ID for
>>>>> the bpf_skc_to_mptcp_sock helper.
>>>>>
>>>>> When CONFIG_MPTCP is disabled, the 'struct mptcp_sock' is not
>>>>> defined and resolve_btfids will complain with:
>>>>>
>>>>> BTFIDS vmlinux
>>>>> WARN: resolve_btfids: unresolved symbol mptcp_sock
>>>>>
>>>>> Adding empty difinition for struct mptcp_sock when CONFIG_MPTCP
>>>>> is disabled.
>>>>>
>>>>> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
>>>>> ---
>>>>> include/net/mptcp.h | 4 ++++
>>>>> 1 file changed, 4 insertions(+)
>>>>>
>>>>> diff --git a/include/net/mptcp.h b/include/net/mptcp.h
>>>>> index ac9cf7271d46..25741a52c666 100644
>>>>> --- a/include/net/mptcp.h
>>>>> +++ b/include/net/mptcp.h
>>>>> @@ -59,6 +59,10 @@ struct mptcp_addr_info {
>>>>> };
>>>>> };
>>>>>
>>>>> +#if !IS_ENABLED(CONFIG_MPTCP)
>>>>> +struct mptcp_sock { };
>>>>> +#endif
>>>>
>>>> The only use of struct mptcp_sock I see with !CONFIG_MPTCP is from this
>>>> stub at the end of mptcp.h:
>>>>
>>>> static inline struct mptcp_sock *bpf_mptcp_sock_from_subflow(struct sock
>>>> *sk) { return NULL; }
>>>>
>>>> It's normally defined in net/mptcp/protocol.h for the MPTCP subsystem code.
>>>>
>>>> The conditional could be added on the line before the stub to make it
>>>> clear that the empty struct is associated with that inline stub.
>>>
>>> If this is required only for this specific BPF function, why not
>>> modifying this stub (or add a define) to return "void *" instead of
>>> "struct mptcp_sock *"?
>>
>> so btf_sock_ids array needs BTF ID for 'struct mptcp_sock' and if CONFIG_MPTCP
>> is not enabled, then resolve_btfids (which resolves and populate all BTF IDs)
>> won't find it and will complain
>>
>> btf_sock_ids keeps all socket IDs regardles the state of their CONFIG options,
>> and relies that sock structs are defined even if related CONFIG option is disabled
>
> Thank you for the explanation. I didn't know about that.
>
> Then it is fine for me to leave it in mptcp.h. If it is not directly
> linked to bpf_mptcp_sock_from_subflow(), I guess it can stay there but
> maybe better to wait for Mat's answer about that.
>
>> if that is false assumption then maybe we need to make btf_sock_ids values optional
>> somehow
>
I'd rather keep the full mptcp_sock definition in net/mptcp/protocol.h
since moving it would require also moving a few other structs it depends
on.
Defining the empty struct in mptcp.h is fine with me and it sounds like
that meets the needs of btf_sock_ids - but I'd like a v2 of this patch
that moves the new empty struct declaration next to the inline
btf_mptcp_sock_from_subflow function in mptcp.h
--
Mat Martineau
Intel
prev parent reply other threads:[~2022-07-12 17:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-11 13:07 [PATCH bpf-next] mptcp: Add struct mptcp_sock definition when CONFIG_MPTCP is disabled Jiri Olsa
2022-07-11 20:27 ` Martin KaFai Lau
2022-07-11 21:21 ` Mat Martineau
2022-07-12 9:06 ` Matthieu Baerts
2022-07-12 12:12 ` Jiri Olsa
2022-07-12 13:06 ` Matthieu Baerts
2022-07-12 17:05 ` Mat Martineau [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d8cecd5-64b-5e5f-3fa-93dbbef3c2@linux.intel.com \
--to=mathew.j.martineau@linux.intel.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=geliang.tang@suse.com \
--cc=john.fastabend@gmail.com \
--cc=kafai@fb.com \
--cc=kpsingh@chromium.org \
--cc=matthieu.baerts@tessares.net \
--cc=mptcp@lists.linux.dev \
--cc=netdev@vger.kernel.org \
--cc=olsajiri@gmail.com \
--cc=songliubraving@fb.com \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox