On 03/06/2018 08:19 PM, Mike Kravetz wrote:
> On 03/06/2018 04:31 PM, Mike Kravetz wrote:
>> On 03/06/2018 01:46 PM, Mike Kravetz wrote:
>>> On 03/06/2018 01:31 PM, Andrew Morton wrote:
>>>>
>>>> That's VM_BUG_ON(resv_map->adds_in_progress) in resv_map_release().
>>>>
>>>> Do you know if earlier kernel versions are affected?
>>>>
>>>> It looks quite bisectable. Does the crash happen every time the test
>>>> program is run?
>>>
>>> I'll take a look. There was a previous bug in this area:
>>> ff8c0c53: mm/hugetlb.c: don't call region_abort if region_chg fails
>>
>> This is similar to the issue addressed in 045c7a3f ("fix offset overflow
>> in hugetlbfs mmap"). The problem here is that the pgoff argument passed
>> to remap_file_pages() is 0x20000000000000. In the process of converting
>> this to a page offset and putting it in vm_pgoff, and then converting back
>> to bytes to compute mapping length we end up with 0. We ultimately end
>> up passing (from,to) page offsets into hugetlbfs where from is greater
>> than to. :( This confuses the heck out the the huge page reservation code
>> as the 'negative' range looks like an error and we never complete the
>> reservation process and leave the 'adds_in_progress'.
>>
>> This issue has existed for a long time. The VM_BUG_ON just happens to
>> catch the situation which was previously not reported or had some other
>> side effect. Commit 045c7a3f tried to catch these overflow issues when
>> converting types, but obviously missed this one. I can easily add a test
>> for this specific value/condition, but want to think about it a little
>> more and see if there is a better way to catch all of these.
>
> Well, I instrumented hugetlbfs_file_mmap when called via the remap_file_pages
> system call path. Upon entry, vma->vm_pgoff is 0x20000000000000 which is
> the same as the value of the argument pgoff passed to the system call.
> vm_pgoff really should be a page offset (i.e. 0x20000000000000 >> PAGE_SHIFT).
> So, there is also an issue earlier in the remap_file_pages system call
> sequence.
My mistake. The pgoff argument to remap_file_pages is a page offset in page
size units. So, there should be no '>> PAGE_SHIFT' of the argument.
The hugetlbfs code wants to convert vm_pgoff to a byte offset by
'<< PAGE_SHIFT'. This is what overflows and gets us into trouble.
My first thought is to simply check for this overflow in remap_file_pages.
Other code within the kernel converts vm_pgoff to a byte offset and I am
not sure they could handle/expect an overflow.
--
Mike Kravetz
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
