All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <1537519325.19048.0.camel@intel.com>

diff --git a/a/1.txt b/N1/1.txt
index f259e80..1b57866 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,16 +1,16 @@
 On Tue, 2018-09-18 at 03:53 +1000, Nicholas Piggin wrote:
 > On Wed, 5 Sep 2018 07:29:51 -0700
 > Guenter Roeck <linux@roeck-us.net> wrote:
-> 
-> > 
+>=20
+> >=20
 > > Hi,
-> > 
+> >=20
 > > On Tue, Aug 28, 2018 at 09:20:34PM +1000, Nicholas Piggin wrote:
-> > > 
+> > >=20
 > > > Similarly to the previous patch, this tries to optimise
 > > > dirty/accessed
 > > > bits in ptes to avoid access costs of hardware setting them.
-> > > 
+> > >=20
 > > This patch results in silent nios2 boot failures, silent meaning
 > > that
 > > the boot stalls.
@@ -18,7 +18,7 @@ On Tue, 2018-09-18 at 03:53 +1000, Nicholas Piggin wrote:
 > I think a bug in the nios2 TLB code, but maybe other archs have
 > similar
 > issues.
-> 
+>=20
 > In case of a missing / !present Linux pte, nios2 installs a TLB entry
 > with no permissions via its fast TLB exception handler (software TLB
 > fill). Then it relies on that causing a TLB permission exception in a
@@ -26,13 +26,13 @@ On Tue, 2018-09-18 at 03:53 +1000, Nicholas Piggin wrote:
 > flushes the old TLB. Then the fast exception handler will find the
 > new
 > Linux pte.
-> 
+>=20
 > With this patch, nios2 has a case where handle_mm_fault does not
 > flush
 > the old TLB, which results in the TLB permission exception
 > continually
 > being retried.
-> 
+>=20
 > What happens now is that fault paths like do_read_fault will install
 > a
 > Linux pte with the young bit clear and return. That will cause nios2
@@ -45,14 +45,14 @@ On Tue, 2018-09-18 at 03:53 +1000, Nicholas Piggin wrote:
 > and
 > that finally allows the fast TLB handler to fire and pick up the new
 > Linux pte.
-> 
+>=20
 > With this patch, the young bit is set in the first handle_mm_fault,
 > so
 > the second handle_mm_fault no longer sees the ptes are different and
 > does not flush the TLB. The spurious fault handler also does not
 > flush
 > them unless FAULT_FLAG_WRITE is set.
-> 
+>=20
 > What nios2 should do is invalidate the TLB in update_mmu_cache. What
 > it
 > *really* should do is install the new TLB entry, I have some patches
@@ -62,12 +62,12 @@ On Tue, 2018-09-18 at 03:53 +1000, Nicholas Piggin wrote:
 > simple
 > path to just do the TLB invalidate that could go in Andrew's git
 > tree.
-> 
+>=20
 > Is that agreeable with the nios2 maintainers?
-> 
+>=20
 > Thanks,
 > Nick
-> 
+>=20
 Hi
 
 Do you have patches to test?
diff --git a/a/content_digest b/N1/content_digest
index c5caab7..e237203 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -20,16 +20,16 @@
  "On Tue, 2018-09-18 at 03:53 +1000, Nicholas Piggin wrote:\n"
  "> On Wed, 5 Sep 2018 07:29:51 -0700\n"
  "> Guenter Roeck <linux@roeck-us.net> wrote:\n"
- "> \n"
- "> > \n"
+ ">=20\n"
+ "> >=20\n"
  "> > Hi,\n"
- "> > \n"
+ "> >=20\n"
  "> > On Tue, Aug 28, 2018 at 09:20:34PM +1000, Nicholas Piggin wrote:\n"
- "> > > \n"
+ "> > >=20\n"
  "> > > Similarly to the previous patch, this tries to optimise\n"
  "> > > dirty/accessed\n"
  "> > > bits in ptes to avoid access costs of hardware setting them.\n"
- "> > > \n"
+ "> > >=20\n"
  "> > This patch results in silent nios2 boot failures, silent meaning\n"
  "> > that\n"
  "> > the boot stalls.\n"
@@ -37,7 +37,7 @@
  "> I think a bug in the nios2 TLB code, but maybe other archs have\n"
  "> similar\n"
  "> issues.\n"
- "> \n"
+ ">=20\n"
  "> In case of a missing / !present Linux pte, nios2 installs a TLB entry\n"
  "> with no permissions via its fast TLB exception handler (software TLB\n"
  "> fill). Then it relies on that causing a TLB permission exception in a\n"
@@ -45,13 +45,13 @@
  "> flushes the old TLB. Then the fast exception handler will find the\n"
  "> new\n"
  "> Linux pte.\n"
- "> \n"
+ ">=20\n"
  "> With this patch, nios2 has a case where handle_mm_fault does not\n"
  "> flush\n"
  "> the old TLB, which results in the TLB permission exception\n"
  "> continually\n"
  "> being retried.\n"
- "> \n"
+ ">=20\n"
  "> What happens now is that fault paths like do_read_fault will install\n"
  "> a\n"
  "> Linux pte with the young bit clear and return. That will cause nios2\n"
@@ -64,14 +64,14 @@
  "> and\n"
  "> that finally allows the fast TLB handler to fire and pick up the new\n"
  "> Linux pte.\n"
- "> \n"
+ ">=20\n"
  "> With this patch, the young bit is set in the first handle_mm_fault,\n"
  "> so\n"
  "> the second handle_mm_fault no longer sees the ptes are different and\n"
  "> does not flush the TLB. The spurious fault handler also does not\n"
  "> flush\n"
  "> them unless FAULT_FLAG_WRITE is set.\n"
- "> \n"
+ ">=20\n"
  "> What nios2 should do is invalidate the TLB in update_mmu_cache. What\n"
  "> it\n"
  "> *really* should do is install the new TLB entry, I have some patches\n"
@@ -81,12 +81,12 @@
  "> simple\n"
  "> path to just do the TLB invalidate that could go in Andrew's git\n"
  "> tree.\n"
- "> \n"
+ ">=20\n"
  "> Is that agreeable with the nios2 maintainers?\n"
- "> \n"
+ ">=20\n"
  "> Thanks,\n"
  "> Nick\n"
- "> \n"
+ ">=20\n"
  "Hi\n"
  "\n"
  "Do you have patches to test?\n"
@@ -94,4 +94,4 @@
  "Regards\n"
  Ley Foon
 
-99d7ef828ac20101e6720e6de38d2e6b13d5eb8c1e7b9850b561c21df3d075d8
+2e0c4c244faaa92cd9ddd06a1b01bf1e8ec95c36a0b6cd8d679aba80b6368f63

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.