[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 01/15] crypto - Avoid free() namespace collision

[Arnd Bergmann]

gcc-10 complains about using the name of a standard library
function in the kernel, as we are not building with -ffreestanding:

crypto/xts.c:325:13: error: conflicting types for built-in function 'free'; expected 'void(void *)' [-Werror=builtin-declaration-mismatch]
  325 | static void free(struct skcipher_instance *inst)
      |             ^~~~
crypto/lrw.c:290:13: error: conflicting types for built-in function 'free'; expected 'void(void *)' [-Werror=builtin-declaration-mismatch]
  290 | static void free(struct skcipher_instance *inst)
      |             ^~~~
crypto/lrw.c:27:1: note: 'free' is declared in header '<stdlib.h>'

The xts and lrw cipher implementations run into this because they do
not use the conventional namespaced function names.

It might be better to rename all local functions in those files to
help with things like 'ctags' and 'grep', but just renaming these two
avoids the build issue. I picked the more verbose crypto_xts_free()
and crypto_lrw_free() names for consistency with several other drivers
that do use namespaced function names.

Fixes: f1c131b45410 ("crypto: xts - Convert to skcipher")
Fixes: 700cb3f5fe75 ("crypto: lrw - Convert to skcipher")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 crypto/lrw.c | 6 +++---
 crypto/xts.c | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/crypto/lrw.c b/crypto/lrw.c
index 376d7ed3f1f8..5b07a7c09296 100644
--- a/crypto/lrw.c
+++ b/crypto/lrw.c
@@ -287,7 +287,7 @@ static void exit_tfm(struct crypto_skcipher *tfm)
 	crypto_free_skcipher(ctx->child);
 }
 
-static void free(struct skcipher_instance *inst)
+static void crypto_lrw_free(struct skcipher_instance *inst)
 {
 	crypto_drop_skcipher(skcipher_instance_ctx(inst));
 	kfree(inst);
@@ -400,12 +400,12 @@ static int create(struct crypto_template *tmpl, struct rtattr **tb)
 	inst->alg.encrypt = encrypt;
 	inst->alg.decrypt = decrypt;
 
-	inst->free = free;
+	inst->free = crypto_lrw_free;
 
 	err = skcipher_register_instance(tmpl, inst);
 	if (err) {
 err_free_inst:
-		free(inst);
+		crypto_lrw_free(inst);
 	}
 	return err;
 }
diff --git a/crypto/xts.c b/crypto/xts.c
index dbdd8af629e6..3565f3b863a6 100644
--- a/crypto/xts.c
+++ b/crypto/xts.c
@@ -322,7 +322,7 @@ static void exit_tfm(struct crypto_skcipher *tfm)
 	crypto_free_cipher(ctx->tweak);
 }
 
-static void free(struct skcipher_instance *inst)
+static void crypto_xts_free(struct skcipher_instance *inst)
 {
 	crypto_drop_skcipher(skcipher_instance_ctx(inst));
 	kfree(inst);
@@ -434,12 +434,12 @@ static int create(struct crypto_template *tmpl, struct rtattr **tb)
 	inst->alg.encrypt = encrypt;
 	inst->alg.decrypt = decrypt;
 
-	inst->free = free;
+	inst->free = crypto_xts_free;
 
 	err = skcipher_register_instance(tmpl, inst);
 	if (err) {
 err_free_inst:
-		free(inst);
+		crypto_xts_free(inst);
 	}
 	return err;
 }
-- 
2.26.0

[PATCH 02/15] iwlwifi: mvm: fix gcc-10 zero-length-bounds warning

[Arnd Bergmann]

gcc-10 complains when a zero-length array is accessed:

drivers/net/wireless/intel/iwlwifi/mvm/tx.c: In function 'iwl_mvm_rx_ba_notif':
drivers/net/wireless/intel/iwlwifi/mvm/tx.c:1929:17: warning: array subscript 9 is outside the bounds of an interior zero-length array 'struct iwl_mvm_compressed_ba_tfd[0]' [-Wzero-length-bounds]
 1929 |     &ba_res->tfd[i];
      |      ~~~~~~~~~~~^~~
In file included from drivers/net/wireless/intel/iwlwifi/mvm/../fw/api/tdls.h:68,
                 from drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h:68,
                 from drivers/net/wireless/intel/iwlwifi/mvm/sta.h:73,
                 from drivers/net/wireless/intel/iwlwifi/mvm/mvm.h:83,
                 from drivers/net/wireless/intel/iwlwifi/mvm/tx.c:72:
drivers/net/wireless/intel/iwlwifi/mvm/../fw/api/tx.h:769:35: note: while referencing 'tfd'
  769 |  struct iwl_mvm_compressed_ba_tfd tfd[0];
      |                                   ^~~

Change this structure to use a flexible-array member for 'tfd' instead,
along with the various structures using an zero-length ieee80211_hdr
array that do not show warnings today but might be affected by similar
issues in the future.

