All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <1310743477.2586.358.camel@twins>

diff --git a/a/1.txt b/N1/1.txt
index 3b8954b..99ad423 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,10 +1,10 @@
 On Fri, 2011-07-15 at 11:18 -0400, Shan Hai wrote:
 
-> >> +	vma = find_vma(mm, address);
+> >> +	vma =3D find_vma(mm, address);
 > > Uhm, find_vma() needs mmap_sem, and futex_atomic_cmpxchg_inatomic() is
 > > most certainly not called with that lock held.
 > >
-> 
+>=20
 > My fault, that will be fixed in the V2 patch.
 
 But you cannot, the function isn't called _atomic_ just for kicks, its
@@ -15,18 +15,18 @@ used while holding spinlocks.
 > >> +		if (follow_page(vma, address, FOLL_WRITE)) {
 > >> +			handle_mm_fault(mm, vma, address, FAULT_FLAG_WRITE);
 > > So how can this toggle your sw dirty/young tracking, that's pretty much
-> > what gup(.write=1) does too!
+> > what gup(.write=3D1) does too!
 > >
-> 
+>=20
 > because of the kernel read only permission of the page is transparent
 > to the follow_page(),  the handle_mm_fault() is not to be activated
-> in the __get_use_pages(), so the gup(.write=1) could not help to fixup
+> in the __get_use_pages(), so the gup(.write=3D1) could not help to fixup
 > the write permission.
 
 So why do you need the vma? Is it like I wrote earlier that you don't
 have spare PTE bits and need the vma flags to see if it may become
 writable?
 
-gup(.write=1) not triggering this is a serious problem though, not
+gup(.write=3D1) not triggering this is a serious problem though, not
 something you can just paper over. I wouldn't be at all surprised to
 find there's more things broken because of that.
diff --git a/a/content_digest b/N1/content_digest
index fffa35d..9cecbc7 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -6,25 +6,24 @@
  "Subject\0Re: [PATCH 1/1] Fixup write permission of TLB on powerpc e500 core\0"
  "Date\0Fri, 15 Jul 2011 17:24:37 +0200\0"
  "To\0Shan Hai <haishan.bai@gmail.com>\0"
- "Cc\0benh@kernel.crashing.org"
+ "Cc\0tony.luck@intel.com"
+  linux-kernel@vger.kernel.org
+  cmetcalf@tilera.com
+  dhowells@redhat.com
   paulus@samba.org
   tglx@linutronix.de
   walken@google.com
-  dhowells@redhat.com
-  cmetcalf@tilera.com
-  tony.luck@intel.com
-  akpm@linux-foundation.org
   linuxppc-dev@lists.ozlabs.org
- " linux-kernel@vger.kernel.org\0"
+ " akpm@linux-foundation.org\0"
  "\00:1\0"
  "b\0"
  "On Fri, 2011-07-15 at 11:18 -0400, Shan Hai wrote:\n"
  "\n"
- "> >> +\tvma = find_vma(mm, address);\n"
+ "> >> +\tvma =3D find_vma(mm, address);\n"
  "> > Uhm, find_vma() needs mmap_sem, and futex_atomic_cmpxchg_inatomic() is\n"
  "> > most certainly not called with that lock held.\n"
  "> >\n"
- "> \n"
+ ">=20\n"
  "> My fault, that will be fixed in the V2 patch.\n"
  "\n"
  "But you cannot, the function isn't called _atomic_ just for kicks, its\n"
@@ -35,20 +34,20 @@
  "> >> +\t\tif (follow_page(vma, address, FOLL_WRITE)) {\n"
  "> >> +\t\t\thandle_mm_fault(mm, vma, address, FAULT_FLAG_WRITE);\n"
  "> > So how can this toggle your sw dirty/young tracking, that's pretty much\n"
- "> > what gup(.write=1) does too!\n"
+ "> > what gup(.write=3D1) does too!\n"
  "> >\n"
- "> \n"
+ ">=20\n"
  "> because of the kernel read only permission of the page is transparent\n"
  "> to the follow_page(),  the handle_mm_fault() is not to be activated\n"
- "> in the __get_use_pages(), so the gup(.write=1) could not help to fixup\n"
+ "> in the __get_use_pages(), so the gup(.write=3D1) could not help to fixup\n"
  "> the write permission.\n"
  "\n"
  "So why do you need the vma? Is it like I wrote earlier that you don't\n"
  "have spare PTE bits and need the vma flags to see if it may become\n"
  "writable?\n"
  "\n"
- "gup(.write=1) not triggering this is a serious problem though, not\n"
+ "gup(.write=3D1) not triggering this is a serious problem though, not\n"
  "something you can just paper over. I wouldn't be at all surprised to\n"
  find there's more things broken because of that.
 
-a3c27acdc25a5527b19a776c50f3fcbf0f7a69ece1bbd10ca87bffd79808d705
+5a9e641d7efc5d88dfdcd0ee20c76e0bb69aa4f58c3b1a6009bf9ef5902af64d

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.