Re: [PATCH] parisc: fix race conditions flushing user cache pages

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

 



On Tue, 2013-05-28 at 08:09 -0400, John David Anglin wrote:
> There are two issues addressed by this patch:
> 
> 1) When we flush user instruction and data pages using the kernel  
> tmpalias region, we need to
> ensure that the local TLB entry for the tmpalias page is never  
> replaced with a different mapping.
> Previously, we purged the entry before and after the cache flush  
> loop.  Although preemption was
> disabled, it seemed possible that the value might change during  
> interrupt processing.  The patch
> removes the purge and disables interrupts during the initial TLB entry  
> purge and cache flush.
> 
> 2) In a number of places, we flush the TLB for the page and then flush  
> the page.  We disabled
> preemption around the flush.  This change disables preemption around  
> both the TLB and cache
> flushes as it seemed the effect of the purge might be lost.
> 
> Without this change, I saw four random segmentation faults in about  
> 1.5 days of intensive package
> building last weekend.  With the change, I haven't seen a single  
> random segmentation fault in about
> one week of building Debian packages on 4-way rp3440.  So, there is a  
> significant improvement
> in system stability.

an rp3440 is PA2.0, so you weren't really testing any of the tlb purge
locking changes.

Also, I don't know what happened, but the actual tmpalias theory
requires a TLB purge before and after and I though we used to have them.
The reason is twofold:

     1. You don't want the caches to speculate in the tmpalias region
     2. A flush after makes the routines interrupt safe (because you can
        interrupt in a tmpalias operation, do another tmpalias
        operation, purge the cache and restart within the non interrupt
        tmpalias and expect everything to work).

Trying to disable interrupts sounds like problem 2.  Can we return to
the proper tmpalias operations rather than trying to hack around them?

James




--
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




[Index of Archives]     [Linux SoC]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux