threadx.git, branch v6.4.1_cert

Restored the Linux port mutex retry

2026-10-14T14:57:14Z

This was reverted because a NetX Secure regression test segfaulted with it in place. The cause was the test: it hands the certificate verify path a stack-local certificate whose signature it never assigns, and this change moves the stack layout that decides whether the unassigned slot reads null or a readable leftover. That test has been fixed, so the retry comes back. Measured with the test unfixed and this change in place, on a layout built without the stack protector: eight of eight runs segfault, the fault read from the faulting process as a null signature dereferenced by the ECDSA verify. With the test fixed, nineteen build configurations run it eight times each with no fault. Without this change, a thread signalled into the port's suspend handler never returns to the contended-mutex loop, the next unlock's wake-up is lost, the scheduler is left parked, and the timer interrupt never runs -- which stalls the tick and hangs about 0.39% of instances of a few TCP tests for their full timeout.

Reverted the Linux port mutex retry on this branch

2026-09-30T19:10:15Z

The backport fixes a real deadlock and is right in itself, but on this branch it reproducibly breaks the NetX Duo nx_secure suite: nx_secure_tls_coverage_test segfaults in 8 of 19 configurations on one run and 9 of 19 on a re-run of the same commit, against four consecutive runs with none before it. Whether the retry causes that or merely exposes something latent is not known. The first guess, a kernel object outliving its stack frame, is wrong: that test's sessions are file scope and its creates and deletes balance. The deadlock the retry cures costs one configuration's coverage data at roughly 0.4% of test instances, which the union absorbs, so the branch is measurably worse with it than without while the interaction is unexplained. This is a deferral, not a dismissal. The diagnosis stands, the reproduction is recorded, and re-applying is one cherry-pick. The upstream fix is unaffected. This reverts commit ac95c32c. Assisted-by: Claude Code (Opus 5)

Stopped the Linux port losing a mutex wake-up to a suspend signal

2026-09-30T15:55:52Z

The port suspends a thread with a signal whose handler calls sigsuspend and does not return until resumed, and takes its critical section with a bare pthread_mutex_lock. A thread signalled while parked on _tx_linux_mutex never returns to glibc's contended-mutex loop, so the next unlock's wake-up goes to a thread that will not act on it and every other waiter is left parked on a mutex that is free. tx_linux_mutex_lock now calls a helper that waits with pthread_mutex_timedlock and retries every TX_LINUX_MUTEX_RETRY_NSEC, one millisecond, so a lost wake-up costs a retry period instead of the process. The original fix was made by inspection, on a port never observed to deadlock. It has now been observed. A stalled regression test reads the mutex free, owner zero, with the scheduler still on its futex word; it never posts _tx_linux_isr_semaphore, the timer thread never returns from _tx_thread_context_restore, and the simulated clock stops. Bounding a wait cannot save it: one capture held 116 ticks of timeout unchanged across 40 seconds. Measured on netx_tcp_overlapping_packet_test_10, six workers on four pinned CPUs: 5 stalls in 1,266 runs before, 0 in 2,034 after, three held frozen through 60 seconds of untraced /proc sampling. netxduo/default_build_coverage is unmoved at 914/914, 121 skipped, 497 files, 11230/11256 lines and 6912/6925 branches. (cherry picked from commit b567428f2a826fa24e78fc82f6a5dd46a87b079c) Assisted-by: Claude Code (Opus 5)

Added an opt-in container options input to the regression template

2026-09-27T20:29:07Z

The tests run in a container started with the default capability set, which holds CAP_NET_RAW and not CAP_NET_ADMIN. That is right for every suite that only compiles and runs code, and wrong for the two NetX Duo interoperability suites: each of their tests builds a veth pair and addresses it, so every configuration fails on its first test with "RTNETLINK answers: Operation not permitted" before anything under test has run. Measured on the certification branch, not predicted. The container now takes an options string from the caller, empty unless a caller sets it, so the two jobs that need CAP_NET_ADMIN ask for it and nothing else changes. Granting it here for everyone would widen the privileges of five suites with no use for it. Proof: the template parses and the input defaults to empty, so every existing caller produces the same container arguments as before. Assisted-by: Claude Code (Opus 5)

Excluded the SMP regression-test hook code from the coverage figure

2026-09-23T13:42:51Z

Every SMP build configuration is compiled with -DTX_REGRESSION_TEST, which opens a block in the Linux SMP port header defining ten macros that expand to live code -- flag tests, state changes and calls -- at eleven sites in common_smp/src. An application defines none of them and tx_api.h expands them all to nothing, but gcov attributes a macro expansion to the file that invokes it, so the harness's own scaffolding was being counted as certified source. coverage_union.py now drops those sites and prints what it dropped, covered and total on both axes, so the exclusion can be audited rather than inferred. One site keeps its line: tx_api.h defines TX_TIMER_INITIALIZE_EXTENSION as a real statement under TX_MISRA_ENABLE, so that line ships and only its branches come out. A listed site that no longer matches the report is a hard failure naming the macro, not a silent skip. The branch gate moves 99.05 to 99.04 because the margin is ten outcomes rather than a percentage, and a smaller denominator buys nine at the old value; the line gate is unchanged. The excluded code measured 10 lines and 36 branch outcomes, every one of them covered, so the uncovered set is untouched: the same 24 outcomes at the same 22 sites in the same 13 files, over the same 194 files. Eight configurations from a wiped tree, 136/136 tests in each, 0 failed. The union goes from 5449/5450 lines and 3588/3612 branch outcomes to 5439/5440 and 3552/3576, re-derived key by key against the previous measurement. gcovr's merged report is published unchanged. Assisted-by: Claude Code (Opus 5)

Excluded the regression-test hook code from the coverage denominator

