Messages in this thread | | | From | Linus Torvalds <> | Date | Wed, 15 Jul 2020 14:31:54 -0700 | Subject | Re: [PATCHv2] mm: Fix warning in move_normal_pmd() |
| |
On Wed, Jul 15, 2020 at 1:54 PM Joel Fernandes <joel@joelfernandes.org> wrote: > > Regarding the ADDR_AFTER_NEXT checks, shouldn't you check for: > > if (ADDR_AFTER_NEXT(ALIGN(*old_addr + *len, PMD_SIZE), old)) > return;
No, there's even a comment to the effect.
Instead, that ADDR_AFTER_NEXT() aligns the next address _down_ to the PMD boundary.
Because otherwise, what can happen is:
- you're on an architecture that has a separate address space for users
- you're the next-to-last VMA in that address space,
- you're in the last PMD.
And now "ALIGN(*old_addr + *len, PMD_SIZE)" will wrap, and become 0, and you think it's ok to move the whole PMD, because it's now smaller than the start address of the next VMA.
It's _not_ ok, because you'd be moving that next-vma data too.
> and for the len calculation, I did not follow what you did, but I think you > meant something like this? Does the following reduce to what you did? At > least this is a bit more readable I think: > > *len += (ALIGN(*new_addr + *len, PMD_SIZE) - (*new_addr + *len));
Yes, right you are.
I actually wrote that first (except I added a helper variable for that "*new_addr + *len" thing), and then I decided it can be simplified.
And simplified it wrong ;)
> Also you did "len +=", it should be "*len +=" in this function.
That's indeed a plain stupid bug ;)
Naresh - don't test that version. The bugs Joel found just make the math wrong, so it won't work.
The concept was solid, the implementation not so much ;)
Linus
| |