| Age | Commit message (Collapse) | Author |
|---|
|
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) <[email protected]>
|
|
_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) <[email protected]>
|
|
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) <[email protected]>
|
|
performs misaligned ULONG accesses
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) <[email protected]>
|
|
|
|
|
|
|
|
* Update version number in API header
* Update release date and version
|
|
|
|
cee19603d Include tx_user.h conditionally.
e40e08007 Update owners
d69641273 Update release date and version
394aee52f Add tx_user.h to GNU port assembly files
5cca2ddd0 RISC-V 64 bit port for Microchip
e0f2c373c Link Winmm.lib that required by the high-resolution timer.
6af472a68 Update Win32 port with high resolution timer.
aea7b556a Add DMB ISH barrier inst in ARMv8-A SMP scheduler
19091a262 Add .section .preamble to m3 m4 m7 module ports
ced60e1b7 Add missing parenthesis in ports assembly file
309dc77ca Modules Cortex-A7 IAR new port
c752a4063 Modules Cortex-A7 GNU new port
dc224b90f Fix race condition in tx_thread_wait_abort and update regression test
6e261f5b7 create threadx cmsis-pack
|
|
|
|
|
|
|
|
|
