On 8/16/22 13:52, Tejun Heo wrote:
Hello,
On Tue, Aug 16, 2022 at 01:38:17PM -0400, Waiman Long wrote:
Yes, a race like this is possible. To completely eliminate the race may
require taking task_rq_lock() and then calling
__set_cpus_allowed_ptr_locked() which is internal to kernel/sched/core.c.
Alternatively, we can check user_cpus_ptr again after the scond
set_cpus_allowed_ptr() and retry it with the other path if set. That will
probably address your concern. Please let me know if you are OK with that.
I think this would look better if structured the other way around - make the
scheduler side call out to cpuset to query the current restrictions and
apply it atomically.
The sched_setaffinity() function does call cpuset_cpus_allowed() to
apply the cpuset constraint. However, making set_cpus_allowed_ptr() call
cpuset function is a major change. It will disturb the current locking
sequences and may cause circular locking dependency problem. We
certainly need more time to figure out if that is feasible.
In the mean time, I would prefer to do a retry if user_cpus_ptr status
changes for now. We can then do a follow up patch to make this
structural change if there is a consensus of doing so.
Cheers,
Longman
