Re: [PATCH 2/3] mmc: Export ios settings for a host through debugfs

[Haavard Skinnemoen]

Greg KH <greg@xxxxxxxxx> wrote:
> Someone can add a "debugfs_rm_dentry_and_children" function if they so
> desire to handle this kind of thing if they want to :)

Ok, I'll try. I'm not an FS developer, so I'm sure the below patch is
horribly broken in some subtle way, but it does appear to work at least
the few times I tried it...

Lockdep indeed confirms that something is broken:

=============================================
[ INFO: possible recursive locking detected ]
2.6.26-rc8 #34
---------------------------------------------
rmmod/396 is trying to acquire lock:
 (&sb->s_type->i_mutex_key#2){--..}, at: [<900a4ab6>] debugfs_remove_recursive+0x2e/0xc0

but task is already holding lock:
 (&sb->s_type->i_mutex_key#2){--..}, at: [<900a4aa8>] debugfs_remove_recursive+0x20/0xc0

other info that might help us debug this:
1 lock held by rmmod/396:
 #0:  (&sb->s_type->i_mutex_key#2){--..}, at: [<900a4aa8>] debugfs_remove_recursive+0x20/0xc0

stack backtrace:
Call trace:
 [<90017018>] dump_stack+0x18/0x20
 [<900327ac>] __lock_acquire+0x6a0/0x964
 [<9003306c>] lock_acquire+0x38/0x4c
 [<90170130>] mutex_lock_nested+0x7c/0x18c
 [<900a4ab6>] debugfs_remove_recursive+0x2e/0xc0
 [<c0861c26>] mmc_remove_host+0x12/0x34 [mmc_core]
 [<c0857222>] atmci_remove+0x4a/0xd4 [atmel_mci]
 [<900d478a>] platform_drv_remove+0x10/0x12
 [<900d3cfc>] __device_release_driver+0x48/0x64
 [<900d3d74>] driver_detach+0x5c/0x7c
 [<900d34be>] bus_remove_driver+0x5a/0x70
 [<900d4054>] driver_unregister+0x24/0x28
 [<900d488e>] platform_driver_unregister+0xa/0xc
 [<c08571ce>] atmci_exit+0xa/0x14 [atmel_mci]
 [<90038086>] sys_delete_module+0x116/0x15c
 [<90013132>] syscall_return+0x0/0x12

But I don't know exactly what. Isn't it ok to take the inode lock in
parent -> child order?

Haavard