| Message ID | 829272fc031f542c7a3d8e446eba19ee0f78dffb.1715794371.git.dcaratti@redhat.com (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Commit | 3baae0500fde102812951c23cf8b541f180a04b8 |
| Delegated to: | Matthieu Baerts |
| Headers | show |
| Series | [mptcp-next] mptcp: refer to 'MPTCP' socket in comments | expand |
| Context | Check | Description |
|---|---|---|
| matttbe/build | success | Build and static analysis OK |
| matttbe/checkpatch | warning | total: 0 errors, 1 warnings, 0 checks, 24 lines checked |
| matttbe/shellcheck | success | MPTCP selftests files have not been modified |
| matttbe/KVM_Validation__normal | warning | Unstable: 1 failed test(s): packetdrill_mp_join |
| matttbe/KVM_Validation__debug | success | Success! ✅ |
| matttbe/KVM_Validation__btf__only_bpftest_all_ | success | Success! ✅ |
Hi Davide, Thank you for your modifications, that's great! Our CI did some validations and here is its report: - KVM Validation: normal: Unstable: 1 failed test(s): packetdrill_mp_join
Hi Davide, On 15/05/2024 19:34, Davide Caratti wrote: > we used to call it 'master' socket at the early stages of MPTCP > development, but the correct wording is 'MPTCP' socket opposed to 'TCP > subflows': convert the last 3 coments to use a more appropriate term. Thanks! I'm giving my green light for that one (anyway, it cannot be red, black, yellow or white... so green it is!) Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Cheers, Matt
Hi Davide, On 16/05/2024 10:23, Matthieu Baerts wrote: > Hi Davide, > > On 15/05/2024 19:34, Davide Caratti wrote: >> we used to call it 'master' socket at the early stages of MPTCP >> development, but the correct wording is 'MPTCP' socket opposed to 'TCP >> subflows': convert the last 3 coments to use a more appropriate term. > > Thanks! I'm giving my green light for that one (anyway, it cannot be > red, black, yellow or white... so green it is!) Now in our tree (feat. for net-next): New patches for t/upstream: - 3baae0500fde: mptcp: refer to 'MPTCP' socket in comments - Results: c7a8f53bd706..21cbbc8eb75d (export) Tests are now in progress: - export: https://github.com/multipath-tcp/mptcp_net-next/commit/73d01b0fdcd849df097e33ff5378885228993e07/checks Cheers, Matt
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 579031c60937..fc879f1a7a1f 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -2202,7 +2202,7 @@ static int mptcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len, if (skb_queue_empty(&msk->receive_queue) && __mptcp_move_skbs(msk)) continue; - /* only the master socket status is relevant here. The exit + /* only the MPTCP socket status is relevant here. The exit * conditions mirror closely tcp_recvmsg() */ if (copied >= target) @@ -3521,7 +3521,7 @@ void mptcp_subflow_process_delegated(struct sock *ssk, long status) static int mptcp_hash(struct sock *sk) { /* should never be called, - * we hash the TCP subflows not the master socket + * we hash the TCP subflows not the MPTCP socket */ WARN_ON_ONCE(1); return 0; diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index 612c38570a64..39e2cbdf3801 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -1719,7 +1719,7 @@ int mptcp_subflow_create_socket(struct sock *sk, unsigned short family, mptcp_sockopt_sync_locked(mptcp_sk(sk), sf->sk); release_sock(sf->sk); - /* the newly created socket really belongs to the owning MPTCP master + /* the newly created socket really belongs to the owning MPTCP * socket, even if for additional subflows the allocation is performed * by a kernel workqueue. Adjust inode references, so that the * procfs/diag interfaces really show this one belonging to the correct
we used to call it 'master' socket at the early stages of MPTCP development, but the correct wording is 'MPTCP' socket opposed to 'TCP subflows': convert the last 3 coments to use a more appropriate term. Signed-off-by: Davide Caratti <dcaratti@redhat.com> --- net/mptcp/protocol.c | 4 ++-- net/mptcp/subflow.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-)