This series backports the padata use-after-free fix and its follow-up
cleanup to the 5.10.y stable branch. There is a race condition in 
padata_reorder() dating back to the initial padata commit.

Backport notes for 5.10.y:

  - The upstream fix (commit 71203f68c774) was written against mainline
    which uses the 2-argument cpumask_next_wrap(cpu, mask) API introduced
    by dc5bb9b769c9 ("cpumask: deprecate cpumask_next_wrap()"). Since
    6.1.y still has the original 4-argument API, the call in
    padata_reorder() is adapted to:
      cpumask_next_wrap(cpu, pd->cpumask.pcpu, -1, false)
    This is functionally equivalent.

  - The context in padata_find_next() differs from mainline due to
    f954a2d37637 ("padata: switch padata_find_next() to using
    cpumask_next_wrap()") not being present in 6.1.y. The conflict was
    resolved.

After applying this series, kernel/padata.c matches the upstream file at
commit 71203f68c774 with a few differences. None of these differences 
affect the fix, the core changes to padata_find_next(), padata_reorder(), 
and padata_do_serial() are identical.

Testing:
  - Built and booted on x86_64 (4 CPUs)
  - All 4 test cases passed:
    * Basic parallel->serial reorder (64 jobs)
    * Out-of-order parallel completion reorder (64 jobs)
    * Concurrent jobs + padata_replace race (64 jobs)
    * Stress test (10 iterations x 64 jobs, random delays)
  - No KASAN/BUG/WARNING/UAF detected in dmesg

Bin Lan

Herbert Xu (2):
  padata: Fix pd UAF once and for all
  padata: Remove comment for reorder_work

 include/linux/padata.h |   4 --
 kernel/padata.c        | 136 +++++++++++------------------------------
 2 files changed, 37 insertions(+), 103 deletions(-)

-- 
2.43.0