runc update: refuse to create new rdt group #4827
Conversation
|
ping @kolyshkin @AkihiroSuda |
marquiz
force-pushed
the
devel/runc-update-rdt-empty-conf
branch
from
fb6195f to
2fd2204
Compare
Error out --l3-cache-schema and --mem-bw-schema if the original spec didn't specify intelRdt which also means that no CLOS (resctrl group) was created for the container. This prevents serious issues in this corner case. First, a CLOS was created but the schemata of the CLOS was not correctly updated. Confusingly, calling runc update twice did the job: the first call created the resctrl group and the seccond call was able to update the schemata. This issue would be relatively easily fixable, though. Second, more severe issue is that creating new CLOSes this way caused them to be orphaned, not being removed when the container exists. This is caused by runc not capturing the updated state (original spec was intelRdt=nil -> no CLOS but after update this is not the case). The most severe problem is that the update only move (or tried to move) the original init process pid but all children escaped the update. Doing this (i.e. migrating all processes of a container from CLOS to another CLOS) reliably, race-free, would probably require freezing the container. Signed-off-by: Markus Lehtonen <[email protected]>
marquiz
force-pushed
the
devel/runc-update-rdt-empty-conf
branch
from
2fd2204 to
85801e8
Compare
kolyshkin
left a comment
kolyshkin
left a comment
There was a problem hiding this comment.
LGTM, thanks!
I think we need to backport it, too.
kolyshkin
added
area/intelrdt
backport/1.2-todo
|
@marquiz can you create backport PRs to release-1.3 and release-1.2 branches? |
Will do, thx EDIT: will do after this is merged |
Isn't this a breaking change? |
Strictly, yes. Because in v1.2 and v1.3 these problematic scenarios are allowed. |
Ah, in this case maybe we don't want to do backports. |
kolyshkin
removed
backport/1.2-todo
|
Let's add a comment to Breaking change: The options |
4 participants
Error out --l3-cache-schema and --mem-bw-schema if the original spec didn't specify intelRdt which also means that no CLOS (resctrl group) was created for the container.
This prevents serious issues in this corner case.
First, a CLOS was created but the schemata of the CLOS was not correctly updated. Confusingly, calling runc update twice did the job: the first call created the resctrl group and the seccond call was able to update the schemata. This issue would be relatively easily fixable, though.
Second, more severe issue is that creating new CLOSes this way caused them to be orphaned, not being removed when the container exists. This is caused by runc not capturing the updated state (original spec was intelRdt=nil -> no CLOS but after update this is not the case).
The most severe problem is that the update only move (or tried to move) the original init process pid but all children escaped the update. Doing this (i.e. migrating all processes of a container from CLOS to another CLOS) reliably, race-free, would probably require freezing the container.