sockbuf: remove sbflush_internal() and sbrelease_internal() shims
Needs ReviewPublic
Actions

Authored by glebius on Fri, Mar 14, 6:06 PM.

Details

Reviewers

Group Reviewers

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 Skipped

Unit

Tests Skipped

Build Status

Buildable 62922
Build 59806: arc lint + arc unit

Event Timeline

glebius created this revision.Fri, Mar 14, 6:06 PM

Herald added subscribers: olce, imp. · View Herald TranscriptFri, Mar 14, 6:06 PM

glebius requested review of this revision.Fri, Mar 14, 6:06 PM

Harbormaster completed remote builds in B62922: Diff 152270.Fri, Mar 14, 6:06 PM

glebius added a child revision: D49364: sockbuf: provide sbunreserve_locked() which is a complement to sbreserve().Fri, Mar 14, 6:07 PM

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?

In D49363#1126167, @markj wrote:

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.