Re: [PATCH v4 3/3] cgroup/cpuset: Keep user set cpus affinity

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [Monitors]

  Powered by Linux