This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: mmap64 with very large offset broken since glibc 2.26 (MIPS64 n32)


El jue., 13 jun. 2019 a las 13:58, Florian Weimer
(<fweimer@redhat.com>) escribió:
>
> * 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?

Are you referring to the fact that in this code:

    off_t physical_base = 0x100001a000000ull;
    ...
    virtual_base = (volatile uint32_t*) mmap64(0, length,
PROT_READ|PROT_WRITE, MAP_SHARED, fd, physical_base);

physical_base is an off_t which is supposedly 32-bit?
In fact, the original code used 'unsigned long long', and I can
reproduce the problem equally well with that.
Note also that when introducing the off_t in the test, I added
large-file defines, so off_t is effectively a 64-bit type.


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.

/Thomas


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]