[PATCH v2 0/2] Fix warnings for RISC-V builds

[PATCH v2 0/2] Fix warnings for RISC-V builds

[Sean Chang]

This series addresses several compiler warnings found when building the
kernel for RISC-V.

The first patch fixes unused variable warnings in the NFS client (including
nfs4proc and flexfilelayout) that occur in certain build configurations.

The second patch fixes a format-truncation warning in the MACB ethernet
driver by ensuring the snprintf output fits within the destination buffer.

v2:
- Split the original treewide patch into subsystem-specific commits.
- Added more detailed commit descriptions to satisfy checkpatch.

Sean Chang (2):
  nfs: fix unused variable warnings
  net: macb: fix format-truncation warning

 drivers/net/ethernet/cadence/macb_main.c  | 4 ++--
 fs/nfs/flexfilelayout/flexfilelayout.c    | 2 +-
 fs/nfs/flexfilelayout/flexfilelayoutdev.c | 3 ++-
 fs/nfs/nfs4proc.c                         | 2 +-
 4 files changed, 6 insertions(+), 5 deletions(-)

-- 
2.34.1

[PATCH v2 1/2] nfs: fix unused variable warnings

[Sean Chang]

Add __maybe_unused to variables only used in specific configurations
to silence compiler warnings found during RISC-V builds.

