Message ID | 20210201093259.52798-1-linmiaohe@huawei.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | mm/huge_memory.c: use helper range_in_vma() in __split_huge_p[u|m]d_locked() | expand |
On 01.02.21 10:32, Miaohe Lin wrote: > The helper range_in_vma() is introduced via commit 017b1660df89 ("mm: > migration: fix migration of huge PMD shared pages"). But we forgot to > use it in __split_huge_pud_locked() and __split_huge_pmd_locked(). > > Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> > --- > mm/huge_memory.c | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index 987cf5e4cf90..33353a4f95fb 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -1959,8 +1959,7 @@ static void __split_huge_pud_locked(struct vm_area_struct *vma, pud_t *pud, > unsigned long haddr) > { > VM_BUG_ON(haddr & ~HPAGE_PUD_MASK); > - VM_BUG_ON_VMA(vma->vm_start > haddr, vma); > - VM_BUG_ON_VMA(vma->vm_end < haddr + HPAGE_PUD_SIZE, vma); > + VM_BUG_ON_VMA(!range_in_vma(vma, haddr, haddr + HPAGE_PUD_SIZE), vma); > VM_BUG_ON(!pud_trans_huge(*pud) && !pud_devmap(*pud)); > > count_vm_event(THP_SPLIT_PUD); > @@ -2039,8 +2038,7 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd, > int i; > > VM_BUG_ON(haddr & ~HPAGE_PMD_MASK); > - VM_BUG_ON_VMA(vma->vm_start > haddr, vma); > - VM_BUG_ON_VMA(vma->vm_end < haddr + HPAGE_PMD_SIZE, vma); > + VM_BUG_ON_VMA(!range_in_vma(vma, haddr, haddr + HPAGE_PMD_SIZE), vma); > VM_BUG_ON(!is_pmd_migration_entry(*pmd) && !pmd_trans_huge(*pmd) > && !pmd_devmap(*pmd)); > > Reviewed-by: David Hildenbrand <david@redhat.com>
On Mon, 1 Feb 2021, Miaohe Lin wrote: > The helper range_in_vma() is introduced via commit 017b1660df89 ("mm: > migration: fix migration of huge PMD shared pages"). But we forgot to > use it in __split_huge_pud_locked() and __split_huge_pmd_locked(). > > Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> > --- > mm/huge_memory.c | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index 987cf5e4cf90..33353a4f95fb 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -1959,8 +1959,7 @@ static void __split_huge_pud_locked(struct vm_area_struct *vma, pud_t *pud, > unsigned long haddr) > { > VM_BUG_ON(haddr & ~HPAGE_PUD_MASK); > - VM_BUG_ON_VMA(vma->vm_start > haddr, vma); > - VM_BUG_ON_VMA(vma->vm_end < haddr + HPAGE_PUD_SIZE, vma); > + VM_BUG_ON_VMA(!range_in_vma(vma, haddr, haddr + HPAGE_PUD_SIZE), vma); > VM_BUG_ON(!pud_trans_huge(*pud) && !pud_devmap(*pud)); > > count_vm_event(THP_SPLIT_PUD); > @@ -2039,8 +2038,7 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd, > int i; > > VM_BUG_ON(haddr & ~HPAGE_PMD_MASK); > - VM_BUG_ON_VMA(vma->vm_start > haddr, vma); > - VM_BUG_ON_VMA(vma->vm_end < haddr + HPAGE_PMD_SIZE, vma); > + VM_BUG_ON_VMA(!range_in_vma(vma, haddr, haddr + HPAGE_PMD_SIZE), vma); > VM_BUG_ON(!is_pmd_migration_entry(*pmd) && !pmd_trans_huge(*pmd) > && !pmd_devmap(*pmd)); > This actually loses information, right? Before the patch, we can determine which conditional is failing because we know the line number that the VM_BUG_ON() is happening on. After the patch, we don't know this. I don't think that's crucial, but I'm not sure it makes sense to do this if the only upside is that we removed one total line of code :)
On 2021/2/2 5:27, David Rientjes wrote: > On Mon, 1 Feb 2021, Miaohe Lin wrote: > >> The helper range_in_vma() is introduced via commit 017b1660df89 ("mm: >> migration: fix migration of huge PMD shared pages"). But we forgot to >> use it in __split_huge_pud_locked() and __split_huge_pmd_locked(). >> >> Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> >> --- >> mm/huge_memory.c | 6 ++---- >> 1 file changed, 2 insertions(+), 4 deletions(-) >> >> diff --git a/mm/huge_memory.c b/mm/huge_memory.c >> index 987cf5e4cf90..33353a4f95fb 100644 >> --- a/mm/huge_memory.c >> +++ b/mm/huge_memory.c >> @@ -1959,8 +1959,7 @@ static void __split_huge_pud_locked(struct vm_area_struct *vma, pud_t *pud, >> unsigned long haddr) >> { >> VM_BUG_ON(haddr & ~HPAGE_PUD_MASK); >> - VM_BUG_ON_VMA(vma->vm_start > haddr, vma); >> - VM_BUG_ON_VMA(vma->vm_end < haddr + HPAGE_PUD_SIZE, vma); >> + VM_BUG_ON_VMA(!range_in_vma(vma, haddr, haddr + HPAGE_PUD_SIZE), vma); >> VM_BUG_ON(!pud_trans_huge(*pud) && !pud_devmap(*pud)); >> >> count_vm_event(THP_SPLIT_PUD); >> @@ -2039,8 +2038,7 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd, >> int i; >> >> VM_BUG_ON(haddr & ~HPAGE_PMD_MASK); >> - VM_BUG_ON_VMA(vma->vm_start > haddr, vma); >> - VM_BUG_ON_VMA(vma->vm_end < haddr + HPAGE_PMD_SIZE, vma); >> + VM_BUG_ON_VMA(!range_in_vma(vma, haddr, haddr + HPAGE_PMD_SIZE), vma); >> VM_BUG_ON(!is_pmd_migration_entry(*pmd) && !pmd_trans_huge(*pmd) >> && !pmd_devmap(*pmd)); >> > > This actually loses information, right? Before the patch, we can > determine which conditional is failing because we know the line number > that the VM_BUG_ON() is happening on. After the patch, we don't know > this. > You are right. We can determine which conditional is failing only through line number via VM_BUG_ON_VMA. So this will loses the information. My careless. :( Many thanks for kindly explanation. > I don't think that's crucial, but I'm not sure it makes sense to do this > if the only upside is that we removed one total line of code :) > . >
diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 987cf5e4cf90..33353a4f95fb 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1959,8 +1959,7 @@ static void __split_huge_pud_locked(struct vm_area_struct *vma, pud_t *pud, unsigned long haddr) { VM_BUG_ON(haddr & ~HPAGE_PUD_MASK); - VM_BUG_ON_VMA(vma->vm_start > haddr, vma); - VM_BUG_ON_VMA(vma->vm_end < haddr + HPAGE_PUD_SIZE, vma); + VM_BUG_ON_VMA(!range_in_vma(vma, haddr, haddr + HPAGE_PUD_SIZE), vma); VM_BUG_ON(!pud_trans_huge(*pud) && !pud_devmap(*pud)); count_vm_event(THP_SPLIT_PUD); @@ -2039,8 +2038,7 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd, int i; VM_BUG_ON(haddr & ~HPAGE_PMD_MASK); - VM_BUG_ON_VMA(vma->vm_start > haddr, vma); - VM_BUG_ON_VMA(vma->vm_end < haddr + HPAGE_PMD_SIZE, vma); + VM_BUG_ON_VMA(!range_in_vma(vma, haddr, haddr + HPAGE_PMD_SIZE), vma); VM_BUG_ON(!is_pmd_migration_entry(*pmd) && !pmd_trans_huge(*pmd) && !pmd_devmap(*pmd));
The helper range_in_vma() is introduced via commit 017b1660df89 ("mm: migration: fix migration of huge PMD shared pages"). But we forgot to use it in __split_huge_pud_locked() and __split_huge_pmd_locked(). Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> --- mm/huge_memory.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)