Page MenuHomeFreeBSD

sockbuf: remove sbflush_internal() and sbrelease_internal() shims
ClosedPublic

Authored by glebius on Mar 14 2025, 6:06 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Apr 17, 2:47 AM
Unknown Object (File)
Mon, Apr 14, 12:42 PM
Unknown Object (File)
Mon, Apr 7, 4:25 AM
Unknown Object (File)
Sat, Apr 5, 7:05 AM
Unknown Object (File)
Fri, Apr 4, 8:24 AM
Unknown Object (File)
Mon, Mar 31, 1:56 PM
Unknown Object (File)
Mon, Mar 24, 7:36 AM
Unknown Object (File)
Mar 20 2025, 4:18 AM
Subscribers

Details

Summary

This functions serve just one purpose - allow to call sbdestroy() from
sofree() without triggering unlocked mutex assertions. Let's just don't
save on locking with INVARIANTS kernel and this will allow to clean up all
these shims. Should be no functional changes.

Diff Detail

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

Event Timeline

This feels weird. Suppose there is some bug that is prevented by acquiring these mutexes. Now the bug will be absent in INVARIANTS kernels, but present in production kernels, which will making debugging very confusing. I'm not sure that this is worth it just to slightly simplify some call paths?

This feels weird. Suppose there is some bug that is prevented by acquiring these mutexes. Now the bug will be absent in INVARIANTS kernels, but present in production kernels, which will making debugging very confusing. I'm not sure that this is worth it just to slightly simplify some call paths?

Nope, it is the opposite! Right now there could be a bug that would call sbrelease_internal() without holding mutex and INVARIANTS won't catch that. Same for sbflush_internal. With the change, the functions start asserting the lock. And the only place that has a legitimate unlocked call is properly marked.

This revision is now accepted and ready to land.Mar 23 2025, 10:50 AM