On Sat, Aug 16, 2025 at 11:31 AM Vlastimil Babka <[email protected]> wrote: > > On 8/16/25 8:31 PM, Vlastimil Babka wrote: > >> > >> I assume somehow the free_to_pcs_bulk() fallback case is taken, thus > >> calling __kmem_cache_free_bulk(), which calls free_to_pcs_bulk() ad > >> nauseam. > > Could it be a rebase gone wrong? Mine to 6.17-rc1 is here (but untested)
Yes Vlastimil, You're right. It is a rebase gone wrong. Thanks for catching this. I ported this patch series on top of v6.17-rc1 using b4 cmd b4 am -o - [email protected] | git am --reject For some reason b4 merging yielded me this: git show 893ee67b5c75e7411e4e3c6ddaa8d0765985423e slab: add opt-in caching layer of percpu sheaves @@ -5252,6 +6133,15 @@ static void __kmem_cache_free_bulk(struct kmem_cache *s, size_t size, void **p) if (!size) return; + /* + * freeing to sheaves is so incompatible with the detached freelist so + * once we go that way, we have to do everything differently + */ + if (s && s->cpu_sheaves) { + free_to_pcs_bulk(s, size, p); + return; + } + do { Whereas the original patch [1] had this instead: @@ -5033,6 +5801,15 @@ void kmem_cache_free_bulk(struct kmem_cache *s, size_t size, void **p) if (!size) return; + /* + * freeing to sheaves is so incompatible with the detached freelist so + * once we go that way, we have to do everything differently + */ + if (s && s->cpu_sheaves) { + free_to_pcs_bulk(s, size, p); + return; + } + I have no idea why b4 got confused between kmem_cache_free_bulk() and __kmem_cache_free_bulk(). After I fixed this issue, I'm able to boot the kernel successfully. [1] https://lore.kernel.org/all/[email protected]/ > > > > https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.git/ > > This branch specifically > https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.git/log/?h=b4/slub-percpu-sheaves
