How atomic the fork() syscall actually is?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
Assuming check_if_pid_exists(pid) returns true when a process with such a pid exists (but possibly hasn't been running yet) or false when there is no process with such pid, is there any chance in parent code for a race condition when the fork() returned the child pid, however the kernel hasn't had a chance to initialize the data structures so that check_if_pid_exists(child) returns false? Or perhaps after returning from fork() we have a guarantee that check_if_pid_exists(pid) returns true?
pid_t child = fork();
if (child == 0) {
/* here the child just busy waits */
for (;;)
;
}
if (child > 0) {
/* here the parent checks whether child PID already exists */
check_if_pid_exists(child);
}
c linux linux-kernel operating-system
edited Nov 28 '18 at 17:16
red0ct
1,36031023
asked Nov 23 '18 at 18:26
Paweł SmolakPaweł Smolak
31927
add a comment |
Assuming check_if_pid_exists(pid) returns true when a process with such a pid exists (but possibly hasn't been running yet) or false when there is no process with such pid, is there any chance in parent code for a race condition when the fork() returned the child pid, however the kernel hasn't had a chance to initialize the data structures so that check_if_pid_exists(child) returns false? Or perhaps after returning from fork() we have a guarantee that check_if_pid_exists(pid) returns true?
pid_t child = fork();
if (child == 0) {
/* here the child just busy waits */
for (;;)
;
}
if (child > 0) {
/* here the parent checks whether child PID already exists */
check_if_pid_exists(child);
}
c linux linux-kernel operating-system
edited Nov 28 '18 at 17:16
red0ct
1,36031023
asked Nov 23 '18 at 18:26
Paweł SmolakPaweł Smolak
31927
1
If an external event kills the child really quickly (for instance a systemtap script monitoring forks),check_if_pid_exists(child)may return false.
– Mark Plotnick
Nov 23 '18 at 18:40
Correct, thanks. However assuming that no "third party" agent kills our processes?
– Paweł Smolak
Nov 23 '18 at 18:43
2
It could be killed by a first party, like a resource limit
– that other guy
Nov 23 '18 at 19:14
1
I think since the kernel is designed to accommodate the case where the first two instructions the parent makes after the fork invoke awaitsyscall, the kernel has almost certainly set up the child completely by the time fork returns.
– Mark Plotnick
Nov 23 '18 at 19:36
add a comment |
Assuming check_if_pid_exists(pid) returns true when a process with such a pid exists (but possibly hasn't been running yet) or false when there is no process with such pid, is there any chance in parent code for a race condition when the fork() returned the child pid, however the kernel hasn't had a chance to initialize the data structures so that check_if_pid_exists(child) returns false? Or perhaps after returning from fork() we have a guarantee that check_if_pid_exists(pid) returns true?
pid_t child = fork();
if (child == 0) {
/* here the child just busy waits */
for (;;)
;
}
if (child > 0) {
/* here the parent checks whether child PID already exists */
check_if_pid_exists(child);
}
c linux linux-kernel operating-system
edited Nov 28 '18 at 17:16
red0ct
1,36031023
asked Nov 23 '18 at 18:26
Paweł SmolakPaweł Smolak
31927
Assuming check_if_pid_exists(pid) returns true when a process with such a pid exists (but possibly hasn't been running yet) or false when there is no process with such pid, is there any chance in parent code for a race condition when the fork() returned the child pid, however the kernel hasn't had a chance to initialize the data structures so that check_if_pid_exists(child) returns false? Or perhaps after returning from fork() we have a guarantee that check_if_pid_exists(pid) returns true?
pid_t child = fork();
if (child == 0) {
/* here the child just busy waits */
for (;;)
;
}
if (child > 0) {
/* here the parent checks whether child PID already exists */
check_if_pid_exists(child);
}
c linux linux-kernel operating-system
c linux linux-kernel operating-system
edited Nov 28 '18 at 17:16
red0ct
1,36031023
asked Nov 23 '18 at 18:26
Paweł SmolakPaweł Smolak
31927
edited Nov 28 '18 at 17:16
red0ct
1,36031023
asked Nov 23 '18 at 18:26
Paweł SmolakPaweł Smolak
31927
edited Nov 28 '18 at 17:16
red0ct
1,36031023
edited Nov 28 '18 at 17:16
red0ct
1,36031023
edited Nov 28 '18 at 17:16
red0ct
1,36031023
1,36031023
asked Nov 23 '18 at 18:26
Paweł SmolakPaweł Smolak
31927
asked Nov 23 '18 at 18:26
Paweł SmolakPaweł Smolak
31927
asked Nov 23 '18 at 18:26
Paweł SmolakPaweł Smolak
31927
31927
1
If an external event kills the child really quickly (for instance a systemtap script monitoring forks),check_if_pid_exists(child)may return false.
– Mark Plotnick
Nov 23 '18 at 18:40
Correct, thanks. However assuming that no "third party" agent kills our processes?
– Paweł Smolak
Nov 23 '18 at 18:43
2
It could be killed by a first party, like a resource limit
– that other guy
Nov 23 '18 at 19:14
1
I think since the kernel is designed to accommodate the case where the first two instructions the parent makes after the fork invoke awaitsyscall, the kernel has almost certainly set up the child completely by the time fork returns.
– Mark Plotnick
Nov 23 '18 at 19:36
add a comment |
1
If an external event kills the child really quickly (for instance a systemtap script monitoring forks),check_if_pid_exists(child)may return false.
– Mark Plotnick
Nov 23 '18 at 18:40
Correct, thanks. However assuming that no "third party" agent kills our processes?
– Paweł Smolak
Nov 23 '18 at 18:43
2
It could be killed by a first party, like a resource limit
– that other guy
Nov 23 '18 at 19:14
1
I think since the kernel is designed to accommodate the case where the first two instructions the parent makes after the fork invoke awaitsyscall, the kernel has almost certainly set up the child completely by the time fork returns.
– Mark Plotnick
Nov 23 '18 at 19:36
1
1
If an external event kills the child really quickly (for instance a systemtap script monitoring forks),
check_if_pid_exists(child) may return false.– Mark Plotnick
Nov 23 '18 at 18:40
If an external event kills the child really quickly (for instance a systemtap script monitoring forks),
check_if_pid_exists(child) may return false.– Mark Plotnick
Nov 23 '18 at 18:40
Correct, thanks. However assuming that no "third party" agent kills our processes?
– Paweł Smolak
Nov 23 '18 at 18:43
Correct, thanks. However assuming that no "third party" agent kills our processes?
– Paweł Smolak
Nov 23 '18 at 18:43
2
2
It could be killed by a first party, like a resource limit
– that other guy
Nov 23 '18 at 19:14
It could be killed by a first party, like a resource limit
– that other guy
Nov 23 '18 at 19:14
1
1
I think since the kernel is designed to accommodate the case where the first two instructions the parent makes after the fork invoke a
wait syscall, the kernel has almost certainly set up the child completely by the time fork returns.– Mark Plotnick
Nov 23 '18 at 19:36
I think since the kernel is designed to accommodate the case where the first two instructions the parent makes after the fork invoke a
wait syscall, the kernel has almost certainly set up the child completely by the time fork returns.– Mark Plotnick
Nov 23 '18 at 19:36
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53451454%2fhow-atomic-the-fork-syscall-actually-is%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53451454%2fhow-atomic-the-fork-syscall-actually-is%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
If an external event kills the child really quickly (for instance a systemtap script monitoring forks),
check_if_pid_exists(child)may return false.– Mark Plotnick
Nov 23 '18 at 18:40
Correct, thanks. However assuming that no "third party" agent kills our processes?
– Paweł Smolak
Nov 23 '18 at 18:43
2
It could be killed by a first party, like a resource limit
– that other guy
Nov 23 '18 at 19:14
1
I think since the kernel is designed to accommodate the case where the first two instructions the parent makes after the fork invoke a
waitsyscall, the kernel has almost certainly set up the child completely by the time fork returns.– Mark Plotnick
Nov 23 '18 at 19:36