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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130725165628.GA12736@redhat.com>
Date:	Thu, 25 Jul 2013 18:56:28 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Steven Rostedt <rostedt@...dmis.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
Cc:	Alexander Z Lam <azl@...gle.com>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	David Sharp <dhsharp@...gle.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	Vaibhav Nagarnaik <vnagarnaik@...gle.com>,
	"zhangwei(Jovi)" <jovi.zhangwei@...wei.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/6] tracing: open/delete fixes

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/