All of lore.kernel.org
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: kbuild-all@lists.01.org
Subject: [android-common:android12-5.10 13859/13862] mm/memory.c:4724:9: error: implicit declaration of function 'mmu_notifier_trylock'; did you mean 'mmu_notifier_unlock'?
Date: Thu, 16 Dec 2021 16:16:17 +0800	[thread overview]
Message-ID: <202112161632.kQZI4tAz-lkp@intel.com> (raw)

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

tree:   https://android.googlesource.com/kernel/common android12-5.10
head:   70c9301d9c4be76630901189cc7376eb22115a3b
commit: 6971350406a366f4565bdc6b17c08ddd577f27f3 [13859/13862] ANDROID: fix mmu_notifier race caused by not taking mmap_lock during SPF
config: x86_64-randconfig-r033-20211214 (https://download.01.org/0day-ci/archive/20211216/202112161632.kQZI4tAz-lkp(a)intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
        git remote add android-common https://android.googlesource.com/kernel/common
        git fetch --no-tags android-common android12-5.10
        git checkout 6971350406a366f4565bdc6b17c08ddd577f27f3
        # save the config file to linux build tree
        mkdir build_dir
        make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   mm/memory.c: In function 'handle_pte_fault':
>> mm/memory.c:4724:9: error: implicit declaration of function 'mmu_notifier_trylock'; did you mean 'mmu_notifier_unlock'? [-Werror=implicit-function-declaration]
    4724 |    if (!mmu_notifier_trylock(vmf->vma->vm_mm)) {
         |         ^~~~~~~~~~~~~~~~~~~~
         |         mmu_notifier_unlock
   cc1: some warnings being treated as errors


vim +4724 mm/memory.c

  4616	
  4617	/*
  4618	 * These routines also need to handle stuff like marking pages dirty
  4619	 * and/or accessed for architectures that don't do it in hardware (most
  4620	 * RISC architectures).  The early dirtying is also good on the i386.
  4621	 *
  4622	 * There is also a hook called "update_mmu_cache()" that architectures
  4623	 * with external mmu caches can use to update those (ie the Sparc or
  4624	 * PowerPC hashed page tables that act as extended TLBs).
  4625	 *
  4626	 * We enter with non-exclusive mmap_lock (to exclude vma changes, but allow
  4627	 * concurrent faults).
  4628	 *
  4629	 * The mmap_lock may have been released depending on flags and our return value.
  4630	 * See filemap_fault() and __lock_page_or_retry().
  4631	 */
  4632	static vm_fault_t handle_pte_fault(struct vm_fault *vmf)
  4633	{
  4634		pte_t entry;
  4635		vm_fault_t ret = 0;
  4636	
  4637		if (unlikely(pmd_none(*vmf->pmd))) {
  4638			/*
  4639			 * In the case of the speculative page fault handler we abort
  4640			 * the speculative path immediately as the pmd is probably
  4641			 * in the way to be converted in a huge one. We will try
  4642			 * again holding the mmap_sem (which implies that the collapse
  4643			 * operation is done).
  4644			 */
  4645			if (vmf->flags & FAULT_FLAG_SPECULATIVE)
  4646				return VM_FAULT_RETRY;
  4647			/*
  4648			 * Leave __pte_alloc() until later: because vm_ops->fault may
  4649			 * want to allocate huge page, and if we expose page table
  4650			 * for an instant, it will be difficult to retract from
  4651			 * concurrent faults and from rmap lookups.
  4652			 */
  4653			vmf->pte = NULL;
  4654		} else if (!(vmf->flags & FAULT_FLAG_SPECULATIVE)) {
  4655			/*
  4656			 * If a huge pmd materialized under us just retry later.  Use
  4657			 * pmd_trans_unstable() via pmd_devmap_trans_unstable() instead
  4658			 * of pmd_trans_huge() to ensure the pmd didn't become
  4659			 * pmd_trans_huge under us and then back to pmd_none, as a
  4660			 * result of MADV_DONTNEED running immediately after a huge pmd
  4661			 * fault in a different thread of this mm, in turn leading to a
  4662			 * misleading pmd_trans_huge() retval. All we have to ensure is
  4663			 * that it is a regular pmd that we can walk with
  4664			 * pte_offset_map() and we can do that through an atomic read
  4665			 * in C, which is what pmd_trans_unstable() provides.
  4666			 */
  4667			if (pmd_devmap_trans_unstable(vmf->pmd))
  4668				return 0;
  4669			/*
  4670			 * A regular pmd is established and it can't morph into a huge
  4671			 * pmd from under us anymore at this point because we hold the
  4672			 * mmap_lock read mode and khugepaged takes it in write mode.
  4673			 * So now it's safe to run pte_offset_map().
  4674			 * This is not applicable to the speculative page fault handler
  4675			 * but in that case, the pte is fetched earlier in
  4676			 * handle_speculative_fault().
  4677			 */
  4678			vmf->pte = pte_offset_map(vmf->pmd, vmf->address);
  4679			vmf->orig_pte = *vmf->pte;
  4680	
  4681			/*
  4682			 * some architectures can have larger ptes than wordsize,
  4683			 * e.g.ppc44x-defconfig has CONFIG_PTE_64BIT=y and
  4684			 * CONFIG_32BIT=y, so READ_ONCE cannot guarantee atomic
  4685			 * accesses.  The code below just needs a consistent view
  4686			 * for the ifs and we later double check anyway with the
  4687			 * ptl lock held. So here a barrier will do.
  4688			 */
  4689			barrier();
  4690			if (pte_none(vmf->orig_pte)) {
  4691				pte_unmap(vmf->pte);
  4692				vmf->pte = NULL;
  4693			}
  4694		}
  4695	
  4696		if (!vmf->pte) {
  4697			if (vma_is_anonymous(vmf->vma))
  4698				return do_anonymous_page(vmf);
  4699			else if ((vmf->flags & FAULT_FLAG_SPECULATIVE) &&
  4700					!vmf_allows_speculation(vmf))
  4701				return VM_FAULT_RETRY;
  4702			else
  4703				return do_fault(vmf);
  4704		}
  4705	
  4706		if (!pte_present(vmf->orig_pte))
  4707			return do_swap_page(vmf);
  4708	
  4709		if (pte_protnone(vmf->orig_pte) && vma_is_accessible(vmf->vma))
  4710			return do_numa_page(vmf);
  4711	
  4712		if (!pte_spinlock(vmf))
  4713			return VM_FAULT_RETRY;
  4714		entry = vmf->orig_pte;
  4715		if (unlikely(!pte_same(*vmf->pte, entry))) {
  4716			update_mmu_tlb(vmf->vma, vmf->address, vmf->pte);
  4717			goto unlock;
  4718		}
  4719		if (vmf->flags & FAULT_FLAG_WRITE) {
  4720			if (!pte_write(entry)) {
  4721				if (!(vmf->flags & FAULT_FLAG_SPECULATIVE))
  4722					return do_wp_page(vmf);
  4723	
> 4724				if (!mmu_notifier_trylock(vmf->vma->vm_mm)) {
  4725					ret = VM_FAULT_RETRY;
  4726					goto unlock;
  4727				}
  4728	
  4729				ret = do_wp_page(vmf);
  4730				mmu_notifier_unlock(vmf->vma->vm_mm);
  4731				return ret;
  4732			}
  4733			entry = pte_mkdirty(entry);
  4734		}
  4735		entry = pte_mkyoung(entry);
  4736		if (ptep_set_access_flags(vmf->vma, vmf->address, vmf->pte, entry,
  4737					vmf->flags & FAULT_FLAG_WRITE)) {
  4738			update_mmu_cache(vmf->vma, vmf->address, vmf->pte);
  4739		} else {
  4740			/* Skip spurious TLB flush for retried page fault */
  4741			if (vmf->flags & FAULT_FLAG_TRIED)
  4742				goto unlock;
  4743			if (vmf->flags & FAULT_FLAG_SPECULATIVE)
  4744				ret = VM_FAULT_RETRY;
  4745			/*
  4746			 * This is needed only for protection faults but the arch code
  4747			 * is not yet telling us if this is a protection fault or not.
  4748			 * This still avoids useless tlb flushes for .text page faults
  4749			 * with threads.
  4750			 */
  4751			if (vmf->flags & FAULT_FLAG_WRITE)
  4752				flush_tlb_fix_spurious_fault(vmf->vma, vmf->address);
  4753		}
  4754	unlock:
  4755		pte_unmap_unlock(vmf->pte, vmf->ptl);
  4756		return ret;
  4757	}
  4758	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

                 reply	other threads:[~2021-12-16  8:16 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=202112161632.kQZI4tAz-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=kbuild-all@lists.01.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.