Re: [PATCH] debugfs: fix potential infinite loop in debugfs_remove_recursive

From: yukuai (C)
Date: Thu Nov 14 2019 - 20:47:49 EST




On 2019/11/14 22:34, Steven Rostedt wrote:
On Thu, 14 Nov 2019 14:59:04 +0800
"yukuai (C)" <yukuai3@xxxxxxxxxx> 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