fix(scheduler-sim-diagnostics): bootstrap limit plugin in sim mode (bug-1825)

info limit was correctly implemented and tested but inert against a real
replay: register_limit()'s only call site was normal-mode sched_register_
plugins(); sim mode's own plugin bootstrap (sim_bootstrap_picker()) never
registered the limit plugin. The snapshot format already carries the
original session's limit config (sim->core.config, a borrowed reference set
by xce_sched_core_load_snapshot()) -- nothing needed to change in the
recording/replay format.

New sim_bootstrap_limit_plugin() (sim_limit.c, mirroring sim_picker.c's
structure) registers the plugin via plugin_register_core() and seeds it via
a new limit_seed_config(plugin, xce_sched_core_t* core, config) entry point,
wired into sim_loop.c alongside the existing sim_bootstrap_picker() call.
limit_new_plugin() extracted from register_limit() as a factory, mirroring
builtin_fcfs_new_plugin()'s established pattern; register_limit() itself is
behavior-preserving.

First attempt set plugin->sched to a disguised xce_sched_sim_driver_t*,
relying on it sharing xce_scheduler_t's first-member layout to reuse the
existing config_hook path -- rejected on review: this repeats the exact
cross-cast pattern that already corrupted memory once in this codebase (see
core.h's xce_core_cache_clear_cb_t history). Fixed by making
limit_seed_config() take xce_sched_core_t* as an honest parameter instead,
with limit_update_config() (normal mode) and the new sim path both
delegating to a shared limit_seed_config_impl() -- no cast, no aliasing risk,
independently verified by two review rounds reading the actual struct
layouts and call chains.

Also added sim_limit.c to sched_sim_isolation_lib so Req 5 AC 17's
controller-I/O-isolation check covers it (an initial gap, closed in the same
remediation round). Two ripple waves of the same established link-stub
pattern applied to the ~24 white-box test files that #include sim_loop.c.

info limit now shows real configured-limit data against a genuine replay.
Live usage will still correctly show "no active usage instance yet" until a
separate, larger fix (logged as bug-1826) wires limit *matching* into the
sim decision path -- deliberately out of this task's scope.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RLSNJhNoULvVcUhXEFafQC
This commit is contained in:
Rongsong Shen 2026-09-18 04:46:49 +00:00
parent 2f1ffd1e4a
commit 487e7b9419
No known key found for this signature in database
GPG key ID: 5BCDAAE0123E9FE2
32 changed files with 1377 additions and 28 deletions

View file

@ -115,6 +115,40 @@ extern int register_fcfs(void*);
extern int register_builtin_fcfs(void*);
extern int register_limit(void*);
/*
* limit_new_plugin - factory half of register_limit()'s template-build
* step (plugins/limit.c), extracted so a caller with no xce_scheduler_t*
* (e.g. the simulation driver, via plugin_register_core() below) can
* obtain a freshly calloc'd, fully populated `xce_sched_plugin_t` for the
* limit plugin -- same hooks/init_fn/fini_fn template register_limit()
* itself uses, just not yet registered anywhere. Mirrors
* builtin_fcfs_new_plugin()'s identical extraction (below) exactly
* (scheduler-sim-diagnostics spec, task 6; bug-1825). Returns NULL on
* allocation failure. Caller owns the returned plugin (frees it only on a
* subsequent registration failure -- once registered, the plugin registry
* owns it, same lifetime rule every other plugin category in this
* codebase already follows).
*/
extern xce_sched_plugin_t* limit_new_plugin(void);
/*
* limit_seed_config - bug-1825 remediation round 2 (scheduler-sim-
* diagnostics spec, task 6): honestly-typed config-seed entry point for a
* caller that holds a real xce_sched_core_t* but no real xce_scheduler_t*
* -- the simulation driver (sim_limit.c's sim_bootstrap_limit_plugin()),
* whose xce_sched_sim_driver_t (sim.h) has no xce_scheduler_t to point
* plugin->sched at. Takes `core` directly with no cast and never touches
* plugin->sched -- see the function's own doc comment (plugins/limit.c)
* for why a plugin->sched type-pun is unsafe here (core.h's
* xce_core_cache_clear_cb_t doc comment documents the real production bug
* this avoids repeating). Delegates to the same seed logic
* limit_update_config() (the normal-mode config_hook) itself uses, so the
* two entry points cannot silently diverge in behavior.
*/
extern int limit_seed_config(xce_sched_plugin_t* plugin,
xce_sched_core_t* core,
xce_conf4sched_t* config);
/* limit_get_configured_limits/limit_get_usage_instances - scheduler-sim-
* diagnostics spec, Requirement Set 1 (Limit Plugin Accessor), task 1.
* Read-only crossing of the plugin-private-state boundary: each looks up