On Sat, Jul 8, 2017 at 1:18 AM, Christoph Lameter <cl@xxxxxxxxx> wrote: > On Fri, 7 Jul 2017, Andrew Morton wrote: > >> On Fri, 7 Jul 2017 10:34:08 +0200 Alexander Potapenko <glider@xxxxxxxxxx> wrote: >> >> > --- a/mm/slub.c >> > +++ b/mm/slub.c >> > @@ -3389,8 +3389,8 @@ static int init_kmem_cache_nodes(struct kmem_cache *s) >> > return 0; >> > } >> > >> > - s->node[node] = n; >> > init_kmem_cache_node(n); >> > + s->node[node] = n; >> > } >> > return 1; >> > } >> >> If this matters then I have bad feelings about free_kmem_cache_nodes(): > > At creation time the kmem_cache structure is private and no one can run a > free operation. > >> Inviting a use-after-free? I guess not, as there should be no way >> to look up these items at this stage. > > Right. > >> Could the slab maintainers please take a look at these and also have a >> think about Alexander's READ_ONCE/WRITE_ONCE question? > > Was I cced on these? I've asked Andrew about READ_ONCE privately. My concern is as follows. Since unfreeze_partials() sees uninitialized value of n->list_lock, I was suspecting there's a data race between unfreeze_partials() and init_kmem_cache_nodes(). If so, reads and writes to s->node[node] must be acquire/release atomics (not actually READ_ONCE/WRITE_ONCE, but smp_load_acquire/smp_store_release). -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Straße, 33 80636 München Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href
