linux-kernel - Re: [RFC][PATCH 0/5] tracing: Add new file system tracefs

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: <20150122145547.GB4507@htj.dyndns.org>
Date:	Thu, 22 Jan 2015 09:55:47 -0500
From:	Tejun Heo <tj@...nel.org>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, Al Viro <viro@...IV.linux.org.uk>,
	Ingo Molnar <mingo@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC][PATCH 0/5] tracing: Add new file system tracefs

Hey, Steven.

On Thu, Jan 22, 2015 at 09:32:49AM -0500, Steven Rostedt wrote:
> The problem is that these do not return dentry. They return kernfs_node.

Yeap, that's what represents a file or directory in kernfs.

> I see a kernfs_node_from_dentry() call but not the other way around.

Because dentries / inodes may or may not exist for a given kernfs
node.  kernfs_nodes are the backing information in a similar way to an
actual filesystem.

> Yes, the interface for tracefs is just these four functions, but then
> the interaction of the kernfs versions use a completely different API.
> 
> Each of the created files expects to attach their own open, read,
> write, and release functions. And yes, some even use the seq functions,
> and they use it the vfs way. I do not intend on rewriting the users of
> the debugfs file system. To use kernfs, it seems that I would need to
> do that, and I don't have the time to make such a dramatic change to
> the system. It will fall down on my TODO list and I probably wont get
> to it for another decade.

kernfs provides two sets of file operations.  One is seq_file based
and the other is direct read/write.  In both cases, bouncing data
between userland and kernel is handled by kernfs.  If you already have
existing read write ops implemented doing custom buffer handling and
direct userland memory access, it'll take some adaptation but for a
lot of cases this would consolidate duplicate code paths.

> I created tracefs with 700 lines of code and two files (inode.c and
> tracefs.h), and for the users of tracefs, I just did
> s/debugfs/tracefs/. If I can't make that substitution for the users,
> that is a show stopper.
> 
> I don't see how I can use kernfs without it causing a lot of invasive
> changes to the ftrace subsystem.

Converting an existing vfs based pseudo fs implementation over to
kernfs isn't trivial.  I mean, if that were trivial, why would kernfs
even exist?  kernfs is a layer which abstracts a large part of pseudo
filesystem which provides extra features like significantly lower
memory footprint with large number of nodes and revocation support in
a way that its users, for the most part, hopefully, only have to worry
about the content to provide to userland.

I frankly have no idea whether tracefs would be a good candidate for
kernfs usage but if you're looking for a mechanical one-to-one
conversion from vfs based implementation, that's not gonna work.

Thanks.

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