All of lore.kernel.org
 help / color / mirror / Atom feed
From: Helge Deller <deller@gmx.de>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: John David Anglin <dave.anglin@bell.net>,
	linux-parisc List <linux-parisc@vger.kernel.org>,
	"James E.J. Bottomley" <jejb@parisc-linux.org>
Subject: Re: [PATCH] parisc: fix race conditions flushing user cache pages
Date: Thu, 30 May 2013 17:05:45 +0200	[thread overview]
Message-ID: <51A76AC9.1020702@gmx.de> (raw)
In-Reply-To: <51A769B6.50801@gmx.de>

On 05/30/2013 05:01 PM, Helge Deller wrote:
> 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.

For those who want to test right now, you can check out the "for-next" branch of:
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
in which I've queue up the outstanding patches for 3.10...

(web: http://git.kernel.org/cgit/linux/kernel/git/deller/parisc-linux.git/log/?h=for-next)

Helge

  reply	other threads:[~2013-05-30 15:05 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-28 12:09 [PATCH] parisc: fix race conditions flushing user cache pages John David Anglin
2013-05-30 14:55 ` James Bottomley
2013-05-30 15:01   ` Helge Deller
2013-05-30 15:05     ` Helge Deller [this message]
2013-05-30 15:11     ` James Bottomley
2013-05-30 17:23       ` John David Anglin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51A76AC9.1020702@gmx.de \
    --to=deller@gmx.de \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=dave.anglin@bell.net \
    --cc=jejb@parisc-linux.org \
    --cc=linux-parisc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.