From: Steven Rostedt <rostedt@goodmis.org>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Greg KH <gregkh@linuxfoundation.org>,
yu kuai <yukuai3@huawei.com>,
rafael@kernel.org, oleg@redhat.com, mchehab+samsung@kernel.org,
corbet@lwn.net, tytso@mit.edu, jmorris@namei.org,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
zhengbin13@huawei.com, yi.zhang@huawei.com,
chenxiang66@hisilicon.com, xiexiuqi@huawei.com
Subject: Re: [PATCH 1/3] dcache: add a new enum type for 'dentry_d_lock_class'
Date: Fri, 15 Nov 2019 08:38:13 -0500 [thread overview]
Message-ID: <20191115083813.65f5523c@gandalf.local.home> (raw)
In-Reply-To: <20191115131625.GO26530@ZenIV.linux.org.uk>
On Fri, 15 Nov 2019 13:16:25 +0000
Al Viro <viro@zeniv.linux.org.uk> wrote:
> I want to understand the overall situation. No argument, list_empty()
> in there is BS, for many reasons. But I wonder if trying to keep the
> current structure of the iterator _and_ the use of simple_rmdir()/simple_unlink()
> is the right approach.
My guess is that debugfs was written to be as simple as possible.
Nothing too complex. And in doing so, may have issues as you are
pointing out. Just a way to allow communications between user space and
kernel space (as tracefs started out).
BTW, what do you mean by "can debugfs_remove_recursive() rely upon the
lack of attempts to create new entries inside the subtree it's trying
to kill?"
-- Steve
next prev parent reply other threads:[~2019-11-15 13:38 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-15 3:27 [PATCH 0/3] fix potential infinite loop in debugfs_remove_recursive yu kuai
2019-11-15 3:27 ` [PATCH 1/3] dcache: add a new enum type for 'dentry_d_lock_class' yu kuai
2019-11-15 3:27 ` Greg KH
2019-11-15 4:12 ` Al Viro
2019-11-15 7:20 ` Greg KH
2019-11-15 10:08 ` yukuai (C)
2019-11-15 13:16 ` Al Viro
2019-11-15 13:38 ` Steven Rostedt [this message]
2019-11-15 13:39 ` Steven Rostedt
2019-11-15 13:48 ` Al Viro
2019-11-15 13:58 ` Steven Rostedt
2019-11-15 14:17 ` Al Viro
2019-11-15 17:54 ` Al Viro
2019-11-15 18:42 ` [RFC] simple_recursive_removal() Al Viro
2019-11-15 19:41 ` Al Viro
2019-11-15 21:18 ` Al Viro
2019-11-15 21:26 ` Steven Rostedt
2019-11-15 22:10 ` Al Viro
2019-11-16 12:04 ` Greg KH
2019-11-17 22:24 ` Al Viro
2019-11-18 6:37 ` Greg KH
2019-11-15 10:02 ` [PATCH 1/3] dcache: add a new enum type for 'dentry_d_lock_class' yukuai (C)
2019-11-15 3:27 ` [PATCH 2/3] fs/libfs.c: use 'spin_lock_nested' when taking 'd_lock' for dentry in simple_empty yu kuai
2019-11-15 3:27 ` [PATCH 3/3] debugfs: fix potential infinite loop in debugfs_remove_recursive yu kuai
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=20191115083813.65f5523c@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=chenxiang66@hisilicon.com \
--cc=corbet@lwn.net \
--cc=gregkh@linuxfoundation.org \
--cc=jmorris@namei.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab+samsung@kernel.org \
--cc=oleg@redhat.com \
--cc=rafael@kernel.org \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
--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).