Date: Thu, 19 Sep 2019 14:56:08 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 240687] jail cpuset masks cannot be expanded Message-ID: <bug-240687-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D240687 Bug ID: 240687 Summary: jail cpuset masks cannot be expanded Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: jhb@FreeBSD.org Suppose one creates a simple jail: jail -c name=3Dfoo command=3D/bin/sh It will inherit the default cpuset from the parent jail. You can use cpuse= t -j to shrink this set: % cpuset -g -j 1 jail 1 mask: 0, 1, 2, 3, 4, 5, 6, 7 % cpuset -g -j 1 -r jail 1 mask: 0, 1, 2, 3, 4, 5, 6, 7 % cpuset -j 1 -l 0-3 % cpuset -g -j 1 jail 1 mask: 0, 1, 2, 3 However, once you've shrunk the set, you can never expand it. The reason is that the jail set is its own root, so the check against the 'root' mask in cpuset_modify() fails with EINVAL. I think this is perhaps not the intended behavior. I think that when setting the cpuset of a jail you want to apply= the check against the parent jail's mask, not the jail's own mask. In particular, this prevents using cpuset -j to dynamically manage the CPUs available to jails. The alternative is to leave the jails unrestricted and manage the processes in the jail (or create dedicated, named cpusets for ea= ch jail and manage those) which is not as convenient for tools operating at the abstraction level of a jail. One possibility might be to have cpuset_getroot() always skip over the pass= ed in set to its parent at least once before checking for the ROOT flag (or fix callers to pass set->cs_parent instead of set), but I haven't looked at what other implications that might have. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-240687-227>