Re: rtmutex deadlock and memory corruption when running gcc testsuite in next-20260303

From: Bert Karwatzki

Date: Wed Mar 04 2026 - 15:45:18 EST


Am Mittwoch, dem 04.03.2026 um 15:15 +0100 schrieb Vlastimil Babka (SUSE):
> On 3/3/26 11:21 PM, Bert Karwatzki wrote:
> > I tried building gcc-14 from the debian repositories (fetched via apt-get
> > source gcc-14) on my new and shiny zen5 machine (Cpu: "AMD Ryzen 9 9950X
> > 16-Core Processor) running debian stable/trixie and linux-next-20260303
> > (PREEMPT_RT=y) with the following command:
>
> It's probably my fault, sorry about that.
> Specifically commit 666a739089c from slab/for-next-fixes.
> Does the following fix it? The fixed commit was meanwhile
> queued so hopefully will be in next-20260304
>
> diff --git a/mm/slub.c b/mm/slub.c
> index 740edbad0475..1871c5ef354a 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -4610,6 +4610,7 @@ __pcs_replace_empty_main(struct kmem_cache *s, struct slub_percpu_sheaves *pcs,
> }
>
> local_unlock(&s->cpu_sheaves->lock);
> + pcs = NULL;
>
> if (!allow_spin)
> return NULL;
>
>

Yes, this seem to fix the issue (two testruns without errors). So the problem was __pcs_replace_empty_main()
returning a non-NULL pcs in the case where it can't take the lock (&s->cpu_sheaves->lock) and jumps to
barn_put:.

Bert Karwatzki