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