diff for duplicates of <1310719445.2586.288.camel@twins> diff --git a/a/1.txt b/N1/1.txt index 8d940b6..76fa0af 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -6,8 +6,7 @@ On Fri, 2011-07-15 at 16:38 +0800, MailingLists wrote: > >> BUG: On FUTEX_LOCK_PI, there is a infinite loop in the futex_lock_pi() > >> on Powerpc e500 core. > >> Cause: The linux kernel on the e500 core has no write permission on -> >> the COW page, refer the head comment of the following test co= -de. +> >> the COW page, refer the head comment of the following test code. > >> > >> ftrace on test case: > >> [000] 353.990181: futex_lock_pi_atomic<-futex_lock_pi @@ -26,17 +25,16 @@ de. > >> [ a loop occures here ] > >> > > -> > But but but but, that get_user_pages(.write=3D1, .force=3D0) should res= -ult +> > But but but but, that get_user_pages(.write=1, .force=0) should result > > in a COW break, getting our own writable page. > > > > What is this e500 thing smoking that this doesn't work? ->=20 +> > A page could be set to read only by the kernel (supervisor in the powerpc > literature) on the e500, and that's what the kernel do. Set SW(supervisor > write) bit in the TLB entry to grant write permission to the kernel on a > page. ->=20 +> > And further the SW bit is set according to the DIRTY flag of the PTE, > PTE.DIRTY is set in the do_page_fault(), the futex_lock_pi() disabled > page fault, the PTE.DIRTY never can be set, so do the SW bit, unbreakable diff --git a/a/content_digest b/N1/content_digest index 7f7476e..5cc077e 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -5,15 +5,16 @@ "Subject\0Re: [PATCH 0/1] Fixup write permission of TLB on powerpc e500 core\0" "Date\0Fri, 15 Jul 2011 10:44:05 +0200\0" "To\0MailingLists <haishan.bai@gmail.com>\0" - "Cc\0tony.luck@intel.com" - linux-kernel@vger.kernel.org - cmetcalf@tilera.com - dhowells@redhat.com + "Cc\0benh@kernel.crashing.org" 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 - " akpm@linux-foundation.org\0" + " linux-kernel@vger.kernel.org\0" "\00:1\0" "b\0" "On Fri, 2011-07-15 at 16:38 +0800, MailingLists wrote:\n" @@ -24,8 +25,7 @@ "> >> BUG: On FUTEX_LOCK_PI, there is a infinite loop in the futex_lock_pi()\n" "> >> on Powerpc e500 core.\n" "> >> Cause: The linux kernel on the e500 core has no write permission on\n" - "> >> the COW page, refer the head comment of the following test co=\n" - "de.\n" + "> >> the COW page, refer the head comment of the following test code.\n" "> >>\n" "> >> ftrace on test case:\n" "> >> [000] 353.990181: futex_lock_pi_atomic<-futex_lock_pi\n" @@ -44,17 +44,16 @@ "> >> [ a loop occures here ]\n" "> >>\n" "> >\n" - "> > But but but but, that get_user_pages(.write=3D1, .force=3D0) should res=\n" - "ult\n" + "> > But but but but, that get_user_pages(.write=1, .force=0) should result\n" "> > in a COW break, getting our own writable page.\n" "> >\n" "> > What is this e500 thing smoking that this doesn't work?\n" - ">=20\n" + "> \n" "> A page could be set to read only by the kernel (supervisor in the powerpc\n" "> literature) on the e500, and that's what the kernel do. Set SW(supervisor\n" "> write) bit in the TLB entry to grant write permission to the kernel on a\n" "> page.\n" - ">=20\n" + "> \n" "> And further the SW bit is set according to the DIRTY flag of the PTE,\n" "> PTE.DIRTY is set in the do_page_fault(), the futex_lock_pi() disabled\n" "> page fault, the PTE.DIRTY never can be set, so do the SW bit, unbreakable\n" @@ -66,4 +65,4 @@ "Also get_user_pages() fully expects to be able to schedule, and in fact\n" can call the full pf handler path all by its lonesome self. -5dc83132b969e480229a17fdffe13d7e84e5e3087fe58f185288b0ffb30e6e9b +0cb3947fb4341f40a9a9af380d6ba56655a7376f6d1aae09daf6b560626f49fe
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.