[PATCH 00/15] gcc-10 warning fixes

[PATCH 00/15] gcc-10 warning fixes

[Arnd Bergmann]

Here are a couple of fixes for warnings introduced with gcc-10.
If you wish to reproduce these, you can find the compiler I used
at [1].

If you like the fixes, please apply them directly into maintainer
trees. I expect that we will also need them to be backported
into stable kernels later.

I disabled -Wrestrict on gcc in my local test tree, but with
the patches from this series and the ones I have already sent,
I see no gcc-10 specific warnings in linux-next when doing
many randconfig builds for arm/arm64/x86.

      Arnd

Arnd Bergmann (15):
  crypto - Avoid free() namespace collision
  iwlwifi: mvm: fix gcc-10 zero-length-bounds warning
  mwifiex: avoid -Wstringop-overflow warning
  ath10k: fix gcc-10 zero-length-bounds warnings
  bpf: avoid gcc-10 stringop-overflow warning
  netfilter: conntrack: avoid gcc-10 zero-length-bounds warning
  drop_monitor: work around gcc-10 stringop-overflow warning
  usb: ehci: avoid gcc-10 zero-length-bounds warning
  udf: avoid gcc-10 zero-length-bounds warnings
  hpfs: avoid gcc-10 zero-length-bounds warning
  omfs: avoid gcc-10 stringop-overflow warning
  media: s5k5baf: avoid gcc-10 zero-length-bounds warning
  scsi: sas: avoid gcc-10 zero-length-bounds warning
  isci: avoid gcc-10 zero-length-bounds warning
  nvme: avoid gcc-10 zero-length-bounds warning

 crypto/lrw.c                                  |  6 +--
 crypto/xts.c                                  |  6 +--
 drivers/media/i2c/s5k5baf.c                   |  4 +-
 drivers/net/wireless/ath/ath10k/htt.h         |  4 +-
 .../net/wireless/intel/iwlwifi/fw/api/tx.h    | 14 +++----
 .../net/wireless/marvell/mwifiex/sta_cmd.c    | 39 ++++++++-----------
 drivers/nvme/host/fc.c                        |  2 +-
 drivers/scsi/aic94xx/aic94xx_tmf.c            |  4 +-
 drivers/scsi/isci/task.h                      |  7 ++--
 drivers/scsi/libsas/sas_task.c                |  3 +-
 fs/hpfs/anode.c                               |  7 +++-
 fs/omfs/file.c                                | 12 +++---
 fs/omfs/omfs_fs.h                             |  2 +-
 fs/udf/ecma_167.h                             |  2 +-
 fs/udf/super.c                                |  2 +-
 include/linux/filter.h                        |  6 +--
 include/linux/usb/ehci_def.h                  | 12 ++++--
 include/net/netfilter/nf_conntrack.h          |  2 +-
 net/core/drop_monitor.c                       | 11 ++++--
 net/netfilter/nf_conntrack_core.c             |  4 +-
 20 files changed, 76 insertions(+), 73 deletions(-)

[1] https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/10.0.20200413/

Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: Johannes Berg <johannes.berg@intel.com>
Cc: Intel Linux Wireless <linuxwifi@intel.com>
Cc: Amitkumar Karwar <amitkarwar@gmail.com>
Cc: James Smart <james.smart@broadcom.com>
Cc: Jens Axboe <axboe@fb.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Cc: Bob Copeland <me@bobcopeland.com>
Cc: Jan Kara <jack@suse.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Florian Westphal <fw@strlen.de>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-media@vger.kernel.org
Cc: ath10k@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-nvme@lists.infradead.org
Cc: linux-scsi@vger.kernel.org
Cc: linux-karma-devel@lists.sourceforge.net
Cc: bpf@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: netfilter-devel@vger.kernel.org
Cc: coreteam@netfilter.org



-- 
2.26.0

[PATCH 13/15] scsi: sas: avoid gcc-10 zero-length-bounds warning

[Arnd Bergmann]

Two files access the zero-length resp_data[] array, which now
causes a compiler warning:

