LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Ingo Molnar <mingo@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 00/16 v3] tracing: Add new file system tracefs
Date: Mon, 26 Jan 2015 21:40:20 +0000	[thread overview]
Message-ID: <20150126214020.GO29656@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20150126193049.GN29656@ZenIV.linux.org.uk>

On Mon, Jan 26, 2015 at 07:30:49PM +0000, Al Viro wrote:
> On Mon, Jan 26, 2015 at 10:09:13AM -0500, Steven Rostedt wrote:
> > There has been complaints that tracing is tied too much to debugfs,
> > as there are systems that would like to perform tracing, but do
> > not mount debugfs for security reasons. That is because any subsystem
> > may use debugfs for debugging, and these interfaces are not always
> > tested for security.
> > 
> > Creating a new tracefs that the tracing directory will now be attached
> > to allows system admins the ability to access the tracing directory
> > without the need to mount debugfs.
> > 
> > Another advantage is that debugfs does not support the system calls
> > for mkdir and rmdir. Tracing uses these system calls to create new
> > instances for sub buffers. This was done by a hack that hijacked the
> > dentry ops from the "instances" debugfs dentry, and replacing it with
> > one that could work.
> > 
> > Instead of using this hack, tracefs can provide a proper interface to
> > allow the tracing system to have a mkdir and rmdir feature.
> > 
> > To maintain backward compatibility with older tools that expect that
> > the tracing directory is mounted with debugfs, the tracing directory
> > is still created under debugfs and tracefs is automatically mounted
> > there.
> > 
> > Finally, a new directory is created when tracefs is enabled called
> > /sys/kernel/tracing. This will be the new location that system admins
> > may mount tracefs if they are not using debugfs.
> 
> You are still fighting an inconvenient API, but now it's not debugfs one -
> it's your copy thereof.  Why not give your instances/ an inode_operations
> of its own?  One with ->mkdir() and ->rmdir(), leaving all other directories
> as-is.  That way you don't need the secondary methods at all.  And sure,
> debugfs_create_dir() grabs ->i_mutex on parent, making you drop that in
> your ->mkdir() if you want to call it.  But now you are not talking to it -
> just to your own code, where you are free to change the calling conventions,
> making it caller's responsibility to get that ->i_mutex.  The same goes for
> the rmdir side...

Is the following correct?
	* only one directory in the entire tree (/instances) allows mkdir/rmdir.
	* ftrace_trace_arrays always starts with global_trace and the rest
is in 1-to-1 correspondence with subdirectories of /instances.
	* tr->name is NULL for global_trace and non-NULL for everything
else.
	* all modifications of that list are happening from mkdir/rmdir
	* in the end of ->mkdir tr->dir set to the dentry of our subdirectory,
and it's non-NULL (or trace_array creation simply fails)
	* global_array.dir is set to magical value ((struct dentry *)1) upon
the first call of tracing_init_dentry().  Prior to that it's NULL.  BTW, may
I politely inquire what the fuck are those contortions in
tracing_init_dentry_tr() about?  Looks like a stunningly convoluted way
to trigger that automount point creation early in tracer_init_tracefs().
Why not do that right there explicitly?

What are mount options doing?  I mean, sure, you set the mode/uid/gid
of root.  Which is not modifiable anyway...  And AFAICS that's all those
options are affecting.

AFAICS, nothing ever removes files in debugfs root.  Right?  If so, you don't
need the games with simple_pin_fs() - they are pointless in such situation
anyway.  Just do tracefs_mount = kern_mount(&trace_fs_type); in tracefs_init()
and be done with that; lose the tracefs_mount_count and all calls of
simple_{pin,release}_fs().

While we are at it, what the hell is tracefs_file_operations about?  Looks
like some bastard offspring of /dev/null, but I don't see anything that would
use it...

  parent reply	other threads:[~2015-01-26 21:40 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-26 15:09 Steven Rostedt
2015-01-26 15:09 ` [PATCH 01/16 v3] debugfs_{mkdir,create,link}(): get rid of redundant argument Steven Rostedt
2015-01-26 15:09 ` [PATCH 02/16 v3] debugfs: split the beginning and the end of __create_file() off Steven Rostedt
2015-01-26 15:09 ` [PATCH 03/16 v3] debugfs: kill __create_file() Steven Rostedt
2015-01-26 15:09 ` [PATCH 04/16 v3] fold debugfs_link() into caller Steven Rostedt
2015-01-26 15:09 ` [PATCH 05/16 v3] debugfs_mknod(): get rid useless arguments Steven Rostedt
2015-01-26 15:09 ` [PATCH 06/16 v3] fold debugfs_mkdir() into caller Steven Rostedt
2015-01-26 15:09 ` [PATCH 07/16 v3] fold debugfs_create() " Steven Rostedt
2015-01-26 15:09 ` [PATCH 08/16 v3] fold debugfs_mknod() into callers Steven Rostedt
2015-01-26 15:09 ` [PATCH 09/16 v3] debugfs: take mode-dependent parts of debugfs_get_inode() " Steven Rostedt
2015-01-26 15:09 ` [PATCH 10/16 v3] debugfs: split end_creating() into success and failure cases Steven Rostedt
2015-01-26 15:09 ` [PATCH 11/16 v3] new primitive: debugfs_create_automount() Steven Rostedt
2015-01-26 15:09 ` [PATCH 12/16 v3] tracefs: Add new tracefs file system Steven Rostedt
2015-01-26 15:09 ` [PATCH 13/16 v3] tracing: Convert the tracing facility over to use tracefs Steven Rostedt
2015-01-26 15:09 ` [PATCH 14/16 v3] tracing: Automatically mount tracefs on debugfs/tracing Steven Rostedt
2015-01-26 15:09 ` [PATCH 15/16 v3] tracefs: Add directory /sys/kernel/tracing Steven Rostedt
2015-01-26 15:09 ` [PATCH 16/16 v3] tracing: Have mkdir and rmdir be part of tracefs Steven Rostedt
2015-01-26 19:30 ` [PATCH 00/16 v3] tracing: Add new file system tracefs Al Viro
2015-01-26 20:42   ` Steven Rostedt
2015-01-26 20:44     ` Steven Rostedt
2015-01-26 20:58       ` Steven Rostedt
2015-01-26 21:44         ` Al Viro
2015-01-26 21:46     ` Al Viro
2015-01-26 23:02       ` Al Viro
2015-01-26 23:39         ` Steven Rostedt
2015-01-26 23:43       ` Steven Rostedt
2015-01-26 23:49         ` Steven Rostedt
2015-01-27  0:39           ` Steven Rostedt
2015-01-27  4:34             ` Al Viro
2015-01-27 15:15               ` Steven Rostedt
2015-01-27  0:37         ` Al Viro
2015-01-27  1:02           ` Steven Rostedt
2015-01-27  1:03             ` Steven Rostedt
2015-01-27  4:38               ` Al Viro
2015-01-27 15:19                 ` Steven Rostedt
2015-01-27 15:44                   ` Steven Rostedt
2015-01-26 21:40   ` Al Viro [this message]
2015-01-26 23:37     ` Steven Rostedt
2015-01-27  2:34       ` Steven Rostedt
2015-01-27  4:46         ` Al Viro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150126214020.GO29656@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=rostedt@goodmis.org \
    --subject='Re: [PATCH 00/16 v3] tracing: Add new file system tracefs' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).