lkml.org 
[lkml]   [2013]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Subject[RFC] Hack to use mkdir/rmdir in debugfs
From
Date
Let me explain the situation.

I'm adding the ability to create multiple ftrace instances (buffers). I
have a directory: /debug/tracing/instances that will hold sub
directories that have the control files for these buffers. Basically,
each directory in the instances directory will be a duplicate of
the /debug/tracing directory, and will act agnostic from each other.

I original had:

# ls /debug/tracing/instances
new free

Where to create an instance you had to echo the name of the instance
into the "new" file and it would be created:

# cd /debug/tracing/instances
# echo foo > new

# ls
new foo free

# ls foo
buffer_size_kb free_buffer trace_clock trace_pipe
buffer_total_size_kb set_event trace_marker tracing_on
events trace trace_options


And to remove it you would echo the name into the "free" file.

I find this interface rather awkward. A more elegant interface would be
to use mkdir and rmdir to create and remove these instances:

# cd /debug/traces/instances

# ls

# mkdir foo

# ls
foo


Unfortunately, the debugfs dir_inode_operations does not include a
mkdir. I decided to hijack the dir operations and install my own. But as
the mkdir needs to created debugfs directories with the instances
directory, they too will grab the i_node->i_mutex that is held by the
mkdir system call.

I finally did the following hack that works in my tests. But I'm a bit
uncomfortable and decided to call upon the VFS overlords to say this is
fine, or that I've must have stumbled upon a new kind of crack. Or maybe
this new crack is just fine.

I release the inode->i_mutex as the new_instance_create() has its own
locking to synchronize things and does the debugfs_create_dir() and
friends . Also, the instances directory is created at boot up and is
never destroyed, so I'm hoping that it's OK to release its i_mutex. I
even added a paranoid check to make sure it is the "instances"
directory. Note, the instances d_entry is saved as a static variable and
isn't needed to be recovered.

Is doing something as silly as the following fine, or is there a better
way?

----
static int instance_mkdir (struct inode *inode, struct dentry *dentry, umode_t mode)
{
struct dentry *parent;
int ret;

/* Paranoid: Make sure the parent is the "instances" directory */
parent = hlist_entry(inode->i_dentry.first, struct dentry, d_alias);
if (WARN_ON_ONCE(parent != trace_instance_dir))
return -ENOENT;

/*
* The inode mutex is locked, but debugfs_create_dir() will also
* take the mutex. As the instances directory can not be destroyed
* or changed in any other way, it is safe to unlock it, and
* let the dentry try. If two users try to make the same dir at
* the same time, then the new_instance_create() determine the
* winner.
*/
mutex_unlock(&inode->i_mutex);

ret = new_instance_create(dentry->d_iname);

mutex_lock(&inode->i_mutex);

return ret;
}

static const struct inode_operations instance_dir_inode_operations = {
.lookup = simple_lookup,
.mkdir = instance_mkdir,
};

static __init void create_trace_instances(struct dentry *d_tracer)
{
trace_instance_dir = debugfs_create_dir("instances", d_tracer);
if (WARN_ON(!trace_instance_dir))
return;

/* Hijack the dir inode operations, to allow mkdir */
trace_instance_dir->d_inode->i_op = &instance_dir_inode_operations;
}
----

As you can see, I haven't implemented the rmdir yet.

Thanks,

-- Steve




\
 
 \ /
  Last update: 2013-01-23 04:41    [W:0.081 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site