proc: Fix proc_init / proc_dtor ordering issues

[des]

Summary

• Move the initialization of p_ktr into proc_init() and make the check in proc_dtor() unconditional. Prior to this, it was possible to fail and invoke proc_dtor() after the first thread had been created (which was the condition for checking p_ktr in proc_dtor()) but before p_ktr had been initialized.

• Move the p_klist initialization in fork1() past the last possible failure point so we don't have to free it on failure. We didn't, which meant we were leaking a knlist every time we failed to fork due to hitting the resource limit.

PR: 291470
MFC after: 1 week

[kib]

IMO it would be more proper to move the initialization into proc_init().

[kib]

In D54215#1238587, @kib wrote:

IMO it would be more proper to move the initialization into proc_init().

And then proc_dtor could assert that p->p_ktr is empty unconditionally, not only when there is a thread owned by the process.

[des]

Should we also move mac_proc_init() and knlist_alloc() into proc_init()? no, we shouldn't.

However, I just realized that we leak the klist if the new process exceeds the resource limit.

[des]

plug knlist leak

[kib]

Indeed, p_klist initialization should not be moved into constructor, since it is cleared in exit1() (and should not be done in destructor, I believe). Then it would leak in each case where exit1() is not called, i.e. fork failures.
For mac, I have no idea what modules expect, so IMO it is better to keep them as is.

sys/kern/kern_proc.c

243–244

Remove this #ifdef as well, it has no point.

[des]

We can't move the MAC initialization, it has to happen before we call priv_check_cred().