linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ricardo Cañuelo Navarro" <rcn@igalia.com>
To: Xin Long <lucien.xin@gmail.com>
Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Simon Horman <horms@kernel.org>,
	kernel-dev@igalia.com, linux-sctp@vger.kernel.org,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH] sctp: check transport existence before processing a send primitive
Date: Fri, 04 Apr 2025 12:04:57 +0200	[thread overview]
Message-ID: <87r028dyye.fsf@igalia.com> (raw)
In-Reply-To: <CADvbK_d+vr-t7D1GZJ86gG6oS+Nzy7MDVh_+7Je6hqCdez4Axw@mail.gmail.com>

Thanks for the suggestion!

On Thu, Apr 03 2025 at 14:44:18, Xin Long <lucien.xin@gmail.com> wrote:

> @@ -9234,7 +9236,7 @@ static int sctp_wait_for_sndbuf(struct
> sctp_association *asoc, long *timeo_p,
>                                           TASK_INTERRUPTIBLE);
>                 if (asoc->base.dead)
>                         goto do_dead;
> -               if (!*timeo_p)
> +               if (!*timeo_p || (t && t->dead))
>                         goto do_nonblock;
>                 if (sk->sk_err || asoc->state >= SCTP_STATE_SHUTDOWN_PENDING)
>                         goto do_error;

I suppose checking t->dead should be done after locking the socket
again, where sctp_assoc_rm_peer() may have had a chance to run, rather
than here?

Something like this:

@@ -9225,7 +9227,9 @@ static int sctp_wait_for_sndbuf(struct sctp_association *asoc, long *timeo_p,
 	pr_debug("%s: asoc:%p, timeo:%ld, msg_len:%zu\n", __func__, asoc,
 		 *timeo_p, msg_len);
 
-	/* Increment the association's refcnt.  */
+	/* Increment the transport and association's refcnt. */
+	if (transport)
+		sctp_transport_hold(transport);
 	sctp_association_hold(asoc);
 
 	/* Wait on the association specific sndbuf space. */
@@ -9252,6 +9256,8 @@ static int sctp_wait_for_sndbuf(struct sctp_association *asoc, long *timeo_p,
 		lock_sock(sk);
 		if (sk != asoc->base.sk)
 			goto do_error;
+		if (transport && transport->dead)
+			goto do_nonblock;
 
 		*timeo_p = current_timeo;
 	}
@@ -9259,7 +9265,9 @@ static int sctp_wait_for_sndbuf(struct sctp_association *asoc, long *timeo_p,
 out:
 	finish_wait(&asoc->wait, &wait);
 
-	/* Release the association's refcnt.  */
+	/* Release the transport and association's refcnt. */
+	if (transport)
+		sctp_transport_put(transport);
 	sctp_association_put(asoc);
 
 	return err;


So by the time the sending thread re-claims the socket lock it can tell
whether someone else removed the transport by checking transport->dead
(set in sctp_transport_free()) and there's a guarantee that the
transport hasn't been freed yet because we hold a reference to it.

If the whole receive path through sctp_assoc_rm_peer() is protected by
the same socket lock, as you said, this should be safe. The tests I ran
seem to work fine. If you're ok with it I'll send another patch to
supersede this one.


> You will need to reintroduce the dead bit in struct sctp_transport and
> set it in sctp_transport_free(). Note this field was previously removed in:
>
> commit 47faa1e4c50ec26e6e75dcd1ce53f064bd45f729
> Author: Xin Long <lucien.xin@gmail.com>
> Date:   Fri Jan 22 01:49:09 2016 +0800
>
>     sctp: remove the dead field of sctp_transport

I understand that none of the transport->dead checks from that commit
are necessary anymore, since they were replaced by refcnt checks, and
that we'll only bring the bit back for this particular check we're doing
now, correct?

Cheers,
Ricardo

  reply	other threads:[~2025-04-04 10:05 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-02 10:25 [PATCH] sctp: check transport existence before processing a send primitive Ricardo Cañuelo Navarro
2025-04-02 13:21 ` Simon Horman
2025-04-02 13:37   ` Ricardo Cañuelo Navarro
2025-04-02 14:03     ` Ricardo Cañuelo Navarro
2025-04-02 19:40 ` Xin Long
2025-04-03  9:58   ` Ricardo Cañuelo Navarro
2025-04-03 14:42     ` Xin Long
2025-04-03 18:44       ` Xin Long
2025-04-04 10:04         ` Ricardo Cañuelo Navarro [this message]
2025-04-04 14:22           ` Xin Long
2025-04-07  7:37             ` Ricardo Cañuelo Navarro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r028dyye.fsf@igalia.com \
    --to=rcn@igalia.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kernel-dev@igalia.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sctp@vger.kernel.org \
    --cc=lucien.xin@gmail.com \
    --cc=marcelo.leitner@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).