[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <916bea8e-0e79-c561-f8e8-b3c7fa026161@gentwo.org>
Date: Mon, 7 Oct 2024 09:00:15 -0700 (PDT)
From: "Christoph Lameter (Ampere)" <cl@...two.org>
To: Hyeonggon Yoo <42.hyeyoo@...il.com>
cc: Vlastimil Babka <vbabka@...e.cz>, "yuan.gao" <yuan.gao@...oud.cn>,
penberg@...nel.org, rientjes@...gle.com, iamjoonsoo.kim@....com,
akpm@...ux-foundation.org, roman.gushchin@...ux.dev, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] mm/slub: Avoid list corruption when removing a slab
from the full list
On Tue, 8 Oct 2024, Hyeonggon Yoo wrote:
> > Is it possible to determine which commit introduced this issue, for a
> > stable cc?
>
> By code inspection I suspect it's around when SLUB's first introduced in 2007,
> more specifically commit 643b113849d8 ("slub: enable tracking of full slabs").
> Even v2.6 kernels do not seem to handle this case correctly.
Yes this is an error that was there in the beginning. Its a rare
condition that only occurs when debugging is enabled so its difficult to
trigger IRL.
> > Also in addition to what Hyeonggon proposed, we should perhaps mark
> > these consistency-failed slabs in a way that further freeing of objects
> > in them will also don't actually free anything, and thus not move the
> > slab back from full to partial list for further reuse.
>
> Yeah I was thinking of that too.
>
Right. Stop any processing on the slab page with metadata corruption.
Powered by blists - more mailing lists