From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754155AbcEZOuQ (ORCPT ); Thu, 26 May 2016 10:50:16 -0400 Received: from eu-smtp-delivery-143.mimecast.com ([146.101.78.143]:52554 "EHLO eu-smtp-delivery-143.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754024AbcEZOuN convert rfc822-to-8bit (ORCPT ); Thu, 26 May 2016 10:50:13 -0400 Message-ID: <57470D19.2000501@arm.com> Date: Thu, 26 May 2016 15:50:01 +0100 From: Szabolcs Nagy User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Catalin Marinas , David Miller CC: , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH 01/23] all: syscall wrappers: add documentation References: <6293194.tGy03QJ9ME@wuerfel> <20160525.135039.244098606649448826.davem@davemloft.net> <6407614.fdv5XFSBue@wuerfel> <20160525.142821.1719403997976778673.davem@davemloft.net> <20160526142057.GA7456@e104818-lin.cambridge.arm.com> In-Reply-To: <20160526142057.GA7456@e104818-lin.cambridge.arm.com> X-Originating-IP: [217.140.96.140] X-ClientProxiedBy: AMSPR04CA0033.eurprd04.prod.outlook.com (10.242.87.151) To VI1PR08MB1104.eurprd08.prod.outlook.com (10.166.45.23) X-MS-Office365-Filtering-Correlation-Id: d4384968-3798-4659-e849-08d38575064e X-Microsoft-Exchange-Diagnostics: 1;VI1PR08MB1104;2:0sL2CuQ8NLm1hACwgD13srpAwZh+5uyf4BtirJVwJ6n9YjaTZPnyJEN7b/X3SP8BNKAuBaQiRHMszqKGGPBJ5dfPY/JyJLJJDJ3XH0K6BjoYAm2iFcFPTrkkJSkQPWUJRBkSzp+2GQFsvoyQTaVfHCsG6SamErQRJsUCKItEks8vTVpy3Jm/CkXG5VfwQWDm;3:BBjQ19LbhwDa4an4pXlRcY6YMhPIHqsvyhzlliyMnOR4She8QxOAzIUo16372TnxrQVdd5/yd7kJ8p+PAjCjR/+KnPyncJVjbPNKatZkL9KnbbUopCTGb3K1uC0G03va;25:iD0Qvkwtke3bQPlsbggCPZRoutvEloNiKFRn3ng+2xoEaZIqFga0eniqh1t8WyaUhZKiz7mFInqh0j+CMZz5xvdwCpu9ZyWo3HBFSqtY2rPbFNHmJnCnMUKK3qQWBaaVPE9YdARN5xNn/QeQdJDkKByMAPG6oc+xr7+rYDMyiLJ1ECpmkExTHMCkUwbixlKrws3tymxmBU+RxqPAFT1SIHQkkaBN9xNMLJ7cnpoU1knjbqMig6228r2P6IUZ7/WEbRjBcjPan8oTMMi46BFg3AWmGNdQi6W7yIkxBsnMd86bh7gxTuGRzkGUxHe/JDG1b1SzFtYNB+9+l9+BU+QMdapfo30akibNi/FFzA5GvIxlPxfrJvTyqtWRABr+5RhwZgoAa87URIbPTqO3vFN5BMEomm07Ushz6OXTNmrgcf8=;20:R3IVUZEYoxz+PJhX8YyioGLjgbJcuTgOdgJZo6ULyg+R05YrG93PCoeHj8J2RS9TVPbgoSlrqiAYK00prQKo13TtaMeIsyNn5mTo3195iNnxXUNRvne7xPWyuw+yPEzvSqHYbV1QX2xQ7fnQ8BupzEh8FmDOBfEpAfAFFV5ri8o= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR08MB1104; X-LD-Processed: f34e5979-57d9-4aaa-ad4d-b122a662184d,ExtAddr NoDisclaimer: True X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026);SRVR:VI1PR08MB1104;BCL:0;PCL:0;RULEID:;SRVR:VI1PR08MB1104; X-Microsoft-Exchange-Diagnostics: 1;VI1PR08MB1104;4:d2+QBuIWmFS8ruRsKVAZu2n7Ql5+Ha9Qcmg3OtqnZT1M3SCk/KPzKI3RuDOZ+i924bAsY1FGAew+8e5eTpoKIxq4tkaJ0BR42fc7b0sFltTkWKFQ7K2HWXAQXKHqWHS0dOZsJKI4M10wMgxqn2vIYcu9y8NRBDxLsXSJcbDLdLIiXOwS3RaSBf8mEzun0MM2VzSe+xkKomzBZL+pjqhCbOnvMbR6taz2g8Ad61W5Mb9Q34GRCTBLsVM02F+bOtS7vVFPefnAP9MAWpYeWpzjw4WK51eYBe7iPLeiMRyYJGA3bR9xbIIMPz+FKAH0EQYRY1Ltroiz2SAVeUn/jBiv2Rsmat9a5o8oXLcsql7NRDLy3uqr7/qQnwQ49YRsHJ9K+bdwtvL2wfqHNshi7vlK+Q== X-Forefront-PRVS: 0954EE4910 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(979002)(6009001)(6049001)(43544003)(24454002)(5001770100001)(5004730100002)(64126003)(586003)(81166006)(8676002)(4326007)(65806001)(66066001)(23746002)(189998001)(92566002)(65956001)(2906002)(86362001)(2950100001)(36756003)(6116002)(3846002)(59896002)(93886004)(99136001)(33656002)(47776003)(87266999)(54356999)(65816999)(76176999)(4001350100001)(50986999)(77096005)(42186005)(80316001)(83506001)(50466002)(230700001)(5008740100001)(969003)(989001)(999001)(1009001)(1019001);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR08MB1104;H:[10.2.206.73];FPR:;SPF:None;MLV:ovrnspm;PTR:InfoNoRecords;LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1;VI1PR08MB1104;23:zTEhYk5EEeuMRv534jK8oivw85OmudiQ7Ana8?= =?Windows-1252?Q?sx53HcUPkGtuD5mfwdAlr6hqzF+LlYqtk7PkBNzy4JWJU50k4+40VUA4?= =?Windows-1252?Q?guf0fONPv7peuIqW7QoWr5QZOmBnntmhAmjlr1kFSvRNINi5B47k71ce?= =?Windows-1252?Q?hFzPAwYr0i5xeGCB4HIWfgIavdiD+eoSipw08FDr7NkLSJXWQeWIql+G?= =?Windows-1252?Q?CUcQ8hxkXWS9dkgnFdc+QHWV7r3X4H4vwhQqZDTmpXhz4Jgi/0YDDbO/?= =?Windows-1252?Q?hTB8O8xgxMSBHDPhFv/IpPU4DOkU4VTLW+aZ6f+iHN7EZoC1MXgCTnRH?= =?Windows-1252?Q?7vPbPVXxmKcZJ52NWzlS1j9UE6iXB+RQrnKDIpI4kyWXVO743eweQDQJ?= =?Windows-1252?Q?hY/ooBf+GtbX/wOlhOLXbmcUdNJlGUFfxAN/QCOnP4jlzdQhV3SW8/Ig?= =?Windows-1252?Q?2HiLSXFKgU5mJZPfY8pAZKSYrJwlVc9zGIqRu1itGgqRL8xtp6iki1Yr?= =?Windows-1252?Q?mdqdQy7juzAhLlSkCFJUBQb41B/Mm217AbzhaWTg2KHdyI/Vpnk+Jklx?= =?Windows-1252?Q?m3d3wopfHnM5h1d0Y9OKjBz/seyrIe6D2eVBZaVIbCVlVUL3O4fOweWE?= =?Windows-1252?Q?5SxVMDl02ontJnNyzEuheOcZMnge7iDjdyDN5FM6f4/E5wFsevIXuLCp?= =?Windows-1252?Q?bi5/kuZScfGSbwYb9ObPrZQ8NyRzTame8r+rMSeTWemamZJqdMcwtFdv?= =?Windows-1252?Q?Q3EuWGFNW0u+uk7ORwXAg+kxGB3Cqo1MjSqqy6PtkhpDBYkxayMUqfXW?= =?Windows-1252?Q?Qxv2nFVmYFiC/VgvZ2t1Zv9MJJSt5m+yvPT7VpWD5qUusLg/Wbj3aN66?= =?Windows-1252?Q?/oEjz74bPrO8SneHbG/CaQc7VREen661G/2KDHyrb6FZj5NeasbJ8gd+?= =?Windows-1252?Q?l702MKwthL4ygzrKl+aOZB5t0wVRLjil01LNZLYWJQbPaHCmEkyRe20u?= =?Windows-1252?Q?duYoFFpURLpygFfAiAC+5CIpV49yWaXuXUE7GSG2zfA/kg4e6rncb6IY?= =?Windows-1252?Q?omMJwObpmBN4xu1MQZTcRPXpE+JwR2uiVGpUBKNQcgtLqUM1oCekL6Ce?= =?Windows-1252?Q?HcQY0Ur0AT+OsSDmorKm59prV7a2Ha7GVCw/9xC6DjUEXruHM8J2nttW?= =?Windows-1252?Q?iwInxpxnBWCGIHABAk8T+g8C6q9uFg1wQf2CH74/DjNbzJQ2NYknl0Y2?= =?Windows-1252?Q?p+/O7rTq+A+dObCvZSx5eqUH095bpU/ssORtcoDIDQGffDh0x0dkv/Nz?= =?Windows-1252?Q?5Ww?= X-Microsoft-Exchange-Diagnostics: 1;VI1PR08MB1104;5:97fBvlv2mOe1YqBDi75BRzLB/afXzZxy8j6GqGBGngSuO/anhrLizuY3VCwPp8HfpBErse7Qq92SDXxl/eCzdroydt7LtM4H9LnOdwLVJGiI35+LUHh2CW8+jT+82ABzNt6xP2aZ221OL/436DXbPg==;24:/A5cfLLqSFXS39fD1cBDmnAwR4NWZqG4gYbZPKraBbKB21Wiw6qtsNBDkESBx9W4EeJJxU+a1h8IvJjO3PlTr8wSMbFhdB6bNUO5ogvezUU=;7:Idd5ZIXy9JkN136ayHwKFDVRENJ2lXaKNr4buWzfMTI5ddg8HHKb6MzhOzJFoeN8Yqc5K06pDiWEZ9zy/2VcM2VMZfkHGbMBGJwY/Mwhl+MyeM0ZdTJG990Hj8Ht7aOc2hWo6XV76pgEyELS4gAQmBW+w+OlXp6RqfzTXCe3uLcOMvxt+NXqPpv7ARSrnrkM;20:2HJbngAI79eOoMHBWUu4mKldEVQAQKxSs26tSUK1IT79yX/4be244itdIXjawa53ZqpHJAB+vlr3dUvtpnA9Ch+o/0RzClid10Eq/x9nwTP/abQHxz80rkvn55Qud5AYOHQcsZfY5wtelsdZXGHt437wFGZRkWZVXMRuPadpIqg= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 May 2016 14:50:04.2405 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB1104 X-MC-Unique: -SbqA56JQBmlmgovEkOFJg-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 26/05/16 15:20, Catalin Marinas wrote: > While writing the above, I realised the current ILP32 patches still miss > on converting pointers passed from user space (unless I got myself > confused in macros). The new __SC_WRAP() and COMPAT_SYSCALL_WRAPx() > macros take care of zero or sign extension via __SC_COMPAT_CAST(). > However, we have two more existing cases which I don't see covered: > > a) Native syscalls taking a pointer argument and invoked directly from > ILP32. For example, sys_read() takes a pointer but I don't see any > __SC_WRAP added by patch 5 > > b) Current compat syscalls taking a pointer argument. For example, > compat_sys_vmsplice() gets the iov32 pointer and the compiler assumes > it is a 64-bit variable. I don't see where the upper half is zeroed > on x32 sign/zero extension is currently left to userspace, which is difficult to deal with, (long long)arg does the wrong thing for pointer args. > We can solve (a) by adding more __SC_WRAP annotations in the generic > unistd.h. For (b), we would need an __SC_DELOUSE with a bit of penalty > on AArch32/compat support where it isn't needed. So maybe davem has a > point on the overall impact of always zeroing the upper half of the > arguments ;) (both from a performance and maintainability perspective). > I guess this part of the ABI is still up for discussion. > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Szabolcs Nagy Subject: Re: [PATCH 01/23] all: syscall wrappers: add documentation Date: Thu, 26 May 2016 15:50:01 +0100 Message-ID: <57470D19.2000501@arm.com> References: <6293194.tGy03QJ9ME@wuerfel> <20160525.135039.244098606649448826.davem@davemloft.net> <6407614.fdv5XFSBue@wuerfel> <20160525.142821.1719403997976778673.davem@davemloft.net> <20160526142057.GA7456@e104818-lin.cambridge.arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: 8BIT Return-path: In-Reply-To: <20160526142057.GA7456@e104818-lin.cambridge.arm.com> Sender: linux-doc-owner@vger.kernel.org List-Archive: List-Post: To: Catalin Marinas , David Miller Cc: nd@arm.com, arnd@arndb.de, ynorov@caviumnetworks.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, libc-alpha@sourceware.org, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, pinskia@gmail.com, broonie@kernel.org, joseph@codesourcery.com, christoph.muellner@theobroma-systems.com, bamvor.zhangjian@huawei.com, klimov.linux@gmail.com, Nathan_Lynch@mentor.com, agraf@suse.de, Prasun.Kapoor@caviumnetworks.com, kilobyte@angband.pl, geert@linux-m68k.org, philipp.tomsich@theobroma-systems.com List-ID: On 26/05/16 15:20, Catalin Marinas wrote: > While writing the above, I realised the current ILP32 patches still miss > on converting pointers passed from user space (unless I got myself > confused in macros). The new __SC_WRAP() and COMPAT_SYSCALL_WRAPx() > macros take care of zero or sign extension via __SC_COMPAT_CAST(). > However, we have two more existing cases which I don't see covered: > > a) Native syscalls taking a pointer argument and invoked directly from > ILP32. For example, sys_read() takes a pointer but I don't see any > __SC_WRAP added by patch 5 > > b) Current compat syscalls taking a pointer argument. For example, > compat_sys_vmsplice() gets the iov32 pointer and the compiler assumes > it is a 64-bit variable. I don't see where the upper half is zeroed > on x32 sign/zero extension is currently left to userspace, which is difficult to deal with, (long long)arg does the wrong thing for pointer args. > We can solve (a) by adding more __SC_WRAP annotations in the generic > unistd.h. For (b), we would need an __SC_DELOUSE with a bit of penalty > on AArch32/compat support where it isn't needed. So maybe davem has a > point on the overall impact of always zeroing the upper half of the > arguments ;) (both from a performance and maintainability perspective). > I guess this part of the ABI is still up for discussion. > From mboxrd@z Thu Jan 1 00:00:00 1970 From: szabolcs.nagy@arm.com (Szabolcs Nagy) Date: Thu, 26 May 2016 15:50:01 +0100 Subject: [PATCH 01/23] all: syscall wrappers: add documentation In-Reply-To: <20160526142057.GA7456@e104818-lin.cambridge.arm.com> References: <6293194.tGy03QJ9ME@wuerfel> <20160525.135039.244098606649448826.davem@davemloft.net> <6407614.fdv5XFSBue@wuerfel> <20160525.142821.1719403997976778673.davem@davemloft.net> <20160526142057.GA7456@e104818-lin.cambridge.arm.com> Message-ID: <57470D19.2000501@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 26/05/16 15:20, Catalin Marinas wrote: > While writing the above, I realised the current ILP32 patches still miss > on converting pointers passed from user space (unless I got myself > confused in macros). The new __SC_WRAP() and COMPAT_SYSCALL_WRAPx() > macros take care of zero or sign extension via __SC_COMPAT_CAST(). > However, we have two more existing cases which I don't see covered: > > a) Native syscalls taking a pointer argument and invoked directly from > ILP32. For example, sys_read() takes a pointer but I don't see any > __SC_WRAP added by patch 5 > > b) Current compat syscalls taking a pointer argument. For example, > compat_sys_vmsplice() gets the iov32 pointer and the compiler assumes > it is a 64-bit variable. I don't see where the upper half is zeroed > on x32 sign/zero extension is currently left to userspace, which is difficult to deal with, (long long)arg does the wrong thing for pointer args. > We can solve (a) by adding more __SC_WRAP annotations in the generic > unistd.h. For (b), we would need an __SC_DELOUSE with a bit of penalty > on AArch32/compat support where it isn't needed. So maybe davem has a > point on the overall impact of always zeroing the upper half of the > arguments ;) (both from a performance and maintainability perspective). > I guess this part of the ABI is still up for discussion. >