linux-kernel - Re: [PATCH] prctl: propagate has_child

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170120181359.GA17205@redhat.com>
Date:   Fri, 20 Jan 2017 19:14:00 +0100
From:   Oleg Nesterov <oleg@...hat.com>
To:     Pavel Tikhomirov <ptikhomirov@...tuozzo.com>
Cc:     Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Cyrill Gorcunov <gorcunov@...nvz.org>,
        John Stultz <john.stultz@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Nicolas Pitre <nicolas.pitre@...aro.org>,
        Michal Hocko <mhocko@...e.com>,
        Stanislav Kinsburskiy <skinsbursky@...tuozzo.com>,
        Mateusz Guzik <mguzik@...hat.com>,
        linux-kernel@...r.kernel.org,
        Pavel Emelyanov <xemul@...tuozzo.com>,
        Konstantin Khorenko <khorenko@...tuozzo.com>
Subject: Re: [PATCH] prctl: propagate has_child_subreaper flag to every
        descendant

On 01/19, Pavel Tikhomirov wrote:
>
> Having these two
> differently behaving groups can lead to confusion. Also it is
> a problem for CRIU, as when we restore process tree we need to
> somehow determine which descendants belong to which group and
> much harder - to put them exactly to these group.

Hmm. could you explain how this change helps CRIU? I mean, why
restorer can't do prctl(CHILD_SUBREAPER) before the first fork?

Anyway, afaics the patch is sub-optimal and not correct...

> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1715,6 +1715,8 @@ struct task_struct {
>  	struct signal_struct *signal;
>  	struct sighand_struct *sighand;
>
> +	struct list_head csr_descendant;
> +

You don't need this new member and descendants_lock. task_struct has
the ->real_parent pointer so you can work the tree without recursion.

> +static void prctl_set_child_subreaper(struct task_struct *reaper, bool arg2)
> +{
> +	LIST_HEAD(descendants);
> +
> +	reaper->signal->is_child_subreaper = arg2;
> +	if (!arg2)
> +		return;
> +
> +	spin_lock(&descendants_lock);
> +	read_lock(&tasklist_lock);
> +
> +	list_add(&reaper->csr_descendant, &descendants);
> +
> +	while (!list_empty(&descendants)) {
> +		struct task_struct *tsk;
> +		struct task_struct *p;
> +
> +		tsk = list_first_entry(&descendants, struct task_struct,
> +				csr_descendant);
> +
> +		list_for_each_entry(p, &tsk->children, sibling) {

This is not enough. Every thread has its own ->children list, you need
to walk the sub-threads as well.

> +			 * If we've found child_reaper - skip descendants in
> +			 * it's subtree as they will never get out pidns
> +			 */
> +			if (is_child_reaper(task_pid(p)))
> +				continue;

Again, a child reaper can be multi-threaded, this check can be false
negative.

Probably is_child_reaper() should be renamed somehow and a new helper
makes sense... something like

	bool task_is_child_reaper(struct task_struct *p)
	{
		return same_thread_group(p, task_active_pid_ns(p)->child_reaper);
	}

Oleg.