Re: [PATCH 1/3] mm/slub: fix the race between validate_slab and slab_free

From: Rongwei Wang <rongwei.wang@linux.alibaba.com>
To: Christoph Lameter <cl@gentwo.de>,
	David Rientjes <rientjes@google.com>,
	songmuchun@bytedance.com, Hyeonggon Yoo <42.hyeyoo@gmail.com>
Cc: akpm@linux-foundation.org, vbabka@suse.cz,
	roman.gushchin@linux.dev, iamjoonsoo.kim@lge.com,
	penberg@kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] mm/slub: fix the race between validate_slab and slab_free
Date: Fri, 3 Jun 2022 11:35:30 +0800	[thread overview]
Message-ID: <9794df4f-3ffe-4e99-0810-a1346b139ce8@linux.alibaba.com> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2206021712530.2924@gentwo.de>

Hi, Christoph, David, Muchun and Hyeonggon

Thanks for your time.

Recently, I am also find other ways to solve this. That case was 
provided by Muchun is useful (Thanks Muchun!). Indeed, it seems that use 
n->list_lock here is unwise. Actually, I'm not sure if you recognize the 
existence of such race? If all agrees this race, then the next question 
may be: do we want to solve this problem? or as David said, it would be 
better to deprecate validate attribute directly. I have no idea about 
it, hope to rely on your experience.

In fact, I mainly want to collect your views on whether or how to fix 
this bug here. Thanks!

Thanks again for your time:).
-wrw

On 6/2/22 11:14 PM, Christoph Lameter wrote:
> On Mon, 30 May 2022, David Rientjes wrote:
> 
>>> Unconditionally taking n->list_lock will degrade performance.
>>
>> This is a good point, it would be useful to gather some benchmarks for
>> workloads that are known to thrash some caches and would hit this path
>> such as netperf TCP_RR.
> 
> Its obvious that adding new spinlocks to some of the hottest functions in
> the kernel will degrade performance. This goes against the basic design of
> these functions to be as efficient as possible.