On Tue, 31 Jul 2018, Andrey Ryabinin wrote: > Guys, it seems that we have a lot of code using SLAB_TYPESAFE_BY_RCU cache without constructor. > I think it's nearly impossible to use that combination without having bugs. > It's either you don't really need the SLAB_TYPESAFE_BY_RCU, or you need to have a constructor in kmem_cache. > > Could you guys, please, verify your code if it's really need SLAB_TYPSAFE or constructor? > > E.g. the netlink code look extremely suspicious: > > /* > * Do not use kmem_cache_zalloc(), as this cache uses > * SLAB_TYPESAFE_BY_RCU. > */ > ct = kmem_cache_alloc(nf_conntrack_cachep, gfp); > if (ct == NULL) > goto out; > > spin_lock_init(&ct->lock); > > If nf_conntrack_cachep objects really used in rcu typesafe manner, than 'ct' returned by kmem_cache_alloc might still be > in use by another cpu. So we just reinitialize spin_lock used by someone else? ct may still be read by another cpu in a RCU section but the object was freed elsewhere so no other processor may modify the object. The lock must have been released before freeing the slab object and thus the initialization of the spinlock is unnecessary if it was initialized in ctor. If there is refcounting going on then why use SLAB_TYPESAFE_BY_RCU? -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
