kern_fork.c: add kern.pdfork_implicit_nowaitpid sysctl

[markj]

I don't understand the motivation for this. The desired behaviour of pdfork() and waitpid() must be determined by the application programmer. How can someone confidently set this as a global policy, unless they reviewed all code running on their system?

[kib]

In D59349#1362217, @markj wrote:

I don't understand the motivation for this. The desired behaviour of pdfork() and waitpid() must be determined by the application programmer. How can someone confidently set this as a global policy, unless they reviewed all code running on their system?

There are several aspects. In the ideal world of sane API, the PD_NOWAITPID flag is not needed, and the behavior requested by the flag is the only way to reap the pdforked children.

In real world, there were two pathes, one racing with another. Either waitpid() is called on the pid of the pdforked child while pfd is still opened, then the child is reaped by waitpid. This is the (mis-)behavior I decided to preserve. Or pfd is closed, and then the child is reaped, pid is freed, and waitpid(2) cannot be used on the pid unless was pid recycled meantime (with the ABA issue).

The second kind of behavior is what the libcasper relied upon. It is a subset of the 'ideal' world.

The knob I propose to add would change the API to 'ideal', and avoids gathering zombies for existing unpatched casper installations, as a workaround. It might break some glib/gtk libraries, it seems. But it is a deliberate choice by admin, we only provide the tool to select less evil for specific situation.