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 S933953AbcCOXeh (ORCPT <rfc822;w@1wt.eu>);
	Tue, 15 Mar 2016 19:34:37 -0400
Received: from mx1.redhat.com ([209.132.183.28]:58077 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S933048AbcCOXed (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 15 Mar 2016 19:34:33 -0400
Date: Wed, 16 Mar 2016 00:34:27 +0100
From: Oleg Nesterov <oleg@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Denys Vlasenko <dvlasenk@redhat.com>, Dmitry Vyukov <dvyukov@google.com>,
        Jan Kratochvil <jan.kratochvil@redhat.com>,
        "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>,
        Pedro Alves <palves@redhat.com>, Roland McGrath <roland@hack.frob.com>,
        syzkaller@googlegroups.com, linux-kernel@vger.kernel.org
Subject: [PATCH 0/2] wait/ptrace: assume __WALL if the child is traced
Message-ID: <20160315233427.GA14509@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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.39]); Tue, 15 Mar 2016 23:34:33 +0000 (UTC)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Resend. And sorry for the huge delay. The patches are the same, I only
updated the changelog a little bit.

The previous discussion was a bit confusing, but iirc/iiuc nobody really
argued with this change. In particular strace/gdb maintainers do not think
it can break something.

To remind, 1 and 2 do not depend on each other. But if we decide to not
fix the kernel, then 2/2 makes much more sense. Most init's use waitid()
which doesn't allow __WALL, so the user-space fix will be more complicated
without this patch.

And just in case let me repeat that I agree, PTRACE_TRACEME is ugly. And
probably it should not succeed after re-parenting (in fact I personally
think PTRACE_TRACEME should not even exist). But imho it is too late to
try change this ancient interface, at least I strongly dislike the idea
to add something like is_global_init() check into ptrace_traceme(). And
any "sane" restriction here can break something too, plus this will
complicate the rules.

Oleg.