proc: Add new process hold facility.

[dchagin]

Summary

Linux kernel allows access to some of /proc/<pid>/* entries where the
process <pid> is in the zombie state. To follow Linux behavior add
a new p_lockreap counter which is intended to hold process vmspace
from release in proc_reap(). Use new facility in pseudofs code to hold
process when needed if node has PFS_ZOMBIE flag set.

We discussed this a while ago, I did.
However, the kern.wait_dequeue_sigchld knob does not allow to get CLD_KILLED.
I see it's not easy to do. If you point me to the right direction, I'll try.

[kib]

I do not quite understand this. Am I right that the intent is to see zombies under linprocfs? If yes, what exact entries from the pid directory should be exposed?

[dchagin]

In D35068#794803, @kib wrote:

I do not quite understand this. Am I right that the intent is to see zombies under linprocfs? If yes, what exact entries from the pid directory should be exposed?

yes, you are right.
linprocfs_doprocstatus, PFS_ZOMBIE flag of pfs_create_xxx()

[kib]

In D35068#794804, @dchagin wrote:

In D35068#794803, @kib wrote:

I do not quite understand this. Am I right that the intent is to see zombies under linprocfs? If yes, what exact entries from the pid directory should be exposed?

yes, you are right.
linprocfs_doprocstatus, PFS_ZOMBIE flag of pfs_create_xxx()

You did not answered the second part of the question, what is the entries from the pid directory, that you want to expose for zombies?

[I do not think this patch can work at all]

[dchagin]

In D35068#794805, @kib wrote:

In D35068#794804, @dchagin wrote:

In D35068#794803, @kib wrote:

I do not quite understand this. Am I right that the intent is to see zombies under linprocfs? If yes, what exact entries from the pid directory should be exposed?

yes, you are right.
linprocfs_doprocstatus, PFS_ZOMBIE flag of pfs_create_xxx()

You did not answered the second part of the question, what is the entries from the pid directory, that you want to expose for zombies?

[I do not think this patch can work at all]

Sorry, if I understood your question correctly, for zombies - nothing. I expose <pid>/status to others who can see that pid, usually their parent.

Glibc modified their tests suite, was added support library which is uses <pid>/status entry to check process status. Yet another Linux-ism.
I do not think that this technic will be used in a real applications (but who knows?) but this annoe me as I should check every failed test when new glibc version released.
Anyway, with that change some tests fails, as CLD_KILLED can't be 'queued'.

Ha, on x86-64 glibc-2.35 tests fails only in 83 cases (4920 passed), while some years ago was failed more than 1000 tests.
Arm64 need more attention, mostly due to signals delivery. Machine dependent futexes part is done, but uncommited while sigtramp is not ready.

[kib]

sys/kern/kern_exit.c

987

Ok, so this 'lockreap' does not have anything to do with vmspace at all, it is just a hold on reuse of the struct proc/p_pid while linprocfs might expose the pid?

If I am right, shouldn't this check/wait appear at the start of the function, while all linkage is still valid?

sys/sys/proc.h

678

Why uint32 and not just uint?

[dchagin]

yes, you are right. fixed both comments

[dchagin]

extra line removed