threadx.git/ports_smp, branch v6.4.1_cert

Covered the byte allocate's overwritten trace entry

2026-09-21T00:08:56Z

The byte allocate records a trace event on the way in, saves the entry's time stamp, and comes back to write the address it returned into that same entry -- but only if the time stamp says nothing overwrote the entry meanwhile. Nothing in the kernel writes a trace event inside the window, so the other arm had no agent and no test. The Linux SMP port's TX_BYTE_ALLOCATE_EXTENSION gains a second clause, guarded by its own flag and calling a routine the harness declares weakly, in the shape TX_BYTE_RELEASE_EXTENSION already uses. The hook runs between the restore and the disable that bracket the pool search, which on SMP is a real release of the protection rather than an interrupt gap. A new test filters the byte pool event class so the allocate's own insert writes nothing and leaves the buffer parked on the saved entry, then lets the hook write a user event onto it; neither lever reaches the arm without the other. No kernel symbol is replaced and the allocate runs its own code end to end. The macro expands inside tx_byte_allocate.c, so the new clause's if is certified-source branch: the union branch denominator moves from 3610 to 3612 and both new outcomes are covered. The arm closes in trace_build alone. Under TX_MISRA_ENABLE the port's trace time source returns a constant, so the comparison reads 0 == 0 whatever the hook writes, and the test asserts the consequence only where the time source is real. 135/135 in each of eight configurations, 3586/3612 branch outcomes on the union basis against 3583/3610 before. Fifty standalone repeats in each of the eight, no failures. Assisted-by: Claude Code (Opus 5)

Stopped the SMP Linux port leaking a critical section on unprotect

2026-09-18T16:10:07Z

_tx_thread_smp_unprotect takes the Linux mutex on entry and releases it twice when the protection structure names this core, but only once when it does not, while the matching _tx_thread_smp_protect took it once either way. _tx_thread_system_return clears the protection outright, so an unprotect can find it no longer naming its core and return having released one level fewer than were taken. A thread that later reaches _tx_linux_mutex_release_all drains that level. The timer interrupt thread has none on its tick path unless a thread was preempted on core 0, so a level leaked there while core 0 is idle is never recovered: the nesting count never reaches zero, the mutex is never handed back to Linux, and every other thread waits on it for the life of the process while the tick keeps arriving. The release of the level the matching protect took now happens whether or not the protection still names this core. Protection bookkeeping and scheduling are unchanged, and releasing beyond what a thread holds was already a no-op. Two hung processes captured untraced, in different tests, show the timer thread owning the mutex with a nesting count of one while parked in its tick wait, the scheduler blocked in pthread_mutex_timedlock, and the clock advancing 99 ticks a second across a ten second sample while nothing else changes. On a healthy run that path is taken 0 times in 26,546 unprotect calls. Forcing it on the timer thread leaks one level before this change and balances after it. Assisted-by: Claude Code (Opus 5)

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

2026-09-17T22:21:12Z

The SMP Linux port suspends a thread with a signal whose handler calls sigsuspend and does not return until the thread is resumed. That signal can arrive while the thread is parked in pthread_mutex_lock on _tx_linux_mutex; the port knows it can, because _tx_linux_mutex_obtain sets tx_thread_linux_mutex_access around the lock call for exactly this case, and nothing anywhere reads that flag. glibc waits for a contended mutex in a loop that re-arms the futex wait after a signal, and this handler never returns to it. The next release hands its wake-up to that thread, which will not act on it, and any other thread parked on the mutex is never woken, leaving the mutex free with waiters on it. That deadlocks the process: the only thread that can resume the suspended one is the scheduler, and the scheduler takes this mutex on every pass. _tx_linux_mutex_obtain now waits with pthread_mutex_timedlock and retries, so the wait is re-armed every TX_LINUX_MUTEX_RETRY_NSEC and a lost wake-up costs one retry period instead of the process. The period is one millisecond, half the scheduler's own idle period. Nothing else changes. Four hung processes captured untraced, across three tests, show the same state: a thread in sigsuspend on top of pthread_mutex_lock, the scheduler blocked in pthread_mutex_lock, and the mutex reading free. Standalone, threadx_smp_random_resume_suspend_exclusion_test hung 3 times in 100 runs and 2 in 55 before the change and 0 in 400 after it. Assisted-by: Claude Code (Opus 5)

Aligned the simulator ports' fake stack pointer so ThreadX no longer performs misaligned ULONG accesses

2026-09-15T22:05:39Z

The Linux, Win32 and SMP Linux simulation ports build a fake initial stack pointer by subtracting a fixed 8 bytes from tx_thread_stack_end. That field addresses the last byte of the thread's stack area, so it is one less than an aligned address and the resulting pointer is misaligned by construction, however well aligned the stack the application supplied was. Two ULONG accesses then use that pointer. _tx_thread_stack_build() itself clears the word below it, and _tx_thread_create() copies it into tx_thread_stack_highest_ptr, which TX_THREAD_STACK_CHECK dereferences on every suspend and resume when TX_ENABLE_STACK_CHECKING is defined. Both are undefined behaviour. They happen to work on x86 and are reported by GCC's undefined behaviour sanitizer. The fake stack pointer is now rounded down to a ULONG boundary, which leaves it inside the stack area and makes both accesses aligned. This is a backport of the same fix from the development branch. It differs from that version in one respect: the conversions are written inline rather than through TX_POINTER_TO_ALIGN_TYPE_CONVERT and TX_ALIGN_TYPE_TO_POINTER_CONVERT, because tx_api.h defines those two macros only in its non-MISRA branch and the port therefore does not compile with TX_MISRA_ENABLE defined. That defect is reported upstream as issue #741. Substituting the ULONG conversion pair would not be equivalent: ALIGN_TYPE is 64-bit on __x86_64__ while ULONG is 32-bit, so a ULONG round trip would truncate the pointer. No certified source is touched, and coverage is unchanged: 4314/4339 lines and 4546/4627 branches merged over the six build configurations, identical line for line and branch for branch to the measurement before this change. 107 of 107 tests pass in each of the six. Assisted-by: Claude Code (Opus 5)

Update version number to 6.4.1

2024-02-27T06:00:58Z

Update the copyright for all assembly files.

2024-02-23T01:39:05Z

Update version id string.

2024-01-30T00:39:18Z

Update copyright.

2024-01-29T05:51:15Z

Update release date and version (#338)

2023-12-28T02:51:29Z

* Update version number in API header * Update release date and version

Update release version to 6.3.0 and date to 10-31-2023 (#308)

2023-10-23T07:31:03Z