Messages in this thread | | | Subject | Re: [PATCH] debugfs: fix potential infinite loop in debugfs_remove_recursive | From | "yukuai (C)" <> | Date | Fri, 15 Nov 2019 09:47:38 +0800 |
| |
On 2019/11/14 22:34, Steven Rostedt wrote: > On Thu, 14 Nov 2019 14:59:04 +0800 > "yukuai (C)" <yukuai3@huawei.com> wrote: > >>> Have you tried this patch with lockdep enabled and tried to hit this >>> code path? >>> > >>> >> You are right, I get the results with lockdep enabled: > > That was what I was afraid of :-( > >> [ 64.314748] ============================================ >> [ 64.315568] WARNING: possible recursive locking detected >> [ 64.316549] 5.4.0-rc7-dirty #5 Tainted: G O >> [ 64.317398] -------------------------------------------- >> [ 64.318230] rmmod/2607 is trying to acquire lock: > >> >> The warning will disappeare by adding >> lockdep_set_novalidate_class(&child->d_lock) before calling >> simple_empty(child). But I'm not sure It's the right modfication. > > I'm wondering if we should add a simple_empty_unlocked() that does > simple_empty() without taking the lock, to allow us to call > spin_lock_nested() on the child. Of course, I don't know how much > nesting we allow as it calls the nesting too. Do you think we can do this: 1. add a new enum type for dentry_d_lock_class: enum dentry_d_lock_class { DENTRY_D_LOCK_NORMAL, /* implicitly used by plain spin_lock() APIs. */ DENTRY_D_LOCK_NESTED DENTRY_D_LOCK_NESTED_1 /* maybe another name */ }; 2. use the new enum type in simple_empty int simple_empty(struct dentry *dentry) { spin_lock(&dentry->d_lock, DENTRY_D_LOCK_NESTED); list_for_each_entry(child, &dentry->d_subdirs, d_child) { spin_lock_nested(&child->d_lock, DENTRY_D_LOCK_NESTED_1); }
If you agree, I'll try to send a patch or patchset(with modification in debugfs_remove_recursive).
Thanks! Yu Kuai
| |