sockbuf locking in sctp_sosend()

[Mark Johnston]

On Fri, May 21, 2021 at 09:53:31PM +0200, Michael Tuexen wrote:
> > On 21. May 2021, at 20:33, Mark Johnston <markj at 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?