Page MenuHomeFreeBSD

socket: Add macros to lock socket buffers using socket references
ClosedPublic

Authored by markj on Sep 10 2021, 4:19 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Oct 26, 8:24 AM
Unknown Object (File)
Oct 1 2024, 3:02 AM
Unknown Object (File)
Sep 30 2024, 4:26 PM
Unknown Object (File)
Sep 30 2024, 6:26 AM
Unknown Object (File)
Sep 28 2024, 9:32 AM
Unknown Object (File)
Sep 27 2024, 6:53 PM
Unknown Object (File)
Sep 24 2024, 8:25 AM
Unknown Object (File)
Sep 24 2024, 12:02 AM
Subscribers

Details

Summary

Since commit c67f3b8b78e50c6df7c057d6cf108e4d6b4312d0 the sockbuf
mutexes belong to the containing socket. Sockbufs contain a pointer to
a mutex, which by default is initialized to the corresponding mutexes in
the socket. The SOCKBUF_LOCK() etc. macros operate on this pointer.
However, the pointer is clobbered by listen(2) so it's not safe to use
them unless one is sure that the socket is not a listening socket.

This change introduces a new set of macros which lock socket buffers
through the socket. This is a bit cheaper since it removes the pointer
indirection, and allows one to safely lock socket buffers and then check
for a listening socket.

I have some changes staged which convert most consumers to use the new
macros, though this introduces a fair bit of churn. The new locking
macros can be trivially implemented in terms of the existing ones on
stable/13, though, so I don't think it's a major problem to do the sweep
and MFC.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

markj requested review of this revision.Sep 10 2021, 4:19 PM
This revision is now accepted and ready to land.Sep 10 2021, 6:50 PM

It's almost (but not really) tempting to name then SND and RCV similar to the so_rcv/so_snd fields. Having the extra 'E' for readability is probably an improvement though.

In D31900#719868, @jhb wrote:

It's almost (but not really) tempting to name then SND and RCV similar to the so_rcv/so_snd fields. Having the extra 'E' for readability is probably an improvement though.

... and I already used SEND/RECV in the macros which replace sblock().