lkml.org 
[lkml]   [2022]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 1/3] mm/slub: fix the race between validate_slab and slab_free
From
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.

\
 
 \ /
  Last update: 2022-06-03 05:36    [W:0.212 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site