Re: [PATCH v2] powerpc/64s/radix: do not flush TLB when relaxing access

[kbuild test robot <lkp@intel.com>]

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

Hi Nicholas,

I love your patch! Yet something to improve:

[auto build test ERROR on v4.17-rc6]
[cannot apply to powerpc/next next-20180517]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Nicholas-Piggin/powerpc-64s-radix-do-not-flush-TLB-when-relaxing-access/20180522-024317
config: powerpc-bamboo_defconfig (attached as .config)
compiler: powerpc-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=powerpc 

All errors (new ones prefixed by >>):

   arch/powerpc/mm/pgtable.c: In function 'ptep_set_access_flags':
>> arch/powerpc/mm/pgtable.c:246:32: error: 'mm_context_t {aka struct <anonymous>}' has no member named 'copros'
       if (atomic_read(&mm->context.copros) > 0)
                                   ^

vim +246 arch/powerpc/mm/pgtable.c

   209	
   210	/*
   211	 * This is called when relaxing access to a PTE. It's also called in the page
   212	 * fault path when we don't hit any of the major fault cases, ie, a minor
   213	 * update of _PAGE_ACCESSED, _PAGE_DIRTY, etc... The generic code will have
   214	 * handled those two for us, we additionally deal with missing execute
   215	 * permission here on some processors
   216	 */
   217	int ptep_set_access_flags(struct vm_area_struct *vma, unsigned long address,
   218				  pte_t *ptep, pte_t entry, int dirty)
   219	{
   220		struct mm_struct *mm = vma->vm_mm;
   221		int changed;
   222	
   223		entry = set_access_flags_filter(entry, vma, dirty);
   224		changed = !pte_same(*(ptep), entry);
   225		if (changed) {
   226			if (!is_vm_hugetlb_page(vma))
   227				assert_pte_locked(mm, address);
   228			__ptep_set_access_flags(mm, ptep, entry, address);
   229			if (IS_ENABLED(CONFIG_PPC_BOOK3S_64)) {
   230				/*
   231				 * Book3S does not require a TLB flush when relaxing
   232				 * access restrictions because the core MMU will reload
   233				 * the pte after taking an access fault. However the
   234				 * NMMU on POWER9 does not re-load the pte, so flush
   235				 * if we have a coprocessor attached to this address
   236				 * space.
   237				 *
   238				 * This could be further refined and pushed out to
   239				 * NMMU drivers so TLBIEs are only done for NMMU
   240				 * faults, but this is a more minimal fix. The NMMU
   241				 * fault handler does a get_user_pages_remote or
   242				 * similar to bring the page tables in, and this
   243				 * flush_tlb_page will do a global TLBIE because the
   244				 * coprocessor is attached to the address space.
   245				 */
 > 246				if (atomic_read(&mm->context.copros) > 0)
   247					flush_tlb_page(vma, address);
   248			} else {
   249				flush_tlb_page(vma, address);
   250			}
   251		}
   252		return changed;
   253	}
   254	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 10986 bytes --]