linux-kernel - [PATCH][RFC] debugfs: dont stop on first failed recursive delete

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>] [day] [month] [year] [list]

Date:	Sat, 25 Apr 2009 00:39:40 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	LKML <linux-kernel@...r.kernel.org>
cc:	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>, gregkh@...ah.com
Subject: [PATCH][RFC] debugfs: dont stop on first failed recursive delete


The following patch is in:

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git

    branch: rfc/debugfs


Steven Rostedt (1):
      debugfs: dont stop on first failed recursive delete

----
 fs/debugfs/inode.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)
---------------------------
commit 2f1680c7a8a9e974ad22b4b145ef7724a76d0e1f
Author: Steven Rostedt <srostedt@...hat.com>
Date:   Sat Apr 25 00:26:51 2009 -0400

    debugfs: dont stop on first failed recursive delete
    
    While running a while loop of removing a module that removes a debugfs
    directory with debugfs_remove_recursive, and at the same time doing a
    while loop of cat of a file in that directory, I would hit a point where
    somehow the cat of the file caused the remove to fail.
    
    The result is that other files did not get removed when the module
    was removed. I simple read of one of those file can oops the kernel
    because the operations to the file no longer exist (removed by module).
    
    The funny thing is that the file being cat'ed was removed. It was
    the siblings that were not. I see in the code to debugfs_remove_recursive
    there's a test that checks if the child fails to bail out of the loop
    to prevent an infinite loop.
    
    What this patch does is to still try any siblings in that directory.
    If all the siblings fail, or there are no more siblings, then we exit
    the loop.
    
    This fixes the above symptom, but...
    
    This is no full proof. It makes the debugfs_remove_recursive a bit more
    robust, but it does not explain why the one file failed. There may
    be some kind of delay deletion that makes the debugfs think it did
    not succeed. So this patch is more of a fix for the symptom but not
    the disease.
    
    This patch still makes the debugfs_remove_recursive more robust and
    until I can find out why the bug exists, this patch will keep
    the kernel from oopsing in most cases.  Even after the cause is found
    I think this change can stand on its own and should be kept.
    
    [ Impact: prevent kernel oops on module unload and reading debugfs files ]
    
    Cc: Greg KH <greg@...ah.com>
    Signed-off-by: Steven Rostedt <rostedt@...dmis.org>

diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index 0662ba6..d22438e 100644
--- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@ -403,6 +403,7 @@ void debugfs_remove_recursive(struct dentry *dentry)
 		}
 		child = list_entry(parent->d_subdirs.next, struct dentry,
 				d_u.d_child);
+ next_sibling:
 
 		/*
 		 * If "child" isn't empty, walk down the tree and
@@ -417,6 +418,16 @@ void debugfs_remove_recursive(struct dentry *dentry)
 		__debugfs_remove(child, parent);
 		if (parent->d_subdirs.next == &child->d_u.d_child) {
 			/*
+			 * Try the next sibling.
+			 */
+			if (child->d_u.d_child.next != &parent->d_subdirs) {
+				child = list_entry(child->d_u.d_child.next,
+						   struct dentry,
+						   d_u.d_child);
+				goto next_sibling;
+			}
+
+			/*
 			 * Avoid infinite loop if we fail to remove
 			 * one dentry.
 			 */

--
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/