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
next prev parent 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