Linux CXL
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "John Groves" <john@jagalactic.com>
Cc: nvdimm@lists.linux.dev, linux-cxl@vger.kernel.org
Subject: Re: [PATCH V11 3/9] famfs_fuse: Plumb the GET_FMAP message/response
Date: Mon, 20 Jul 2026 03:56:14 +0000	[thread overview]
Message-ID: <20260720035615.394531F000E9@smtp.kernel.org> (raw)
In-Reply-To: <0100019f7da14ceb-fbd4edd7-ce17-4770-8c58-1296ad3e3fbe-000000@email.amazonses.com>

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] famfs_meta_free() fails to free metadata memory and clear the pointer, causing a memory leak, and famfs_meta_set() has an incorrect return type.
- [Low] The struct fuse_famfs_fmap_header is incomplete and undefined, causing a build failure.
- [Low] Lockless read of shared pointer fi->famfs_meta without READ_ONCE().
--

--- Patch [3]: [PATCH V11 3/9] famfs_fuse: Plumb the GET_FMAP message/response ---
commit d837c9b994af8cb48d023d1ff3ded4fc24c04e86
Author: John Groves <john@groves.net>

famfs_fuse: Plumb the GET_FMAP message/response
    
On completion of an OPEN in famfs mode, issue a GET_FMAP request to the
server to retrieve the file's file-offset-to-dax map (fmap) and cache it
on the fuse_inode (fi->famfs_meta). Once the map is cached, read, write
and mmap are resolved directly to dax with no further upcalls.