2026-09-23T11:39:47Z

The test build defines TX_REGRESSION_TEST for every configuration, which opens a block in the Linux port header defining eight *_EXTENSION macros. They expand to live code -- flag tests, state changes and calls -- at eight sites in common/src, and an application defines none of them and compiles none of it. gcov attributes a macro expansion to the file that invokes it, so the harness's own scaffolding was being counted as certified source. coverage_union.py now drops those expansions and prints what it dropped beside the configurations it merged, so the exclusion is auditable, and a site that no longer matches the report fails the run rather than being skipped. tx_timer_initialize.c:275 keeps its line and loses only its branches: it is the one macro whose tx_api.h fallback is not empty, so under TX_MISRA_ENABLE that line still carries a statement in a build that ships. gcovr's merged report is not touched. The hook code is 8 lines and 22 branch outcomes, all covered, 0.183% of lines and 0.694% of outcomes. The union goes from 4383/4383 and 3150/3170 to 4376/4376 and 3128/3148: line coverage stays at 100.00%, and the branch rate falls from 99.36909% to 99.364676%, since removing an all-covered block from a figure below 100% moves it down. Both thresholds are unchanged and both pass, the branch one by 0.15 of an outcome. Seven configurations from a wiped tree, 115/115 tests in each, and the twenty uncovered outcomes are the same twenty at the same sixteen sites. Assisted-by: Claude Code (Opus 5)

Corrected the gate comment's count of single-carrier outcomes

2026-09-21T12:36:35Z

The comment added in the previous commit said six outcomes in the figure have no configuration to cover for them. That was the count of outcomes that both have a single carrier and were seen moving between runs, not the count of single-carrier outcomes, and as written it is wrong. Measured over sixteen runs at two commits: thirty-five outcomes are compiled by two configurations and covered by only one of them in at least one run, almost all TX_THREAD_STACK_CHECK fence ordinals that stack_checking_build holds alone because its random-fill sibling short-circuits before them. A further 894 are compiled by exactly one configuration at all, which is structural rather than fragile, the racing outcome excepted. The margin's justification is restated on the figure that actually sizes it: the largest movement observed in any one configuration is eight outcomes, and the margin is ten. No threshold changes. The gate stays at 99.79 line and 99.05 branch, and sixteen runs read 5449/5450 lines and 3588/3612 branch outcomes on the union basis with an empty unstable set on both axes. Assisted-by: Claude Code (Opus 5)

Settled the SMP coverage gate margin on the evidence measurement

2026-09-21T12:18:43Z

The gate's comment left open whether the ten-line, ten-outcome margin could be removed once the unstable set closed, and deferred the answer to the coverage evidence work. It has now been measured. The thresholds do not move, and the comment records why. Read per configuration over eight CI runs at one commit, eight branch outcomes and four lines move between runs, and six outcomes in the published figure are compiled by only one configuration that covers them: five TX_THREAD_STACK_CHECK arms that stack_checking_build carries alone in most runs, because stack_checking_rand_fill_build misses them in seven and four runs of eight, and the trace race outcome, which only trace_build compiles. The union figure is stable because the eight configurations cover for each other, not because the suite is deterministic, so a zero-margin gate would read a runner's timing as a regression. Eight runs at the preceding commit read 5449/5450 lines and 3588/3612 branch outcomes identically on the union basis, unstable set empty on both axes, 136/136 tests in each of the 64 configuration-runs. gcovr's merged report over those same runs reads 6561, 6563 and 6564 of 6601, which is the same movement seen through a denominator that does not collapse it. Assisted-by: Claude Code (Opus 5)

Raised the SMP gate onto the floor the trace race test lifted

2026-09-21T04:01:02Z

The coverage ratchet sat at 99.03 branch, set below the 3587 outcomes every run of the previous sample reached. Covering the user event insert's disabled-buffer arm moves that floor by one. Raised to 99.05, still ten outcomes below the set covered in every run, which is now 3588 of 3612. The line gate is unchanged at 99.79: neither the line total nor its denominator moved. The comment above the thresholds gains the one thing about this figure a later reader has to know -- a single outcome in it is reached by two cores racing rather than by a thread doing something in order, and it is counted in the always-covered set on a measurement over ten runs on two machines rather than on one sample. Seven CI runs at the test head, all green, 136/136 in each of eight configurations, 5449/5450 and 3588/3612 in every one. Two clean local cycles read the same two totals. Assisted-by: Claude Code (Opus 5)

Covered the user event insert's own test of a disabled trace buffer

2026-09-21T04:01:02Z

_tx_trace_user_event_insert tests the trace buffer pointer and returns TX_NOT_DONE if it is null; the insert sits in the else, and the macro reads the same variable and tests it again a few instructions later, inside one protection with nothing between. The second test's false arm had no route on one core and was carried as unreachable. It is an ordinary state of the running kernel on SMP, and no fault has to be invented for it. _tx_trace_disable clears that pointer and takes no lock of any kind, so a thread disabling tracing on one core while another is inside the insert clears it under that core. A new test drives 300,000 inserts against a second thread on a core of its own writing the same store the disable service writes. No kernel symbol is replaced and both services run their own code from end to end; the test asserts that the two threads held different cores and that the writer's stores reached the service, and says in the file that the arm itself is evidenced by the coverage report because nothing outside the macro can observe it. The pass count is sized from measurement on the slower of two machines. The arm is taken 49 to 132 times per run on this workstation over three runs and 521 to 1298 times per run on a CI runner over seven. 136/136 in each of eight configurations, twice from clean, 3588/3612 branch outcomes on the union basis against 3587/3612 before. Fifty standalone repeats in each of the eight, no failures. Assisted-by: Claude Code (Opus 5)