-
Notifications
You must be signed in to change notification settings - Fork 3.8k
[release/1.7 backport] containerd-shim-runc-v2: avoid potential deadlock in create handler #9209
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[release/1.7 backport] containerd-shim-runc-v2: avoid potential deadlock in create handler #9209
Conversation
|
Looks like we may be missing something in this branch; |
|
Signed-off-by: Marat Radchenko <marat@slonopotamus.org> (cherry picked from commit 9e34b8b) Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Previous code has already called `getContainer()`, just pass it into `s.getContainerPids` to reduce unnecessary lock and map lookup. Signed-off-by: Chen Yiyang <cyyzero@qq.com> (cherry picked from commit 6604ff6) Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
After pr containerd#8617, create handler of containerd-shim-runc-v2 will call handleStarted() to record the init process and handle its exit. Init process wouldn't quit so early in normal circumstances. But if this screnario occurs, handleStarted() will call handleProcessExit(), which will cause deadlock because create() had acquired s.mu, and handleProcessExit() will try to lock it again. So, I added a parameter muLocked to handleStarted to indicate whether or not s.mu is currently locked, and thus deciding whether or not to lock it when calling handleProcessExit. Fix: containerd#9103 Signed-off-by: Chen Yiyang <cyyzero@qq.com> (cherry picked from commit 68dd47e) Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2febc4d to
2eee3df
Compare
|
Should the new test be skipped for |
Signed-off-by: Wei Fu <fuweid89@gmail.com> (cherry picked from commit 11a7751) Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2eee3df to
d0a1fed
Compare
| if getRuntimeVersion() == "v1" { | ||
| t.Skip("skip it when using shim v1") | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks @fuweid (let's see if it goes green with this patch added); I'll update the 1.6 PR as well
|
/retest |
fuweid
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
After pr #8617, create handler of containerd-shim-runc-v2 will
call handleStarted() to record the init process and handle its exit.
Although init process wouldn't quit so early in normal circumstances.
But if this screnario occurs, handleStarted() will call
handleProcessExit(), which will cause deadlock because create() had
acquired s.mu, and handleProcessExit() will try to lock it again.
So I add handleProcessExitNoLock() function which will not lock s.mu.
It can safely be called in create handler without deadlock.