From: Richard Weinberger <richard@nod.at>
To: Hugh Dickins <hughd@google.com>
Cc: Dave Jones <davej@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Sasha Levin <sasha.levin@oracle.com>,
LKML <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [3.15rc1] BUG at mm/filemap.c:202!
Date: Sun, 04 May 2014 22:58:01 +0200 [thread overview]
Message-ID: <5366A9D9.8000100@nod.at> (raw)
In-Reply-To: <alpine.LSU.2.11.1405041311130.3230@eggly.anvils>
Am 04.05.2014 22:37, schrieb Hugh Dickins:
> On Sat, 3 May 2014, Richard Weinberger wrote:
>> On Thu, May 1, 2014 at 6:20 PM, Richard Weinberger
>> <richard.weinberger@gmail.com> wrote:
>>> On Wed, Apr 16, 2014 at 10:40 PM, Hugh Dickins <hughd@google.com> wrote:
>>>>
>>>> Help!
>>>
>>> Using a trinity as of today I'm able to trigger this bug on UML within seconds.
>>> If you want me to test patch, I can help.
>>>
>>> I'm also observing one strange fact, I can trigger this on any kernel version.
>>> So far I've managed UML to crash on 3.0 to 3.15-rc...
>>
>> After digging deeper into UML's mmu and tlb code I've found issues and
>> fixed them.
>>
>> But I'm still facing this issue. Although triggering the BUG_ON() is
>> not so easy as before
>> I can trigger "BUG: Bad rss-counter ..." very easily.
>> Now the interesting fact, with my UML mmu and flb fixes applied it
>> happens only on kernels >= 3.14.
>> If it helps I can try to bisect it.
>
> Thanks a lot for trying, but from other mail it looks like your
> bisection got blown off course ;(
Yeah, looks like the issue I'm facing on UML is a completely different
story. Although the symptoms are identical. :-(
> I expect for the moment you'll want to concentrate on getting UML's
> TLB flushing back on track with 3.15-rc.
This is what I'm currently doing. But it might take some time
as I'm a mm novice.
> Once you have that sorted out, I wouldn't be surprised if the same
> changes turn out to fix your "Bad rss-counter"s on 3.14 also.
>
> If not, and if you do still have time to bisect back between 3.13 and
> 3.14 to find where things went wrong, it will be a bit tedious in that
> you would probably have to apply
>
> 887843961c4b "mm: fix bad rss-counter if remap_file_pages raced migration"
> 7e09e738afd2 "mm: fix swapops.h:131 bug if remap_file_pages raced migration"
>
> at each stage, to avoid those now-known bugs which trinity became rather
> good at triggering. Perhaps other fixes needed, those the two I remember.
>
> Please don't worry if you don't have time for this, that's understandable.
>
> Or is UML so contrary that one of those commits actually brings on the
> problem for you?
Hehe, no. I gave it a quick try, both 887843961c4b and 7e09e738afd2
seem to be unrelated to the issues I see.
Thanks,
//richard
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Richard Weinberger <richard@nod.at>
To: Hugh Dickins <hughd@google.com>
Cc: Dave Jones <davej@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Sasha Levin <sasha.levin@oracle.com>,
LKML <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [3.15rc1] BUG at mm/filemap.c:202!
Date: Sun, 04 May 2014 22:58:01 +0200 [thread overview]
Message-ID: <5366A9D9.8000100@nod.at> (raw)
In-Reply-To: <alpine.LSU.2.11.1405041311130.3230@eggly.anvils>
Am 04.05.2014 22:37, schrieb Hugh Dickins:
> On Sat, 3 May 2014, Richard Weinberger wrote:
>> On Thu, May 1, 2014 at 6:20 PM, Richard Weinberger
>> <richard.weinberger@gmail.com> wrote:
>>> On Wed, Apr 16, 2014 at 10:40 PM, Hugh Dickins <hughd@google.com> wrote:
>>>>
>>>> Help!
>>>
>>> Using a trinity as of today I'm able to trigger this bug on UML within seconds.
>>> If you want me to test patch, I can help.
>>>
>>> I'm also observing one strange fact, I can trigger this on any kernel version.
>>> So far I've managed UML to crash on 3.0 to 3.15-rc...
>>
>> After digging deeper into UML's mmu and tlb code I've found issues and
>> fixed them.
>>
>> But I'm still facing this issue. Although triggering the BUG_ON() is
>> not so easy as before
>> I can trigger "BUG: Bad rss-counter ..." very easily.
>> Now the interesting fact, with my UML mmu and flb fixes applied it
>> happens only on kernels >= 3.14.
>> If it helps I can try to bisect it.
>
> Thanks a lot for trying, but from other mail it looks like your
> bisection got blown off course ;(
Yeah, looks like the issue I'm facing on UML is a completely different
story. Although the symptoms are identical. :-(
> I expect for the moment you'll want to concentrate on getting UML's
> TLB flushing back on track with 3.15-rc.
This is what I'm currently doing. But it might take some time
as I'm a mm novice.
> Once you have that sorted out, I wouldn't be surprised if the same
> changes turn out to fix your "Bad rss-counter"s on 3.14 also.
>
> If not, and if you do still have time to bisect back between 3.13 and
> 3.14 to find where things went wrong, it will be a bit tedious in that
> you would probably have to apply
>
> 887843961c4b "mm: fix bad rss-counter if remap_file_pages raced migration"
> 7e09e738afd2 "mm: fix swapops.h:131 bug if remap_file_pages raced migration"
>
> at each stage, to avoid those now-known bugs which trinity became rather
> good at triggering. Perhaps other fixes needed, those the two I remember.
>
> Please don't worry if you don't have time for this, that's understandable.
>
> Or is UML so contrary that one of those commits actually brings on the
> problem for you?
Hehe, no. I gave it a quick try, both 887843961c4b and 7e09e738afd2
seem to be unrelated to the issues I see.
Thanks,
//richard
next prev parent reply other threads:[~2014-05-04 20:58 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-15 19:09 [3.15rc1] BUG at mm/filemap.c:202! Dave Jones
2014-04-15 19:09 ` Dave Jones
2014-04-16 20:40 ` Hugh Dickins
2014-04-16 20:40 ` Hugh Dickins
2014-05-01 16:20 ` Richard Weinberger
2014-05-01 16:20 ` Richard Weinberger
2014-05-03 19:24 ` Richard Weinberger
2014-05-03 19:24 ` Richard Weinberger
2014-05-04 20:37 ` Hugh Dickins
2014-05-04 20:37 ` Hugh Dickins
2014-05-04 20:58 ` Richard Weinberger [this message]
2014-05-04 20:58 ` Richard Weinberger
2014-05-04 21:46 ` 502304919
2014-05-03 23:37 ` [PATCH] mm: Fix force_flush behavior in zap_pte_range() Richard Weinberger
2014-05-03 23:37 ` Richard Weinberger
2014-05-03 23:57 ` Linus Torvalds
2014-05-03 23:57 ` Linus Torvalds
2014-05-04 8:34 ` Richard Weinberger
2014-05-04 8:34 ` Richard Weinberger
2014-05-04 18:31 ` Linus Torvalds
2014-05-04 18:31 ` Linus Torvalds
2014-05-04 20:42 ` Richard Weinberger
2014-05-04 20:42 ` Richard Weinberger
2014-05-04 21:19 ` Linus Torvalds
2014-05-04 21:19 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5366A9D9.8000100@nod.at \
--to=richard@nod.at \
--cc=akpm@linux-foundation.org \
--cc=davej@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=sasha.levin@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.