[dpdk-dev] [RFC 0/2] gcc 10 disable stringop-overflow warning

[Kevin Traynor]

On 31/03/2020 15:53, Stephen Hemminger wrote:
> On Tue, 31 Mar 2020 15:08:26 +0100
> Kevin Traynor <ktraynor at redhat.com> wrote:
> 
>> struct virtchnl_rss_key {
>>         u16 vsi_id;
>>         u16 key_len;
>>         u8 key[1];         /* RSS hash key, packed bytes */
>>         ^^^^^^^^^
>> };
>>
>> Then in iavf_configure_rss_key()
>>
>> 	len = sizeof(*rss_key) + vf->vf_res->rss_key_size - 1;
>>                                              ^^^^^^^^^^^^
>> 	rss_key = rte_zmalloc("rss_key", len, 0);
>>                   ^^^ extra space beyond key[1] allocated here
>>
>> <snip>
>> 	rte_memcpy(rss_key->key, vf->rss_key, vf->vf_res->rss_key_size);
>> 	                    ^^^                           ^^^^^^^^^^^^
>>
>> At runtime we have allocated extra space at the end of the struct for
>> key, and the same size used in the malloc is also considered when
>> finding the right branches in the memcpy fns. But the compiler does not
>> know value of size and it simply sees there can be casts of a 1 byte key
>> to 16 or 32 bytes in some branches of the memcpy fns, so gives a warning.
> 
> The standard way to do such a thing is to use an empty
> array. The Linux kernel has just gone through cleaning up
> all these zero length (and it this case one) array at
> end of function.
> 

Thanks for the tip. There is only one occurrence of a zero-length array
in these warning (sess_data[0] in ice) and changing to [] does indeed
remove the warning for that.

For the others they have a defined length so it cannot just be removed,
some don't have any dynamic allocation at all, sizes are checked etc.

I don't think adding dynamic allocation for those structs just to get
around this warning is the right way to go.

Crypto/iavf/ip_pipeline maintainers - any comment?

../drivers/crypto/caam_jr/caam_jr_pvt.h:187:10: note: at offset 0 to
object ‘digest’ with size 32 declared here
../drivers/crypto/ccp/ccp_crypto.h:272:11: note: at offset 0 to object
‘key’ with size 32 declared here
../drivers/crypto/dpaa_sec/dpaa_sec.h:217:10: note: at offset 0 to
object ‘digest’ with size 32 declared here
../drivers/crypto/virtio/virtio_cryptodev.h:36:10: note: at offset 0 to
object ‘iv’ with size 16 declared here

../drivers/net/iavf/../../common/iavf/virtchnl.h:508:5: note: at offset
0 to object ‘key’ with size 1 declared here
../drivers/net/iavf/../../common/iavf/virtchnl.h:516:5: note: at offset
0 to object ‘lut’ with size 1 declared here

../lib/librte_pipeline/rte_table_action.c:1648:12: note: at offset 0 to
object ‘cipher_iv’ with size 16 declared here
../lib/librte_pipeline/rte_table_action.c:1650:12: note: at offset 0 to
object ‘auth_iv’ with size 16 declared here
../lib/librte_pipeline/rte_table_action.c:1655:12: note: at offset 0 to
object ‘iv’ with size 16 declared here
../lib/librte_pipeline/rte_table_action.c:1656:12: note: at offset 0 to
object ‘aad’ with size 16 declared here
../lib/librte_pipeline/rte_table_action.c:1728:10: note: at offset 0 to
object ‘iv_aad_data’ with size 32 declared here