Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752514AbcLFVVr (ORCPT ); Tue, 6 Dec 2016 16:21:47 -0500 Received: from mout.kundenserver.de ([212.227.126.133]:65060 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752363AbcLFVVq (ORCPT ); Tue, 6 Dec 2016 16:21:46 -0500 From: Arnd Bergmann To: Yury Norov Cc: libc-alpha@sourceware.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, Catalin Marinas , szabolcs.nagy@arm.com, heiko.carstens@de.ibm.com, cmetcalf@ezchip.com, philipp.tomsich@theobroma-systems.com, joseph@codesourcery.com, 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, linux-arm-kernel@lists.infradead.org, maxim.kuvyrkov@linaro.org, Nathan_Lynch@mentor.com, schwidefsky@de.ibm.com, davem@davemloft.net, christoph.muellner@theobroma-systems.com Subject: Re: [Question] New mmap64 syscall? Date: Tue, 06 Dec 2016 22:20:20 +0100 Message-ID: <3014428.VXGdOARdm1@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <20161206185440.GA4654@yury-N73SV> References: <20161206185440.GA4654@yury-N73SV> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:mGmXJieeD1wHJ7JuPCjWZmSxvUpIP/HWYCc1N594Y3Ie9Sxv0LJ XWMS9zUx5BRLAjzmTVj9/Xqg7pubc73N7Ld4WBMgL9uMIMh6bAj5sSXp4JmDI4cnLGcKDcZ m7MM0/IaeSardjvRwLff7lWC/5kg/Bq9IaFSu8121Dz3a8ybwrn3QhJA6epXkx9BkfbQLmI sxtk0pvyEYtl3JMLqQQDQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:goWSmvsQyYk=:b2XV5sc8ihdqBizT/z63kj OPMtyA+bQ0bRHQicW8V+1TxSOxJGOYr8FZKXyJjFVam6a61fBU/U82U+TKG1kGPog/oz4yMdh cyvQiBh7TlmG2+YtCODV/P9Tv/l2qXJCDV6FrJa+QfBItEpkt9K6kXoGrlj/eQ/m1D3xx5/n2 iTsr29hEalcJmE+UQVV5m1dgCsAYvMOnbN/NLmEPabuKCtpbDRiqvZbR85JV+08YNFJHTa2X5 nyRWeoSBH0+ejupQ6Ynw1MDhF7hEY8UB1xn/updCUtyEZc4VO3blpX8S77eLF15hqvzOTmGIm AqbhPA2X8QpPpseHecTmEw5XjqUPKdb4/Ce1vuPRsYttjgTbNPWI1z9Tlpwrm9ZTaqFeEi/0C cDkUlPCjcXt3qFrcCQ6pVwWd6gfak6Ik3W9GaIy5aHUf5308QgoIZadGVXbNgpDBIPhykq6fN 99S7o4TcjM4LTTmUDiUUuA/daj7d5kqBLQXGLGA792QNsE9Na2s4f/qHwsF4FdH/0H7XJMNxO 0BWwwnJNqOK0hlC+P3ACAwoIlMsTuQpnr+VLOcL91KpTJgTbNOFIet/BWQ39KCvT1/1ccJgoU Rc7C5XQ4Y+2TIZSrx3ZV5zhSM44Z5uBWXnHIBaGN/itoOpI65ogLV5YqEVpsIyjyZrqApvnts S/Q9nerphzYOlW2aVe9EYschwMQDUCQIWVPib+L7/Afw6v89wUMuyYNZsno1Ks08wdizJG9FG MOnL1u0PzOwy5WKe Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2229 Lines: 47 On Wednesday, December 7, 2016 12:24:40 AM CET Yury Norov wrote: > I see 3 solutions for my problem: > 1. Reuse aarch64/lp64 mmap code for ilp32 in glibc, but wrap offset with > SYSCALL_LL64() macro - which converts offset to the pair for 32-bit > ports. This is simple but local solution. And most probably it's enough. I wouldn't want arm64 to be different from all other architectures here for the 32-bit API. The mmap() API used to be done entirely in architecture specific code, while nowadays at least new architectures use something resembling sys_mmap_pgoff(). I think that was originally introduced to be the default API for 32-bit architectures, but it failed to address architectures with variable page sizes. > 2. Add new flag to mmap, like MAP_OFFSET_IN_PAIR. This will also work. > The problem here is that there are too much arches that implement > their custom sys_mmap2(). And, of course, this type of flags is > looking ugly. Right, better not touch make complicate it further. The other problem is that mmap2() already has six argument and on most architectures that is the limit for the number of syscall arguments, so you cannot add another argument for the upper half. > 3. Introduce new mmap64() syscall like this: > sys_mmap64(void *addr, size_t len, int prot, int flags, int fd, struct off_pair *off); > (The pointer here because otherwise we have 7 args, if simply pass off_hi and > off_lo in registers.) This wouldn't have to be a pair, just a pointer to a 64-bit number. > With new 64-bit interface we can deprecate mmap2(), and generalize all > implementations in kernel. > > I think we can discuss it because 64-bit is the default size for off_t > in all new 32-bit architectures. So generic solution may take place. > > The last question here is how important to support offsets bigger than > 2^44 on 32-bit machines in practice? It may be a case for ARM64 servers, > which are looking like main aarch64/ilp32 users. If no, we can leave > things as is, and just do nothing. If there is a use case for larger than 16TB offsets, we should add the call on all architectures, probably using your approach 3. I don't think that we should treat it as anything special for arm64 though. Arnd