On Thu, Jul 16, 2020 at 1:55 PM Linus Torvalds
wrote:
>
> On Thu, Jul 16, 2020 at 6:16 AM Kirill A. Shutemov
> wrote:
> >
> > It can also lead to performance regression: for small mremap() if only one
> > side of the range got aligned and there's no PMD_SIZE range to move,
> > kernel will still
On Thu, Jul 16, 2020 at 6:16 AM Kirill A. Shutemov wrote:
>
> It can also lead to performance regression: for small mremap() if only one
> side of the range got aligned and there's no PMD_SIZE range to move,
> kernel will still iterate over PTEs, but it would need to handle more
> pte_none()s than
On Wed, Jul 15, 2020 at 04:18:44PM -0700, Linus Torvalds wrote:
> On Wed, Jul 15, 2020 at 4:04 PM Linus Torvalds
> wrote:
> >
> > It *might* be as simple as this incremental thing on top
>
> No, it needs to be
>
> + if (*old_addr + *len < old->vm_end)
> + return;
>
> in try_
On Thu, Jul 16, 2020 at 12:53:23PM +0530, Naresh Kamboju wrote:
> On Thu, 16 Jul 2020 at 12:07, Naresh Kamboju
> wrote:
> >
> > On Thu, 16 Jul 2020 at 04:49, Linus Torvalds
> > wrote:
> > >
> > > On Wed, Jul 15, 2020 at 4:04 PM Linus Torvalds
> > > wrote:
> > > >
> > > > It *might* be as simple
On Thu, 16 Jul 2020 at 04:49, Linus Torvalds
wrote:
>
> On Wed, Jul 15, 2020 at 4:04 PM Linus Torvalds
> wrote:
> >
> > It *might* be as simple as this incremental thing on top
>
> No, it needs to be
>
> + if (*old_addr + *len < old->vm_end)
> + return;
>
> in try_to_align_end
On Thu, 16 Jul 2020 at 12:07, Naresh Kamboju wrote:
>
> On Thu, 16 Jul 2020 at 04:49, Linus Torvalds
> wrote:
> >
> > On Wed, Jul 15, 2020 at 4:04 PM Linus Torvalds
> > wrote:
> > >
> > > It *might* be as simple as this incremental thing on top
> >
> > No, it needs to be
> >
> > + if (*old
On Thu, 16 Jul 2020 at 04:49, Linus Torvalds
wrote:
>
> On Wed, Jul 15, 2020 at 4:04 PM Linus Torvalds
> wrote:
> >
> > It *might* be as simple as this incremental thing on top
>
> No, it needs to be
>
> + if (*old_addr + *len < old->vm_end)
> + return;
>
> in try_to_align_end
On Wed, Jul 15, 2020 at 4:04 PM Linus Torvalds
wrote:
>
> It *might* be as simple as this incremental thing on top
No, it needs to be
+ if (*old_addr + *len < old->vm_end)
+ return;
in try_to_align_end(), of course.
Now I'm going for a lie-down, because this cross-eyed thin
On Wed, Jul 15, 2020 at 3:57 PM Linus Torvalds
wrote:
>
> But now I've screwed it up twice, and have a splitting headache, so
> rather than stare at this cross-eyed, I'll take a break and hope that
> somebody more competent than me looks at the code.
I lied. I had a couple of pending pulls, so I
On Wed, Jul 15, 2020 at 3:22 PM Kirill A. Shutemov wrote:
>
> Sorry, but the patch is broken.
.. instead of taking up knitting - which I'd invariably also screw up
- I took a look.
Yeah, in addition to checking the vm_prev/vm_next vma's, we need to
check the limits of the 'vma' itself. Because w
On Wed, Jul 15, 2020 at 3:22 PM Kirill A. Shutemov wrote:
>
> Sorry, but the patch is broken.
I should take up some other hobby. Maybe knitting.
But then I'd probably end up with sweaters with three arms, and
there's a very limited market for that.
Oh well.
Linus
On Wed, Jul 15, 2020 at 02:43:00PM -0700, Linus Torvalds wrote:
> On Wed, Jul 15, 2020 at 2:31 PM Linus Torvalds
> wrote:
> >
> > Naresh - don't test that version. The bugs Joel found just make the
> > math wrong, so it won't work.
>
> Here's a new version with the thing that Joel and Kirill both
On Wed, Jul 15, 2020 at 2:35 PM Linus Torvalds
wrote:
>
> The stack relocation only moves down.
.. and that may not be true on a grow-up stack. Christ, that code is
hard to read. But I think Kirill is right, and I'm wrong.
So that "try to expand" code is only ok when non-overlapping, or when
mov
On Wed, Jul 15, 2020 at 2:31 PM Linus Torvalds
wrote:
>
> Naresh - don't test that version. The bugs Joel found just make the
> math wrong, so it won't work.
Here's a new version with the thing that Joel and Kirill both noticed
hopefully fixed.
But I probably screwed it up again. I guess I shoul
On Wed, Jul 15, 2020 at 1:55 PM Kirill A. Shutemov 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 bot
On Wed, Jul 15, 2020 at 1:54 PM Joel Fernandes 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() al
On Wed, Jul 15, 2020 at 04:54:28PM -0400, Joel Fernandes wrote:
> Hi Linus,
>
> On Wed, Jul 15, 2020 at 11:36:59AM -0700, Linus Torvalds wrote:
> Regarding the ADDR_AFTER_NEXT checks, shouldn't you check for:
>
> if (ADDR_AFTER_NEXT(ALIGN(*old_addr + *len, PMD_SIZE), old))
> r
On Wed, Jul 15, 2020 at 11:36:59AM -0700, Linus Torvalds wrote:
> On Wed, Jul 15, 2020 at 6:50 AM Kirill A. Shutemov
> wrote:
> >
> > mremap(2) does not allow source and destination regions to overlap, but
> > shift_arg_pages() calls move_page_tables() directly and in this case the
> > source and
Hi Linus,
On Wed, Jul 15, 2020 at 11:36:59AM -0700, Linus Torvalds wrote:
> On Wed, Jul 15, 2020 at 6:50 AM Kirill A. Shutemov
> wrote:
> >
> > mremap(2) does not allow source and destination regions to overlap, but
> > shift_arg_pages() calls move_page_tables() directly and in this case the
> >
On Wed, Jul 15, 2020 at 6:50 AM Kirill A. Shutemov
wrote:
>
> mremap(2) does not allow source and destination regions to overlap, but
> shift_arg_pages() calls move_page_tables() directly and in this case the
> source and destination overlap often. It
Actually, before we do this patch (which I th
mremap(2) does not allow source and destination regions to overlap, but
shift_arg_pages() calls move_page_tables() directly and in this case the
source and destination overlap often. It confuses move_normal_pmd():
WARNING: CPU: 3 PID: 27091 at mm/mremap.c:211 move_page_tables+0x6ef/0x720
move_n
21 matches
Mail list logo