Signed-off-by: Sean Chang <seanwascoding@gmail.com>
---
v2:
- Split the original treewide patch into subsystem-specific commits.
- Added more detailed commit descriptions to satisfy checkpatch.

 fs/nfs/flexfilelayout/flexfilelayout.c    | 2 +-
 fs/nfs/flexfilelayout/flexfilelayoutdev.c | 3 ++-
 fs/nfs/nfs4proc.c                         | 2 +-
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/fs/nfs/flexfilelayout/flexfilelayout.c b/fs/nfs/flexfilelayout/flexfilelayout.c
index 9056f05a67dc..de9e8bad6af2 100644
--- a/fs/nfs/flexfilelayout/flexfilelayout.c
+++ b/fs/nfs/flexfilelayout/flexfilelayout.c
@@ -1502,7 +1502,7 @@ static void ff_layout_io_track_ds_error(struct pnfs_layout_segment *lseg,
 {
 	struct nfs4_ff_layout_mirror *mirror;
 	u32 status = *op_status;
-	int err;
+	int err __maybe_unused;
 
 	if (status == 0) {
 		switch (error) {
diff --git a/fs/nfs/flexfilelayout/flexfilelayoutdev.c b/fs/nfs/flexfilelayout/flexfilelayoutdev.c
index c2d8a13a9dbd..3fb8dba0abf5 100644
--- a/fs/nfs/flexfilelayout/flexfilelayoutdev.c
+++ b/fs/nfs/flexfilelayout/flexfilelayoutdev.c
@@ -53,7 +53,8 @@ nfs4_ff_alloc_deviceid_node(struct nfs_server *server, struct pnfs_device *pdev,
 	u32 mp_count;
 	u32 version_count;
 	__be32 *p;
-	int i, ret = -ENOMEM;
+	int i;
+	int ret __maybe_unused = -ENOMEM;
 
 	/* set up xdr stream */
 	scratch = folio_alloc(gfp_flags, 0);
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 180229320731..f76c23cdc888 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -9241,7 +9241,7 @@ static int _nfs4_proc_create_session(struct nfs_client *clp,
 int nfs4_proc_create_session(struct nfs_client *clp, const struct cred *cred)
 {
 	int status;
-	unsigned *ptr;
+	unsigned *ptr __maybe_unused;
 	struct nfs4_session *session = clp->cl_session;
 	struct nfs4_add_xprt_data xprtdata = {
 		.clp = clp,
-- 
2.34.1

Re: [PATCH v2 1/2] nfs: fix unused variable warnings

[Andrew Lunn]

On Tue, Feb 17, 2026 at 01:49:49AM +0800, Sean Chang wrote:
> Add __maybe_unused to variables only used in specific configurations
> to silence compiler warnings found during RISC-V builds.

Could you give more details.

>  int nfs4_proc_create_session(struct nfs_client *clp, const struct cred *cred)
>  {
>  	int status;
> -	unsigned *ptr;
> +	unsigned *ptr __maybe_unused;
>  	struct nfs4_session *session = clp->cl_session;
>  	struct nfs4_add_xprt_data xprtdata = {
>  		.clp = clp,

Lets look at this function

int nfs4_proc_create_session(struct nfs_client *clp, const struct cred *cred)
{
	int status;
	unsigned *ptr;
	struct nfs4_session *session = clp->cl_session;
	struct nfs4_add_xprt_data xprtdata = {
		.clp = clp,
	};
	struct rpc_add_xprt_test rpcdata = {
		.add_xprt_test = clp->cl_mvops->session_trunk,
		.data = &xprtdata,
	};

	dprintk("--> %s clp=%p session=%p\n", __func__, clp, session);

	status = _nfs4_proc_create_session(clp, cred);
	if (status)
		goto out;

	/* Init or reset the session slot tables */
	status = nfs4_setup_session_slot_tables(session);
	dprintk("slot table setup returned %d\n", status);
	if (status)
		goto out;

	ptr = (unsigned *)&session->sess_id.data[0];
	dprintk("%s client>seqid %d sessionid %u:%u:%u:%u\n", __func__,
		clp->cl_seqid, ptr[0], ptr[1], ptr[2], ptr[3]);
	rpc_clnt_probe_trunked_xprts(clp->cl_rpcclient, &rpcdata);
out:
	return status;
}

There is no #ifdef'ery here. How is ptr not used? Is status always
true, so the goto it always taken? But then rpcdata should also be
unused?

	Andrew

Re: [PATCH v2 1/2] nfs: fix unused variable warnings

[Sean]

On Tue, Feb 17, 2026 at 4:06 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
>
> There is no #ifdef'ery here. How is ptr not used? Is status always
> true, so the goto it always taken? But then rpcdata should also be
> unused?
>

If CONFIG_SUNRPC_DEBUG is not enabled, dprintk expands to
do {} while (0) during preprocessing. This means unsigned *ptr has
no remaining references in the function, as its only 'read' was inside
the macro.

Regarding rpcdata, the compiler's unused-variable check doesn't care if a
specific branch (like the goto out) might skip the variable's usage at runtime.
As long as there is at least one valid code path where the variable is
referenced
which there is for rpcdata in the call to
rpc_clnt_probe_trunked_xprts() -> the warning is avoided.
For ptr, the macro expansion leaves it with zero references in any path.

Best regards,
Sean

[PATCH v2 2/2] net: macb: fix format-truncation warning

[Sean Chang]

Use a precision specifier in snprintf to ensure the generated
string fits within the ETH_GSTRING_LEN (32 bytes) buffer.

Signed-off-by: Sean Chang <seanwascoding@gmail.com>
---
v2:
- Split the original treewide patch into subsystem-specific commits.
- Added more detailed commit descriptions to satisfy checkpatch.

 drivers/net/ethernet/cadence/macb_main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 43cd013bb70e..26f9ccadd9f6 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -3159,8 +3159,8 @@ static void gem_get_ethtool_strings(struct net_device *dev, u32 sset, u8 *p)
 
 		for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) {
 			for (i = 0; i < QUEUE_STATS_LEN; i++, p += ETH_GSTRING_LEN) {
-				snprintf(stat_string, ETH_GSTRING_LEN, "q%d_%s",
-						q, queue_statistics[i].stat_string);
+				snprintf(stat_string, ETH_GSTRING_LEN, "q%u_%.19s",
+					 q, queue_statistics[i].stat_string);
 				memcpy(p, stat_string, ETH_GSTRING_LEN);
 			}
 		}
-- 
2.34.1

Re: [PATCH v2 2/2] net: macb: fix format-truncation warning

[Andrew Lunn]

On Tue, Feb 17, 2026 at 01:49:50AM +0800, Sean Chang wrote:
> Use a precision specifier in snprintf to ensure the generated
> string fits within the ETH_GSTRING_LEN (32 bytes) buffer.
> 
> Signed-off-by: Sean Chang <seanwascoding@gmail.com>
> ---
> v2:
> - Split the original treewide patch into subsystem-specific commits.
> - Added more detailed commit descriptions to satisfy checkpatch.
> 
>  drivers/net/ethernet/cadence/macb_main.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
> index 43cd013bb70e..26f9ccadd9f6 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -3159,8 +3159,8 @@ static void gem_get_ethtool_strings(struct net_device *dev, u32 sset, u8 *p)
>  
>  		for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) {
>  			for (i = 0; i < QUEUE_STATS_LEN; i++, p += ETH_GSTRING_LEN) {
> -				snprintf(stat_string, ETH_GSTRING_LEN, "q%d_%s",
> -						q, queue_statistics[i].stat_string);
> +				snprintf(stat_string, ETH_GSTRING_LEN, "q%u_%.19s",
> +					 q, queue_statistics[i].stat_string);

These strings are special, in that they are fixed length, 32 bytes
long, and not \0 terminated. There are some helpers at the end of
linux/ethtool.h for dealing with these strings. You might want to use
them.

>  				memcpy(p, stat_string, ETH_GSTRING_LEN);

Also, it looks like stat_string might be one byte too
short. snprintf() will \0 terminate, so you need it big enough to hold
the \0, and then this memcpy() will discard it.

I also wounder, why is just one architecture complaining about this?

    Andrew

Re: [PATCH v2 2/2] net: macb: fix format-truncation warning

[Sean Chang]

On Tue, Feb 17, 2026 at 2:35 AM Andrew Lunn <andrew@lunn.ch> wrote:
> > diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
> > index 43cd013bb70e..26f9ccadd9f6 100644
> > --- a/drivers/net/ethernet/cadence/macb_main.c
> > +++ b/drivers/net/ethernet/cadence/macb_main.c
> > @@ -3159,8 +3159,8 @@ static void gem_get_ethtool_strings(struct net_device *dev, u32 sset, u8 *p)
> >
> >               for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) {
> >                       for (i = 0; i < QUEUE_STATS_LEN; i++, p += ETH_GSTRING_LEN) {
> > -                             snprintf(stat_string, ETH_GSTRING_LEN, "q%d_%s",
> > -                                             q, queue_statistics[i].stat_string);
> > +                             snprintf(stat_string, ETH_GSTRING_LEN, "q%u_%.19s",
> > +                                      q, queue_statistics[i].stat_string);
>
> These strings are special, in that they are fixed length, 32 bytes
> long, and not \0 terminated. There are some helpers at the end of
> linux/ethtool.h for dealing with these strings. You might want to use
> them.
>

Yes, I've switched to ethtool_sprintf() from linux/ethtool.h and
removed the manual
snprintf() and memcpy() calls. After testing, it behaves exactly as expected,
so I will send out [PATCH V3] shortly.

> I also wounder, why is just one architecture complaining about this?

Regarding the architecture-specific nature of the warning: I have verified that
this warning is not triggered on x86_64, even with W=1. It appears to
be specific
to the RISC-V toolchain's diagnostic analysis.

Regardless, converting to ethtool_sprintf() is the correct approach
which does not throw
any warning on the both platforms.

Best regards,
Sean

Re: [PATCH v2 2/2] net: macb: fix format-truncation warning

[Andrew Lunn]

> Regarding the architecture-specific nature of the warning: I have verified that
> this warning is not triggered on x86_64, even with W=1. It appears to
> be specific
> to the RISC-V toolchain's diagnostic analysis.

Given the other patches in there series, i have to wounder, is the
diagnostic analysis correct? Or is the RISC-V toolchain buggy?

> Regardless, converting to ethtool_sprintf() is the correct approach
> which does not throw any warning on the both platforms.

I do agree ethtool_sprintf() is better. But we want the commit message
to reflect why we are making this change. Is it because
ethtool_sprintf() is better, or are we working around toolchain bugs?

	Andrew

Re: [PATCH v2 2/2] net: macb: fix format-truncation warning

[Sean Chang]

On Wed, Feb 18, 2026 at 1:46 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
> Given the other patches in there series, i have to wounder, is the
> diagnostic analysis correct? Or is the RISC-V toolchain buggy?
>

I retry the different methods, I found that when I directly compile
the macb_main.c, it can trigger the same error, and I already prove
the different compiler will reach the same result, so it is not a bug
of the compiler.

I also found that the x86_64 defconfig does not enable CONFIG_MACB
because it requires CONFIG_COMMON_CLK (which is also disabled by
default on x86), whereas the RISC-V defconfig has both enabled.

>
> I do agree ethtool_sprintf() is better. But we want the commit message
> to reflect why we are making this change. Is it because
> ethtool_sprintf() is better, or are we working around toolchain bugs?
>

according to the content I mentioned upon, I think the commit will
something like "ethtool_sprintf() is better to prevent data truncation
and properly fill the 32-byte ethtool string boundary.'"

Best regards,
Sean

Re: [PATCH v2 2/2] net: macb: fix format-truncation warning

[Andrew Lunn]

On Wed, Feb 18, 2026 at 03:14:08AM +0800, Sean Chang wrote:
> On Wed, Feb 18, 2026 at 1:46 AM Andrew Lunn <andrew@lunn.ch> wrote:
> >
> > Given the other patches in there series, i have to wounder, is the
> > diagnostic analysis correct? Or is the RISC-V toolchain buggy?
> >
> 
> I retry the different methods, I found that when I directly compile
> the macb_main.c, it can trigger the same error, and I already prove
> the different compiler will reach the same result, so it is not a bug
> of the compiler.
> 
> I also found that the x86_64 defconfig does not enable CONFIG_MACB
> because it requires CONFIG_COMMON_CLK (which is also disabled by
> default on x86), whereas the RISC-V defconfig has both enabled.

arm and arm64 are much more similar to risc-v than x86. You should
test with those compilers. However, make allmodconfig will get you the
common clk code on x86. Most build testing is done with this
configuration, including the netdev CI.

> > I do agree ethtool_sprintf() is better. But we want the commit message
> > to reflect why we are making this change. Is it because
> > ethtool_sprintf() is better, or are we working around toolchain bugs?
> >
> 
> according to the content I mentioned upon, I think the commit will
> something like "ethtool_sprintf() is better to prevent data truncation
> and properly fill the 32-byte ethtool string boundary.'"

O.K.

	Andrew

Re: [PATCH v2 2/2] net: macb: fix format-truncation warning

[Sean Chang]

On Wed, Feb 18, 2026 at 4:33 AM Andrew Lunn <andrew@lunn.ch> wrote:
> > >
> > > Given the other patches in there series, i have to wounder, is the
> > > diagnostic analysis correct? Or is the RISC-V toolchain buggy?
> > >
> >
> > I retry the different methods, I found that when I directly compile
> > the macb_main.c, it can trigger the same error, and I already prove
> > the different compiler will reach the same result, so it is not a bug
> > of the compiler.
> >
> > I also found that the x86_64 defconfig does not enable CONFIG_MACB
> > because it requires CONFIG_COMMON_CLK (which is also disabled by
> > default on x86), whereas the RISC-V defconfig has both enabled.
>
> arm and arm64 are much more similar to risc-v than x86. You should
> test with those compilers. However, make allmodconfig will get you the
> common clk code on x86. Most build testing is done with this
> configuration, including the netdev CI.
>

Thanks for your suggestion to use the "allmodconfig" before the build.
I running the command: "make ARCH=arm64 CROSS_COMPILE=aarch64-
linux-gnu- KCFLAGS="-Wno-error" W=1 C=1 modules -j$(nproc) 2>&1
| tee build.log" and "make ARCH=arm CROSS_COMPILE=arm-linux-
gnueabihf- KCFLAGS="-Wno-error" W=1 C=1 modules -j$(nproc) 2>&1
| tee build.log", it throws the same warning -> [-Wformat-truncation=], so
It proves that even if I switch to a different platform, like arm, arm32,
x86_64, riscv64, it still shows the same warning.

Best regards,
Sean