Re: [PATCH mptcp-next] Revert "mptcp: add data lock for sk timers"

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

On Thu, 5 May 2022, Paolo Abeni wrote:

> This reverts commit 4293248c6704b854bf816aa1967e433402bee11c.
>
> Additional locks are not needed, all the touched sections
> are already under mptcp socket lock protection.
>

I agree that this needs to be reverted:

Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com>


But msk->sk_timer is *also* accessed in two places without the mptcp 
socket lock (but with the data lock):

  * mptcp_pm_mp_fail_received() (stop timer when mp_fail received)

  * subflow_check_data_avail() (start timer on infinite mapping rx)


I think these were the reason the locking was added, because we don't want 
the use of msk->sk_timer for MP_FAIL timeout to interfere with other use 
of msk->sk_timer when a msk is closing.

Now I see that the data lock doesn't work for that purpose. In addition to 
removing the data locks as this patch does, it looks like the two 
functions I listed above need to use msk->cb_flags and deferred events to 
safely check msk->sk_state and modify msk->sk_timer. What do you think? I 
can send a patch on Friday.


- Mat


> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
> net/mptcp/protocol.c | 12 ------------
> 1 file changed, 12 deletions(-)
>
> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
> index 5243c58789a4..ff567e9d0b1f 100644
> --- a/net/mptcp/protocol.c
> +++ b/net/mptcp/protocol.c
> @@ -1605,10 +1605,8 @@ void __mptcp_push_pending(struct sock *sk, unsigned int flags)
>
> out:
> 	/* ensure the rtx timer is running */
> -	mptcp_data_lock(sk);
> 	if (!mptcp_timer_pending(sk))
> 		mptcp_reset_timer(sk);
> -	mptcp_data_unlock(sk);
> 	if (copied)
> 		__mptcp_check_send_data_fin(sk);
> }
> @@ -2516,10 +2514,8 @@ static void __mptcp_retrans(struct sock *sk)
> reset_timer:
> 	mptcp_check_and_set_pending(sk);
>
> -	mptcp_data_lock(sk);
> 	if (!mptcp_timer_pending(sk))
> 		mptcp_reset_timer(sk);
> -	mptcp_data_unlock(sk);
> }
>
> static void mptcp_mp_fail_no_response(struct mptcp_sock *msk)
> @@ -2707,10 +2703,8 @@ void mptcp_subflow_shutdown(struct sock *sk, struct sock *ssk, int how)
> 		} else {
> 			pr_debug("Sending DATA_FIN on subflow %p", ssk);
> 			tcp_send_ack(ssk);
> -			mptcp_data_lock(sk);
> 			if (!mptcp_timer_pending(sk))
> 				mptcp_reset_timer(sk);
> -			mptcp_data_unlock(sk);
> 		}
> 		break;
> 	}
> @@ -2811,10 +2805,8 @@ static void __mptcp_destroy_sock(struct sock *sk)
> 	/* join list will be eventually flushed (with rst) at sock lock release time*/
> 	list_splice_init(&msk->conn_list, &conn_list);
>
> -	mptcp_data_lock(sk);
> 	mptcp_stop_timer(sk);
> 	sk_stop_timer(sk, &sk->sk_timer);
> -	mptcp_data_unlock(sk);
> 	msk->pm.status = 0;
> 	mptcp_release_sched(msk);
>
> @@ -2877,9 +2869,7 @@ static void mptcp_close(struct sock *sk, long timeout)
> 		__mptcp_destroy_sock(sk);
> 		do_cancel_work = true;
> 	} else {
> -		mptcp_data_lock(sk);
> 		sk_reset_timer(sk, &sk->sk_timer, jiffies + TCP_TIMEWAIT_LEN);
> -		mptcp_data_unlock(sk);
> 	}
> 	release_sock(sk);
> 	if (do_cancel_work)
> @@ -2924,10 +2914,8 @@ static int mptcp_disconnect(struct sock *sk, int flags)
> 		__mptcp_close_ssk(sk, ssk, subflow, MPTCP_CF_FASTCLOSE);
> 	}
>
> -	mptcp_data_lock(sk);
> 	mptcp_stop_timer(sk);
> 	sk_stop_timer(sk, &sk->sk_timer);
> -	mptcp_data_unlock(sk);
>
> 	if (mptcp_sk(sk)->token)
> 		mptcp_event(MPTCP_EVENT_CLOSED, mptcp_sk(sk), NULL, GFP_KERNEL);
> -- 
> 2.35.1
>
>
>

--
Mat Martineau
Intel