On Wed, Jul 15, 2020 at 1:55 PM Kirill A. Shutemov <[email protected]> wrote:
>
> I don't understand 'len' calculation in try_to_align_end().
Yeah, Joel found the same thing. You don't understand it, because it's garbage.
> BUT
>
> I *think* there's a bigger problem with the patch:
>
> For stack relocation case both VMAs are the same and always(?) the only
> VMA around at the time. It means none of ADDR_BEFORE_PREV and
> ADDR_AFTER_NEXT are going to stop us.
But for the stack relocation case, that should actually be fine. We
are moving the whole thing.
Or maybe I missed something.
> Consider the following case, before and after try_to_align_start():
>
> before after
> old_addr: 0x0123000 0x0000000
> new_addr: 0x1123000 0x1000000
> len: 0x1000000 0x1123000
That's the "move up" case that fundamentally doesn't work anyway
because it will corrupt the data as it moves it.
The stack relocation only moves down.
Linus
