[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7a347d75-4df0-4591-b040-a832d3860a30@meta.com>
Date: Tue, 30 Jul 2024 08:03:36 -0400
From: Chris Mason <clm@...a.com>
To: Vlastimil Babka <vbabka@...e.cz>, Rik van Riel <riel@...riel.com>
Cc: Pekka Enberg <penberg@...nel.org>, Christoph Lameter <cl@...ux.com>,
Andrew Morton <akpm@...ux-foundation.org>, kernel-team@...a.com,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Joonsoo Kim <iamjoonsoo.kim@....com>,
David Rientjes <rientjes@...gle.com>,
kasan-dev <kasan-dev@...glegroups.com>, Jann Horn <jannh@...gle.com>
Subject: Re: [PATCH] mm,slub: do not call do_slab_free for kfence object
On 7/30/24 6:01 AM, Vlastimil Babka wrote:
> On 7/29/24 8:46 PM, Chris Mason wrote:
>>
>>
>> On 7/29/24 2:19 PM, Rik van Riel wrote:
>>> Reported-by: Chris Mason <clm@...a.com>
>>> Fixes: 782f8906f805 ("mm/slub: free KFENCE objects in slab_free_hook()")
>>> Cc: stable@...nel.org
>>> Signed-off-by: Rik van Riel <riel@...riel.com>
>>
>> We found this after bisecting a slab corruption down to the kfence
>> patch, and with this patch applied we're no longer falling over. So
>> thanks Rik!
>
> Indeed thanks and sorry for the trouble! Given that
> __kmem_cache_free_bulk is currently only used to unwind a
> kmem_cache_bulk_alloc() that runs out of memory in the middle of the
> operation, I'm surprised you saw this happen reliably enough to bisect it.
>
The repro was just forcing two sequential OOMs during iperf load on top
of mlx5 ethernet:
Test machine:
- iperf -s -V
Load generator:
- iperf -c test_machine -P 10 -w 1k -l 1k -V --time 900
Test machine:
- hog all memory until OOM
- Do it one more time
Since we didn't have memory corruptions on other nics, I was pretty sure
the bisect had gone wrong when all the remaining commits were in MM.
Nothing against our friends in networking, but MM bugs are usually
easier to fix, so I was pretty happy after confirming kfence as the cause.
> Added to slab/for-6.11-rc1/fixes
Thanks!
-chris
Powered by blists - more mailing lists