diff for duplicates of <20180310141823.GA5420@andrea> diff --git a/a/1.txt b/N1/1.txt index 0d965f1..674b75f 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,60 +1,60 @@ On Fri, Mar 09, 2018 at 04:21:37PM -0800, Daniel Lustig wrote: > On 3/9/2018 2:57 PM, Palmer Dabbelt wrote: -> > On Fri, 09 Mar 2018 13:30:08 PST (-0800), parri.andrea at gmail.com wrote: +> > On Fri, 09 Mar 2018 13:30:08 PST (-0800), parri.andrea@gmail.com wrote: > >> On Fri, Mar 09, 2018 at 10:54:27AM -0800, Palmer Dabbelt wrote: -> >>> On Fri, 09 Mar 2018 10:36:44 PST (-0800), parri.andrea at gmail.com wrote: +> >>> On Fri, 09 Mar 2018 10:36:44 PST (-0800), parri.andrea@gmail.com wrote: > >> > >> [...] > >> > >>> >This proposal relies on the generic definition, > >>> > -> >>> >?? include/linux/atomic.h , +> >>> > include/linux/atomic.h , > >>> > > >>> >and on the > >>> > -> >>> >?? __atomic_op_acquire() -> >>> >?? __atomic_op_release() +> >>> > __atomic_op_acquire() +> >>> > __atomic_op_release() > >>> > > >>> >above to build the acquire/release atomics (except for the xchg,cmpxchg, > >>> >where the ACQUIRE_BARRIER is inserted conditionally/on success). > >>> > >>> I thought we wanted to use the AQ and RL bits for AMOs, just not for LR/SC -> >>> sequences.? IIRC the AMOs are safe with the current memory model, but I might +> >>> sequences. IIRC the AMOs are safe with the current memory model, but I might > >>> just have some version mismatches in my head. > >> > >> AMO.aqrl are "safe" w.r.t. the LKMM (as they provide "full-ordering"); OTOH, > >> AMO.aq and AMO.rl present weaknesses that LKMM (and some kernel developers) -> >> do not "expect".? I was probing this issue in: +> >> do not "expect". I was probing this issue in: > >> -> >> ? https://marc.info/?l=linux-kernel&m=151930201102853&w=2 +> >> https://marc.info/?l=linux-kernel&m=151930201102853&w=2 > >> > >> (c.f., e.g., test "RISCV-unlock-lock-read-ordering" from that post). > >> > >> Quoting from the commit message of my patch 1/2: > >> -> >> ? "Referring to the "unlock-lock-read-ordering" test reported below, -> >> ?? Daniel wrote: +> >> "Referring to the "unlock-lock-read-ordering" test reported below, +> >> Daniel wrote: > >> -> >> ???? I think an RCpc interpretation of .aq and .rl would in fact -> >> ???? allow the two normal loads in P1 to be reordered [...] +> >> I think an RCpc interpretation of .aq and .rl would in fact +> >> allow the two normal loads in P1 to be reordered [...] > >> -> >> ???? [...] +> >> [...] > >> -> >> ???? Likewise even if the unlock()/lock() is between two stores. -> >> ???? A control dependency might originate from the load part of -> >> ???? the amoswap.w.aq, but there still would have to be something -> >> ???? to ensure that this load part in fact performs after the store -> >> ???? part of the amoswap.w.rl performs globally, and that's not -> >> ???? automatic under RCpc. +> >> Likewise even if the unlock()/lock() is between two stores. +> >> A control dependency might originate from the load part of +> >> the amoswap.w.aq, but there still would have to be something +> >> to ensure that this load part in fact performs after the store +> >> part of the amoswap.w.rl performs globally, and that's not +> >> automatic under RCpc. > >> -> >> ?? Simulation of the RISC-V memory consistency model confirmed this -> >> ?? expectation." +> >> Simulation of the RISC-V memory consistency model confirmed this +> >> expectation." > >> > >> I have just (re)checked these observations against the latest specification, > >> and my results _confirmed_ these verdicts. > > -> > Thanks, I must have just gotten confused about a draft spec or something.? I'm -> > pulling these on top or your other memory model related patch.? I've renamed +> > Thanks, I must have just gotten confused about a draft spec or something. I'm +> > pulling these on top or your other memory model related patch. I've renamed > > the branch "next-mm" to be a bit more descriptiove. > > (Sorry for being out of the loop this week, I was out to deal with diff --git a/a/content_digest b/N1/content_digest index d9eaf32..7eecea5 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,68 +1,84 @@ "ref\0mhng-a5cc1e9d-00d5-49e7-8acd-173277f28381@palmer-si-x1c4\0" "ref\0d7f08bbb-3afb-b745-640a-b720971c68d4@nvidia.com\0" - "From\0parri.andrea@gmail.com (Andrea Parri)\0" - "Subject\0[PATCH v2 2/2] riscv/atomic: Strengthen implementations with fences\0" + "From\0Andrea Parri <parri.andrea@gmail.com>\0" + "Subject\0Re: [PATCH v2 2/2] riscv/atomic: Strengthen implementations with fences\0" "Date\0Sat, 10 Mar 2018 15:18:23 +0100\0" - "To\0linux-riscv@lists.infradead.org\0" + "To\0Daniel Lustig <dlustig@nvidia.com>\0" + "Cc\0Palmer Dabbelt <palmer@sifive.com>" + albert@sifive.com + stern@rowland.harvard.edu + Will Deacon <will.deacon@arm.com> + peterz@infradead.org + boqun.feng@gmail.com + npiggin@gmail.com + dhowells@redhat.com + j.alglave@ucl.ac.uk + luc.maranget@inria.fr + paulmck@linux.vnet.ibm.com + akiyks@gmail.com + mingo@kernel.org + Linus Torvalds <torvalds@linux-foundation.org> + linux-riscv@lists.infradead.org + " linux-kernel@vger.kernel.org\0" "\00:1\0" "b\0" "On Fri, Mar 09, 2018 at 04:21:37PM -0800, Daniel Lustig wrote:\n" "> On 3/9/2018 2:57 PM, Palmer Dabbelt wrote:\n" - "> > On Fri, 09 Mar 2018 13:30:08 PST (-0800), parri.andrea at gmail.com wrote:\n" + "> > On Fri, 09 Mar 2018 13:30:08 PST (-0800), parri.andrea@gmail.com wrote:\n" "> >> On Fri, Mar 09, 2018 at 10:54:27AM -0800, Palmer Dabbelt wrote:\n" - "> >>> On Fri, 09 Mar 2018 10:36:44 PST (-0800), parri.andrea at gmail.com wrote:\n" + "> >>> On Fri, 09 Mar 2018 10:36:44 PST (-0800), parri.andrea@gmail.com wrote:\n" "> >>\n" "> >> [...]\n" "> >>\n" "> >>> >This proposal relies on the generic definition,\n" "> >>> >\n" - "> >>> >?? include/linux/atomic.h ,\n" + "> >>> >\302\240\302\240 include/linux/atomic.h ,\n" "> >>> >\n" "> >>> >and on the\n" "> >>> >\n" - "> >>> >?? __atomic_op_acquire()\n" - "> >>> >?? __atomic_op_release()\n" + "> >>> >\302\240\302\240 __atomic_op_acquire()\n" + "> >>> >\302\240\302\240 __atomic_op_release()\n" "> >>> >\n" "> >>> >above to build the acquire/release atomics (except for the xchg,cmpxchg,\n" "> >>> >where the ACQUIRE_BARRIER is inserted conditionally/on success).\n" "> >>>\n" "> >>> I thought we wanted to use the AQ and RL bits for AMOs, just not for LR/SC\n" - "> >>> sequences.? IIRC the AMOs are safe with the current memory model, but I might\n" + "> >>> sequences.\302\240 IIRC the AMOs are safe with the current memory model, but I might\n" "> >>> just have some version mismatches in my head.\n" "> >>\n" "> >> AMO.aqrl are \"safe\" w.r.t. the LKMM (as they provide \"full-ordering\"); OTOH,\n" "> >> AMO.aq and AMO.rl present weaknesses that LKMM (and some kernel developers)\n" - "> >> do not \"expect\".? I was probing this issue in:\n" + "> >> do not \"expect\".\302\240 I was probing this issue in:\n" "> >>\n" - "> >> ? https://marc.info/?l=linux-kernel&m=151930201102853&w=2\n" + "> >> \302\240 https://marc.info/?l=linux-kernel&m=151930201102853&w=2\n" "> >>\n" "> >> (c.f., e.g., test \"RISCV-unlock-lock-read-ordering\" from that post).\n" "> >>\n" "> >> Quoting from the commit message of my patch 1/2:\n" "> >>\n" - "> >> ? \"Referring to the \"unlock-lock-read-ordering\" test reported below,\n" - "> >> ?? Daniel wrote:\n" + "> >> \302\240 \"Referring to the \"unlock-lock-read-ordering\" test reported below,\n" + "> >> \302\240\302\240 Daniel wrote:\n" "> >>\n" - "> >> ???? I think an RCpc interpretation of .aq and .rl would in fact\n" - "> >> ???? allow the two normal loads in P1 to be reordered [...]\n" + "> >> \302\240\302\240\302\240\302\240 I think an RCpc interpretation of .aq and .rl would in fact\n" + "> >> \302\240\302\240\302\240\302\240 allow the two normal loads in P1 to be reordered [...]\n" "> >>\n" - "> >> ???? [...]\n" + "> >> \302\240\302\240\302\240\302\240 [...]\n" "> >>\n" - "> >> ???? Likewise even if the unlock()/lock() is between two stores.\n" - "> >> ???? A control dependency might originate from the load part of\n" - "> >> ???? the amoswap.w.aq, but there still would have to be something\n" - "> >> ???? to ensure that this load part in fact performs after the store\n" - "> >> ???? part of the amoswap.w.rl performs globally, and that's not\n" - "> >> ???? automatic under RCpc.\n" + "> >> \302\240\302\240\302\240\302\240 Likewise even if the unlock()/lock() is between two stores.\n" + "> >> \302\240\302\240\302\240\302\240 A control dependency might originate from the load part of\n" + "> >> \302\240\302\240\302\240\302\240 the amoswap.w.aq, but there still would have to be something\n" + "> >> \302\240\302\240\302\240\302\240 to ensure that this load part in fact performs after the store\n" + "> >> \302\240\302\240\302\240\302\240 part of the amoswap.w.rl performs globally, and that's not\n" + "> >> \302\240\302\240\302\240\302\240 automatic under RCpc.\n" "> >>\n" - "> >> ?? Simulation of the RISC-V memory consistency model confirmed this\n" - "> >> ?? expectation.\"\n" + "> >> \302\240\302\240 Simulation of the RISC-V memory consistency model confirmed this\n" + "> >> \302\240\302\240 expectation.\"\n" "> >>\n" "> >> I have just (re)checked these observations against the latest specification,\n" "> >> and my results _confirmed_ these verdicts.\n" "> > \n" - "> > Thanks, I must have just gotten confused about a draft spec or something.? I'm\n" - "> > pulling these on top or your other memory model related patch.? I've renamed\n" + "> > Thanks, I must have just gotten confused about a draft spec or something.\302\240 I'm\n" + "> > pulling these on top or your other memory model related patch.\302\240 I've renamed\n" "> > the branch \"next-mm\" to be a bit more descriptiove.\n" "> \n" "> (Sorry for being out of the loop this week, I was out to deal with\n" @@ -159,4 +175,4 @@ "> > \n" > > Thanks! -e3fb4a1a92d3d9513b4712df6faf2de23dc8ebffec623a7e4610d5ee6fabe280 +7773de5c7326a771514b59729c035b8ca6966e1cfbe20f90105de6e7adfd1130
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.