limit_seed_config_impl() key_add()ed each pushed limit into the existing table and returned at the first failure, so on any second push (live config upgrade, or a simulator CONFIG_PUSH since bug-1964) the first already-present name failed with -EEXIST: changed limits kept the old definition and later new limits were never added. A push now builds the whole new limit set into a fresh table and swaps it in (all-or-nothing: on any build/register failure the previous set and its instances stay). Usage instances are carried across: an instance of a kept limit whose scoping and resource are unchanged is rebound to the new definition; an instance of a removed limit, or of one whose per-consumer scoping, resource or percent changed, is dropped and re-created on the next match. Usage itself lives in the resource manager under the instance's virtual resource, so counts survive either way. Not part of the snapshot (a snapshot carries the config and reseeds from it). The seed moves to plugins/limit_config.c (limit.c is near the 800-line cap) with the private data type in plugins/limit_internal.h. Two REPL limit-table fixtures relied on the additive behaviour (two single-limit pushes) and now configure both limits in one push. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| autoscaler | ||
| configs | ||
| controller | ||
| docs | ||
| frontend | ||
| harness | ||
| include | ||
| lib | ||
| nixSupport | ||
| scheduler | ||
| schema | ||
| tools | ||
| worker | ||
| xceadmin | ||
| flake.lock | ||
| flake.nix | ||
| meson.build | ||
| meson.options | ||