public inbox for linux-parisc@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Andrew Morton <akpm@linux-foundation.org>, Helge Deller <deller@gmx.de>
Cc: Parisc List <linux-parisc@vger.kernel.org>,
	John David Anglin <dave.anglin@bell.net>,
	"Liam R. Howlett" <Liam.Howlett@Oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>
Subject: linux-next: manual merge of the mm tree with the parisc-hd tree
Date: Tue, 17 May 2022 18:17:37 +1000	[thread overview]
Message-ID: <20220517181737.102eec7a@canb.auug.org.au> (raw)

[-- Attachment #1: Type: text/plain, Size: 3621 bytes --]

Hi all,

Today's linux-next merge of the mm tree got a conflict in:

  arch/parisc/kernel/cache.c

between commit:

  2d30c4586e69 ("parisc: Rewrite cache flush code for PA8800/PA8900")

from the parisc-hd tree and commit:

  25ba0672baad ("parisc: remove mmap linked list from cache handling")

from the mm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/parisc/kernel/cache.c
index 0fd04073d4b6,ab7c789541bf..000000000000
--- a/arch/parisc/kernel/cache.c
+++ b/arch/parisc/kernel/cache.c
@@@ -654,51 -559,50 +654,56 @@@ static void flush_cache_pages(struct vm
  			}
  		}
  	}
 -	return ptep;
  }
  
 -static void flush_cache_pages(struct vm_area_struct *vma, struct mm_struct *mm,
 -			      unsigned long start, unsigned long end)
 +static inline unsigned long mm_total_size(struct mm_struct *mm)
  {
 -	unsigned long addr, pfn;
 -	pte_t *ptep;
 +	struct vm_area_struct *vma;
 +	unsigned long usize = 0;
++	VMA_ITERATOR(vmi, mm, 0);
  
- 	for (vma = mm->mmap; vma && usize < parisc_cache_flush_threshold; vma = vma->vm_next)
 -	for (addr = start; addr < end; addr += PAGE_SIZE) {
 -		ptep = get_ptep(mm->pgd, addr);
 -		if (ptep) {
 -			pfn = pte_pfn(*ptep);
 -			flush_cache_page(vma, addr, pfn);
 -		}
++	for_each_vma(vmi, vma) {
++		if (usize >= parisc_cache_flush_threshold)
++			break;
 +		usize += vma->vm_end - vma->vm_start;
+ 	}
 +	return usize;
  }
  
  void flush_cache_mm(struct mm_struct *mm)
  {
  	struct vm_area_struct *vma;
+ 	VMA_ITERATOR(vmi, mm, 0);
  
 -	/* Flushing the whole cache on each cpu takes forever on
 -	   rp3440, etc.  So, avoid it if the mm isn't too big.  */
 -	if ((!IS_ENABLED(CONFIG_SMP) || !arch_irqs_disabled()) &&
 -	    mm_total_size(mm) >= parisc_cache_flush_threshold) {
 -		if (mm->context.space_id)
 -			flush_tlb_all();
 +	/*
 +	 * Flushing the whole cache on each cpu takes forever on
 +	 * rp3440, etc. So, avoid it if the mm isn't too big.
 +	 *
 +	 * Note that we must flush the entire cache on machines
 +	 * with aliasing caches to prevent random segmentation
 +	 * faults.
 +	 */
 +	if (!parisc_requires_coherency()
 +	    ||  mm_total_size(mm) >= parisc_cache_flush_threshold) {
 +		if (WARN_ON(IS_ENABLED(CONFIG_SMP) && arch_irqs_disabled()))
 +			return;
 +		flush_tlb_all();
  		flush_cache_all();
  		return;
  	}
  
 +	/* Flush mm */
- 	for (vma = mm->mmap; vma; vma = vma->vm_next)
+ 	for_each_vma(vmi, vma)
 -		flush_cache_pages(vma, mm, vma->vm_start, vma->vm_end);
 +		flush_cache_pages(vma, vma->vm_start, vma->vm_end);
  }
  
 -void flush_cache_range(struct vm_area_struct *vma,
 -		unsigned long start, unsigned long end)
 +void flush_cache_range(struct vm_area_struct *vma, unsigned long start, unsigned long end)
  {
 -	if ((!IS_ENABLED(CONFIG_SMP) || !arch_irqs_disabled()) &&
 -	    end - start >= parisc_cache_flush_threshold) {
 -		if (vma->vm_mm->context.space_id)
 -			flush_tlb_range(vma, start, end);
 +	if (!parisc_requires_coherency()
 +	    || end - start >= parisc_cache_flush_threshold) {
 +		if (WARN_ON(IS_ENABLED(CONFIG_SMP) && arch_irqs_disabled()))
 +			return;
 +		flush_tlb_range(vma, start, end);
  		flush_cache_all();
  		return;
  	}

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

                 reply	other threads:[~2022-05-17  8:18 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20220517181737.102eec7a@canb.auug.org.au \
    --to=sfr@canb.auug.org.au \
    --cc=Liam.Howlett@Oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=dave.anglin@bell.net \
    --cc=deller@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=willy@infradead.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