Date: Fri, 21 May 2021 21:53:31 +0200 From: Michael Tuexen <tuexen@freebsd.org> To: Mark Johnston <markj@FreeBSD.org> Cc: freebsd-transport@freebsd.org Subject: Re: sockbuf locking in sctp_sosend() Message-ID: <DD51DB8A-9CCC-43B8-A1A7-2315041D043D@freebsd.org> In-Reply-To: <YKf89YT3cPk3Q6Li@nuc> References: <YKf89YT3cPk3Q6Li@nuc>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 21. May 2021, at 20:33, Mark Johnston <markj@FreeBSD.org> wrote: > > Hi, > > As part of an attempt to finally fix races with listen(2), I have some > patches which move the socket I/O sx locks out of struct sockbuf and > into the owning socket structure. This is a prerequisite for > synchronizing socket I/O with listen(2), since most pru_sosend routines > acquire the sx lock as their first operation. > > I noticed though that among pru_sosend implementations, scpt_sosend() is > unique in that it does not use sblock() to serialize senders. Is that > intentional? I see that sctp_soreceive() uses it. You might want to double check with rrs@, but I think the reason might be to support the 1-to-many style sockets. This means that you have a single socket, but multiple SCTP association, each of them having a sendbuffer. But that is not the socket level send buffer... Best regards Michael
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DD51DB8A-9CCC-43B8-A1A7-2315041D043D>