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)


On Mon, Jun 17, 2019 at 1:57 PM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> On 17/06/2019 13:19, Adhemerval Zanella wrote:
> >
> >
> > On 17/06/2019 11:59, Florian Weimer wrote:
> >> * Thomas De Schampheleire:
> >>
> >>> El jue., 13 jun. 2019 a las 18:49, Joseph Myers
> >>> (<joseph@codesourcery.com>) escribió:
> >>>>
> >>>> On Thu, 13 Jun 2019, Andreas Schwab wrote:
> >>>>
> >>>>> IIUC n32 already uses long long for syscall arguments, and it uses the
> >>>>> mmap syscall with an unshifted offset.
> >>>>
> >>>> Yes, the n32 syscall ABI generally matches the function calling ABI, with
> >>>> 64-bit arguments in a single register.  See the commit message for commit
> >>>> 5163b4b76f61e361f0f4bbe3b96732b12e5c9b1a for more discussion of the mmap
> >>>> interfaces for MIPS.
> >>>
> >>> Should I open a bugzilla bug to track this further, or do you prefer
> >>> to continue in this mail thread?
> >>
> >> Both. 8-) Since this is a user-visible bug, we need to track this
> >> Bugzilla.  But we can discuss the right solution here.
> >>
> >> Would you be able to test a patch if one of us blindly writes one?
> >
> > I think we just need to move the test of 'if (offset & MMAP_OFF_MASK)'
> > to inside the patch when building for mmap2 (so it is not used for
> > mmap).
> >
>
> Ok, it seems that only mips64n32 is the affected ABI for this issue,
> since it is the only one that does not define mmap2 and has sizeof
> (off_t) different than sizeof (off64_t) (x32 at least has sizeof (off_t)
> equal to sizeof (off64_t)).  And the straightforward check is just to
> check MMAP_OFF_HIGH_MASK for mmap2 only.
>
> For the patch itself, the only issue is I can't really create a
> workable test without relying on something arch-specific.  The
> /dev/mem is tricky, it requires root access and it no portable
> (not all architectures support that range of VMA).  Same for a sparse
> file of such size to trigger the issue, most FS don't support files
> that large.

Couldn't you use mmap on /dev/zero with the large offset for the testcase?

Thanks,
Andrew



>
> As a side note, I am not sure if the MMAP_OFF_LOW_MASK is really
> useful here: afaik for old __NR_mmap Linux will explicit check if
> offset is multiple of page size, while for mmap2 architecture will
> either check or just shift by PAGE_SHIFT.


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