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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux