From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752854AbcELNYf (ORCPT ); Thu, 12 May 2016 09:24:35 -0400 Received: from mail-bl2on0082.outbound.protection.outlook.com ([65.55.169.82]:43840 "EHLO na01-bl2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752758AbcELNYc (ORCPT ); Thu, 12 May 2016 09:24:32 -0400 X-Greylist: delayed 10423 seconds by postgrey-1.27 at vger.kernel.org; Thu, 12 May 2016 09:24:31 EDT Authentication-Results: arndb.de; dkim=none (message not signed) header.d=none;arndb.de; dmarc=none action=none header.from=caviumnetworks.com; Date: Thu, 12 May 2016 16:19:48 +0300 From: Yury Norov To: Arnd Bergmann CC: "Zhangjian (Bamvor)" , Catalin Marinas , , Andrew Pinski , , Hanjun Guo , , , , "jijun (D)" , , , , , , , , , , Andrew Pinski , , Subject: Re: [PATCH 20/25] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Message-ID: <20160512131948.GA30205@yury-N73SV> References: <1459894127-17698-1-git-send-email-ynorov@caviumnetworks.com> <2733875.IzutTZKHMc@wuerfel> <57347BD4.8010105@huawei.com> <4521594.dSmlmmAdFg@wuerfel> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <4521594.dSmlmmAdFg@wuerfel> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [95.143.213.121] X-ClientProxiedBy: HE1PR03CA0025.eurprd03.prod.outlook.com (10.163.170.163) To CY1PR07MB2230.namprd07.prod.outlook.com (10.164.112.144) X-MS-Office365-Filtering-Correlation-Id: 4aba7cc0-90d4-40b7-1a40-08d37a68bef1 X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2230;2:aSm5R5XTQND3ntiJ7Utl13Dp9QjzrxqG9TQ1FxdBf/xmqEQ+gZu4mdl3SsFVYsk9pCwBWvZGxRITeoBbhMX6xMJszYuk2gWm0MbxLR3LNPU2FBYJ0EVpef6nLYIMNjwwtkpdfU/dkp5/BDJ8DjxmuDIldJPOm9+avYHnPCGegUzC0AgySQ+29T5Xeo5Iq4Tw;3:75Cwak3Rn68LgRok02FY3oFxvkC4tWSjMF39plI1iyhFLGvqto584//ktvdW5Rgof/6Qf16I1862ns8YzAuYROwQa9yiqtE7/gkl0woNH4PsxuAHOUltzgB72r3LKWXA;25:jkvJxbi47XvyjCqnogZHZdGd1zXIpCMKCQr2VQmViqCEzvBmB/vGR0W92Wh2Tn+RtwU+AyaHlY3YK9Ea9Ndz5A8EscyAJklubtXxZCPbopJw9DFK/NA4qBx42r+IJDpx24cIns8eDcSyeWol+aAT964P8tFxsEyqJs+ZLZql+Gz5NzeKZm7F7hnnow6f/SRKTcVL4m5yc6A4L1WnJbxXnMLKzO2WyHjLI80/PT6QmDs6SK8khPnoBslPuEGLdVGf5HZTTVyfWFUvuiVQjSKfYhnxK/c2rgwOINeCQbMJAy3hn+aEsI5c2w+wEDtPC7yrzvtBvDZ0dljo6sj80g61j5Te2MRiByhE3wvapK6fL3DqjlveDumZD+weuqU5tldIN/HwmcVV9RcewYrTEVf9YMAS+C4Yt3N8bxFCZsFozkA= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR07MB2230; X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2230;20:2OtUa7PCw61ig2LSLieRwisrbQNnu4D5Mw/KWbMRj8klRm9ETBC/9d8EpL1S12LfskG9Ur1oonPjyxS23M13iPMXKwx1OMysdpFz3dpHj0z6pkwC6UP0OCW0enGGcCzy6mJP+C8Yg4aLIF+SaXC6Jbt5eDpUfk8xgR9uapL6DIRkx6DoH5P97lmKzEqxtKY0bXaco9ItFH9cKD/mbCSQaNlh42rmj120cIi5gmXHW0qF0ZG2BCshqgNgJDKwa73CWUGMtfwyhO7O0hXGuuMjeNVEchjD4EUH65wuyaA64JzLvcT1LnvpewC0ZoZ9dJmXxfDK6rbOXE168SNxX5p4sKW8kz1Xjs+IUgkTVw9F16VRw9HIFm/zwvqMwBSOUv5fWYBrjNHWd1mdNwKTWdgulimmPWB56yfTYzXa0SURyvoyZi6x1bfr5NNtOYDrUuL0JiE3sROSpTy8WWayjFbwWjxNeMRexeke9t63pkb8f/XELcLynucxhxPaXACbSIW6chQV70s+lFvU4JTZhT2Rwhwl3KSnKnHN6aAWKLKmuNo8km32Fb6pBIUqed73Yjr1YjCb1z3dR4AxZameX2MNhgviCHeywSwPBODhhhEzets= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046);SRVR:CY1PR07MB2230;BCL:0;PCL:0;RULEID:;SRVR:CY1PR07MB2230; X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2230;4:QdfDtPubcPZHedxWKSVup/ME7yvA6l+hDYOfUaKTJuQwvhr7mSP0d//SzwhsJhrWXiSzBOt3xQ73UQ7at/F13U7i7asgYAIGxCk2VUJjJ32k3pZ5tABG1CZdOgx7tS/1ZHtO1wgdikGP9bYkJtJzrVsod/vtPKpc1AWd3shWx1UZWuDsnz2d8iEd989XJxq8v0n/ikcOhnh6yMD15VX24APy6E2uLhjBsMHVMz8DW7gbf/EfrqwVjLT6GfjSvL1bjYwsSflTO43vkSbguySO8r4Q6oOI6iCPpUz4MZYmlItlWpYGClWGpiO2o3hWMYanErsNGdFWIqvylxsD5sRxjenLff9s6slD0BCnma+OYHZPxrlM443OmxID37fuT9Pk X-Forefront-PRVS: 0940A19703 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6009001)(6069001)(24454002)(52314003)(51444003)(2950100001)(33716001)(54356999)(76176999)(9686002)(47776003)(50986999)(93886004)(33656002)(77096005)(92566002)(5004730100002)(2906002)(50466002)(97756001)(110136002)(81166006)(83506001)(66066001)(189998001)(4001350100001)(5008740100001)(46406003)(1076002)(586003)(3846002)(42186005)(6116002)(23726003)(76506005);DIR:OUT;SFP:1101;SCL:1;SRVR:CY1PR07MB2230;H:localhost;FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;CY1PR07MB2230;23:EeqUvtPhoBXlqcHVneXQnpH8LFttd9X7ix9SzzAZb?= =?us-ascii?Q?5jiQbAh9CSzv1pH/fpyb+OSgex88qHUTD4pUpXqI+0HYHycRkEOkxh4cz5NZ?= =?us-ascii?Q?J/HnWcwIN89UPjUQKqZfkRWqIli4iHQcP+0Z4K5L8D3NvsuyEb1hDKU0XJqA?= =?us-ascii?Q?UrV639j5eP4x8EY4qPZuxPFnnYYZgLyv/nQGLv9JO9QHx3xe3aPDxC8WsJyl?= =?us-ascii?Q?PuTjNFRSsg9KbkGOh5Fq0ZIR/j/NURgRYrlPCwuL6229WTqu37HFVC71fvhb?= =?us-ascii?Q?jDNv+8ClBfmAuKfb6AEpQXZIMBdAH/i3XTAUn5z//8KftAFCtPYD3YxMiC9M?= =?us-ascii?Q?xIPUga2LEb3wO+OwKudwwEdvBWcwNrvw+Ilxkdv6eIrzFX0dmJmFJ59J5cQS?= =?us-ascii?Q?Wkk56j5cVqN1KHeFyhmPzzvvHZGCdWtKq0E9x/1UAzaOXgo8Mysm++kDqKUV?= =?us-ascii?Q?OTDf7VKV4WHZEVGhUcGUg1RdX8kLRkr+/KWT8nxmXqwskLyzLueug+pJECSa?= =?us-ascii?Q?JsV445r7lyBGvk/ttswjqJD4HiWsz51klTdwEsn2Iu8WpXcTTzzmTtEqQWyM?= =?us-ascii?Q?t8tPjOfx3NfZtTMOCkc+cm074AXkjWij5ulQiVbr/BTc1idLn1NeK5DsAM7K?= =?us-ascii?Q?jIGd7HP6TTMvQji3NYpgtluajASn3Ph72aUWDdC43vaJ/WGi1jmIpSwgIkxk?= =?us-ascii?Q?WMQ7Yc5T2Wl249DrGJPwjMmHq48aNRbXdefi5dl4u/fFr936NfJGNy75nFde?= =?us-ascii?Q?lxnO7gKCq7TggXi+C0UC2Y1ZwQRx5jMwx1qsUqdG9EssyOSyELdqykfx4fA4?= =?us-ascii?Q?bw6AS3GJ3Cm44fHdduFaVjq9Ii8J5LLGc9wmH0xGEzlIHGrxiJ+TkPLrIk4y?= =?us-ascii?Q?ZzEIcYzL6fHtHqNqHh/AErAfwp23vc60mRL1UO2Lyi0YRJfRSVld3AgyPmGK?= =?us-ascii?Q?s8992/PNDhWgaSJIcCt2CCdiJ7Y6Sb7LJ4lKU+Brw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2230;5:If/gRhZpBHmQw7AfbkTe7/UrAM7EQ/yYSVXH2mctl1PVhuua99Hsu81O8D9aRiQ9PquTV5+SKSFPYIfm7yaOcrQF3jP1AZlYgam7E2sRS5xPp3bnBVDMR97JsorsxVyUIV2PGobwdmf6S9LFGySNuw==;24:uwEFGft/xKSaGofnpbTN7vhGSEw5Fsxlow5giOVv01nwqOpZZUBswjw/tGoCyidmunlxzTpPIxw1vM18+MZ+SoqC9434dh+95JpTvOFtwCo=;7:ncJ+jJxcMWPvGVJVV50FQye13mRiKI51iJSJpRLLTHCAKrXOxPQpM2fzRNOVp5e/AWwxCG9WjuutkBK2l+zJLwcc/vmQpydHb0q4RvbFd9V322+PO9/NarQksmqDK9o15pg78QEDGJinRPrOQTvTPsCewiKXe/cebdencxeGZOmKYIOJRtcLRHPbWFTp87iF SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2016 13:24:28.1936 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR07MB2230 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 12, 2016 at 03:06:39PM +0200, Arnd Bergmann wrote: > On Thursday 12 May 2016 20:49:24 Zhangjian wrote: > > Hi, > > > > On 2016/5/12 17:21, Arnd Bergmann wrote: > > > On Thursday 12 May 2016 10:17:58 Catalin Marinas wrote: > > >> On Wed, May 11, 2016 at 09:30:07PM +0200, Arnd Bergmann wrote: > > >>> On Wednesday 11 May 2016 17:59:01 Catalin Marinas wrote: > > >>> > > >>> I don't think the shifts are a problem, the main downside would be > > >>> the limit to 44 bits of file offsets (16TB files), but it's also > > >>> unclear if that is a practical problem at all. If it is, we run > > >>> into the same problem on all other 32-bit architectures too. > > >> > > >> I hope people are seriously thinking of moving to an LP64 ABI if they > > >> have such large file offset needs. > > > > > > Good point. 44 bits of file size is certainly enough for mmap() > > > on a 32-bit task: you would only be able to map a very small fraction > > > of the file anyway, and if you want to map larger files, and should > > > move to 64-bit tasks long before this becomes a limitation. > > Hi, > > > > I apply the following patch in order to make use of the REAL mmmap2. LTP > > test pass in litle endian. mmap16 successful with segfault in big endian. > > > > BTW, I saw the similar code in tile, mips, microblaze and s390 compat. Should > > we merge these code into a common syscall wrapper? > > I think that's a good idea. The function used to be slightly different > for each architecture, but now it seems we have a significant number > of identical implementations that we could just merge them together > into one. > > sys_mmap_pgoff was originally introduced as the common implementation > and it reduced the amount of duplication a lot, but as its units > are based on PAGE_SIZE rather than hardwired 4096 bytes, it's > not as useful. > microblaze and mips (twice) are doing like this. And aarh32 as well, in arch/arm64/kernel/entry32.S In previous submissions it was a patch that shares aarch32 code to ilp32. If we decided turn around again, I think, we'd pick up that patch. The other option is to make this hack generic, as so many arches use it.