drivers/scsi/aic94xx/aic94xx_tmf.c: In function 'asd_get_tmf_resp_tasklet':
drivers/scsi/aic94xx/aic94xx_tmf.c:291:22: warning: array subscript 3 is outside the bounds of an interior zero-length array 'u8[0]' {aka 'unsigned char[0]'} [-Wzero-length-bounds]
  291 |   res = ru->resp_data[3];
      |         ~~~~~~~~~~~~~^~~
In file included from include/scsi/libsas.h:15,
                 from drivers/scsi/aic94xx/aic94xx.h:16,
                 from drivers/scsi/aic94xx/aic94xx_tmf.c:11:
include/scsi/sas.h:557:9: note: while referencing 'resp_data'
  557 |  u8     resp_data[0];
      |         ^~~~~~~~~
drivers/scsi/libsas/sas_task.c: In function 'sas_ssp_task_response':
drivers/scsi/libsas/sas_task.c:21:30: warning: array subscript 3 is outside the bounds of an interior zero-length array 'u8[0]' {aka 'unsigned char[0]'} [-Wzero-length-bounds]
   21 |   tstat->stat = iu->resp_data[3];
      |                 ~~~~~~~~~~~~~^~~
In file included from include/scsi/scsi_transport_sas.h:8,
                 from drivers/scsi/libsas/sas_internal.h:14,
                 from drivers/scsi/libsas/sas_task.c:3:
include/scsi/sas.h:557:9: note: while referencing 'resp_data'
  557 |  u8     resp_data[0];
      |         ^~~~~~~~~

This should really be a flexible-array member, but the structure
already has such a member, swapping it out with sense_data[] would
cause many more warnings elsewhere.

As a workaround, add a temporary pointer that can be accessed without
a warning.

Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver")
Fixes: 366ca51f30de ("[SCSI] libsas: abstract STP task status into a function")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/scsi/aic94xx/aic94xx_tmf.c | 4 +++-
 drivers/scsi/libsas/sas_task.c     | 3 ++-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/aic94xx/aic94xx_tmf.c b/drivers/scsi/aic94xx/aic94xx_tmf.c
