On 05/30/2013 04:55 PM, James Bottomley wrote: > 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. Which kind of system do we need to test those "tlb purge locking changes" (PAx.y)? At least I can confirm, that Dave's patches have made all my systems absolutely stable. > 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? -- 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
