In this answer user suggests that

Normally, Uninterruptible sleep should not last long, but as under windows, broken drivers or broken userpace programs (vfork without exec) can end up sleeping in D forever.

How can userspace program really lock up in D on non-buggy kernel? I though it's sort of little vulnerability for usermode to be able to stuck in D on purpose...

  • I know it about FUSE program being able to take it's users to D, but I consider that a drawback of FUSE kernel driver, not FUSE filesystems.
    – Vi.
    Sep 18 '14 at 22:21

When a process calls vfork, the parent remains in state D as long as the child hasn't executed _exit or execve (the only two authorized functions, together with execve's relatives like execvp, etc.). The parent is still executing the vfork call, so it's in state D.

If the child does something like this (which is stupid, but valid), the parent will remain in state D indefinitely, while the child will remain in state R indefinitely.

if (!vfork()) while (1) {}
  • man vfork -> vfork - create a child process and block parent. OK, now I see. I though was "fork, but preserve Virtual memory unified". Parent is locked, but there's a "key" to unlock it, so no problem.
    – Vi.
    Sep 18 '14 at 23:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.