Messages in this thread | | | Date | Wed, 31 Aug 2022 16:53:20 -0400 | Subject | Re: [PATCH v6 4/5] sched: Handle set_cpus_allowed_ptr() & sched_setaffinity() race | From | Waiman Long <> |
| |
On 8/31/22 05:26, Peter Zijlstra wrote: > On Thu, Aug 25, 2022 at 09:01:18PM -0400, Waiman Long wrote: >> Racing is possible between set_cpus_allowed_ptr() and sched_setaffinity() >> or between multiple sched_setaffinity() calls from different CPUs. To >> resolve these race conditions, we need to update both user_cpus_ptr >> and cpus_mask in a single lock critical section instead of separated >> ones. This requires moving the user_cpus_ptr update to >> affine_move_task() before doing task_rq_unlock(). >> >> A new argument puser_mask is added to affine_move_task(), >> __set_cpus_allowed_ptr_locked() and __set_cpus_allowed_ptr() to do that. >> >> Ideally, user_cpus_ptr should only be updated if the sched_setaffinity() >> is successful. However, this patch will update user_cpus_ptr when the >> first call to __set_cpus_allowed_ptr() is successful. However, if there >> is racing between sched_setaffinity() and cpuset update, the subsequent >> calls to __set_cpus_allowed_ptr() may fail but the user_cpus_ptr will >> still be updated in this corner case. > Urgh, this is a bit weird, to have a fix for a patch in the same series.
This is just to make each patch simpler and easier to read.
Cheers, Longman
| |