linux-kernel - Re: [RFC] Hack to use mkdir/rmdir in debugfs

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: <1358915495.21576.102.camel@gandalf.local.home>
Date:	Tue, 22 Jan 2013 23:31:35 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC] Hack to use mkdir/rmdir in debugfs

On Tue, 2013-01-22 at 20:08 -0800, Greg Kroah-Hartman wrote:

> > Is doing something as silly as the following fine, or is there a better
> > way?
> 
> Yes, why not create your own fs for ftrace?  :)

But but but...

debugfs is soooo convenient!

Do you think it would be worth doing that though? I only need the mkdir
and rmdir for this one instance. Nothing more.

> >	mutex_unlock(&inode->i_mutex);
> > 
> > 	ret = new_instance_create(dentry->d_iname);
> > 
> > 	mutex_lock(&inode->i_mutex);
> > 

> But how can you callback to your code to let it know that something was
> created in it?

I pass the dentry->d_iname to create a directory.

> 
> Don't you need that for both mkdir and rmdir?

It's a global list. It's very specific and doesn't need to be robust. It
all deals with modifying one global parameter. Not that hard. And I've
already implemented this. It works quite well :-)

> 
> But again, I'd really not want to do this in debugfs, how about your own
> filesystem?

I will note that this never modifies the debugfs code. But it does
circumvent it. That is, all this code lives in kernel/trace/trace.c. I
don't modify any of the debugfs code. I just replace the debugfs
dentry->d_inode->i_op with my own ops.

I can create my own fs, but that just seems to be overkill. The only
difference is that I need mkdir and rmdir for this one instance.

That said, perhaps it wouldn't be too hard to create a ftracefs. Where
should it go? fs/ftrace or perhaps kernel/trace/fs ?

I notice that I only use:

debugfs_create_file()
debugfs_remove();
debugfs_create_dir();
debugfs_remove_recursive();
debugfs_initialized()

so maybe it wouldn't be such a far fetch thing to implement.

But then would I be able to still mount it in /debug/tracing ? As this
is where everything currently uses it? But then we need to teach admins
to add it there, or someplace else. /sys/kernel/ftrace?

Tools like trace-cmd and perf already expect it to be in the debugfs
tracing directory, and will automate mounting it to /sys/kernel/debug/
if not found. This may break userspace if I make another fs.

-- Steve

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