Linux PARISC architecture development
 help / color / mirror / Atom feed
From: Sven Schnelle <svens@stackframe.org>
To: John David Anglin <dave.anglin@bell.net>
Cc: linux-parisc@vger.kernel.org, Helge Deller <deller@gmx.de>,
	Deller <deller@kernel.org>,
	James Bottomley <James.Bottomley@hansenpartnership.com>
Subject: Re: [PATCH] parisc: Fix non-access data TLB cache flush faults
Date: Thu, 10 Mar 2022 21:57:42 +0100	[thread overview]
Message-ID: <87fsnp34qh.fsf@x1.stackframe.org> (raw)
In-Reply-To: <Yij4pmK8Yjt7Wh1A@mx3210.localdomain> (John David Anglin's message of "Wed, 9 Mar 2022 18:57:42 +0000")

Hi Dave,

John David Anglin <dave.anglin@bell.net> writes:

> When a page is not present, we get non-access data TLB faults from
> the fdc and fic instructions in flush_user_dcache_range_asm and
> flush_user_icache_range_asm. When these occur, the cache line is
> not invalidated and potentially we get memory corruption. The
> problem was hidden by the nullification of the flush instructions.
>
> These faults also affect performance. With pa8800/pa8900 processors,
> there will be 32 faults per 4 KB page since the cache line is 128
> bytes.  The will be more faults with earlier processors.
>
> The problem is fixed by using flush_cache_pages(). It does the flush
> using a tmp alias mapping.
>
> The flush_cache_pages() call in flush_cache_range() flushed too
> large a range.
>  
> Signed-off-by: John David Anglin <dave.anglin@bell.net>
> ---
>
> diff --git a/arch/parisc/kernel/cache.c b/arch/parisc/kernel/cache.c
> index 94150b91c96f..e439b53b0f62 100644
> --- a/arch/parisc/kernel/cache.c
> +++ b/arch/parisc/kernel/cache.c
> @@ -558,15 +558,6 @@ static void flush_cache_pages(struct vm_area_struct *vma, struct mm_struct *mm,
>  	}
>  }
>  
> -static void flush_user_cache_tlb(struct vm_area_struct *vma,
> -				 unsigned long start, unsigned long end)
> -{
> -	flush_user_dcache_range_asm(start, end);
> -	if (vma->vm_flags & VM_EXEC)
> -		flush_user_icache_range_asm(start, end);
> -	flush_tlb_range(vma, start, end);
> -}
> -
>  void flush_cache_mm(struct mm_struct *mm)
>  {
>  	struct vm_area_struct *vma;
> @@ -582,13 +573,6 @@ void flush_cache_mm(struct mm_struct *mm)
>  	}
>  
>  	preempt_disable();
> -	if (mm->context == mfsp(3)) {
> -		for (vma = mm->mmap; vma; vma = vma->vm_next)
> -			flush_user_cache_tlb(vma, vma->vm_start, vma->vm_end);
> -		preempt_enable();
> -		return;
> -	}
> -
>  	for (vma = mm->mmap; vma; vma = vma->vm_next)
>  		flush_cache_pages(vma, mm, vma->vm_start, vma->vm_end);
>  	preempt_enable();
> @@ -606,13 +590,7 @@ void flush_cache_range(struct vm_area_struct *vma,
>  	}
>  
>  	preempt_disable();
> -	if (vma->vm_mm->context == mfsp(3)) {
> -		flush_user_cache_tlb(vma, start, end);
> -		preempt_enable();
> -		return;
> -	}
> -
> -	flush_cache_pages(vma, vma->vm_mm, vma->vm_start, vma->vm_end);
> +	flush_cache_pages(vma, vma->vm_mm, start, end);
>  	preempt_enable();
>  }
>  

I think the preempt_enable()/disable() calls are no longer
required. I've added them to fix a bug when the kernel is preempted
after the mm->context / mfsp(3) compare but as that is now removed
this shouldn't be required anymore.

  reply	other threads:[~2022-03-10 22:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-09 18:57 [PATCH] parisc: Fix non-access data TLB cache flush faults John David Anglin
2022-03-10 20:57 ` Sven Schnelle [this message]
2022-03-10 22:52   ` 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=87fsnp34qh.fsf@x1.stackframe.org \
    --to=svens@stackframe.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=dave.anglin@bell.net \
    --cc=deller@gmx.de \
    --cc=deller@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox