On Mon, Jan 28, 2019 at 09:28:36AM +0100, Dmitry Vyukov wrote: > > > Weird, this is the kfree() on the error path of br_multicast_new_group() > > when rhashtable_lookup_insert_fast() fails, which means the entry should > > not be linked in the rhashtable or the hlist. > > All other frees are via kfree_rcu. I'll keep looking.. > > Humm.... +rhashtable.c maintianers > > The code in br_multicast_new_group is effectively: > > mp = kzalloc(sizeof(*mp), GFP_ATOMIC); > err = rhashtable_lookup_insert_fast(&br->mdb_hash_tbl, &mp->rhnode, > br_mdb_rht_params); > if (err) > kfree(mp); > > So it looks like rhashtable_lookup_insert_fast both returned an error > and left the new object linked in the table. Since it happened only > once, it may have something to do with concurrent resizing/shrinking. I've looked through the rhashtable code in question and everything looks OK. So I suspect some earlier corruption has occured to cause this anomalous result. Is it possible to collect earlier alloc/free stack traces on the object in question? Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
