[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v2 03/47] mm: shrinker: add infrastructure for dynamically allocating shrinker
Hi Peter, On 2023/7/24 20:25, Peter Zijlstra wrote: On Mon, Jul 24, 2023 at 05:43:10PM +0800, Qi Zheng wrote:+void shrinker_unregister(struct shrinker *shrinker) +{ + struct dentry *debugfs_entry; + int debugfs_id; + + if (!shrinker || !(shrinker->flags & SHRINKER_REGISTERED)) + return; + + down_write(&shrinker_rwsem); + list_del(&shrinker->list); + shrinker->flags &= ~SHRINKER_REGISTERED; + if (shrinker->flags & SHRINKER_MEMCG_AWARE) + unregister_memcg_shrinker(shrinker); + debugfs_entry = shrinker_debugfs_detach(shrinker, &debugfs_id); + up_write(&shrinker_rwsem); + + shrinker_debugfs_remove(debugfs_entry, debugfs_id);Should there not be an rcu_barrier() right about here? The shrinker_debugfs_remove() will wait for debugfs_file_put() to return, so when running here, all shrinker debugfs operations have been completed. And the slab shrink will hold the read lock of shrinker_rwsem to traverse the shrinker_list, so when we hold the write lock of shrinker_rwsem to delete the shrinker from the shrinker_list, the shrinker will not be executed again. So I think there is no need to add a rcu_barrier() here. Please let me know if I missed something. Thanks, Qi + + kfree(shrinker->nr_deferred); + shrinker->nr_deferred = NULL; + + kfree(shrinker); +} +EXPORT_SYMBOL(shrinker_unregister);
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |