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: Andreas Schwab <schwab at suse dot de>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Thomas De Schampheleire <patrickdepinguin at gmail dot com>, libc-alpha at sourceware dot org, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Date: Thu, 13 Jun 2019 14:19:34 +0200
- 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>
On Jun 13 2019, Florian Weimer <fweimer@redhat.com> wrote:
> * Thomas De Schampheleire:
>
>> Hello,
>>
>> In glibc 2.26, a change was made to the behavior of mmap64, as a fix
>> for bug 21270 (mmap64 silently truncates large offset values) [1], via
>> commit 158d5fa0e1906e7810bdc6ecb7bf598dcc3cd17d.
>> Practically, with the new behavior, doing mmap64 with an offset larger
>> than 1<<44 now fails with errno=EINVAL. The reasoning in this bug is
>> that offsets greater than 1<<44 are silently truncated, and so better
>> to fail early.
>>
>> However, I have several cases in embedded applications where such
>> mmap64 with large offset values is performed, and it worked correctly
>> (< 2.26). In these applications, a physical memory region is mapped
>> into the virtual address space, by performing an mmap64 on /dev/mem.
>> The offset is very large because this is accessing devices high up in
>> the memory range.
>
> Is the bug here that mmap64 is not used with a 64-bit argument? Should
> this system call have a long long argument?
IIUC n32 already uses long long for syscall arguments, and it uses the
mmap syscall with an unshifted offset.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."