Commit ee9c669f9bf5 for kernel

commit ee9c669f9bf5fd2c24206746ded9382fe810df89
Merge: e8dfd03a1c51 4409a85735cd
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Sep 24 15:04:11 2026 -0700

    Merge tag 'sched_ext-for-7.3-rc4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext

    Pull sched_ext fixes from Tejun Heo:

     - A task reenqueued while its dispatch was still completing had its
       queued state clobbered by the dispatcher, dropping every later
       dispatch of the task. Wait for the in-flight dispatch to settle
       first

     - A wakeup activation on another CPU marked the destination runqueue as
       mid-wakeup, stranding a pending local reenqueue. If the scheduler was
       unloaded first, the stale request pointed into freed memory that the
       next scheduler dereferenced

     - ops.dequeue() ran with the source dispatch queue's lock held, so a
       scheduler iterating that queue from the callback deadlocked the CPU

     - Schedulers with their own CPU ID mapping had no way to learn a task's
       initial CPU mask and rebuilt it themselves, which went wrong across
       sub-scheduler enable and re-home. Pass it to ops.enable()

     - A bypass dispatch event counter missed the dispatches made by the
       end-of-dispatch fallback and under-reported

     - Selftests for the dequeue locking and initial mask changes

    * tag 'sched_ext-for-7.3-rc4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext:
      sched_ext: Count SCX_EV_SUB_BYPASS_DISPATCH in the dispatch fallback
      selftests/sched_ext: Check the cmask cid-form ops.enable() receives
      sched_ext: Pass the initial cmask to cid-form ops.enable()
      selftests/sched_ext: Test that ops.dequeue() can iterate the consumed DSQ
      sched_ext: Don't run ops.dequeue() with a DSQ lock held
      sched_ext: Derive SCX_RQ_IN_WAKEUP from the core enqueue flags
      sched_ext: Wait for SCX_OPSS_DISPATCHING before reenqueueing a task