diff for duplicates of <1455033795.2925.74.camel@hpe.com> diff --git a/a/1.txt b/N1/1.txt index a12d913..2ecf549 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -2,12 +2,12 @@ On Tue, 2016-02-09 at 10:10 +0100, Ingo Molnar wrote: > * Toshi Kani <toshi.kani@hpe.com> wrote: > > > Since 4.1, ioremap() supports large page (pud/pmd) mappings in x86_64 -> > and PAE. vmalloc_fault() however assumes that the vmalloc range is +> > and PAE. A vmalloc_fault() however assumes that the vmalloc range is > > limited to pte mappings. > > > > pgd_ctor() sets the kernel's pgd entries to user's during fork(), which > > makes user processes share the same page tables for the kernel -> > ranges. When a call to ioremap() is made at run-time that leads to +> > ranges.A A When a call to ioremap() is made at run-time that leads to > > allocate a new 2nd level table (pud in 64-bit and pmd in PAE), user > > process needs to re-sync with the updated kernel pgd entry with > > vmalloc_fault(). @@ -23,7 +23,7 @@ Large page support of ioremap() has been used for persistent memory mappings for a while. In order to hit this problem, i.e. causing a vmalloc fault, a large mount -of ioremap allocations at run-time is required. The following example +of ioremap allocations at run-time is required. A The following example repeats allocation of 16GB range. # cat /proc/vmallocinfo | grep memremap @@ -35,9 +35,9 @@ phys=480000000 ioremap phys=c80000000 ioremap 0xffffc90d00000000-0xffffc91100001000 17179873280 memremap+0xb4/0x110 phys=c80000000 ioremap -0xffffc91140000000-0xffffc91540001000 17179873280 memremap+0xb4/0x110 +0xffffc91140000000-0xffffc91540001000 17179873280 memremap+0xb4/0x110A phys=480000000 ioremap - : +A : 0xffffc97300000000-0xffffc97700001000 17179873280 memremap+0xb4/0x110 phys=c80000000 ioremap 0xffffc97740000000-0xffffc97b40001000 17179873280 memremap+0xb4/0x110 @@ -49,33 +49,33 @@ phys=480000000 ioremap The last ioremap call above crossed a 512GB boundary (0x8000000000), which allocated a new pud table and updated the kernel pgd entry to point it. - Because user process's page table does not have this pgd entry update, a -read/write syscall request to the range will hit a vmalloc fault. Since +A Because user process's page table does not have this pgd entry update, a +read/write syscall request to the range will hit a vmalloc fault. A Since vmalloc_fault() does not handle a large page properly, this causes an Oops as follows. - BUG: unable to handle kernel paging request at ffff880840000ff8 - IP: [<ffffffff810664ae>] vmalloc_fault+0x1be/0x300 - PGD c7f03a067 PUD 0 - Oops: 0000 [#1] SM - : - Call Trace: - [<ffffffff81067335>] __do_page_fault+0x285/0x3e0 - [<ffffffff810674bf>] do_page_fault+0x2f/0x80 - [<ffffffff810d6d85>] ? put_prev_entity+0x35/0x7a0 - [<ffffffff817a6888>] page_fault+0x28/0x30 - [<ffffffff813bb976>] ? memcpy_erms+0x6/0x10 - [<ffffffff817a0845>] ? schedule+0x35/0x80 - [<ffffffffa006350a>] ? pmem_rw_bytes+0x6a/0x190 [nd_pmem] - [<ffffffff817a3713>] ? schedule_timeout+0x183/0x240 - [<ffffffffa028d2b3>] btt_log_read+0x63/0x140 [nd_btt] - : - [<ffffffff811201d0>] ? __symbol_put+0x60/0x60 - [<ffffffff8122dc60>] ? kernel_read+0x50/0x80 - [<ffffffff81124489>] SyS_finit_module+0xb9/0xf0 - [<ffffffff817a4632>] entry_SYSCALL_64_fastpath+0x1a/0xa4 +A BUG: unable to handle kernel paging request at ffff880840000ff8 +A IP: [<ffffffff810664ae>] vmalloc_fault+0x1be/0x300 +A PGD c7f03a067 PUD 0A +A Oops: 0000 [#1] SM +A A : +A Call Trace: +A [<ffffffff81067335>] __do_page_fault+0x285/0x3e0 +A [<ffffffff810674bf>] do_page_fault+0x2f/0x80 +A [<ffffffff810d6d85>] ? put_prev_entity+0x35/0x7a0 +A [<ffffffff817a6888>] page_fault+0x28/0x30 +A [<ffffffff813bb976>] ? memcpy_erms+0x6/0x10 +A [<ffffffff817a0845>] ? schedule+0x35/0x80 +A [<ffffffffa006350a>] ? pmem_rw_bytes+0x6a/0x190 [nd_pmem] +A [<ffffffff817a3713>] ? schedule_timeout+0x183/0x240 +A [<ffffffffa028d2b3>] btt_log_read+0x63/0x140 [nd_btt] +A A : +A [<ffffffff811201d0>] ? __symbol_put+0x60/0x60 +A [<ffffffff8122dc60>] ? kernel_read+0x50/0x80 +A [<ffffffff81124489>] SyS_finit_module+0xb9/0xf0 +A [<ffffffff817a4632>] entry_SYSCALL_64_fastpath+0x1a/0xa4 -Note that this issue is limited to 64-bit. 32-bit only uses index 3 of the +Note that this issue is limited to 64-bit. A 32-bit only uses index 3 of the pgd entry to cover the entire vmalloc range, which is always valid. I will add this information to the change log. diff --git a/a/content_digest b/N1/content_digest index f7103c1..0f9257b 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -18,12 +18,12 @@ "> * Toshi Kani <toshi.kani@hpe.com> wrote:\n" "> \n" "> > Since 4.1, ioremap() supports large page (pud/pmd) mappings in x86_64\n" - "> > and PAE. \302\240vmalloc_fault() however assumes that the vmalloc range is\n" + "> > and PAE. A vmalloc_fault() however assumes that the vmalloc range is\n" "> > limited to pte mappings.\n" "> > \n" "> > pgd_ctor() sets the kernel's pgd entries to user's during fork(), which\n" "> > makes user processes share the same page tables for the kernel\n" - "> > ranges.\302\240\302\240When a call to ioremap() is made at run-time that leads to\n" + "> > ranges.A A When a call to ioremap() is made at run-time that leads to\n" "> > allocate a new 2nd level table (pud in 64-bit and pmd in PAE), user\n" "> > process needs to re-sync with the updated kernel pgd entry with\n" "> > vmalloc_fault().\n" @@ -39,7 +39,7 @@ "mappings for a while.\n" "\n" "In order to hit this problem, i.e. causing a vmalloc fault, a large mount\n" - "of ioremap allocations at run-time is required. \302\240The following example\n" + "of ioremap allocations at run-time is required. A The following example\n" "repeats allocation of 16GB range.\n" "\n" "# cat /proc/vmallocinfo | grep memremap\n" @@ -51,9 +51,9 @@ "phys=c80000000 ioremap\n" "0xffffc90d00000000-0xffffc91100001000 17179873280 memremap+0xb4/0x110\n" "phys=c80000000 ioremap\n" - "0xffffc91140000000-0xffffc91540001000 17179873280 memremap+0xb4/0x110\302\240\n" + "0xffffc91140000000-0xffffc91540001000 17179873280 memremap+0xb4/0x110A \n" "phys=480000000 ioremap\n" - "\302\240 :\n" + "A :\n" "0xffffc97300000000-0xffffc97700001000 17179873280 memremap+0xb4/0x110\n" "phys=c80000000 ioremap\n" "0xffffc97740000000-0xffffc97b40001000 17179873280 memremap+0xb4/0x110\n" @@ -65,33 +65,33 @@ "\n" "The last ioremap call above crossed a 512GB boundary (0x8000000000), which\n" "allocated a new pud table and updated the kernel pgd entry to point it.\n" - "\302\240Because user process's page table does not have this pgd entry update, a\n" - "read/write syscall request to the range will hit a vmalloc fault. \302\240Since\n" + "A Because user process's page table does not have this pgd entry update, a\n" + "read/write syscall request to the range will hit a vmalloc fault. A Since\n" "vmalloc_fault() does not handle a large page properly, this causes an Oops\n" "as follows.\n" "\n" - "\302\240BUG: unable to handle kernel paging request at ffff880840000ff8\n" - "\302\240IP: [<ffffffff810664ae>] vmalloc_fault+0x1be/0x300\n" - "\302\240PGD c7f03a067 PUD 0\302\240\n" - "\302\240Oops: 0000 [#1] SM\n" - "\302\240 \302\240:\n" - "\302\240Call Trace:\n" - "\302\240[<ffffffff81067335>] __do_page_fault+0x285/0x3e0\n" - "\302\240[<ffffffff810674bf>] do_page_fault+0x2f/0x80\n" - "\302\240[<ffffffff810d6d85>] ? put_prev_entity+0x35/0x7a0\n" - "\302\240[<ffffffff817a6888>] page_fault+0x28/0x30\n" - "\302\240[<ffffffff813bb976>] ? memcpy_erms+0x6/0x10\n" - "\302\240[<ffffffff817a0845>] ? schedule+0x35/0x80\n" - "\302\240[<ffffffffa006350a>] ? pmem_rw_bytes+0x6a/0x190 [nd_pmem]\n" - "\302\240[<ffffffff817a3713>] ? schedule_timeout+0x183/0x240\n" - "\302\240[<ffffffffa028d2b3>] btt_log_read+0x63/0x140 [nd_btt]\n" - "\302\240 \302\240:\n" - "\302\240[<ffffffff811201d0>] ? __symbol_put+0x60/0x60\n" - "\302\240[<ffffffff8122dc60>] ? kernel_read+0x50/0x80\n" - "\302\240[<ffffffff81124489>] SyS_finit_module+0xb9/0xf0\n" - "\302\240[<ffffffff817a4632>] entry_SYSCALL_64_fastpath+0x1a/0xa4\n" + "A BUG: unable to handle kernel paging request at ffff880840000ff8\n" + "A IP: [<ffffffff810664ae>] vmalloc_fault+0x1be/0x300\n" + "A PGD c7f03a067 PUD 0A \n" + "A Oops: 0000 [#1] SM\n" + "A A :\n" + "A Call Trace:\n" + "A [<ffffffff81067335>] __do_page_fault+0x285/0x3e0\n" + "A [<ffffffff810674bf>] do_page_fault+0x2f/0x80\n" + "A [<ffffffff810d6d85>] ? put_prev_entity+0x35/0x7a0\n" + "A [<ffffffff817a6888>] page_fault+0x28/0x30\n" + "A [<ffffffff813bb976>] ? memcpy_erms+0x6/0x10\n" + "A [<ffffffff817a0845>] ? schedule+0x35/0x80\n" + "A [<ffffffffa006350a>] ? pmem_rw_bytes+0x6a/0x190 [nd_pmem]\n" + "A [<ffffffff817a3713>] ? schedule_timeout+0x183/0x240\n" + "A [<ffffffffa028d2b3>] btt_log_read+0x63/0x140 [nd_btt]\n" + "A A :\n" + "A [<ffffffff811201d0>] ? __symbol_put+0x60/0x60\n" + "A [<ffffffff8122dc60>] ? kernel_read+0x50/0x80\n" + "A [<ffffffff81124489>] SyS_finit_module+0xb9/0xf0\n" + "A [<ffffffff817a4632>] entry_SYSCALL_64_fastpath+0x1a/0xa4\n" "\n" - "Note that this issue is limited to 64-bit. \302\24032-bit only uses index 3 of the\n" + "Note that this issue is limited to 64-bit. A 32-bit only uses index 3 of the\n" "pgd entry to cover the entire vmalloc range, which is always valid.\n" "\n" "I will add this information to the change log.\n" @@ -105,4 +105,4 @@ "see: http://www.linux-mm.org/ .\n" "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" -426c3aba8cba30059c94c3703bcb00651e3e95a519e8a5e7edef5b504e128c0f +d96057f00a25110fe00e4803a36f5210ed00e0951a260b4552a7a0f83b3aa36b
diff --git a/a/1.txt b/N2/1.txt index a12d913..86039a5 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -82,9 +82,3 @@ I will add this information to the change log. Thanks, -Toshi - --- -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> diff --git a/a/content_digest b/N2/content_digest index f7103c1..a8d54dd 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -9,7 +9,7 @@ hpa@zytor.com bp@alien8.de henning.schild@siemens.com - linux-nvdimm@lists.01.org + linux-nvdimm@ml01.01.org linux-mm@kvack.org " linux-kernel@vger.kernel.org\0" "\00:1\0" @@ -97,12 +97,6 @@ "I will add this information to the change log.\n" "\n" "Thanks,\n" - "-Toshi\n" - "\n" - "--\n" - "To unsubscribe, send a message with 'unsubscribe linux-mm' in\n" - "the body to majordomo@kvack.org. For more info on Linux MM,\n" - "see: http://www.linux-mm.org/ .\n" - "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" + -Toshi -426c3aba8cba30059c94c3703bcb00651e3e95a519e8a5e7edef5b504e128c0f +abd221cb860a2312c722576a7c81c7a4366c850c964e7e67247a20fb40c59ead
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.