On Tue, Jun 28, 2022 at 04:10:29AM +0900, Tejun Heo tj@kernel.org wrote:
What I'm trying to say is that cpuset.cpus of child_1 and child_2 are owned by the parent,
Cf
On Mon, Jun 13, 2022 at 08:00:56AM -1000, Tejun Heo tj@kernel.org wrote:
On Mon, Jun 13, 2022 at 07:55:49PM +0200, Michal Koutný wrote:
I don't think child_*/cpuset.cpus must be owned by root.
I meant the parent.
I'm slightly confused.
so a feature which blocks siblings from intersecting each other doesn't make whole lot of sense because all those files are under the control of the parent who would have the power to enable or disable the restrition anyway.
file owner parent/ user (mkdir) `- cpuset.cpus root `- cpuset.cpus.partition root (P) `- child_1/ user ` cpuset.cpus user (*) `- child_2/ user ` cpuset.cpus user (*)
The writes to child cpuset.cpus may/may not invalidate parent's (P) partition validity (whether a cpu is left to it to host possible tasks). child_1 vs child_2 overlap affects only whether the children cgroups are a valid partition.
I think you mean: writes to children cpuset.cpus should be allowed, possible exclusivity violation should be reported in parent/cpuset.cpus.partition.
What I thought was OK: prevent (fail) writes to children cpuset.cpus that'd violate the exclusivity (or would take the last cpu from parent if it's necessary to host a task). IMO, it's similar to failed writes to parent/cgroup.subtree_control in a delegated subtree if the parent still has some tasks (that'd violate internal node constraint).
What I think might still be OK: allow writes to children cpuset.cpus that violate exclusivity and report that in children's cpuset.cpus.partition. Writes that'd take last cpu from parent should still fail (similar to the failing subtree_control writes above).
Hope that clarifies, Michal