index f814026f26fa..a3139f9766c8 100644
--- a/drivers/scsi/aic94xx/aic94xx_tmf.c
+++ b/drivers/scsi/aic94xx/aic94xx_tmf.c
@@ -269,6 +269,7 @@ static int asd_get_tmf_resp_tasklet(struct asd_ascb *ascb,
 	struct ssp_frame_hdr *fh;
 	struct ssp_response_iu   *ru;
 	int res = TMF_RESP_FUNC_FAILED;
+	u8 *resp;
 
 	ASD_DPRINTK("tmf resp tasklet\n");
 
@@ -287,8 +288,9 @@ static int asd_get_tmf_resp_tasklet(struct asd_ascb *ascb,
 	fh = edb->vaddr + 16;
 	ru = edb->vaddr + 16 + sizeof(*fh);
 	res = ru->status;
+	resp = ru->resp_data;
 	if (ru->datapres == 1)	  /* Response data present */
-		res = ru->resp_data[3];
+		res = resp[3];
 #if 0
 	ascb->tag = fh->tag;
 #endif
diff --git a/drivers/scsi/libsas/sas_task.c b/drivers/scsi/libsas/sas_task.c
index e2d42593ce52..4cd2f9611c4a 100644
--- a/drivers/scsi/libsas/sas_task.c
+++ b/drivers/scsi/libsas/sas_task.c
@@ -12,13 +12,14 @@ void sas_ssp_task_response(struct device *dev, struct sas_task *task,
 			   struct ssp_response_iu *iu)
 {
 	struct task_status_struct *tstat = &task->task_status;
+	u8 *resp = iu->resp_data;
 
 	tstat->resp = SAS_TASK_COMPLETE;
 
 	if (iu->datapres == 0)
 		tstat->stat = iu->status;
 	else if (iu->datapres == 1)
-		tstat->stat = iu->resp_data[3];
+		tstat->stat = resp[3];
 	else if (iu->datapres == 2) {
 		tstat->stat = SAM_STAT_CHECK_CONDITION;
 		tstat->buf_valid_size =
-- 
2.26.0

[PATCH 14/15] isci: avoid gcc-10 zero-length-bounds warning

[Arnd Bergmann]

gcc-10 warns about accesses to zero-length arrays:

drivers/scsi/isci/task.h:125:31: error: array subscript 0 is outside the bounds of an interior zero-length array 'u8[0]' {aka 'unsigned char[0]'} [-Werror=zero-length-bounds]
  125 |    tmf->resp.resp_iu.resp_data[0],
      |    ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
include/linux/dynamic_debug.h:143:2: note: in expansion of macro '__dynamic_func_call'
  143 |  __dynamic_func_call(__UNIQUE_ID(ddebug), fmt, func, ##__VA_ARGS__)
      |  ^~~~~~~~~~~~~~~~~~~
include/linux/dynamic_debug.h:157:2: note: in expansion of macro '_dynamic_func_call'
  157 |  _dynamic_func_call(fmt,__dynamic_dev_dbg,   \
      |  ^~~~~~~~~~~~~~~~~~
include/linux/dev_printk.h:115:2: note: in expansion of macro 'dynamic_dev_dbg'
  115 |  dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
      |  ^~~~~~~~~~~~~~~
drivers/scsi/isci/task.h:111:3: note: in expansion of macro 'dev_dbg'
  111 |   dev_dbg(&ihost->pdev->dev,
      |   ^~~~~~~
In file included from include/scsi/libsas.h:15,
                 from drivers/scsi/isci/task.c:59:
include/scsi/sas.h:326:9: note: while referencing 'resp_data'
  326 |  u8     resp_data[0];
      |         ^~~~~~~~~

This instance is not a bug, so just work around the warning by
adding a temporary pointer.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/scsi/isci/task.h | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/isci/task.h b/drivers/scsi/isci/task.h
index 8f4531f22ac2..2d556d7b5292 100644
--- a/drivers/scsi/isci/task.h
+++ b/drivers/scsi/isci/task.h
@@ -98,6 +98,8 @@ struct isci_tmf {
 
 static inline void isci_print_tmf(struct isci_host *ihost, struct isci_tmf *tmf)
 {
+	u8 *resp = tmf->resp.resp_iu.resp_data;
+
 	if (SAS_PROTOCOL_SATA == tmf->proto)
 		dev_dbg(&ihost->pdev->dev,
 			"%s: status = %x\n"
@@ -122,10 +124,7 @@ static inline void isci_print_tmf(struct isci_host *ihost, struct isci_tmf *tmf)
 			tmf->resp.resp_iu.datapres,
 			tmf->resp.resp_iu.status,
 			be32_to_cpu(tmf->resp.resp_iu.response_data_len),
-			tmf->resp.resp_iu.resp_data[0],
-			tmf->resp.resp_iu.resp_data[1],
-			tmf->resp.resp_iu.resp_data[2],
-			tmf->resp.resp_iu.resp_data[3]);
+			resp[0], resp[1], resp[2], resp[3]);
 }
 
 
-- 
2.26.0

Re: [PATCH 13/15] scsi: sas: avoid gcc-10 zero-length-bounds warning

[John Garry]

On 30/04/2020 22:30, Arnd Bergmann wrote:
> Two files access the zero-length resp_data[] array, which now
> causes a compiler warning:
> 
> drivers/scsi/aic94xx/aic94xx_tmf.c: In function 'asd_get_tmf_resp_tasklet':
> drivers/scsi/aic94xx/aic94xx_tmf.c:291:22: warning: array subscript 3 is outside the bounds of an interior zero-length array 'u8[0]' {aka 'unsigned char[0]'} [-Wzero-length-bounds]
>    291 |   res = ru->resp_data[3];
>        |         ~~~~~~~~~~~~~^~~
> In file included from include/scsi/libsas.h:15,
>                   from drivers/scsi/aic94xx/aic94xx.h:16,
>                   from drivers/scsi/aic94xx/aic94xx_tmf.c:11:
> include/scsi/sas.h:557:9: note: while referencing 'resp_data'
>    557 |  u8     resp_data[0];
>        |         ^~~~~~~~~
> drivers/scsi/libsas/sas_task.c: In function 'sas_ssp_task_response':
> drivers/scsi/libsas/sas_task.c:21:30: warning: array subscript 3 is outside the bounds of an interior zero-length array 'u8[0]' {aka 'unsigned char[0]'} [-Wzero-length-bounds]
>     21 |   tstat->stat = iu->resp_data[3];
>        |                 ~~~~~~~~~~~~~^~~
> In file included from include/scsi/scsi_transport_sas.h:8,
>                   from drivers/scsi/libsas/sas_internal.h:14,
>                   from drivers/scsi/libsas/sas_task.c:3:
> include/scsi/sas.h:557:9: note: while referencing 'resp_data'
>    557 |  u8     resp_data[0];
>        |         ^~~~~~~~~
> 
> This should really be a flexible-array member, but the structure
> already has such a member, swapping it out with sense_data[] would
> cause many more warnings elsewhere.
> 


Hi Arnd,

If we really prefer flexible-array members over zero-length array 
members, then could we have a union of flexible-array members? I'm not 
sure if that's a good idea TBH (or even permitted), as these structures 
are defined by the SAS spec and good practice to keep as consistent as 
possible, but just wondering.

Apart from that:

Reviewed-by: John Garry <john.garry@huawei.com>

> As a workaround, add a temporary pointer that can be accessed without
> a warning.
> 
> Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver")
> Fixes: 366ca51f30de ("[SCSI] libsas: abstract STP task status into a function")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>   drivers/scsi/aic94xx/aic94xx_tmf.c | 4 +++-
>   drivers/scsi/libsas/sas_task.c     | 3 ++-
>   2 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/aic94xx/aic94xx_tmf.c b/drivers/scsi/aic94xx/aic94xx_tmf.c
> index f814026f26fa..a3139f9766c8 100644
> --- a/drivers/scsi/aic94xx/aic94xx_tmf.c
> +++ b/drivers/scsi/aic94xx/aic94xx_tmf.c
> @@ -269,6 +269,7 @@ static int asd_get_tmf_resp_tasklet(struct asd_ascb *ascb,
>   	struct ssp_frame_hdr *fh;
>   	struct ssp_response_iu   *ru;
>   	int res = TMF_RESP_FUNC_FAILED;
> +	u8 *resp;
>   
>   	ASD_DPRINTK("tmf resp tasklet\n");
>   
> @@ -287,8 +288,9 @@ static int asd_get_tmf_resp_tasklet(struct asd_ascb *ascb,
>   	fh = edb->vaddr + 16;
>   	ru = edb->vaddr + 16 + sizeof(*fh);
>   	res = ru->status;
> +	resp = ru->resp_data;
>   	if (ru->datapres == 1)	  /* Response data present */
> -		res = ru->resp_data[3];
> +		res = resp[3];
>   #if 0
>   	ascb->tag = fh->tag;
>   #endif
> diff --git a/drivers/scsi/libsas/sas_task.c b/drivers/scsi/libsas/sas_task.c
> index e2d42593ce52..4cd2f9611c4a 100644
> --- a/drivers/scsi/libsas/sas_task.c
> +++ b/drivers/scsi/libsas/sas_task.c
> @@ -12,13 +12,14 @@ void sas_ssp_task_response(struct device *dev, struct sas_task *task,
>   			   struct ssp_response_iu *iu)
>   {
>   	struct task_status_struct *tstat = &task->task_status;
> +	u8 *resp = iu->resp_data;
>   
>   	tstat->resp = SAS_TASK_COMPLETE;
>   
>   	if (iu->datapres == 0)
>   		tstat->stat = iu->status;
>   	else if (iu->datapres == 1)
> -		tstat->stat = iu->resp_data[3];
> +		tstat->stat = resp[3];
>   	else if (iu->datapres == 2) {
>   		tstat->stat = SAM_STAT_CHECK_CONDITION;
>   		tstat->buf_valid_size =
> 

Re: [PATCH 13/15] scsi: sas: avoid gcc-10 zero-length-bounds warning

[Arnd Bergmann]

On Fri, May 1, 2020 at 9:48 AM John Garry <john.garry@huawei.com> wrote:
> On 30/04/2020 22:30, Arnd Bergmann wrote:

> > This should really be a flexible-array member, but the structure
> > already has such a member, swapping it out with sense_data[] would
> > cause many more warnings elsewhere.
> >
>
>
> Hi Arnd,
>
> If we really prefer flexible-array members over zero-length array
> members, then could we have a union of flexible-array members? I'm not
> sure if that's a good idea TBH (or even permitted), as these structures
> are defined by the SAS spec and good practice to keep as consistent as
> possible, but just wondering.

gcc does not allow flexible-array members inside of a union, or more than
one flexible-array member at the end of a structure.

I found one hack that would work, but I think it's too ugly and likely not
well-defined either:

struct ssp_response_iu {
...
        struct {
                u8      dummy[0]; /* a struct must have at least one
non-flexible member */
                u8      resp_data[]; /* allowed here because it's at
the one of a struct */
        };
        u8     sense_data[];
} __attribute__ ((packed));

> Apart from that:
>
> Reviewed-by: John Garry <john.garry@huawei.com>

Thanks!

     Arnd

Re: [PATCH 13/15] scsi: sas: avoid gcc-10 zero-length-bounds warning

[James Bottomley]

On Fri, 2020-05-01 at 09:54 +0200, Arnd Bergmann wrote:
> On Fri, May 1, 2020 at 9:48 AM John Garry <john.garry@huawei.com>
> wrote:
> > On 30/04/2020 22:30, Arnd Bergmann wrote:
> > > This should really be a flexible-array member, but the structure
> > > already has such a member, swapping it out with sense_data[]
> > > would cause many more warnings elsewhere.
> > > 
> > 
> > 
> > Hi Arnd,
> > 
> > If we really prefer flexible-array members over zero-length array
> > members, then could we have a union of flexible-array members? I'm
> > not sure if that's a good idea TBH (or even permitted), as these
> > structures are defined by the SAS spec and good practice to keep as
> > consistent as possible, but just wondering.
> 
> gcc does not allow flexible-array members inside of a union, or more
> than one flexible-array member at the end of a structure.
> 
> I found one hack that would work, but I think it's too ugly and
> likely not well-defined either:
> 
> struct ssp_response_iu {
> ...
>         struct {
>                 u8      dummy[0]; /* a struct must have at least one
> non-flexible member */

If gcc is now warning about zero length members, why isn't it warning
about this one ... are unions temporarily excluded?

>                 u8      resp_data[]; /* allowed here because it's at
> the one of a struct */
>         };
>         u8     sense_data[];
> } __attribute__ ((packed));

Let's go back to what the standard says:  we want the data beyond the
ssp_response_iu to be addressable either as sense_data if it's an error
return or resp_data if it's a real response.  What about trying to use
an alias attribute inside the structure ... will that work on gcc-10?

James

Re: [PATCH 13/15] scsi: sas: avoid gcc-10 zero-length-bounds warning

[Arnd Bergmann]

On Fri, May 1, 2020 at 4:53 PM James Bottomley <jejb@linux.ibm.com> wrote:
> On Fri, 2020-05-01 at 09:54 +0200, Arnd Bergmann wrote:
> > On Fri, May 1, 2020 at 9:48 AM John Garry <john.garry@huawei.com>
> > wrote:
> > I found one hack that would work, but I think it's too ugly and
> > likely not well-defined either:
> >
> > struct ssp_response_iu {
> > ...
> >         struct {
> >                 u8      dummy[0]; /* a struct must have at least one
> > non-flexible member */
>
> If gcc is now warning about zero length members, why isn't it warning
> about this one ... are unions temporarily excluded?

It does not warn about all zero-length arrays, but it does warn when you
try to access an array with an out-of-range index, and this apparently
got extended in gcc-10 to any index for zero-length arrays.

> >                 u8      resp_data[]; /* allowed here because it's at
> > the one of a struct */
> >         };
> >         u8     sense_data[];
> > } __attribute__ ((packed));
>
> Let's go back to what the standard says:  we want the data beyond the
> ssp_response_iu to be addressable either as sense_data if it's an error
> return or resp_data if it's a real response.  What about trying to use
> an alias attribute inside the structure ... will that work on gcc-10?

I think alias attributes only work for functions and variables, but not
for struct members.

A "#define sense_data resp_data" would obviously work, but it's
rather error-prone when other code uses the same identifiers.

Another option would be an inline helper like

static inline u8 *ssp_response_data(struct ssp_response_iu *iu)
{
      return iu.resp_data;
}

      Arnd