Re: [PATCH] prctl: propagate has_child_subreaper flag to every descendant

[Oleg Nesterov]

On 01/23, Pavel Tikhomirov wrote:
>
> >IOW. Currently CRIU can't restore the process tree with the same
> >has_child_subreaper bits if some process forks before
> >prctl(PR_SET_CHILD_SUBREAPER). It restores the tree as if prctl()
> >was called before the 1st fork.
> >
> >So you change the semantics of PR_SET_CHILD_SUBREAPER and now CRIU
> >is fine simply because you remove this feature: the sub-reaper can
> >no longer pre-fork the children which should reparent to the previous
> >reaper.
> >
> >I won't really argure, but I am not sure this is good idea...
>
> If one task uses these feature now it must be very carefull: if some our
> ancestor have enabled is_child_subreaper somewhere up the tree, forked our
> tree and after that disabled is_child_subreaper, so we already have has-flag
> and all children will inherit has-flag irrelevant to what is our order of
> fork/prctl-ing to become subreaper.

Agreed.

So let me reword my initial question, why did you make this patch? Did you
actually hit a case when a child of is_child_subreaper process doesn't have
has_child_subreaper bit set?

If yes, then perhaps that application has a reason to do this and your patch
can break it? If no, then you can probably forget this until you have a CRIU
bug report ;)

But let me repeat, I won't really argue. And I even agree that this change
makes the semantics of PR_SET_CHILD_SUBREAPER more clear, just I am always
nervous when we add the subtle user-visible changes like this, and I greatly
misundestood the changelog as if CRIU needs to do prctl(SET_CHILD_SUBREAPER)
after it has already restored the process tree and this can't work even in
the common case.

Oleg.