From: "Darrick J. Wong" <djwong@kernel.org>
To: John Groves <john@jagalactic.com>
Cc: John Groves <John@groves.net>, 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 05/12] famfs: Introduce file_operations read/write
Date: Wed, 5 Aug 2026 22:14:54 -0700 [thread overview]
Message-ID: <20260806051454.GE3560084@frogsfrogsfrogs> (raw)
In-Reply-To: <0100019fc5741536-d6b2c2f4-794a-43b4-abf4-f38f2d812e19-000000@email.amazonses.com>
On Mon, Aug 03, 2026 at 02:29:07AM +0000, John Groves wrote:
> From: John Groves <john@groves.net>
>
> This commit introduces fs/famfs/famfs_file.c and the famfs
> file_operations for read/write.
>
> This is not usable yet because:
>
> * It calls dax_iomap_rw() with NULL iomap_ops (which will be
> introduced in a subsequent commit).
> * famfs_ioctl() is coming in a later commit, and it is necessary
> to map a file to a memory allocation.
>
> Signed-off-by: John Groves <john@groves.net>
> ---
> fs/famfs/Makefile | 2 +-
> fs/famfs/famfs_file.c | 138 ++++++++++++++++++++++++++++++++++++++
> fs/famfs/famfs_inode.c | 2 +-
> fs/famfs/famfs_internal.h | 2 +
> 4 files changed, 142 insertions(+), 2 deletions(-)
> create mode 100644 fs/famfs/famfs_file.c
>
> diff --git a/fs/famfs/Makefile b/fs/famfs/Makefile
> index 62230bcd6793..8cac90c090a4 100644
> --- a/fs/famfs/Makefile
> +++ b/fs/famfs/Makefile
> @@ -2,4 +2,4 @@
>
> obj-$(CONFIG_FAMFS) += famfs.o
>
> -famfs-y := famfs_inode.o
> +famfs-y := famfs_inode.o famfs_file.o
> diff --git a/fs/famfs/famfs_file.c b/fs/famfs/famfs_file.c
> new file mode 100644
> index 000000000000..e192b573c51f
> --- /dev/null
> +++ b/fs/famfs/famfs_file.c
> @@ -0,0 +1,138 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * famfs - dax file system for shared fabric-attached memory
> + *
> + * Copyright 2023-2024 Micron Technology, Inc.
> + *
> + * This file system, originally based on ramfs the dax support from xfs,
> + * is intended to allow multiple host systems to mount a common file system
> + * view of dax files that map to shared memory.
> + */
> +
> +#include <linux/fs.h>
> +#include <linux/mm.h>
> +#include <linux/dax.h>
> +#include <linux/iomap.h>
> +
> +#include "famfs_internal.h"
> +
> +/*********************************************************************
> + * file_operations
> + */
> +
> +/* Reject I/O to files that aren't in a valid state */
> +static ssize_t
> +famfs_file_invalid(struct inode *inode)
> +{
> + if (!IS_DAX(inode)) {
> + pr_debug("%s: inode %llx IS_DAX is false\n",
> + __func__, (u64)inode);
> + return -ENXIO;
> + }
> + return 0;
> +}
> +
> +static ssize_t
> +famfs_rw_prep(struct kiocb *iocb, struct iov_iter *ubuf)
> +{
> + struct inode *inode = iocb->ki_filp->f_mapping->host;
> + struct super_block *sb = inode->i_sb;
> + struct famfs_fs_info *fsi = sb->s_fs_info;
> + size_t i_size = i_size_read(inode);
> + size_t count = iov_iter_count(ubuf);
> + size_t max_count;
> + ssize_t rc;
> +
> + if (fsi->deverror)
> + return -ENODEV;
> +
> + rc = famfs_file_invalid(inode);
> + if (rc)
> + return rc;
> +
> + /* Avoid unsigned underflow if position is past EOF */
> + if (iocb->ki_pos >= i_size)
> + max_count = 0;
> + else
> + max_count = i_size - iocb->ki_pos;
> +
> + if (count > max_count)
> + iov_iter_truncate(ubuf, max_count);
> +
> + if (!iov_iter_count(ubuf))
> + return 0;
> +
> + return rc;
> +}
> +
> +static ssize_t
> +famfs_dax_read_iter(struct kiocb *iocb, struct iov_iter *to)
> +{
> + struct inode *inode = iocb->ki_filp->f_mapping->host;
> + ssize_t rc;
> +
> + /* dax_iomap_rw() requires i_rwsem held (shared for read) */
> + inode_lock_shared(inode);
> + rc = famfs_rw_prep(iocb, to);
> + if (rc || !iov_iter_count(to)) {
> + inode_unlock_shared(inode);
> + return rc;
> + }
> +
> + rc = dax_iomap_rw(iocb, to, NULL /*&famfs_iomap_ops */);
> + inode_unlock_shared(inode);
> +
> + file_accessed(iocb->ki_filp);
Is it really accessed if rc != 0?
> + return rc;
> +}
> +
> +/**
> + * famfs_dax_write_iter()
> + *
> + * We need our own write-iter in order to prevent append
> + *
> + * @iocb:
> + * @from: iterator describing the user memory source for the write
> + */
> +static ssize_t
> +famfs_dax_write_iter(struct kiocb *iocb, struct iov_iter *from)
> +{
> + struct inode *inode = iocb->ki_filp->f_mapping->host;
> + struct famfs_fs_info *fsi = inode->i_sb->s_fs_info;
> + ssize_t rc;
> +
> + if (!famfs_opt_enabled(fsi, FAMFS_OPT_WRITE))
> + return -EPERM;
> +
> + /* dax_iomap_rw() requires i_rwsem held (exclusive for write) */
> + inode_lock(inode);
> + rc = famfs_rw_prep(iocb, from);
> + if (rc || !iov_iter_count(from)) {
> + inode_unlock(inode);
> + return rc;
> + }
> +
> + rc = dax_iomap_rw(iocb, from, NULL /*&famfs_iomap_ops*/);
What happens if you pass a null iomap ops? TBH I was expecting you to
define the iomap ops with a dummy ->iomap_begin that returns EIO or
something.
> + inode_unlock(inode);
> + return rc;
Do you need to update mtime here?
--D
> +}
> +
> +const struct file_operations famfs_file_operations = {
> + .owner = THIS_MODULE,
> +
> + /* Custom famfs operations */
> + .write_iter = famfs_dax_write_iter,
> + .read_iter = famfs_dax_read_iter,
> + .unlocked_ioctl = NULL /*famfs_file_ioctl*/,
> + .mmap = NULL /* famfs_file_mmap */,
> +
> + /* Force PMD alignment for mmap */
> + .get_unmapped_area = thp_get_unmapped_area,
> +
> + /* Generic Operations */
> + .fsync = noop_fsync,
> + .splice_read = filemap_splice_read,
> + .splice_write = iter_file_splice_write,
> + .llseek = generic_file_llseek,
> +};
> +
> diff --git a/fs/famfs/famfs_inode.c b/fs/famfs/famfs_inode.c
> index efc6b852eca0..910a143dad30 100644
> --- a/fs/famfs/famfs_inode.c
> +++ b/fs/famfs/famfs_inode.c
> @@ -58,7 +58,7 @@ static struct inode *famfs_get_inode(
> break;
> case S_IFREG:
> inode->i_op = &famfs_file_inode_operations;
> - inode->i_fop = NULL /* &famfs_file_operations */;
> + inode->i_fop = &famfs_file_operations;
> break;
> case S_IFDIR:
> inode->i_op = &famfs_dir_inode_operations;
> diff --git a/fs/famfs/famfs_internal.h b/fs/famfs/famfs_internal.h
> index 485087588a11..26f5abda96dc 100644
> --- a/fs/famfs/famfs_internal.h
> +++ b/fs/famfs/famfs_internal.h
> @@ -15,6 +15,8 @@
> #include <linux/bits.h>
> #include <linux/build_bug.h>
>
> +extern const struct file_operations famfs_file_operations;
> +
> struct famfs_mount_opts {
> umode_t mode;
> };
> --
> 2.53.0
>
>
next prev parent reply other threads:[~2026-08-06 5:14 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 [this message]
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
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=20260806051454.GE3560084@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=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=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.