All of lore.kernel.org
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: Peter Xu <peterx@redhat.com>
Cc: kbuild-all@lists.01.org,
	Linux Memory Management List <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: [linux-next:master 5085/5845] fs/userfaultfd.c:337:13: error: implicit declaration of function 'pte_none_mostly'
Date: Sun, 24 Apr 2022 03:23:23 +0800	[thread overview]
Message-ID: <202204240320.TGDuGcsL-lkp@intel.com> (raw)

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head:   e7d6987e09a328d4a949701db40ef63fbb970670
commit: 70a8da53f7cb7368776f9d2790ecbb4f8bc53ba5 [5085/5845] mm: teach core mm about pte markers
config: x86_64-randconfig-a002-20210928 (https://download.01.org/0day-ci/archive/20220424/202204240320.TGDuGcsL-lkp@intel.com/config)
compiler: gcc-11 (Debian 11.2.0-20) 11.2.0
reproduce (this is a W=1 build):
        # https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=70a8da53f7cb7368776f9d2790ecbb4f8bc53ba5
        git remote add linux-next https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
        git fetch --no-tags linux-next master
        git checkout 70a8da53f7cb7368776f9d2790ecbb4f8bc53ba5
        # save the config file
        mkdir build_dir && cp config build_dir/.config
        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>

Note: the linux-next/master HEAD e7d6987e09a328d4a949701db40ef63fbb970670 builds fine.
      It may have been fixed somewhere.

All errors (new ones prefixed by >>):

   fs/userfaultfd.c: In function 'userfaultfd_must_wait':
>> fs/userfaultfd.c:337:13: error: implicit declaration of function 'pte_none_mostly' [-Werror=implicit-function-declaration]
     337 |         if (pte_none_mostly(*pte))
         |             ^~~~~~~~~~~~~~~
   cc1: some warnings being treated as errors


vim +/pte_none_mostly +337 fs/userfaultfd.c

   272	
   273	/*
   274	 * Verify the pagetables are still not ok after having reigstered into
   275	 * the fault_pending_wqh to avoid userland having to UFFDIO_WAKE any
   276	 * userfault that has already been resolved, if userfaultfd_read and
   277	 * UFFDIO_COPY|ZEROPAGE are being run simultaneously on two different
   278	 * threads.
   279	 */
   280	static inline bool userfaultfd_must_wait(struct userfaultfd_ctx *ctx,
   281						 unsigned long address,
   282						 unsigned long flags,
   283						 unsigned long reason)
   284	{
   285		struct mm_struct *mm = ctx->mm;
   286		pgd_t *pgd;
   287		p4d_t *p4d;
   288		pud_t *pud;
   289		pmd_t *pmd, _pmd;
   290		pte_t *pte;
   291		bool ret = true;
   292	
   293		mmap_assert_locked(mm);
   294	
   295		pgd = pgd_offset(mm, address);
   296		if (!pgd_present(*pgd))
   297			goto out;
   298		p4d = p4d_offset(pgd, address);
   299		if (!p4d_present(*p4d))
   300			goto out;
   301		pud = pud_offset(p4d, address);
   302		if (!pud_present(*pud))
   303			goto out;
   304		pmd = pmd_offset(pud, address);
   305		/*
   306		 * READ_ONCE must function as a barrier with narrower scope
   307		 * and it must be equivalent to:
   308		 *	_pmd = *pmd; barrier();
   309		 *
   310		 * This is to deal with the instability (as in
   311		 * pmd_trans_unstable) of the pmd.
   312		 */
   313		_pmd = READ_ONCE(*pmd);
   314		if (pmd_none(_pmd))
   315			goto out;
   316	
   317		ret = false;
   318		if (!pmd_present(_pmd))
   319			goto out;
   320	
   321		if (pmd_trans_huge(_pmd)) {
   322			if (!pmd_write(_pmd) && (reason & VM_UFFD_WP))
   323				ret = true;
   324			goto out;
   325		}
   326	
   327		/*
   328		 * the pmd is stable (as in !pmd_trans_unstable) so we can re-read it
   329		 * and use the standard pte_offset_map() instead of parsing _pmd.
   330		 */
   331		pte = pte_offset_map(pmd, address);
   332		/*
   333		 * Lockless access: we're in a wait_event so it's ok if it
   334		 * changes under us.  PTE markers should be handled the same as none
   335		 * ptes here.
   336		 */
 > 337		if (pte_none_mostly(*pte))
   338			ret = true;
   339		if (!pte_write(*pte) && (reason & VM_UFFD_WP))
   340			ret = true;
   341		pte_unmap(pte);
   342	
   343	out:
   344		return ret;
   345	}
   346	

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp


             reply	other threads:[~2022-04-23 19:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-23 19:23 kernel test robot [this message]
2022-04-23 20:45 ` [linux-next:master 5085/5845] fs/userfaultfd.c:337:13: error: implicit declaration of function 'pte_none_mostly' Peter Xu
2022-04-23 20:45   ` Peter Xu

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=202204240320.TGDuGcsL-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=kbuild-all@lists.01.org \
    --cc=linux-mm@kvack.org \
    --cc=peterx@redhat.com \
    /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.