linux-ext4 - [RFC 0/3] getfsmapx ioctl

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

Date:	Thu, 5 May 2016 12:47:54 -0700
From:	"Darrick J. Wong" <darrick.wong@...cle.com>
To:	Mark Fasheh <mfasheh@...e.de>, Josef Bacik <jbacik@...com>,
	Dave Chinner <david@...morbit.com>,
	"Theodore Ts'o" <tytso@....edu>,
	Ross Zwisler <ross.zwisler@...ux.intel.com>,
	Dan Williams <dan.j.williams@...el.com>,
	"Darrick J. Wong" <darrick.wong@...cle.com>
Cc:	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	linux-api@...r.kernel.org, xfs <xfs@....sgi.com>,
	linux-btrfs <linux-btrfs@...r.kernel.org>,
	linux-ext4 <linux-ext4@...r.kernel.org>
Subject: [RFC 0/3] getfsmapx ioctl

Hi,

Building on the discussion "Exposing Extent Information to Userspace"
at LSF, this patchset offers the userspace definition, implementation,
and manpages for a new FS_IOC_GETFSMAPX ioctl that enables userspace
to query the filesystem for a map of every extent in a given range of
physical block keyspace.

Note that prior to the existence of block sharing, I'd have said
"given range of physical blocks", but now that we can return multiple
owner:offset pairs for a given block, the block keyspace now has to
include extra fields to uniquely identify a reverse mapping record.

This ioctl behaves in a similar manner to XFS_IOC_GETBMAPX -- pass in
an array of struct getfsmapx with key and other control values in the
first two array elements, and the kernel passes back extent
information in the other array elements.  The particulars of how to do
this are documented in the manpage that goes along with this set (it
applies against man-pages.git) and example code in the other patches
is against xfsprogs.git#for-next.

Basically, set the lowest key for which you want records in the first
array element; the highest key in the second; and the kernel spits out
records in the rest of the elements.  That's similar to how GETBMAPX
does it, but different from FIEMAP.  I added a dummy 64-bit "device
id" per Josef's request, though I'm thinking that could be cut down to
a simple dev_t.  I also wonder if the kernel should rewrite the low
key with the last element returned so as to seed the next call, but
userspace can do that too.

The kernel-space implementation (for XFS) is buried inside the xfs
reverse mapping patchset which is treading water at github[1].  I
prefer not to patchbomb the whole kernel series until I've put the
mess through better testing, but this should be enough to get the
mailing list discussion started.

Questions?  Comments?  Bike sheds?

--D

[1] https://github.com/djwong/linux/tree/djwong-experimental
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html