My build is still running on the old hardware where I can test this.
Quick check, if I get it right:

• this solves the issue where demand is false on the next period.
• this does not solve an issue where ~1 packet per period is send while more than one is in the queue (no idea if this is behavior we can see in the real world): growth every period → demand true every period → armed reaches 4 → still resets.

In D59102#1356034, @markj wrote:

In D59102#1355583, @netchild wrote:

	if (PMC_SYSTEM_SAMPLING_ACTIVE() || PMC_PROC_IS_USING_PMCS(p)) {
		VOP_UNLOCK(imgp->vp);
-		pe.pm_credentialschanged = credential_changing;
+		pe.pm_credentialschanged = imgp->credential_setid;

filemon already does it this way — filemon_wrapper.c:127-129 pairs the same priv_check_cred(cred, PRIV_DEBUG_DIFFCRED) with imgp->newcred != NULL && imgp->credential_setid.
With this change, my 32 test cases pass (= no regression to what we have right now, except the security issue gone).

Yes, thanks. Probably exec should just be passing imgp directly to these hooks. (HWT has a nearly duplicate hook, but it doesn't seem to check for setuid/setgid switches. OTOH it is currently only usable by privileged users, at least today. Something to fix, but not in this patch.)

My tests detect a regression:

Comments reworded, a part moved into the commit log. The single (after f6afed726b00 ) goto moved into the one place where it matters.

Make the padding explicit.

Move the variables instruct iflib_txq to a place which causes less padding. Make the existing padding in the struct visible. Checked for amd64, riscv64, arm64, and i386 (only arch where the sizeof() changes, follow-up commit to remove the "old" watchdog parts changes the size back.

full context

full context

Results from the affected hardware (em0, 82541PI), ~44 h
on a v3 kernel. Summary: 16 watchdog fires, all true positives, 0 false
positives.

New tested version, on hardware which triggers the watchdog.

So you disagree with kern.features.exterror.
Do you also disagree with kern.features.exterr_strings which covers the optional behavior of verbose exterror and is useful in unit tests to differentiate between "fails because something is wrong -> error" and "fails because it does not exist -> intendet -> ok".

The kern.features.exterror part is for the benefit of userland programs which want to use it (e.g. difference between FreeBSD 14.x and 15.x).
The kern.features.exterr_strings part is for the benefit of unit tests to be able to skip if the verbose strings are not enabled.

This fires too often, maybe some false positives. I will rework.

Switch to the mxge way. Mxge seems to harvest the completions
eagerly per interrupt, while iflib seems to reclaim lazy. The
software counter of iflib would get into the watchdog firing
situation on a lightly loaded interface... if I get it correctly.

When excluding from fortify the ones for which I mailed the error message to you, I have build
Queued: 1338 Inspected: 0 Ignored: 0 Built: 1338 Failed: 0 Skipped: 0 Fetched: 0 Remaining: 0

In D57628#1322519, @kevans wrote:

In D57628#1322468, @netchild wrote:

In D57628#1321971, @kevans wrote:

All supported releases should have it, but it is also harmless to define any of this when it isn't -- I'd probably avoid complicating it too much.

Sounds sensible.

If you don't object to the ports patch as the maintainer, I'll just go ahead and request an exp-run with both patches applied (with the assignment you noted fixed). I had hoped to land this this week, but I also don't want antoine throwing tomatoes at me if we fundamentally break the ports tree. =-)

I don't object for sure. But I suggest to use this instead:

diff --git Mk/Features/fortify.mk Mk/Features/fortify.mk
index 2e43ca98242..86d149ff68e 100644
--- Mk/Features/fortify.mk
+++ Mk/Features/fortify.mk
@@ -14,5 +14,7 @@ FORTIFY_SOURCE?=2
 FORTIFY_CFLAGS?=       -D_FORTIFY_SOURCE=${FORTIFY_SOURCE}
 CFLAGS+=       ${FORTIFY_CFLAGS}
 CXXFLAGS+=     ${FORTIFY_CFLAGS}
+.  else
+FORTIFY_SOURCE=0
 .  endif
 .endif

That works- it does need an .export FORTIFY_SOURCE line to work, though, otherwise the build will pick up the default in bsd.sys.mk if we aren't adding to C*FLAGS (since the port build would be running in a submake)

In D57628#1321971, @kevans wrote:

All supported releases should have it, but it is also harmless to define any of this when it isn't -- I'd probably avoid complicating it too much.

Without doing any build-test, should the UNSAFE part be "=0" instead of "?=0"? We want a hard override in the UNSAFE case, don't we?

@kevans would it help if I build a known failing port with your ports-patch applied?

This is what I have, this is historically grown and may or may not be an issue today: