diff for duplicates of <20161028041300.GA12061@linux.intel.com> diff --git a/a/1.txt b/N1/1.txt index 05bd567..7bf0d72 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -15,7 +15,7 @@ On Thu, Oct 27, 2016 at 09:48:41PM +0000, Kani, Toshimitsu wrote: > > > > wp_huge_pmd(). For whatever reason that returns VM_FAULT_FALLBACK > > > > so we continue to handle_pte_fault(). There we do > > > > -> > > > if (pmd_trans_unstable(vmf->pmd) || pmd_devmap(*vmf- +> > > > ��������if (pmd_trans_unstable(vmf->pmd) || pmd_devmap(*vmf- > > > > >pmd)) > > > > > > > > check which is true - the PMD we have is pmd_trans_huge() - so we @@ -31,8 +31,8 @@ On Thu, Oct 27, 2016 at 09:48:41PM +0000, Kani, Toshimitsu wrote: > > > Can you bisect it with CONFIG_BROKEN removed from older kernels? > > > > > > I remember tracking down something like this when initially doing -> > > the pmd support. It ended up being a missed pmd_devmap() check in -> > > the fault path, so it may not be the same issue. It would at least +> > > the pmd support.��It ended up being a missed pmd_devmap() check in +> > > the fault path, so it may not be the same issue.��It would at least > > > be interesting to see if 4.6 fails in a similar manner with this > > > test and FS_DAX_PMD enabled. > > @@ -51,7 +51,3 @@ Thanks! Applying a similar patch solves this deadlock. Unfortunately I don't solution, but it makes generic/344 + PMDs pass. :) Does anyone with more mm knowledge have time to review? -_______________________________________________ -Linux-nvdimm mailing list -Linux-nvdimm@lists.01.org -https://lists.01.org/mailman/listinfo/linux-nvdimm diff --git a/a/content_digest b/N1/content_digest index c3c5b6f..e54cef7 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -7,9 +7,11 @@ "Date\0Thu, 27 Oct 2016 22:13:00 -0600\0" "To\0Kani" " Toshimitsu <toshi.kani@hpe.com>\0" - "Cc\0linux-fsdevel@vger.kernel.org <linux-fsdevel@vger.kernel.org>" + "Cc\0dan.j.williams@intel.com <dan.j.williams@intel.com>" + ross.zwisler@linux.intel.com <ross.zwisler@linux.intel.com> jack@suse.cz <jack@suse.cz> - " linux-nvdimm@lists.01.org <linux-nvdimm@lists.01.org>\0" + linux-nvdimm@lists.01.org <linux-nvdimm@lists.01.org> + " linux-fsdevel@vger.kernel.org <linux-fsdevel@vger.kernel.org>\0" "\00:1\0" "b\0" "On Thu, Oct 27, 2016 at 09:48:41PM +0000, Kani, Toshimitsu wrote:\n" @@ -29,7 +31,7 @@ "> > > > wp_huge_pmd(). For whatever reason that returns VM_FAULT_FALLBACK\n" "> > > > so we continue to handle_pte_fault(). There we do\n" "> > > > \n" - "> > > > \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240if (pmd_trans_unstable(vmf->pmd) || pmd_devmap(*vmf-\n" + "> > > > \303\257\302\277\302\275\303\257\302\277\302\275\303\257\302\277\302\275\303\257\302\277\302\275\303\257\302\277\302\275\303\257\302\277\302\275\303\257\302\277\302\275\303\257\302\277\302\275if (pmd_trans_unstable(vmf->pmd) || pmd_devmap(*vmf-\n" "> > > > >pmd))\n" "> > > > \n" "> > > > check which is true - the PMD we have is pmd_trans_huge() - so we\n" @@ -45,8 +47,8 @@ "> > > Can you bisect it with CONFIG_BROKEN removed from older kernels?\n" "> > > \n" "> > > I remember tracking down something like this when initially doing\n" - "> > > the pmd support.\302\240\302\240It ended up being a missed pmd_devmap() check in\n" - "> > > the fault path, so it may not be the same issue.\302\240\302\240It would at least\n" + "> > > the pmd support.\303\257\302\277\302\275\303\257\302\277\302\275It ended up being a missed pmd_devmap() check in\n" + "> > > the fault path, so it may not be the same issue.\303\257\302\277\302\275\303\257\302\277\302\275It would at least\n" "> > > be interesting to see if 4.6 fails in a similar manner with this\n" "> > > test and FS_DAX_PMD enabled.\n" "> > \n" @@ -64,10 +66,6 @@ "(yet?) understand this well enough to say whether this is the correct\n" "solution, but it makes generic/344 + PMDs pass. :)\n" "\n" - "Does anyone with more mm knowledge have time to review?\n" - "_______________________________________________\n" - "Linux-nvdimm mailing list\n" - "Linux-nvdimm@lists.01.org\n" - https://lists.01.org/mailman/listinfo/linux-nvdimm + Does anyone with more mm knowledge have time to review? -0a743cfe0c208b93986394fc19c9970a3cb85a0e8a0a2cd95e212957f8a943c0 +ba425c55e408295bc99cb6dcecbf093555c2f7f3c81249ff1dac6afbb40e5863
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.