From mboxrd@z Thu Jan 1 00:00:00 1970 From: Qi Zheng Date: Tue, 25 Jul 2023 11:01:06 +0800 Subject: [Cluster-devel] [PATCH v2 03/47] mm: shrinker: add infrastructure for dynamically allocating shrinker In-Reply-To: <20230724122549.GA3731903@hirez.programming.kicks-ass.net> References: <20230724094354.90817-1-zhengqi.arch@bytedance.com> <20230724094354.90817-4-zhengqi.arch@bytedance.com> <20230724122549.GA3731903@hirez.programming.kicks-ass.net> Message-ID: <9b149dd9-1617-9af4-4252-6d0df01f93b1@bytedance.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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); >