[codex] Fix IAR file lock mutex bounds

[Old-Ding]

Summary

• update IAR file lock mutex allocation bounds to use _MAX_FLOCK
• keep system lock allocation bounds on _MAX_LOCK
• apply the same fix across the duplicated IAR ThreadX port sources

Root cause

The file lock mutex pool is sized with _MAX_FLOCK, but its round-robin allocation checks used _MAX_LOCK in two places. When _MAX_FLOCK is larger than _MAX_LOCK, the allocator can wrap or report exhaustion using the system-lock limit instead of the file-lock pool size.

Validation

• git diff --check
• verified all 26 changed files only replace the file-lock wrap/no-free checks from _MAX_LOCK to _MAX_FLOCK
• verified no remaining file_lock references use _MAX_LOCK

CI notes

• Current required eclipsefdn/eca failure says the PR author is not covered by the required Eclipse legal agreements.
• This is an account/legal gate, not a code failure in the IAR file-lock mutex diff.

[fdesbiens]

Thank you for this contribution, @Old-Ding.

Before we can accept it, you need to sign the Eclipse Contributor Agreement (ECA). The purpose of the ECA is to provide a written record that you have agreed to provide your code and documentation contributions under the licenses used by the Eclipse ThreadX project. It also makes it clear that you are promising that what you are contributing to Eclipse is code you wrote, and you have the necessary rights to contribute it to our projects. And finally, it documents a commitment from you that your open source contributions will be permanently on the public record.

Signing the ECA requires an Eclipse Foundation account if you do not already have one. You can create one for free at https://accounts.eclipse.org.

Be sure to use the same email address when you register for the account that you intend to use on Git commit records. Also, please add your GitHub ID to your Eclipse account. This enables synchronisation between Eclipse-owned infrastructure and GitHub.

Here is the link to sign the ECA:
https://accounts.eclipse.org/user/login?destination=user/eca

[fdesbiens]

Also, another comment.

If this contribution has been assisted or authored by AI, make sure you conform to the official Generative Artificial Intelligence Usage Guidelines for Eclipse Committers found in the project handbook.

[fdesbiens]

I checked this one carefully because a 26-file search-and-replace is easy to get subtly wrong, and it holds up. The bug is real and the fix is right.

The bug

The file-lock block sizes its pool with _MAX_FLOCK and loops to _MAX_FLOCK, but bounds the round robin and the exhaustion test with _MAX_LOCK:

TX_MUTEX    __tx_iar_file_lock_mutexes[_MAX_FLOCK];
...
    for (i = 0; i < _MAX_FLOCK; i++)
    {
        mutex_ptr =  &__tx_iar_file_lock_mutexes[__tx_iar_file_lock_next_free_mutex++];
        if (__tx_iar_file_lock_next_free_mutex >= _MAX_LOCK)     /* wrong bound */
        ...
    }
    if (i >= _MAX_LOCK)                                          /* wrong bound */

The system-lock block immediately above is correct throughout, which is what makes this look like a copy-paste that was only half adjusted.

With the values the module ports declare — _MAX_LOCK 4 and _MAX_FLOCK as FOPEN_MAX, which the C standard puts at 8 or more — the round robin wraps after slot 3, so the upper half of the pool is never handed out. A program that opens more than _MAX_LOCK files gets a lock failure while the pool still has free entries.

Worth recording the inverse, since it is the reason this is worth fixing rather than tidying: if a configuration ever had _MAX_FLOCK smaller than _MAX_LOCK, the wrap test would not fire in time and the allocator would index past the end of __tx_iar_file_lock_mutexes. That is an out-of-bounds write rather than a capacity problem. No in-tree configuration does that today, but nothing in the code prevents it.

What I verified

• Every changed line is one of exactly two forms, both inside the file-lock block. Nothing else moved.
• No system-lock block was switched to _MAX_FLOCK by mistake — checked programmatically across all 26 files, not by eye.
• All 26 tx_iar.c copies in the tree now have the file-lock block bounded by _MAX_FLOCK, including the three ports_arch sources of truth. Editing the generated copies and their source is the right way round.

Three things before this can go in

Retarget to dev. This targets master; the other port work has been landing on dev.

Rebase and re-run the generators. Cortex-M52 arrived in #519 after you opened this, and it was generated from the unfixed source, so it carries the same bug. Rebasing onto dev and running scripts/copy_armv7_m.sh, scripts/copy_armv8_m.sh and scripts/copy_module_armv7_m.sh picks it up automatically — ports/cortex_m52/iar/src/tx_iar.c is the twenty-seventh file. scripts/check_ports.sh currently reports that one file as drift; after regenerating it passes.

The ECA. Your CI note is right that this is a legal gate rather than a code problem, but it is a hard gate: nothing can be merged until the Eclipse Contributor Agreement is signed with the same email address as your commits. https://www.eclipse.org/legal/eca/

Also, this is still marked as a draft — mark it ready when the above is done.

Thank you for the clear root-cause description in the PR body; it made this quick to confirm.