I completely forgot about this... LGTM.

In D48766#1112402, @mhorne wrote:

Yes, this is smarter.

I kind of regret adding this thing. Although it is conceptually helpful/correct, its positive practical impact has so far been zero, while it has created several headaches.

Whoops, good catch, thanks

Highlights:

• Cache the catpages
• Limit rights(4) on UDP sockets immediately post-bind(2), rather than repeatedly- we shouldn't need higher privileges anymore
• Better explain setup_ctrl_caps()
• Switch the discard UDP service to enter capability mode, as a means of demonstrating that it does work for UDP services as well

In D48483#1106209, @emaste wrote:

This looks reasonable to me but could it be that whatever base64 exists on typical Linux distros allows "incorrect" argument order?

I'm doing a more thorough review of vt_window_switch() after thinking more on jhb's comment in D48413... the lock moved in that one is for a branch that's effectively dead code after this change and should've been removed here anyways. Right now I just get a frozen UI if I panic with xfce in focus on ttyv9 (but no nested panic), and I'm not sure I'm convinced that that would play out any differently even if we could attempt most of the rest of vt_window_switch() while panicking.

In D48414#1104253, @jhb wrote:

I'm fine with this. Don't the locking implementations just bail without panicking though if a panic is already active, or is the nested panic not inside a lock but elsewhere?

Drop the garbage reference entirely, expand on the description to note the
figure used. Also note some possible future work to rewrite the later part of
this to more closely follow the algorithm described, as they don't seem to want
to commit to D.DD[MGT]Hz or DDDD[MGT]Hz -- they specifically recommend scanning
for a prior space. This would also offer us an opportunity to validate that
all of the involved digits are actually [0-9] or '.'.

In D48331#1102324, @imp wrote:

In D48331#1102305, @markj wrote:

In D48331#1102183, @imp wrote:

Why 5, but regardless of why, this is correct

A bit further down there's an assignment p -= 5.

Where does that 5 come from was my real question. What spec says we know this format

In D48331#1102305, @markj wrote:

In D48331#1102183, @imp wrote:

Why 5, but regardless of why, this is correct

A bit further down there's an assignment p -= 5.

Looks fine in principle

Reverse course, just move sc_cpuids out from underneath SMP and let it allocatee
a single-entry sc_cpuids. The overhead of still doing intr_irq_next_cpu() is
minimal since it's simply a PCPU_GET(cpuid) on !SMP kernels.

This seems like the kind of thing Coverity should notice- any other lower-hanging fruit like this buried in Coverity results, by chance?

I came to the same conclusion (patch) in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283653, but hadn't had a chance to test it yet. Thanks!

One last wording tweak: be more direct about what tar(1) provides