From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932951AbcLGUlx (ORCPT ); Wed, 7 Dec 2016 15:41:53 -0500 Received: from mout.kundenserver.de ([212.227.17.13]:59162 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753554AbcLGUlu (ORCPT ); Wed, 7 Dec 2016 15:41:50 -0500 From: Arnd Bergmann To: Catalin Marinas Cc: Yury Norov , linux-doc@vger.kernel.org, szabolcs.nagy@arm.com, heiko.carstens@de.ibm.com, cmetcalf@ezchip.com, philipp.tomsich@theobroma-systems.com, joseph@codesourcery.com, linux-arch@vger.kernel.org, zhouchengming1@huawei.com, Prasun.Kapoor@caviumnetworks.com, agraf@suse.de, geert@linux-m68k.org, kilobyte@angband.pl, manuel.montezelo@gmail.com, pinskia@gmail.com, linyongting@huawei.com, klimov.linux@gmail.com, broonie@kernel.org, bamvor.zhangjian@huawei.com, Bamvor Zhang Jian , linux-arm-kernel@lists.infradead.org, maxim.kuvyrkov@linaro.org, Nathan_Lynch@mentor.com, linux-kernel@vger.kernel.org, schwidefsky@de.ibm.com, davem@davemloft.net, christoph.muellner@theobroma-systems.com Subject: Re: [PATCH 16/18] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32 Date: Wed, 07 Dec 2016 21:40:13 +0100 Message-ID: <3703608.GKr1zzErMk@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <20161207165913.GD31779@e104818-lin.cambridge.arm.com> References: <1477081997-4770-1-git-send-email-ynorov@caviumnetworks.com> <20161206062508.GA17835@yury-N73SV> <20161207165913.GD31779@e104818-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:BPymnezVyXY1CzDfMmKVmUfPe8q/N7kr7F2jFPIMVmBVjvE+owD kAS/CncmaBsYRD31l88l1od1zChn38kzmk150Dru+wweQFGFM6uLqaM5l6ij1s+Wk/2y8pA ga0cpLd80pIvouGv4btZHpYpAP6lltHePMG9/6MyH9ruTmMma4a2y8eari/m4OhlUUE91mt +fEGYHfW4GnEbqs/MxHOQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:KNlthUQ+8t8=:h0j6fXVHtr/Z28Av4Z+MO6 acedMwwmqnJxMQL30OWCxhtDqQ8SQ2NRXgdNdT8YycGCFJkcodM517OdZCHsnwXxMI3DWTxwF kTEPSMI702AY2ZHbLNLRKVoDm92kzfuMetJfCeREAHfPaNJAuXsrMzpv7MJJeJVaZOHthzz7W vwlE59vc2LkUjIcq0bZH6KUpfJpLKJXGctAL15OxT6kCkOitn3AV+FLiejMt271RspswdksFm 1H+a4g9HWHOS2E6NJ7yqq9oAoRxKfLtpRvR9gv+Ejhius2Vi03iSKN05WYff77nQYdUjL2vvg bLtNSyMadpfO1+LdwLiU0grKBPtU9B1k9/Q0krc/e/fQpXZnCGk0/4W9GF0+EEiPHMkIscoC/ svXG8uPYc9EnarVh7k+6wkzekgTQp9M7o37/V9xDOeiOFsEoGOShiGAgGoF3lADLvyEvpS8MQ 4ZddEMJofIcSfpgy441GKplMFVOkP8+vEHp0ebYqrRZIDRA4/hYHjLDVmbqDcl/GQEOzYOCB9 rNk9oA1e00Lq66mmHXYyGv+k3tJ/IhhK/Wx0uGZlHgGmGwUn4fmcmnOX1wR0N0IegYNEsdY+b BflAudjqAnKLLcLsWjLWTnyXl3nYNOB5qyKWhCjyr2/OahklZzA97vJnGlCvU1NKSD7JTAR6+ lxvVAT4qVrnzkGAXtwYAFZ/YjMstbgWR75HGtI4cFbViBR1aIkAIMYqkvemdr7BdVc7Hg2GL3 3tVkTbhXStmUWuYN Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, December 7, 2016 4:59:13 PM CET Catalin Marinas wrote: > On Tue, Dec 06, 2016 at 11:55:08AM +0530, Yury Norov wrote: > > On Mon, Dec 05, 2016 at 04:34:23PM +0000, Catalin Marinas wrote: > > > On Fri, Oct 21, 2016 at 11:33:15PM +0300, Yury Norov wrote: > > > > New aarch32 ptrace syscall handler is introduced to avoid run-time > > > > detection of the task type. > > > > > > What's wrong with the run-time detection? If it's just to avoid a > > > negligible overhead, I would rather keep the code simpler by avoiding > > > duplicating the generic compat_sys_ptrace(). > > > > Nothing wrong. This is how Arnd asked me to do. You already asked this > > question: http://lkml.iu.edu/hypermail/linux/kernel/1604.3/00930.html > > Hmm, I completely forgot about this ;). There is still an advantage to > doing run-time checking if we avoid touching core code (less acks to > gather and less code duplication). > > Let's see what Arnd says but the initial patch looked simpler. I don't currently have either version of the patch in my inbox (the archive is on a different machine), but in general I'd still think it's best to avoid the runtime check for aarch64-ilp32 altogether. I'd have to look at the overall kernel source to see if it's worth avoiding one or two instances though, or if there are an overwhelming number of other checks that we can't avoid at all. Regarding ptrace, I notice that arch/tile doesn't even use the compat entry point for its ilp32 user space on 64-bit kernels, it just calls the regular 64-bit one. Would that help here? Arnd