A racy reading spot on n->free_objects in slab.c

["Gong, Sishuai" <sishuai@purdue.edu>]

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