Re: [PATCH 1/1] lib/ioremap.c: avoid endless loop under ioremapping page unaligned ranges

[zijun_hu]

On 2016/9/23 21:33, Michal Hocko wrote:
> On Fri 23-09-16 21:00:18, zijun_hu wrote:
>> On 09/23/2016 08:42 PM, Michal Hocko wrote:
>>>>>> no, it don't work for many special case
>>>>>> for example, provided  PMD_SIZE=2M
>>>>>> mapping [0x1f8800, 0x208800) virtual range will be split to two ranges
>>>>>> [0x1f8800, 0x200000) and [0x200000,0x208800) and map them separately
>>>>>> the first range will cause dead loop
>>>>>
>>>>> I am not sure I see your point. How can we deadlock if _both_ addresses
>>>>> get aligned to the page boundary and how does PMD_SIZE make any
>>>>> difference.
>>>>>
>>>> i will take a example to illustrate my considerations
>>>> provided PUD_SIZE == 1G, PMD_SIZE == 2M, PAGE_SIZE == 4K
>>>> it is used by arm64 normally
>>>>
>>>> we want to map virtual range [0xffffffff_ffc08800, 0xffffffff_fffff800) by
>>>> ioremap_page_range(),ioremap_pmd_range() is called to map the range
>>>> finally, ioremap_pmd_range() will call
>>>> ioremap_pte_range(pmd, 0xffffffff_ffc08800, 0xffffffff_fffe0000) and
>>>> ioremap_pte_range(pmd, 0xffffffff_fffe0000, 0xffffffff fffff800) separately
>>>
>>> but those ranges are not aligned and it ioremap_page_range fix them up
>>> to _be_ aligned then there is no problem, right? So either I am missing
>>> something or we are talking past each other.
>>>
>> my complementary considerations are show below
>>
>> why not to round up the range start boundary to page aligned?
>> 1, it don't remain consistent with the original logic
>>    take map [0x1800, 0x4800) as example
>>    the original logic map range [0x1000, 0x2000), but rounding up start boundary
>>    don't mapping the range [0x1000, 0x2000)
> 
> just look at how we do that for the mmap...
okay
i don't familiar with mmap code very well now
it is okay to roundup start boundary to page aligned in order to keep consistent with Mmap code
if insane start boundary overflow is considered
> 
>> 2, the rounding up start boundary maybe cause overflow, consider start boundary =
>>    0xffffffff_fffff800  
> 
> this is just insane
>