linux-kernel - Re: [RFC][patch series] vfsmount gutting

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, 8 Dec 2011 13:10:52 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Matthew Wilcox <matthew@....cx>
Cc:	linux-fsdevel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC][patch series] vfsmount gutting

On Thu, Dec 08, 2011 at 05:19:57AM -0700, Matthew Wilcox wrote:
> On Thu, Dec 08, 2011 at 01:02:52AM +0000, Al Viro wrote:
> > 	OK, that's something I wanted to do for a long time - struct vfsmount
> > contains too much stuff that is strictily VFS-internal and not needed by
> > anything outside of a very small subset of VFS, at that.  As the matter of
> > fact, only 3 fields, 1 of them redundant, are used by code outside of that
> > area - it's mnt_flags ("how it's mounted"), mnt_root ("what dentry tree
> > is mounted here", assign-once thing) and mnt_sb (always equal to
> > mnt_root->d_sb, also assign-once, might or might not be not needed).
> 
> If only these 3 fields are used, why not make the definition of struct
> vfsmount entirely hidden, and add accessor functions for those three?

Code churn from hell, for starters.  And cost of non-inlined calls on some
fairly sensitive paths, but that's secondary.

It might turn out to be feasible, but the price is likely to include several
method prototype changes affecting filesystems all over the place.  E.g.
I really suspect that ->show_options() taking vfsmount had been a mistake.
Mine, at that.  It ought to take root dentry of (sub)tree instead.  No,
passing struct super_block * will _not_ work; the things that share superblock
between several mounts really want to know e.g. which of the snapshots it
is (nilfs2), etc.  The same probably goes for the rest of ->show...() methods.

Hell knows; if we end up in a place where what you said would be doable -
great, but I'd prefer to pull what can be pulled without messing with
fs code first.  Besides, this separation really makes sense - it's
"what part of fs this vfsmount refers to" vs. "how vfsmounts are connected
into mount trees".
--
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/