Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 8 Nov 2018 10:16:38 +0100
From:   Oleg Nesterov <oleg@redhat.com>
To:     Elvira Khabirova <lineprinter@altlinux.org>
Cc:     Andy Lutomirski <luto@amacapital.net>, rostedt@goodmis.org,
        mingo@redhat.com, linux-kernel@vger.kernel.org, ldv@altlinux.org,
        esyr@redhat.com, luto@kernel.org, strace-devel@lists.strace.io
Subject: Re: [RFC PATCH] ptrace: add PTRACE_GET_SYSCALL_INFO request
Message-ID: <20181108091638.GA9939@redhat.com>
References: <20181107042751.3b519062@akathisia>
 <20181107112100.GA20419@redhat.com>
 <3BDB914D-12F3-4703-A033-EBE02226EC45@amacapital.net>
 <20181107164443.GA8726@redhat.com>
 <20181107210251.542cf8a1@akathisia>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20181107210251.542cf8a1@akathisia>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 11/07, Elvira Khabirova wrote:
>
> On Wed, 7 Nov 2018 17:44:44 +0100
> Oleg Nesterov <oleg@redhat.com> wrote:
>
> > To me PT_IN_SYSCALL_STOP makes no real sense, but I won't argue.
> >
> > At least I'd ask to not abuse task->ptrace. ptrace_report_syscall() can clear
> > ->ptrace_message on exit if we really want PTRACE_GET_SYSCALL_INFO to fail after
> > that.
>
> I really would not like to rely on ->ptrace_message remaining empty;
> this looks too fragile.

Well. I do not understand why this is fragile. And certainly this is not more
fragile than

	current->ptrace |= PT_IN_SYSCALL_STOP;
	trace_notify();
	current->ptrace &= ~PT_IN_SYSCALL_STOP;

simply because both ->ptrace updates are technically wrong. The tracee can race
with the exiting tracer which clears ->ptrace.

But even if this was correct. This patch manipulates ->ptrace_message anyway,
I do not understand why should we abuse ->ptrace too just to for the sanity
check in PTRACE_GET_SYSCALL_INFO.

Oleg.