On Thu, Feb 16, 2023 at 01:19:07PM +0300, Vitaliy Makkoveev wrote: > > Sorry for big non obvious diff. I need this refactoring to keep required > lock order between solock() and the standalone sblock(). >
The standalone sblock() could be non obvious for this moment. I want to to this mostly because it solve some solock() and netlock relations for inet sockets. This time we have per-socket `so_lock' rwlock(9) and we use it as solock() backend for all sockets except inet. For inet sockets case we use netlock as solock() backend to protect socket's data and PCB data. Also netlock is required in inet socket's PCB layer to protect network stack data. We can't use `so_lock' as solock() backend because for the send path solock() will be taken at sockets layer and the netlock will be taken at PCB layer, but for receive path the netlock and then solock() will be taken at PCB layer. We can't do this the deadlock. But the standalone sblock(&so->so_snd) and sblock(&so->so_rcv) are different locks, so the relations "sblock(&so->so_snd) -> netlock" and "netlock -> sblock(&so->so_rcv)" is fully accepted. This allows us to move netlock deep down to PCB layer and make netstack a little bit more MP capable.
