On Wed, Apr 10, 2024 at 07:48:55PM +0200, Alexander Bluhm wrote:
> On Wed, Apr 10, 2024 at 04:55:49PM +0300, Vitaliy Makkoveev wrote:
> > Updated to be on top of the tree. Against previous, the shared solock()
> > used around sorflush_locked(). Only unix(4) sockets set (*dom_dispose)()
> > handler and it actually doesn't need any protection.
> 
> For that you add different locking strategies in sosend() and
> soreceive() that are controlled by SB flags.  The result is that
> these functions get even harder to understand.
> 

This is temporary solution. I can made the diff which turns all the
sockets to the new locking strategy, but it will be very huge.

Not only sosend(), soreceive() sorflush() and sofree() need to be
converted, the PCB layers for all the sockets also need corresponding
work. Don't forget about splicing sockets, we also need to convert
somove() and the worst thing will be sorwakeup() path. So, I prefer to
introduce flags and do the work step by step.

Really, this big diff will be the hellish one to commit and receive
possible fallout due to very huge area.

I see raw sockets the best way to start, because they don't need to call
pru_rcvd(), they are not connection oriented sockets, they nave no
splicing ability. So the diff is small enough, however you use them not
only for ping(8), but as divert sockets too, so it's the better choice
then AF_KEY or AF_ROUTE sockets. I wanted to convert them as the next
step after new sblock() landing.

So, yes. I want to implement generic logic for all the sockets, but with
many diffs. This time raw sockets, unix sockets, route sockets and key
management sockets could be converted. The tcp and udp sockets require
to start sosplice() and somove() reworking, so I want to do this the
last.

> Would it make more sense to advance the underlying protocols to a
> similar level of fine grained locking?  Then the socket layer can
> implement a generic logic.
>