[PATCH mptcp-next] mptcp: sockopt: info: stop early if no buffer

[PATCH mptcp-next] mptcp: sockopt: info: stop early if no buffer

[Matthieu Baerts (NGI0)]

Up to recently, it has been recommended to use getsockopt(MPTCP_INFO) on
an 'accept'ed socket, for a server app to check if the client requested
to use MPTCP.

In this case, the userspace app is only interested by the returned value
of the getsocktop() call, and can then give 0 for the option lenght, and
NULL for the buffer address. An easy optimisation is then to stop early,
and avoid filling a local buffer -- which now requires two different
locks -- if it is not needed.

Note that userspace apps should use getsockopt(SO_PROTOCOL) in such case
instead: it looks less like a workaround, and it works with any kernel
versions, while the MPTCP_INFO method requires kernels >= v5.16.

Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
 net/mptcp/sockopt.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c
index 1fea43f5b6f3..b0d1dc4df0c1 100644
--- a/net/mptcp/sockopt.c
+++ b/net/mptcp/sockopt.c
@@ -960,6 +960,12 @@ static int mptcp_getsockopt_info(struct mptcp_sock *msk, char __user *optval, in
 	if (get_user(len, optlen))
 		return -EFAULT;
 
+	/* Opti when used to check if a fallback to TCP happened on an 'accept'
+	 * socket. Userspace apps should use getsockopt(SO_PROTOCOL) instead.
+	 */
+	if (len == 0)
+		return 0;
+
 	len = min_t(unsigned int, len, sizeof(struct mptcp_info));
 
 	mptcp_diag_fill_info(msk, &m_info);

---
base-commit: 69582b96be671a6d87ab1e96e86c26225f1ec12a
change-id: 20240418-mptcp-getsockopt-info-opti-1232118bb417

Best regards,
-- 
Matthieu Baerts (NGI0) <matttbe@kernel.org>

Re: [PATCH mptcp-next] mptcp: sockopt: info: stop early if no buffer

[MPTCP CI]

Hi Matthieu,

Thank you for your modifications, that's great!

Our CI did some validations and here is its report:

- KVM Validation: normal: Success! ✅
- KVM Validation: debug: Success! ✅
- KVM Validation: btf (only bpftest_all): Success! ✅
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/8741402954

Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/06f7acd7238b
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=845876


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)

Re: [PATCH mptcp-next] mptcp: sockopt: info: stop early if no buffer

[Mat Martineau]

On Thu, 18 Apr 2024, Matthieu Baerts (NGI0) wrote:

> Up to recently, it has been recommended to use getsockopt(MPTCP_INFO) on
> an 'accept'ed socket, for a server app to check if the client requested
> to use MPTCP.
>
> In this case, the userspace app is only interested by the returned value
> of the getsocktop() call, and can then give 0 for the option lenght, and
> NULL for the buffer address. An easy optimisation is then to stop early,
> and avoid filling a local buffer -- which now requires two different
> locks -- if it is not needed.
>
> Note that userspace apps should use getsockopt(SO_PROTOCOL) in such case
> instead: it looks less like a workaround, and it works with any kernel
> versions, while the MPTCP_INFO method requires kernels >= v5.16.
>
> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
> ---
> net/mptcp/sockopt.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c
> index 1fea43f5b6f3..b0d1dc4df0c1 100644
> --- a/net/mptcp/sockopt.c
> +++ b/net/mptcp/sockopt.c
> @@ -960,6 +960,12 @@ static int mptcp_getsockopt_info(struct mptcp_sock *msk, char __user *optval, in
> 	if (get_user(len, optlen))
> 		return -EFAULT;
>
> +	/* Opti when used to check if a fallback to TCP happened on an 'accept'
> +	 * socket. Userspace apps should use getsockopt(SO_PROTOCOL) instead.
> +	 */
> +	if (len == 0)
> +		return 0;
> +

Makes sense to skip the work, LGTM:

Reviewed by: Mat Martineau <martineau@kernel.org>

> 	len = min_t(unsigned int, len, sizeof(struct mptcp_info));
>
> 	mptcp_diag_fill_info(msk, &m_info);
>
> ---
> base-commit: 69582b96be671a6d87ab1e96e86c26225f1ec12a
> change-id: 20240418-mptcp-getsockopt-info-opti-1232118bb417
>
> Best regards,
> -- 
> Matthieu Baerts (NGI0) <matttbe@kernel.org>
>
>
>

Re: [PATCH mptcp-next] mptcp: sockopt: info: stop early if no buffer

[Matthieu Baerts]

Hi Mat,

On 18/04/2024 19:06, Mat Martineau wrote:
> On Thu, 18 Apr 2024, Matthieu Baerts (NGI0) wrote:
> 
>> Up to recently, it has been recommended to use getsockopt(MPTCP_INFO) on
>> an 'accept'ed socket, for a server app to check if the client requested
>> to use MPTCP.
>>
>> In this case, the userspace app is only interested by the returned value
>> of the getsocktop() call, and can then give 0 for the option lenght, and
>> NULL for the buffer address. An easy optimisation is then to stop early,
>> and avoid filling a local buffer -- which now requires two different
>> locks -- if it is not needed.
>>
>> Note that userspace apps should use getsockopt(SO_PROTOCOL) in such case
>> instead: it looks less like a workaround, and it works with any kernel
>> versions, while the MPTCP_INFO method requires kernels >= v5.16.
>>
>> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
>> ---
>> net/mptcp/sockopt.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c
>> index 1fea43f5b6f3..b0d1dc4df0c1 100644
>> --- a/net/mptcp/sockopt.c
>> +++ b/net/mptcp/sockopt.c
>> @@ -960,6 +960,12 @@ static int mptcp_getsockopt_info(struct
>> mptcp_sock *msk, char __user *optval, in
>>     if (get_user(len, optlen))
>>         return -EFAULT;
>>
>> +    /* Opti when used to check if a fallback to TCP happened on an
>> 'accept'
>> +     * socket. Userspace apps should use getsockopt(SO_PROTOCOL)
>> instead.
>> +     */
>> +    if (len == 0)
>> +        return 0;
>> +
> 
> Makes sense to skip the work, LGTM:
> 
> Reviewed by: Mat Martineau <martineau@kernel.org>

Thank you for the quick review!

Now in our tree (without a typo: s/lenght/length/)

New patches for t/upstream:
- 1131e79ff7b0: mptcp: sockopt: info: stop early if no buffer
- Results: f0f388aa6196..b88f530f98b9 (export)

Tests are now in progress:

- export:
https://github.com/multipath-tcp/mptcp_net-next/commit/0347b4edc15cbbeaf0d16118ffa43fecc9b51e2c/checks

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.