From: Mel Gorman <mgorman@suse.de>
To: Jovi Zhangwei <jovi@cloudflare.com>
Cc: linux-kernel@vger.kernel.org, sasha.levin@oracle.com,
n-horiguchi@ah.jp.nec.com, akpm@linux-foundation.org,
Hugh Dickins <hughd@google.com>,
linux-mm@kvack.org, vbabka@suse.cz, rientjes@google.com
Subject: Re: kernel bug(VM_BUG_ON_PAGE) with 3.18.13 in mm/migrate.c
Date: Tue, 2 Jun 2015 08:19:41 +0100 [thread overview]
Message-ID: <20150602071941.GB26425@suse.de> (raw)
In-Reply-To: <CABPcSq+5SR0vqs6fGOwKJ0AZMiLSDQ6Rsevi2wB4YgZPJ9iadg@mail.gmail.com>
On Thu, May 28, 2015 at 11:38:36AM -0700, Jovi Zhangwei wrote:
> Hi Mel,
>
> On Thu, May 28, 2015 at 5:00 AM, Mel Gorman <mgorman@suse.de> wrote:
> > On Wed, May 27, 2015 at 11:05:33AM -0700, Jovi Zhangwei wrote:
> >> Hi,
> >>
> >> I got below kernel bug error in our 3.18.13 stable kernel.
> >> "kernel BUG at mm/migrate.c:1661!"
> >>
> >> Source code:
> >>
> >> 1657 static int numamigrate_isolate_page(pg_data_t *pgdat, struct page *page)
> >> 1658 {
> >> 1659 int page_lru;
> >> 1660
> >> 1661 VM_BUG_ON_PAGE(compound_order(page) &&
> >> !PageTransHuge(page), page);
> >>
> >> It's easy to trigger the error by run tcpdump in our system.(not sure
> >> it will easily be reproduced in another system)
> >> "sudo tcpdump -i bond0.100 'tcp port 4242' -c 100000000000 -w 4242.pcap"
> >>
> >> Any comments for this bug would be great appreciated. thanks.
> >>
> >
> > What sort of compound page is it? What sort of VMA is it in? hugetlbfs
> > pages should never be tagged for NUMA migrate and never enter this
> > path. Transparent huge pages are handled properly so I'm wondering
> > exactly what type of compound page this is and what mapped it into
> > userspace.
> >
> Thanks for your reply.
>
> After reading net/packet/af_packet.c:alloc_one_pg_vec_page, I found
> there indeed have compound page maped into userspace.
>
Ok, it's clear now. Thanks very much.
> I sent a patch for this issue(you may received it), but not sure it's
> right to fix,
> feel free to update it or use your own patch.
>
It avoids the problem but it's not the best fix because a lot of useless
overhead has been incurred for a page that can never be migrated. Can you
try the following instead please?
---8<---
sched, numa: Do not hint for NUMA balancing on VM_MIXEDMAP mappings
Jovi Zhangwei reported the following problem
Below kernel vm bug can be triggered by tcpdump which mmaped a lot of pages
with GFP_COMP flag.
[Mon May 25 05:29:33 2015] page:ffffea0015414000 count:66 mapcount:1 mapping: (null) index:0x0
[Mon May 25 05:29:33 2015] flags: 0x20047580004000(head)
[Mon May 25 05:29:33 2015] page dumped because: VM_BUG_ON_PAGE(compound_order(page) && !PageTransHuge(page))
[Mon May 25 05:29:33 2015] ------------[ cut here ]------------
[Mon May 25 05:29:33 2015] kernel BUG at mm/migrate.c:1661!
[Mon May 25 05:29:33 2015] invalid opcode: 0000 [#1] SMP
Compound pages cannot be migrated and it was not expected that such pages
be marked for NUMA balancing. This did not take into account that drivers
such as net/packet/af_packet.c may insert compound pages into userspace
with vm_insert_page. This patch tells the NUMA balancing protection scanner
to skip all VM_MIXEDMAP mappings which avoids the possibility that compound
pages are marked for migration.
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reported-by: Jovi Zhangwei <jovi@cloudflare.com>
---
kernel/sched/fair.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 241213be507c..486d00c408b0 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2166,7 +2166,7 @@ void task_numa_work(struct callback_head *work)
}
for (; vma; vma = vma->vm_next) {
if (!vma_migratable(vma) || !vma_policy_mof(vma) ||
- is_vm_hugetlb_page(vma)) {
+ is_vm_hugetlb_page(vma) || (vma->vm_flags & VM_MIXEDMAP)) {
continue;
}
--
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: Mel Gorman <mgorman@suse.de>
To: Jovi Zhangwei <jovi@cloudflare.com>
Cc: linux-kernel@vger.kernel.org, sasha.levin@oracle.com,
n-horiguchi@ah.jp.nec.com, akpm@linux-foundation.org,
Hugh Dickins <hughd@google.com>,
linux-mm@kvack.org, vbabka@suse.cz, rientjes@google.com
Subject: Re: kernel bug(VM_BUG_ON_PAGE) with 3.18.13 in mm/migrate.c
Date: Tue, 2 Jun 2015 08:19:41 +0100 [thread overview]
Message-ID: <20150602071941.GB26425@suse.de> (raw)
In-Reply-To: <CABPcSq+5SR0vqs6fGOwKJ0AZMiLSDQ6Rsevi2wB4YgZPJ9iadg@mail.gmail.com>
On Thu, May 28, 2015 at 11:38:36AM -0700, Jovi Zhangwei wrote:
> Hi Mel,
>
> On Thu, May 28, 2015 at 5:00 AM, Mel Gorman <mgorman@suse.de> wrote:
> > On Wed, May 27, 2015 at 11:05:33AM -0700, Jovi Zhangwei wrote:
> >> Hi,
> >>
> >> I got below kernel bug error in our 3.18.13 stable kernel.
> >> "kernel BUG at mm/migrate.c:1661!"
> >>
> >> Source code:
> >>
> >> 1657 static int numamigrate_isolate_page(pg_data_t *pgdat, struct page *page)
> >> 1658 {
> >> 1659 int page_lru;
> >> 1660
> >> 1661 VM_BUG_ON_PAGE(compound_order(page) &&
> >> !PageTransHuge(page), page);
> >>
> >> It's easy to trigger the error by run tcpdump in our system.(not sure
> >> it will easily be reproduced in another system)
> >> "sudo tcpdump -i bond0.100 'tcp port 4242' -c 100000000000 -w 4242.pcap"
> >>
> >> Any comments for this bug would be great appreciated. thanks.
> >>
> >
> > What sort of compound page is it? What sort of VMA is it in? hugetlbfs
> > pages should never be tagged for NUMA migrate and never enter this
> > path. Transparent huge pages are handled properly so I'm wondering
> > exactly what type of compound page this is and what mapped it into
> > userspace.
> >
> Thanks for your reply.
>
> After reading net/packet/af_packet.c:alloc_one_pg_vec_page, I found
> there indeed have compound page maped into userspace.
>
Ok, it's clear now. Thanks very much.
> I sent a patch for this issue(you may received it), but not sure it's
> right to fix,
> feel free to update it or use your own patch.
>
It avoids the problem but it's not the best fix because a lot of useless
overhead has been incurred for a page that can never be migrated. Can you
try the following instead please?
---8<---
sched, numa: Do not hint for NUMA balancing on VM_MIXEDMAP mappings
Jovi Zhangwei reported the following problem
Below kernel vm bug can be triggered by tcpdump which mmaped a lot of pages
with GFP_COMP flag.
[Mon May 25 05:29:33 2015] page:ffffea0015414000 count:66 mapcount:1 mapping: (null) index:0x0
[Mon May 25 05:29:33 2015] flags: 0x20047580004000(head)
[Mon May 25 05:29:33 2015] page dumped because: VM_BUG_ON_PAGE(compound_order(page) && !PageTransHuge(page))
[Mon May 25 05:29:33 2015] ------------[ cut here ]------------
[Mon May 25 05:29:33 2015] kernel BUG at mm/migrate.c:1661!
[Mon May 25 05:29:33 2015] invalid opcode: 0000 [#1] SMP
Compound pages cannot be migrated and it was not expected that such pages
be marked for NUMA balancing. This did not take into account that drivers
such as net/packet/af_packet.c may insert compound pages into userspace
with vm_insert_page. This patch tells the NUMA balancing protection scanner
to skip all VM_MIXEDMAP mappings which avoids the possibility that compound
pages are marked for migration.
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reported-by: Jovi Zhangwei <jovi@cloudflare.com>
---
kernel/sched/fair.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 241213be507c..486d00c408b0 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2166,7 +2166,7 @@ void task_numa_work(struct callback_head *work)
}
for (; vma; vma = vma->vm_next) {
if (!vma_migratable(vma) || !vma_policy_mof(vma) ||
- is_vm_hugetlb_page(vma)) {
+ is_vm_hugetlb_page(vma) || (vma->vm_flags & VM_MIXEDMAP)) {
continue;
}
next prev parent reply other threads:[~2015-06-02 7:19 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-27 18:05 kernel bug(VM_BUG_ON_PAGE) with 3.18.13 in mm/migrate.c Jovi Zhangwei
2015-05-27 18:05 ` Jovi Zhangwei
2015-05-27 18:42 ` Jovi Zhangwei
2015-05-27 18:42 ` Jovi Zhangwei
2015-05-28 12:00 ` Mel Gorman
2015-05-28 12:00 ` Mel Gorman
2015-05-28 18:38 ` Jovi Zhangwei
2015-05-28 18:38 ` Jovi Zhangwei
2015-05-31 1:39 ` Jovi Zhangwei
2015-05-31 1:39 ` Jovi Zhangwei
2015-06-02 7:19 ` Mel Gorman [this message]
2015-06-02 7:19 ` Mel Gorman
-- strict thread matches above, loose matches on Subject: below --
2015-05-26 23:44 Jovi Zhangwei
2015-05-26 23:44 ` Jovi Zhangwei
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=20150602071941.GB26425@suse.de \
--to=mgorman@suse.de \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=jovi@cloudflare.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=rientjes@google.com \
--cc=sasha.levin@oracle.com \
--cc=vbabka@suse.cz \
/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.