3:10 a.m.
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>
Note: the melver/review/kasan-vmalloc-tagging HEAD
bd2110728a4d621f8a26a266ae1bd6ea2b8a1efa builds fine.
It only hurts bisectability.
All errors (new ones prefixed by >>):
> mm/vmalloc.c:2211:40: error: too few arguments to function call,
expected 3, have 2
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
2211 mem = kasan_unpoison_vmalloc(mem, size);
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