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]

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

Hello, Al.

On Thu, Jan 22, 2015 at 04:23:30AM +0000, Al Viro wrote:
> I would recommend against that - kernfs is overburdened by their need to
> accomodate cgroup weirdness.  IMO it's not a good model for anything, other

That's not true.  The two big items where sysfs is complicated are the
custom revocation implementation and namespace support, both of which
come from its sysfs lineage.  The revocation implementation had an
update to better support cgroup but the new interface is more generic
than before and necessary if it wants to support self-removing files
along with the said revocation support.

One complexity actually added for cgroup is in the mount path because
cgroup needs to be able to create or match superblocks dynamically
during mount time and that doesn't really jive well with how
superblocks are managed in the vfs layer.  This part is ugly and
intentially left that way.  This really should be cgroup specific (and
we can't shed it at the moment) and shouldn't be used elsewhere.
IIRC, you had some complaints about this and I wonder whether that's
what shaped your opinion, but this is entirely isolated.  Just use
kernfs_mount() and ignore the @new_fs_created param.

Overall, kernfs is basically the actual filesystem part of sysfs.
None of the fundamentals changed while separating out kernfs out of
sysfs.  You may not like kernfs but then wouldn't improving it a far
better strategy over long haul?  I really don't think we need yet
another pseudo vfs based filesystem in kernel and unless tracingfs is
doing something crazy kernfs should be able to serve as a common
foundation.

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/