> diff --git a/fs/fuse/famfs.c b/fs/fuse/famfs.c
> new file mode 100644
> index 0000000000000..80e6640ac970b
> --- /dev/null
> +++ b/fs/fuse/famfs.c
[ ... ]
> @@ -0,0 +1,134 @@
> +int fuse_get_fmap(struct fuse_mount *fm, struct inode *inode)
> +{
> +	struct fuse_inode *fi = get_fuse_inode(inode);
> +	u64 nodeid = get_node_id(inode);
> +	size_t bufsize = FMAP_BUFSIZE_INIT;
> +	void *fmap_buf = NULL;
> +	ssize_t fmap_size;
> +	int attempt;
> +	int rc;
> +
> +	/* Don't retrieve if we already have the famfs metadata */
> +	if (fi->famfs_meta)
            ^^^^^^^^^^^^^^

[Severity: Low]
Does this lockless read need a READ_ONCE() wrapper?  Without it, we might risk
compiler optimization issues, especially since this is a shared pointer that
can be concurrently modified by another thread.

> +		return 0;
> +
> +	/*
> +	 * The fmap size is not known in advance. Start with a modest buffer and,
> +	 * if the server reports (via the returned header's fmap_size) that the
> +	 * whole fmap did not fit, reallocate exactly that size and retry once.
> +	 * The server learns our buffer size from the request's
> +	 * fuse_getxattr_in.size (GETXATTR-style size probe).
> +	 */
> +	for (attempt = 0; ; attempt++) {
> +		struct fuse_getxattr_in in = { .size = bufsize };
> +		struct fuse_famfs_fmap_header *fmh;
> +		u32 required;
> +
> +		FUSE_ARGS(args);
[ ... ]
> +		fmap_size = rc;
> +
> +		/* Need at least a header to learn the required size */
> +		if (fmap_size < (ssize_t)sizeof(*fmh)) {
                                          ^^^^^^^^^^^

[Severity: Low]
Will this cause a build failure?  It looks like struct fuse_famfs_fmap_header
is declared as a pointer but never defined anywhere in the source tree, so
its size cannot be evaluated here.

> +			pr_err("%s: short fmap reply %zd\n", __func__, fmap_size);
> +			kvfree(fmap_buf);
> +			return -EIO;
> +		}
> +
> +		fmh = fmap_buf;
> +		required = fmh->fmap_size;
                             ^^^^^^^^^^^^

[Severity: Low]
this isn't a bug, but similar to the above, this dereference of fmh->fmap_size
might fail to compile because the struct is incomplete.

[ ... ]
> diff --git a/fs/fuse/fuse_i.h b/fs/fuse/fuse_i.h
> index 9c354118c931e..5bacc50986203 100644
> --- a/fs/fuse/fuse_i.h
> +++ b/fs/fuse/fuse_i.h
[ ... ]
> @@ -1339,4 +1344,59 @@ extern void fuse_sysctl_unregister(void);
> +/* Set fi->famfs_meta iff the current value is NULL */
> +static inline struct fuse_backing *famfs_meta_set(struct fuse_inode *fi,
> +						  void *meta)
> +{
> +	return cmpxchg(&fi->famfs_meta, NULL, meta);
> +}
> +
> +static inline void famfs_meta_free(struct fuse_inode *fi)
> +{
> +	famfs_meta_set(fi, NULL);
        ^^^^^^^^^^^^^^^^^^^^^^^^

[Severity: High]
Does this code leak the metadata?  When called from fuse_free_inode() on inode
teardown to free the metadata, fi->famfs_meta is non-NULL. But famfs_meta_set()
uses cmpxchg() against NULL, so the exchange will fail and the pointer will
never be cleared, bypassing any actual free operation.

Also, famfs_meta_set() returns a struct fuse_backing *, which looks like a
copy-paste error from passthrough code.

> +}
> +
> +static inline int fuse_file_famfs(struct fuse_inode *fi)
> +{
> +	return (READ_ONCE(fi->famfs_meta) != NULL);
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/0100019f7d9fbe81-6cb16662-2522-47ea-a152-fab0ee3d9b35-000000@email.amazonses.com?part=3

  reply	other threads:[~2026-07-20  3:56 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260720034358.68714-1-john@jagalactic.com>
2026-07-20  3:44 ` [PATCH V11 0/9] famfs: port into fuse John Groves
2026-07-20  3:45   ` [PATCH V11 1/9] famfs_fuse: Update macro s/FUSE_IS_DAX/FUSE_IS_VIRTIO_DAX/ John Groves
2026-07-20  3:45   ` [PATCH V11 2/9] famfs_fuse: Basic fuse kernel ABI enablement for famfs John Groves
2026-07-20  3:56     ` sashiko-bot
2026-07-20  3:45   ` [PATCH V11 3/9] famfs_fuse: Plumb the GET_FMAP message/response John Groves
2026-07-20  3:56     ` sashiko-bot [this message]
2026-07-22 13:59     ` Miklos Szeredi
2026-07-20  3:46   ` [PATCH V11 4/9] famfs_fuse: Create files with famfs fmaps John Groves
2026-07-20  3:59     ` sashiko-bot
2026-07-22 15:24     ` Miklos Szeredi
2026-07-20  3:46   ` [PATCH V11 5/9] famfs_fuse: register fs-dax daxdevs via FUSE_DEV_IOC_DAXDEV_OPEN John Groves
2026-07-20  4:02     ` sashiko-bot
2026-07-20  3:46   ` [PATCH V11 6/9] famfs_fuse: Plumb dax iomap and fuse read/write/mmap John Groves
2026-07-20  3:57     ` sashiko-bot
2026-07-20  3:46   ` [PATCH V11 7/9] famfs_fuse: fail I/O on invalid or errored daxdevs John Groves
2026-07-20  4:00     ` sashiko-bot
2026-07-20  3:46   ` [PATCH V11 8/9] famfs_fuse: Add DAX address_space_operations with noop_dirty_folio John Groves
2026-07-20  4:04     ` sashiko-bot
2026-07-20  3:47   ` [PATCH V11 9/9] famfs_fuse: Add documentation John Groves
2026-07-20  4:09     ` sashiko-bot
2026-07-20 10:07   ` [PATCH V11 0/9] famfs: port into fuse Amir Goldstein
2026-07-22 10:46     ` Miklos Szeredi
2026-07-22 12:47       ` Amir Goldstein
2026-07-22 14:42         ` Joanne Koong

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=20260720035615.394531F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=john@jagalactic.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=nvdimm@lists.linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox