This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: mmap64 with very large offset broken since glibc 2.26 (MIPS64 n32)
- From: Zack Weinberg <zackw at panix dot com>
- To: Thomas De Schampheleire <patrickdepinguin at gmail dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Date: Thu, 13 Jun 2019 13:36:23 -0400
- Subject: Re: mmap64 with very large offset broken since glibc 2.26 (MIPS64 n32)
- References: <CAAXf6LWW9kknauk11d2Yi-18f6sB1rAGcfhnW+=eKDK8jDBVNA@mail.gmail.com> <87k1dp1yts.fsf@oldenburg2.str.redhat.com> <CAAXf6LUtjxaksSjzKC0VUNJrpbO2zPVwAnqcPjobXwyD02Q=Xg@mail.gmail.com>
On Thu, Jun 13, 2019 at 1:19 PM Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> In this thread there was some discussion about the syscall convention,
> but actually: with glibc since 2.26, there is no actual syscall made
> anymore: it is glibc that does a preliminary check on the offsets, and
> returns early if the offset is considered too large.
Right, but this preliminary check is a workaround for what we
_thought_ was a kernel limitation, where the `mmap64` syscall doesn't
allow you to pass an offset larger than 1<<44. Your program working
with glibc <2.26 indicates that this kernel limitation does not exist
on at least some architectures, but to remove the check safely, we
need to understand exactly what is and is not possible at the syscall
level on all supported architectures and ABIs.
zw