[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240926040138.GA16982@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
Date: Wed, 25 Sep 2024 21:01:38 -0700
From: Saurabh Singh Sengar <ssengar@...ux.microsoft.com>
To: Dexuan Cui <decui@...rosoft.com>
Cc: KY Srinivasan <kys@...rosoft.com>,
Haiyang Zhang <haiyangz@...rosoft.com>,
Wei Liu <wei.liu@...nel.org>, Long Li <longli@...rosoft.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"open list:Hyper-V/Azure CORE AND DRIVERS" <linux-hyperv@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>,
"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH] tools: hv: Fix a complier warning in the fcopy uio daemon
On Tue, Sep 24, 2024 at 11:22:50AM -0700, Saurabh Singh Sengar wrote:
> On Sat, Sep 21, 2024 at 01:23:09AM +0000, Dexuan Cui wrote:
> > > From: Saurabh Singh Sengar <ssengar@...ux.microsoft.com>
> > > Sent: Friday, September 13, 2024 12:31 AM
> > > To: Dexuan Cui <decui@...rosoft.com>
> > > Cc: KY Srinivasan <kys@...rosoft.com>; Haiyang Zhang
> > > <haiyangz@...rosoft.com>; Wei Liu <wei.liu@...nel.org>; Long Li
> > > <longli@...rosoft.com>; Greg Kroah-Hartman
> > > <gregkh@...uxfoundation.org>; open list:Hyper-V/Azure CORE AND DRIVERS
> > > <linux-hyperv@...r.kernel.org>; open list <linux-kernel@...r.kernel.org>;
> > > stable@...r.kernel.org
> > > Subject: Re: [PATCH] tools: hv: Fix a complier warning in the fcopy uio
> > > daemon
> > >
> > > On Tue, Sep 10, 2024 at 12:44:32AM +0000, Dexuan Cui wrote:
> > > > hv_fcopy_uio_daemon.c:436:53: warning: '%s' directive output may be
> > > truncated
> > > > writing up to 14 bytes into a region of size 10 [-Wformat-truncation=]
> > > > 436 | snprintf(uio_dev_path, sizeof(uio_dev_path), "/dev/%s",
> > > uio_name);
> > >
> > > Makefile today doesn't have -Wformat-truncation flag enabled, I tried to add
> > > -Wformat-truncation=2 but I don't see any error in this file.
> > >
> > > Do you mind sharing more details how you get this error ?
> > >
> > > - Saurabh
> >
> > This repros in a Ubuntu 20.04 VM:
> >
> > root@...ui-u2004-2024-0920:~/linux/tools/hv# cat /etc/os-release
> > NAME="Ubuntu"
> > VERSION="20.04.6 LTS (Focal Fossa)"
> > ...
> >
> > root@...ui-u2004-2024-0920:~/linux/tools/hv# gcc --version
> > gcc (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0
> > Copyright (C) 2019 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions. There is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> >
> > root@...ui-u2004-2024-0920:~/linux/tools/hv# make clean; make
> > ...
> > make -f /root/linux/tools/build/Makefile.build dir=. obj=hv_fcopy_uio_daemon
> > make[1]: Entering directory '/root/linux/tools/hv'
> > CC hv_fcopy_uio_daemon.o
> > hv_fcopy_uio_daemon.c: In function 'main':
> > hv_fcopy_uio_daemon.c:443:53: warning: '%s' directive output may be truncated writing up to 14 bytes into a region of size 10 [-Wformat-truncation=]
> > 443 | snprintf(uio_dev_path, sizeof(uio_dev_path), "/dev/%s", uio_name);
> > | ^~ ~~~~~~~~
> > In file included from /usr/include/stdio.h:867,
> > from hv_fcopy_uio_daemon.c:20:
> > /usr/include/x86_64-linux-gnu/bits/stdio2.h:67:10: note: '__builtin___snprintf_chk' output between 6 and 20 bytes into a destination of size 15
> > 67 | return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
> > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > 68 | __bos (__s), __fmt, __va_arg_pack ());
> > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > CC vmbus_bufring.o
> > LD hv_fcopy_uio_daemon-in.o
> > make[1]: Leaving directory '/root/linux/tools/hv'
> > LINK hv_fcopy_uio_daemon
>
> Thanks for the details. Looks this is the behaviour of old gcc versions.
> How about fixing it like this :
>
> --- a/tools/hv/hv_fcopy_uio_daemon.c
> +++ b/tools/hv/hv_fcopy_uio_daemon.c
> @@ -35,7 +35,7 @@
> #define WIN8_SRV_MINOR 1
> #define WIN8_SRV_VERSION (WIN8_SRV_MAJOR << 16 | WIN8_SRV_MINOR)
>
> -#define MAX_FOLDER_NAME 15
> +#define MAX_FOLDER_NAME 10
> #define MAX_PATH_LEN 15
>
>
Had a offline discussion with Dexuan.
The above suggested approach saves few bytes of userspace memory,
using standard macros for path and folder length would be
preferable for better code readability
Please add,
Reviewed-by: Saurabh Sengar <ssengar@...ux.microsoft.com>
- Saurabh
Powered by blists - more mailing lists