linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
	linux-mm@kvack.org, Vlastimil Babka <vbabka@suse.cz>,
	Chengming Zhou <chengming.zhou@linux.dev>
Subject: [vbabka-slab:slab/for-next 1/3] mm/slub.c:2103:11: error: call to undeclared function 'get_info_end'; ISO C99 and later do not support implicit function declarations
Date: Wed, 1 May 2024 19:07:15 +0800	[thread overview]
Message-ID: <202405011954.GfS77PZb-lkp@intel.com> (raw)

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab.git slab/for-next
head:   8acbdbf0106c179801f30bff547e9512889c624d
commit: 7f39e23ed8ddd6c49b7a2615037af50881b50206 [1/3] mm/slub: avoid zeroing outside-object freepointer for single free
config: x86_64-buildonly-randconfig-002-20240501 (https://download.01.org/0day-ci/archive/20240501/202405011954.GfS77PZb-lkp@intel.com/config)
compiler: clang version 18.1.4 (https://github.com/llvm/llvm-project e6c3289804a67ea0bb6a86fadbe454dd93b8d855)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240501/202405011954.GfS77PZb-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202405011954.GfS77PZb-lkp@intel.com/

All errors (new ones prefixed by >>):

>> mm/slub.c:2103:11: error: call to undeclared function 'get_info_end'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
    2103 |                 inuse = get_info_end(s);
         |                         ^
   mm/slub.c:2580:15: warning: variable 'partial_slabs' set but not used [-Wunused-but-set-variable]
    2580 |         unsigned int partial_slabs = 0;
         |                      ^
>> mm/slub.c:3731:7: error: call to undeclared function 'freeptr_outside_object'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
    3731 |             !freeptr_outside_object(s))
         |              ^
   1 warning and 2 errors generated.


vim +/get_info_end +2103 mm/slub.c

  2061	
  2062	/*
  2063	 * Hooks for other subsystems that check memory allocations. In a typical
  2064	 * production configuration these hooks all should produce no code at all.
  2065	 *
  2066	 * Returns true if freeing of the object can proceed, false if its reuse
  2067	 * was delayed by KASAN quarantine, or it was returned to KFENCE.
  2068	 */
  2069	static __always_inline
  2070	bool slab_free_hook(struct kmem_cache *s, void *x, bool init)
  2071	{
  2072		kmemleak_free_recursive(x, s->flags);
  2073		kmsan_slab_free(s, x);
  2074	
  2075		debug_check_no_locks_freed(x, s->object_size);
  2076	
  2077		if (!(s->flags & SLAB_DEBUG_OBJECTS))
  2078			debug_check_no_obj_freed(x, s->object_size);
  2079	
  2080		/* Use KCSAN to help debug racy use-after-free. */
  2081		if (!(s->flags & SLAB_TYPESAFE_BY_RCU))
  2082			__kcsan_check_access(x, s->object_size,
  2083					     KCSAN_ACCESS_WRITE | KCSAN_ACCESS_ASSERT);
  2084	
  2085		if (kfence_free(x))
  2086			return false;
  2087	
  2088		/*
  2089		 * As memory initialization might be integrated into KASAN,
  2090		 * kasan_slab_free and initialization memset's must be
  2091		 * kept together to avoid discrepancies in behavior.
  2092		 *
  2093		 * The initialization memset's clear the object and the metadata,
  2094		 * but don't touch the SLAB redzone.
  2095		 *
  2096		 * The object's freepointer is also avoided if stored outside the
  2097		 * object.
  2098		 */
  2099		if (unlikely(init)) {
  2100			int rsize;
  2101			unsigned int inuse;
  2102	
> 2103			inuse = get_info_end(s);
  2104			if (!kasan_has_integrated_init())
  2105				memset(kasan_reset_tag(x), 0, s->object_size);
  2106			rsize = (s->flags & SLAB_RED_ZONE) ? s->red_left_pad : 0;
  2107			memset((char *)kasan_reset_tag(x) + inuse, 0,
  2108			       s->size - inuse - rsize);
  2109		}
  2110		/* KASAN might put x into memory quarantine, delaying its reuse. */
  2111		return !kasan_slab_free(s, x, init);
  2112	}
  2113	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


                 reply	other threads:[~2024-05-01 11:08 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202405011954.GfS77PZb-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=chengming.zhou@linux.dev \
    --cc=linux-mm@kvack.org \
    --cc=llvm@lists.linux.dev \
    --cc=nicolas.bouchinet@ssi.gouv.fr \
    --cc=oe-kbuild-all@lists.linux.dev \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox