On Thu, Nov 28, 2019 at 09:09:45PM +0000, Wei Yang wrote: > On Thu, Nov 28, 2019 at 11:31:43AM +0300, Kirill A. Shutemov wrote: > >On Thu, Nov 28, 2019 at 09:03:21AM +0800, Wei Yang wrote: > >> The check here is to guarantee pvmw->address iteration is limited in one > >> page table boundary. To be specific, here the address range should be in > >> one PMD_SIZE. > >> > >> If my understanding is correct, this check is already done in the above > >> check: > >> > >> address >= __vma_address(page, vma) + PMD_SIZE > >> > >> The boundary check here seems not necessary. > >> > >> Signed-off-by: Wei Yang <richardw.yang@xxxxxxxxxxxxxxx> > > > >NAK. > > > >THP can be mapped with PTE not aligned to PMD_SIZE. Consider mremap(). > > > > Hi, Kirill > > Thanks for your comment during Thanks Giving Day. Happy holiday:-) > > I didn't think about this case before, thanks for reminding. Then I tried to > understand your concern. > > mremap() would expand/shrink a memory mapping. In this case, probably shrink > is in concern. Since pvmw->page and pvmw->vma are not changed in the loop, the > case you mentioned maybe pvmw->page is the head of a THP but part of it is > unmapped. mremap() can also move a mapping, see MREMAP_FIXED. > This means the following condition stands: > > vma->vm_start <= vma_address(page) > vma->vm_end <= vma_address(page) + page_size(page) > > Since we have checked address with vm_end, do you think this case is also > guarded? > > Not sure my understanding is correct, look forward your comments. > > >> Test: > >> more than 48 hours kernel build test shows this code is not touched. > > > >Not an argument. I doubt mremap(2) is ever called in kernel build > >workload. > > > >-- > > Kirill A. Shutemov > > -- > Wei Yang > Help you, Help me >
