All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Groves <John@groves.net>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: John Groves <john@jagalactic.com>,
	Miklos Szeredi <miklos@szeredi.hu>,
	 Dan Williams <djbw@kernel.org>,
	Bernd Schubert <bschubert@ddn.com>,
	 Alison Schofield <alison.schofield@intel.com>,
	John Groves <jgroves@micron.com>,
	 Jonathan Corbet <corbet@lwn.net>, Jake Edge <jake@lwn.net>,
	Shuah Khan <skhan@linuxfoundation.org>,
	 Vishal Verma <vishal.l.verma@intel.com>,
	Dave Jiang <dave.jiang@intel.com>,
	 Matthew Wilcox <willy@infradead.org>, Jan Kara <jack@suse.cz>,
	 Alexander Viro <viro@zeniv.linux.org.uk>,
	David Hildenbrand <david@kernel.org>,
	 Christian Brauner <brauner@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	 Jeff Layton <jlayton@kernel.org>,
	Amir Goldstein <amir73il@gmail.com>,
	 Jonathan Cameron <jic23@kernel.org>,
	Stefan Hajnoczi <shajnocz@redhat.com>,
	 Joanne Koong <joannelkoong@gmail.com>,
	Josef Bacik <josef@toxicpanda.com>,
	 Bagas Sanjaya <bagasdotme@gmail.com>,
	Chen Linxuan <chenlinxuan@uniontech.com>,
	 James Morse <james.morse@arm.com>, Fuad Tabba <tabba@google.com>,
	 Sean Christopherson <seanjc@google.com>,
	Shivank Garg <shivankg@amd.com>,
	 Ackerley Tng <ackerleytng@google.com>,
	Gregory Price <gourry@gourry.net>,
	 Andrew Morton <akpm@linux-foundation.org>,
	Namjae Jeon <linkinjeon@kernel.org>,
	 Lorenzo Stoakes <ljs@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	 Ira Weiny <iweiny@kernel.org>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	 Haren Myneni <haren@linux.ibm.com>,
	Pratyush Yadav <pratyush@kernel.org>,
	 Giovanni Cabiddu <giovanni.cabiddu@intel.com>,
	Jiri Slaby <jirislaby@kernel.org>,
	 Ethan Nelson-Moore <enelsonmoore@gmail.com>,
	Gabriel Whigham <gabewhigham@gmail.com>,
	 Aravind Ramesh <arramesh@micron.com>,
	Ajay Joshi <ajayjoshi@micron.com>,
	 "venkataravis@micron.com" <venkataravis@micron.com>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"nvdimm@lists.linux.dev" <nvdimm@lists.linux.dev>,
	 "linux-cxl@vger.kernel.org" <linux-cxl@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	 "fuse-devel@lists.linux.dev" <fuse-devel@lists.linux.dev>
Subject: Re: [PATCH V12 07/12] famfs: MAP_CREATE ioctl and fmap ingest (ABI 44)
Date: Thu, 6 Aug 2026 15:53:13 -0500	[thread overview]
Message-ID: <anTxt3qsUQuCKvMz@groves.net> (raw)
In-Reply-To: <20260806052449.GG3560084@frogsfrogsfrogs>

