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