linux-kernel - Re: [PATCH 3/6 linux-next] fs/affs: make affs exportable

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] [day] [month] [year] [list]

Date:   Fri, 13 Jan 2017 15:02:06 -0500
From:   "J. Bruce Fields" <bfields@...ldses.org>
To:     Al Viro <viro@...IV.linux.org.uk>
Cc:     Christoph Hellwig <hch@...radead.org>,
        Fabian Frederick <fabf@...net.be>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel@...r.kernel.org, Jan Kara <jack@...e.cz>,
        linux-fsdevel@...r.kernel.org, neilb@...e.com
Subject: Re: [PATCH 3/6 linux-next] fs/affs: make affs exportable

On Fri, Jan 13, 2017 at 07:57:06PM +0000, Al Viro wrote:
> On Fri, Jan 13, 2017 at 02:03:57PM -0500, J. Bruce Fields wrote:
> > On Fri, Jan 13, 2017 at 10:52:54AM -0800, Christoph Hellwig wrote:
> > > On Fri, Jan 13, 2017 at 12:39:12PM -0500, J. Bruce Fields wrote:
> > > > If we're going to reject patches that don't implement get_parent (and I
> > > > think we should), then we should replace "optional but strongly
> > > > recommended" there by just "mandatory".  Any objections?
> > > 
> > > In theory yes - we'll just need an exception (or dummy implementation)
> > > for in-memory file systems like tmpfs.
> > 
> > Hm, so does get_parent just never get called for tmpfs because the
> > parent's always there already?
> 
> 	As the matter of fact, tmpfs *does* have a dummy ->get_parent().
> FWIW, the situation right now looks so:

Thanks for the summary.

> 	1) most of the local filesystems: get_parent/fh_to_dentry/fh_to_parent.
> efs, exofs, ext2, ext4, f2fs, fat, jffs2, jfs, ntfs, squashfs, udf, ufs are
> that way.
> 	2) ditto, but with non-default ->encode_fh() (that's basically those
> who need more than 32-bit inumber to get to an inode).  Often enough those
> have non-default ->get_name() as well - default one relies upon in-core
> ->i_ino matching whatever getdents(2) puts into d_ino; besides, there might
> be a faster way to search.  Ones without ->get_name(): fat_nostale, fuse,
> isofs, nilfs2, ocfs2, reiserfs.  Ones with: lustre, btrfs, ceph, gfs2.
> 	3) shmem - essentially as (2), but there ->get_parent() is
> a dummy and so's ->fh_to_parent(), the latter represented by NULL rather
> than as an explicit stub.
> 	4) orangefs - no ->fh_to_parent, no ->get_parent.  Not sure if
> orangefs has a way to get khandle of parent by that of directory (i.e.
> if it can open a disconnected directory by khandle and then obtain
> a khandle of parent from it).  They do include khandle of directory into
> on-the-wire fhandle, but never actually use that part.  Might be blind
> copying of what other fs are doing, might be something they plan to do
> but hadn't gotten around to.  If it's the latter, that's yet another class
> 2 (and it'll definitely need a ->get_name() then).
> 	5) befs - ->fh_to_dentry/->fh_to_parent, no ->get_parent.  IIRC,
> they simply don't have a way to find the parent by directory.
> 	6) cifs - stub ->get_parent(), NULL everything else, impossible
> to use and what the hell is fs/cifs/export.c is doing in the tree, anyway?

Dunno, I thought I tried to remove it once some time ago, but my memory
may be wrong.  It seems like nothing more than a trap for the unwary.

--b.