| Message ID | 20220314153223.53753-1-linmiaohe@huawei.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | mm/mlock: remove unneeded start >= vma->vm_end check | expand |
On Mon, Mar 14, 2022 at 11:32:23PM +0800, Miaohe Lin wrote: > If find_vma returns a vma, it must satisfies that start < vma->vm_end. > Since vma list is sorted in the ascending order, so we will never see > start >= vma->vm_end here. Remove this unneeded check. faulty logic; vm_start + len might wrap.
On 2022/3/15 0:17, Matthew Wilcox wrote: > On Mon, Mar 14, 2022 at 11:32:23PM +0800, Miaohe Lin wrote: >> If find_vma returns a vma, it must satisfies that start < vma->vm_end. >> Since vma list is sorted in the ascending order, so we will never see >> start >= vma->vm_end here. Remove this unneeded check. > > faulty logic; vm_start + len might wrap. Many thanks for comment. I agree with you about "vm_start + len" might wrap. But what I mean here is that we will never see "start" >= vma->vm_end here as find_vma guarantees this. And I leave the "start + len <= vma->vm_start" check untouched. So my cleanup should be right. Or am I miss something? Thanks. > > . >
On 2022/3/15 20:30, Miaohe Lin wrote: > On 2022/3/15 0:17, Matthew Wilcox wrote: >> On Mon, Mar 14, 2022 at 11:32:23PM +0800, Miaohe Lin wrote: >>> If find_vma returns a vma, it must satisfies that start < vma->vm_end. >>> Since vma list is sorted in the ascending order, so we will never see >>> start >= vma->vm_end here. Remove this unneeded check. >> >> faulty logic; vm_start + len might wrap. > > Many thanks for comment. I agree with you about "vm_start + len" might wrap. > But what I mean here is that we will never see "start" >= vma->vm_end here > as find_vma guarantees this. And I leave the "start + len <= vma->vm_start" > check untouched. So my cleanup should be right. Or am I miss something? > friendly ping. :) > Thanks. > >> >> . >> >
On 2022/3/15 20:30, Miaohe Lin wrote: > On 2022/3/15 0:17, Matthew Wilcox wrote: >> On Mon, Mar 14, 2022 at 11:32:23PM +0800, Miaohe Lin wrote: >>> If find_vma returns a vma, it must satisfies that start < vma->vm_end. >>> Since vma list is sorted in the ascending order, so we will never see >>> start >= vma->vm_end here. Remove this unneeded check. >> >> faulty logic; vm_start + len might wrap. What do you mean is vm_start + len might wrap, so vm_end might be < vm_start ? If so, this could not happen as get_unmapped_area guarantees this. > > Many thanks for comment. I agree with you about "vm_start + len" might wrap. > But what I mean here is that we will never see "start" >= vma->vm_end here > as find_vma guarantees this. And I leave the "start + len <= vma->vm_start" > check untouched. So my cleanup should be right. Or am I miss something? So I think this "start >= vma->vm_end" check is unneeded and we can remove it. Or am I miss something? Many thanks! > > Thanks. > >> >> . >> >
diff --git a/mm/mlock.c b/mm/mlock.c index fefa9644d0f9..fe278634ebe3 100644 --- a/mm/mlock.c +++ b/mm/mlock.c @@ -509,8 +509,6 @@ static unsigned long count_mm_mlocked_page_nr(struct mm_struct *mm, return 0; for (; vma ; vma = vma->vm_next) { - if (start >= vma->vm_end) - continue; if (start + len <= vma->vm_start) break; if (vma->vm_flags & VM_LOCKED) {
If find_vma returns a vma, it must satisfies that start < vma->vm_end. Since vma list is sorted in the ascending order, so we will never see start >= vma->vm_end here. Remove this unneeded check. Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> --- mm/mlock.c | 2 -- 1 file changed, 2 deletions(-)