On Fri, 12 Aug 2022, Waiman Long wrote: > A circular locking problem is reported by lockdep due to the following > circular locking dependency. > > +--> cpu_hotplug_lock --> slab_mutex --> kn->active --+ > | | > +-----------------------------------------------------+ > > The forward cpu_hotplug_lock ==> slab_mutex ==> kn->active dependency > happens in > > kmem_cache_destroy(): cpus_read_lock(); mutex_lock(&slab_mutex); > ==> sysfs_slab_unlink() > ==> kobject_del() > ==> kernfs_remove() > ==> __kernfs_remove() > ==> kernfs_drain(): rwsem_acquire(&kn->dep_map, ...); > > The backward kn->active ==> cpu_hotplug_lock dependency happens in > > kernfs_fop_write_iter(): kernfs_get_active(); > ==> slab_attr_store() > ==> cpu_partial_store() > ==> flush_all(): cpus_read_lock() > > One way to break this circular locking chain is to avoid holding > cpu_hotplug_lock and slab_mutex while deleting the kobject in > sysfs_slab_unlink() which should be equivalent to doing a write_lock > and write_unlock pair of the kn->active virtual lock. > > Since the kobject structures are not protected by slab_mutex or the > cpu_hotplug_lock, we can certainly release those locks before doing > the delete operation. > > Move sysfs_slab_unlink() and sysfs_slab_release() to the newly > created kmem_cache_release() and call it outside the slab_mutex & > cpu_hotplug_lock critical sections. There will be a slight delay > in the deletion of sysfs files if kmem_cache_release() is called > indirectly from a work function. > > Signed-off-by: Waiman Long <longman@xxxxxxxxxx> Acked-by: David Rientjes <rientjes@xxxxxxxxxx>
