lkml.org 
[lkml]   [2022]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v8 10/23] mm/shmem: Handle uffd-wp during fork()
Hi Peter,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on hnaz-mm/master]
[cannot apply to arnd-asm-generic/master linus/master linux/master v5.18-rc1 next-20220405]
[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/intel-lab-lkp/linux/commits/Peter-Xu/userfaultfd-wp-Support-shmem-and-hugetlbfs/20220405-100136
base: https://github.com/hnaz/linux-mm master
config: ia64-buildonly-randconfig-r005-20220405 (https://download.01.org/0day-ci/archive/20220406/202204061453.OXOxSh6e-lkp@intel.com/config)
compiler: ia64-linux-gcc (GCC) 11.2.0
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
# https://github.com/intel-lab-lkp/linux/commit/49e56558a1f453907d2813e1ba94d91f9d102e73
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Peter-Xu/userfaultfd-wp-Support-shmem-and-hugetlbfs/20220405-100136
git checkout 49e56558a1f453907d2813e1ba94d91f9d102e73
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=ia64 SHELL=/bin/bash

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

All warnings (new ones prefixed by >>):

In file included from arch/ia64/include/asm/pgtable.h:153,
from include/linux/pgtable.h:6,
from arch/ia64/include/asm/uaccess.h:40,
from include/linux/uaccess.h:11,
from arch/ia64/include/asm/sections.h:11,
from include/linux/interrupt.h:21,
from include/linux/kernel_stat.h:9,
from mm/memory.c:42:
arch/ia64/include/asm/mmu_context.h: In function 'reload_context':
arch/ia64/include/asm/mmu_context.h:127:48: warning: variable 'old_rr4' set but not used [-Wunused-but-set-variable]
127 | unsigned long rr0, rr1, rr2, rr3, rr4, old_rr4;
| ^~~~~~~
In file included from include/linux/mm_inline.h:9,
from mm/memory.c:44:
include/linux/userfaultfd_k.h: In function 'pte_marker_entry_uffd_wp':
include/linux/userfaultfd_k.h:260:16: error: implicit declaration of function 'is_pte_marker_entry' [-Werror=implicit-function-declaration]
260 | return is_pte_marker_entry(entry) &&
| ^~~~~~~~~~~~~~~~~~~
include/linux/userfaultfd_k.h:261:14: error: implicit declaration of function 'pte_marker_get' [-Werror=implicit-function-declaration]
261 | (pte_marker_get(entry) & PTE_MARKER_UFFD_WP);
| ^~~~~~~~~~~~~~
include/linux/userfaultfd_k.h:261:38: error: 'PTE_MARKER_UFFD_WP' undeclared (first use in this function)
261 | (pte_marker_get(entry) & PTE_MARKER_UFFD_WP);
| ^~~~~~~~~~~~~~~~~~
include/linux/userfaultfd_k.h:261:38: note: each undeclared identifier is reported only once for each function it appears in
In file included from include/linux/mm_inline.h:10,
from mm/memory.c:44:
include/linux/swapops.h: At top level:
include/linux/swapops.h:289:20: error: conflicting types for 'is_pte_marker_entry'; have 'bool(swp_entry_t)' {aka '_Bool(swp_entry_t)'}
289 | static inline bool is_pte_marker_entry(swp_entry_t entry)
| ^~~~~~~~~~~~~~~~~~~
In file included from include/linux/mm_inline.h:9,
from mm/memory.c:44:
include/linux/userfaultfd_k.h:260:16: note: previous implicit declaration of 'is_pte_marker_entry' with type 'int()'
260 | return is_pte_marker_entry(entry) &&
| ^~~~~~~~~~~~~~~~~~~
In file included from include/linux/mm_inline.h:10,
from mm/memory.c:44:
include/linux/swapops.h:294:26: error: conflicting types for 'pte_marker_get'; have 'pte_marker(swp_entry_t)' {aka 'long unsigned int(swp_entry_t)'}
294 | static inline pte_marker pte_marker_get(swp_entry_t entry)
| ^~~~~~~~~~~~~~
In file included from include/linux/mm_inline.h:9,
from mm/memory.c:44:
include/linux/userfaultfd_k.h:261:14: note: previous implicit declaration of 'pte_marker_get' with type 'int()'
261 | (pte_marker_get(entry) & PTE_MARKER_UFFD_WP);
| ^~~~~~~~~~~~~~
>> mm/memory.c:1238:1: warning: no previous prototype for 'vma_needs_copy' [-Wmissing-prototypes]
1238 | vma_needs_copy(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma)
| ^~~~~~~~~~~~~~
In file included from include/linux/mm_inline.h:9,
from mm/memory.c:44:
include/linux/userfaultfd_k.h: In function 'pte_marker_entry_uffd_wp':
include/linux/userfaultfd_k.h:262:1: error: control reaches end of non-void function [-Werror=return-type]
262 | }
| ^
cc1: some warnings being treated as errors


vim +/vma_needs_copy +1238 mm/memory.c

1231
1232 /*
1233 * Return true if the vma needs to copy the pgtable during this fork(). Return
1234 * false when we can speed up fork() by allowing lazy page faults later until
1235 * when the child accesses the memory range.
1236 */
1237 bool
> 1238 vma_needs_copy(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma)
1239 {
1240 /*
1241 * Always copy pgtables when dst_vma has uffd-wp enabled even if it's
1242 * file-backed (e.g. shmem). Because when uffd-wp is enabled, pgtable
1243 * contains uffd-wp protection information, that's something we can't
1244 * retrieve from page cache, and skip copying will lose those info.
1245 */
1246 if (userfaultfd_wp(dst_vma))
1247 return true;
1248
1249 if (src_vma->vm_flags & (VM_HUGETLB | VM_PFNMAP | VM_MIXEDMAP))
1250 return true;
1251
1252 if (src_vma->anon_vma)
1253 return true;
1254
1255 /*
1256 * Don't copy ptes where a page fault will fill them correctly. Fork
1257 * becomes much lighter when there are big shared or private readonly
1258 * mappings. The tradeoff is that copy_page_range is more efficient
1259 * than faulting.
1260 */
1261 return false;
1262 }
1263

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

\
 
 \ /
  Last update: 2022-09-17 16:20    [W:0.293 / U:0.544 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site