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