linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: "yukuai (C)" <yukuai3@huawei.com>
Cc: <gregkh@linuxfoundation.org>, <rafael@kernel.org>,
	<oleg@redhat.com>, <jack@suse.cz>, <linux-kernel@vger.kernel.org>,
	<zhengbin13@huawei.com>, <yi.zhang@huawei.com>,
	<chenxiang66@hisilicon.com>, <xiexiuqi@huawei.com>
Subject: Re: [PATCH] debugfs: fix potential infinite loop in debugfs_remove_recursive
Date: Wed, 13 Nov 2019 21:43:07 -0500	[thread overview]
Message-ID: <20191113214307.29a8d001@oasis.local.home> (raw)
In-Reply-To: <a399ae58-a467-3ff9-5a01-a4a2cdcf4fd6@huawei.com>

On Thu, 14 Nov 2019 10:01:23 +0800
"yukuai (C)" <yukuai3@huawei.com> wrote:


> Do you agree with that list_empty(&chile->d_subdirs) here is not 
> appropriate? Since it can't skip the subdirs that is not 
> simple_positive(simple_positive() will return false), which is the 
> reason of infinite loop.

I do agree that simple_empty() is wrong, for the reasons you pointed out.

> >> +		if (!simple_empty(child)) {  
> > 
> > Have you tried this with lockdep enabled? I'm thinking that you might
> > get a splat with holding parent->d_lock and simple_empty(child) taking
> > the child->d_lock.  
> The locks are taken and released in the right order:
> take parent->d_lock
> 	take child->d_lock
> 		list_for_each_entry(c, &child->d_sundirs, d_child)
> 			take c->d_lock
> 			release c->d_lock
> 	release child->d_lock
> release parent->d_lock
> I don't see anything wrong, am I missing something?

It should be fine, my worry is that we may be missing a lockdep
annotation, that might confuse lockdep, as lockdep may see this as the
same type of lock being taken, and wont know the order.

Have you tried this patch with lockdep enabled and tried to hit this
code path?

-- Steve

  reply	other threads:[~2019-11-14  2:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-31 13:34 [PATCH] debugfs: fix potential infinite loop in debugfs_remove_recursive yu kuai
2019-11-13 20:17 ` Steven Rostedt
2019-11-14  2:01   ` yukuai (C)
2019-11-14  2:43     ` Steven Rostedt [this message]
2019-11-14  3:20       ` yukuai (C)
2019-11-14  6:59       ` yukuai (C)
2019-11-14 14:34         ` Steven Rostedt
2019-11-15  1:47           ` yukuai (C)
2019-11-15  1:53             ` Steven Rostedt
2019-11-15  2:13               ` yukuai (C)
2019-11-15  1:57             ` yukuai (C)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191113214307.29a8d001@oasis.local.home \
    --to=rostedt@goodmis.org \
    --cc=chenxiang66@hisilicon.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=rafael@kernel.org \
    --cc=xiexiuqi@huawei.com \
    --cc=yi.zhang@huawei.com \
    --cc=yukuai3@huawei.com \
    --cc=zhengbin13@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).