Re: [PATCH] prctl.2: Document new PR_SET_CHILD_SUBREAPER semantics

[Pavel Tikhomirov]

On 01/28/2017 01:47 AM, Michael Kerrisk (man-pages) wrote:
> Hello Pavel,
>
> On 27 January 2017 at 23:11, Pavel Tikhomirov <ptikhomirov@xxxxxxxxxxxxx> wrote:
> > old semantics was non deterministic and worked differently
> > depending on the external factors, but nothing changes if
> > process first sets itself subreaper and only after forks
>
> When did the kernel behavior change?

Sorry for inconvenience, should have added you to cc of a main patch also.

Kernel behavior haven't changed yet, doc change will be a continuation 
of "[PATCH v2 0/2] prctl: make PR_SET_CHILD_SUBREAPER deterministic", 
see https://lkml.org/lkml/2017/1/27/108

> Cheers,
>
> Michael
>
>
> > Signed-off-by: Pavel Tikhomirov <ptikhomirov@xxxxxxxxxxxxx>
> > ---
> >  man2/prctl.2 | 24 +++++++++++++++++-------
> >  1 file changed, 17 insertions(+), 7 deletions(-)
> >
> > diff --git a/man2/prctl.2 b/man2/prctl.2
> > index 97cf21a..84fbd7e 100644
> > --- a/man2/prctl.2
> > +++ b/man2/prctl.2
> > @@ -162,20 +162,30 @@ if
> >  is zero, unset the attribute.
> >
> >  When a process is marked as a child subreaper,
> > -all of the children that it creates, and their descendants,
> > +all of the children that it creates or have created already, and their descendants,
> >  will be marked as having a subreaper.
> >  In effect, a subreaper fulfills the role of
> >  .BR init (1)
> >  for its descendant processes.
> > -Upon termination of a process
> > -that is orphaned (i.e., its immediate parent has already terminated)
> > -and marked as having a subreaper,
> > -the nearest still living ancestor subreaper
> > -will receive a
> > +Upon termination of a process having a subreaper,
> > +all its children become orphaned
> > +and will be reparented to the nearest still living ancestor subreaper.
> > +So that on it's adopted child termination
> > +these subreaper will receive a
> >  .BR SIGCHLD
> >  signal and will be able to
> >  .BR wait (2)
> > -on the process to discover its termination status.
> > +on the child to discover its termination status.
> > +
> > +Note, that on older kernels these prctl works slightly different.
> > +Child subreaper process was not actualy the
> > +.BR init (1)
> > +for all its descendants.
> > +If process forks a child while not been a child subreaper,
> > +and after sets himself child subreaper,
> > +sub-tree of the child might or might not reparent to the subreaper,
> > +depending on the configuration of ancestors of the subreaper,
> > +at the time of forking our subtree.
> >  .TP
> >  .BR PR_GET_CHILD_SUBREAPER " (since Linux 3.4)"
> >  Return the "child subreaper" setting of the caller,
> > --
> > 2.9.3

--
Best regards, Tikhomirov Pavel
Software Developer, Virtuozzo.