linux-kernel - linux-next: manual merge of the akpm-current tree with the powerpc-fixes tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date:   Wed, 6 Feb 2019 16:15:01 +1100
From:   Stephen Rothwell <sfr@...b.auug.org.au>
To:     Andrew Morton <akpm@...ux-foundation.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        PowerPC <linuxppc-dev@...ts.ozlabs.org>
Cc:     Linux Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "Aneesh Kumar K.V" <aneesh.kumar@...ux.ibm.com>
Subject: linux-next: manual merge of the akpm-current tree with the
 powerpc-fixes tree

Hi all,

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

  arch/powerpc/mm/pgtable-book3s64.c

between commit:

  579b9239c1f3 ("powerpc/radix: Fix kernel crash with mremap()")

from the powerpc-fixes tree and commit:

  41bde21e85a7 ("arch/powerpc/mm: Nest MMU workaround for mprotect RW upgrade")

from the akpm-current 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/powerpc/mm/pgtable-book3s64.c
index ecd31569a120,9f154efed1ae..c11c60056669
--- a/arch/powerpc/mm/pgtable-book3s64.c
+++ b/arch/powerpc/mm/pgtable-book3s64.c
@@@ -401,24 -398,27 +398,49 @@@ void arch_report_meminfo(struct seq_fil
  }
  #endif /* CONFIG_PROC_FS */
  
 +/*
 + * For hash translation mode, we use the deposited table to store hash slot
 + * information and they are stored at PTRS_PER_PMD offset from related pmd
 + * location. Hence a pmd move requires deposit and withdraw.
 + *
 + * For radix translation with split pmd ptl, we store the deposited table in the
 + * pmd page. Hence if we have different pmd page we need to withdraw during pmd
 + * move.
 + *
 + * With hash we use deposited table always irrespective of anon or not.
 + * With radix we use deposited table only for anonymous mapping.
 + */
 +int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl,
 +			   struct spinlock *old_pmd_ptl,
 +			   struct vm_area_struct *vma)
 +{
 +	if (radix_enabled())
 +		return (new_pmd_ptl != old_pmd_ptl) && vma_is_anonymous(vma);
 +
 +	return true;
 +}
++
+ pte_t ptep_modify_prot_start(struct vm_area_struct *vma, unsigned long addr,
+ 			     pte_t *ptep)
+ {
+ 	unsigned long pte_val;
+ 
+ 	/*
+ 	 * Clear the _PAGE_PRESENT so that no hardware parallel update is
+ 	 * possible. Also keep the pte_present true so that we don't take
+ 	 * wrong fault.
+ 	 */
+ 	pte_val = pte_update(vma->vm_mm, addr, ptep, _PAGE_PRESENT, _PAGE_INVALID, 0);
+ 
+ 	return __pte(pte_val);
+ 
+ }
+ 
+ void ptep_modify_prot_commit(struct vm_area_struct *vma, unsigned long addr,
+ 			     pte_t *ptep, pte_t old_pte, pte_t pte)
+ {
+ 	if (radix_enabled())
+ 		return radix__ptep_modify_prot_commit(vma, addr,
+ 						      ptep, old_pte, pte);
+ 	set_pte_at(vma->vm_mm, addr, ptep, pte);
+ }

Content of type "application/pgp-signature" skipped