linux-ext4 - Re: [PATCH 19/31] fuse: query filesystem geometry when using iomap

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

Message-ID: <20260205190840.1958463-1-clm@meta.com>
Date: Thu, 5 Feb 2026 11:07:55 -0800
From: Chris Mason <clm@...a.com>
To: "Darrick J. Wong" <djwong@...nel.org>
CC: <miklos@...redi.hu>, <joannelkoong@...il.com>, <bernd@...ernd.com>,
        <neal@...pa.dev>, <linux-ext4@...r.kernel.org>,
        <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH 19/31] fuse: query filesystem geometry when using iomap

"Darrick J. Wong" <djwong@...nel.org> wrote:
> From: Darrick J. Wong <djwong@...nel.org>
> 
> Add a new upcall to the fuse server so that the kernel can request
> filesystem geometry bits when iomap mode is in use.
> 

Hi everyone,

I'm trying out my AI review prompts on a few more trees, and I ran it
on the fuse-iomap-cache branch:

https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=fuse-iomap-cache

This was the latest email lore could find, apologies if I grabbed the wrong one.

Hopefully the review below is useful, please let me know if there are places it
has gone wildly wrong.  I kept the header to make it obvious exactly which
commit I'd run through:

commit d529d13100b2e00c33a507c371b6c1b19f2206ae
Author: Darrick J. Wong <djwong@...nel.org>

fuse_trace: query filesystem geometry when using iomap

This commit adds tracepoints for the FUSE_IOMAP_CONFIG operation,
enabling tracing of filesystem geometry queries when using iomap with
FUSE. The tracepoint captures configuration flags, block size, link
limits, time granularity and ranges, maximum file size, and UUID length.

> diff --git a/fs/fuse/fuse_iomap.c b/fs/fuse/fuse_iomap.c
> --- a/fs/fuse/fuse_iomap.c
> +++ b/fs/fuse/fuse_iomap.c
> @@ -743,6 +743,8 @@ static int fuse_iomap_process_config(struct fuse_mount *fm, int error,
>  		return error;
>  	}
>
> +	trace_fuse_iomap_config(fm, outarg);
> +
>  	if (outarg->flags & ~FUSE_IOMAP_CONFIG_ALL)
>  		return -EINVAL;
>

[ ... ]

> diff --git a/fs/fuse/fuse_trace.h b/fs/fuse/fuse_trace.h
> --- a/fs/fuse/fuse_trace.h
> +++ b/fs/fuse/fuse_trace.h

[ ... ]

> @@ -1005,6 +1014,45 @@
>  		  __entry->mode,
>  		  __entry->newsize)
>  );
> +
> +TRACE_EVENT(fuse_iomap_config,
> +	TP_PROTO(const struct fuse_mount *fm,
> +		 const struct fuse_iomap_config_out *outarg),
> +	TP_ARGS(fm, outarg),
> +
> +	TP_STRUCT__entry(
> +		__field(dev_t,			connection)
> +
> +		__field(uint32_t,		flags)
> +		__field(uint32_t,		blocksize)
> +		__field(uint32_t,		max_links)
> +		__field(uint32_t,		time_gran)
> +
> +		__field(int64_t,		time_min)
> +		__field(int64_t,		time_max)
> +		__field(int64_t,		maxbytes)
> +		__field(uint8_t,		uuid_len)
> +	),
> +
> +	TP_fast_assign(
> +		__entry->connection	=	fm->fc->dev;
> +		__entry->flags		=	outarg->flags;
                                                           ^^^^

Does this truncate the upper 32 bits of the flags field? The flags field
in struct fuse_iomap_config_out (include/uapi/linux/fuse.h:1471) is
defined as uint64_t:

struct fuse_iomap_config_out {
	uint64_t flags;		/* FUSE_IOMAP_CONFIG_* */
	...
}

But the trace event declares it as uint32_t in TP_STRUCT__entry. While
current flag definitions (FUSE_IOMAP_CONFIG_SID through
FUSE_IOMAP_CONFIG_MAXBYTES) only use bits 0-5, using uint32_t will lose
the upper 32 bits if future flags use them.

Should the trace event field be declared as uint64_t to match the
structure definition?