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 S1753561AbcHWPfE (ORCPT <rfc822;w@1wt.eu>);
        Tue, 23 Aug 2016 11:35:04 -0400
Received: from mx1.redhat.com ([209.132.183.28]:51868 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1753508AbcHWPfC (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 23 Aug 2016 11:35:02 -0400
Date: Tue, 23 Aug 2016 17:34:29 +0200
From: Oleg Nesterov <oleg@redhat.com>
To: Keno Fischer <keno@juliacomputing.com>
Cc: Roland McGrath <roland@hack.frob.com>, linux-kernel@vger.kernel.org,
        Tejun Heo <tj@kernel.org>
Subject: Re: ptrace group stop signal number not reset before
        PTRACE_INTERRUPT is delivered?
Message-ID: <20160823153428.GB4067@redhat.com>
References: <CABV8kRx6LQGBvJnR2UtWJbx7P_tjEGn=omhzzL-QVyLYEQPedQ@mail.gmail.com> <20160818143750.GA24070@redhat.com> <20160818153806.GA25492@redhat.com> <20160818162311.GA27883@redhat.com> <CABV8kRwP8g+y862bPhghEfCFAeDqd9fxR1EjHoJNwq5JnJx8Gg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABV8kRwP8g+y862bPhghEfCFAeDqd9fxR1EjHoJNwq5JnJx8Gg@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Tue, 23 Aug 2016 15:34:52 +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 08/18, Keno Fischer wrote:
>
> On Thu, Aug 18, 2016 at 12:23 PM, Oleg Nesterov <oleg@redhat.com> wrote:
> >
> > And you if you get PTRACE_EVENT_STOP and WSTOPSIG() == SIGTTIN after
> > PTRACE_INTERRUPT, you know that the tracee did not report the "new"
> > SIGTTIN.
>
> It seems possible to remember whether or not we injected a stopping
> signal and if so the next PTRACE_EVENT_STOP is a group-stop, otherwise
> a PTRACE_INTERRUPT stop. Currently what I do is the other way around,
> after issuing PTRACE_INTERRUPT, the first (if any) of the next two
> stops that is a PTRACE_EVENT_STOP get interpreted as a
> PTRACE_INTERRUPT stop. I haven't thought through this fully yet, so I
> can't give you a concrete example I worried about, it just seems
> fragile compared to just checking whether WSTOPSIG() == SIGTRAP.

Yes, I see your point. And to remind, I was confused too.

Perhaps we can add another THIS_SIGNAL_WAS_ALREADY_REPORTED bit, but
you know, I'd prefer to avoid another subtle change in behaviour. You
can never know if it is "safe" or not when it comes to ptrace, perhaps
some application already relies on this WSTOPSIG().

Oleg.