From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S937310AbdAEUlK (ORCPT ); Thu, 5 Jan 2017 15:41:10 -0500 Received: from mail-bl2nam02on0070.outbound.protection.outlook.com ([104.47.38.70]:34149 "EHLO NAM02-BL2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754496AbdAEUlA (ORCPT ); Thu, 5 Jan 2017 15:41:00 -0500 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Yuri.Norov@caviumnetworks.com; Date: Fri, 6 Jan 2017 02:10:03 +0530 From: Yury Norov To: Arnd Bergmann CC: Catalin Marinas , , , , , , , , , , , , , , , , , , , Bamvor Zhang Jian , , , , , , , Subject: Re: [PATCH 16/18] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32 Message-ID: <20170105204003.GA7437@yury-N73SV> References: <1477081997-4770-1-git-send-email-ynorov@caviumnetworks.com> <20161206062508.GA17835@yury-N73SV> <20161207165913.GD31779@e104818-lin.cambridge.arm.com> <3703608.GKr1zzErMk@wuerfel> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <3703608.GKr1zzErMk@wuerfel> User-Agent: Mutt/1.5.24 (2015-08-30) X-Originating-IP: [223.196.184.37] X-ClientProxiedBy: HE1PR0802CA0001.eurprd08.prod.outlook.com (10.172.123.139) To DM3PR07MB2252.namprd07.prod.outlook.com (10.164.33.150) X-MS-Office365-Filtering-Correlation-Id: bd2da305-f0ea-4213-ef4d-08d435ab11dd X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM3PR07MB2252; X-Microsoft-Exchange-Diagnostics: 1;DM3PR07MB2252;3:Ji9e9jt5WsLhGWSiN9dhm+OcHtr6alQW39fNf5uDSa6Lf6PyQzev08JBLKsvrVVe51AqTfjJWFRGxuU8Jd/k8oEQTOFC1Qtf/ysl9ANzdH7UfHyp3dEMZ+o7SMflgXRZVcas6dEUOkuyAkitg9F/44iotdh0dd71pXlsS5BZ7Bu7MXHsWsNFTqZqTraai3/sTeczL2BD4TNvD7PEZ9sZ66xMsm+PCBRDdj8c+FVWug1ARsXykC6Ij6Pb3TqU8ULrY6V9Sxyz1EmD2Vf1vSJoow== X-Microsoft-Exchange-Diagnostics: 1;DM3PR07MB2252;25:EeokHHHRVv3Q4R2YEE0vXyzXqvmqkp4VKXZZ194t0U+sUqHFlFhjEs2py0Ie7KIWhy0bYzhQGQPpJIJDwR1AsOE0oAsYLhVGd3jyDXhEeu4AVTmxMdRinbU9kC7ycPmjnqDie1P8GTI6C30tf9+bvsNCCIZNjJYaP7w+a0iEmp+MHJ2CWwQB3WitIgg5HJLmCCOvcfbN+ZTgcXT/M9KoftmcG8vRzd84BNdmslGyqEkzkK+TK6Wj4qmhftD2H6zA0//yXCslOLpp+YdtO8B9bqj2A/aq61gu3iUDxhRe+HxxLoxXLTCx17h9S6cx3yMcsmMaxJf45t1+BUMNkiuxS2XzB5YOV8R+7Hcz3D/GC0vkqM+tFftgMrPZOI1WNC04A2ZXxrsgW70V3Pcp/wQ/0bju0TLqdRryt4SrTqjeR99jTsJf8oVgNZ1E8FgMQT9F8BfmLWK4X1DD8HmnoRup/9yb3cP3c6bHOoBK749VIoN0yRlVawW6j+5tjX6SeIHFh73vaua+S6R7vYbmm6B/tvQt0iHnVTV6aceeV3IdQg/Fi1zBUQI1ziiJVm0r2FS6nZbBJ8eK8Ht+JzT84rBUXeGI3srybd8tWK66IVsR2nc9TizDiEF3j1vMf6Wt71jgHjyLS45rl5lKgRuk1Ba/00lZ4V4C7SIqd6xu2QJvIUgq7pbomQESDuzoVnYCupF5lNjMKu4JPa7AopoKmbtm57qv7bhbD+wa+3YN/o4Sno1VN9H5zR2+wV/aHzWObXd2zQcUjpg+BUvMKcI46yBOIdyA/K9fqiVFY96qmOKp6uAdzdUbdliAx7GjywpyU5ekyjzUcLVO3BzHi+3wN5DOeoMoht+E9fRvFVLM6AoPbd6Q9Tr87/QNzqsQ9UeRkf/6+8X9yvaVtqxuc82ZaLeCSQ== X-Microsoft-Exchange-Diagnostics: 1;DM3PR07MB2252;31:IK8ahJw7cio/kqWcet5MOg+2LSYIfULPZNw6YtMvxktmbsRG1KEVC5XNc8Ue2Aej/H9uy7ligvZx0cTCEWfqwKKMR5yPG/yXEoUdnRjkcTzOkd4c5hHyMSiKg9AzwEjmyLbgt2MozDPtpU5jyqusqtvtRqLPJt3KDMC1HLw5ehIws/8fSInOmOHRWvPNQM4UVojdhW0ig74F1GL4eHfK37IlnBuTpXtS7JhmFOotcNzaMT751UiDDrJ9zjYWzDvt3doGkXdh3yPmrtODjJPe7w==;20:QpKYsVL+S/qy9wMXgJTL0YDohfT87/ODn8NlaGNIlemyTRsxkZJgiYm5zHeZHbhMoGubOLlVswv5T8fZ6IxrjkPq/o0cPGt2zm4XBDOmhkn9xLA4fRK6dwL1CUbe9FYiSsRgj+COXWnyys6IyiHZcemukrnXedtYY6Bh+wqT2vPEq6pswHKaXTWNMyjfMlqYdvaAXt01/z0aou77V2F1fLJDzkYFTC8UeV3KMoZCUdbhkibqc0eT9e/Mh4Vs8zxm7jfSSJc5VQp7pp5DNTd1Db28wI6ht4GrdWJhIEtW4VcdQ0tWYu1k25UCghHTg2Y4INg0yqmVW3BhXDD5J2oB9uzo6qNa57iKdGvkRb0G08mUsilmP78zM2snS//kNG2cBC0Vhr9IStYgo+7rw25RIuQJQtVAhv5/+YrjXoTcrGk4ccO2TNzJRLgkscOZWFpXD9ib6sIoUuZbec6fjz1kfbKfRve4Mbch1UxeoM11ut+UufSjMXplcgKDib2TCXWNp5gHG3FmoiPhd7jWlcruV8taYO1mnKkhYrPdFpN82U+8YCISLjfP/1qV7SOaUuEnCYis97T+0xinGFTfoJHdLq/HbicvNLfe4eJozL8IlIA= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(166708455590820)(36064498253994); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(20161123558021)(6072148);SRVR:DM3PR07MB2252;BCL:0;PCL:0;RULEID:;SRVR:DM3PR07MB2252; X-Microsoft-Exchange-Diagnostics: 1;DM3PR07MB2252;4:g8BhW+40hI+QyODnTEkpVx37NHIKgWWczUnxH5lTeI+ucaEamytDQQvZ2avNB51CMtSwWG7RkLTOt8PdUVTzNrxWD24VxV+6HL10vWglmcCfpAv2saQCbgqZWLdharVhsXMyIQcb7QXy1NNPMUPWuoaNci82nN5f9GUWIWX/mfVST8mAalTsZ4B4XAnj/Eo1ko3LkR6gqlYEIGyv2pfgnYw+x50E9wIBxlwqvge8WNzSHbGoF5cdYzsu08clIOUqdsUy5R8HLDtgoukrphI3e9rPsEQokJ3TEXhWG8fk2x7CBBMhPM6WnRqBwmu6OGMs4QskEwtU1V7Wv/6N4LwZby5TWOy6R+JOtEZ3mv1clm8NppKjPSA3DjpbRDkm0jejfYSN3YMCzao+/1yKEuuqXBYine1zcQHO+mDedF9Bof3UKqpOrSDL1BKIgwFUAU7mAIAGjt9awjBXUjU3uP3OGksweWsOT5xMlIEHY0sPIs8DX3Q1B8AsJT5rs5nZ6ZL4Ka9nzDEACFPmAicvhLZ3ahzxBGbwNdznJXpenA16W6DfQZkpYnheLRGSK57x8I77oprUASOA3onWAbzWVmLUxJkhEqdlkjSCyPLbgepGiojXAD9RmYJk2iUYE4M8BLyF0GQtpSULgRR2pc+bzLpFPOxw2Rmm7JI8p75/3pZiY1G4nUIVcPua6lffeFS9BywJ X-Forefront-PRVS: 0178184651 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6069001)(6009001)(7916002)(39450400003)(24454002)(189002)(377454003)(199003)(8676002)(33716001)(50466002)(68736007)(39060400001)(6116002)(6916009)(305945005)(3846002)(92566002)(38730400001)(4326007)(25786008)(229853002)(33656002)(76176999)(6666003)(101416001)(54906002)(23726003)(66066001)(1076002)(2950100002)(2906002)(110136003)(9686002)(42186005)(93886004)(83506001)(97736004)(5660300001)(575784001)(97756001)(46406003)(54356999)(4001350100001)(50986999)(47776003)(76506005)(7416002)(105586002)(6306002)(81166006)(189998001)(6486002)(6496003)(106356001)(7736002)(81156014)(18370500001)(2690400003);DIR:OUT;SFP:1101;SCL:1;SRVR:DM3PR07MB2252;H:localhost;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;DM3PR07MB2252;23:DehpcATHZzqiQVC2wfYgEplJkNCCwXvW5M8Ljzj8c?= =?us-ascii?Q?5cyziG9iqSkmJiP4N0zRO0V45MWBFi270pcHKEL2DqTJ/L0rqc3Rlsag1i58?= =?us-ascii?Q?eZ4r3nMvMEcbx5eZ5dmLd+gRxaB5IoWCLnF0/mPft+tRlDDTNr3nuGxBPNu3?= =?us-ascii?Q?1cMNjFmOkxm1XxakaO7xsCiaO1/thtNe4JOR6uHtdPnzkzmGmIfnpwcq6m0b?= =?us-ascii?Q?wNV8myt7Bj0qplpfo3IDy21GfdHOFzANsD4cmzQSe93es7s4W1HpB+Lj7ySt?= =?us-ascii?Q?MEXcG/gnpluUOEDm6YObx0SIuFNEdSYv5E5FeUGzscvyKu/8McyNq+mtmozN?= =?us-ascii?Q?3/5bn7gm+Zwqol7BdUWiOfk3re5zI8e9eKQOhXbTAKZMoV6PPTLu+TB1EWB/?= =?us-ascii?Q?RlJWzDN3AhYb5Ek5Mu6wGSD3Hpkk3cRZMW0tF2+aPRjjipMRYkNjq0hdCIvN?= =?us-ascii?Q?7pxyje1Y+WHrTW02YI74Cis6WBDKGapoQVlhYI/bfSm3Ps9Qhqdq5H/6by0c?= =?us-ascii?Q?SL1tq3KPq53Aj+W/mLK/xj4HDBZRzQhrPZnSeJYNwu7dh7I2gujo4ysih0Ej?= =?us-ascii?Q?zTpdLXVsNVQM5AgNtZIEKE922S4gvJrx5WZvAh9ESYY/LAWwkNOr2Xq6zwUG?= =?us-ascii?Q?4jdlOhYcjqGHPDM6/dVB5hdUuNLdQh6Vw5YSRwmM5duKj1ZurFhyzcdzy4jz?= =?us-ascii?Q?9TTaoeZHyqQB0HQ5QaelR735fTFvqZznEBSDhD8l9NL8o1SBRubhuK7Piq8d?= =?us-ascii?Q?ks+vSIp+sBienyhwSSAmehfD6aXNWjrrCif83GFYilfKZbKiOSFSe3jt6cSg?= =?us-ascii?Q?jIXxWzTPoo7q594PAeeoKIzCLv5uBl5wGm2DhFI+gV4cQwMeQD9xEjoBZLFm?= =?us-ascii?Q?PbMXb1mcgW3+dtr/UYh8g3JVyNIVfgWkK/XANPWk+gz0Zi+IFoKyAI6Ulgl2?= =?us-ascii?Q?uFkPJDBgYjK+KV69fchBEBXAbPR/L7Sx+ZVfEWYRnJAm03oO3AKq3Tf6OENo?= =?us-ascii?Q?z3BO/kp06qpeY5G8nebk22JmHYBRcESb7LADRB3TGc2CCF6at9iBx2zgNZwj?= =?us-ascii?Q?fvQHKHjYfxur8WRX6ETF6icYSopL5SNuu/N3H7rNeGUi6ED9zHdApoZ4toTp?= =?us-ascii?Q?O6TzClHNqcSHoiwOapy/TEiVmSdMoEj67hEkMKeJVo44PdimpTL3+1tUI9VG?= =?us-ascii?Q?Ag5QZk28sBHnJg1eK5kFgjGQ7F8eynpN/MA6jpiTbFfc5C8HcVBHpQ6pHGSG?= =?us-ascii?Q?7ZwMK470G2lEzFPC1BQI/wH3t5ziEQfPfcBnHxcIkNLhW7PmXyyYkfVpJIt7?= =?us-ascii?Q?NN0NffnW9F6T5Ufmr7s65RGVvIR93ONUuh64ooHtnSm6njVfS3TWlunBYYjF?= =?us-ascii?Q?OwJaS6+B5eoSgJQS/NvNSxWYPKC63W3n34iy70EkT0o+SUMpHcAdqfJIE8GZ?= =?us-ascii?Q?u/IyM2I8Q=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;DM3PR07MB2252;6:O70j+u+UyUF/oVmVKGYdvcRqImkYzB/HR4bCAZ+XJOQYSg0VuIxRT1YK0OeSr9kvqW7BJeskLCE0McuEqCV58mdCKE0UHg5H+rQfgCTNBJRfrvXX4Bg0C7XWX0xrncJwXiTKIKQmC+jumfv7peMmgHPrNTU9YMRZqBpgptB+o3H6P/WlQPnsh30jZDaU6+g+wZf73x6cG1pXkzZGs+7XKvC1OC0RcxOrndpbuGDY/TCgYAF4uL1+E57lW+91SPDLxLof7klZw5UsZq7LmRfxb4NjMESQV0GOHASeUieaDYRRUUlOO+jtA2icObh16T/jcOC9gQX9IDStksnBNtBWzXFEaYDvCbifw9HK6/XjHT5llxT50fzcq/2oNInzPTRHzQaXLUyGFNADeVoMPxT9mf1Om+DC4vL5FZFtRYlE2bE=;5:eOP1eDUaxdhHtLNzUBd0BZfmDFphmKtYZQAlHizqEAEb9VFVDeLcJ/BNgQrS03v8kQRjRyEA7tNQuHW1oKd/1s5Ckpiz2hfsBA44ZJk1EnyorORGWw3aV/3q4NImjtCdJnQqvdzFqiC2o84OOakl9cGffhV7C1Pj/xTAWzBkVV4=;24:nH2bAjC49p0kbUUI09KYS5nBR/r8y/9UOfMwnwqjMyaNAGFWp+fLCmkVX9yo0GpuNYna09fY9kFdKQnl4++or7fgKHaEAHkKpHCBT5S/0/o= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;DM3PR07MB2252;7:EslXKhNH0EKItJ6ibIDhGdRsvnS03/arCF5u0G64RX4r8IZH3kgPJvJ8IB4ahIJWHdACA64a5m3tkLVIxgsI/hgaACHFOvBbjV2vb4IdUu1rg47SIJ4d83KtGdffr0C6EX2//gARC5aKr7q0OEoM/pj50kAVT/7hZBdrl3ElHdisMB8beei3AkR7q+7Y4gsUOJNJIJ0hDHzUH6bpH6/moAOLApqMnAcQAqM0/qEUVrLTRpLXEerjR3NIDM6Fg+uY1TCWT73WlMMwr1HLskgUezZTu5PEOLXSz04rCrdIinl5mL4mvHurWCtJQbg1Wu5T3gfQz3awcucfIZF/j/dICf7X+bZBF4QRUPGjKqjRcoK+5xhV7RiLVGd3ZTtboAZ1e2Yzh1COxYx2w+aCgaRFHDVaDtcfdZjNQaYfG+k4dbwj02srcXD0SmNmboKjY3xKgYgAX9yJmbAJCossJ4WQYg== X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jan 2017 20:40:20.8118 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3PR07MB2252 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 07, 2016 at 09:40:13PM +0100, Arnd Bergmann wrote: > 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? ILP32 tasks has unique context that is not like aarch64 or aarch32, so we have to have unique ptrace handler. I prepared the patch for ptrace with runtime ABI detection, as Catalin said, see there: https://github.com/norov/linux/commit/1f66dc22a4450b192e83458f2c3cc0e79f53e670 If it's OK, I'd like to update submission. Yury From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yury Norov Subject: Re: [PATCH 16/18] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32 Date: Fri, 6 Jan 2017 02:10:03 +0530 Message-ID: <20170105204003.GA7437@yury-N73SV> References: <1477081997-4770-1-git-send-email-ynorov@caviumnetworks.com> <20161206062508.GA17835@yury-N73SV> <20161207165913.GD31779@e104818-lin.cambridge.arm.com> <3703608.GKr1zzErMk@wuerfel> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <3703608.GKr1zzErMk@wuerfel> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Arnd Bergmann Cc: linux-doc@vger.kernel.org, szabolcs.nagy@arm.com, Catalin Marinas , 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 List-Id: linux-arch.vger.kernel.org On Wed, Dec 07, 2016 at 09:40:13PM +0100, Arnd Bergmann wrote: > 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? ILP32 tasks has unique context that is not like aarch64 or aarch32, so we have to have unique ptrace handler. I prepared the patch for ptrace with runtime ABI detection, as Catalin said, see there: https://github.com/norov/linux/commit/1f66dc22a4450b192e83458f2c3cc0e79f53e670 If it's OK, I'd like to update submission. Yury From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-bl2nam02on0070.outbound.protection.outlook.com ([104.47.38.70]:34149 "EHLO NAM02-BL2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754496AbdAEUlA (ORCPT ); Thu, 5 Jan 2017 15:41:00 -0500 Date: Fri, 6 Jan 2017 02:10:03 +0530 From: Yury Norov Subject: Re: [PATCH 16/18] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32 Message-ID: <20170105204003.GA7437@yury-N73SV> References: <1477081997-4770-1-git-send-email-ynorov@caviumnetworks.com> <20161206062508.GA17835@yury-N73SV> <20161207165913.GD31779@e104818-lin.cambridge.arm.com> <3703608.GKr1zzErMk@wuerfel> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <3703608.GKr1zzErMk@wuerfel> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Arnd Bergmann Cc: Catalin Marinas , 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 Message-ID: <20170105204003.CSePB38Ic0cR2qkYx7LaTwZFZXaDm9EcQJmGgLAsY8s@z> On Wed, Dec 07, 2016 at 09:40:13PM +0100, Arnd Bergmann wrote: > 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? ILP32 tasks has unique context that is not like aarch64 or aarch32, so we have to have unique ptrace handler. I prepared the patch for ptrace with runtime ABI detection, as Catalin said, see there: https://github.com/norov/linux/commit/1f66dc22a4450b192e83458f2c3cc0e79f53e670 If it's OK, I'd like to update submission. Yury From mboxrd@z Thu Jan 1 00:00:00 1970 From: ynorov@caviumnetworks.com (Yury Norov) Date: Fri, 6 Jan 2017 02:10:03 +0530 Subject: [PATCH 16/18] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32 In-Reply-To: <3703608.GKr1zzErMk@wuerfel> References: <1477081997-4770-1-git-send-email-ynorov@caviumnetworks.com> <20161206062508.GA17835@yury-N73SV> <20161207165913.GD31779@e104818-lin.cambridge.arm.com> <3703608.GKr1zzErMk@wuerfel> Message-ID: <20170105204003.GA7437@yury-N73SV> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, Dec 07, 2016 at 09:40:13PM +0100, Arnd Bergmann wrote: > 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? ILP32 tasks has unique context that is not like aarch64 or aarch32, so we have to have unique ptrace handler. I prepared the patch for ptrace with runtime ABI detection, as Catalin said, see there: https://github.com/norov/linux/commit/1f66dc22a4450b192e83458f2c3cc0e79f53e670 If it's OK, I'd like to update submission. Yury