Why:
The atomic helper header had minor cleanup issues and two no-atomics
fallbacks did not match the contracts of the GCC builtins they replace.
Keeping these semantics aligned matters for portability builds.
Impact:
No behavior change when compiler atomic builtins are available. Builds
without atomic builtins now get matching OR and CAS return semantics.
Before/After:
Before, the fallback OR helper assigned the value, and CAS_VAL returned
the value after the operation. After, they match the builtin behavior.
Technical Overview:
Fix comment and URL typos left in runtime/atomic.h and remove a stray
semicolon from the ATOMIC_CAS_VAL builtin macro. Parenthesize data in the
atomic CAS builtin wrappers for macro consistency. In the mutex fallback,
make ATOMIC_OR_INT_TO_INT apply bitwise OR and make ATOMIC_CAS_VAL save
and return the previous value before any successful replacement.
With the help of AI-Agents: Codex
Use the uint64 atomic helper path when updating the journal disk usage
stat from reader threads. The value remains a best-effort statistic.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Why: Make atomic helper expectations explicit for maintainers and tooling.
Impact: Documentation only; no behavior change.
Before/After: Before: header lacked usage guidance. After: added a usage section that clarifies constraints.
Technical Overview:
- Document helper mutex expectations across atomic/non-atomic builds.
- Explain best-effort PREFER_* semantics and when they are safe.
- Emphasize word-sized constraints and safe argument usage.
- Warn against mixing atomic helpers with plain accesses.
With the help of AI-Agents: ChatGPT
Motivation: CI surfaced TSAN-related flakes suggesting a threading edge
case. This change keeps the atomic fast path efficient and makes the
non-atomic slow path portable and safe. No real-world bug reports.
Impact: Non-atomic builds avoid a nested-lock scenario in worker init.
Atomic builds retain the lock-free fast path. No API/ABI change.
Before/After: non-atomic builds could check instance existence via a
mutex-backed fallback while holding the same mutex / the check happens
under a single mutex (or via atomics), preventing self-deadlock.
Technical: when HAVE_ATOMIC_BUILTINS is set, perform a fast pointer read
and re-check under mutWrkrDataTable (double-checked locking). On
non-atomic toolchains, take mutWrkrDataTable once and read actWrkrData
directly, avoiding fallback atomics that would re-lock the same mutex.
Provide pointer atomics for both __sync-based and mutex-backed paths, and
return type fix for ATOMIC_FETCH_32BIT_unsigned. Also reverts a recent
fix-attempt from earlier this week that introduced the nested-lock risk
on non-atomic builds. Add ommysql README with TSAN context and extend
tsan-rt.supp for libmysqlclient. Minor whitespace tweaks in diag.sh.
Tests/Docs: ommysql/README.md added (TSAN notes), tsan-rt.supp extended.
With the help of AI-Agents: Claude (Anthropic), Codex
Fixed a critical race condition where wtpSetState() used a plain store
while readers (wtpChkStopWrkr) used atomic loads. This violated the C11
memory model and created undefined behavior, causing shutdown delays and
potential message loss.
The fix introduces ATOMIC_STORE_INT macro and updates wtpSetState() to
use atomic stores, ensuring proper memory barriers and visibility across
all worker threads on all architectures.
Root cause: Mixed synchronization - plain store on writer side, atomic
load on reader side creates data race per C11 §5.1.2.4.
Impact:
- Ensures SHUTDOWN_IMMEDIATE signal is immediately visible
- Prevents shutdown timeouts and forced termination
- Provides proper memory ordering on ARM and weak-memory architectures
- No performance regression (atomic operations are hardware-optimized)
Testing:
- Builds successfully on x86_64
- Passes smoke test (imtcp-basic.sh)
- Verified synchronization consistency between reader/writer
With the help of AI Agents: GitHub Copilot
Trailing semicolons in atomic helper macros caused double
semicolons when the macros expanded, producing build warnings.
Macros now omit semicolons and call sites add them explicitly.
STATSCOUNTER_DEF updated to terminate the generated mutex line.
AI-Agent: ChatGPT
This commit applies the new canonical formatting style using `clang-format` with custom settings (notably 4-space indentation), as part of our shift toward automated formatting normalization.
⚠️ No functional changes are included — only whitespace and layout modifications as produced by `clang-format`.
This change is part of the formatting modernization strategy discussed in:
https://github.com/rsyslog/rsyslog/issues/5747
Key context:
- Formatting is now treated as a disposable view, normalized via tooling.
- The `.clang-format` file defines the canonical style.
- A fixup script (`devtools/format-code.sh`) handles remaining edge cases.
- Formatting commits are added to `.git-blame-ignore-revs` to reduce noise.
- Developers remain free to format code however they prefer locally.
New parameters for mmkubernetes (module and action):
* `cacheexpireinterval`
If `cacheexpireinterval` is -1, then do not check for cache expiration.
If `cacheexpireinterval` is 0, then check for cache expiration.
If `cacheexpireinterval` is greater than 0, check for cache expiration
if the last time we checked was more than this many seconds ago.
* `cacheentryttl` - maximum age in seconds for cache entries
New statistics counters:
* `podcachenumentries` - the number of entries in the pod metadata cache.
* `namespacecachenumentries` - the number of entries in the namespace
metadata cache.
* `podcachehits` - the number of times a requested entry was found in the
pod metadata cache.
* `namespacecachehits` - the number of times a requested entry was found
in the namespace metadata cache.
* `podcachemisses` - the number of times a requested entry was not found
in the pod metadata cache, and had to be requested from Kubernetes.
* `namespacecachemisses` - the number of times a requested entry was not
found in the namespace metadata cache, and had to be requested from
Kubernetes.
macro used unsigned, inline function int. This could lead to an unsigned
overflow if macro version was used. That could potentially lead to malfunction
on some platforms (not seen nor expected in practice, though).
Detected by clang UBSAN.
During e.g. shutdown it could happen that a worker thread was started
and immediately be requested to terminate. In such situations there was
a race the prevented proper initialization. This could lead to follow-on
problems.
We believe (but could not proof) that this also could lead to a hang of
the termination process. Thus we claim to close an issue tracker down
here below, but are not 100% certain it really closes it (we hope for
user feedback on this). In any case, the thread debuger showed invalid
operations and this has been fixed, so it is useful in any case.
closes https://github.com/rsyslog/rsyslog/issues/1959
This is not a real problem because imdiag intentionally does multiple
tries to validate predicate validity. However, this is reported in
clang thread sanitizer and so we need to fix it.
this was previously not properly handeld. This is also the first occurence of
a (real) CAS loop inside rsyslog. Note that the performance is now very well
in the default configuration, and mark message directives are still correctly
being handled. So this code looks close to final, but needs to have some
bug cleanup as the testsuite shows.
replaced atomic operation emulation with new code. The previous code
seemed to have some issue and also limited concurrency severely. The
whole atomic operation emulation has been rewritten.
... but this is not considered a real solution. For some of the
uses, it may acutally be sufficient, but the implications need
to be analyzed in detail.
This may have caused a segfault under strange circumstances (but if
we just run long enough with a high enough message volume, even the
strangest circumstances will occur...)
There was a wrong order of mutex lock operations. It is hard to
believe that really caused problems, but in theory it could and with
threading we often see that theory becomes practice if something is only
used long enough on a fast enough machine with enough CPUs ;)
there are still some files left which could go into the
runtime, but I think we will delete most of them once we
are done with the full modularization.
