On 2016/9/23 22:27, Michal Hocko wrote:

On Fri 23-09-16 22:14:40, zijun_hu wrote:

quoted

On 2016/9/23 21:33, Michal Hocko wrote:

quoted

On Fri 23-09-16 21:00:18, zijun_hu wrote:

quoted

On 09/23/2016 08:42 PM, Michal Hocko wrote:

quoted

quoted

quoted

quoted

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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>