Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933101AbcDYQ5b (ORCPT ); Mon, 25 Apr 2016 12:57:31 -0400 Received: from foss.arm.com ([217.140.101.70]:48226 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754393AbcDYQ53 (ORCPT ); Mon, 25 Apr 2016 12:57:29 -0400 Date: Mon, 25 Apr 2016 17:57:21 +0100 From: Catalin Marinas To: Yury Norov Cc: linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, arnd@arndb.de, pinskia@gmail.com, Prasun.Kapoor@caviumnetworks.com, schwab@suse.de, linux-doc@vger.kernel.org, heiko.carstens@de.ibm.com, linux-kernel@vger.kernel.org, agraf@suse.de, klimov.linux@gmail.com, broonie@kernel.org, bamvor.zhangjian@huawei.com, joseph@codesourcery.com, schwidefsky@de.ibm.com, Nathan_Lynch@mentor.com, linux-arm-kernel@lists.infradead.org, christoph.muellner@theobroma-systems.com Subject: Re: [PATCH 19/25] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32 Message-ID: <20160425165721.GH9614@e104818-lin.cambridge.arm.com> References: <1459894127-17698-1-git-send-email-ynorov@caviumnetworks.com> <1459894127-17698-20-git-send-email-ynorov@caviumnetworks.com> <20160422171009.GR2998@e104818-lin.cambridge.arm.com> <20160422214013.GA2234@yury-N73SV> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160422214013.GA2234@yury-N73SV> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 732 Lines: 18 On Sat, Apr 23, 2016 at 12:40:13AM +0300, Yury Norov wrote: > On Fri, Apr 22, 2016 at 06:10:09PM +0100, Catalin Marinas wrote: > > On Wed, Apr 06, 2016 at 01:08:41AM +0300, Yury Norov wrote: > > > Here new aarch32 ptrace syscall handler is introsuced to avoid run-time > > > detection of the task type. > > > > The reason for this patch isn't clear to me. What's wrong with the > > run-time detection? It's not some performance critical code. > > It was requested by Arnd, It's not 'new' syscall basically, just an > attempt to avoid run-time detection of things that may be detected an > compile-time. OK. I noticed that it touches core files and wondering whether it was necessary but I'm fine with this approach. -- Catalin