slurmctld - Restore qos_ptr after multi-QOS job-queue build

[Yash0270]

Problem

A job submitted with multiple QOS (--qos=a,b) is evaluated against each qos_list member during scheduling: _build_job_queue_for_qos() (src/slurmctld/job_scheduler.c) sets job_ptr->qos_ptr to each member to test runnability, but never restores it. After the loop, job_ptr->qos_ptr is left pointing at the last-iterated (lowest-priority) member, on every scheduling cycle.

Both per-user/per-account QOS TRES accounting (acct_policy) and the priority/multifactor tres_run_secs decay key usage on job_ptr->qos_ptr. Leaving it on a stale member can cause a multi-QOS job's TRES (e.g. gres/gpu) to be charged/uncharged against the wrong QOS member.

Fix

After the per-member test loop, reset job_ptr->qos_ptr to the highest-priority member (the pending default), mirroring how pending multi-QOS jobs are resolved elsewhere (_set_highest_prio_qos_ptr() / _foreach_cache_update_job()). The job_queue entries already captured their own qos_ptr at append time (job_queue_rec->qos_ptr), so dispatch is unaffected; only the job's transient live pointer is reset.

Testing

Built slurmctld from source and ran a multi-QOS workload on a two-node from-source cluster (low = per-user GRES cap, high = GrpTRES group cap). A multi-QOS job array distributed across both members stays correctly attributed per member across scheduling cycles and scontrol reconfigure (4 high / 4 low preserved), whereas without the fix the jobs collapse onto the highest-priority member.

Target Release

26.05 (bug fix).

Related

Companion multi-QOS qos_ptr-consistency fix for the state-reload path: #207. Same class of bug (a running multi-QOS job's qos_ptr left on the wrong qos_list member, mis-charging accounting), different code path.

[Yash0270]

Closing as redundant. On review, the stale job_ptr->qos_ptr left after the queue-build loop is only ever parked on a pending job, and it is always NULLed or re-resolved before the QOS record it points to is freed: both the full assoc_mgr refresh (_foreach_cache_update_job) and incremental QOS removal (job_hold_by_qos_id -> job_fail_qos) do this under job_write_lock, which excludes the scheduler. So it prevents no use-after-free and no observable misaccounting. The genuine multi-QOS reload misattribution fix is tracked in #207.