Re: [PATCH] x86/mm: Add barriers and document switch_mm()-vs-flush synchronization follow-up

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Rafael Aquini <aquini@xxxxxxxxxx> wrote:

> On Tue, Aug 02, 2016 at 03:27:06PM -0700, Nadav Amit wrote:
>> Rafael Aquini <aquini@xxxxxxxxxx> wrote:
>> 
>>> While backporting 71b3c126e611 ("x86/mm: Add barriers and document switch_mm()-vs-flush synchronization")
>>> we stumbled across a possibly missing barrier at flush_tlb_page().
>> 
>> I too noticed it and submitted a similar patch that never got a response [1].
> 
> As far as I understood Andy's rationale for the original patch you need
> a full memory barrier there in flush_tlb_page to get that cache-eviction
> race sorted out.

I am completely ok with your fix (except for the missing barrier in
set_tlb_ubc_flush_pending() ). However, I think mine should suffice. As far as
I saw, an atomic operation preceded every invocation of flush_tlb_page(). I
was afraid someone would send me to measure the patch performance impact so I
looked for one with the least impact.

See Intel SDM 8.2.2 "Memory Ordering in P6 and More Recent Processor Families"
for the reasoning behind smp_mb__after_atomic() . The result of an atomic
operation followed by smp_mb__after_atomic should be identical to smp_mb().

Regards,
Nadav




--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]