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
next reply other threads:[~2022-04-23 19:23 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-23 19:23 kernel test robot [this message]
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox