[PATCH mptcp-next] mptcp: call mp_fail_no_response only when needed

[PATCH mptcp-next] mptcp: call mp_fail_no_response only when needed

[Geliang Tang]

mptcp_mp_fail_no_response shouldn't be invoked on each worker run, it
should be invoked only when MP_FAIL response timeout occurs.

This patch adds a new msk flag MPTCP_FAIL_RESPONSE_EXPECT, set it when
sending MP_FAIL and test it in mptcp_timeout_timer().

Add back MPTCP_FAIL_NO_RESPONSE flag, set it in mptcp_timeout_timer()
when MP_FAIL response timeout occurs. Test it in mptcp_worker() before
invoking mptcp_mp_fail_no_response().

Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/281
Fixes: d9fb797046c5 ("mptcp: Do not traverse the subflow connection list without lock")
Signed-off-by: Geliang Tang <geliang.tang@suse.com>
---
 net/mptcp/protocol.c | 8 +++++++-
 net/mptcp/protocol.h | 2 ++
 net/mptcp/subflow.c  | 1 +
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index d6aef4b13b8a..cede25e7f2a3 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -2185,7 +2185,12 @@ mp_fail_response_expect_subflow(struct mptcp_sock *msk)
 static void mptcp_timeout_timer(struct timer_list *t)
 {
 	struct sock *sk = from_timer(sk, t, sk_timer);
+	struct mptcp_sock *msk = mptcp_sk(sk);
 
+	bh_lock_sock(sk);
+	if (test_and_clear_bit(MPTCP_FAIL_RESPONSE_EXPECT, &msk->flags))
+		__set_bit(MPTCP_FAIL_NO_RESPONSE, &msk->flags);
+	bh_unlock_sock(sk);
 	mptcp_schedule_work(sk);
 	sock_put(sk);
 }
@@ -2562,7 +2567,8 @@ static void mptcp_worker(struct work_struct *work)
 	if (test_and_clear_bit(MPTCP_WORK_RTX, &msk->flags))
 		__mptcp_retrans(sk);
 
-	mptcp_mp_fail_no_response(msk);
+	if (test_and_clear_bit(MPTCP_FAIL_NO_RESPONSE, &msk->flags))
+		mptcp_mp_fail_no_response(msk);
 
 unlock:
 	release_sock(sk);
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index d406b5afbee4..99023a59639b 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -116,6 +116,8 @@
 #define MPTCP_WORK_EOF		3
 #define MPTCP_FALLBACK_DONE	4
 #define MPTCP_WORK_CLOSE_SUBFLOW 5
+#define MPTCP_FAIL_RESPONSE_EXPECT	6
+#define MPTCP_FAIL_NO_RESPONSE		7
 
 /* MPTCP socket release cb flags */
 #define MPTCP_PUSH_PENDING	1
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index 8841e8cd9ad8..849dd001bc61 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -1240,6 +1240,7 @@ static bool subflow_check_data_avail(struct sock *ssk)
 					sk_eat_skb(ssk, skb);
 			} else if (!sock_flag(ssk, SOCK_DEAD)) {
 				WRITE_ONCE(subflow->mp_fail_response_expect, true);
+				__set_bit(MPTCP_FAIL_RESPONSE_EXPECT, &msk->flags);
 				sk_reset_timer((struct sock *)msk,
 					       &((struct sock *)msk)->sk_timer,
 					       jiffies + TCP_RTO_MAX);
-- 
2.35.3

Re: mptcp: call mp_fail_no_response only when needed: Tests Results

[MPTCP CI]

Hi Geliang,

Thank you for your modifications, that's great!

Our CI did some validations and here is its report:

- KVM Validation: normal:
  - Success! ✅:
  - Task: https://cirrus-ci.com/task/5856398490730496
  - Summary: https://api.cirrus-ci.com/v1/artifact/task/5856398490730496/summary/summary.txt

- KVM Validation: debug:
  - Unstable: 3 failed test(s): packetdrill_sockopts selftest_diag selftest_mptcp_join 🔴:
  - Task: https://cirrus-ci.com/task/5293448537309184
  - Summary: https://api.cirrus-ci.com/v1/artifact/task/5293448537309184/summary/summary.txt

Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/527585a8ae40


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-debug

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 (Tessares)