On 26/08/05 10:24PM, Darrick J. Wong wrote:
> On Mon, Aug 03, 2026 at 02:29:26AM +0000, John Groves wrote:
> > From: John Groves <John@Groves.net>
> > 
> > Add the famfs file ioctl handler (FAMFSIOC_NOP, FAMFSIOC_MAP_CREATE) and
> > the KABI-44 self-describing fmap message: the wire ABI in famfs_ioctl.h
> > (famfs_ioc_fmap_header plus the simple and interleaved extent structs), the
> > in-core famfs_file_meta, and famfs_file_init_dax(), which copies the
> > message in, parses both the simple-extent and interleaved (striped) wire
> > forms into inode->i_private, and sets S_DAX.
> > 
> > Resolving those mappings to dax-device offsets (iomap_begin) is added in
> > the following commit; the read/write/fault paths keep their NULL iomap_ops
> > stub until then.
> > 
> > Also add famfs ioctls to ioctl-number.rst
> > 
> > Signed-off-by: John Groves <john@groves.net>
> > ---
> >  .../userspace-api/ioctl/ioctl-number.rst      |   1 +
> >  fs/famfs/famfs_file.c                         | 326 +++++++++++++++++-
> >  fs/famfs/famfs_inode.c                        |   1 +
> >  fs/famfs/famfs_internal.h                     |  46 +++
> >  include/uapi/linux/famfs_ioctl.h              |  91 +++++
> >  5 files changed, 462 insertions(+), 3 deletions(-)
> >  create mode 100644 include/uapi/linux/famfs_ioctl.h
> > 
> > diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst
> > index 3f0ef1e27eb0..5e244dec1b98 100644
> > --- a/Documentation/userspace-api/ioctl/ioctl-number.rst
> > +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
> > @@ -299,6 +299,7 @@ Code  Seq#    Include File                                             Comments
> >  'u'   00-2F  linux/ublk_cmd.h                                          conflict!
> >  'u'   20-3F  linux/uvcvideo.h                                          USB video class host driver
> >  'u'   40-4f  linux/udmabuf.h                                           userspace dma-buf misc device
> > +'u'   50-5F  linux/famfs_ioctl.h                                       famfs shared memory file system
> >  'v'   00-1F  linux/ext2_fs.h                                           conflict!
> >  'v'   00-1F  linux/fs.h                                                conflict!
> >  'v'   00-0F  linux/sonypi.h                                            conflict!
> > diff --git a/fs/famfs/famfs_file.c b/fs/famfs/famfs_file.c
> > index 678f2035fd5f..d710c8a0c923 100644
> > --- a/fs/famfs/famfs_file.c
> > +++ b/fs/famfs/famfs_file.c
> > @@ -13,9 +13,313 @@
> >  #include <linux/mm.h>
> >  #include <linux/dax.h>
> >  #include <linux/iomap.h>
> > +#include <linux/capability.h>
> >  
> > +#include <linux/famfs_ioctl.h>
> >  #include "famfs_internal.h"
> >  
> > +/* Expose famfs kernel abi version as a read-only module parameter */
> > +static int famfs_kabi_version = FAMFS_KABI_VERSION;
> > +module_param(famfs_kabi_version, int, 0444);
> > +MODULE_PARM_DESC(famfs_kabi_version, "famfs kernel abi version");
> 
> Maybe make the "NOP" ioctl a geometry ioctl that tells you the abi
> version and (I guess) the page and pmd size? :D

I like it - will do

> 
> > +void
> > +famfs_meta_free(struct famfs_file_meta *map)
> > +{
> > +	if (map) {
> > +		switch (map->fm_extent_type) {
> > +		case FAMFS_IOC_EXT_SIMPLE:
> > +			kfree(map->se);
> > +			break;
> > +		case FAMFS_IOC_EXT_INTERLEAVE:
> > +			if (map->ie) {
> > +				u32 i;
> > +
> > +				for (i = 0; i < map->fm_niext; i++)
> > +					kfree(map->ie[i].ie_strips);
> > +			}
> > +			kfree(map->ie);
> > +			break;
> > +		default:
> > +			break;
> > +		}
> > +	}
> > +	kfree(map);
> > +}
> > +
> > +/**
> > + * famfs_file_init_dax() - FAMFSIOC_MAP_CREATE ioctl handler
> > + * @file: the un-initialized file
> > + * @arg:  user pointer to a self-describing fmap message
> > + *
> > + * The map-create ioctl carries the fmap as a self-describing message: a
> > + * struct famfs_ioc_fmap_header followed by an extent list. The message is
> > + * copied in, parsed into a famfs_file_meta, and published on inode->i_private.
> > + * Both the simple-extent and the interleaved (striped) wire forms are handled.
> > + * The wire layout byte-matches the fmap carried in a fuse famfs GET_FMAP reply.
> > + */
> 
> This kerneldoc is for the next function?

Oops, fixed thanks!

