Messages in this thread | | | Date | Fri, 3 Jun 2022 11:35:30 +0800 | Subject | Re: [PATCH 1/3] mm/slub: fix the race between validate_slab and slab_free | From | Rongwei Wang <> |
| |
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.
| |