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 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.

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]