Re: PATCH? trace_remove_event_call() should fail if call is active
From: Masami Hiramatsu
Date: Thu Jul 04 2013 - 00:25:27 EST
(2013年07月04日 6:02), Steven Rostedt wrote:
>
On Wed, 2013年07月03日 at 21:17 +0200, Oleg Nesterov wrote:
>
>
> diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
>
> index 4888cb3..c23d41e 100644
>
> --- a/fs/debugfs/inode.c
>
> +++ b/fs/debugfs/inode.c
>
> @@ -475,6 +475,7 @@ static int __debugfs_remove(struct dentry *dentry, struct dentry *parent)
>
> kfree(dentry->d_inode->i_private);
>
> /* fall through */
>
> default:
>
> + dentry->d_inode->i_private = NULL;
>
> simple_unlink(parent->d_inode, dentry);
>
> break;
>
> }
>
>
Ah, I see what you are saying. If the file is being opened just as it is
>
being deleted, it can up the dentry refcount and prevent it from
>
actually being deleted at that point. :-p
Yeah, that's actually what I'd like to point out.,,
>
>
There's a slight race that we can get to the open call when the dentry
>
was deleted. But can it? Seems that there would be other places that
>
have issues as I would think it would be common to do something like:
>
>
data = kmalloc(size, GFP_KERNEL);
>
dentry = debugfs_create_file("file", 0644, parent, data, &ops);
>
>
[...]
>
>
debugfs_remove(dentry);
>
kfree(data);
>
>
Any thing like this would have issues if the open referenced the data.
I'm not so sure about vfs layer, but yes, I think that pattern may be
always unsafe. Perhaps, we need to wait the entry is surely removed
before freeing the data.
Thanks,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@xxxxxxxxxxx
--
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/