8:01 a.m.
Hi Peter,
[FYI, it's a private test report for your RFC patch.]
[auto build test WARNING on asm-generic/master]
[cannot apply to arm64/for-next/core linus/master hnaz-linux-mm/master v5.11-rc3
next-20210115]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Peter-Xu/userfaultfd-wp-Support-...
base: https://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git master
config: powerpc64-randconfig-r015-20210115 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
5b42fd8dd4e7e29125a09a41a33af7c9cb57d144)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc64 cross compiling tool for clang build
# apt-get install binutils-powerpc64-linux-gnu
#
https://github.com/0day-ci/linux/commit/52b3f6cd15560c697c44ecfb34fd303f9...
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Peter-Xu/userfaultfd-wp-Support-shmem-and-hugetlbfs/20210116-011305
git checkout 52b3f6cd15560c697c44ecfb34fd303f9cc43ae2
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp(a)intel.com>
All warnings (new ones prefixed by >>):
> mm/memory.c:4380:12: warning: no previous prototype for function
'uffd_wp_handle_special' [-Wmissing-prototypes]
vm_fault_t
uffd_wp_handle_special(struct vm_fault *vmf)
^
mm/memory.c:4380:1: note: declare 'static' if the function is not intended to
be used outside of this translation unit
vm_fault_t uffd_wp_handle_special(struct vm_fault *vmf)
^
static
1 warning generated.
vim +/uffd_wp_handle_special +4380 mm/memory.c
4375
4376 /*
4377 * This is actually a page-missing access, but with uffd-wp special pte
4378 * installed. It means this pte was wr-protected before being unmapped.
4379 */
4380 vm_fault_t uffd_wp_handle_special(struct vm_fault *vmf)
4381 {
4382 /* Careful! vmf->pte unmapped after return */
4383 if (!pte_unmap_same(vmf))
4384 return 0;
4385
4386 /*
4387 * Just in case there're leftover special ptes even after the region
4388 * got unregistered - we can simply clear them.
4389 */
4390 if (unlikely(!userfaultfd_wp(vmf->vma) || vma_is_anonymous(vmf->vma)))
4391 return uffd_wp_clear_special(vmf);
4392
4393 /*
4394 * Tell all the rest of the fault code: we're handling a special pte,
4395 * always remember to arm the uffd-wp bit when intalling the new pte.
4396 */
4397 vmf->flags |= FAULT_FLAG_UFFD_WP;
4398
4399 /*
4400 * Let's assume this is a read fault no matter what. If it is a real
4401 * write access, it'll fault again into do_wp_page() where the message
4402 * will be generated before the thread yields itself.
4403 *
4404 * Ideally we can also handle write immediately before return, but this
4405 * should be a slow path already (pte unmapped), so be simple first.
4406 */
4407 vmf->flags &= ~FAULT_FLAG_WRITE;
4408
4409 return do_fault(vmf);
4410 }
4411
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org