cmcfarlen opened a new pull request, #13454:
URL: https://github.com/apache/trafficserver/pull/13454
## Draft — CI verification
Backports the remap-table refcount race fix to `10.2.x`, adapted to this
branch's
config-reload code. The fix is on master as `709443e870`; it was deferred
from the
Release 2 backport (#13452) because master's version is entangled with
remap.yaml and
the `ConfigRegistry::attach()` API, neither of which is on 10.2.x.
### The race
The global remap table's `load()` and `acquire()` ran as two unsynchronized
steps, while
config reload swapped the table and released the old one without a mutex. A
reader
preempted between load and acquire could revive a table whose refcount
reload had just
driven to zero — after the deleter was already scheduled — a use-after-free.
### The fix
- Retire the bespoke `acquire()/release()` refcount on `UrlRewrite`; use
`std::atomic<std::shared_ptr<UrlRewrite>>` (via a new `AtomicSharedPtr`
helper) for
publish-and-replace.
- Each transaction snapshots the current table into `HttpSM::m_remap` at
session start;
reload `exchange()`s in a new `shared_ptr` and drops its ref, so the old
table destructs
only after the last in-flight `HttpSM` releases its snapshot.
- `shutdown_url_rewrite()` drains and inhibits further drops so plugin
`doneInstance()`
runs while `this_ethread()` is still valid.
- Second commit guards remap consumers against a null table during the
shutdown window
(quiet defensive remap miss), preventing a crash in
`RemapProcessor::setup_for_remap`
when a transaction is created after the table is torn down.
### 10.2.x adaptation
Kept this branch's `register_config(…)` + `CfgLoad*` reload instrumentation
and scoped
enums; grafted the `AtomicSharedPtr` lifecycle onto them.
### Testing
Local build clean; `ctest` 157/158 (the one failure is the pre-existing macOS
`test_jsonrpcserver` unix-socket flake, unrelated). Note: the unit tests do
not exercise
the reload race itself — a config-reload-under-load check is the meaningful
CI signal here.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
