This is the approach to exposing kernel declarations to userland that glebius@ requested I investigate. It has the advantage of being less invasive in kernel headers than the last attempt, and the meaning of the _KERNEL/_KERNEL_UT/_KERNEL_UT_KSRC macros is a lot clearer than in the last version. However I'm not thrilled with how this requires changes to how every header exposes syscalls. At the very least, this would require an exp-run before committing.

glebius@ has requested a different approach where unit tests define _KERNEL and opt out of the KPI symbols that they don't want, rather than opting into the symbols that they do want.

glebius@ has requested a different approach where unit tests define _KERNEL and opt out of the KPI symbols that they don't want, rather than opting into the symbols that they do want.

glebius@ has requested a different approach where unit tests define _KERNEL and opt out of the KPI symbols that they don't want, rather than opting into the symbols that they do want.

glebius@ has requested a different approach where unit tests define _KERNEL and opt out of the KPI symbols that they don't want, rather than opting into the symbols that they do want.

glebius@ has requested a different approach where unit tests define _KERNEL and opt out of the KPI symbols that they don't want, rather than opting into the symbols that they do want.

glebius@ has requested a different approach where unit tests define _KERNEL and opt out of the KPI symbols that they don't want, rather than opting into the symbols that they do want.

glebius@ has requested a different approach where unit tests define _KERNEL and opt out of the KPI symbols that they don't want, rather than opting into the symbols that they do want.

glebius@ has requested a different approach where unit tests define _KERNEL and opt out of the KPI symbols that they don't want, rather than opting into the symbols that they do want.

glebius@ has requested a different approach where unit tests define _KERNEL and opt out of the KPI symbols that they don't want, rather than opting into the symbols that they do want.

glebius@ has requested a different approach where unit tests define _KERNEL and opt out of the KPI symbols that they don't want, rather than opting into the symbols that they do want.

In D34034#769620, @imp wrote:

A preference for positive logic here where the primary thing (_KERNEL) is also switched on makes it easier to understand, imho.

Ping? I'd like to get this patch and the other LRO patch in by next week.

Ping? I'd like to get this off of my queue by some time next week.

Please do not introduce new usages of mbuf clusters > PAGE_SIZE into
the network stack. When under memory pressure attempting to
allocating >PAGE_SIZE clusters will DoS the whole system if done at
the packet rates seen on modern networks.

I haven't been able to find a repro scenario for the leak outside of $WORK's repo, but by inspection this fix is obviously correct so I'm reopening this.

I can confirm don't have any out-of-tree consumers of linuxkpi, so looks fine to me.

Thanks for looking into this for me.

Fix lock leak. Sorry, this review was based off of an
older version of my patch that didn't have that fixed.
I've confirmed that this is now in sync with what was
tested internally at $WORK

Change the value of M_NORECLAIM to avoid the style issue

Fix overflap between new flag and count field

Sorry about the delay in coming back to this; I've had to deal with a number of critical issues at work. I ported the patch that we tested internally to main and posted it to this review:

sorry I got distracted by a different critical issue at work. Will be able to return to this next week

This patch doesn't work. After the goto retry, nothing stops the cancelling thread from seeing state still in WORK_ST_CANCEL, and then the timer thread can come in and change it to TASK, causing the same bug.

I don't think that spinning is the right answer. That could hold the CPU that the callout needs to make progress, resulting in a livelock.

Removing the ability to create unnamed vlans is an unnecessary POLA violation. It can make sense for the user to establish a convention that vlanX is for vlan tag X, but we absolutely shouldn't bake that assumption into the kernel.

Try putting entries in the witness_order_list_entry in kern/subr_witness.c specifying the ifnet_sx -> in_multi_sx ordering as correct. That should get better information. Likely the issue is a cycle of length larger than 2 (e.g. in_multi_sx before mystery lock, mystery lock before ifnet_sx, ifnet_sx before in_multi_sx).

In D26879#599402, @markj wrote:

That shouldn't be true. Did you test that recently? I'm not sure if it'll work for standalone module builds since KDTRACE_HOOKS might not be defined.

In D25085#560681, @lutz_donnerhacke.de wrote:

In my eyes, throwing away packets which successfully reached the destination for potential QoS/routing issues, is unexpected.

What's the status of this? We're hitting this problem very frequently at Isilon and this patch does fix the issue.

In D24902#550400, @rrs wrote:

Has discussed on the transport call, I will be updating these to have a uint64_t and a nano-second basis for the values (including t_starttime I think since this
is what you compare these against) :)

In D7821#510126, @rscheff_gmx.at wrote:

Is this still alive? As ECN has become more interesting recently, something like this is probably needed for RFC3168 ECN flows.

Also, forgive my ignorance, but can the LRO code add some side-band information to the upstream - e.g. number of packets coalesced, or number of CE marks observed? This would be very relevant in context of Accurate ECN. Where for RFC3168 it is sufficience that any segment marked as CE to appear in the final header, for AccECN the actual number of the CE marks, and also the number of coalesced packets would be relevant, to arrive at an appropriate alpha (reduction) value.

By just moving any number of CE marks to a single, the AccECN CC reaction would be more strong, shedding more bandwidth than appropriate...