[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191115083813.65f5523c@gandalf.local.home>
Date: Fri, 15 Nov 2019 08:38:13 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Greg KH <gregkh@...uxfoundation.org>, yu kuai <yukuai3@...wei.com>,
rafael@...nel.org, oleg@...hat.com, mchehab+samsung@...nel.org,
corbet@....net, tytso@....edu, jmorris@...ei.org,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
zhengbin13@...wei.com, yi.zhang@...wei.com,
chenxiang66@...ilicon.com, xiexiuqi@...wei.com
Subject: Re: [PATCH 1/3] dcache: add a new enum type for
'dentry_d_lock_class'
On Fri, 15 Nov 2019 13:16:25 +0000
Al Viro <viro@...iv.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
Powered by blists - more mailing lists