Hi, 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()) Currently, we haven’t found any explicit errors due to this data race but we noticed 1) most of the reading spots on n->free_objects in slab.c have been protected by locks and 2) the racy result can affect the control flow, thus we want to point out this reader. ------------------------------------------ Execution interleaving Thread 1 (reader) Thread 2 (writer) cache_alloc_refill() free_block() shared = READ_ONCE(n->shared); if (!n->free_objects && (!shared || !shared->avail)) n->free_objects += nr_objects; // lock protected goto direct_grow; spin_lock(&n->list_lock); Thanks, Sishuai
