tree: https://git.kernel.org/pub/scm/linux/kernel/git/melver/linux.git review/kasan-vmalloc-tagging head: bd2110728a4d621f8a26a266ae1bd6ea2b8a1efa commit: d045c20eea99e4c9ca4a5bee4907f728fa9181f2 [23/34] kasan, vmalloc: add vmalloc support to SW_TAGS config: i386-randconfig-a015-20211207 (https://download.01.org/0day-ci/archive/20211211/202112110047.IynWQv4Y-lk...) compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project 097a1cb1d5ebb3a0ec4bcaed8ba3ff6a8e33c00a) 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://git.kernel.org/pub/scm/linux/kernel/git/melver/linux.git/commit/?... git remote add melver https://git.kernel.org/pub/scm/linux/kernel/git/melver/linux.git git fetch --no-tags melver review/kasan-vmalloc-tagging git checkout d045c20eea99e4c9ca4a5bee4907f728fa9181f2 # save the config file to linux build tree mkdir build_dir COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 SHELL=/bin/bash If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot <lkp(a)intel.com&gt; Note: the melver/review/kasan-vmalloc-tagging HEAD bd2110728a4d621f8a26a266ae1bd6ea2b8a1efa builds fine. It only hurts bisectability. All errors (new ones prefixed by >>): mem = kasan_unpoison_vmalloc(mem, size); ~~~~~~~~~~~~~~~~~~~~~~ ^ include/linux/kasan.h:458:21: note: 'kasan_unpoison_vmalloc' declared here static inline void *kasan_unpoison_vmalloc(const void *start, ^ mm/vmalloc.c:2446:64: error: too few arguments to function call, expected 3, have 2 area->addr = kasan_unpoison_vmalloc(area->addr, requested_size); ~~~~~~~~~~~~~~~~~~~~~~ ^ include/linux/kasan.h:458:21: note: 'kasan_unpoison_vmalloc' declared here static inline void *kasan_unpoison_vmalloc(const void *start, ^ mm/vmalloc.c:3770:24: error: too few arguments to function call, expected 3, have 2 vms[area]->size); ^ include/linux/kasan.h:458:21: note: 'kasan_unpoison_vmalloc' declared here static inline void *kasan_unpoison_vmalloc(const void *start, ^ 3 errors generated. vim +2211 mm/vmalloc.c 2174 2175 /** 2176 * vm_map_ram - map pages linearly into kernel virtual address (vmalloc space) 2177 * @pages: an array of pointers to the pages to be mapped 2178 * @count: number of pages 2179 * @node: prefer to allocate data structures on this node 2180 * 2181 * If you use this function for less than VMAP_MAX_ALLOC pages, it could be 2182 * faster than vmap so it's good. But if you mix long-life and short-life 2183 * objects with vm_map_ram(), it could consume lots of address space through 2184 * fragmentation (especially on a 32bit machine). You could see failures in 2185 * the end. Please use this function for short-lived objects. 2186 * 2187 * Returns: a pointer to the address that has been mapped, or %NULL on failure 2188 */ 2189 void *vm_map_ram(struct page **pages, unsigned int count, int node) 2190 { 2191 unsigned long size = (unsigned long)count << PAGE_SHIFT; 2192 unsigned long addr; 2193 void *mem; 2194 2195 if (likely(count <= VMAP_MAX_ALLOC)) { 2196 mem = vb_alloc(size, GFP_KERNEL); 2197 if (IS_ERR(mem)) 2198 return NULL; 2199 addr = (unsigned long)mem; 2200 } else { 2201 struct vmap_area *va; 2202 va = alloc_vmap_area(size, PAGE_SIZE, 2203 VMALLOC_START, VMALLOC_END, node, GFP_KERNEL); 2204 if (IS_ERR(va)) 2205 return NULL; 2206 2207 addr = va->va_start; 2208 mem = (void *)addr; 2209 } 2210 2212 2213 if (vmap_pages_range(addr, addr + size, PAGE_KERNEL, 2214 pages, PAGE_SHIFT) < 0) { 2215 vm_unmap_ram(mem, count); 2216 return NULL; 2217 } 2218 2219 return mem; 2220 } 2221 EXPORT_SYMBOL(vm_map_ram); 2222 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org