@kmacy I have not. We probably have an equivalent fix committed locally @ $WORK but it might be tied too closely to the high-precision timestamp work to easily extract.

In D10535#218388, @sbruno wrote:

Maybe you've seen something that requires this lock acquisition in your testing. Can you explain why we need to acquire this lock here?

Add the locking mentioned the description but omitted from the
actual revision.

I'm not sure what we want to do with this fix given the imminent iflib conversion, but at least this should go into stable branches.

Obsoleted by gleb's User/Kernel KPI fixes

In D9465#198397, @pkelsey wrote:

I realize the issue there is exposure of a type definition to userland, but a related question is - what exactly is the userland-ABI property we are trying to maintain here? Are we just trying to keep this struct the same size and layout under all kernel configuration option selections and feature evolutions for a given machine type? Or are we also trying to keep it the same size and layout across different machine types (or at the very least a single pair of relevant machine types)? For example, is the #ifdef_LP64 really necessary in the TCPPCAP section?

• fixup! Don't zero out srtt after excess retransmits

See this ML post for a detailed description of the problem:
https://lists.freebsd.org/pipermail/freebsd-current/2013-January/039261.html

Ensure we don't walk off the end of the ring

--git-dir is unreliable, so use -C $git_repo instead

Similar fix is needed in importgit

This is not the correct fix. The bug lies in a higher layer; the stack must never call into the ifnet layer with the if_addr_lock already held. I see how to fix the upper layer, so I'll take that.

Add -n option to arcgit to perform a dry run, and fix some typos.

Add sysctl to control new UDP receive behaviour, and document it
in UPDATING.

I already have this one in review. I'm trying to address some concerns that have been raised outside of phabricator, and once that's taken care of I'll commit my version.

so apparently this is called on nearly every packet that passes through ip_output() (according to a comparison of dtrace and netstat output). Adding an additional lock/unlock to the transmit path concerns me, but this is obviously the right fix. Does in_broadcast() really need to be called so much?

Use macros for code compiled in kernel

Have we tested the case where there is only a single flow, so all of the flowids are equal? That tends to be a very bad case for qsort.