> 
> > +static int
> > +famfs_check_ext_alignment(struct famfs_meta_simple_ext *se)
> > +{
> > +	int errs = 0;
> > +
> > +	if (!IS_ALIGNED(se->ext_offset, PMD_SIZE))
> > +		errs++;
> > +	if (!IS_ALIGNED(se->ext_len, PMD_SIZE))
> > +		errs++;
> 
> Does this need to check the dax dev index is valid?  Or is it ok to just
> fail an IO if that index is garbage?

That is validated elsewhere

> 
> > +
> > +	return errs;
> > +}
> > +
> > +static int
> > +famfs_file_init_dax(struct file *file, void __user *arg)
> > +{
> > +	struct famfs_ioc_fmap_header fmh;
> > +	struct famfs_file_meta *meta = NULL;
> > +	struct famfs_fs_info *fsi;
> > +	struct super_block *sb;
> > +	struct inode *inode;
> > +	void *fmap_buf = NULL;
> > +	size_t extent_total = 0;
> > +	size_t next_offset;
> > +	int errs = 0;
> > +	int rc;
> > +	u32 i, j;
> > +
> > +	inode = file_inode(file);
> > +	if (!inode)
> > +		return -EBADF;
> > +	if (inode->i_private)
> > +		return -EEXIST;
> > +
> > +	sb  = inode->i_sb;
> > +	fsi = sb->s_fs_info;
> > +	if (fsi->deverror)
> > +		return -ENODEV;
> > +	if (!famfs_opt_enabled(fsi, FAMFS_OPT_MAP_CREATE))
> > +		return -EPERM;
> > +
> > +	if (copy_from_user(&fmh, arg, sizeof(fmh)))
> > +		return -EFAULT;
> > +
> > +	if (fmh.fmap_version != FAMFS_FMAP_VERSION)
> > +		return -EINVAL;
> > +	if (fmh.fmap_size < sizeof(fmh))
> > +		return -EINVAL;
> > +	if (fmh.fmap_size > FAMFS_FMAP_MSG_MAX)
> > +		return -EFBIG;
> > +	if (fmh.nextents < 1)
> > +		return -EINVAL;
> > +
> > +	fmap_buf = kvmalloc(fmh.fmap_size, GFP_KERNEL);
> > +	if (!fmap_buf)
> > +		return -ENOMEM;
> > +
> > +	if (copy_from_user(fmap_buf, arg, fmh.fmap_size)) {
> > +		rc = -EFAULT;
> > +		goto out;
> > +	}
> > +	next_offset = sizeof(fmh);	/* start of the extent list */
> > +
> > +	meta = kzalloc_obj(*meta, GFP_KERNEL);
> > +	if (!meta) {
> > +		rc = -ENOMEM;
> > +		goto out;
> > +	}
> > +
> > +	meta->error = false;
> > +	meta->file_type = fmh.file_type;
> > +	meta->file_size = fmh.file_size;
> > +	meta->fm_extent_type = fmh.ext_type;
> > +
> > +	switch (fmh.ext_type) {
> > +	case FAMFS_IOC_EXT_SIMPLE: {
> > +		struct famfs_ioc_simple_ext *se_in = fmap_buf + next_offset;
> > +
> > +		next_offset += (size_t)fmh.nextents * sizeof(*se_in);
> > +		if (next_offset > fmh.fmap_size) {
> > +			rc = -EINVAL;
> > +			goto out;
> > +		}
> > +
> > +		meta->fm_nextents = fmh.nextents;
> > +		meta->se = kcalloc(meta->fm_nextents, sizeof(*meta->se),
> > +				   GFP_KERNEL);
> > +		if (!meta->se) {
> > +			rc = -ENOMEM;
> > +			goto out;
> > +		}
> > +
> > +		for (i = 0; i < fmh.nextents; i++) {
> > +			meta->se[i].dev_index  = se_in[i].se_devindex;
> > +			meta->se[i].ext_offset = se_in[i].se_offset;
> > +			meta->se[i].ext_len    = se_in[i].se_len;
> > +
> > +			if (meta->se[i].dev_index >= FAMFS_MAX_DAXDEVS) {
> > +				rc = -EINVAL;
> > +				goto out;
> > +			}
> > +			meta->dev_bitmap |= BIT_ULL(meta->se[i].dev_index);
> > +			errs += famfs_check_ext_alignment(&meta->se[i]);
> > +			extent_total += meta->se[i].ext_len;
> > +		}
> > +		break;
> > +	}
> > +
> > +	case FAMFS_IOC_EXT_INTERLEAVE: {
> > +		s64 size_remainder = meta->file_size;
> > +		u32 niext = fmh.nextents;
> > +
> > +		meta->fm_niext = niext;
> > +		meta->ie = kcalloc(niext, sizeof(*meta->ie), GFP_KERNEL);
> > +		if (!meta->ie) {
> > +			rc = -ENOMEM;
> > +			goto out;
> > +		}
> > +
> > +		/* Outer loop is over the separate interleaved extents */
> > +		for (i = 0; i < niext; i++) {
> > +			struct famfs_ioc_iext *ie_in = fmap_buf + next_offset;
> > +			struct famfs_ioc_simple_ext *sie_in;
> > +			u64 nstrips;
> > +
> > +			next_offset += sizeof(*ie_in);
> > +			if (next_offset > fmh.fmap_size) {
> > +				rc = -EINVAL;
> > +				goto out;
> > +			}
> > +
> > +			if (ie_in->ie_chunk_size == 0 ||
> > +			    !IS_ALIGNED(ie_in->ie_chunk_size, PMD_SIZE)) {
> > +				rc = -EINVAL;
> > +				goto out;
> > +			}
> > +			if (ie_in->ie_nbytes == 0) {
> > +				rc = -EINVAL;
> > +				goto out;
> > +			}
> > +
> > +			nstrips = ie_in->ie_nstrips;
> > +			if (nstrips < 1) {
> > +				rc = -EINVAL;
> > +				goto out;
> > +			}
> > +
> > +			meta->ie[i].fie_chunk_size = ie_in->ie_chunk_size;
> > +			meta->ie[i].fie_nstrips    = ie_in->ie_nstrips;
> > +			meta->ie[i].fie_nbytes     = ie_in->ie_nbytes;
> > +
> > +			/* The strip extents follow the interleaved-ext header */
> > +			sie_in = fmap_buf + next_offset;
> > +			next_offset += nstrips * sizeof(*sie_in);
> > +			if (next_offset > fmh.fmap_size) {
> > +				rc = -EINVAL;
> > +				goto out;
> > +			}
> > +
> > +			meta->ie[i].ie_strips =
> > +				kcalloc(nstrips, sizeof(meta->ie[i].ie_strips[0]),
> > +					GFP_KERNEL);
> > +			if (!meta->ie[i].ie_strips) {
> > +				rc = -ENOMEM;
> > +				goto out;
> > +			}
> > +
> > +			/* Inner loop is over the strips */
> > +			for (j = 0; j < nstrips; j++) {
> > +				struct famfs_meta_simple_ext *so =
> > +					&meta->ie[i].ie_strips[j];
> > +
> > +				so->dev_index  = sie_in[j].se_devindex;
> > +				so->ext_offset = sie_in[j].se_offset;
> > +				so->ext_len    = sie_in[j].se_len;
> > +
> > +				if (so->dev_index >= FAMFS_MAX_DAXDEVS) {
> > +					rc = -EINVAL;
> > +					goto out;
> > +				}
> > +				meta->dev_bitmap |= BIT_ULL(so->dev_index);
> > +				errs += famfs_check_ext_alignment(so);
> > +				extent_total += so->ext_len;
> > +				size_remainder -= so->ext_len;
> 
> This is a lot of indenting, maybe each case should be a separate helper
> function?
> 
> --D

But I still fit it in 80 columns! :D

This one I think I will leave as-is unless somebody feels strongly.

Thank you!

John

<snip>


  reply	other threads:[~2026-08-06 20:53 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260803022730.75731-1-john@jagalactic.com>
2026-08-03  2:27 ` [PATCH V12 00/12] famfs: the Fabric-Attached Memory File System (standalone) John Groves
2026-08-03  2:28   ` [PATCH V12 01/12] dax: replace exported dax_dev_get() with non-allocating dax_dev_find() John Groves
2026-08-03  2:43     ` sashiko-bot
2026-08-03 19:13     ` Alison Schofield
2026-08-05 20:21       ` John Groves
2026-08-03  2:28   ` [PATCH V12 02/12] famfs: Module operations, fs_context, and mount John Groves
2026-08-03  2:49     ` sashiko-bot
2026-08-06  4:37     ` Darrick J. Wong
2026-08-06 13:22       ` John Groves
2026-08-03  2:28   ` [PATCH V12 03/12] famfs: Add daxdev table and dax notify_failure support John Groves
2026-08-03  2:45     ` sashiko-bot
2026-08-06  5:05     ` Darrick J. Wong
2026-08-06 13:36       ` John Groves
2026-08-03  2:28   ` [PATCH V12 04/12] famfs: Introduce inode_operations and super_operations John Groves
2026-08-03  2:42     ` sashiko-bot
2026-08-06  5:12     ` Darrick J. Wong
2026-08-06 16:31       ` John Groves
2026-08-03  2:29   ` [PATCH V12 05/12] famfs: Introduce file_operations read/write John Groves
2026-08-03  2:42     ` sashiko-bot
2026-08-06  5:14     ` Darrick J. Wong
2026-08-06 20:03       ` John Groves
2026-08-03  2:29   ` [PATCH V12 06/12] famfs: Introduce mmap and VM fault handling John Groves
2026-08-03  2:46     ` sashiko-bot
2026-08-06  5:16     ` Darrick J. Wong
2026-08-06 20:40       ` John Groves
2026-08-03  2:29   ` [PATCH V12 07/12] famfs: MAP_CREATE ioctl and fmap ingest (ABI 44) John Groves
2026-08-03  2:42     ` sashiko-bot
2026-08-06  5:24     ` Darrick J. Wong
2026-08-06 20:53       ` John Groves [this message]
2026-08-07 22:17         ` John Groves
2026-08-03  2:29   ` [PATCH V12 08/12] famfs: iomap_begin and file-to-dax offset resolution John Groves
2026-08-03  2:44     ` sashiko-bot
2026-08-06  5:28     ` Darrick J. Wong
2026-08-06 22:14       ` John Groves
2026-08-03  2:29   ` [PATCH V12 09/12] famfs: Register secondary daxdevs by path (FAMFSIOC_DAXDEV_OPEN) John Groves
2026-08-03  2:42     ` sashiko-bot
2026-08-06  5:29     ` Darrick J. Wong
2026-08-06 22:22       ` John Groves
2026-08-03  2:29   ` [PATCH V12 10/12] famfs: Add runtime operation-permission (opts) framework John Groves
2026-08-03  2:42     ` sashiko-bot
2026-08-06  5:31     ` Darrick J. Wong
2026-08-06 22:30       ` John Groves
2026-08-03  2:30   ` [PATCH V12 11/12] famfs: Report device capacity via statfs so df works John Groves
2026-08-03  2:58     ` sashiko-bot
2026-08-06  5:33     ` Darrick J. Wong
2026-08-07 13:47       ` John Groves
2026-08-03  2:30   ` [PATCH V12 12/12] famfs: Add documentation John Groves
2026-08-06  5:38     ` Darrick J. Wong
2026-08-07 15:05       ` John Groves
2026-08-03  8:52   ` [PATCH V12 00/12] famfs: the Fabric-Attached Memory File System (standalone) Amir Goldstein
2026-08-06  5:19     ` Matthew Wilcox
2026-08-06  5:34       ` Darrick J. Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=anTxt3qsUQuCKvMz@groves.net \
    --to=john@groves.net \
    --cc=ackerleytng@google.com \
    --cc=ajayjoshi@micron.com \
    --cc=akpm@linux-foundation.org \
    --cc=alison.schofield@intel.com \
    --cc=amir73il@gmail.com \
    --cc=arramesh@micron.com \
    --cc=bagasdotme@gmail.com \
    --cc=brauner@kernel.org \
    --cc=bschubert@ddn.com \
    --cc=chenlinxuan@uniontech.com \
    --cc=corbet@lwn.net \
    --cc=dave.jiang@intel.com \
    --cc=david@kernel.org \
    --cc=djbw@kernel.org \
    --cc=djwong@kernel.org \
    --cc=enelsonmoore@gmail.com \
    --cc=fuse-devel@lists.linux.dev \
    --cc=gabewhigham@gmail.com \
    --cc=giovanni.cabiddu@intel.com \
    --cc=gourry@gourry.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=haren@linux.ibm.com \
    --cc=iweiny@kernel.org \
    --cc=jack@suse.cz \
    --cc=jake@lwn.net \
    --cc=james.morse@arm.com \
    --cc=jgroves@micron.com \
    --cc=jic23@kernel.org \
    --cc=jirislaby@kernel.org \
    --cc=jlayton@kernel.org \
    --cc=joannelkoong@gmail.com \
    --cc=john@jagalactic.com \
    --cc=josef@toxicpanda.com \
    --cc=linkinjeon@kernel.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ljs@kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=nvdimm@lists.linux.dev \
    --cc=pasha.tatashin@soleen.com \
    --cc=pratyush@kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=seanjc@google.com \
    --cc=shajnocz@redhat.com \
    --cc=shivankg@amd.com \
    --cc=skhan@linuxfoundation.org \
    --cc=tabba@google.com \
    --cc=venkataravis@micron.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=vishal.l.verma@intel.com \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.