docs(scheduler-allocator-runner): requirements, design and tasks; log bug-1892 and bug-1893

Requirements reviewed and revised (seqjob per-bucket reset, nslots/nhosts,
bug-1893 fix in the runner), design and 11-task plan generated and reviewed.
bug-1892: unsatisfy_() reads index-keyed uncommitted amounts by position.
bug-1893: allocators' shared pend-reason loop reads past the unmet list.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

2026-09-30 07:35:14 +00:00

3.3 KiB

Raw Blame History

status

status_updated

status_note

component

severity

timestamp

last_seen

occurrences

files

bug-1893: xce_scheduler allocators add spurious resource-0 shared pend reasons (loop reads past unmet list)

Description

Observed: found by code reading, so there is no failing run yet. When the shared-resource check fails, both allocators add the pend reasons with

for (i = 0; i < ctx->alloc_req.shared.count; i++) {
    rc = vget(core->resmgr, ((int*)ctx->unmeet.idxs.data)[i], (void**)&r);
    if (rc <= 0) continue;
    add_job_preason(reason->reasons, PREASON_NO_RESOURCE, NULL, r->name);
}

(seqjob_allocator.c my_alloc, parjob_allocator.c my_alloc). The loop bound is the number of requested shared resources, but ctx->unmeet holds only the unmet ones, packed at [0, unmeet.count) by unsatisfy_() (resource.c:152-165). Its arrays were calloced with capacity shared.count (resource.c:280), so entries [unmeet.count, shared.count) are 0.

Expected: iterate i < ctx->unmeet.count (as the host path does, resource.c:566), giving one NO_RESOURCE reason per unmet shared resource.

Impact: wrong pend reason, noise level. When a job requests N shared resources and only M < N are unmet, the loop adds N - M extra PREASON_NO_RESOURCE reasons naming whatever resource has index 0 (if one exists), which that job may never have requested. Main reason and allocation decision are unaffected. No out-of-bounds memory access (the tail is inside the allocation).

Found by: review of the scheduler-allocator-runner requirements (2026-09-29); the loop moves into the framework runner in that spec.

Environment

OS: no /etc/os-release; Docker container; NixOS kernel; kernel Linux 6.18.33 x86_64
libc: glibc 2.42-47 (interpreter /nix/store/wb6rhpznjfczwlwx23zmdrrw74bayxw4-glibc-2.42-47/lib/ld-linux-x86-64.so.2)
Toolchain: gcc (GCC) 15.2.0, meson 1.9.1
Build: asan (xce.build)
Code: scheduler-framework @ a370d724-dirty
Deployment: n/a: found by code reading; any deployment where a job requests 2+ shared resources and only some are short

Reproduction

git checkout a370d724; read the loop in src/scheduler/src/plugins/seqjob_allocator.c / parjob_allocator.c my_alloc() (after sched_check_shared_satisfy), and src/scheduler/src/resource.c:130-169,266-316.
Unit-test sketch: resource idx 0 = slots; two shared resources A (idx 7, plenty) and B (idx 8, total 0); a seqjob primary requesting 1 of each. Expected: exactly one host-less reason (NO_RESOURCE, res "B"); today a second reason names slots.

Frequency: deterministic (by code reading; no test exercises it yet)
Evidence: not kept (code reading only)

Root cause

TODO: required for fixed/partial

Fix