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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 23 Sep 2016 22:58:03 +0800
From:   zijun_hu <zijun_hu@...o.com>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     zijun_hu@....com, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>, tj@...nel.org,
        mingo@...nel.org, rientjes@...gle.com, iamjoonsoo.kim@....com,
        mgorman@...hsingularity.net
Subject: Re: [PATCH 1/1] lib/ioremap.c: avoid endless loop under ioremapping
 page unaligned ranges

On 2016/9/23 22:27, Michal Hocko wrote:
> On Fri 23-09-16 22:14:40, zijun_hu wrote:
>> 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
> 
> mmap basically does addr &= PAGE_MASK (modulo mmap_min_addr) and
> len = PAGE_ALIGN(len).
> 
> this is [star, end) raher than [start, start+len) but you should get the
> point I guess.
> 
you are right
this patch is consistent with that you pointed

for map virtual range [0x80000800, 0x80007800) to physical area[0x20000800, 0x20007800)
it actually map range [0x80000000, 0x80008000) to physical area[0x20000000, 0x20008000)

maybe expanding range [0x80000800, 0x80007800) to [0x80000000, 0x80008000) is better than
shrinking to [0x80001000, 0x80007000) because the following reasons

1. if a user is mapping [0x80000800, 0x80007800) -> [0x20000800, 0x20007800), he/she expect to
access physical address 0x20000800 by virtual address 0x80000800, expanding range do the right
thing but shrinking will cause address fault

2. shrinking will cause not enough virtual range [0x80001000, 0x80007000) to mapping physical
area [0x20000800, 0x20007800)

3. this is no need to round up parameter end to page boundary to expand the end limit, it has less
modification for code

BTW
there are many page table operations to using this similar logic, maybe a universal fixing is used
to all, not just lib/ioremap.c or mm/vmalloc.c