On 2017-12-10 4:42 PM, John David Anglin wrote:
I had always wondered why this code is backwards:
void flush_kernel_dcache_page_addr(void *addr)
{
unsigned long flags;
flush_kernel_dcache_page_asm(addr);
purge_tlb_start(flags);
pdtlb_kernel(addr);
purge_tlb_end(flags);
}
I did try reversing the order yesterday and it it seemed to increase the number of random segmentation faults.
As it stands, there is a bit of a race between the cache flush and the TLB purge.
Actually, the order is understandable given that
flush_kernel_dcache_page_asm uses the same translation
as regular accesses. So, purging the translation before the cache flush
does nothing and speculation can
corrupt the cache.
I think there are a few places where we have the order wrong.
We might be able to use the tmpalias flush_dcache_page_asm routine for
the above.
Dave
--
John David Anglin dave.anglin@xxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
