On Sun, Jul 04, 2021 at 03:59:53PM +0200, Martin Pieuchot wrote: > On 02/07/21(Fri) 15:01, Alexander Bluhm wrote: > > On Fri, Jul 02, 2021 at 01:05:39PM +0200, Martin Pieuchot wrote: > > > Looks good to me. Grabbing solock() after calling pledge_socket() in > > > sys_connect(), like it is already done in sys_bind(), means it is ok > > > to read this field w/o lock. Is it true? > > > > I guess it is good enough. If MP rules are followed stictly, every > > access without lock or memory barrier is problematic. But here the > > SS_DNS flag is set during socket creation. Also racing against > > pledge does not look like something we must be aware of. > > Does good enough means it OK to read so_state w/o serialization > mechanism in poll & kqueue handlers? If so that would simplify a lot > the work to reduce the contention on the NET_LOCK() in these code paths.
pledge(2) and so_state SS_DNS are special. There is no real risk of a race and the flag is set only at socket creation. But things that are modified by network stack and other threads like SS_RCVATMARK, SS_CANTRCVMORE, SS_ISDISCONNECTED, ... should be accessed with a socket lock. bluhm
