From: kernel test robot <lkp@intel.com>
To: "Harry Yoo (Oracle)" <harry@kernel.org>
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev
Subject: [harry:slab-allow-runtime-parameter-tuning-rfc-v1r1-wip 5/5] mm/slub.c:5985:8: error: use of undeclared label 'flush'
Date: Sun, 03 May 2026 08:08:12 +0800 [thread overview]
Message-ID: <202605030847.0BApbpIn-lkp@intel.com> (raw)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/harry/linux.git slab-allow-runtime-parameter-tuning-rfc-v1r1-wip
head: cb8be1e8cd9f6033638b579596456da407e4fb5c
commit: cb8be1e8cd9f6033638b579596456da407e4fb5c [5/5] mm/slab: allow changing sheaf_capacity at runtime
config: arm-allnoconfig (https://download.01.org/0day-ci/archive/20260503/202605030847.0BApbpIn-lkp@intel.com/config)
compiler: clang version 23.0.0git (https://github.com/llvm/llvm-project 5bac06718f502014fade905512f1d26d578a18f3)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260503/202605030847.0BApbpIn-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/202605030847.0BApbpIn-lkp@intel.com/
All errors (new ones prefixed by >>):
>> mm/slub.c:5985:8: error: use of undeclared label 'flush'
5985 | goto flush;
| ^
>> mm/slub.c:8575:26: error: no member named 'barn' in 'struct kmem_cache_node'
8575 | if (get_node(s, node)->barn)
| ~~~~~~~~~~~~~~~~~ ^
2 errors generated.
vim +/flush +5985 mm/slub.c
2d517aa09bbc420 Vlastimil Babka 2025-09-03 5958
ec66e0d599520ab Vlastimil Babka 2025-09-03 5959 static void rcu_free_sheaf(struct rcu_head *head)
ec66e0d599520ab Vlastimil Babka 2025-09-03 5960 {
ec66e0d599520ab Vlastimil Babka 2025-09-03 5961 struct slab_sheaf *sheaf;
fd6db58867924d2 Vlastimil Babka 2025-10-11 5962 struct node_barn *barn = NULL;
ec66e0d599520ab Vlastimil Babka 2025-09-03 5963 struct kmem_cache *s;
ec66e0d599520ab Vlastimil Babka 2025-09-03 5964
ec66e0d599520ab Vlastimil Babka 2025-09-03 5965 sheaf = container_of(head, struct slab_sheaf, rcu_head);
ec66e0d599520ab Vlastimil Babka 2025-09-03 5966
ec66e0d599520ab Vlastimil Babka 2025-09-03 5967 s = sheaf->cache;
ec66e0d599520ab Vlastimil Babka 2025-09-03 5968
ec66e0d599520ab Vlastimil Babka 2025-09-03 5969 /*
ec66e0d599520ab Vlastimil Babka 2025-09-03 5970 * This may remove some objects due to slab_free_hook() returning false,
ec66e0d599520ab Vlastimil Babka 2025-09-03 5971 * so that the sheaf might no longer be completely full. But it's easier
ec66e0d599520ab Vlastimil Babka 2025-09-03 5972 * to handle it as full (unless it became completely empty), as the code
ec66e0d599520ab Vlastimil Babka 2025-09-03 5973 * handles it fine. The only downside is that sheaf will serve fewer
ec66e0d599520ab Vlastimil Babka 2025-09-03 5974 * allocations when reused. It only happens due to debugging, which is a
ec66e0d599520ab Vlastimil Babka 2025-09-03 5975 * performance hit anyway.
1ce20c28eafdc10 Vlastimil Babka 2025-11-05 5976 *
1ce20c28eafdc10 Vlastimil Babka 2025-11-05 5977 * If it returns true, there was at least one object from pfmemalloc
1ce20c28eafdc10 Vlastimil Babka 2025-11-05 5978 * slab so simply flush everything.
ec66e0d599520ab Vlastimil Babka 2025-09-03 5979 */
1ce20c28eafdc10 Vlastimil Babka 2025-11-05 5980 if (__rcu_free_sheaf_prepare(s, sheaf))
cb8be1e8cd9f603 Harry Yoo (Oracle 2026-04-21 5981) goto flush_unlocked;
ec66e0d599520ab Vlastimil Babka 2025-09-03 5982
5ba6bc27b1f99b3 Vlastimil Babka (SUSE 2026-03-11 5983) barn = get_barn_node(s, sheaf->node);
5ba6bc27b1f99b3 Vlastimil Babka (SUSE 2026-03-11 5984) if (!barn)
fd6db58867924d2 Vlastimil Babka 2025-10-11 @5985 goto flush;
fd6db58867924d2 Vlastimil Babka 2025-10-11 5986
cb8be1e8cd9f603 Harry Yoo (Oracle 2026-04-21 5987) if (!local_trylock(&s->cpu_sheaves->lock))
cb8be1e8cd9f603 Harry Yoo (Oracle 2026-04-21 5988) goto flush_unlocked;
cb8be1e8cd9f603 Harry Yoo (Oracle 2026-04-21 5989)
ec66e0d599520ab Vlastimil Babka 2025-09-03 5990 /* due to slab_free_hook() */
ec66e0d599520ab Vlastimil Babka 2025-09-03 5991 if (unlikely(sheaf->size == 0))
ec66e0d599520ab Vlastimil Babka 2025-09-03 5992 goto empty;
ec66e0d599520ab Vlastimil Babka 2025-09-03 5993
ec66e0d599520ab Vlastimil Babka 2025-09-03 5994 /*
ec66e0d599520ab Vlastimil Babka 2025-09-03 5995 * Checking nr_full/nr_empty outside lock avoids contention in case the
ec66e0d599520ab Vlastimil Babka 2025-09-03 5996 * barn is at the respective limit. Due to the race we might go over the
ec66e0d599520ab Vlastimil Babka 2025-09-03 5997 * limit but that should be rare and harmless.
ec66e0d599520ab Vlastimil Babka 2025-09-03 5998 */
ec66e0d599520ab Vlastimil Babka 2025-09-03 5999
ec66e0d599520ab Vlastimil Babka 2025-09-03 6000 if (data_race(barn->nr_full) < MAX_FULL_SHEAVES) {
ec66e0d599520ab Vlastimil Babka 2025-09-03 6001 stat(s, BARN_PUT);
ec66e0d599520ab Vlastimil Babka 2025-09-03 6002 barn_put_full_sheaf(barn, sheaf);
cb8be1e8cd9f603 Harry Yoo (Oracle 2026-04-21 6003) local_unlock(&s->cpu_sheaves->lock);
ec66e0d599520ab Vlastimil Babka 2025-09-03 6004 return;
ec66e0d599520ab Vlastimil Babka 2025-09-03 6005 }
ec66e0d599520ab Vlastimil Babka 2025-09-03 6006
ec66e0d599520ab Vlastimil Babka 2025-09-03 6007 stat(s, BARN_PUT_FAIL);
ec66e0d599520ab Vlastimil Babka 2025-09-03 6008 sheaf_flush_unused(s, sheaf);
ec66e0d599520ab Vlastimil Babka 2025-09-03 6009
ec66e0d599520ab Vlastimil Babka 2025-09-03 6010 empty:
fd6db58867924d2 Vlastimil Babka 2025-10-11 6011 if (barn && data_race(barn->nr_empty) < MAX_EMPTY_SHEAVES) {
ec66e0d599520ab Vlastimil Babka 2025-09-03 6012 barn_put_empty_sheaf(barn, sheaf);
cb8be1e8cd9f603 Harry Yoo (Oracle 2026-04-21 6013) local_unlock(&s->cpu_sheaves->lock);
ec66e0d599520ab Vlastimil Babka 2025-09-03 6014 return;
ec66e0d599520ab Vlastimil Babka 2025-09-03 6015 }
ec66e0d599520ab Vlastimil Babka 2025-09-03 6016
cb8be1e8cd9f603 Harry Yoo (Oracle 2026-04-21 6017) local_unlock(&s->cpu_sheaves->lock);
cb8be1e8cd9f603 Harry Yoo (Oracle 2026-04-21 6018) free_empty_sheaf(s, sheaf);
cb8be1e8cd9f603 Harry Yoo (Oracle 2026-04-21 6019) return;
cb8be1e8cd9f603 Harry Yoo (Oracle 2026-04-21 6020)
cb8be1e8cd9f603 Harry Yoo (Oracle 2026-04-21 6021) flush_unlocked:
cb8be1e8cd9f603 Harry Yoo (Oracle 2026-04-21 6022) stat(s, BARN_PUT_FAIL);
cb8be1e8cd9f603 Harry Yoo (Oracle 2026-04-21 6023) sheaf_flush_unused(s, sheaf);
ec66e0d599520ab Vlastimil Babka 2025-09-03 6024 free_empty_sheaf(s, sheaf);
ec66e0d599520ab Vlastimil Babka 2025-09-03 6025 }
ec66e0d599520ab Vlastimil Babka 2025-09-03 6026
:::::: The code at line 5985 was first introduced by commit
:::::: fd6db58867924d2bfbc4ece4b0092f697f9fc31c slab: fix barn NULL pointer dereference on memoryless nodes
:::::: TO: Vlastimil Babka <vbabka@suse.cz>
:::::: CC: Vlastimil Babka <vbabka@suse.cz>
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
reply other threads:[~2026-05-03 0: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=202605030847.0BApbpIn-lkp@intel.com \
--to=lkp@intel.com \
--cc=harry@kernel.org \
--cc=llvm@lists.linux.dev \
--cc=oe-kbuild-all@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.