Date: Fri, 21 May 2021 22:55:46 +0200 From: Michael Tuexen <tuexen@freebsd.org> To: Mark Johnston <markj@FreeBSD.org> Cc: freebsd-transport@freebsd.org, Randall Stewart <rrs@freebsd.org> Subject: Re: sockbuf locking in sctp_sosend() Message-ID: <48692FDD-688F-4D1F-98AA-7F555E35CC71@freebsd.org> In-Reply-To: <YKgSPWv8xqUCs12F@nuc> References: <YKf89YT3cPk3Q6Li@nuc> <DD51DB8A-9CCC-43B8-A1A7-2315041D043D@freebsd.org> <YKgSPWv8xqUCs12F@nuc>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 21. May 2021, at 22:04, Mark Johnston <markj@FreeBSD.org> wrote: > > On Fri, May 21, 2021 at 09:53:31PM +0200, Michael Tuexen wrote: >>> 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... > > Is the idea here is that multiple threads might be transmitting on the > socket in parallel? Would a shared lock be reasonable for that case? Yes, I think that is the idea. When you are sending, you specify on which association you are sending on. In contrast to that, when receiving, you can't specify on which association you want to receive one. That could explain the difference between the sending and receiving side. I haven't look up when the socket buffer lock is used for, but we support various incarnations on different platforms. Have a look at the upstream code, for example at https://github.com/sctplab/usrsctp we process the sources to generate the FreeBSD sources. Best regards Michael
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48692FDD-688F-4D1F-98AA-7F555E35CC71>