Re: [PATCH v6 31/39] kasan, vmalloc: only tag normal vmalloc allocations

From: kernel test robot <lkp@intel.com>
To: kbuild-all@lists.01.org
Subject: Re: [PATCH v6 31/39] kasan, vmalloc: only tag normal vmalloc allocations
Date: Tue, 25 Jan 2022 15:56:44 +0800	[thread overview]
Message-ID: <202201251520.0CgVaz6r-lkp@intel.com> (raw)
In-Reply-To: <fbfd9939a4dc375923c9a5c6b9e7ab05c26b8c6b.1643047180.git.andreyknvl@google.com>

[-- Attachment #1: Type: text/plain, Size: 5425 bytes --]

Hi,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v5.17-rc1 next-20220124]
[cannot apply to arm64/for-next/core rostedt-trace/for-next]
[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/andrey-konovalov-linux-dev/kasan-vmalloc-arm64-add-vmalloc-tagging-support-for-SW-HW_TAGS/20220125-021005
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git dd81e1c7d5fb126e5fbc5c9e334d7b3ec29a16a0
config: microblaze-randconfig-s032-20220124 (https://download.01.org/0day-ci/archive/20220125/202201251520.0CgVaz6r-lkp(a)intel.com/config)
compiler: microblaze-linux-gcc (GCC) 11.2.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # apt-get install sparse
        # sparse version: v0.6.4-dirty
        # https://github.com/0day-ci/linux/commit/e53c62ef4d4998f3bdd75ec887bc39a1ef2dd740
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review andrey-konovalov-linux-dev/kasan-vmalloc-arm64-add-vmalloc-tagging-support-for-SW-HW_TAGS/20220125-021005
        git checkout e53c62ef4d4998f3bdd75ec887bc39a1ef2dd740
        # save the config file to linux build tree
        mkdir build_dir
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=microblaze SHELL=/bin/bash

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

sparse warnings: (new ones prefixed by >>)
>> mm/vmalloc.c:2224:49: sparse: sparse: incorrect type in argument 3 (different base types) @@     expected restricted kasan_vmalloc_flags_t [usertype] flags @@     got unsigned int @@
   mm/vmalloc.c:2224:49: sparse:     expected restricted kasan_vmalloc_flags_t [usertype] flags
   mm/vmalloc.c:2224:49: sparse:     got unsigned int
   mm/vmalloc.c:2463:53: sparse: sparse: incorrect type in argument 3 (different base types) @@     expected restricted kasan_vmalloc_flags_t [usertype] flags @@     got unsigned int @@
   mm/vmalloc.c:2463:53: sparse:     expected restricted kasan_vmalloc_flags_t [usertype] flags
   mm/vmalloc.c:2463:53: sparse:     got unsigned int
   mm/vmalloc.c:3148:29: sparse: sparse: invalid assignment: |=
   mm/vmalloc.c:3148:29: sparse:    left side has type restricted kasan_vmalloc_flags_t
   mm/vmalloc.c:3148:29: sparse:    right side has type unsigned int
   mm/vmalloc.c:3165:21: sparse: sparse: invalid assignment: |=
   mm/vmalloc.c:3165:21: sparse:    left side has type restricted kasan_vmalloc_flags_t
   mm/vmalloc.c:3165:21: sparse:    right side has type unsigned int
   mm/vmalloc.c:3167:29: sparse: sparse: invalid assignment: |=
   mm/vmalloc.c:3167:29: sparse:    left side has type restricted kasan_vmalloc_flags_t
   mm/vmalloc.c:3167:29: sparse:    right side has type unsigned int

vim +2224 mm/vmalloc.c

  2176	
  2177	/**
  2178	 * vm_map_ram - map pages linearly into kernel virtual address (vmalloc space)
  2179	 * @pages: an array of pointers to the pages to be mapped
  2180	 * @count: number of pages
  2181	 * @node: prefer to allocate data structures on this node
  2182	 *
  2183	 * If you use this function for less than VMAP_MAX_ALLOC pages, it could be
  2184	 * faster than vmap so it's good.  But if you mix long-life and short-life
  2185	 * objects with vm_map_ram(), it could consume lots of address space through
  2186	 * fragmentation (especially on a 32bit machine).  You could see failures in
  2187	 * the end.  Please use this function for short-lived objects.
  2188	 *
  2189	 * Returns: a pointer to the address that has been mapped, or %NULL on failure
  2190	 */
  2191	void *vm_map_ram(struct page **pages, unsigned int count, int node)
  2192	{
  2193		unsigned long size = (unsigned long)count << PAGE_SHIFT;
  2194		unsigned long addr;
  2195		void *mem;
  2196	
  2197		if (likely(count <= VMAP_MAX_ALLOC)) {
  2198			mem = vb_alloc(size, GFP_KERNEL);
  2199			if (IS_ERR(mem))
  2200				return NULL;
  2201			addr = (unsigned long)mem;
  2202		} else {
  2203			struct vmap_area *va;
  2204			va = alloc_vmap_area(size, PAGE_SIZE,
  2205					VMALLOC_START, VMALLOC_END, node, GFP_KERNEL);
  2206			if (IS_ERR(va))
  2207				return NULL;
  2208	
  2209			addr = va->va_start;
  2210			mem = (void *)addr;
  2211		}
  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		/*
  2220		 * Mark the pages as accessible, now that they are mapped.
  2221		 * With hardware tag-based KASAN, marking is skipped for
  2222		 * non-VM_ALLOC mappings, see __kasan_unpoison_vmalloc().
  2223		 */
> 2224		mem = kasan_unpoison_vmalloc(mem, size, KASAN_VMALLOC_PROT_NORMAL);
  2225	
  2226		return mem;
  2227	}
  2228	EXPORT_SYMBOL(vm_map_ram);
  2229	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org