On Tue, 13 Apr 2021, Gong, Sishuai wrote: > We found a racy reading spot on shared variable n->free_objects in > slab.c and it can be data-racing with several writers that update this > variable. As shown below, in function cache_alloc_refill(), > n->free_objects will be read without any protection. It could be > possible that the read value immediately becomes out-of-date when > another writer is changing it (e.g. free_block()) Ok that is fine. If we mistakenly fill up the per cpu cache with new objects to the slab then so be it. If we mistakenly take the lock and fail to get an object then we can still reverse that decision and do the other thing. Maybe we need to add a comment there?
