[dpdk-dev] [PATCH] kni: fix build with gcc 8.1

[Ferruh Yigit]

On 6/20/2018 12:35 AM, Stephen Hemminger wrote:
> On Tue, 19 Jun 2018 13:08:55 +0100
> Ferruh Yigit <ferruh.yigit at intel.com> wrote:
> 
>> Error observed when CONFIG_RTE_KNI_KMOD_ETHTOOL config option is
>> enabled.
>>
>> build error:
>> In function ‘strncpy’,
>>     inlined from ‘igb_get_drvinfo’ at
>>     .../dpdk/build/build/kernel/linux/kni/igb_ethtool.c:814:2:
>>     .../include/linux/string.h:246:9: error: ‘__builtin_strncpy’ output
>>     may be truncated copying 31 bytes from a string of length 42
>>     [-Werror=stringop-truncation]
>>       return __builtin_strncpy(p, q, size);
>>                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> Fixed by reducing the adapter->fw_version size and adjusting strncpy
>> limit size.
>>
>> Cc: stable at dpdk.org
>>
>> Signed-off-by: Ferruh Yigit <ferruh.yigit at intel.com>
>> ---
>>  kernel/linux/kni/ethtool/igb/igb.h         | 2 +-
>>  kernel/linux/kni/ethtool/igb/igb_ethtool.c | 2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/kernel/linux/kni/ethtool/igb/igb.h b/kernel/linux/kni/ethtool/igb/igb.h
>> index 8aa2a3088..5e798ae83 100644
>> --- a/kernel/linux/kni/ethtool/igb/igb.h
>> +++ b/kernel/linux/kni/ethtool/igb/igb.h
>> @@ -592,7 +592,7 @@ struct igb_adapter {
>>  	int int_mode;
>>  	u32 rss_queues;
>>  	u32 vmdq_pools;
>> -	char fw_version[43];
>> +	char fw_version[32];
> 
> Use ETHTOOL_FWVERS_LEN?

Yes, that is what drvinfo->fw_version uses, and it seems it has been around
enough to not cause any build issue, will use that one.

> 
>>  	u32 wvbr;
>>  	struct igb_mac_addr *mac_table;
>>  #ifdef CONFIG_IGB_VMDQ_NETDEV
>> diff --git a/kernel/linux/kni/ethtool/igb/igb_ethtool.c b/kernel/linux/kni/ethtool/igb/igb_ethtool.c
>> index 064528bcf..0b8b25ff1 100644
>> --- a/kernel/linux/kni/ethtool/igb/igb_ethtool.c
>> +++ b/kernel/linux/kni/ethtool/igb/igb_ethtool.c
>> @@ -812,7 +812,7 @@ static void igb_get_drvinfo(struct net_device *netdev,
>>  	strncpy(drvinfo->version, igb_driver_version, sizeof(drvinfo->version) - 1);
>>  
>>  	strncpy(drvinfo->fw_version, adapter->fw_version,
>> -		sizeof(drvinfo->fw_version) - 1);
>> +		sizeof(drvinfo->fw_version));
> 
> Why not:
> 	strlcpy(drvinfo->fw_version, adapter->fw_version,
> 		sizeof(drvinfo->fw_version));

Just to be cautious about changing API, to not have any problem with older
version of kernels.
But it seems strlcpy supported long enough to not cause an issue, I will use it.