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

[yukuai (C)]

在 2019/11/15 9:53, Steven Rostedt 写道:
> On Fri, 15 Nov 2019 09:47:38 +0800
> "yukuai (C)" <yukuai3@xxxxxxxxxx> wrote:
>
> > 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).
>
> It sounds fine to me, but I think the decision needs to be with the
> debugfs and vfs maintainers.
>
> -- Steve
>
> .
Thank you very much! I'll have a try.
Yu Kuai