Re: [PATCH 0/6] tracing: open/delete fixes

[Oleg Nesterov]

On 07/24, Oleg Nesterov wrote:
>
> On 07/23, Oleg Nesterov wrote:
> >
> > Will try to test tomorrow.
>
> Well, it seems to work "as expected",

Yes. And so far I think it is fine.

> but I forgot about debugfs
> problems.

And yes. We still have the problems with "Failed to create system
directory" if subsytem was removed while someone keeps the file
opened.

BUT: so far I think this is another and unrelated problem, see
below.

> This makes me think again that perhaps
> the subsystem logic is not correct, but probably I misunderstood
> it for the 2nd time.

Damn yes, I misread this code again.

Now I am almost sure fs/debugfs is wrong. At least it doesn't match
my expectations ;)

Suppose we have

	dir1/
		file1
		dir2/
			file2

somewhere in debugfs.

Suppose that someone opens dir1/dir2/file2.

Now. debugfs_remove_recursive(dir1/dir2) succeeds, and dir1/di2 goes
away.

But debugfs_remove_recursive(dir1) silently fails and doesn't remove
this directory. It relies on list_empty(d_subdirs) and this doesn't
look right.

If nothing else, note that simple_empty() doesn't blindly return
list_empty(d_subdirs), this list still have the deleted nodes.

The patch below fixes the problem, but I do not think it is really
correct, I'll try to think more.

Oleg.

--- a/fs/debugfs/inode.c~	2013-03-20 12:54:00.000000000 +0100
+++ b/fs/debugfs/inode.c	2013-07-25 18:31:46.000000000 +0200
@@ -566,7 +579,7 @@ void debugfs_remove_recursive(struct den
 		 * If "child" isn't empty, walk down the tree and
 		 * remove all its descendants first.
 		 */
-		if (!list_empty(&child->d_subdirs)) {
+		if (debugfs_positive(child) && !list_empty(&child->d_subdirs)) {
 			mutex_unlock(&parent->d_inode->i_mutex);
 			parent = child;
 			mutex_lock(&parent->d_inode->i_mutex);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/