-
Notifications
You must be signed in to change notification settings - Fork 596
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
pidfd: tmp process is waited upon by correct process #2505
Conversation
e7303de
to
1a00bf7
Compare
LGTM |
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.
I played with this PR locally and tried to make a deadlock. By combining pipe+pidfd in that way so one process became "master" (the one who restores pidfd or pipe pair) while another one became "slave" (the one who received fd through TRANSPORT_FD
socket). But taking into account the fact that recv_desc_from_peer
is non-blocking call and it can return 1
(which means "please retry later") we are on the safe side.
LGTM.
I'll do some small adjustments in this PR to fix code style issues so we can merge it today. Upd: have done. |
Currently, the `waitpid()` call on the tmp process can be made by a process which is not its parent. This causes restore to fail. This patch instead selects one process to create the tmp process and open all the fds that point to it. These fds are sent to the correct process(es). Fixes: checkpoint-restore#2496 Signed-off-by: Andrei Vagin <[email protected]> Signed-off-by: Bhavik Sachdev <[email protected]>
We have multiple processes open a pidfd to a common dead process. After C/R we check that the inode numbers for these pidfds are equal or not. Signed-off-by: Bhavik Sachdev <[email protected]>
1a00bf7
to
54b8bd0
Compare
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
Fixes: #2496
This patch ensures that the process that created the tmp process is the one that kills and waits for it after all pidfds have been opened. We do this by keeping track of each process that has to open a pidfd for the tmp process and the number of pidfds it has to open.
Thing I am unsure about need to dump the pid of the process that opened the pidfd. (This might be available from some where else)