All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Alexander Z Lam <azl@google.com>,
	Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
	David Sharp <dhsharp@google.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
	Vaibhav Nagarnaik <vnagarnaik@google.com>,
	"zhangwei(Jovi)" <jovi.zhangwei@huawei.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Re: PATCH? debugfs_remove_recursive() must not rely on list_empty(d_subdirs)
Date: Fri, 26 Jul 2013 19:24:10 +0900	[thread overview]
Message-ID: <51F24E4A.3080803@hitachi.com> (raw)
In-Reply-To: <20130725200423.GA22274@redhat.com>

(2013/07/26 5:04), Oleg Nesterov wrote:
> On 07/25, Oleg Nesterov wrote:
>>
>> To simplify the review, this is how it looks with the patch applied:
> 
> v2. We can use simply use list_for_each_entry_safe() and
> list_next_entry() should be calles under ->i_mutex. Although
> debugfs_remove_recursive() can race with itself anyway, but
> still.
> 
> And the code looks much simpler. But I do not know what did
> I miss.
> 
> Oleg.
> 
> void debugfs_remove_recursive(struct dentry *dentry)
> {
> 	struct dentry *child, *next, *parent;
> 
> 	if (IS_ERR_OR_NULL(dentry))
> 		return;
> 
> 	parent = dentry->d_parent;
> 	if (!parent || !parent->d_inode)
> 		return;
> 
> 	parent = dentry;
>  down:
> 	mutex_lock(&parent->d_inode->i_mutex);
> 	list_for_each_entry_safe(child, next, &parent->d_subdirs, d_u.d_child) {

Perhaps, you can use list_for_each_entry_safe_continue() here, as below.

	parent = dentry;
down:
	child = list_first_entry_or_null(&parent->d_subdirs,
					 typeof(*child), d_u.d_child);
	mutex_lock(&parent->d_inode->i_mutex);

restart:
	list_for_each_entry_safe_continue(child, next, &parent->d_subdirs, d_u.d_child) {

> 		if (!debugfs_positive(child))
> 			continue;
> 
> 		/* XXX: simple_empty(child) instead ? */
> 		if (!list_empty(&child->d_subdirs)) {
> 			mutex_unlock(&parent->d_inode->i_mutex);
> 			parent = child;
> 			goto down;
> 		}
>  up:
> 		__debugfs_remove(child, parent);
> 	}

Then, you can avoid jumping into the loop, just restart it from
parent as below.

	mutex_unlock(&parent->d_inode->i_mutex);

	child = parent;
	parent = parent->d_parent;
	mutex_lock(&parent->d_inode->i_mutex);
	__debugfs_remove(child, parent);

	if (child != dentry)
		goto restart;

> 	mutex_unlock(&parent->d_inode->i_mutex);
> 	simple_release_fs(&debugfs_mount, &debugfs_mount_count);
> }

It's just an idea, which came up to my mind. :)

Thank you,

-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com



  parent reply	other threads:[~2013-07-26 10:24 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-23 20:58 [PATCH 0/6] tracing: open/delete fixes Oleg Nesterov
2013-07-23 20:59 ` [PATCH 1/6] tracing: Turn event/id->i_private into call->event.type Oleg Nesterov
2013-07-24 20:13   ` Steven Rostedt
2013-07-25 14:26     ` Oleg Nesterov
2013-07-23 20:59 ` [PATCH 2/6] tracing: Change event_enable/disable_read() to verify i_private != NULL Oleg Nesterov
2013-07-24 19:37   ` Steven Rostedt
2013-07-23 20:59 ` [PATCH 3/6] tracing: Change event_filter_read/write " Oleg Nesterov
2013-07-24 19:52   ` Steven Rostedt
2013-07-23 20:59 ` [PATCH 4/6] tracing: Change f_start() to take event_mutex and " Oleg Nesterov
2013-07-23 20:59 ` [PATCH 5/6] tracing: Introduce remove_event_file_dir() Oleg Nesterov
2013-07-24 20:01   ` Steven Rostedt
2013-07-23 20:59 ` [PATCH 6/6] tracing: Change remove_event_file_dir() to clear "d_subdirs"->i_private Oleg Nesterov
2013-07-24 20:08   ` Steven Rostedt
2013-07-25 14:18     ` Oleg Nesterov
2013-07-24 18:46 ` [PATCH 0/6] tracing: open/delete fixes Oleg Nesterov
2013-07-25 16:56   ` Oleg Nesterov
2013-07-25 19:27   ` PATCH? debugfs_remove_recursive() must not rely on list_empty(d_subdirs) Oleg Nesterov
2013-07-25 20:04     ` Oleg Nesterov
2013-07-25 23:43       ` Greg Kroah-Hartman
2013-07-26 15:11         ` [PATCH 0/1] debugfs: " Oleg Nesterov
2013-07-26 15:12           ` Oleg Nesterov
2013-07-26 15:14             ` Oleg Nesterov
2013-07-26 15:12           ` [PATCH 1/1] " Oleg Nesterov
2013-07-26 17:38             ` Greg Kroah-Hartman
2013-07-26 18:40               ` Steven Rostedt
2013-07-26 15:30           ` [PATCH 0/1] " Steven Rostedt
2013-07-26 16:28             ` Greg Kroah-Hartman
2013-07-26 17:38             ` Greg Kroah-Hartman
2013-07-26 10:24       ` Masami Hiramatsu [this message]
2013-07-26 14:49         ` Re: PATCH? " Oleg Nesterov

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=51F24E4A.3080803@hitachi.com \
    --to=masami.hiramatsu.pt@hitachi.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@ghostprotocols.net \
    --cc=azl@google.com \
    --cc=dhsharp@google.com \
    --cc=fweisbec@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jovi.zhangwei@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=vnagarnaik@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.