From owner-freebsd-transport@freebsd.org  Fri May 21 19:53:39 2021
Return-Path: <owner-freebsd-transport@freebsd.org>
Delivered-To: freebsd-transport@mailman.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
 by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9A32463ADC3
 for <freebsd-transport@mailman.nyi.freebsd.org>;
 Fri, 21 May 2021 19:53:39 +0000 (UTC)
 (envelope-from tuexen@freebsd.org)
Received: from drew.franken.de (mail-n.franken.de [193.175.24.27])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "*.franken.de",
 Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK))
 by mx1.freebsd.org (Postfix) with ESMTPS id 4Fmy3722TXz4m0p;
 Fri, 21 May 2021 19:53:38 +0000 (UTC)
 (envelope-from tuexen@freebsd.org)
Received: from smtpclient.apple (ip4d15f626.dynamic.kabel-deutschland.de
 [77.21.246.38]) (Authenticated sender: macmic)
 by mail-n.franken.de (Postfix) with ESMTPSA id EDE2F722CEB83;
 Fri, 21 May 2021 21:53:35 +0200 (CEST)
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\))
Subject: Re: sockbuf locking in sctp_sosend()
From: Michael Tuexen <tuexen@freebsd.org>
In-Reply-To: <YKf89YT3cPk3Q6Li@nuc>
Date: Fri, 21 May 2021 21:53:31 +0200
Cc: freebsd-transport@freebsd.org
Content-Transfer-Encoding: 7bit
Message-Id: <DD51DB8A-9CCC-43B8-A1A7-2315041D043D@freebsd.org>
References: <YKf89YT3cPk3Q6Li@nuc>
To: Mark Johnston <markj@FreeBSD.org>
X-Mailer: Apple Mail (2.3654.80.0.2.43)
X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00
 autolearn=disabled version=3.4.1
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de
X-Rspamd-Queue-Id: 4Fmy3722TXz4m0p
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	none
X-Spamd-Result: default: False [0.00 / 15.00];
 local_wl_from(0.00)[freebsd.org];
 ASN(0.00)[asn:680, ipnet:193.174.0.0/15, country:DE]
X-BeenThere: freebsd-transport@freebsd.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Discussions of transport level network protocols in FreeBSD
 <freebsd-transport.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-transport>, 
 <mailto:freebsd-transport-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-transport/>
List-Post: <mailto:freebsd-transport@freebsd.org>
List-Help: <mailto:freebsd-transport-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-transport>, 
 <mailto:freebsd-transport-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 21 May 2021 19:53:39 -0000

> 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