d/freebsd-nq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

If process becomes reaper (procctl(PROC_REAP_ACQUIRE)) while already

Browse Source 
having some children, the children' reaper is not reset to the parent.
This allows for the situation where reaper has children but not
descendands and the too strict asserts in the reap_status() fire.

Remove the wrong asserts, add some clarification for the situation to
the procctl(2) REAP_STATUS.

Reported and tested by:	feld
Sponsored by:	The FreeBSD Foundation
MFC after:	1 week
This commit is contained in:
Konstantin Belousov 2015-08-20 22:44:26 +00:00
parent 75824a7b3e
commit 41d50cd6b7
2 changed files with 6 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
lib/libc/sys/procctl.2
View File

@ -29,7 +29,7 @@
.\"
.\" $FreeBSD$
.\"
.Dd December 29, 2014
.Dd August 21, 2015
.Dt PROCCTL 2
.Os
.Sh NAME
@ -148,7 +148,11 @@ The specified process is the root of the reaper tree, i.e.
.Pp
The
.Fa rs_children
field returns the number of children of the reaper.
field returns the number of children of the reaper among the descendands.
It is possible to have a child which reaper is not the specified process,
since the reaper for the existing children is not reset on the
.Dv PROC_REAP_ACQUIRE
operation.
The
.Fa rs_descendants
field returns the total number of descendants of the reaper(s),

2
sys/kern/kern_procctl.c
View File

@ -187,8 +187,6 @@ reap_status(struct thread *td, struct proc *p,
}
} else {
rs->rs_pid = -1;
KASSERT(LIST_EMPTY(&reap->p_reaplist), ("reap children list"));
KASSERT(LIST_EMPTY(&reap->p_children), ("children list"));
}
return (0);
}