[RFC mptcp-next v2] Squash to "tls: add ops in tls_context"

[RFC mptcp-next v2] Squash to "tls: add ops in tls_context"

[Geliang Tang]

From: Geliang Tang <tanggeliang@kylinos.cn>

Oops, sorry. spin_lock(&tls_prot_ops_lock) shouldn't be called after
write_lock_bh(&sk->sk_callback_lock); otherwise, a deadlock occurs.

When calling tls_prot_ops_find() here, it's unnecessary to hold
tls_prot_ops_lock; holding sk->sk_callback_lock is sufficient.

Based-on: <cover.1768284047.git.tanggeliang@kylinos.cn>

Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
---
 v2:
 - do not hold tls_prot_ops_lock in tls_init().
---
 net/tls/tls_main.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
index 75e01f2dde26..1051cb53bc5a 100644
--- a/net/tls/tls_main.c
+++ b/net/tls/tls_main.c
@@ -1097,9 +1097,7 @@ static int tls_init(struct sock *sk)
 	ctx->tx_conf = TLS_BASE;
 	ctx->rx_conf = TLS_BASE;
 	ctx->tx_max_payload_len = TLS_MAX_PAYLOAD_SIZE;
-	spin_lock(&tls_prot_ops_lock);
 	ctx->ops = tls_prot_ops_find(sk->sk_protocol);
-	spin_unlock(&tls_prot_ops_lock);
 	if (!ctx->ops) {
 		rc = -EINVAL;
 		goto out;
-- 
2.51.0

Re: [RFC mptcp-next v2] Squash to "tls: add ops in tls_context"

[MPTCP CI]

Hi Geliang,

Thank you for your modifications, that's great!

But sadly, our CI spotted some issues with it when trying to build it.

You can find more details there:

  https://github.com/multipath-tcp/mptcp_net-next/actions/runs/20949913531

Status: failure
Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/761f4fddebf4
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=1041619

Feel free to reply to this email if you cannot access logs, if you need
some support to fix the error, if this doesn't seem to be caused by your
modifications or if the error is a false positive one.

Cheers,
MPTCP GH Action bot
Bot operated by Matthieu Baerts (NGI0 Core)

Re: [RFC mptcp-next v2] Squash to "tls: add ops in tls_context"

[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 (except selftest_mptcp_join): Unstable: 2 failed test(s): packetdrill_add_addr selftest_simult_flows 🔴
- KVM Validation: normal (only selftest_mptcp_join): Success! ✅
- KVM Validation: debug (except selftest_mptcp_join): Unstable: 2 failed test(s): packetdrill_add_addr selftest_diag 🔴
- KVM Validation: debug (only selftest_mptcp_join): Unstable: 1 failed test(s): selftest_mptcp_join 🔴
- KVM Validation: btf-normal (only bpftest_all): Success! ✅
- KVM Validation: btf-debug (only bpftest_all): Success! ✅
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/20949913521

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


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)