John Hubbard writes:
>> Is that what you meant?
>
> Yes.
>
I am still trying to understand this issue.
I am also analyzing some cases where interrupt disable is not done
before the lockless pagetable walk (patch 3 discussion).
But given I forgot to add the mm mailing list before, I think it
On 9/23/19 1:23 PM, Leonardo Bras wrote:
> On Mon, 2019-09-23 at 12:58 -0700, John Hubbard wrote:
>>
>> CPU 0CPU 1
>> -- --
>>READ(pte) (re-ordered at run time)
>>
On Mon, 2019-09-23 at 12:58 -0700, John Hubbard wrote:
>
> CPU 0CPU 1
> -- --
>READ(pte) (re-ordered at run time)
>atomic_inc(val) (no run-time memory barrier!)
>
On Mon, 2019-09-23 at 11:14 -0700, John Hubbard wrote:
> On 9/23/19 10:25 AM, Leonardo Bras wrote:
> [...]
> That part is all fine, but there are no run-time memory barriers in the
> atomic_inc() and atomic_dec() additions, which means that this is not
> safe, because memory operations on CPU 1
On Fri, 2019-09-20 at 17:48 -0700, John Hubbard wrote:
>
[...]
> So it seems that full memory barriers (not just compiler barriers) are
> required.
> If the irq enable/disable somehow provides that, then your new code just goes
> along for the ride and Just Works. (You don't have any memory
On Fri, 2019-09-20 at 13:11 -0700, John Hubbard wrote:
> On 9/20/19 12:50 PM, Leonardo Bras wrote:
> > Skips slow part of serialize_against_pte_lookup if there is no running
> > lockless pagetable walk.
> >
> > Signed-off-by: Leonardo Bras
> > ---
> > arch/powerpc/mm/book3s64/pgtable.c | 3 ++-
6 matches
Mail list logo
