diff for duplicates of <20161207103451.GA869@yury-N73SV> diff --git a/a/1.txt b/N1/1.txt index 9f993f9..7de94fb 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -21,36 +21,3 @@ On Tue, Dec 06, 2016 at 10:20:20PM +0100, Arnd Bergmann wrote: > 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. - -From this point of view, 16+TB offset is a matter of 16+TB storage, -and it's more than real. The other consideration to add it is that -we have 64-bit support for offsets in syscalls like sys_llseek(). -So mmap64() will simply extend this support. - -I can prepare this patch. Some implementation details I'd like to -clarify: -Syscall declaration: -SYSCALL_DEFINE6(mmap64, unsigned long, addr, unsigned long, len, - unsigned long, prot, unsigned long, flags, - unsigned long, fd, unsigned long long *, offset); - -sys_mmap64() deprecates sys_mmap2(), and __ARCH_WANT_MMAP2 is -introduced to keep it enabled for all existing architectures. -All modern arches (aarch64/ilp32 is the first candidate) will have -mmap64() only. The example is set/getrlimit() or renameat() drop -patches (b0da6d44). - -On GLIBC side, __OFF_T_MATCHES_OFF64_t will wire mmap() from -linux/generic/wordsize32/mmap.c to mmap64() from linux/mmap64.c. - -mmap64() will first try __NR_mmap64, and if not defined, or ENOSYS -is returned, __NR_mmap2 will be called. This is to let userspace that -supports both mmap2() and mmap64() have full 64-bit offset support, not -44-bit one. - -For __NR_mmap2 case, I'd also add the check against offsets more than -2^44, and set errno to EOVERFLOW in that case. - -Any thoughts? - -Yury. diff --git a/a/content_digest b/N1/content_digest index 86037d5..5b4295f 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -54,39 +54,6 @@ "> \n" "> If there is a use case for larger than 16TB offsets, we should add\n" "> the call on all architectures, probably using your approach 3. I don't\n" - "> think that we should treat it as anything special for arm64 though.\n" - "\n" - "From this point of view, 16+TB offset is a matter of 16+TB storage,\n" - "and it's more than real. The other consideration to add it is that\n" - "we have 64-bit support for offsets in syscalls like sys_llseek().\n" - "So mmap64() will simply extend this support.\n" - "\n" - "I can prepare this patch. Some implementation details I'd like to\n" - "clarify:\n" - "Syscall declaration:\n" - "SYSCALL_DEFINE6(mmap64, unsigned long, addr, unsigned long, len,\n" - " unsigned long, prot, unsigned long, flags,\n" - " unsigned long, fd, unsigned long long *, offset);\n" - "\n" - "sys_mmap64() deprecates sys_mmap2(), and __ARCH_WANT_MMAP2 is\n" - "introduced to keep it enabled for all existing architectures.\n" - "All modern arches (aarch64/ilp32 is the first candidate) will have\n" - "mmap64() only. The example is set/getrlimit() or renameat() drop\n" - "patches (b0da6d44).\n" - " \n" - "On GLIBC side, __OFF_T_MATCHES_OFF64_t will wire mmap() from\n" - "linux/generic/wordsize32/mmap.c to mmap64() from linux/mmap64.c. \n" - "\n" - "mmap64() will first try __NR_mmap64, and if not defined, or ENOSYS\n" - "is returned, __NR_mmap2 will be called. This is to let userspace that\n" - "supports both mmap2() and mmap64() have full 64-bit offset support, not\n" - "44-bit one.\n" - "\n" - "For __NR_mmap2 case, I'd also add the check against offsets more than\n" - "2^44, and set errno to EOVERFLOW in that case.\n" - "\n" - "Any thoughts?\n" - "\n" - Yury. + > think that we should treat it as anything special for arm64 though. -8056497c91064bc8009abc043bdfd3157a53782491cc0350b885c0d49903b8ef +d6f65546bc0726bf82585bf0fc42b74265e31b3d0eea835c8ea6ccbad81bfb1c
diff --git a/a/1.txt b/N2/1.txt index 9f993f9..759f45e 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -22,7 +22,7 @@ On Tue, Dec 06, 2016 at 10:20:20PM +0100, Arnd Bergmann wrote: > 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. -From this point of view, 16+TB offset is a matter of 16+TB storage, +>From this point of view, 16+TB offset is a matter of 16+TB storage, and it's more than real. The other consideration to add it is that we have 64-bit support for offsets in syscalls like sys_llseek(). So mmap64() will simply extend this support. diff --git a/a/content_digest b/N2/content_digest index 86037d5..c0d331b 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,35 +1,9 @@ "ref\020161206185440.GA4654@yury-N73SV\0" "ref\03014428.VXGdOARdm1@wuerfel\0" - "From\0Yury Norov <ynorov@caviumnetworks.com>\0" - "Subject\0Re: [Question] New mmap64 syscall?\0" + "From\0ynorov@caviumnetworks.com (Yury Norov)\0" + "Subject\0[Question] New mmap64 syscall?\0" "Date\0Wed, 7 Dec 2016 16:04:51 +0530\0" - "To\0Arnd Bergmann <arnd@arndb.de>\0" - "Cc\0libc-alpha@sourceware.org" - linux-arch@vger.kernel.org - linux-kernel@vger.kernel.org - Catalin Marinas <catalin.marinas@arm.com> - 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\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "On Tue, Dec 06, 2016 at 10:20:20PM +0100, Arnd Bergmann wrote:\n" @@ -56,7 +30,7 @@ "> the call on all architectures, probably using your approach 3. I don't\n" "> think that we should treat it as anything special for arm64 though.\n" "\n" - "From this point of view, 16+TB offset is a matter of 16+TB storage,\n" + ">From this point of view, 16+TB offset is a matter of 16+TB storage,\n" "and it's more than real. The other consideration to add it is that\n" "we have 64-bit support for offsets in syscalls like sys_llseek().\n" "So mmap64() will simply extend this support.\n" @@ -89,4 +63,4 @@ "\n" Yury. -8056497c91064bc8009abc043bdfd3157a53782491cc0350b885c0d49903b8ef +f72b636db5531a03e23db5f745d48c1f7d4dbfe0fa1fa77617d021e93811d199
diff --git a/a/1.txt b/N3/1.txt index 9f993f9..759f45e 100644 --- a/a/1.txt +++ b/N3/1.txt @@ -22,7 +22,7 @@ On Tue, Dec 06, 2016 at 10:20:20PM +0100, Arnd Bergmann wrote: > 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. -From this point of view, 16+TB offset is a matter of 16+TB storage, +>From this point of view, 16+TB offset is a matter of 16+TB storage, and it's more than real. The other consideration to add it is that we have 64-bit support for offsets in syscalls like sys_llseek(). So mmap64() will simply extend this support. diff --git a/a/content_digest b/N3/content_digest index 86037d5..2b5174e 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -4,32 +4,32 @@ "Subject\0Re: [Question] New mmap64 syscall?\0" "Date\0Wed, 7 Dec 2016 16:04:51 +0530\0" "To\0Arnd Bergmann <arnd@arndb.de>\0" - "Cc\0libc-alpha@sourceware.org" - linux-arch@vger.kernel.org - linux-kernel@vger.kernel.org + "Cc\0<libc-alpha@sourceware.org>" + <linux-arch@vger.kernel.org> + <linux-kernel@vger.kernel.org> Catalin Marinas <catalin.marinas@arm.com> - 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\0" + <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>\0" "\00:1\0" "b\0" "On Tue, Dec 06, 2016 at 10:20:20PM +0100, Arnd Bergmann wrote:\n" @@ -56,7 +56,7 @@ "> the call on all architectures, probably using your approach 3. I don't\n" "> think that we should treat it as anything special for arm64 though.\n" "\n" - "From this point of view, 16+TB offset is a matter of 16+TB storage,\n" + ">From this point of view, 16+TB offset is a matter of 16+TB storage,\n" "and it's more than real. The other consideration to add it is that\n" "we have 64-bit support for offsets in syscalls like sys_llseek().\n" "So mmap64() will simply extend this support.\n" @@ -89,4 +89,4 @@ "\n" Yury. -8056497c91064bc8009abc043bdfd3157a53782491cc0350b885c0d49903b8ef +99fbf97eb41e8a4705b27d3b9916487dfde06ded65ce66a1decd6f15b082bda4
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.