Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp423193ybk; Wed, 20 May 2020 03:08:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxbaciHdIGx05XebIxjQpGTWOmYTIo4CrsCvEiSIMflHr1zdfQ5IxE9aYpl4xVTsQ7gRmsd X-Received: by 2002:a17:906:7e15:: with SMTP id e21mr3002940ejr.106.1589969289721; Wed, 20 May 2020 03:08:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589969289; cv=none; d=google.com; s=arc-20160816; b=pUFCGkBIy0MoVy8NxYbaDJavH5k+67iCxOJgesJ+QJfesMui0uFIWrVde6B8VdtLN7 kI1nbv22kC5PBOLpBnrF4VG+NpVZlM1wlVZFuS4tzU37NVz3xuDipeVC/HUqpIEacPeV KYxGyUamRAqVehB55VaIHsHOD9Q1P4gcaW82ka0kP7UJ4MbnhIk+kayOHNRjjR5w+LeS 7oRTw7ZfVFJUVzoZmzOZGDtcrB7gh2yHwZ6L5oGK0BD42yPJtSuHsbyHpcUMg11I74qt Y1HBI1ICePTgqHSNm1nCBaT+ei0nHjmT6+ZMaRBlffbSyRuyvmYe2bQuv0sPyGdrjVBR 391A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=1Etp2eJRAuT7HDH7+KW9XmbzlqzTG22cf5eIo9P+sf0=; b=YHr5SXD8Bn5IQ9a2M8POYgslQF39JUKzgQexlC6mwOhVlRWFamaE+u8mh6tTtJa/1n pr+mhADJyvhWHX6HfY0ivkQUuAzAfzKvKCJpFqaeJDIVi+aIPgRyGpcm/7Ql8S68gA/p zFZ/AnOk5kipbg6BnXnY8E+RqYh11vD6BsKW8invOSrp/92FWQib2RW63yQXcAbW805t FYOfprfm6lJRA4SxyGzUPRxJkGhrgYsCYicKoPH0id9wB8tl0gfNZU/dEWIgnr2lyAG4 LX6QcIKWi4aUJhiAeGrHaHsYlBthtCIr8F3acDsrP8dkJKMb1aEIU8TimmXVgCl1HpsO N8wA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v21si1447877ejx.356.2020.05.20.03.07.46; Wed, 20 May 2020 03:08:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726845AbgETKFw (ORCPT + 99 others); Wed, 20 May 2020 06:05:52 -0400 Received: from foss.arm.com ([217.140.110.172]:52018 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726435AbgETKFw (ORCPT ); Wed, 20 May 2020 06:05:52 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 98C0F31B; Wed, 20 May 2020 03:05:51 -0700 (PDT) Received: from gaia (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 873B53F68F; Wed, 20 May 2020 03:05:50 -0700 (PDT) Date: Wed, 20 May 2020 11:05:44 +0100 From: Catalin Marinas To: Sudeep Holla Cc: Will Deacon , will.deacon@arm.com, linux-kernel@vger.kernel.org, oleg@redhat.com, Keno Fischer , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] arm64: Fix PTRACE_SYSEMU semantics Message-ID: <20200520100543.GA18302@gaia> References: <20200515222253.GA38408@juliacomputing.com> <20200518114119.GB32394@willie-the-truck> <20200519120725.GA20313@gaia> <20200520100330.GA25430@bogus> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200520100330.GA25430@bogus> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 20, 2020 at 11:03:30AM +0100, Sudeep Holla wrote: > On Tue, May 19, 2020 at 01:07:27PM +0100, Catalin Marinas wrote: > > On Mon, May 18, 2020 at 12:41:20PM +0100, Will Deacon wrote: > > > On Fri, May 15, 2020 at 06:22:53PM -0400, Keno Fischer wrote: > > > > Quoth the man page: > > > > ``` > > > > If the tracee was restarted by PTRACE_SYSCALL or PTRACE_SYSEMU, the > > > > tracee enters syscall-enter-stop just prior to entering any system > > > > call (which will not be executed if the restart was using > > > > PTRACE_SYSEMU, regardless of any change made to registers at this > > > > point or how the tracee is restarted after this stop). > > > > ``` > > > > > > > > The parenthetical comment is currently true on x86 and powerpc, > > > > but not currently true on arm64. arm64 re-checks the _TIF_SYSCALL_EMU > > > > flag after the syscall entry ptrace stop. However, at this point, > > > > it reflects which method was used to re-start the syscall > > > > at the entry stop, rather than the method that was used to reach it. > > > > Fix that by recording the original flag before performing the ptrace > > > > stop, bringing the behavior in line with documentation and x86/powerpc. > > > > > > > > Signed-off-by: Keno Fischer > > > > --- > > > > arch/arm64/kernel/ptrace.c | 8 +++++--- > > > > 1 file changed, 5 insertions(+), 3 deletions(-) > > > > > > > > diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c > > > > index b3d3005d9515..b67b4d14aa17 100644 > > > > --- a/arch/arm64/kernel/ptrace.c > > > > +++ b/arch/arm64/kernel/ptrace.c > > > > @@ -1829,10 +1829,12 @@ static void tracehook_report_syscall(struct pt_regs *regs, > > > > > > > > int syscall_trace_enter(struct pt_regs *regs) > > > > { > > > > - if (test_thread_flag(TIF_SYSCALL_TRACE) || > > > > - test_thread_flag(TIF_SYSCALL_EMU)) { > > > > + u32 flags = READ_ONCE(current_thread_info()->flags) & > > > > + (_TIF_SYSCALL_EMU | _TIF_SYSCALL_TRACE); > > > > + > > > > + if (flags) { > > > > > > nit: but I'd rather the '&' operation was in the conditional so that the > > > 'flags' variable holds all of the flags. > > > > > > With that: > > > > > > Acked-by: Will Deacon > > > > > > Also needs: > > > > > > Cc: > > > Fixes: f086f67485c5 ("arm64: ptrace: add support for syscall emulation") > > > > > > Catalin -- can you pick this up for 5.7 please, with my 'nit' addressed? > > > > I'll queue it with the above addressed. I think flags also needs to be > > unsigned long rather than u32. > > > > However, before sending the pull request, I'd like Sudeep to confirm > > that it doesn't break his original use-case for this feature. > > I just tested it with my simple programs I had before. I have also asked > teams working on gvisor to test. They have tested it and see no > regression. I will ask them to reply here. > > Tested-by: Sudeep Holla Thanks Sudeep. -- Catalin