Re: [PATCH v3] mm/slab_common: Deleting kobject in kmem_cache_destroy() without holding slab_mutex/cpu_hotplug_lock

[Waiman Long]

On 8/23/22 07:33, Vlastimil Babka wrote:
> On 8/12/22 20:30, 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>
> Thanks, added to slab.git for-6.0/fixes

Thanks for taking it.

Cheers,
Longman