On Tue, Jul 14, 2020 at 11:12 AM Joel Fernandes wrote:
>
> I think you misunderstood me. I was not advocating breaking the stack
> movement code or breaking stack randomization, I was going to try to
> see if I could keep that working while not having to do an overlapping
> move.
I'm not really
On Tue, Jul 14, 2020 at 12:11 PM Linus Torvalds
wrote:
>
> On Tue, Jul 14, 2020 at 9:08 AM Joel Fernandes wrote:
> >
> > I was thinking we should not call move_page_tables() with overlapping ranges
> > at all, just to keep things simple.
>
> No, we're not breaking the existing stack movement
On Tue, Jul 14, 2020 at 9:08 AM Joel Fernandes wrote:
>
> I was thinking we should not call move_page_tables() with overlapping ranges
> at all, just to keep things simple.
No, we're not breaking the existing stack movement code just to keep
things simple.
The rule is "make it as simple as
Hi Kirill,
On Tue, Jul 14, 2020 at 10:33:06AM +0300, Kirill A. Shutemov wrote:
> On Sun, Jul 12, 2020 at 03:58:06PM -0700, Linus Torvalds wrote:
> > Anybody else have any opinions?
>
> Maybe we just shouldn't allow move_normal_pmd() if ranges overlap?
>
> Other option: pass 'overlaps' down to
On Tue, 14 Jul 2020 at 13:03, Kirill A. Shutemov wrote:
>
> On Sun, Jul 12, 2020 at 03:58:06PM -0700, Linus Torvalds wrote:
> > Anybody else have any opinions?
>
> Maybe we just shouldn't allow move_normal_pmd() if ranges overlap?
>
> Other option: pass 'overlaps' down to move_normal_pmd() and
On Sun, Jul 12, 2020 at 03:58:06PM -0700, Linus Torvalds wrote:
> Anybody else have any opinions?
Maybe we just shouldn't allow move_normal_pmd() if ranges overlap?
Other option: pass 'overlaps' down to move_normal_pmd() and only WARN() if
see establised PMD without overlaps being true.
On Sun, Jul 12, 2020 at 08:51:26PM -0700, Linus Torvalds wrote:
> > > Maybe saying "doing the pmd copies for the initial stack isn't
> > > important, so let's just note this as a special case and get rid of
> > > the WARN_ON()" might be an alternative solution.
> >
> > Personally, I feel it is
On Sun, Jul 12, 2020 at 7:53 PM Joel Fernandes wrote:
>
> > But I do feel like you figured out why the bug happened, now we're
> > just discussing whether the patch is the right thing to do.
>
> Yes.
>
> > Maybe saying "doing the pmd copies for the initial stack isn't
> > important, so let's just
Hi Linus,
On Sun, Jul 12, 2020 at 03:58:06PM -0700, Linus Torvalds wrote:
> On Sun, Jul 12, 2020 at 2:50 PM Joel Fernandes wrote:
> >
> > I reproduced Naresh's issue on a 32-bit x86 machine and the below patch
> > fixes it.
> > The issue is solely within execve() itself and the way it
On Sun, Jul 12, 2020 at 2:50 PM Joel Fernandes wrote:
>
> I reproduced Naresh's issue on a 32-bit x86 machine and the below patch fixes
> it.
> The issue is solely within execve() itself and the way it allocates/copies the
> temporary stack.
>
> It is actually indeed an overlapping case because
On Thu, Jul 09, 2020 at 10:22:21PM -0700, Linus Torvalds wrote:
> On Thu, Jul 9, 2020 at 9:29 PM Naresh Kamboju
> wrote:
> >
> > Your patch applied and re-tested.
> > warning triggered 10 times.
> >
> > old: bfe0-c000 new: bfa0 (val: 7d530067)
>
> Hmm.. It's not even the overlapping
On Sun, Jul 12, 2020 at 10:31 AM Matthew Wilcox wrote:
>
> But I don't see any other way to do it. It's not like I can put THPs
> in the page cache before fixing the things that won't work.
I agree that sometimes there are bootstrapping issues. Incremental and
explanatory commits are still
On Sat, Jul 11, 2020 at 11:12:58AM -0700, Linus Torvalds wrote:
> Yeah, that's just the commit that enables the code, not the commit
> that introduces the fundamental problem.
>
> That said, this is a prime example of why I absolutely detest patch
> series that do this kind of thing, and are
On Sat, Jul 11, 2020 at 11:12:58AM -0700, Linus Torvalds wrote:
> On Sat, Jul 11, 2020 at 10:27 AM Naresh Kamboju
> wrote:
> >
> > I have started bisecting this problem and found the first bad commit
>
> Thanks for the effort. Bisection is often a great tool to figure out
> what's wrong.
>
>
On Sat, Jul 11, 2020 at 11:12 AM Linus Torvalds
wrote:
>
> The fact that it seems to happen with
>
>
> https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/mem/thp/thp01.c
>
> makes me think it's somehow related to THP mappings, but I don't see
> why those would matter. All
On Sat, Jul 11, 2020 at 10:27 AM Naresh Kamboju
wrote:
>
> I have started bisecting this problem and found the first bad commit
Thanks for the effort. Bisection is often a great tool to figure out
what's wrong.
Sadly, in this case:
> commit 9f132f7e145506efc0744426cb338b18a54afc3b
> Author:
On Sat, 11 Jul 2020 at 01:35, Linus Torvalds
wrote:
>
> On Fri, Jul 10, 2020 at 10:48 AM Naresh Kamboju
> wrote:
I have started bisecting this problem and found the first bad commit
commit 9f132f7e145506efc0744426cb338b18a54afc3b
Author: Joel Fernandes (Google)
Date: Thu Jan 3 15:28:41 2019
On Fri, Jul 10, 2020 at 10:48 AM Naresh Kamboju
wrote:
>
> I have applied your patch and test started in a loop for a million times
> but the test ran for 35 times. Seems like the test got a timeout after 1 hour.
That just means that my test-case was wrong (in the sense that what it
was testing
On Fri, 10 Jul 2020 at 10:55, Linus Torvalds
wrote:
>
> On Thu, Jul 9, 2020 at 9:29 PM Naresh Kamboju
> wrote:
> >
> > Your patch applied and re-tested.
> > warning triggered 10 times.
> >
> > old: bfe0-c000 new: bfa0 (val: 7d530067)
>
> Hmm.. It's not even the overlapping case,
On Thu, Jul 9, 2020 at 9:29 PM Naresh Kamboju wrote:
>
> Your patch applied and re-tested.
> warning triggered 10 times.
>
> old: bfe0-c000 new: bfa0 (val: 7d530067)
Hmm.. It's not even the overlapping case, it's literally just "move
exactly 2MB of page tables exactly one pmd down".
On Fri, 10 Jul 2020 at 00:42, Linus Torvalds
wrote:
>
> On Wed, Jul 8, 2020 at 10:28 PM Naresh Kamboju
> wrote:
> >
> > While running LTP mm test suite on i386 or qemu_i386 this kernel warning
> > has been noticed from stable 5.4 to stable 5.7 branches and mainline
> > 5.8.0-rc4
> > and linux
On Thu, 9 Jul 2020 at 13:55, Arnd Bergmann wrote:
>
> On Thu, Jul 9, 2020 at 7:28 AM Naresh Kamboju
> wrote:
> >
> > While running LTP mm test suite on i386 or qemu_i386 this kernel warning
> > has been noticed from stable 5.4 to stable 5.7 branches and mainline
> > 5.8.0-rc4
> > and linux
On Wed, Jul 8, 2020 at 10:28 PM Naresh Kamboju
wrote:
>
> While running LTP mm test suite on i386 or qemu_i386 this kernel warning
> has been noticed from stable 5.4 to stable 5.7 branches and mainline 5.8.0-rc4
> and linux next.
Hmm
If this is repeatable, would you mind making the warning also
On Thu, Jul 9, 2020 at 7:28 AM Naresh Kamboju wrote:
>
> While running LTP mm test suite on i386 or qemu_i386 this kernel warning
> has been noticed from stable 5.4 to stable 5.7 branches and mainline 5.8.0-rc4
> and linux next.
Are you able to correlate this with any particular test case in
While running LTP mm test suite on i386 or qemu_i386 this kernel warning
has been noticed from stable 5.4 to stable 5.7 branches and mainline 5.8.0-rc4
and linux next.
metadata:
git branch: master
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git commit:
25 matches
Mail list logo