Fixes: 6f68cc367ab6 ("iwlwifi: api: annotate compressed BA notif array sizes")
Fixes: c46e7724bfe9 ("iwlwifi: mvm: support new BA notification response")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/net/wireless/intel/iwlwifi/fw/api/tx.h | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/fw/api/tx.h b/drivers/net/wireless/intel/iwlwifi/fw/api/tx.h
index f1d1fe96fecc..82d59b5a5f8c 100644
--- a/drivers/net/wireless/intel/iwlwifi/fw/api/tx.h
+++ b/drivers/net/wireless/intel/iwlwifi/fw/api/tx.h
@@ -293,7 +293,7 @@ struct iwl_tx_cmd {
 	__le16 pm_frame_timeout;
 	__le16 reserved4;
 	u8 payload[0];
-	struct ieee80211_hdr hdr[0];
+	struct ieee80211_hdr hdr[];
 } __packed; /* TX_CMD_API_S_VER_6 */
 
 struct iwl_dram_sec_info {
@@ -319,7 +319,7 @@ struct iwl_tx_cmd_gen2 {
 	__le32 flags;
 	struct iwl_dram_sec_info dram_info;
 	__le32 rate_n_flags;
-	struct ieee80211_hdr hdr[0];
+	struct ieee80211_hdr hdr[];
 } __packed; /* TX_CMD_API_S_VER_7 */
 
 /**
@@ -342,7 +342,7 @@ struct iwl_tx_cmd_gen3 {
 	struct iwl_dram_sec_info dram_info;
 	__le32 rate_n_flags;
 	__le64 ttl;
-	struct ieee80211_hdr hdr[0];
+	struct ieee80211_hdr hdr[];
 } __packed; /* TX_CMD_API_S_VER_8 */
 
 /*
@@ -766,8 +766,8 @@ struct iwl_mvm_compressed_ba_notif {
 	__le32 tx_rate;
 	__le16 tfd_cnt;
 	__le16 ra_tid_cnt;
-	struct iwl_mvm_compressed_ba_tfd tfd[0];
 	struct iwl_mvm_compressed_ba_ratid ra_tid[0];
+	struct iwl_mvm_compressed_ba_tfd tfd[];
 } __packed; /* COMPRESSED_BA_RES_API_S_VER_4 */
 
 /**
@@ -784,7 +784,7 @@ struct iwl_mac_beacon_cmd_v6 {
 	__le32 template_id;
 	__le32 tim_idx;
 	__le32 tim_size;
-	struct ieee80211_hdr frame[0];
+	struct ieee80211_hdr frame[];
 } __packed; /* BEACON_TEMPLATE_CMD_API_S_VER_6 */
 
 /**
@@ -805,7 +805,7 @@ struct iwl_mac_beacon_cmd_v7 {
 	__le32 tim_size;
 	__le32 ecsa_offset;
 	__le32 csa_offset;
-	struct ieee80211_hdr frame[0];
+	struct ieee80211_hdr frame[];
 } __packed; /* BEACON_TEMPLATE_CMD_API_S_VER_7 */
 
 enum iwl_mac_beacon_flags {
@@ -840,7 +840,7 @@ struct iwl_mac_beacon_cmd {
 	__le32 tim_size;
 	__le32 ecsa_offset;
 	__le32 csa_offset;
-	struct ieee80211_hdr frame[0];
+	struct ieee80211_hdr frame[];
 } __packed; /* BEACON_TEMPLATE_CMD_API_S_VER_10 */
 
 struct iwl_beacon_notif {
-- 
2.26.0

[PATCH 03/15] mwifiex: avoid -Wstringop-overflow warning

[Arnd Bergmann]

gcc-10 reports a warning for mwifiex_cmd_802_11_key_material_v1:

drivers/net/wireless/marvell/mwifiex/sta_cmd.c: In function 'mwifiex_cmd_802_11_key_material_v1':
cc1: warning: writing 16 bytes into a region of size 0 [-Wstringop-overflow=]
In file included from drivers/net/wireless/marvell/mwifiex/sta_cmd.c:23:
drivers/net/wireless/marvell/mwifiex/fw.h:993:9: note: at offset 0 to object 'action' with size 2 declared here
  993 |  __le16 action;
      |         ^~~~~~

As the warning makes no sense, I reported it as a bug for gcc. In the
meantime using a temporary pointer for the key data makes the code easier
to read and stops the warning.

Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94881
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 .../net/wireless/marvell/mwifiex/sta_cmd.c    | 39 ++++++++-----------
 1 file changed, 16 insertions(+), 23 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index 0bd93f26bd7f..8bd355d7974e 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -853,43 +853,36 @@ mwifiex_cmd_802_11_key_material_v1(struct mwifiex_private *priv,
 		memset(&key_material->key_param_set, 0,
 		       sizeof(struct mwifiex_ie_type_key_param_set));
 	if (enc_key->is_wapi_key) {
+		struct mwifiex_ie_type_key_param_set *set;
+
 		mwifiex_dbg(priv->adapter, INFO, "info: Set WAPI Key\n");
-		key_material->key_param_set.key_type_id =
-						cpu_to_le16(KEY_TYPE_ID_WAPI);
+		set = &key_material->key_param_set;
+		set->key_type_id = cpu_to_le16(KEY_TYPE_ID_WAPI);
 		if (cmd_oid == KEY_INFO_ENABLED)
-			key_material->key_param_set.key_info =
-						cpu_to_le16(KEY_ENABLED);
+			set->key_info = cpu_to_le16(KEY_ENABLED);
 		else
-			key_material->key_param_set.key_info =
-						cpu_to_le16(!KEY_ENABLED);
+			set->key_info = cpu_to_le16(!KEY_ENABLED);
 
-		key_material->key_param_set.key[0] = enc_key->key_index;
+		set->key[0] = enc_key->key_index;
 		if (!priv->sec_info.wapi_key_on)
-			key_material->key_param_set.key[1] = 1;
+			set->key[1] = 1;
 		else
 			/* set 0 when re-key */
-			key_material->key_param_set.key[1] = 0;
+			set->key[1] = 0;
 
 		if (!is_broadcast_ether_addr(enc_key->mac_addr)) {
 			/* WAPI pairwise key: unicast */
-			key_material->key_param_set.key_info |=
-				cpu_to_le16(KEY_UNICAST);
+			set->key_info |= cpu_to_le16(KEY_UNICAST);
 		} else {	/* WAPI group key: multicast */
-			key_material->key_param_set.key_info |=
-				cpu_to_le16(KEY_MCAST);
+			set->key_info |= cpu_to_le16(KEY_MCAST);
 			priv->sec_info.wapi_key_on = true;
 		}
 
-		key_material->key_param_set.type =
-					cpu_to_le16(TLV_TYPE_KEY_MATERIAL);
-		key_material->key_param_set.key_len =
-						cpu_to_le16(WAPI_KEY_LEN);
-		memcpy(&key_material->key_param_set.key[2],
-		       enc_key->key_material, enc_key->key_len);
-		memcpy(&key_material->key_param_set.key[2 + enc_key->key_len],
-		       enc_key->pn, PN_LEN);
-		key_material->key_param_set.length =
-			cpu_to_le16(WAPI_KEY_LEN + KEYPARAMSET_FIXED_LEN);
+		set->type = cpu_to_le16(TLV_TYPE_KEY_MATERIAL);
+		set->key_len = cpu_to_le16(WAPI_KEY_LEN);
+		memcpy(&set->key[2], enc_key->key_material, enc_key->key_len);
+		memcpy(&set->key[2 + enc_key->key_len], enc_key->pn, PN_LEN);
+		set->length = cpu_to_le16(WAPI_KEY_LEN + KEYPARAMSET_FIXED_LEN);
 
 		key_param_len = (WAPI_KEY_LEN + KEYPARAMSET_FIXED_LEN) +
 				 sizeof(struct mwifiex_ie_types_header);
-- 
2.26.0

[PATCH 04/15] ath10k: fix gcc-10 zero-length-bounds warnings

[Arnd Bergmann]

gcc-10 started warning about out-of-bounds access for zero-length
arrays:

In file included from drivers/net/wireless/ath/ath10k/core.h:18,
                 from drivers/net/wireless/ath/ath10k/htt_rx.c:8:
drivers/net/wireless/ath/ath10k/htt_rx.c: In function 'ath10k_htt_rx_tx_fetch_ind':
drivers/net/wireless/ath/ath10k/htt.h:1683:17: warning: array subscript 65535 is outside the bounds of an interior zero-length array 'struct htt_tx_fetch_record[0]' [-Wzero-length-bounds]
 1683 |  return (void *)&ind->records[le16_to_cpu(ind->num_records)];
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/ath/ath10k/htt.h:1676:29: note: while referencing 'records'
 1676 |  struct htt_tx_fetch_record records[0];
      |                             ^~~~~~~

The structure was already converted to have a flexible-array member in
the past, but there are two zero-length members in the end and only
one of them can be a flexible-array member.

Swap the two around to avoid the warning, as 'resp_ids' is not accessed
in a way that causes a warning.

Fixes: 3ba225b506a2 ("treewide: Replace zero-length array with flexible-array member")
Fixes: 22e6b3bc5d96 ("ath10k: add new htt definitions")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/net/wireless/ath/ath10k/htt.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt.h b/drivers/net/wireless/ath/ath10k/htt.h
index e7096a73c6ca..7621f0a3dc77 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -1673,8 +1673,8 @@ struct htt_tx_fetch_ind {
 	__le32 token;
 	__le16 num_resp_ids;
 	__le16 num_records;
-	struct htt_tx_fetch_record records[0];
-	__le32 resp_ids[]; /* ath10k_htt_get_tx_fetch_ind_resp_ids() */
+	__le32 resp_ids[0]; /* ath10k_htt_get_tx_fetch_ind_resp_ids() */
+	struct htt_tx_fetch_record records[];
 } __packed;
 
 static inline void *
-- 
2.26.0

[PATCH 05/15] bpf: avoid gcc-10 stringop-overflow warning

[Arnd Bergmann]

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

kernel/bpf/core.c: In function 'bpf_patch_insn_single':
cc1: warning: writing 8 bytes into a region of size 0 [-Wstringop-overflow=]
In file included from kernel/bpf/core.c:21:
include/linux/filter.h:550:20: note: at offset 0 to object 'insnsi' with size 0 declared here
  550 |   struct bpf_insn  insnsi[0];
      |                    ^~~~~~

In this case, we really want to have two flexible-array members,
but that is not possible. Removing the union to make insnsi a
flexible-array member while leaving insns as a zero-length array
fixes the warning, as nothing writes to the other one in that way.

This trick only works on linux-3.18 or higher, as older versions
had additional members in the union.

Fixes: 60a3b2253c41 ("net: bpf: make eBPF interpreter images read-only")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 include/linux/filter.h | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/include/linux/filter.h b/include/linux/filter.h
index af37318bb1c5..73d06a39e2d6 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -545,10 +545,8 @@ struct bpf_prog {
 	unsigned int		(*bpf_func)(const void *ctx,
 					    const struct bpf_insn *insn);
 	/* Instructions for interpreter */
-	union {
-		struct sock_filter	insns[0];
-		struct bpf_insn		insnsi[0];
-	};
+	struct sock_filter	insns[0];
+	struct bpf_insn		insnsi[];
 };
 
 struct sk_filter {
-- 
2.26.0

[PATCH 06/15] netfilter: conntrack: avoid gcc-10 zero-length-bounds warning

[Arnd Bergmann]

gcc-10 warns around a suspicious access to an empty struct member:

net/netfilter/nf_conntrack_core.c: In function '__nf_conntrack_alloc':
net/netfilter/nf_conntrack_core.c:1522:9: warning: array subscript 0 is outside the bounds of an interior zero-length array 'u8[0]' {aka 'unsigned char[0]'} [-Wzero-length-bounds]
 1522 |  memset(&ct->__nfct_init_offset[0], 0,
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from net/netfilter/nf_conntrack_core.c:37:
include/net/netfilter/nf_conntrack.h:90:5: note: while referencing '__nfct_init_offset'
   90 |  u8 __nfct_init_offset[0];
      |     ^~~~~~~~~~~~~~~~~~

The code is correct but a bit unusual. Rework it slightly in a way that
does not trigger the warning, using an empty struct instead of an empty
array. There are probably more elegant ways to do this, but this is the
smallest change.

Fixes: c41884ce0562 ("netfilter: conntrack: avoid zeroing timer")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 include/net/netfilter/nf_conntrack.h | 2 +-
 net/netfilter/nf_conntrack_core.c    | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/net/netfilter/nf_conntrack.h b/include/net/netfilter/nf_conntrack.h
index 9f551f3b69c6..90690e37a56f 100644
--- a/include/net/netfilter/nf_conntrack.h
+++ b/include/net/netfilter/nf_conntrack.h
@@ -87,7 +87,7 @@ struct nf_conn {
 	struct hlist_node	nat_bysource;
 #endif
 	/* all members below initialized via memset */
-	u8 __nfct_init_offset[0];
+	struct { } __nfct_init_offset;
 
 	/* If we were expected by an expectation, this will be it */
 	struct nf_conn *master;
diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
index c4582eb71766..0173398f4ced 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -1519,9 +1519,9 @@ __nf_conntrack_alloc(struct net *net,
 	ct->status = 0;
 	ct->timeout = 0;
 	write_pnet(&ct->ct_net, net);
-	memset(&ct->__nfct_init_offset[0], 0,
+	memset(&ct->__nfct_init_offset, 0,
 	       offsetof(struct nf_conn, proto) -
-	       offsetof(struct nf_conn, __nfct_init_offset[0]));
+	       offsetof(struct nf_conn, __nfct_init_offset));
 
 	nf_ct_zone_add(ct, zone);
 
-- 
2.26.0

[PATCH 07/15] drop_monitor: work around gcc-10 stringop-overflow warning

[Arnd Bergmann]

The current gcc-10 snapshot produces a false-positive warning:

net/core/drop_monitor.c: In function 'trace_drop_common.constprop':
cc1: error: writing 8 bytes into a region of size 0 [-Werror=stringop-overflow=]
In file included from net/core/drop_monitor.c:23:
include/uapi/linux/net_dropmon.h:36:8: note: at offset 0 to object 'entries' with size 4 declared here
   36 |  __u32 entries;
      |        ^~~~~~~

I reported this in the gcc bugzilla, but in case it does not get
fixed in the release, work around it by using a temporary variable.

Fixes: 9a8afc8d3962 ("Network Drop Monitor: Adding drop monitor implementation & Netlink protocol")
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94881
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 net/core/drop_monitor.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/net/core/drop_monitor.c b/net/core/drop_monitor.c
index 8e33cec9fc4e..2ee7bc4c9e03 100644
--- a/net/core/drop_monitor.c
+++ b/net/core/drop_monitor.c
@@ -213,6 +213,7 @@ static void sched_send_work(struct timer_list *t)
 static void trace_drop_common(struct sk_buff *skb, void *location)
 {
 	struct net_dm_alert_msg *msg;
+	struct net_dm_drop_point *point;
 	struct nlmsghdr *nlh;
 	struct nlattr *nla;
 	int i;
@@ -231,11 +232,13 @@ static void trace_drop_common(struct sk_buff *skb, void *location)
 	nlh = (struct nlmsghdr *)dskb->data;
 	nla = genlmsg_data(nlmsg_data(nlh));
 	msg = nla_data(nla);
+	point = msg->points;
 	for (i = 0; i < msg->entries; i++) {
-		if (!memcmp(&location, msg->points[i].pc, sizeof(void *))) {
-			msg->points[i].count++;
+		if (!memcmp(&location, &point->pc, sizeof(void *))) {
+			point->count++;
 			goto out;
 		}
+		point++;
 	}
 	if (msg->entries == dm_hit_limit)
 		goto out;
@@ -244,8 +247,8 @@ static void trace_drop_common(struct sk_buff *skb, void *location)
 	 */
 	__nla_reserve_nohdr(dskb, sizeof(struct net_dm_drop_point));
 	nla->nla_len += NLA_ALIGN(sizeof(struct net_dm_drop_point));
-	memcpy(msg->points[msg->entries].pc, &location, sizeof(void *));
-	msg->points[msg->entries].count = 1;
+	memcpy(point->pc, &location, sizeof(void *));
+	point->count = 1;
 	msg->entries++;
 
 	if (!timer_pending(&data->send_timer)) {
-- 
2.26.0

[PATCH 08/15] usb: ehci: avoid gcc-10 zero-length-bounds warning

[Arnd Bergmann]

Building ehci drivers with gcc-10 results in a number of warnings like
when an zero-length array is accessed:

drivers/usb/host/ehci-hub.c: In function 'ehci_bus_suspend':
drivers/usb/host/ehci-hub.c:320:30: error: array subscript 14 is outside the bounds of an interior zero-length array 'u32[0]' {aka 'unsigned int[0]'} [-Werror=zero-length-bounds]
  320 |    u32 __iomem *hostpc_reg = &ehci->regs->hostpc[port];
      |                              ^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/usb/host/ehci.h:273,
                 from drivers/usb/host/ehci-hcd.c:96:
include/linux/usb/ehci_def.h:186:7: note: while referencing 'hostpc'
  186 |  u32  hostpc[0]; /* HOSTPC extension */
      |       ^~~~~~
In file included from drivers/usb/host/ehci-hcd.c:305:
drivers/usb/host/ehci-hub.c: In function 'ehci_hub_control':
drivers/usb/host/ehci-hub.c:892:15: error: array subscript 256 is outside the bounds of an interior zero-length array 'u32[0]' {aka 'unsigned int[0]'} [-Werror=zero-length-bounds]
  892 |  hostpc_reg = &ehci->regs->hostpc[temp];
      |               ^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/usb/host/ehci.h:273,
                 from drivers/usb/host/ehci-hcd.c:96:
include/linux/usb/ehci_def.h:186:7: note: while referencing 'hostpc'
  186 |  u32  hostpc[0]; /* HOSTPC extension */
      |       ^~~~~~

All these fields are colocated with reserved fields that I guess
refer to the correct field length.

Change the two struct definition to use an unnamed union to define
both of these fields at the same location as the corresponding
reserved fields.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 include/linux/usb/ehci_def.h | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/include/linux/usb/ehci_def.h b/include/linux/usb/ehci_def.h
index 78e006355557..8777d8e56ef2 100644
--- a/include/linux/usb/ehci_def.h
+++ b/include/linux/usb/ehci_def.h
@@ -127,7 +127,8 @@ struct ehci_regs {
 #define FLAG_CF		(1<<0)		/* true: we'll support "high speed" */
 
 	/* PORTSC: offset 0x44 */
-	u32		port_status[0];	/* up to N_PORTS */
+	union {
+		u32		port_status[9];	/* up to N_PORTS */
 /* EHCI 1.1 addendum */
 #define PORTSC_SUSPEND_STS_ACK 0
 #define PORTSC_SUSPEND_STS_NYET 1
@@ -165,7 +166,8 @@ struct ehci_regs {
 #define PORT_CONNECT	(1<<0)		/* device connected */
 #define PORT_RWC_BITS   (PORT_CSC | PORT_PEC | PORT_OCC)
 
-	u32		reserved3[9];
+		u32		reserved3[9];
+	};
 
 	/* USBMODE: offset 0x68 */
 	u32		usbmode;	/* USB Device mode */
@@ -181,11 +183,13 @@ struct ehci_regs {
  * PORTSCx
  */
 	/* HOSTPC: offset 0x84 */
-	u32		hostpc[0];	/* HOSTPC extension */
+	union {
+		u32		hostpc[17];	/* HOSTPC extension */
 #define HOSTPC_PHCD	(1<<22)		/* Phy clock disable */
 #define HOSTPC_PSPD	(3<<25)		/* Port speed detection */
 
-	u32		reserved5[17];
+		u32		reserved5[17];
+	};
 
 	/* USBMODE_EX: offset 0xc8 */
 	u32		usbmode_ex;	/* USB Device mode extension */
-- 
2.26.0

[PATCH 09/15] udf: avoid gcc-10 zero-length-bounds warnings

[Arnd Bergmann]

gcc-10 warns about writes to the empty freeSpaceTable[] array, with
many instances like:

fs/udf/balloc.c: In function 'udf_bitmap_new_block':
fs/udf/balloc.c:101:36: error: array subscript 65535 is outside the bounds of an interior zero-length array '__le32[0]' {aka 'unsigned int[0]'} [-Werror=zero-length-bounds]
  101 |  le32_add_cpu(&lvid->freeSpaceTable[partition], cnt);
      |                ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
In file included from fs/udf/udfdecl.h:7,
                 from fs/udf/balloc.c:22:
fs/udf/ecma_167.h:363:11: note: while referencing 'freeSpaceTable'
  363 |  __le32   freeSpaceTable[0];
      |           ^~~~~~~~~~~~~~

These can all be avoided by using a flexible array member instead.

Another warning is a bit more obscure:

fs/udf/super.c: In function 'udf_count_free':
fs/udf/super.c:2521:26: warning: array subscript '(<unknown>) + 4294967295' is outside the bounds of an interior zero-length array '__le32[0]' {aka 'unsigned int[0]'} [-Wzero-length-bounds]
 2521 |      lvid->freeSpaceTable[part]);

Work around this one by changing the array access to equivalent
pointer arithmetic, as there cannot be multiple flexible-array
members in a single struct.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 fs/udf/ecma_167.h | 2 +-
 fs/udf/super.c    | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/udf/ecma_167.h b/fs/udf/ecma_167.h
index 736ebc5dc441..14ffe27342bc 100644
--- a/fs/udf/ecma_167.h
+++ b/fs/udf/ecma_167.h
@@ -360,9 +360,9 @@ struct logicalVolIntegrityDesc {
 	uint8_t			logicalVolContentsUse[32];
 	__le32			numOfPartitions;
 	__le32			lengthOfImpUse;
-	__le32			freeSpaceTable[0];
 	__le32			sizeTable[0];
 	uint8_t			impUse[0];
+	__le32			freeSpaceTable[];
 } __packed;
 
 /* Integrity Type (ECMA 167r3 3/10.10.3) */
diff --git a/fs/udf/super.c b/fs/udf/super.c
index f747bf72edbe..379867888c36 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -117,7 +117,7 @@ struct logicalVolIntegrityDescImpUse *udf_sb_lvidiu(struct super_block *sb)
 	}
 	/* The offset is to skip freeSpaceTable and sizeTable arrays */
 	offset = partnum * 2 * sizeof(uint32_t);
-	return (struct logicalVolIntegrityDescImpUse *)&(lvid->impUse[offset]);
+	return (struct logicalVolIntegrityDescImpUse *)(lvid->impUse + offset);
 }
 
 /* UDF filesystem type */
-- 
2.26.0

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

[Arnd Bergmann]

gcc-10 now warns about accessing members of a zero-length array
field:

fs/hpfs/anode.c: In function 'hpfs_add_sector_to_btree':
fs/hpfs/anode.c:209:27: error: array subscript 0 is outside the bounds of an interior zero-length array 'struct bplus_internal_node[0]' [-Werror=zero-length-bounds]
  209 |    anode->btree.u.internal[0].down = cpu_to_le32(a);
      |    ~~~~~~~~~~~~~~~~~~~~~~~^~~
In file included from fs/hpfs/hpfs_fn.h:26,
                 from fs/hpfs/anode.c:10:
fs/hpfs/hpfs.h:411:32: note: while referencing 'internal'
  411 |     struct bplus_internal_node internal[0]; /* (internal) 2-word entries giving
      |                                ^~~~~~~~

It would be nice to make it a flexible-array member, but that is not
possible inside of a union, so work around the warnings by adding
a temporary pointer that hides the problem.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 fs/hpfs/anode.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/fs/hpfs/anode.c b/fs/hpfs/anode.c
index c14c9a035ee0..55788ca7969f 100644
--- a/fs/hpfs/anode.c
+++ b/fs/hpfs/anode.c
@@ -200,14 +200,17 @@ secno hpfs_add_sector_to_btree(struct super_block *s, secno node, int fnod, unsi
 		brelse(bh);
 		a = na;
 		if ((new_anode = hpfs_alloc_anode(s, a, &na, &bh))) {
+			struct bplus_internal_node *internal;
+
 			anode = new_anode;
 			/*anode->up = cpu_to_le32(up != -1 ? up : ra);*/
 			anode->btree.flags |= BP_internal;
 			anode->btree.n_used_nodes = 1;
 			anode->btree.n_free_nodes = 59;
 			anode->btree.first_free = cpu_to_le16(16);
-			anode->btree.u.internal[0].down = cpu_to_le32(a);
-			anode->btree.u.internal[0].file_secno = cpu_to_le32(-1);
+			internal = anode->btree.u.internal;
+			internal->down = cpu_to_le32(a);
+			internal->file_secno = cpu_to_le32(-1);
 			mark_buffer_dirty(bh);
 			brelse(bh);
 			if ((anode = hpfs_map_anode(s, a, &bh))) {
-- 
2.26.0

[PATCH 11/15] omfs: avoid gcc-10 stringop-overflow warning

[Arnd Bergmann]

gcc-10 correctly points out a memcpy beyond the end of the structure
it gets copied into:

fs/omfs/file.c: In function 'omfs_grow_extent':
cc1: warning: writing 16 bytes into a region of size 0 [-Wstringop-overflow=]
In file included from fs/omfs/omfs.h:8,
                 from fs/omfs/file.c:11:
fs/omfs/omfs_fs.h:80:27: note: at offset 0 to object 'e_entry' with size 16 declared here
   80 |  struct omfs_extent_entry e_entry; /* start of extent entries */
      |                           ^~~~~~~

This is not a bug however, as the file system layout contains an array
of extent entries instead of just a single one that was part of the
structure definition.

Changing the definition to use a c99 flexible array member makes
makes the code match the actual layout, which avoids the warning and
an odd '+1' in the calculation of the number of extent entries.

Fixes: 8f09e98768c1 ("omfs: add file routines")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 fs/omfs/file.c    | 12 ++++++------
 fs/omfs/omfs_fs.h |  2 +-
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/fs/omfs/file.c b/fs/omfs/file.c
index d7b5f09d298c..94344386c6ff 100644
--- a/fs/omfs/file.c
+++ b/fs/omfs/file.c
@@ -14,7 +14,7 @@ static u32 omfs_max_extents(struct omfs_sb_info *sbi, int offset)
 {
 	return (sbi->s_sys_blocksize - offset -
 		sizeof(struct omfs_extent)) /
-		sizeof(struct omfs_extent_entry) + 1;
+		sizeof(struct omfs_extent_entry);
 }
 
 void omfs_make_empty_table(struct buffer_head *bh, int offset)
@@ -24,8 +24,8 @@ void omfs_make_empty_table(struct buffer_head *bh, int offset)
 	oe->e_next = ~cpu_to_be64(0ULL);
 	oe->e_extent_count = cpu_to_be32(1),
 	oe->e_fill = cpu_to_be32(0x22),
-	oe->e_entry.e_cluster = ~cpu_to_be64(0ULL);
-	oe->e_entry.e_blocks = ~cpu_to_be64(0ULL);
+	oe->e_entry[0].e_cluster = ~cpu_to_be64(0ULL);
+	oe->e_entry[0].e_blocks = ~cpu_to_be64(0ULL);
 }
 
 int omfs_shrink_inode(struct inode *inode)
@@ -68,7 +68,7 @@ int omfs_shrink_inode(struct inode *inode)
 
 		last = next;
 		next = be64_to_cpu(oe->e_next);
-		entry = &oe->e_entry;
+		entry = oe->e_entry;
 
 		/* ignore last entry as it is the terminator */
 		for (; extent_count > 1; extent_count--) {
@@ -117,7 +117,7 @@ static int omfs_grow_extent(struct inode *inode, struct omfs_extent *oe,
 			u64 *ret_block)
 {
 	struct omfs_extent_entry *terminator;
-	struct omfs_extent_entry *entry = &oe->e_entry;
+	struct omfs_extent_entry *entry = oe->e_entry;
 	struct omfs_sb_info *sbi = OMFS_SB(inode->i_sb);
 	u32 extent_count = be32_to_cpu(oe->e_extent_count);
 	u64 new_block = 0;
@@ -245,7 +245,7 @@ static int omfs_get_block(struct inode *inode, sector_t block,
 
 		extent_count = be32_to_cpu(oe->e_extent_count);
 		next = be64_to_cpu(oe->e_next);
-		entry = &oe->e_entry;
+		entry = oe->e_entry;
 
 		if (extent_count > max_extents)
 			goto out_brelse;
diff --git a/fs/omfs/omfs_fs.h b/fs/omfs/omfs_fs.h
index caecb3d5a344..1ff6b9e41297 100644
--- a/fs/omfs/omfs_fs.h
+++ b/fs/omfs/omfs_fs.h
@@ -77,7 +77,7 @@ struct omfs_extent {
 	__be64 e_next;			/* next extent table location */
 	__be32 e_extent_count;		/* total # extents in this table */
 	__be32 e_fill;
-	struct omfs_extent_entry e_entry;	/* start of extent entries */
+	struct omfs_extent_entry e_entry[];	/* start of extent entries */
 };
 
 #endif
-- 
2.26.0

[PATCH 12/15] media: s5k5baf: avoid gcc-10 zero-length-bounds warning

[Arnd Bergmann]

gcc-10 warns about accessing a zero-length struct member:

drivers/media/i2c/s5k5baf.c: In function 's5k5baf_load_setfile':
drivers/media/i2c/s5k5baf.c:390:13: warning: array subscript 65535 is outside the bounds of an interior zero-length array 'struct <anonymous>[0]' [-Wzero-length-bounds]
  390 |   if (f->seq[i].offset + d <= end)
      |       ~~~~~~^~~

This should really be a flexible-array member, but the structure
already has one. I experimentally confirmed that swapping the two
avoids the warning, as the 'data[]' array is not accessed like this.

Fixes: 3ba225b506a2 ("treewide: Replace zero-length array with flexible-array member")
Fixes: 7d459937dc09 ("[media] Add driver for Samsung S5K5BAF camera sensor")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/media/i2c/s5k5baf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/s5k5baf.c b/drivers/media/i2c/s5k5baf.c
index 42584a088273..0b1ddedcf7dc 100644
--- a/drivers/media/i2c/s5k5baf.c
+++ b/drivers/media/i2c/s5k5baf.c
@@ -277,11 +277,11 @@ enum {
 
 struct s5k5baf_fw {
 	u16 count;
+	u16 data[0];
 	struct {
 		u16 id;
 		u16 offset;
-	} seq[0];
-	u16 data[];
+	} seq[];
 };
 
 struct s5k5baf {
-- 
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

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

[Arnd Bergmann]

When CONFIG_ARCH_NO_SG_CHAIN is set, op->sgl[0] cannot be dereferenced,
as gcc-10 now points out:

drivers/nvme/host/fc.c: In function 'nvme_fc_init_request':
drivers/nvme/host/fc.c:1774:29: warning: array subscript 0 is outside the bounds of an interior zero-length array 'struct scatterlist[0]' [-Wzero-length-bounds]
 1774 |  op->op.fcp_req.first_sgl = &op->sgl[0];
      |                             ^~~~~~~~~~~
drivers/nvme/host/fc.c:98:21: note: while referencing 'sgl'
   98 |  struct scatterlist sgl[NVME_INLINE_SG_CNT];
      |                     ^~~

I don't know if this is a legitimate warning or a false-positive.
If this is just a false alarm, the warning is easily suppressed
by interpreting the array as a pointer.

Fixes: b1ae1a238900 ("nvme-fc: Avoid preallocating big SGL for data")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/nvme/host/fc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nvme/host/fc.c b/drivers/nvme/host/fc.c
index 887537d1243f..b7ecda48d597 100644
--- a/drivers/nvme/host/fc.c
+++ b/drivers/nvme/host/fc.c
@@ -1771,7 +1771,7 @@ nvme_fc_init_request(struct blk_mq_tag_set *set, struct request *rq,
 	res = __nvme_fc_init_request(ctrl, queue, &op->op, rq, queue->rqcnt++);
 	if (res)
 		return res;
-	op->op.fcp_req.first_sgl = &op->sgl[0];
+	op->op.fcp_req.first_sgl = op->sgl;
 	op->op.fcp_req.private = &op->priv[0];
 	nvme_req(rq)->ctrl = &ctrl->ctrl;
 	return res;
-- 
2.26.0

Re: [PATCH 04/15] ath10k: fix gcc-10 zero-length-bounds warnings

[Arnd Bergmann]

On Thu, Apr 30, 2020 at 11:41 PM Gustavo A. R. Silva
<gustavo@embeddedor.com> wrote:
> On 4/30/20 16:30, Arnd Bergmann wrote:
> > gcc-10 started warning about out-of-bounds access for zero-length
> > arrays:
> The treewide patch is an experimental change and, as this change only applies
> to my -next tree, I will carry this patch in it, so other people don't have
> to worry about this at all.

Ok, thanks!

       Arnd

Re: [PATCH 04/15] ath10k: fix gcc-10 zero-length-bounds warnings

[Gustavo A. R. Silva]

Hi Arnd,

On 4/30/20 16:30, Arnd Bergmann wrote:
> gcc-10 started warning about out-of-bounds access for zero-length
> arrays:
> 
> In file included from drivers/net/wireless/ath/ath10k/core.h:18,
>                  from drivers/net/wireless/ath/ath10k/htt_rx.c:8:
> drivers/net/wireless/ath/ath10k/htt_rx.c: In function 'ath10k_htt_rx_tx_fetch_ind':
> drivers/net/wireless/ath/ath10k/htt.h:1683:17: warning: array subscript 65535 is outside the bounds of an interior zero-length array 'struct htt_tx_fetch_record[0]' [-Wzero-length-bounds]
>  1683 |  return (void *)&ind->records[le16_to_cpu(ind->num_records)];
>       |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/net/wireless/ath/ath10k/htt.h:1676:29: note: while referencing 'records'
>  1676 |  struct htt_tx_fetch_record records[0];
>       |                             ^~~~~~~
> 
> The structure was already converted to have a flexible-array member in
> the past, but there are two zero-length members in the end and only
> one of them can be a flexible-array member.
> 
> Swap the two around to avoid the warning, as 'resp_ids' is not accessed
> in a way that causes a warning.
> 
> Fixes: 3ba225b506a2 ("treewide: Replace zero-length array with flexible-array member")
> Fixes: 22e6b3bc5d96 ("ath10k: add new htt definitions")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/net/wireless/ath/ath10k/htt.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath10k/htt.h b/drivers/net/wireless/ath/ath10k/htt.h
> index e7096a73c6ca..7621f0a3dc77 100644
> --- a/drivers/net/wireless/ath/ath10k/htt.h
> +++ b/drivers/net/wireless/ath/ath10k/htt.h
> @@ -1673,8 +1673,8 @@ struct htt_tx_fetch_ind {
>  	__le32 token;
>  	__le16 num_resp_ids;
>  	__le16 num_records;
> -	struct htt_tx_fetch_record records[0];
> -	__le32 resp_ids[]; /* ath10k_htt_get_tx_fetch_ind_resp_ids() */
> +	__le32 resp_ids[0]; /* ath10k_htt_get_tx_fetch_ind_resp_ids() */
> +	struct htt_tx_fetch_record records[];
>  } __packed;
>  
>  static inline void *
> 

The treewide patch is an experimental change and, as this change only applies
to my -next tree, I will carry this patch in it, so other people don't have
to worry about this at all.

Thank you
--
Gustavo

Re: [PATCH 12/15] media: s5k5baf: avoid gcc-10 zero-length-bounds warning

[Gustavo A. R. Silva]

Hi Arnd,

On 4/30/20 16:30, Arnd Bergmann wrote:
> gcc-10 warns about accessing a zero-length struct member:
> 
> drivers/media/i2c/s5k5baf.c: In function 's5k5baf_load_setfile':
> drivers/media/i2c/s5k5baf.c:390:13: warning: array subscript 65535 is outside the bounds of an interior zero-length array 'struct <anonymous>[0]' [-Wzero-length-bounds]
>   390 |   if (f->seq[i].offset + d <= end)
>       |       ~~~~~~^~~
> 
> This should really be a flexible-array member, but the structure
> already has one. I experimentally confirmed that swapping the two
> avoids the warning, as the 'data[]' array is not accessed like this.
> 
> Fixes: 3ba225b506a2 ("treewide: Replace zero-length array with flexible-array member")
> Fixes: 7d459937dc09 ("[media] Add driver for Samsung S5K5BAF camera sensor")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/media/i2c/s5k5baf.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/i2c/s5k5baf.c b/drivers/media/i2c/s5k5baf.c
> index 42584a088273..0b1ddedcf7dc 100644
> --- a/drivers/media/i2c/s5k5baf.c
> +++ b/drivers/media/i2c/s5k5baf.c
> @@ -277,11 +277,11 @@ enum {
>  
>  struct s5k5baf_fw {
>  	u16 count;
> +	u16 data[0];
>  	struct {
>  		u16 id;
>  		u16 offset;
> -	} seq[0];
> -	u16 data[];
> +	} seq[];
>  };
>  
>  struct s5k5baf {
> 

The treewide patch is an experimental change and, as this change only applies
to my -next tree, I will carry this patch in it, so other people don't have
to worry about this at all.

Thank you
--
Gustavo

Re: [PATCH 09/15] udf: avoid gcc-10 zero-length-bounds warnings

[Pali Rohár]

On Thursday 30 April 2020 23:30:51 Arnd Bergmann wrote:
> gcc-10 warns about writes to the empty freeSpaceTable[] array, with
> many instances like:
> 
> fs/udf/balloc.c: In function 'udf_bitmap_new_block':
> fs/udf/balloc.c:101:36: error: array subscript 65535 is outside the bounds of an interior zero-length array '__le32[0]' {aka 'unsigned int[0]'} [-Werror=zero-length-bounds]
>   101 |  le32_add_cpu(&lvid->freeSpaceTable[partition], cnt);
>       |                ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
> In file included from fs/udf/udfdecl.h:7,
>                  from fs/udf/balloc.c:22:
> fs/udf/ecma_167.h:363:11: note: while referencing 'freeSpaceTable'
>   363 |  __le32   freeSpaceTable[0];
>       |           ^~~~~~~~~~~~~~

Hi Arnd! This looks like a false-positive warning.

> These can all be avoided by using a flexible array member instead.
> 
> Another warning is a bit more obscure:
> 
> fs/udf/super.c: In function 'udf_count_free':
> fs/udf/super.c:2521:26: warning: array subscript '(<unknown>) + 4294967295' is outside the bounds of an interior zero-length array '__le32[0]' {aka 'unsigned int[0]'} [-Wzero-length-bounds]
>  2521 |      lvid->freeSpaceTable[part]);
> 
> Work around this one by changing the array access to equivalent
> pointer arithmetic, as there cannot be multiple flexible-array
> members in a single struct.

Well, this code uses GNU extension for zero-length arrays because it was
written in pre-C99 era when C99 flexible arrays did not exist yet.

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  fs/udf/ecma_167.h | 2 +-
>  fs/udf/super.c    | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/udf/ecma_167.h b/fs/udf/ecma_167.h
> index 736ebc5dc441..14ffe27342bc 100644
> --- a/fs/udf/ecma_167.h
> +++ b/fs/udf/ecma_167.h
> @@ -360,9 +360,9 @@ struct logicalVolIntegrityDesc {
>  	uint8_t			logicalVolContentsUse[32];
>  	__le32			numOfPartitions;
>  	__le32			lengthOfImpUse;
> -	__le32			freeSpaceTable[0];
>  	__le32			sizeTable[0];
>  	uint8_t			impUse[0];
> +	__le32			freeSpaceTable[];

Please do not change order of members in these structures. Order is
strictly defined by ECMA 167 standard and changing them you would just
confuse reader. In LVID is free space table before size table.

If you do not like GNU C extension for zero-length arrays then just
replace it by standard C99 flexible arrays. I think that there is no
reason to not use standard C99 language constructions, just nobody had
motivation or time to change (working) code.

Also this file is semi-synchronized with udftools project in which I
already replaced all GNU C zero-length arrays by C99 flexible arrays.

You can take inspiration what I did with logicalVolIntegrityDesc:
https://github.com/pali/udftools/commit/f851d84478ce881d516a76018745fa163f803880#diff-1e1a5b89f620d380f22b973f9449aeaeL381-R384

Anyway, if you have a better idea what to do with such on-disk structure
and how to represent it in C struct syntax, let me know as it could be
updated also in udftools project.

>  } __packed;
>  
>  /* Integrity Type (ECMA 167r3 3/10.10.3) */
> diff --git a/fs/udf/super.c b/fs/udf/super.c
> index f747bf72edbe..379867888c36 100644
> --- a/fs/udf/super.c
> +++ b/fs/udf/super.c
> @@ -117,7 +117,7 @@ struct logicalVolIntegrityDescImpUse *udf_sb_lvidiu(struct super_block *sb)
>  	}
>  	/* The offset is to skip freeSpaceTable and sizeTable arrays */
>  	offset = partnum * 2 * sizeof(uint32_t);
> -	return (struct logicalVolIntegrityDescImpUse *)&(lvid->impUse[offset]);
> +	return (struct logicalVolIntegrityDescImpUse *)(lvid->impUse + offset);
>  }
>  
>  /* UDF filesystem type */
> -- 
> 2.26.0
> 

Re: [PATCH 08/15] usb: ehci: avoid gcc-10 zero-length-bounds warning

[Alan Stern]

On Thu, 30 Apr 2020, Arnd Bergmann wrote:

> Building ehci drivers with gcc-10 results in a number of warnings like
> when an zero-length array is accessed:
> 
> drivers/usb/host/ehci-hub.c: In function 'ehci_bus_suspend':
> drivers/usb/host/ehci-hub.c:320:30: error: array subscript 14 is outside the bounds of an interior zero-length array 'u32[0]' {aka 'unsigned int[0]'} [-Werror=zero-length-bounds]
>   320 |    u32 __iomem *hostpc_reg = &ehci->regs->hostpc[port];
>       |                              ^~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from drivers/usb/host/ehci.h:273,
>                  from drivers/usb/host/ehci-hcd.c:96:
> include/linux/usb/ehci_def.h:186:7: note: while referencing 'hostpc'
>   186 |  u32  hostpc[0]; /* HOSTPC extension */
>       |       ^~~~~~
> In file included from drivers/usb/host/ehci-hcd.c:305:
> drivers/usb/host/ehci-hub.c: In function 'ehci_hub_control':
> drivers/usb/host/ehci-hub.c:892:15: error: array subscript 256 is outside the bounds of an interior zero-length array 'u32[0]' {aka 'unsigned int[0]'} [-Werror=zero-length-bounds]
>   892 |  hostpc_reg = &ehci->regs->hostpc[temp];
>       |               ^~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from drivers/usb/host/ehci.h:273,
>                  from drivers/usb/host/ehci-hcd.c:96:
> include/linux/usb/ehci_def.h:186:7: note: while referencing 'hostpc'
>   186 |  u32  hostpc[0]; /* HOSTPC extension */
>       |       ^~~~~~
> 
> All these fields are colocated with reserved fields that I guess
> refer to the correct field length.

No, they don't.

> Change the two struct definition to use an unnamed union to define
> both of these fields at the same location as the corresponding
> reserved fields.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  include/linux/usb/ehci_def.h | 12 ++++++++----
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/include/linux/usb/ehci_def.h b/include/linux/usb/ehci_def.h
> index 78e006355557..8777d8e56ef2 100644
> --- a/include/linux/usb/ehci_def.h
> +++ b/include/linux/usb/ehci_def.h
> @@ -127,7 +127,8 @@ struct ehci_regs {
>  #define FLAG_CF		(1<<0)		/* true: we'll support "high speed" */
>  
>  	/* PORTSC: offset 0x44 */
> -	u32		port_status[0];	/* up to N_PORTS */
> +	union {
> +		u32		port_status[9];	/* up to N_PORTS */

This array can have up to 15 elements, meaning that it can extend out
to offset 0x80.

>  /* EHCI 1.1 addendum */
>  #define PORTSC_SUSPEND_STS_ACK 0
>  #define PORTSC_SUSPEND_STS_NYET 1
> @@ -165,7 +166,8 @@ struct ehci_regs {
>  #define PORT_CONNECT	(1<<0)		/* device connected */
>  #define PORT_RWC_BITS   (PORT_CSC | PORT_PEC | PORT_OCC)
>  
> -	u32		reserved3[9];
> +		u32		reserved3[9];
> +	};
>  
>  	/* USBMODE: offset 0x68 */
>  	u32		usbmode;	/* USB Device mode */

As you see, this next field actually lies inside the preceding array.  
It's not a real conflict; any hardware which supports the usbmode field 
uses only the first element of the port_status array.

I don't know how you want to handle this.  Doing

#define usbmode port_status[9]

doesn't seem like a very good approach, but I can't think of anything 
better at the moment.  Maybe just set the array size to 9, as you did, 
but with a comment explaining what's really going on.

> @@ -181,11 +183,13 @@ struct ehci_regs {
>   * PORTSCx
>   */
>  	/* HOSTPC: offset 0x84 */
> -	u32		hostpc[0];	/* HOSTPC extension */
> +	union {
> +		u32		hostpc[17];	/* HOSTPC extension */

Likewise, this array can have up to 15 elements.  In fact, it's the 
same size as the port_status array.

>  #define HOSTPC_PHCD	(1<<22)		/* Phy clock disable */
>  #define HOSTPC_PSPD	(3<<25)		/* Port speed detection */
>  
> -	u32		reserved5[17];
> +		u32		reserved5[17];
> +	};
>  
>  	/* USBMODE_EX: offset 0xc8 */
>  	u32		usbmode_ex;	/* USB Device mode extension */

Alan Stern

Re: [PATCH 15/15] nvme: avoid gcc-10 zero-length-bounds warning

[Christoph Hellwig]

On Thu, Apr 30, 2020 at 11:30:57PM +0200, Arnd Bergmann wrote:
> When CONFIG_ARCH_NO_SG_CHAIN is set, op->sgl[0] cannot be dereferenced,
> as gcc-10 now points out:
> 
> drivers/nvme/host/fc.c: In function 'nvme_fc_init_request':
> drivers/nvme/host/fc.c:1774:29: warning: array subscript 0 is outside the bounds of an interior zero-length array 'struct scatterlist[0]' [-Wzero-length-bounds]
>  1774 |  op->op.fcp_req.first_sgl = &op->sgl[0];
>       |                             ^~~~~~~~~~~
> drivers/nvme/host/fc.c:98:21: note: while referencing 'sgl'
>    98 |  struct scatterlist sgl[NVME_INLINE_SG_CNT];
>       |                     ^~~
> 
> I don't know if this is a legitimate warning or a false-positive.
> If this is just a false alarm, the warning is easily suppressed
> by interpreting the array as a pointer.

This looks like a surpression to be, but then again I find the new
code actually cleaner, so I'm fine with it :)

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 07/15] drop_monitor: work around gcc-10 stringop-overflow warning

[Neil Horman]

On Thu, Apr 30, 2020 at 11:30:49PM +0200, Arnd Bergmann wrote:
> The current gcc-10 snapshot produces a false-positive warning:
> 
> net/core/drop_monitor.c: In function 'trace_drop_common.constprop':
> cc1: error: writing 8 bytes into a region of size 0 [-Werror=stringop-overflow=]
> In file included from net/core/drop_monitor.c:23:
> include/uapi/linux/net_dropmon.h:36:8: note: at offset 0 to object 'entries' with size 4 declared here
>    36 |  __u32 entries;
>       |        ^~~~~~~
> 
> I reported this in the gcc bugzilla, but in case it does not get
> fixed in the release, work around it by using a temporary variable.
> 
> Fixes: 9a8afc8d3962 ("Network Drop Monitor: Adding drop monitor implementation & Netlink protocol")
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94881
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  net/core/drop_monitor.c | 11 +++++++----
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/net/core/drop_monitor.c b/net/core/drop_monitor.c
> index 8e33cec9fc4e..2ee7bc4c9e03 100644
> --- a/net/core/drop_monitor.c
> +++ b/net/core/drop_monitor.c
> @@ -213,6 +213,7 @@ static void sched_send_work(struct timer_list *t)
>  static void trace_drop_common(struct sk_buff *skb, void *location)
>  {
>  	struct net_dm_alert_msg *msg;
> +	struct net_dm_drop_point *point;
>  	struct nlmsghdr *nlh;
>  	struct nlattr *nla;
>  	int i;
> @@ -231,11 +232,13 @@ static void trace_drop_common(struct sk_buff *skb, void *location)
>  	nlh = (struct nlmsghdr *)dskb->data;
>  	nla = genlmsg_data(nlmsg_data(nlh));
>  	msg = nla_data(nla);
> +	point = msg->points;
>  	for (i = 0; i < msg->entries; i++) {
> -		if (!memcmp(&location, msg->points[i].pc, sizeof(void *))) {
> -			msg->points[i].count++;
> +		if (!memcmp(&location, &point->pc, sizeof(void *))) {
> +			point->count++;
>  			goto out;
>  		}
> +		point++;
>  	}
>  	if (msg->entries == dm_hit_limit)
>  		goto out;
> @@ -244,8 +247,8 @@ static void trace_drop_common(struct sk_buff *skb, void *location)
>  	 */
>  	__nla_reserve_nohdr(dskb, sizeof(struct net_dm_drop_point));
>  	nla->nla_len += NLA_ALIGN(sizeof(struct net_dm_drop_point));
> -	memcpy(msg->points[msg->entries].pc, &location, sizeof(void *));
> -	msg->points[msg->entries].count = 1;
> +	memcpy(point->pc, &location, sizeof(void *));
> +	point->count = 1;
>  	msg->entries++;
>  
>  	if (!timer_pending(&data->send_timer)) {
Acked-by: Neil Horman <nhorman@tuxdriver.com>

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

Re: [PATCH 08/15] usb: ehci: avoid gcc-10 zero-length-bounds warning

[Arnd Bergmann]

On Fri, May 1, 2020 at 4:42 AM Alan Stern <stern@rowland.harvard.edu> wrote:
> On Thu, 30 Apr 2020, Arnd Bergmann wrote:

>
> No, they don't.

> >       /* PORTSC: offset 0x44 */
> > -     u32             port_status[0]; /* up to N_PORTS */
> > +     union {
> > +             u32             port_status[9]; /* up to N_PORTS */
>
> This array can have up to 15 elements, meaning that it can extend out
> to offset 0x80.

Ok, thanks for the clarification!

> >  /* EHCI 1.1 addendum */
> >  #define PORTSC_SUSPEND_STS_ACK 0
> >  #define PORTSC_SUSPEND_STS_NYET 1
> > @@ -165,7 +166,8 @@ struct ehci_regs {
> >  #define PORT_CONNECT (1<<0)          /* device connected */
> >  #define PORT_RWC_BITS   (PORT_CSC | PORT_PEC | PORT_OCC)
> >
> > -     u32             reserved3[9];
> > +             u32             reserved3[9];
> > +     };
> >
> >       /* USBMODE: offset 0x68 */
> >       u32             usbmode;        /* USB Device mode */
>
> As you see, this next field actually lies inside the preceding array.
> It's not a real conflict; any hardware which supports the usbmode field
> uses only the first element of the port_status array.
>
> I don't know how you want to handle this.  Doing
>
> #define usbmode port_status[9]
>
> doesn't seem like a very good approach, but I can't think of anything
> better at the moment.  Maybe just set the array size to 9, as you did,
> but with a comment explaining what's really going on.

The easiest change would be to use an anonymous struct like this

        /* PORTSC: offset 0x44 */
        union {
                u32             port_status[15]; /* up to N_PORTS */
/* EHCI 1.1 addendum */
#define PORTSC_SUSPEND_STS_ACK 0
...
#define PORT_RWC_BITS   (PORT_CSC | PORT_PEC | PORT_OCC)
                struct {
                        u32             reserved3[9];

        /* USBMODE: offset 0x68 */
                        u32             usbmode;        /* USB Device mode */
#define USBMODE_SDIS    (1<<3)          /* Stream disable */
#define USBMODE_BE      (1<<2)          /* BE/LE endianness select */
#define USBMODE_CM_HC   (3<<0)          /* host controller mode */
#define USBMODE_CM_IDLE (0<<0)          /* idle state */

                        u32             reserved4[5];
                };
        };
        u32             reserved5;

It doesn't really improve readability, but it should correctly
reflect the layout as you described it.

       Arnd

Re: [PATCH 08/15] usb: ehci: avoid gcc-10 zero-length-bounds warning

[Alan Stern]

On Fri, 1 May 2020, Arnd Bergmann wrote:

> On Fri, May 1, 2020 at 4:42 AM Alan Stern <stern@rowland.harvard.edu> wrote:
> > On Thu, 30 Apr 2020, Arnd Bergmann wrote:
> 
> >
> > No, they don't.
> 
> > >       /* PORTSC: offset 0x44 */
> > > -     u32             port_status[0]; /* up to N_PORTS */
> > > +     union {
> > > +             u32             port_status[9]; /* up to N_PORTS */
> >
> > This array can have up to 15 elements, meaning that it can extend out
> > to offset 0x80.
> 
> Ok, thanks for the clarification!
> 
> > >  /* EHCI 1.1 addendum */
> > >  #define PORTSC_SUSPEND_STS_ACK 0
> > >  #define PORTSC_SUSPEND_STS_NYET 1
> > > @@ -165,7 +166,8 @@ struct ehci_regs {
> > >  #define PORT_CONNECT (1<<0)          /* device connected */
> > >  #define PORT_RWC_BITS   (PORT_CSC | PORT_PEC | PORT_OCC)
> > >
> > > -     u32             reserved3[9];
> > > +             u32             reserved3[9];
> > > +     };
> > >
> > >       /* USBMODE: offset 0x68 */
> > >       u32             usbmode;        /* USB Device mode */
> >
> > As you see, this next field actually lies inside the preceding array.
> > It's not a real conflict; any hardware which supports the usbmode field
> > uses only the first element of the port_status array.
> >
> > I don't know how you want to handle this.  Doing
> >
> > #define usbmode port_status[9]
> >
> > doesn't seem like a very good approach, but I can't think of anything
> > better at the moment.  Maybe just set the array size to 9, as you did,
> > but with a comment explaining what's really going on.
> 
> The easiest change would be to use an anonymous struct like this
> 
>         /* PORTSC: offset 0x44 */
>         union {
>                 u32             port_status[15]; /* up to N_PORTS */
> /* EHCI 1.1 addendum */
> #define PORTSC_SUSPEND_STS_ACK 0
> ...
> #define PORT_RWC_BITS   (PORT_CSC | PORT_PEC | PORT_OCC)
>                 struct {
>                         u32             reserved3[9];
> 
>         /* USBMODE: offset 0x68 */
>                         u32             usbmode;        /* USB Device mode */
> #define USBMODE_SDIS    (1<<3)          /* Stream disable */
> #define USBMODE_BE      (1<<2)          /* BE/LE endianness select */
> #define USBMODE_CM_HC   (3<<0)          /* host controller mode */
> #define USBMODE_CM_IDLE (0<<0)          /* idle state */
> 
>                         u32             reserved4[5];
>                 };
>         };
>         u32             reserved5;
> 
> It doesn't really improve readability, but it should correctly
> reflect the layout as you described it.

Sounds good.  Please go ahead and update the patch.

Alan Stern

Re: [PATCH 09/15] udf: avoid gcc-10 zero-length-bounds warnings

[Arnd Bergmann]

On Thu, Apr 30, 2020 at 11:54 PM Pali Rohár <pali@kernel.org> wrote:
>
> On Thursday 30 April 2020 23:30:51 Arnd Bergmann wrote:
> > gcc-10 warns about writes to the empty freeSpaceTable[] array, with
> > many instances like:
> >
> > fs/udf/balloc.c: In function 'udf_bitmap_new_block':
> > fs/udf/balloc.c:101:36: error: array subscript 65535 is outside the bounds of an interior zero-length array '__le32[0]' {aka 'unsigned int[0]'} [-Werror=zero-length-bounds]
> >   101 |  le32_add_cpu(&lvid->freeSpaceTable[partition], cnt);
> >       |                ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
> > In file included from fs/udf/udfdecl.h:7,
> >                  from fs/udf/balloc.c:22:
> > fs/udf/ecma_167.h:363:11: note: while referencing 'freeSpaceTable'
> >   363 |  __le32   freeSpaceTable[0];
> >       |           ^~~~~~~~~~~~~~
>
> Hi Arnd! This looks like a false-positive warning.

Right, sorry for not making that clearer in the changelog.

> > These can all be avoided by using a flexible array member instead.
> >
> > Another warning is a bit more obscure:
> >
> > fs/udf/super.c: In function 'udf_count_free':
> > fs/udf/super.c:2521:26: warning: array subscript '(<unknown>) + 4294967295' is outside the bounds of an interior zero-length array '__le32[0]' {aka 'unsigned int[0]'} [-Wzero-length-bounds]
> >  2521 |      lvid->freeSpaceTable[part]);
> >
> > Work around this one by changing the array access to equivalent
> > pointer arithmetic, as there cannot be multiple flexible-array
> > members in a single struct.
>

> > @@ -360,9 +360,9 @@ struct logicalVolIntegrityDesc {
> >       uint8_t                 logicalVolContentsUse[32];
> >       __le32                  numOfPartitions;
> >       __le32                  lengthOfImpUse;
> > -     __le32                  freeSpaceTable[0];
> >       __le32                  sizeTable[0];
> >       uint8_t                 impUse[0];
> > +     __le32                  freeSpaceTable[];
>
> Please do not change order of members in these structures. Order is
> strictly defined by ECMA 167 standard and changing them you would just
> confuse reader. In LVID is free space table before size table.

Ok

> If you do not like GNU C extension for zero-length arrays then just
> replace it by standard C99 flexible arrays. I think that there is no
> reason to not use standard C99 language constructions, just nobody had
> motivation or time to change (working) code.

No, the problem is that only the last member can be a flexible array,
so when impUse[] is the last member, freeSpaceTable has to be a zero
length array.

[]> Also this file is semi-synchronized with udftools project in which I
> already replaced all GNU C zero-length arrays by C99 flexible arrays.
>
> You can take inspiration what I did with logicalVolIntegrityDesc:
> https://github.com/pali/udftools/commit/f851d84478ce881d516a76018745fa163f803880#diff-1e1a5b89f620d380f22b973f9449aeaeL381-R384

Right, this is likely the best workaround.

> Anyway, if you have a better idea what to do with such on-disk structure
> and how to represent it in C struct syntax, let me know as it could be
> updated also in udftools project.

The trick I used for impUse[] would also work for freeSpaceTable[] to avoid
the gcc warning, it's still not great, but maybe you like this better:

arnd@threadripper:~/arm-soc$ git diff
diff --git a/fs/udf/balloc.c b/fs/udf/balloc.c
index 02f03fadb75b..666d022eb00b 100644
--- a/fs/udf/balloc.c
+++ b/fs/udf/balloc.c
@@ -98,7 +98,7 @@ static void udf_add_free_space(struct super_block
*sb, u16 partition, u32 cnt)
                return;

        lvid = (struct logicalVolIntegrityDesc *)sbi->s_lvid_bh->b_data;
-       le32_add_cpu(&lvid->freeSpaceTable[partition], cnt);
+       le32_add_cpu(lvid->freeSpaceTable + partition, cnt);
        udf_updated_lvid(sb);
 }

diff --git a/fs/udf/ecma_167.h b/fs/udf/ecma_167.h
index 14ffe27342bc..215d97d7edc4 100644
--- a/fs/udf/ecma_167.h
+++ b/fs/udf/ecma_167.h
@@ -360,9 +360,9 @@ struct logicalVolIntegrityDesc {
        uint8_t                 logicalVolContentsUse[32];
        __le32                  numOfPartitions;
        __le32                  lengthOfImpUse;
        __le32                  freeSpaceTable[0];
        __le32                  sizeTable[0];
-       uint8_t                 impUse[0];
+       uint8_t                 impUse[];
 } __packed;

 /* Integrity Type (ECMA 167r3 3/10.10.3) */
diff --git a/fs/udf/super.c b/fs/udf/super.c
index 379867888c36..a1fc51c2261e 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -2517,8 +2517,8 @@ static unsigned int udf_count_free(struct super_block *sb)
                        (struct logicalVolIntegrityDesc *)
                        sbi->s_lvid_bh->b_data;
                if (le32_to_cpu(lvid->numOfPartitions) > part) {
-                       accum = le32_to_cpu(
-                                       lvid->freeSpaceTable[part]);
+                       accum = le32_to_cpup(
+                                       (lvid->freeSpaceTable + part));
                        if (accum == 0xFFFFFFFF)
                                accum = 0;
                }



This version could easily be backported to stable kernels to let them be
compiled with gcc-10, and then synchronizing with the udftools version of
the header needs additional changes on top, which do not need to be
backported.

       Arnd

Re: [PATCH 09/15] udf: avoid gcc-10 zero-length-bounds warnings

[Jan Kara]

On Fri 01-05-20 22:30:27, Arnd Bergmann wrote:
> On Thu, Apr 30, 2020 at 11:54 PM Pali Rohár <pali@kernel.org> wrote:
> > > @@ -360,9 +360,9 @@ struct logicalVolIntegrityDesc {
> > >       uint8_t                 logicalVolContentsUse[32];
> > >       __le32                  numOfPartitions;
> > >       __le32                  lengthOfImpUse;
> > > -     __le32                  freeSpaceTable[0];
> > >       __le32                  sizeTable[0];
> > >       uint8_t                 impUse[0];
> > > +     __le32                  freeSpaceTable[];
> >
> > Please do not change order of members in these structures. Order is
> > strictly defined by ECMA 167 standard and changing them you would just
> > confuse reader. In LVID is free space table before size table.
> 
> Ok
> 
> > If you do not like GNU C extension for zero-length arrays then just
> > replace it by standard C99 flexible arrays. I think that there is no
> > reason to not use standard C99 language constructions, just nobody had
> > motivation or time to change (working) code.
> 
> No, the problem is that only the last member can be a flexible array,
> so when impUse[] is the last member, freeSpaceTable has to be a zero
> length array.
> 
> []> Also this file is semi-synchronized with udftools project in which I
> > already replaced all GNU C zero-length arrays by C99 flexible arrays.
> >
> > You can take inspiration what I did with logicalVolIntegrityDesc:
> > https://github.com/pali/udftools/commit/f851d84478ce881d516a76018745fa163f803880#diff-1e1a5b89f620d380f22b973f9449aeaeL381-R384
> 
> Right, this is likely the best workaround.
> 
> > Anyway, if you have a better idea what to do with such on-disk structure
> > and how to represent it in C struct syntax, let me know as it could be
> > updated also in udftools project.
> 
> The trick I used for impUse[] would also work for freeSpaceTable[] to avoid
> the gcc warning, it's still not great, but maybe you like this better:

I like Pali's version somewhat better because whenever I look at several
(obviously flexible) arrays in one struct, I start wondering what's going
on. So let's not define members of struct whose offset we actually don't
know (and thus we cannot sanely use them anyway).

								Honza
 
> arnd@threadripper:~/arm-soc$ git diff
> diff --git a/fs/udf/balloc.c b/fs/udf/balloc.c
> index 02f03fadb75b..666d022eb00b 100644
> --- a/fs/udf/balloc.c
> +++ b/fs/udf/balloc.c
> @@ -98,7 +98,7 @@ static void udf_add_free_space(struct super_block
> *sb, u16 partition, u32 cnt)
>                 return;
> 
>         lvid = (struct logicalVolIntegrityDesc *)sbi->s_lvid_bh->b_data;
> -       le32_add_cpu(&lvid->freeSpaceTable[partition], cnt);
> +       le32_add_cpu(lvid->freeSpaceTable + partition, cnt);
>         udf_updated_lvid(sb);
>  }
> 
> diff --git a/fs/udf/ecma_167.h b/fs/udf/ecma_167.h
> index 14ffe27342bc..215d97d7edc4 100644
> --- a/fs/udf/ecma_167.h
> +++ b/fs/udf/ecma_167.h
> @@ -360,9 +360,9 @@ struct logicalVolIntegrityDesc {
>         uint8_t                 logicalVolContentsUse[32];
>         __le32                  numOfPartitions;
>         __le32                  lengthOfImpUse;
>         __le32                  freeSpaceTable[0];
>         __le32                  sizeTable[0];
> -       uint8_t                 impUse[0];
> +       uint8_t                 impUse[];
>  } __packed;
> 
>  /* Integrity Type (ECMA 167r3 3/10.10.3) */
> diff --git a/fs/udf/super.c b/fs/udf/super.c
> index 379867888c36..a1fc51c2261e 100644
> --- a/fs/udf/super.c
> +++ b/fs/udf/super.c
> @@ -2517,8 +2517,8 @@ static unsigned int udf_count_free(struct super_block *sb)
>                         (struct logicalVolIntegrityDesc *)
>                         sbi->s_lvid_bh->b_data;
>                 if (le32_to_cpu(lvid->numOfPartitions) > part) {
> -                       accum = le32_to_cpu(
> -                                       lvid->freeSpaceTable[part]);
> +                       accum = le32_to_cpup(
> +                                       (lvid->freeSpaceTable + part));
>                         if (accum == 0xFFFFFFFF)
>                                 accum = 0;
>                 }
> 
> 
> 
> This version could easily be backported to stable kernels to let them be
> compiled with gcc-10, and then synchronizing with the udftools version of
> the header needs additional changes on top, which do not need to be
> backported.
> 
>        Arnd
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [PATCH 09/15] udf: avoid gcc-10 zero-length-bounds warnings

[Pali Rohár]

On Friday 01 May 2020 22:30:27 Arnd Bergmann wrote:
> On Thu, Apr 30, 2020 at 11:54 PM Pali Rohár <pali@kernel.org> wrote:
> >
> > On Thursday 30 April 2020 23:30:51 Arnd Bergmann wrote:
> > > gcc-10 warns about writes to the empty freeSpaceTable[] array, with
> > > many instances like:
> > >
> > > fs/udf/balloc.c: In function 'udf_bitmap_new_block':
> > > fs/udf/balloc.c:101:36: error: array subscript 65535 is outside the bounds of an interior zero-length array '__le32[0]' {aka 'unsigned int[0]'} [-Werror=zero-length-bounds]
> > >   101 |  le32_add_cpu(&lvid->freeSpaceTable[partition], cnt);
> > >       |                ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
> > > In file included from fs/udf/udfdecl.h:7,
> > >                  from fs/udf/balloc.c:22:
> > > fs/udf/ecma_167.h:363:11: note: while referencing 'freeSpaceTable'
> > >   363 |  __le32   freeSpaceTable[0];
> > >       |           ^~~~~~~~~~~~~~
> >
> > Hi Arnd! This looks like a false-positive warning.
> 
> Right, sorry for not making that clearer in the changelog.
> 
> > > These can all be avoided by using a flexible array member instead.
> > >
> > > Another warning is a bit more obscure:
> > >
> > > fs/udf/super.c: In function 'udf_count_free':
> > > fs/udf/super.c:2521:26: warning: array subscript '(<unknown>) + 4294967295' is outside the bounds of an interior zero-length array '__le32[0]' {aka 'unsigned int[0]'} [-Wzero-length-bounds]
> > >  2521 |      lvid->freeSpaceTable[part]);
> > >
> > > Work around this one by changing the array access to equivalent
> > > pointer arithmetic, as there cannot be multiple flexible-array
> > > members in a single struct.
> >
> 
> > > @@ -360,9 +360,9 @@ struct logicalVolIntegrityDesc {
> > >       uint8_t                 logicalVolContentsUse[32];
> > >       __le32                  numOfPartitions;
> > >       __le32                  lengthOfImpUse;
> > > -     __le32                  freeSpaceTable[0];
> > >       __le32                  sizeTable[0];
> > >       uint8_t                 impUse[0];
> > > +     __le32                  freeSpaceTable[];
> >
> > Please do not change order of members in these structures. Order is
> > strictly defined by ECMA 167 standard and changing them you would just
> > confuse reader. In LVID is free space table before size table.
> 
> Ok
> 
> > If you do not like GNU C extension for zero-length arrays then just
> > replace it by standard C99 flexible arrays. I think that there is no
> > reason to not use standard C99 language constructions, just nobody had
> > motivation or time to change (working) code.
> 
> No, the problem is that only the last member can be a flexible array,

I know, that is why I replaced those 3 zero-length arrays by just one
flexible array in udftools project.

> so when impUse[] is the last member, freeSpaceTable has to be a zero
> length array.
> 
> > Also this file is semi-synchronized with udftools project in which I
> > already replaced all GNU C zero-length arrays by C99 flexible arrays.
> >
> > You can take inspiration what I did with logicalVolIntegrityDesc:
> > https://github.com/pali/udftools/commit/f851d84478ce881d516a76018745fa163f803880#diff-1e1a5b89f620d380f22b973f9449aeaeL381-R384
> 
> Right, this is likely the best workaround.
> 
> > Anyway, if you have a better idea what to do with such on-disk structure
> > and how to represent it in C struct syntax, let me know as it could be
> > updated also in udftools project.
> 
> The trick I used for impUse[] would also work for freeSpaceTable[] to avoid
> the gcc warning, it's still not great, but maybe you like this better:
> 
> arnd@threadripper:~/arm-soc$ git diff
> diff --git a/fs/udf/balloc.c b/fs/udf/balloc.c
> index 02f03fadb75b..666d022eb00b 100644
> --- a/fs/udf/balloc.c
> +++ b/fs/udf/balloc.c
> @@ -98,7 +98,7 @@ static void udf_add_free_space(struct super_block
> *sb, u16 partition, u32 cnt)
>                 return;
> 
>         lvid = (struct logicalVolIntegrityDesc *)sbi->s_lvid_bh->b_data;
> -       le32_add_cpu(&lvid->freeSpaceTable[partition], cnt);
> +       le32_add_cpu(lvid->freeSpaceTable + partition, cnt);
>         udf_updated_lvid(sb);
>  }
> 
> diff --git a/fs/udf/ecma_167.h b/fs/udf/ecma_167.h
> index 14ffe27342bc..215d97d7edc4 100644
> --- a/fs/udf/ecma_167.h
> +++ b/fs/udf/ecma_167.h
> @@ -360,9 +360,9 @@ struct logicalVolIntegrityDesc {
>         uint8_t                 logicalVolContentsUse[32];
>         __le32                  numOfPartitions;
>         __le32                  lengthOfImpUse;
>         __le32                  freeSpaceTable[0];
>         __le32                  sizeTable[0];
> -       uint8_t                 impUse[0];
> +       uint8_t                 impUse[];
>  } __packed;
> 
>  /* Integrity Type (ECMA 167r3 3/10.10.3) */
> diff --git a/fs/udf/super.c b/fs/udf/super.c
> index 379867888c36..a1fc51c2261e 100644
> --- a/fs/udf/super.c
> +++ b/fs/udf/super.c
> @@ -2517,8 +2517,8 @@ static unsigned int udf_count_free(struct super_block *sb)
>                         (struct logicalVolIntegrityDesc *)
>                         sbi->s_lvid_bh->b_data;
>                 if (le32_to_cpu(lvid->numOfPartitions) > part) {
> -                       accum = le32_to_cpu(
> -                                       lvid->freeSpaceTable[part]);
> +                       accum = le32_to_cpup(
> +                                       (lvid->freeSpaceTable + part));
>                         if (accum == 0xFFFFFFFF)
>                                 accum = 0;
>                 }
> 

This is much better as it does not change order of members in LVID
structure. I'm fine with it.

> This version could easily be backported to stable kernels to let them be
> compiled with gcc-10

I do not know what triggers that false-positive warning. But if you
think that this change is enough to "hide" that warning, you can add my
Acked-by: Pali Rohár <pali@kernel.org>

For sure it is better to have just small changes needed for backporting.

> and then synchronizing with the udftools version of
> the header needs additional changes on top, which do not need to be
> backported.

Both header files (ECMA and OSTA) should be in-sync with udftools since
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=614644676394951e73194ea96b3f026c1adf5443
Differences in kernel code are: usage of zero-length array members,
usage of integer types and usage of structure attributes.

If you are planning in future to do some changes in those ECMA or OSTA
header files, please send updates also for udftools. So we will have
header files synchronized as much as possible.

Re: [PATCH 04/15] ath10k: fix gcc-10 zero-length-bounds warnings

[Kalle Valo]

"Gustavo A. R. Silva" <gustavo@embeddedor.com> writes:

> Hi Arnd,
>
> On 4/30/20 16:30, Arnd Bergmann wrote:
>> gcc-10 started warning about out-of-bounds access for zero-length
>> arrays:
>> 
>> In file included from drivers/net/wireless/ath/ath10k/core.h:18,
>>                  from drivers/net/wireless/ath/ath10k/htt_rx.c:8:
>> drivers/net/wireless/ath/ath10k/htt_rx.c: In function 'ath10k_htt_rx_tx_fetch_ind':
>> drivers/net/wireless/ath/ath10k/htt.h:1683:17: warning: array subscript 65535 is outside the bounds of an interior zero-length array 'struct htt_tx_fetch_record[0]' [-Wzero-length-bounds]
>>  1683 |  return (void *)&ind->records[le16_to_cpu(ind->num_records)];
>>       |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> drivers/net/wireless/ath/ath10k/htt.h:1676:29: note: while referencing 'records'
>>  1676 |  struct htt_tx_fetch_record records[0];
>>       |                             ^~~~~~~
>> 
>> The structure was already converted to have a flexible-array member in
>> the past, but there are two zero-length members in the end and only
>> one of them can be a flexible-array member.
>> 
>> Swap the two around to avoid the warning, as 'resp_ids' is not accessed
>> in a way that causes a warning.
>> 
>> Fixes: 3ba225b506a2 ("treewide: Replace zero-length array with flexible-array member")
>> Fixes: 22e6b3bc5d96 ("ath10k: add new htt definitions")
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> ---
>>  drivers/net/wireless/ath/ath10k/htt.h | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/drivers/net/wireless/ath/ath10k/htt.h b/drivers/net/wireless/ath/ath10k/htt.h
>> index e7096a73c6ca..7621f0a3dc77 100644
>> --- a/drivers/net/wireless/ath/ath10k/htt.h
>> +++ b/drivers/net/wireless/ath/ath10k/htt.h
>> @@ -1673,8 +1673,8 @@ struct htt_tx_fetch_ind {
>>  	__le32 token;
>>  	__le16 num_resp_ids;
>>  	__le16 num_records;
>> -	struct htt_tx_fetch_record records[0];
>> -	__le32 resp_ids[]; /* ath10k_htt_get_tx_fetch_ind_resp_ids() */
>> +	__le32 resp_ids[0]; /* ath10k_htt_get_tx_fetch_ind_resp_ids() */
>> +	struct htt_tx_fetch_record records[];
>>  } __packed;
>>  
>>  static inline void *
>> 
>
> The treewide patch is an experimental change and, as this change only applies
> to my -next tree, I will carry this patch in it, so other people don't have
> to worry about this at all.

Gustavo, why do you have ath10k patches in your tree? I prefer that
ath10k patches go through my ath.git tree so that they are reviewed and
tested.

-- 
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH 04/15] ath10k: fix gcc-10 zero-length-bounds warnings

[Gustavo A. R. Silva]

On 5/4/20 06:54, Kalle Valo wrote:
> "Gustavo A. R. Silva" <gustavo@embeddedor.com> writes:
> 
>> Hi Arnd,
>>
>> On 4/30/20 16:30, Arnd Bergmann wrote:
>>> gcc-10 started warning about out-of-bounds access for zero-length
>>> arrays:
>>>
>>> In file included from drivers/net/wireless/ath/ath10k/core.h:18,
>>>                  from drivers/net/wireless/ath/ath10k/htt_rx.c:8:
>>> drivers/net/wireless/ath/ath10k/htt_rx.c: In function 'ath10k_htt_rx_tx_fetch_ind':
>>> drivers/net/wireless/ath/ath10k/htt.h:1683:17: warning: array subscript 65535 is outside the bounds of an interior zero-length array 'struct htt_tx_fetch_record[0]' [-Wzero-length-bounds]
>>>  1683 |  return (void *)&ind->records[le16_to_cpu(ind->num_records)];
>>>       |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> drivers/net/wireless/ath/ath10k/htt.h:1676:29: note: while referencing 'records'
>>>  1676 |  struct htt_tx_fetch_record records[0];
>>>       |                             ^~~~~~~
>>>
>>> The structure was already converted to have a flexible-array member in
>>> the past, but there are two zero-length members in the end and only
>>> one of them can be a flexible-array member.
>>>
>>> Swap the two around to avoid the warning, as 'resp_ids' is not accessed
>>> in a way that causes a warning.
>>>
>>> Fixes: 3ba225b506a2 ("treewide: Replace zero-length array with flexible-array member")
>>> Fixes: 22e6b3bc5d96 ("ath10k: add new htt definitions")
>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>> ---
>>>  drivers/net/wireless/ath/ath10k/htt.h | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/htt.h b/drivers/net/wireless/ath/ath10k/htt.h
>>> index e7096a73c6ca..7621f0a3dc77 100644
>>> --- a/drivers/net/wireless/ath/ath10k/htt.h
>>> +++ b/drivers/net/wireless/ath/ath10k/htt.h
>>> @@ -1673,8 +1673,8 @@ struct htt_tx_fetch_ind {
>>>  	__le32 token;
>>>  	__le16 num_resp_ids;
>>>  	__le16 num_records;
>>> -	struct htt_tx_fetch_record records[0];
>>> -	__le32 resp_ids[]; /* ath10k_htt_get_tx_fetch_ind_resp_ids() */
>>> +	__le32 resp_ids[0]; /* ath10k_htt_get_tx_fetch_ind_resp_ids() */
>>> +	struct htt_tx_fetch_record records[];
>>>  } __packed;
>>>  
>>>  static inline void *
>>>
>>
>> The treewide patch is an experimental change and, as this change only applies
>> to my -next tree, I will carry this patch in it, so other people don't have
>> to worry about this at all.
> 
> Gustavo, why do you have ath10k patches in your tree? I prefer that
> ath10k patches go through my ath.git tree so that they are reviewed and
> tested.
> 

I just wanted to test out a mechanical change. I will remove it from my tree
now and will send a patch to you so you can apply it to your ath.git tree.

Thanks!
--
Gustavo

Re: [PATCH 05/15] bpf: avoid gcc-10 stringop-overflow warning

[Daniel Borkmann]

On 4/30/20 11:30 PM, Arnd Bergmann wrote:
> gcc-10 warns about accesses to zero-length arrays:
> 
> kernel/bpf/core.c: In function 'bpf_patch_insn_single':
> cc1: warning: writing 8 bytes into a region of size 0 [-Wstringop-overflow=]
> In file included from kernel/bpf/core.c:21:
> include/linux/filter.h:550:20: note: at offset 0 to object 'insnsi' with size 0 declared here
>    550 |   struct bpf_insn  insnsi[0];
>        |                    ^~~~~~
> 
> In this case, we really want to have two flexible-array members,
> but that is not possible. Removing the union to make insnsi a
> flexible-array member while leaving insns as a zero-length array
> fixes the warning, as nothing writes to the other one in that way.
> 
> This trick only works on linux-3.18 or higher, as older versions
> had additional members in the union.
> 
> Fixes: 60a3b2253c41 ("net: bpf: make eBPF interpreter images read-only")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Not pretty but looks okay to me, both have the same offset afterwards
in the pahole dump as well.

struct bpf_prog {
[...]
         unsigned int               (*bpf_func)(const void  *, const struct bpf_insn  *); /*    48     8 */
         struct sock_filter         insns[0];             /*    56     0 */
         struct bpf_insn            insnsi[];             /*    56     0 */

         /* size: 56, cachelines: 1, members: 21 */
         /* sum members: 50, holes: 1, sum holes: 4 */
         /* sum bitfield members: 10 bits, bit holes: 1, sum bit holes: 6 bits */
         /* last cacheline: 56 bytes */
};

Applied to bpf-next, thanks!

Re: [PATCH 04/15] ath10k: fix gcc-10 zero-length-bounds warnings

[Kalle Valo]

"Gustavo A. R. Silva" <gustavo@embeddedor.com> writes:

> On 5/4/20 06:54, Kalle Valo wrote:
>> "Gustavo A. R. Silva" <gustavo@embeddedor.com> writes:
>> 
>>> Hi Arnd,
>>>
>>> On 4/30/20 16:30, Arnd Bergmann wrote:
>>>> gcc-10 started warning about out-of-bounds access for zero-length
>>>> arrays:
>>>>
>>>> In file included from drivers/net/wireless/ath/ath10k/core.h:18,
>>>>                  from drivers/net/wireless/ath/ath10k/htt_rx.c:8:
>>>> drivers/net/wireless/ath/ath10k/htt_rx.c: In function 'ath10k_htt_rx_tx_fetch_ind':
>>>> drivers/net/wireless/ath/ath10k/htt.h:1683:17: warning: array subscript 65535 is outside the bounds of an interior zero-length array 'struct htt_tx_fetch_record[0]' [-Wzero-length-bounds]
>>>>  1683 |  return (void *)&ind->records[le16_to_cpu(ind->num_records)];
>>>>       |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> drivers/net/wireless/ath/ath10k/htt.h:1676:29: note: while referencing 'records'
>>>>  1676 |  struct htt_tx_fetch_record records[0];
>>>>       |                             ^~~~~~~
>>>>
>>>> The structure was already converted to have a flexible-array member in
>>>> the past, but there are two zero-length members in the end and only
>>>> one of them can be a flexible-array member.
>>>>
>>>> Swap the two around to avoid the warning, as 'resp_ids' is not accessed
>>>> in a way that causes a warning.
>>>>
>>>> Fixes: 3ba225b506a2 ("treewide: Replace zero-length array with flexible-array member")
>>>> Fixes: 22e6b3bc5d96 ("ath10k: add new htt definitions")
>>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>>> ---
>>>>  drivers/net/wireless/ath/ath10k/htt.h | 4 ++--
>>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/net/wireless/ath/ath10k/htt.h b/drivers/net/wireless/ath/ath10k/htt.h
>>>> index e7096a73c6ca..7621f0a3dc77 100644
>>>> --- a/drivers/net/wireless/ath/ath10k/htt.h
>>>> +++ b/drivers/net/wireless/ath/ath10k/htt.h
>>>> @@ -1673,8 +1673,8 @@ struct htt_tx_fetch_ind {
>>>>  	__le32 token;
>>>>  	__le16 num_resp_ids;
>>>>  	__le16 num_records;
>>>> -	struct htt_tx_fetch_record records[0];
>>>> -	__le32 resp_ids[]; /* ath10k_htt_get_tx_fetch_ind_resp_ids() */
>>>> +	__le32 resp_ids[0]; /* ath10k_htt_get_tx_fetch_ind_resp_ids() */
>>>> +	struct htt_tx_fetch_record records[];
>>>>  } __packed;
>>>>  
>>>>  static inline void *
>>>>
>>>
>>> The treewide patch is an experimental change and, as this change only applies
>>> to my -next tree, I will carry this patch in it, so other people don't have
>>> to worry about this at all.
>> 
>> Gustavo, why do you have ath10k patches in your tree? I prefer that
>> ath10k patches go through my ath.git tree so that they are reviewed and
>> tested.
>> 
>
> I just wanted to test out a mechanical change. I will remove it from my tree
> now and will send a patch to you so you can apply it to your ath.git tree.

Great, thanks.

-- 
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH 03/15] mwifiex: avoid -Wstringop-overflow warning

[Kalle Valo]

Arnd Bergmann <arnd@arndb.de> wrote:

> gcc-10 reports a warning for mwifiex_cmd_802_11_key_material_v1:
> 
> drivers/net/wireless/marvell/mwifiex/sta_cmd.c: In function 'mwifiex_cmd_802_11_key_material_v1':
> cc1: warning: writing 16 bytes into a region of size 0 [-Wstringop-overflow=]
> In file included from drivers/net/wireless/marvell/mwifiex/sta_cmd.c:23:
> drivers/net/wireless/marvell/mwifiex/fw.h:993:9: note: at offset 0 to object 'action' with size 2 declared here
>   993 |  __le16 action;
>       |         ^~~~~~
> 
> As the warning makes no sense, I reported it as a bug for gcc. In the
> meantime using a temporary pointer for the key data makes the code easier
> to read and stops the warning.
> 
> Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94881
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Patch applied to wireless-drivers-next.git, thanks.

08afb432c996 mwifiex: avoid -Wstringop-overflow warning

-- 
https://patchwork.kernel.org/patch/11521661/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH 01/15] crypto - Avoid free() namespace collision

[Herbert Xu]

On Thu, Apr 30, 2020 at 11:30:43PM +0200, Arnd Bergmann wrote:
> gcc-10 complains about using the name of a standard library
> function in the kernel, as we are not building with -ffreestanding:
> 
> crypto/xts.c:325:13: error: conflicting types for built-in function 'free'; expected 'void(void *)' [-Werror=builtin-declaration-mismatch]
>   325 | static void free(struct skcipher_instance *inst)
>       |             ^~~~
> crypto/lrw.c:290:13: error: conflicting types for built-in function 'free'; expected 'void(void *)' [-Werror=builtin-declaration-mismatch]
>   290 | static void free(struct skcipher_instance *inst)
>       |             ^~~~
> crypto/lrw.c:27:1: note: 'free' is declared in header '<stdlib.h>'
> 
> The xts and lrw cipher implementations run into this because they do
> not use the conventional namespaced function names.
> 
> It might be better to rename all local functions in those files to
> help with things like 'ctags' and 'grep', but just renaming these two
> avoids the build issue. I picked the more verbose crypto_xts_free()
> and crypto_lrw_free() names for consistency with several other drivers
> that do use namespaced function names.
> 
> Fixes: f1c131b45410 ("crypto: xts - Convert to skcipher")
> Fixes: 700cb3f5fe75 ("crypto: lrw - Convert to skcipher")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  crypto/lrw.c | 6 +++---
>  crypto/xts.c | 6 +++---
>  2 files changed, 6 insertions(+), 6 deletions(-)

Patch applied.  Thanks.
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 06/15] netfilter: conntrack: avoid gcc-10 zero-length-bounds warning

[Pablo Neira Ayuso]

On Thu, Apr 30, 2020 at 11:30:48PM +0200, Arnd Bergmann wrote:
> gcc-10 warns around a suspicious access to an empty struct member:
> 
> net/netfilter/nf_conntrack_core.c: In function '__nf_conntrack_alloc':
> net/netfilter/nf_conntrack_core.c:1522:9: warning: array subscript 0 is outside the bounds of an interior zero-length array 'u8[0]' {aka 'unsigned char[0]'} [-Wzero-length-bounds]
>  1522 |  memset(&ct->__nfct_init_offset[0], 0,
>       |         ^~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from net/netfilter/nf_conntrack_core.c:37:
> include/net/netfilter/nf_conntrack.h:90:5: note: while referencing '__nfct_init_offset'
>    90 |  u8 __nfct_init_offset[0];
>       |     ^~~~~~~~~~~~~~~~~~
> 
> The code is correct but a bit unusual. Rework it slightly in a way that
> does not trigger the warning, using an empty struct instead of an empty
> array. There are probably more elegant ways to do this, but this is the
> smallest change.

Applied, thanks.

Re: [PATCH 02/15] iwlwifi: mvm: fix gcc-10 zero-length-bounds warning

[Luciano Coelho]

On Thu, 2020-04-30 at 23:30 +0200, Arnd Bergmann wrote:
> gcc-10 complains when a zero-length array is accessed:
> 
> drivers/net/wireless/intel/iwlwifi/mvm/tx.c: In function 'iwl_mvm_rx_ba_notif':
> drivers/net/wireless/intel/iwlwifi/mvm/tx.c:1929:17: warning: array subscript 9 is outside the bounds of an interior zero-length array 'struct iwl_mvm_compressed_ba_tfd[0]' [-Wzero-length-bounds]
>  1929 |     &ba_res->tfd[i];
>       |      ~~~~~~~~~~~^~~
> In file included from drivers/net/wireless/intel/iwlwifi/mvm/../fw/api/tdls.h:68,
>                  from drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h:68,
>                  from drivers/net/wireless/intel/iwlwifi/mvm/sta.h:73,
>                  from drivers/net/wireless/intel/iwlwifi/mvm/mvm.h:83,
>                  from drivers/net/wireless/intel/iwlwifi/mvm/tx.c:72:
> drivers/net/wireless/intel/iwlwifi/mvm/../fw/api/tx.h:769:35: note: while referencing 'tfd'
>   769 |  struct iwl_mvm_compressed_ba_tfd tfd[0];
>       |                                   ^~~
> 
> Change this structure to use a flexible-array member for 'tfd' instead,
> along with the various structures using an zero-length ieee80211_hdr
> array that do not show warnings today but might be affected by similar
> issues in the future.
> 
> Fixes: 6f68cc367ab6 ("iwlwifi: api: annotate compressed BA notif array sizes")
> Fixes: c46e7724bfe9 ("iwlwifi: mvm: support new BA notification response")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Patch applied to iwlwifi-next.git, thanks.

9cec1d547cb7 iwlwifi: mvm: fix gcc-10 zero-length-bounds warning