From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751460AbdAWQHA (ORCPT <rfc822;w@1wt.eu>);
        Mon, 23 Jan 2017 11:07:00 -0500
Received: from mx1.redhat.com ([209.132.183.28]:56824 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1750957AbdAWQG7 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 23 Jan 2017 11:06:59 -0500
Date: Mon, 23 Jan 2017 17:06:55 +0100
From: Oleg Nesterov <oleg@redhat.com>
To: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Cc: Ingo Molnar <mingo@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Cyrill Gorcunov <gorcunov@openvz.org>,
        John Stultz <john.stultz@linaro.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Nicolas Pitre <nicolas.pitre@linaro.org>,
        Michal Hocko <mhocko@suse.com>,
        Stanislav Kinsburskiy <skinsbursky@virtuozzo.com>,
        Mateusz Guzik <mguzik@redhat.com>, linux-kernel@vger.kernel.org,
        Pavel Emelyanov <xemul@virtuozzo.com>,
        Konstantin Khorenko <khorenko@virtuozzo.com>,
        Lennart Poettering <lennart@poettering.net>
Subject: Re: [PATCH] prctl: propagate has_child_subreaper flag to every
 descendant
Message-ID: <20170123160655.GA1857@redhat.com>
References: <20170119164346.4214-1-ptikhomirov@virtuozzo.com>
 <20170120181359.GA17205@redhat.com>
 <4908be49-d3c3-366d-0fd1-05249ef4ecef@virtuozzo.com>
 <20170123115534.GA11827@redhat.com>
 <9e63e64c-70bf-0dcc-c74d-cd2364cee1b9@virtuozzo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9e63e64c-70bf-0dcc-c74d-cd2364cee1b9@virtuozzo.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Mon, 23 Jan 2017 16:07:00 +0000 (UTC)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.